Internetová telefonie (VoIP) a protokol SIP

Zkratkou VoIP (Voice over Internet Protocol) je v současnosti označovánmechanismus přenosu hlasu prostřednictvím datových sítí založených na protokolu IP (Internet Protocol). Pojmy internetová telefonie nebo IP telefonie jsou pak dalšími označeními pro VoIP. Rita Pužmanová ve svém článku "Hlasové služby v IP sítích" upřesňuje tyto termíny. Cituji: "IP telefonie (kam VoIP patří) obecně označuje poskytování telefonních služeb přes IP síť, zatímco internetová telefonie má užší význam, kde se přenos hlasu realizuje přímo přes veřejný internet."

Hlavní motivací pro přenos hlasu v datových sítích byla kromě zvídavosti také zjevná snaha sloučit dvě původně odlišné telekomunikační sítě (telefonní a datovou) do jedné síťové infrastruktury. Z důvodu efektivnějšího využití přenosových cest byla za společné prostředí zvolena datová (počítačová) síť.

V následujícím textu se tedy budeme dále zabývat možnostmi přenosu hlasu v datových (počítačových) sítích. Nejprve si ukážeme, jak lze převést originální spojitý (analogový) hlasový signál do jeho nové digitální podoby. Následně si vysvětlíme protokolový model používaný pro obecný přenos dat zejména v počítačových sítích (TCP/IP model). V poslední části se budemepodrobněji zabývat řídícími protokoly (tj. signalizací) a transportními protokoly ve VoIP. Podrobněji se zaměříme na nejpoužívanější protokol SIP (Session Initiation Protocol). Na závěr zmíníme překážky a problémy, kterým přenos hlasu v datových sítích v současnosti čelí a jaká jsou jejich možná řešení.

Lidský vokální trakt vytváří svým funkčním uspořádáním zvukové vlny ve formě lidského hlasu. Zvukové vlny jsou následně pomocí mikrofonu převedeny na prvotní elektrický signál. Ten je z hlediska fyzikální formy analogový, tj. spojitý v čase i amplitudě (tzn. nabývající nekonečné množiny hodnot). Aby bylo možné přenášet prvotní elektrický signál prostřednictvím digitální sítě, je potřeba jej zpracovat a převést do digitální podoby. V prvním kroku odebíráme v pravidelných intervalech tzv. vzorky signálu a provádíme tak operaci vzorkování (anglicky "Sampling"). Touto operací transformujeme prvotní elektrický signá na signál nespojitý v čase. Hodnoty amplitudy signálu jsou však stále spojité a mohou tak nabývat libovolných hodnot. Následně rozdělíme množinu dosažených hodnot amplitud na omezený, resp. přesně definovaný počet intervalů. Každému intervalu přiřadíme jednu konkrétní hodnotu, tzv. kvantizační úroveň. Všem hodnotám amplitudy, které spadají do

určitého intervalu, je přiřazena právě tato jednoznačná kvantizační úroveň. Tento proces se z hlediska digitalizace hlasu označuje jako kvantování. Nyní máme k dispozici diskrétní signál, a to jak v čase, tak i v amplitudě. V posledním kroku jsou jednotlivé kvantizační úrovně vyjádřeny pomocí unikátního kódu. Proces digitalizace hovorového signálu tak ukončuje operace kódování. Nyní máme k dispozici digitální signál. Pro vlastní kódování se nejčastěji používá posloupnost dvojkových číslic. Čím delší je tato posloupnost, tím vyššího dosahujeme rozlišení (anglicky "Bit Resolution"), a tím je vyšší i kvalita výstupního digitálního signálu.

Komprese digitálního audio signálu, zjednodušeně také někdy označovaná pojmem kódování (z anglického "Speech Coding"), má především za úkol snížit počet bitů přenášeného hlasového signálu, tzn. odstranit nadbytečnou (redundantní) informační zátěž. Procesem komprese tedy ve výsledku dosáhneme datového toku vyžadujícího mnohdy výrazně nižší přenosovou režii než původní nekomprimovaný digitální audio signál. Tohoto lze následně využít pro případy, kdy máme k dispozici pomalé připojení resp. lze tímto způsobem např. efektivněji využít dostupné přenosové cesty současným přenosem více datových toků najednou. Komprese a následná dekomprese je realizována tzv. kódovacími a dekódovacími algoritmy, zkráceně kodeky. Tyto algoritmy jsou implementovány v softwaru koncových zařízení nebo bran ve VoIP síti. Kodeky lze rozdělit do dvou kategorií. První kategorií jsou bezeztrátové kodeky. Běžně dosahují úspory přibližně poloviny informačního obsahu a zachovávají

veškerou informační hodnotu původního audio signálu. Příkladem mohou být kodeky Dolby TrueHD nebo Free Lossless Audio Codec. Ve VoIP se však mnohem častěji využívají ztrátové kodeky, které nabízí daleko větší úsporu. Kódovaný datový tok dosahuje až 5% objemu datového toku původního. Ztrátové kodeky především využívají nedokonalostí lidského sluchu, mezi které patří např.:

omezený frekvenční rozsah (přibližně 16 Hz až 16 kHz (teoreticky až 20 kHz))

snížená schopnost vnímání zvuku za přítomnosti jiného zvuku, tzv. maskování

