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: 252 Vydala: Vysoká škola báňská-technická univerzita Ostrava Náklad CD-ROM, 500 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 70 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 Timestamp a rozptyl zpoždění Stanovení zpoždění z RTP Řídící protokol RTCP 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 Audio v přenosovém řetězci od odesílatele k příjemci Nároky na přenos audia v IP sítích Kodeky PCM ADPCM CELP 21 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 Hlasové brány 43 Signalizace v PSTN Siťová signalizace v digitálních sítích Účastnická signalizace v digitálních sítích Vlastnosti hlasové brány Modul FXS Modul FXO Modul EM 49 i

5 3.2.4 Moduly ISDN Konfigurace ISDN modulů v Cisco směrovačích Globální parametry nastavení 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ě 56 4 GNU Gatekeeper Instalace a konfigurace GnuGK Základní konfigurace po instalaci 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 69 5 Základy protokolu SIP 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 Transakce a dialog v příkladu SIP časovače a retransmise Zabezpečení v SIPu Registrace Směrování 96 ii

6 5.5.1 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 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 Vytočení kliknutím - Click to dial Zpětné volání Call Back Metoda INFO Využití DNS pro IP telefonii SRV záznamy NAPTR záznamy ENUM mapování E.164 a URI Prostory ENUMu Sestavení spojení s využitím DNS Konfigurace DNS pro účely ENUMu Budoucnost ENUMu SIPp a jeho použití k emulaci SIP relací Instalace Scénáře pro SIPp SIPp v příkazovém řádku 141 iii

7 8.2.2 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 MGCP a IAX2 protokol Media Gateway Control Protocol Architektura a základní rysy MGCP MGCP zprávy Příklad komunikace pomocí MGCP Inter Asterisk Exchange Protocol Formát rámce IAX Adresace v IAX Zprávy IAX Registrace pomocí IAX Příklad sestavení hovoru pomocí IAX Rozpad spojení v IAX 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 185 iv

8 Pobočky Priority Aplikace Tvorba dialplanu Vzory Pattern Matching 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 Aspekty kvality IP telefonie Kvalita služby (QoS) 222 v

9 13.2 IntServ IntServ Architektura a protokol RSVP DiffServ Architektura DiffServ DSCP značka Nástroje QoS Obsluha paketových front Metoda FIFO Metoda CQ Metoda WFQ Metoda PQ Metoda CBWFQ Metoda PQ/WFQ Metoda LLQ Řízení toku a zahlcení Komprese RTP a fragmentace Kvalita řeči Vliv zabezpečení na kvalitu hovoru RTP přes TLS RTP přes IPsec WebRTC a nové směry v IP telefonii 242 Literatura 246 Rejstřík 250 vi

10 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

11 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

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

13 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ž Timestamp a rozptyl zpoždění RTP pakety jsou odesílány obvykle v pravidelných intervalech Δt [s]. Pokud zachytíme RTP tok, tak tento interval zjistíme z časových značek (timestamp). Pro timestamp platí, že údaje v políčku jsou odvozeny od lineárního časového zdroje. Interval odesílání (timing) se z RTP paketů vypočte ze dvou po sobě jdoucích časových značek dle rovnice (1.2). timestamp {N+1} timestamp {N} t= (1.2) sampling_frequency Vzorkovací kmitočet je obvykle 8 khz, na obrázku níže jsou zachyceny RTP pakety s PCM kódováním G.711-Alaw. Rozdíl dvou po sobě jdoucích údajů zachycených na obr.1.4. v položce Time úplně vpravo (timestamp) je 160, pochopitelně odcházejících ze stejné IP adresy (source). Po vydělení vzorkovacím kmitočtem 8 khz dostáváme 20 ms, což je časování odesílání paketů ze zdroje. V uvedeném případě můžeme očekávat tedy 50 paketů za sekundu. Obr Inkrementace hodnoty pole timestamp. Ačkoliv datagramy byly odeslány v intervalech 20 ms, tak pokud bychom určili rozdíly mezi vyslanými na straně odesílatele a srovnali je s rozdíly mezi přijatými datagramy na straně příjemce, zjistili bychom, že se liší. Jelikož pakety neměly stejné podmínky přenosu, způsobené především odlišným časem stráveným ve frontách na směrovačích, tak došlo k rozdílu mezi časem skutečného a očekávaného příchodu, tento rozdíl označujeme jako rozptyl (jitter). 4

14 1 Přenos sítí Internet v reálném čase Označme Si jako hodnotu časové značky v i-tém RTP paketu (timestamp) a Ri čas skutečného doručení paketu i příjemci, potom pro dva dva pakety i a i-1 bude platit pro výpočet rozptylu jejich doručení příjemci rovnice (1.3): D (R R ) (S S ) (R S ) (R S ) (1.3) i i i1 i i1 i i i1 i1 Podmínkou platnosti vztahu je, že RTP pakety jsou přijaty z jednoho zdroje synchronizace (SSRC pole v RTP hlavičce). Obr Rozptyl zpoždění zjištěný při příjmu RTP toku. Zatímco Di [ms] představuje okamžitý jitter, tak v praxi se využívá k sledování rozptylu klouzavý průměr, který reflektuje jeho dosavadní průběh, na druhé straně je ale potřebnost rychlé konvergence k aktuálním hodnotám. Pro tento účel se nejčastěji používá následující vztah pro výpočet sledované hodnoty rozptylu Ji, přičemž empiricky získaná hodnota 16 zahrnující průměr 16-ti předchozích rozptylů reflektuje vlastnosti zmíněné v předchozí větě. [ Di J i1] 15 Di Ji Ji 1 Ji 1 (1.4) Stanovení zpoždění z RTP RCTP XR definuje rozšířené posílání zpráv XR (Extended Reports) v rámci dohledu nad RTP tokem, které zajišťuje protokol RTCP (Real Time Control Protocol). RTCP XR je obsažen v doporučení RFC 3611 z konce roku 2003, XR pakety jsou složeny z jednotlivých bloků oznámení (report blocks) a jedním z těchto bloků je i VoIP Metrics Report Block, který uceleně informuje o kvalitativních parametrech VoIP. RTD ESD(A) ESD(B) OWPD (1.5) 2 5

15 1 Přenos sítí Internet v reálném čase Jednosměrné síťové zpoždění OWPD (1.5) může být stanoveno z RTD (Round Trip Delay) [ms], což je doba oběhu zprávy od odesílatele k příjemci a zpět neboli odezva. Jelikož je nutné vyjádřit celkové E2E zpoždění, tak RFC 3611 zavádí parametr odhadu systémového zpoždění ESD (Estimated System Delay) [ms], který je definován součet všech přírustků zpoždění na zařízení. RTCP-XR stanovuje, že na straně vysílací je v ESD(A) zahrnuto celkové zpoždění vzniklé kódováním a paketizací, na straně přijímací je ESD(B) tvořenou součtem nastavené doby mezipaměti vyrovnání rozptylu (de-jitter buffer) a zpožděním při dekódování. Je zaveden parametr jednosměrného symetrického zpoždění hlasové cesty OWPD (one way symmetric voice path delay), který je vyjádřen vztahem (1.5). 1.4 Ří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.5 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]. 6

16 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 7

17 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.9, 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 8

18 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 9

19 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. 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 10

20 1 Přenos sítí Internet v reálném čase 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 11

21 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.12, 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 12

22 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.6 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ů: 13

23 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

24 1 Přenos sítí Internet v reálném čase 1.7 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) 15

25 1 Přenos sítí Internet v reálném čase 1.8 Audio v přenosovém řetězci od odesílatele k příjemci V řetězci cesty audia od odesílatele k příjemci nacházíme tři podstatná místa, viz. obr.1.15 [v111]: u odesílatele dochází k paketizaci audia a odeslání RTP paketů, IP sítí probíhá přenos RTP v Internetu, a nakonec u příjemce se opětovně získávají hlasové informace z RTP paketů. Místa výše uvedená jsou zdrojem zpoždění, které může zásadním způsobem ovlivnit výslednou kvalitu řeči. Komponenty zpoždění v souladu s jejich umístěním můžeme klasifikovat následovně: paketizační zpoždění (packetization) a zpoždění v kodéru (coder), zpoždění čekáním ve frontách (queuing), serializační (serialization) způsobené odesíláním přes rozhraní síťových zařízení a propagační (propagation) způsobené šířením signálu přenosovým prostředím nakonec zpoždění v mezipaměti přijímače (De-jitter) a zpoždění při zpracování přijaté informace na dekodéru (decompression). Obr Identifikace míst komunikačního řetězce, kde vzniká zpoždění. Při zpracování audio signálu na straně odesílatele dochází k následujícím operacím [v111]: audio je kódováno na kodéru (např. do formátu PCM), bitový tok z kodéru je doslova naporcován do balíčků o konstantní velikosti (u PCM jsou to balíčky o velikosti 160B), k užitečné zátěži s audio informací dochází k přidání RTP hlavičky (12B) a UDP hlavičky (8B) a IP hlavičky (20B), audio je enkapsulováno napříč jednotlivými protokolovými vrstvami, nakonec dojde k vytvoření rámce (doplnění fyzických adres a kontrolního součtu) a jeho odeslání. 16

26 1 Přenos sítí Internet v reálném čase Obr Cesta audia od odesílatele a jeho zpracování u příjemce. Při přenosu audia IP sítí dochází k časovému posunu mezi RTP pakety především vlivem jejich řazení ve frontách na směrovačích, viz. obr a vzniká jitter, což bylo již vysvětleno v kapitole 1.2. Na tento problém bylo pamatováno při návrhu standardu RFC 1889 pro RTP protokol a v hlavičce paketu je přenášena položka Timestamp vyjadřující vzorkovací značku v RTP paketu odvozenou od lineárního časovače. Díky této značce je možné jitter přesně rozpoznat a jeho vliv eliminovat. Na straně příjemce je přijatý paket zařazen do vyrovnávací mezipaměti (de-jitter buffer neboli playout buffer), tím je minimalizován vliv rozptylu zpoždění, viz. obr Následně jsou data z mezipaměti předávány k dekódování, mezipaměť je vhodné nastavit na násobky dob trvání kódovaných hlasových fragmentů při paketizaci (např. 60 ms je nejvhodnější, neboť vyhovuje pro kódování G.711, G.729 i G ), některá zařízení umožňují samokorekci velikosti mezipaměti a pomocí adaptivních algoritmů přizpůsobují její hodnotu aktuální situaci. Obr Řazení ve frontách směrovačů. 17

27 1 Přenos sítí Internet v reálném čase 1.9 Nároky na přenos audia v IP sítích Základními kroky předcházející odeslání hlasu v RTP paketu je kódování určitým typem kodeku a paketizace. RTP pakety jsou odesílány v dedikovaných intervalech a načasování odeslání bude záviset jednak na velikosti užitečné zátěže a jednak rychlosti výstupního toku z kodéru. Základní rovnice, která vyjadřuje časování odesílání RTP je vyjádřena jako P t= C S (1.7) R t [s] je časování, P [b] je velikost užitečné zátěže a kde S C R [bit/s] představuje rychlost proudu bitů z kodéru. Informace o časování jsou uloženy v RTP paketech v časových značkách (timestamp) a mohou být zpětně získány, viz. vztah (1.1). Na aplikační vrstvě můžeme do vztahu (1.8) vyjádřit jednak payload P a velikost RTP hlavičky H, což je 12B. S RTP SAL HRTP PS (1.8) Nyní je důležité vyjádřit velikost dalších hlaviček v jednotlivých vrstvách OSI modelu, což je provedeno jako suma 3 j1 H j. Jednak se jedná o 8B na UDP, 20B na IP poté 26B v případě Ethernetu jako velikost polí v rámci IEEE Nyní můžeme vyjádřit hodnotu BW M nárokovaného pásma RTP toků pro M hovorů jako sumu jednotlivých příspěvků velikosti rámců S Fi, které je nutné přenést v intervalu t : BW M S Fi M i1 ti (1.9) Pokud všechny hovory používají stejný kodek, tak (1.7) a (1.8) do vztahu (1.9) získáváme pro výpočet nároků všech RTP toků (1.10). 3 H RTP H j j1 BW M M C R 1 P S (1.10) Z výše uvedené rovnice můžeme graficky vyjádřit, jak závisí nárokované pásmo na velikosti užitečné zátěže v RTP a počtu hovorů, obr Ve 3D zobrazení vidíme, že s klesající velikostí užitečné zátěže rostou nároky na pásmo, což je způsobeno režií hlaviček, jejichž poměr vůči klesajícímu množství přenášené informaci roste. 18

28 1 Přenos sítí Internet v reálném čase Obr Závislost pásma na velikosti zátěže a počtu hovorů 1.10 Kodeky Kodek je zařízení nebo algoritmus, který slouží ke zmenšení jinak zbytečně velkého objemu audiovizuálních dat. Slovo kodek vzniklo složením slov kodér a dekodér, tj. zařízení jež je na jedné straně schopné data zakódovat a na druhé straně opět rozkódovat. Při použití osobního počítače je typicky vstupem kodeku zvuková karta, data získaná z mikrofonního vstupu kodér zpracuje a předá je RTP vrstvě, vzniklé protokolové datové jednotky se enkapsulují v jednotlivých vrstvách OSI modelu, až jsou nakonec vyslána příjemci. Přijatá data převede do původní podoby dekodér a pošle na audio výstup zvukové karty. Kodeky velmi často používají ztrátovou kompresi a proto dekódovaná data nejsou totožná s daty, která byla zakódována. Tato kapitola je věnována popisu kodeků, které se v IP telefonii nejčastěji vyskytují. Zdrojem hovorového signálu jsou řečové orgány, které se skládají z hlasivek, hrdelní dutiny, ústní dutiny, nosní dutiny, měkkého a tvrdého patra, zubů a jazyka. Zdrojem buzení této soustavy jsou plíce ve spolupráci s dýchacími svaly. Vlivem tlaku proudu vzduchu vycházejícího z plic dochází k jeho modulaci hlasivkami. Kmitočet závisí na tlaku vzduchu na svalovém napětí hlasivek. Kmitočet hlasivek je charakterizován základním tónem lidského hlasu, který tvoří základ znělých zvuků. Kmitočet základního tónu je různý u dětí, dospělých, mužů i žen, pohybuje se většinou v rozmezí 150 až 400 Hz. V klidu je štěrbina hlasivek otevřena a proud vzduchu volně prochází hlasivkami. Vytvářený zvuk je po průchodu hlasivkami formován ústní dutinou a je vyřazován do volného prostoru. Sdělení zprostředkované řečovým signálem je diskrétní, tzn. může být vyjádřeno ve tvaru posloupnosti konečného počtu symbolů. Každý jazyk má vlastní množinu těchto symbolů - fonemů, většinou 30 až 50. Lidská řeč je souvislý časově proměnný proces, z toho plyne i náročnost popisu lidské řeči a jejího modelování. Hovorový signál snímáme mikrofonem, který převádí modulovaný proud vzduchu na elektrický signál. Přístupy ke kódování jsou následující: 19

29 1 Přenos sítí Internet v reálném čase kódování vlny (waveform coding), zpracování vychází z přeměny hovorového signálu ve tvaru elektrického signálu. Tento signál je vzorkován, kvantován a následně kódován, kódování parametrů zdroje hovorového signálu (Source Coding), a hybridní, do této kategorie patří kodeky založené na adaptivních predikčních metodách, na metodách vektorové kvantizace, složkovém kódování anebo adaptivním transformačním kódování PCM Nejznámější a nejpoužívanější kodek je PCM ITU-T G.711, výstupem kodéru je bitový tok 64 kbit/s. Kódování PCM (Pulse Code Modulation) se sestává ze tří kroků: vzorkování 8 khz, hodnoty spojitého analogového signálu ve frekvenční oblasti Hz se odečítají v diskrétním čase, kvantování, ke každému vzorku získanému v předchozím kroku se přiřadí bitová sekvence z možných diskrétních úrovní, a nakonec kódování. Vzorkuje se 8 khz a jednotlivé vzorky jsou reprezentovány osmibitovými sekvencemi. Při kvantování ovšem vzniká kvantizační zkreslení, protože každému vzorku je přiřazen jemu nejbližší kvantizační stupeň a počet hodnot je omezený. Kodér přiřadí každému kvantizačnímu stupni číselnou kódovou kombinaci a kvantovaný vzorek do ní zakóduje. Příčinou kvantizačního zkreslení je rozdíl mezi nekonečným počtem vstupních a konečným počtem výstupních hodnot, nižší hodnoty budou u lineární stupnice více zkresleny. Proto se u digitálních modulací používá komprese, výšky malých vzorků se zvýrazní a výšky velkých vzorků se ponechají tak, aby útlum kvantizačního zkreslení byl konstantní. Pomocí expanze v přijímači se vzorkům vrátí původní rozsah a poměr jednotlivých výšek. Pro zajištění rovnoměrné hodnoty odstupu kvantizačního zkreslení se v pracovním rozsahu kodéru PCM používají logaritmické křivky A-law a µ-law (Severní Amerika). Použítí logaritmické kvantizační stupnice namísto lineární nízké hodnoty vzorků se na vysílací straně zesílí a vysoké naopak zeslabí. Na přijímací straně proběhne inverzní proces ADPCM Kódování ADPCM (Adaptive Differential Pulse Code Modulation) vychází z DPCM. Kódování DPCM (Differential Pulse Code Modulation) je modifikací PCM kódování, nekódují se navzorkovaná data, ale jejich rozdíl oproti odhadnutému průběhu signálu, průběh signálu je možné částečně odhadnout, navzorkovaný průběh a odhadnutý průběh jsou si podobné, výsledný rozdíl má mnohem menší dynamický rozsah a je možné ho zakódovat pomocí menšího počtu bitů, tedy množství přenášených dat se snižuje. ADPCM je vylepšeno tak, že generátor srovnávacího průběhu je adaptivní a přizpůsobuje se konkrétní řeči, která se kóduje. Výsledkem je ještě menší dynamický rozsah než v případě DPCM a tedy opět menší počet bitů nutný k zakódování. Kromě toho se mění i vlastnosti kvantifikace pro charakteristiku konkrétní řeči. Nejznámějším představitelem ADPCM je ITU-T G.726 (32 kbit/s), ale jsou možné i jiné rychlosti výstupního toku z kodéru v závislosti na 20

