Technologie a protokoly multimediálních komunikací pro integrovanou výuku VUT a VŠB-TUO

Transkript

1 VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA Fakulta elektrotechniky a informatiky Technologie a protokoly multimediálních komunikací pro integrovanou výuku VUT a VŠB-TUO Garant předmětu: Miroslav Vozňák Autor textu: Miroslav Vozňák Ostrava 2014 Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/ Evropského sociálního fondu a státním rozpočtem České republiky.

2 Za odbornou náplň tohoto vydání odpovídá autor. Miroslav Vozňák je docentem na Fakultě elektrotechniky a informatiky VŠB-Technické univerzity v Ostravě, kde přednáší předmět Voice over IP pro studenty navazujícího magisterského studia, kurz VoIP je na fakultě nabízen ve studijním programu Informační a komunikační technologie. Vznik skript byl podpořen projektem č. CZ.1.07/2.2.00/ Evropského sociálního fondu a státním rozpočtem České republiky. Tato publikace neprošla redakční ani jazykovou úpravou. Miroslav Vozňák, 2014, VŠB-Technická univerzita Ostrava Autor: Miroslav Vozňák Katedra: Katedra telekomunikační techniky Název: Technologie a protokoly multimediálních komunikací pro integrovanou výuku VUT a VŠB-TUO Místo, rok, vydání: Ostrava, 2014, 1. vydání Počet stran: 188 Vydala: Vysoká škola báňská-technická univerzita Ostrava Náklad CD-ROM, 100 ks Neprodejné ISBN

3 PŘEDMLUVA Vážené studentky a vážení studenti, mým cílem bylo vytvořit studijní materiál, který by reflektoval na současný trend hlasových komunikačních systémů. Do jaké míry má snaha byla úspěšná, nepochybně ukáže čas a především, do jaké míry bude koncept po obsahové stránce nadčasový. VoIP lze chápat jako technologii, která využívá prostředky sítě Internet k přenosu hlasu, v aplikační rovině pak vidíme IP telefonii jako aplikaci nad VoIP. První pokusy s přenosem hlasu datovaných v počátcích Internetu uskutečnil Danny Cohen v roce Komerční úspěch Internetu znamenal podnět k intenzivnímu vývoji v této oblasti a přijetí mezinárodně uznávaných standardů, a to především H.323 v roce 1996 z organizace ITU-T a SIP doporučení v roce 1999 z dílny IETF. V naší publikaci se budeme orientovat na SIP, a to vzhledem k faktu, že SIP se stal de-facto stěžejním protokolem pro IP telefonii a s přihlédnutím k rozsahu publikace a užitné hodnotě informací byl pro autory jednoznačnou volbou. V první části se čtenář seznámí s nezbytnými teoretickými základy VoIP technologie a SIP protokolu, které zužitkuje v druhé části věnované Asterisku. Tak jako je Apache symbolem úspěšného projektu webového serveru, tak analogicky Asterisk představuje v IP telefonii uznávané komunikační řešení pro nasazení IP telefonie. Na závěr této předmluvy bych rád poděkoval své manželce Pavle a našim dětem za trpělivost, bez které by tato skripta nevznikla a rovněž děkuji kolegům, kteří se mnou odborně spolupracují a přispěli tak k formování obsahu této publikace a to především svým nejbližším spolupracovníkům Honzovi Rozhonovi a Filipovi Řezáčovi. V neposlední řadě patří poděkováním i mým kolegům z FEKT VUT v Brně za spolupráci při řešení projektu OP VK č. CZ.1.07/2.2.00/ Společné aktivity VUT a VŠB-TUO při vytváření obsahu a náplně odborných akreditovaných kurzů ICT, za jehož podpory byl obsah předmětu inovován a vytvořena tato skripta. V Ostravě, leden 2014 Miroslav Vozňák Miroslav Vozňák, nar. 1971, je docentem Fakulty elektrotechniky a informatiky VŠB-Technické univerzity v Ostravě, je ovšem zván rovněž k přednáškám na řadu zahraničních univerzit jako např. v letech na University of Milan, 2012 na University of Ankara, v roce 2013 byl hostujícím profesorem na University of Calabria a od téhož roku je veden jako overseas profesor na Ton Duc Thang University v Saigonu. Je autorem či spoluautorem více než 300 článků v časopisech, příspěvcích na konferencích či kapitol v knihách, z toho přes 80 z nich je indexováno v citační databázi vědeckých publikací Scopus společnosti Elsevier a v Google Scholar je u jeho jména zaevidováno na 500 citací článků. Od roku 2011 je rovněž výzkumným pracovníkem národního superpočítačového centra IT4Innovations. Profesně se věnuje informačním a komunikačním technologiím, doménami jeho výzkumných aktivit jsou Voice over IP, kvalita řeči a síťová bezpečnost. voznak@ieee.org

4 OBSAH 1 Přenos sítí Internet v reálném čase Real Time Protocol Zabezpečení přenosu RTP Zabezpečení pomocí SRTP Návrh vylepšení SRTP pomocí ZRTP Přenos DTMF a jiných tónů přes RTP SCTP Stream Control Transmission Protocol 13 2 Standard ITU-T H Rodina protokolů H.32x Verze H Koncepce komunikace v H Protokolový model H Prvky H.323 a jejich vlastnosti Signalizace RAS Signalizace Q Signalizace H Modely spojení DRC a GRC Vybrané scénáře toku zpráv H Konfigurace ISDN modulů v Cisco směrovačích Příklad nastavení BRI Příklad nastavení PRI Pravidla volby čísel a směrů Třídy kodeků Chybějící kontrolní vyzváněcí tón Diagnostika na hlasové bráně GNU Gatekeeper Instalace a konfigurace GnuGK Registrace EP Propojení GnuGK s jiným GK Statická registrace GW v GnuGK Autentizace v GnuGK Autorizace v GnuGK Návrh sítě s konfigurací GnuGK Nastavení GK a mezizónové propojení Nastavení VoGW a dynamické registrace na GK 50 i

5 3 Session Initiation Protocol Základní popis protokolu SIP Prvky SIP řešení User Agent a Back to Back User Agent SIP Proxy Server SIP Registrar Server SIP Redirect Server SIP žádosti a odpovědi Základní popis SIP hlavičky typické žádosti SIP metody SIP odpovědi Transakce Dialog SIP časovače a retransmise Zabezpečení v SIPu Registrace Směrování Směrování dle RURI a Via SIP trapezoid Udržení SIP Proxy v signalizační trase SDP- protokol popisu relace Konstrukce položek SDP pro komunikaci SIP/SDP Offer/Answer model 84 4 Další metody rozšiřující SIP Metoda PRACK (Provisional Response Acknowledgement) Použití PRACK při volání do PSTN Early Media Metoda UPDATE Metoda REFER Metoda MESSAGE (Instant Messaging) Metody SUBSCRIBE,NOTIFY,PUBLISH (Event/Notification) Realizace vybraných doplňkových služeb v SIPu Síťování SIP s PSTN Paralelní vyzvánění - Forking Přidržení hovoru - Call hold Hudba při přidržení Music on Hold Předání hovoru - Call transfer Přesměrování volání - Call forwarding Indikace zprávy - Message waiting indication 102 ii

6 4.14 Vytočení kliknutím - Click to dial Zpětné volání Call Back Metoda INFO SIPp a jeho použití k emulaci SIP relací Instalace Scénáře pro SIPp SIPp v příkazovém řádku Vytváření XML schémat Vkládání hodnot z externích souborů Ovládání SIPp za běhu Další tipy pro SIPp NAT vs. IP telefonie Terminologie Popis problému s průchodem SIP zpráv přes NAT Klasifikace typů NAT Provozování IP telefonie přes NAT STUN server Překonání NATu pomocí TURN, ICE a rport Asterisk Verze Asterisku Popis Asterisku Režimy Asterisku Kodeky a protokoly Asterisku Služby Asterisku Instalace Globální nastavení asterisk.conf a modules.conf Konfigurace SIP a IAX uživatelů v sip.conf a iax.conf SIP uživatel v sip.conf IAX uživatel v iax.conf Další možnosti sip.conf a iax.conf Dialplan extensions.conf Kontexty Pobočky Priority Aplikace Tvorba dialplanu Vzory Pattern Matching 145 iii

7 7.6.7 Offset při práci s řetězcem Vložené kontexty Include Statements Časové Vložené kontexty Proměnná ${EXTEN} a funkce ${CALLERID(num)} Voic IVR Interactive Voice Response Jednoduché IVR Neplatný vstup (extension i) Pauzy Víceúrovňové IVR DAHDI/ZAPTEL Chan_dahdi.conf (Zapata.conf) Peering mezi dvěma Asterisky Použití SRTP a SIPS/TLS Zabezpečení médií pomocí SRTP Zabezpečení signalizace v Asterisku pomocí SIPS Asterisk a kalendáře Instalace Davical serveru Propojení Asterisku a Davical serveru Aplikace kalendářových funkcí Směrování volání na základě zaneprázdněnosti Zapisování do kalendáře Čtení záznamů uložených v kalendáři Upozornění na schůzku XMPP server a Asterisk Instalace Openfire instalace XMPP klientů Propojení XMPP a Asterisku Kamailio Popis modulů Kamailia Instalace o rozběhnutí Kamailia WebRTC a nové směry v IP telefonii 179 Literatura 182 Rejstřík 186 iv

8 1 Přenos sítí Internet v reálném čase 1 Přenos sítí Internet v reálném čase Transportní protokoly Internetu nabízí spolehlivou službu s potvrzováním doručených datagramů pomocí spojově orientovaného protokolu TCP (Transmission Control Protocol) anebo nespolehlivou službu na nespojově orientovaném protokolu UDP (User Datagram Protocol). UDP protokol přidává k IP záhlaví důležitá pole, kterými jsou: zdrojový a cílový port služby, délka přenášených dat včetně záhlaví a kontrolní součet pseudozáhlaví. Nepochybně stojí za zmínku, že UDP nezaručuje doručení ve správném pořadí, což některým aplikacím přináší komplikace. Je zřejmé, že u požadavku na realtime přenos není možné použít službu s potvrzováním datagramů, neboť informace pozbývá svou platnost s časem a pro IP telefonii je nutné použit transportní službu zajišťovanou UDP [v92]. UDP protokol je vhodnější pro Real-time aplikace, umožňuje sice nespolehlivé, ale rychlé doručování. I tady ovšem najdeme nedostatky a potřebu adaptace pomocí dalšího protokolu nad UDP, řešením je protokol přenosu v reálném čase RTP, struktura zprávy je na zobrazena na obr [v92]. Obr.1.1. Struktura zprávy pro real-time přenos. 1.1 Real Time Protocol Real Time Protocol je označován jako protokol aplikační vrstvy, který využívá transportní protokol UDP, ale dle účelu a obsahu polí hlaviček nese důležité znaky transportního protokolu a tak se jeví logičtější ho zařadit na transportní vrstvu hned nad UDP, jehož přenos vylepšuje. Tento pohled je ale spíše filozofický a neřeší nic zásadního, pojďme se podívat na jednotlivá pole RTP a způsob adaptace real-time aplikací na přenos v Internetu, viz. obr. 1.2 RTP protokol především zajišťuje seřazení zaslaných paketů (Sequence Number) a jejich časové značkování (Timestamp), další vlastnost, která ho řadí do transportní vrstvy je multiplexování a demultiplexování. Pokud si vezmeme postup odesílání hlasu v IP sítí, tak tok bitů digitalizovaného hlasu ve zvoleném formátu (např. PCM) je naporcován do bloků (typicky 20 B až 160 B) a každý blok je opatřen hlavičkou RTP o velikosti 12 B, dále se před hlavičku zařadí 8 B hlavičky UDP, viz. obr Tím je datagram připraven ke vstupu do vrstvy síťové, kde dostane IP hlavičku o velikosti 20 B, celkově tedy bylo k užitečné zátěži přidáno 40 B. Jednotlivá pole RTP obsahují tyto položky, viz. obr.1.2 : 1

9 1 Přenos sítí Internet v reálném čase V je verze. Určuje verzi RTP, P je doplnění. Pokud je nastaveno, paket obsahuje na konci jeden či více doplňkových oktetů, které nenesou užitečná data, X je rozšiřující bit. Pokud je nastaven, pak pevné záhlaví je následováno právě jedním rozšířením záhlaví, které má definovanou strukturu, CC je CSRC count obsahuje číslo identifikátoru příspěvku zdroje, M je značka. Interpretace značky je různá. Lze jí použít např. jako označení konce rámce v paketovém toku, na své využití ještě čeká. Payload Type určuje formát užitečného zatížení RTP a stanovuje jeho význam pro aplikaci. Další kód typu užitečného zatížení je definován dynamicky, ale ne již přes RTP, Sequence number se zvyšuje o jeden pro každý vyslaný RTP paket Přijímač jej využívá pro určení případné ztráty paketu a pro obnovení souslednosti paketu, Timestamp vyjadřuje vzorkovací značku prvního oktetu v RTP paketu. Vzorkovací značka musí být odvozena od lineárního časovače z důvodu synchronizace a korekce rozptylu zpoždění (jitter). Rozlišení časovače musí být dostatečné pro požadovanou synchronizační přesnost a pro zjištění jitteru příchozího paketu (např. jeden kmit za videosnímek není dostačující), SSRC identifikuje synchronizační zdroj. Tento identifikátor je zvolen náhodně s tím, že žádné dva synchronizační zdroje v rámci jedné RTP relace nemají stejný SSRC identifikátor, CSRC je identifikační seznam přispívajících zdrojů. Identifikuje přispívající zdroj z důvodu užitečné informace obsažené v tomto paketu. Obr.1.2. Jednotlivá pole RTP dle specifikace RFC Samotný přenos audia/videa v RTP bývá doplněn o dohledový protokol RTCP (Real Time Control Protocol), který nese statistické informace o průběhu přenosu. Port pro RTCP je nastaven o jedničku vyšší než RTP, minimální doba pro odeslání RTCP je stanovena na 2 sec., např. u G.711 by to znamenalo jeden paket RTCP na sto paketů RTP, pro čísla portů platí (1.1), přičemž portům RTP jsou přidělována sudá čísla. port_rtcp=port_rtp+1 (1.1) 2

10 1 Přenos sítí Internet v reálném čase Obr Formát pole Payload Type. 3

11 1 Přenos sítí Internet v reálném čase V současné době prošel Real-Time protokol třemi verzemi, a to: RFC 1889, z roku 1996 (Transport Protocol for Real-Time Applications), původní doporučení; RFC 3550, z roku 2003, drobná vylepšení oproti RFC 1889 především v části dohledu nad RTP tokem, tím původní RFC 1889 zastaralo; RFC 3711, z roku 2004, specifikuje zabezpečený přenos RTP jako SRTP (Secure Real-time Transport Protocol). Hlavička RTP může být komprimována ze 40B na 2-3B s použitím kompresního protokolu crtp (compressed RTP), jelikož je vyžadována podpora na obou stranách, tak je použití víceméně omezeno na dvoubodové spoje a crtp není příliš rozšířen [coli], [cam]. Typickým portem RTP je 5004 a RTCP tím pádem 5005, ale v zásadě může být použit jakýkoliv port vyšší než 1024, např. Cisco zařízení alokují pro RTP porty v rozmezí až Řídící protokol RTCP Původní RFC 1889 pro RTP z ledna 1996 vydrželo poměrně dlouho a další RFC pro RTP bylo uvolněno až v červnu roku Implementace RTP dle RFC 3550 si dokáže poradit se starší RFC 1889, neboť ve formátu paketu či v obsahu hlaviček nedošlo ke změnám, změny jsou v RTCP, čili v protokolu dohledu toku médií. Změnila se pravidla a algoritmy užití protokolu, nejvýznamnější změnou je specifikace typů zpráv RTCP a rozšíření týkající se pravidel odesílání RTCP (jedná se o algoritmus časování odesílání RTCP). RTCP shromažďuje statistiky přenosu na RTP, informace o množství odeslaných bajtů a počtu paketů, ztracených paketů, rozptylu zpoždění. Dle RFC 3550 je definováno celkem pět typů zpráv: SR (Sender Report) soubor statistik od odesílatelů, posílá se aktuální identifikace zdroje synchronizace (SSRC), časová značka (timestamp), počet odeslaných paketů a odeslaných bajtů, RR (Receiver Report) soubor statistik od příjemců, obsahuje jednak podíl ztracených paketů k celkovému množství očekávaných, počet ztracených paketů, aktuální sekvenční číslo (SN), jitter, poslední timestamp a čas, který uběhl od poslední zprávy SR, SDES (Source DEScription) vlastnosti odesílatelů RTP komunikace (jejich vizitky ), jednak je to SSRC a jméno (obvykle URI), BYE (End message) signalizuje ukončení relace; APP funkce specifické pro jednotlivé aplikace. 1.2 Zabezpečení přenosu RTP Použitím nešifrovaného přenosu pomocí RTP zvyšujeme riziko odposlechu hovoru [v191], [v193]. Oblíbený síťový softvérový analyzátor Wireshark umí ze zachyceného RTP toku rekonstruovat původní zvukovou stopu. Získání zvukové stopy z RTP paketů a její následné přehrání či uložení, je v aplikaci Wireshark možné pouze u kodeků PCM A-law a µ-law, ovšem existuje řada placených analyzátorů, které zpracují pro přehrání audio signál i s jinými kodeky (např. Observer). Nešifrovaný přenos RTP je proto velkým hazardem a zabezpečení je nezbytné. U transportních protokolů užívaných pro multimédia musíme hlavně brát zřetel na to, že komunikace pomocí těchto protokolů probíhá v reálném čase, proto i zabezpečovací techniky musí byt implementovány tak, aby vznikalo minimální časové zpoždění [v138], [v166] a [v194]. 4

12 1 Přenos sítí Internet v reálném čase Zabezpečení pomocí SRTP Stejně jako u signalizačních protokolů, tak ani nejpoužívanější protokol RTP neobsahuje ve svém základu žádné ochranné metody či mechanizmy, a proto byl v roce 2004 v RFC 3711 definován protokol SRTP (Secure Real-time Transport Protocol). Formát paketu SRTP je odvozen od RTP, šifrován je přenášený obsah užitečné informace (payload) a integrita polí hlaviček je zajištěna pomocí autentizační značky (authentication tag), která je získána algoritmem HMAC-SHA-1. Do této hašovací funkce vstupuje klíč auth_key a užitečná zátěž RTP, výstupem je autentizační značka, která je přidána do poslední položky zabezpečeného SRTP datagramu. Obr HMAC-SHA1 funkce Použití SRTP autentizační značky je v RFC 3711 doporučeno vždy, zatímco další značka SRTP MKI je nepovinná Obr Obsah polí hlavičky SRTP 5

13 1 Přenos sítí Internet v reálném čase MKI (Master Key Identifier) je prezentován jako hlavní klíč a může být použit pro správu klíčů (key management), využití je pro účely obměny klíčů během relace, identifikuje konkrétního hlavní klíč (master_key) užívaného v SRTP, z něj jsou odvozeny další důležité klíče, což je zobrazeno v obr MKI zvyšuje bezpečnost, protože během jedné relace mohou být klíče střídány [v120]. Obr Režim šifrování OFB. Podívejme se nyní na kryptografické mechanizmy užité v RFC SRTP definuje používání režimu šifrování AES-CTR (Counter Mode) anebo AES-f8, přičemž výchozím módem je AES-CTR. Povinně implementováno musí být šifrování AES-CTR a případně může být nepovinně podporován i algoritmus AES-f8. Zatím jsme se s implementací algoritmu AES-f8 v SRTP dosud nesetkali, všichni implementují AES-CTR. V případě f8 jde o aplikaci módu OFB (Output Feedback) a používá se pro šifrování v UMTS sítích. U OFB se otevřený text sčítá na členu nonekvivalence s výstupním blokem získaným aplikací blokové šifry, viz. obr První výstupní blok je vytvořen šifrovací funkcí CIPH K z inicializačního vektoru a je zároveň vstupem do druhého bloku, kde po aplikaci šifrovacího algoritmu získáme druhý výstupní blok, který je opět vstupem do dalšího. Šifrový text získáme operací exkluzivní disjunkce, vstupními hodnotami jsou jednak bity otevřeného textu a jednak bity z jednotlivých výstupních bloků. Jedná se o režim proudové šifry (stream cipher mode) anebo exaktně řečeno, u OFB dochází k převodu blokové šifry na proudovou. Čítačový režim CTR, viz. obr. 1.7, je zjednodušenou verzi zpětnovazební šifry OFB, kdy při šifrování je namísto vazby na předchozí blok použita vazba s hodnotou inkrementálního čítače, viz. obrázek. Opět dochází převodu blokové šifry na proudovou. CTR rovněž využívá inicializační hodnotu, která se načte do vstupního registru (Counter 1) a po zašifrování funkcí CIPH K dostáváme první výstupní blok, který se sčítá na členu XOR s otevřeným textem. Poté doje k aktualizaci čítače 6

14 1 Přenos sítí Internet v reálném čase (obvykle přičtením jedničky) a získáváme Counter 2, opět se opakuje jeho šifrování a operace operací exkluzivní disjunkce s otevřeným textem. Obr CTR režim šifrování. Aktualizace čítače je definována poměrně volně, hodnota nemusí být inkrementována o jedničku, musí být ovšem splněna podmínka, že obsah čítačů nesmí být stejný. Obr Blokové schéma šifrování obsahu RTP Podívejme se nyní na aplikaci AES-CTR v SRTP, viz. obr Důvěrnost přenášených dat v paketu zajišťuje kryptografický primitiv AES, který funguje v tomto případě jako generátor pseudonáhodných klíčů. Vstupem do generátoru je šifrovací klíč encr_key a inicializační vektor IV, který sestává z kontrolního součtu salt key, SSRC a indexu paketu. Výsledný klíč je pomocí logické operace XOR 7

15 1 Přenos sítí Internet v reálném čase aplikován na nezašifrovaný obsah paketu, což odpovídá CTR režimu šifrování. Inicializační vektor IV je získán z rovnice (1.6), ve které SSRC je identifikátor synchronizace, k s je sůl a i je index SRTP paketu odesílatele IV (ks 2 ) (SSRC 2 ) (i 2 ) = (1.6) Šifrovací klíče encr_key a salt_key, jsou získány opět pomocí AES-CTR, přičemž jsou odvozeny z hlavního klíče master_key, viz. obr Problém je ovšem v distribuci hlavního klíče, který je distribuován během sestavení spojení, v signalizaci SIP se používá SDP (Session Description Protocol). Obr Odvození klíčů pro šifrovací schéma. Pokud je šifrování provedeno na úrovni SIP, není pochopitelně nutné používat silné kryptografické algoritmy pro přenášení informací uvnitř SIP, sice je to možné, ale je to zbytečné plýtvání výpočetním výkonem. Jako ukázku naprosto nevhodné implementace a přenosu šifrovacího klíče, uvádím příklad zachycený při použití MS Messenger k=base64:d0c7ni7jtkf+mjjy7bfxioihnje6rrckz46gstvxele= Zda bylo použito base64 či nebylo, to už není zásadní, base64 je triviální způsob kódování, který lze dekódovat ručně s papírem, tužkou a ASCII tabulkou po ruce a navíc interoperabilita s dalšími zařízeními bude problematická. Zásadním problémem je zde přenos šifrovacího klíče přímo v SDP s využitím deskriptoru k=* (encryption key), takto by to opravu býti nemělo. 8

16 1 Přenos sítí Internet v reálném čase V dalším příkladu je způsob vyjednávání klíčů popsaného v RFC 4568 z roku 2006, jedná se o SDES (Security Descriptions for Media Streams). V SDP pod m řádkem s popisem médií se přidává crypto atribut ve formě a řádku s popisem režimu šifrování obsahu (AES_CM_128_, F8_128_) a vytvoření autentizační značky (HMAC_SHA1_80, HMAC_SHA1_32). a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0rmdmcmvcspeec3qgzinwpvlfjhqx1cfhawjsoj 2^20 1:32 Pod crypto atributem je inline řádek obsahující klíče (master key a salt key) a politiky vztažené k master klíči, tzn. jak dlouho bude platit (lifetime) a zda se bude používat MKI (master key identifier) s konkrétním master klíčem "inline:" <key salt> [" " lifetime] [" " MKI ":" length]. Zřetězení dvou klíčů key salt je opět kódováno v base64. Níže je uveden příklad použití SDES dle RFC Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): IN IP Session Name (s): SIP Call Connection Information (c): IN IP Time Description, active time (t): 0 0 Media Description, name and address (m): audio 5004 RTP/SAVP 0 Media Attribute (a): sendrecv Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:nuc6m+o/eo+bejivqdtozo4j3pb4awzyq05z07qd Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): ptime:20 Bez použití TLS anebo S/MIME, kterým by bylo zašifrován obsah SDP v SIP relaci, neposkytuje ani výše uvedené řešení dostatečnou úroveň zabezpečení. S tím nebyl spokojen Philip Zimmermann, který přišel s dalším vylepšením umožňující bezpečně sestavit klíče na obou komunikujících stranách. Philip Zimmermann již zanechal ve světě sítí důležitou stopu v oblasti šifrování ové komunikace a proslavil se protokolem PGP (PGP Pretty Good Privacy). Jelikož produkt svého intelektu poskytl v roce 1991 k volnému použití pro tehdy rodící se Internet, tak si zasloužil v USA obvinění z nelegálního vývozu kryptografického softvéru, na který se tehdy stahovalo embargo a tři roky byl vyšetřován a pronásledován FBI, než byl zbaven tohoto absurdního obvinění. Návrhem nového zabezpečení RTP s označením ZRTP se bude zabývat další podkapitola Návrh vylepšení SRTP pomocí ZRTP ZRTP (Zimmermann Real-time Transport Protocol, RFC 6189) neslouží jako náhrada za SRTP, ale pouze jako nadstavba pro jeho lehčí použití a implementaci. ZRTP rozšiřuje SRTP protokol o mechanismus pro počáteční dohodu na klíčích a dokáže chránit i proti útokům zvaných jako MiTM (Man in the middle). Zimmermann si všiml způsobu distribuce hlavního klíče v SRTP, ve kterém viděl slabinu a možnost prolomení šifrované komunikace třetí stranou. Zásadním rozdílem je, že výměna probíhá v dohodnuté trase pro média a zprávy jsou transportovány přes stejné porty jako RTP. Návrh ZRTP používá při dohodě na klíčích Diffie-Hellmanův algoritmus, komunikující strany si vyměňují řetězce, ze kterých je odvozen utajený šifrovací klíč, tento klíč se přitom nepřenáší, jeho získání z přenášených zpráv třetí osobou je velmi časově náročným matematickým problémem řešení diskrétního logaritmu s velkými čísly. Detekce MiTM útoků se řeší zobrazováním krátkých 9

17 1 Přenos sítí Internet v reálném čase autentizačních řetězců SAS (Short Authentication String). ZRTP užívá tři fáze k tomu, aby zjistil a nastavil potřebné klíče a přešel na SRTP mód: detekce, zda-li účastníci podporují ZRTP implementaci, výměna hodnot pro dohodu na klíčích s využitím DH algoritmu přepnutí do SRTP módu a úspěšné používání SRTP. V první fázi si oba ZRTP účastníci vymění mezi sebou informace o šifrování, dohodnutých klíčích a způsoby autentizace, které budou používat. Současně ZRTP specifikace tyto šifrovací režimy: AES Counter Mode s délkou klíče 128 bit, AES Counter Mode s délkou klíče 256 bit. Pro dohodu na klíči se používá ZRTP Diffie-Hellmanův algoritmus. Pro tento algoritmus ZRTP může využívat dva různé módy: 3072 bit Diffie - Hellman hodnoty, 4096 bit Diffie - Hellman hodnoty. Obr Princip DH algoritmu. Princip DH algoritmu je znázorněn na obrázku 1.10, tento algoritmus umožňuje rychle sestavit tajný klíč, aniž by byl přenesen komunikujícími stranami přenesen, přičemž útočník odposlouchávající komunikaci by k jeho sestavení potřeboval extrémní výpočetní výkon a čas. DH a algoritmus je postaven na složitosti řešení diskrétního logaritmu. Mějme rovnici g = y, přičemž známe hodnoty g, y a neznámou a vypočteme jako a = log g y, to je triviální problém logaritmu. Pokud ale aplikujeme funkci modulo p, kde p bude prvočíslo v rovnici a g mod p = y, tak dostáváme 10

18 1 Přenos sítí Internet v reálném čase netriviální problém tzv. diskrétního logaritmu, výpočet je při použití velkých prvočísel p velmi složitý a současnými prostředky nezvládnutelný. Jakmile se pomocí ZRTP vyjednají klíče, tak je nastavena v SRTP kryptografická souvislost a komunikace se přepne do SRTP módu. Nakonec ZRTP změní některé kontrolní informace, aby si mohl ověřit, zda celá operace proběhla úspěšně. ZRTP řeší také ochranu proti útoku MITM, kde se případný útočník snaží řídit a kontrolovat spojení mezi komunikujícími stranami. Pro zamezení tohoto útoku ZRTP používá metody Short Authentication String (SAS) a Retained Secrets (RS). Zajímavým projektem implementace ZRTP je Zfone [zph],, který pracuje s běžnými SIP klienty. Zfone GUI slouží k ujištění volaných, že hovor je šifrován a nebyl detekován útok MiTM. U SRTP nelze MiTM vyloučit a ani detekovat. Philip Zimmermann udělal svým návrhem ZRTP velký krok jiným směrem, než by chtěla jakákoliv vláda, regulátor či úřední moc. Dosud bylo možné spojení odposlechnout a pokud bylo šifrováno SRTP, tak výměnu klíče odchytit a rozšifrovat, případně šifrovat spojení hop-by-hop. ZRTP zaručuje šifrování end-to-end a v případě MITM budou jeho uživatelé aspoň upozorněni, že spojení není bezpečné. ZRTP je významný krok v bezpečném přenosu médií a bude mít značný dopad zvláště v USA, kde platí od roku 2007 rozšíření CALEA (The Communications Assistance for Law Enforcement Act) i na IP telefonii. CALEA jsou pravidla právně vynucovaného nahrávání hovorů, které stanovily Ministerstvo spravedlnosti a FBI. V USA platí CALEA pro všechny poskytovatele telefonních služeb a od roku 2007 nevyjímaje poskytovatele hlasových služeb na VoIP. I tito poskytovatelé musí v USA poskytnout asistenci při nahrávání hovorů, to platí i např. pro Skype, pokud je alespoň jeden účastník spojení v USA. 1.3 Přenos DTMF a jiných tónů přes RTP V roce 2000 bylo uvolněno RFC 2833 (RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals), které specifikuje způsob přenášení tónové volby a obecně tónů pomocí RTP protokolu. Dnes je RFC 2833 nejpoužívanější způsob pro přenos DTMF (tónové volby). Pomocí RFC 2833 či RFC4733 lze obecně přenášet tóny, jde o způsob přenosu out-of-band, čili mimo hovorové pásmo, tóny jsou popsány určitou formou (u DTMF postačí čísla, lze i kmitočet) a příjemce je generuje z popisu. Druhý způsob přenosu in-band vyžaduje použití PCM a tóny v pásmu Hz jsou přenášeny v digitalizované podobě dané standardem ITU-T G.711. Třetím způsobem je přenos pomocí SIP metody INFO, který je používán zřídka. Pro přenos DTMF se dle výše uvedeného používají tři způsoby: in-band, v pásmu Hz pomocí PCM (G.711) out-band, pomocí RFC 2833 a RFC 4733 (modifikovaný RTP) out-band, pomocí SIP metody INFO RFC 4733 z roku 2006 plně nahrazuje RFC 2833 z roku 2000 a je s ním zpětně kompatibilní. Původní RFC definuje dva typy formátů: 11

19 1 Přenos sítí Internet v reálném čase první pro přenos DTMF čísel, kontrolních tónů a signálů trunku druhý pro obecné MF (Multi-Frequency) tóny v RTP Informace jsou přenášeny v RTP a níže uvedený příklad ukazuje přenos čísla 112, pole digit nese přenášená DTMF čísla (112), pole duration indikuje dobu vysílání tónu (při výchozím vzorkování 8 khz jsou doby trvání 200ms, 250ms a 50ms. Pole timestamp offset prezentuje časovou souslednost vysílaných tónů, první znak 1 znamená začátek časové osy 0 sec, z druhé hodnoty 4800/8 khz určíme, že další znak 1 začne být reprodukován 800 ms od začátku přehrávání prvního a poslední 11200/8Kz říká, že třetí znak 2 začne být reprodukován po 1,4 sec. od začátku generování prvního. Novější RFC 4733 na rozdíl od RFC 2833 přidává tři nové procedury: rozdělení dlouhých událostí do segmentů, oznamování více událostí v jednom paket, oznamování stavů V=2 P X CC M PT sequence number timestamp synchronization source (SSRC) identifier 0x5234a F block PT timestamp offset block length F block PT timestamp offset block length = F Block PT digit E R volume duration digit E R volume duration digit E R volume duration Obr RTP paket dle RFC 2833 po volbě čísla

20 1 Přenos sítí Internet v reálném čase 1.4 SCTP Stream Control Transmission Protocol Stream Control Transmission Protocol je transportní protokol RFC 4960 (2007), který byl navržen IETF skupinou Signaling Transport (SIGTRAN), která především řešila přenos SS7 přes IP. Jedním z požadavků bylo vytvoření několika nezávislých kanálů přepravovaných paralelně, což je největší odlišností SCTP od transportních protokolů jako je UDP a TCP. Po navázání spojení (asociaci), lze přenášet několik navzájem nezávislých toků (streams), v rámci každého toku je garantováno doručení ve správném pořadí a jednotlivé toky se navzájem neovlivňují, čili výpadek, opakování, zdržení v jednom nemá vliv na další a jejich komunikace pokračuje bez přerušení či pozdržení. SCTP je velmi zajímavým protokolem, ve VoIP se ovšem neprosadil. SCTP má jednodušší strukturu než UDP či TCP: Hlavička 12B obsahuje Source port, Destination Port, Verification tag a Checksum, následně zbytek datagramu tvoří Chunks (balíky porce dat), viz. obr Source Port Number Destination Port Number Verification Tag Checksum Chunk # Chunk #n Obr Formát SCTP paketu Výhody protokolu SCTP jsou následující: Multihoming - komunikující uzel má několik IP adres (i směs IPv4 a IPv6), dostupné adresy si komunikující strany vyměňují přes asociace, během komunikace je jedna z nich brána jako primární a na tu jsou odesílána data. V případě opakování se ale vybírá jiná a pokud je primární IP adresa opakovaně nedostupná, tak odesílatel začne používat jinou. Chunks - doručení probíhá v balících a eliminují se chybějící bloky obdobně jako u TCP. Výběr a sledování trasy - SCTP monitoruje všechny trasy, jedna je vybrána jako primární, v případě problémů se přechází na další alternativní. Ověřovací a potvrzovací mechanizmy - SCTP má vyšší rezistenci oproti DoS útokům, zajišťuje ověření opakujících se a chybějících balíků (chunks). 13

21 2 Standard ITU-T H Standard ITU-T H.323 Standard H.323 od ITU-T byl prvním doporučením, které popisovalo komunikaci v paketových sítích. Již rok před jeho uvolněním firma VocalTec spustila v roce 1995 produkt Internet Phone založený na vývojové verzi H.323 a stala se tak první firmou na světě, která začala nabízet IP telefonii. Jako doporučený HW byl uváděn 486SX PC - 25 MHZ, 8MB RAM a minimální požadovaná konektivita byla 14,4 kbit/s, podporovaný OS byl Windows 3.1 a připojení k Internetu bylo téměř výhradně přes modem. Od roku 1995 urazil Internet závratný kus cesty a H.323 se dostala z prenatální verze do své známé poslední verze 7 z roku Řada sítí je na H.323 dodnes provozována a ačkoliv je zřejmé, že v souboji s protokolem SIP, tento vyzrálý standard prohrál, nachází si nadále okruh uživatelů, kteří na něj nedají dopustit. Každopádně jeho vyhlídky nejsou růžové a dnes existuje pouze několik málo aktivních projektů, ve kterých probíhá nadále implementační vývoj produktů pro H.323. Obr. 2.1 Vývoj H.323 od uvedení až po aktuální verzi. 14

22 2 Standard ITU-T H Rodina protokolů H.32x Za vývojem rodiny protokolů H.32x stojí mezinárodní telekomunikační unie ITU-T. H.32x rodina řeší multimediální komunikace přes různé sítě, a to: H.320, N-ISDN, úzkopásmová ISDN, H.321, B-ISDN, širokopásmová ISDN (ATM), H.322, LAN s garancí QoS, H.323, paketově založené multimediální systémy, H.324, PSTN, veřejné analogové telefonní sítě s přepojov. okruhů, H.324M, rozšíření H.324 pro mobilní sítě 3GPP, H.325, nový standard vyvíjený v SG16 jako AMS (Advanced Multimedia System). 2.2 Verze H.323 Doporučení H.323.v1 z roku 1996 ve verzi 1 popisuje terminály, zařízení a služby pro multimediální komunikaci v lokálních počítačových sítích LAN bez garance kvality služby. Terminály H.323 mohou přenášet hlas, data a video, nebo kombinaci služeb včetně videotelefonie. Evoluce standardu H.323 přinesla další verze, v roce 1998 byla přijata verze 2, která řešila především vylepšení H.245, nástroj QoS pomocí rezervačního protokolu RSVP a autentizaci standardem H.235. Další verze 3 je z roku 1999 a přispěla především v oblasti doplňkových služeb, které řeší doporučení H.450. Nové služby přináší i verze 4 z roku 2000, v roce 2003 byla uvolněna verze 5, která řeší i podporu ENUM (univerzální identifikátory, vazba DNS a E.164), z roku 2006 je verze 6 s vylepšeným zálohováním (hot standby) a poslední verze 7 je z roku H.323v1 byla uvolněna v únoru 1996 jako Vizuální telefonní systém a zařízení pro LAN bez poskytování garantované kvality služeb. Jedna z prvních implementací se objevuje v MS Windows pod označením NetMeeting. Standard specifikuje komponenty, protokoly a procedury, které poskytují služby multimediální komunikace přes paketové sítě. První verze neřeší bezpečnost a má problém s vyjednáváním médií během sestavování spojení, později tato vlastnost dostává název Slow-Start. H.323v2 je z roku 1998 a název standardu se mění na Paketově založené multimediální komunikační systémy. Novými změnami jsou: Fast Connect, metoda navazování spojení (Fast Start pole v Q.931), Supplementary services H.450.x doplňkové služby předání hovoru (Call Transfer) a přesměrování volání (Call Diversion), H.235, bezpečnost, definice bezpečnostních profilů, šifrování a kryptotokenů, tunelování H.245, není nutné otevírat nové TCP spojení, celá H.245 se dá přenést v Q.931, overlap, metoda volby číslo po čísle, empty capability set, zjednodušení restartu H.245, alias adresy (URL, ), 15

23 2 Standard ITU-T H.323 RIP (znovunastavení expirace zasílání požadavků, pokud je nutný čas, např. V mezizónové komunikaci), TTL, doba vypršení registrace, alternate GK, záložní GK (cold standby) vykryje výpadky primárního GK, RAS QoS (EP mohou indikovat schopnost rezervace zdrojů). H.323v3 v následujícím roce 1999 reaguje především na zoufalé naléhání vývojářů na zmenšení obsáhlosti doporučení, neboť nejsou schopni plně implementovat celý H.323 stack, který je nesmírně rozsáhlý a robustní, přichází nová vylepšení: Simple Endpoint Terminal (SET) definovaný v Annex F, což je ořezaná H.323 pouze pro audio, objevuje se řada výrobců HW telefonů s H.323, H.450.x přidržení hovoru, parkování, převzetí volání, indikace čekající zprávy a čekajícího hovoru (call hold, call park, pickup, MWI, call waiting), H.341 MIB (Management Information Base) pro SNMP, je možné přes SNMP provádět základní správu H.323, vyčítat stavy a provádět dohled. H.323v4, opět po roce další verze (rok 2000) a ta přináší především: dekompozice brán (GW), návaznost a podpora ITU-T H.248 (MG a MGC), H.450.x identifikace jména, zpětné volání, poklepání do hovoru, vstup do hovoru (name identification, call completion, call offer, call intrusion), vylepšení řešení záložního GK, EP indikuje zda-li podporuje procedury pro záložní GK, sdílení zátěže přes záložní GK, správa pásma, transparentní tunelování non-h.323 protokolů jako QSIG a ISUP (SS7), Fast Connect a H.245 Parallel můžou probíhat současně. H.323v5 z roku 2003, která přinesla již v začátku kapitoly zmiňované vylepšení podpory URL a spolupráci s DNS, nejvýznamnějšími přínosy jsou: nově definovaný generický rámec implementace funkcí GEF (General Extensibility Framework), ITU-T H.460.1, přenositelnost čísel, mapování stavu kanálů, volání s prioritou, přenos duplicitních informačních prvků Q.931, rozšířená metoda FastConnect (změna parametrů H.245 bez uzavření logického kanálu), QoS dohled a report, Annex O popisuje použití URL a DNS, Annex P modemový přenos. H.323v6 z roku 2006 přináší: assigned GK, model přidruženého GK, který umožňuje režim hot standby (H.323 síť při výpadku GK okamžitě konverguje do provozuschopného stavu s přidruženým GK), vylepšení H.235 bezpečnost a SRTP, 16

24 2 Standard ITU-T H.323 zpoždění navazování spojení (ověření kvality trasy a až potom se sestaví spojení). H.323v7 z roku 2009 je poslední verzí H.323, novým přínosem je: single transmitter multicast, umožňuje otevřít multicast (výhodné např. pro Music on Hold), procedura Common Alerting Protocol (CAP) definuje nové zprávy pro použití v nouzové komunikaci, umožňuje rozesílat nouzové zprávy a varování Situace ve studijní skupině SG 16, která stojí za H.323 je nejasná, v roce 2007 byl oznámen vývoj nového protokolu H.235, který by měl nahradit SIP i H.323 a měl by být použit v sítích NGN. Jeho uvolnění bylo oznámeno na rok 2009, ale zprávy o postupu prací nelze najít a domnívám se, že organizace ITU-T se smířila s faktem, že pro NGN byl vybrán SIP a sdružení IETF bylo úspěšnější. Nelze říct, že v IETF byl vyvinut lepší protokol pro multimediální komunikaci, SIP uspěl díky své jednodušší koncepci, otevřenosti a vůli vývojářů se dohodnout. Vývoj aplikací na SIPu je sice levnější, ale má evidentně větší problémy v interoperabilitě, které se i více než deset let po jeho uvedení stále vyskytují a řeší. 2.3 Koncepce komunikace v H.323 Hovor je přenášen na RTP/RTCP protokolech. RTP přenáší konkrétní hovor a RTCP přenáší stavové a řídící informace. Signalizace, s výjimkou RAS, je přenášena spolehlivě přes TCP. Následující protokoly se zabývají signalizací: RAS -řídí registraci, přistup a stav, Q.931 -řídí nastavení volání a jeho ukončení, H.245 -určí využití kanálu a jeho kapacitu. Následující protokoly zajišťují v rámci H.323: H.235 -zabezpečení a identifikace, H.450 -doplňkové služby. V případě H.323 jsou signalizační informace k hovoru dány doporučením H.225.0, které využívá obou protokolů UDP i TCP, standardně řídící prvek sítě (Gatekeeper) naslouchá signalizaci H.225.0/RAS na portu UDP 1719 a případně i na 1718 (pro multicast , povoleno pro zprávy GRQ a LRQ), hovorová signalizace spojení H.225.0/Q.931 se přenáší na portu TCP Navíc je tu další část signalizace dle ITU-T H.245 pro vyjednávání parametrů audia/videa, která je postavena na TCP, od verze H.323v2 je pomocí metody Fast Connect schopná většinu informací přenést v H.225.0/Q

25 2 Standard ITU-T H Protokolový model H.323 H.323 protokoly jsou zobrazeny na obr Všechny H.323 terminály musí podporovat audio. Podpora pro video a data jsou volitelné. Ve třetí verzi H.323 byl specifikován terminál SET (Simple endpoint Terminal), který je zredukovanou verzi audio terminálu H.323. Pro řízení spojení jsou důležité tři protokoly: RAS (Registration, Admission and Satus) je komunikační protokol pro Gatekeeper (dále jen GK), pokud jakékoliv zařízení (terminál, brána, další gatekeeper) komunikuje s GK, tak používá RAS zprávy, H.225.0/Q.931 protokol v H.323 je nazýván jako signalizace volání (Call signaling) a obsahuje zprávy pro inicializaci i ukončení spojení (SETUP, ALERTING, CONNECT, RELEASE COMPLETE, atd..), koncepce byla převzata z ISDN, H.245 je označován jako protokol řízení médií (media control), obsahuje procedury pro vyjednání kodeků a portů pro RTP toky, pro každý směr zvlášť. Obr. 2.2 Protokolový model. Jak jsme si již vysvětlili v předchozí kapitole, nezbytnou součástí H.323 audio terminálu je vyrovnání zpoždění doručovaných RTP paketů, neboť jitter by znemožnil kontinuální dekódování. Maximální velikost zpoždění mezi odesílatelem a příjemcem je 150 ms, což je podmínka pro spojení s vysokou kvalitou, rozsahy zpoždění definuje ITU-T G Prvky H.323 a jejich vlastnosti Na obr. 2.3 jsou vyobrazeny komponenty v H.323. Prvky sítě H.323 tvoří koncové body EP (endpoints) a řídící prvky GK (gatekeepers). Množina EP registrovaná ke stejnému GK tvoří zónu, zónu můžeme chápat jako logickou oblast spravovanou GK, v jedné zóně nemůžeme provozovat více GK. Existuje způsob zálohování GK, kdy více GK se může postarat o EP, ovšem veškeré EP 18

26 2 Standard ITU-T H.323 jsou přihlášeny vždy v danou chvíli jen k jednomu GK. Zálohování je prováděno na principu přeregistrace EP a replikací směrovacích tabulek, které více GK sdílí mezi sebou. Kupříkladu budeme mít dva identické GK, jeden v Praze, druhý v Ostravě, EP geograficky náležející Moravě budou přihlášeny na GK v Ostravě, zbytek bude registrován na pražském. Oba GK si mezi sebou synchronizují směrovací informace (sousední GK a hlasové brány k výstupu z H.323 sítě). V případě vypnutí ostravského, pošle tento GK všem EP v jeho zóně požadavek na přeregistrování do Prahy. Pokud by došlo k nekorektnímu vypnutí a GK by už neměl možnost komunikovat EP, tak i na to je pamatováno, jelikož už při první registraci EP na GK, je předán list s alternativními GK seřazenými dle priorit, pro případ výpadku. Protože registrace EP na GK platí omezenou dobu, tak je zajištěno, že mrtvá zóna vždy nakonec zkonverguje do jiné, pokud má ovšem kam. Obr. 2.3 Komponenty H.323. H.323 infrastruktura je logicky rozdělena do zón. Zóna je množina zařízení řízených jedním GK. V H.323 rozeznáváme následující komponenty: Endpoint (koncový bod, zařízení), tím může být MCU, brána GW nebo terminál TE, Gatekeeper (řídící prvek sítě), MCU (Multipoint Control Unit) je multikonferenční jednotka, která má za úkol podporovat konference mezi 3 nebo více koncovými body, jde zpravidla o nejdražší část sítě, byť nepovinnou. Podstatnou výhodou MCU pro audio je, že umí transkódování, čili propojit terminály i s různými kodeky. MCU obsahuje řídící jednotku MC (controller) a procesorovou jednotku neboli audio mixér MP (media processor). GW (Gateway) je brána zajišťující propojení s telefonní sítí, obsahuje tedy zpravidla navíc ISDN rozhraní (případně jiné) a DSP procesory pro podporu více kodeků, dle výkonu, kapacity, typu rozhraní a podporovaných kodeků se odvíjí i cena. TE (Terminal) je typické koncové zařízení, buď je realizováno na bázi SW pro Windows/Linux (softphone) anebo jako HW terminál (IP telefon), trh je poměrně dobře zásoben stovkami typů IP 19

27 2 Standard ITU-T H.323 telefonů, cena pochopitelně záleží na výkonu zařízení (implementované funkce, podpora kodeků, NAT, 802.1Q, diffserv, napájení 803.af, miniswitch uvnitř, apod..). Gatekeeper je řídicím prvkem H.323 koncových bodů (terminal, gateway, MCU). Dle standardu H.323 musí zajišťovat následující: podpora signalizace RAS (Registration/Administration/Status). Pomocí signalizace RAS se realizuje řízení přístupů k prostředkům sítě, řízení přístupu (Admission Control), zajišťuje autorizovaný přístup pomocí zpráv ARQ/ACF/ARJ (Admission Request/Confirm/Reject) definovaných v signalizaci RAS (Registration, Admission and Status Signaling), překlad adres (Address Translation) mezi E.164 číslem a IP síťovou adresou. Překlad na IP adresy koncových bodů z přijatých adres typu alias (jmeno@domena) nebo E.164 (standardní tel.č.), řízení přidělování kapacity pásma (Bandwidth Control). Řízení pásma dle požadavků z koncových bodů pomocí zpráv BRQ/BCF/BRJ signalizace RAS, řízení spojení (Call Control), zpracování zpráv nebo jejich směrování, řízení zón (Zone Management), zajišťuje řídicí funkce pro všechny registrované koncové body H.323 zóny. Koncové terminály a VoGW jsou rozděleny do zón, které představují distribuovanou strukturu GK. Dále GK obvykle podporují autorizaci volání (Call authorization). Autorizace jednotlivých volání se provádí dle identifikačních kódů a umožňuje zavést hovorový kredit. GK může zajišťovat Least Cost routing, optimalizaci směrování cestou nejnižších nákladů a možnosti nastavení záložního GK (standby GK) Signalizace RAS RAS signalizace zajišťuje řídicí funkce spojení v H.323 sítích. Kanál RAS je sestavován mezi koncovými body a GK. Nalezení GK probíhá z H.323 koncových bodů sítě automaticky nebo manuálně. Manuální způsob spočívá v pevném nastavení IP adresy, automatické vyhledání vyžaduje mechanizmus známý jako auto discovery. UDP discovery port je 1718 a GK UDP registrační port je Pomocí zpráv multicast je vyhledán GK na IP adrese RAS zpráv jsou následující: GRQ/GCF/GRJ Gatekeeper Request/Confirm/Reject, RRQ/RCF/RRJ Registration Request/Confirm/Reject, URQ/UCF/URJ Unregister Request/Confirm/Reject, ARQ/ACF/ARJ Admission Request/Confirm/Reject, IRQ/IRR Information Request/Request Response, Status, LRQ/LCF/LRJ Location Request/Confirm/Reject, BRQ/BCF/BRJ Bandwidth Request/Confirm/Reject, DRQ/DCF/DRJ Disengage Request/Confirm/Reject. Následující obr. 2.4 znázorňuje mechanizmus navázání spojení přes RAS signalizaci, hlasové brány VoGW-A a VoGW-B se při startu registrují ke GK, kde předají svou IP adresu, H.323 Id (identifikaci typu alias) a prefix Id (identifikaci typu E.164). GK zapíše tyto informace do směrovací tabulky. Registrace má obvykle omezenou platnost a je vyžadováno její obnovování, pokud EP tak nečiní, tak GK si opětovnou registraci vyžádá. Pokud je z VoGW-A vysláno na GK číslo, které 20

28 2 Standard ITU-T H.323 obsahuje řetězec začínající prefixem Id VoGW-B, potom GK ve zprávě ACF (Admission Confirm) vrací příslušnou IP adresu a zprávy signalizace Q.931 jsou přenášeny přes H.225 protokolem TCP. H.245 otevírá logický kanál pro řízení spojení a vlastní hovor je již přenášen protokolem RTP. Během spojení GK monitoruje zprávou Status Enquiry, zda je spojení ještě aktivní. Při ukončení spojení musí proběhnout ukončení logického spojení (H.245) a následně se mezi GK a koncovým bodem vyměňují zprávy DRQ/DCF (Disengage Request/Confirm). Obr. 2.4 Mechanizmus navázání spojení pomocí RAS signalizace. Podstatnou výhodou signalizace RAS je dynamické přihlášení koncového bodu na GK. Jednotlivé terminály a VoGW se autorizují na GK při zapnutí zařízení a není zapotřebí udržovat statické tabulky. Přidání dalšího zařízení do zóny H.323 spočívá ve správném nakonfigurování koncového bodu (nastavení autorizace na příslušném GK) a řídicí prvek H.323 zóny aktualizuje údaje o spravovaných koncových zařízeních. Pro automatické nalezení koncového bodu H.323 zóny jsou v RAS definovány tři zprávy GRQ/GCF/GRJ, což je Gatekeeper Request/Confirm/Reject. Při registraci jsou v RAS definovány zprávy: RRQ/RCF/RRJ - Registration Request/Confirm/Reject, viz. obr. 2.5 URQ/UCF/URJ -Unregister Request/Confirm/Reject. Registrace proběhne po vyhledání před uskutečněním volání. Po úspěšné registraci získá GK informace o H.323 koncovém bodu IP sítě (IP adresa, alias) a koncový bod může využívat zónu GK, obr Ze zachycené zprávy RRQ je možné vyčíst, že EP je dosažitelný pod IP na portu 1164, kam mu může být zaslána zpráva SETUP. Terminál si registruje h323 jméno a číslo , registraci navrhuje na 120 sec. Nakonec terminál připojí autentizační řetězec v 21

29 2 Standard ITU-T H.323 CryptoToken jako hash získaný pomocí MD5 a prozradí i některé vstupní parametry jednosměrné hashovací funkce, ačkoliv ten nejdůležitější (heslo) tají, uživatelské jméno a heslo je uloženo v útrobách terminálu. Obr. 2.5 Průběh registrace na GK. Gatekeeper srovná zaslaný autentizační řetězec s vlastním výsledkem výpočtu MD5 funkce (pochopitelně musí znát všechny parametry do funkce vstupující) a pokud sedí, tak uživatel je úspěšně autentizován a registraci potvrdí v RCF, případně upraví dobu registrace. Zachycená zpráva RRQ: H RAS RasMessage: registrationrequest (3) callsignaladdress: 1 item Item 0 Item: ipaddress (0) ipaddress ip: ( ) port: 1164 terminalalias: 2 items Item 0 Item: h323-id (1) h323-id: Item 1 Item: dialeddigits (0) dialeddigits: timetolive: 120 cryptotokens: 1 items Item 0 Item: cryptoeppwdhash (0) cryptoeppwdhash 22

30 2 Standard ITU-T H.323 alias: h323-id (1) h323-id: timestamp: Aug 19, :13: token algorithmoid: (md5) params hash: F2CAF26F70AA812383C4F6B12 ARQ/ACF/ARJ znamená Admission Request/Confirm/Reject. Zprávou ARQ požaduje koncový bod inicializaci spojení, pokud je autorizován, dostává ve zprávě ACF koncovou IP adresu na jejímž základě může být inicializováno Q.931 spojení mezi koncovými H.323 body IP sítě, obr Inicializace signalizace volání Q.931 (Call Signaling) začíná odesláním zprávvy SETUP a výměnou další zpráv Q.931, které nakonec vedou k sestavení spojení. Pokud je volaný IP Phone B registrován na GK, tak na přijatou žádost o sestavení spojení SETUP odešle ARQ na GK a pokud dostane potvrzení ACF (jinými slovy, že může volání akceptovat), tak odpovídá zprávou Call Proceeding a následují další Q.931 zprávy na jejichž konci je sestavení hovoru. Pokud IP phone B není registrován na GK, tak na SETUP odpovídá bezprostředně a RAS signalizace pochopitelně vůbec u volaného neprobíhá. Opět se podíváme do zprávy ARQ zaslanou na GK a vidíme, že terminál se dotazuje na a připojuje CryptoToken, pomocí kterého autorizuje svůj požadavek na sdělení informace k číslu Obr. 2.6 Průběh inicializace spojení. H RAS RasMessage: admissionrequest (9) admissionrequest endpointidentifier: 7254_gk1ext destinationinfo: 1 item Item 0 23

31 2 Standard ITU-T H.323 Item: dialeddigits (0) dialeddigits: srcinfo: 2 items Item 0 Item: h323-id (1) h323-id: Item 1 Item: dialeddigits (0) dialeddigits: callreferencevalue: 4096 conferenceid: 56b08f95-7cbf d4-e6627b290c8b activemc: False answercall: False callidentifier guid: a8f00c6c-7324-ec49-a10e-5b42a cryptotokens: 1 items Item 0 Item: cryptoeppwdhash (0) cryptoeppwdhash alias: h323-id (1) h323-id: timestamp: Aug 19, :13: token algorithmoid: (md5) params hash: 1E854B FED75E BFB98 Gatekeeper vyřídil kladně požadavek terminálu a odpověděl zprávou Admission Confirm, ve které nařídil použití modelu gatekeeperrouted (model GRC) a sdělil informace pro signalizaci volání (IP adresu a port, kam má být terminálem zaslán SETUP jako inicializace volání). Samozřejmě že Gatekeeper uvedl pro zaslání SETUP sám sebe, neboť vybral model GRC a není naivní, aby prozradil IP adresu a port protější strany, bude tedy přeposílat zprávy Q.931 jako prostředník a tím má možnost kontrolovat jejich obsah. Gatekeeper rovněž sděluje terminálu v poli irrfrequency, že chce dostávat každých 120 sekund hlášení o aktuálním stavu spojení. H RAS RasMessage: admissionconfirm (10) admissionconfirm callmodel: gatekeeperrouted (1) gatekeeperrouted: NULL destcallsignaladdress: ipaddress (0) ipaddress ip: ( ) port: 1720 irrfrequency: 120 Monitorování koncových bodů je prováděno průběžně během spojení zprávami IRQ/IRR, což je Information Request/Response. Status Enquiry je zpráva, kterou GK používá k ověření, zda je volání ještě stále aktivní. Řízení pásma předchází sekvence řízení přístupu ARQ/ACF, nicméně šířka přiděleného pásma může být změněna i během hovoru. K řízení pásma jsou v RAS signalizaci 24

32 2 Standard ITU-T H.323 definovány zprávy BRQ/BCF/BRJ, což je Bandwidth Request/Confirm/Reject. Pro ukončení hovoru se používají zprávy DRQ/DCF/DRJ, což znamená Disengage Request/Confirm/Reject. Pomocí uvedených zpráv může koncový bod spojení nebo GK vyslat požadavek k ukončení či potvrzení ukončení spojení, případně odmítnout požadavek na rozpojení. Další procedura popsaná v RAS signalizaci je určení umístění koncového bodu sítě, viz. obr. 2.7, jestliže je volání terminováno na koncový bod, který není přihlášen v zóně inicializující spojení. LRQ/LCF/LRJ znamená Location Request/Confirm/Reject. Zprávou LRQ se posílá požadavek na E.164 adresu např. v případě, že koncový bod je mimo vlastní zónu GK. Řízení přístupů v H.323 síti je zajištěno v RAS signalizaci pomocí zpráv ARQ/ACF/ARJ, pokud se podaří vyhledat umístění volaného, tak je zasláno potvrzení ACF, proto potvrzení ACF logicky následuje až po přijetí LCF. Obr. 2.7 Průběh inicializace spojení mezi zónama GK Signalizace Q.931 Signalizace RAS zajišťuje vždy komunikace čehokoliv s Gatekeeperem, viz. obr. 2.8, nevypovídá o tom, zda bylo spojení navázáno, jak dlouho trvalo vyzvánění, z RAS nelze sestavit záznam o spojení CDR (Call Detail Record). Standardně se pro RAS používá UDP s cílovým portem 1719 pro unicast, v případě multicastu pak 1718 (GRQ), pomocí GRQ se dá v síti vyhledat GK. Další signalizací je H Call Signalling, čímž se myslí signalizace volání Q.931. Ta je znázorněna na dalším obr Obsahem této signalizace jsou zprávy, které slouží k sestavení a ukončení spojení mezi koncovými terminály. Standardně se používá TCP s cílovým portem Aby tato signalizace mohla proběhnout, tak musí být známa cílová IP adresa a Q.931 port, což se zjistí ze zprávy RAS ACF. Přes Q.931 se 25

33 2 Standard ITU-T H.323 může v jednom TCP spojení přenášet i signalizace pro média (H.245 tunneling) anebo alespoň část (H.245 Fast Connect). Obr. 2.8 Signalizace RAS. V Q.931 se jedná o výměnu následujících zpráv: Setup Call Proceeding Alerting Information Release Complete Facility Progress Status Setup Acknowledge Notify Connect Při ukončení spojení se posílá pouze Release Complete na rozdíl od ISDN, kde se posílá Disconnect, Release a Release Complete, u H.323 je Q.931 přenášena spolehlivým transportním protokolem TCP, a proto se upustilo od potvrzování přijetí odpovědi. Q.931 nemusí být přenášena přímo mezi EP, H.323 signalizace umožňuje v zásadě dva režimy: DRC, Direct Routed Call signalling, kdy veškerá komunikace kromě RAS jde přímo mezi koncovými účastníky spojení (IP telefony, bránami), GRC, Gatekeeper Routed Call signalling, která může být provozována ve více režimech (přes GK prochází kromě RAS i Q.931 a případně i H.245). 26

34 2 Standard ITU-T H.323 Obr. 2.9 Signalizace H.225.0/Q Signalizace H.245 Pro média je určena signalizace H.245, přenáší se v oddělených zprávách anebo v rámci Q.931 pomocí metody Fast Connect (rychlé navazování spojení). H.245 obsahuje následující důležité procedury, viz. obr. 2.10: TCS, Terminal Capability Set, nastavení vlastností terminálů, každá strana poskytne druhé list preferovaných kodeků s jejich vlastnostmi, MSD, Master Slave Determination, tato procedura rozhodne, kdo je Master a čí zprávy jsou tedy směrodatné v případě konfliktu, OLC, Open Logical Channel, otevření logického kanálu, vybere se kodek i port a bude otevřeno spojení pro RTP zvlášť pro každý směr. Výměna zpráv v H.245 probíhá pomocí žádosti a potvrzení (Request, Acknowledge). Při použití Fast Connect se přenášejí prvky Fast Start uvnitř zpráv SETUP, ALERTING, CONNECT a ty obsahují parametry vyjednávání spojení, při přihlášení volaného je proto H.245 vždy sestavena a RTP může přenášet obsah hovoru. Problém u H.323v1 byl ten, že H.245 probíhala odděleně od Q.931 až po ukončení výměny Q.931, což nebylo šťastné a mohlo docházet k prodlení otevření kanálu anebo jednostranné slyšitelnosti. Kromě Fast Connect může popsaný problém H.323v1 odstranit i Parallel H.245, která umožní spustit procedury H.245 paralelně s Q.931 a nakonec tunelovaná H.245, u které se nemusí sestavovat nové TCP, pro odeslání H.245 PDU se může využít zpráva FACILITY. 27

35 2 Standard ITU-T H.323 Obr Signalizace H.245. Pokud se sestavuje nové TCP spojení pro H.323, tak IP adresa a port H.245 je přenesen ve zprávě Connect, jak je uvedeno následovně: Q.931 CONNECT H245_IP_Address, H245_Port = Called H245 Port, q931.call_ref = 50:A4, h225.t35countrycode = 0 Otevřením logického kanálu H.245 je umožněno zasílání RTP paketů, pro ukončení H.245 se jednak uzavře logický kanál a potom celá relace: Close Logical Channel, CLC Request, Acknowledge, End Session Command, ESC Request, Acknowledge. Pokud během relace dojde ke změně parametrů médií, tak stačí zavřít kanál a otevřít jej znovu s novými parametry, u H.323v4 je procedura zjednodušena pomocí mechanizmu ExtendedFast Connect, ten umožňuje modifikaci médií zasláním FastStart prvku s jejich popisem v Q.931. Odesílání RTP paketů ihned po sestavení logického kanálu se označuje jako Early Media Modely spojení DRC a GRC Na následujících obrázcích jsou znázorněny modely spojení, na prvním obrázku je model DRC, obrázky jsou převzaty přímo z doporučení H.323. DRC model umožňuje přes GK pouze komunikaci RAS, vše ostatní probíhá přímo mezi koncovými body spojení. O použitém modelu rozhoduje GK, ve zprávě ACF je určeno, který model se použije. Koncové zařízení sice může navrhnout typ modelu, ale GK definitivně rozhodne. 28

36 2 Standard ITU-T H.323 Obr Model DRC. Na druhém obrázku 2.12 je model GRC, u modelu GRC jde H vždy přes GK, ale v tomto modelu můžeme ovlivnit i cestu H.245 a RTP. Obr Model GRC. 29

37 2 Standard ITU-T H.323 Signalizace v módu GRC může být tedy provozována následovně: GRC bez H.245 (H.245 i RTP probíhají přímo mezi EP), GRC včetně H.245 (H.245 je směrována přes GK, ale RTP přímo mezi EP), a Proxy režim, kdy vše je směrováno přes GK včetně RTP, podmínkou je, že GK obsahuje RTP Proxy, tento režim je výborný pro NAT. Nejčastěji se používá první režim a H.245 vyjednávající parametry spojení se nechává proběhnout mezi EP. Poslední režim se používá pro podporu zařízení za NATem, pokud GK zjistí, že adresa EP je neveřejná, tak pro konkrétní spojení vyžádá Proxy režim. Na uvedeném obrázku 2.12 je režim GRC bez H Vybrané scénáře toku zpráv H.323 V této kapitole si ukážeme, jak náročné je sestavit spojení klasickou metodou Slow Start popsanou H.323v1, viz. obr Obr Scénář se Slow Start. Další scénář využívá běžně používaných prvků Fast Start (metoda Fast Connect) a nakonec s tunelováním H.245. Na obr je první navázání spojení pomocí Slow Start. Ve druhém scénáři na obr je Fast Connect, OLC procedura H.245 je přenášena přes Q.931 a už ve zprávě Connect proběhlo otevření logického kanálu a pokud by byly použity Early Media, tak RTP výměna mohla začít, z příkladu je čitelné, že RTP tok se rozběhl, až po ukončení všech procedur H

38 2 Standard ITU-T H.323 Obr Scénář s Fast Connect V posledním scénáři na obr je tunelovaná H.245 přes Q.931, kde je zřetelně vidět, jak je využito zpráv Q.931 a pokud potřebuje H.245 nějakou další Q.931 zprávu, tak se použije FACILITY. Otevření logického kanálu proběhlo už před zprávou Connect, tzn. před přihlášením volaného a RTP pakety jsou přenášeny oběma směry, což znamená, že se jedná o Early Media (urychlená média). Obr Scénář s tunelovanou H.245 a Early Media. 31

39 2 Standard ITU-T H Konfigurace ISDN modulů v Cisco směrovačích Pro registraci na GK je nutné v Ciscu konfigurovat položky na síťovém rozhraní pod označením h323-gateway. Během registrace se zasílá GRQ a RRQ se jménem GK jako id (identifikátoru GK) a brána je registrována s prefixy seřazenými v tech-prefix a s jeho h323-id. # interface FastEthernet0/0 # ip address # h323-gateway voip interface # h323-gateway voip id OpenH323GK ipaddr priority 100 # h323-gateway voip h323-id gw1vsb # h323-gateway voip tech-prefix 0 V případě použití GNU GK je název GNU GK zadán v sekci Main v souboru /etc/gatekeeper.ini, kde musí být stejné id GK jako v Cisco GW. [Gatekeeper::Main] Name=OpenH323GK Pro registraci na SIP serveru se nekonfigurují položky pod síťovým rozhraním ale globálně. # sip-ua # authentication username jmeno heslo # sip-server dns:asterisk.vsb.cz # anebo sip-server ipv4: Pomocí IOS příkazů gateway a no gateway můžeme provést zaregistrování či odregistrování brány a pomocí show gateway zjistit aktuální stav registrace. # show gateway H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1 H.323 service is up Gateway gw1vsb is registered to Gatekeeper OpenH323GK A konečně se dostáváme ke konfigurací ISDN rozhraní na Cisco GW. Nejdříve několik globálních nastavení, které je vhodné minimálně zkontrolovat. Co se týče nastavení v sekci voice, tak je to ověření, že je zapnutý příjem i vysílání RTP a v podsekci voip, že je zakázán H.245 caps režim, bez něj může být problém s dokončením vyjednání H.245, jelikož Cisco nechává nepotvrzenou H.245 pro detekci DTMF, tónů a faxu, s touto vlastností mají produkty třetích stran většinou potíže. # voice rtp send-recv # voice service voip # h323 # h245 caps mode restricted 32

40 2 Standard ITU-T H.323 Dále je nutné na voice portu nastavit české kontrolní tóny, evropskou kompresní křivku pro PCM A-law a jako výchozí bearer-capability doporučuji 3100Hz. # voice-port 0/0 # compand-type a-law # cptone CZ # bearer-cap 3100Hz Příklad nastavení BRI Následující nastavení je pro ISDN BRI na Cisco GW, která je konfigurovaná jako síťová strana, tzn. k tomu portu můžu připojit koncové zařízení či PBX a nakonfigurovaný port se chová jako poskytovatel (obdobně jako ISDN BRI veřejného operátora). # interface BRI0/0 /*identifikace rozhraní # no ip address # isdn switch-type basic-net3 /* basic-net3 znamená BRI s DSS1 /* basic-qsig znamená BRI s QSIG # isdn overlap-receiving /* schopnost přijímat číslo po čísle # isdn protocol-emulate network /* L3 v režimu strany poskytovatele # isdn layer1-emulate network /* L1/L2 v režimu poskytovatele # isdn incoming-voice modem /* s příchozím volání je nakládáno jako s modemem # isdn send-alerting /* bude posílat ALERTING # isdn sending-complete /* pošle volbu v bloku # isdn static-tei 0 /* TEI=0 pro konfiguraci Point to Point # isdn skipsend-idverify /* nebude verifikovat TEI Pro stranu uživatele se změní několik položek. K tomuto rozhraní můžeme připojit ISDN BRI z veřejné sítě. # isdn protocol-emulate user /* L3 je provozován v režimu strany uživatele # isdn layer1-emulate user # no skipsend-idverify /* zašle TEI verifikaci v režimu PMP Příklad nastavení PRI Následující nastavení je pro ISDN PRI na Cisco GW, nejdříve nakonfigurujeme E1 kontroler. # controller E1 1/0 # clock source line primary /* L1 synchronizace hodin z PCM traktu anebo # clock source internal /* interní zdroj časování # pri-group timeslots

41 2 Standard ITU-T H.323 Následně můžeme přistoupit ke konfiguraci signalizační části ISDN PRI, která je podobná jako v přechozím případě a začneme nejdříve stranou sítě, čili konfigurujeme Cisco GW v pozici poskytovatele. # interface Serial1/0:15 # no ip address # isdn switch-type primary-net5 /* primary-net5 znamená PRI s DSS1 # isdn overlap-receiving # isdn not-end-to-end 64 /* přepsání rychlosti, kterou avizuje síť # isdn protocol-emulate network # isdn incoming-voice modem # isdn send-alerting # isdn sending-complete A pro stranu uživatele postačí změnit jednu položku. # isdn protocol-emulate user /* interface operates in user side mode Časovače na ISDN není doporučeno měnit z jejich výchozích hodnot, ale někdy to může prospět a proto si uvedeme seznam vybraných časovačů. # isdn overlap-receiving T302 /* T302 timer (v ms) vypršení volby # isdn overlap-receiving terminating-char # /* znak konce volby # isdn t306 /* časovač rozpadu spojení po odeslání zprávy disconnect # isdn timer t309 /* uvolnění B-kanálu a Call Reference po přerušení či restartu # isdn t310 /* časovač rozpadu pokusu volání po přijetí Call Proceeding Pravidla volby čísel a směrů Abychom s Cisco GW mohli uskutečnit spojení, tak je nutné definovat příchozí volbu z VoIP sítě do PSTN označovanou jako inbound peers (POTS) a odchozí volbu z PSTN do VoIP označovanou jako outbound peers (VoIP). Tato konfigurace se provádí v sekci dial-peer voice. Následující nastavení je pro ISDN PRI na Cisco GW, nejdříve nakonfigurujeme E1 kontroler. Předpokládejme, že směrovač v tomto příkladu přijímá volání s volbou 59699XXXX z VoIP sítě, kde XXXX je pobočka a je prefix. Níže uvedené pravidlo akceptuje řetězec začínající 59699, za kterým následují čtyři čísla, tyto čísla jsou odeslány do připojené PBX přes port 0/0, což zajišťuje příznak provolení direct-inward-dial. # dial-peer voice 1 pots # destination-pattern # direct-inward-dial # port 0/0 34

42 2 Standard ITU-T H.323 T je speciální znak časovače ukončení volby, jehož použití potlačuje čekání na přesný počet čísel, namísto toho se spustí časovač T302 mezičíslicové pauzy (interdigit timer), po jeho uplynutí je příchozí číslo považováno za úplné. # destination-pattern 59699T Pravidla odchozí volby směrem jsou chápána směrem do VoIP sítě a proto je dial-peer označen jako voip. Předpokládejme, že potřebujeme nasměrovat na GK všechna čísla začínající , z PBX tedy přichází do Cisco GW devítimístné číslo, což vyjadřuje , na posledních třech číslech nezáleží, GW spáruje takovýto řetězec s pravidlem odchozí volby číslo 20 a směruje volání na cíl zadaný v session target. Na cíl je posláno celé přijaté číslo # dial-peer voice 20 voip # destination-pattern # codec g711alaw /* použij tento kodek # session target ras /* v případě GK nebo # session target ipv4: /* cíl je specifikován IP adresou (jiná GW) Pokud je uvedeno session target ras, tak je použita RAS signalizace pro zjištění cílové IP adresy a portu pro Q.931, což znamená, že RAS je směrován na GK. V případě session target ipv4 není použita RAS signalizace a odchází se přímo zprávami signalizace Q.931, což značí odeslání zprávy SETUP a protějším zařízením nemůže být GK nýbrž EP (GW anebo TE). V praxi potřebujeme mnohdy s čísly manipulovat, různě je překládat, přepisovat, odříznout či přidat určitou část a k tomu používáme pravidla, která jsou označována jako pravidla překladu čísel (The Digit Translation Rules). Tato pravidla mohou být užita jak v příchozím, tak i v odchozím směru. Dosáhneme tedy přepisu CPN (volaného čísla) anebo CLI (čísla volajícího). Přijaté číslo 59699XXXX bude přeloženo na XXXX a čísla začínající číslicí 0 na 420, jakýkoliv typ čísla TON (Type of Number) bude přeložen na typ UNKNOWN. # translation-rule 1 # Rule 0 ^ ANY unknown # Rule 1 ^0 420 ANY unknown Popsaná pravidla jsme uložili do pravidel překladu čísel č. 1 a teď je použijeme po směr odchozí volby číslo 20. # dial-peer voice 20 voip # translate-outgoing called 1 /* přepsání CPN nebo # translate-outgoing calling 1 /* přepsání CLI Pokud potřebujeme některé z pravidel použít rutinně, tak abychom je nemuseli zapisovat u každého směru, tak se nastaví jako globální a v tom případě se zapisují na voice-port, pokud potřebujeme použít jiné, tak je nastavíme přímo na konkrétní dial-peer. 35

43 2 Standard ITU-T H.323 # voice-port 1/0:15 /* the rule placed as a global into voice-port # translate calling 2 # translate called Třídy kodeků Skvělým pomocníkem je nastavení třídy kodeků (voice class codec). Tím dosáhneme nastavení preferencí a přiřadíme třídu pro konkrétní dial-peer. Nastavíme tím seznam položek kodeků, které budou ve spojení ze strany Cisco GW nabízeny. # voice class codec 99 # codec preference 1 g711alaw # codec preference 2 g711ulaw # codec preference 3 g729r8 Výše uvedeným nastavením byla sestavena třída kodeků č.99 obsahující tři kodeky a tuto třídu teď přiřadíme na dial-peer voice 20 voip, tím docílíme, že se bude vytvořený list preferencí kodeků nabízet v odchozím směru č. 20. # dial-peer voice 20 voip # voice-class codec 99 Zcela netypicky se nastavuje kodek pro příchod, a to rovněž v dial-peer voice voip, níže uvedený příklad bude použit pro všechny příchozí volání s volbou delší než dvě číslice. Doporučuji používat uvedené pravidlo, neboť výchozím kodekem je u Cisca G.729. # dial-peer voice 999 voip # voice-class codec 99 # incoming called-number..t Chybějící kontrolní vyzváněcí tón Cisco brány jsou velmi spolehlivá zařízení. Pokud se vůbec objeví nějaký problém, tak obvykle při volání přes Cisco GW volající neslyší kontrolní vyzváněcí tón, ačkoliv příchozí volání úspěšně vyzvání u volaného. Proto si rozebereme řešení této situace. Důvodem je většinou situace, kdy strana volaná posílá svůj kontrolní tón v hovorovém kanále (in-band) a volající strana nenaslouchá, neboť nebyl propojen B-kanál. K nepropojení může dojít z více důvodů, informaci o propojení nese informační prvek Progress Indicator (PI) a jeho nastavením dokážeme vynutit propojení B-kanálu již během vyzvánění. Nemusí se jednat pouze o přenos kontrolních tónů, ale i různých ohlášení. PI můžeme najít ve zprávách ALERTING, CONNECT, PROGRESS nebo DISCONNECT. Kde hodnota PI=1 nebo PI=8 vyjadřuje přítomnost informace in-band. Můžeme přinutit otevření B-kanálu i přes SETUP hodnotou PI=3, pokud takovéto PI v SETUPu dorazí na GW, tak to znamená, že je očekávána informace in-band. 36

44 2 Standard ITU-T H.323 Pro Cisco jsou pomocí IOS řešení následující. Prvním krokem by mělo být nastavení globálním parametrem. # voice call send-alert Pokud nastavení nezabralo, tak si vynutíme otevření B-kanálu přepisem PI, předpokladem je, že kontrolní vyzváněcí tón (kvt) je skutečně v B-kanálu posílán. Tam, kde kvt v B-kanále není zasíláno, tak naopak může způsobit nefunkčnost, protože přepíše PI a zabrání vygenerování lokálního kvt, takže příkaz se používá selektivně a taky je možné zkusit nastavit PI pro konkrétní zprávu. Tady platí, že měníme co nejméně, přepisy PI jsou dost tvrdým zásahem do signalizace. # voice dial-peer 1 pots # progress_ind alert enable 8 # progress_ind progress enable 8 # progress_ind connect enable 8 # progress_ind setup enable 3 Jestliže ani přechozí nastavení nepomohlo, tak přichází zaručený recept v podobě vynucení lokálního generování kvt. # voice dial-peer 20 voip # progress_ind setup enable 3 nebo # tone ringback alert-no-pi 2.6 Diagnostika na hlasové bráně Pokud se chceme přesvědčit zda Cisco GW je připravena a ISDN je v dobré kondici, tak použijeme příkaz show isdn status a dostaneme odezvu, kde zkontrolujeme, zda je aktivní vrstva L3. Pokud není, tak hledáme problém na L2, praxe je taková, že většina chyb je na L1, takže pokud nevidíme aktivní první vrstvu, tak jdeme prověřit vedení. Vyplatí se mít po ruce LED diodu pro testování fyzické vrstvy PRI, tímto nejlevnějším testerem lze rychle zjistit, na kterých párech jsou vysílače obou propojovaných stran a hlavně, zda vysílají. ISDN Serial1/0:15 interface ******* Network side configuration ******* dsl 0, interface ISDN Switchtype = primary-net5 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0xFFFF7FFF Number of L2 Discards = 0, L2 Session ID = 1 Total Allocated ISDN CCBs = 0 37

45 2 Standard ITU-T H.323 Následně byl zachycen průběh signalizace na ISDN rozhraní mezi Cisco GW a PBX, a to na L3 příkazem debug isdn q931. Tučně jsou zvýrazněny zajímavé partie signalizace. Ze zprávy SETUP vyčteme, že je číslo voleno v bloku a kompletní, jedná se o nosnou službu 3,1 khz Audio a je použitý první kanál z ISDN PRI, samozřejmě v SETUP najdeme číslo volajícího a volaného. C2651-VoGW-OV# Aug 19 19:06:23.024: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x5D9D Sending Complete Bearer Capability i = 0x9090A3 Standard = CCITT Transfer Capability = 3.1 khz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98381 Exclusive, Channel 1 Progress Ind i = 0x Origination address is non-isdn Display i = 'Voznak Mobil' Calling Party Number i = 0x0180, ' ' Plan:ISDN, Type:Unknown Called Party Number i = 0x81, '1699' Plan:ISDN, Type:Unknown Aug 19 19:06:23.128: ISDN Se1/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0xDD9D Channel ID i = 0xA98381 Exclusive, Channel 1 Aug 19 19:06:23.476: ISDN Se1/0:15 Q931: RX <- ALERTING pd = 8 callref = 0xDD9D Progress Ind i = 0x In-band info or appropriate now available Aug 19 19:06:43.544: ISDN Se1/0:15 Q931: RX <- CONNECT pd = 8 callref = 0xDD9D Aug 19 19:06:43.552: ISDN Se1/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x5D9D Další zprávou Call Proceeding byla strana inicializující volání informována o zpracování požadavku na sestavení spojení. Ve zprávě ALERTING se volající strana dozvídá jednak, že u volaného začal vyzvánět telefon a jednak dostává v PI informaci o zaslání in-band informace, což je jistě kontrolní vyzváněcí tón a je nutné ho naslouchat na B-kanálu. Nakonec při přihlášení volaného je přijat CONNECT, který je potvrzen CONNECT_ACK. Dále byl zachycen rozpad spojení, jelikož požadavek DISCONNECT byl vyslán (TX), tak spojení ukončila strana volající standardní cestou a rozpad je dovršen přijetím RELEASE a potvrzením RELEASE_COMPLETE. Aug 19 19:06:58.844: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x5D9D Cause i = 0x Normal call clearing Aug 19 19:06:58.992: ISDN Se1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0xDD9D Aug 19 19:06:59.000: ISDN Se1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x5D9D C2651-VoGW-OV# 38

46 2 Standard ITU-T H.323 Poslední příklad ukazuje odchozí spojení z PBX přes CiscoGW, což je indikováno jako RX SETUP, čili zpráva SETUP byla přijata na E1 rozhraní (z PBX) a obsahovala opět kompletní volbu, viz. Sending Complete, po čtyřech vteřinách od odeslání přišla zpráva o vyzvánění a od té chvíle dostával volající kontrolní vyzváněcí tón, po dalších 4 vteřinách bylo volání přijato volaným, což indikuje zpráva CONNECT. Spojení bylo ukončeno volající, účastníkem na pobočkové ústředně, což je indikováno odesláním žádosti o rozpojení DISCONNECT. C2651-VoGW-OV# : Dec 30 16:41:55.988: ISDN Se1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0011 Sending Complete Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA9839A Exclusive, Channel 26 Calling Party Number i = 0x0083, '3683' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, ' ' Plan:Unknown, Type:Unknown High Layer Compat i = 0x : Dec 30 16:41:56.088: ISDN Se1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8011 Channel ID i = 0xA9839A Exclusive, Channel : Dec 30 16:42:00.356: ISDN Se1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8011 Progress Ind i = 0x In-band info or appropriate now available : Dec 30 16:42:05.212: ISDN Se1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8011 Date/Time i = 0x0D0C1E102A : Dec 30 16:42:05.288: ISDN Se1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0011 C2651-VoGW-OV# : Dec 30 16:42:19.281: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0011 Cause i = 0x Normal call clearing : Dec 30 16:42:19.289: ISDN Se1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x : Dec 30 16:42:19.385: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0011 Cause i = 0x Normal call clearing C2651-VoGW-OV# Za povšimnutí rovněž stojí, že všechny přijaté zprávy GW z PBX mají shodný Call reference callref = 0x0011 a odchozí odeslané GW do PBX callref = 0x8011 a byl použit TSL 26 (timeslot) 32-kanálové E1 Exclusive, Channel 26. Podle Call reference najdu zprávy týkající se jednoho spojení a v případě silně zatížené GW, kde probíhají desítky volání současně lze očekávat poměrně slušný provoz zpráv z různých kanálů a je nutné najít nejdříve konkrétní Call reference, podle kterých můžou býti zprávy analyzovaného spojení dohledány. 39

47 2 Standard ITU-T H.323 Výše zmíněná nastavení byla prakticky ověřena v rálném nasazení (autor stál u zrodu akademické VoIP sítě v ČR postavené na Cisco technologii), ale je nutné vzít v potaz, že s dalšími verzemi IOS byly možnosti ještě rozšířeny. 2.7 GNU Gatekeeper GNU Gatekeeper je open-source projekt, který vznikl v roce 2001, jedná se o svobodný software šířený pod licencí GNU GPL. Nejznámějším gatekeeperem je bezesporu GNU GK, jedná se o plně H.323 kompatibilní gatekeeper (dále jen GK) dostupný na stránkách projektu a použitelný pod licencí GPL. GNU GPL dovoluje aplikaci kopírovat, distribuovat, prodávat nebo modifikovat, ale veškerá činnost musí být opět pod GPL, což znamená, že k případně provedeným úpravám původního kódu musí být dodán i modifikovaný zdrojový kód. Aktuálně je aplikace v ostré verzi 3.5 z roku 2014, během jednoho roku může být vydáno i několik verzí. GNU GK je úspěšný projekt a existuje řada sítí, které jsou postaveny na GNU GK. V akademické komunitě je to např. GDS (Global Dialing Scheme), což je síť pro videokonference a telefonii, projekt vznikl původně na anglických univerzitách a postupně byl rozšířen po celém světě. Obr 2.16 Logo projektu GnuGK Současným koordinátorem projektu GNU GK (dále jen GnuGK) je Jan Willamowius. Jelikož se jedná o open-source projekt, je možné se do samotného vývoje případně testování osobně zapojit. GnuGK gatekeeper je velmi stabilní, proto je komerčně využíván mnoha organizacemi poskytujícími VoIP služby. Autoři projektu poskytují GnuGK pro operační systémy: Linux, Windows, FreeBSD, Solaris a MacOS X. Pod operačním systémem Windows může GnuGK běžet jako služba v pozadí. GnuGK nabízí mnoho užitečných funkcí, jako např. flexibilní směrování hovorů, široké možnosti autentizace a autorizace, plnou podporu H.323 proxy a NAT a rovněž H.235 bezpečnostních mechanizmů. Vývojáři také postupně implementují nové funkce dle požadavků uživatelů. GnuGK je možné dále rozšířit o grafické uživatelské prostředí usnadňující práci s gatekeeperem nebo možnost vytvořit aplikaci call-centra. Stává se nedílnou součástí systémů pro IP telefonii, založených na standardu H.323. Velká výhoda je vzájemná kompatibilita GnuGK gatekeeperu s řadou zařízení pro VoIP služby. Na uvedené webové stránce projektu GnuGK je možné získat více informací o projektu, procházet diskuze týkající se podpory, nalézt konfigurační tipy a ukázkové konfigurace, získat samotný gatekeeper a přehledně zpracovaný manuál. Implementace GnuGK vychází z knihoven projektu openh323 dostupného na stránkách kde je rovněž ke stažení GK pro Linux i Windows pod názvem OpenGK, ale nejedná se o GnuGK, nýbrž o projekt odlišný a OpenGK nedosahuje možností GnuGK dostupného na Implementaci H.323 přináší i Asterisk v podobě oh323 či 40

48 2 Standard ITU-T H.323 ooh323 kanálu a je možné propojit řešení GnuGK s Asteriskem, kterému je věnována kapitola zabývající se otevřeným řešením pro SIP. Příkladem nejrozsáhlejšího nasazení GnuGK v ČR je síť sdružení vysokých škol CESNET2 [v55]. V současné době je v rámci IP telefonie sdružení CESNET2 přihlášeno zhruba padesát hlasových brán (dále jen VoGW), které jsou registrovány k vnitřním GK na platformě Cisco. K těmto VoGW jsou připojeny pobočkové ústředny institucí (dále jen PBX), které mohou volat v rámci sítě CESNET2 a subjekty mohou využívat i výstupu do veřejné sítě přes ČVUT. Sdružení CESNET byl přidělen přístupový kód do neveřejné sítě sdružení ve tvaru Na GNU GK je provozován národní gatekeeper akademické sítě v ČR, který je zapojen jak do další mezinárodní struktury hierarchického směrování (GDS), tak slouží pro připojení jiných GK. Doménové jméno národního GK je gk1ext.cesnet.cz. Téměř všechny univerzity v ČR mají k síti CESNET2 připojeny své pobočkové ústředny a GnuGK se uplatňuje jako hraniční Gatekeeper, je využíván pro peering se zahraničními institucemi a kromě komunikace s interními GK spravuje číselný plán s prefixem Například v roce 2005 bylo v síti CESNET2 pomocí technologie VoIP uskutečněno zhruba 1,5 mil. hovorů. Bližší informace k projektu GnuGK na Cesnetu lze najít na stránkách projektu a v dalších publikacích [v50], [v67], [sir] Instalace a konfigurace GnuGK Předpokládejme, že pro otestování postačí zavolat mezi dvěma H.323 koncovými body a k tomu nám postačí nějaká aplikace H.323 klienta, použijeme např. YATE, který stáhneme ze stránek anebo SPRANTO S GnuGK budeme pracovat v linuxovém prostředí, jelikož autor pracuje s distribucí Debian, tak je nutné vzít v potaz, že instalace např. v Ubuntu bude nutné uvést příkazy vzhledem k uživatelským právům pomocí sudo a v případě CentOS namísto apt-get se použije yum, apod. Nejdříve zjistíme, zda je balíček s gnugk dostupný a potom nainstalujeme. Během instalace vidíme, jaká verze je instalována. # apt-cache search gnugk # apt-get install gnugk Konfigurace GnuGK je uložena v souboru etc/gatekeeper.ini a za běhu GK se dá měnit přes telnet přístupem na port 7000 telnet localhost 7000, to je standardní nastavení. Pro znovunačtení konfigurace za běhu slouží příkaz reload, jinak při spuštění aplikace se vždy načítá nastavení z inicializačního souboru gatekeeper.ini. Pokud někomu nevyhovuje editace inicializačního souboru, tak může používat grafické rozhraní GnuGK Control Center, což je shareware program dostupný na Obsahem souboru gatekeeper.ini jsou hodnoty parametrů v jednotlivý sekcích, název sekce je v hranatých závorkách, pokud je jakýkoliv řádek uvozen středníkem, tak není brán v potaz. Nejdříve bychom měli do gatekeeper.ini vepsat základní část konfigurace. [Gatekeeper::Main] Fourtytwo=42 Name=gk1ext Home= TimeToLive=300 41

49 2 Standard ITU-T H.323 Hodnota 42 prvního parametru je údaj, kterým je zkontrolována přítomnost konfiguračního souboru, do parametru Name zapíšeme název GK dle libosti a tento název se objevuje v některých RAS zprávách, dále následuje IP adresa GK a poslední parametr je expirační čas registrace přihlášeného koncového H.323 prvku na GK v sekundách. GnuGK umožňuje čtyři režimy volání, jedná se o režim DRC (Direct Routed Call), GRC (Gatekeeper Routed Call) pouze s H.225.0/Q.931, GRC včetně H.245 a režim Proxy. V režimu DRC zpracovává GnuGK pouze RAS zprávy, veškerá komunikace se odehrává přímo mezi EP. Pokud je povolen režim GRC, tak lze nastavit směrování signalizace H.225.0/Q931 a H.245 přes GK. Nastavení se provede v sekci [RoutedMode]. Nastavuje se parametry GKRouted na hodnotu 0 (vypnuto) nebo 1 (zapnuto) a H245Routed opět pomocí dvou hodnot. Položku CallSignalPort pro Q.931doporučuji posunout na typický port [RoutedMode] GKRouted=1 H245Routed=0 CallSignalPort=1720 Pokud je zapnut třetí režim GRC, tak může být povolen i Proxy režim, vše přes GK, pokud se zadá v sekci [Proxy] volba Enable a hodnota 1. [Proxy] Enable= Registrace EP Registrace EP (Endpoint - H.323 telefon nebo H323 brána) je na GnuGK časově omezená. GnuGK vrací při registraci každému EP dobu platnosti registrace ve zprávě RFC (Registration Confirm), která je zapsána v poli timetolive. Po vypršení této doby je registrace zrušena. Každý EP by měl svou registraci periodicky obnovovat zasíláním RRQ (Registration Request), je povoleno i obnovování pomocí lightweight RRQ, tzn. pomocí keepalive bit, to probíhá tak, že před uplynutím registrace na GK (time to live) zašle EP zprávu RRQ s keepalive a tím resetuje čítač timetolive a registrace je prodloužena. EP může pochopitelně požadovat i menší čas timetolive ve zprávě RRQ, než má GNU GK jako výchozí. Aby nedošlo k zahlcení GNU GK RRQ zprávami, tak GK vrací jako nejmenší limitní čas pro registraci 60 sekund, ikdyž EP bude požadovat nižší hodnotu. Po expiraci registrace na GK zašle GnuGK dvě zprávy IRQ (Information Request), kterými zjistí, zda je EP komunikativní a pokud nedostane odpověď zprávou IRR, kterou může být registrace prodloužena, tak posílá na endpoint URQ (Unregistration Request) s odůvodněním ttlexpired. V této chvíli je vymazán z databáze aktivních EP na GnuGK a EP musí provést opětovnou registraci pomocí RRQ. Problém může nastat u registrovaných EP, kteří mění svou IP adresu během doby registrace, například bezdrátová LAN dle a uživatel přemísťující se se softphonem na notebooku nebo s 42

50 2 Standard ITU-T H.323 WiFi telefonem. To lze vyřešit tak, že přidáme do gatekeeper.ini další sekci, ve které povolíme přepisování IP adres registrovaných EP. [RasSrv::RRQFeatures] OverwriteEPOnSameAddress=1 Určitě bychom chtěli kontrolovat, jaký EP (Endpoint) se může registrovat na GK. GNU GK umožňuje jednoduchou metodu autentizace, ověření uživatelského jména a hesla přenášeného v poli cryptotokens (hashed by MD5), pričemž uživatelské jméno je vidět transparentně. V GNU GK lze například zadat, aby probíhala autentizace pouze při registraci na GK. Heslo zadané do sekce SimplePasswordAuth se získá přes utilitu addpasswd. Ta se spustí z příkazové řádky a mezerami se oddělí parametry, prvním je název souboru, kam se zapíše výsledek, následuje název sekce, uživatel a heslo. addpasswd gnugkpasswd.conf passwd cesnet cesnet more gnugkpasswd.conf Oblíbeným editorem nebo příkazem more si prohlídneme výsledek a ten zapíšem do gatekeeper.ini ve stejném tvaru [passwd] cesnet=fvqqgh4stxe= Jednotlivé účty řadíme pod sebe do sekce SimplePasswordAuth. Nejdříve ale musíme specifikovat v sekci Gatekeeper::Auth, které zprávy RAS budeme autorizovat k provedení autentizace. Uvedený příklad vyžaduje autentizaci při registraci na GnuGK. [Gatekeeper::Auth] SimplePasswordAuth=required;RRQ default=allow [SimplePasswordAuth] cesnet=fvqqgh4stxe= SW klient, který umí autentizaci je např. YATE, SPRANTO či EKIGA. Pokud máme koncová zařízení, která neumí autentizaci, tak může být užitečné znát další mechanizmus s názvem Alias Authorization a spočívá v ověření uživatelského jména a IP adresy ve zprávě RRQ. Můžeme oba mechanizmy zkombinovat tak, že nejdříve proběhne ověření uživatelského jména a hesla v RRQ modulem SimplePasswordAuth a pokud autentizace přes tento modul neprojde, tak postoupíme další pravidlo a tady je už vyžadováno, aby prošlo přes Alias Authorization. Upravíme tedy sekci Gatekeeper::Auth. [Gatekeeper::Auth] SimplePasswordAuth=optional;RRQ AliasAuth=required;RRQ 43

51 2 Standard ITU-T H.323 default=allow Následně vytvoříme novou sekci RasSrv::RRQAuth, kde je konkrétně vyžadována registrace u čísla z IP adresy s TCP portem [RasSrv::RRQAuth] =sigip: :1720 default=reject Propojení GnuGK s jiným GK Infrastruktura H.323 ovšem bývá složitější, protože potřebujeme volat i mimo svou vlastní zónu obsluhovanou GnuGK a v tom případě potřebujeme propojení s dalším GK. To je snadné, potřebujeme znát jeho IP adresu a telefonní čísla, které používá. Přidání sousedního Gatekeeperu se provádí přes dvě sekce, první RasSrv::Neighbors určuje typ GK a druhá Neighbor už obsahuje konkrétní konfiguraci. [RasSrv::Neighbors] LSU=GnuGK [Neighbor::LSU] Host= SendPrefixes= AcceptPrefixes=* Na vzdálenou zónu, kterou jsme si nazvali LSU (jedná se o univerzitu v Lousianě), jsou posílány požadavky na spojení začínající čísly , a to včetně prefixu, z této zóny jsou přijímány požadavky na vytočení jakéhokoliv čísla Statická registrace GW v GnuGK Často potřebujeme propojení s jiným typem sítě, tak potřebujeme hlasovou bránu VoGW (Voice Gateway), nejčastěji s rozhraním ISDN PRI nebo BRI. VoGW může být realizována například na směrovači osazeném příslušným rozhraním pro propojení nebo kartou v PC. Pokud budeme mít v popisu práce intenzivně šetřit a máme solidní znalosti Linuxu, tak je možné GK i VoGW postavit na řešení Asterisk, což je doslovně SW pobočková ústředna, která je vyvíjena jako open-source projekt a firma Digium, která za Asteriskem stojí, se zabývá prodejem a podporou HW pro Asterisk. Pokud se GW registruje na GK pomocí registračních zpráv RRQ obdobně jako klient, tak není nutné statickou registraci provádět a nakládáme s GW stejně jako s IP telefonem, GW si na GnuGK zaregistruje své prefixy a o nic se nemusíme starat. Pokud se nechceme spoléhat na dynamickou registraci a chceme mít natvrdo v konfiguraci zapsáno, že čísla začínající určitým řetězcem mají být směrována na konkrétní EP, tak GW do konfigurace přidáme, tím pádem GK bude volání na GW 44

52 2 Standard ITU-T H.323 směrovat, ať už bude GW funkční či nikoliv. Přidání VoGW je záležitostí jednoho řádku sekce RasSrv::PermanentEndpoints, často je ovšem nutné přepisovat čísla. Například používáme-li mezinárodní formát čísel a nechceme, aby uživatel musel točit před každým čísel ještě 420, příchod na GW mu tedy ještě přepíšeme v sekci RasSrv::GWRewriteE164, předtím je ovšem nutné dát GW do sekce RasSrv::GWPrefixes. Přepisy mohou být nejen v příchodu na GW, ale taky při vytočení z GW budeme chtít přepsat na [RasSrv::GWPrefixes] GW-VUTBR=54114 [RasSrv::GWRewriteE164] GW-VUTBR=out=54114= [RasSrv::PermanentEndpoints] :1720=GW-VUTBR; [RasSrv::RewriteE164] = Autentizace v GnuGK Autentizace je proces ověření identity subjektu vstupujícího do systému. V našem případě se jedná o ověření identity uživatele žádajícího o přístup na gatekeeper za účelem využívat jeho prostředků a služeb. Konfigurace možnosti autentizace se konkrétně týká již jednou v zmiňované sekce [Gatekeeper::Auth]. Jednotlivá pravidla se poté konfigurují dle předem určené syntaxe. GnuGK podporuje několik autentizačních mechanizmů, každý autentizační mechanizmus se konfiguruje pomocí příslušné podsekce. Je možné definovat více pravidel a udělit jim prioritu. Pokud ověření uživatele selže na primárním autentizačním pravidle, ověření uživatele pokračuje dle nakonfigurovaného následujícího pravidla. Při ověřování uživatele pomocí autentizačního pravidla mohou nastat tři výsledné stavy: ok úspěšně autentizován, ověření uživatele bylo úspěšné, fail ověření selhalo a požadavek by měl být zamítnut, next pravidlo nemůže rozpoznat požadavek, je možné přejít na jiné pravidlo. Autentizační pravidlo můžeme definovat pomocí tří možností: optional pokud nemůže rozpoznat požadavek, je požadavek přeposlán na následující pravidlo, required požadavek musí být autentizován pomocí tohoto pravidla nebo bude zamítnut. sufficient pokud je tímto pravidlem autentizován, požadavek může být přijat. GnuGK gatekeeper podporuje následující autentizační mechanizmy: SimplePasswordAuth - Modul se konfiguruje v podsekci [SimplePasswordAuth], kde se definují uživatelská jména (identifikátory) a příslušná uživatelská hesla. Všechna hesla by měla být šifrována pomocí dodávané utility addpasswd. Tento autentizační modul kontroluje obsah token a cryptotoken polí v RAS signalizačních zprávách. Token by měl minimálně obsahovat identifikátor uživatele generalid a uživatelské heslo. Pro zašifrování hesla podporuje modul hash algoritmy MD5 a HMAC-SHA1-96. Je podporován také přenos 45

53 2 Standard ITU-T H.323 uživatelského jména a hesla ve formě čistého textu (nešifrovaně). Přijaté autentizační informace, získané z příslušné RAS signalizační zprávy, jsou porovnávány s autentizačními údaji definovanými v podsekci modulu, kdy na základě shody je uživatel autentizován. SQLPasswordAuth - Modul se konfiguruje v podsekci [SQLPasswordAuth], kde se konfigurují parametry SQL databáze, která obsahuje autentizační údaje příslušných koncových bodů podporujících standard H.235. Kvůli zpětné kompatibilitě je také podporován modul MySQLPasswordAuth. Přijaté autentizační informace jsou v případě tohoto modulu porovnávány s autentizačními údaji uloženými v SQL databázi. AliasAuth - Modul se konfiguruje v podsekci [RasSrv::RRQAuth], kde se specifikuje chování modulu (přijmout/zamítnout) v případě přijetí RRQ (RegistrationRequest) signalizační zprávy, tedy žádosti o registraci koncového bodu na gatekeeper. Alias adresa koncového bodu, obvykle se jedná o H.323 identifikátor, se stává klíčovým parametrem pro chování autentizačního pravidla. Aby byla autentizace koncového bodu úspěšná, je nutné, aby byly všechny podmínky stanovené pro příslušnou alias adresu splněny. Jako příklad lze uvést registraci podmíněnou IP adresou, ze které koncový bod žádá o registraci na gatekeeper. SQLAliasAuth - Modul se konfiguruje v podsekci [SQLAliasAuth], kde se konfigurují parametry SQL databáze, která obsahuje autentizační pravidlo. Tento modul vychází z modulu AliasAuth, chování modulu (přijmout/zamítnout) je ovlivněno podmínkami a pravidly uloženými v SQL databázi. FileIPAuth - Modul se konfiguruje v podsekci [FileIPAuth], kde se definují IP adresy a sítě, které mají povoleny přístup k prostředkům gatekeeperu. Je možné specifikovat seznam povolených (zakázaných) prefixů společně s IP adresami, seznam může být také načítán externě pomocí instrukce include. Modul tedy poskytuje jednoduchý postup jak zamezit přístup na gatekeeper pomocí IP adresy nebo adresy sítě. PrefixAuth - Modul se konfiguruje v podsekci [PrefixAuth], kde se definují příslušná autentizační pravidla. Tento modul v současné době podporuje pouze signalizační zprávy ARQ (AdmissionRequest) a LRQ (LocationRequest). Princip chování modulu spočívá v tom, že IP adresy nebo alias adresy požadavku spolu s daným prefixem musí odpovídat definovanému pravidlu, jinak bude požadavek zamítnut. RadAuth - Modul se konfiguruje v podsekci [RadAuth], kde se využívá možnosti autentizace pomocí RADIUS serveru, založené na H.235 CAT (Cisco Access Token) token mechanizmu. Modul podporuje RAS signalizační zprávy RRQ, ARQ a signalizační zprávu Q.931 Setup. Pracuje s H.235 bezpečnostními mechanizmy, kdy autentizační informace získané z CAT tokenu posílá k ověření na RADIUS server. Pokud koncový bod CAT token nepodporuje, je možné použít modul RadAliasAuth. RadAliasAuth - Modul se konfiguruje v podsekci [RadAliasAuth], kde se nastavuje možnost autentizace pomocí RADIUS serveru na základě alias adres nebo IP adres koncových bodů obsažených v požadavku. Modul podporuje RAS signalizační zprávy RRQ, ARQ a signalizační zprávu Q.931 Setup. Tento autentizační modul je vhodný jak pro registrované koncové body, kde se pro autentizaci uplatňují signalizační zprávy RRQ a ARQ, tak i pro neregistrované koncové body, kde se využívá pro autentizaci signalizační zpráva Setup. Modul nevyžaduje přítomnost H.235 tokenu uvnitř signalizačních zpráv, proto je použitelný ve větší míře, než modul RadAuth. 46

54 2 Standard ITU-T H.323 SQLAuth - Modul se konfiguruje v podsekci [SQLAuth], kde se konfigurují parametry SQL databáze, která obsahuje potřebné informace pro autentizaci i autorizaci koncových bodů. Modul podporuje RAS signalizační zprávy RRQ, ARQ, LRQ a signalizační zprávu Q.931 Setup. Jedná se o výkonný modul umožňující autentizovat i autorizovat požadavky na základě různých parametrů, jako např. číslo volajícího uživatele, volané číslo, uživatelské jméno apod. Pomocí tohoto modulu můžeme také stanovit maximální délku hovorů, směrování hovorů, přiřazování alias adres apod. Syntaxe konfigurace autentizačního pravidla může být provedena následujícím způsobem. Autentizace na GnuGK probíhá pomocí modulu FileIPAuth. Povolený přístup mají pouze uživatelé sítě s IP adresou /24, kromě IP adresy , která má přístup zakázán. [Gatekeeper::Auth] FileIPAuth=required;RRQ,LRQ,Setup [FileIPAuth] =reject /24=allow any=reject Autorizace v GnuGK Autorizace je proces pro ověření práv daného uživatele. Úspěšně autentizovaný a přihlášený uživatel může mít totiž různá práva pro různé úkony. V oblasti IP telefonie to znamená např. omezit uživateli možnost volat na určitá čísla nebo naopak omezit přístup na jeho číslo. V současnosti nabízí GnuGK možnost autorizace uživatelů pomocí dvou modulů. PrefixAuth modul podporuje autorizaci uživatelů pro signalizační zprávy ARQ a LRQ. Modul ověřuje prefix z pole destinationinfo (volané číslo), obsažený v požadavku spolu s IP adresou nebo alias adresou, jestli se shoduje s definovaným pravidlem. Na základě tohoto definovaného pravidla je možné požadavek přijmout nebo zamítnout. Můžeme také definovat implicitní pravidlo, pokud nedojde ke shodě prefixu s pravidlem. Modul tedy nabízí možnost efektivně zamezit volání uživatelů na určitá zakázaná čísla. Ukázka autorizace uživatelů na základě prefixu: 555=deny ipv4: /27 allow ipv4:0/0 5555=allow ipv4: deny ipv4: / =deny!ipv4: /24 09=deny alias:^ * SQLAuth modul je výkonný modul nabízející více možností autorizace uživatelů. Podporuje RAS signalizační zprávy RRQ, ARQ, LRQ a signalizační zprávu Q.931 Setup. Na základě tohoto modulu můžeme autorizovat uživatele dle mnoha volitelných parametrů, které ukládáme v SQL databázi. Uživatele můžeme autorizovat na základě volaného čísla, uživatelského jména, můžeme stanovit maximální délku hovoru, můžeme směrovat jednotlivé hovory apod. SQL databáze tedy tvoří flexibilní možnost libovolně autorizovat uživatele na základě řady podporovaných parametrů. Mechanizmus autentizace a autorizace na obr byl realizován jako diplomová práce [sir] a řešení přes RADIUS bylo zvoleno z důvodu 47

55 2 Standard ITU-T H.323 nepodporovaného protokolu LDAP v GnuGK, podpora LDAP byla přidána ve verzi a dá se zapnout při kompilaci GnuGK. Obr 2.17 Příklad řešení mechanizmu autentizace a autorizace Návrh sítě s konfigurací GnuGK Návrh topologie je v obr. 2.18, skládá se ze dvou GK, každý GK spravuje svou zónu, ve které jsou umístěny IP telefony a v zóně B je navíc umístěna hlasová brána VoGW, která je propojena s PBX a přes PBX do veřejné sítě PSTN, tato VoGW se registruje dynamicky s prefixem 9, čili cokoliv začínající číslicí 9 posíláme přes VoGW do PBX. Obr 2.18 Návrh topologie H.323 sítě. 48

56 2 Standard ITU-T H.323 V zóně A se budou nacházet čísla začínající pětkou, např (IP phone A) a v zóně B začínající dvojkou, např (IP phone B), navíc je v zóně B už zmíněná brána VoGW s ISDN. Zvolíme ISDN BRI a jelikož se připojujeme k PBX, tak budeme emulovat stranu sítě, nechť je konfigurace v PBX standardní. Začneme s konfigurací GnuGKA umístěného na obr vlevo nahoře. Než nainstalujeme gnugk, tak pro jistotu nejdříve odinstalujeme starší verzi, pokud se nachází a vyčistíme staré konfigurační soubory, následně provedeme aktualizaci seznamu balíčku z repozitáře a poté konečně nainstalujeme gnugk. # apt-get remove gnugk # dpkg --purge gnugk # apt-get update # apt-get install gnugk Veškerá konfigurace je uložena v souboru /etc/gatekeeper.ini, změny budeme provádět vhodným editorem. Po provedení změn můžeme přes telnet můžeme provést přehrání (reload) konfigurace bez výpadku gnugk a rovněž se můžeme podívat příkazem rv na výpis aktuálních registrací. # nano /etc/gatekeeper.ini # telnet localhost 7000 reload rv exit Nastavení GK a mezizónové propojení V sekci Main si GK vhodně pojmenujeme a nastavíme režim (např. DRC), posuneme TCP port Q.931 na standardní 1720 a abychom se vyhnuli problémům s detekcí duplicitní registrace (změna IP u EP), tak raději povolíme i přepisování registrací. [Gatekeeper::Main] Name=GnuGKA TimeToLive=600 [RoutedMode] GKRouted=0 /* running in DRC H245Routed=0 CallSignalPort=1720 [RasSrv::RRQFeatures] OverwriteEPOnSameAddress=1 Teď bychom měli nakonfigurovat IP klienta Yate, PacPhone nebo Ekiga a zkusit se zaregistrovat. Registraci můžeme sledovat přes telnet v konzoli. Připravíme si mezizónovou komunikaci směrem na GK-B, kam budeme směrovat volbu s čísly začínající dvojkou a devítkou, jako příchozí akceptujeme jakoukoliv volbu (*). 49

57 2 Standard ITU-T H.323 [RasSrv::Neighbors] GK-B=GnuGK [Neighbor::GK-B] Host= SendPrefixes=2,9 AcceptPrefixes=* V dalším kroku si připravíme GnuGKB a jeho konfigurace je obdobná přechozí. Připravíme mezizónovou komunikaci směrem do zóny A, kterou pozorně porovnáme s přechozím zápisem na GnuGKA [Gatekeeper::Main] Name=GnuGKB TimeToLive=600 [RoutedMode] GKRouted=0 H245Routed=0 CallSignalPort=1720 [RasSrv::RRQFeatures] OverwriteEPOnSameAddress=1 [RasSrv::Neighbors] GK-A=GnuGK [Neighbor::GK-A] Host= SendPrefixes=5 AcceptPrefixes=* Nastavení VoGW a dynamické registrace na GK Nejdříve nastavíme doporučené globální parametry v kapitole věnující se konfiguraci hlasových brán Cisco. Přihlášení na GK nakonfigurujeme tak, že se bude brána registrovat pod názvem VoGW a prefixem 9, na GK není třeba provádět žádnou úpravu. voice rtp send-recv! voice service voip h323 h245 caps mode restricted interface FastEthernet0/0 ip address h323-gateway voip interface h323-gateway voip id GnuGKB ipaddr priority 100 h323-gateway voip h323-id VoGW 50

58 2 Standard ITU-T H.323 h323-gateway voip tech-prefix 9 V další části nastavíme opět globální parametry brány ale tentokrát z pohledu ISDN, zatímco předtím to byly parametry ze strany IP světa. Konfigurace ISDN BRI je dána tím, že emulujeme stranu sítě a používáme signalizaci DSS1. voice-port 0/0 compand-type a-law cptone CZ bearer-cap 3100Hz interface BRI0/0 no ip address isdn switch-type basic-net3 isdn not-end-to-end 64 isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn send-alerting isdn outgoing-voice info-transfer-capability 3.1 khz-audio isdn static-tei 0 isdn skipsend-idverify Poslední část konfigurace VoGW se týká nastavení směrů jak odchozí tak příchozí a v závorce uvedený řetězec [25] je součást regulárního výrazu říkající, že platí pro číslo začínající dvojkou nebo pětkou. dial-peer voice 1 voip destination-pattern [25]... session target ras codec g711alaw no vad! dial-peer voice 20 pots destination-pattern 9... direct-inward-dial port 0/0! dial-peer voice 999 voip codec g711alaw incoming called-number..t! Komunikaci sledujeme protokolovým analyzátorem Wireshark a po úspěšném odzkoušení návrhu změníme režim z DRC na GRC pomocí nastavení GKRouted=1. Obr zobrazuje příklad mezizónové mezizónovou komunikace (IP adresy jsou odlišné). 51

59 2 Standard ITU-T H.323 Obr 2.19 Mezizónová komunikace. GK na levé straně obr. 2.4 nemůže odpovědět ihned na ARQ, jelikož nezná umístění volaného EP, posílá LRQ na sousední GK, kde se ptá na destinationinfo (hledané číslo ), odpověď je očekávána na IP portu 1719, viz. obr Obr 2.20 Obsah zprávy LRQ. Odpověď LCF, viz. obr obsahuje callsignaladdress (Q.931) port 1720, tato informace je následně vložena do ACF, tím se volající EP dozvídá, kam má poslat žádost o sestavení spojení SETUP. Sousední GK rovněž sděluje adresu pro další RAS komunikaci port Obr 2.21 Zpráva LCF v mezizónové komunikaci. 52

60 5 Základy protokolu SIP 3 Session Initiation Protocol SIP (Session Initiation Protocol) je protokolem pro sestavení, modifikaci a terminaci obecné relace v Internetu a nejčastěji je používán pro audio. Byl vyvíjen od roku 1996 pracovní skupinou MMUSIC (Multiparty Multimedia Session Control) v rámci IETF (Internet Engineering Task Force). V roce 1999 byl předložen ve formě navrhovaného standardu (Proposed Standard) v RFC Téhož roku na popud IETF vznikla nová pracovní skupina, nazvaná příznačně SIP, která převzala vývoj hlavního jádra protokolu. Její práce v květnu roku 2002 vyústila v nový standard RFC Dnes existuje kolem stovky dalších RFC, které se přímo týkají SIPu nebo na něj navazují, ať už jde přímo o nové metody komunikace anebo např. rozšíření položek v hlavičkách. 3.1 Základní popis protokolu SIP SIP pracuje na aplikační vrstvě, byl navržen tak, aby byl snadno implementovatelný, rozšiřitelný a dostatečně flexibilní. Protokol je užíván pro sestavení, modifikaci a ukončení spojení s jedním nebo více účastníky, ale není jediným protokolem, který je potřebný pro audiovizuální komunikaci, ve spojení se SIPem jsou nejčastěji používány ještě dva další protokoly, RTP (Real-Time Protocol) pro přenos vlastního obsahu a SDP (Session Description Protocol) pro popis přenášeného obsahu [sin1], [sin2]. SIP je end-to-end orientovaný signalizační protokol, což znamená, že veškerá logika je uložená v koncových zařízeních, koncová zařízení znají i jednotlivé stavy komunikace, chování lze popsat stavovým diagramem, ve kterém se v rámci dialogu (spojení) probíhají jednotlivé transakce (žádosti a odpovědi). Tím je zvýšena odolnost komunikace proti chybám. Cena, která se musí zaplatit za decentralizaci a dostupnost služby, je vyšší režie hlaviček zpráv. Nepochybně stojí za zmínku, že end-to-end koncept SIPu je zásadně odlišný od klasického řešení PSTN (Public Switched Telephone Network), kde logika je uložena v síti a koncová zařízení jsou primitivní. Jedním z cílů SIPu je zajistit stejnou funkcionalitu jakou mají klasické PSTN, ale end-to-end návrh umožňuje v SIPu podstatně snadnější implementaci nových služeb a některé z nich mohou být jen stěží nasazeny v klasických PSTN. SIP je textově orientovaný protokol z rysy podobnými HTTP a SMTP protokolu. HTTP a SMTP jsou nepochybně nejúspěšnějšími a nejpoužívanějšími protokoly v Internetu, volba osvědčeného modelu komunikace zaručuje SIPu robustnost a nadčasovost. Klient posílá požadavky na server, který zasílá odpovědi obdobně jako u HTTP, v hlavičkách najdeme položky From, To či Subject jako 53

61 5 Základy protokolu SIP u mailové komunikace pomocí SMTP. SIP entita je vázána k doméně obsluhovanou SIP Proxy a mezidoménová komunikace je tedy mezi různými SIP Proxy, výjimkou je multidoménová SIP Proxy. SIP entity jsou identifikovány použitím SIP URI (Uniform Resource Identifier), řekli bychom jednoduše jmennými identifikátory, jejich obecný tvar je uveden níže. sip:user:password@host:port;uri-parameters?headers SIP URI se skládá jednak z části username identifikující uživatele a jednak z host vztažené k doméně neboli hostiteli, který poskytuje uživateli určité prostředky k zajištění komunikace, následuje pole password jehož použití není doporučeno. Port je standardně 5060 na UDP, případné parametry se oddělují středníkem a pokud je potřebné přímo do URI zadat i nějaké parametry hlavičky, tak se uvádějí za otazníkem. Většinou ale uvidíme SIP URI v podobě jednoduché konstrukce sip:user@host, což nápadně připomíná ovou adresu. Příkladem SIP URI může být: sip:voznak@cesnet.cz sip: @cesnet.cz SIP tedy pracuje se jmennými identifikátory a číslo můžeme přeložit na URI pomocí DNS, kde jsou k tomu určeny záznamy NAPTR (Name Authority Pointer) a technika mapování URI na tel. čísla (standard ITU-T E.164) se nazývá ENUM (E.164 NUmber Mapping). URI je obecně prezentováno řetězcem znaků, jehož cílem je umožnit interakci se zdrojem pomocí určitého protokolu, tzn. musí nutně obsahovat název schématu (protokol) a adresu zdroje, za schématem následuje dvojtečka. URI dle RFC 3986 je definováno následovně: <scheme name> : <hierarchical part> [? <query> ] [ # <fragment> ] Příklady pro scheme name jsou: sip, sips, h323, tel, http, https, ftp, imap, ldap, mailto, telnet, im, pop, news, atd... Hierarchical part nese informaci o identifikaci zdroje, obvykle začíná dvojitým lomítkem // a následuje např.: domain name, IP address, username:password@, user@host. Pokud je specifikováno číslo portu, tak se začíná znakem :, např. :5060, :8080, :8085, atd... Query je nepovinná část, která obsahuje doplňující informace, obecná syntaxe není definována, obvykle se objevuje ve formě <key>=<value>, kde jednotlivé hodnoty jsou odděleny znakem &, např. key1=value1&key2=value2&key3=value3. Fragment je nepovinná část umožňující nepřímo identifikovat další zdroj a začíná znakem #. 54

62 5 Základy protokolu SIP SIP adresa je vázána k doméně, a proto následuje několik základních informací k DNS. Jména domén jsou vyjádřena pomocí adres 32-bitových (IPv4) A záznam nebo 128 bitových (IPv6) - AAAA záznam. Systém DNS zajišťuje překlad doménových jmen na IP adresy, stejně tak zajišťuje zpětný překlad IP adresy na doménové jméno - PTR záznam. Doménová jména jsou vytvářena hierarchicky, stejně jako jsou hierarchicky organizovány DNS servery. Prostor doménových jmen tvoří strom, jeho kořenem je kořenová doména, která se zapisuje jako samotná tečka, pod ní se v hierarchii nacházejí tzv. domény nejvyšší úrovně (Top-Level Domain, TLD). Při vyhledávání v DNS provádějí klienti obvykle dopředné vyhledávání (reverzní dotaz slouží k získání doménového jména ze známé IP adresy), což je hledání založené na názvu DNS jiného počítače, který je uložen v záznamu o prostředku hostitele (A). U odpovědi na tento typ dotazu se jako údaj o prostředku očekává adresa IP. Systém DNS poskytuje rovněž zpětné vyhledávání, při kterém klienti používají známou adresu IP a hledají název počítače na základě jeho adresy, pro tento účel byla ve standardech DNS definována speciální doména in-addr.arpa. V rámci domény inaddr.arpa jsou pomocí opačného pořadí čísel adres IP v desítkovém formátu s tečkou vytvořeny subdomény, které tvoří obor názvů pro zpětné dotazy. Stromová struktura domény in-addr.arpa integrovaná do systému DNS vyžaduje definování dalšího typu záznamu o prostředku - záznamu o prostředku ukazatele (PTR). Tento záznam o prostředku vytváří v zóně zpětného vyhledávání mapování, které obvykle koresponduje se záznamem prostředku hostitele (A) pro název počítače DNS hostitele v jeho zóně dopředného vyhledávání. Strom je administrativně rozdělen rozdělit do zón, které spravují jednotliví správci. Obsah zóny (domény či několika domén) je uložen v tzv. zónovém souboru, skládá se z jednotlivých záznamů (resource records, RR) obsahujících dílčí informace. Zónový soubor vždy musí začínat záznamem typu SOA. Nejčastěji se používají následující typy záznamů: A (address record) obsahuje IPv4 adresu přiřazenou danému jménu, například neco.vsb.cz má IP adresu , zónový soubor pro doménu vsb.cz bude obsahovat záznam, neco IN A , CNAME (canonical name record) je alias - jiné jméno pro jméno již zavedené, jeho definice pomocí přezdívky umožňuje jej později snadno přestěhovat na jiný počítač, např. neco.vsb.cz má sloužit zároveň jako nic.vsb.cz, v zónovém souboru přibude nic IN CNAME neco, SOA (start of authority record) je zahajující záznam zónového souboru. Obsahuje jméno primárního serveru, adresu elektronické pošty jejího správce a další údaje (serial, refresh, retry, expire a TTL). 3.2 Prvky SIP řešení Ačkoliv v nejjednodušší konfiguraci je možné použít dva UA posílající si navzájem SIP zprávy, typická SIP síť bude obsahovat více než jeden typ prvků. 55

63 5 Základy protokolu SIP User Agent a Back to Back User Agent Základními SIP prvky jsou: SIP user agent (UA), který je prezentován koncovým terminálem, SIP proxy, registrar, redirect a location servery, často označováno jako SIP server. Jednotlivé servery jsou většinou stavěny jako logické části SIP serveru, jelikož z pohledu nákladů je efektivnější jejich provoz na jednom společném HW, každopádně filozofie návrhu SIP architektury umožňuje jejich plnou dekompozici, což je výhodou pro velká řešení, distribuovaná architektura vede ke zvýšení robustnosti. Koncové body, kde vzniká a je terminována SIP relace, jsou nazývány jako user agents (UA). UA obvykle jsou představovány koncovými terminály ve formě HW SIP telefonu nebo aplikace, SIP UA mohou být IP telefony, Smartphones, PSTN brány (GW), IVR systémy, atd. UA jsou vztaženi k User Agent Server (UAS) a User Agent Client (UAC). UAS a UAC jsou pouze logické entity, každý UA obsahuje UAC a UAS: UAC je část vysílající požadavky a přijímající odpovědi, UAS je část přijímající požadavky a odesílající odpovědi. Žádost a odpověď jsou dva základní typy SIP zpráv. Protože koncové zařízení téměř vždy obsahuje UAC a UAS, tak používáme pouze označení UA namísto UAC a UAS. Například, volající UA funguje jako UAC, když odesílá zprávu INVITE (požadavek na sestavení spojení) a přijímá odpověď na požadavek. Volaný UA se chová jako UAS, když obdrží zprávu INVITE a odesílá odpověď. Ale tato situace se mění, když volaný se rozhodne zavěsit a odesílá se zpráva BYE a ukončuje spojení. V tomto případě se volající chová jako UAC a volaný jako UAS. INVITE INVITE Obr. 3.1 Rozeslání INVITE více příjemcům. 56

64 5 Základy protokolu SIP Obr. 3.1 ukazuje tři UA a SIP Proxy. UAC inicializuje spojení odesláním žádosti INVITE na SIP Proxy, ta je přeposlána adresátovi, jelikož je příjemců více, tak dochází k rozeslání na dva UAS (forking). Na prvním z nich, který přijme volání, tak je sestaveno spojení. Při ukončení spojení odesílá UAC zprávu BYE přímo na UAS. B2BUA je speciální typ UA vkládaného do cesty a vytvářejícího dvě spojení, na B2BUA je ukončeno jedno spojení a sestaveno nové na cíl, B2BUA zprávy a odpovědi na rozdíl od SIP Proxy nepřeposílá, ale vytváří nové směrem k oběma komunikujícím stranám. Koncový terminál ovšem nerozezná rozdíl mezi voláním přes B2BUA a SIP Proxy. B2BUA má rozsáhlejší možnosti než SIP Proxy, ovšem výkon vyjádřený počet obsloužených požadavků na spojení za jednotku času je podstatně menší oproti klasickým SIP Proxy, což vyplývá z rozdílného přístupu k obsluze SIP zpráv [v188] a [v191]. Použití B2BUA je poměrně časté, typickým příkladem je ASTERISK, který má rozsáhlé možnosti doplňkových služeb pro koncové uživatele, je používán jako pobočková ústředna do velikosti řádově tisíců uživatelů. Jako představitele klasické SIP PROXY si uveďme KAMAILIO, řešení je vhodné i pro velké poskytovatele s dimenzování až pro stovky tisíc uživatelů [v133], [v191] and [v229] SIP Proxy Server SIP umožňuje vytvořit infrastrukturu sítě hostitelů nazývaných jako SIP Proxy servery. Koncové terminály UA mohou odesílat zprávy na SIP Proxy server. SIP Proxy servery jsou důležité entity infrastruktury. Zajišťují směrování žádostí o spojení dle aktuálního umístění adresáta, mohou provádět autentizaci, účtování a realizovat doplňkové služby (např. přesměrování). Nejdůležitější úloha SIP Proxy serveru je směrovat žádosti o sestavení spojení blíž k volanému. Při inicializaci sestavení spojení je základní úlohou SIP Proxy nalézt další SIP Proxy, která obslouží požadavek a na tuto danou zprávu odeslat. K nalezení SIP proxy pro next hop může kromě statického záznamu i vyhledávat v DNS. Požadavek na sestavení spojení je tedy směrován přes jednotlivé SIP Proxy a volaný nakonec žádost akceptuje nebo odmítne. Máme dva základní typy SIP proxy serverů: stateless (bezestavový), stateful (a s informací o stavech). Kromě SIP Proxy serveru máme následující servery: Redirect Server slouží pro přesměrování, vrací nové URI uživatele, Registrar Server přijímá požadavky na registraci, aktualizuje lokalizační databázi a mapuje logickou URI uživatele (user URI) na fyzickou URI zařízení (device URI), user URI je taky označována jako AOR (Address of Record), Location Server je úložištěm informací o umístění uživatelů a SIP Proxies, posledním případem je B2BUA, který je používán v režimu SIP serveru. Stateless SIP Proxy jsou poměrně jednoduché a pouze přeposílají zprávy nezávisle na jejich vzájemné vazby. Zprávy jsou většinou v pořádku z hlediska souslednosti a významu v signalizaci, bezestavové SIP Proxy servery neumí kontrolovat jejich výměnu z hlediska smysluplnosti, nezachytí 57

65 5 Základy protokolu SIP replikaci zpráv, detekce nekonečných smyček jim trvá déle, nejsou srovnatelné se stateless SIP Proxy do rozsahu možností, neumí např. větvení či přesměrování. Stateless SIP Proxy servery jsou jednoduché, ale rychlejší než Stateful SIP Proxy. Využití mají jako balanční servery, pro jednoduché překládání zpráv a směrování. Stateful SIP Proxy servery jsou mnohem komplexnější. Po přijetí požadavku, server vytvoří záznam stavu a drží důležité informace, dokud nedojde k ukončení transakce či dialogu, dělí se tak na dva typy. transakční, drží stavy k žádosti (dokud není definitivně vyřízena), dialogové, drží stavy dialogu (dokud neskončí celé spojení). Některé transakce, zejména vytvořené zprávou INVITE, mohou trvat poměrně dlouho (dokud volaný nevyzvedne nebo se neukončí volání). Protože proxy servery s informací o stavech musí udržovat stav po celou dobu dané transakce, je jejich výkon limitován. #1 INVITE #5 INVITE Obr Sestavení spojení přes dvě SIP Proxy. Schopnost přiřazovat SIP zprávy do transakcí dává serveru některé zajímavé vlastnosti, například může provádět větvení, na přijetí jedné zprávy, může být odesláno více zpráv (uživatel má např. vícenásobnou registraci). Stateful SIP Proxy server může zachytit opakování zpráv, protože ze stavu transakce ví, jestli byla stejná zpráva už přijata (Stateless Sip Proxy nemůže ověřovat, protože nedrží stav). Stateful SIP Proxy server může aplikovat komplikovanější metody nalezení uživatele, například možnost zkusit volat na telefon v zaměstnání a v případě neohlášení volání přesměrovat na mobilní telefon, zatímco stateless SIP Proxy žádost přepošle a už o nemá k ní 58

66 5 Základy protokolu SIP informacemi, čili nemůže tedy provést např. přesměrování po čase. Většina SIP Proxy serverů je stateful, často nabízejí generování záznamů o spojeních, větvení, některé druhy podporují i NAT. SIP je připraven na situaci, kdy každá jednotka (např. firma) bude mít vlastní SIP proxy server, který je užíván všemi UA v rámci administrované jednotky [v90]. Předpokládejme, že jsou dvě firmy A a B a každá z nich má svůj Proxy server. Obr. 3.2 ukazuje situaci, kdy Alice z firmy A inicializuje spojení na Boba z firmy B. Uživatel Alice volá Boba a použije URI adresu sip:bob@b.com. UA neví, kam má poslat žádost o sestavení spojení, ale je nakonfigurován tak, že veškerý odchozí provoz (outbound traffic) posílá na SIP Proxy server své firmy A s adresou proxy.a.com. Proxy server zjistí, že uživatel sip:bob@b.com je v jiné firmě a tak vyhledá odpovídající SIP Proxy server, kam pošle žádost. Odpovídajícím serverem je proxy.b.com a je zadán staticky v proxy serveru firmy A anebo bude Proxy vyhledán pomocí záznamu DNS SRV, kterým je zjištěno, kdo poskytuje službu SIP v doméně b.com. Žádost tedy dorazí na proxy.b.com. SIP Proxy ví, že Bob je aktuálně ve své kanceláři a dosažitelný na telefonu na svém stole, jež má IP adresu , takže SIP Proxy přeposílá žádost INVITE. Zmínili jsme se, že SIP Proxy na proxy.b.com zná současnou polohu Boba, ale neřekli jsme, jak Proxy může lokalizovat uživatele. Bobův UA (SIP telefon) musí být registrován na SIP Registrar serveru. Registrar server je speciální část SIP serveru, která přijímá od uživatelů požadavky na registraci, tím získává informaci o jejich aktuální poloze (IP adresa, port a uživatelské jméno) a ukládá informaci do lokalizační databáze (location database) SIP Registrar Server V lokalizační databázi v našem případě došlo k namapování adresy User URI sip:bob@b.com k adrese Device URI sip:bob@ :5060. Lokalizační databáze je pak užívána Proxy serverem. Když inbound Proxy server obdrží žádost pro sip:bob@b.com, vyhledá v lokalizační databázi záznam sip:bob@ :5060 a na danou IP adresu pošle žádost. Obr Průběh registrace. 59

67 5 Základy protokolu SIP Registrar server je velmi často pouze jako logická část SIP serveru, jelikož je těsně svázán s Proxy serverem. Obr. 3.3 znázorňuje typickou SIP registraci. Zpráva REGISTER je vyslána do Registrar serveru a obsahuje adresu záznamu User URI sip:bob@biloxi.com a kontaktní adresu Device URI sip:bob@ :5060, kde je IP adresa telefonu. Registrar zaznamenává tyto informace do lokalizační databáze. Pokud registrace proběhla správně, tak Registrar server posílá odpověď 200 OK a proces registrace je ukončen. Každá registrace má limitovanou dobu platnosti, doba platnosti je v hlavičce kontaktu (Expires), do té doby musí UA obnovit registraci, jinak bude nedostupný SIP Redirect Server Jak již bylo řečeno, SIP URI je vázána k doméně, ta je nezávislá na síťové topologii, a například SIP server v doméně vsb.cz můžu používat odkudkoliv. Může být ovšem někdy nepraktické jej používat, pokud jsem v doméně cvut.cz a nabízí se mi možnost využívat jejich SIP Proxy, v tom případě by ale někdo měl vědět o mém novém SIP URI a zajistit přesměrování, viz. obr. 3.4 #1 INVITE sip:bob@vsb.cz #2302Moved Temporarily Obr Průběh přesměrování. Entita, která přijímá požadavek a odesílá zpět odpověď obsahující lokalizaci konkrétního uživatele se nazývá Redirect server. Redirect server přijímá požadavky a vyhledává zamýšlené příjemce v lokalizační databázi vytvořené registrar serverem. Následně vytváří seznam aktuálních lokalizací uživatele a posílá jej odesílateli požadavku v odpovědi zařazené do třídy 3xx. Odesílatel požadavku poté dostává seznam destinací a odesílá další požadavky přímo na ně. Obr. 3.5 ukazuje způsob přesměrování, Alice volá Boba a odeslaný INVITE přijme Redirect server, který zjistí, že Bob má nový kontakt a vrací odpověď 302 Moved Temporarily, ve které do pole contact zapíše SIP URI, na kterou je Bob přesměrován. Alice zasílá nový INVITE na URI z kontaktu předaného Redirect serverem a INVITE již s novou požadovanou URI se dostává na SIP Proxy sip.cvut.cz, kde už o Bobovi vědí a umí INVITE na něj přeposlat. 60

68 5 Základy protokolu SIP 3.3 SIP žádosti a odpovědi Komunikace v SIPu je tvořena zprávami, které jsou obvykle přenášeny v samostatných UDP datagramech. Každá zpráva obsahuje hlavičku zprávy (header) a může obsahovat vlastní tělo zprávy s popisem médií (body, většinou SDP), hlavička a tělo jsou odděleny volným řádkem (CRLF). generic-message = start-line *header fields CRLF [ message-body ] V prvním řádku zprávy je identifikován její typ. Známe dva typy zpráv, jednak žádost (neboli metoda) a jednak odpověď Základní popis SIP hlavičky typické žádosti Žádosti jsou obvykle užívány k registraci uživatele, sestavení, modifikaci či ukončení spojení anebo může jít o další služby (presence, instant messaging). Odpovědi jsou užívány k potvrzení přijetí žádosti a její vyřízení, obsahují konkrétní status. Typická SIP žádost vypadá následovně: Request-Line: INVITE sip: @asterisk.vsb.cz SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK9ec4c0248acd d7;rport From: "SJphone" <sip:7002@asterisk.vsb.cz>;tag=27df31582de To: <sip: @asterisk.vsb.cz> Contact: <sip:7002@ > Call-ID: C EB9B1443F8B448CC2830x9ec4c020 CSeq: 2 INVITE Max-Forwards: 70 User-Agent: SJphone/ a (SJ Labs) Content-Length: 321 Content-Type: application/sdp (v): 0 (o): IN IP (s): SJphone (c): IN IP (t): 0 0 (m): audio RTP/AVP (a): rtpmap:18 G729/8000 (a): rtpmap:3 GSM/8000 (a): rtpmap:8 PCMA/8000 (a): rtpmap:0 PCMU/8000 První řádek nám říká, že se jedná o zprávu INVITE, jež je užívána k sestavení spojení. URI na prvním řádku sip: @asterisk.vsb.cz se nazývá Request URI a obsahuje URI 61

69 5 Základy protokolu SIP dalšího skoku zprávy (next hop, směruje se dle RURI). V tomto případě bude hostitelem asterisk.vsb.cz a hledá se uživatel SIP žádost obsahuje v hlavičce jedno nebo více polí Via, jež jsou použity k záznamu cesty žádosti. Následně jsou užívány ke směrování SIP odpovědí přesně takovou cestou, jakou byly odeslány. Naše INVITE zpráva obsahuje jedno pole Via, to bylo vytvořeno UA, který odeslal žádost. Z pole Via můžeme říct, že odpověď bude doručena UA na IP adresu a port Pole hlavičky From a To identifikuje iniciátora volání (volající) a příjemce (volaného). Pole From obsahuje parametr tag, který slouží jako identifikátor dialogu a bude popsán později. Pole hlavičky Call-ID je identifikátor dialogu a jeho cílem je identifikovat zprávy náležející jednomu volání. Takovéto zprávy mají stejný identifikátor Call-ID. V rámci dialogu jsou jednotlivé žádosti očíslovány v poli CSeq. Protože žádosti mohou být odeslány nespolehlivým přenosem, může docházet k opakováním a pořadové číslo je nutné, aby příjemce mohl detekovat opakování a správně tak selektovat žádosti. V SIP hlavičce je dále pole Contact obsahující IP adresu a port, na kterém odesílatel očekává další žádosti odesílané volaným, obě strany si vymění své kontakty v žádosti a odpovědi a pokud bude chtít jedna ze stran poslat další požadavek, např. ukončení spojení BYE, tak nemusí posílat žádost na SIP Proxy, ale pošle ji přímo. Samozřejmě že je možnost ovlivnit i cestu dalších žádostí v dialogu, ale to si vysvětlíme v dalších kapitolách. Hlavička zprávy je oddělena od těla zprávy prázdným řádkem. Tělo zprávy žádosti INVITE obsahuje popis médií vyhovující odesílateli a kódované v SDP. Z SDP jsme se dozvěděli, kdo poslal nabídku SDP a na které IP má být tok médií ukončen. A co se týče vlastní nabídky, tak ta obsahuje čtyři kodeky seřazené dle preferencí G.729, GSM, PCM (A-law) a PCM (μlaw) SIP metody Žádosti neboli metody jsou obvykle užívány k inicializaci procedury (sestavení, aktualizaci či ukončení spojení). V jádru SIP protokolu je dle RFC 3261 specifikováno šest metod, které jsou následující: INVITE je žádost o inicializaci spojení nebo změnu parametrů již probíhajícího spojení (re- INVITE); ACK je metoda potvrzující přijetí konečné odpovědi na žádost INVITE. Sestavení relace používá 3-way hand-shaking, volaný periodicky opakuje odpověď (např. 200 OK), dokud nepřijme ACK, což indikuje, že odpověď byla doručena. Metoda ACK má řadu výjimek v pravidlech gramatice SIPu, které budou zmíněny později; BYE je zpráva užívána k ukončení sestaveného spojení; CANCEL se používá ke zrušení sestavovaného spojení, když není sestaven dialog, volaný ještě nepotvrdil konečnou odpovědí žádost INVITE a volající chce zrušit sestavování spojení; REGISTER je žádost registrace anebo odregistrování uživatele, sváže se logická jmenná adresa uživatele s jeho fyzickým umístěním (IP adresa a port), konkrétně jde o položky FROM a CONTACT ze SIP hlavičky. Registrace jsou časově limitovány a je nutné je periodicky obnovovat; 62

70 5 Základy protokolu SIP OPTIONS je speciální typ metody k zjištění vlastností SIP zařízení, má stejnou strukturu jako INVITE, ale spojení není sestavováno, pouze se přijme odpověď. Využívá se např. nejen ke zjištění podporovaných funkcí, ale SIP Proxy může periodickými dotazy zjišťovat mezi registracemi, zda SIP UA odpovídá a je dostupný anebo naopak SIP UA může periodicky posílat Options přes NAT k udržení záznamu překladu a tím pádem průchodnosti zvenčí. Kromě výše vysvětlených šesti základních metod existují i další žádosti, které byly definovány dodatečně v některých dalších RFC, viz. níže. Kupříkladu vyžadujeme-li funkcionalitu spolehlivé doručování dočasných odpovědí (PRACK), tak je nutné zjistit, zda konkrétní zařízení podporuje RFC Pro základní telefonii postačí RFC 3261, pro přehled si uvedeme seznam metod užívaných SIPem s odkazem na konkrétní RFC: sestavení relace INVITE RFC 3261, potvrzení na INVITE ACK RFC 3261, ukončení existující relace BYE RFC 3261, zrušení dosud nevyřízené žádosti CANCEL RFC 3261, registrace (svázáno s URI) REGISTER RFC 3261, získání schopností entity OPTIONS RFC 3261, Další metody, které nejsou v RFC 3261, jsou následující: přenos informací během relace INFO RFC 2976, potvrzení dočasné (1xx) odpovědi PRACK RFC 3262, přihlášení k upozornění na událost SUBSCRIBE RFC 3265, doručení o události NOTIFY RFC 3265, aktualizace stavu relace UPDATE RFC 3311, zprávy pro instant messaging MESSAGE RFC 3428, požadavek jiného UA k relaci REFER RFC 3515, aktualizace prezence PUBLISH RFC SIP odpovědi Jestliže UAS obdrží žádost, tak na žádost odesílá odpověď. Každá žádost musí být zodpovězena, výjimkou je metoda ACK, což je žádost, která má význam potvrzení doručení odpovědi na INVITE. Naproti tomu PRACK (Provisional Acknowledgement) se potvrzuje. Odpovědi jsou svou strukturou velmi podobné žádostem, kromě prvního řádku [col]. První řádek odpovědi obsahuje verzi protokolu (SIP/2.0) a kód odpovědi (reply code). Typická odpověď vypadá následovně: Status-Line: SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK9ec4c02048ace1a554;rport=5060 From: "SJphone" <sip:7002@asterisk.vsb.cz>;tag=164235a64f6 To: <sip:1194@asterisk.vsb.cz>;tag=as Call-ID: D73F3443CABCD68EE653C791C0x9ec4c020 CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 63

71 5 Základy protokolu SIP Contact: Content-Type: application/sdp Content-Length: 312 (v): 0 (o): root IN IP (s): session (c): IN IP (t): 0 0 (m): audio RTP/AVP (a): rtpmap:0 PCMU/8000 (a): rtpmap:8 PCMA/8000 (a): rtpmap:3 GSM/8000 Kód odpovědi je celé číslo z rozsahu 100 až 699 a označuje typ odpovědi. Celkem je definováno 6 tříd odpovědí, buď jsou informativní 1xx anebo finální 2xx-6xx: 1xx jsou dočasné informativní odpovědi, které jsou odesílány na žádosti, které byly přijaty, ale výsledek zpracování ještě není znám, na základě této odpovědi musí odesílatel zastavit opakování odesílání dané žádosti. Obvykle SIP Proxy servery odesílají odpovědi s kódem 100 (Trying), jestliže začínají zpracovávat INVITE a UA odesílají odpovědi s kódem 180 (Ringing), které oznamují vyzvánění volaného, kód 183 Session Progress má stejný význam jako 180, ale je doplněn o popis médií (SDP), 2xx jsou pozitivní finální odpovědi, je to poslední odpověď, kterou odesílatel na svou žádost dostává, vyjadřuje výsledek zpracování konkrétní žádosti. Odpovědi s kódy 200 až 299 oznamují, že požadavek byl akceptován a úspěšně zpracován, například odpověď 200 OK je vyslána, jestliže uživatel akceptuje žádost INVITE. V případě větvení zprávy INVITE můžeme dosáhnout několik UAS a každý z nich bude akceptovat žádost. V tomto případě je každá odpověď rozlišena parametrem tag v poli To. Každá odpověď probíhá v odlišném dialogu s jedinečným identifikátorem dialogu, 3xx odpovědi jsou užívány k přesměrování. Tyto odpovědi dávají informaci o nové poloze uživatele nebo alternativní službě, která má být použita. Pokud Proxy přijme žádost a nezpracuje ji z nějakého důvodu, tak vyšle volajícímu v odpovědi požadavek na přesměrování a vloží do odpovědi jiné umístění, které má být kontaktováno. Může to být jiná Proxy nebo aktuální umístění volajícího (z lokalizační databáze vytvořené registrar serverem). Volající následně znovu vyšle žádost na nové umístění, odpovědi 3xx jsou konečné, 4xx jsou negativní konečné odpovědi a znamenají problém na straně klienta. Žádost nemohla být zpracována, protože obsahuje chybnou syntaxi, 5xx znamenají problém na straně serveru. Žádost je zřejmě v pořádku, ale server selhal při zpracování, klient by měl obvykle požadavek zkusit znovu, 6xx představuje globální chybu a tento kód je vysílán, pokud žádost nemůže být splněna na žádném serveru, to je odpověď obvykle vysílaná serverem, když má informaci o konkrétním uživateli, např. UA vysílá 603 Decline response, když odmítá žádost o sestavení spojení, Kromě odpovědi odpovídající třídy obsahuje první řádka popis reason phrase, obsažený kód je určen ke zpracování, což je snadno analyzovatelné a popis jasně oznamuje výsledek. UA může popis zobrazit uživateli. Přiřazení žádosti k odpovědi je na základě pole CSeq v hlavičce, kromě 64

72 5 Základy protokolu SIP pořadového čísla obsahuje také metodu korespondující žádosti, v našem případě to byla žádost INVITE. Níže je uveden seznam odpovědí, se kterými se můžeme setkat v SIP protokolu: 1xx = informational responses * 100 Trying * 180 Ringing * 181 Call Is Being Forwarded * 182 Queued * 183 Session Progress 2xx = success responses * 200 OK * 202 accepted: Used for referrals 3xx = redirection responses * 300 Multiple Choices * 301 Moved Permanently * 302 Moved Temporarily * 305 Use Proxy * 380 Alternative Service 4xx = request failures * 400 Bad Request * 401 Unauthorized: Used only by registrars. Proxys should use proxy authorization 407 * 402 Payment Required (Reserved for future use) * 403 Forbidden * 404 Not Found: User not found * 405 Method Not Allowed * 406 Not Acceptable * 407 Proxy Authentication Required * 408 Request Timeout: Couldn't find the user in time * 410 Gone: The user existed once, but is not available here any more. * 413 Request Entity Too Large * 414 Request-URI Too Long * 415 Unsupported Media Type * 416 Unsupported URI Scheme * 420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server * 421 Extension Required * 423 Interval Too Brief * 480 Temporarily Unavailable * 481 Call/Transaction Does Not Exist * 482 Loop Detected * 483 Too Many Hops * 484 Address Incomplete * 485 Ambiguous * 486 Busy Here * 487 Request Terminated * 488 Not Acceptable Here * 491 Request Pending * 493 Undecipherable: Could not decrypt S/MIME body part 65

73 5 Základy protokolu SIP 5xx = server errors * 500 Server Internal Error * 501 Not Implemented: The SIP request method is not implemented here * 502 Bad Gateway * 503 Service Unavailable * 504 Server Time-out * 505 The server does not support this version of the SIP protocol * 513 Message Too Large 6xx = global failures * 600 Busy Everywhere * 603 Decline * 604 Does Not Exist Anywhere * 606 Not Acceptable INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: AG <sip:usera@here.com>;tag=123 To: BG <sip:userb@there.com> Call-ID: @here.com Cseq: 1 INVITE Contact: AG <sip:usera@here.com> Content-Type: application/sdp Content-Length: 147 v=0 o=usera IN IP4 here.com s=session SDP c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/ OK Via: SIP/2.0/UDP here.com:5060 From: AG <sip:usera@here.com>;tag=123 To: BG <sip:userb@there.com>;tag=65a35 Call-ID: @here.com Cseq: 1 INVITE Contact: BG <sip:userb@there.com> Content-Type: application/sdp Content-Length: 134 v=0 o=userb IN IP4 there.com s=session SDP c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Obr 3.5 Žádost a odpověď. Na obr. 3.5 jsou pole žádosti INVITE a konečné odpovědi na ni 200 OK, zobrazeny jsou i obsahy SDP, obě strany si vyměnily na sebe kontakty, nabídku SDP a odpověď na ní, použit bude kodek PCM G.711 µ-law Transakce Transakce jsou v SIPu velmi důležité pro tok zpráv a zacházení s nimi, neboť většina SIP prvků jsou transakční stroje. Ačkoliv bylo řečeno, že SIP zprávy jsou posílány sítí nezávisle, tak obvykle jsou uspořádány do transakcí agenty UA a stavovými SIP Proxy servery. 66

74 5 Základy protokolu SIP Obr Transakce v SIP protokolu. Transakce je sekvence SIP zpráv vyměňovaných mezi síťovými SIP prvky. Transakce obsahuje jednu žádost a všechny odpovědi vztažené k této žádosti. To může znamenat žádnou, jednu nebo i více dočasných odpovědí a jednu nebo více konečných odpovědí (např. při větvení v Proxy na zprávu INVITE ). Jestliže byla transakce zahájena žádostí INVITE, pak stejná transakce obsahuje i zprávu ACK, ale dle RFC 3261 pouze tehdy, jestliže finální odpověď nebyla třídy 2xx, potom ACK není součástí dané transakce. Důvodem je, že odpověď je zpráva 200 OK, viz. obr Jiná situace je po přijetí non-2xx odpovědi, např. 407 Proxy Authorization Required, pak by žádost ACK do transakce patřila a v poli branch byl stejný identifikátor jako u předešlých zpráv stejné transakce. Především UA jsou zodpovědní za opakování odpovědi 200 OK, dokud nepřijmou ACK. SIP entity, které sledují tyto transakce, se nazývají stateful, vytvořený stav k žádosti je spojován s transakcí a je držen po celou dobu trvání transakce. Pokud přichází žádost nebo odpověď, tak je zkoušeno vždy přiřazení zprávy do probíhající transakce. Aby tato operace byla proveditelná, tak musí ze zprávy přečíst jednoznačný identifikátor transakce a porovnat jej s identifikátory probíhajících transakcí. Jestliže takováto transakce existuje, tak dochází k jejímu doplnění o další informace. V předchozím SIP RFC2543 (SIP 1.0) byl identifikátor transakce odvozován jako hash z důležitých informací v hlavičce zprávy (zahrnující pole To, From, Request-URI a CSeq), což bylo komplikované a zpomalovalo zpracování a při testech interoperability bylo zdrojem problémů. V aktuálně používaném RFC 3261 (SIP 2.0) byl způsob výpočtu identifikátoru transakce zásadně změněn. Namísto komplikovaného určování z polí hlavičky teď obsahuje SIP zpráva identifikátor přímo v políčku Via s názvem branch. To je významné zjednodušení, ovšem stále existují staré implementace, které nepodporují nový způsob určování identifikátoru transakce, proto musí být určování zpětně kompatibilní s oběma verzemi, noví UA a SIP Proxy musí rozeznat i předešlý způsob, skutečnost v praxi je ovšem mnohdy jiná. Způsob nového určení transakce poznáme dle začátku řetězce z9hg4bk v branch identifikátoru pole Via. 67

75 5 Základy protokolu SIP branch=z9hg4bk9ec4c0248acd d7 Stavový transakční stroj okamžitě odpovídá 100 Trying na přijetí INVITE, čímž se potvrdí přijetí INVITE a zastaví se případné její opakování, pokud už odpověď 100 Trying byla jednou zaslána, tak se znovu nepřeposílá. Bezestavový stroj má jiné chování a přepošle vše, co dostane, neboť si nepamatuje stavy transakce. Rozdíl mezi SIP Proxy pracující s transakcemi nebo bez je vidět na obr Alice's UA Stateful Proxy Stateless Proxy Stateful Proxy Bob's UA INVITE 100 TRYING INVITE INVITE 100 TRYING 100 TRYING INVITE 100 TRYING 180 RINGING 200OK 180 RINGING 200OK 180 RINGING 200OK 180 RINGING 200OK ACK ACK ACK Media Session Obr Rozdílné zacházení se 100 Trying u stavových transakčních strojů Dialog V předchozím kapitole jsme si ukázali dvě transakce, viz. obr. 3.8, jedna transakce obsahovala zprávu INVITE a odpověď, druhá obsahovala zprávu BYE a následnou odpověď. Obě transakce však spolu souvisejí a náleží tak do jednoho dialogu, v první verzi SIPu RFC 2543 se používal pro dialog výraz call-leg. 68

76 5 Základy protokolu SIP Caller Callee INVITE 100 TRYING 180 RINGING Transaction#1 200OK ACK Dialog BYE 200OK Transaction#2 Obr. 3.8 Dialog. Dialog bychom mohli definovat jako soubor SIP zpráv peer-to-peer mezi dvěma UA, které mají vzájemnou spojitost. Dialogy popisují řazení a směrování zpráv mezi dvěma koncovými body. Dialogy jsou identifikované pomocí pole Call-ID, From (tag) a To (tag). Zprávy, které mají tyto tři identifikátory stejné, tak náleží jednomu dialogu. Ukázali jsme si, že pole CSeq je užíváno k řazení zpráv, je používáno k řazení zpráv uvnitř dialogu. CSeq číslo určuje transakci uvnitř dialogu, protože jsme řekli, že žádost a přidružená odpověď se nazývá transakce. To znamená, že v každém směru může být uvnitř dialogu aktivní pouze jedna transakce. Mohli bychom také tvrdit, že dialog je posloupnost transakcí. Pomocí CSeq snadno rozpoznáme zprávy dialogu. Dialogy usnadňují řízení komunikace, protože UA nedrží stavy dialogu. V uvedeném příkladu zpráva INVITE zahajuje dialog, neboť inicializuje spojení, všechny zprávy v tomto spojení patří do stejného dialogu, který je ukončen konečnou odpovědí na žádost BYE. Dialogy jsou vytvářeny generováním odpovědí typu non-failure (bez návratu chyby), pouze odpovědi typu 2xx a jsou schopny sestavit dialog, neboť vrací značku (tag) v poli To (To tag). RFC 3261 nepřináší zcela jednoznačnou definici, kdy je dialog přesně sestaven a proto rozeznáváme dva stavy: napůl sestavený (early dialog) a potvrzený dialog (confirmed dialog). Pokud se hovoří o dialogu, tak jde o potvrzený dialog, zatímco v prvním případě se vždy uvádí plně jako early dialog. Early dialog je sestaven dočasnou (non-final) odpovědí , potvrzený dialog je sestaven pomocí pozitivní konečné odpovědi 2xx. Dialog při typickém sestavení spojení projde prvním stavem, než je potvrzen. Všimněme si, že dočasná odpověď typu 100 TRYING neumožňuje sestavit early dialog a v této odpovědi se nepřidává To tag SIP časovače a retransmise Jelikož se v SIP signalizaci používá mnohdy nespolehlivý přenos (UDP), musí být ošetřeny retransmise žádostí v transakcích. Po odeslání žádosti INVITE klientem se zprávy v transakcích 69

77 5 Základy protokolu SIP opakují po dosažení časovače T1 a následně vždy po dosažení dvojnásobné doby od poslední retransmise, tzn. poprvé T1, podruhé 2*T1, dále 4*T1 a 8*T1. Základní časovač T1 je odvozen od RTT (Round Trip Time) a jeho výchozí hodnota je nastavena na 500 ms. Téměř všechny časovače jsou od T1 odvozeny a změna T1 se tak do nich promítá. Tab. 3.1 Časovače dle RFC Retransmise se neuplatňují při použití spolehlivého přenosu (TCP). Přijetí dočasné informativní odpovědi 1xx zastavuje retransmise žádosti INVITE a UAC musí čekat na přijetí dalších odpovědí. UAS může opakovat dočasnou odpověď 1xx před zasláním finální odpovědi, pokud se používá nespolehlivý přenos. Každá finální odpověď na INVITE je potvrzena ACK. Na straně UAC je dohlížen timeout transakce, žádná transakce by neměla trvat déle než 64*T1 (časovač B). Pokud vyprší časovač A, tak se provede retransmise a časovač se zvedne na 2*T1, pokud i tento čas vyprší, tak se zase zdvojnásobí. Níže jsou popsány časovače uvedené v RFC

78 5 Základy protokolu SIP Zabezpečení v SIPu Protokol SIP je přenášen jako otevřený text a je snadněji analyzovatelný než H.323, který je kódován v ASN.1 PER. Pro zachycení a nahlídnutí do SIPové komunikace nepotřebujeme analyzátory, vystačíme si např. s linuxovým příkazem ngrep. Principy způsobu komunikace v SIPu jsou podobné HTTP a díky této podobnosti se využívají stejné bezpečnostní mechanismy, které používá právě Hypertext Transfer Protocol [dor]. HTTP Basic Authentication je prvním mechanizmem, který zajišťuje autentizaci pomocí sdíleného hesla. Data nejsou šifrována a není také zaručena integrita zprávy, obsahuje pouze základní kódování schématem Base64. HTTP Digest Authentication vychází z předchozí metody s tím rozdílem, že místo přenosu otevřeného hesla ho šifruje pomocí hashovaní funkce MD5 nebo SHA. Ta funguje tak, že heslo vytvoří z náhodně generovaného řetězce, loginu a hesla. Tato metoda ověřuje autenticitu na základě sdíleného hesla. Obsah zprávy se však nijak nešifruje. Secure MIME (S/MIME) je, jak z názvu vyplývá, zabezpečení tzv. MIME (Multipurpose Internet Mail Extension). Konkrétně tato metoda zabezpečí obsah zprávy a zaručí i její integritu. Existuji dva způsoby šifrování obsahu dat MIME. První application/pkcs7-mime dokáže digitálně podepsat a zašifrovat data. Druhý způsob multipart/signed je podobný prvnímu s tím rozdílem, že zpráva obsahuje šifrovaná i nešifrovaná data. K ověření autentizace se používá architektura veřejných klíčů (PKI). Pro utajení obsahu zprávy jsou využity symetrické kryptografické primitivy (DES, 3DES, AES). SIPS URI (TLS) využívá architekturu veřejných klíčů pro ověření autentizace. Při použití této metody se mění prefix identifikační hlavičky na sips. Aby byla zaručena bezpečná komunikace, používá tato metoda šifrovaný protokol Transfer Layer Security (TLS). Tento protokol využívá asymetrické šifrování (RSA), symetrické algoritmy (DES, 3DES, AES) a hashovací funkci. Při použití této metody je kladena podmínka, že protokol TLS je použit na celé cestě zprávy a pro SIP musí být použit protokol TCP. Princip používané metody HTTP digest bude prakticky vysvětlen v následující kapitole zabývající se registrací, u registrace se neautentizovaná zpráva REGISTER odmítá pomocí 401 Unauthorized, v případě INVITE je to 407 Proxy Authentication Required, následně se pošle REGISTER nebo INVITE s autentizačním řetězcem, který je ověřen. Pokud je použito TLS, tak další autentizace pomocí HTTP digest je zbytečná a nepoužívá se, neboť už sestavení TLS obsahuje jeden z kroků, u kterého se klient prokazuje certifikátem a zabezpečení je na mnohem vyšší úrovni. Řada aplikací volně dostupných na Internetu se dá použít buď ke generování útoků, odposlechu hovoru či modifikaci paketů spojení, proto je otázka zabezpečení nejen signalizace, ale i vlastního hovoru velmi důležitá, což je argument pro použití TLS. Například aplikace SCAPY umožňuje nejen prolomení základních způsobů zabezpečení, ale i modifikaci obsahu paketů v reálném čase. SIPp je open-source generátor provozu, pomocí kterého zvládneme připravit DoS (Denial of Service) anebo DDOS útok (distribuovaný DoS). Aplikace voipbot umí pět různých typů útoků a sipdump se sipcrack umožňují uhodnutí hesla v autentizací s MD5. Zajímavou aplikací s použitím pro testování výkonnosti SIP serveru anebo pro útoky je VoIPER. 71

79 5 Základy protokolu SIP 3.4 Registrace Při registraci se sváže User URI z pole From s Device URI z pole Contact hlavičky SIP. Pokud pole Contact hlavička žádosti Registrace neobsahuje, tak se z Registrar serveru ve 200 OK vrátí seznam platných registrací k SIP URI z pole From. Device URI nese IP adresu a port, na kterém je uživatel se svou SIP URI k dosažení, např. pro SIP URI sip:voznak@vsb.cz může být device URI sip:voznak@ :5060. Doba platnosti registrace je dána parametrem expires v hlavičce, tento čas je Registrar serverem upravován, pokud UAC v návrhu nezadá čas, který by ležel v povoleném intervalu mezi minimální a maximální dobou registrace na Registrar serveru. Pokud se pošle nulová hodnota doby registrace expires=0, tak to znamená zrušení registrace, viz. níže. Request-Line: REGISTER sip:cesnet.cz SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK-d8754zdf2acad8754z-;rport Max-Forwards: 70 Contact: <sip:voznak@ ;rinstance=45b13194f4a07bb>;expires=0 To: "voznak"<sip:voznak@cesnet.cz> From: "voznak"<sip:voznak@cesnet.cz>;tag= d Call-ID: MjY0YzU5OTdiMDYxNTI4YzgzNTIwYzE2NTUzNzgyZGM. CSeq: 5 REGISTER User-Agent: X-Lite release 1100l stamp Authorization: Digest username="voznak",realm="cesnet.cz", nonce="48ad92308a4f8ee", uri="sip:cesnet.cz",response="6e6f1ca5803c805ac885f8cb4a8a1df1",algorithm=md5 Content-Length: 0 Odregistrování všech lokalizací konkrétního URI uživatele se docílí tak, že do pole Contact se zadá znak * a zároveň s nulovou hodnotu do expirace expires=0. UA Registrar Server A@ B@ C@ REGISTER 401 UNAUTHORISED REGISTER with AUTH. 200OK Obr Registrace s autentizací. Nepochybně je žádoucí, aby se uživatel při registraci autentizoval. Předpokládejme, že uživatel obdržel důvěryhodným způsobem uživatelské jméno a heslo, které si uložil ve svém IP telefonu. SIP používá stejnou metodu autentizace jako HTTP, a to HTTP digest authentication. Metoda spočívá v tom, že obě strany, jak server tak i klient, mají sdílené tajemství (heslo) a pomocí daných vstupních parametrů je jednosměrnou funkcí vygenerován otisk (hash). Vlastnost jednosměrné funkce spočívá 72

80 5 Základy protokolu SIP v tom, že není možné z otisku zpětně získat vstupní proměnné funkce, přesněji řečeno pravděpodobnost získání vstupů je mizivá a otisk je jedinečný, tzn. neexistují dva stejné otisky pro různé vstupy hashovací funkce. Pokud hash zaslaná klientem bude souhlasit s řetězcem, který spočítal server, tak autentizace bude úspěšná a kladně tak vyřízena. Na obr. 3.9 je znázorněna výměna při registraci s autentizací. Žádost INVITE je odeslána bez autentizačních údajů na SIP Proxy, ta odmítá odpovědí 401 Unauthorized, v odpovědi posílá bližší informace k autentizaci. Klient akceptuje zaslané informace a vypočte hash, kterou zašle ve zprávě REGISTER, tentokrát je úspěšně autentizován a dostává 200 OK s potvrzením registrace. Status-Line: SIP/ Unauthorized Message Header Via: SIP/2.0/UDP :18188;branch=z9hG4bKd8754z-d8754z-;rport=33209 To: "voznak"<sip:voznak@cesnet.cz>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.10f8 From: "voznak"<sip:voznak@cesnet.cz>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 1 REGISTER WWW-Authenticate: Digest realm="cesnet.cz", nonce="48ad92c" Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Request-Line: REGISTER sip:cesnet.cz SIP/2.0 Via: SIP/2.0/UDP :18188;branch=z9hG4bK-d8bc45e75b347-;rport Max-Forwards: 70 Contact: <sip:voznak@ :18188;rinstance= > To: "voznak"<sip:voznak@cesnet.cz> From: "voznak"<sip:voznak@cesnet.cz>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 2 REGISTER Expires: 3600 User-Agent: X-Lite release 1100l stamp Authorization: Digest username="voznak",realm="cesnet.cz",nonce="48ad92c", uri="sip:cesnet.cz",response="1ca1df39a865353b cbdfbb062",algorithm=md5 Content-Length: 0 Na příkladu výše je odpověď 401 Anauthorized, která obsahuje v odmítnutí výzvu k autentizaci a podává klientovi realm a nonce pro hashovací funkci. Klient posílá žádost REGISTER znovu, ale tentokrát již s autentizačními údaji, je použit algoritmus MD5, pro hash se použije username, realm, nonce a password, což je sdílené tajemství. Výsledný hash je v poli response. 3.5 Směrování Zásadním problémem směrování je, jak z URI adresy určit cíl. SIP v tomto směru může využít buď DNS anebo statických směrovacích záznamů a dalších údajů lokalizace UA v databázi, do které se dostaly přes Registrar server. Pokud se cíl určí a spojení je uskutečněno, tak se objevují další zásadní otázky. Kudy budou směrovány další žádosti, zda by měla SIP Proxy být prostředníkem v komunikaci a zůstávat v SIP signalizační trase či nikoliv. 73

81 5 Základy protokolu SIP Noční můrou každého signalizačního protokolu je vznik nekonečné smyčky (zacyklení), v tomto ohledu má SIP dva silné nástroje. Prvním je detekce smyček pomocí branch parametru v poli Via, který si umí zapamatovat ovšem pouze stateful SIP Proxy, pomocí branch zjistí, že zpráva patří do jedné transakce a může tak limitovat počet zpráv v transakci. Druhým nástrojem je povinné pole Max- Forwards v SIP hlavičce, které se snižuje o jedničku na každém skoku (výchozí hodnota je obvykle 70), tzn. s každým průchodem přes SIP Proxy se hodnota sníží, až dosáhne 0, tak SIP Proxy odešle 483 Too Many Hops a zpráva zanikne. V obr je znázorněn tok zpráv v rámci jednoho SIP Proxy serveru, ze kterého je čitelná souslednost konkrétních žádostí a odpovědí. Směrování mezi SIP Proxy servery je obsahem dalších kapitol. Obr Tok SIP zpráv v rámci SIP Proxy Směrování dle RURI a Via Žádosti jsou směrovány dle prvního řádku (RURI) SIP metody a odpovědi na žádost dle prvního záznamu ve Via., viz. obr Alice volá Boba, odesílá se INVITE, původní SIP URI se zapisuje do pole To, kde je logická adresa příjemce AOR (Address of Record) a neměl by ho po cestě nikdo změnit. První řádek obsahující RURI (Request URI) může SIP Proxy změnit dle aktuálních směrovacích informací, INVITE nakonec zastihne Boba na sip:bob@pc42.cs.columbia.edu. Alicin UA zapisuje do pole Via na první řádek sám sebe (a.example.com nebo svou IP), každá další Proxy po cestě udělá to samé, opět se vepíše na první řádek, a tak INVITE, který dostane Bob, bude mít 74

82 5 Základy protokolu SIP čtyři záznamy ve Via, viz. obr Jelikož odpověď je směrována dle Via, tak prochází stejnou cestou jako žádost, každý první záznam je z Via odstraněn ihned po přijetí odpovědi SIP Proxy, a tak je aktuální informace ve Via vždy první. Jakmile si koncové komunikující strany vymění na sebe kontakty (pole Contact v hlavičce), tak další žádosti mohou být odesílány napřímo. Ovšem i tato cesta se dá ovlivnit, viz. další kapitola. bob_doe@yahoo.com bob@columbia.edu INVITE Via: a.example.com Via: y1.yahoo.com Via: a.example.com Via: a.example.com alice@example.com Via: y1.yahoo.com Via: a.example.com Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com Via: cs.columbia.edu Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com bob@pc42.cs. columbia.edu bob@cs.columbia.edu 200OK Via: cs.columbia.edu Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com Obr Směrování žádostí a odpovědí SIP trapezoid SIPu trapezoid je typickým příkladem směrování zpráv v SIPu, předpokládáme, že Alice (sip:alice@atlanta.com) volá Boba z jiné domény (sip:bob@biloxi.com). INVITE je zaslán na SIP Proxy domény atlanta.com, která vyhledá SIP Proxy obsluhující doménu biloxi.com a tam INVITE odešle, SIP Proxy domény biloxi.com zná umístění Boba a přepošle tedy INVITE Bobovi. Odpovědi jdou stejnou cestou jako žádost dle položky Via. ACK je další žádostí (potvrzení doručení finální odpovědi) a ta je zaslána přímo Bobovi dle pole Contact. Alice provede hovor s Bobem a relaci ukončí Bob odesláním žádosti BYE, která odchází na Alici přímo dle pole Contact. Tok zpráv připomíná geometrický útvar trapezoid, viz. obr Následně se podíváme do hlaviček SIP zpráv 75

83 5 Základy protokolu SIP při sestavení spojení a popíšeme si, jak prvky na trase pracují s vybranými položkami hlavičky (bez SDP, popis médií je obsahem samostatné kapitoly), budeme pracovat se stateful SIP Proxy. První řádek obsahuje Request-URI a tato URI je zapsána do pole To jako AOR, tam nebude měněna. Do Via se zapíše odesílatel a přidá branch pro identifikaci transakce, když se mu vrátí odpověď se stejným branch, tak ji zařadí do této transakce. INVITE INVITE Obr SIP trapezoid. Do pole From zapíše odesílatel svou logickou SIP URI (AOR), přičemž text před úhlovými závorkami se zobrazuje na displeji jako textová identifikace odesílatele. Do pole Contact zapíše odesílatel svou device SIP URI, na které je k zastižení. Je vytvořeno nové jedinečné Call-ID, pořadí transakce Cesq a za ním název metody, nakonec je v hlavičce odkaz na tělo SDP (v naší ukázce odebráno). INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 INVITE dorazil na SIP Proxy atlanta.com a jelikož je statefull, tak ihned odesílá 100 TRYING. Odpověď 100 TRYING obsahuje stejné hodnoty To, From, Call-ID, Cseq jako v přijatém INVITE. Parametr received je přidán do pole Via, kde SIP Proxy doplní stroj, ze kterého byla žádost přijata pc33.atlanta.com (může být i IP). 76

84 5 Základy protokolu SIP SIP/ Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Content-Length: 0 SIP Proxy atlanta.com najde SIP Proxy, která obsluhuje doménu biloxi.com, ve které je volaný Bob. Nejdříve zjistí, zda už nemá destinaci ve své lokalizační databázi a pokud ne, tak provede vyhledání v DNS (DNS lookup), bude se hledat SRV záznam, ten obsahuje identifikaci stroje, který poskytuje službu SIP v dané doméně. INVITE teď SIP Proxy přepošle na zjištěnou cílovou SIP Proxy, přičemž připíše parametr received do prvního záznamu ve Via, následně zapíše sebe jako první záznam ve Via a sníží hodnotu v položce Max-Forwards. Další položky SIP hlavičky zůstávají nezměněny. INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 INVITE byl přijat SIP Proxy biloxi.com, která ihned odesílá 100 TRYING, obdobně předchozím kroku je přidán parametr received do Via. jako v SIP/ Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Content-Length: 0 SIP Proxy biloxi.com vyhledává ve své lokalizační databázi záznam Boba, který byl vložen při registraci, v lokalizační databázi je device URI z pole Contact svázána s logickou URI sip:bob@atlanta.com. Proxy biloxi.com odesílá INVITE Bobovi, přičemž připíše received do prvního záznamu ve Via, následně zapíše sebe jako první záznam ve Via a sníží hodnotu v položce Max- Forwards, zbytek hlavičky nemění. INVITE sip:bob@ SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received=

85 5 Základy protokolu SIP Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= Max-Forwards: 68 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 Dále si ukážeme obsah odpovědi 180 RINGING odesílanou z Bobova UA. Bobův UA vyzvání a odesílá 180 RINGING, do hlavičky připíše received do prvního záznamu ve Via a přidává tag do pole To. Ačkoliv dialog není ještě sestaven, tak jsou už definovány všechny tři části, dle kterých se identifikuje (Call-ID, from Tag a to Tag). Do pole Contact zapisuje Bob svou device URI, na které je k zastižení, přičemž v příchozím INVITE získal kontakt na Alici. SIP/ Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 Contact: <sip:bob@ > CSeq: INVITE Odpověď 180 RINGING je přeposílána přes SIP Proxy Alici, přičemž každá SIP Proxy po přijetí smaže první řádek v pořadí ve Via, a přepošle na další stroj v pořadí ve Via, odpověď se tak postupně dostane až k odesílateli žádosti. Bobův UA vyzvání a na displeji zobrazuje text z pole From přijatý v INVITE, tzn. vidí na displeji nápis Alice. Po přijetí volání odesílá Bobův UA odpověď 200 OK s obdobnou konstrukcí jako 180 RINGING, akorát se posílá i SDP, což v ukázce teď není. Jelikož jde o odpověď finální, tak se ukončuje transakce mezi biloxi.com a Bobem identifikovanou branch=z9hg4bk4b43c2ff8.1, pořadí ukončené transakce je dané polem CSeq: INVITE. SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:bob@ > Content-Type: application/sdp Content-Length: 131 Přijatá odpověď 200 OK je přeposlána na SIP Proxy atlanta.com a ukončí transakci mezi biloxi.com a atlanta.com branch=z9hg4bk77ef4c se CSeq: INVITE. Nakonec je 200 OK přeposlána ze SIP Proxy atlanta.com Alici a ukončí na obou strojích transakci 78

86 5 Základy protokolu SIP branch=z9hg4bknashds8 se CSeq: INVITE. Alicin UA přestává indikovat vyzvánění a kontrolní vyzváněcí tón umlkne, Alice může začít mluvit. Dokud Bobův UA neobdrží žádost ACK, tak nebude mít jistotu, že odpověď 200 OK byla doručena a bude opakovaně odesílat 200 OK (retransmise). ACK žádost je zaslána přímo na Bobův UA a obchází obě SIP Proxy, k tomuto dochází, protože obě strany si uložily na sebe kontakty z pole Contact SIP hlaviček. Jelikož ACK nepatří do předchozí transakce, tak se vytvoří nový branch=z9hg4bknashds9, ale nezvedá se Cseq, neboť na žádost ACK není žádná odpověď a nevytváří tak novou transakci. Jedná se o stejný dialog, a tak se musí zachovat značky From tag, To tag a Call-ID. ACK sip:bob@ SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: ACK Content-Length: 0 Hovor ukončí Bob, zavěsí a jeho UA odesílá žádost BYE, opět přímo na Alici. Jedná o novou transakci, takže se zvedne Cseq a zachová se From tag, To tag a Call-ID (patří do dialogu). Po přijetí finální odpovědi 200 OK na BYE se dialog ukončí. BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: BYE Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: BYE Content-Length: Udržení SIP Proxy v signalizační trase V předchozí kapitole byly další žádosti v dialogu zasílány přímo mezi koncovými účastníky spojení a signalizace tak obcházela SIP Proxy. Nástrojem, který v SIPu umožní zachovat libovolný prvek v signalizační trase během celého dialogu, je pole Record-route SIP hlavičky pro uložení záznamu o cestě a pole Route, dle kterého se žádost směruje. 79

87 5 Základy protokolu SIP Do hlavičky žádosti INVITE se vloží pole Record-route obsahující záznam prvku, který chceme udržet v trase, tzn. že SIP Proxy do INVITE přidá sebe např. p1.atlanta.com a pokud INVITE prochází další SIP Proxy, která se chce udržet v trase, tak se opět zapíše do hlavičky jako např. p2.biloxi.com, v INVITE nám tedy přibude: Record-route: <sip:p2.biloxi.com;lr> Record-route: <sip:p1.atlanta.com;lr> Without record routing With record routing UA1 SIP Proxy UA2 UA1 SIP Proxy UA2 BYE 200OK BYE 200OK BYE 200OK Obr Rozdíl v komunikaci při použití Record-route pole INVITE dorazil cílovému příjemci, pokud je detekováno pole Record-route, tak UA si nastaví cestu odesílání žádostí dle seznamu URI v Record-route seřazeném tak, jak byly zapsány v přijatém INVITE. Poté UA zkopíruje Record-route položky do odpovědi 180 RINGING a ta putuje původnímu odesílateli INVITE, v odpovědi nikdo nesmí Record-Route změnit. Příjemce odpovědi si nastaví cestu odesílání žádostí dle seznamu Record-route v obráceném pořadí. Pro další krok, je nutné vysvětlit dva přístupy ke směrování SIP žádostí: Strict routing přepíše RURI (Request-URI, první řádek SIP žádosti) dle údaje v Route poli hlavičky, přepisuje RURI na každém skoku a prochází jen přes servery uvedené v Route poli hlavičky; Loose routing je metoda která se mnohem více užívá a její aplikaci vyjadřuje parametr lr v poli Record-Route či Route. V tomto případě se nepřepisuje RURI, ale žádost se směruje dle URI v Route poli hlavičky, na každém skoku se dané URI z Route hlavičky odstraní, až neexistuje žádné URI v poli Route a potom se odsměruje dle RURI. Další žádost (např. ACK) odešle UA tak, že sestaví Request-URI standardně z pole Contact v odpovědi na INVITE, ale vytvoří Route pole v hlavičce ACK, které bude obsahovat: Route: <sip:p1.atlanta.com;lr>, <sip:p2.biloxi.com;lr> Údaje byly získány v Record-route a pořadí bylo obráceno (jelikož údaje byly získány z odpovědi). Žádost je odsměrována dle prvního URI v route hlavičce. ACK tak dorazí na SIP Proxy p1.atlanta.com, kde je odstraněn první záznam v pořadí z pole Route a na další je ACK odesláno, a 80

88 5 Základy protokolu SIP tak dorazí na SIP Proxy p2.biloxi.com, kde je opět odstraněn první záznam v pořadí, a jelikož je Route pole prázdné, tak se dále směruje dle RURI. 3.6 SDP- protokol popisu relace SDP je Session Description Protocol, který obecně slouží k popisu kterékoliv relace a je se SIP signalizací velmi často používán. Používá se často se SIPem a proto se v souvislosti se SIPem objevuje označení SIP/SDP. SDP protokol prošel třemi zásadními verzemi: Session Description Protocol, RFC 2327 z roku 1998 je původní verze; Support for IPv6 in Session Description Protocol (SDP), RFC 3266 z roku 2002 je aktualizací RFC 2327 a rozšířením o IPv6; Session Description Protocol, RFC 4566 z roku 2006 je nahrazením obou předešlých, uvolněním RFC 4566 zastaraly obě RFC 2327 i 3266, ale je zde zpětná kompatibilita, tzn. že implementace dle RFC 4566 dokáže porozumět starším verzím. SDP se skládá z řádků obsahující text ve formě položek typ a hodnota oddělených rovnítkem, položky, u kterých je symbol *, jsou nepovinné: <type>=<value> Položky jsou rozděleny do třech skupin: Session description, popis relace, Time description, popis časování, Media description, popis médií. Následně si projdeme seznam položek SDP dle skupin uvedených RFC Skupina Session description obsahuje položky v,o,s,i,u,e,c,b,z,k,a, kde: v= (protocol version), vždy je nastaveno v=0, o= (owner/creator and session identifier), označuje iniciátora relace a má následující syntaxi: o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address> s= (session name), název relace, pole je povinné a nesmí být prázdné, často se do něj zadává mezera, pomlčka anebo tečka, i=* (session information), textová informace o relaci, u=* (URI of description), URI adresa odkazující na dodatečné informace k relaci, e=* ( address) p=* (phone number), kontaktní a tel.č., c=* (connection information - not required if included in all media), udává informace o připojovaném koncovém bodu relace ve formátu c=<nettype> <addrtype> <connectionaddress>, b=* (bandwidth information), informace o využívaném pásmu, 81

89 5 Základy protokolu SIP z=* (time zone adjustments), ošetřuje posuny času, dají se naplánovat opakované přechody letního a zimního času. k=* (encryption key), pokud je SDP transportován přes důvěryhodný transportní kanál, tak může být pole k využito pro zprostředkování výměny klíčů ve formátu k=<method>:<encryption key>, a=* (zero or more session attribute lines), rozšiřující atributy ve formátu a=<attribute>:<value>, např. a=recvonly. Skupina Time description obsahuje položky t a r, kde : t= (time the session is active), řádek specifikuje v relaci časové značky pro start a stop ve formátu t=<start-time> <stop-time>, pokud jsou značky nastaveny 0 0, tak jde o permanentní přehrávání relace, r=* (zero or more repeat times), časy opakování relace ve tvaru r=<repeat interval> <active duration> <offsets from start-time>, Skupina Media description obsahuje položky m, c, b, k, a, kde: m= (media name and transport address), SDP může obsahovat více m řádků, každý je chápán jako nabídka jednoho toku, který se udává ve formátu m=<media> <port> <proto> <fmt>, jako média se uvádí audio, video, text, application nebo message, port udává transportní port a fmt je popis formátu médií, c=* (connection information - optional if included at session-level), b=* (bandwidth information), k=* (encryption key), a=* (zero or more media attribute lines) Konstrukce položek SDP pro komunikaci SIP/SDP Povinnými položkami hlavičky SDP jsou řádku v, o, s, t, m : v=0 o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-addr.> s= název relace t= 0 0 m=m=<media> <port> <proto> <fmt> Popis médií v m řádku se obvykle doplňuje nepovinnými atributy, tyto atributy jsou specifikovány v dalších RFC a jde o tyto atributy: a=ptime:<packet time>, [RFC4566] a=rtpmap:<payload type> <encoding name>/<clock rate> <encoding parameters>, [RFC4566] a=orient:<orientation>, [RFC4566] a=framerate:<frame rate>, [RFC4566] a=quality:<quality>, [RFC4566] 82

90 5 Základy protokolu SIP a=fmtp:<format> <format specific parameters>, [RFC4566] a=maxptime:<maximum packet time>, RFC3267, RFC4566 a=curr:<precondition-type> <status-type> <direction-tag>, [RFC3312] a=des:<precondition-type> <strength-tag> <status-type> <direction-tag>,[rfc3312] a=conf:<precondition-type> <status-type> <direction-tag>, [RFC3312] a=mid:<identification-tags>, [RFC3388] a=rtcp:<port>, [RFC3605] a=crypto:<tag> <crypto-suite> <key-params> [<session-param>], [RFC4568] a=label:<pointer>, [RFC4574] a=floorctrl:<role>,[rfc4583] a=confid:<conference-id>, [RFC4583] a=floorid:<token>, [RFC4583] a=content:<mediacnt-tag>, [RFC4796] Uvedené atributy jsou použity výhradně pro média, dále existují atributy relace, které neuvádím, neboť v SIP/SDP se s nimi nepotkáme, ale ještě máme atributy používané na obou úrovních, jak pro popis médií, tak i relace, a ty si uvedeme: a=recvonly, [RFC4566] a=sendrecv, [RFC4566] a=sendonly, [RFC4566] a=inactive, RFC3108, RFC4566 (and used in RFC3264) a=sdplang:<language tag>, [RFC4566] a=lang:<language tag>, [RFC4566] a=maxprate:<packet-rate>, [RFC3890] a=setup:<role>, [RFC4145] a=connection:<conn-value>, [RFC4145] a=key-mgmt:<prtcl-id> <keymgmt-data>, [RFC4567] a=source-filter:<filter-mode> <filter-spec>, [RFC4570] a=fingerprint:<hash-func> <fingerprint>, [RFC4572] Níže je uveden příklad obsahu SDP připojeného k SIP žádosti INVITE, ve kterém jsou nabídnuty dva RTP toky. První je audio s preferencí kodeků PCM µ-law, A-law, GSM, ilbc a G.729, GSM, očekávaný na portu a druhý tok je video H.263 na portu 15014, oba toky mají být zakončeny na IP INVITE sip:7002@ SIP/2.0 (SIP hlavička, volný řádek a SDP) v=0 o=root IN IP s=session c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 ilbc/8000 a=rtpmap:18 G729/

91 5 Základy protokolu SIP a=fmtp:18 annexb=no a=silencesupp:off m=video RTP/AVP 34 a=rtpmap:34 H263/90000 Odpověď přišla v SDP připojeného k odpovědi 200 OK na INVITE. Druhá strana sděluje, že naslouchá G.729 na portu a IP a druhý m řádek s videem H.263 je vrácen s portem 0, což znamená odmítnutí celého m řádku (toku), video tedy odesílatel SDP neumožňuje. SIP/ OK (SIP hlavička, volný řádek a SDP) v=0 o= IN IP s=sjphone c=in IP t=0 0 m=audio RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no m=video 0 RTP/AVP Offer/Answer model Vyjednávání probíhá v modelu označovaného jako Offer/Answer model specifikovaném v RFC RFC 3264 z roku Doporučení zavádí následující pojmy: Offerer, UA zasílající SDP jako požadavek na vytvoření či modifikaci relace, Offer, nabídka, kterou zasílá offerer, Answerer, UA přijímací SDP a zasílající na ní odpověď s popisem vlastních médií, Answer, je SDP odpověď na nabídku, Media Stream, je tok médií (např. video, audio,...), každý media stream je popsán konkrétním m řádkem a jeho přidruženými atributy. U SDP řádek s= (subject) nesmí být volný. Jelikož v SIPu relaci vytváříme a ukončujeme pomocí SIP signalizačních zpráv, tak nepoužíváme start a stop značky v SDP a relaci zde necháváme jako permanentní pomocí řádku t = 0 0. Pokud odešleme nabídku s SDP, tak dokud není zaslána odpověď, nesmí se odeslat další SDP nabídka, tzn. probíhá vždy pouze jedno vyjednávání. Jelikož offer/answer model je řízen protokolem vyšší vrstvy (SIP), tak musí být následující situace ošetřena na úrovni signalizace SIP: UA nesmí generovat novou SDP nabídku, jestliže přijal nabídku, kterou dosud nezodpověděl nebo neodmítnul; UA nesmí generovat novou nabídku, jestliže předtím odeslal nabídku a dosud neobdržel odpověď nebo odmítnutí. Přesto může dojít výjimečně k situaci, kdy jsou zaslány dvě nabídky (např. INVITE a re-invite v rámci offer/answer), tato situace se označuje jako SIP glare. Jestliže UAS obdržel druhý INVITE, když předtím odeslal v témže dialogu odpověď na první INVITE s nižším Cseq, tak musí vrátit 84

92 5 Základy protokolu SIP odpověď 500 Server Internal Error na přijatý druhý INVITE a do hlavičky odpovědi přidat pole Retry- After s náhodně zvolenou hodnotou v rozsahu 0 až 10. Jestliže UAS dostane INVITE v dialogu, v rámci kterého má nevyřízený INVITE (před chvíli sám INVITE odeslal a dosud nedostal odpověď), tak musí na přijatý INVITE vrátit odpověď 491 Request Pending. Nabídka buď neobsahuje žádný nebo obsahuje jeden anebo více média toků a každý je popsán v jednotlivém m řádku s přiřazenými atributy. Pokud neobsahuje žádný, tak si strana nabízející SDP přeje komunikovat později a až získá odpověď na nabídku, tak bude svou nabídku modifikovat (zašle novou). Pokud obsahuje více m řádků, tak každý musí popisovat jiný typ toku, neboť nelze žádat o vícenásobný tok stejného typu (paralell stream), typ toku je určen portem, profilem a kodeky, takže např. můžu si nechat poslat jeden šifrovaný tok a druhý nešifrovaný RTP či poslat jeden tok audio a druhý video. Na nabídku jednotlivých toků druhá strana odpovídá tak, že v odpovědi uvede na základě nabídky své typy toků (port, kodeky), v odpovědi je uveden stejný počet m řádků obsažených v nabídce a to i ve stejném pořadí. Nabídka toku může být odmítnuta z jakéhokoliv důvodu (nepodporovaný tok např. video), odmítá se konkrétní m řádek a to tak, že v odpovědi se v m řádku nastaví port na hodnotu 0. 85

93 6 Další metody rozšiřující SIP 4 Další metody rozšiřující SIP Jádro SIP protokolu v RFC 3261 z roku 2002 definuje šest základních žádostí, které jsme si již uvedli. V dalších letech ale vznikla nutnost definovat nové typy žádostí z důvodu podpory nových pokročilých služeb anebo jako vylepšení některé ze stávajících funkcí. 4.1 Metoda PRACK (Provisional Response Acknowledgement) Tato metoda je umožňuje potvrzování i dočasných informativních odpovědí. Jak známo, SIP potvrzuje finální odpověď na INVITE metodou ACK, čímž je zabezpečeno spolehlivé doručení obvykle odpovědi 200 OK, ve které je SDP s popisem médií. Pokud by bylo SDP připojeno např. k odpovědi 180 RINGING (častěji 183 Session Progress), tak vznikne potencionální problém na UDP, důležitá odpověď se může cestou ztratit a druhá strana nemá popis médií. SIP postrádal mechanizmus spolehlivého doručování dočasných odpovědí, a proto byla definována nová žádost PRACK (Provisional Response Acknowledgement) v RFC 3262, obr Na žádost PRACK se posílá odpověď (200). S metodou PRACK se často používá i časné zasílaní médií EM (Early Media).V roce 2004 bylo uvolněno RFC 3960 (Early Media and Ringing Tone Generation) v SIP protokolu. EM se vztahují k médiím (např. audio, video), které jsou vyměněny předtím, než je konkrétní relace akceptována volaným účastníkem (před přihlášením). EM mohou být jednosměrné, obousměrné a generovány jak volajícím, tak volaným či oběma stranami. Typickými příklady EM generovanými volaným jsou vyzváněcí tóny a ohlášení (např. čekání ve frontě Call Centra). Základní SIP specifikace RFC 3261 podporuje pouze velmi jednoduchý mechanizmus EM. RFC 3262 používá volitelnou značku 100rel a definuje PRACK metodu. UAS musí odesílat každou non- 100 dočasnou odpověď spolehlivě, jestliže původní žádost obsahuje vyžadované pole hlavičky se značkou 100rel. Jestliže UAS tak nemůže učinit, tak musí odmítnou žádost odpovědí 420 Bad Extension a zahrnout do ní do pole Unsupported obsahující značku 100rel. 86

94 6 Další metody rozšiřující SIP Použití PRACK při volání do PSTN Typickým příkladem použití pro PRACK je volání do PSTN, kdy již během vyzvánění mohou z PSTN přicházet informace, které se přehrávají volajícímu, např. volaný účastník právě hovoří, čekejte prosím. Obr. 4.1 Uplatnění PRACK při propojení s PSTN. 87

95 6 Další metody rozšiřující SIP Early Media SIP na rozdíl od jiných signalizačních protokolů neposkytuje EM indikátor (Early Media Indicator) a není zde tak informace o výskytu či absenci médií během sestavování spojení (například v ISDN je to Progress Indicator). Takovýto indikátor v SIPu by mohl být využitý k jasnému deklarování, zda má být generován lokální kontrolní vyzváněcí tón anebo druhá strana poskytuje in-band kontrolní vyzváněcí tón nebo nějakou ohlášku. Pravidla při sestavování spojení jsou následující: média jsou přehrávána před 200 OK, aby se zamezilo ořezávání prvních slabik hovoru označovaných termínem media clipping, užívá se offer/answer model k vyjednání parametrů relace, nabídka médií může být odeslána v INVITE žádosti a odpověď může dorazit ve 200 OK nebo případně, nabídka může být odeslána ve 200 OK v případě INVITE bez SDP a odpověď může být zaslána v ACK, pokud se používá PRACK ve spojení s metodou UPDATE, také existuje mnohem více možností, jak pro média vyměnit nabídku a odpověď, media clipping se vyskytuje, jestliže účastník spojení věří, že relace je již sestavena, ale proces sestavení spojení ještě není dokončen, potom prvních několik slabik nebo slov může být ztraceno, jestliže výměna v modelu offer/answer proběhne ve 200 OK odpovědi a ACK žádosti, pak je media clipping nevyhnutelný. Volaný účastník začíná mluvit ve stejný okamžik, kdy je odeslána odpověď 200 OK, ale tento UA nemůže zaslat žádná média, dokud nedostane odpověď na nabídku ve zprávě ACK. SIP User Agent (UA) by měl implementovat následující politiky vyzvánění: dokud odpověď 180 Ringing není přijata, nikdy negenerovat lokální vyzvánění, jestliže je přijato 180 Ringing, ale nepřicházejí žádné pakety s médii, pak se generuje lokální vyzváněcí tón, jestliže je přijato 180 Ringing a přicházejí pakety s médii, pak se negeneruje lokální vyzváněcí tón, ale přehrávají se přijaté média. Zajímavostí je pole Alert-Info v hlavičce SIP zprávy. Alert-Info dovoluje specifikovat alternativní obsah vyzvánění, např. zadáním URL nalinkuji kontrolní vyzváněcí tón umístěný v internetu. 4.2 Metoda UPDATE Metoda UPDATE je obsahem RFC 3311 z roku 2002 a dovoluje klientům aktualizovat parametry relace ale bez vlivu na stav dialogu. V tomto smyslu je metoda UPDATE podobná re-invite, ale na rozdíl od re-invite může být UPDATE poslán předtím, než je INVITE dokončen (víme, že na INVITE přichází finální odpověď, která je potvrzena ACK, tím je INVITE dokončen). UPDATE je tak velmi užitečný pro aktualizaci parametrů relace v rámci časně sestaveného dialogu (early dialog), tím pádem může volající či volaný modifikovat parametry relace, ještě než je volání vyzvednuto volaným. 88

96 6 Další metody rozšiřující SIP Re-INVITE nemůže být pro tento účel použit, protože re-invite má vliv na stav dialogu. Jestliže odpověď obsahuje v poli Allow hodnotu UPDATE, tak se UA dozví, že druhá strana UPDATE podporuje a může metodu použít. UPDATE může být použit jak pro early dialog, tak pro sestavené dialogy (potvrzené), ale po sestavení dialogu je doporučeno použít re-invite. Obr. 4.2 Příklad použití UPDATE. V příkladu, viz. obr. 4.2, je vidět INVITE s nabídkou SDP, která je zodpovězena ve 180. Protože je použito spolehlivé doručování PRACK s odpovědí 200 a následně jde nová druhá nabídka SDP ve zprávě UPDATE, dialog ještě není plně sestaven (pouze early dialog), tak nabídka je zodpovězena odpovědí 200. Dále je odeslána další již třetí nabídka SDP opět zodpovězená odpovědí 200 a jelikož byla v dalším kroku odeslána odpověď 200 na původní INVITE, tak je potvrzeno doručení přes ACK a dialog je sestaven. Pro další aktualizaci popisu médií by měl být použit re-invite. V případě, že UPDATE není na straně UA podporován, tak se musí použít re-invite, ale je nutné vždy čekat na sestavení dialogu. Využití UPDATE je v situacích, kdy je nutné změnit vlastnosti médií během sestavování spojení, např. volám-li přes GW do PSTN na fax, tak GW použije EM a zodpoví nabídku SDP pomocí odpovědi 180 nebo 183, ale následně se detekuje faxová komunikace (tón CNG na 1,1 khz vysílaný odesílatelem) a ještě během sestavování se může změnit kodek např. na G.711, čili se použije UPDATE. 89

97 6 Další metody rozšiřující SIP 4.3 Metoda REFER Metoda REFER je obsahem specifikace RFC 3515 z roku 2003 a umožňuje tzv. 3 rd party control, což je řízení komunikace třetí stranou. Toto rozšíření SIPu umožňuje odeslat žádost REFER příjemci, aby sestavil spojení s dalším UA a odesílatel žádosti REFER je informován o zpracování jeho požadavku. Toto rozšíření je využíváno např. pro realizaci služby Call Transfer (předání hovoru) či Click to dial (CTD, vytočení kliknutím na webu). Obr. 4.3 Použití REFER. Pro metodu REFER byla definována nová položka do SIP hlavičky, a to pole Refer-To indikující, na které URI má být sestaveno spojení, viz. níže, přičemž konstrukce SIP žádosti REFER je standardní a do Request-URI se zadává příjemce žádosti REFER. Refer-To: sip:alice@atlanta.example.com Jestliže nebyla na REFER generována žádná finální odpověď 4xx-6xx, pak UA musí vrátit odpověď 202 Accepted předtím, než vyprší REFER transakce. Pro informování odesílatele REFER o stavu vyřizování žádosti musí být použit mechanizmus NOTIFY. Příklad v obr. 4.3 ukazuje, že žádost zaslaná agentem A na agenta B je potvrzena pomocí 202 Accepted a agent A je informován v žádosti NOTIFY o stavu vyřizování požadavku. Mezitím agent B sestavuje spojení dle Refer-To. Postup s obsahem prvních třech zpráv je uveden níže. 90

98 6 Další metody rozšiřující SIP Message One (F1) REFER SIP/2.0 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hg4bk To: From: Call-ID: CSeq: REFER Max-Forwards: 70 Refer-To: (whatever URI) Contact: Content-Length: 0 Message Two (F2) SIP/ Accepted Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hg4bk To: <sip:b@atlanta.example.com>;tag= From: <sip:a@atlanta.example.com>;tag= Call-ID: @agenta.atlanta.example.com CSeq: REFER Contact: sip:b@atlanta.example.com Content-Length: 0 Message Three (F3) NOTIFY sip:a@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hg4bk9922ef To: <sip:a@atlanta.example.com>;tag= From: <sip:b@atlanta.example.com>;tag= Call-ID: @agenta.atlanta.example.com CSeq: NOTIFY Max-Forwards: 70 Event: refer Subscription-State: active;expires=(depends on Refer-To URI) Contact: sip:b@atlanta.example.com Content-Type: message/sipfrag;version=2.0 Content-Length: 20 Dále se začne sestavovat spojení agentem B tam, kam vedla URI adresa v poli Refer-To žádosti REFER zaslané agentem A. 4.4 Metoda MESSAGE (Instant Messaging) Metoda MESSAGE (Extension for Instant Messaging) je rozšířením SIP signalizace, které je obsaženo v RFC 3428 z roku IM (Instant Messaging) se vztahuje k přenosu zpráv mezi uživateli a navozuje se prostředí interaktivní komunikace (chat). Tyto zprávy IM komunikace jsou obvykle krátké, ale není to podmínkou. UAS přijímá žádost MESSAGE a okamžitě odpovídá konečnou odpovědí. To, že UAS odpověděl např. 200 OK (úspěšně přijato), však neznamená, že UAS přijatou zprávu zobrazil a už vůbec ne, že 91

99 6 Další metody rozšiřující SIP si ji někdo přečetl, je to pouze informace o doručení. Odpověd 2xx na žádost MESSAGE nesmí obsahovat tělo (SDP) a UAS nesmí vložit do odpovědi 2xx kontaktní pole SIP hlavičky Contact. Odpovědi 4xx nebo 5xx oznamují, že zpráva nebyla úspěšně doručena a odpověď typu 6xx znamená, že zpráva sice byla úspěšně doručena, ale byla příjemcem odmítnuta. Velikost žádosti MESSAGE nesmí překročit 1300 bajtů, větší obsah se dá přenést jako část média relace, tzn. např. textová relace s využitím SDP. MESSAGE nesestavuje dialog, jsou zde pouze transakce, není zde vytvoření a ani ukončení dialogu. Pokud nám druhá strana bude chtít na námi zaslaný obsah zprávy reagovat, tak rovněž pošle zprávu MESSAGE. Na obr. 4.4 je příklad odeslání žádosti MESSAGE přes Proxy. Obr. 4.4 Použití žádosti MESSAGE. Obsah žádosti MESSAGE je zobrazen níže, zpráva je zaslána jako text. MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hg4bk776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@ CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. 4.5 Metody SUBSCRIBE,NOTIFY,PUBLISH (Event/Notification) V roce 2002 bylo uvolněno RFC 3265 (Session Initiation Protocol Specific Event Notification), které přináší možnost požadovat zasílání oznámení při výskytu sledované události, schopnost tohoto oznamování je označována jako Event/Notification. Příkladem použití může být: 92

100 6 Další metody rozšiřující SIP služba zpětné volání, volaný je obsazen a po změně stavu (uvolnění) obdrží volající notifikaci, že je volaný volný a spojení se automaticky sestaví, buddy list, seznam kamarádů založený na přítomnosti-přihlášení (Presence), MWI (Message Waiting Indications), indikace nově zanechaného vzkazu ve schránce (RFC 3842). Subscriber Notifier SUBSCRIBE 200OK NOTIFY Request state subscription Acknowledge subscription Return current state information 200OK NOTIFY Return current state information 200OK Obr. 4.5 Příklad typického použití Event/Notification. RFC 3265 obsahuje dvě nově definované metody: SUBSCRIBE, metoda se používá k přihlášení a odběru sledovaných událostí, UA odesílající SUBSCRIBE následně dostává notifikace obsahující informace o stavech, které jej zajímají, v poli Expires se nastavuje, jak dlouho má UA notifikace dostávat a pokud chce UA ukončit odběr těchto oznámení, tak odešle opět SUBSCRIBE s nastavenou nulovou hodnotou hlavičky Expires=0, NOTIFY, metodou NOTIFY odesílá UA žádosti odběratelům stavů, kteří se přihlásili k zasílání upozorňování (přihlásili se pomocí SUBSCRIBE). Žádost SUBSCRIBE vytváří dialog a UA, který se přihlásil k odběru oznámení na sledovaný stav, může očekávat přijetí NOTIFY. Dokud nebyla doručena první žádost NOTIFY, tak UA by měl předpokládat neutrální stav a rovněž musí být připraven na situaci, že již před dokončením transakce SUBSCRIBE 200 OK může obdržet NOTIFY. UA zasílající SUBSCRIBE je rovněž odpovědný za obnovování přihlášení k odběru sledovaného stavu, tzn. před vypršením expirační doby znovu zašle SUBSCRIBE. V roce 2004 bylo definováno další rozšíření týkající se Event/Notification RFC 3903 (Session Initiation Protocol - Extension for Event State Publication), obsahem je definování nového mechanizmu s využitím metody PUBLISH. V RFC je definován vztah mezi EPA (Event Publication Agent), což je UA publikující stav a ESC (Event State Compositor), který je zodpovědný za 93

101 6 Další metody rozšiřující SIP zpracování stavů odesílaných z EPA. ESC je označován jako PA (Presence Agent). EPA zasílá stav prezence (publikuje) pomocí PUBLISH. Na obr. 4.6 je znázorněn tok SIP zpráv v mechanizmu Event/Notification s využitím metody PUBLISH. UA, který si nechává zasílat notifikaci na sledované stavy se označuje jako watcher a používá již vysvětlené metody SUBSCRIBE a NOTIFY. EPA ESC, PA Watcher SUBSCRIBE 200OK NOTIFY 200OK PUBLISH 200OK NOTIFY 200OK Obr. 4.6 Mechanizmus Event/Notification s užitím metody PUBLISH. Watcher inicializuje přihlášení k odběru zpráv presence z entity PA (Presence Agent) presentity@example.com s expirací 3600 sekund, což je první zpráva M1. SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hg4bknashds7 To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag= Call-ID: @host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Contact: sip:user@host.example.com Content-Length: 0 EPA posílá aktualizaci informací na PA pomocí PUBLISH, což je zpráva M5. PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hg4bk652hsge To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=1234wxyz Call-ID: @pua.example.com 94

102 6 Další metody rozšiřující SIP CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length:... Jelikož PA zjistil, že od EPA obdržel informace, které znamenají změnu presence, tak posílá pomocí NOTIFY oznámení se stavem nové presence na iniciátora sledování (watcher), což je zpráva M7, jejíž obsah je následně uveden. NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hg4bk4cd42a To: <sip:watcher@example.com>;tag= From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: @host.example.com CSeq: 2 NOTIFY Max-Forwards: 70 Event: presence Subscription-State: active; expires=3400 Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length:... Oblast Presence a IM je velmi zajímavá, ale SIP má zde velmi zdatné konkurenty v podobě protokolu XMPP (Extensible Messaging and Presence Protocol), který využívá např. Google Talk a Jabber. Rozšíření SIPu do oblasti IM a Presence nebude tak úspěšné a potenciál uplatnění připadá v úvahu pouze jako doplňkové služby pro telefonii. Nejpoužívanějším řešením pro IM je dnes Jabber. 4.6 Realizace vybraných doplňkových služeb v SIPu V následující kapitole se seznámíme s řešením několika vybraných doplňkových služeb pomocí SIP signalizace, bude se jednat o následující služby: síťování mezi SIP a PSTN, tady je nutné použít Early Media, paralelní vyzvánění (Forking), tato služba se týká především transakcí na SIP Proxy odesílající INVITE žádosti na více míst, tato SIP Proxy musí mít ošetřeny stavy rozjednaných transakcí tak, aby po přihlášení volaného došlo ke zrušení sestavování zbylých dialogů, přidržení hovoru (Call hold), v této službě jde o re-invite a úpravy toků médií na úrovni SDP, takže podstatné úpravy jsou učiněny v SDP, hudba při přidržení (Music on hold), je podobná přidržení hovoru s tím rozdílem, že je nutné zakončit tok médií na Music serveru přehrávající MoH, předání hovoru (Call transfer), dva přístupy k realizaci služby se řeší buď přes INVITE s namapováním médií mezi předávanými stranami anebo pomocí 3 rd party control, přesměrování volání (Call forwarding), služba se řeší na stateful SIP Proxy pravidly definujícími akce pro různé typy přesměrování, indikace zprávy (Message waiting indication), realizuje se s využitím Event/Notification, 95

103 6 Další metody rozšiřující SIP vytočení kliknutím (click to dial), služba je typickým příkladem řízení spojení třetí stranou, takže to je úloha pro 3 rd party control a tím pádem žádost REFER, zpětné volání (Call Back) se řeší pomocí EVENT/Notification. 4.7 Síťování SIP s PSTN V případě síťování SIP světa s PSTN se musí zabezpečit přenos kontrolních tónů či hlásek již během vyzvánění, každý se už jistě setkal s ohlášením volané číslo je nedostupné, zavolejte později anebo dovolali jste se do zákaznického centra společnosti... Obr. 4.7 Tok zpráv v síťování SIP a PSTN Tyto ohlášení pochopitelně nejsou generovány mobilním telefonem, ale jsou transparentně přenášeny PSTN sítí a již během vyzvánění je otevřen příslušný B-kanál v ISDN trasách, ve kterém se in-band přenášejí kontrolní tóny a ohlášení. SIP původně počítal s odlišným přístupem a mezi SIP účastníky stačí na přijetí 180 RINGING lokálně generovat nastavený kontrolní vyzváněcí tón (např. opakovat 425 Hz po dobu 1sek./4 sek. pauza). Řešením jsou Early Media a proto se nabídka SDP potvrdí už ve 183 Session Progress a minimálně směrem z PSTN je přenášen RTP tok, vždyť nakonec vlastnosti komunikace GW již předem zná, neboť ty jsou dány možnostmi GW (porty, kodeky) a nikoliv účastníka v PSTN. Komunikace na obr. 4.7 by se dala pochopitelně vylepšit o PRACK, který byl už rozebrán v předchozích kapitolách. 96

104 6 Další metody rozšiřující SIP 4.8 Paralelní vyzvánění - Forking Předpokládejme, že budeme mít uživatele, který se zaregistruje z několika zařízení pod stejným user URI (z telefonu z práce, domu či mobilu) a příchozí žádost INVITE rozešle SIP Proxy na všechny aktivní registrovaná zařízení, viz. obr. 4.8 Alice Stateful Proxy Bob@home Bob@work INVITE bob@proxy 180 Ringing 200OK INVITE INVITE 180 Ringing 200OK Contact: bob@home CANCEL bob@work ACK bob@work 180 Ringing Answered 200 OK(CANCEL) 487 Cancelled (INVITE) ACK bob@home Media session Obr. 4.8 Forking na SIP Proxy Tato funkce se označuje jako forking, není ji možné realizovat na stateless SIP Proxy, jelikož je založena na několika současně probíhajících transakcích a samozřejmě takováto Proxy není schopna tyto transakce sledovat. Na obr. 4.8 máme situaci, Bob je registrován pod user URI Bob@proxy na dvou device URI, a to Bob@home a Bob@work. Alice volá Boba a SIP Proxy odesílá INVITE na obě místa, z obou míst je odeslána odpověd 180 RINGING, což znamená, že došlo k paralelnímu vyzvánění. Bob přijal hovor na bob@home, SIP Proxy musí teď vytvořit novou transakci a zrušit sestavované a stále vyzvánějící 97

105 6 Další metody rozšiřující SIP volání na je tedy odeslána žádost CANCEL. Na CANCEL je odeslána odpověď 200 OK a původní transakce s INVITE je zodpovězena pomocí 487 Cancelled, což je potvrzeno metodou ACK. Mezitím SIP Proxy odeslala 200 OK z bob@home, kde je v poli contact uveden bob@home, díky tomu je další žádost ACK již přímo odeslána na kontaktní adresu a dialog je sestaven. 4.9 Přidržení hovoru - Call hold Máme sestaveno spojení, potřebujeme provést přidržení hovoru a po chvíli se vrátit zpět. Existují v zásadě dvě možnosti obě pomocí re-invite přes modifikaci v SDP, a to buď ukončit RTP tok a potom jej znovu navázat, tzn. m řádek v SDP anebo pomocí atributu sendonly, což je elegantnější, jelikož pouze změníme stav toku. Předpokládejme, že máme sestaveno spojení mezi Alicí a Bobem a Bob aktivuje službu Call Hold, Bobův UA odešle re-invite a v SDP nastaví atribut sendonly. INVITE sip:alice@u1.atlanta.ex.com SIP/2.0 From: Bob <sip:bob@biloxi.ex.com>;tag=b-tag To: Alice <sip:alice@atlanta.ex.com>;tag=a-tag Call-ID: ab-cid CSeq: 1 INVITE Contact: <sip:bob@u2.biloxi.ex.com> v=0 o=bob IN IP4 u2.biloxi.ex.com s=c=in IP IP4 u2.biloxi.ex.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly Alice na INVITE odešle odpověď 200 OK, k ní připojí SDP a vloží atribut recvonly. SIP/ OK From: Bob <sip:bob@biloxi.ex.com>;tag=b-tag To: Alice <sip:alice@atlanta.ex.com>;tag=a-tag Call-ID: ab-cid CSeq: 1 INVITE Contact: <sip:alice@u1.atlanta.com> v=0 o=alice IN IP4 u1.atlanta.com s=c=in IP IP4 u1.atlanta.ex.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly 98

106 6 Další metody rozšiřující SIP Relace je teď jednosměrná a Bobův UA neodesílá žádná média, pro obnovení se opět použije re-invite, tentokrát bez atributu, tím pádem se použije výchozí a=sendrecv a komunikace se obnoví Hudba při přidržení Music on Hold Hovor je sestaven mezi Alicí a Bobem, Bob aktivuje přidržení spojení s hudbou, Bobův UA posílá INVITE bez SDP na Music server. Odpověď 200 OK na Bobem zaslaný INVITE obsahuje SDP s atributem a=sendonly. Bob posílá re-invite Alici, kde v SDP použije a=sendonly a do řádku c uvede Music server jako adresu pro ukončení RTP toku, Alice potvrdí 200 OK a připojí své SDP s a=recvonly, Bob potvrdí přijetí 200 OK pomocí metody ACK a Alicino SDP připojí k žádosti ACK a zašle na Music server. Music server zasílá RTP tok na Alici, viz. obr Při vrácení z přidržení s hudbou k hovoru musí Bob nejdříve pomocí BYE ukončit spojení s Music serverem a potom pomocí re-invite obnovit spojení s Alicí. Obr. 4.9 Přidržení hovoru s hudbou 4.11 Předání hovoru - Call transfer Předání hovoru se může realizovat pomocí re-invite anebo pomocí REFER, ukážeme si oba způsoby, první způsob bude s využitím INVITE a jde o starší přístup. 99

107 6 Další metody rozšiřující SIP Alice Bob Veronika INVITE no SDP 200OKSDPa ACK SDPv Media session INVITE SDPa 200OKSDPv ACK Media session Obr Předání hovoru pomocí INVITE Na obr je první způsob, ve kterém Bob má sestavenou relaci s Veronikou a předává ji Alici. Jelikož nezná popis médií Alice, tak pošle nejprve INVITE bez SDP a získá nabídku médií Alice v SDP jako součást odpovědi 200 OK. Tuto nabídku SDP následně připojí k žádosti re-invite a pošle Veronice. Veronika odpoví 200 OK a připojí svou nabídku SDP, kterou Bob použije do žádosti ACK zasílané Alici jako potvrzení na přijetí 200 OK. Bob ještě zašle ACK Veronice a dialog je sestaven, přičemž Bob sloužil jako prostředník, přes kterého si vyměnily obě strany své SDP. Pochopitelně, že Bob do hlaviček v poli Contact uvedl obě nově komunikující strany, takže v tomto dialogu už nemá žádnou úlohu. Ve druhém případě na obr je použita metoda REFER, spojení je sestaveno mezi Alicí a Bobem. Alice pomocí REFER požádá Boba o sestavení spojení s Veronikou, když dostane potvrzení, tak pomocí BYE ukončí stávající spojení. Bob sestaví nové spojení s Veronikou a potvrdí přes NOTIFY Alici, že předání zdárně proběhlo. SDP s popisem médií se přenášejí standardně v INVITE a 200 OK. 100

108 6 Další metody rozšiřující SIP Obr Předání hovoru pomocí REFER 4.12 Přesměrování volání - Call forwarding Služba přesměrování volání je možná na Stateful SIP Proxy, na které jsou definovány pravidla ke stavům, které se v transakci při sestavování spojení mohou vyskytnout. Přesměrování můžeme rozdělit na následující typy: přesměrování při obsazení CFWB (Call Forwarding Busy), SIP Proxy při obdržení návratového kódu 486 vytvoří nový INVITE na definovaný cíl přesměrování, přesměrování při neohlášení (obvykle po čase sek.) - CFWNR (Call Forwarding No Reply), SIP Proxy sleduje dobu vyzvánění signalizované návratovým kódem 180 RINGING a po překročení hraniční hodnoty vytvoří nový INVITE na definovaný cíl, přesměrování nepodmíněné CFWU (Call Forwarding Unconditional), SIP Proxy zasílá INVITE přímo na zvolený cíl, přesměrování při nedostupnosti CFWNA (Call Forwarding Not Available). 101

109 6 Další metody rozšiřující SIP Přesměrování se obvykle označují zkratkou CFW (Call Forwarding), což je uvedeno i v seznamu výše, ale můžeme se setkat i s označením CD (Call Diversion). Z PSTN sítí je zažitější používání CFW, a tak nové označení CD se stejným významem může být pro někoho zavádějící. Na obr je situace při CFWB (přesm. při obsazení), jak již bylo zmíněno, tak na návratový kód 486 vytvoří SIP Proxy nové spojení odesláním INVITE. Alice SIP Proxy Bob Veronika INVITE Bob@biloxi 100 Trying INVITE Bob@ Busy Here ACK Bob@1.2.3 INVITE Veronika@ Ringing 200OK 180 Ringing 200OK ACK Veronika@3.4.5 Media session Obr Přesměrování při obsazení - CFWB 4.13 Indikace zprávy - Message waiting indication Signalizace zanechání vzkazu ve schránce hlasové pošty je založena na modelu EVENT/ NOTIFICATION, obr Zájemce o službu zasílá SUBSCRIBE na server hlasové pošty VMS (Voic Server), v notifikaci obdrží aktuální stav, v našem případě dvě nové zprávy z osmi uložených. Po zanechání nového vzkazu na VMS, bude server vždy oznamovat tuto událost pomocí NOTIFY, v našem případě Alice obdržela informaci, že má tři nové zprávy z celkových devíti uložených. Signalizace uložené zprávy je označována jako MWI (Message Waiting Indication) a zpráva NOTIFY by měla na telefonu Alice aktivovat rozsvícení LED diody tlačítka, po jeho stisknutí by se 102

110 6 Další metody rozšiřující SIP měl Alici zobrazit na displeji text upozorňující na nový vzkaz a ihned nabídnuto jeho vyzvednutí. Způsob ovládání telefonu už pochopitelně záleží na jeho výrobci, každopádně by měla být implementace jednoduchá, nejlépe rolovací menu nabízející položky dle pravděpodobnosti či četnosti použití a jednoduchý pohyb v něm pomocí tlačítek Vpřed/Vzad anebo dotekovým jezdcem (Touch Slider, kruhový pohyb/např. ipod anebo vertikální nahoru/dolů). Hlasová pošta může být propojena s ovou schránkou uživatele (odešle uložený vzkaz pomocí SMTP na daný ), který tak může dostávat vzkazy např. v mp3 formátu na svůj , případně naopak z u odesílat krátké vzkazy na telefon. Komunikace umožňující propojení různých systémů zpracování zpráv se označuje jako Unified Messaging. Alice VMS SUBSCRIBE Bob@vms Event: Message-summary 200OK NOTIFY Event: Message-summary VoiceMessage 2/8 Voic Server 200OK NOTIFY Event: Message-summary VoiceMessage 3/9 Event: someone leaves voic forbob 200OK Obr Oznámení o zanechání vzkazu - MWI 4.14 Vytočení kliknutím - Click to dial Další služba je založena na zprávě REFER, jelikož se jedná o sestavení řízení spojení stranou ( 3 rd party control). Webová aplikace bude obsahovat např. korporátní adresář, soukromé kontakty Alice anebo jen pole pro vložení jmenného identifikátoru (URI) či telefonního čísla, spojení je inicializováno z webu. Kliknutím na položku (CTD Click to Dial) jsou pomocí některé z metod (GET, POST) přes HTTP odeslána data k provedení volby na webový server, Alice volá Boba. Web server odesláním INVITE inicializuje spojení s telefonem Alice, Alice přijme volání, čímž odešle 200 OK a webový server na tento návratový kód odešle žádost REFER, kde do Refer-To vloží URI Boba. Žádost REFER je doručena Alici, jejíž telefon odpoví návratovým kódem 202 a zobrazí Alici na 103

111 6 Další metody rozšiřující SIP displeji informaci o zahájení spojení s Bobem, webová aplikace ukončí sestavené spojení s Alicí žádostí BYE a telefon Alice odesílá INVITE na Boba, obr Obr Vytočení kliknutím CTD 104

112 6 Další metody rozšiřující SIP Při implementaci této funkce je vhodné nastavit zpoždění cca 2-3 sek. mezi zobrazením informace na displeji Alice o sestavování spojení s Bobem a skutečným odesláním INVITE, Alice tak má možnost zavěsit. Pomocí REFER je realizována většina služeb CTI (podpora telefonování z PC), druhá možnost je použití INVITE a re-invite, ale tento přístup je zastaralý. Řada SIP telefonů podporuje XML, přes HTTP může přímo komunikovat s webovým serverem a integrovat do telefonie řadu zajímavých aplikací, které mohou být postaveny nad XML. Dokumenty XML mohou být zasílány i přes SIP žádosti NOTIFY a PUBLISH, avšak využití HTTP se zde jeví jako vhodnější. Dalším příkladem využití spolupráce SIP telefonu a webového serveru může být CRM (Customer Relationship Management), při příchozím volání se na základě identifikace volajícího vyhledají v databázi informace o volajícím a volanému se zobrazí webová stránka s informacemi o volajícím. Výsledkem je, že volaný má už během vyzvánění o volajícím informace, které může použít, položit mu otázky k autentizaci, atd... Informace o volajícím jsou využívány i ke směrování, ale to se týká jiné oblasti (call processing) a patří do problematiky Call center. Na základě identifikace lze například volajícího přepojit přímo na jeho osobního asistenta, na maďarsky hovořící operátorku anebo zařadit do fronty, kde bude čekat na obsloužení Zpětné volání Call Back Zpětné volání je typickou službou pro použití EVENT/Notification. Jak jsme si již vysvětlili v předchozích kapitolách, tak pomocí žádostí SUBSCRIBE a NOTIFY docílíme, že zájemci je zasláno oznámení při výskytu hlídané události (změna stavu). Na obr je zaslán INVITE, ale Bob je obsazen, odpověď je potvrzena přes ACK, ale telefon Alice podporuje zpětné volání a tuto funkci nabídne. Alice potvrdí, čímž se odešle SUBSCRIBE a jako sledovaná událost se uvádí event: call completion (dokončení volání), položka by měla být součástí nového návrhu RFC - Call Completion for Session Initiation Protocol (SIP), který se připravuje. Bob zavěsí a jeho UA ihned odešle NOTIFY, telefon Alice začne vyzvánět a po vyzvednutí odešle INVITE na Boba a dává Alici kontrolní vyzváněcí tón. Volání může být dokončeno ve stavu volno (CCNR Call Completion on No Reply) i obsazeno CCBS (Call Completion on Busy). Níže je obsah žádosti SUBSCRIBE. SUBSCRIBE sip:bob@example.org SIP/2.0 To: <sip:bob@example.org>; From: <sip:alice@example.org>;tag=2222 Call-ID: @phone.example.org CSeq: 1 SUBSCRIBE Contact: <sip:alice@example.org > Event: call-completion Expires:

113 6 Další metody rozšiřující SIP Obr Zpětné volání při obsazení 4.16 Metoda INFO Metoda INFO typicky obsahuje tělo zprávy, kde můžou být signalizační informace či události během relace. Metoda byla původně navržena s cílem přenášet z PSTN signalizační informace během sestaveného spojení jako ISUP (ISDN User Part) zprávy. Metoda INFO vždy inkrementuje CSeq. INFO sip:poynting@mason.edu.uk SIP/2.0 Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk ;branch=z9hg4bk24555 Max-Forwards: 70 To: John Poynting <sip:nting@mason.edu.uk> ;tag=3432 From: J.C. Maxwell <sip:james.maxwell@kings.cambridge.edu.uk> ;tag= Call-ID: e71facaa7f7c0a fe4951a9b6 Content-Type: application/isup 106

114 6 Další metody rozšiřující SIP Content-Length:... (tělo zprávy není zobrazeno) Původní specifikace INFO v RFC 2976 nemá žádné mechanizmy vyjednávání, jaký obsah v těle zprávy je akceptovatelný. V roce 2011 původní RFC 2976 bylo nahrazeno novějším RFC 6086, které je jednak zpětně kompatibilní se starším, ale hlavně obsahuje rozšíření chybějící vlastnosti pomocí pole Recv-Info v hlavičce deklarující, jaký obsah v INFO konkrétní UA podporuje. 107

115 8 SIPp a jeho použití k emulaci SIP relací 5 SIPp a jeho použití k emulaci SIP relací SIPp je nástroj pro emulaci SIP relací, obsahuje UAC a UAS, poskytuje statistiky o zprávách v SIP signalizaci, umožňuje rovněž emulovat i média, SIPp pracuje s audio či videem ve formě pcap. Jedná se o open-source aplikaci, která je velmi flexibilní a umožňuje vytváření různých scénářů v XML. Statistky, které jsou aplikací SIPp vytvářeny v reálném čase, poskytují informace o počtu sestavených volání, round trip delay a statistiky jednotlivých SIP zpráv, kromě zobrazení v okně terminálu, viz. obr. 4.1, lze tyto statistiky periodicky ukládat do CSV. Ve scénářích lze používat proměnné či regulární výrazy, což dává SIPp rozsáhlé možnosti Scenario Screen Port Total-time Total-calls Transport s 1814 UDP Messages Retrans Timeout Unexpected-Msg > INVITE < < > ACK E-RTD > BYE < [ 4000ms] Pause Sipp Server Mode Obr. 5.1 Statistiky v okně terminálu SIPp SIPp může být využit k testování reálných SIP zařízení jako SIP Proxy (např. Kamailio), B2BUA (např. Asterisk), SIP media servery, SIP brány and SIP PBX. Nástroj může být využit k emulování tisíců UA generujících relace do cílového zařízení. Kromě těchto výkonnostních testů lze využít SIPp využít i k testování interoperability, čili k ověření chování neznámého zařízení. 5.1 Instalace SIPp lze přímo instalovat z repozitářů většiny linuxových aplikací, např. pro Debian či Ubuntu lze najít SIPp pod balíčkem s označením sip tester. Nakonec SIPp je dostupný i pro MS Windows na URL 108

116 8 SIPp a jeho použití k emulaci SIP relací # apt-cache search sip-tester sip-tester - Performance testing tool for the SIP protocol Instalace je tedy záležitostí několik desítek vteřin, doporučuji předtím provést update pro získání aktuálních seznamů balíčků a můžeme instalovat apt-get install sip-tester. Po nainstalování se SIPp může okamžitě používat, ale ověříme si ještě verzi pomocí sipp-v. # apt-get update # apt-get install sip-tester # sipp -v SIPp v3.2-pcap, version unknown, built Nov , 11:30:21. Zjistili jsme, že máme verzi 3.2, která podporuje PCAP a tím pádem můžeme relace emulovat s reálnými médii (PCAP je podporovaný ve Wireshark, tzn. můžeme si takováto média extrahovat s reálného provozu a uložit RTP jako pcap soubor). Pokud bychom přece jen chtěli vyšší verzi (v roce 2013 byla dostupná v3.4), tak zkompilujeme. Pro v3.4 musíme před vlastní kompilací doinstalovat tyto balíčky: C++ Compiler curses nebo ncurses library pro TLS OpenSSL >= pro pcap play: libpcap and libnet # apt-get install gcc # apt-get install libncurses5-dev # apt-get install libssl-dev # apt-get install openssl # apt-get install libnet1-dev # apt-get install libpcap0.8-dev Stáhneme si aktuální balíček, rozbalíme a zkompilujeme s parametry pro podporu TLS --withopenssl a PCAP --with-pcap. # tar -xvzf sipp-xxx.tar.gz # cd sipp #./configure --with-pcap --with-openssl # make # make install 5.2 Scénáře pro SIPp SIPp umožňuje generovat jeden či více SIP relací na vzdálený systém. Nástroj je spuštěn z příkazové řádky. SIPp je možné ihned využívat s výchozím scénářem UAC a UAS např. pro zjištění, zda přes danu síť je možné realizovat SIP relace, nejdříve spustíme UAS [rez1]: # tar -xvzf sipp-xxx.tar.gz 109

117 8 SIPp a jeho použití k emulaci SIP relací # sipp -sn uas a poté UAC s výchozím XML schématem, což můžeme provést i na lokální rozhraní , port UAS je 5060 a UAC používá 5061 na stejné IP. #./sipp -sn uac Tento výchozí scénář obsahuje následující schéma, viz, obr 5.1, vzhledem k použití stejné adresy nám Wireshark nezobrazil správně orientaci odesílaných žádostí a přijatých odpovědí, ale pro prvotní odzkoušení funkčnosti SIPp nám můžou nakonec i postačit statistiky, kdy uvidíme, že nějaké žádosti byly odeslány a na ně přijaty odpovědi. V dalších příkladech s reálným nasazením mezi různými IP již bude výpis z Wireshark v pořádku, viz. obr Obr Výchozí scénář SIPp SIPp v příkazovém řádku Spuštění SIPp se provádí zavoláním aplikace sipp a přepínači s parametry. Mezi nejpoužívanější patří: -sd: výpis XML scénáře na obrazovku -sf : nahrání vlastního XML scénáře -sn : nahrání defaultního XML scénáře. (např. uac,uas) -t : nastavení transportního protokolu -u1,un,ui UDP protokol a nastavení počtu soketů, -t1,tn TCP protokol a nastavení soketů, -c1,cn UDP s kompresí -i : nastavení lokální IP adresy pro SIP hlavičku -p : nastavení lokálního portu pro SIP -v : zobrazení verze a dostupných funkcionalit -bg : spuštění SIPp v daemon módu -sleep : pozdržení startup času -lost : simuluje ztrátovost v nastavených procentech Další možnosti nám dávají následující volby používané pro bližší specifikaci generovaných relací: -aa : zapnutí automatické odpovědi 200 OK na zprávy INFO, UPDATE a NOTIFY -base_cseq : nastavení startovní hodnoty CSeq -cid_str : Nastavení hodnoty CallID 110

118 8 SIPp a jeho použití k emulaci SIP relací -d : nastavení délky audio streamu v milisekundách -au : nastavení username pro auth. Digest -ap : nastavení password pro auth. Digest -s : nastavení username v SIP hlavičce -r : nastavení počtu hovorů -rp : nastavení intervalu mezi hovory -l : nastavení maximálního počtu paralelně běžících hovorů -m : zastaví testování a ukončí sipp jakmile proběhnout všechny hovory Příkladem může být spuštění výchozího scénáře UAC #./sipp sn uac r 10 rp 1000 s [login] [server] Pomocí -sn uac vyvoláme výchozí scénář pro UAC, ve kterém bude generováno deset relací za periodu -r 10 a perioda potrvá 1000 ms -rp Username volaného uživatele se nastaví pomocí -s [login] a cílový server relace, kam budou zprávy zasílány je v [server]. Další příklad je s vlastním vytvořeným scénářem v XML souboru. Zavolání XML souboru uac_sipuri.xml, který si předem vytvoříme v adresáři, kde spouštíme sipp, následně provedeme pomocí -sf uac_sipuri.xml. Kde -r 500 -rp 1000 určuje násobnost 500 relací za periodu 1000 ms a voláme uživatele 6543 s 6543 na cílovém serveru iptel.org. #./ sipp -sf uac_sipuri.xml s r 500 -rp 1000 iptel.org Vytváření XML schémat Vytváření XML schémat á svá pravidla. Každé XML schéma začíná a končí značkou scenario. <?xml version="1.0" encoding="iso "?> <scenario name= Basic"> <!-- vlastní scénář --> </scenario> Příkazy, které používáme v XML jsou následující: <send> - Příkaz pro zasílaní SIP zpráv. <recv> - Příkaz pro příjem SIP zpráv. <nop> - Definování akce, která bude provedena (např. přehrání PCAP hlasového vzorku). <pause> - Definování zapauzování běhu scénáře. <sendcmd> - Zasílání příkazu pro scénář druhé strany. <recvcmd> - Definice akce při příchozím příkazu. <label> - Nastavení značek pro skoky ve scénáři. <globals> - Vytváří vlastních proměnných ve scénáři. Každý příkaz má své vlastní atributy, viz. URL: Příkladem je základní XML scénář, který vygeneruje nejprve zprávu INVITE s SDP obsahující nabídku kodeku G711ulaw. <?xml version="1.0" encoding="iso "?> <scenario name="basic"> 111

119 8 SIPp a jeho použití k emulaci SIP relací <send retrans="500"> <![CDATA[ INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user IN IP[local_ip_type] [local_ip] s=c=in IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 ]]> </send> Žádost INVITE je zaslána vzdálené straně a klient čeká na odpověď pomocí zpráv recv, přičemž přijetí zpráv 100 a 180 je volitelné, zatímco 200 je povinná a čeká se do expirace časovače (výchozí hodnota je 3000 ms): <recv response="100" optional="true"> </recv> <recv response="180" optional="true"> </recv> <recv response="200" rtd="true"> </recv> <send> <![CDATA[ Nyní se pošle žádost ACK signalizující potvrzení doručení finální odpovědi na žádost INVITE. ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 1 ACK Contact: sip:sipp@[local_ip]:[local_port] 112

120 8 SIPp a jeho použití k emulaci SIP relací Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]]> </send> V dalším kroku scénáře vložíme pauzu, která simuluje probíhající hovor, případně se může vložit akce pro přehrání skutečného audio souboru. <pause miliseconds "5000"/> <nop> <action> <exec play_pcap_audio="pcap/g711u.pcap"/> </action> </nop> Poté následuje ukončení hovoru pomocí zprávy BYE a očekávání odpovědi, scénář nesmíme zapomenout zavřít pomocí </scenario>. <send retrans="500"> <![CDATA[ BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 2 BYE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]]> </send> <recv response="200" crlf="true"> </recv> </scenario> Serverový scénář můžeme ponechat výchozí, čili spustíme pouze sipp -sn uas. Na straně generující relaci se přepneme do adresáře s vytvořeným scénářem, který jsem si nazval uac_basic.xml a spustíme jej na cílovou adresu, kde nám běží SIPp UAS. Namísto SIPp UAS se může jednat o skutečný server. Zachytíme relaci např. pomocí tcpdump anebo ngrep a zachycenou SIP relaci můžeme analyzovat Wiresharkem. # sipp -sf uac_basic.xml # tcpdump -w /home/voz29/trace8.pcap 113

121 8 SIPp a jeho použití k emulaci SIP relací Ověříme, že XML scénář se chová dle předpokladů, viz. obr. 5.3 Obr. 5.3 Výměna SIP zpráv v sestavené relaci Nyní se podíváme ještě na obsah žádosti INVITE, viz. obr. 5.4, kde vidíme, že je v souladu s očekáváním a její obsah je validní z pohledu RFC 3261 (jádra SIPu). Obr. 5.4 Zobrazení žádosti INVITE Pokud bychom přece jen chtěli sestavit vlastní UAS scénář, tak proměnné jsou podobné jako u klientského scénáře, podstatně ovšem jednodušší co do obsahu, jelikož se používá proměnná [last_*], která přebírá hodnoty polí z přijaté žádosti. Scénář začneme standardní hlavičkou, odpověď 100 vytvářet nemusíme a první zprávou tedy bude 180 Ringing, ve které otočíme přijaté hodnoty v jednotlivých polích, přidáme tag do pole To a vytvoříme obsah pole Contact, které obsahuje údaje o našem UAS. <?xml version="1.0" encoding="iso "?> <scenario name="basic UAS responder"> </recv> <send> <![CDATA[ SIP/ Ringing [last_via:] [last_from:] [last_to:];tag=[call_number] 114

122 8 SIPp a jeho použití k emulaci SIP relací [last_call-id:] [last_cseq:] Contact: <sip:[local_ip]:[local_port];transport=[transport]> Content-Length: 0 ]]> </send> Obdobně pokračujeme s 200 OK, kde přidáme SDP a použijeme kodek G711ulaw. <send retrans="500"> <![CDATA[ SIP/ OK [last_via:] [last_from:] [last_to:];tag=[call_number] [last_call-id:] [last_cseq:] Contact: <sip:[local_ip]:[local_port];transport=[transport]> Content-Type: application/sdp Content-Length: [len] v=0 o=user IN IP[local_ip_type] [local_ip] s=c=in IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 ]]> </send> Následně ve scénáři UAS ošetříme přijetí potvrzení ACK, na tuto zprávu nereagujeme. <recv request="ack" optional="true" rtd="true" crlf="true"> </recv> Nakonec vytvoříme odpověď na přijetí žádosti BYE a opět nezapomene scénář ukončit pomocí značky </scenario>. <recv request="bye"> </recv> <send> <![CDATA[ SIP/ OK 115

123 8 SIPp a jeho použití k emulaci SIP relací [last_via:] [last_from:] [last_to:] [last_call-id:] [last_cseq:] Contact: <sip:[local_ip]:[local_port];transport=[transport]> Content-Length: 0 ]]> </send> </scenario> Vkládání hodnot z externích souborů Do XML scénářů lze vkládat dynamicky hodnoty z externích souborů, tato funkcionalita se vyvolá pomocí příkazu inf název_souboru při spuštění SIPp. Například budu potřebovat volat různá tel. čísla s každým hovorem bez nutnosti parsovat XML scénář anebo měnit volajícího. V následujícím příkladu si ukážeme, jak lze měnit volajícího s každým hovorem. Vytvoříme si soubor.csv, kde první řádek značí, jak má SIPp soubor procházet SEQUENTIAL postupně, RANDOM náhodně, USER definováno uživatelem. Každý další řádek reprezentuje jeden hovor a může být rozdělen na několik proměnných pomocí ;. V našem příkladu jsou dvě proměnné [field0]; [field1]. SEQUENTIAL #This line will be ignored Sarah;sipphone32 Bob;sipphone12 #This line too Fred;sipphone94 Parametry řádků podporují klíčová slova v argumentu, ve spojení s vyhledáváním je možné vybrat hodnoty na základě vhodného klíče, viz. obr CSV soubor může obsahovat komentované řádky (ty se neberou v potaz a začínají symbolem "#"). SIPp podporuje SIP autentizaci, a to Digest/MD5 ("algorithm="md5"") a Digest/AKA ("algorithm="akav1-md5"", dle 3GPP pro IMS). Povolení autentizace je snadné. Při přijetí 401 (Unauthorized) nebo 407 (Proxy Authentication Required) se musí přidat auth="true" v příkazu <recv>, aby se autentizace vzala v úvahu, následně bude do další zprávy vložena autorizovaná hlavička hlavička použitím klíčového slova [authentication]. Použitím [authentication] bude vyvolána hashovací funkce a výsledek vložen do hlavičky. V závislosti na použití ("MD5" nebo "AKAv1-MD5") se používá buď Digest/MD5 (example: [authentication username=joe password=schmo]) anebo Digest/AKA: (example: [authentication username=happyfeet aka_op=0xcdc202d5123e20f 62B6D676AC72CB318 aka_k=0x465b5ce8b199b49faa5f0a2ee238a6bc aka_amf=0xb9b9]) 116

124 8 SIPp a jeho použití k emulaci SIP relací Obr. 5.5 Vazba klíčového slova v argumentu konkrétního pole SIP hlavičky na řádek v CSV souboru V případě, že chceme použít autentizaci s různými username/password pro každé volání, tak vytvoříme CSV soubor dle vzoru níže. SEQUENTIAL User0001;[authentication username=joe password=schmo] User0002;[authentication username=john password=smith] User0003;[authentication username=betty password=boop] Ve scénáři vytvoříme zprávu REGISTER, při provedení XML scénáře bude [field1] nahrazeno autentizačním řetězcem, který bude vytvořen jako nové klíčové slovo (hashovací funkcí MD5). <send retrans="500"> <![CDATA[ REGISTER sip:[remote_ip] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port] To: <sip:[field0]@sip.com:[remote_port]> From: <sip:[field0]@[remote_ip]:[remote_port]> Contact: <sip:[field0]@[local_ip]:[local_port]>;transport=[transport] [field1] Expires: 300 Call-ID: [call_id] CSeq: 2 REGISTER Content-Length: 0 ]]> </send> Nakonec vytvoříme čekání na odpověď. 117

125 8 SIPp a jeho použití k emulaci SIP relací <recv response="407" auth="true"> </recv> <send retrans="500"> Ovládání SIPp za běhu Aplikace SIPp může být interaktivně ovládána přes klávesnici nebo přes UDP sokety. Tzv. hot keys můžou být vyvolány kdykoliv a umožňují vyvolat i jednoduchý příkazový režim. Key Action + Increase the call rate by 1 * rate_scale * Increase the call rate by 10 * rate_scale - Decrease the call rate by 1 * rate_scale / Decrease the call rate by 10 * rate_scale c Enter command mode q Quit SIPp (after all calls complete, enter a second time to quit immediately) Q Quit SIPp immediately s Dump screens to the log file (if -trace_screen is passed) p Pause traffic 1 Display the scenario screen 2 Display the statistics screen 3 Display the repartition screen 4 Display the variable screen 5 Display the TDM screen 6-9 Display the second through fifth repartition screen. V příkazovém módu se mohou zadávat pouze následující příkazy, jejichž popis a příklad užití je uveden níže. Command Description Example dump tasks Prints a list of active tasks (most tasks are calls) to the error log. dump tasks set rate X Sets the call rate. set rate 10 set rate-scale X Sets the rate scale, which adjusts the speed of '+', '-', '*', and '/'. set ratescale 10 set users X Sets the number of users (only valid when -users is specified). set rate 10 set limit X Sets the open call limit (equivalent to -l option) set limit 100 set hide <true false> Should the hide XML attribute be respected? set hide false set index <true false> Display message indexes in the scenario screen. set display <main ooc> Changes the scenario that is displayed to either the main or the out-of-call scenario. trace <log> <on off> Turns log on or off at run time. Valid values for log are "error", "logs", "messages", and "shortmessages". set index true set display main set display ooc trace error on 118

126 8 SIPp a jeho použití k emulaci SIP relací Další tipy pro SIPp SIPp obsahuje podporu IPv6, k použití stačí specifikovat IP adresu pomocí přepínače i. V následujícím příkladu bude UAS naslouchající na portu 5063 a UAC bude na tento port generovat provoz. #./sipp -sn uas -i [fe80::204:75ff:fe4d:19d9] -p 5063 #./sipp -sn uac -i [fe80::204:75ff:fe4d:19d9] [fe80::204:75ff:fe4d:19d9]:5063 Pokud se používá "multi-socket" transport (více hovorů současně probíhajících), maximální počet soketů, který může být otevřen (koresponduje s počtem současných hovorů), bude dán systémem (limity se dají zvednout navýšením file deskriptorů cat /proc/sys/fs/file-max ). Rovněž se limit počtu užívaných soketů může nastavit přímo v příkazovém řádku pomocí -max_socket. V případě dosažení maximálního počtu soketů je provoz distribuován pouze přes již otevřené sokety. SIPp je původně generátor na signalizační úrovni a proto má omezenou podporu médií (RTP). Přece jen má jednu zajímavou funkcionalitu, a to "RTP echo", která umožňuje SIPp naslouchat na lokální IP a portu (specifikováno užitím přepínače -mi a -mp) RTP média. Cokoliv je přijato na této adrese/portu je také vráceno odesílateli (použitelné pro echo audia i videa). -mi : Set the local media IP address (default: local primary host IP address) -rtp_echo : RTP/UDP packets received on port defined by -mp are echoed to their sender. -mb : Set the RTP echo buffer size (default: 2048). -mp : Set the local RTP echo port number. Default is min_rtp_port : Minimum port number for RTP socket range. -max_rtp_port : Maximum port number for RTP socket range. -rtp_payload : RTP default payload type. -rtp_threadtasks : RTP number of playback tasks per thread. -rtp_buffsize : Set the rtp socket send/receive buffer size.echoed back to the sender. RTP streaming v SIPp "rtp_stream" podporuje strwming audia z kodeků PCMA, PCMU nebo G729, podporované akce jsou následující: <exec rtp_stream="file.wav" /> proběhne streaming audia z file.wav, formátu PCMA <exec rtp_stream="[filename],[loopcount],[payloadtype]" /> vyvolá streaming audia ve [filename], opakováno [loopcount] krát (výchozí hodnota je 1 a hodnota -1 indikuje nekonečné opakování), a zacházeno s audiem bude dle [payloadtype] (8 je PCMA, 0 je PCMU a 18 je pro G729). <exec rtp_stream="pause" /> přejde z aktivního přehrávání d pauzy. <exec rtp_stream="resume" /> bude pokračovat dále v aktivním přehrávání. 119

127 10 MGCP a IAX protokol 6 NAT vs. IP telefonie V této kapitole se budeme zabývat problematikou překladu adres NAT (Network Address Translation) z pohledu IP telefonie, seznámíme se s terminologií a klasifikací typů NAT a nakonec i se zajímavými protokoly STUN, TURN a ICE, které umožňující průchod přes NAT [sil1]. Překlad adres je důležitou vlastností směrovačů, používá se zejména ze dvou důvodů: omezit potřebný počet veřejných IP adres, s rozšiřováním IPv6 ztrácí tento důvod své opodstatnění, přesto ještě dnes dominuje IPv4, kde je obvyklé dokonce poskytovateli za přidělení veřejné adresy zaplatit, zvýšit bezpečnost podnikové či domácí sítě, skrytím vnitřních adres a jejich oddělením NAT prvkem je nejjednodušší způsob ochrany proti neoprávněnému vniknutí z vnější sítě). Zařazením NATu mezi vnitřní a vnější síť se automaticky vytvoří jednoduchý firewall a žádný počítač z vnější sítě nemůže kontaktovat počítač na vnitřní síti, dokud to neudělá tento počítač sám. Připojení vnitřní sítě LAN k internetu pak zajišťuje pouze jediná veřejná IP adresa. Ta je přidělena na externí WAN rozhraní směrovače. U odchozího spojení dochází k nahrazení zdrojové adresy z privátního rozsahu veřejnou IP adresou směrovače. Při příchozích spojeních zase dochází ke změně cílové adresy z veřejné na privátní. Těmito privátními adresami jsou rozsahy: Rozsah IP adres: , CIDR blok: /8 Rozsah IP adres: , CIDR blok: /12 Rozsah IP adres: , CIDR blok: / Terminologie Pod funkcí NAT rozumíme překlad adres mezi veřejným a privátním (neveřejným rozsahem). NAT pracuje v několika režimech [sin3]: Dynamický NAT mapuje vnitřní IP adresu na vnější IP adresu z nějaké skupiny IP adres (address pool). NAT Pool je seznam globálních adres na externím rozhraní, je to množina veřejných adres, které máme k dispozici při přístupu do vnější sítě WAN. Pokud se nějaké zařízení z vnitřní sítě pokusí odeslat paket na IP adresu ve veřejné síti, tak NAT přidělí první dostupnou IP adresu z NAT poolu a vytvoří se příslušný záznam v překladové tabulce, když 120

128 10 MGCP a IAX protokol přijde odpověď z veřejné IP zpět, tak NAT zkontroluje cílovou adresu, podívá se do překladové tabulky a zjistí, na které zařízení z vnitřní sítě má paket přeposlat. NAT rovněž vyměňuje IP adresy v IP hlavičce, pracuje na L3. Existuje doba životnosti (timeout), po kterém se záznam v překladové tabulce vymaže, díky timeoutu je umožněno obměňování IP adres. Statický NAT mapuje vnitřní IP adresu na vnější IP adresu. Statický NAT je používán pokud je zapotřebí přistupovat z vnější sítě do vnitřní. NAT, provádí se statický překlad jedné IP adresy vždy na tutéž IP adresu. Každá vnitřní IP adresa má pevnou externí veřejnou IP adresu, která je nastavena v NAT prvku. Překladová tabulka je tedy statická a v případě nějaké změny je potřeba ji upravit manuálně. Overloading (PAT) přetěžování, mapuje vnitřní IP adresy na jednu vnější IP adresu; bývá označován jako PAT; jedná se o formu dynamického NATu. V případě PAT dochází k překladu jak adres tak i příslušných portů, výhodou je, že za jednu externí IP adresu můžeme schovat celou řadu služeb, které jsou hostovány na různých serverech. Překladová tabulka je rozšířena o dvě položky: interní port, ze kterého byl paket odeslán a externí port, na který je paket odeslaný ze zdrojového portu mapován. NAT prvek v tomto případě pracuje na L3/L4 a vymění IP adresu i port v IP hlavičce paketu tak, jak to určuje překladová tabulka. Tento režim nejpoužívanější a prakticky se takřka vždy setkáme u NAT se změnou IP a portů. Mezi ajťáky se běžně používá i sloveso natovat, což zahrnuje právě překlad IP adres a portů mezi vnitřní a vnější sítí, kterou NAT odděluje. 6.2 Popis problému s průchodem SIP zpráv přes NAT Jak jsem si vysvětlili v předchozí kapitole, tak NAT pracuje s IP adresami a porty, v hlavičkách IP a TCP či UDP mění jejich hodnoty, ale SIP je aplikační protokol, který uvádí IP adresy a porty přímo v polích SIP hlavičky. Co se stane, když tyto hodnoty z interní sítě za NATem nebudou odpovídat hodnotám IP adres a portů ve veřejné síti před NATem? Situaci ilustruje obr Ačkoliv bylo NATem vytvořeno mapování mezi vnitřní privátní adresou s portem a vnější veřejnou adresou s portem a adresy i porty přepsány v hlavičkách IP a UDP, tak odpověď na SIP žádost zpět nedorazí, protože ze znalosti fungování SIPu víme, že odpověď putuje stejnou cestou jako žádost, a tato cesta je v polích Via, do kterých se zapíše nejdříve odesílající UAC a následně další SIP Proxy, které žádost přeposílají, jenže ve Via je neveřejná adresa , která ve veřejném prostoru IP adres neexistuje. Problémů je ovšem více, další neveřejnou IP nalezneme v SDP v řádku o (původce), c (IP, na kterou bude terminován RTP stream) a nakonec i port v m řádku bude jiný. Při registraci bude UA na REGISTRAR serveru zapsán na IP a REGISTRAR sever se na UDP ani nedozví, že jeho odpověď 200 OK nebyla doručena příjemci. Bez pomoci na straně klienta, serveru anebo přímo směrovači s NAT nebude možné SIP provozovat. 121

129 10 MGCP a IAX protokol Obr SIP zprávy přes NAT 6.3 Klasifikace typů NAT Obr znázorňuje situaci, kdy host X za NAT komunikuje s dvěma různými zařízeními host 1 a host 2. Pakety zasílané z X mají zdrojovou adresu a port X:x a cílová adresa a port Y:y, přičemž NAT má k dispozici IP adresy pro mapování X1, X2,... (nebo může mít pouze jedinou IP adresu X1=X2). Existuje několik variant překladu adres a portů: Full Cone NAT Restricted Cone NAT Port Restricted Cone NAT Symmetric NAT. Full Cone NAT (jedna k jedné) se chová tak, že všechny požadavky ze stejné vnitřní IP a portu jsou mapovány na stejnou vnější IP a port. Jedná se v podstatě o statické mapování. Restricted Cone NAT oproti předchozímu vyžaduje, aby nejprve vnitřní zařízení zaslalo paket externímu. Poté všechny pakety z tohoto vnějšího zařízení (i s odlišnými porty) jsou poslány na toto vnitřní zařízení. 122

130 10 MGCP a IAX protokol Port Restricted Cone NAT dovoluje na vnitřní zařízení doručit paket jen tehdy, pokud byl vnějšímu zařízení poslán paket z daného IP vnitřního zařízení a portu. Symmetric NAT funguje tak, že požadavky ze stejné vnitřní IP a stejného portu jsou mapovány na vnější IP a port pro danou komunikaci s externím zařízením. Pří komunikaci s dalším zařízením ze stejné vnitřní IP a stejného portu je vytvořeno odlišné mapování, přičemž původní je odstraněno. Obr Mapování v NAT 6.4 Provozování IP telefonie přes NAT Naštěstí existuje několik způsobů, jak zajisti podporu provozování IP telefonie přes NAT, ty lze roztřídit následovně: pomocí STUN (Session Traversal Utilities for NAT) dle RFC5389, bohužel nevyřeší problém NATu v případě Symmetric NAT pomocí TURN (Traversal Using Relays around NAT) dle RFC 5766, pomocí IEC (Interactive Connectivity Establishment) dle RFC 5245, pomocí rport (receive port parameter) dle RFC 3581, s pomocí překonání NATu na straně SIP serveru, kde je SIP Proxy doplněna RTP Proxy, Media Proxy anebo NAT helperem, podporou na routeru pomocí UPnP (Universal Plug and Play) anebo ALG (Application Layer Gateway). 123

131 10 MGCP a IAX protokol pomocí SBC (Session Border Controler), který se chová jako B2BUA (BAck to Back User Agent) s podporou SIP ALG. pomocí VPN, vytvořením šifrovaného tunelu STUN server STUN byl poprvé publikován jako RFC 3489 (Simple Traversal of UDP through NAT), výrazně byl rozšířen v RFC 5389 (Session Traversal Utilities for NAT). Základní myšlenka je znázorněna na obr. 6.3., STUN klient, který nezná použitou veřejnou adresu a port, odesílá žádost na STUN server umístěného ve veřejném IP prostoru a v odpovědi dostává požadovanou informaci, tu použije do SIP hlavičky a SDP těla odesílaných zpráv. Výhodou je podpora vícenásobných NATů, kdy STUN paket odeslaný klientem může projít několika NAT servery, než dosáhne STUN server a nakonec se dozvídá veřejnou IP adresu, se kterou byl požadavek na STUN server doručen. Právě tuto adresu SIP klient potřebuje znát k správnému vyplnění polí SIP zprávy (o výměnu IP adres na L3 a portů na L4 se postará NAT), čili prakticky všichni SIP klienti mají dnes v sobě integrovaného STUN klienta. Obr Mapování vnější veřejné IP a portu pomocí STUN protokolu Jednoduchý open-source STUN server je dostupný na URL (je dostupná i verze pro MS WIN), jedná se o balíček cca 150 kb obsahující server a klienta. Po instalaci je možné spustit STUN server příkazem stund a pokud máme na stroji dvě IP adresy, atk můžeme specifikovat pomocí přepínače h primární, pomocí a sekundární a nakonec pomocí přepínače b poběží na pozadí (background), primární IP používá port 3478 a sekundární 3479 (může sloužit jako backup). # apt-cache search stun stun - Server daemon and test client for STUN # apt-get install stun # stund -h a b 124

132 10 MGCP a IAX protokol STUN server version 0.96 Running with on interface :3478 with alternate :3479 Port 3478 for receiving UDP is in use Port 3479 for receiving UDP is in use Problémem STUN protokolu v SIP klientech pro překonání NATu je ovšem Symetric NAT, kde vnější přidělený port pro komunikaci se STUN serverem bude odlišný od mapování pro komunikaci s jiným zařízením (SIP serverem) Překonání NATu pomocí TURN, ICE a rport TURN (Traversal Using Relays around NAT) RFC 5766 je protokol, který umožňuje s využitím TURN serveru ve veřejné síti přijímat data zařízení za NATem, včetně symetrickým NATem. Využití je možné i pro IPv4 - IPv6 relay [sim], [sil2]. TURN relay server využívá významné zdroje stroje, na kterém běží, protože média jsou přenášeny přes TURN relay a tím pádem serverem prochází up a down stream (incoming + outgoing), oproti SIP klientovi dvojnásobné požadavky toku na pásmo. TURN server je vytěžován v závislosti na počtu současně probíhajících hovorů. Tím, že musí zpracovat a přeposlat každý paket, media relay rovněž zanáší zpoždění a vkládají další hop do trasy paketu, čímž zvyšují pravděpodobnost ztráty. Myšlenka je postavena na alokaci portu pro média na TURN serveru, viz. obr. 6.4, tím pádem SIP klient za NATem otevře trasu k TURN serveru pomocí TURN Allocate, poté komunikuje se SIP serverem, kde v SDP uvádí pro terminaci médií adresu TURN serveru, kterou dostal jako Relay address. Média přeposílá TURN relay na NAT, který ví, kam média přeposlat, jelikož SIP klient (resp. TURN client) již záznam pro překlad v NAT vytvořil. Tím je dosaženo průchodu i symetrickým NATem. Základní rysy TURN protokolu jsou následující: funguje i pro symmetric NAT, TURN klient inicializuje a udržují spojení na TURN relay, média procházejí přes TURN relay. je chápán jako rozšíření STUN Adresa alokovaná TURN serverem se nazývá Relayed address, viz. obr 6.4 a je použita pro RTP. TURN garantuje komunikaci ve všech případech použití NATu, pokud není cíleně zakázán politikou na firewallu. Nevýhodou ovšem je, že je v trase komunikace, má vysoké nároky na zdroje, pásmo a přináší další zpoždění. Co se týče posledně zmíněného, tento efekt se dá zmírnit tím, že TURN server bude co nejblíže NAT zařízení, tzn. provozován jako služba ISP poskytovatele. TURN relay server najdeme v balíčku rfc5766-turn-server, po instalaci okamžitě TURN běží jako služba, můžeme jej ovšem spustit i s volbou L naslouchající na konkrétní IP adrese. # apt-get install rfc5766-turn-server # turnserver stop 125

133 10 MGCP a IAX protokol : RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server : version Citrix 'Harding Grim' # less /etc/default/rfc5766-turn-server TURNSERVER_ENABLED=0 # turnserver L Obr Průchod IP telefonie s pomocí TURN serveru IEC (Interactive Connectivity Establishment) RFC 5245 je protokol vhodně využívající STUN a TURN. Koncepčně je poměrně jednoduchý, na základě analýzy sítě určí jednotlivé možnosti a vypočte priority jednotlivých kandidátů. Zdařilá implementace ICE kombinující STUN a TURN je v balíčku resiprocate-turn-server a je součástí většiny linuxových distribucí. Po instalaci ihned běží, což je možné ověřit přes netstat, lze ovšem i ručně nastavit IP adresy v konfiguračním souboru a poté službu restartovat. # apt-cache search resiprocate-turn-server resiprocate-turn-server - resiprocate SIP stack - ICE/TURN server 126

134 10 MGCP a IAX protokol # apt-get install resiprocate-turn-server # netstat -nlp grep returnserver # nano /etc/returnserver.config TurnAddress = AltStunAddress = AuthenticationRealm = osanet.cz LongTermAuthPassword = heslojeveslo # service resiprocate-turn-server restart Restarting TURN relay: returnserver. V RFC 3581 je definován nový parametr rport do pole Via hlavičky SIP, který umožňuje klientům zažádat SIP server o vložení zdrojové IP adresy a portu, ze které byla žádost obdržena, do Via. Následující INVITE byl poslán z IP adresy a zdrojového portu SIP Proxy je na IP (proxy.example.com) a poslouchá na standardním UDP INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP :4540;rport;branch=z9hG4bKkjshdyff UA posílá žádost INVITE přes NAT, která po průchodu NAT odchází z veřejné IP a zdrojového portu SIP Proxy přidává tyto informace do Via, tím pádem je možné doručit odpověď pomocí informací received a rport, pokud tedy Via obsahuje tyto hodnoty, tak odpověď je směrována na danou IP adresu a port. INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hg4bkkjsh77 Via: SIP/2.0/UDP :4540;received= ;rport=9988;branch=z9hG4bKkjshdyff Podstatnou výhodu má B2BUA, který má plnou kontrolu nad spojením včetně médií. V případ Asterisku (B2BUA) je nutné v jednotlivých konfiguračním souboru /etc.asterisk/sip.conf nastavit následující: nat = yes qualify = yes directmedia = nonat /* Asterisk ignoruje IP adresu (i port), kterou mu zasílá klient ve zprávě SIP INVITE v poli Contact a odpověď zasílá na stejnou IP adresu a port, odkud mu byla zpráva zaslána. /* dále je nutno udržet NAT mapování otevřené, Asterisk pravidelně každou minutu zasílá zprávu SIP OPTION. Od verze Asterisku lze změnit frekvenci opakování parametrem qualifyfreq. /* rovněž je nutné (není li použit STUN) zakázat pro klienty za NATem možnost re-invite. V IAX pak nastavit transfer = no (mediaonly). 127

135 11 Asterisk 7 Asterisk Asterisk je fenomén posledních let, to co představuje Apache v oblasti webových serverů, tak obdobné postavení má Asterisk v IP telefonii. Trend nasazování IP telefonie je dlouhodobý a telefonie se ocitá v roli aplikace na IP sítích. Alfou a omegou IP telefonie ve firemním prostředí je pobočková ústředna (PBX), v operátorském je to softswitch. V případě pobočkové ústředny se častěji mluví o komunikačním serveru, protože většina nasazovaných řešení PBX může sloužit jako aplikační server, překladová média brána či poskytovat podporu dalších služeb. V současné době nejrozšířenější volně dostupnou softwarovou realizací takové ústředny představuje produkt Asterisk od firmy Digium. V následujících kapitolách provedeme čtenáře jednotlivými konfiguracemi služeb, tak aby byl po přečtení textu schopen vytvořit fungující systém a infrastrukturu umožňující efektivní používání VoIP telefonie v praxi. Nejdříve ovšem pár vět k původu Asterisku. Při vzniku Asterisku byl Mark Spencer, čerstvý absolvent Auburn University v Alabamě, který se v roce 1999 rozhodl napsat pro linux svůj vlastní softvér realizující pobočkovou ústřednu s hlasovou poštou (voic ) namísto zakoupení komerčního produktu, údajně nebylo na PBX dost prostředků. Výstup své práce zveřejnil jako open-source a nabídl tím široké komunitě uživatelů, testerů i vývojářů. I was so excited the first time I got a phone call delivered through my PC using my own software. Mark Spencer Nevíme, nakolik je historka pravdivá, ale každopádně v roce 1999 vznikl jeden z nejvýznamnějších open-source projektů. Mark Spencer založil o tři roky později firmu Digium, která dlouhodobě stojí za vývojem Asterisku a protože SW Asterisk se prodávat nedá, tak její profit je z především z technické podpory a z prodeje HW, který je plně kompatibilní s Asteriskem, jedná se o Digium Cards jako je T1/E1/FXO/FXS. 7.1 Verze Asterisku Dnes je vývoj Asterisku z větší části záležitostí open-source komunity, na jeho kódu se podílí stovky vývojářů z různých částí světa, rychle se vyvíjí a pro řadu komerčních firem je velmi obtížné Asterisku konkurovat, většinou se nové funkcionality (jako např. webrtc) objeví nejdříve v Asterisku 128

136 11 Asterisk a až poté u komerčních produktů, pro něž je Asterisk velkou inspirací. Pro ilustraci vývoje si ukážeme aktuální roadmapu a podporu jednotlivých verzí Asterisku, viz. obr První použitelná verze s dlouhodobou podporou byla 1.2 uvolněná v roce 2005 následovaná verzí 1.4 z roku 2006, 1.6 z roku 2008 a 1.8 z roku Další vývoj již vidíme na obr. 7.1, došlo ke změně číslování ve verzích, verze Asterisk 10 byla uvolněna v roce 2011 a prakticky každý rok přichází další verze. Rovněž vidíme, že některé verze mají delší podporu (LTS Long Term Support). Během této podpory jsou zajišťovány opravy, jednak se korektury (patche) nabízejí přímo ke stažení a jednak se v rámci hlavní řady uvolňují další podverze (subversioning) a velmi snadno se dá provést upgrade, protože daná verze zachovává stejnou architekturu, strukturu souborů, notaci v konfiguracích a ve prakticky zapracovává patche, které vznikají v rámci dané řady, např. verze je z října 2010 a verze z prosince 2013 s řadou oprav. U nové verze jsou změny v architektuře, používají se jiné knihovny, zásadní změny v kódu již neumožňují záměnu konfiguračních souborů, např. ve verzi Asterisk 12 je zcela přepracován SIP stack (mimochodem je postaven na knihovně PJSIP) a změnila se i notace v konfiguračním souboru sip.conf pro SIP kanál. U LTS verzí je podpora ve formě vydávání dalších podverzí a patchů garantována po dobu alespoň čtyř let a repozitáře verze jsou udržovány ještě déle [md2]. Obr. 7.1 Roadmapa verzí Asterisku 7.2 Popis Asterisku Asterisk je open-source softwarová PBX určená pro instalaci na standardních PC a spolu se správným rozhraním může být použita jako PBX pro domácí uživatele, podniky, poskytovatele VoIP služeb a telefonní společnosti. Asterisk je rovněž open-source komunita a komerční produkt od firmy 129

137 11 Asterisk Digium. Systém je navržen tak, aby vytvořil rozhraní mezi telefonním hardwarem či softwarem a libovolnou telefonní aplikací. S jednotlivými protokoly SIP, IAX, H.323 pracuje Asterisk jako s kanály navázanými na jádro, DAHDI (Digium Hardware Device Interface) představuje rozhraní směrem k PSTN, může se jednat o ISDN BRI či PRI karty, FXS, FXO, apod, viz. obr 7.2. Příkazový řádek CLI je silným nástrojem Asterisku, stejně jako Manager Interface. Srdcem Asterisku je Dialplan, kde je definováno chování v případě obsluhy požadavku, ať už odchozího či příchozího volání anebo požadavku na vyvolání služby, viz. obr. architektury Asterisku. Obr.7.2 Architektura Asterisku Režimy Asterisku Jak již bylo naznačeno v úvodu, Asterisk může mimo jiné sloužit jako: Různorodá VoIP gateway mezi protokoly (MGCP, SIP, IAX, H.323). Pobočková ústředna (PBX). Voic služba s adresářem. Interaktivní hlasový průvodce (IVR server). Softwarová ústředna (Softswitch). 130

138 11 Asterisk Konferenční server. Packet voice server. Šifrovací médium telefonních nebo faxových volání. Překladač čísel. Aplikace Calling card, Prediktivní volič, Vzdálená kancelář pro existující PBX. A další... Asterisk také podporuje služby, které byly dříve součástí pouze pokročilých firemních řešení: Hudba pro zákazníky v pořadí čekající ve frontě na hovor, podpora streamování médií a MP3 souborů. Fronty volajících, kdy tým agentů může odpovědět na volání a může sledovat fronty (vhodné pro Call Centra). Integrace Text-to-speech modulů a rozpoznávání hlasu. Podrobné záznamy o hovorech jsou převáděny do textových souborů a SQL databází. Propojení s PSTN sítí skrze digitální a analogové linky Kodeky a protokoly Asterisku Obvykle je snaha, aby bylo možné v dané datové sítí realizovat co nejvíce hlasových spojení. Kodeky poskytují nové možnosti pro digitální přenos hlasu, včetně komprese, která je jednou z nejdůležitějších vlastností, mezi další vlastnosti patří detekce hlasové aktivity, vyrovnání paketové ztráty, a generování výplňového šumu. V Asterisku jsou podporovány následující kodeky s uvedenou šířkou pásma. Ty mohou být samozřejmě transparentně překládány z jednoho na druhý [md2]. G.711 ulaw (USA) - (64 Kbps). G.711 alaw (Europe) - (64 Kbps). G.722 (širokopásmový kodek 7 khz) (64 Kbps). G pouze pass-through režim G (16/24/32/40kbps) GSM - (12-13 Kbps) ilbc - (15 Kbps) LPC10 - (2.5 Kbps) Speex - ( Kbps) G.729 nutná licence (8Kbps) SILK nutná licence (superwideband 12 khz) Siren7 nutná licence, G.722.1, 7 khz Siren14 nutná licence, G AnnexC, 14 khz Kromě těchto audio kodeků je zde podpora videa h.263 a h.264. Odesílání dat z jednoho telefonu do druhého by mělo být snadné za předpokladu, že si data samy najdou cestu skrze síť. V praxi je nutné pro toto směrování využívat signalizační protokoly, dominantním a nejpoužívanějším signalizačním protokolem je SIP. Přesto existuje stále spousta systémů, které pro signalizaci ve VoIP síti využívají starších protokolů jako jsou např. H.323. Jiný protokol IAX je zase nativním 131

139 11 Asterisk protokolem Asterisku a výborně prochází NATem. Seznam podporovaných signalizačních protokolů v Asterisku je uveden níže: SIP H323 IAX2 MGCP SCCP (Cisco Skinny) Nortel unistim Jingle Služby Asterisku Asterisk nabízí množství doplňkových služeb, jak klasických, tak i pokročilých, které jsou obvykle poskytovány pouze špičkovými firemními PBX. Jako doplňkové služby a funkce si uvedeme následující příklady, výčet nemusí být úplný, ale i tak je docela obsáhlý: ACCOUNT CODE, používá se pro účely tarifování. Volající před volbou čísla vloží svůj kód. Do CDR (Call Detail Recording) se zaznamenávají údaje o délce hovoru, volaném čísle, ceně, atd... AUTOMATED ATTENDANT, volající je přepojen na požadovanou pobočku bez účasti spojovatelky. AUTOMATIC HOLD, pokud chceme provést hovor druhý hovor, tak můžeme inicializovat bez zavěšení předchozího a Asterisk první hovor automaticky podrží, přičemž se k němu můžeme zpětně vrátit. CALL TRANSFER, jedná se o předání hovoru. BLACKLIST, seznam nežádoucích čísel, které jsou jako příchozí hovory odmítnuty. BLIND TRANSFER, je předání hovoru na jinou pobočku bez sledování toho, zda hovor někdo přijme, hovor je předán i s vyzváněním. CALL DETAIL RECORD, záznam hovorů uskutečněných v PBX, který obsahuje volající číslo, volané číslo, datum, délku hovoru a případně další informace. CALL FORWARDING ON BUSY, příchozí hovor je automaticky přesměrován za podmínky, že je volané číslo obsazeno. CALL FORWARDING ON NO ANSWER, příchozí hovor je automaticky přesměrován jen tehdy, pokud volané číslo neodpovídá, tzn. po určitém čase. CALL FORWARDING UNCONDITIONALLY, jedná se o okamžité přesměrování bez podmínek. CALL MONITORING, evidence příchozích, odchozích a zmeškaných volání, přístup přes web, uživatel po autentizaci vidí seznam volání, které se týkají jeho účtu. CALL PARKING, odložení hovoru do virtuálního úložiště s možností jeho vyzvednutí stejnou nebo jinou pobočkou. CALL QUEUING, umožňuje řadit příchozí hovory do fronty a vyzvedávat je dalším volným účastníkem konkrétní skupiny. CALL RECORDING, umožňuje zaznamenávat hovory, zaznamenané hovory jsou uloženy v požadovaném formátu (např. PCM či GSM) a nabídnuty k přehrání oprávněnému uživateli, přihlášení probíhá přes https a po zadání hesla jsou nabídnuty pouze hovory týkající se konkrétní pobočky autentizovaného uživatele. 132

140 11 Asterisk CALL RETRIEVAL, funkce vyvolá osobu, která může převzít volání. CALL ROUTING, je provolení na pobočku (DDI Direct Dialing In, provolba). CALL SNOOPING, umožňuje odposlouchávat určenou skupinu telefonů. CALLER ID, je funkce zobrazení čísla volajícího a jména volajícího. CALLER ID BLOCKING, hovor je odmítnut na základě identifikace volajícího. CALL WAITING, je upozornění na čekající volání během sestaveného spojení, po jeho přijetí je možné střídání mezi oběma hovory. CALL ID ON CALL WAITING, je identifikace dalšího volajícího při probíhajícím hovoru. CONFERENCE BRIDGING. vytvoří konferenci mezi terminály různých typů jako lokální pobočkou, vzdálenou linkou, mobilním účastníkem, VoIP spojením, apod... DATABASE STORE / RETRIEVAL, ukládá informace o hovorech do DB pro pozdější využití. DATABASE INTEGRATION, Asterisk umožňuje poskytování informací o volajícím účastníkovi volanému před přijmutím volání nebo během hovoru. DIAL BY NAME, namísto čísla je možné volit i jméno (jako alias). DISTINCTIVE RING, jedná se o rozdílný typ vyzvánění založený na identifikaci volajícího. DUNDI (Distributed Universal Number Discovery), je distribuovaný systém směrování, který v síti Asterisků umožní jednak rozložení zátěže mezi různé servery a jednak zvýšení odolnosti při výpadku některého z Asterisk serverů (cluster několik Asterisků, které se navenek tváří jako jeden velký softswitch). DO NOT DISTURB, aktivací funkce nerušit je volání přesměrováno na ohlášení, spojovatelku nebo jinou pobočku, apod... ENUM, Asterisk podporuje vyhledávání telefonních čísel přes DNS, kde je realizováno mapování telefonních čísel na jmenné identifikátory (URI), pokud je spojení na vyhledanou URI adresu nedostupné, tak se použije další pravidlo (např. směrování přes PSTN). INTERACTIVE DIRECTORY LISTING, umožňuje volajícímu účastníkovi interaktivní vyhledání volaného podle jeho jména v korporátním adresáři. INTERACTIVE VOICE RESPONSE, IVR je pokročilý systém pro obsluhu příchozích volání,volající prochází hlasovým menu a pomocí volby čísel volí možnosti spojení. LOCAL AND REMOTE CALL AGENTS, účastník se může pomocí své identifikace přihlásit na kterékoliv telefonu a používat ho jako svůj vlastní (tzn. s vlastním číslem, nastavením služeb, atd.) MUSIC ON HOLD, hudba na přidržené lince, přičemž audio soubory lze vytvářet jednoduchým způsobem. PREDICTIVE DIALER, funkce je používaná odchozími centry volání, spojení se sestavuje na základě statistického modelu, který určuje, kdy bude volaná strana dostupná. PRIVACY MANAGER, jestliže je kód pro vzdálený přístup zablokován (viz. LOCAL AND REMOTE CALL AGENTS), potom ručním zadáním čísla Privacy Manager zkontroluje, zda je číslo na Black listu nebo White listu a podle toho volbu povolí nebo zamítne. PROTOCOL CONVERSION, umožňuje spojení mezi sítěmi používajícími rozdílné protokoly. REMOTE CALL PICKUP, umožňuje vyzvednout hovor, který vyzvání na jiné pobočce. REMOTE OFFICE SUPPORT, umožňuje přihlásit telefon z jiné PBX tak, že má vlastnosti lokální pobočky. ROAMING EXTENSIONS, jednotlivé osoby jsou vybaveny číslem pobočky a kódem, pomocí kterého se mohou přihlásit na kterémkoliv pobočkovém telefonu, tato služba je odlišná od LOCAL AND REMOTE CALL AGENTS tím, že číslo pobočky, pokud se zrovna nepoužívá, neexistuje v Dialplan. 133

141 11 Asterisk ROUTE BY CALLER ID, hovor je směrován na základě čísla volajícího na pobočku, do fronty nebo do skupiny účastníků (Ring Group). SMS MESSAGING, Asterisk umožňuje pomocí SMS upozorňovat např. zmeškaná volání a zanechané vzkazy, SMS se posílají přes SMS bránu (může to být GSM modem lokálně připojený k Asterisku). SPELL/SAY, funkce umožňuje přečíst text, např. . SUPERVISED TRANSFER, je předání volání řízené automatickým zařízením (např. Voice Response Unit), které vyhodnotí výsledek předání přijato, obsazeno, nevyzvednuto. TALK DETECTION, funkce umí detekovat hovor (rozezná záznamník od osoby). THREE-WAY CALLING, je konference tří účastníků, je možné ovšem dělat i konference o několika desítkách účastníků (na Asterisku otestováno do 30-ti) s využitím konferenční místnosti (Meet-Me). TIME AND DATE, funkce čte čas a datum volajícímu. TRANSCODING, Asterisk umožňuje konverzi mezi různými kodeky. TRUNKING, je funkce připojení do klasické telefonní sítě pomocí interní karty v Asterisku. VOIC , umožňuje nahrát vzkaz pro volaného, zpřístupnit nahrané vzkazy z telefonu, přes web anebo odeslat vzkaz do poštovní schránky uživatele jako Instalace instalace je možná přímo z repozitáře, ověříme si, zda nám vyhovuje verze a nainstalujeme. root@debian119:~# apt-cache show asterisk Package: asterisk Version: 1:11.7.0~dfsg-1 root@debian119:~# apt-get install asterisk Asterisk ihned běží, samozřejmě můžeme zkompilovat určitou verzi, potom je užitečné se podívat na požadavky dané verze na např. pro Asterisk 11 na Ubuntu je postup následující. # sudo apt-get install build-essential subversion libncurses5-dev libssl-dev libxml2-dev libsqlite3-dev # mkdir -p ~/src/asterisk-complete/asterisk # cd ~/src/asterisk-complete/asterisk # wget asterisk-11-current.tar.gz # cd ~/src/asterisk-complete/asterisk/11 #./configure # make # sudo make install # sudo make config Můžeme ověřit status asterisku, zastavit je, spustit, restartovat a připojit se na konzoli a ovládat jej z příkazového řádku. Pokud Asterisk běží, tak se připojíme s přepínačem -r pomocí asterisk rvvv, pokud nám neběží, tak přepínačem c rovnou aplikaci spustíme asterisk cvvv. # /etc/init.d/asterisk status # /etc/init.d/asterisk {start stop restart reload force-reload} 134

142 11 Asterisk asterisk -rvvv Asterisk ~dfsg-1, Copyright (C) Digium, Inc. and others. Created by Mark Spencer ========================================================================= Connected to Asterisk ~dfsg-1 currently running on debian119 (pid = 5051) debian119*cli> help debian119*cli> exit 7.4 Globální nastavení asterisk.conf a modules.conf Globální nastavení Asterisku najdeme v konfiguračním asterisk,.conf umístěném v adresáři /etc/asterisk stejně jako většina konfiguračních souborů Asterisku. Tento soubor ovlivňuje chování běhu celého Asterisku. Často není třeba do jeho konfigurace zasahovat, ale je dobré jeho možnosti znát. Po instalaci nalezneme ve složce /etc/asterisk vzorový soubor asterisk.conf. Pokud bychom chtěli využívat jiný asterisk.conf soubor, předáme cestu k němu jako parametr při spouštění Asterisku v příkazové řádce # asterisk C /home/voz29/asterisk.conf Obsahem konfiguračního souboru asterisk.conf je sekce nastavení složek [directories]. Pro většinu instalací není třeba tuto konfigurace měnit, důvodem ke změně může být běh několika instancí Asterisku v jednom čase nebo pokud chceme konfigurační soubory ukládat na nestandardním místě. Tímto způsobem můžeme také ovlivnit ukládání objemnějších dat v případě nahrávání hovorů apod. Následující tabulka obsahuje název direktivy, její hodnotu a vysvětlení funkce dané direktivy [mik]. Volba Hodnota (Příklad) Vysvětlení astetcdir /etc/asterisk Umístění konfiguračních souborů Asterisku astmoddir /usr/lib/asterisk/modules Umístění modulů, které je možné načíst astvarlibdir /var/lib/asterisk Základní umístění pro různé stavové informace používané různými částmi Asterisku. Zároveň sem Asterisk ukládá při běhu některé informace. astdbdir /var/lib/asterisk Asterisk ukládá svoji vnitřní databázi do soubor astdb uloženého v tomto umístění. astkeydir /var/lib/asterisk Základní umístění pro klíče používané k šifrování astdatadir /var/lib/asterisk Cesta k pomocných datům, které Asterisk používá (zvuky apod.) 135

143 11 Asterisk astagidir /var/lib/asterisk/agi-bin Umístění pro AGI skripty astspooldir /var/spool/asterisk Složka pro ukládání souborů jako záznamy hovorů, hovory ve hlasové schránce apod. astrundir /var/run/asterisk Uložiště UNIX kontrolních soketů nebo čísla procesu astlogdir /var/log/asterisk Uložiště log souborů Tab. 7.1 Directivy v asterisk.conf Další sekcí jsou volby [options]. V této sekci jsou nastaveny globální proměnné pro běh programu. V tabulce jsou uvedeny nejvýznamnější z nich. Volba Hodnota (příklad) Vysvětlení verbose 3 Nastaví úroveň výpisu v CLI asterisku a v logu. v debug 3 Nastaví úroveň ladění. d highpriority yes Běh s real-time prioritou dumpcore yes Nařídí Asterisku vytvořit dump jádra při spadnutí programu autosystemnme yes Automaticky nastaví instanci název podle hostname počítače maxcalls 100 Nastaví maximální počet simultánních hovorů, default. Bez limitu maxload 0.9 Nastaví maximální zatížení. Pokud je tato hodnota překročena, nepřijímá již Asterisk nové hovory. maxfiles 1000 Nastaví maximální počet souborových deskriptorů minmemfree 1 Nastaví minimální počet MB volné paměti, do které bude Asterisk přijímat hovory. cache_record_files yes Povolí ukládání hovorů do record_cache_dir již během hovoru. record_cache_dir /tmp složka pro ukládání nahrávaných hovorů během hovoru Tab. 7.2 Options v asterisk.conf 136

144 11 Asterisk Ostatní volby již nejsou tak významné a nemá cenu se jimi v téhle fázi seznamování zabývat. Nyní si ukážeme, jak je možné v Asterisku pracovat s přídavnými moduly. Soubor modules.conf není v Asterisk instalaci striktně vyžadován, avšak bez modulů by Asterisk nebyl schopen dělat téměř nic. Pokud v konfiguračním souboru /etc/asterisk/modules.conf zvolíme autoload=yes, Asterisk vyhledá všechny moduly v /usr/lib/asterisk/modules složce a načte je při startu. Ačkoliv většina modulů nevyžaduje příliš systémových prostředků a jsou načteny velmi rychle, je vhodné načíst pouze ty moduly, které máme v plánu využívat. Moduly, které navíc využívají síťových prostředků, mohou být z bezpečnostního hlediska zneužity. Rovněž je možné nechat ze složky načíst všechny moduly, které najde a explicitně říct, které moduly nechceme načíst použitím noload direktivy. Jedna z možností, jak kontrolovat, které moduly jsou načteny je jednoduše nekompilovat a neinstalovat je během instalačního procesu. Během něj provádíme příkaz make menuselect, který zobrazí v prostředí menu dostupné moduly ke kompilaci. Moduly, které mají před sebou XXX, jsou moduly, které nemohou být zkompilovány protože configure skript nebyl schopný najít požadované závislosti. Přehled direktiv pro modules.conf je v následující tabulce Volba Hodnota (příklad) Vysvětlení autoload yes Asterisk načte všechny moduly, kromě modulů zmíněných v noload direktivě. preload res_odbc.so Indikuje, že zmíněný modul by měl být načten první v pořadí load chan_sip.so Načte modul (autoload=no) noload chan_alse.so Definuje modul, který nemá být načten require chan_sip.so Stejně jako load, ale Asterisk skončí, pokud dojde k chybě při načtení modulu preload-require res_odbc.so Stejně jako preload a require dohromady Tab. 7.3 Moduly v modules.conf 7.5 Konfigurace SIP a IAX uživatelů v sip.conf a iax.conf V této části se seznámíme s konfigurací SIP a IAX kanálu. Konfigurace SIP a IAX je uložena v sip.conf a iax.conf. Volání je směrován na pobočku (extension), která je prezentována řetězcem alfanumerických znaků, čili můžeme např. volat jménem Alice anebo číslem

145 11 Asterisk SIP uživatel v sip.conf V následující ukázce je znázorněn příklad rychlé konfigurace SIP účtu. Konfigurační soubor sip.conf obsahuje jednak obecné nastavení v sekci [general], které je platné, pokud specifická sekce neobsahuje jinou volbu parametrů ze sekce [general], některé z obecných parametrů můžou být specifikovány i v sekci uživatele, např. kodeky či kontext. Na konec souboru sip.conf přidáme následující. [alice] type=friend context=vlastni language=cz host=dynamic username=300 secret=heslo callerid=alice <300> ;Definování účtu ;Vyjadřuje skupinu v dialplanu ;(/etc/asterisk/extensions.conf), kde ;hledat v případě volání tohoto čísla ;Povolení registrace účtu na všech IP ;adresách ;Přihlašovací jméno při registraci účtu ;Přihlašovací heslo při registraci účtu ;identifikace volajícího [bob] type=friend context=asterisk1 language=cz host=dynamic username=400 secret=heslo callerid=bob <400> IAX uživatel v iax.conf Definice IAX účtů používá téměř stejnou syntaxi, jako definice SIP účtů, s jediným rozdílem, že se provádí v souboru iax.conf, opět umístěném v hlavním adresáři s aplikací /etc/asterisk, níže uvedené přidáme na konec souboru. [Klara] type=friend context=vlastni language=cz host=dynamic username=500 secret=heslo callerid=klara <500> ;Definice účtu Pokud by se nám objevovala chyba chan_iax2.c:5010 handle_call_token: Call rejected, CallToken ;Support required, tak přidáme do hlavní sekce [general] následující. [general] calltokenoptional= /

146 11 Asterisk Po uložení konfigurace provedeme reload systému anebo pouze SIP či IAX2 modulu a přesvědčíme se o existenci uživatelů. # asterisk rvvv *CLI> reload *CLI> sip show peers *CLI> sip show users Další možnosti sip.conf a iax.conf Následující v iax.conf. tabulka obsahuje možnosti nastavení parametrů uživatele jak v sip.conf, tak Volba Hodnota Vysvětlení [Alice] Název definujíci uživatele type friend Znamená, že ovladač kanálu (channel driver) se bude snažit nejdříve najít jméno a až potom IP adresu. (Peer = IP adresa + port. User = hledá název v SIP hlavičce From, který se shoduje s názvem v hranatých závorkách) host dynamic akceptuje se IP adresa uživatele, jinak je možné zadat statickou adresu, na které bude uživatel dosažitelný disallow all Implicitně zakáže všechny povolené kodeky allow alow,ulow Povolí uvedené kodeky context vlastní Uživatel v dialplanu je obsloužen daným kontextem callerid Alice 200 Název pobočky pro identifikaci (zobrazení) u volaného (objeví se v poli FROM) secret heslo Heslo k autorizaci Tab Parametry uživatele v sip.conf a iax.conf Uvedeme si podrobnější nastavení sip.conf včetně globálních parametrů a možnosti nastavení různých typu účtů. [general] bindport=5060 srvlookup=yes qualify=1000 ;sekce general určuje společná nastaveni pro všechny účty ;port na kterém naslouchá SIP ;podpora DNS ;monitorování dostupnosti klientů 139

147 11 Asterisk disallow=all allow=alaw dtmfmode=rfc2833 language=cz allowguest=yes context = cizi ;zakazuje všechny kodeky ;povolíme jen vybrané ;způsob přenosu DMTF volby ;výchozí jazyk,např. pro chybové hlášky ;povolení hovorů neregistrovaným klientům ;určuje kontext, skupinu do které uživatel patří ;registrace asterisku jako klienta, rovněž musí být definován i účet viz níže register => user[:secret[:authuser]]@host[:port][/extension] ; deklarace účtů [my_provider] ;učet k poskytovateli - název name= my_provider ;registrační jméno secret=heslo_1 ;heslo type=peer ;ovlivňuje autentizaci, peer servery, user klient, friend oba fromuser=xxxx ;položka fromuser v SIP protokolu (pokud poskytovatel vyžaduje) fromdomain=yy.com ;položka fromdomain v SIP protokolu (pokud poskytovatel vyžaduje) host=provider.cz ;IP adresa, DNS název (, dynamic - dynamicky přidělená registrací) canreinvite=no ;určuje zda mohou RTP pakety obcházet Asterisk context = verejny ;určuje kontext, skupinu do které uživatel patří [nazev_uctu] name=nazev_uctu secret=heslo_2 type=friend host=dynamic canreinvite=no nat=yes context = vnitrni ;uživatelský účet název (nejčastěji přímo telefonní číslo) ;registrační jméno ;heslo ;friend autorizace v obou směrech ;dynamicky získaná IP hosta registrací ;bude klient za NATem? ;určuje kontext, skupinu do které uživatel patří [general] port = 2727 bindaddr = ; IP adresa ( všechny rozhranní) ; IP adresa ( všechny rozhranní) [ ] host = ; IP brány line => aaln/1 ; jednotlivé linky brány line => aaln/2 line => aaln/3 line => aaln/4 dtmfmode=rfc2833 ; DTMF mód context = mgcp_kon ; kontext directmedia = yes ; může provést re-invite (stejné jako sip) ;... a řada dalších parametrů 140

148 11 Asterisk A obdobně pro iax.conf opět včetně příkladu nastavení trunku. [general] bindport=4569 ;sekce general určuje společná nastaveni pro všechny účty ;port na kterém naslouchá SIP calltokenoptional= / maxcallnumbers=512 ;ošetření pro klienty nepodporující novou ;metodu zabezpečení call token validation qualify=yes bandwidth=high allow=alaw language=cz ; monitoruje dostupnost klapky ; povolení kodeků s vyšší rychlostí (G.711), medium střední, lowdisallow=all ;zakazuje všechny kodeky ;povolíme jen vybrané ;výchozí jazyk,např. pro chybové hlášky ;způsoby registrace asterisku jako klienta - register => user:heslo@host ; IAX2TRN:anca@ ; deklarace účtů [120] username=120 secret=asdf auth=md5 type=friend host=dynamic context=kontext1 [IAX2_TRN] username=iax2_trn secret=trnk auth=md5 type=friend host= context=kontext1 trunk=yes ;trunk mod asterisku, je zapotřebí hw časovač (např. digium hw) Pro zajištění přenosu videa je nutné toto nastavení povolit přidáním příkazu videosupport do obecného nastavení ([general]) v souboru sip.conf a také povolit podporu kodeků sloužících pro přenos videa, jako H.261, H.263, H.263+ nebo H.264 nebo jen některé z nich. [general] videosupport=yes allow=h261 allow=h263 allow=h263p allow=h

149 11 Asterisk 7.6 Dialplan extensions.conf Dialplan určuje, jak se zachází s relacemi, které vznikají v Asterisku anebo přicházejí do Asterisku zvenčí, je srdcem Asterisku a rozhoduje se v něm, jaké činnosti budou vykonány při odchozím či příchozím volání. Dialplan se vytváří se pomocí skriptovacího jazyka, kterým definujeme instrukce, které Asterisk provádí při splnění podmínek pro danou sadu instrukcí. Na rozdíl od tradičních telefonních systémů je dialplan plně přizpůsobitelný. Jeho syntaxe je specifikována v konfiguračním souboru extensions.conf. Dialplan se dělí do 4 základních koncepcí: na kontexty, pobočky, priority a aplikace Kontexty Dialplan je rozdělen na sekce zvané kontexty (context). Kontexty oddělují různé části dialplanu od vzájemné interakce. Pobočka definovaná v jednom kontextu je naprosto izolovaná od pobočky z jiného kontextu, pokud tak není výslovně povoleno. Všechny instrukce zapsané pod názvem kontextu jsou jeho součástí, dokud není definován nový kontext. Za začátku dialplanu existují dva speciální kontexty s názvy [general] a [globals]. První sekce obsahuje seznam obecných nastavení dialplanu a druhý obsahuje globální proměnné. Kromě těchto dvou kontextů je třeba vyvarovat se používání kontextu [default]. Pokud v sip.conf definujeme pobočku, určujeme také, k jakému kontextu se váže. Obr. 7.3 Funkce kontextu ze sip.conf v dialplan Pobočky Ve světě telekomunikací pojem pobočka obvykle značí číselný identifikátor, který, pokud je volán, rozezvoní telefon (hlasovou schránku, frontu). V Asterisku pobočka pod určitým názvem definuje jedinečnou posloupnost kroků, přes které Asterisk hovor povede. Uvnitř každého kontextu můžeme definovat neomezený počet poboček. Syntaxe pro telefonní pobočku je tvořena slovem exten =>, následuje název (nebo číslo) pobočky (nebo kombinace). Dále následuje priorita a aplikace (příkaz), který se má v daném kroku provést exten => název, priorita, aplikace() 142

150 11 Asterisk Priority Každá pobočka má několik kroků nazývané priority. Priority jsou číslovány postupně od čísla 1 a každý krok spustí specifickou aplikaci. Příkladem může být pobočka, která vyzvedne hovor a vzápětí jej zavěsí. Mezi těmito kroky bývá samozřejmě obvykle sekvence dalších kroků [md1]. exten => 123,1,Answer() exten => 123,2,Hangup() Číslování nemusí být striktní ve všech krocích, pro automatické doplnění čísla s prioritou o 1 vyšší je možné uvést v dalším kroku prioritu n. První priorita však musí začínat číslem 1. exten => 123,1,Answer() exten => 123,n,něco udělej exten => 123,n,ještě něco udělej exten => 123,n,udělej poslední funkci exten => 123,n,Hangup() Z důvodu zjednodušení syntaxe došlo k zavedení nové proměnné same => Ta doplní slovo exten => a název pobočky za klíčové slovo same =>. Zlepšuje čitelnost a přenositelnost kódu z jedné pobočky na druhou. exten => 123,1,Answer() same => n,něco udělej same => n,ještě něco udělej same => n,udělej poslední funkci same => n,hangup() Návěští priorit Umožňují přiřadit název prioritě uvnitř pobočky. Zaručuje to, že můžeme konkrétně odkazovat na priority něčím jiným než jejím číslem, které obvykle nemusí být ani známé. Jako syntaxe se používá exten => 123,n(návěští),aplikace() Aplikace Každá aplikace provádí specifickou akci s daným kanálem jako přehrání zvuku, čtení DTMF volby, prohledávání databáze, volání kanálu, zavěšení hovoru atd. Příklady aplikací jsou: Answer() Answer() aplikace je používána k vyzvednutí kanálu, který zvoní. Nemá žádné argumenty. 143

151 11 Asterisk Progress() Progress() poskytuje informaci o probíhajícím hovoru původnímu kanálu. Někteří poskytovatelé mají signalizační problémy, pokud tato aplikace není použita. Playback() Slouží k přehrání předem uložené nahrávky. Typickým způsobem využití je hlasový automat. Jako parametr vyžaduje cestu k přehrávanému souboru. Buďto absolutní nebo relativní. Playback(/home/john/sounds/filename) Playback(custom/filename) Asterisk vybírá nejlepší soubory k přehrání na základě hodnoty překladu tzn., vybere soubor ve formátu, který je nejméně náročný na CPU při převodu na nativní audio formát. Pokud chceme zjistit, jak dlouho zabere převod mezi formáty, můžeme to zjistit příkazem v CLI show translation Hangup() Slouží k zavěšení hovoru a nevyžaduje žádný parametr, popř. můžeme použít ISDN cause code Hangup(16) Background() Slouží k přehrávání hovorů a zároveň reaguje na DTMF volbu uživatele Tvorba dialplanu Nyní si vytvoříme ukázkový diaplpan, definujeme vlastní kontext [vlastni] a do něj vložíme pobočku 200. Pokud tuto pobočku vytočíme z klienta, přehraje se nám uložený audio soubor helloworld a po přehrání dojde k zavěšení hovoru. Na konec souboru /etc/asterisk/extensions.conf tento kontext s obsahem doplníme [vlastni] exten => 200,1,Answer() same => n,playback(hello-world) same => n,hangup() Kontext s názvem [vlastni] již máme svázaný s uživateli Alice a Bob v konfiguračním souboru /etc/asterisk/sip.conf, takže nyní stačí pouze načíst novou konfiguraci do Asterisku. Po uložení konfigurace ji načteme do Asterisku reloadem celé konfigurace. # /usr/sbin/asterisk -rx "dialplan reload" ;nebo z konzole pomocí CLI asterisku CLI> dialplan reload 144

152 11 Asterisk Následuje otestování funkce, jednoduše zavoláme pobočku 200 a ze sluchátka uslyšíme Hello World. Nyní povolíme uživatelům Alice a Bob komunikovat mezi sebou. Do kontextu [vlastni] vložíme následující pobočky exten => alice,1,dial(sip/alice) exten => bob,1,dial(sip/bob) Po reloadu Asterisku může Alice volat Bobovi a Bob Alici vytočením jejich jména v softwarových telefonech a pokud použijeme v dialplan níže uvedené, tak se dovoláme vytočením 300 a 500. exten => 300,1,Dial(SIP/alice) exten => 400,1,Dial(SIP/bob) Vzory Pattern Matching V extensions.conf nám vzory pomáhají definovat kombinace několika čísel do jednoho zápisu. Pokud bychom pracovali se stávajícími znalostmi řešili bychom následující problém následovně. Pokud někdo zavolá na číslo přehraje se mu zpráva hello-world: [general] [test] exten => 100,1,Answer() exten => 100,2,Playback(hello-world) exten => 100,3,Hangup() exten => 101,1,Answer() exten => 101,2,Playback(hello-world) exten => 101,3,Hangup() exten => 102,1,Answer() exten => 102,2,Playback(hello-world) exten => 102,3,Hangup() A tak bychom pokračovali dále až po 109. Pokud použijeme vzor, bude zápis vypadat přehledněji a lépe: [general] [test] exten => _10X,1,Answer() exten => _10X,2,Playback(hello-world) exten => _10X,3,Hangup() Extension _10X definuje rozsah čísel od 100 do 109. Vzory vždy začínají podtržítkem. [abc] znaky a,b,c. Na příklad mohou být nahrazeny čísly 1,2,3. Ve výsledku 31,32,33: 145

153 11 Asterisk exten => _3[123],1,NoOp(Test) [a-b] jakékoliv znak mezi a-b. Na příklad mohou být nahrazeny čísly 1-5. Ve výsledku Může být také ve tvaru [25-8] pro 32,35-38: exten => _3[1-5],1,NoOp(Test) [X] jakákoliv číslice od 0-9. Například pro jakékoliv číslo od 300 do 399: exten => _3XX,1,NoOp(Test) [Z] jakákoliv číslice od 1-9. Například pro jakékoliv číslo od 31 do 39: exten => _3Z,1,NoOp(Test) [N] jakákoliv číslice od 2-9. Například pro jakékoliv číslo od 32 do 39: exten => _3N,1,NoOp(Test) * stisk tlačítka s hvězdičkou: exten => _*7,1,NoOp(Test) # stisk tlačítka s křížkem: exten => _#7,1,NoOp(Test). jakékoliv číslo či číslice. Na příklad pro všechna čísla, která začínají 420: exten => _420.,1,NoOp(Test) Nepoužívejte vzor _.! Pokud tento vzor použijete extension vloží speciální pravidlo i,t a h, které by mohlo vyvolat neočekávané chování. Pro označení celého rozsahu používejte raději _X. Nebo _X Offset při práci s řetězcem Při vytváření číslovacího plánu je výhodné využívat některé předdefinované proměnné Asterisku. Mezi nejčastěji používané patří CALLERID, CONTEXT, EXTEN. Význam proměnných je patrný z jejich názvu [sil3]. CALLERID obsahuje řetězec Identifikace volajícího, CONTEXT obsahuje název kontextu, ze které proměnnou čteme, EXTEN obsahuje volanou klapku. Obsah těchto proměnných, tj. řetězec znaků, můžeme číst pomocí zápisu: ${název_proměnné:offset:délka} 146

154 11 Asterisk Offset nám určuje počátek čtení řetězce, v případě že je negativní počítá se od konce řetězce. Délka nám určuje délku předaného řetězce. V případě že délka v zápise chybí nebo je negativní, pak se vrátí část řetězce začínající na hodnotě offsetu až po poslední znak řetězce. Například je-li v proměnné EXTEN uložen řetězec : ${EXTEN:1} - vrátí řetězec ${EXTEN:-4} - vrátí řetězec 6789 ${EXTEN:0:3} - vrátí řetězec 123 ${EXTEN:2:3} - vrátí řetězec 345 ${EXTEN:-4:3} - vrátí řetězec Vložené kontexty Include Statements Vložené kontexty (dále jen includes) jsou velice silným nástrojem pro zjednodušení a organizaci velkých dialplánů. Vložrním příkazu include, můžeme vkládat kontexty do stávajících kontextů. Uveďme příklad: include => název vloženého kontextu A v dialplánu: [general] [prodej] include => interni include => externi [interni] exten => 2000,1,Dial(SIP/2000) [externi] exten => ,1,Dial(SIP/ ) Máme kontext prodej a v něm vložené další kontexty interni a externi Časové Vložené kontexty Pomocí časových vložených kontextů (Time-Conditional Included Statements) můžeme definovat například dobu, po kterou bude číslo dostupné, a kdy bude například volající odkázán do hlasové schránky. Příkaz má nasledující syntaxi: include => kontext <čas> <den> <den v měsíci> <měsíc> Názvy dnů a měsíců reprezentují vždy třípismenné zkratky anglických názvů a čas je zadáván ve 24 hodinovém tvaru. Pokud bychom chtěli mít například pracovní číslo dostupné od pondělí do pátku od 9:00 hodin do 18:00 a v sobotu od 9:00 do 13:00, zápis v dialplánu by vypadal následovně: 147

155 11 Asterisk ;Den include => otevreno 09:00-18:00 mon-fri * * include => otevreno 09:00-13:00 sat * * include => zavreno [otevreno] exten => 2000,1,Dial(SIP/2000) [zavreno] exten => 2000,1,Voic (2000,u) Proměnná ${EXTEN} a funkce ${CALLERID(num)} Dříve než bude popsáno dialplánové programování a funkce, je dobré zmínit ještě dva základní a velice používané prvky: systémovou proměnnou ${EXTEN} a funkci ${CALLERID(num)}. ${EXTEN} Asterisk automaticky za tuto proměnnou vkládá vytáčené číslo. Narozdíl od: exten => 2000,1,Dial(SIP/2000) Použijeme: exten => 2000,1,Dial(SIP/${EXTEN}) Výsledek je stejný. ${CALLERID(num)} Tato funkce vrací číslo volajícího. Využívá se převážně ve spojení s aplikací Voic Main (), kde se přidává jako parametr. Po zavolaní na číslo 99 se volající dostane do své hlasové schránky: exten => 99,1,Voic Main(${CALLERID(num)}) V Asterisku mohou být funkce a programy implementovány buď externě pomoci Asterisk Gateway Interface (AGI) skriptu nebo Asterisk Extension Language (AEL). 7.7 Voic Hlasová schánka (dále jen voic ) je jednou ze základních služeb, která je Asteriskem poskytována [vore]. Asterisk již v základní instalaci obsahuje funkční voic module. Potřebujeme ho jen nakonfigurovat skrze soubor etc/asterisk/voic .conf. Nejprve opět přeneseme ukázkový soubor do našeho záložního adresáře: debian: /etc/asterisk# mv voic . conf /var/tmp/asterisk-etc-backup/ Nyní vytvoříme nový soubor etc/asterisk/voic .conf a vložíme do něj následující: 148

156 11 Asterisk [general] format = wav [default] 2000 => 1234,Filip Rezac,filip.rezac@vsb.cz 2001 => 5678,Miroslav Voznak,miroslav.voznak@vsb.cz Nyní jsou schránky nakonfigurovány. Každý záznam začíná číslem hlasové schránky (2000, 2001), dále pak pokračuje heslem účtu (1234, 5678), poté jmény uživatelů voic u (Filip, Miroslav) a končí jejich ovou adresou (filip.rezac@vsb.cz, miroslav.voznak@vsb.cz). Posledním krokem je přidat několik řádek i do extensions.conf, tak, aby byly voic y plně funkční: [default] exten => 1001,1,Answer() exten => 1001,2,Playback(hello-world) exten => 1001,3,Hangup() exten => 2000,1,Dial(SIP/2000,20) exten => 2000,2,Voic (2000,u) exten => 2001,1,Dial(SIP/2001,20) exten => 2001,2,Voic (2001,u) exten => 2999,1,Voic Main(${CALLERID(num)},s) V následujícím zápise se v aplikaci Dial () objevuje hodnota 20. Jedná se o dobu vyzvánění v sekundách, než je uživatel volající přesměrován do hlasové schránky. V aplikaci Voic () je dále uvedena proměnná u, která určuje, jaká hláška se má volajícímu přehrát při vstupu do voic u. Proměnná u reprezentuje hlášku unavaible (nedostupný). Dále ze může být použita proměnná b busy (obsazeno) a proměnná s, po které se pouze ozve tón ohlašující začátek nahrávání. Poslední řádek v extensions.conf slouží k přístupu do voic u. Pokud si Filip nebo Miroslav nepřečtou zprávu ve své ové schránce, mohou si jí posledchnout pokud zavolají na číslo Funkce ${CALLERID(num)} doplní automaticky číslo volajícícho,ten je přesměrován do své hlasové schránky. Proměnná s zakazuje použitá hesla pro voic . Nyní máme nakonfigurován základní voic a přístup k němu. Rozšířená řešení voic u, jako například podpora hesel, či využití STT (Speech-to-text) modulu není součástí tohoto materiálu. 7.8 IVR Interactive Voice Response Hlasové menu (dále jen IVR) je další velice používaná služba v Asterisku. IVR (Interactive Voice Response) umožňuje hlasovou interakci Vašeho systému s volajícími, kteří se systémem komunikují pomocí tlačítek a tzv. DTMF volby, nebo klasicky hlasovou interakcí. Mnoho IVR poskytuje výběrové menu pro směrování hovorů bez potřeby zásahu operátora, moderní IVR však dokážou plnit funkce kompletních systémů a řídících součástí. 149

157 11 Asterisk Jednoduché IVR Asterisk obsahuje několik nahraných hlasových zpráv. Soubor s názvem marryme.gsm obsahuje hlášku: Will you marry me? Press 1 for yes or 2 for no. (Vezmeš si mě? Stiskni 1 pro ano, nebo 2 pro ne). Pokud bychom chtěli následující zprávu využít jako IVR vypadalo by to následovně: exten => 30,1,Answer() exten => 30,2,Background(marryme) exten => 30,3,Hangup() exten => 1,1,Playback(thank-you-cooperation) exten => 1,2,Hangup() exten => 2,1,Playback(sorry) exten => 2,2,Hangup() Pokud volající zavolá na 30, Asterisk přehraje zprávu marryme.gsm. Pro IVR se používá aplikace Backround (), kde systém čeká na odpověď od volajícího. Pokud zvolí volající číslo 1 je mu přehrána hláška Thank you for your cooperation (Děkujeme za spolupráci), pokud stiskne 2,Asterisk přehraje hlášku Sorry (Promiňte) a zavěsí Neplatný vstup (extension i) Neplatný údaj (každý vstup, pro který není v dialplánu záznam) může být spravován pomocí extension i. V následujícím příkladu, IVR přehraje omluvu volajícímu a zavěsí. (Skutečný IVR by měl přesměrovat volajícího zpět do hlavního menu v případě neplatného vstupu.) exten => 30,1,Answer() exten => 30,2,Background(marryme) exten => 30,3,Hangup() exten => 1,1,Playback(thank-you-cooperation) exten => 1,2,Hangup() exten => 2,1,Playback(sorry) exten => 2,2,Hangup() ; Pokud je vloženo jiné než platné číslo exten => i,1,background(sorry) exten => i,2,hangup() Pauzy Nejjednodušší způsob, jak vytvořit pauzy je přehrání prázdných zvukových souborů. Série tichých zvukových souborů s délkou mezi 1 a 9 sekundami lze nalézt v /var/lib/asterisk/sounds/silenc ev následujícím příkladu je použita pauza 5 sekund: 150

158 11 Asterisk exten => 30,1,Answer() exten => 30,2,Background(marryme) exten => 30,3,Background(silence/5) exten => 30,4,Hangup() exten => 1,1,Playback(thank-you-cooperation) exten => 1,2,Hangup() exten => 2,1,Playback(sorry) exten => 2,2,Hangup() exten => i,1,background(marryme) exten => i,2,hangup() Víceúrovňové IVR Problém víceúrovňových IVR systémů spočívá v tom, že volající může zadat vstupní jednoduché číslice několikrát za sebou, ale dostane vždy jinou odpověď v závislosti na úrovni menu. V Asterisku mohou být čísla v daném kontextu použita pouze jednou, proto pokud chceme využívat víceúrovňové menu, je nutné vytvořit nový kontext pro další úroveň. V následujícím příkladu přeskakujeme mezi kontexty pomocí aplikace Goto (). Využijeme následujících fiktivních zvukových souborů, které byly pro příklad nahrány: hlavni-menu.gsm Stiskněte 1 pro prodej, 2 pro služby, 3 pro přístup do restaurace. restaurace.gsm - Stiskněte 1 pro přehrání nabídky pro tento týden nebo 2 pro přehrání nabídky na příští týden. restaurace-nabidka-tento-tyden.gsm Pondělí: Nudle se sýrovou omáčkou.úterý: Kuře na paprice... restaurace-nabidka-pristi-tyden.gsm Pondělí: Domácí bramborák.úterý: Smažený sýr s hranolkama... Pokud bude IVR na čísle 30, prodej na čísle 100, služby na čísle 150 a restaurace na čísle 200 bude IVR systém vypadat následovně: [ivr] ; Menu je přehráváno stále dokola, dokud volající nevloží vstup. ; exten => 30,1,Answer() exten => 30,2,Background(hlavni-menu) exten => 30,3,Background(silence/3) exten => 30,4,Goto(2) exten => 1,1,Dial(SIP/100) exten => 2,1,Dial(SIP/150) ; Goto() skočí do dalšího kontextu ([restaurace]) 151

159 11 Asterisk ; exten => 3,1,Goto(restaurace,200,1) exten => i,1,goto(30,2) [restaurace] exten => 200,1,Background(restaurace) exten => 200,2,Background(silence/3) exten => 200,3,Goto(1) exten => 1,1,Playback(restaurace-nabidka-tento-tyden) exten => 1,2,Wait(2) exten => 1,3,Goto(1) exten => 2,1,Playback(restaurace-nabidka-pristi-tyden) exten => 2,2,Wait(2) exten => 2,3,Goto(1) ; Špatné zadání pošle volajícího zpět do hlavního menu exten => i,1,goto(ivr,30,2) Teoreticky je možné vytvářet nekonečný počet úrovní menu, ale z praktické zkušenosti volající většinou hovor ukončí po třetím menu. 7.9 DAHDI/ZAPTEL Jedná se o konfigurační soubor ovladače hardwarových karet Digium a kompatibilních. Ve verzích Asterisku 1.2 a 1.4 (do verze ) byl tento ovladač označován jako ZAPTEL. Od verze a u všech verzí 1.6, 1.8 a 10 je označen názvem DAHDI (verze jsou číslovány od 2.0.0). Tento konfigurační soubor slouží ke konfiguraci analogových, E1, ISDN-BRI karet a dalších na úrovni ovladače [sil3]. Naleznete jej v adresáři /etc/dahdi/system.conf, respektive /etc/zaptel.conf. V tomto souboru se zejména konfiguruje přidružení signalizací jednotlivým kanálům, povolení použití potlačení ozvěny a u E1 karet se definují SPANy a rozdělení kanálů signalizačních a hovorových (B-kanály). Jako znak začátku komentáře se používá #. U analogových karet, se kterými se můžete ve Vašich počítačích setkat, rozeznáváme dva typy portů. FXS (Foreign exchange Subscriber) pro připojení analogového přístroje a port FXO ( Foreign exchange Office) pro připojení k nadřazené ústředně. Z pohledu konfiguračních souborů Asterisku je jejich označení přesně opačné, neboť se zde udává signalizace, nikoliv typ portu. Typ portu je dán osazeným hardwarovým modulem. span=1,1,0,ccs,hdb3,crc4 # span, zdroj hodiny, délka vedení, typ rámce, kód (,crc4)... mtp2=1 #..(zdroj hodin 0-vždy master, 1-slave (bez hodin - master), 2, 3 bchan=2-31 # konfigurace SS7 přenašeče echocanceller=mg2,2-31 span=2,0,0,cas,hdb3 152

160 11 Asterisk cas=32-46:1101 hardhdlc=47 # konfigurace CAS - R2 přenašeče cas=48-62:1101 echocanceller=mg2,32-46,48-62 span=3,0,0,ccs,hdb3,crc4 bchan=63-77,79-93 # konfigurace ISDN PRI přenašeče hardhdlc=78 echocanceller=mg2,63-77,79-93 fxoks=125 echocanceller=mg2,125 fxsks=126 echocanceller=mg2,126 loadzone=cz defaultzone=cz # konfigurace analogového FXS portu (pro připojení telefonu) # konfigurace analogového FXO portu (pro připojení k ústředně) # pro FXS port signalizace fxoks, pro FXO fxsks, tedy opačně # určuje konfiguraci HW korespondující s danou # zemí, ovlivňuje i další věci... velmi důležité Chan_dahdi.conf (Zapata.conf) Konfigurační soubor Asterisku pro konfiguraci kanálu Asterisku DAHDI, tedy karet Digium a jim kompatibilních. Konfigurace a přidružení kanálů již závisí na definici system.conf. Syntaxe tohoto souboru je následující. Nejprve jsou nastaveny jednotlivé parametry (ze zvyklosti se používá znak = ). Poté zápisem channel => číslo kanálu se provede zápis těchto parametrů pro daný kanál či kanály. Následně můžeme parametry změnit dalšími přiřazeními a povést nový zápis pro jiné kanály. [trunkgroups] [channels] group=1 ; svazek v extensions.conf se pak lze odkazovat na všechny okruhy svazku ; E1 - dahdi/g1 např.: exten => _8XX,1,Dial(dahdi/g1/${EXTEN},20) language=cz context = kontext1 ; kontext signalling = ss7 ; signalizace ss7type = itu linkset= 1 pointcode= 2 adjpointcode = 1 defaultdpc = 1 adjpointcodenetworkindicator = national cicbeginswith= 2 channel => 2-31 ; přidružení okruhů svazku 1 sigchan = group=5 ; svazek... např.: exten => _731,1,Dial(dahdi/g5,20) 153

161 11 Asterisk language=cz context=kontext1 signalling=fxo_ks callerid="731" <731> usecallerid=yes echocancel=yes ; kontext ; signalizace FXS channel => 125 ; přidružení okruhu 125 svazku 5 ; lze volat i přímo okruh: exten => _731,1,Dial(dahdi/125,20) group=6 ; svazek language=cz context=kontext1 ; kontext signalling=fxs_ks ; signalizace FXO echocancel=yes channel => 126 ; přidružení okruhu 126 svazku Peering mezi dvěma Asterisky Peering slouží k logickému propojení dvou ústředen stejného typu. V případě, že volám na číslo, které se nenachází v mé databázi (není registrované na moji ústřednu a není definováno v sip.conf nebo iax.conf), ale vím, že se nachází na ústředně sousední, mohu využít této funkce a vyvolat patřičný extension z této ústředny sousední. Jako první ústřednu použijeme tu, kterou jsme si vytvořili v prvních bodech, včetně nastavení SIP protokolu. U druhé budeme postupovat podobně, akorát zvolíme jiná čísla účtů. Tedy nastavení sip.conf druhé ústředny: [general] context=asterisk2 port=5060 udpbindaddr= srvlookup=yes disallow=all allow=alaw allow=gsm allow=ulaw allow=h261 allow=h263 allow=h263p allow=h264 [201] type=friend context=asterisk2 language=cz host=dynamic username=

162 11 Asterisk secret=201 callerid=201 <201> [202] type=friend context=asterisk2 language=cz host=dynamic username=202 secret=202 callerid=202 <202> Podobným způsobem, jako u první ústředny, také potřebujeme vytvořit (resp. upravit) soubor extensions.conf, abychom zajistili základní spojení v rámci ústředny: [general] static=yes writeprotect=no [macro-hovor] exten => s,1,dial(${arg1}) exten => s,2,congestion exten => s,3,hangup [Asterisk2] exten => _201,1,Macro(hovor,SIP/201) exten => _202,1,Macro(hovor,SIP/202) Ke spojení ústředen bude využit protokol IAX. Nyní je potřeba na každé z ústředen vytvořit účet ústředny sousední. Parametry tohoto účtu se definují opět v souboru iax.conf. Pro lepší představu je použitá topologie, včetně o adresování ústředen uvedena na obr Obr. 7.4 Logická topologie zapojení Do konfigurace souboru iax.conf první ústředny (Asterisk1) je tedy potřeba vytvořit účet pro protější ústřednu (Asterisk2): 155

163 11 Asterisk [Asterisk2] ;Definice účtu druhé ústředny (Asterisk2) type=friend username=asterisk1 secret=peer auth=plaintext ;Použité šifrování při autentizaci (také ;podpora MD5) host= ;Přidělení pevné adresy, která bude účet ;využívat předpokládá se, že PBX svoji ;IP adresu nemění (nebo alespoň ne často) context=iaxpeer peercontext=iaxpeer qualify=yes trunk=yes ;Nastavení, že se nejedná o běžný účet, ;nýbrž o peer (trunk) na jinou ústřednu Podobnou konfiguraci je také potřeba provést i u ústředny druhé (Asterisk2): [Asterisk1] type=friend username=asterisk2 secret=peer auth=plaintext host= context=iaxpeer peercontext=iaxpeer qualify=yes trunk=yes Nyní je ovšem také potřeba upravit číslovací plány na jednotlivých ústřednách, aby v případě neznámého čísla došlo k přeposlání žádosti k výstavbě spojení na ústřednu druhou. Tedy v případě Asterisk1: [general] static=yes writeprotect=no [macro-hovor] exten => s,1,dial(${arg1}) exten => s,2,congestion exten => s,3,hangup [Asterisk1] exten => _101,1,Macro(hovor,SIP/101) exten => _102,1,Macro(hovor,SIP/102) exten => _201,1,Macro(hovor,IAX2/Asterisk2/${EXTEN}) ;Rozšíření ;našeho defaultního ;contextu, v případě, ;že volám na čísla ;registrované na druhé ;ústředně, kde ;prostřednictvím našho ;IAX účtu vyvolám ;patřičný EXTEN na ;ústředně Asterisk2 exten => _202,1,Macro(hovor,IAX2/Asterisk2/${EXTEN}) [IAXpeer] ;Vytvoření contextu pro příchozí volání ;z druhé ústředny exten => _101,1,Macro(hovor,SIP/101) exten => _102,1,Macro(hovor,SIP/102) 156

164 11 Asterisk Samozřejmě podobnou úpravu je nutné také provést na straně ústředny Asterisk2: [general] static=yes writeprotect=no [macro-hovor] exten => s,1,dial(${arg1}) exten => s,2,congestion exten => s,3,hangup [Asterisk2] exten => _201,1,Macro(hovor,SIP/201) exten => _202,1,Macro(hovor,SIP/202) exten => _101,1,Macro(hovor,IAX2/Asterisk1/${EXTEN}) exten => _102,1,Macro(hovor,IAX2/Asterisk1/${EXTEN}) [IAXpeer] exten => _201,1,Macro(hovor,SIP/201) exten => _202,1,Macro(hovor,SIP/202) 7.11 Použití SRTP a SIPS/TLS Od verze 1.8 je obsaženo v základní distribuci a SRTP je možné využívat, v dřívějších verzích je nutné doinstalovat zvlášť Zabezpečení médií pomocí SRTP V /etc/asterisk/sip.conf dodáme do konfigurace příslušných účtů povolení srtpcapable=yes anebo můžeme dát přímo do sekce [general] a nastavení bude platit pro všechny. [201] type=friend context=asterisk2 language=cz srtpcapable=yes host=dynamic *** atd *** Dále upravíme dialplan v /etc/asterisk/extensions.conf tak, že nastavíme použití SRTP jak pro příchozí, tak pro odchozí volání. 157

165 11 Asterisk exten => 201,1,NoOp() exten => 201,n,Set(_SIPSRTP=${SIPPEER(${EXTEN},srtpcapable)}) exten => 201,n,Set(_SIPSRTP_CRYPTO=enable) exten => 201,n,Set(_SIP_SRTP_SDES=enable) exten => 201,n,Answer() *** atd *** exten => _1XX,1,NoOp() exten => _1XX,n,Set(_SIPSRTP=${SIPPEER(${EXTEN},srtpcapable)}) exten => _1XX,n,Set(_SIPSRTP_CRYPTO=enable) exten => _1XX,n,Set(_SIP_SRTP_SDES=enable) exten => _1XX,n,Dial(SIP/${EXTEN}) *** atd *** Zabezpečení signalizace v Asterisku pomocí SIPS K zabezpečení SIP protokolu využijeme open source SSL/TLS knihovny openssl. V první řadě je tedy potřeba ji nainstalovat, kde opět využijeme samoinstalačních balíčků: root@asterisk1:/# apt-get install openssl Samotný postup lze rozdělit do několika kroků. V první řadě je potřeba si pomocí aplikace openssl vygenerovat vlastní certifikační autoritu (CA). Začneme tedy vygenerováním 4096 bitového klíče a vytvořením této CA. Tuto naši CA bude ve velkém množství případů potřeba nainstalovat na naší pracovní stanici nebo telefonu. root@asterisk1:/etc/cert# openssl genrsa -des3 -out ca.key 4096 root@asterisk1:/etc/cert# openssl req -new -x509 -days 365 -key ca.key -out ca.crt Po vygenerování vlastní CA je potřeba vytvořit certifikát serveru a podepsat jej naší CA. Opět začneme vygenerováním klíče, tentokrát však pouze 1024 bitového, pokračujeme vygenerováním certifikátu a v poslední řadě jeho podpisem. Při generování certifikátu serveru je nutné zadat do položky Common Name doménové jméno vašeho SIP serveru (Asterisku), popř. jeho IP adresu. root@asterisk1:/etc/cert# openssl genrsa -out key.pem 1024 root@asterisk1:/etc/cert# openssl req -new -key key.pem -out asterisk.csr root@asterisk1:/etc/cert# openssl x509 -req -days 365 -in asterisk.csr -CA ca.crt -CAkey ca.key - set_serial 01 -out asterisk.crt Asterisk potřebuje ke správné funkcionalitě SIP zabezpečení mít, jak klíč (key.pem), tak samotný certifikát serveru (asterisk.crt) v jednom souboru. Proto v kořenovém umístění aplikace Asterisk vytvoříme adresář s názvem např. cert a v něm do souboru, který pojmenujeme, jako asterisk.pem zkopírujeme náš klíč a certifikát serveru. root@asterisk1:/etc/asterisk# mkdir cert root@asterisk1:/etc/cert# cat key.pem > /etc/asterisk/cert/asterisk.pem root@asterisk1:/etc/cert# cat asterisk.crt >> /etc/asterisk/cert/asterisk.pem 158

166 11 Asterisk Nyní na ústředně v konfiguračním souboru SIP protokolu (sip.conf) potřebujeme povolit TLS šifrování a nastavit cestu k našemu souboru s klíčem a certifikátem serveru (asterisk.pem) a u vytvořených účtů povolíme pouze šifrovaný přenos: [global] tlsenable=yes tlsbindaddr= tlscertfile=/etc/asterisk/cert/asterisk.pem [101] transport=tls [102] transport=tls 7.12 Asterisk a kalendáře Jednou z pokročilých služeb, které můžeme s Asteriskem využít, jsou propojení komunikačního systému s kalendářem, čili chování Asterisku bude ovlivňovat stav uživatele v kalendáři [mik]. Výhody využívaní kalendářů je několik, od rychlého vyhledávání v obsahu, sdílení na webu až po synchronizaci s jinými kalendáři a aplikacemi jak v PC, tak v mobilních zařízeních. Nejpoužívanějšími protokoly pro kalendáře jsou CalDAV a Exchange Web Service. Právě tyto protokoly jsou rovněž podporovány Asteriskem v jeho kalendářovém modulu. Spárování Asterisku s kalendářem nám umožní následující funkce: Asterisk si v nastaveném časovém intervalu kontroluje dostupnost uživatele v událostech kalendáře. V těchto událostech je možné nastavit stav dostupný anebo nedostupný. Na základě této informace Asterisk dokáže směrovat hovor, např. do hlasové schránky, na mobil, na zástupce, atd. a směrování volání tak bude efektivnější. Asterisk je schopný do kalendáře i zapisovat, typickým příkladem využití je záznam o realizovaných hovorech, takže uživatel může mít v kalendáři přehled svých volání (volající a volaný, příchozí č odchozí hovoru, délku hovoru a kdy se uskutečnil, rovněž i zmeškaná volání). Pokud do Asterisku naimplementujeme i aplikaci pro převod textu na řeč (TTS Text To Speech) a existuje řada placených i otevřených řešení, tak se nám otevřou možnosti přehrávání textu zapsaného v kalendáři ve formě audia, tím pádem vytočením určité pobočky se nám přehrají události v kalendáři. Asterisk umožňuje automatické zavolání v definovaný čas např. před začátkem schůzky poznačené v kalendáři a přehraje text zapsaný k dané události. TTS open-source řešením je např. Festival, ve spojení s VoiceGlue a VoiceXML lze vytvářet v Asterisku IVR stromy, ve kterých bude přehráván kupříkladu text z webových stránek, obdoba RSS čtečky s hlasovým výstupem 159

167 11 Asterisk Abychom funkce kalendáře mohli využívat, musíme si doinstalovat kalendářový server. Nainstalujme si tedy kalendářový server Davical. Samozřejmě existují i jiné řešení pro správu kalendářů, ale vybereme si open-source Davical, u kterého oceníme i user-friendly uživatelské rozhraní a navíc je již v repozitářích většiny linuxových distribucí Instalace Davical serveru Přidáme tedy zvolený kalendářový server do našeho komunikačního systému pomocí standardního příkazu k instalaci balíčku z repozitáře. # apt-get install davical Protože Davical využívá pro správu dat databázi PostgreSQL je nutné ji stáhnout a nakonfigurovat. # apt-get install postgresql postgresql-contrib php5-pgsql libapache2-mod-auth-pgsql V databázi se nám vytvořil uživatel s názvem postgres, kterému musíme nastavit heslo. # sudo passwd -d postgres # sudo passwd postgres Enter new UNIX password: postgres Retype new UNIX password: postgres passwd: password updated successfully root@server:/# /etc/init.d/postgresql-8.4 restart Nyní nakonfigurujeme databázi Davical. # su postgres # nano /etc/postgresql/8.4/main/pg_hba.conf Tento textový sobor editujeme podle vzoru. # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local davical davical_app trust local davical davical_dba trust # IPv4 local connections: host all all /32 md5 # IPv6 local connections: host all all ::1/128 md5f Takto editovaný soubor uložíme (CTRL+X a Yes) a restartujeme databázi. # /etc/init.d/postgresql restart 160

168 11 Asterisk Nainstalujeme databázi Davical serveru do PostgreSQL databáze. # /usr/share/davical/dba/create-database.sh/etc/init.d/postgresql restart Měla by se zobrazit informace o úspěšně instalaci a výzva k zadání přihlašovacího heslo Davicalu. Předtím než se přihlásíme potřebujeme ještě nakonfigurovat přístup virtualhostu v Apache2. Odhlásíme uživatele postgres (Ctrl+D) a do defaultního virtualhostu Apache přidáme následující záznam. nano /etc/apache2/sites-enabled/000-defaul # Virtual Host for DAViCal <VirtualHost > DocumentRoot /usr/share/davical/htdocs DirectoryIndex index.php index.html ServerName ServerAlias Alias /images/ /usr/share/davical/htdocs/images/ <Directory /usr/share/davical/htdocs/> AllowOverride None Order allow,deny Allow from all </Directory> AcceptPathInfo On php_value include_path /usr/share/awl/inc php_value magic_quotes_gpc 0 php_value register_globals 0 php_value error_reporting "E_ALL & ~E_NOTICE" php_value default_charset "utf-8" </VirtualHost> # /etc/init.d/apache2 restart Pokud bychom se přihlásili na Davical server, zjistili bychom, že vyžaduje editaci. Proto je potřebné vykonat ještě poslední editaci přes příkazový řádek. # nano /etc/davical/ conf.php <?php // $c->domain_name = "calendar.example.net"; // $c->sysabbr = 'DAViCal'; // $c->admin_ = 'admin@example.net'; // $c->system_name = "Example DAViCal Server"; // $c->enable_row_linking = true; $c->pg_connect[] = 'dbname=davical port=5432 user=davical_app';?> Nyní se konečně můžeme přihlásit na náš kalendářový server webovým prohlížečem na adrese kde se přihlásíme jako uživatel admin a heslem vygenerovaným během 161

169 11 Asterisk instalace. V tomto grafickém prostředí si vytvoříme kalendář, který bude sledovaný Asteriskem pomocí User functions Create Principal a použijeme níže uvedené nastavení. User Name: New Password: Confirm: Full Name: Active: User Roles: CREATE asterisk asterisk asterisk asterisk asterisk@localhost ano všechny ano Tento kalendář bude dostupný na adrese s login a password nastaveným výše Propojení Asterisku a Davical serveru Pro komunikaci Asterisku s kalendářem budeme používat program Sunbird nainstalovaný na PC a nejprve si jej stáhneme z Po instalaci aplikaci spustíme a nastavíme podle návodu níže. File > New calendar > On the Network Format: CalDAV Location: Name: asterisk Show Alarms: ano Finish Zadáme požadované přihlašovací údaje pro přístup ke kalendáři: asterisk / asterisk, pokud by Sunbird přihlášení nevyžadoval a nespojil se s kalendářem, použijeme URL kalendáře ve tvaru: Location: Nyní nastavíme Asterisk, aby mohl číst a zapisovat do vytvořeného kalendáře asterisk na caldav serveru. Na straně Asterisku editujeme soubor calendar.conf. # nano /etc/asterisk/calendar.conf [asterisk] type = caldav url = user = asterisk secret = asterisk refresh = 1 162

170 11 Asterisk Uložíme a provedeme restart Asterisku. # /etc/init.d/asterisk restart Správnou funkčnost ověříme v CLI Asterisku příkazem: # server*cli> calendar show calendars Calendar Type Status asterisk caldav busy Pokud máme v kalendáři v daném čase poznačenou schůzku, objeví se status busy. V této kapitole jsme si ukázali instalaci a nastavení kalendáře Aplikace kalendářových funkcí V této kapitole se budeme zabývat možnostmi využití kalendáře Asteriskem Směrování volání na základě zaneprázdněnosti CALENDAR_BUSY() funkce nám vrací aktuálně nastavenou zaneprázdněnost, kterou má uživatel nastavenou v kalendáři. Tento stav kontroluje dle nastaveného limitu v /etc/asterisk/calendar.conf. Do kontextu vlastní dopíšeme pobočku dostupnost. exten => dostupnost,1,gotoif(${calendar_busy(asterisk)}?busy:free) same => n(busy),dial(sip/alice) same => n,hangup() same => n(free),dial(sip/bob) same => n,hangup() Pokud tedy zavoláme na pobočku dostupnost a účastník bude dle kalendáře dostupný, půjde hovor na pobočku alice, pokud dostupný nebude, hovor půjde na pobočku bob Zapisování do kalendáře Asterisk umí také do kalendáře zapisovat, jako příklad vytvoříme jednoduché logování hovorů. Pokud dojde k vytočení pobočky log, volá se pobočka alice a po skončení hovoru se do kalendáře zapíše, kdo a jaký časový interval volal. Tento log si můžeme zkontrolovat v kalendářovém klientu Sunbird po reloadu. exten => log,1,set(start=${epoch}) same =>n,dial(sip/alice) same =>h,1,set(end=${epoch}) 163

171 11 Asterisk same =>h,n,set(calendar_write(asterisk,summary,start,end)=volal ${CALLERID(all)},${start},${end}) Čtení záznamů uložených v kalendáři K dalším funkcím, které Asterisk nabízí je funkce CALENDAR_QUERY(), který má jako parametry název kalendáře a čas ve formátu unix time. Vrací ID a pole události (event), které použijeme ve funkci CALENDAR_QUERY_RESULT. Tato funkce přijímá parametry CALENDAR_QUERY_RESULT(id z CALENDAR_QUERY, požadovaná informace, pořadí události)mezi požadované informace patří: summary název události description úplný popis události organizer osoba, která událost organizuje location místo události calendar název kalendáře, ve kterém je událost zaznamenána uid jedinečný identifikátor události start začátek události ve formátu unix time (počet sekund od Unix epoch) end konec události ve formátu unix time (počet sekund od Unix epoch) busystate 0 volný, 1 možná, 2 nepřítomný attendees seznam pozvaných účastníků události oddělených čárkou Pro přehrání informací je třeba nainstalovat na server Text To Speech aplikaci. Asterisk nativně podporuje aplikaci Festival, ve které najdeme i částečnou českou lokalizaci. Provedeme tedy instalaci této aplikace. # apt-get install festival festival-czech festvox-czech-ph na konec souboru zkopírujeme následující konfiguraci # nano /usr/share/festival/festival.scm ;; Enable access to localhost (needed by debian users) (set! server_access_list '("localhost\\.localdomain" "localhost")) ;;(set! voice_default 'voice_pc_diphone) (require 'czech) (require 'czech-unisyn) (set! inhibit-initial-pauses t) ;; (voice_czech_ph) (set! voice_default 'voice_czech_ph) ;;; Command for Asterisk begin (define (tts_textasterisk string mode) (let ((wholeutt (utt.synth (eval (list 'Utterance 'Text string))))) (utt.wave.resample wholeutt 8000) (utt.wave.rescale wholeutt 5) (utt.send.wave.client wholeutt))) ;;; Command for Asterisk end 164

172 11 Asterisk Uložíme a propojíme Asterisk s aplikací Festival # nano /etc/asterisk/festival.conf [general] host=localhost port=1314 usecache=yes cachedir=/var/cache/asterisk/festival/ festivalcommand=(tts_textasterisk "%s" 'file)(quit)\n Pro správné čtení české diakritiky je ještě třeba nastavit české locale pro jazyk. Editujte následující soubor dle návodu a poté provést reboot serveru. # nano /etc/default/locale LANG LANG="cs_CZ.UTF-8" Po restartu spustíme Festival v režimu server. # festival --server & Následuje ukázka využití CALENDAR_QUERY() funkce spojenou s Text To Speech aplikací. Po zavolání na pobočku schuzky se dozvíme události, které máme naplánovány v kalendáři na příštích 60 minut. # nano /etc/asterisk/extensions.conf exten => schuzky,1,answer same => n,set(id=${calendar_query(asterisk,${epoch},$[${epoch}+24*60*60])}) same => n,set(num=${calendar_query_result(${id},getnum)}) same => n,set(i=1) same => n,festival("plán na dalších 60 minut je následující") same => n,festival(celkový počet schůzek je ${num}) same => n,while($[${i} <= ${num}]) same => n,festival(schůzka číslo ${i} má začátek) same => n,sayunixtime(${calendar_query_result(${id},start,${i})},,q 'digits/at' IMp) same => n,festival(a konec je v) same => n,sayunixtime(${calendar_query_result(${id},end,${i})},,imp) same => n,festival(místo schůzky je: ${CALENDAR_QUERY_RESULT(${id},location,${i})}) same => n,festival(schůzka je zapsána v kalendáři: ${CALENDAR_QUERY_RESULT(${id},calendar,${i})}) same => n,festival(obsah schůzky je: ${CALENDAR_QUERY_RESULT(${id},summary,${i})}) same => n,set(i=$[${i} + 1]) same => n,endwhile Nyní vložíme přes Sunbird do následující hodiny schůzku, uložíme ji do vzdáleného kalendáře Asterisku. Poté zavoláme pobočku schůzky a Asterisk nám přečte, co jsme do obsahu schůzky uložili. 165

173 11 Asterisk Upozornění na schůzku Podobnou funkcí jako CALENDAR_QUERY je funkce CALENDAR_EVENT(). Tuto funkci použijeme pro hlasové oznámení blížící se schůzky 10 minut před jejím začátkem. Vytvoříme pro tento účel kontext calendar_event_notify a umístíme jej do dialplanu v souboru /etc/asterisk/extensions.conf. Na tento kontext se budeme odkazovat ze souboru /etc/asterisk/calendar.conf. # nano /etc/asterisk/extensions.conf [calendar_event_notify] exten => s,1,answer same => n,festival(za 10 minut máte schůzku\, která se koná v ${CALENDAR_EVENT(location)}\, obsahem schůzky je ${CALENDAR_EVENT(description)}\, nashledanou) same =: n,hangup # nano /etc/asterisk/calendars.conf [asterisk] type = caldav url = user = asterisk secret = asterisk refresh = 1 timeframe = 60 autoreminder = 10 channel = SIP/alice context = calendar_event_notify extension = s Nyní si posuneme začátek schůzky v kalendáři tak, aby začínal za 12 minut od aktuálního času a za 2 minuty můžeme očekávat hovor na pobočce Alice o blížící se schůzce včetně popisu lokace a obsahu schůzky XMPP server a Asterisk XMPP protklo využívá např. Jabber a používá se především pro služby Presence a Instant Messaging [mik]. Tento protokol je založen na jazyku XML a umožňuje výměnu textových zpráv anebo informaci o aktuální činnosti uživatelů, tedy podobně jako aplikace ICQ, MSN, Skype či AIM. Jednou z aplikací, která nabízí funkce XMPP serveru je Openfire. Jedná se tedy o server poskytující služby online výměny zpráv obdobně jako Instant Messaging (IM). Vlastní XMPP sever přináší řadu výhod a pro nás je podstatné, že můžeme propojením Asterisku a XMPP serveru sledovat status uživatelů a podle toho směrovat na ně volání. Správa těchto uživatelů může být zajištěna LDAP serverem. Openfire rovněž podporuje tvorbu chatovacích místností a může sloužit jako brána do ostatních sítí pro online výměnu zpráv jako např. do ICQ. Výhodou vlastního IM (Instant Messaging) systému ve spolupráci s Asteriskem přináší možnost reagovat na status 166

174 11 Asterisk uživatele (např. automatická odpověď v případě nepřítomnosti). Asterisk se přihlásí na tento server jako klient, může zasílat zprávy, přijímat odpovědi, v reálném čase získávat stavy dalších uživatelů na serveru a patřičně řídit dle těchto informací pravidla směrování Instalace Openfire Než si ukážeme spolupráci Asterisku a XMPP serveru, musíme si jej nejprve nainstalovat a nakonfigurovat. Instalaci provedeme z balíčku, který si stáhneme. # mkdir /usr/src/openfire # cd /usr/src/openfire/ # sudo wget Openfire vyžaduje java6-jre, ten ale není běžnou součástí systému a proto rozšíříme prohledávané repozitáře o další zdroj a instalujeme. # apt-get install python-software properties # add-apt-repository "deb lucid partner" # apt-get update # apt-get install sun-java6-jre Nyní pokračujeme v instalaci Openfire. # cd /usr/src/openfire # dpkg idownloadservlet\?filename\=openfire%2fopenfire_3.7.0_all.deb # /etc/init.d/openfire start # su postgres # createuser openfire Shall the new role be a superuser? (y/n) n Shall the new role be allowed to create databases? (y/n) y Shall the new role be allowed to create more new roles? (y/n) y postgres@server:/root$ createdb openfire postgres@server:/root$ psql openfire openfire=# ALTER USER openfire with password 'openfire'; openfire=# ALTER DATABASE openfire OWNER TO openfire; Dále pokračujeme ve webovém rozhraní na Choose lenguage: Czech (cs_cz) Doména: Port admin konzoly: 9090 Zabezpečený port admin. konzoly: 9091 Nastavení databáze: Štandardní nastavení Předvolby DB ovladače: PostgreSQL URL databáze: jdbc:postgresql://localhost: 5462/openfire Užívatelské jméno: openfire Heslo: openfire Nastavení profilu: výchozí Administrátorský účet: root@localhost 167

175 11 Asterisk Nové heslo Potvrzení hesla: asterisk asterisk Nyní se můžeme přihlásit jako administrátor na jako admin s heslem asterisk. V Server Jazyk a Časové pásmo Místní nastavení provedeme změnu časové zóny na Central Europe (GMT+1:00) instalace XMPP klientů Pro účely testování zvolíme dva Instant Messaging (IM) klienty s podporou XMPP protokolu. Prvním je populární Pidgin, jedná se multiplatformní aplikaci dostupnou pro Windows, Linux a Mac OS X, podporuje řadu komunikačních protokolů a hlavně XMPP. Druhým použitým IM klientem je Spark. XMPP klient Spark umožňuje i uskutečnění hovoru na uživatele, kteří mají na Openfire serveru přiřazené číslo pobočky (extension) z Asterisku. Pidgin je možné stáhnout ze stránek Po instalaci zvolíme: Účty>Spravovat účty>přidat a nastavíme následující parametry: Protokol: XMPP Meno: alice Doména: Heslo: alice Vytvořit tento účet na serveru: ANO Po přidání uživatele v Pidgin se nám zobrazí výzva na autorizaci ze strany serveru a vyplníme následující údaje: Username: alice Full name: alice alice@localhost Password: heslo Obr. 7.5 Vyplnění registrace XMPP klienta Pidgin 168

176 11 Asterisk Pokud vše proběhlo korektně, tak dostaneme potvrzení o úspěšné registraci. Obr. 7.6 Potvrzení úspěšné registrace XMPP klienta Pidgin Následně v aplikaci Pidgin účet aktivujeme a server si od nás ještě jednou vyžádá heslo k účtu, které si bude Pidgin již pamatovat. Stejně jako u klienta Pidgin, musíme nakonfigurovat rovněž klienta Spark. Je k dispozici na stránkách společnosti: Po stažení programu a jeho instalaci vytvoříme nový účet pomocí Accounts, kde vyplníme následující údaje: Username: bob Password: heslo Confirm Password: heslo Server: Měli bychom následně obdržet potvrzení: New account has been created. Přihlašovací údaje se nám vyplní automaticky a zvolíme Login. Nyní si přidáme uživatele Alice jako kontakt: Contact>Add Contact>UserName: Alice. Alice (XMPP Pidgin) obdrží výzvu k autorizaci Boba (XMPP Spark), což potvrdíme. Teď máme nainstalovaný náš XMPP server a k němu zaregistrované dva uživatele Alice a Bob prostřednictvím XMPP klientů Pidgin a Spark. Obr. 7.7 Vyplnění registrace XMPP klienta Spark 169

177 11 Asterisk Propojení XMPP a Asterisku Spojení Openfire a Asterisku umožňuje kontrolovat, který uživatel právě hovoří a není tak plně dostupný k online komunikaci. Jeho stav XMPP klienta se během hovoru změní na On Phone. Zároveň je možné uživateli Openfire severu přiřadit pobočku z Asterisku a tímto uživatele přímo volat z XMPP klienta Spark bez znalosti čísla přiřazené pobočky. Pokud se Asterisk přihlásí k XMPP serveru jako uživatel, je schopen číst stavy spřátelených účtů, psát jim zprávy a přijímat jejich odpovědi. Na základě těchto funkcí může při-způsobovat své chování. Vzájemné propojení Asterisku s Openfire serverem probíhá přes AMI (Asterisk Manager Interface). Na straně Asterisku je třeba přístup povolit a vytvořený účet nastavit do Asterisk-IM modulu na Openfire serveru. Zde je také nastaveno přiřazení čísla pobočky každému z uživatelů. Dále je zapotřebí přihlásit Asterisk k XMPP serveru jako uživatele. Nastavení se provádí v souboru /etc/asterisk/jabber.conf, kde nastavíme běžné údaje k přihlášení k XMPP serveru jako adresa XMPP serveru, port, status, apod. Důležitá je položka buddy, která určuje spřátelené účty, které bude Asterisk žádat o autorizaci a které bude poté schopen sledovat. Typickým využitím je informování uživatele o příchozím hovoru v okně XMPP klienta a následné směrování hovoru na základě jeho odpovědi také v tomto okně. Konfigurace v /etc/asteris/extensions.conf bude následující. exten => 333,1,Answer(); exten =>333,n, JabberSend(asterisk,alice@IP_SERVERU,Prichozi hovor od uzivatele ${CALLERID(name)}, vyber cilovou pobočku); exten =>333,n, JabberSend(asterisk,alice@IP_SERVERU,1 :posli na 101); exten =>333,n, JabberSend(asterisk,alice@IP_SERVERU,2 :posli na 102); exten => 333,n, Set(OPTION=${JABBER_RECEIVE(asterisk,alice@ IP_SERVERU)}); exten => 333,n, GotoIf($[${OPTION} = 1]?10:20) exten => 333,10, JabberSend(asterisk,alice@IP_SERVERU,(Calling101...); exten => 333,n, Dial(SIP/101); exten => 333,20, JabberSend(asterisk,alice@IP_SERVERU,(Calling102...); exten => 333,n, Dial(SIP/102); Další zajímavou funkcí je směrování hovoru na základě aktuálně nastaveného stavu v XMPP klientu. Stavy, které XMPP server používá jsou následující: Přítomen Volný k hovoru (Free to chat) Pryč Pryč na dlouho Nerušit Offline Odhlášen Celkem tedy máme 7 stavů, podle kterých můžeme měnit chování ústředny. Příkladem je jednoduchý skript, který rozlišuje, zdali je uživatel online (stav 1-5) nebo offline (stav 6-7) a podle toho směruje hovor buďto přímo na uživatele nebo do hlasové schránky. O tomto faktu informuje volajícího do okna XMPP klienta. 170

178 11 Asterisk exten exten => 555,2,gotoif($[$[${STATUS}] < 6]?3:10) exten=>555,3,dial(sip/101) exten => volana pobočka ${EXTEN} neni dostupna! Smeruji do hlasove-schranky.) exten => 555,11(unavailable),Dial(SIP/102) Jako souhrn většiny funkcí byl vytvořen prezenční skript. Cílem tohoto skriptu je směrovat hovor na základě stavu v kalendáři, XMPP klientu a podle reakce uživatele v okně XMPP klienta. Skript funguje následovně. Uživatel Bob má veřejnou pobočku pro celou kancelář, svoji privátní linku, voic ovou schránku a asistentku Alici, která má také svou privátní linku. Asterisk sleduje Bobův stav v kalendáři a XMPP klientu. Pokud nemá žádnou schůzku v kalendáři (stav free) a je online, dostane zprávu do okna XMPP klienta o tom, že mu volá konkrétní uživatel a on má možnost tento hovor akceptovat nebo předat na asistentku. Pokud hovor příjme, má 30s na vyzvednutí hovoru, jinak hovor skončí v hlasové schránce. Pokud není Bob dostupný díky kalendáři nebo XMPP klientu, hovor je směrován na Alici na její privátní pobočku. U Alice se zjišťuje, zdali je přítomna v práci (je online v XMPP klientu). Pokud ano, zvoní je telefon a má 30s na vyzvednutí hovoru, jinak hovor končí Bobovi v hlasové schránce. Kompletní schéma chování prezenčního skriptu včetně propojení s kalendářem a XMPP serverem dle výše uvedeného popisu je zobrazeno na obr Obr.7.8 Schéma chování prezenčního skriptu 171

179 11 Asterisk Níže následuje výpis inkriminované části direktiv a volání funkcí ve skriptu v extensions.conf. exten => 201,1,GotoIf(${CALENDAR_BUSY(asterisk)}?busy:free) exten =>201,n(free),Set(STATUS=${JABBER_STATUS(asterisk,bob@IP_SERVERU)}); exten => 201,n,gotoif($[$[${STATUS}] < 7]?5:busy) exten => 201,5,JabberSend(asterisk,bob@IP_SERVERU,Prichozi hovor od uzivatele ${CALLERID(name)}, vyber cilovou pobočku); exten =>201,n, JabberSend(asterisk,bob@IP_SERVERU,1 :prevezmi hovor (102)); exten =>201,n, JabberSend(asterisk,bob@IP_SERVERU,2 :posli na Alici 101); exten => 201,n, Set(OPTION=${JABBER_RECEIVE(asterisk,bob@IP_SERVERU)}); exten =>201,n, GotoIf($[${OPTION} = 2]?busy:10) exten => 201,10, Jabber-Send(asterisk,bob@IP_SERVERU,(Volam102...); exten => 201,n, Dial(SIP/102,30); exten =>201,n, Voic (6001@mailbox-102) exten =>201,n, Hangup(); exten =>201,n(busy),Set(STATUS=${JABBER_STATUS(asterisk,alice@IP_SERVERU)}); exten => 201,n,gotoif($[$[${STATUS}] < 7]?105:200) exten => 201,105,JabberSend(asterisk,alice@IP_SERVERU,Bob je nedostupny,prichozi hovor od uzivatele ${CALLE-RID(name)},vybercilovou pobočku:); exten => 201,106, JabberSend(asterisk,alice@IP_SERVERU,1: prevezmi hovor (101)); exten => 201,107, JabberSend(asterisk,alice@IP_SERVERU,2: posli na do hlasoveschranky Boba); exten => 201,108, Set(OPTION=${JABBER_RECEIVE(asterisk,alice@IP_SERVERU)}); exten => 201,109, GotoIf($[${OPTION} = 2]?200:110) exten => 201,110, Jabber-Send(asterisk,alice@IP_SERVERU,(Volam101...); exten => 201,n, Dial(SIP/101,30); exten =>201,n, Hangup(); exten => 201,200, Voic (6001@mailbox-102) exten =>201,n,Hangup(); Přímé volání účastníka bez znalosti jeho telefonního čísla. V XMPP klientu Spark je možné, pokud má uživatel v systému přidělenou pobočku, přímo volat daného účastníka. Po zvolení tlačítka volat ústředna nejprve zavolá volajícímu a po vyzvednutí hovoru dochází ke spojení s požadovanou pobočkou. Uživatel je v okně obeznámen, že má příchozí hovor a je mu nabídnuta možnost volby směrování na cílové pobočky. Na základě jeho číselné odpovědi je hovor směrován na jednu z nabízených poboček. Protokol XMPP je schopen nastavit až 7 různých stavů. Dle těchto stavů se mění chování Asterisku a hovory se směrují na různé pobočky. Výše uvedený Prezenční skript představuje modelovou situaci vedoucího, který má asistentku a pokud přichází hovor na vedoucího, Asterisk zkontroluje jeho stav v kalendáři a XMPP klientu, pokud je dostupný, přijde mu zpráva o příchozím hovoru a může se rozhodnout, zda-li hovor příjme, pokud není jakákoliv podmínka splněna, hovor přechází na asistentku, zkontroluje se její stav v XMPP klientu, a hovor je směrován buď na ni nebo do hlasové schránky. 172

180 12 Kamailio 8 Kamailio Kamailio má kořeny v open-source projektu SER (SIP Express Router), který byl vyvinut v Berlíně ve výzkumném institutu FhG Fokus v roce 2002, byly tím položeny základy kódu jedné z nevýkonnějších SIP Proxy a řada dalších se v SER inspirovala [igl]. Část týmu přesunula i se značkou SER do nově založené komerční společnosti iptel.org a jiná část založila v roce 2005 nekomerční opensource projekt OpenSER, tyto části vývojářů pracovaly odděleně. Obr. 8.1 Logo SER a Kamailio Kvůli sporům o obchodní značku SER se OpenSER v roce 2008 přejmenoval na Kamailio a rovněž byla ještě v témže roce vytvořena další větev s názvem OpenSIPS. Následně o několik měsíců se týmy vývojářů Kamailia a SER dohodly na vzniku projektu SIP Router, který by měl sjednotit Kamailio a SER. Obr.8.2 Souvislost mezi projekty vzešlých ze SER 173

181 12 Kamailio 8.1 Popis modulů Kamailia Možnosti využití Kamailia jsou rozsáhlé, jedná se o velice výkonnou SIP Proxy, která dokáže zpracovat stovky tisíc požadavků za sekundu, může rovněž fungovat jako SBC, Presence server či registr ar anebo jako malá PBX a konkurovat Asterisku. Výhodou je interoperabilita se SIP klienty a neskutečné možnosti adaptace, čili s určitým úsilím lze integrovat i SIP UA, kteří obsahují neočekávané vlastnosti. Nevýhodou je malý rozsah aplikací např. oproti Asterisku, což je dáno tím, že se nejedná o B2BUA ale SIP Proxy a složitost vynucování kodeků, síla Kamailia je především ve zpracování SIP signalizace. Kamailio má rovněž odlišný přístup ke konfiguraci než Asterisk, protože konfigurační soubor Kamailia je skript vyžadující znalosti jazyka C. Neřídí se aplikační logika ale přímo flow SIP zpráv, je zde možnost nahrávání modulů, lze použít různé DB moduly. Kamailio podporuje iipv6, TLS, NAT, skriptovací jazyky Perl, Python, Lua a databáze MySQL, PostgreSQL, UnixODBC, Berkeley DB, Oracle [roz], [gon]. Obr. 8.3 Modulární architektura Kamailia Jádro Kamailia poskytuje: Management transportu a paměti Rozhraní pro moduly Konfigurace Uzamykání Moduly Kamailia poskytují: Funkce skriptů Speciální proměnné 174

182 12 Kamailio Parametry modulů Managementové funkce Podporovaných modulů je celá řada, viz. obr 8.4, zmíníme si pouze ty nejdůležitější. Jednak jsou zde základní moduly kex (sada funkcí), corex (další sada funkcí), tm (pro obsluhu transakcí), tmx (rozšířený modul obsluhy transakcí), sl (stateless module), rr (Record-Route a Route module), pv (Modul pseudoproměnných), maxfwd (Max-Forward processor module) a dialog (modul pro podporu dialogů). Obr. 8.4 Moduly Kamailia Další důležité moduly, které si zmíníme jsou následující: db moduly, pro podporu databází jako db_mysql, db_sqlite, db2_ldap (možnost přistupovat k LDAP jako k DB) a db2_ops registrar modul, pro podporu registrací 175

183 12 Kamailio aac moduly, Accounting (vytváření CDR záznamů o hovorech) s podporou různých backendů včetně DB auth modul, obecná podpora autorizace jak pro INVITE tak pro REGISTER enum module, pro podporu ENUM dotazů ipops module, pro operace nad IPv4 a IPv6 adresami LDAP module, pro podporu LDAP dotazů přímo ve skriptu rtproxy a nathelper modul, podpora průchodu NATem pomocí RTP Proxy mediaproxy modul, podpora pro NAT pomocí Media Proxy pike modul, pro zabezpečen proti DoS, umožňuje blokovat adresy generující příliš velký provoz ratelimit modul, podpora omezení různých částí kódu před zneužitím, např. omezení počtu registrací za minutu lcr modul, podpora LCR (Least Cost Routing), optimalizace směrování s nejnižšími náklady xlog, vylepšený logovací modul vhodný nejen pro debug sipcapture modul, modul pro přeposílání vybraných SIP zpráv do DB pro pozdější analýzu 8.2 Instalace o rozběhnutí Kamailia Nejdříve ověříme pomocí apt-cache search kamailio, že balíček existuje a o kterou verzi se jedná apt-cache show kamailio. root@debian119:~# apt-cache search kamailio kamailio - very fast and configurable SIP proxy kamailio-berkeley-bin - Berkeley database module for Kamailio - helper program *** root@debian119:~# apt-cache show kamailio Package: kamailio Version: Pokud by balíček nebyl dostupný, tak si stáhneme a přidáme Kamailio GPG key do apt key seznamu, potom do /etc/apt/sources.list odkazy do repozitáře Kamailia pro danou verzi, např. lenny. root@debian119:~# wget root@debian119:~# apt-key add kamailiodebkey.gpg OK root@debian119:~# nano /etc/apt/sources.list deb lenny main deb-src lenny main Teď můžeme balíček nainstalovat. root@debian119:~# apt-get install kamailio Setting up kamailio ( )... [FAIL] Kamailio not yet configured. Edit /etc/default/kamailio first.... failed! 176

184 12 Kamailio Processing triggers for libc-bin ( )... Kamailio není nakonfigurováno, musíme nejdříve editovat /etc/default/kamailio., kde povolíme níže uvedené. nano /etc/default/kamailio RUN_KAMAILIO=yes USER=kamailio GROUP=kamailio MEMORY=64 DUMP_CORE=yes Teď můžeme spustit Kamailio server /etc/init.d/kamailio start, který poběží s výchozí konfigurací. root@debian119:~# /etc/init.d/kamailio start [...] Starting Kamailio SIP server: kamailio:loading modules under /usr/local/lib/kamailio/modules_k/:/usr/lib/i386-linux-gnu/kamailio/modules/ Listening on udp: :5060 tcp: :5060 Aliases: tcp: localhost:5060 udp: localhost:5060 Kamailio lze ovládat pomocí shell skriptu kamctl, např. přidávat další uživatele pomocí kamctl add <username> <password>, restartovat kamct restart, vypisovat stavy přes kamctl monitor, atd. Provedeme vypsání online uživatelů kamctl ul show.. root@debian119:~# kamctl ul show Domain:: location table=512 records=2 max_slot=1 AOR:: 123 Contact:: sip:123@ :5060 Q= Expires:: 131 Callid:: @ Cseq:: 8 User-agent:: YATE/4.1.0 State:: CS_NEW Socket:: udp: :5060 Methods:: 543 Ruid:: uloc-52c369d3-b04-1 Reg-Id:: 0 Last-Keepalive:: Last-Modified:: AOR:: 111 Contact:: sip:111@ :43489;transport=udp Q= Expires:: 3194 Callid:: @ Cseq:: 1 User-agent:: Sipdroid/3.2 beta/gt-i9505 State:: CS_NEW Socket:: udp: :

185 12 Kamailio Methods:: Ruid:: uloc-52c369d3-b07-1 Reg-Id:: 0 Last-Keepalive:: Last-Modified:: root@debian119:~# Kamailio běží a můžeme registrovat klienty a provést hovor, viz. obr. 8.5, ve kterém je odpověď s 200 OK na žádost INVITE zachycená na SIP PROXY (Kamailio běží na ) a obsahuje v poli Via záznamy, podle kterých je tato odpověď směrována, rovněž vidíme, že Kamailio vložilo do zprávy pole Record-Route vyžadující zasílání veškerých zpráv v dialogu přes tuto SIP Proxy. Obr. 8.5 Potvrzení 200 OK na žádost INVITE 178

186 14 WebRTC a nové směry v IP telefonii 9 WebRTC a nové směry v IP telefonii Web Real-Time Communications (WebRTC) přináší novou funkcionalitu do webového prohlížeče, která umožňuje komunikaci v reálném čase. Vše je realizováno pomocí relativně jednoduchého API (Application Programming Interface) rozhraní jazyka Javascript a HTML5. WebRTC nabízí vývojářům webových aplikací schopnost psát multimediální aplikace v reálném čase (video, chat) na webu bez nutnosti instalace jakýchkoliv pluginů [wie]. Smyslem projektu WebRTC je vybudovat silnou RTC platformu, která bude pracovat ve většině webových prohlížečů. WebRTC je otevřený projekt a má rovněž podporu webových prohlížečů: Firefoxu, Chrome a Opery. Audio i video komunikace probíhá šifrovaně a bez problémů prochází i přes firewally, pro video WebRTC specifikuje používání kodeku VP8, za kterým stojí Google, ale kompresní formát je otevřený se zveřejněnými zdrojovým kódy a je implementován v knihovně libvpx (pod BSD licencí). Na konci roku 2013 společnost Cisco oznámila, že zveřejní svůj kodek, respektive implementaci, pro použití video formátu H.264 ve webových prohlížečích jako openh264 (a obdobně jako Google pod BSD licencí) s cílem podpořit technologie WebRTC. Obr. 9.1 Podpora WebRTC v Asterisku 179

187 14 WebRTC a nové směry v IP telefonii Asterisk podporuje WebRTC od verze 11, viz. obr. 9.1, kde byl vytvořen res_http_websocket modul a podpora pro web sokety přidána do chan_sip. Asterisk tedy umožňuje přes web sokety transportovat SIP. Rovněž má Asterisk podporu ICE, STUN a TURN v res_rtp_asterisk, což dává silnou podporu klientům za NATem. WebRTC vyžaduje zabezpečená média, což se řeší přes SRTP/SRTCP. S Asteriskem jsou možné dva scénáře, jednak komunikace mezi dvěma web prohlížeči, přičemž uživatelé ve svých prohlížečích vyplní své přihlašovací údaje ke svému účtu na Asterisku a můžou volat přímo z prohlížeče. Uživatel nic neinstaluje, postačí mu prohlížeč HTML5 a klient je spuštěn jako javascript při přístupu na webovou stránku, takovýmto prvním klientem s otevřeným kódem je sipml5 a francouzská společnost Duabango Telecom (založena v v roce 2011) stojící za tímto SIP HTML klientem uvádí funkčnost sipml5 na prohlížečích Chrome, Firefox, IE, Opera a Safari. Tím pádem lze takovéhoto klienta integrovat i do sociálních sítí (přidáním kódu na webovou stránku) jako FaceBook, Twitter, Google+, atd., přičemž není nutné instalovat žádný plugin nebo SW [joh]. Obr. 9.2 WebRTC signalizace a média v případě Asterisku I když obecně WebRTC popisuje komunikaci v tzv. WebRTC Web Triangle, kde pouze signalizace jde na Web Server s podporou RTC a média již napřímo, tak v případě Asterisku prochází signalizace i média skrz něj, viz. obr Výhodou ovšem je kontrola nad médii a zprostředkování GW i do jiných sítí než IP anebo protokolové GW, např. do Skype anebo Jingle (rozšíření komunikačního protokolu Jabber/XMPP), viz. obr Pokud jsme u XMPP, tak nepochybně stojí za zmínku, že přes WebRTC lze posílat i zprávy. WebRTC má velmi slibnou budoucnost, prohlížeč je prakticky ve všech koncových zařízeních, čili potenciál rozšiřitelnosti je značný, rovněž podpora za NATem a jednoduchost používání, to jsou atributy, které dávají této nové technologii velké šance na úspěch. Pro podporu WebRTC v Asterisk u při kompilaci spustíme make menuselect, kde vybereme res_http_websocket a res_rtp_asterisk a poté make install. Poté povolíme websocket v /etc/asterisk/http.conf. enabled=yes bindaddr=

188 14 WebRTC a nové směry v IP telefonii bindport=8088 Doporučeno je zabezpečit ještě zabezpečit http přístup pomocí TLS, což zajistíme úpravou v /etc/asterisk/http.conf. tlsenable=yes tlsbindaddr= :8089 tlscertfile=localhost.crt tlsprivatekey=localhost.key Obr. 9.3 Asterisk jako WebRTC Gateway Další konfigurace je v /etc/asterisk/sip.conf, kde povolíme transport přes web sokety. transport=ws,wss Přímo v nastavení uživatele ještě povolíme šifrování a podporu ICE protokolu. [1010] type=peer username=1010 host=dynamic secret=1010 context=default encryption = yes avpf = yes icesupport = yes ; AVPF and SAVPF to be used and the media streams to be accepted ; encryption media encryption is a requirement of rtcweb the following must be added to the peer, user, or friend to enable it. 181