Voice over IP - přehled protokolů a praktické zkušenosti

Voice over IP - přehled protokolů a praktické zkušenosti Vladimír Toncar, Jakub Zeman ([email protected])

Kerio Technologies ČR, s.r.o

1 Úvod Tento článek si klade za cíl poskytnout základní přehled o struktuře, filozofii návrhu a fungování VoIP protokolů H.323 a SIP. Je zmíněna historie těchto protokolů a čtenář je také seznámen s jejich open-source implementacemi. V poslední části příspěvku jsou nastíněny některé problémy, se kterými se lze setkat při implementaci VoIP protokolů v praxi.

2 Přehled protokolu H.323 Standard H.323, nesoucí název “Packet-based multimedia communications systems” (viz [1]) je Voice-over IP protokol definovaný Mezinárodní telekomunikační unií (ITU). ITU existuje již od roku 1890 a organizačně spadá pod Organizaci spojených národů. První verze H.323 byla uveřejněna v roce 1996, poslední – čtvrtá – verze byla přijata 17. listopadu 2000. H.323 je “zastřešující” standard, kterému jsou podřazeny následující protokoly: • H.225.0 – hovorová signalizace • Q.931 – protokol vypůjčený z L3 vrstvy ISDN, v H.323 se používá s modifikacemi pro signalizaci během hovoru (jsou v něm zapouzdřeny zprávy protokolu H.225.0) • H.245 – protokol pro vyjednání parametrů multimediálních kanálů • H.235 – bezpečnostní a ověřovací mechanismy • RTP – protokol IETF (viz [9]) pro přenos multimediálních dat v reálném čase • H.450.x – doplňkové služby (např. Call transfer, diversion, hold) • atd. Většina těchto protokolů používá definiční jazyk ASN.1 a zprávy se pro přenos kódují metodou ASN.1 PER (Packed Encoding Rules). Výjimkou je protokol Q.931, který byl definován dříve, než ITU začalo používat ASN.1, a používá vlastní způsob binárního kódování. Druhou výjimkou je protokol RTP, který pochází od IETF.

2.1 Entity v H.323 síti a terminologie Protokol H.323 rozlišuje tyto druhy entit: • Terminál – obvykle HW nebo SW telefon, za speciální případ terminálu lze považovat i např. systém hlasové pošty 1

• Brána (Gateway) – zařízení, které umožňuje obousměrnou komunikaci se zařízeními v jiné komunikační síti (např. ISDN, analogová tlf. síť, jiná H.323 síť). Brána formálně sestává z “Media Gateway Controller” (MGC, obsluha hovorové signalizace) a “Media Gateway” (MG, směrování audio/video proudů). MGC a MG tvoří obvykle jedno fyzické zařízení, v opačném případě se hovoří o tzv. dekomponované bráně. • Konferenční jednotka (MCU) – opět se formálně dělí na Multipoint Controller (MC, obsluha hovorové signalizace během konference) a Multipoint Processor (MP, obsluha multimediálních kanálů, mixování audia, atd.) • Gatekeeper – volitelná entita, která poskytuje služby překladu adres a řízení provozu v H.323 síti. Pro terminály, brány a konferenční jednotky se souhrně používá termín “koncová zařízení” (“endpoint”). Gatekeeper je centrálním řídícím prvkem H.323 sítě. Pokud se nějaké koncové zařízení zaregistruje na gatekeeperu, jsou pro něj veškeré pokyny od gatekeeperu závazné (například povel k ukončení hovoru). Množina zařízení spravovaná jedním gatekeeperem se označuje termínem “zóna”.