30 1 Přenos sítí Internet v reálném čase použitém adaptivním algoritmu, G.726 a G.727 umožňují 40, 32, 24 a 16 kbit/s. Vůbec prvním standardem ADPCM bylo doporučení ITU-T G.721 pro 32 kbit/s. LPC LPC (Linear Predictive Coding) je způsob kódování založený na úplně jiném principu než PCM nebo ADPCM, ty vycházely z kvantifikace průběhu signálu. Metoda LPC vychází naopak ze znalostí o mluvícím traktu (tj. hlasivkách a krku). Tato metoda se snaží vytvořit model hlasového ústrojí člověka. LPC využívá předpokladu že hlasový signál je generován bzučákem na konci trubky, štěrbina mezi hlasivkami produkuje bzukot, který je charakterizován hlasitostí a frekvencí. Mluvící ústrojí (krk, ústa) vytváří trubku, která je charakterizována svými rezonancemi nazývanými formanty. LPC analyzuje řeč aproximováním formantů, odstraněním jejich působení z hlasového signálu a odhadem intenzity a frekvence zbývajícího signálu, který je generován hlasivkami. Proces odstranění formantů se nazývá inverzní filtrování. LPC vytváří signál řeči obráceným procesem, vygeneruje se signál s příslušnou hlasitostí a frekvencí a z formantů se vytvoří filtr. Tímto filtrem se potom vygenerovaný signál zpracuje a výsledkem je signál podobný původnímu signálu řeči. Protože vstupní signál se mění v závislosti na čase, je nutné tento proces opakovat pro kratší časové intervaly, tzv. rámce. Pro rozumnou kvalitu výsledné řeči se používá 30 až 50 rámců za vteřinu. Představitelem je LPC kodek s výstupním tokem 4,8 kbit/s nebo kodek LPC-10 s tokem 2,4 kbit/s. Obr MOS v závislosti na bitové rychlosti kodeků CELP Kódování CELP (Code Excited Linear Prediction) zásadně vylepšuje LPC. Problém metody LPC je v tom, že to, co zbude po odfiltrování formantů, není pouze signál bzučáku. Důvodem je, že v řeči se vyskytují složky reprezentující třeba sykot. Takovéto zvuky nebudou jednoduchým LPC kodekem správně aproximovány. Nepřesnosti při odhadu formantů způsobí, že více informací o signálu zůstane v reziduu (zbytek po odfiltrování formantů). To platí pro zvuky které neodpovídají 21

31 1 Přenos sítí Internet v reálném čase jednoduchému LPC modelu, platí to například pro zvuky generované různou pozicí jazyka atd. Tedy reziduum obsahuje důležité informace o tom, jak má řeč znít, tyto informace se zakódováním pomocí LPC ztratí, protože reziduum se zakóduje pouze pomocí dvou parametrů, frekvence a amplitudy signálu. Vzniká tedy otázka, jak reziduum zakódovat lépe tak, aby se příliš nezvýšil nárok na šířku pásma a tyto důležité informace se přitom neztratily. Jednou z nejúčinnějších metod je použití codebooku. Kódová kniha je tabulka obsahující typické průběhy rezidua. Kodér potom porovnává průběh rezidua s hodnotami v tabulce a použije tu, která odpovídá nejvíc, index této hodnoty z tabulky se potom přenáší. Druhá strana má stejnou tabulku a po příjmu indexu dokáže průběh rezidua z tabulky obnovit, toto reziduum potom slouží jako budič pro filtr aproximující formanty. Výsledkem je lepší aproximace hlasového signálu než v případě jednodušší metody LPC. Tato metoda se nazývá Code Excited Linear Prediction, zkratka CELP. Aby metoda CELP správně fungovala, tabulka obsahující typické průběhy rezidua musí být velmi rozsáhlá, pokud je ale tabulka velká, bude vyhledávání v tabulce trvat rovněž velmi dlouho. Dalším problémem je, že tabulka by musela obsahovat vzorky pro různě vysoký hlas, taková tabulka by však byla extrémně rozsáhlá. Tento problém se řeší vytvořením dvou tabulek. Jedna tabulka je vytvořená při tvorbě kodeku a obsahuje vzorky pro právě jednu výšku hlasu. Druhá tabulka je adaptivní, ze začátku je prázdná a průběžně se plní předešlými vzorky rezidua zpožděnými o určitou hodnotu. Právě hodnota zpoždění určuje výšku hlasu, popsaný algoritmus poskytuje dobrou kvalitu přenášené řeči už při šířce pásma 4,8 kbit/s. Typickými představiteli jsou ACELP dle G s tokem 5,3 kbit/s, CS-ACELP dle G.729 s tokem 8kbit/s anebo LD-CELP dle G.728 s tokem 16 kbit/s. Tab. 1.1 Typ kódování, MOS, rychlost a náročnost na výpočetní výkon. Mezi modifikace CELP patří ACELP (Algebraic Code Excited Linear Prediction), LD-CELP (Low Delay Code Excited Linear Prediction) a CS-ACELP (Conjugate Structure Algebraic Linear Code Prediction). Následně si popíšeme nejpoužívanější kodeky, ty jsou specifikovány v doporučeních ITU-T: G.711 je základní kodek PCM, který se používá i v klasické telefonní síti. Kvalita přenášeného hlasu je totožná s kvalitou hlasu při běžném telefonním hovoru, MOS má hodnotu 4,2, rámec trvá 0,125 ms; 22

32 1 Přenos sítí Internet v reálném čase G používá buď kódování MP-MLP nebo ACELP. První typ kódování vyžaduje šířku pásma 6,3 kbit/s, druhý typ 5,3 kbit/s. Jeden rámec obsahuje úsek trvající 30 ms a MOS skóre je 3,9 při použití kódování MP-MLQ a 3,65 při použití ACELP; G.726 kodek používá kódování ADPCM, potřebná šířka pásma je 16, 24, 32 a 40 kbit/s. Kodek může zpracovávat bloky různé délky podle toho, jak velké zpoždění je požadováno, pro 32 kbit/s se uvádí MOS=3,85; G.728 používá kódování LD-CELP. Potřebná šířka pásma je 16 kbit/s, MOS skóre je přibližně 3,6; G.729 Použité kódování je CS-ACELP - Conjugate Structure Algebraic Code Excited Linear Prediction. Rámec trvá 10 ms a potřebná šířka pásma je 8 kbit/s, MOS je hodnocen 3,92; GSM kodek, šířka pásma je 13 kbit/s (Full Rate GSM FR). Kodek je založen na kódování LPC. Dalším rozšířením v roce 1997 byl kodek GSM EFR (Enhanced Full Rate, GSM 06.60) s rychlostí 12,2 kbit/s a rámcem 20 ms (obsahuje 244 bitů). V roce 1998 přišlo další kódovací schéma, a to AMR kodek (Adaptive Multi-Rate), který je používán i v UMTS. AMR používá ACELP techniku kódování a rychlosti se pohybují od 4,75 (AMR 4,75) do 12,2 kbit/s (AMR 12,2). AMR 12,2 je kompatibilní s GSM EFR. ilbc - internet Low Bit Rate Codec, tento kodek byl vyvinut firmou Global IP Sound, potřebná šířka pásma je kbit/s, rámec obsahuje úsek trvající 30 ms. Kodek umožňuje elegantní snížení kvality přenášeného signálu v případě zpoždění nebo ztráty paketů. Použitý algoritmus je Block Independent Linear Predictive Coding. Každý rámec je komprimován na 399 bitů, které se potom přenáší. G.722 je wideband hlasový kodek z roku 1988 pracující se šířkou pásma 50Hz-7 khz s typickým výstupním proudem 64 kbit/s., technologie je postavena na SB-ADPCM (sub-band ADPCM). Dalšími 7 khz wideband kodeky jsou G a G.722.2, tyto kodeky nejsou deriváty původní G.722, ale využívají jiné kompresní algoritmy. G (Siren codec) se vyznačuje výkonnou kompresí s typickým proudem 24 nebo 32 kbit/s. Novější G známá jako AMR-WB (Adaptive Multirate Wideband) vychází z ACELP kódování a vyznačuje se jednak silnou kompresí (až 6,6 kbit/s) a schopností adaptovat kompresní algoritmus na aktuální situaci. Tab. 1.2 Typ kódování, rychlost, typická paketizace, rámec a zpoždění. V tabulce 1.2 můžeme vidět srovnání nejpoužívanějších kodeků, ve čtvrtém sloupci tabulky je uvedena typické časování odesílání paketů, v dalším sloupci je doba trvání rámce a po sečtení s 23

33 1 Přenos sítí Internet v reálném čase look-ahead (dopředným výpočetním zpožděním u kodeků pracujících s predikcí) dostaneme celkové minimální zpoždění, které lze u kodeku teoreticky dosáhnout. V posledním řádku je použit kodek G.729A, což je dodatek ke kodeku G.729, tento dodatek implementuje G.729 s nižší výpočetní náročností, G.729A vyžaduje pouze 11 MIPS, klesá ale MOS na 3,6. Dalším používaným dodatkem G.729 je implementace detekce ticha VAD s označením G.729B, často najdeme i kodek s oběma dodatky s označením G.729AB. Implementace VAD do G je označována jako G.723.1A. VAD (Voice Activity Detection) nebo taky někdy označována jako SS (Silence Suppression) je funkce potlačení ticha, ticho během hovoru se nepřenáší, neboť nenese žádnou informaci. V průměrném hovoru ticho tvoří 40-60% celkové doby spojení. Během ticha se tedy nebudou přenášet RTP pakety a u příjemce se zapne generování šumu CNG (Comfort Noice Generator). Princip aktivace a deaktivace SS je založena na překročení prahových úrovní odstupu signálu od šumu, pokud se detekuje úroveň signálu setrvávající stanovený čas pod či nad prahovou úrovní, tak se aktivuje či deaktivuje SS. V praxi je ovšem zkušenost taková, že funkce VAD může způsobovat ořezávání prvních slabik slov po odmlkách, jelikož aktivace je záležitostí typicky cca 20 ms, funkce VAD proto není používána při broadband konektivitě. Cisco IOS má pro aktivaci a deaktivaci jednoduché příkazy, a to VAD a no VAD, pokud ovšem není použita G.729B či G.723.1, potom je VAD součástí kodeku a funkce se nedá řídit. 24

34 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. 25

35 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ě vyvíjený standard. 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, ), 26

36 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, 27

37 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

38 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ředešlé 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 29

39 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 30

40 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é 31

41 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 32

42 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 33

43 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 34

44 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 definovány zprávy BRQ/BCF/BRJ, což je Bandwidth Request/Confirm/Reject. Pro ukončení hovoru 35

45 2 Standard ITU-T H.323 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 36

46 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). 37

47 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. 38

48 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. 39

49 2 Standard ITU-T H.323 Tab 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. Signalizace v módu GRC může být tedy provozována následovně: 40

50 2 Standard ITU-T H.323 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

51 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. 42

52 3 Hlasové brány 3 Hlasové brány Ideálním stavem pro IP telefonii by bylo využívání pouze VoIP technologie, ale jelikož v roce 2013 bylo na světě IP telefonie přes 7 mld. telefonních čísel fungujících na jiné technologiee (v roce 2000 to bylo 2,5 mld.), tak j nutné zajistit interoperabilitu se stávajícími telefonními sítěmi. Například v roce 2013 bylo v ČR cca 500 tis. IP telefonů, 13 mil. mobilních telefonů a cca 3 mil. telefonních čísel na pevných linkách (převážně podniková telefonie). Signalizace v PSTN Signalizace se dělí na účastnickou, síťovou a vnitřní, rozdělení je dle místa použití, viz. obr. 3.1, S postupem vývoje se sjednotila nejdříve vnitřní se síťovou signalizací (u SS7 se je vnitřní a síťová identická) a následně i účastnická (pokud je používána IP telefonie jak pro trunk tak pro účastníka,, tak veškerou signalizaci může přenášet jeden protokol, např. SIP) a dělení je již pouze logické. V současné době jsou používány v sítích s propojováním kanálů následující typy signalizací: smyčková (loop) na analogových přípojkách, digitální účastnický signalizační systém č.1 (DSS1) na ISDN účastnických přípojkách, signalizační systém č.7 (SS7) na ISDN propojích spojovacích systémů. SIP u IP telefonů a u SIP trunků Obr 3.1 Dělení signalizace dle místa použití. 43

53 3 Hlasové brány V sítích pobočkových ústředen jsou používány navíc ještě další typy signalizací, se kterýma se setkáme v podnikových sítích: Q-signalizace (QSIG) se používá pro vzájemné ISDN propojení pobočkových ústředen [v44], EM signalizace se používá pro analogové propojení PBX různých výrobců. u IP telefonie v případ PBX Asterisk se může použít IAX trunk při propojení PBX a rovněž pro IAX IP telefon Siťová signalizace v digitálních sítích Ve veřejné síti je od roku 1997 pro propojení spojovacích systémů použit signalizační systém č.7. Architektura sítě signalizačního systému č.7 (SS7) se skládá ze třech základních komponentů: SSP (Signal Switching Point), STP (Signal Transfer Point), SCP (Signal Control Point). Obr 3.2 Signalizační síť SS7. SSP jsou koncové body sítě, ve kterých vznikají požadavky na spojení a kam jsou zároveň tyto požadavky terminovány. STP jsou tranzitní body, které směrují zprávy SS7 a rozdělujeme je do třech úrovní: National Signal Transfer Point (národní), International Signal Transfer Point (mezinárodní), Gateway Signal Transfer Point (protokolové brány). Jednotlivé komponenty SS7 sítě jsou propojeny do struktury vytvářející signalizační síť, viz. obrázek níže. 44

54 3 Hlasové brány Uvedeme si vybrané vybrané signalizační zprávy SS7: IAM (Initial Address Message) Tato zpráva se používá pro inicializaci hovorového spojení. Mimo informace o čísle volaného obsahuje další parametry týkající se např. typu spojení, zda je použito potlačení echa, ACM (Address Complete Message) Zpráva je posílána v opačném směru než IAM a indikuje, že hovor je zpracováván, například účastník je vyzváněn. ANM (Answer Message) Zpráva indikující přijmutí hovoru, CPG (Call Progress Message) Tato zpráva slouží k informování vzdálené strany (ústředny) o nějaké události týkající se hovoru, REL (Release Message) Zpráva informující o ukončení hovoru, RLC (Release Komplete Message) Tato zpráva se posílá jako potvrzení o ukončení hovoru a uvolnění spojovací cesty Účastnická signalizace v digitálních sítích Jako účastnická signalizace se v ISDN používá DSS1, a to jak pro připojení koncových terminálů, tak pro připojení pobočkových ústředen pomocí BRI či PRI přípojek. Základní přístup je označován jako BRI (Basic Rate Interface) a má sktrukturu 2B + D, kde B je informační kanál s užitečnými daty o rychlosti 64 kbit/s a D je signalizační kanál 16 kbit/s. Primární přístup je označován jako PRI (Primary Rate Interface) a má strukturu 30B + D, kde D má rychlost 64 kbit/s a používá se klasický 32 kanálový multiplex s připojením na metalickém rozhraní dle ITUT G.703 (2.048 kbit/s). Uvedeme si vybrané signalizační zprávy DSS1: SETUP (Sestavování volání), žádost o sestavení spojení. Při blokové volbě obsahuje zpráva všechny potřebné informace pro spojení, při postupném vysílání volaného čísla zpráva obsahuje jen část nebo žádné adresné informace, SETUP ACKNOWLEDGE (Potvrzení sestavování volání), potvrzení zprávy SETUP, pokud je volba neúplná, CALL PROCEEDING (Sestavování spojení), ústředna již nepotřebuje další informace pro spojení, probíhá sestavování spojení, ALERTING (Vyzvánění), spojení bylo vybudováno k požadovanému cíli, volaný terminál je ve stavu přijmout volání, tj. vyzvání CONNECT (Propojení), příchozí volání bylo volaným terminálem přijato (vyzvednutí), B kanál byl propojen, CONNECT ACKNOWLEDGE (Potvrzení propojení), potvrzení zprávy CONNECT, spojení bylo navázáno, DISCONNECT (Rozpojení), výzva k rozpadu spojení (zavěšení), RELEASE (Vybavení), odpověď na DISCONNECT, uvolnění B kanálu a požadavek na uvolnění Call Reference, RELEASE COMPLETE (potvrzení vybavení), potvrzení RELEASE, uvolňuje se Call Reference, což je jedinečný identifikátor spojení, INFORMATION (Informace), pomocí této zprávy se přenášejí informace mezi terminálem a ústřednou (např. volba), 45