omezená lokalizace nízkých a vysokých frekvencí (využití u vícekanálových zvuků)

Veškerá tato nadbytečná informační zátěž tak může být ze signálu odstraněna, aniž by uživatelé pocítili nějaké omezení. Na obrázku níže je uveden příklad maskování, kdy ucho vnímá dva zdroje zvuku podobné hlasitosti, jejichž spektra se překrývají. Ucho přestává tyto zvuky rozlišovat a dochází k maskování slabšího signálu signálem silnějším.

Mezi nejrozšířenější kodeky ve VoIP sítích patří kodeky definované mezinárodní telekomunikační unií v rámci doporučení řady G.7xx, dále pak kodeky specifikované ETSI a 3GPP (3rd Generation Partnership Project) – kodeky pro mobilní sítě, kodeky vyvíjené soukromými organizacemi – iLBC (internet Low Bitrate Codec) a kodeky s otevřeným kódem – SPEEX. Většina výše uvedených kodeků přenáší pouze základní hovorové pásmo (300 Hz

až 3 400 Hz). Některé nové tzv. širokopásmové kodeky již pracují se šířkou pásma 8 až 16 kHz a přenáší tak audio signál ve vyšší kvalitě než původní úzkopásmové kodeky. I přes vysokou kompresi digitalizovaného hovorového signálu nastává ve VoIP sítích značná neefektivita. Ta souvisí především s množstvím doplňkových záhlaví, která se přidávají na nejnižších vrstvách protokolového modelu. Tímto procesem tak dochází k výraznému navýšení požadované přenosové kapacity i na dvoj- až trojnásobek kapacity původního komprimovaného hovorového signálu (například hlas komprimovaný kodekem ITU-T G.723.1 s nominální přenosovou rychlostí 5,6 kbit/s potřebuje pro vlastní přenos kapacitu 18 kbit/s).

