Měření propustnosti VoIP sítí

Transkript

1

2

3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Měření propustnosti VoIP sítí Bc. Tomáš Vondra Vedoucí práce: Ing. Kučerák Ján Studijní program: Elektrotechnika a informatika, magisterský Obor: Výpočetní technika 10. května 2011

4

5 Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne :

6

7 Abstrakt Práce se zabývá měřením propustnosti VoIP sítě založené na protokolu SIP, konkrétně Open IMS Core, z hlediska maximálního počtu transakcí za jednotku času. V teoretickém úvodu rozebírá obecné kořeny technologie VoIP, popisuje protokol SIP a jeho aplikaci v síti IMS. Na základě dostupných pramenů v podobě standardů a vědeckých článků navrhuje měření podle normy ETSI TS , z dostupných generátorů zátěže vybírá IMS Bench SIPp. Následně je popsán průběh měření na referenční síti a je učiněn závěr, že tato síť je příliš nestabilní pro reálné nasazení. Abstract The thesis deals with VoIP throughput measurement on a SIP-based network, namely the Open IMS Core, from the perspective of maximal amount of transactions per a unit of time. The theoretical introduction analyses the common roots of VoIP technology, describes the SIP protocol and its application in the IMS network. Based on available sources in the form of standards and scientific articles, a measurement method based on ETSI TS is proposed and IMS Bench SIPp is selected among the available load generators. Subsequently, the course of measurement on the reference network is described and the conclusion is drawn that this network is too unstable for real applications.

8

9 Obsah 1 Úvod VoIP aneb internetová telefonie Obecně Princip Historie Problémy Topologie Druhy zařízení Výhody a nevýhody SIP (Session Initiation Protocol) Vlastnosti Popis protokolu SDP (Session Description Protocol) Průběh hovoru a příklady IMS (Internet Multimedia Subsystem) Vlastnosti Odlišnosti od čistého SIP Popis sítě Platforma Open IMS Core Měření propustnosti VoIP Teoreticky Sledované veličiny Kvalitativní Výkonnostní Metodika měření Aplikační servery Infrastruktura SIPstone ETSI TS Generátory zátěže Návrh metody měření Průběh měření Seznámení s Open IMS Core Softwarové telefony pro IMS Monster IMS Communicator UCT IMS Client Mercuro IMS Bench SIPp Instalace Seznámení s programem

10 4.4 Zavedení uživatelů Testovací pokusy, pozorování Prvotní pokusy, ladění parametrů Open IMS Core Přesun na finální platformu, potíže se stabilitou serveru Distribuovaný režim hovorové scénáře Závěr Seznam literatury Příloha A - Seznam zkratek Příloha B - Obsah přiloženého CD

11 Seznam obrázků Obrázek 1 - Princip VoIP Obrázek 2 - De-jitter Buffer [11] Obrázek 3 - Topologie VoIP Obrázek 4 - hardwarový VoIP telefon [16] Obrázek 5 - VoIP ATA brána [16] Obrázek 6 - VoIP DECT brána [16] Obrázek 7 - Softwarový telefon Obrázek 8 - Navázání hovoru přes proxy [28] Obrázek 9 - Průběh registrace Obrázek 10 - Vrstvy v IMS [31] Obrázek 11 - Aplikační server v režimu proxy [32] Obrázek 12 - Vztahy identit v IMS [5] Obrázek 13 - Vyhledání P-CSCF [5] Obrázek 14 - Druhy roamingu v IMS [5] Obrázek 15 - Sestavení hovoru v IMS [5] Obrázek 16 - Komponenty Open IMS Core [41] Obrázek 17 - Obslužný systém [58]

12

13 1 Úvod V poslední době jsme svědky masivního rozmachu datových sítí a rapidního vývoje souvisejících technologií. Vysokorychlostní Internet proniká již nejen do sféry firemní, ale i do domácností, ceny připojení klesají, poněvadž jsou tlačeny dolů konkurencí mezi různými poskytovateli a technologiemi připojení. S pokrokem v technologiích přichází snaha o konvergenci služeb a sítí. O tento fenomén mají zájem všechny zúčastněné strany. Koncovému zákazníku umožní platit poplatky za připojení pouze k jedné síti, poskytovateli zase nabízet na své síti více služeb a rozšířit tak svou působnost a pokrytí trhu. Na to reagují i standardizační organizace. Zřejmě prvním důkazem je síť ISDN (Integrated Services Digital Network), standardizovaná CCITT už v roce 1988 [6], která dokázala přenášet hlas, data i video. Síť ISDN ovšem patří mezi sítě s přepojováním okruhů, což je pro datový provoz nevýhodné jak z hlediska plýtvání přenosovou kapacitou, tak v důsledku i ekonomicky. V datových sítích se proto vývoj ubíral směrem k technologii přepojování paketů. Mezi těmito sítěmi se nejvíce prosadila síť Internet založená na protokolu IP (Internet Protocol). Síť Internet má pro přenos hlasu spíše špatné vlastnosti, protože v globálním měřítku neposkytuje žádnou garanci kvality služeb. Přesto, hlavně kvůli její rozšířenosti a nízké ceně za provoz, je snaha ji k přenosu hovorů využívat. Technologie toto umožňující se souhrnně označují zkratkou VoIP (Voice over IP). V současné době nejrozšířenější VoIP technologií, pomineme-li uzavřené technologie typu Skype, je zřejmě ta postavená na protokolu SIP (Session Initiation Protocol) a dalších přidružených protokolech z dílny IETF, která oblíbeností předčila konkurenční ITU-T H.323. SIP zřejmě za vhodnější uznala i standardizační organizace 3GPP při projektování architektury IMS (Internet Multimedia Subsystem), což je návrh jádra mobilní sítě, které má nahradit jádro s přepojováním okruhů známé z GSM, a umožňuje připojovat uživatelské terminály libovolnou přístupovou sítí podporující protokol IP. IMS je především reakcí na předchozí vývoj, kdy konvergence sítí na základě standardů od telekomunikačních standardizátorů neměla úspěch a dostupné protokoly z internetového světa neměly všechny vlastnosti potřebné pro telekomunikační operátory. IMS proto SIP rozšiřuje o silnější autentizaci uživatele, systém autorizace a účtování, protokoly pro připojení služeb sítě, definuje způsob propojování operátorů mezi sebou a další vylepšení. Projekt Open IMS Core implementuje jádro sítě IMS pomocí otevřeného software. Existence dostupné implementace a dobře definovaný způsob propojení sítí IMS slibuje možnost bezproblémového spojování uživatelů jednotlivých VoIP sítí různých institucí, které by tuto technologii nasadily. (V současném stavu jsou systémy založené na SIP většinou osamělé pobočkové ústředny, používané na hovory uvnitř organizace a přístup do veřejné telefonní - 1 -

14 sítě. Spojování sítí je otázkou důvěry mezi administrátory kvůli nedostatku autentizace a autorizace.) Otevřenou implementaci lze také s výhodou využít k experimentování s touto novou sítí. Projekt Open IMS Core je ovšem ve stadiu vývoje, trpí nedostatkem dokumentace a o jeho praktických vlastnostech není mnoho známo. Proto vzniká tato diplomová práce, jejímž účelem je zjistit metody používané k výkonnostnímu testování VoIP sítí, navrhnout metodu vhodnou pro testování sítě IMS a změření parametrů zkušební instalace serveru Open IMS Core. V případě katastrofálního selhání tohoto serveru bych navrženou metodu použil na jiný server sítě IMS, případně klasický SIP server. Vlastní práce začíná druhou kapitolou, kde se podíváme na obecné vlastnosti VoIP sítí, rozebereme sítě SIP a IMS a shrneme jejich rozdíly. Zjistíme stav projektu Open IMS Core a jaké funkce IMS pokrývá. V kapitole třetí se zaměříme na měření propustnosti VoIP sítí, zvláště pak které veličiny jsou zajímavé a jaké jsou běžné metody k jejich zjišťování. Podíváme se na existující normy a praktické příklady měření. Následovat bude rešerše dostupných nástrojů na generování simulované zátěže a výsledný návrh konkrétní testovací metody. Ve čtvrté kapitole popíšu přípravu měřícího prostředí a průběh vlastního měření. V páté kapitole, závěru práce, budou shrnuty hlavní body této práce, výsledky měření a budou naznačeny možnosti dalšího výzkumu

