Aktuální problémy řízení kvality služeb v IP telefonii

Autor: J. Hlaváček, R. Bešťák <hlavaj1(at)feld.cvut.cz?cc=bestarob(at)fel.cvut.cz>, Pracoviště: České vysoké učení technické v Praze, FEL, Téma: QoS, Vydáno dne: 21. 01. 2010

Quality of Service Management in The Voice over IP Systems. Článek stručně popisuje problémy způsobené použitím protokolu IP v IP telefonii. Následně rozebírá možnosti řízení kvality služeb prostřednictvím protokolů H.323 a SIP.


Quality of Service Management in The Voice over IP Systems

This article describes briefly issues caused by the use of the IP protocol in the Voice over IP systems. Furthermore, it discusses the quality of service management in VoIP systems. Resource reservation capabilities defined by H.323 are compared with those defined by SIP and its extensions.

Keywords: QoS, SIP and H.323 Resource Management


Využití protokolu IP (Internet protocol) [1] v telefonii přineslo kromě mnoha výhod i několik nových problémů. Jedním z nich je negarantovaný způsob přenosu paketů v IP sítích. Použitá metoda přenosu je nazývána „maximální snaha“ (z anglického Best effort). Tato metoda má za cíl maximální využití jednotlivých spojů, ale jejím následkem mohou být ztráty paketů na přetížených spojích. Pokud ztráty paketů nejsou některou aplikací tolerovány, musí být řešeny protokoly vyšších vrstev. Pro úplnost dodejme, že protokol IP je protokolem síťové vrstvy modelu OSI (Open Systems Interconnection) [2].

Požadavky na přenos paketů v IP telefonii

V telefonii s přepojováním paketů rozlišujeme dva typy paketů – pakety signalizace a pakety obsahující uživatelská data, nejčastěji hlasové vzorky. Pro přenos signalizace jsou v IP telefonii používány zejména dva protokoly: H.323 [3] a SIP [4]. Protokol H.323 byl navržen Mezinárodní telekomunikační unií (International Telecommunication Union – ITU) a je proto velmi robustní a zaměřený čistě na IP telefonii. Protokol SIP (Session Initiation Protocol) je popsán v doporučení IETF RFC 3261 (Internet Engineering Task Force Request For Comments) [4]. Protokol SIP je zaměřen na sestavování multimediálních relací, telefonní hovor je považován za typ takové relace.

Protokol H.323 používá pro přenos signalizace protokol transportní vrstvy modelu OSI nazvaný Transmission Control Protocol (TCP) [5], který v případě ztrát paketů zaručuje doručení zprávy opakovaným přenosem. Protokol SIP umožňuje použití jednoho z následujících dvou protokolů na úrovni transportní vrstvy: UDP (User Datagram Protocol) [6], nebo TCP. Protokol UDP narozdíl od TCP nezaručuje doručení dat, SIP proto definuje opakované odeslání zpráv v případě neobdržení odpovědi. Ztráty se tedy v obou případech projeví vyšším zpožděním přenosu, ale s výjimkou poruchy na spoji je doručení zprávy zaručeno. Pro úplnost dodejme, že SIP umožňuje také použití protokolu Transport Layer Security Protocol (TLS) [7], který zajišťuje zabezpečení signalizačních dat.

Skutečný problém nastává pro pakety hlasu. Pakety hlasu jsou přenášeny pomocí protokolu UDP (User Datagram Protocol) [6] na úrovni transportní vrstvy modelu OSI a pomocí protokolu RTP (Real-Time Transport Protocol) [8] na úrovni vrstvy relační. Protokol UDP zajišťuje pouze možnost adresovat konkrétní aplikaci v rámci cílové IP adresy a integritu přenášených dat pomocí kontrolního součtu. Každý hlasový paket tedy může být ztracen, nebo doručen vícekrát. Jejich pořadí může být zaměněno. Protokol RTP zajišťuje služby specifické pro přenos hlasových nebo video vzorků, přenáší zejména informace o typu vzorků, časové údaje, údaje o pořadí a vzorky samotné. Případné ztráty paketů hlasu však nejsou žádným z těchto protokolů řešeny. Aby byla dodržena vysoká kvalita hovoru, musí být pakety doručeny beze ztrát, s nízkým zpožděním (angl. low latency) a s nízkou variabilitou zpoždění (angl. low jitter). Požadavky na zpoždění a pravidelnost vylučují možnost opakovaného přenosu paketů hlasu. Hierarchie hlavních protokolů používaných v IP telefonii je zobrazena na obrázku 1.