Kodek hojně využívaný v současných pevných i mobilních telekomunikačních. Kodek vzorkuje analogový signál s frekvencí 8 kHz a původních 13 bitů na vzorek je pomocí nelineární komprese (na americkém kontinentě a v Japonsku (μ- law), v Evropě a ostatních částech světa (A-law)) převedeno na 8 bitů sítích. Výsledný datový tok má nominální přenosovou rychlost 64 kbit/s a v případě VoIP sítí poskytuje vysokou kvalitu hovoru s hodnotou MOS přibližně 4,1. Také náročnost zpracování se pohybuje hluboko pod 1 MIPS (Milion Instructions Per

Tento kodek poskytuje jednu z nejlepších kompresí vůbec. Komprimuje intervaly hlasového signálu o délce 30 ms s vzorkovací frekvenci 8 kHz. Využívá dvou druhů kódování MP-MLQ (MultiPulse Maximum Likelihood Quantization) – datový tok 6,3 kbit/s (hodnota MOS je 3,9) a ACELP (Algebraic Code Excited Linear Prediction) – datový tok 5,3 kbit/s (hodnota MOS je 3,65). Výpočetní náročnost zpracování je v případě kodeku G.723.1 15 až 25 MIPS. Kódovací algoritmus G.723.1 je chráněn patenty. Pro jeho využívání tedy potřebuje

Kodek G.729 zpracovává úseky hovorového signálu o délce 10 ms vzorkované s frekvencí 8 kHz. Využitím algoritmu CS-ACELP (Conjugate Structure- ACELP) dosahuje výsledný datový tok rychlosti 8 kbit/s (případně 6,4 a 11,8 kbit/s) a hodnota MOS je rovna 3.92. Náročnost zpracování se pohybuje mezi 20 až 25 MIPS. Kodek je taktéž zatížen licenčními poplatky.

Tento kodek je upravenou verzí kodeku G.729 snižující nároky na výpočet algoritmu (cca 10 MIPS). Nižší náročnost se však projevuje v nižší kvalitě přeneseného hlasu (MOS 3.7). Kodek je možné opět využívat pouze po zaplacení licenčního poplatku.

GSM kodek pochází z mobilních sítí 2. generace a existuje hned několik jeho verzí. Prvním je GSM kodek FR (Full Rate) využívající algoritmu RTP-LPE (Realtime Transport Protocol – Loss Period Error). Dalším je kodek GSM HR (Half Rate) se sníženou přenosovou rychlostí na polovinu a algoritmem CELPVSELP

(Code Excited Linear Prediction-Vector Sum Excited Linear Prediction). Následuje asi nejpoužívanější kodek GS EFR (Enhanced Full Rate) s nejlepší kvalitou založený na algoritmu ACELP. V následující tabulce je přehled hodnot přenosových rychlostí a parametru MOS jednotlivých GSM kodeků (hodnoty parametru MOS jsou orientační):

Kodek iLBC byl vyvinut firmou Global IP Sound. Kóduje úseky hovorového signálu o délce 30 ms a výsledný datový tok je 13,33 kbit/s. Použitý algoritmus BI-LPC (Block Independent Linear Predictive Coding) umožňuje podle

aktuálních podmínek (ztráty, zpoždění v síti) měnit parametry (kvalitu, přenosovou rychlost) kódování.

V závislosti na kapacitě přenosového kanálu nabízí Speex kodek zpracování audio signálu ve třech šířkách pásma - 4, 8 a 16 kHz. Tomu odpovídá také proměný datový tok s rychlostmi od 2 do 44 kbit/s. Speex využívá algoritmu CELP spolu s mechanismy pro úsporu přenosové kapacity jako je detekce ticha (VAD).

Pro číselné vyjádření kvality zpracování hovorového signálu a hovorových vzorků přenesených použitím určitého typu kodeku se velmi často využívají stupnice MOS (Mean Opinion Score). Kvalitu kódování a následného přenosu hovorového signálu lze však stanovit a následně porovnat pouze na základě výsledků uskutečněných měření. V současné době existují dvě kategorie měření definovaných v rámci doporučení ITU (International Telecommunication Union):

o založena na statistickém ohodnocení jednotlivých zpracovaných a přenesených vzorků hovorového signálu pomocí dostatečně velké skupiny osob (dle doporučení ITU-T P.82) o výsledkem je parametr MOS-LQS (Mean Opinion Score – Listening

o realizována na základě matematických modelů (tzn. statisticky), které modelují lidský sluchový a vokální trakt

o dvě podkategorie - intrusivní měření (porovnání referenčního a degradovaného vzorku) a neintrusivní měření (založena na kontrole a sledování sítí)

o výsledkem je parametr MOS-LQO (Mean Opinion Score – Listening Quality Objective) udávající odhadovanou hodnotu kvality

Parametr MOS je standardizován v rámci doporučení mezinárodní telekomunikační unie ITU-T P.800. Využívá stupnici hodnocení od 1 (nejhorší kvalita) do 5 (nejvyšší kvalita). Výše zmíněné subjektivní i objektivní metody však neberou příliš v úvahu především vlivy zpoždění a nemohou být tedy uspokojivě použity pro stanovení

hovorové kvality mezi koncovými systémy. Komplexním nástrojem, který může být použit pro stanovení kvalit hovoru s efektivním zohledněním vlivu zpoždění, je tzv. E-model (z anglického „Ear = ucho“), vyvinutý expertní skupinou při ETSI (European Telecommunications Standards Institute) v letech 1993–96

E-model přiřazuje koeficient každému dílčímu faktoru, který má vliv na kvalitu přenosu hovoru. Výsledný R-faktor (anglicky Rating) je pak definován jako prostý součet těchto koeficientů a nabývá hodnot v rozsahu od 0 do 100. Zohledňuje vliv šumu, hlasitosti, kvantizačního zkreslení, způsobu kódování ozvěny a zpoždění a stanovuje se pro celý přenosový řetězec mezi akustickými rozhraními telefonní sítě. E-model je standardizován v rámci doporučení ITU-T G.107.

Výstupem kodeku je digitalizovaný hovorový signál v podobě obecného bitového toku. Ten je potřeba přenést v obecné datové síti od volajícího k volanému. Aby však bylo možné takto rozsáhlý úkol vyřešit, je nutné jej rozdělit na dílčí části, které jsou řešeny odděleně. K popisu jednotlivých částí se používá tzv. protokolový model. V případě sítí VoIP se používá již ověřený model TCP/IP (Transmission Control Protocol/Internet Protocol).

Model TCP/IP popisuje strukturu datové sítě, která je založena na principu paketového přenosu. Jméno modelu je odvozené od původně nejvýznamnějších protokolů TCP a IP. Nynější protokolový model obsahuje ještě množství dalších doplňkových protokolů. Protokol je jednoznačně definovaný soubor pravidel, dle kterých obecně probíhá vlastní výměna dat, resp. protokol tedy definuje pravidla řídící syntaxi, sémantiku a synchronizaci vzájemné komunikace. Na vlastním spojení v síti VoIP se podílí více protokolů, které jsou uspořádány do

vrstev v rámci protokolového modelu. Každý protokol pak obstarává určitou funkci, a tím poskytuje služby nejbližší nadřazené vrstvě a využívá služeb nejbližší podřízené vrstvy. V případě, že je stejný model uplatněn na obou stranách spojení, pak spolu vždy vzájemně komunikují protokoly odpovídající vrstvy.

Na následujícím obrázku je uveden architektura TCP/IP modelu používaného v sítích VoIP.

Vrstva síťového rozhraní (Network Interface Layer) je v rámci modelu TCP/IP vrstvou nejnižší a bývá velmi často ještě rozdělena na dvě dílčí vrstvy – fyzická vrstva (Physical Layer) a spojová vrstva (Data Link Layer). Obecně má tato vrstva na starosti především interpretaci signálů na přenosovém médiu (optické sítě, bezdrátové sítě, metalické sítě) a sdílení přenosového média mezi více zařízeními.

Model TCP/IP je záměrně navržen tak, aby byla možná spolupráce co největšího počtu různých typů sítí, resp. široká možnost implementace různých přenosových technologií. Proto není tato vrstva v rámci modelu TCP/IP striktně specifikována a je do jisté míry závislá na konkrétní použité přenosové technologii (např. Ethernet, ATM (Asynchronous Transfer Mode), WiFi, xDSL (Digital Subscriber Line), SDH (Synchronous Digita Hierarchy),…). Tato vrstva je realizována naúrovni hardwarových prvků a zařízení.

Síťová vrstva (Network Layer) má za úkol především směrování dat v síti od zdroje k cíli a to nezávisle na použité přenosové technologii. Při návrhu síťového protokolu v rámci modelu TCP/IP se především kladl důraz na rychlost přenosu na úkor zajištění spolehlivého přenosu. Spolehlivost tak byla ponechána na navazujících vyšších vrstvách.

Funkcionalitu síťové vrstvy má na starosti především protokol IP zajišťující distribuci informací mezi vyššími vrstvami. Dále pak protokoly zajišťující vlastní směrování dat (OSPF (Open Shortest Path First), RIP (Routing Information Protocol)), dohled v síti (ICMP (Internet Control Message Protocol)) a řada

Hlavní funkcí protokolu IP je přenos informace mezi zdrojem a cílem. Data z vyšších vrstev jsou rozdělena do paketů a ty jsou bez nutnosti navazování spojení odeslány přímo do sítě. Na základě směrovacích tabulek definovaných v jednotlivých uzlech sítě jsou směrována k cíli. Pokud dojde při přenosu ke ztrátě (např. v důsledku přetížení v síti), je úkolem protokolů vyšších vrstev zajistit adekvátní opravu. Protokol je implementován ve všech prvcích TCP/IP sítě. Protokol IP se dnes používá ve dvou verzích. První verzí specifikovanou již v roce

1981 organizací IETF (Internet Engineering Task Force) je protokol IP verze 4 (IPv4). Je popsán v RFC (Request For Comment) 791 a jeho hlavním znakem je adresový prostor 232 čísel. Tato vlastnost se již v minulosti projevila jako nedostačující, a proto byl dodatečně vytvořen protokol IP verze 6 (IPv6), který mimo další vylepšení poskytuje výrazně zvětšený adresový prostor 2128 adres.

Transportní vrstva (Transportation Layer) bezprostředně navazuje na rychlou, ale nespolehlivou síťovou vrstvu. Zajišťuje tak funkce související především se zajištěním spolehlivosti přenosu. Míra spolehlivosti je závislá na použitém protokolu transportní vrstvy. Transportní protokoly jsou na rozdíl od síťových protokolů implementovány pouze v koncových zařízeních a nikoliv v jednotlivých uzlech sítě. Data přenášená mezi dvěma koncovými zařízeními (např. mezi webovým prohlížečem a serverem) jsou nejprve přijata z vyšší vrstvy, následně rozdělena na menší celky a uložena do paketů. Další funkce (např. řazení paketů, kontrola chybovosti, řízení objemu přenášených dat, apod.) pak závisí na konkrétním použitém protokolu transportní vrstvy.

Nejpoužívanějšími protokoly transportní vrstvy jsou protokol TCP (Transmission Control Protocol) a protokol UDP (User Datagram Protocol).

Protokol TCP zajišťuje spolehlivý přenos dat. Veškerá data poslaná pomocí protokolu TCP budou doručena ke svému cíli a to ve správném pořadí a bez chyb. Protokol TCP vytváří taková spojení, do kterých mohou aplikace vyšších vrstev postupně vkládat svá data a ta jsou na druhé straně spojení odebírána partnerskou aplikací.

Samotný protokol TCP tedy řeší případy, kdy může dojít ke ztrátě dat na některé z nižších vrstev (síťové nebo fyzické). Pokud neobdrží potvrzení od příjemce o správném doručení dat, zahájí jejich opakované odeslání. Tak pořadí doručených paketů se může lišit od původního. Tuto skutečnost je řešena dočasným uchováváním doručených paketů a jejich následným zpracováním po větších celcích. Protokol TCP je vhodný transportní protokol pro aplikace citlivé na ztrátu dat (např. pro přenos souborů, emailů nebo webových stránek).

Protokol UDP je jednodušší variantou protokolu TCP. Protokol již nezaručuje spolehlivé doručení přenášených dat ani jejich správné pořadí. Jediné co zajišťuje, je rozlišování mezi jednotlivými odesílateli a příjemci a rozdělení da přijímaných z nadřazených vyšších vrstev. Protokol UDP má velmi jednoduchou strukturu záhlaví. Jednoduchost protokolu UDP tak umožňuje velmi efektivní přenos se zachováním rychlosti přenosu síťové vrstvy. Protokol UDP je tedy velmi často využíván jako transportní protokol především u aplikací vyžadujících přenos v reálném čase s minimálním časovým zpožděním. Např. přenos hlasu a videa v sítích VoIP je velmi citlivý na zpoždění, a proto jejich přenos probíhá převážně prostřednictvím protokolu UDP.

Na úrovni aplikační vrstvy pracují tzv. aplikační procesy (např. běžící programy), které poskytují přímé služby uživatelům prostřednictvím standardizovaných rozhraní nebo také služby ostatním aplikačním procesům běžícím na stejné úrovni. Stěžejní funkcí aplikační vrstvy je především umožnit a zprostředkovat spolupráci

mezi dílčími procesy běžícími na vzdálených systémech. Protokoly aplikační vrstvy využívané v sítích VoIP dělíme na dvě základní skupiny. První skupinou jsou přenosové protokoly, tj. protokoly sloužící pro přenos informace směrem k uživateli (např. ve formě hlasu, videa, apod.). Druhou skupinu tvoří řídicí protokoly, které naopak v síti zajišťují podmínky pro vlastní

Protokol TCP není ze své podstaty vhodný pro přenos multimédií, jako jsou např. hlasové a obrazové informace, v reálném čase. Je to dáno především zpožděním, které vzniká v případě ztráty a mechanismu opětovného přeposlání informace. Protokol UDP sice vyhovuje svou rychlostí, avšak chybí mu funkce potřebné pro zaručení přenosu v reálném čase. Proto byl navržen přenosový protokol RTP (Real-time Transport Protocol).

Protokol RTP je jako většina výše uvedených protokolů standardem organizace IETF (Internet Engineering Task Force). Specifikace protokolu je volně dostupná na Internetu pod označením RFC 3550. Protokol RTP využívá jako svého transportního protokolu protokol UDP, ke kterému však navíc přidává následující funkce. Protokol RTP čísluje vysílané pakety a v případě doručení paketů v nesprávném pořadí tak snadno dochází k úpravě jejich pořadí. Protokol RTP také označuje časové okamžiky vyslání jednotlivých paketů. V případě ztráty jsou na přijímací straně chybějící pakety vynechány a ty správně doručené jsou umístěny na odpovídající časovou pozici.

V případě ticha není přenášena žádná informace. Protistrana pouze vytváří šum pro navození přirozeného prostředí. Protokol RTP dále označuje přenášený obsah. To znamená, že identifikuje, zdali jde o hlasovou (resp. audio) nebo obrazovou (resp. video) informaci a jakým způsobem byla komprimována (typ kodeku). Na přijímací straně jsou pak tato data vyhodnocena cílovou aplikací a převedena do původní podoby. Vzhledem k tomu, že protokol RTP umožňuje přenos více komunikačních kanálů současně, je také nutná identifikace zdroje obsahu. Každý komunikační kanál (audio, video, …) je pak přenášen v samostatném RTP toku.

VER	Kódování	Audio/Video	Popis
0	PCMU	A	ITU-T G.711 PCM μ-law
3	GSM	A	GSM kodek
4	G723	A	ITU-T G.723.1
5	DV14	A	IMA ADPCM kodek
8	PCMA	A	ITU-T G.711 PCM A-law
9	G722	A	ITU-T G.722 (širokopásmový)
12	QCELP	A	EIA & TIA standard IS-733
15	G728	A	ITU-T G.728
18	G729	A	ITU-T G.729
26	JPEG	V	Video komprimované algoritmem JPEG
31	H261	V	ITU-T H.261 (n×64 kbit/s)
32	MPV	V	MPEG-1, MPEG-2 video
33	MP2T	A/V	MPEG-2 audio, video
34	H263	V	ITU-T H.261 (nízké přenosové rychlosti)

Mechanismus ukládání digitalizovaných dat do paketů a jejich následný přenos

Protokol RTCP (Real-time Transport Control Protocol) je protokolem, jehož účelem je sledování kvality přenosu dat přenášených prostřednictvím protokolu RTP. Protokol RTCP tedy nepřenáší vlastní uživatelská data, ale pouze periodicky vysílá kontrolní data všem účastníkům účastnících se komunikace. Na základě příjmu kontrolních dat jsou a mohou být vyhodnocovány následující

• doba mezi vysláním paketů a příjmem odpovědi ze vzdálené strany Koncová zařízení mohou pomocí protokolu RTCP získat data, která slouží pro úpravu parametrů vlastního RTP toku. Konkrétně jde např. o optimalizaci

přenosové rychlosti, která zabrání případnému vzniku dalších ztrát nebo omezí kolísající zpoždění. Není to však přímo protokol RTP, resp. protokol RTCP, který by přímo zajišťoval tyto funkce. Přenos protokolu RTCP je totiž svázán s přenosem protokolu RTP na transportní vrstvě. Každému toku uživatelských dat (RTP toku) je přidělen UDP port a příslušnému RTCP toku je přiřazen port hodnotou o jednu vyšší.

Implementovat určitou konkrétní míru zabezpečení komunikace ve VoIP síti je mnohem snazší než jak je tomu v pevných nebo mobilních telefonních sítích. Základní idea spočívá v rozšíření protokolu RTP o další přídavné protokoly, mezi které patří např. protokoly SRTP (Secure Real-time Transport Protocol) a ZRTP (Zimmermann secure Real-time Transport Protocol). Zabezpečení může být také provedeno pomocí protokolu TLS (Transport Layer Security) nebo implementováno na nižších vrstvách jako například na síťové vrstvě pomocí mechanismu IPSec (IP security).

Nejpoužívanější řídicí protokol, resp. signalizační protokol, v sítích VoIP je protokol SIP. Tento standard vytvořený organizací IETF byl vydán pod označením RFC 3261. Protokol SIP byl také přijat organizací 3GPP pro řízení multimediálních spojení v mobilních sítích založených na protokolu IP v rámci

V klasických pevných nebo mobilních telekomunikačních sítích založených na signalizačním systému SS7 (Signalling System No. 7) bylo řízení rozprostřeno mezi jednotlivá spolupracující síťová zařízení. Naproti tomu koncepce protokolu SIP koncentruje řídicí funkce převážně do koncových zařízení. Díky tomu jsou pak síťové prvky pouze jednoduchá směrovací zařízení (např. IP směrovače). Mezi řídicí protokoly užívané převážně v páteřních sítích se řadí také skupina protokolů standardu H.323. Za vývojem koncepce standardu H.323 stojí standardizační organizace ITU, která v současné době připravuje nástupní standard H.325.

Protokol SIP jako řídicí protokol aplikační vrstvy je zodpovědný za sestavení spojení v síti, dohled nad jeho průběhem a ukončení stávajícího spojení. Spojením může být chápán hlasový nebo video hovor mezi dvěma či více účastníky nebo automatickými zařízeními nebo jakékoliv jiné spojení vyžadující své sestavení jako je např. systém okamžité výměny zpráv a souborů tzv. IM (Instant Messaging). Samotný přenos uživatelské informac probíhá na bázi protokolu RTP, jehož podrobnější popis je uveden v předchozích kapitolách. Protokol SIP je jednoduchý protokol založený na textově kódovaných zprávách. Protokolové zprávy lze snadno číst v jednoduchých prohlížečích textu bez nutnosti převodu z jejich binární formy. Protokol SIP nezjišťuje konkrétní schopnosti účastnických koncových zařízení (např. podporované kodeky, apod.). Výměna těchto informací je funkcí protokolu

SDP (Session Description Protocol), který je zapouzdřen v těle některých SIP

zpráv. Pomocí protokolu SDP se mají možnost účastnická komunikující zařízení domluvit na způsobu kódování multimediálních dat, na číslech používaných portů, na kterých poběží RTP přenosy, případně na dalšíc podporovaných funkcích. Protokol SIP může využívat pro svůj přenos libovolný z protokolů transportní vrstvy (TCP, UDP). Nejčastěji však využívá protokolu UDP a portu 5060.

Jednotlivé uživatele v síti VoIP odlišuje a zároveň jednoznačně identifikuje tzv. SIP adresa. Tato adresa je syntaxí podobná emailové adrese, tj. skládá se z identifikátoru uživatele, značky „@“ a označení domény (př. uživatel@doména). Ve své nejjednodušší formě může být SIP adresa ve formátu uživatel@IP_adresa.

To tedy znamená, že dva uživatelé spolu mohou v rámci sítě IP přímo komunikovat pouze za předpokladu znalosti IP adresy druhého z uživatelů. Na straně volaného pak také musí být aktivní tzv. SIP User Agent (viz Architektura SIP), který je schopen příchozí volání přijmout. Běžnějším způsobem adresace používaným v síti VoIP operátorů je označení uživatele unikátním telefonním číslem a doménová část specifikuje IP adresu SIP serveru operátora (viz Architektura SIP) – př. 123456789@operator.cz. Aby vůbec bylo možné volat uživatele s touto adresou je nejprve nutná registrace adresy SIP. Uživatel vloží svou adresu do koncového zařízení a to následně provede registraci v síti VoIP. Tímto krokem tak dojde ke svázání SIP adresy uživatele a jeho současného umístění neboli konkrétní I adresy koncového zařízení. (registrace: uživatel@doména ↔ IP adresa)

Pro řízení komunikace v síti VoIP za pomoci protokolu SIP je nutný SIP server a tzv. uživatelský agent UA (User Agent).

Architektura SIP vytváří síťové prvky nazývané „server“. Tyto servery následně poskytují své funkce uživatelským agentům tak, aby bylo možné vytvářet spojení v síti VoIP. Za všech okolností však není vždy nutné instalovat v síti všechny typy serverů. Bývá zcela běžné, že více virtuálních serverů sdílí jeden fyzický SIP server (např. kombinace Proxy + Registrar + Location server).

Registrar server přijímá žádosti o registraci od jednotlivých koncových zařízení. Pomocí procesu registrace dochází ke svázání identity uživatele (SIP adresa) a konkrétního umístění koncového zařízení (IP adresa). Tyto informace jsou následně uloženy v Location serveru a dále slouží pro směrování v IP síti.

Location server poskytuje informaci o dislokaci jednotlivých koncových zařízení. Tyto informace vkládá do Location serveru Registrar server nebo mohou být přímo definovány správcem sítě.

Hlavní funkcí Redirect serveru je umožnit směrování v síti VoIP, které je iniciováno na základě žádosti o spojení od klienta. Redirect server pak posílá informaci (adresu), kam žádost o spojení přesměrovat.

Proxy server přijímá žádosti o spojení od klientů a pomáhá je směrovat v IP síti. Pokud je volaný uživatel registrován přímo na tomto serveru, pak žádost přeposílá přímo na jeho koncové zařízení. Informaci o umístění uživatele, resp. IP adresu koncového zařízení, získává Proxy server z Location serveru. V případě, že je uživat registrován pod jiným SIP serverem, přeposílá žádost na cílový server a další cíl směrování žádosti je pak určen dotazem do záznamů uložených v systému DNS (Domain Name System). Funkcí Proxy serveru je také ověření

identity uživatelů. Na základě uvedení správných identifikačních údajů je pak uživatel oprávněn využívat funkcí Proxy serveru.

Uživatelský agent představuje koncové zařízení nebo Proxy server. Jeho funkce lze rozdělit na klientskou část UAC (User Agent Client) a serverovou část UAS (User Agent Server). Funkcí klientské části je vysílat žádosti (např. o registraci koncového zařízení nebo o zahájení komunikace). Serverová část naopak reaguje na příchozí žádosti a vysílá odpovědi klientské části. Koncová zařízení mohou být implementována ve formě programu na počítači

(Software Client) nebo v podobě terminálů velmi podobných klasickým analogovým, resp. digitálním telefonům (Hardware Client).

Funkcionalita protokolu SIP je založena na výměně SIP zpráv. SIP zprávy jsou

jednoduché, textově kódované (kódování UTF-8) a lze je tak číst v libovolném prohlížeči textu.

Struktura SIP zpráv a jejich výměna připomíná protokol pro výměnu webových stránek HTTP (HyperText Transfer Protocol). Komunikace probíhá výměnou žádostí (Method) a odpovědí (Response) mezi klientskou a serverovou částí uživatelských agentů (UAC a UAS). V následujícím stručném přehledu jsou uvedeny základní typy žádostí definované v RFC 3261. Další metody rozšiřující funkce protokolu SIP jsou definovány v samostatných RFC.

• REGISTER (registrace do sítě) – pokud se uživatel přihlašuje do sítě proběhne registrace koncového zařízení. Zpráva REGISTER zahajuje proces registrace.

• INVITE (žádost o spojení) – v případě, že uživatelský agent zahajuje spojení, vyšle zprávu INVITE. Zpráva jde buď přímo volanému, nebo je směrována přes Proxy servery. Na základě doručení zprávy zjistí volaný své možnosti, tj. zda je uživatel dostupný/obsazený/přesměrovaný, a dále např. jaké jsou podporované kodeky, apod. Na základě tohoto zjištění pak vyšle jednu z následujících odpovědí.

• ACK (potvrzení o sestavení spojení) – protokol SIP vytváří spojení výměnou tří zpráv. Žadatel o spojení nejprve vyšle zprávu INVITE. V případě, že volaný přijme hovor, vyšle odpověď 200 OK. Na závěr volající potvrzuje sestavení spojení zprávou ACK.

• CANCEL (přerušení sestavování spojení) – pokud se uživatel rozhodne přerušit sestavování spojení (spojení ještě nebylo sestaveno) vyšle uživatelský agent zprávu CANCEL. Protistrana odpoví chybovou hláškou a pokus o sestavení spojení je ukončen.

• BYE (konec spojení) – pro ukončení spojení je vyslána zpráva BYE. Protistrana odpoví potvrzením a spojení je následně ukončeno.

• OPTIONS (zjišťování možností) – možnost jednoho uživatelského agenta zjistit schopnosti protistrany bez toho, aniž by uživatelský agent musel zahájit spojení. Pomocí OPTIONS zprávy může zjistit podporované zprávy, kodeky a typy médií, které je protistrana schopna obsloužit.

Odpovědi protokolu SIP vychází z HTTP odpovědí. Určitá část HTTP odpovědí je využita i v protokolu SIP a některé jsou přidány navíc. Zde jsou základní třídy SIP

• 1xx (průběh) – vzdálená strana informuje o průběhu zpracování žádosti

• 3xx (přesměrování) – odpověď s informací kam přesměrovat žádost

• 4xx (chyba klienta) – odpověď informuje o tom, že žádost klienta nebyla ve

správném formátu nebo nemůže být na tomto serveru obsloužena. Na jiném serveru však může být žádost úspěšná.

• 5xx (chyba serveru) – nastala chyba na straně serveru. Přestože byla žádost vytvořena podle pravidel, server není schopen ji obsloužit.

• 6xx (fatální chyba) – informuje o ukončení pokusu o navázání spojení z důvodu chyby. Např. žádost byla odmítnuta uživatelem nebo požadovaná média (typ kodeku) nejsou podporována.

Přenos uživatelské informace pomocí protokolu RTP probíhá přes protokol UDP. Protokol UDP však svým charakterem nezaručuje doručení zpráv ani jejich konstantní zpoždění. Protokol RTP přidá funkce zaručující správné pořadí v cíli, odstranění duplicit a umístění obsahu na správnou časovou pozici. Protokol RTCP navíc poskytne informace o zpoždění, kolísání zpoždění a ztrátách při přenosu. Žádný z výše uvedených protokolů však nezaručuje pevnou šířku pásma, resp. přenosovou rychlost, konstantní a co nejnižší hodnotu zpoždění. To jsou ovšem nutné předpoklady pro kvalitní realizaci multimediálních přenosů v reálném čase. Z tohoto důvodu j potřeba uplatnit jiné mechanismy pro zajištění dostatečné kvality poskytovaných služeb – QoS (Quality of Service). Mechanismy, jak zajistit dostatečnou kvalitu poskytovaných služeb v sítích VoIP:

1. První možností jak zaručit dostatečnou míru QoS je předimenzování spoje. V IP síti tak dojde k vytvoření spoje s takovou přenosovou kapacitou, která je výrazně vyšší než nejvyšší očekávaná hodnota provozního zatížení daného spoje.

2. Druhou možností je, že si VoIP klient rezervuje síťové zdroje. To znamená, že na žádost klienta je v síťových prvcích rezervována určitá část kapacity (např. požadovaná šířka pásma, prostor ve vyrovnávací paměti, apod.) a tyto prostředky již nemohou být využity ostatními spojeními. Příkladem rezervačních mechanismů mohou být tzv. integrované služby (IntServ) spolu s protokolem RSVP (ReSource reserVation Protocol). Implementace takového mechanismu však vyžaduje podporu ze strany koncových zařízení i síťových prvků.

3. Třetí možností je využití tzv. prioritních mechanismů. Příkladem takových mechanismů mohou být tzv. diferencované služby (DiffServ) nebo mechanismy MPLS (MultiProtocol Label Switching). Jednotlivé pakety vysílané v síti jsou označeny prioritou, která udává pořadí jejich zpracování v síťových prvcích. Implementace obou algoritmů je nutná v síťových prvcích a v případě diferencovaných služeb (DiffServ) také

V důsledku omezeného počtu IP adres (IPv4) a v zájmu ochrany lokálních počítačů vznikají tzv. privátní sítě. V těchto sítích jsou počítačům přidělovány privátní IP adresy, které se však mohou v různých sítích opakovat, tj. nejsou jedinečné oproti veřejným adresám v Internetu. Zařízení na rozhraní privátní sítě a veřejného Internetu se nazývá překladač síťových adres NAT (Network Address Translation). V případě, že aplikace v privátní síti vytváří spojení do veřejné sítě, jde toto spojení přes překladač NAT. Zde je privátní adresa zdroje zaměněna za veřejnou adresu překladače a informace je poslána ke svému cíli. V případě odpovědi vyhledá překladač v převodních tabulkách původní privátní adresu, ze které požadavek vzešel a směruje odpověď na tuto lokální adresu. Avšak pokud je spojení zahájeno z veřejné sítě, překladač NAT neví (a ani z podstaty věci vědět nemůže), na ktero privátní adresu jej má směrovat. Existují však řešení, jak v překladači NAT napevno přiřadit, kam se maj doručené zprávy

z veřejné sítě směrovat dál. Např. Příchozí spojení řízené protokolem SIP na portu 5060. Avšak pak lze zprávy směrovat pouze jen na jeden počítač a nejsou tak volně k dispozici v privátní síti. Druhým problémem je průchod uživatelské informace. Protokol RTP pro přenos audio/video dat nemá staticky definovaný port. Ten je vždy stanoven dynamicky až při sestavování spojení. Proto mohou nastávat situace, kdy je spojení navázán (vyzvánění + příjem spojení) avšak jedna strana druhou „neslyší“ nebo „nevidí“.

Nejjednodušším řešením by bylo překladač NAT vůbec nepoužít. Dnes je tato možnost i docela reálná, a to díky implementaci protokolu IP ve verzi 6 (IPv6), kde je k dispozici dostatečně široký adresní prostor, nebo v případě, že bychom připojovali pouze jediné SIP zařízení v privátní síti, pak lze v překladači NAT

nastavit přesměrování, tzv. tunelování, rozsahu příchozích portů veřejné adresy (5060-5070 pro signalizace SIP a 8766-35000 pro RTP data) na privátní adresu zařízení. Ještě lepším řešením je využít protokol, který přenáší řízení i uživatelskou informaci společně (např. protokol IAX (Inter-Asterisk eXchange) na portu 4569).

V tomto případě stačí tunelovat na překladači NAT jediný port na cílové zařízení. Jinou možností je podpora protokolů jako je např. protokol STUN (Simple Traversal of UDP over NATs), které umožní koncovým zařízením v privátní síti zjistit, jakým způsobem jsou připojeny do veřejné sítě, tj. jakou mají veřejnou

adresu, a následně ji používat pro vlastní spojení. Pokud překladače NAT dynamicky mění kombinaci veřejné adresy a portu pro každé spojení, pak bohužel ani toto řešení nepomáhá. Další možností je dynamické sestavení přenosové cesty s použitím techniky ICE (Interactive Connection Establishment). Technika ICE na rozdíl od protokolu SIP umožňuje sestavit přenos uživatelských dat až po sestavení signalizačního spojení

a vybrat optimální způsob průchodu překladačem NAT. Posledním standardem IETF pro průchod spojení přes překladač NAT je protokol TURN (Traversal Using Relay NAT). Tento protokol pracuje na principu přeposílání uživatelské informace od TURN serveru umístěném ve veřejném Internetu klientovi v privátnísíti. V současné době se již vyskytují řešení překladačů NAT, která již mají přímo implementovanou podporu pro sítě VoIP a spojení jimi mohou volně procházetbez omezení.

V sítích VoIP mohou nastat problémy s přenosem faxů, které pro svůj přenos vyžadují zaručenou šířku pásma. Pokud tak dojde například ke kompresi signálu v průběhu přenosu, část přenesené informace se ztratí a na příjímací straně nebude možné obnovit původní zprávu.

Řešením může být použití protokolu ITU-T T.38, který je určen pro přenos faxů v IP sítích. Jinou možností je považovat faxový systém za systém přenosu zpráv, u kterého není vyžadován přenos dat v reálném čase. To znamená, realizovat přenos faxu např. jako přílohu e-mailu, případně jako vzdálený tisk. Koncový

systém pak totiž může přechodně uložit kompletní zprávu do vyrovnávací paměti před jejím vlastním zobrazením nebo tiskem.

GSM kodek	Přenosová rychlost	Parametr MOS
GSM HR	5,6 kbit/s	3,5
GSM FR	13 kbit/s	3,7
GSM EFR	12,2 kbit/s	4,5