55 3 Hlasové brány PROGRESS (Sestavování spojení s jiným účastníkem), označuje určitou fázi výstavby spojení a oznamuje, že další signalizace je již v B kanále realizována (např. oznamovací tón), FACILITY (Schopnost), terminál nebo ústředna vyžaduje pro existující spojení doplňkovou službu. 3.2 Vlastnosti hlasové brány Hlasová brána VoGW (Voice Gateway) je klíčovou částí služeb IP telefonie, neboť umožňuje spojení mezi telefonní a paketovou sítí, to znamená, že provádí veškerý nezbytně nutný fyzický překlad a hlasovou kompresi a tím dovoluje volání mezi těmito dvěma prostředími. Brány s analogovým rozhraním mohou obsahovat jednak rozhraní U s moduly FXS a FXO a jednak rozhraní EM. Digitální brány budou mít většinou jeden z ISDN přístupů, a to BRI nebo PRI, výjimečně se může vyskytnout i některá starší CAS signalizace na PCM 30/32. Uveďme si charakteristiku brány: počet současně realizovatelných hovorů s daným kodekem, tato výkonnost je ovlivněna nejen SW, ale hlavně typem a počtem DSP, některé GW mají modulární koncepci DSP (dají se přidávat), podporovaná rozhraní a jejich počet, podporované signalizace na straně telefonní sítě a IP sítě, způsob konfigurace brány a její dohled (např. podpora CLI, webový přístup, dohled SNMP, podpora RADIUS, atd...), zábrana echo (výkonnější je pochopitelně HW implementace echo-cancellation). Echo v hovoru vzniká nežádoucím odrazem hovorového signálu zpět k hovořícímu účastníkovi a negativně ovlivňuje kvalitu, jelikož ozvěny vlastních slov působí pro hovořícího rušivě. Echo vzniká ze dvou základních příčin, které jsou i důvodem pro rozdělení na akustické a elektrické echo. Akustické echo vzniká částečným přenosem signálu ze sluchátka zpět do mikrofonu na straně naslouchajícího účastníka a nejčastěji vzniká u mobilních, bezdrátových telefonů a při hlasitém příposlechu. Typicky je známé zavazbení signálu, které vede až k rozpískání, pokud je IP telefon tvořen počítačem s reproduktory a stojánkovým mikrofonem. Tento typ echa není tak významný, jelikož se s ním velmi dobře vypořádají echokancelátory (potlačovače echa), které pracují s algoritmy eliminujícími jeho vliv. Elektrické echo vzniká nevyvážeností telefonní vidlice přechodu 4-dr. vedení na 2-dr., typicky je to v místech napojení analogových telefonních přístrojů. Na vyvážení telefonní vidlice se podílí kvalita řešení vidlice a vyvažovače, vlastnosti přípojného vedení (účastnické vedení může mít i pár metrů, ale i přes deset km) a impedance přístroje (teoreticky 600 Ω). Echo vzniká na straně naslouchajícího účastníka, ale negativně se projeví u hovořícího, teoreticky je možné i echo echa (druhý odraz hovoru), který ovšem v praxi není znám. Elektrické echo nemůže vznikat na částech spojení, které mají povahu 4-dr. Pokud se odražený signál vrací do 25 ms, tak hovor neovlivňuje a pro člověka se zdá přirozené, se vzrůstajícím časem se zvyšuje negativní vliv na hovor, který závisí pochopitelně i na úrovni 46

56 3 Hlasové brány vracejícího se signálu Loudness Rating). TELR, což je míra hlasitosti ozvěny na straně hovořícího (Talker Echo Většina GW umí generovat záznamy o spojení CDR a předávat je (např. pomocí RADIUS protokolu), vždyť přes GW odchází hovory do veřejné telefonní sítě, kde je spojení spojeno s nějakým poplatkem. Call Detail Record (CDR) je detailní záznam volání obsahující nejčastěji tyto informace: identifikace volajícího, identifikace volaného, začátek hovoru, délka hovoru, identifikace vedení či poskytovatele (operátora). Případně mohou CDR obsahovat další informace, kterými jsou: identifikace tranzitu spojení (přes které body spojení šlo), bližší identifikace vedení (adresa pro trunk), počet použitých kanálů, délka vyzvánění, identifikace služby (voice, fax, data), kód volání(soukromý, služební), identifikace PINem, typ PINu, autorizace, délka vyzvánění, příčina rozpadu spojení. CDR záznamy se obvykle ukládají v databázích, jejich zpracování je závislé na typu použité technologie, v případě klasických PBX jsou dočasně uchovávány v pamětech (flash, HDD...) a vyčítány v intervalech přes sériové rozhraní nebo pomocí IP. Jelikož se pomocí GW realizuje propojení často s veřejnými telekomunikačními sítěmi, tak je nutné splňovat pravidla číslování, ty jsou stanovena číslovacím plánem a v digitálních sítích se řídí dle ITU-T E.164. V ITU T E.164 (The international public telecommunication numbering plan) je doporučení obsahující specifikaci mezinárodního veřejného číslovacího plánu telekomunikační sítě. Struktura geografických čísel má následující části: CC: Country Code (kód země), NDC:National Destination Code (směrové číslo oblasti), SN:Subscriber Number (účastnické číslo). CC může být 1-3 místné číslo a CC + NDC + SN může být max. 15-ti místné číslo. Struktura geografických čísel má dvě možnosti: 47

57 3 Hlasové brány první možnost, oddělené NDC a SN, druhá možnost, spojené NDC a SN, což znamená že národní účastnické číslo obsahuje obě části Modul FXS Modul FXS (Foreign Exchange Station) poskytuje připojení na účastnickém rozhraní U se smyčkovou signalizací, umožňuje DTMF volbu dle doporučení ITU-T Q.23. Modul FXS pracuje v režimu analogové účastnické sady, na rozhraní lze připojit přímo telefonní přístroj. V případě připojení pobočkové ústředny (dále jen PBX) se linka přivádí na port karty státního přenašeče standardně používaného pro připojení státní linky. Provozovat modul lze i obousměrně, ale v příchozím směru není možné provolení do ústředny až na pobočku, což je dáno typem použité signalizace. Pokud konkrétní PBX umožňuje DISA provolbu, lze pomocí pseudoprovolby dosáhnout až provolení na konkrétní pobočku ústředny. V případě potřeby je možné modifikovat řadu parametrů, např. impedanční přizpůsobení, generování šumu, zisk na vstupu, útlum na výstupu, potlačení ozvěny, dobu čekání na volbu čísla, čas mezi volbou čísel apod.. V případě připojení PBX je odchozí provoz z PBX bez omezení, v případě příchozího volání je možné předat hovor na konkrétní pobočkovou linku např. přes spojovatelské pracoviště. DISA se někdy se označuje jako "pseudoprovolba". Umožňuje automatické vyzvednutí příchozího hovoru a výběr volané pobočky pokračováním ve volbě čísla. Po vyzvednutí hovoru je obvykle volajícímu přehrána hlasová zpráva a nabídnuta možnost přepojení. DISA se používá v PBX, které nemají DDI (Direct Dialing In - provolba) a jsou připojeny analogovou státní linkou. V těchto PBX je při příchozím volání možnost buď nechat vyzvánět volání na určené pobočce a nebo použít DISA provolbu. Obr. 3.3 Modul VIC/FXS ve směrovači Cisco Modul FXO Modul FXO (Foreign Exchange Office) pracuje v režimu analogového přístroje. Na rozhraní lze připojit např. státní tel. linku nebo analogovou linku pobočkové ústředny. Problémy s ukončením hovoru, např. u prvních FXO modulů Cisco, mohou vzniknout při připojení většiny evropských 48

58 3 Hlasové brány ústředen. Komplikace způsobuje signalizační značka Kewl-start (označováno taky jako Power denial nebo Battery drop), jedná se o přerušení napájení při ukončení hovoru inicializované účastnickou sadou. Zmiňovaná značka není v ČR a ve většině evropských zemích vyžadována a řešení problému při zavěšení spočívá ve vyhodnocení kontrolních tónů modulem FXO Modul EM V případě VoIP brány s modulem E&M se jedná o analogové rozhraní pro připojení PBX s oddělenou hovorovou a signalizační částí. Pro hovor se používá dvoudrátová nebo i čtyřdrátová cesta s možností odděleného nastavení přijímacích/vysílacích útlumů/zesílení na delších trasách. Z nabízených signalizačních zapojení na straně GW je vzhledem k univerzálnosti nejvhodnější vybrat verzi č. 5. (negativní logika). Rozhraní pracuje s trvalou EM linkovou signalizací a je doplněné DTMF registrovou signalizací. Pro vlastní EM linkovou signalizaci je nejvhodnější zvolit signalizaci US-WINK doplněnou o DTMF volbu, neboť s touto signalizací jsou nejlepší zkušenosti. US-WINK má následující výhody: rychlé a spolehlivé navázání spojení mezi GW a PBX, při zahájení komunikace se posílá značka WINK, po které následuje DTMF volba, značka přihlášení je přijata po přihlášení volaného a následně se propojují hovorové cesty a nedochází k tarifování před přihlášením, což je důležité u tranzitních volání. Výhoda E&M modulu oproti FXS spočívá v možnosti technicky neomezené obousměrné komunikace, tzn. provolení na pobočku ústředny v příchozím volání a na rozdíl od FXS je přenášena IP sítí značka přihlášení, tzn. u tranzitního hovoru nemůže dojít k zahájení tarifování během vyzvánění. Doporučené nastavení: signalizační zapojení č. 5, mezinárodní varianta, signalizace US WINK (případně Delay dial nebo Immediate-start), pro volbu DTMF (případně pulzní), zapojení hovorové části 2-drát (případně čtyřdrát). V příchozím i odchozím provozu je spojení bez omezení s možností provolení až na pobočkovou linku, přičemž identifikaci volajícího rozhraní neumožňuje Moduly ISDN Modul BRI/ISDN a PRI/ISDN umožňuje obousměrný provoz s provolbou a identifikací čísla volajícího CLIP (Calling Line Identification Presentation). Číslo volajícího bude transparentně přeneseno sítí IP a na digitálních přístrojích zobrazeno během vyzvánění. Provoz v odchozím i příchozím směru je při připojení PBX bez omezení s možností zobrazení CLIP a zachycení identifikace volajícího. Pro odchozí provoz do sítě PSTN/ISDN veřejného telekomunikačního operátora postačí konfigurace BRI/ISDN v režimu TE [v51]. 49

59 3 Hlasové brány Doporučené nastavení PRI/ISDN: Layer 1, Slave (případně Master), CRC4; Procedurou CRC4 (v kanálovém intervalu KI č.0) se kontroluje správné doručení obsahu rámců a způsobuje automatickou blokaci portů při překročení mezních hodnot chybovosti, pro hlas je standardní mez BER=10-3. Bez procedury CRC4 dochází k blokaci vedení až při rozpadu synchronizace (alarmový signál AIS); Layer 2, TEI=0; Layer 3, signalizace DSS1 (případně QSIG). Doporučené nastavení BRI/ISDN v režimu NT: Layer 1, Master, Layer 2, TEI=0, L1/2permanent active, Layer 3, signalizace DSS1 (případně QSIG). Doporučené nastavení BRI/ISDN v režimu TE: Layer 1, Slave, Layer 2, L1/2permanent active, Layer 3, signalizace DSS1 (případně QSIG). Signalizační systém QSIG je založen na využití principu komunikačních funkcí a protokolů, které odpovídají hierarchické struktuře modelu OSI (Open System Interconnection). Je to varianta ISDN signalizace D kanálu. Základním principem modelu je členění na vrstvy. Funkce jednotlivých vrstev jsou definovány ve standardech ETS. Pro fyzickou vrstvu L1 platí standard ETS , pro linkovou vrstvu standard ETS s úpravou pro QSIG ETS Pro síťovou a aplikační vrstvu platí více standardů ETS. 3.3 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. 50

60 3 Hlasové brány [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 Globální parametry nastavení 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 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). 51

61 3 Hlasové brány # 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 1-31 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 52

62 3 Hlasové brány Č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 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) 53

63 3 Hlasové brány 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, viz. kapitola 7.3. 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. # 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 54

64 3 Hlasové brány 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. 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 55

65 3 Hlasové brány 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 3.4 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 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' 56

66 3 Hlasové brány 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# 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 57

67 3 Hlasové brány 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. 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. 58

68 4 GNU Gatekeeper 4 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 4.1 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. 59

69 4 GNU Gatekeeper 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 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]. 4.1 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 Základní konfigurace po instalaci 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ý 60

70 4 GNU Gatekeeper 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 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 61

71 4 GNU Gatekeeper 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 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 62

72 4 GNU Gatekeeper 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 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. 63

73 4 GNU Gatekeeper 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 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: 64

74 4 GNU Gatekeeper 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 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ů 65

75 4 GNU Gatekeeper 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. 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. Ukázka syntaxe konfigurace autentizačního pravidla může vypadat následovně: [Gatekeeper::Auth] FileIPAuth=required;RRQ,LRQ,Setup [FileIPAuth] =reject /24=allow any=reject 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 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 66

76 4 GNU Gatekeeper 5555=allow ipv4: deny ipv4: / =deny!ipv4: /24 09=deny alias:^ * Obr 4.2 Příklad řešení mechanizmu autentizace a autorizace. 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. 4.2 byl realizován jako diplomová práce [sir] a řešení přes RADIUS bylo zvoleno z důvodu nepodporovaného protokolu LDAP v GnuGK, podpora LDAP byla přidána ve verzi a dá se zapnout při kompilaci GnuGK. 4.2 Návrh sítě s konfigurací GnuGK Návrh topologie je v obr. 4.3, 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. 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. 4.3 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. 67

77 4 GNU Gatekeeper Obr 4.3 Návrh topologie H.323 sítě. # 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=

78 4 GNU Gatekeeper [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 (*). [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 7.3. 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 69

79 4 GNU Gatekeeper 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 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, jedná se opět o popsané nastavení z třetí kapitoly. 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! 70

80 4 GNU Gatekeeper 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. 4.4 zobrazuje příklad mezizónové mezizónovou komunikace (IP adresy jsou odlišné). Obr 4.4 Mezizónová komunikace. GK na levé straně obr. 4.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 4.5. Obr 4.5 Obsah zprávy LRQ. Odpověď LCF, viz. obr. 4.6 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

81 4 GNU Gatekeeper Obr 4.6 Zpráva LCF v mezizónové komunikaci. 72

82 5 Základy protokolu SIP 5 Základy protokolu SIP 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. 5.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 73

83 5 Základy protokolu SIP 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 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 #. 74

84 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). 5.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ů. 75

85 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. Obr. 5.1 Rozeslání INVITE více příjemcům. 76

86 5 Základy protokolu SIP Obr. 5.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í 77

87 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. 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í 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. 5.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. 78

88 5 Základy protokolu SIP Obr Sestavení spojení přes dvě SIP Proxy SIP Registrar Server 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). 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. Registrar server je velmi často pouze jako logická část SIP serveru, jelikož je těsně svázán s Proxy serverem. Obr. 5.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ý. 79

89 5 Základy protokolu SIP Obr Průběh registrace 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. 5.4 Obr Průběh přesměrování. 80

90 5 Základy protokolu SIP 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. 5.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. 5.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 81

91 5 Základy protokolu SIP (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 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 82

92 5 Základy protokolu SIP 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; 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 83

93 5 Základy protokolu SIP 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 Contact: <sip:1194@ > 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é, 84

94 5 Základy protokolu SIP 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ě 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 85

95 5 Základy protokolu SIP * 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 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 Obr 5.5 Žádost a odpověď. 86

96 5 Základy protokolu SIP Na obr. 5.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. 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 87

97 5 Základy protokolu SIP 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. 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 Obr Rozdílné zacházení se 100 Trying u stavových transakčních strojů. 88

98 5 Základy protokolu SIP Dialog V předchozím kapitole jsme si ukázali dvě transakce, viz. obr. 5.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. Obr. 5.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); 89

99 5 Základy protokolu SIP 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 Transakce a dialog v příkladu Určení transakce a dialogu si můžeme ukázat v následujícím příkladu, který odpovídá obr. 5.9, jde tedy o žádost INVITE s odpověďmi 100 TRYING, 180 RINGING, 200 OK, dále žádost ACK a nakonec BYE s odpovědí 200 OK. První zpráva #1 INVITE obsahuje branch=z9hg4bk7225f861, který najdeme ve zprávách #1 INVITE, #2 100 TRYING, #3 180 RINGING a #4 200 OK, tím je určena první transakce. Zpráva #5 ACK obsahuje branch=z9hg4bk , čili do první transakce nepatří a ani novou transakci nevytváří, neboť na tuto žádost není odpověď. Druhá transakce obsahuje branch=z9hg4bk011c16dd a je tvořena #6 BYE a #7 200 OK. Dialog je určen: pomocí tag=as396d4fbf z pole From, tag= d4b8 z pole To, řetězcem v Call-ID: 1c068e57440c89084bf549466dddfea0@ Early dialog je vytvořen přijetím #3 180 RINGING a dialog je sestaven přijetím #4 200 OK. Pole Cseq se v rámci dialogu inkrementuje s každou novou žádostí (výjimkou je ACK), všechny odpovědi k žádosti mají stejný Cseq, čili lze jednoduše určit, ke které žádosti odpověď patří a rovněž se snadno rozpoznají retransmise. # 1 INVITE Request-Line: INVITE sip:7002@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport From: "5779" <sip:5779@ >;tag=as396d4fbf To: <sip:7002@ > Contact: <sip:5779@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Type: application/sdp Content-Length: 422 (v): 0 (o): root IN IP (s): session (c): IN IP (t): 0 0 (m): audio RTP/AVP (a): rtpmap:0 PCMU/