QoS_IP_01

Obr. 1: Hierarchie protokolů IP telefonie

Shrneme-li výše uvedené, můžeme říci, že využití protokolu IP není problematické pro signalizaci, může však negativně ovlivnit přenos datových paketů. Kvalita přenosu hlasu (či videa) je ovlivněna následujícími faktory:

  • ztráty paketů,
  • zpoždění paketů,
  • variabilita zpoždění paketů,
  • změna pořadí paketů.

Jmenované faktory mohou být ovlivněny řízením přístupu k přenosovému médiu.

Řízení kvality služeb

Problematika kvality je studována a pro její řízení v sítích IP se používá termín kvalita služby (z anglického Quality of Service, zkracovaného QoS). Řízení QoS je nutnou podmínkou pro možnost garance úrovně služeb na linkách s omezenou šířkou pásma, jako jsou například satelitní spojení nebo velmi vytížené spoje. Vzhledem k rozvoji IP telefonie je i přes rychlý nárůst kapacit přenosových spojů řízení kvality služeb stále v popředí zájmu operátorů telekomunikačních sítí. Tento zájem je umocněn stále častějším využitím spojů s omezenou kapacitou, například rádiových IP spojů.

Vraťme se nyní k problému přenosu metodou „maximální snahy“. Tento je ilustrován na obrázku 2. Obrázek ukazuje tři páry IP telefonů, které spolu komunikují prostřednictví směrovačů (routerů) R1 a R2. Všechny spoje na obrázku mají kapacitu 3 pakety za jednotku času. Pro zjednodušení uvažujme routery bez vyrovnávací paměti. Na principu to nic nezmění, protože vyrovnávací paměť umožňuje řešit pouze nárazové překročení kapacity spojů. Každý z telefonů 1-3 vytváří datový tok 3 pakety za jednotku času. R1 musí při směrování paketů k R2 určité pakety zahodit, protože spoj mezi R1 a R2 nemá dostatečnou kapacitu pro přenesení všech paketů. Bez řízení využití spojů budou zahozeny náhodné pakety a všechny hovory budou trpět snížením kvality. Přepínače IP totiž na rozdíl od (například) ústředen ISDN (Integrated Services Digital Network) neuvažují jednotlivé hovory, ale pracují na úrovni paketů. Řízení kvality služeb má za cíl zjednodušeně řečeno zajistit maximální kvalitu pro maximální počet hovorů. Hovory, pro které není dostatek přenosové kapacity, nesmí být umožněny. Je tedy třeba zajistit koordinaci sestavování hovorů s řízením QoS. Již výše bylo uvedeno, že pro přenos signalizace jsou v IP telefonii nejběžnější dva protokoly: H.323 a SIP. Následující odstavce analyzují přístup těchto protokolů k řízení QoS.

QoS_IP_02

Obr. 2: Princip metody maximální snahy (Best Effort)

Protokol H.323

Norma H.323 verze 6 z června 2006 doporučuje použití rezervace prostředků pro audio a video pakety. Dokument nedefinuje detaily mechanismů zajišťujících takovou rezervaci, nicméně obecné zásady a způsob koordinace mezi jednotlivými H.323 zařízeními je normou popsán.

Každý H.323 terminál v první fázi sestavení hovoru indikuje ústředně H.323 (termín ústředna H.323 je použit pro anglický termín gatekeeper), zda je schopen rezervace prostředků. Ústředna H.323 rozhoduje o provedení rezervace, tato může být provedena koncovým terminálem, samotnou ústřednou H.323, nebo vůbec. Rezervace nebude prováděna pokud ústředna H.323 považuje přenos metodou „maximální snahy“ za dostačující pro daný hovor. Norma dále doporučuje, aby rezervace byla provedena samotným terminálem, protože tím je zajištěna rezervace ve všech síťových prvcích, které zpracovávají hlasové pakety (pakety nejsou nutně směrovány přes ústřednu H.323).