2.2 Použití součástí H.323 při komunikaci Jednotlivé součásti H.323 se používají takto: • Pro komunikaci endpoint-gatekeeper a gatekeeper-gatekeeper se používá podmnožina protokolu H.225.0 označovaná jako H.225.0-RAS (Registration, Admission, Status). Tato část protokolu obsahuje zprávy pro registraci koncového zařízení na gatekeeperu, žádost o povolení hovoru, ukončení hovoru, atd. Zprávy H.225.0-RAS se přenášejí protokolem UDP a gatekeeper standardně poslouchá na portu 1719/udp a také na 1718/udp (multicast). Multicastová adresa přidělená pro komunikaci s gatekeepery je 224.0.1.41. • Pro hovorovou signalizaci mezi koncovými zařízeními se na nejnižší úrovni používá protokol Q.931. Protože zprávy tohoto protokolu zdaleka neobsahují všechny položky, které jsou pro VoIP signalizaci zapotřebí, postupuje se tak, že ty údaje, které lze namapovat na položky zpráv Q.931, se do zpráv vyplní přímo (např. číslo volajícího a volaného) a kompletní údaje se umístí do zprávy protokolu H.225.0, která se binárně zakóduje (ASN.1 PER). Takto získané pole bajtů se přenese v položce User-User Information Element zprávy protokolu Q.931. Metoda binárního zapouzdřování zpráv je v H.323 (v některých případech bohužel) poměrně populární. Zprávy protokolu Q.931 se přenášejí protokolem TCP a standardní port, na kterém terminály očekávají příchozí spojení, je 1720. • Parametry multimediálních kanálů (audio/video) se vyjednávají protokolem H.245, kterým se dohodnou kodeky, IP adresy a čísla portů pro přenos zvuku, popř. videa protokolem RTP. Použití H.245 bývá někdy protokolu H.323 vyčítáno, protože H.245 je poměrně obsáhlý protokol a pro účely H.323 se využijí jen některé jím definované zprávy. Pro protokol H.245 se (v “základní” verzi signalizace) používá separátní TCP spojení, takže kompletní hovorová signalizace mezi dvěma terminály vyžaduje dva TCP kanály. Popišme si nyní typický průběh hovoru. Předpokládejme terminály označené EP1, EP2 a gatekeeper GK. Rovněž předpokládáme, že EP1 a EP2 jsou úspěšně zaregistrovány na GK. 2

1. EP1 pošle GK žádost o povolení hovoru (Admission Request, ARQ) s telefonním číslem terminálu EP2. Jak je zmíněno výše, při komunikaci mezi koncovými zařízeními a gatekeeperem se používá H.225.0-RAS a jeho zprávy jsou přenášeny protokolem UDP. 2. GK najde ve své registrační databázi údaje o EP2, posoudí, zda lze hovor povolit (dostupná šířka pásma, definovaná oprávnění, atd.) a pošle potřebné informace (např. IP adresa EP2) nazpět EP1 v povolující zprávě Admission Confirm (ACF). 3. Navázání hovorové signalizace a) Direct call model – EP1 se spojí přímo na signalizační adresu EP2. b) Gatekeeper-routed call model – EP1 naváže signalizační spojení s GK, ten naváže druhé spojení s EP2 (GK poslal v ACF svoji signalizační adresu místo adresy EP2). V tomto režimu má GK větší kontrolu nad průběhem hovoru (přesné měření délky hovoru, možnost upravovat některé zprávy, atd.) 4. EP2 se po navázání signalizačního spojení a obdržení první Q.931/H.225.0 zprávy (Setup) také dotáže GK na povolení hovoru (ARQ). Gatekeeper hovor povolí zprávou ACF. 5. Signalizace Q.931/H.225.0 začíná zprávou Setup (požadavek na hovor), protistrana obvykle odpoví zprávou Call Proceeding (požadavek se zpracovává), následuje zpráva Alerting (protistrana vyzvání). Hovor je přijat zprávou Connect, odmítnutí nebo ukončení se provede zprávou ReleaseComplete. 6. Některá ze zpráv protokolu Q.931/H.225.0 obsahuje adresu a port pro otevření TCP spojení pro přenos zpráv H.245 (jak jsme zmínili, v základním režimu signalizace používá H.245 separátní TCP kanál). Používá-li se gatekeeper-routed call model, může gatekeeper rozhodnout, zda umožní přímé H.245 spojení mezi EP1 a EP2 nebo zda jej bude také směrovat přes sebe. 7. EP1 a EP2 si protokolem H.245 dohodnou parametry pro přenos zvuku, popřípadě videa (kodeky, IP adresy, UDP porty). 8. Zvuk nebo video se posílají přímo mezi EP1 a EP2 protokolem RTP [9]. 9. Na konci hovoru se zastaví vysílání zvuku/videa, ukončí se signalizační spojení a poté obě strany ohlásí konec hovoru gatekeeperu zprávou Disengage Request (DRQ).