100 5 Základy protokolu SIP (a): rtpmap:8 PCMA/8000 (a): rtpmap:3 GSM/8000 (a): rtpmap:18 G729/8000 #2 100 TRYING Status-Line: SIP/ Trying Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport=5060 From: "5779" To: "SJphone" Call-ID: CSeq: 102 INVITE Content-Length: 0 Server: SJphone/ a (SJ Labs) #3 180 RINGING Status-Line: SIP/ Ringing Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport=5060 From: "5779" <sip:5779@ >;tag=as396d4fbf To: "SJphone" <sip:7002@ >;tag= d4b8 Contact: <sip:7002@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 INVITE Content-Length: 0 Server: SJphone/ a (SJ Labs) #4 200 OK Status-Line: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport=5060 From: "5779" <sip:5779@ >;tag=as396d4fbf To: "SJphone" <sip:7002@ >;tag= d4b8 Contact: <sip:7002@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 INVITE Content-Length: 274 Content-Type: application/sdp Server: SJphone/ a (SJ Labs) (v): 0 (o): IN IP (s): SJphone (c): IN IP (t): 0 0 (m): audio RTP/AVP 0 (a): rtpmap:0 PCMU/8000 #5 ACK Request-Line: ACK sip:7002@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK ;rport From: "5779" <sip:5779@ >;tag=as396d4fbf To: <sip:7002@ >;tag= d4b8 Contact: <sip:5779@ > Call-ID: 1c068e57440c89084bf549466dddfea0@

101 5 Základy protokolu SIP CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 #6 BYE Request-Line: BYE sip:7002@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK011c16dd;rport From: "5779" <sip:5779@ >;tag=as396d4fbf To: <sip:7002@ >;tag= d4b8 Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 103 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 #7 200 OK Status-Line: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK011c16dd;rport=5060 From: "5779" <sip:5779@ >;tag=as396d4fbf To: "SJphone" <sip:7002@ >;tag= d4b8 Contact: <sip:7002@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 103 BYE Content-Length: 0 Server: SJphone/ a (SJ Labs) 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 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á. 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

102 5 Základy protokolu SIP Tab. 5.1 Časovače dle RFC 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 93

103 5 Základy protokolu SIP 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. 5.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 94

104 5 Základy protokolu SIP Contact: To: From: 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. 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á 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. 5.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 95

105 5 Základy protokolu SIP 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. 5.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. 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. 96

106 5 Základy protokolu SIP 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 č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. 97

107 5 Základy protokolu SIP 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 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. 98

108 5 Základy protokolu SIP 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). SIP/ Trying 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 99

109 5 Základy protokolu SIP 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= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= Max-Forwards: 68 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 100

110 5 Základy protokolu SIP 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 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ý 101

111 5 Základy protokolu SIP 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. 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> 102

112 5 Základy protokolu SIP 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 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. 103

113 5 Základy protokolu SIP 5.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, 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>, 104

114 5 Základy protokolu SIP 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] 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] 105

115 5 Základy protokolu SIP 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/8000 a=fmtp:18 annexb=no a=silencesupp:off m=video RTP/AVP 34 a=rtpmap:34 H263/

116 5 Základy protokolu SIP 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 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 107

117 5 Základy protokolu SIP 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

118 6 Další metody rozšiřující SIP 6 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í. 6.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. 109

119 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. 6.1 Uplatnění PRACK při propojení s PSTN. 110

120 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. 6.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. 111

121 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. 6.2 Příklad použití UPDATE. V příkladu, viz. obr. 6.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. 112

122 6 Další metody rozšiřující SIP 6.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. 6.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. 6.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. 113

123 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. 6.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 114

124 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. 6.4 je příklad odeslání žádosti MESSAGE přes Proxy. Obr. 6.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. 6.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: 115

125 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). Obr. 6.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 116

126 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. 6.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. Obr. 6.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 117

127 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. 6.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, 118

128 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. 6.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. 6.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. 6.7 by se dala pochopitelně vylepšit o PRACK, který byl už rozebrán v předchozích kapitolách. 119

129 6 Další metody rozšiřující SIP 6.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. 6.8 Obr. 6.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. 6.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í 120

130 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. 6.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 121

131 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. 6.9 Přidržení hovoru s hudbou 6.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. 122

132 6 Další metody rozšiřující SIP 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. 123

133 6 Další metody rozšiřující SIP Obr Předání hovoru pomocí REFER 6.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). 124

134 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. Obr Přesměrování při obsazení - CFWB 6.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 125

135 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. Obr Oznámení o zanechání vzkazu - MWI 6.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 126

136 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 127

137 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:

138 6 Další metody rozšiřující SIP Obr Zpětné volání při obsazení 6.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 129

139 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. 130

140 7 Využití DNS pro IP telefonii 7 Využití DNS pro IP telefonii Jak už napovídá název kapitoly, budeme se zabývat využitím systému doménových jmen (DNS) pro IP telefonii, popíšeme si používané typy záznamů a jejich funkci. V předchozí kapitole jsme se věnovali SIP protokolu, obsahuje-li cílová URI adresu mimo vlastní doménu a INVITE byl odeslán na domácí SIP Proxy, tak existují dvě možnosti, jak tato SIP Proxy zjistí, kam má INVITE odeslat. První možností je existence záznamu pro daný cíl v lokalizační databázi, tzn. má staticky mapovanou cílovou doménu na konkrétní stroj, na němž cílová SIP Proxy běží. Druhá možnost spočívá v dotazu do DNS a pro tento účel se používají SRV záznamy specifikující umístění služby. 7.1 SRV záznamy DNS obsahuje specifické informace o dostupných službách ve formátu dle RFC 2782 z roku SRV záznamy umožňují pro jednu doménu použít několik serverů pro konkrétní službu. SRV obsahuje informace o specifické službě pro doménu a umožňuje nastavit i prioritu. SRV záznam poskytuje následující informace: Service, symbolické jméno požadované služby, Protocol, obvykle TCP nebo UDP, Domain name, název domény pro níž je záznam platný, TTL, doba života záznamu, např sec. (cache drží záznam 12 hod. ), Class: pole pro třídu (vždy IN), Priority: priorita pro cíl, nižší číslo bude dřív vybráno, Weight: váha priority záznamu, při více spojení se stejnou prioritou je brána dříve v potaz vyšší váha, Port: TCP nebo UDP port, na kterém je služba dostupná, Target: název stroje FQDN poskytujícího službu. _sip._udp.cesnet.cz IN SRV cyrus.cesnet.cz Výše uvedený příklad záznamu dostaneme, pokud se dotážeme na stroj, který poskytuje službu SIP na UDP v doméně cesnet.cz, v Linuxu zadáme příkaz: host -t SRV _sip._udp.cesnet.cz 131

141 7 Využití DNS pro IP telefonii Z odpovědi se dozvíme, že SIP na UDP v doméně cesnet.cz je to stroj cyrus.cesnet.cz na portu Pochopitelně obdobný záznam můžeme mít pro TCP. Nakonec pro jednu službu můžeme mít i více záznamů s různou prioritou, což je užíváno pro zvýšení dostupnosti a zachování funkčnosti služby v případě poruchy některého z poskytovatelů služby, jedním slovem survivability. SRV záznam můžeme použít i pro UA, aby našel poskytovatele služby v doméně, což nám zjednoduší konfiguraci SIP telefonu, zadáme uživatelské jméno, heslo a doménu, poskytovatele služby si UA najde sám v DNS. _sip._tcp.biloxi.com IN SRV ser.biloxi.com. _sip._udp.biloxi.com IN SRV ser.biloxi.com. _sips._tcp.biloxi.com IN SRV ser.biloxi.com. _sip._tls.biloxi.com IN SRV ser.biloxi.com. 7.2 NAPTR záznamy NAPTR (Naming Authority Pointer Record) je poměrně novým typem záznamu. Původní RFC 2915 (The Naming Authority Pointer DNS Resource Record) je z roku 2000 a novější RFC je 3404 (The Uniform Resource Identifiers Resolution Application) z roku NAPTR je typ DNS záznamu, který podporuje regulární výrazy, mohou být tak použity sofistikované přepisovací pravidla. Odpovídající záznam v DNS pro ENUMU je předepsán ve tvaru: IN NAPTR order pref u E2U+enumservice regexp replacement. Tvar obsahuje pořadí (order), upřednostnění (pref), označení u (flag) znamená, že výstupem bude URI požadované služby a nakonec aplikující se regulární výraz (regexp) a nahrazení (replacement). Výsledkem aplikace regulárního výrazu je URI adresa pro konkrétní službu. NAPTR mohou být použity i pro směrování servisních záznamů SRV, viz. RFC 3263 (Locating SIP Servers). NAPTR záznamy nasměrují SIP požadavek pro doménu iptel.biloxi.com na záznamy SRV, kde protokol TCP má vyšší prioritu (menší číslo znamená vyšší prioritu). iptel.biloxi.com. IN NAPTR "s" "SIP+D2T" _sip._tcp.iptel.biloxi.com. iptel.biloxi.com. IN NAPTR "s" "SIP+D2U" _sip._udp.iptel.biloxi.com. SRV záznamy už ukazují na konkrétní SIP server. _sip._tcp.iptel.biloxi.com. IN SRV sip.iptel.biloxi.com. _sip._udp.iptel.biloxi.com. IN SRV sip.iptel.biloxi.com. SRV nám vyřeší lokalizaci služby v doméně, ale problém máme s telefonními čísly, protože SIP URI je vázáno na doménu a pokud bychom nahradili položku username telefonním číslem, tak stále řešíme, jak se dovolat mimo svou doménu anebo přesněji, jak zjistit, která SIP Proxy obslouží volání na žádané číslo. S tímto úkolem si výtečně poradil mechanizmus ENUM (telephone NUmber 132

142 7 Využití DNS pro IP telefonii Mapping). Standard ENUM přináší mapování telefonních čísel E.164 na jmenné identifikátory URI. V jmenném serveru může záznam vypadá následovně: $ORIGIN e164.arpa. IN NAPTR "u" "E2U+h323" "!^\\+420(.*)$!h323:\\1@cesnet.cz!". IN NAPTR "u" "E2U+sip" "!^\\+420(.*)$!sip:\\1@cesnet.cz!". IN NAPTR "u" "E2U+smtp" "!^(.*)$!mailto:info@cesnet.cz!. Odpověď je rozdělena do dvou polí oddělených vykřičníky, v ukázce je : Regulární výraz. který je odstartován symbolem ^ a ukončen $, výraz v prvním poli mezi dvěma vykřičníky \\+420(.*) představuje všechna čísla nacházející se za +420 nahrazení (replacement) je v druhém poli vyjádřen dosazením získaného výrazu z prvního pole \\1 do URL, v případě třetího záznamu se vždy vrátí mailto:info@cesnet.cz Dotazující SIP UA převede na e164.arpa a odešle do DNS, pro tento dotaz v DNS odpovídá zóna e164.arpa, z odpovědí si SIP UA vybere službu si E2U+sip a aplikováním regulárního výrazů získá SIP URI sip: @cesnet.cz, pomocí SRV záznamů zjistí, že stroj obsluhující SIP v doméně cesnet.cz je cyrus.cesnet.cz a na ten bude odeslán INVITE. Posledním krokem v DNS by bylo dohledání A nebo AAAA záznamu odpovídající danému doménovému jménu. Vidíme, že pro SIP běžně využijeme v DNS následující záznamy : NAPTR, SRV, A a AAA. ENUM definuje E2U pro službu, která je očekávána pro: SIP jako E2U+sip, např. s URI sip: voznak@cesnet.cz, H.323 jako E2U+h323, např. s URI h323:voznak@cesnet.cz, Internet FAX jako E2U+ifax, např. s URI mailto:fax@fax.vsb.cz, Telephone jako E2U+tel, např. s URI tel: :svc=voice, Fax jako E2U+fax:tel, např. s URI tel: :svc=fax, jako E2U+ mailto, např. s URI mailto:miroslav.voznak@vsb.cz, Web jako E2U+web:http, např. s URI ENUM mapování E.164 a URI ENUM je most mezi číselnými identifikátory telefonních sítí definovaných v ITU-T E.164 a jmennými identifikátory URI uloženými v záznamech DNS a užívanými v Internetu. V roce 2000 byl ENUM poprvé popsán v RFC 2916, jeho autorem byl švédský inženýr Patrik Fältström, novější verze je v RFC 3761 z dubna roku Pro ENUM se užívá TLD doména e164.arpa a ta je delegována se souhlasem zástupce státu v ITU-T na organizaci, která se stává správcem národní domény. V případě ČR je to doména e164.arpa a správcem této domény je od roku 2003 sdružení CZ.NIC. První část služby ENUM tvoří čísla ITU-T doporučení E.164, za tímto účelem byla v ITU-T založena 133

143 7 Využití DNS pro IP telefonii studijní skupina (SG2), která pracuje na administrativních postupech týkajících se služby ENUM. Druhou část vytváří organizace IETF, kde tato služba vznikla a spočívá v začlenění tohoto standardu do struktury systému doménových jmen DNS. V souvislosti s IP telefonní je hlavním cílem ENUM zprostředkovat identifikaci a adresovat klienta služby přes internet na základě univerzálního identifikátoru, kterým je telefonní číslo. Pro tento účel se v DNS používají záznamy NAPTR (Naming Authority Pointer) a dotaz do DNS musí přijít ve vhodném formátu z čísla v mezinárodním formátu se odstraní nenumerické znaky, mezi číslice se vloží tečky, celý řetězec se zapíše v opačném pořadí, a nakonec se přidá.e164.arpa. Uživatel vytočí a odesílá se řetězec e164.arpa, o naformátování se postaral buď sipový klient (SIP UA)anebo SIP Proxy. Teď potřebujeme odpovídající záznam v DNS: $ORIGIN e164.arpa. IN NAPTR "u" "E2U+sip" "!^\\+(.*)$!sip:\\1@cesnet.cz!". IN NAPTR "u" "E2U+h323" "!^\\+(.*)$!h323:\\1@cesnet.cz!". Použití regulárních výrazů v DNS dotazech je postaveno na exaktních pravidlech..* odpovídá libovolné řadě znaků a číslic, ˆ znamená začátek regulárního výrazu, $ znamená konec regulárního výrazu, Ukázky použití pravidel: ˆ123.*, každý záznam začínající 123, *1234$ každý záznam končící 1234, ˆ123(.*)567$ všechny záznamy začínající 123 a končící 567. Aplikací regulárního výrazu dostaneme URI adresy sip: @cesnet.cz a h323: @cesnet.cz. Vykřičníky slouží jako oddělovače jednotlivých částí výrazu, podívejme se na příklad regulárního výrazu!ˆ.*$!sip:voznak@cesnet.cz!, řetězec mezi prvními dvěma vykřičníky říká, že se má označit celý řetězec (aplikuje se na dotazované tel. č.), druhá část říká, čím se bude nahrazovat, aplikací regulárního výrazu dostaneme SIP URI sip: voznak@cesnet.cz. Existenci NAPTR záznamu k tel. č ověříme příkazem: host -t naptr e164.arpa. Pokud bychom výše uvedený záznam nezapsali do zóny e164.arpa našeho DNS serveru, ale vytvořili si svou privátní zónu, do které bychom se dotazovali, tak by se jednalo o privátní strom, příkladem může být například e164.org, e164.info anebo akademickou komunitou používaný 134

144 7 Využití DNS pro IP telefonii nrenum.net. Tyto stromy většinou zakládají skupiny s určitým cílem a stanovují individuální pravidla. Veřejný strom e164.arpa má jasně daná pravidla, viz. obr. 7.1, používají se veřejná čísla dle ITU-T E.164, je zde role ITU-T udělující souhlas s delegací na úrovni domény identifikující konkrétní stát, např. delegace e164.arpa na sdružení CZ.NIC na základě požadavku zastoupení ČR v ITU-T. Obr. 7.1 Příklad procházení stromu e164.arpa 7.4 Prostory ENUMu ENUM je v ČR v ostrém provozu od ledna 2007, registraci telefonních čísel zajišťuje zhruba dvacet registrátorů, jejich seznam je uveden na stránkách Koncem roku 2008 bude spuštěn DNSSEC pro domény e164.arpa a cz, což je rozšíření umožňující ověřit pravost informací získaných z DNS, ty budou podepsány, zabezpečené DNS bude tak sloužit pro uvedené stromy jako úložiště certifikátů [v131]. Základní myšlenka, na které ENUM vznikl, byla dovolit uživatelům čísel vkládat za vymezených podmínek stávající telefonní čísla do DNS a umožnit vyhledávání těchto čísel. Tento ENUM se nazývá uživatelský ENUM, ale tento přístup nemusí vyhovovat všem, například operátorům určitě nesedí, že o vložení čísla do DNS rozhoduje jeho uživatel. ISP většinou preferují federace 135