Protokol H.323 využívá dvě spojení TCP pro přenos signalizace, jedno spojení pro přenos signalizace hovoru a jedno spojení pro dohodu parametrů přenosu hlasu a/nebo videa. Toto oddělení usnadňuje realizaci rezervace. Pro rezervaci prostředků je totiž nutné vyřešit dvě podmínky: znát požadavky na šířku pásma potřebnou pro uskutečnění hovoru a zajistit rezervaci prostředků před vyzváněním na straně volaného. Je zřejmé, že bez znalosti šířky pásma není možné uskutečnit rezervaci. V IP telefonii je však použité kódování a tím i potřebná šířka pásma zpravidla výsledkem dohody mezi dvěma koncovými terminály. Tato dohoda je uskutečněna během sestavování hovoru, zpravidla je dokončena až v okamžiku vyzvednutí (standardní chování protokolu SIP) nebo dokonce až po vyzvednutí (standardní chování protokolu H.323). Chování obou protokolů je tedy nutné modifikovat. Pokud by byla rezervace prováděna až během vyzvánění volaného nebo až po jeho vyzvednutí, mohlo by vyzvednutí být následováno okamžitým ukončením hovoru z důvodu nedostatku prostředků.

Norma H.323 bere v úvahu výše jmenované podmínky. Sekvence sestavení hovoru zahrnuje rezervaci přenosových prostředků a její synchronizaci se sestavováním hovoru. Aplikací této sekvence je zaručeno řízení QoS pro daný hovor. Sekvence je ve zjednodušené formě zobrazena na obrázku 3.

QoS_IP_03

Obr. 3: Sekvence sestavení hovoru s rezervací prostředků (H.323)

Pozdržením vyzvánění do okamžiku dokončení dohody o požadavcích na přenosové prostředky a uskutečnění rezervace prostředků nemůže dojít k situaci, kdy volaný vyzvedne, ale hovor je přerušen z důvodu nedostatku přenosových prostředků.

Uvedená sekvence je v normě H.323 popsána s použitím protokolu RSVP (Ressource Reservation Protocol) [9]. Tento protokol je však použit pouze pro ilustraci popsaných principů a norma nechává volnou ruku při výběru protokolu pro řízení QoS. Řízení QoS je tímto způsobem řešeno od verze 2 protokolu H.323 z roku 1998.

Protokol SIP

Na rozdíl od normy H.323 protokol SIP neposkytuje žádnou možnost rezervace prostředků. Autoři doporučení RFC 3261 definující protokol SIP verze 2.0 uvádějí, že spojení uskutečněné pomocí protokolu SIP mohou procházet různými sítěmi a z tohoto důvodu nemůže protokol SIP rezervaci zajišťovat. Komunita pracující na rozvoji protokolu SIP si však uvědomuje potřebu řízení QoS a bylo vypracováno několik doporučení zabývajících se touto problematikou.

Nejobecnější způsob podobný způsobu použitému protokolem H.323 je popsán v doporučení RFC 3312 - Integration of Resource Management and Session Initiation Protocol [10]. Protože ale protokol SIP disponuje pouze jedním signalizačním kanálem, sekvence sestavení hovoru musí být rozšířena. Protokol SIP používá pro stanovení parametrů přenosu uživatelských dat (nejčastěji vzorků hlasu) protokol nazvaný Session Description Protocol (SDP) [11]. Data protokolu SDP jsou vkládána do zpráv protokolu SIP. Dokument RFC 3312 rozšiřuje protokol SDP o parametry sloužící k řízení rezervace prostředků a dále předefinovává sekvenci sestavení spojení protokolu SIP. Aby bylo možné využít definovaného mechanismu, je třeba, aby jednotlivé prvky SIP implementovaly kromě již uvedeného rozšíření (RFC 3312) také rozšíření specifikované dokumenty RFC 3311 – The Session Initiation Protocol UPDATE Method [12] a RFC 3262 - Reliability of Provisional Responses in Session Initiation Protocol [13]. Tato dvě rozšíření jsou nutná pro zajištění dohody parametrů přenosu hlasu/videa a pro synchronizaci rezervace se signalizací hovoru. Obrázek 4 porovnává sestavení hovoru bez rezervace prostředků a s jejich rezervací dle RFC 3312. Obrázek pro zjednodušení zobrazuje pouze koncové terminály. Zprávy SDP1 a SDP2 vyměněné mezi terminály slouží k dohodě o použitém kódování, IP adresách a portech pro výměnu uživatelských dat. SDP3 a SDP4 slouží k přenosu informace uskutečněné rezervací (v uvedeném příkladu úspěšné).