2.3 Metody optimalizace hovorové signalizace Protože způsob hovorové signalizace navržený v H.323 ver. 1 měl několik nedostatků, přistoupilo se v dalších verzích k několika optimalizačním krokům, které lze stručně shrnout takto: 1. Snížení počtu TCP spojení – aby se nemuselo otevírat druhé spojení pro H.245, je možné použít “tunelované” H.245. Zprávy se zakódují do binárního tvaru (ASN.1 PER) a v binárním tvaru se přiloží do té zprávy Q.931/H.225.0, která je právě k dispozici – není-li žádná, využije se zpráva Facility. Je to už druhá úroveň binárního vnoření, protože zakódovanou zprávu protokolu H.245 vložíme do zprávy protokolu H.225.0 a tu po zakódování vložíme do zprávy protokolu Q.931. 2. Rychlejší vyjednání parametrů audia/videa – standardní výměna zpráv protokolem H.245 potřebuje obvykle 3 “round-tripy”, než dojde k vyjednání potřebných parametrů (hlasování master/slave, výměna informací o schopnostech terminálů, otevření logických kanálů). 3

Zavedla se proto procedura “Fast Connect” (někdy též “Fast Start”), která spočívá v tom, že endpoint připraví několik variant zpráv H.245 request openLogicalChannel, podle toho, kolik kodeků podporuje. Tyto varianty binárně zakóduje a jako pole bajtových řetězců přiloží do zprávy Q.931/H.225.0 (např. Setup). Protistrana si některou z variant vybere a pošle ji zpět spolu se svojí nabídkou možností. Tímto způsobem je o kodecích, IP aresách a portech rozhodnuto již v okamžiku přijetí hovoru. Zbytek výměny H.245 zpráv pak proběhne standardním způsobem, buď v separátním TCP kanále nebo metodou tunelování, Fast Connect a tunelované H.245 mohou být použity nezávisle na sobě. 3. H.323 verze 4 přidala ještě jednu zrychlovací úpravu, tzv. “Parallel H.245” - ta spočívá v binárním zapouzdření zprávy H.245 request terminalCapabilitySet do zprávy Setup, opět nezávisle na jiných optimalizačních metodách. Volaný endpoint je tak seznámen se schopnostmi volající strany současně se žádostí o navázání hovoru. 4. Early media start – RTP kanály se rozběhnou ihned, jakmile jsou jejich parametry vyjednány, nečeká se na přijetí hovoru – v okamžiku přijetí se pouze přepne na skutečný zdroj zvuku. Skutečný přínos této metody pro uživatele je vhodné otestovat v konkrétních podmínkách, neboť je závislý na konfiguraci sítě, počtu směrovačů nebo firewallů v cestě, atd. Metoda nemusí být vhodná pro poskytovatele PC-to-phone služeb, protože hovor zabírá část přenosového pásma ještě před tím, než je spojen a tudíž tarifikován.

2.4 Open-source implementace – projekt OpenH323 Známou open-source implementací protokolu H.323 je knihovna OpenH323 [5]. Knihovna je distribuována pod Mozilla Public License, kvůli její “přátelskosti” ke komerčnímu využítí. Knihovna je dílem malé australské firmy Equivalence a vývoj začal už v roce 1998. Projekt OpenH323 je sponzorován firmou Quicknet, která aplikace založené na OpenH323 nabízí se svými kartami PhoneJack a LineJack a používá OpenH323 i pro provoz své dceřinné firmy, PC-to-phone operátora MicroTelco. Ve světě pracuje s OpenH323 řada producentů software, včetně velkých nadnárodních firem. Knihovna je použita také v některých VoIP produktech firmy Kerio Technologies. Z programátorského hlediska má projekt OpenH323 dvě části. Spodní vrstvu tvoří multiplatformní C++ knihovna PWLib, která poskytuje třídy pro práci s procesy, vlákny, sockety, atd. Součástí knihovny je také parser ASN.1 a datové struktury potřebné pro práci s ASN.1. Knihovna byla naportována na operační systémy Linux, Windows, Solaris, OpenBSD, MacOS X a také některé “embedded” platformy. Nad knihovnou PWLib je postaven samotný kód OpenH323, který je již plně platformně nezávislý. Část kódu je generována překladačem ASN.1 – jedná se o C++ třídy představující jednotlivé zprávy H.225.0, H.245 a dalších součástí H.323. Programátor vytvářející aplikaci založenou na OpenH323 postupuje tak, že ze tříd definovaných v knihovně (např. třída H323EndPoint) oddědí nové třídy a v nich implementuje virtuální metody pro obsluhu některých událostí (např. nový příchozí hovor, hovor spojen, hovor skončil, atd.). Zájemce o podrobnější informace o programování s OpenH323 můžeme odkázat na [5] a [6].

