VoIP, Voice over IP

Zdaleka nejvíce se v současné době hovoří o možnostech přenosu hlasu po datových sítích na bázi protokolu IP z rodiny TCP/IP. Není to rozhodně proto, že by tyto sítě byly pro daný účel nejvhodnější (jak si řekneme záhy, je tomu právě naopak). Důvod je úplně jiný a je třeba jej hledat v univerzálnosti a široké dostupnosti tohoto typu datových sítí. Je to dáno zejména tím, že jde právě o tu technologii, na které je řešen přenos dat i v prostředí Internetu (ostatně, zkratka IP je od Internet Protocol, jde o hlavní přenosový protokol používaný v Internetu na úrovni síťové vrstvy). Navíc je pro realizaci IP přenosů k dispozici opravdu široká paleta produktů od nejrůznějších výrobců, které si navzájem dobře rozumí.

Jak dobře ale vychází protokol IP vstříc potřebám přenosu hlasu? Jak těžké či naopak lehké je realizovat služby VOIP, neboli "Voice over IP"? Odpověď je taková, že protokol IP vychází těmto potřebám vstříc jen velmi málo. Pokud bychom si protokol IP srovnávali například s ATM či Frame Relay, pak je fungování protokolu IP možné srovnat s jejich režimem UBR (Unspecified Bit Rate) u ATM, resp. Available/Unspecified Frame Rate (tam, kde Frame Relay nabízí výše zmiňované tři třídy služeb). Protokol IP totiž funguje způsobem, který bývá označován jako "best effort", neboli jako princip "maximální snahy, ale nezaručeného výsledku". Prakticky to znamená, že protokol IP nezaručuje přenášeným datům vůbec nic. Nezaručuje dokonce ani to, že vůbec budou doručena. Protokol IP totiž funguje tzv. nespolehlivě a pokud zjistí nějaké porušení přenášených dat, má právo je zahodit a nepodnikat žádná opatření pro jejich nápravu. Samotný princip "maximální snahy, ale nezaručeného výsledku" pak znamená také to, že když požadavky jednotlivých přenosů překročí možnosti IP sítě, jsou všechny požadavky rovnoměrně kráceny - všem je měřeno stejně.

Pro potřeby přenosu hlasu je samotná nespolehlivost přenosu spíše předností, protože kdyby protokol IP fungoval spolehlivě, musel by si v případě přijetí poškozeného paketu vyžádat jeho opakované zaslání, a to by mělo fatální důsledky jak pro celkové přenosové zpoždění, tak hlavně pro pravidelnost doručování jednotlivých částí hlasových dat (ostatně, technologie ATM i Frame Relay také fungují jako nespolehlivé). Naopak příležitostné výpadky paketů (do četnosti 5 procent, viz výše, dokáží kodeky překlenout).

Největším problémem přenosu hlasu po IP sítích je však naprostá absence jakýchkoli garancí ohledně kvality služeb, zejména celkového zpoždění a pravidelnosti doručování. Jak ale lze tyto vlastnosti IP protokolu kompenzovat či ještě lépe eliminovat? Odpověď je taková, jakou jsme si již naznačili výše - jednou možností je "přístup hrubou silou", neboli navyšování celkové dostupné přenosové kapacity, a druhou možností je zavádění mechanismů podporující různou kvalitu služeb (QoS) pro různé druhy přenosů). Důležité je, že v prostředí IP sítí jsou fakticky využívány obě tyto možnosti.

Pokud jde o zavádění mechanismů na podporu QoS, zde existuje poměrně široká škála navržených řešení vycházejících vstříc tzv. přenosům v reálném čase (jak se v prostředí IP sítí označují přenosy citlivé na přenosové zpoždění a pravidelnost doručování). Tato škála zahrnuje:

• Přenosový protokol RTP (Real Time Protocol), určený pro přenos v reálném čase. Je zařazován do transportní vrstvy, ale funguje jako nadstavba nad protokolem UDP, jehož služby sám využívá (tj. RTP pakety jsou vkládány do UDP datagramů, které jsou dále vkládány do IP paketů). Vedle protokolu RTP pak existuje řídící protokol RTCP (Real Time Control Protocol) pro potřeby řízení přenosů v reálném čase.
• Rezervační protokol RSVP (ReSerVation Protocol) fungující na úrovni vrstvy síťové. Jeho úkolem je vyhradit určitou přenosovou a přepojovací kapacitu pro potřeby přenosů probíhajících v reálném čase (a tím ji vyjmout ze zdrojů, které zajišťují zpracování všech ostatních dat na principu "best effort").
• QoS architektury IntServ (Integrated Services) a Diffserv (Differentiated Services), fungující na principu prioritizace . Rozdíl mezi nimi je v tom, že IntServ se snaží poskytnout určitou konkrétní úroveň priority (resp. kvality služeb) individuálně každému jednotlivému proudu dat, zatímco DiffServ zavádí několik tříd služeb a každý datový tok si mezi nimi vybírá.

Problém je ale stále v tom, že právě uvedená řešení nejsou ještě zdaleka rozšířena všude, ve všech IP sítích. Nejsou dosud podporována ani ve všech nových produktech pro IP sítě od různých výrobců, ale hlavně nejsou implementována ve všech již existujících IP sítí. S jejich systematickým nasazením se lze nejčastěji setkat v uzavřených a privátních IP sítích.