QoS_IP_04

Obr. 4: Porovnání protokolu SIP s jeho rozšířením pro rezervaci prostředků

Závěr

Protokol H.323 umožňuje provedení rezervace použitím parametrů existujících zpráv, je nutná pouze změna pořadí vysílaných zpráv. Pokud je použit protokol SIP, je nutné najít terminály, které implementují výše uvedená rozšíření protokolu SIP. Sekvence sestavení hovoru je oproti standardní sekvenci protokolu SIP značně komplikovanější. Z uvedeného je zřejmé, že protokol H.323 je na řízení QoS připraven lépe, než protokol SIP. I přes svou robustnost demonstrovanou i v tomto článku je protokol H.323 stále častěji nahrazován protokolem SIP. Interoperabilita protokolu SIP s ostatními telekomunikačními protokoly je komplikovaná, ale jeho pružnost, jednoduchost a snadná implementace jeho negativní vlastnosti vyvažují.

Oba uvedené mechanismy předpokládají, že rezervace bude prováděna samotnými terminály. Operátoři telekomunikačních sítí však z důvodu kontroly a snadnosti konfigurace terminálů preferují rezervaci prostřednictvím IP ústředny (gatekeeper H.323 nebo proxy SIP). Z popsaných sekvencí je také zřejmé, že mechanismy ještě nejsou plně optimalizovány. Řízení kvality služeb je stále předmětem vědecké práce.

Článek vznikl v rámci výzkumného záměru MSM6840770014.

Literatura

[1] Information Sciences Institute - Internet Protocol, Version 4 (IPv4) Specification [online]. c1981. Dostupné z: http://www.ietf.org/rfc/rfc791.txt.
[2] ITU-T X.200 - Information Technology - Open Systems Interconnection – Basic Reference Model (07/94)
[3] ITU-T H.323 - Audiovisual and Multimedia Systems - Packed Based Multimedia Communications Systems (06/06)
[4] Rosenberg J. – Schulzrinne H. et. al. - SIP: Session Intiation Protocol [online]. c2002. Dostupné z: http://www.ietf.org/rfc/rfc3261.txt.
[5] Information Sciences Institute - Transmission Control Protocol [online]. c1981. Dostupné z: http://www.ietf.org/rfc/rfc793.txt.
[6] Postel J. – User Datagram Protocol [online]. c1980. Dostupné z: http://www.ietf.org/rfc/rfc768.txt.
[7] Dierks T. – Rescorla E. – The Transport Layer Security Protocol Version 1.2 [online]. c2008. Dostupné z: http://www.ietf.org/rfc/rfc5246.txt.
[8] Schulzrinne H. et. al. - A Transport Protocol for Real-Time Applications [online]. c2003. Dostupné z: http://www.ietf.org/rfc/rfc3550.txt.
[9] Braden R. Ed. et. al. – Resource Reservation Protocol [online]. c1997. Dostupné z: http://www.ietf.org/rfc/rfc2205.txt.
[10] Camarillo G. et. al. - Integration of Resource Management and Session Initiation Protocol [online]. c2002. Dostupné z: http://www.ietf.org/rfc/rfc3312.txt.
[11] Hanley M. et. al. - Session Description Protocol [online]. c2006. Dostupné z: http://www.ietf.org/rfc/rfc4566.txt.
[12] Rosenberg J. - The Session Initiation Protocol UPDATE Method [online]. c2002. Dostupné z: http://www.ietf.org/rfc/rfc3311.txt.
[13] Rosenberg J. – Schulzrinne H. - Reliability of Provisional Responses in the Session Initiation Protocol [online]. c2002. Dostupné z: http://www.ietf.org/rfc/rfc3262.txt.