15 2 VoIP aneb internetová telefonie 2.1 Obecně Pojem VoIP (Voice over IP) není nic jiného, než co říká rozklad této zkratky přenos hlasu pomocí protokolu IP (Internet Protocol). Někdy se také používá pojem internetová telefonie, který je mu podřízený; IP můžeme provozovat ve vlastní uzavřené síti, zatímco použití pojmu Internet implikuje globální dostupnost a dosah služby. Běžně se ale tyto dva pojmy dají použít zaměnitelně Princip Pro přenos hlasu po protokolu IP je nejdříve nutné ho digitalizovat, což se provádí nejčastěji ve světě telekomunikací obvyklou metodou vzorkování s frekvencí 8KHz a kvantování na 8 bitů, čímž vzniká datový tok 64 kbit/s. Existují ale i širokopásmové VoIP kodeky, které zpracovávají vyšší kvalitu vstupního signálu. Další fází je kódování, při kterém může být datový tok snížen nějakým hlasovým kodekem. Základním kodekem je G.711 (PCM), který přímo posílá navzorkovaný materiál a výstupní datový tok zůstává 64 kbit/s, ostatní kodeky používají nějaký algoritmus ztrátové komprese zvuku. Známé jsou například G.723 (MLQ), G.726 (ADPCM), G.729 (ACELP) nebo nestandardizované a licencemi nezatížené ilbc a Speex. Tyto kodeky výstupní datový tok snižují, od 40 kbit/s u G.726 až po 5,3kbit/s u G.723 [10]. Daní za to je snížená kvalita zvuku, spotřeba výpočetního výkonu a přidané zpoždění v řádu desítek ms [11]. Zakódovaný hovorový signál se pro přenos IP sítí rozdělí na bloky, nejčastěji konstantní velikosti, což se nazývá paketizace. Velikost paketů se volí s ohledem na to, že příliš malé pakety by při přenosu sítí měly velkou režii, a to jak s ohledem na velikost hlaviček, tak na výpočetní výkon nutný na zpracování ve směrovačích (router); příliš velké pakety zase znamenají přidané zpoždění, protože paketizér musí počkat, než se jeho vyrovnávací paměť zaplní hlasovými daty; také riziko jejich ztráty při průchodu sítí je vyšší. Běžně se velikost paketu volí tak, aby zpoždění bylo 20 nebo 30 ms [11]. Na přijímací straně se provedou opačné postupy, v opačném pořadí, tj. depaketizace, dekódování a digitálně-analogový převod. A/D převod kódování paketizace IP síť depaketizace dekódování D/A převod Obrázek 1 - Princip VoIP - 3 -

16 2.1.2 Historie Zřejmě prvním počítačovým programem, který pracoval dle tohoto schématu, byl program Internet Phone od izraelské společnosti Vocaltec vydaný v roce 1995 [7]. Byl to komerční program a sliboval uživatelům ušetřit za dálkové telefonní hovory. K provozu mu stačila vytáčená linka už od 14,4kbit/s. Spustit šel na počítači s procesorem 486/66MHz [13]. V roce 1996 vydala organizace ITU-T standard H.323, původně určený na podporu videokonferencí po lokálních sítích, ale brzy se začal používat i k přenosu hlasu po Internetu, čemuž se přizpůsobily pozdější revize tohoto standardu (Poslední je H.323v6 z roku 2006 [14].). Je to robustní protokol, složený z několika podstandardů. K provozu potřebuje otevřít několik portů TCP (Transmission Control Protocol) i UDP (User Datagram Protocol), sestavení spojení je otázka výměny až 8 zpráv [12]. První komerční softwarovou ústřednu (softswitch) na tomto standardu vyvinula americká firma Level 3 v roce 1997 [7]. V roce 1999 [7] vydala IETF doporučení RFC 2543, popisující první verzi protokolu SIP (Session Initiation Protocol). Tento protokol je určen na sestavování, změnu a ukončování multimediálních relací v IP sítích. Podporuje několik transportních protokolů a dokáže popsat širokou škálu konfigurací datových proudů [12]. Tato flexibilita, skutečnost, že je na rozdíl od H.323 textový, takže je jednodušší na ladění, a celkově jednodušší návrh způsobily, že v současné době nad H.323 v oblasti IP telefonie převažuje. H.323 se stále používá v oblasti videokonferencí a při spojování mezi telekomunikačními operátory. K sestavení spojení v SIP obvykle stačí 2 UDP porty jeden na signalizaci a jeden na datový tok RTP (Real-time Transport Protocol), vymění se 3 zprávy. V témže roce [7] vyšla první verze otevřené (open source) softwarové ústředny Asterisk firmy Digium. Ta umožňuje každému postavit si z běžného počítače VoIP pobočkovou ústřednu, včetně služeb jako hlasová schránka, přesměrování, přepojování a vyzváněcí skupiny. V rámci tohoto projektu byly také vyvinuty protokoly IAX (Inter-Asterisk Exchange) a IAX2, které jsou zajímavé tím, že na rozdíl od výše zmiňovaných protokolů používají jen jeden UDP port na signalizaci i data, ba dokonce i k přenosu více hovorových kanálů, což zjednodušuje procházení bezpečnostními prvky typu firewall a NAT (Network Address Translator). Jeho podpora není široká, ale už se dočkal standardizace v RFC 5456 [15]. V roce 2002 vydala 3GPP dokument Release 5, ve kterém uvádí systém IMS (IP Multimedia Subsystem), původně určený na zavedení multimediálních služeb do mobilních telefonů v sítích GPRS (General Packet Radio Service). Později byla do standardu přidána podpora dalších přístupových sítí a počítá se s ním jako s primárním nositelem hlasových služeb pro mobilní síť LTE (Long Term Evolution), která již neimplementuje službu s přepojováním okruhů a má být čistě datová [8]. Tento standard zatím není v oblasti - 4 -