4

3 Stručný přehled protokolu SIP SIP (Session Initiation Protocol) je signalizační protokol navržený organizací Internet Engineering Task Force. SIP obecně slouží pro navázání relace mezi dvěma či více účastníky, v praxi se zatím využívá pro navazování telefonních hovorů a videokonferencí. SIP se do širšího povědomí dostal v roce 1999 díky uveřejnění RFC 2543 [7], jeho prapočátky lze však podle [11] vystopovat až do roku 1995 v pracovní skupině IETF “mmusic”. Dalším mezníkem pro rozvoj SIPu byl rok 2001, kdy se konal významný test interoperability, kterého se účastnilo 58 firem a vývojových týmů. Na konci roku 2002 SIP dosáhl stavu “proposed standard”. SIP je textový protokol, který vychází z protokolu HTTP. Používají se dva druhy zpráv: požadavky a odpovědi. SIPová zpráva se skládá z hlavičky a těla, přičemž tělo zprávy může být prázdné. Obecná struktura zpráv je následující: • Požadavek: <řádek požadavku> CRLF

• Odpověď: <stavový řádek> CRLF

RFC 2543 definovalo 6 základních typů požadavků, později byly přidány ještě další, pro účely přehledu však postačí zmínit jen původní šestici: • INVITE – žádost o vytvoření relace • ACK – potvrzuje vytvoření relace (použití např. po předchozím INVITE) • BYE – ukončuje relaci • CANCEL – ruší předchozí INVITE • OPTIONS – dotaz na schopnosti protistrany • REGISTER – registrace adresy na SIP registraru – vytvoří vazbu mezi trvalou (SIPovou) adresou a aktuálním umístěním (tj. IP adresou). SIP pracuje s adresami ve tvaru URL, např. “sip:[email protected]”. Stavový řádek odpovědí používá formát známý z HTTP, tj. “XYZ ”. Kódy začínající 1 mají informační funkci (např. 180 Ringing), kódy začínající 2 označují úspěch (např. 200 Success), 3 označuje přesměrování (301 Moved Permanently), kódy začínající 4 označují chybu (401 Unauthorized), 5 označuje chybu serveru (500 Server Internal Error) a 6 globální chybu (600 Busy Everywhere). Uveďme si příklad SIPové zprávy, jedná se konkrétně o zprávu INVITE, která žádá o vytvoření hovoru s telefonním číslem 0800 123456:

5

INVITE sip:[email protected] SIP/2.0 Accept: application/sdp Call-ID: [email protected] Contact: sip:[email protected]:5060 CSeq: 101 INVITE Expires: 1000 From: "Vladimir Toncar" <sip:[email protected]>;tag=ff177c16ff177c16 To: <sip:[email protected]> Via: SIP/2.0/UDP 192.168.40.143:5060 Content-Type: application/sdp Content-Length: 152 v=0 o=TinyPhone 19505 19505 IN IP4 192.168.40.143 s=SIP Call c=IN IP4 192.168.40.143 t=0 0 m=audio 48256 RTP/AVP 18 101 a=rtpmap:18 g729a/8000