145 7 Využití DNS pro IP telefonii postavených na bilaterálních či uliterálních dohodách, a tak vzniká ENUM s přívlastky User, Private, Operator, Enterprise, Federation, Carrier, Infrastructure a snad někoho napadne ještě další. Příklady ENUM stromů se zařazením typu jsou v tabulce níže. Aktuálně se diskutuje veřejný operátorský strom, který operátorům chybí a jako nejreálnější se jeví paralelní veřejný strom ke stávajícímu uživatelskému, tlak ovšem není dostatečně silný a tak se dosud tento návrh nepodařilo v IETF prosadit. Tab. 7.1 Příklady prostorů ENUMu 7.5 Sestavení spojení s využitím DNS Do DNS je odeslán dotaz s naformátovaným číslem E.164, předpokládejme, že se bude vyhledávat ve veřejném stromu e164.arpa a bude nalezen odpovídající NAPTR záznam. Dokážeme si ovšem představit, že dotaz může být paralelně odeslán i do více stromů. Obr. 7.2 Příklad využití DNS při sestavení spojení 136

146 7 Využití DNS pro IP telefonii Aplikací regulárního výrazu je získána adresa SIP URI, která identifikuje uživatele v doméně cesnet.cz. V dalším kroku je pomocí SRV v cílové doméně zjištěno, že službu SIP poskytuje cyrus.cesnet.cz. Domácí SIP Proxy tak získává SIP URI volaného a adresu stroje, na který může odeslat INVITE, čili žádost o inicializaci spojení. 7.6 Konfigurace DNS pro účely ENUMu Nejdříve nastavíme SIP server, aby se dotazoval do name serveru, který budeme konfigurovat. Změnu provedeme v souboru /etc/resolv.conf, kde nastavíme jako nameserver [v68],[vil]. ;soubor /etc/resolv.conf nameserver Nyní upravíme konfiguraci DNS serveru. K implementaci DNS použijeme BIND, který je součástí většiny linuxových distribucí. V souboru named.conf vytvoříme novou zónu e164.arpa odkazující se na db.arpa. Zónu přidáme do souboru /etc/bind/named.conf. ;část souboru /etc/bind/named.conf zone "e164.arpa" IN { type master; file "/etc/bind/db.arpa"; }; Pro rychlé otestování vytvoříme soubor /etc/bind/db.arpa s následujícím obsahem. ;soubor /etc/bind/db.arpa $TTL IN SOA root ( ; Serial ; Refresh ; Retry ; Expire ) ; Minimum IN NS e164.arpa. IN NAPTR "u" "sip+e2u" "!^.*$!sip: @ !". NAPTR záznam říká, že pro dotazu na číslo dostaneme SIP URI sip: @ Po dokončení konfigurace musíme BIND restartovat. /etc/init.d/bind restart 137

147 7 Využití DNS pro IP telefonii Než nakonfigurujeme SIP server pro volání přes ENUM je vhodné si funkčnost NAPTR záznamu otestovat a nesmíme zapomenout, jaký nameserver máme nastavený pro DNS. host -t naptr e164.arpa. 7.7 Budoucnost ENUMu Pomalá implementace ENUMu je organizačně politickým problémem nikoliv technickým. Pro prosazení užívání mechanizmu ENUM se jeví jednak jako potřebné dosáhnout určitého kritického množství a jednak zapojení telekomunikačních operátorů (telco). Ti ovšem přistupují k ENUMu odmítavě z jasného důvodu, za kterým stojí peníze. Pokud by došlo k masovému nasazení ENUMu, znamenalo by to snížení zisků telco společností, neboť směrování přes ENUM v Internetu je levnější než v klasických PSTN. Řada publikací popisující ENUM tvrdí, že se jedná o technologii pro telefonování zadarmo, ale s tím není možné souhlasit. Model zpoplatňování hovorů závisí na poskytovateli hlasové služby, nikoliv na tom, zda číslo uživatele je v DNS. Konkrétní tel.č. může být v DNS propagováno, ale není nikde zaručeno, že příchozí SIP Proxy volání přijme. Každopádně lze očekávat, že používání ENUMu by mělo příznivý dopad na cenu hovorů, což nevylučuje, že hovor může být i zdarma. Pravděpodobně lze očekávat model, že náklady poskytovatele služby budou ukryty v paušálním poplatku a jednotlivé hovory nebudou zpoplatňovány. Pro tento princip se užívá názvu flat rate a tento koncept se bude v tarifech poskytovatelů používat nejčastěji. 138

148 8 SIPp a jeho použití k emulaci SIP relací 8 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. 8.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 10 new calls during s period 1 ms scheduler resolution 40 calls Peak was 42 calls, after 158 s 0 Running, 371 Paused, 24 Woken up 0 dead call msg (discarded) 3 open sockets Messages Retrans Timeout Unexpected-Msg > INVITE < < > ACK E-RTD > BYE < [ 4000ms] Pause Sipp Server Mode Obr. 8.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í. 139

149 8 SIPp a jeho použití k emulaci SIP relací 8.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 # 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 140

150 8 SIPp a jeho použití k emulaci SIP relací 8.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 # 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 8.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 141

151 8 SIPp a jeho použití k emulaci SIP relací -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 -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. #./ sipp -sf uac_sipuri.xml s r 500 -rp 1000 iptel.org 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 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). 142

152 8 SIPp a jeho použití k emulaci SIP relací <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"> <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> 143

153 8 SIPp a jeho použití k emulaci SIP relací <![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] 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> 144

154 8 SIPp a jeho použití k emulaci SIP relací </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. # sipp -sf uac_basic.xml Zachytíme relaci např. pomocí tcpdump anebo ngrep a zachycenou SIP relaci můžeme analyzovat Wiresharkem. # tcpdump -w /home/voz29/trace8.pcap Ověříme, že XML scénář se chová dle předpokladů, viz. obr. 8.3 Obr. 8.3 Výměna SIP zpráv v sestavené relaci Nyní se podíváme ještě na obsah žádosti INVITE, viz. obr. 8.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. 8.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á 145

155 8 SIPp a jeho použití k emulaci SIP relací [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] [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. 146

156 8 SIPp a jeho použití k emulaci SIP relací <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 [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 147

157 8 SIPp a jeho použití k emulaci SIP relací 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 "#"). Obr. 8.5 Vazba klíčového slova v argumentu konkrétního pole SIP hlavičky na řádek v CSV souboru 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]) 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"> 148

158 8 SIPp a jeho použití k emulaci SIP relací <![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ěď. <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. 149

159 8 SIPp a jeho použití k emulaci SIP relací 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 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. 150

160 8 SIPp a jeho použití k emulaci SIP relací 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í. 151

161 9 NAT vs. IP telefonie 9 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é 152

162 9 NAT vs. IP telefonie 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ž 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. 9.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. 153

163 9 NAT vs. IP telefonie Obr SIP zprávy přes NAT 9.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í. 154

164 9 NAT vs. IP telefonie 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í. 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 9.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, 155

165 9 NAT vs. IP telefonie - 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). - 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. 9.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. 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 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). 156

166 9 NAT vs. IP telefonie Obr Mapování vnější veřejné IP a portu pomocí STUN protokolu 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. 9.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 157

167 9 NAT vs. IP telefonie Obr Průchod IP telefonie s pomocí TURN serveru Adresa alokovaná TURN serverem se nazývá Relayed address, viz. obr 9.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 : 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

168 9 NAT vs. IP telefonie 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 # 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 159

169 9 NAT vs. IP telefonie 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). 160

170 10 MGCP a IAX protokol 10 MGCP a IAX2 protokol Ve světě VoIP je používána řada signalizačních protokolů, zpočátku byl dominantním protokol H.323, cca od roku 2005 již nikdo nepochyboval o budoucnosti SIP protokolu, což souviselo i s jeho využitím ve veřejných sítích. Specifikace IMS z roku 2005, za kterou stojí 3GPP otevřela protokolu SIP cestu do mobilních sítí a v jádru sítě se SIP stal klíčovým protokolem pro poskytování IP multimediálních služeb. Řada výrobců promptně zareagovala a jejich vývoj byl směrován především do oblasti koncových SIP SW klientů a zařízení. Dnes tedy dominuje světu IP telefonie SIP, ale kromě těchto dvou protokolů jsou ještě další, ze kterých si zmíníme velmi důležité protokoly, MGCP a IAX. Zatímco MGCP nachází uplatnění především ve veřejných sítích, tak doménou IAX jsou sítě privátní, svět pobočkových ústředen Media Gateway Control Protocol MGCP (Media Gateway Control Protocol) je master/slave protokol pro řízení brány (slave). Tento IETF protocol, který byl vydán v roce 1999 jako informativní RFC 2705 a dotažen do finální podoby standardního doporučení byl až v roce 2003 v RFC Z MGCP vychází protokol Megaco/H.248, přičemž Megaco je označení IETF a H.248 je značení ITU-T pro stejný standard. První verze H.248 byla uvolněna v roce 2000, nyní je třetí verze z roku Architektura a základní rysy MGCP Prvky MGCP architektury jsou následující: Media Gateway (MGW) konvertuje média na formát vyžadovaný jinou sítí, MGWC (Media Gateway Controller) řídí prvky MGCP architektury, používají se i termíny Call Agent (CA) nebo Softswitch, entita zajišťuje zpracování volání, řízení komunikace a ovládá veškeré dalších prvky, se kterými má vztah Master/Slave, Signaling Gateway (SGW) umožňuje připojení do signalizační sítě SS7. Základní rysy MGCP: MGCP je textově orientovaný protokol vycházející z HTTP, pro přenos signalizace používá UDP, nebo TCP 161

171 10 MGCP a IAX protokol standardní port brány (MGW) je 2427 standardní port Call Agenta (CA) je 2727 správa multimediální relace tunelovaným protokolem SDP, real-time multimediální přenos protokolem RTP nebo šifrovaným SRTP, MGCP zprávy Formát protokolu MGCP je příkaz odpověď, command/response (CMD/ACK). Příkaz začíná slovem se čtyřmi znaky: AUEP, AUCX, CRCX, DLCX, EPCF, MDCX, NTFY, RQNT, RSIP. Odpověď začíná třemi čísly tzv. kódu odpovědi, např. 200 (OK), podobně jako SIP. V protokolu MGCP má každý příkaz transakční ID, které obsahuje i odpověď. Příkazy protokolu MGCP jsou následující: EPCF (Endpoint Configuration), CA>MG, dává GW instrukce k nastavení kódování na straně linkového rozhraní (směrem do PSTN, ISDN,...), RQNT (Notification Request), CA>MG, dává GW instrukce k dohledu specifických událostí a instruuje jak k těmto událostem generovat signály, CRCX (Create Connection), CA>MG, CA požaduje vytvořit spojení přes GW mezi dvěma endpointy, MDCX (Modify Connection), CA>MG, CA vyžaduje změnit parametry týkající se sestaveného spojení, DLCX (Delete Connection), CA>MG a MG>CA, umožňuje zrušit existující spojení, ACK vrací statistiky volání, AUEP (Audit EndPoint), CA>MG, monitoruje status endpointu, AUCX (Audi Connection), CA>MG, monitoruje status spojení, RSIP (RestartInProgress), MG>CA, MG sděluje CA o stavu v provozu a mimo provoz. NTFY (Notify), MG>CA, MG dává CA instrukce k dohledu specifických událostí, Každý příkaz musí být zodpovězen, odpověď vrací návratový kód indikující stav vyřízení příkazu. Tyto kódy jsou součástí RFC 3661 a mají rozsah : Response acknowledgement, potvrzení odpovědi, (např jde o potvrzení po přijetí dočasné odpovědi, je použit 3-way handshake), Provisional response, dočasná neboli prozatímní odpověď informující o průběhu vyřizování požadavku (např. 100 transaction in progress oznamující vyřizování anebo 101 transaction has been queued oznamující zařazení požadavku do fronty), Successful completion je úspěšné dokončení, tuto odpověď vidíme nejraději, Transient error, jedná se o přechodnou chybu, kterou může být např. 401 phone allready off-hook oznamující stav obsazeno anebo 404 insufficient bandwith indikující nedostatek pásma, Permanent error, trvalá chyba např. 500 unknown endpoint oznamující neznámý cíl anebo 504 unknown or unsupported command indikující neznámý či nepodporovaný příkaz, Package specific response codes oznamuje specifické kódy (nestandardní), 162

172 10 MGCP a IAX protokol Reason codes, jedná se o důvody chyb např. 901 endpoint taken out of service oznamující, že koncový terminál je mimo provoz anebo 903 QoS resource reservation was lost indikuje nemožnost garantovat kvalitu Příklad komunikace pomocí MGCP Na obr je zachycena výměna zpráv mezi CA a MGW [sil2]. První zprávou je obsazení CRCX (SDP) s popisem médií v SDP, následuje odpověď 100 potvrzující doručení CRCX a následně 200 (SDP) jako finální odpověď na CRCX včetně popisu médií přicházející při vyzvednutí volaným a sestavení hovoru, média jsou přenášeny standardně v RTP (G711Alaw), následuje zavěšení volaným DLCX a jeho potvrzení 250. Obr Výměna zpráv mezi CA a MGW MGCP protokol je podporován řadou výrobců jako je např. Cisco, Nortel, Ericsson a rovněž je podporován v Asterisku. V PBX Asterisk je implementován pouze Call Agent (CA). Gateway je implementována zpravidla hardwarově, ale najdeme ji např. v PBX YATE. # less /etc/asterisk/mgcp.conf: [general] port = 2727 ; IP adresa ( všechny rozhranní) bindaddr = ; IP adresa ( všechny rozhranní) [ ] host = ; IP brány line => aaln/1 line => aaln/2 line => aaln/3 line => aaln/4 dtmfmode=rfc2833 ; jednotlivé linky brány ; DTMF mód 163

173 10 MGCP a IAX protokol context = mgcp_kon ; kontext directmedia = yes ; může provést re-invite (stejné jako sip) ;... a řada dalších parametrů Příklad pravidla volání v dial plan Asterisku může vypadat následovně. v /etc/asterisk/extensions.conf exten => _841,1,Dial(MGCP/aaln/1@ ,20). V případě mapování SIP a MGCP, kdy volání je iniciováno ze strany MGCP s terminací do SIP, se využívá modifikace spojení MDCX (SDP), když jsou média vyjednána a doručen ve 200 OK., viz. obr Obr Komunikace přes protokolovou bránu MGCP/SIP 10.2 Inter Asterisk Exchange Protocol Protokol IAX byl navržen s ohledem na maximální jednoduchost a snadnost implementace. Jedná se o binární protokol, který sdružuje signalizaci i hlasová data v jenom kanálu a umožní tak lépe využít šířku pásma a snadno prochází přes NAT. Uplatnění nachází především při propojení 164

174 10 MGCP a IAX protokol ústředen Asterisk, i když jeho použití je ovšem i pro koncové klienty, ale vzhledem k široké podpoře SIPu v koncových zařízeních je portfolio IAX SW klientů a zařízení o poznání menšího rozsahu než SIP. Asterisku bude věnována následující kapitola. IAX je zaveden do ústředny Asterisk od samého počátku vývoje [mol1]. Od Asterisk 0.5 začala být podporována vylepšená verze protokolu, nazývaná IAX2, ta je využívána v současnosti a je specifikována v IETF RFC 5456 (IAX: Inter-Asterisk exchange Version 2) z roku IAX je orientován na přenos peer-to-peer a je určen jak pro přenos signalizace, tak i médií. U protokolů SIP a H.323 je přenos médií zabezpečen pomocí RTP. Protokol IAX2 využívá jeden kanál pro přenos signalizace i samotných multimediálních dat a navíc umožňuje i multiplex více hovorových i signalizačních dat do jednotného datového toku, tzn. že snižuje overhead hlaviček a na rozdíl od SIP či H.323 s RTP, kde při dvaceti současných hovorech se stejným kodekem je celkový tok dán násobkem dvaceti jednotlivých toků, tak u IAX2 to nebude jednoduchým násobkem, ale méně vzhledem k multiplexování Formát rámce IAX2 Pro přenos je využíván pouze jeden UDP port, obvykle port 4569, základní komunikační jednotkou protokolu IAX je IAX rámec, viz. obr Základní rámec nesoucí hovorová i signalizační data se nazývá Full Frame a pro přenos multimediálních dat bez signalizace je využit tzv. Mini Frame, jehož hlavička má pouhé 4B. Obr Rámec Full Frame a Mini Frame protokolu IAX MiniFrame hlavička obsahuje posledních 16 bitů časové značky, zdrojové číslo volajícího (Source call number) a bit F, který rozlišuje typ rámce. Full Frame má hlavičku 12B bajtovou stejně jako RTP. Obsahuje identické informace jako MiniFrame, včetně plné časové značky TimeStamp a navíc obsahuje číslo volaného (Destination Call Numer), OSeqno (OutBound stream sequence number), které udává číslo odchozích rámců a ISeqno (InBound stream sequence number) obsahující stejnou informaci pro příchozí rámce. Frame Type určuje typ rámce (DTMF signalizace, 165

175 10 MGCP a IAX protokol Hlasová data, Video, řídící rámec, IAX řízení, atd...). Pole C určuje jak bude interpretováno pole nazývané Subclass. Pokud je C rovno nule, potom Subclass je interpretován jako mocnina dvou, když je C jedna, Subclass je interpretován jako 7bitová hodnota. Pokud je pro přenos DTMF použit úplný rámec, Subclass obsahuje aktuální přenesenou číslici. Pokud je přenášeno video, hlas nebo obraz, pole Subclass udává typ komprese [mol1] Adresace v IAX2 Protokol IAX využívá pro adresaci standardních formátů typu URI (Uniform Resource Identifiers). Základní schéma URI protokolu IAX je následující: iax2:[uživatelské_jméno@ ]host[: port][/identifikátor[?kontext]] Jednotlivé položky mají následující význam: iax2 Označení protokolu, povinný údaj uživatelské_jméno Uživatelské jméno, vyžadováno pro registraci a autentizaci host Identifikace systému v síti. Akceptovány jsou IP adresy ve tvaru IPv4 nebo IPv6 nebo doménové jméno. port Určuje port protokolu UDP. identifikátor Číslo nebo jméno identifikující zdroj na konkrétním systému kontext Určení části systému, na kterém je služba provozována Příklady použití formátu: iax2:alice@ :4569/200?vlastni Zprávy IAX2 Zprávy protokolu IAX2 se dělí na dvě základní skupiny: spolehlivé (reliable) a negarantované (non-guaranteed). Mezi spolehlivé se řadí všechny ty, které využívají Full Frame [mol1]. Negarantované zprávy jsou označovány všechny informace, které jsou zaslány pomocí Mini Frame. IAX2 obsahuje následující zprávy: REGREQ Registration Request Message REGAUTH Registration Authentication Response Message REGACK Registration Acknowledgment Message REGREJ Registration Rejection Message REGREL Registration Release Request Message NEW Request Message AUTHREQ Authentication Request Message AUTHREP Authentication Reply Message ACCEPT Response Message 166