17 internetové telefonie příliš známý, je možné, že se v ní ani nerozšíří a zůstane doménou mobilních sítí. Dokonce i v telekomunikační oblasti má konkurenci ve specifikaci VoLGA (Voice over LTE Via Generic Access), která by měla tunelováním okruhů přes IP prodloužit životnost původního jádra sítě GSM (Groupe Spécial Mobile) a zmenšit tak náklady na přechod na novou technologii[9] Problémy Inherentní pro IP Problémy IP telefonie vycházejí již ze samé podstaty protokolu IP a sítě na něm založené. Jde o síť s přepojováním paketů a bezestavovým provozem, anglické označení pro tento druh sítě best effort se do češtiny někdy překládá jako nespolehlivá služba. Pakety se mohou při průchodu sítí ztratit, dorazit v jiném pořadí, než byly vyslány, nebo mohou dorazit ve více kopiích. Korekci těchto situací nechává IP na protokolech vyšších vrstev, ovšem TCP, které poskytuje spojově orientovanou službu s garantovaným doručením se ve VoIP nepoužívá, neboť retransmise ztracených paketů by způsobovaly nepřípustné zpoždění a zdržovaly by i všechny pakety vyslané bezprostředně po ztraceném paketu. Místo toho se používá protokol UDP, který negativní vlastnosti IP zachovává. Navíc v IP sítích obecně nemůžeme počítat se zaručenou kvalitou služeb čili QoS (Quality of Service). Směrovače v síti řadí pakety většinou do jedné fronty, takže malý VoIP paket musí často čekat, než se linkou odešle několik velkých datových paketů. To způsobuje zpoždění, a náhodná povaha délek front na směrovačích pak vnáší do zpoždění variabilitu čili jitter. Nástroje na zavedení QoS v IP sítích samozřejmě existují, v hlavičce IP je k tomu vyhrazeno pole DSCP (Differentiated Services Code Point), VoIP programy ho často i nastavují na vyšší prioritu, ale málokterý z domácích směrovačů, se kterými jsem se setkal, nastavenou prioritu respektuje, a mezi poskytovateli Internetu je nejčastější praktikou hodnotě v tomto poli nedůvěřovat a pole nulovat, protože jeho zneužití by umožňovalo případnému útočníkovi poměrně efektivně zahltit síť. Ve výsledku jsou QoS metody použitelné pouze ve firemních sítích, nad kterými má administrátor plnou kontrolu. Naštěstí jsou v současné době páteřní internetové linky naddimenzované a představují minimální zpoždění. Nejužšími místy sítě jsou tak přístupové linky, na kterých si člověk může s vhodným vybavením QoS sám nastavit. Tyto problémy se vzhledem k výše uvedenému blokovému schématu projevují ve fázi depaketizace. Možnost ztráty paketu a příchodu mimo pořadí se řeší tím, že se hlasová data zabalí do protokolu typu RTP (Real-time Transport Protocol), který má ve hlavičce časovou značku. Do cesty datovému toku se postaví fronta zvaná de-jitter buffer, která převádí variabilní zpoždění na konstantní. Její střední délka se nastavuje nejméně na nejdelší - 5 -

18 očekávané zpoždění. Pakety se do fronty řadí podle časové značky a doba, kterou ve frontě stráví, dává nějaký čas opožděným paketům aby dorazily a byly zařazeny na své místo podle časové značky. Pokud se pakety zpozdí příliš, přehraje se místo nich ticho a dále se na ně nečeká, stejně se řeší pakety ztracené. Pokud by se zpoždění v síti náhle zmenšilo, hrozí naopak zahození paketů kvůli přetečení fronty. Pokročilé VoIP programy dokáží na změnu zpoždění v síti reagovat např. změnou rychlosti přehrávání vzorků a posunout tak střední délku fronty. [11,12] Obrázek 2 - De-jitter Buffer [11] NAT (Network Address Translation) Dalším problémem, specifickým pro současnou dobu, je NAT. IP adres je nedostatek, a tak jsou klientské počítače, ke kterým není třeba mít přístup z Internetu, adresovány privátními adresami, a přístup do globální sítě jim zajišťuje technologie dynamického překladu adres. Při návrhu standardních protokolů pro VoIP, a to jak H.323, tak SIP, se s tímto stavem nepočítalo a jejich návrh je pro průchod přes NAT, dá se říci, nejhorší možný. V případě SIP není problém s otevřením řídícího spojení, ale datové spojení se otevírá na náhodných UDP portech, a to navíc na adresu, která je uvedena v obsahu SIP paketů, kterou samozřejmě běžný NAT, prohlížející pouze hlavičky, neumí změnit. Výsledkem může být, že telefon sice zvoní, ale není v něm slyšet hlas na jedné či na obou stranách. Situace s H.323 je podobná, ne-li horší. Na obcházení NAT bylo vyvinuto množství různých technologií pro použití na telefonech, ústřednách i vlastních NAT zařízeních. Například softwarová ústředna Asterisk umí detekovat situaci, kdy adresa, ze které přišel SIP paket, je jiná než ta, která je v něm uvedena jako cílová pro datové spojení. Tu pak při sestavování datového spojení neuvažuje a navíc nastaví porty svého hlasového kanálu stejně jako klient, čímž dosáhne průchodu přes NAT. Na domácích směrovačích se zase můžeme setkat s technologií SIP ALG (Application Layer Gateway), která podle čísla portu detekuje řídící spojení SIP a na aplikační vrstvě v něm přepisuje adresy. Zjištění konfigurace NAT a sestavení přímého hlasového spojení mezi dvěma účastníky zase podporují technologie jako STUN (Session Traversal Utilities for NAT) a ICE (Interactive Connectivity Establishment). Naneštěstí bývají aplikační brány v levných směrovačích nekvalitní a spojíli se více zařízení s touto technologií za sebe na přenosové trase, je výsledkem často ticho ve sluchátku. Proto byly vyvinuty technologie jako IAX (Inter

19 Asterisk Exchange), který multiplexuje řídící i hlasové informace na jedno spojení, nebo Skype, které využívá šťastnější uživatele s veřejnou IP adresou na spojování hovorů těch uživatelů, kteří jsou za překladem adres. Ve specifikaci IMS se tento problém neřeší, neboť se od začátku počítá s nasazením IPv6 (Internet Protocol version 6), ve kterém se NAT nepoužívá [5]. Bezpečnost Jednoduchost přístupu k firemnímu VoIP serveru odkudkoli z Internetu je sice dobrá věc, ale skrývá i své nebezpečí. I když to uživatelům nemusí být na první pohled jasné, jedná se o server jako každý jiný a může obsahovat bezpečnostní chyby, které má kdokoli z Internetu příležitost využít a následně udělat majiteli virtuální ústředny nemalý účet za telefon. Toto nebezpečí podporuje také to, že hesla k účtům internetové telefonie mívají často formu číselné kombinace, aby šla zadávat na klávesnicích hardwarových telefonů. To útočníka přímo vyzývá k vyzkoušení útoku hrubou silou. Obranou je pravidelné záplatování operačního systému, na kterém ústředna běží, a používání silnějších hesel, protože i hardwarové telefony většinou umožňují jejich zadání. V případě častých útoků pak pomůže restriktivní firewall. Také odposlech hovorů je na IP telefonii jednodušší, než v případě pevných telefonních linek. Odposlech na takové lince šel rozpoznat podle změny kvality hovoru a impedance vedení, v digitálních sítích toto neplatí, data je možné zkopírovat bez jakékoli změny na kvalitě, a na rozdíl od digitálních telefonních linek je vybavení na odposlech VoIP velmi snadno dostupné, stačí počítač se softwarem na zachytávání paketů. Rekonstruovat hovor ze zachycených dat je možné například známým nástrojem Wireshark. Naštěstí nejsou pro IP sítě dostupnější jen nástroje na odposlech, stejně dostupné jsou i nástroje na zabezpečení přenosu. V H.323 i SIP je možnost použití TLS (Transport Layer Security), ovšem komerční poskytovatelé tuto možnost neposkytují, neboť jim to, alespoň v České Republice, zákon zakazuje [16]. Není ale větší problém spustit si vlastní, neveřejnou, virtuální ústřednu a TLS si na ní nastavit, případně tunelovat hovory přes IPSec (IP Security) nebo jinou technologii šifrované VPN (Virtual Private Network). Na šifrování v uzavřených aplikacích jako Skype není radno spoléhat, protože neexistuje záruka, že nikdo další nemá šifrovací klíč (u Skype je přímo známo, že operátor má ke klíčům přístup, protože se na něj vztahují stejné zákony, jako na ostatní veřejné telefonní operátory) Topologie I když VoIP označuje jakýkoli případ přenosu hlasu přes IP síť, ve skutečnosti připadá v úvahu jen několik základních scénářů, ve kterých se VoIP používá. Tyto možnosti bych zde shrnul a uvedl příklady použití