V těle zprávy INVITE je nesena zpráva protokolu SDP (Session Description Protocol), která poskytuje údaje potřebné pro přenos zvuku na volající stanici. Stejně jako H.323 používá i SIP pro přenos audia a videa protokol RTP. Koncová zařízení (tj. především HW nebo SW telefony) se v terminologii SIP označují výrazem “User Agent”. Servery přítomné v SIPové síti lze rozdělit do následujících kategorií: • Proxy server – jeho úkolem je směrovat hovorovou signalizaci mezi koncovými zařízeními. Proxy servery mohou být také zřetězeny. • Redirect server – provádí přesměrování hovorů na jinou adresu, obvykle je implementován jako součást proxy serveru. • Registrar – registruje koncová zařízení a poskytuje služby převodu SIPové adresy na aktuální umístění (IP adresu). Nejznámější open-source implementací je VOCAL od skupiny Vovida.org. Tento projekt je sponzorován firmou Cisco a řada jeho vývojářů je u firmy Cisco zaměstnána. VOCAL obsahuje SIP proxy, SIP registrar a další součásti SIPové softwarové ústředny. Dále je k dispozici SIP stack, SIP user agent, SIP/H.323 translator, SIP/MGCP translator a velké množství dalších aplikací a knihoven pro použití ve VoIP řešení založeném na protokolu SIP. Ačkoli se jedná o nejpoužívanější open-source implementaci SIPu, bývá skupině Vovida.org někdy vyčítána horší interoperabilita s jinými implementacemi protokolu zapříčiněná specifickým výkladem některých částí standardu.

3.1 Porovnání protokolu SIP s H.323 Porovnání protokolů SIP a H.323 bývá někdy předmětem vášnivých debat. Často se stává, že to, co jedna strana vidí jako výhodu, je druhou stranou považováno za nevýhodu. Například textový formát protokolu SIP může být považován buď za výhodu (kvůli jednoduchosti) nebo za nevýhodu, protože ručně psané textové parsery mohou snáze podléhat útokům typu přetečení zásobníku (kód generovaný automaticky překladači ASN.1 se pokládá za robustnější). Autoři tohoto článku se domnívají, že ve věci SIP versus H.323 bude výhodnější nechat působit síly evoluce a že současné VoIP aplikace (s výjimkou infrastrukturních prvků 6

specifických pro jednotlivé protokoly) by měly podporovat protokoly oba. V případě zájmu lze seznam nejrůznějších srovnání protokolů SIP a H.323 nalézt na adrese [3].

4 Teorie a praxe – problémy při implementaci VoIP aplikací V této části článku stručně nastíníme některé problémy, se kterými se lze setkat při vývoji Voice-over-IP aplikací.

4.1 Nepřesnosti v implementaci Vývojář, který pracuje na VoIP aplikaci, se občas setká s tím, že produkty jiných výrobců, se kterými by aplikace měla spolupracovat, se v některých situacích odchylují od standardu a je nutné tyto odchylky nějak ošetřit či obejít. Dochází dokonce k tomu, že použití některých legálních prvků protokolu přivede druhé zařízení do chybového stavu (např. restart), ačkoli by mělo být zařízení schopno daný prvek ignorovat nebo odmítnout. V případě H.323 mají například některá zařízení problémy, pokud protistrana použije některou z metod pro optimalizaci hovorové signalizace (např. tunelování H.245). U protokolu SIP způsobuje někdy problém jeho “neustálenost” - někteří výrobci například přidávají do zpráv vlastní hlavičky a dochází tak k částečné nekompatibilitě.