176 10 MGCP a IAX protokol RINGING Response Message ANSWER Response Message HANGUP Request Message REJECT Response Message ACK: Acknowledgement Message FLASH Request Message HOLD Request Message TXREQ Transfer Request Message TXCNT Transfer Connectivity Response Message TRANSFER Request Message UNHOLD Request Message PROCEEDING Response Message INVAL: Invalid Response Message VNAK: Voice Negative Acknowledgement Message MWI: Message Waiting Indicator Request Message UNSUPPORT Unsupported Response Message DTMF Media Message Voice Media Message Video Media Message Text Media Message Image Media Message HTML Media Message Comfort Noise Media Message LAGRQ Lag Request Message LAGRP Lag Response Message Pomocí LAGRQ se zjišťuje zpoždění mezi komunikujícími stranami, žádost LAQRQ obsahuje timestamp, který musí být vrácen (identický) v odpovědi LAQRP, tím pádem je zjištěn RTT. Zpráva Voice obsahuje typ kodeku a obsah přenášeného vzorku pomocí FULL Frame a tedy je potvrzena a jinak se přenáší obsah hovoru v Mini Frame rámcích. Ze znalosti protokolu SIP je debug IAX2 intuitivní a ukážeme si registraci, sestavení hovoru a ukončení Registrace pomocí IAX2 Při registraci je nejprve zaslána zpráva REGREQ (Registration Request Message) s uživatelským jménem a dobou vypršení registrace. Jestliže je vyžadována autentizace, tak Asterisk odpoví pomocí zprávy REGAUTH (Registration Authentication Response Message), která obsahuje podporované autentizační metody. Na obr je znázorněna celá výměna při úspěšné registraci, zároveň v obr vidíme, že autentizace byla možná pomocí MD5/RSA. 167

177 10 MGCP a IAX protokol Obr IAX2 zprávy při registraci s autentizací IAX2 klient odpoví opět zprávou REGREQ, přičemž tentokrát již zpráva obsahuje i autentizační údaje v potřebném formátu. Jestliže nelze registraci akceptovat, stav vzdáleného sytému bude neautorizovaný a žádné další akce nejsou nutné. Pokud je registrace akceptována, Asterisk odpoví zprávou REGACK (Registration Acknowledgment Message), která musí obsahovat IP adresu Asterisku a dobu vypršení registrace. Pokud tomu tak není, obě strany musí nastavit shodnou dobu vypršení registrace na 60 vteřin. Pokud je registrace odmítnuta, je zaslána zpráva REGREJ (Registration Reject Message). Každá registrace je platná jen po omezenou časovou periodu (standardně 60 sekund, jak již bylo uvedeno výše). IAX2 klient může tuto dobu prodloužit pomocí opakování registračního procesu nebo naopak zkrátit pomocí zprávy REGREL (Registration Release Request Message). Obr IAX2 zpráva REGAUTH Příklad sestavení hovoru pomocí IAX2 Inicializace hovoru začíná zasláním zprávy NEW klientem na Asterisk, viz. obr a Asterisk odpoví pomocí zpráv AUTOREK, pokud vyžaduje autorizaci, respektive ACCEPT nebo REJECT pro schválení nebo zamítnutí požadavku na sestavení hovoru. 168

178 10 MGCP a IAX protokol Obr 10.6 Počáteční fáze sestavení hovoru pomocí IAX2 Následuje vyzvánění indikované zprávou RINGING a protože je přenášená pomocí FULL Frame, tak zpráva je potvrzena pomocí ACK. Pokud je volaným IAX2 klientem hovor vyzvednut, tak je odeslána zpráva ANSWER, viz obr Obr Vyzvánění a přijetí hovoru v IAX2. Obr zobrazuje obsah NEW včetně seznamu podporovaných i nepodporovaných kodeků. 169

179 10 MGCP a IAX protokol Obr Obsah zprávy NEW inicializující spojení v IAX2 Během hovoru se v IAX2 může vyskytnout požadavek na vyvolání služby pomocí zprávy FLASH (FLASH Request Message) anebo přidržení spojení HOLD (HOLD Request Message), předání spojení TRANSFER (TRANSFER Request Message) a požadavek na pokračování po přidržení UNHOLD Request Message) Rozpad spojení v IAX2 Rozpad spojení se uskutečňuje odesláním zprávy HANGUP, viz. obr. 10.9, který nepotřebuje další komentář. Obr Rozpad spojení v IAX2 170

180 11 Asterisk 11 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 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 171

181 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. 11.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 Roadmapa verzí Asterisku 11.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 172

182 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 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.11.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). 173

183 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 174

184 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. 175

185 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. 176

186 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} 177

187 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 11.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.) 178

188 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 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 Options v asterisk.conf 179

189 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 Moduly v modules.conf 11.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

190 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= /

191 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ů 182

192 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ů 183

193 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

194 11 Asterisk 11.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. sip.conf [alice] context=vlastni extensions.conf [general] [globals] [vlastni] exten => alice,1,dial(sip/alice) Obr 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() 185

195 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. 186

196 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 187

197 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: 188

198 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} 189

199 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ě: 190

200 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) 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í: 191

201 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 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í. 192

202 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: 193

203 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]) 194

204 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 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 195

205 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) 196

206 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=

207 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 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): 198

208 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) 199

209 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) 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í. 200

210 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 201

211 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 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 202

212 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 203

213 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 204

214 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 205

215 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}) 206

216 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 207

217 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. 208

218 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 209

219 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 210

220 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 Vyplnění registrace XMPP klienta Pidgin 211

221 11 Asterisk Pokud vše proběhlo korektně, tak dostaneme potvrzení o úspěšné registraci. Obr 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 Vyplnění registrace XMPP klienta Spark 212

222 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. 213

223 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 BOB ALICE Kalendář dostupný? Ne Ano XMPP online? Ne Ne XMPP online? Ano Ano XMPP zpráva přijmout hovor? Ano Ne Ne XMPP zpráva přijmout hovor? Ano Vyzvánění 30s Přijetí hovoru J Ne HLASOVÁ SCHRÁNKA Ne Vyzvánění 30s Přijetí hovoru J Obr.11.8 Schéma chování prezenčního skriptu 214

224 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. 215

225 12 Kamailio 12 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 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.12.2 Souvislost mezi projekty vzešlých ze SER 216

226 12 Kamailio 12.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 Modulární architektura Kamailia Jádro Kamailia poskytuje: Management transportu a paměti Rozhraní pro moduly Konfigurace Uzamykání Moduly Kamailia poskytují: Funkce skriptů 217

227 12 Kamailio Speciální proměnné Parametry modulů Managementové funkce Podporovaných modulů je celá řada, viz. obr 12.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ů) Moduly Kamailia Obr. 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í 218

228 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 12.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! 219

229 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: :

230 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. 12.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 Potvrzení 200 OK na žádost INVITE 221

231 13 Aspekty kvality IP telefonie 13 Aspekty kvality IP telefonie Aplikace pracujících v IP síti v reálném čase kladou nároky na QoS (Quality of Service), což znamená snahu o dodržení předem stanovených parametrů při přenose dat. Zajištění QoS je důležité například při interaktivním přenosu hlasu či videa přes internet. V poslední době dochází k rozvoji těchto síťových aplikací, jejichž úspěšnost z pohledu uživatele významně závisí na časových charakteristikách přes danou síť. Definované parametry, jejichž určitou hodnotu je třeba během přenosu zajistit, slouží k tomu, aby koncové aplikace byly schopné správné činnosti a poskytly tak uživateli požadovanou službu [hos], [mol2]. Existují různé typy řešení a návrhy architektur, které zavádějí úrovně kvality služeb a seřazují datové jednotky přicházejícího provozu podle priorit. Kvalita služeb v referenčním modelu počítačové sítě může být implementována v různých vrstvách. Nejčastěji se používá implementace na úrovni linkové (802.1.p pole User priority v VLAN značce 802.1Q) nebo síťové vrstvy (DSCP kód v ToS). Při implementaci na úrovni IP protokolu existuje několik metod, avšak dva nejčastější způsoby řešení jsou Integrované služby (Integrated Service, IntServ) a Diferencované služby (Differentiated services, DiffServ) Kvalita služby (QoS) Kvalitou služby (QoS) rozumíme schopnost sítě poskytovat lepší zacházení vybranému síťovému provozu při použití různých technik pro přenos dat. Internet byl vybudován s cílem poskytovat přenosovou službu bez zajištění parametrů spojení. V současnosti se však velice rychle rozvíjí aplikace pracujících v reálném čase, jako jsou například videokonferenční hovory nebo IP telefonie. A právě pro tyto síťové aplikace je třeba klást velký důraz na zajištění kvality, neboť každá z těchto aplikací má vlastní specifické požadavky na přenos sítí. Na základě těchto požadavků proto byly definovány tyto základní QoS parametry: ztrátovost paketů (packet loss) zpoždění paketů (latency, delay) kolísání zpoždění (jitter) propustnost, přenosová rychlost, pásmo (throughput, transmission rate, bandwith) 222

232 13 Aspekty kvality IP telefonie Každý typ provozu je citlivější na jiný parametr, proto je důležité síťový provoz třídit a následně zajišťovat specifickou kvalitu služeb pro konkrétní třídy. Hlavním úkolem QoS je tedy minimalizovat nežádoucí vlastnosti přenosu a snažit se zajistit požadované hodnoty QoS parametrů. Toho lze však dosáhnout pouze za podpory všech síťových prvků podílejících se na přenosu IntServ Technologie Integrovaných služeb byla první technologie používanou v IP sítích, která umožňovala klasifikaci datových toků a přidělování síťových zdrojů podle typu služby a splnila tak oba výše popsané základní úkoly obecného QoS mechanizmu. Koncept Integrovaných služeb byl definován v roce 1994 v dokumentu RFC Základní myšlenka architektury IntServ vychází z okruhově-spínaného typu komunikace, kdy jsou síťové zdroje alokovány zvlášť pro každý vybraný tok dat. Aby aplikace získala požadované parametry přenosu, musí před samotným přenosem dat proběhnout proces rezervace. Rezervace síťových zdrojů se skládá z několika kroků. Nejprve musí aplikace definovat charakter odesílaných dat a také požadavky na síťové zdroje. Síť poté použije směrovací protokol pro nalezení vhodné trasy, která umožní uspokojení požadavků uživatelské aplikace. Následně je použit rezervační protokol pro vytvoření tzv. rezervačního stavu, který zajištuje garanci síťových zdrojů na všech zúčastněných uzlech podél celé trasy. Je tedy nutné vyjednat, zda jsou všechny prvky sítě schopné garantovat požadované parametry přenosu.. Jestliže poskytnuté síťové zdroje nejsou na některém z uzlů dostačující, spojení bude odmítnuto a zdrojová aplikace se může rozhodnout, zda se spokojí s mírnějšími požadavky, nebo odloží přenos. Pokud je však proces rezervace jednou schválen a řádně dokončen, aplikace může začít vysílat svoje data po rezervované trase. K zajištění informovanosti prvků sítě a tím pádem k rezervaci prostředků v síti slouží u mechanizmu IntServ tzv. rezervační protokoly. V praxi je používán především protokol RSVP (Resource Reservation Protocol). RSVP protokol poskytuje mechanizmus pro vytváření a správu rezervačního stavu podél celé trasy mezi zdrojem a cílem datového toku. Samotné rozhodnutí, která trasa bude pro přenos dat vybrána, je však provedeno směrovacím protokolem IntServ Architektura a protokol RSVP IntServ architektura definuje tři třídy: Best-effort class, základní třídu, Controlled-Load Class, třídu řízené zátěže, nabízí lepší službu než best effort Guaranteed Class, garantovanou třídu, garantuje zpoždění, pásmo, ztráty a dva popisovače provozu (traffic descriptors): TSpec (Traffic Specification), popisuje vlastnosti provozu, RSpec (Requirements Specification) popisuje požadavky na kvalitu služby jako end-toend zpoždění, jitter, zráty paketů 223

233 13 Aspekty kvality IP telefonie Referenční model technologie IntServ je možné rozdělit na dvě základní části - řídící rovinu a datovou rovinu. Řídící rovina zajišťuje proces rezervace síťových zdrojů a datová rovina provádí předávání datových paketů na základě vytvořeného rezervačního stavu. Hlavními bloky referenčního modelu IntServ, viz. obr. 13.1, jsou: Reservation Agent, rezervační agent, Admission Control, řízení přístupu, Classfifier, klasifikátor, Packet Scheduler, plánovač paketů, Obr Boky řešení IntServ Protokol RSVP zajišťuje rezervací zdrojů na trase pomocí dvou klíčových typů zpráv: PATH, odesíláno stranou inicializující spojení, popisuje vlastnosti provozu, jako objekty jsou tyto informace ukládány v každém uzlu trasy spojení, RESV, odesílá vzdálená strana příjemce zpět straně inicializující spojení zprávy, zpráva obsahuje datové objekty identifikující požadavky na zdroje (kvalitu služby) DiffServ DiffServ oproti IntServ používá odlišný způsob zajištění kvality služeb v IP sítích. Základní myšlenka je velmi jednoduchá. Jednotlivé datové toky jsou sdruženy do několika tříd podle 224

234 13 Aspekty kvality IP telefonie základního charakteru služeb, takže síťové prvky (s výjimkou hraničních) se nemusí starat o každý datový tok zvlášť]. Každý IP paket vstupující do datové sítě je označen značkou, která říká, jak má být s paketem zacházeno - neboli určuje třídu přenosu poskytnutou paketu. Toto značení paketů probíhá pouze na vstupu do datové sítě. Během přenosu paketů datovou sítí další směrovače pouze přečtou značku každého paketu a dle této značky se řídí při zacházení s paketem. Značka je uložena přímo v hlavičce IP paketu, takže není potřeba žádný signalizační protokol pro vytvoření rezervačního stavu. Dále, jelikož je síťový provoz sdružován a následně zpracováván v rámci tříd, odpadá potřeba složitého třídění a plánování síťových zdrojů pro jednotlivé datové toky, jako je tomu u IntServ Architektura DiffServ Architektura definuje třídy služeb založené na klasifikaci toků. Označení paketů je provedeno pomocí vzorků v oktetu ToS u IPv4 nebo nastavením parametru třídy provozu u IPv6 (Traffic Class Octet). Z pohledu mechanizmu diferencovaných služeb se rozsáhlé datové sítě dělí na menší oblasti, které se nazývají DiffServ domény. Každá DS doména je spravována jedním poskytovatelem připojení ISP a probíhá v ní jednotná administrace, která zajišťuje vyhodnocování oprávněnosti požadavků, přiřazení toků do jednotlivých tříd a označování paketů. V rámci DS domény jsou rozlišovány dva typy směrovačů: hraniční a páteřní. Obr Typy směrovačů v DiffServ doméně Edge Router - hlavní směrovač leží mezi dvěma DS doménami nebo na rozhraní mezi DiffServ doménou a částí sítě, která nepodporuje mechanizmus DiffServ. Tento směrovač tedy provádí klasifikaci vstupních toků a následné označování paketů, které jsou pak dále posílány do DiffServ domény. Core Router - páteřní směrovač se nachází uvnitř DiffServ domény. Nároky na tento prvek jsou podstatně menší v porovnání s hraničním směrovačem. Páteřní směrovač neprovádí žádnou klasifikaci paketů, zajišťuje pouhé předávání označených paketů a garantuje určitou kvalitu služby definovanou značkou v hlavičce paketu. 225