20 Propojení dvou částí veřejné telefonní sítě v tomto případě je technologie VoIP použito k propojení telefonních ústředen nikoli přes telefonní síť, ale přes síť datovou. Používá se v případech, kdy mezi oběma místy není telefonní okruh, ale je dostupný okruh datový, nebo jsou dostupné obě technologie, ale použití datové sítě je finančně výhodnější. Příkladem první možnosti je propojení dvou klasických pobočkových ústředen v rámci jedné firmy, které jsou obě připojené do Internetu, a kdy firma chce ušetřit na hovorech mezi těmito pobočkami, ale ještě se jí nevyplatí investovat do pronajaté linky na telefonní provoz. Druhou možnost využívají například telefonní operátoři k nabízení levných mezistátních hovorů. Propojování operátorů na mezistátní úrovni je zřejmě levnější pomocí IP sítě, než pomocí telefonních okruhů. S výhodou se také dá využít komprese hlasu, aby se do dané kapacity linky vešlo více hovorů. Brána mezi VoIP sítí a veřejnou telefonní sítí zde máme část sítě na technologii VoIP a část klasickou telefonní, mezi nimi stojí nějaký druh brány, podle rozsahu může stačit vyřazený počítač s ISDN (Integrated Services Digital Network) kartou a vhodným softwarem (např. Asterisk), nebo může být použita specializovaná pobočková ústředna s VoIP modulem. Také rozsah a povaha takových sítí jsou různé. V zásadě můžeme rozlišovat VoIP sítě soukromé a veřejné. Soukromou síť může nasadit například firma, která do kanceláří nakoupí VoIP telefony místo telefonů klasických, případně je ve stadiu přechodu mezi těmito technologiemi. V jádru takové sítě můžeme právě nalézt výše zmíněný počítač s ISDN kartou jako rozhraním do veřejné telefonní sítě, který je pro firmu menší investicí než hardwarová pobočková ústředna. Veřejné sítě provozují takzvaní alternativní telefonní operátoři, jejichž ceny bývají nižší než u poskytovatelů klasické pevné telefonní služby. Dostupnost služby může být omezena na vlastní datovou síť operátora, ve které je schopen garantovat kvalitu služeb, nebo může být služba provozována po veřejném Internetu. Brána mezi sítěmi bývá někdy jednosměrná, kdy se z VoIP sítě dá dovolat do veřejné, ale VoIP stanice nemá přidělené vlastní telefonní číslo, nebo obousměrná. Čistě VoIP síť případ, kdy komunikace jde čistě po IP síti a na žádné části cesty hovoru není klasická telefonní linka. Může jít čistě o komunikaci dvou počítačů na Internetu, adresovaných pomocí IP adresy, nebo o telefonní hovor ve firmě, která používá IP telefony. Jsou-li telefony registrované v pobočkové ústředně, může tato provádět převod telefonních čísel na IP adresy. Stejně fungují VoIP telefonní linky poskytované alternativním operátorem. V čistě VoIP síti je možné místo telefonních čísel používat textových jmen či přezdívek, což je případ sítě Skype. Sítě SIP a IMS - 8 -

21 umožňují identifikaci uživatelů způsobem podobným ové adrese, tj. Je-li DNS (Domain Name System) server cílové domény správně nastaven, měla by být možná komunikace i mezi doménami. Toho je možné docílit i pomocí telefonních čísel, jejichž doménovou příslušnost lze vyhledávat pomocí rozšíření DNS zvaného ENUM (E.164 Number Mapping) [17]. Někde mezi touto a předchozí kategorií stojí soukromé VoIP sítě, které potřebují bránu do veřejné telefonní sítě, ale neimplementují ji samy, nýbrž využijí nějakého veřejného VoIP operátora, případně operátora velkoobchodního, takzvaného terminátora VoIP linek, který tyto linky zakončí ve veřejné telefonní síti. Zdroje [10,12]. IP síť tel. síť IP síť IP síť Obrázek 3 - Topologie VoIP - 9 -