4.2 Problém přesného časování VoIP aplikace provádějí přenos zvuku (popř. videa) v reálném čase. Pokud tyto aplikace provozujeme na počítačích s běžným operačním systémem (Linux, Windows), narážíme na problém, jak dosáhnout přesného časování. RTP pakety nesoucí zvuková data je totiž nutné odesílat v co nejpřesnějších časových intervalech (např. jednou za 30 milisekund). Každá VoIP aplikace, která přijímá proud RTP dat, je vybavena tzv. “jitter bufferem”, jehož úkolem je vyrovnávat odchylky intervalů mezi příchody paketů od ideální hodnoty. Jitter buffery jsou ovšem dimenzovány spíše na jednorázové odchylky (čím větší jitter buffer, tím větší zpoždění zvuku) a pokud by vysílající strana nebyla schopna dlouhodobě zajistit vysílaní RTP paketů s rozumnou přesností, bude tím značně zasažena kvalita přenosu zvuku nebo videa. Situace je poměrně jednoduchá, pokud již sám zdroj zvuku zajišťuje dostatečně přesné časování. To je případ softwarového telefonu, který čte audio data ze zvukové karty. Protože karta poskytuje data po blocích v reálném čase, postačí, aby je softwarový telefon zakódoval zvoleným kodekem a ihned odesílal. Hodiny zvukové karty jsou obvykle kvalitní a zajišťují potřebnou přesnost. Realizace přesného odesílání zvukových paketů se ovšem komplikuje v případě, že zvuková data nepocházejí ze zdroje, který pracuje v reálném čase – například se čtou ze souborů na disku nebo jsou výsledkem hlasové syntézy (např. systém hlasové pošty). Pro ilustraci předpokládejme, že čteme zvuková data ze souboru a chceme je odesílat v rámcích po 30 milisekundách. Protože IP telefonie (podobně jako ISDN) pracuje se vzorkovací frekvencí 8000 Hz, je 30 milisekund představováno 240 vzorky. Aplikace tedy musí každých 30 milisekund přečíst ze souboru 240 vzorků, zakódovat je zvoleným kodekem a pak ve správný okamžik odeslat. Čtení a zakódování rámce o 240 vzorcích obvykle 7

vyžaduje čas v jednotkách milisekund, uvažujme např. 2 milisekundy. Aby bylo možné odeslat RTP paket ve správný okamžik, muselo by tedy dané vlákno aplikace spát přesně po dobu 28 milisekund. V operačních systémech jako Windows a Linux (není-li jádro upraveno), se ovšem jednotlivá vlákna střídají v procesoru po 10 milisekundách a to znamená, že doba spánku vlákna se vždy zaokrouhluje nahoru na násobky zmíněných deseti milisekund. Tuto situaci je nezbytné řešit adaptivním algoritmem, který sleduje chyby časování v předchozích cyklech a upravuje dobu spánku. Pokud dojde k výraznější odchylce od přesného načasování, mělo by se jednat pouze o jednotlivou odchylku a průměrný interval mezi odesíláním paketů by se měl blížit ideální hodnotě (tzv. minimalizace jitteru). Problém přesného časování RTP paketů je rovněž diskutován v [6].

5 Závěr Pro značnou obsáhlost problematiky protokolů Voice-over-IP a jejich implementace zde bylo možné podat pouze stručný přehled tématu. Přesto však věříme, že článek splnil svůj úkol podat základní informaci a že ve čtenářích podnítí další zájem o VoIP. K dané problematice existuje celá řada zdrojů jak na Internetu (např. [3]), tak v odborné literatuře.

Literatura [1]

International Telecommunication Union: ITU-T Recommendation H.323 v4, Packet Based multimedia communications systems, November 2000.

[2]

International Telecommunication Union: ITU-T Recommendation H.225.0 v4, Call Signalling protocols and media stream packetization for packet-based multimedia communication systems, March 2001.

[3]

Packetizer, A Resource for packet-switched conversational protocols, http://www.packetizer.com/

[4]

Jones, P. E.: Current State of H.323 and Relation to Other VoIP Protocols, available at http://www.packetizer.com/

[5]

The OpenH323 Project, http://www.openh323.org/

[6]

Toncar, V.: Simple OpenH323 Tutorial, http://toncar.cz/openh323/tut/

[7]

Handley, M. et al: SIP: Session Initiation Protocol, IETF RFC 2543, http://www.ietf.org/rfc/rfc2543.txt

[8]

Rosenberg, J. et al: SIP: Session Initiation Protocol, IETF RFC 3261, http://www.ietf.org/rfc/rfc3261.txt

[9]

Schulzrinne, H. et al: RTP: A Transport Protocol for Real-Time Applications, IETF RFC 1889, http://www.ietf.org/rfc/rfc1889.txt

[10]

Vovida.org, http://www.vovida.org/

[11]

Sisalem, D., Kuthan, J.: Understanding SIP. Available at: http://www.fokus.gmd.de/mobis/siptutorial/

8