235 13 Aspekty kvality IP telefonie V rámci každé DS domény musí být jasně definována úroveň služby, kterou může koncový uživatel očekávat od sítě, respektive od ISP. K tomuto účelu slouží dohoda o úrovni poskytované služby Service Level Agreement (SLA). Dohoda SLA je aplikována na rozhraních mezi uživatelem a DS doménou nebo dvěma DS doménami spravovanými různými ISP a jasně vymezuje povolené profily síťového provozu, podmínky zacházení s datovými toky, konkrétní síťové parametry pro jednotlivé třídy provozu atd. Referenční model technologie DiffServ je definován v RFC 2475, model diferencovaných služeb se skládá z několika bloků, viz. obr a je možné jej rozdělit na dvě základní části. Na část klasifikace, kde probíhá měření a značkování a část pro úpravu provozu (zacházení), která na základě parametrů provozu a značek přidělených jednotlivým paketům rozhoduje o jejich dalším zpracování. Obr Referenční model DiffServ Třídič (Classifier) provádí identifikaci přicházejících paketů a jejich následné dělení do několika skupin podle předem definovaných pravidel. Měřič (Meter) provádí měření pro každý datový tok od zákazníka a poté výsledky porovná s konkrétním datovým profilem. Přeznačovač (Remaker) provádí přeznačkování, ke kterému může dojít na základě nesplnění kritérií pro jejich definovanou třídu provozu. Většinou se jim proto nastaví vyšší priorita zahození při případném zahlcení sítě v dalších směrovačích. Dalším důvodem k přeznačení paketů může být jejich přechod mezi dvěma DS doménami, které používají odlišného způsobu třídění provozu. Tvarovač (Shaper) má za úkol přenést datový tok do souladu se sjednaným datovým profilem. Rozdíl mezi tvarovačem a značkovačem je v tom, že značkovač jednoduše označí paket a nechá jej projít do sítě. Zatímco tvarovač zabrání paketům projít sítí do té doby, dokud se datový tok nepřizpůsobí danému profilu. Tvarování je méně náročná forma zacházení s pakety než značení. Stejně jako přeznačení, tak i tvarování je důležité v hraničním uzlu mezi dvěma DiffServ doménami. 226

236 13 Aspekty kvality IP telefonie Zahazovač (Dropper) realizuje jednodušší metodu zpracování paketů než tvarovač. Příchozí pakety, které nevyhovují jejich definovanému profilu provozu, jsou vyřazeny z provozu jejich zahozením. Proto zahazovač nepotřebuje vyrovnávací paměť. Značkovač (Marker) přiděluje každému toku dat určitou značku, která definuje způsob, jak se s ním bude zacházet v síti tzv. Per Hop Behavior index (PHB index). Jsou definovány tři typy PHB: Expedited Forwarding (EF) urychlené doručení, Assured Forwarding (AF) zaručené doručení, celkem 12 možností, viz. tab Best Effort (BE) základní služba bez prioritizace Expedited Forwarding nabízí absolutní záruku velikosti kolísání zpoždění pro danou třídu provozu. Tento typ je proto velmi složitý na zajištění a tím pádem neefektivní. Poskytnutí EF danému toku znamená vyhrazení téměř všech síťových prostředků pro tento tok, což pak vede k neefektivnímu využívání prostředků sítě. Urychlené doručení je tedy možné používat pouze v omezené míře. Služba Assured Forwarding je navržena tak, aby zajistila přenos garantovanou rychlostí. AF zajišťuje nižší garance QoS než EF a používá se především pro transportní protokol TCP. AF pracuje na základě stanovení priorit pro různé kategorie provozu. Best Effort představuje základní službu, která je vhodná pro přenos dat nenáročných na zajištění QoS parametrů. U služby BE není žádná garance QoS, síť se pouze snaží doručit pakety nejlepším možným způsobem s využitím aktuálně dostupných síťových prostředků. Mechanizmus DiffServ je postaven na předpokladu odlišného zacházení pro jednotlivé pakety. Aby to bylo možné, je třeba pakety nějakým způsobem od sebe odlišit. K tomu slouží jedinečný identifikátor, značka, označovaný jako DSCP (DiffServ Code Point). Tato značka je uložena v hlavičce IP paketu v poli označovaném jako DS pole, viz. obr Velikost DS pole je 8 bitů, avšak pro uložení DSCP značky se používá pouze prvních 6 bitů, zbylé dva jsou momentálně nevyužité DSCP unused Obr DSCP pole DSCP značka Značka DSCP definuje konkrétní třídu provozu a na ni je navázán definovaný způsob zacházení s pakety patřícími do dané třídy. V rámci architektury Diferencovaných služeb se způsob zacházení s pakety označuje zkratkou PHB (Per Hop Behaviour). PHB nedefinuje přímo konkrétní mechanizmy nebo způsob jejich implementace, ale obsahuje spíše obecný popis způsobu zacházení s pakety (v závislosti na DSCP) nebo specifikaci parametrů požadované služby v rámci 227