22 2.1.5 Druhy zařízení Nerad bych se zde pouštěl do popisu zařízení tvořících jádro VoIP sítě, protože v každé technologii se funkční bloky jmenují jinak, i když funkčnost bývá podobná. Například v H.323 můžeme najít Gatekeeper a Gateway, v SIP jsou obdobné prvky nazvané Registrar a Proxy, v IMS HSS (Home Subscriber Server) a CSCF (Call Service Control Function). Co je u všech sítí stejné, jsou druhy koncových zařízení. Pro VoIP existují hardwarové stolní telefony, které jsou na první pohled nerozeznatelné od analogových tlačítkových či digitálních telefonů. Vyrábí se různé typy, od levného telefonu se základní funkcionalitou, jako ten na Obr. 4, přes manažerské telefony s velkým barevným displejem a podporou videohovorů, až po telefony s polem programovatelných tlačítek pro spojovatelky [10]. Dalším druhem uživatelského terminálu jsou různé brány. Může jít o bránu typu ATA (Analog Telephone Adapter, Obr. 5), ke které se dá připojit analogový telefon; výsledná funkcionalita je podobná jako u levných hardwarových telefonů. Některé brány umožňují připojit několik telefonů na několik VoIP účtů nebo použít analogovou telefonní linku jako zálohu při výpadku internetového spojení. Oblíbené jsou brány s podporou sítě DECT (Digital Enhanced Cordless Telecommunications, Obr. 6), které rovněž umožňují připojit více telefonů a více linek, ale navíc s možností pohybu po domě či kanceláři. Prapůvodní internetové telefony měly podobu počítačových programů a i dnes se můžeme se softwarovými klienty setkat. Jejich hlavní výhodou je možnost vyzkoušení VoIP bez investice do hardwaru. Na druhé straně se mohou s úspěchem použít v prostředí telefonních center, kde operátor ocení například možnosti propojení s databází zákazníků. Poznámka: SIP klient Phoner zobrazený na Obr. 7 doporučuji. Jeho grafické rozhraní sice není tak pěkné, jako u jiných podobných programů, ale zobrazuje použité kodeky a umožňuje zobrazení ladícího výpisu SIP zpráv, který se velmi hodí při řešení problémů. Existují i přenosné VoIP telefony, které se do sítě připojují technologií WiFi (Wireless Fidelity). V poslední době se objevují chytré mobilní telefony, které jsou buď přímo zamýšlené jako kombinované GSM/VoIP telefony, nebo jejich operační systém umožňuje spuštění softwarového VoIP klienta. V případě praktického nasazení sítě IMS se přímo počítá s kombinovanými telefony, které se budou připojovat přes technologie LTE, UMTS (Universal Mobile Telecommunications System) nebo WiFi do sítě IMS a v případě její nedostupnosti dojde k předání hovoru do sítě GSM [5]

23 Obrázek 4 - hardwarový VoIP telefon [16] Obrázek 5 - VoIP ATA brána [16] Obrázek 6 - VoIP DECT brána [16] Obrázek 7 - Softwarový telefon Výhody a nevýhody Hlavním důvodem, proč se vůbec VoIP používá, je cena. Existuje řada ekonomických důvodů, proč je VoIP levnější než klasická telefonie. Základem je nízká cena přenosů v datových sítích. Zatímco telefonní operátor účtuje hovory podle času, internetové linky v dnešní době bývají účtované měsíčním paušálem, který účastník, tak jako tak závislý na datových službách, musí platit. V takovém případě je jasné, že není výhodné platit další paušál za připojení do telefonní sítě. Účtování hovorů na minuty se dá zcela vyhnout, pokud používáme čistě VoIP síť, a za hovory do veřejné telefonní sítě zaplatíme alternativním operátorům či velkoobchodním terminátorům výrazně méně než operátorům fixních linek. Při nasazení technologie VoIP ušetří firma nejen na poplatcích za provoz, ale také na infrastruktuře. Zatímco klasické pobočkové ústředny jsou limitované počtem portů na připojení telefonů a externích linek, a od jejich počtu se odvíjí cena takového zařízení, ústředna pro IP telefonii si vystačí s jedním portem Ethernet na obsluhu stovek poboček, včetně připojení k bráně do veřejné telefonní sítě, a je možno ji vytvořit z otevřeného software běžícího na běžném počítači. Od výkonnosti počítače se pak odvíjí množství hovorů, které dokáže ústředna současně obsloužit. S VoIP ušetříme také na kabeláži. Od pobočkové telefonní ústředny je nutné natáhnout symetrický pár ke každému telefonu, s technologií Ethernet

24 můžeme využít výhod strukturované kabeláže a táhnout mezi každými dvěma místy jen jeden kabel. VoIP je možné spojit s dalšími internetovými technologiemi a nabídnout tak uživateli více služeb. Namátkou mě napadá například videotelefonie, sdílené nebo centrálně uložené adresáře, posílání souborů nebo spojení se sociálními sítěmi. Pokud jde o nevýhody, tak o jedné nevýhodě VoIP jsem se již zmínil v podkapitole Problémy výše. Touto nevýhodou je zpoždění. Zatímco analogová telefonní linka znamenala přímé spojení dvou míst drátem a zpoždění bylo rovno době šíření signálu vodičem, novější digitální telefonní hierarchie časového multiplexu pro každý hovor rezervuje timeslot a přidané zpoždění je maximálně rovno délce rámce, která je v SDH (Synchronous Digital Hierarchy) 125 µs [18], používají se v IP sítích techniky ulož a pošli dál (store and forward), takže pro každý úsek, kterým pakety projdou, se přičítá doba, po kterou je paket vysílán síťovou kartou na linku. Navíc musí v IP síti každý paket obsahující hlasová data soupeřit o linku s datovými pakety, které mohou být ve frontě na směrovači před ním. Jak jsem zmínil výše při popisu principů technologie VoIP, přidává kódování, paketizace a depaketizace další zpoždění. Díky těmto procesům dosahuje zpoždění i na lokální síti desítek milisekund. Vložíme-li mezi účastníky veřejnou síť Internet, a zvláště jsou-li jejich přístupové linky postavené na některé pomalejší technologii, může zpoždění snadno dosáhnout nesnesitelných hodnot. ITU-T v doporučení G.114 udává, že uživatel nepozná zpoždění do 150 ms, zpoždění do 400 ms dokáže akceptovat, ale při vyšších hodnotách začne být zpoždění velmi obtěžující [11]. Cisco uvádí, že maximální rozumná hodnota je dokonce jen 250 ms. Se zpožděním souvisí výpadky paketů, které už v poměrně malém množství dokáží rapidně snížit kvalitu hovoru. Proto je důležité na vytížených linkách, po kterých má být provozována VoIP služba, zavádět QoS (Quality of Service), je-li to možné. Fakt, že je možné do objektu mít zavedenu jen jednu datovou linku a vynechat linky telefonní, zmiňovaný mezi výhodami, se může snadno změnit v nevýhodu technologie VoIP v okamžiku, kdy řečená linka vypadne. V tom okamžiku přijde firma nejen o datové spojení, ale i o telefonní, což jí může způsobit vyšší ztráty, než kdyby měla telefony vedené odděleně. Obecně nižší spolehlivost Internetu tento problém znásobuje. Zařízení na internetových linkách jsou, na rozdíl od analogových telefonních linek, závislá na dodávce elektrického proudu. V případě jeho přerušení telefony také přestávají fungovat. Tato nižší spolehlivost znamená, že není úplně vhodné, aby v domě nebylo jiné telefonní spojení, než VoIP, už s ohledem na možnost volání na nouzová telefonní čísla. I kdyby se na ně účastník dovolal, decentralizovaná povaha Internetu může záchranářům ztěžovat práci s vypátráním jeho polohy. Čeští operátoři sice mají povinnost registrovat u čísla stanice její umístění [12,16],

25 nic ale nebrání zlomyslnému uživateli v ohrožení připojit se do VoIP sítě z úplně jiné internetové přípojky. 2.2 SIP (Session Initiation Protocol) Vlastnosti SIP je protokol vytvořený v rámci standardizační organizace IETF a popsaný dokumentem RFC 2543, momentálně poslední verze SIP 2.0 má číslo RFC Mimo to existují další RFC dokumenty popisující různá rozšíření tohoto protokolu, těmi se tu ale nebudu zabývat, nebude-li to nutné. Stránka [19] obsahuje jejich seznam. Účelem SIP a řešení na něm postavených je poskytnout účastníkům službu správy relací, a to hlasových, video, multimediálních, případně i herních. Umožňuje i relace více než dvou účastníků. Na rozdíl od H.323, který je uceleným a kompaktním řešením zaměřeným na poskytování hlasových a konferenčních služeb, je v souladu s filosofií Internetu SIP pouze jednou, i když ústřední, částí modulární architektury protokolů, jejichž součinnost teprve dokáže poskytnout kýžené služby. Souvislost SIP s ostatními internetovými protokoly je na první pohled patrná. Jde o textový protokol vycházející z osvědčených protokolů HTTP (Hypertext Transfer Protocol) a SMTP (Simple Mail Transfer Protocol), který ovšem od počátku počítá s kódováním UTF-8 (Unicode Transformation Format 8). Z HTTP si půjčuje schéma žádost-odpověď, kdy na první řádce žádosti se vyskytuje takzvaná metoda, adresa URI (Uniform Resource Identifier) a verze protokolu, v odpovědi opět verze, návratový kód a jeho slovní popis. Ze SMTP si bere dělení zpráv na hlavičky a tělo. Druhy polí, vyskytujících se v hlavičkách, jsou směsí obou, s přidáním některých dalších. Formát těla zprávy je popisován pomocí MIME (Multipurpose Internet Mail Extensions). Adresace uživatelů je řešena pomocí takzvaného SIP URI, které nápadně připomíná ovou adresu, až na to, že metoda není mailto:, ale sip:, případně sips:, pokud si přejeme zabezpečené spojení. Příklad: sip:uzivatel@domena.cz. Zvláště pokud je SIP síť spojena s veřejnou telefonní sítí, používají se také telefonní čísla zapsaná jako tel: URI. Příklad: tel: SIP URI obsahují adresu domény a jsou propojeny se systémem DNS (Domain Name System). Zařízení SIP může zjistit adresu serveru obsluhujícího danou doménu pomocí záznamů SRV (Service record) [20]. Tel: URI sice doménu přímo neobsahují, ale bylo vyvinuto rozšíření DNS systému jménem ENUM (E.164 Number Mapping), které mapuje telefonní čísla do hierarchické struktury DNS a umožňuje k danému telefonnímu číslu dohledat doménu, ke které přísluší [17]. Protokol SIP je navržen tak, aby byl nezávislý na protokolu transportní vrstvy (v modelu OSI). Běžně se provozuje na protokolu UDP (User Datagram

26 Protocol), ale je možné použít i TCP (Transmission Control Protocol) nebo SCTP (Stream Control Transmission Protocol), případně zabezpečit přenos vložením vrstvy TLS (Transport Layer Security). V každém případě má SIP přiděleno číslo portu 5060, zabezpečený SIP Jak již bylo řečeno, SIP sám o sobě neposkytuje služby IP telefonie či videokonferencí, slouží pouze jak signalizační protokol. Jako takový zajišťuje tyto služby [4 kap.1, 19]: Nalezení účastníka a překlad jmen zajišťuje, že se hovor dostane k zamýšlenému účastníkovi a bude existovat mapování mezi jeho adresou a skutečným umístěním (IP adresou). Zjištění dostupnosti účastníka zajišťuje, že volající bude informován, zda je volaný ochoten relaci přijmout (například o stavech jako odmítnutí, obsazení a přesměrování). Zjištění schopností účastníka zajišťuje výměnu informací o podporovaných druzích médií, formátech a kodecích mezi účastníky. Navázání spojení prozvonění volaného, přijetí relace a navázání hlasových, příp. jiných datových kanálů. Řízení a změny probíhajícího spojení umožňuje změnu parametrů relace v jejím průběhu, například změnu kodeku, přidání dalšího datového toku, přesměrování, přizvání dalšího účastníka. Patří sem také ukončení spojení. Na zjišťování schopností účastníku ve skutečnosti SIP částečně potřebuje součinnost dalšího protokolu, kterým je obvykle SDP (Session Description Protocol), jehož zprávy se posílají jako tělo SIP zpráv. Tento protokol slouží k popisu parametrů multimediálních relací a výměnou obvykle dvou zpráv se jeho prostřednictvím obě strany dohodnou, kam posílat datové toky a v jakém formátu. Formát zpráv SDP bude popsán v kapitole Samotné datové toky se obvykle posílají protokolem RTP (Real-time Transport Protocol), což je protokol zajišťující pomocí sekvenčních čísel a časových značek posílání a hlavně rekonstrukci multimediálních datových proudů v nespolehlivé síti IP. Jako transportní protokol se používá UDP (je možné použít i SCTP), kvůli zajištění co nejmenšího zpoždění; občasné výpadky paketů se tolerují. RTP také umožňuje oddělit od sebe několik datových proudů i zdrojů dat, které z hlediska UDP přichází ze stejného zdroje, nevím ale o tom, že by se toho v SIP využívalo. [12, 21] RTP je rozšiřitelný pomocí takzvaných profilů, které definují druhy obsahu, jejich čísla pro pole Payload Type v hlavičce, způsob, jakým se přenášejí v RTP paketu a z toho vyplývající velikost paketů, a také rozlišení časových značek, které nejčastěji odpovídá vzorkovací frekvenci daného proudu. V telefonii se používá nejčastěji RTP profile for Audio and video conferences with minimal control (RFC 3551 [22]), zkráceně RTP/AVP. Pomocný protokol RTCP (RTP Control Protocol), který posílá od přijímače zpět k vysílači mj. statistiky o zpoždění a výpadcích paketů, se v SIP telefonii běžně nepoužívá