237 13 Aspekty kvality IP telefonie dané DS domény. Pro dosažení stejné úrovně zacházení v rámci konkrétního PHB je tedy možné použít různé fyzické implementace metod řízení front a plánování odesílání paketů. Velikost DSCP je 6 bitů, první 3 bity odpovídají IP Precedenci. Pole v IP hlavičce, které umožňuje rozlišení provozu do několika tříd, nutných pro odlišný způsob obsluhy, může obsahovat hodnotu DSCP (Differentiated Services Code Point) kód, viz. obr anebo IP precedence, viz. obr Zatímco DSCP používá šest bitů, tak IP precedence tři bity Precedence TOS MBZ Obr IP precedence Hodnota IP precedence obsahuje tříbitovou informaci sloužící k rozlišení toku. Ta umožňuje definovat až osm rozdílných provozních tříd. To je poměrně dostatečný počet pro rozlišování jednotlivých toků, není to však dostačující počet pro přesné nastavení odlišných politik pro zacházení s více typy provozu. Výchozí hodnotou pole IP precedence je nula. Vyšší hodnota tohoto pole značí vyšší přednost. DSCP umožňuje vhodnější značkování provozu, DSCP obsahuje šestibitovou informaci sloužící k rozlišení toku. Ta umožňuje definovat až 64 jednotlivých provozních tříd. To je dostatečný počet nejen pro standardní, ale i pro specifičtější třídy provozu. Standardně je definováno pouze 14 tříd (kromě EF a BE je možné rozlišit 12 kategorií pomocí AF. Čím hodnota pole, tím větší je priorita daného provozu. Pro PHB AF, viz. tab. 13.1, se doplňuje toto číslo do názvu (např. AF4x). Další dva bity určují pravděpodobnost zahození, čím větší číslo, tím spíše dojde k zahození provozu (AFx1 nízká pravděpodobnost zahození, AFx2 střední pravděpodobnost zahození, AFx3 vysoká pravděpodobnost zahození). Poslední bit je 0. Drop Precedence Class #1 Class #2 Class #3 Class #4 Low Drop Prec AF AF AF AF Medium Drop Prec AF AF AF AF High Drop Prec AF AF AF AF Tab PHB typu Assured Forwarding 228

238 13 Aspekty kvality IP telefonie Následující tabulka 13.2 ukazuje doporučené hodnoty IP Precedence (IPP) a k nim odpovídající PHB třídy spolu s hodnotou DSCP (binárně, v závorce decimálně). Per Hop Behavior index / DSCP nízká pst. zahození střední pst. zahození vysoká pst. zahození BE (0) AF (10) AF (18) AF (26) AF (34) AF (12) AF (20) AF (28) AF (36) AF (14) AF (22) AF (30) AF (38) EF (46) Tab Index PHB Plánované odesílání paketů umožňuje prioritní zacházení pro vybrané třídy síťového provozu, což je základní myšlenka téměř všech technologií pro zajištění kvality služeb. Proto je plánované odesílání paketů srdcem každého QoS mechanizmu, neboť právě tento proces má zásadní vliv na výslednou úroveň kvality uživatelské aplikace. Pojmem plánované odesílání paketů jsou většinou označeny dva úzce související procesy - proces řazení paketů do front a proces řízeného odesílání, který rozhoduje, který paket bude odeslán na výstupní rozhraní síťového prvku. Plánované odesílání paketů je u technologie DiffServ prováděno na základě DSCP značky a k ní přidruženému způsobu zacházení PHB. Mezi nejpoužívanější mechanizmy plánovaného odesílání paketů například patří FIFO (First In First Out), PQ (Priority Queuing), WFQ (Weighted Fair Queuing), jejichž bližší popis je v další kapitole. 229

239 13 Aspekty kvality IP telefonie 13.4 Nástroje QoS Pakety, které mají být poslány ven ze směrovače přes určité rozhraní, se dočasně umístí do paketové fronty, pokud je v daném okamžiku příslušné rozhraní zaměstnáno vysíláním jiného paketu. Paketových front může být na určitém rozhraní i více (např. pro různé druhy provozu). V takovém případě je nutno definovat metodu obsluhy těchto front, tj. způsob a pořadí, v jakém budou pakety vybírány z jednotlivých front a posílány přes rozhraní ven ze směrovače. Také uvnitř každé fronty je definován určitý mechanizmus, který seřazuje pakety. Ve většině případů se jedná o metodu FIFO. Paketové fronty mají vliv na všechny přenosové parametry. Čím delší je paketová fronta, tím větší je zpoždění a variabilita zpoždění paketů, ale tím menší je ztrátovost paketů. Pokud dojde na delší dobu k zahlcení daného rozhraní, tj. počet paketů vkládaných do fronty je delší dobu větší než počet paketů vybíraných z fronty, je ztrátovost vysoká bez ohledu na délku fronty. Kromě dříve popsaných softwarových front, existuje v každém rozhraní i malá hardwarová fronta, kam se umisťují pakety těsně před vysláním ze směrovače. Důvodem její existence je, aby vysílání paketu nebylo zdrženo procesem vybírání paketu ze softwarových front [mac], [hos], [mol2] Obsluha paketových front Metody obsluhy paketových front patří mezi QoS nástroje pro řízení stavů zahlcení sítě (congestion management). Modely řazení paketů do front nám popisují vřazení jednotlivých typů informace do příslušné fronty a způsob její obsluhy [hro]. Základní modely řazení provozu do front jsou: Základní řazení FIFO (First In First Out) Vážené řazení do front WFQ ( Weighted Fair Queuing) Vlastní řazení do front CQ (Custom Queuing) Prioritní řazení do front PQ (Priority Queuing) Druhou skupinou modelů řazení paketů do front jsou modely složitější, odpovídající zejména kombinacím modelů základních. Z možných kombinací se nejčastěji můžeme setkat s těmito modely: Vážené řazení do front na základě třídy CBWFQ (Class-Based Weighted Fair Queuing) Prioritní řazení do front / Vážené řazení do front PQ/WFQ (Priority Queuing / Weighted Fair Queuing) Řazení do front s nízkou latencí LLQ (Low Latency Queuing) Metoda FIFO Nejzákladnějším typem obslužné fronty je FIFO (First In First Out). Tato fronta je základním prvkem většiny modelů. FIFO používá jen jednu frontu, ze které se pakety vybírají v tom pořadí, ve kterém byly do ní vloženy. Není zde nutná žádná klasifikace paketů. 230

240 13 Aspekty kvality IP telefonie Metoda CQ CQ pracuje také na principu rozdělení toku do více obslužných front. U metody CQ není přenosové pásmo rozděleno ve vyváženém poměru. Přidělené pásmo pro danou frontu může být nastaveno konkrétní hodnotou, nebo procentem z celkově poskytované šířky pásma. V případě vyprázdnění obslužné fronty, je její přidělené pásmo v příslušném poměru rozděleno mezi fronty zbývající. CQ používá až 16 uživatelem definovaných paketových front. Paketové fronty jsou cyklicky obsluhovány jedna za druhou. Z každé fronty se vybírají pakety, dokud není překročen limit počtu bytů pro danou frontu nebo dokud zbývá ve frontě nějaký paket. Poté se stejným způsobem obslouží další fronta. Tímto způsobem lze garantovat jednotlivým frontám určité procento z celkové přenosové rychlosti příslušného rozhraní. Pokud jsou některé fronty dočasně bez paketů, zbývající fronty si automaticky přerozdělí nevyužitou část přenosové rychlosti rozhraní. Klasifikace Obsluha fronty Přidělené pásmo 15% Přidělené pásmo 30% Přidělené pásmo 55% Obr Ilustrace obsluhy v režimu CQ Metoda WFQ WFQ pracuje na principu rozdělení toku do více obslužných front na základě jejich klasifikace. Klasifikace bývá provedena nejčastěji na základě typu datového toku nebo na základě zdroje toku. Celé dostupné přenosové pásmo je rozděleno ve vyváženém poměru mezi jednotlivé obslužné fronty. Obslužné fronty využívají k obsluze svých požadavků přidělené pásmo. V případě že dojde k vyprázdnění konkrétní obslužné fronty, je její přidělené pásmo dynamicky rozděleno mezi fronty u nichž dochází k obsluze. V případě příchodu požadavku do prázdné fronty je ostatním frontám naopak pásmo odebráno. V tomto modelu tak nevzniká situace, při které by jeden typ datového toku zahltil celé přenosové pásmo a tím zabránil obsluze ostatních toků. Klasifikace Obsluha fronty Obr Ilustrace obsluhy v režimu WFQ WFQ používá pro každý datový tok (data z určité IP adresy a portu aplikace na určitou IP adresu a port aplikace) samostatnou frontu. Počet front se rychle mění, každá fronta má přiděleno určité 231

241 13 Aspekty kvality IP telefonie vážené procento z celkové přenosové rychlosti rozhraní v závislosti na počtu datových toků v daném okamžiku. Váha je odvozena od hodnoty IP precedence Metoda PQ PQ pracuje na principu rozdělení datového toku do front s různou prioritou. Je-li požadavek na základě své klasifikace přiřazen do fronty s vyšší prioritou, je obsloužen dříve, než požadavek přiřazený do fronty s prioritou nižší. Obsluha fronty s vyšší prioritou probíhá do momentu, než je tato fronta kompletně vyprázdněna. Po jejím vyprázdnění začíná obsluha fronty s nižší prioritou. Celý proces se opakuje až do obslužné fronty nejnižší priority. V okamžiku příchodu požadavku do fronty s vyšší prioritou, než je priorita fronty obsluhované, je v případě obsluhy bez přerušení obsloužen stávající požadavek a až poté nově příchozí požadavek s vyšší prioritou. Nevýhodou této obslužné metody je, že v případě stálého zaplnění fronty s vyšší prioritou nemusí být požadavky s nižší prioritou v požadované době obslouženy. Tento model je díky svým obslužným parametrům, dostupným zejména požadavkům zařazeným ve vyšší prioritní frontě, vhodný pro aplikace s vysokými nároky na zpoždění přenosu, které mají nízké požadavky na přenášenou šířku pásma. Tento obslužný model je tedy vhodný pro obsluhu provozu generovaného aplikacemi pracujícími v reálném čase. Klasifikace Obsluha fronty Prioritní třída 1 Prioritní třída 2 Prioritní třída 3 Obr Ilustrace obsluhy v režimu PQ Metoda CBWFQ CBWFQ kombinuje vlastnosti CQ a WFQ, provoz je rozdělen do front (až 64) jako u CQ s tím, že na rozdíl od CQ je každé frontě garantováno určité procento z přenosové rychlosti rozhraní. V rámci jednotlivých front se používá buď FIFO nebo WFQ. V praxi se obvykle vyčlení fronty pro typy provozu, kterým chceme garantovat určitou přenosovou rychlost. Tyto fronty používají metodu FIFO. Zbytek provozu se umístí do zvláštní fronty, která používá metodu WFQ Metoda PQ/WFQ PQ/WFQ je založena na kombinaci dvou jednodušších front. Fronty PQ a fronty WFQ. Principem tohoto modelu je upřednostnění obslužné fronty PQ před frontami WFQ. WFQ v tomto modelu zastupuje PQ frontou s nižší prioritou. Tímto obslužným modelem zajistíme jednak upřednostnění informací citlivých na zpoždění a zároveň i obsluhu dalších informací pomocí front typu WFQ. PQ/WFQ je tedy z hlediska obsluhy v reálného provozu výhodnější než obslužný model PQ. 232

242 13 Aspekty kvality IP telefonie Klasifikace Obsluha fronty Obr Ilustrace obsluhy v režimu PQ/WFQ Metoda LLQ LLQ je metoda vycházející z metody PQ/WFQ a CBWFQ. Oproti metodě PQ/WFQ zavádí možnost rozdělení jednotlivých toků do několika tříd, u kterých je možné přiřadit specifickou část systémových prostředků. Možné je přiřazení systémových prostředků celé prioritní frontě. Jelikož je oproti metodě PQ/WFQ přidána možnost specifikace systémových prostředků, můžeme se setkat i s označením PQ/CBWFQ. Z hlediska obsluhy reálného provozu je, z výše uvedených modelů, tento model nejvhodnějším pro obsluhu provozu generovaného aplikacemi pracujícími v reálném čase. Aby provoz z LLQ fronty neznemožnil přenos i jiných typu dat, jako se to může stát u PQ, definuje se pro LLQ určitá maximální přenosová rychlost, po jejímž překročení se přebývající pakety zahazují. Klasifikace Obsluha fronty Obr Ilustrace obsluhy v režimu LLQ Řízení toku a zahlcení Jestliže totiž dojde ve směrovači k úplnému zaplnění výstupní fronty směrovače, jsou všechny další pakety určené pro tuto linku zahazovány (mluvíme o tzv. tail drop, jelikož se zahazují pakety na konci fronty, resp. za ním). Pokud přes takovéto rozhraní prochází větší množství TCP spojení, budou ze všech těchto spojení zahazovány pakety a odesílatel neobdrží několik následných potvrzení. To se projeví u odesílatele poklesem intenzity vysílání. U TCP se používá mechanizmus oken, který reguluje, kolik segmentů lze odeslat vysílačem bez čekání na potvrzení o jejich doručení do cíle. Čím větší je toto okno, tím více segmentů se přenese za jednotku času. Naopak snížením velikosti okna se dosáhne snížení množství vysílaných segmentů, protože se častěji čeká na potvrzení o přijetí dříve poslaných segmentů. 233

243 13 Aspekty kvality IP telefonie Obr Využití fronty u Tail drop. Dalším mechanizmem je algoritmus Random Early Detection (RED), který je postaven na inteligentním zahazováním paketů, dříve než se zaplní fronta a zpomaluje tok v TCP relace. Odesílající strana TCP reaguje na zahozené pakety zpomalením. Dochází ke globálně synchronizovaným vlnám zahlcení, při zahlcení se začne zahazovat veškerý provoz, všechna TCP spojení tedy zpomalí, což má za následek, že v součtu se opět část pásma uvolní a rychlost jednotlivých TCP relací začne opět narůstat. Důmyslnější variantou RED je Weighted Random Early Detection ( WRED), ve které jsou různé profily dle váhy, důležitější toky zahazuje méně na základě IP Precedence a DSCP. Další variantou je Class Based Weighted Random Early Detection (CBWRED) s rozšířením na třídy Komprese RTP a fragmentace Efektivním nástrojem pro snížení RTP režie je použití komprese crtp (Compressed Real-Time Protocol) a dosáhnout snížení ze 40 Bytes RTP hlavičky na 2-3 Bytes crtp. Použití crtp je omezeno na link-by-link, tzn. např. mezi dvěma směrovači. LFI (Link Fragmentation and Interleaving) je technika, která rozdělí velké rámce na menší o stejné velikosti a vysílá je prokládaně (dovolí mezi ně vložit jiné rámce). Výhodou je, že se jiné malé pakety jako např. VoIP dostanou rychle na rozhraní k odeslání na linku a nemusí čekat, než se odešle nějaký velký rámec. Zmenší se serializační zpoždění (odesílání přes výstupní rozhraní směrovače). LFI se používá hlavně na pomalých linkách, kde je může být velké serializační zpoždění,, např. odeslání 1500B přes linku 64kbps trvá 187,5 ms. 234

244 13 Aspekty kvality IP telefonie 13.6 Kvalita řeči Při přenosu hlasu pomocí nespojově orientovaného přenosu v IP síti má na výslednou kvalitu hlasového provozu vliv více faktorů, než tomu bylo v případě přenosu hlasu klasickými telekomunikačními technologiemi [har]. Jednotlivými faktory, které mají v prostředí VoIP vliv na kvalitu hovoru jsou zpoždění, kolísání zpoždění, ztráta paketů, posloupnost paketů, použitý kodek a nakonec i echo (ozvěna). Hodnocení kvality hovoru, na který má vliv řada různých faktorů, není zcela triviálním úkolem. Pro komplexní hodnocení kvality je vhodné použít jednotný parametr, pomocí něhož jsme schopni kvalitu vyjádřit. V prvé řadě je nutné provést základní klasifikaci kvality, kterou si rozdělíme na: poslechovou LQ (Listening Quality), konverzační CQ (Conversational Quality), a očekávanou EQ (Estimated Quality). Kvalita hovoru CQ je v telefonii klíčovou záležitostí a definovat její úroveň je úkol velmi obtížný, protože kvalita je individuální. Je vysoce pravděpodobné, že kvalita jednoho hovoru bude různými osobami posuzována rozdílně a je rovněž pravděpodobné, že při opakovaném posuzování stejného vzorku hovoru jednou osobou dojdeme k různým výsledkům. Při hodnocení kvality se používá stupnice MOS (Mean Opinion Score). Při subjektivním hodnocení posluchači používají hodnoty 1 až 5, kde 5 odpovídá nejlepší kvalitě a 1 nejhorší kvalitě. Z jednotlivých hodnocení je určen aritmetický průměr MOS. 5 - vynikající kvalita, neznatelné rušení, 4 - dobrá kvalita, rušení lze rozpoznat, ale není obtěžující, 3 - kvalita je průměrná, rušení lze rozpoznat a mírně obtěžuje, 2 - kvalita je nízká, rušení obtěžuje, je nutno vyvinout úsilí při snaze porozumět. 1 - špatná kvalita, rušení velmi obtěžuje, řeč je nesrozumitelná. Pro hodnocení kvality hovoru je vhodnější použití objektivního hodnocení, které poskytne MOS co nejvíce korelující se subjektivním názorem. Hodnotící model, který byl vyvíjen s ohledem na VoIP, je specifikován v doporučení ITU-T G.107 a nazývá se E-model [har]. Jedná se o výpočetní model, který patří mezi neintrusivní přístupy. Myšlenka je následující, na základě znalostí přenosové trasy lze pomocí E-modelu vypočíst míru degradace řečového signálu průchodem přenosovou trasou a spočíst očekávaný MOS (resp. R-faktor, odpovídá konverzační kvalitě a lze přepočíst na MOS). Výsledkem E-modelu je skalár, R-faktor nabývající hodnoty 0 až 100 (pro úzkopásmové kodeky 0 až 94 a pro širokopásmové 0 až 129), slovní prezentace je uvedena v tab a lze nalézt tyto kritické hodnoty: R<50, telefonii s takovouto hodnotou R není doporučeno používat, 50<R<70, hovory jsou problémové, uživatelé jsou nespokojeni, R>70, převládá spokojenost. 235

245 13 Aspekty kvality IP telefonie Tab Hodnocení kvality R-faktorem a MOS. Rozsah R - faktoru Rozsah MOS Kvalita hovoru Spokojenost uživatelů 90 R < 100 >4,3 Nejlepší (Bust) Velmi spokojení 80 R < 90 4,0-4,3 Vysoká (High) Spokojení 70 R < 80 3,6-4,0 Střední (Medium) Někteří uživatelé nespokojení 60 R < 70 3,1-3,6 Nízká (Low) Mnoho uživatelů je nespokojených 50 R < 60 2,6-3,1 Špatná (Poor) Skoro všichni jsou nespokojení Principem E-modelu je sčítání jednotlivých faktorů ovlivňujících celkovou kvalitu, a proto je hodnotící faktor R kombinací sčítání a odečítání jednotlivých komponent, což prezentuje rovnice (13.1). R = R -I I I A (13.1) 0 S D e-eff V této rovnici Ro představuje úroveň odstupu signálu od šumu SNR zahrnující jak zdroj rušení el. obvody, tak i hluk v místnosti. Faktor Is zahrnuje vliv snížení kvality hovoru působící víceméně souběžně s vlastním hlasovým signálem, jde tedy o změnu úrovně signálu. Faktor Id představuje vlivy, které jsou způsobeny zpožděním Ie-eff je efektivní faktor zařízení, který zahrnuje nejen vliv zařízení (vliv použitého kodeku původní faktor zařízení) ale i ztrátovost. Tento faktor v revizi E-modelu z roku 2002 nahradil faktor Ie používaný v dřívějším E-modelu z roku 2000, každopádně Ie-eff zahrnuje ve svém výpočtu i Ie, který tvoří jednu z komponent efektivního faktoru zařízení. Hodnoty Ie jsou publikovány jako dodatky doporučení ITU-T G.113 a je proto vhodnější použít aktuální hodnoty Ie přímo ze stránek ITU-T [G113]. Například pro kodek G.711 je hodnota Ie=0 a pro G.729 Ie=10. Posledním parametrem je faktor zvýhodnění A umožňující kompenzaci nepříznivých faktorů. Faktor zvýhodnění A nemá žádnou souvislost k ostatním přenosovým parametrům a zvýhodňuje určité typy terminálů, které svým charakterem mají vliv na vynaložení úsilí porozumění při jejich použití. 236

246 13 Aspekty kvality IP telefonie 13.7 Vliv zabezpečení na kvalitu hovoru V kapitole 1.5 je vysvětlen způsob zabezpečení pomocí SRTP a ZRTP. Formát paketu přináší minimální overhead, který je v poli authentication tag (80 bitů nebo 32 bitů), vlastní šifrování AES v CM režimu má vlastnosti proudové šifry a nedochází k vkládání dalších výplňových bitů. Významný overhead je především v souvislosti s TLS a IPsec, kde jsou používány blokové šifry RTP přes TLS Transport Layer Security (TLS) je protokol umožňující zabezpečenou komunikaci v IP sítích, data na aplikační vrstvě jsou šifrovány. Při sestavování TLS spojení se obě strany nejdříve dohodnou na podporovaných algoritmech, vymění si klíče a autentizují se se na základě certifikátu, při autentizaci se používá asymetrická kryptografie. Šifrování provozu se již provádí symetrickou šifrou. Jestliže předpokládáme navýšení RTP toku vlivem šifrování v TLS, tak můžeme vyloučit proudové šifry, neboť zde jednak nedochází k doplňování bloků užitečné zátěže a jednak se v TLS prakticky nepoužívají. Obr Zpracování RTP paketu v CBC módu Blokové šifry mají několik schémat, ze kterých je TLS provozováno v CBC módu, viz. obr (resp. 1.8 v kapitole 1.5). Jedná se režim řetězové blokové šifry (Cipher Block Chaining), inicializační vektor se sečte na členu XOR s prvním blokem užitečné zátěže, následně jsou data šifrována vhodným kryptografickým algoritmem a zároveň slouží jako vstup do dalšího bloku, takto dochází k 237

247 13 Aspekty kvality IP telefonie řetězení označovaného jako CBC. Obr znázorňuje rozdělení jednoho RTP paketu do N bloků, každý blok má stejnou velikost, která v případě šifrovacího algoritmu AES má 128 bitů. Zde pozor na záměnu s vlastní klíčem v AES algoritmu, ten může mít jinou velikost (128, 192 nebo 256 bitů), blok má ale stejnou délku 128 bitů. Pokud se aplikují jiné algoritmy, tak v případě DES, 3DES a Blow Fish je velikost bloku 64 bitů. Základními kroky předcházející odeslání hlasu v RTP paketu je kódování určitým typem kodeku a paketizace. RTP pakety jsou odesílány v dedikovaných intervalech a načasování odeslání bude záviset jednak na velikosti užitečné zátěže a jednak rychlosti výstupního toku z kodéru. Základní rovnice, která vyjadřuje časování odesílání RTP je vyjádřena v rovnici 1.7 v kapitole 1.9 a aplikací vztahů 1.8 a 1.9 dospějeme k vyjádření hodnoty nárokovaného pásma RTP tok (13.2). BW M S Fi M i1 ti (13.2) Velikost rámce S F je dána součtem hlaviček na linkové, síťové a transportní vrstvě s velikostí zprávy na aplikační vrstvě (13.3) a t [s] je časování (timing odesílání RTP). 3 j1 H j 3 F AL j j1 S S H (13.3) Ačkoliv TLS protokol nese v názvu označení transportní, tak ve skutečnosti je umístěn mezi transportní a aplikační vrstvou, což je v TCP/IP modelu poněkud zavádějící. TLS šifruje data aplikační vrstvy, ale transportní vrstva je nedotčena. Nebudeme tedy zasahovat do rovnic vyjadřující velikost na transportní vrstvě, ale nahradíme velikost zprávy na aplikační vrstvě za parametr vyjadřující velikost zprávy po aplikaci TLS. Substituce odpovídá výše uvedenému popisu umístění TLS v TCP/IP modelu a její vyjádření je provedeno následovně: S C S B AL TLS 0 S BS (13.4) Symbol x označuje ceiling funkci pro kterou platí x minn x n 238,což znamená, že ceiling funkce pro x vrátí nejbližší celé číslo, které je větší nebo rovno x. Ceiling funkci definoval poprvé M. Schroeder [schr] v roce 1991 a symbol byl označen K. Iversonem v roce Parametr představuje velikost bloku ve režimu CBC, jehož vytvoření bylo již vysvětleno. Užívané hodnoty 64 a 128 bitů závisí na použitém kryptografickém algoritmu (AES, DES, Triple DES, Blow Fish). Jelikož implementace OpenVPN přidává další blok konstantní velikosti, tak byla zavedena konstanta C 0 a výchozí hodnota TLS je pro C0 0, v případě různých implementací TLS ve VPN může nabývat různých hodnot, např. pro OpenVPN a CBC s velikostí bloků 64 bitů je C0 600 bitů a C 664 bitů pro OpenVPN v CBC režimu s šifrou používající bloky 128 bitů. 0

248 13 Aspekty kvality IP telefonie Tab Srovnání RTP vs. TLS a TLS/OpenVPN t RTP TLS TLS/OpenVPN Kodek [ms] [kbps] [kbps] [kbps] G.711 PCM 20 90,40 96,80 130,00 G.729 CS-ACELP 20 34,4 39,2 72,4 G ACELP 30 22,93 26,13 48,27 Údaje v tabulce byly vypočteny pro Ethernet rámce a TLS v CBC s AES-128. Typická paketizace RTP je u G.729 t = 20 ms, je zde vidět markantní rozdíl mezi RTP nešifrovaným BW=34,4 kbit/s a šifrovaným TLS/OpenVPN s více než dvojnásobnými nároky BW=72,4 kbit/s. Obr Závislost pásma na časování u G.711 v TLS s AES šifrou Obdobně můžeme konstatovat, že u G.711 kodeku, viz. obr , kde rovněž typické rozestupy RTP paketů jsou t = 20 ms, vychází v OpenVPN BW=130 kbit/s oproti BW=90,4 kbit/s 239

249 13 Aspekty kvality IP telefonie nešifrovaného RTP. Typické časové odstupy RTP paketů u G kodeku jsou t = 30 ms. Zjištěné údaje se pochopitelně musí zohlednit při plánování síťových kapacit VoIP provozu poskytovateli IP telefonie. Zajímavé by mohlo býti použití protokolu DTLS (Datagram TLS) RFC 4347 Jedná se o obdobu TLS, která je upravena pro spolupráci s protokolem UDP, v DTLS může nalézt zabezpečení řada aplikací vyžadující nízké zpoždění za cenu možné ztrátovosti paketů a VoIP mezi ně určitě patří RTP přes IPsec Šifrování na síťové vrstvě IPsec se oproti TLS používá v menším měřítku. IPsec umožňuje zabezpečit komunikaci přes IP protokol a to autentizací a šifrováním každého datagramu toku. Obsahuje protokoly pro výměnu vzájemné autentizace mezi komunikujícími agenty a výměnu šifrovacích klíčů. Zabezpečení je provedeno pomocí dvou protokolů AH (Authentication Header) dle RFC 4302 a ESP (Encapsulation Security Payload) dle RFC AH implementuje autentizaci pro datový tok a můžeme analyzovat tyto situace: V AH transportním módu je IP paket pouze modifikován přidáním AH hlavičky mezi IP hlavičku a a zbytek TCP paketu. V původní IP hlavičce je přepsán protocol code, tak, aby došlo k propojení IP hlavičky s AH hlavičkou. V tunelovém módu se na rozdíl od transportního módu enkapsuluje celý paket včetně IP hlavičky, to umožňuje, aby nový paket měl jinou zdrojovou a cílovou IP adresu než má původní neenkapsulovaný paket. Tato vlastnost umožňuje vytvoření virtuálního tunelu. Pokud IPsec pracuje v tunelovém módu, tak v poli next header hlavičky AH bude hodnota IP. ESP dokáže data nejenom autentizovat,ale také šifrovat. Zatímco AH přidává k zabezpečenému paketu novou hlavičku, ESP obklopí množství užitečné informace IP paketu. Tím je šifrování pomocí ESP komplikovanější než autentizace pomocí AH. Kromě polí, které jsou obsaženy i v AH hlavičce, obsahuje ESP hlavička navíc pole padding, které slouží k doplnění do odpovídající velikosti paketu při využití blokových šifer (opět převažuje CBC). A opět můžeme uvést dvě situace, a to pro transportní a tunelový mód: transportní mód, stejně jako u AH, enkapsuluje pouze užitečnou informaci, v datagramu, tzn. od síťové vrstvy nahoru, původní IP hlavička je v datagramu zachována, zdrojová ani cílová IP adresa se nemění, ESP v tunelovém módu je velice podobné tradičnímu VPN, enkapsuluje celý IP datagram, viz. obr Obr Formát datagramu IPsec v tunelovaném módu ESP+AH 240

250 13 Aspekty kvality IP telefonie U AH autentizace bylo možné podle obsahu pole next header v nově vytvořené IP hlavičce určit, zda se jedná o transportní či tunelový mód. U ESP je totiž toto pole součástí zašifrovaného obsahu. Prakticky se používá v drtivé většině tunelový mód ESP pro realizaci VPN kombinovaný s AH autentizací a proto se budeme zabývat pouze tunelovým módem, viz. obr Pro výpočet lze využít rovnici, kde je nutné k velikosti užitečné zátěže příspěvek hlaviček jednotlivých vrstev 3 j1 H j S AL vyjádřit celkový. Empiricky bylo zjištěno, že výpočet může být podstatně zjednodušen a přitom poskytne relevantní výsledky, byl prověřen vzorek tří set hovorů přes IPsec. Pro tunelový ESP mód vložený do AH zavedeme konstanty IPsec pro typické velikosti užitečné zátěže: G.711, H IPsec =704 b G.729, H IPsec =672 b G (5,3 kbit/s), H IPsec =672 b Do rovnice dosazujeme výše uvedené hodnoty pro IPsec jako H 2. 3 H RTP H j j1 BW M M C R 1 P S (13.5) Tab Srovnání RTP vs. SRTP a IPsec t RTP SRTP IPsec Kodek [ms] [kbps] [kbps] [kbps] G.711 PCM 20 90,40 94,4 117,6 G.729 CS-ACELP 20 34,4 38,4 60 G ACELP 30 22,93 25,

251 14 WebRTC a nové směry v IP telefonii 14 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 Podpora WebRTC v Asterisku 242

252 14 WebRTC a nové směry v IP telefonii Asterisk podporuje WebRTC od verze 11, viz. obr. 14.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 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. 243