27 2.2.2 Popis protokolu Prvky sítě Síť založená na protokolu SIP se skládá z uživatelských agentů (UA, User Agent) a serverů. UA jsou koncová zařízení sítě vzhledem ke zpracování SIP zpráv a servery jsou její jádro. Koncový bod sítě může mít podobu VoIP telefonu, softwarového či hardwarového, jak byly popsány v kapitole 2.1.5, ale například i brány do veřejné telefonní sítě, jiného druhu VoIP sítě či jiného zařízení. Důležitý je zde pouze fakt, že zařízení je zdrojem či koncovým příjemcem SIP zpráv. UA se logicky dělí na UAC (User Agent Client) a UAS (User Agent Server) právě podle toho, zda v dané transakci (viz níže) figuruje jako odesilatel žádosti a příjemce odpovědi (UAC), či naopak (UAS). Koncové zařízení musí implementovat obě logické části. Specialitou je B2BUA (Back to Back User Agent), který jako server přijme žádost a aby ji vyplnil, odešle jako klient novou žádost dále do sítě. V zásadě je to brána mezi dvěma SIP sítěmi. Na rozdíl od proxy serveru musí udržovat stav navázaných SIP dialogů (viz. podkapitola Dialogy a transakce). SIP byl o začátku navržen tak, aby odpovídal decentralizovanému internetovému stylu návrhu, takže na rozdíl od klasických telekomunikačních sítí, kde většina inteligence je v jádru sítě, je zde naopak kladen větší důraz na funkčnost UA, zatímco hlavní úkol serverů je směrovat požadavek směrem k cíli [23]. Servery se dělí na Proxy, přesměrovací (Redirect) a registrční (Registrar). Úkolem proxy serveru je přijmout požadavek od UA nebo jiného proxy serveru a předat jej dále směrem k cíli, případně přímo cílovému UA, pokud je v jeho doméně. Na proxy serverech také může probíhat autentizace a kontrola administrativních politik, tj. např. smí-li účastník vůbec hovor uskutečnit. Proxy servery se dělí na bezestavové, které pouze přeposílají každou zprávu, kterou dostanou, a stavové, které pro každou zprávu spustí transakční stavový automat (viz. Dialogy a transakce) a samy se starají o její úspěšné doručení. Takové proxy servery také interpretují a mění/přidávají do zprávy hlavičky, nejčastěji za tím účelem, aby další zprávy z dialogu procházely stejnou cestou jako ta první. Pokud SIP klient posílá všechny požadavky předkonfigurovanému proxy serveru místo proxy serveru cílové domény, nazývá se tento odchozí (outbound) proxy. Přesměrovací server slouží také ke směrování požadavků k cíli, ale na rozdíl od proxy neposílá zprávy dál a odpovídá na ně odpovědí z kategorie 300 (přesměrování). Tím předá UA informaci, jak směrovat požadavek k cíli a je na UA, aby zkonstruoval a odeslal nový požadavek na změněnou adresu. Výhodou tohoto přístupu je, že server nebude v cestě dalších zpráv, což z něj sejme část zátěže. V některých případech (autentizace, účtování, průchod firewallem) je ale žádoucí, aby přes server všechny zprávy prošly a přesměrování použít nelze

28 Registrační server je komponenta, která přijímá požadavky typu REGISTER (viz. další sekce) a údaje z nich ukládá do databáze lokační služby (location service) pro svou doménu. Z této databáze je pak čtou ostatní druhy SIP serverů, obsluhující danou doménu, a to jim umožňuje převádět SIP URI na IP adresy. Všechny výše uvedené druhy prvků je nutné brát jako logické entity. Nemusí být, a také nebývají, oddělené. Softwarový balík typu SIP server může při zpracování různých požadavků vystupovat střídavě jako registrační, proxy i přesměrovací server, obsahuje interní lokační službu a je-li na něm spuštěna například služba hlasových schránek, bude se chovat také jako UAC a UAS. Zdroje [4 kap.6, 10, 19, 23]. Žádosti a odpovědi SIP zprávy se dělí na žádosti a odpovědi. Oba druhy zpráv mají shodný formát v tom, že začínají úvodní řádkou, za kterou následují hlavičky, které končí prázdnou řádkou. Dále může následovat tělo zprávy. Úvodní řádka se pro žádosti a odpovědi liší. U žádostí se skládá z metody, URI a verze protokolu, u odpovědí je na prvním místě verze protokolu, pak návratový kód a jeho slovní popis. Toto schéma je prakticky shodné s protokolem HTTP, ovšem druhy metod se liší a seznam návratových kódů není shodný. Verze je v současné době SIP/2.0 [4 kap.7.0]. Základní SIP RFC definuje pět různých metod, a to REGISTER, který slouží k informování registračního serveru a potažmo lokační služby o umístění klienta. Dále INVITE, který představuje žádost o navázání relace. Vzhledem k tomu, že se k této žádosti často musí vyjádřit člověk, očekává se, že může trvat delší dobu, než na ni bude vygenerována odpověď. Na finální odpověď (jakoukoli, nikoli jen na 200 OK) se proto odesílá reakce ve formě SIP požadavku se speciální metodou ACK. Teprve po této třícestné výměně se může navázat relace. Dalším použitím INVITE je změna parametrů relace. Pokud se tato metoda vyskytne v rámci již navázaného dialogu, mluvíme o ní jako o operaci re-invite. Umožňuje změnu adres a portů, přidání či zrušení datových toků a podobně. V případě, že zpracování nějakého požadavku trvá příliš dlouho, používá se metoda CANCEL, která na serveru způsobí přerušení činností s požadavkem souvisejících a vygenerování chybové odpovědi. Nemá žádný vliv, pokud operace skončí před doručením požadavku na zrušení. Ke zrušení probíhajících relací slouží metoda BYE. Vyslat jí může kterákoli strana relace. Poslední metodou je OPTIONS sloužící ke zjištění schopností SIP zařízení bez navázání relace. Takto je možné zjistit podporované metody, rozšíření, typy těl zpráv a kodeků. Je to jediná metoda, kterou musí každé zařízení SIP povinně implementovat [4 kap.7.1, 19]

29 Odpovědi v SIP jsou určené primárně svým číselným kódem. Slovní popisy následující za kódem mají sice doporučené znění, ale smí se měnit, například přeložit do jiného jazyka. Kódy jsou třímístná dekadická čísla a podle první číslice se dělí do šesti kategorií. Kategorie 1xx jsou takzvané provizorní (provisional) odpovědi. Informují odesilatele žádosti, že byla přijata a server ji zpracovává. Posílají se tehdy, pokud server očekává, že zpracování může trvat déle než 200ms [19], tedy hlavně při použití metody INVITE. Zajímavé kódy jsou například 100 Trying, kterým proxy servery potvrzují přijetí požadavku, 180 Ringing indikující vyzvánění a 183 Session Progress posílaný periodicky a indikující, že zpracování žádosti stále probíhá. Odpovědi třídy 2xx indikují úspěch a používají se k potvrzování úspěšně vyplněných žádostí. Obecně se používá hlavně 200 OK. Třída 3xx indikuje přesměrování, nebo obecně že klient musí k vyplnění žádosti podnikat další kroky. Používají ji přesměrovací servery za účelem směrování žádostí k cíli, případně i SIP klienty na dočasné přesměrování hovorů. Zajímavé kódy jsou 300 Multiple Choices, který dá uživateli seznam umístění, kde lze volaného zastihnout. Používá se, pokud není vhodné vybírat umístění automaticky nebo posílat INVITE na všechny adresy současně (takzvaný forking). 301 Moved Permanently znamená přesměrování, při kterém by si volající měl upravit adresář a 302 Moved Temporarily je běžné přesměrování, které podle přiložené hlavičky Expires může mít nastavenu delší platnost. Pokud hlavička neexistuje, musí se pokaždé opakovat původní požadavek [4 kap ]. Kategorie 4xx, chyba klienta, je nejpočetnější skupina odpovědných kódů. Znamená obecně, že požadavek má špatnou syntaxi nebo že ho server z nějakého důvodu nedokáže splnit. Uživatel může běžně vidět 404 Not Found, které dostane, pokud zadá neexistující adresu/telefonní číslo a 486 Busy Here indikující obsazení linky. Linka, která má nastavenu službu nerušit nebo není registrovaná v lokační službě může vyvolávat kód 480 Temporarily Unavailable [4 kap ]. Kódy 401 Unauthorized, používaný registračními servery, a 407 Proxy Authentication Required obsahují kryptografickou výzvu a SIP klient je řeší automaticky opakováním požadavku s přidanými autentizačními údaji, pokud je má k dispozici. 488 Not Acceptable Here se objevuje nejčastěji tehdy, pokud obě strany sestavované relace nemají žádný společný kodek pro některý datový tok. Na žádost s metodou CANCEL se odpovídá kódem 487 Request Terminated v případě, že je úspěšná, a 481 Call/Transaction Does Not Exist, pokud rušená žádost mezitím skončila. Na opakovanou žádost, kterou ale server již provádí, může přijít odpověď 491 Request Pending. 420 Bad Extension a 421 Extension Required mají co do činění s rozšířeními SIP protokolu, resp. jejich přebytkem nebo nedostatkem. Odpovědi třídy 5xx znamenají chybu serveru, nebo že server nedokázal splnit jinak syntakticky správnou žádost. Jsou to například obecné 500 Server

30 Internal Error a 504 Server Timeout. Směrujeme-li požadavky na server, který není funkční proxy, dostaneme 502 Bad Gateway. Třída 6xx, globální selhání, indikuje, že požadavek nedokáže splnit žádný server. Příklady jsou obecný 600 Busy Everywhere nebo 603 Decline, který znamená, že volaný aktivně odmítl hovor. Zdroje [4 kap.7.2, 19]. Pole hlaviček K vygenerování požadavku ovšem nestačí jen úvodní řádka se specifikací metody, je nutné přidat i hlavičky. Některé jsou povinné, jiné slouží k bližší specifikaci požadavku a jeho parametrů. Formát hlavičky je název: hodnota. U všech částí, které nejsou uzavřeny do uvozovek, nezáleží na velikosti znaků. Stejně tak počet mezer, tabulátorů a konců řádky (mimo případu prázdné řádky, která hlavičky ukončuje) není omezen. Pořadí hlaviček je libovolné s tím, že se doporučuje umisťovat hlavičky důležité pro směrování blízko k začátku zprávy, aby se urychlilo zpracování na proxy serverech. Pokud je ve zprávě více hlaviček stejného typu, pak na jejich pořadí záleží. Některé druhy hlaviček připouštějí sloučení více stejných hlaviček do jedné, jejíž hodnota je seznam původních hodnot oddělených čárkou. Hodnoty mohou mít parametr, který je od nich oddělen středníkem a má formát parametr=obsah. Pro případ, kdy je nutné šetřit přenosovou kapacitou, existují pro názvy nejčastějších hlaviček jednopísmenné zkratky, kterými lze nahradit plné znění názvu. [4 kap. 7.3] Povinné hlavičky jsou To, From, CSeq, Call-ID, Max-Forwards a Via. Hlavička To obsahuje adresu konečného cíle zprávy, na rozdíl od URI žádosti se během života zprávy nemění. Při vyslání zprávy bývají ale obě tato pole shodná. Mimo URI může obsahovat také textové jméno volaného, URI je pak uvedeno za ním v lomených závorkách: To: Carol <sip:carol@chicago.com> Hlavička From podobně obsahuje logickou adresu odesilatele zprávy, včetně možného textového jména. Pokud možno, neměla by v ní být IP adresa. Z pohledu SIP na obsahu této hlavičky příliš nezáleží a lze do ní vyplnit jakékoli (i falešné) jméno, pokud bude syntakticky správně. Povinně se k hlavičce From přidává parametr tag s náhodně vygenerovanou hodnotou. Stejný parametr přidá UAS v odpovědi i ke hlavičce To. From:Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 Pole hlavičky Call-ID je globálně unikátní identifikátor SIP dialogu. Generuje se znovu pro každý nový dialog, naopak v požadavcích na registraci klienta by mělo být neměnné. Doporučený tvar obsahuje náhodné číslo a identifikaci klienta. Dialog je unikátně identifikován až ve spojení s parametry tag od příjemce a odesilatele. Důvodem je to, že jeden požadavek může potenciálně být doručen více příjemcům (forking) a založit více dialogů [4 kap.19.3]. Call-ID: @

31 Pole CSeq slouží jako sekvenční číslo transakce v rámci dialogu. Obsahuje kladné číslo menší než 2 32, při generování musí být menší než 2 31, aby byl prostor pro růst (s přetečením se nepočítá). Za číslem následuje název metody, která transakci započala. Slouží k identifikaci duplicitních zpráv a přiřazení odpovědí k žádostem (v odpovědi se pole CSeq nemění). CSeq: 4711 INVITE Max-Forwards je klasický mechanismus na potlačení zpráv v nekonečných smyčkách. Každý proxy server po cestě toto pole snižuje o 1, v případě, že dosáhne nuly, vygeneruje se chyba 483 Too Many Hops. Doporučená počáteční hodnota je 70. Hlavička Via slouží k zaznamenání cesty, kterou požadavek prošel, a k tomu, aby odpověď na něj prošla zpět stejnou cestou. Klient odesílající zprávu a každý proxy server, který ji zpracovává, přidá na začátek svou hlavičku obsahující verzi protokolu, použitý transportní protokol, adresu daného prvku a povinný parametr branch, což je opět náhodný identifikátor unikátní pro daný prvek a požadavek. Parametr branch povinně začíná řetězcem "z9hg4bk" kvůli odlišení od minulé verze protokolu SIP, která unikátnost nepožadovala. Poslední verze ji využívá například na identifikaci požadavku, který se má zrušit zprávou CANCEL, a na detekci směrovacích cyklů [4 kap.20.42]. Přijímající prvek by měl zkontrolovat, zda adresa uvedená v poli Via odpovídá adrese, ze které mu požadavek přišel, pokud ne, přidá se parametr received se skutečnou adresou odesilatele. Toho se využívá například pro detekci NAT (Network Address Translation). Odpověď na požadavek se pak směruje tak, že se vždy do URI zapíše adresa z první položky Via a na tuto adresu se zpráva odešle (stejné změny URI se dějí i po cestě požadavku, ale proxy servery používají ke zjištění další adresy v cestě své vlastní směrovací mechanismy). Příjemce odebere svoji položku Via ze začátku seznamu a zprávu posílá na další položku Via, pokud existuje, jinak je sám finálním příjemcem zprávy. [24] Via: SIP/2.0/UDP ;branch=z9hG4bK0a5d.90580ee2.0. Norma [4] uvádí, že v požadavcích na sestavení relace a kladných odpovědích na ně je povinná ještě položka Contact, která obsahuje adresu, na kterou si odesilatel zprávy přeje dostávat požadavky jemu zpětně adresované. Tím se docílí toho, že první požadavek projde přes proxy servery, ale všechny další již půjdou mezi koncovými zařízeními přímo. Je-li třeba tomuto chování zabránit, používá se mechanismus založený na hlavičkách Record-Route a Route. Ten funguje následovně: Je-li po cestě prvního požadavku v dialogu proxy server, který si přeje dostávat i další požadavky z tohoto dialogu, přidá svoji adresu na konec hlavičky Record- Route. V odpovědi na požadavek se tato hlavička zkopíruje a dorazí zpět k odesilateli původní zprávy. Oba koncové body si její obsah uloží a při posílání dalších žádostí budou do nich přidávat hlavičku Route s tímto