Měření propustnosti VoIP sítí

Č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

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 10.5.2011:

________________

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 186.008, 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 186.008 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.

Obsah 1 2

Úvod....................................................................................................... - 1 VoIP aneb internetová telefonie ............................................................ - 3 2.1 Obecně ........................................................................................... - 3 2.1.1 Princip.................................................................................... - 3 2.1.2 Historie................................................................................... - 4 2.1.3 Problémy................................................................................ - 5 2.1.4 Topologie ............................................................................... - 7 2.1.5 Druhy zařízení...................................................................... - 10 2.1.6 Výhody a nevýhody ............................................................. - 11 2.2 SIP (Session Initiation Protocol).................................................. - 13 2.2.1 Vlastnosti ............................................................................. - 13 2.2.2 Popis protokolu .................................................................... - 15 2.2.3 SDP (Session Description Protocol) .................................... - 23 2.2.4 Průběh hovoru a příklady..................................................... - 24 2.3 IMS (Internet Multimedia Subsystem) ........................................ - 29 2.3.1 Vlastnosti ............................................................................. - 29 2.3.2 Odlišnosti od čistého SIP ..................................................... - 30 2.3.3 Popis sítě .............................................................................. - 31 2.3.4 Platforma Open IMS Core ................................................... - 44 3 Měření propustnosti VoIP.................................................................... - 46 3.1 Teoreticky .................................................................................... - 46 3.2 Sledované veličiny....................................................................... - 49 3.2.1 Kvalitativní .......................................................................... - 49 3.2.2 Výkonnostní......................................................................... - 50 3.3 Metodika měření .......................................................................... - 52 3.3.1 Aplikační servery................................................................. - 52 3.3.2 Infrastruktura ....................................................................... - 54 3.3.3 SIPstone ............................................................................... - 55 3.3.4 ETSI TS 186.008 ................................................................. - 57 3.4 Generátory zátěže ........................................................................ - 60 3.5 Návrh metody měření .................................................................. - 64 4 Průběh měření ...................................................................................... - 66 4.1 Seznámení s Open IMS Core....................................................... - 66 4.2 Softwarové telefony pro IMS ...................................................... - 68 4.2.1 Monster ................................................................................ - 68 4.2.2 IMS Communicator ............................................................. - 69 4.2.3 UCT IMS Client................................................................... - 69 4.2.4 Mercuro................................................................................ - 70 4.3 IMS Bench SIPp .......................................................................... - 71 4.3.1 Instalace ............................................................................... - 71 4.3.2 Seznámení s programem ...................................................... - 71 -

5 6 7 8

4.4 Zavedení uživatelů ....................................................................... - 76 4.5 Testovací pokusy, pozorování...................................................... - 79 4.5.1 Prvotní pokusy, ladění parametrů Open IMS Core.............. - 79 4.5.2 Přesun na finální platformu, potíže se stabilitou serveru ..... - 80 4.5.3 Distribuovaný režim – hovorové scénáře............................. - 84 Závěr .................................................................................................... - 87 Seznam literatury ................................................................................. - 90 Příloha A - Seznam zkratek.................................................................. - 97 Příloha B - Obsah přiloženého CD..................................................... - 101 -

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

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-

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.

-2-

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ě.

2.1.1 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íť

Obrázek 1 - Princip VoIP

-3-

depaketizace

dekódování

D/A převod

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-

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].

2.1.3 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-

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-

-6-

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).

2.1.4 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í.

-7-

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-

umožňují identifikaci uživatelů způsobem podobným e-mailové adrese, tj. jméno@doména. 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-

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].

- 10 -

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

2.1.6 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

- 11 -

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],

- 12 -

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) 2.2.1 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 3261. 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á e-mailovou adresu, až na to, že metoda není mailto:, ale sip:, případně sips:, pokud si přejeme zabezpečené spojení. Příklad: sip:[email protected]. 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:123456. 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

- 13 -

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 5061. 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 2.2.3. 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á.

- 14 -

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.

- 15 -

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].

- 16 -

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.21.3.3]. 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. 21.4.18]. 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

- 17 -

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:[email protected]>

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:[email protected]>;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: [email protected]

- 18 -

Pole CSeq slouží jako sekvenční číslo transakce v rámci dialogu. Obsahuje kladné číslo menší než 232, při generování musí být menší než 231, 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 195.113.222.3;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 RecordRoute. 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

- 19 -

uloženým obsahem, přesněji na první adresu v seznamu se požadavek odešle a zbytek se přidá jako hlavička do zprávy. Proxy servery pak mechanismem podobným Via dopraví požadavek k cíli po předem určené cestě. Mimo to je v činnosti také mechanismus Via, který zajišťuje směrování odpovědí [4 kap.16.12, 24]. K dohodě SIP zařízení na podporovaných a vyžadovaných rozšířeních protokolu slouží hlavičky Supported a Require, za nimiž se nachází výčet názvů podporovaných, resp. vyžadovaných rozšíření. Zdroj [4 kap.8.1].

Dialogy a Transakce SIP je interně navržen jako strukturovaný protokol; funkcionalita je v doporučení rozdělena na několik volně propojených vrstev. Nejnižší vrstvou je dle [4 kap.5] syntaxe zpráv, na ni navazuje transportní vrstva, definující způsob odesílání a přijímání zpráv na síti. (V kontextu modelu TCP/IP by byla lépe nazvána vrstvou návaznosti na transportní vrstvu, neboť celý SIP spadá do aplikační vrstvy.) Třetí vrstvou je transakční vrstva. Transakce je definována jako požadavek od klienta k serveru, jeho případné retransmise a všechny odpovědi na něj odeslané. Transakční vrstva se stará o spárování odpovědí k požadavkům a o spolehlivé doručení zpráv po nespolehlivé síti, k čemuž jí slouží transakční stavové automaty s časovači ovládajícími opakované posílání zpráv. Některé časovače ale existují i při použití SIP nad TCP. Doporučené časové prodlevy jsou definovány v normě [4 kap.17]. Nejdůležitější z nich je interval nazvaný T1, který ovládá opakované posílání zpráv a má výchozí hodnotu 500 ms. Od něho se odvíjí hodnoty ostatních časovačů, které pak např. zničí transakci při příliš dlouhé absenci odpovědi.. Transakční vrstva se dělí na dvě varianty, serverovou a klientskou, podle toho, spravuje-li odesílání požadavků či odpovědí, navíc je chování odlišné při zpracování metody INVITE. Tato vrstva existuje nejen v koncových zařízeních, ale i ve stavových proxy serverech, nikoli však v bezestavových. Nad transakční vrstvou je vrstva jménem „transaction user“, která užívá transakční vrstvu k odesílání požadavků a určuje adresy, kam se mají posílat. Zpět pak od transakční vrstvy dostává odpovědi na tyto požadavky nebo požadavky od jiných prvků. Má také možnost transakce stornovat metodou CANCEL. Tato vrstva dostává SIP zprávy filtrované transakční vrstvou, tj. každou dostane nejvýše jednou a nedostane žádné zprávy, které přijdou v době, kdy by podle stavového automatu přijít neměly. Tato poslední vrstva je jádrem protokolového zásobníku SIP a určuje celkové chování aplikace. Dělí se podle druhu síťového prvku, tj. UAC jádro, UAS jádro, registrační jádro, proxy jádro. Na této nejvyšší vrstvě existují stavové konstrukty jménem dialogy. Dialog je vztah mezi dvěma koncovými zařízeními, který má delší trvání než transakce. Slouží ke správě sekvenčních čísel a cest (viz. hlavička

- 20 -

Record-Route) mezi UA. Zahajuje se metodou INVITE, která zkonstruuje stav, a tím se pak všechny další požadavky v rámci dialogu řídí. Dialog je identifikován hodnotou hlavičky Call-ID a parametry „tag“ odesilatele a příjemce, je svém stavu pak obsahuje adresy odesilatele a příjemce z hlaviček Contact, jejich sekvenční čísla a cestu ke druhé straně ve formě seznamu proxy serverů, kterými musí zprávy procházet. Také je zde příznak, zda dialog probíhá přes zabezpečené spojení. Dialog se ruší metodou BYE. [4 kap. 12] Nejvyšší konstrukcí protokolu SIP je relace (session), která zahrnuje dialogy mezi dvěma a více koncovými zařízeními a související multimediální datové toky.

Autentizace a zabezpečení SIP používá k autentizaci uživatelů metodu Digest převzatou z protokolu HTTP. Tato metoda zajišťuje autentizaci uživatele heslem bez toho, aby se heslo posílalo po síti v otevřeném tvaru a zabraňuje útokům typu zpětné přehrání (replay). Mechanismus je založen na výzvě serveru, která je součástí odpovědi 401 Unauthorized v případě UAS nebo registračního serveru, případně 407 Proxy Authentication Required vyhrazené proxy serveru. Použité hlavičky se pak jmenují WWW_Authentication nebo Proxy_Authentication. Součástí výzvy je náhodné číslo (nonce) a doména (realm), pro kterou je autentizace vyžadována. Klient na výzvu reaguje tak, že opakuje původní požadavek, na který obdržel odpověd 4xx, ale přiloží odpověď na kryptografickou výzvu. V této odpovědi je výsledek operace hash nad heslem a číslem nonce algoritmem MD5 (Message Digest 5). Na rozdíl od algoritmu CRAM-MD5 (Challenge-Response Authentication Mechanism - MD5) do operace hash vstupuje několik dalších údajů jako doména (realm), URI a uživatelské jméno a provádí se 3 rundy MD5 s různými kombinacemi těchto vstupů, což by mělo Digest činit odolnějším proti útokům generováním kolizí hash funkce. [4 kap.22, 25] Tento mechanismus ale umožňuje pouze autentizaci klienta. Neřeší autentizaci serveru, integritu a utajení zpráv. Potřebujeme-li zajistit i tyto vlastnosti, nabízí SIP použít TLS nad TCP jako svou transportní vrstvu. Pokud je jako metoda URI použito „sips:“, měla by spojení mezi jednotlivými SIP prvky až nejméně do domény příjemce být zabezpečena pomocí TLS, včetně kontroly platnosti certifikátů X.509 a šifrování AES (Advanced Encryption Standard). Protože SIP prvky potřebují číst hlavičky v SIP zprávách, aby je mohly směrovat, není možné zašifrovat celou cestu mezi oběma koncovými zařízeními, ale bezpečnostní asociace se vytvářejí mezi každými dvěma prvky po cestě zprávy. To vyžaduje, aby každý SIP server důvěřoval tomu následujícímu a klient měl důvěru v celý tento řetěz. Možnost, aby klient sám autentizoval každý prvek v řadě, neexistuje [4 kap. 26.2].

- 21 -

Toto schéma zamezuje odposlechu zpráv a jejich změnám jinde, než na proxy serverech, ale neochrání uživatele před zlovolnými či špatně nastavenými proxy servery, které by například na části cesty TLS nepoužily nebo neověřovaly platnost certifikátů a daly tak prostor pro MITM (Man in the Middle) útok, a samozřejmě proti odposlechu zpráv na samotných serverech. Fakt, že se k popisu těla SIP zprávy používá MIME, dává prostor k využití jeho speciálních funkcí jako „multipart“ mimo jiné k přiložení vizitky s obrázkem k SIP zprávě, ale také je možné použít funkci S/MIME k zašifrování těla zprávy stejně, jako v elektronické poště. S/MIME nepoužívá certifikáty serverové, jako HTTP, ale osobní, a umožňuje podepisovat zprávy soukromým klíčem odesilatele a šifrovat veřejným klíčem příjemce. K tomu je samozřejmě nutná předchozí znalost klíče zamýšleného adresáta zprávy. Veřejný klíč je možné získat z dříve přijaté podepsané SIP zprávy, případně z adresářové služby, a ověřit u certifikační autority jeho autentičnost, nebo lze provést ruční výměnu, při které je možné použít i certifikáty nepodepsané známou autoritou (self-signed). Touto metodou se dají šifrovat obsahy SIP zpráv, což jsou většinou popisy multimediálních relací ve formátu SDP, ale mohou to být i jiné zprávy ve formátu MIME, tak, že je nemůže dešifrovat nikdo jiný, než koncový příjemce. [4 kap.23] Norma [4 kap.23.4] také uvádí kompromisní variantu, jak zabezpečit hlavičky SIP zprávy a zároveň zachovat schéma předávání SIP zpráv mezi síťovými prvky. Tím je tunelování SIP v S/MIME v SIP. V takto vytvořené zprávě je pak vnější sada hlaviček, kterou je možno zredukovat na minimum, a v těle této zprávy je šifrovaná vnitřní sada hlaviček a další tělo zprávy, které může přečíst až koncový adresát. Je tak možné utajit hlavičky, které nejsou nutné k doručení zprávy k cíli a obsahují potenciálně citlivé údaje, například Subject, Organization, User-Agent apod. U hlaviček To a From je také možné ve vnější zprávě vynechat textový popis. Hlavičky ve vnější zprávě, které by neměly proxy servery měnit, je možné při přijetí srovnat s jejich šifrovanou verzí a upozornit na případné neshody. Dosud zmíněné metody slouží k zabezpečení signalizačního provozu. Samozřejmě existuje i metoda k zabezpečení samotného hovorového signálu, kterou je SRTP (Secure RTP), rozšiřující profil pro RTP, který umožňuje šifrování a autentizaci RTP paketů. Používá k tomu standardně šifru AES s délkou klíče 128 bitů v čítačovém režimu (Counter Mode), který zajišťuje, že každý paket bude zašifrován jiným klíčem (po dostatečně dlouhou dobu), který bude ovšem odvoditelný ze znalosti hlavního klíče (master key) a pořadového čísla paketu. Autentizace se řeší přidáním zkráceného výstupu funkce HMAC-SHA1 (Hash-based Message Authentication Code - Secure Hash Algorithm 1) na konec paketu. Na výměnu hlavního klíče existuje několik konkurujících si metod, a to SDES (Security Descriptions for Media Streams), rozšíření protokolu SDP, které posílá označení šifrovací metody a klíč v otevřeném tvaru ve zprávě SDP

- 22 -

a spoléhá pro bezpečnost na použití TLS nebo S/MIME, nebo protokoly MIKEY (Multimedia Internet KEYing) a ZRTP (Zimmerman RTP) posílané na začátku datového proudu RTP. MIKEY poskytuje několik schémat výměny klíče, včetně předsdíleného klíče, protokolu RSA (Rivest, Shamir, Adleman) s nebo bez použití veřejné infrastruktury klíčů (PKI, Public Key Infrastructure), a výměnu DiffieHellman. ZRTP nabízí pouze Diffie-Hellman protokol s tím, že proti útoku MITM se chrání tak, že si uživatelé po navázání hlasového spojení přečtou hash hodnotu vzniklou z výměny klíčů, což má na základě ověření hlasu protistrany zaručit, že si klíč skutečně vyměnili spolu a ne s prostředníkem. [26 a odkazy]

2.2.3 SDP (Session Description Protocol) SDP je strukturovaný textový formát sloužící k popisu multimediálních relací. Současná verze je definována v dokumentu RFC 4566. V kontextu SIP se používá k popisu koncových bodů relace, zvláště IP adres a portů, a k dohodě na formátu datových proudů. Dohoda probíhá dvoustranně. Iniciátor SIP relace v požadavku INVITE přiloží do těla SIP zprávy SDP s popisem zamýšlené relace, u mediálních proudů uvede všechny formáty, které sám podporuje. Druhá strana přiloží SDP do těla odpovědi 200 OK, ale uvede pouze ty mediální toky, které je ochotna zpracovat, a u každého vybere pouze jeden formát, ve kterém se pak bude médium přenášet. Nerozumí-li druhá strana žádnému z nabízených formátů, nepošle odpověď 200 OK, ale 488 Not Acceptable Here. Zpráva SDP se skládá z polí. Pole je identifikováno jednopísmennou zkratkou, za ní následuje znak „=“ a hodnota. Pole končí koncem řádku. Dále se zpráva skládá ze tří druhů sekcí. První obsahuje popis relace jako celku, za ní se pak střídavě opakují sekce informací o čase a o parametrech média pro každý popisovaný mediální proud. V sekci popisu relace jsou povinná pole „v“ (Protocol Version), nastavované na 0, „o“ (Origin), obsahující jméno a IP adresu zakladatele relace, a „s“ (Session Name), což je textové pojmenování relace. Nepovinně je možno přidat další textové informační pole „i“ (Session Information) nebo kontaktní informace na zakladatele relace ve formě URI „u“, e-mailové adresy „e“ nebo telefonu „p“. Buď na úrovni relace nebo na úrovni média je povinné pole „c“ (Connection Data), které udává adresu odkud/kam se mají média posílat. Nepovinně se na jedné z úrovní může objevit „b“ (Bandwidth) udávající šířku pásma, podle umístění buď celé relace, nebo jednotlivých proudů. Dále následuje sekce času, která popisuje začátek a trvání, popřípadě opakování, následujícího mediálního proudu. Časy se uvádějí ve formátu „Network Protocol Time“, tj. v sekundách od začátku roku 1900. Pole „t“ (Timing) obsahuje časy začátku a konce proudu oddělené mezerou a je

- 23 -

povinné, pole „r“ (Repeat Times) specifikuje intervaly a délky případných opakování. Sekce popisu mediálního proudu začíná polem „m“ (Media Descriptions), které se skládá z typu proudu („audio“/ „video“), portu, na kterém bude proud posílán, a použitého protokolu. Tímto protokolem je nejčastěji „RTP/AVP“, což je RTP se zmiňovaným profilem „RTP profile for Audio and video conferences with minimal control“ [22]. Dále mohou následovat parametry protokolu, což je případě RTP/AVP seznam číselných kódů kodeků seřazený podle priority. Některé jsou staticky definované v RTP profilu [22], jiné používají dynamické přidělování čísel, čímž se dostáváme k pojmu atribut. Atributy jsou rozšíření základního formátu SDP. Vyskytují se souhrnně pod značkou „a“, za kterou následuje buď pouze jméno atributu, nebo dvojice atribut:hodnota. Takto je možné například implementovat výběr jazyka („lang“) nebo specifikovat kategorii („cat“) a klíčová slova („keywds“). Atributy se mohou vyskytovat v sekci popisu relace nebo mediálního proudu, čímž se specifikuje jejich rozsah platnosti. Pro popis jednotlivých proudů jsou zajímavé zvláště „recvonly“ a „sendrecv“, které určují, zda je mediální tok jednostranný či oboustranný a „rtpmap“ soužící k mapování číselných kódů na kodeky a vzorkovací frekvence u RTP/AVP. Zdroje [10, 24, 27].

2.2.4 Průběh hovoru a příklady Zde bych rád přiložil několik ukázek použití SIP, na kterých jsou vidět výše popsané principy. Na Obr.8 (převzatém s opravou z Wikipedie) je vidět klasický příklad průběhu SIP relace přes dva stavové proxy servery. Je vidět použití provizorních odpovědí 100 Trying, které posílá každý proxy předchozímu uzlu, aby zabránil zbytečnému opakovanému posílání zpráv, a 180 Ringing, kterým UAS informuje, že žádost o spojení oznámil uživateli. Dále je zde finální odpověď 200 OK a její potvrzení metodou ACK, po kterém se naváže vlastní relace, a její ukončení metodou BYE. (Které může provést libovolný z účastníků.)

- 24 -

Obrázek 8 - Navázání hovoru přes proxy [28]

Dále si dovolím uvést jeden příklad převzatý od Cesnetu [24], na kterém je vidět reálný zachycený SIP paket s metodou INVITE. Je vidět, že byl zachycen na cestě či u příjemce, protože obsahuje nejen hlavičku Via odesilatele, ale i jednoho proxy serveru v režimu Record-Route. Dále si všimněte, že obsahuje vyplněné pole Proxy-Authorization, což svědčí o tom, že se jedná o opakované odeslání paketu v reakci na zprávu 407 Proxy Authorization Required. Na konci zprávy je vidět popis relace v SDP, včetně atributů definujících kódy kodeků. INVITE sip:[email protected] SIP/2.0 Max-Forwards: 10 Record-Route: <sip:195.113.222.3;ftag=5DAA94E7;lr=on> Via: SIP/2.0/UDP 195.113.222.3;branch=z9hG4bK0a5d.90580ee2.0 Via: SIP/2.0/UDP 195.113.134.233:5062;branch=z9hG4bK2E1FD348 CSeq: 262 INVITE To: <sip:[email protected]> Proxy-Authorization: Digest username="bbb", realm="ces.net", nonce="43788e90381194d66364fced4dc7097828391e81", uri="sip:[email protected]", cnonce="abcdefghi", nc=00000001, response="ed4adec8" Content-Type: application/sdp From: "Franta Vomacka" <sip:[email protected]>;tag=5DAA94E7 Call-ID: [email protected] Subject: sip:[email protected] Content-Length: 234 User-Agent: kphone/4.2 Contact: "Franta Vomacka" <sip:[email protected]:5062;transport=udp> P-hint: outbound

- 25 -

Remote-Party-ID: "Franta Vomacka" <sip:[email protected]>;party=calling;idtype=subscriber;privacy=off; screen=yes v=0 o=username 0 0 IN IP4 195.113.134.233 s=The Funky Flow c=IN IP4 195.113.134.233 t=0 0 m=audio 33728 RTP/AVP 0 97 8 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30

Existuje dokument RFC číslo 3655 jménem SIP: Basic Call Flow Examples [29], který se věnuje pouze příkladům průběhu hovorů a tvarům paketů v SIP. Z něj bych uvedl příklad registrace klienta k serveru. Vidíme na něm výměnu čtyř zpráv ve dvou transakcích, které jsou odlišeny sekvenčním číslem CSeq. Komunikace probíhá zabezpečeně, typ URI je sips a v hlavičce Via je uveden transport TLS. Vidíme, že tag přidaný v žádosti ke hlavičce From je v odpovědi zachován a přibyl tag také u To, čímž lze odlišit jednotlivé strany konverzace, i když URI je stejná (což je typické pro požadavky REGISTER). Klient je zřejmě za překladem adres, protože server v odpovědi přidává k hlavičce Via parametr received. Dále je zde vidět kompletní výměna autentizační výzvy a odpovědi a ve finální odpovědi 200 OK potvrzení doby registrace serverem ve hlavičce Contact. Doba je zřejmě výchozí pro daný server, protože klient o žádnou explicitně nepožádal hlavičkou Expires. SIP Server

Bob

REGISTER F1

401 Unauthorized F2

REGISTER F3

200 OK F4

Obrázek 9 - Průběh registrace

- 26 -

F1 REGISTER Bob -> SIP Server REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sips:[email protected]>;tag=a73kszlfl To: Bob <sips:[email protected]> Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sips:[email protected]> Content-Length: 0 F2 401 Unauthorized SIP Server -> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob <sips:[email protected]>;tag=a73kszlfl To: Bob <sips:[email protected]>;tag=1410948204 Call-ID: [email protected] CSeq: 1 REGISTER WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0 F3 REGISTER Bob -> SIP Server REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 Max-Forwards: 70 From: Bob <sips:[email protected]>;tag=ja743ks76zlflH To: Bob <sips:[email protected]> Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sips:[email protected]> Authorization: Digest username="bob", realm="atlanta.example.com" nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sips:ss2.biloxi.example.com", response="dfe56131d1958046689d83306477ecc" Content-Length: 0

- 27 -

F4 200 OK SIP Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201 From: Bob <sips:[email protected]>;tag=ja743ks76zlflH To: Bob <sips:[email protected]>;tag=37GkEhwl6 Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sips:[email protected]>;expires=3600 Content-Length: 0

- 28 -

2.3 IMS (Internet Multimedia Subsystem) 2.3.1 Vlastnosti Síť IMS je globální architektura určená k poskytování různých druhů multimediálních služeb koncovým uživatelům založená na protokolu IP (Internet Protocol) a internetových standardech, nezávislá na přístupové síti [5 kap.1.1]. Vznikla jako reakce na vývoj v oblasti telekomunikací, zvláště postupný odliv zákazníků od klasické pevné telefonní služby k VoIP (Voice over IP) na jedné straně a k mobilním sítím na straně druhé. Ceny pevných telefonních hovorů klesají a konkurence roste. Operátoři proto často poskytují více různých služeb a snaží se hledat nové druhy služeb, které by mohli zákazníkům prodat a zvýšit tak svůj zisk. Bylo by pro ně dobré tyto služby sjednotit, čemuž nahrává trend konvergence, a to jak konvergence sítí, ve kterých převládá protokol IP a rozšiřuje se širokopásmový přistup k Internetu, jak přes pevné, tak i mobilní spojení, tak konvergence zařízení, která stále častěji spojují několik funkcí dohromady. Příkladem jsou chytré telefony, které spojují funkce telefonu, fotoaparátu, přijímače televize, e-mailového klienta a prohlížeče internetu [5 kap.1.2]. Sjednocení přístupu k různým službám a přístup k nim z různých zařízení umožní zlepšit na jedné straně uživatelský komfort, na druhé straně i zisky operátorů, kteří si budou účtovat peníze za služby, o kterých předtím uživatel ani nevěděl, že je potřebuje, nebo si je obstaral zadarmo (např. okamžité posílání zpráv po internetu). IMS vzniklo v rámci standardizační organizace 3GPP, která se zabývá vývojem nových technologií pro mobilní sítě. Původně se objevila v dokumentu Release 5 z roku 2002, kde je definována základní struktura sítě, v Release 6 v roce 2005 byly přidány některé služby a způsoby propojení s telefonními sítěmi. V těchto dokumentech se počítalo zejména s použitím IMS k poskytování multimediálních služeb v sítích GPRS (General Packet Radio Service) / EDGE (Enhanced Data for GSM Evolution) a UMTS (Universal Mobile Telecommunications System). Ve druhém zmiňovaném dokumentu byla přidána podpora WLAN (Wireless Local Area Network). To se nelíbilo organizacím 3GPP2, která specifikaci převzala a přidala podporu pro svou síť CDMA2000 (Code division multiple access 2000), také Cablelabs, která sdružuje operátory sítí kabelové televize, a TISPAN, která se zabývá sítí NGN (Next Generation Network) pro konvergenci pevné a mobilní služby. Naštěstí došlo mezi těmito organizacemi k dohodě a jejich připomínky jsou začleněny do vývoje specifikace IMS

- 29 -

v Release 7 a 8 z let 2007 a 2008. Ty samozřejmě mimo to přináší další služby a rozšíření. [5 kap. 1.4] Jako jeden ze základních protokolů pro IMS byl zvolen SIP (Session Initiation Protocol) z důvodů jeho jednoduchého textového formátu zpráv, který zjednodušuje vývoj aplikací a jejich ladění, jeho obecné povahy, která umožňuje ho použít na navazování různých druhů relací, jeho rozšiřitelnosti o další metody a hlavičky a jeho flexibility ve vytváření různých topologií. V neposlední řadě byl SIP zvolen také proto, že jeho principy jsou vývojářům dobře známé. SIP je podobný HTTP (Hypertext Transfer Protocol) a dalším internetovým standardům a mělo by být snadné přejít z vývoje webových aplikací na aplikace telefonní. Ovšem SIP je původně do značné míry decentralizovaným protokolem, který soustřeďuje většinu inteligence na okraj sítě, do uživatelských terminálů, zatímco centrum sítě má být pokud možno jednoduché a rychlé. Telekomunikační operátoři nemohou ze sítě, kde spolu koncoví uživatelé komunikují přímo, příliš profitovat. Proto se specifikace IMS zaměřuje právě na definování chytrého jádra sítě, které obohatí SIP o nové vlastnosti, jako zabezpečení, zajištění kvality služeb a propojení sítí a umožní poskytovatelům nabízet jejich služby. [30] V zásadě existují 2 pohledy na to, co je IMS. Ve většině materiálů se dozvíme tom, jaké nové služby přinese IMS koncovým uživatelům a jak si je budou moci užívat na různých zařízeních. Druhým pohledem je pohled technický, který mluví o konvergenci sítí a jednoduchosti propojování standardizovaných síťových prvků a celých sítí jednotlivých operátorů mezi sebou. Ač jsou nové služby zajímavé, jako příklady je možno uvést sdílený seznam kontaktů mezi různými službami a zařízeními se zobrazením stavu jednotlivých uživatelů, posílání textových a multimediálních zpráv, konferenční hovory včetně režimu „zmáčkni a mluv“ (PoC, Push to Talk over Cellular), kde jsou jednotlivé hlasové zprávy oddělené v čase, nebo multimediální telefonie a videotelefonie, nebudu se tady jimi zabývat a spíše se pokusím přiblížit technickou stránku věci. Zájemce odkazuji na knihu [5], kde jsou služby popsány poměrně detailně.

2.3.2 Odlišnosti od čistého SIP IMS přidává k SIP tyto vlastnosti: Optimalizace pro bezdrátové sítě – komprese SIP zpráv (SigComp), implicitní registrace více identit, sítí iniciovaná deregistrace a reautentizace. Nové modely autentizace – mechanismus AKA (Authentication and Key Agreement), navázání na autentizaci v síti GPRS nebo jiné přístupové síti, identifikační moduly ISIM (IP Multimedia Services Identity Module) a USIM (Universal Subscriber Identity Module).

- 30 -

Vynucení politiky – slouží k určení, co smí uživatel do sítě vysílat a v jakém objemu, pracuje v součinnosti s mechanismy QoS (Quality of Service). Účtování – typ Online (předplacené služby) a Offline (placené dodatečně); umožnění korelace informací o využívání služeb s přístupovou sítí. Standardizovaná podpora služeb – definované rozhraní k aplikačním serverům a metoda automatického vyvolání služeb (filtrační kritéria). Přenos informací o přístupové síti – přidaná SIP hlavička s identifikátorem přístupové technologie vč. identifikace buňky v mobilních sítích. Definovaná pravidla pro mobilitu a roaming, včetně roamingu mezi IMS a sítí GSM (Groupe Spécial Mobile) – funkce VCC (Voice Call Continuity). Přenos informací o navštívené síti – v případě roamingu se přidává hlavička identifikující navštívenou síť. Soulad s pravidly regulačních orgánů – podpora nouzových volání vč. nalezení nejbližšího kontaktního bodu, přenos čísel, policejní odposlech. Zdroj [5 kap.1.5].

2.3.3 Popis sítě Vrstvy Funkcionalitu IMS je možné rozdělit do tří logických vrstev, a to transportní vrstvy, řídící vrstvy a vrstvy služeb. Transportní vrstva slouží k abstrakci od různých druhů přístupových sítí. Slouží k oddělení světa IMS běžícího na IP protokolu od protokolů ležících pod ním. Spadá do ní například funkcionalita přidělení IP adresy a brány a nalezení vstupního bodu do IMS, tj. P-CSCF (Proxy CSCF, viz. Prvky sítě níže). Funkce této vrstvy se nachází hlavně v konfiguraci přístupových sítí a v prvku P-CSCF. Dále sem může patřit také korelace účtovacích dat mezi přístupovou sítí a IMS a nastavení QoS politik a s tím související prvky. Řídící vrstva se zabývá autentizací uživatelů, směrováním zpráv v rámci sítě i mezi různými sítěmi a řízením provozu mezi transportní vrstvou a vrstvou služeb. Většina provozu zde je založena na protokolu SIP. Hlavními prvky této vrstvy jsou servery CSCF (Call Service Control Function) a databáze účastníků HSS (Home Subscriber Server). Patří sem také služby účtování. Vrstva služeb obsahuje služby sítě IMS, a to jak tradiční služby typu hlasových schránek a hlasových automatů, tak nové služby definované ve standardu IMS a služby, které budou přidávat jednotliví operátoři. Služby zde mají definované rozhraní k uživateli i k dalším prvkům sítě, jako jsou databáze uživatelů a účtovací servery. Takto definovaná architektura sítě umožňuje abstrakci komunikace od přístupové sítě pomocí transportní vrstvy a abstrakci služeb od zbytku sítě řídící vrstvou. Celkově by měla sloužit ke zvýšení konkurence v oblasti

- 31 -

telekomunikačního hardware a software a eliminovat masivní proprietární systémy v těchto oblastech. Zdroj [31].

Obrázek 10 - Vrstvy v IMS [31]

Prvky sítě Norma IMS nedefinuje přesnou implementaci prvků sítě, ale vymezuje funkční oblasti jednotlivých prvků a popisuje komunikaci na referenčních rozhraních mezi nimi. Základem řídící vrstvy IMS jsou 3 SIP servery (logické servery; je samozřejmě možné je umístit na jeden fyzický stroj) jménem CSCF (Call Service Control Function). Každý z nich zodpovídá za jiné aspekty chodu sítě; jsou to P-CSCF (Proxy-CSCF), S-CSCF (Serving-CSCF) a I-CSCF (Interrogating-CSCF). Součástí veřejné sítě by měl být také E-CSCF (Emergency-CSCF) směřující nouzové hovory na nejbližší kontaktní bod. Součástí jádra sítě je také databáze uživatelů HSS (Home Subscriber Server). Dále jsou v síti aplikační servery, funkce zajišťující propojení s jinými sítěmi a funkce politik a účtování, těmi se zde ale nebudu zabývat, protože se ve zkoumaném systému Open IMS Core nevyskytují. P-CSCF má na starost spojení jádra sítě s uživatelskými terminály. Je bodem prvního kontaktu uživatele se sítí při registraci a i poté skrze něj prochází veškerý signalizační provoz. Vytváří bezpečnostní asociace IPSec s uživatelem a autentizuje pro zbytek sítě všechny zprávy obdržené přes toto zabezpečení. Je-li uživatelem podporována komprese SIP zpráv, pak probíhá v tomto bodě. Společně s funkcí PCRF (Policy and Charging Rules Function) a

- 32 -

případně v korelaci s přístupovými sítěmi se stará o dodržení politik operátora ohledně datových toků, nastavení QoS a účtování těchto toků. P-CSCF detekuje nouzové hovory, což je důležité při roamingu (viz. Roaming níže). I-CSCF je vstupním bodem do sítě pro všechny SIP zprávy určené pro účastníky nebo služby sítě, včetně těch mezi dvěma účastníky jedné sítě, kteří mohou například být obsluhování jinými S-CSCF. Jeho úkolem je dotázat se databáze HSS, který S-CSCF obsluhuje daného uživatele. Další funkce je přidělení S-CSCF uživateli v případě registrace nebo pokud se má provést vyvolání služby pro neregistrovaného uživatele (např. hlasové schránky). Zjistí-li adresu serveru (S-CSCF nebo přímo aplikačního serveru), pošle požadavek dál a vyloučí se z cesty dalších zpráv v dialogu. Může také přepisovat zprávy posílané ven ze sítě za účelem skrytí její interní topologie (tato funkce se nazývá THIG, Topology Hiding Internetwork Gateway). S-CSCF je server starající se o uživatele sítě. Zabezpečuje registraci uživatelů, včetně autentizace. Při registraci si stáhne uživatelský profil z HSS, podle kterého provede případně implicitní registrace ostatních identit uživatele (viz. Identifikace uživatele) a nastaví politiku pro uživatele, např. povolené druhy médií, a instaluje jeho služby. Při požadavcích na hovor od uživatele provede vyhledávání pomocí ENUM (E.164 Number Mapping) v DNS (Domain Name System) a určí, zda je cílem IMS nebo jiná síť, a podle toho dále směruje zprávy. Služby jsou v uživatelském profilu popsány pomocí filtračních kritérií (Initial Filter Criteria; „initial“ proto, že pracují nad zprávami zahajujícími dialog). Tato kritéria jsou vyjádřena v XML (Extensible Markup Language) a umožňují filtrovat požadavky podle URI (Universal Resource Identifier), SIP metody, hlaviček, směru požadavku (od uživatele nebo k uživateli), stavu uživatele (registrován/neregistrován) a obsahu SDP (Session Description Protocol). Dále obsahují kritéria adresu aplikačního serveru, kam se má požadavek poslat, vyhodnotí-li se podmínky kladně. Aplikační server se může chovat různě – jako UA (User Agent) může požadavek sám obsloužit (např. hlasová schránka), jako B2BUA (Back to Back User Agent) může ukončit dialog a zahájit nový (nahrávání hovorů), nebo se může chovat jako proxy (a měnit hlavičky) či přesměrovací server (na SIP či třeba HTTP URI). Po zpracování vrátí aplikační server požadavek spirálou (smyčka, která není nekonečná, viz. [4]) k S-CSCF a pokud vedl ve směru od uživatele, pokračuje se ve vyhodnocování filtrů nižších priorit. [5 kap. 3.13]

- 33 -

Obrázek 11 - Aplikační server v režimu proxy [32]

HSS slouží jako centrální úložiště informací o uživatelích. Jsou zde informace o přiřazení veřejných identit k soukromým, informace o stavu registrace uživatele, jeho přístupové údaje, údaje o oprávněních uživatele a politikách a o jeho službách (ve formě filtrů). Jsou zde také informace o preferencích serverů S-CSCF, podle kterých jsou přiřazovány serverem I-CSCF. V případě, že je jako přístupová síť do IMS používáno GPRS/UMTS nebo je požadována schopnost roamingu do sítě GSM, obsahuje databáze HSS také funkce z HLR (Home Location Register) a AuC (Authentication Center) sítě GSM. Je-li v síti více serverů HSS, slouží k nalezení toho správného, obsluhujícího daného uživatele, databáze SLF (Subscriber Location Function). Zdroje [5 kap.2.2, 33].

Rozhraní Rozhraní mezi prvky IMS jsou popsána pomocí tzv. referenčních bodů, identifikovaných (většinou) dvoupísmennými zkratkami. Většina rozhraní používá protokol SIP, ovšem referenční body se liší úrovní zabezpečení. S databázemi se komunikuje protokolem Diameter a některé aplikační servery používají také HTTP. Referenční bod Gm je rozhraní mezi uživatelským zařízením a P-CSCF. Použitý protokol je SIP a všechny SIP zprávy mezi uživatelem a sítí prochází tímto rozhraním. Je na něm použito zabezpečení IPSec (IP Security), případně TLS (Transport Layer Security), zprávy mohou být komprimovány pomocí metody SigComp. Mw je rozhraní mezi jednotlivými servery CSCF. Procházejí jím zprávy SIP při registraci uživatele od P-CSCF k I-CSCF, pak dalším rozhraním Mw k S-CSCF, a odpověď jde také po Mw od S-CSCF k P-CSCF. Podobně samozřejmě prochází sítí zprávy řízení relací od či k účastníkovi sítě i zprávy jednoduchých transakčních služeb (bez ustavení SIP dialogu). Je podrobeno vnitřní bezpečnostní politice sítě (která může také vyžadovat IPSec).

- 34 -

Výjimkou z dvoupísmenných zkratek je ISC (IMS Service Control), které je referenčním bodem mezi S-CSCF a aplikačním serverem. Protokol na tomto rozhraní je SIP a zprávy jsou po něm posílány na základě vyvolání služby filtrem v S-CSCF, nebo mohou být také iniciovány ze strany aplikačního serveru (pro nedostatek lepších nápadů, např. buzení po telefonu). V případě, že služba má být kontaktována uživateli přímo pomocí své identity v IMS, existuje referenční bod Ma mezi I-CSCF a AS (Application Server), který obchází server S-CSCF. Mezi servery CSCF a databází HSS je referenční bod Cx používající protokol Diameter. Toto rozhraní používá I-CSCF při dotazu na přidělení S-CSCF při registraci uživatele a při příchozím SIP požadavku. S-SCSF ho používá na zjištění šifrovacích klíčů při autentizaci uživatele a stahuje a upravuje po něm uživatelské profily a informace o službách. Pokud je v síti více serverů HSS, používá I-CSCF rozhraní Dx, také s protokolem Diameter, na komunikaci se SLF. Aplikační servery mohou potřebovat stahovat a ukládat informace v uživatelských profilech v HSS. K tomu slouží referenční bod Sh mezi AS a HSS a Dh mezi AS a SLF, taktéž s protokolem Diameter. Protokol Diameter je popsán v RFC 3589 a je nástupcem protokolu RADIUS (Remote Authentication Dial-In User Service) pro centralizovanou autentizaci, autorizaci a účtování. Oproti němu umožňuje použití spolehlivých transportních protokolů (ne jen UDP (User Datagram Protocol)), má zabezpečení přenosu zpráv (TLS nebo IPSec), větší adresní prostor druhů přenášených zpráv, podporuje IP mobilitu, spolehlivý přenos na nespolehlivém protokolu UDP a notifikaci o chybových stavech. Protokol je rozšiřitelný o nové definice druhů zpráv a hodnot (AVP, Attribute-Value Pair), čehož 3GPP v IMS hojně využívá. [5 kap.11.5.5, 34] Zdroj [5 kap.2.3].

Identifikace uživatele V IMS se obecně řečeno používají SIP URI, případně tel: URI, stejně jako v SIP, ovšem IMS nad nimi definuje několik různých druhů takzvaných identit. Nejdůležitějším typem identity je veřejná identita, která se používá při požadavcích na spojení s jinými uživateli a dá se udávat jako kontaktní údaj. Veřejných identit může mít uživatel více, nejméně však jednu; každý uživatel by měl mít alespoň jednu identitu ve tvaru SIP URI a jednu tel: URI, aby byl dostupný z ostatních telefonních sítí. Veřejná identita může být registrována i na více uživatelských terminálech současně, jeden terminál může mít více veřejných identit. Na veřejnou identitu je navázán profil uživatelových služeb. Privátní uživatelská identita slouží pro vnitřní potřeby sítě a nepoužívá se pro hovory a zprávy. Uživatel ji může vidět nejvýše na výpisech hovorů a účtech za služby. Nejdůležitější je však její role jako identifikátoru pro registraci do sítě. Při registraci se posílá právě tato identita (případně se seznamem veřejných identit, ty se ale mohou doplnit v S-CSCF metodou

- 35 -

implicitní registrace). Privátní identita je svázána s jednou a více veřejnými identitami. Privátní identita je také svázána s ISIM (IP Multimedia Services Identity Module) kartou a tudíž s uživatelským zařízením, do kterého je karta vložena. Uživatel má tolik privátních identit, kolik současně používá IMS zařízení. Nemá-li uživatel specielní kartu ISIM pro IMS, ale kartu USIM (Universal Subscriber Identity Module) používanou v síti UMTS před nástupem IMS, generuje se mu dočasná privátní identita z čísla IMSI (International Mobile Subscriber Identity). Na rozdíl od USIM je na ISIM uložena identifikace domácí sítě IMS a veřejné identity. Síť lze ale vyčíst z IMSI a identity může přidělit S-CSCF implicitně. Autentizační mechanismy jsou v obou případech stejné.

Obrázek 12 - Vztahy identit v IMS [5]

Pro případ, kdy uživatel má více zařízení, ale každé má jiné schopnosti, případně kvůli možnosti přepojení hovoru z jednoho uživatelského zařízení uživatele na jiné, existuje identifikátor GRUU (Globally Routable User-agent URI). Jsou dva druhy těchto identifikátorů, dočasný a veřejný. Dočasný GRUU se používá pro interní potřeby IMS a jeho životnost je omezena dobou registrace. Naproti tomu veřejný GRUU je pevně spojený se zařízením a jednou veřejnou identitou (tím se liší od privátní identity) a je viditelný navenek. Použití je například takové, že při registraci sdělí uživatelská zařízení S-SCSF své schopnosti (pomocí rozšíření SIP hlaviček) a příchozí například video hovory budou směrovány přednostně na zařízení podporující video. Dále ještě v IMS existují identity služeb, které se nespouští přes filtry v S-CSCF. Tyto identity se mohou vytvářet dynamicky a nepotřebují registraci – například uživatel může vytvořit textovou či hlasovou konferenci (PoC, Push to Talk over Cellular), která pak obdrží po čas své existence veřejnou identitu služby. Také SIP prvky sítě mají svoji interní identifikaci pro případ, že by měly jako UE ukončovat SIP zprávy. Zdroje [5 kap. 3.5, 32].

Autentizace, zabezpečení a komprese V IMS se alespoň pro mobilní zařízení počítá s použitím aplikace ISIM nahrané na kartě UICC (Universal Integrated Circuit Card) vložené do

- 36 -

mobilního telefonu. Karta může obsahovat i další aplikace jako SIM a USIM pro přístup ke GSM a UMTS. Tato karta bude dodána operátorem sítě a bude obsahovat informace jako privátní identita uživatele a případně jedna a více veřejných identit, doménové jméno domácí sítě, adresa P-CSCF pro případ, že přístupová síť nemá vlastní, případný kód pro zabezpečení přístupu ke kartě a bezpečnostní parametry pro autentizaci uživatele. [5 kap. 3.6] K vlastní autentizaci se v IMS používá kryptografická metoda AKA (Authentication and Key Agreement) vyvinutá v rámci 3GPP a používaná také v síti UMTS. Tato metoda je založena na sdíleném klíči (K) bezpečně uloženém v kartě UICC a v databázi HSS, společně s algoritmy, které ho používají, takže klíč K nikdy tato dvě místa neopustí. Algoritmy nad klíčem pracující norma pro AKA (RFC 3310 [36]) nepopisuje, řetězec „AKAv1MD5“, který dává tušit, že se bude používat hash funkce MD5, ovšem není v normě uveden jako konstanta, je umožněno používat i jiné funkce. V dokumentu [37] z dílny 3GPP, na který [36] odkazuje, je vidět schéma odvozování hodnot z klíče a náhodného čísla na kartě USIM, ovšem použité funkce pod názvy f1..f5 jsou zde popsány pouze jako funkce typu MAC (Message Authentication Code), kde hodnota jedné nejde odvodit z hodnoty druhé. Jsou zde ale specifikovány délky všech výstupních klíčů na 128 bitů. [5 kap.3.21.2.2] Ze zdrojových kódů programů použitých později v této práci se dá tušit, že šifrovací algoritmus 3GPP se jmenuje „MILENAGE“, internetové hledání tohoto názvu ale nedává žádné relevantní výsledky. Autentizační výměna je mapována do SIP hlavičky „Authorization: Digest“ s parametrem „algorithm=AKAv1-MD5“. Výměna probíhá tak, že uživatelské zařízení v prvotním požadavku REGISTER pošle hlavičku „Authorization“ a v parametru „username=“ uvede privátní identitu uživatele, v parametru „realm=“ pak doménu své domácí sítě. Tento požadavek dostane S-CSCF, který se zeptá HSS na autentizační data pro danou privátní identitu. HSS vygeneruje náhodné číslo (RAND) a síťový autentizační token (AUTN) a s pomocí tajného klíče K spočítá očekávanou odpověď na výzvu (XRES) a klíče pro důvěrnost a integritu (CK a IK). Tato čísla předá S-CSCF, který si vezme číslo XRES a ostatní vloží do SIP odpovědi 401 Unauthorized a pošle na P-CSCF. Ten si ze zprávy vezme CK a IK, která bude používat pro IPSec a bez těchto čísel, tedy již jen s RAND a AUTN, obě mapovaná do parametru „nonce=“, odešle odpověď na UE. Pomocí tokenu AUTN ověří UE identitu své domácí sítě – AUTN je číslo, které sleduje pseudonáhodnou posloupnost odvíjející se od klíče K a sekvenčního čísla (SEQ) a musí být na UICC i v HSS stejné, plus minus několik kroků. Dále spočítá UE stejná čísla, jako dříve HSS, tedy odpověď (RES) a klíče CK a IK. Pomocí těch naváže bezpečnostní asociaci IPSec s P-CSCF a po ní pošle druhý požadavek REGISTER s odpovědi na kryptografickou výzvu do sítě.

- 37 -

P-CSCF potvrdí parametrem „integrity-protected="yes"“, že zprávu obdržel zabezpečeně a S-CSCF ověří rovnost čísel XRES a RES, načež odpoví UE zprávou 200 OK. [5 kap.11.6] IMS ve verzi Release 8 uvolnil požadavky na zabezpečení a podporuje také metodu vyjednání podporovaných algoritmů autentizace a šifrování „sec-agree“ z RFC 3329. Pokud to bude síť podporovat, bude možné použít i jiné standardy, jako originální HTTP Digest a TLS. [5 kap.11.8] Zabezpečení přístupu k IMS je, jak již bylo zmíněno, řešeno pomocí IPSec ESP (Encapsulation Security Payload), ovšem výměna klíčů je řešena poněkud nestandardně součinností s autentizačním mechanismem AKA, takže se tato zabezpečovací metoda označuje často jako 3GPP IPSec. K němu je ještě nutno dodat, že nezabezpečuje veškerý provoz mezi UE a sítí, nýbrž jenom provoz signalizační. Vytváří se dva páry bezpečnostních asociací – mezi zabezpečeným klientským portem UE a zabezpečeným serverovým portem P-CSCF, a druhá mezi klientským portem P-CSCF a serverovým portem UE. Tyto porty jsou různé od standardního portu 5060, na kterém jsou přijímány nezabezpečené SIP zprávy při úvodní registraci a jsou ve zprávách uváděny ve všech relevantních hlavičkách jako Contact, Via a Route. SIP zprávy putují po protokolu UDP výhradně od klientského portu jedné strany k serverovému portu druhé, a to včetně zpráv typu odpověď. Po TCP (Transmission Control Protocol) tímto směrem jdou pouze žádosti, odpovědi mohou po sestaveném spojení procházet i „proti” směru. TCP by se běžně mělo používat pro zprávy větší, než je kapacita nesegmentovaného UDP datagramu. Čísla portů si UE a P-CSCF vymění v SIP zprávách v hlavičkách Security-Client a Security-Server z rozšíření „sec-agree“, stejně jako druhy podporovaných šifrovacích schémat. Povinná je kryptografická ochrana integrity, která se okamžitě použije na validaci proběhlé výměny parametrů – výměna se zopakuje ještě jednou v druhém požadavku REGISTER a odpovědi 200 OK. Šifrování obsahu zpráv je nepovinné. [5 kap.3.21.4, 5 kap.11.7] V IMS je vyřešeno i zabezpečení provozu v jádru sítě, což je vlastnost, která například v síti GSM chyběla. Tato vlastnost se nazývá NDS (Network Domain Security) a pracuje se zde s pojmem bezpečnostních domén. Doména může zahrnovat celou síť operátora, nebo její část. Různí operátoři ale budou mít různé domény. Mezi prvky ve stejné doméně se definuje rozhraní Zb, mezi různými doménami pak Za. Na okraji bezpečnostní domény může být specializované zařízení typu bezpečnostní brána (SEG, Security Gateway) realizující rozhraní Za. Mechanismus stojící za NDS je pak klasický IPSec, bezpečnostní asociace pro něj jsou vytvářeny standardně přes protokol IKE (IPSec Key Exchange), autentizace protistrany se může řešit předsdíleným klíčem, výměnou certifikátů nebo přes certifikační autority systému PKI (Public Key Infrastructure). Na

- 38 -

obou typech rozhraní je povinná ochrana integrity, na rozhraní mezi doménami je doporučené i šifrování. [5 kap.3.21.3] Existuje ještě jeden parametr, který se dojednává při registraci uživatele do IMS, a tím je komprese. Protože textový formát SIP zpráv je vzhledem k binárnímu kódování signalizačních informací neúsporný a v 3GPP vznikla obava, aby velké zprávy nezpůsobovaly na úzkopásmových mobilních linkách přerušování hovorů nebo příliš dlouhé prodlevy při sestavování hovorů, rozhodli se požadovat na rozhraní Gm v IMS použití kompresního mechanismu SigComp z RFC 3320. Samotný SigComp není přímo kompresní metoda (používá se Deflate), ale rámec pro detekci komprimovaných zpráv, předávání zpráv komprimátorům a dekomprimatorům a hlavně uchování stavu kompresního slovníku po dobu relace, což výrazně vylepšuje dlouhodobý kompresní poměr. Relací jsou zde myšleny všechny zprávy z jedné adresy, mezi UE a P-CSCF by tedy měl být jeden dlouhodobě uložený stav kompresního algoritmu. [5 kap.3.18] Stav se ovšem začíná ukládat až po navázání bezpečnostních asociací, aby se zabránilo útoku DoS (Denial of Service) na P-CSCF zaplněním jeho paměti stavy komprimátoru. Způsob dojednání použití SigComp je popsán v RFC 3486. Spočívá v přidání parametru „comp=SigComp“ do hlaviček Contact a Via při registraci a v každém dalším dialogu. Pošle-li UE registrační požadavek s tímto parametrem, dostane již odpověď komprimovaně. [5 kap.11.10] Nutno konstatovat, že všechny tyto vlastnosti IMS (šifrování, komprese, alternativní porty) z větší části negují kladné vlastnosti SIP ve oblastech snadné zachytitelnosti, čitelnosti a laditelnosti.

QoS a politiky Síť IMS je primárně sítí pro poskytování služeb, proto zavádí QoS, aby mohla garantovat jejich vysokou kvalitu, a zároveň systém politik, aby uživatelé nemohli komunikovat bez využití služeb sítě a placení za ně. O zajištění QoS se stará P-CSCF v součinnosti s prvky různých přístupových sítí (se standardizovaným rozhraním PCEF (Policy and Charging Enforcement Point)) a funkčním blokem PCRF (Policy and Charging Rules Function). Podle informací z výměny SDP (Session Description Protocol) o portech a kodecích zachycené P-CSCF se nastavují hodnoty DSCP (Differentiated Services Code Point) v hlavičce IP, zakládají PDP (Packet Data Protocol) kontexty v GPRS a nastavují třídy QoS v UMTS. Zároveň je zajištěno, že uživatel nebude posílat více dat, než odpovídá kodeku, jehož použití deklaroval, a nebude vysílat žádné neschválené datové toky. Důležitá funkce P-CSCF je sítí iniciované ukončení relace, pokud ustanou datové toky od uživatele bez předchozí zprávy BYE (například ztratí-li mobilní stanice signál). [5 kap. 3.10] Právě kvůli restriktivní politice, která otevírá porty pro datové toky až po dekódování obsahu SDP a možnosti, že nastavení QoS v některých

- 39 -

přístupových sítích zabere nějaký čas, se v IMS zavedl mechanismus podmínek (preconditions) v SDP. Tento mechanismus je definován v RFC 3312 a spočívá v přidání SDP atributů „a=curr:qos“ a „a=des:qos“, kterými jedna strana dialogu signalizuje druhé současný stav nastavení QoS na své straně a své vědomosti o nastavení druhé strany (current), a žádaný finální stav (desired). [5 kap.12.6.3] Podstatná změna od klasického SIP je v tom, že tento mechanismus vyžaduje 2 výměny SDP a tudíž čtyřcestnou výměnu při navazování relace. První výměna proběhne ve zprávách INVITE a 183 Session Progress. V této výměně dojde klasicky k dojednání parametrů spojení mezi uživateli, ale je indikováno, že podmínky QoS pro zahájení relace nejsou splněny. Z této výměny se síťové prvky mezi uživateli dozví o parametrech relace a povolí příslušné datové toky. Druhá výměna, ve které je indikováno splnění podmínek a po které následuje zahájení hovoru, se posílá ve zprávách PRACK a 200 OK. [5 kap.12.6.3] Metoda PRACK je součástí rozšíření SIP „100rel“ definovaném v RFC 3262. Jejím účelem je spolehlivé doporučení zpráv typu provizorní odpověď (kódy 100-199). Spolehlivé doručování těchto zpráv je v IMS nutné právě z toho důvodu, že obsahují v těle zprávy SDP výměnu. Rozšíření „preconditions“ a „100rel“ se tudíž dobře doplňují. Ve zprávách s tímto rozšířením se objevují nové hlavičky RSeq se sekvenčním číslem SIP odpovědi a RAck, opakující toto sekvenční číslo i obsah hlavičky CSeq původního požadavku, což umožňují identifikovat, ke které transakci se PRACK vztahuje. [5 kap.12.5.2]

Roaming a průběh hovoru O průběhu registrace UE do sítě jsem se sice nezmiňoval přímo, ale ze všech předchozích kapitol by měl čtenář mít dostatečný přehled o jejím průběhu a rolích jednotlivých prvků. Zajímavý je ale také mechanismus, jakým klient při připojení do sítě zjišťuje, kam má registrační požadavek posílat. Jeho význam vyplyne při popisu roamingu. Na zjištění adresy P-CSCF existují dva automatické postupy. Jeden je specifický pro GPRS a vyžaduje inovovaný formát požadavku na otevření PDP kontextu a součinnost GGSN (Gateway GPRS Support Node). Druhý postup je univerzální a nezávislý na přístupové síti. Spočívá v použití protokolu DHCPv6 (Dynamic Host Configuration Protocol version 6) s rozšířením RFC 3319 [38] popisujícím volbu (DHCP Option) pro přidělení odchozího SIP serveru. Tímto mechanismem získá klient jméno domény, ve které se nachází. Dále pomocí DNS vyhledá NAPTR (Naming Authority Pointer) záznam [39, 40] této domény, z něho si vybere službu SIP po UDP nebo TCP dle priority a pro tu vyhledá SRV (Service Record) záznam v DNS. Pak ještě na výsledek SRV dotazu provede dotaz AAAA a získá IPv6 adresu nejbližšího P-CSCF serveru. Výměnu ukazuje Obr. 13. [5 kap.3.8, 5 kap.11.4]

- 40 -

Obrázek 13 - Vyhledání P-CSCF [5]

Tento mechanismus úzce souvisí se dvěma druhy roamingu v IMS, které naznačuje Obr.14. Na obou částech obrázku vidíme vlevo uživatele navštěvujícího cizí síť s otevřenou relací do nějaké další sítě vpravo. Podmínkou pro roaming na bázi IMS je dostupnost IP konektivity, a to nejlépe IP verze 6, ačkoli je možné použít v přístupové síti IPv4 a v domácí síti provést překlad protokolů metodou NAT-PT (Network Address Translation – Protocol Translation), nebo tunelování IP v IP pomocí ISATAP (Intra-Site Automatic Tunnel Addressing Protocol). V případě IPv4 přístupové sítě však není možné použít popsanou druhou metodu zjištění P-CSCF, protože ta vyžaduje DHCPv6, a zbývá metoda první, specifická pro moderní nasazení GPRS podle 3GPP Release 5, nebo ruční konfigurace. [5 kap.3.22.8] Dále se situace liší podle toho, zda navštívená síť obsahuje subsystém IMS nebo nikoli. Při připojení do sítě se UE pokusí použít některou z popsaných metod zjištění adresy P-CSCF, pokud uspěje, připojí se k místnímu P-CSCF, který bude zajišťovat přístupové zabezpečení, QoS a politiky datových toků a signalizaci bude přeposílat do uživatelovy domácí sítě specifikované v registračním požadavku se zabezpečením podle NDS (Network Domain Security). Druhou možností je, že vyhledání P-CSCF selže a UE se připojí k serveru ve své domácí síti, který má uložen v ISIM nebo nakonfigurován ručně.

- 41 -

Navštívená síť pak poskytuje a účtuje pouze datové služby a o IMS nemusí nic vědět. Nevýhodou tohoto řešení je, jak je vidět z obrázku, že jelikož veškerý IMS provoz uživatele, včetně multimediálních proudů, musí (hlavně z důvodů politiky a účtování) procházet přes P-CSCF, a ten je v domácí síti, dochází zde k takzvanému trojúhelníkovému směrování, které zbytečně prodlužuje trasu paketů a tím i zpoždění. Také nedojde ke správnému nastavení QoS a hovorová informace může dostat stejnou prioritu, jako ostatní datový provoz. [5 kap. 2.1.2.] Určitě je také možné využít při roamingu služeb s přepojováním okruhů v GSM nebo UMTS. Zajímavou funkcí je VCC (Voice Call Continuity), která umožňuje roaming mezi mobilními technologiemi okruhového a paketového charakteru (například mezi WLAN a GSM) v rámci jedné sítě bez přerušení hovoru. [5 kap. 3.20]

Obrázek 14 - Druhy roamingu v IMS [5]

Na Obr. 15 vidíme obvyklý průběh navázání hovoru v IMS. Situace je taková, že oba uživatelé využívají roaming, vlevo je to roaming na úrovni IMS, vpravo na úrovni IP, jak je vidět z hlavičky grafu. Sítové prvky, kterými zprávy procházejí, jsou po řadě P-CSCF obsluhující volajícího uživatele, který zajišťuje přístupové zabezpečení, kompresi, QoS a účtování datových toků. I-CSCF volajícího uživatele není nutné kontaktovat, protože po registraci uživatel již zná svůj S-CSCF (Podle hlavičky ServiceRoute z RFC 3608. [5 kap. 11.5]) a vkládá jeho adresu do hlavičky Route, kterou se bude řídit P-CSCF. Dále tedy obdrží zprávu S-CSCF v domácí síti volajících uživatele, který případně podle filtračních kritérií pošle požadavek aplikačnímu serveru, odkud by se vrátil spirálou zpět. S-CSCF podle veřejné identity volaného uživatele

- 42 -

uvedené v požadavku INVITE zjistí jeho doménu a pomocí NAPTR (je-li to tel: URI, tak s pomocí jeho varianty ENUM), SRV a AAAA dotazů na DNS vyhledá I-CSCF této domény. I-CSCF v domácí síti volaného uživatele zkonzultuje HSS (přesněji SLF) a pošle požadavek na S-CSCF obsluhující tohoto uživatele. Na rozdíl od ostatních serverů nepřidá svou adresu do hlavičky Record-Route, ale dle normy pro SIP nesmí vynechat zápis do hlavičky Via. To způsobí, jak je z grafu vidět, že přes něj neprochází další požadavky v dialogu a odpovědi na ně, ale projdou přes něj provizorní a finální odpovědi vztahující se k původnímu INVITE. Dále požadavek obdrží server S-CSCF v domácí síti volaného uživatele, který spustí filtrační kritéria a podle profilu uživatele zjistí jeho server P-CSCF. Ten provede své obvyklé funkce a doručí požadavek uživateli.

Obrázek 15 - Sestavení hovoru v IMS [5]

Co se týče vyměňovaných zpráv, vidíme zde požadavek INVITE se SDP popisem relace, provizorní odpověď 100 Trying posílanou mezi každými dvěma proxy servery a provizorní odpověď 183 Session Progress od UA, nesoucí navíc SDP odpověď.

- 43 -

Přijetí SDP odpovědi se potvrzuje požadavkem PRACK a následuje odpověd na něj 200 OK. Na rozdíl od dříve popsané čtyřcestné výměny v tomto přikladu ještě navázání spojení nekončí, protože v době odeslání PRACK nebyla dokončena rezervace kapacity pro datový tok. V pevné síti by druhá SDP výměna proběhla už zde. V mobilní síti proběhne v požadavku UPDATE a odpovědi na něj 200 OK. (UPDATE je definován v RFC3311 a slouží ke změně parametrů dojednávané relace před jejím sestavením. [19]) Teprve při přijetí požadavku UPDATE s potvrzením nastavení QoS začne UE zvonit a odešle 180 Ringing. Uživatel telefon zvedne, což způsobí zaslání 200 OK, jeho potvrzení metodou ACK a navázání hovoru.

2.3.4 Platforma Open IMS Core Open IMS Core je zřejmě v současné době jedinou funkční volně dostupnou implementací jádra IMS sítě. Vznikla jako výzkumný projekt v německém výzkumném ústavu Fraunhofer FOKUS a má sloužit hlavně jako platforma pro vývoj a testování aplikací a aplikačních serverů pro sítě nové generace. Je k dispozici pod licencí GPL (General Public License). Na stránce projektu [41] je explicitně uvedeno, že není záměrem vytvořit komerčně využitelný produkt, a že části specifikace IMS mohou podléhat patentům či licencím třetích stran. Na stránce s citacemi uživatelů je dokonce názor, že systém nelze nechat běžet bez dozoru ani v laboratorních podmínkách. Projekt implementuje SIP servery P-CSCF, S-CSCF a I-CSCF (Proxy, Serving a Interrogating Call Service Control Function), a to pomocí upraveného software SER (SIP Express Router, rovněž z dílny Fraunhofer FOKUS), ke kterému je připsána komponenta C Diameter Peer pro komunikaci protokolem Diameter. Na stránce s novinkami je zpráva, že do projektu přibyla i funkce E-CSCF (Emergency CSCF) pro nouzové hovory. Zvláštní část projektu tvoří rozhraní pro aplikační servery (ISC, IMS Service Control) u S-CSCF. Dále je zde server HSS (Home Subscriber Server) implementovaný v jazyce Java jménem FHoSS. Jeho součástí je znovupoužitelná komponenta Java Diameter Peer. Uživatelské profily a některé informace o konfiguraci sítě se ukládají pomocí knihovny Hibernate v databázi MySQL. Pomocí Apache Tomcat je také vytvářeno webové rozhraní pro editaci těchto údajů. Ze zabezpečovacích prvků podporují CSCF servery jak IPSec (Internet Protocol Security), tak TLS (Transport Layer Security). Problém s podporou zabezpečení je spíše ze strany VoIP klientů a testovacích balíků, viz. níže. Administrátor si může při vytváření uživatelských profilů, které lze provádět přes webové rozhraní, ručně v databázi, nebo unixovým skriptem zapisujícím do databáze, vybrat z několika možných autentizačních protokolů, včetně nativního AKA (Authentication and Key Agreement). Je možné použít i HTTP Digest pro kompatibilitu s čistými SIP klienty.

- 44 -

Projekt nemá žádná čísla verzí, proto se zdá, že je v rané fázi vývoje. Z toho důvodu také neexistují jednoduše instalovatelné softwarové balíky, a hlavním způsobem instalace je stažení vývojové větve softwaru ze systému Subversion. Na vyzkoušení je nabízen i obraz virtuálního počítače s nainstalovaným Open IMS Core. Pohledem do Subversion archivu zjistíme, že projekt není příliš aktivní. Poslední změna FHoSS pochází z roku 2009, na SER ale stále vývoj probíhá. Obraz virtuálního počítače je z roku 2008. Na katedře Telekomunikační techniky mám k dispozici testovací server s instalací Open IMS Core z listopadu 2010. Okolo začátku roku 2011 se zřejmě obnovil zájem o otevřenou implementaci IMS a to v projektu SIP serveru Kamailio, na který podle [42] byly přeneseny části kódu z Open IMS Core. V souvislosti s tímto projektem by zřejmě měl vzniknout i server HSS v jazyce C. Kamailio, dříve zvané OpenSER, je odštěpenou větví projektu SER; podle zpráv na webové stránce projektu [43] došlo k opětovnému sloučení obou projektů a vývoj bude probíhat jen v jedné větvi. Dokumentace k projektu Open IMS Core je velmi sporá. Sestává se z instalačního návodu popisujícího poměrně přehledně instalaci a konfiguraci od stažení zdrojového kódu po nastavení uživatelských účtů. Také obsahuje poznámku o správném nastavení DNS. Dále je zde již jen stránka častých dotazů a komentáře ke zdrojovému kódu. Projekt má e-mailovou diskusní skupinu.

Obrázek 16 - Komponenty Open IMS Core [41]

- 45 -

3 Měření propustnosti VoIP 3.1 Teoreticky Teoreticky řeší problém zátěže telefonní ústředny obor Teorie hromadné obsluhy (Queueing theory). Je to obor založený na začátku 20. století dánským matematikem A.K.Erlangem právě ke studiu telefonních systémů, ale má aplikace například i v dopravním inženýrství, výpočetní technice nebo průmyslovém plánování (dimenzování továren, bankovních poboček). [57] Ústředním pojmem Teorie hromadné obsluhy je obsluhový systém. Ten se skládá z jedné či více obsluhových linek, které obsluhují žádosti, dále nepovinné paměti, ve které mohou požadavky na obsluhu čekat ve frontě a řízení, které rozřazuje příchozí požadavky do front a z nich pak k obsluhovým linkám. Požadavky vstupující do systému a žádající obsluhu tvoří vstupní tok, uspokojené požadavky pak výstupní tok. Alternativní názvy jsou tok nabízený systémem pro výstup a tok žádaný pro vstup. Požadavky, které z nějakého důvodu nebyly uspokojeny, tvoří odstupující tok. Důvody odstoupení mohou být například obsazenost všech obsluhových linek u systému bez front, u systému s frontami pak přeplnění těchto front nebo nadměrná doba čekání na obsluhu.

Obrázek 17 - Obslužný systém [58]

Na vstupní tok jsou kladeny tři požadavky: [57, 58] Stacionárnost – charakter vstupního toku se s časem nemění a popisovaný systém se po čase dostane do stavu statistické rovnováhy. Ordinárnost – v daném okamžiku se nevyskytne více než jedna žádost. Tok je popisován z hlediska intervalu mezi příchody žádostí. Nezávislost – příchody požadavků a doby obsluhy jsou statisticky nezávislé. Základním parametrem obsluhového systému je míra uspokojení požadavků, kterou lze vyjádřit v procentech, případně její kvalita (např. doba

- 46 -

čekání ve frontě). Kvantitativní veličiny jsou Objem provozního zatížení, vyjadřovaný v počtu požadavků za jednotku času a Intenzita provozního zatížení, což je objem zpracovaný jednou stále vytíženou obsluhovou linkou za hodinu. Jednotka intenzity je 1 erlang [erl]. [58] Teorie hromadné obsluhy staví silně na statistice, a podle statistických rozložení příchodu zpráv, doby obsluhy a počtu linek se obsluhové systémy také klasifikují. Tuto klasifikaci a její zkrácený zápis navrhl D.G.Kendall. Zápis spočívá v trojici A/B/n, kde A je statistické rozložení příchodu požadavků, B je rozložení doby obsluhy a n počet obslužných linek. Existuje i verze notace se čtyřmi údaji, kde poslední údaj značí délku fronty. Obvyklá statistická rozložení mají přidělena písmena, a to D – deterministické (konstantní), M – Markovovské (Poissonův proces příchodu a exponenciální rozložení), G – obecné (general), GI – obecné a nezávislé (independent), EK – Erlangovo s parametrem K, KN – Χ2. [59, 60] Obslužné systémy je možné dělit podle různých dalších parametrů, například zda je systém deterministický či stochastický, zda se v něm vyskytuje jeden či více druhů požadavku na obsluhu, zda je intenzita vstupu konstantní či proměnlivá (v obecných případech), zda obsahuje či neobsahuje frontu či fronty a jaká jsou pravidla jejich použití, a podle pravidel pro odstup požadavků – kdy žádost ze systému odstoupí a zda a kdy se do systému vrátí. [59, 61] K popisu příchodu požadavků do obslužného systému se při simulaci nebo analytickém řešení nejčastěji využívá takzvaný Poissonův proces, který popisuje příchody požadavků vycházejících z bezpaměťového (memoryless) procesu. Je to stochastický model, který dobře popisuje situace z reálného života a zároveň je analyticky řešitelný. Systém založený na Poissonově procesu vypadá tak, že požadavky generuje nějaký zdroj či zdroje, a to tak, že doba mezi požadavky je náhodná a sleduje exponenciální rozložení. Bezpaměťovost tohoto zdroje znamená, že pravděpodobnost, že vyšle další požadavek, není nijak závislá na době od minulého požadavku nebo na počtu požadavků v minulosti. Objem toku požadavků lze regulovat změnami parametrů generujícího exponenciálního rozložení. Jsou-li požadavky na generování vstupního toku splněny, může pozorovatel u vstupu do obslužného systému pozorovat tok, jehož počet požadavků za jednotku času sleduje Poissonovo rozložení. Dobu mezi hovory na vstupu obslužného systému, který zatěžuje více generátorů zátěže s exponenciálním rozložením, popisuje Erlangovo rozložení. [57 a odkazy] Při aplikaci teorie hromadné obsluhy na problém měření SIP (Session Initiation Protocol) serveru se používá model M/G/1 s Poissonovým procesem příchodu a jednou obsluhovou linkou s obecnou dobou obsluhy [62]. Čistě technicky by se dalo číslo 1 nahradit počtem procesorů nebo SIP serverů v testovaném systému, nebo prohlásit počet současně zpracovávaných žádostí

- 47 -

za nekonečný, kategorie systému by pak byla M/G/1-PS (Processor Sharing) [60], ale tyto modely by se zřejmě nehodily k analytickému řešení. Faktem je, že reálný SIP server bude schopen zpracovávat několik žádostí současně a dá se očekávat, že doba obsluhy bude do naplnění tohoto počtu nízká, nejspíše s normálním rozložením. Po dosažení tohoto počtu začnou být zprávy zachycovány (buffered) operačním systémem a se zvyšujícím se množstvím požadavků lineárně poroste střední doba odpovědi. Při naplnění kapacity procesoru nebo paměti serveru pak začne odezva na zprávy růst exponenciálně. Kritická hodnota odezvy je taková, při které začne přibývat opakovaných požadavků (retransmisí), které v názvosloví teorie hromadné obsluhy představují odstupující tok vracející se zpět do systému. Odstupující požadavky jsou v protokolu SIP takové, které čekají na obsluhu více než mezní hodnota časovače T1 (u SIP 500 ms, v IMS (Internet Multimedia Subsystem) 2 s). SIP požadavky se do systému několikrát se vzrůstající periodou vracejí (viz. standard [4]), což způsobí finální zahlcení kapacity testovaného SIP serveru.

- 48 -

3.2 Sledované veličiny Měřené veličiny v technologii SIP (Session Initiation Protocol) se dají rozdělit do dvou základních kategorií, a to kvalitativní a výkonnostní. Kvalitativní veličiny ovlivňují, jak bude uživatel se službou spokojen, například dobu, za kterou se mu spojí hovor (nemluvíme zde o zpoždění datových toků RTP (Real-time Transport Protocol), ale signalizace SIP). Výkonnostní charakteristikou je například počet hovorů za jednotku času, které dokáže zvládnout SIP server. Oba druhy charakteristik jsou spolu provázány – strop výkonnostní charakteristiky je často určen bodem, kde byla překročena norma na charakteristiku kvalitativní.

3.2.1 Kvalitativní Nejdůležitější kvalitativní charakteristiky měřitelné na technologii SIP shrnuje standard RFC 6076 [63]. Vzhledem k tomu, že tyto charakteristiky jsou založené na měření časových intervalů, s okamžiky začátku a konce (v normě označovanými t1 a t4) v některých případech měřenými na různých síťových prvcích, vyžaduje norma použití nějaké formy synchronizace času a doporučuje pro ni přesnost na 1 ms. Časové okamžiky jsou měřené od prvního bitu vyslané zprávy do posledního bitu přijaté odpovědi. Případné retransmise se do délky intervalu započítávají také. Naměřené hodnoty jsou ovlivněny faktory, jako je výkon SIP serveru, klientů, síťových prvků mezi nimi atd. Všechny tyto skutečnosti by měly být uvedené v zprávě o měření. Ke sběru metrik je možno přistupovat jak formou syntetického testu, tak je možno je sbírat za normálního provozu sítě např. modulem zapisujícím časy SIP zpráv v SIP serveru nebo síťovým analyzátorem. V tom případě je vhodné sebraná čísla rozlišovat dle situace – např. podle uživatele, přístupové sítě nebo denní doby. Zavedené metriky jsou: Registration Request Delay (RRD) je doba reakce na požadavek k registraci. Měří se od prvního požadavku REGISTER do odpovědi 200 OK, zahrnuje tedy i výměnu autentizačních zpráv a její trvání může tedy ovlivnit volba autentizačního algoritmu. Míra neúspěšných registrací (Ineffective Registration Attempts (IRA)) způsobených vypršením časovače retransmisí (v [4] označen Timer F), nebo chybovou odpovědí serveru se měří v procentech z celkového počtu pokusů. Session Request Delay (SRD) je doba reakce na žádost o novou relaci. Měří se mezi odesláním INVITE a první odpovědí jinou, než 100 Trying nebo přesměrování (3xx), tedy první odpovědí od cílového systému nebo chybou. Výsledky měření je nutné dělit na úspěšné a

- 49 -

neúspěšné případy navázání relace, protože se průběh jejich zpracování může výrazně lišit. Míra úspěšných pokusů o navázání relace (Session Establishment Ratio (SER)) je počet požadavků INVITE s odpovědí 200 ku celkovému počtu těchto požadavků. Zprávy INVITE, na něž odpověděl přesměrující server (odpovědi 3xx), se nepočítají. Metrika Session Establishment Effectiveness Ratio (SEER) navíc počítá za úspěšné ty pokusy, kdy důvodem chybové odpovědi bylo odmítnutí uživatelem (tj. odpovědi s kódy 480, 486, 600 a 603). Opačný pohled, ale ne vždy číselně opačný, přináší metrika Ineffective Session Attempts (ISAs). Měří poměr neúspěšných pokusů o navázání relace, které selhaly kvůli poruše nebo přetížení cílové stanice nebo nějakého SIP síťového prvku po cestě k ní (chybové kódy 408, 500, 503 a 504), k celkovému počtu pokusů. Session Disconnect Delay (SDD) je doba reakce na žádost o ukončení relace. Měří se mezi zprávou BYE a odpovědí 200 OK nebo chybou. Úspěšné a neúspěšné případy by se opět měly zaznamenávat zvlášť. Session Duration Time (SDT) je délka hovoru. Měří se mezi odpovědí 200 OK na žádost INVITE a ukončením BYE. V případě neúspěšného ukončení se započítávají všechny retransmise BYE až do vypršení časovače F, stejně jako u SDD. Účelem této metriky je detekce problémů projevujících se příliš krátkými hovory a má smysl jen v produkčním prostředí. V syntetickém měření se parametr nazývá Call Hold Time a je vstupním parametrem testu. Poměr bezchybně proběhlých relací ku celkovému množství se nazývá Session Completion Ratio (SCR).

3.2.2 Výkonnostní Měřením výkonnostních charakteristik síťových zařízení SIP se zabývá návrh (draft) standardu [64, 65]. Je rozdělen do dvou částí, terminologie a metodologie. Jeho zájem je shodný se zájmem této práce, a to zátěžové testování nějakého druhu SIP serveru (označovaného jako DUT, Device Under Test) nebo soustavy serverů (širší pojem SUT, System Under Test), pomocí nástroje emulujícího uživatelské agenty. Dokument [64] nejdříve shrnuje všechny možné scénáře testování, tj. testovaný systém chovající se jako UAC (User Agent Client), UAS (User Agent Server) nebo proxy, scénáře pouze se signalizací nebo i s mediálním tokem. Pak dokument definuje některé obecně známé termíny ze světa SIP telefonie, a nakonec se dostává k výkonnostním metrikám. V některých případech jsou parametry stejné nebo podobné jako v minulém dokumentu pojmenovány jinak; soudím, že je to vinou toho, že tento dokument není ještě schváleným standardem a terminologie není zcela sladěna. Definované charakteristiky jsou:

- 50 -

Session Attempt Rate (SAR) – parametr testu; počet nově navazovaných relací za jednotku času. Session Duration – parametr testu; doba hovoru. Ekvivalentní název je Call Hold Time. Establishment Threshold Time – parametr testu ovlivňující jeho vyhodnocení; doba, za kterou je pokus o navázání relace označen za neúspěšný. Doporučená maximální hodnota se odvíjí od definice časovačů v RFC 3261 [4] a je 64 * T1. Má-li tester na mysli pohodlí uživatelů, může tento parametr nastavit níže. Standing Sessions Count – počet současných relací, které jsou navázány na SUT v daný časový okamžik. Je produktem parametrů testovacího systému Session Attempt Rate a Session Duration. Registration Rate – počet registrací, které SUT dokáže obsloužit za jednotku času. Měří se zvyšováním množství pokusů o registraci po krocích, dokud se nezačnou objevovat chyby. V případě, že existuje rozdíl mezi prvotní registrací a její obnovou (při re-registraci nemusí být přítomna autentizační výzva), je vhodné změřit oba případy. Expirační doba registrace by měla být nastavena alespoň na hodinu. Jednotka výsledku je rps (Registrations per Second). Session Establishment Rate – počet nových relací za jednotku času, které dokáže SUT obsloužit. Měří se zvyšováním SAR, dokud se nezačnou objevovat chyby. Výsledek měření je hodnota v posledním kroku, kde ještě chyby nebyly pozorovány. Celkový výsledek by měl být průměrem maxim z několika měření. Během jednoho měření by se relace neměly ukončovat. Jednotka je sps (Session per Second). Metoda měření doporučená v [65] spočívá v iniciálním nastavení SAR na 100 sps a zvyšování či snižování o 50% podle toho, zda se objeví či neobjeví chyby, v mezích od 100 do 100 000 sps. Nejdříve by se měla vyzkoušet výkonnost testovacího systému bez zapojeného SUT, aby se zjistil výkonnostní strop měřícího zapojení. Session Capacity – maximální dosažitelná hodnota Standing Sessions Count. Měření má smysl ve scénářích s mediálními toky nebo když SUT uchovává stav dialogů. Měří se tvořením nových relací bez uzavírání starých, s omezením jejich celkového počtu nastaveného prvotně na 10 000, pak zvyšovaného nebo snižovaného dle potřeby. S výsledkem se musí uvádět zátěž SAR, při které byl naměřen. Měření se provádí do první chyby, pokud se pokračuje dál, je výsledkem Session Overload Capacity, který se měří do chvíle, než SUT přestane přijímat jakékoli nové požadavky. Chování SIP serverů ve stavu přetížení je zřejmě předmětem probíhajícího výzkumu v IETF (Internet Engineering Task Force). Session Establishment Performance – procento úspěšných pokusů o sestavení relace během testu, závislé zvláště na Standing Sessions Count.

- 51 -

3.3 Metodika měření Návrh standardu, zabývající se metodikou měření SIP (Session Initiation Protocol) [65], je poměrně krátký a dost prostoru věnuje náležitostem a příkladům zpráv z měření. Zajímavé postřehy z něj jsem zahrnul jako komentáře k měřeným veličinám výše. V zásadě mluví tento dokument o použití testovacího nástroje, který emuluje chování jednoho nebo více uživatelských agentů a umožňuje generování požadavků na registraci, hovor a zasílání krátkých zpráv se zadanými parametry. Navrhuje zátěž měnit po krocích 50% a tak rychleji nalézt maximum testovaného systému. Tím poněkud kontradikuje přiložený terminologický dokument, který o výkonnostních veličinách tvrdí, že se mají měřit postupným zvyšování zátěže do zaznamenání první chyby. Žádné standardy zabývající se metodikou měření výkonu SIP jsem nenašel (dokument [65] je pouze návrhem standardu), existují ale dokumenty typu krátkých vědeckých prací, ze kterých je možno čerpat informace o obecné praxi provádění testů na SIP zařízeních.

3.3.1 Aplikační servery Metodikou ladění a měření výkonnosti aplikačních serverů SIP se zabývá práce americké neziskové společnosti Computer Measurement Group (CMG) [66].

Souhrn Práce nejdříve shrnuje vlastnosti protokolu SIP a zdůrazňuje, že na rozdíl od HTTP (Hypertext Transfer Protocol) je SIP velmi citlivý na zpoždění v doručování zpráv. Dále se zabývá všeobecným rozborem faktorů, které mohou mít vliv na výkonnost SIP aplikačního serveru, a poskytuje některé rady k optimalizaci výkonu. S faktory, které je třeba optimalizovat, začíná na velmi nízké úrovni. Argumentuje, že jestliže většina SIP zpráv používá transportní protokol UDP (User Datagram Protocol), je třeba vyladit počítač na optimální výkon při zpracování jeho paketů. Popisuje, že je vhodné otestovat výkon všech dostupných ovladačů k síťovým kartám a vyladit jejich parametry nástroji „ethtool“ a „ifconfig“. Během všech změn měří propustnost protokolem FTP (File Transfer Protocol, který sice komunikuje po TCP (Transmission Control Protocol), ale na měření propustnosti se používá běžně) a ztrátovost paketů pomocí „ping“; v případě konkrétního použitého stroje uvádí výrazné zlepšení. Dále shrnuje parametry, které ovlivňují výkon SIP aplikace. Jako největší problém při dodržování nároků SIP na nízké zpoždění uvádí sběr odpadu (garbage collection, GC) v aplikacích psaných v některém z jazyků používajících virtuální stroj, např. Java. Zmiňuje možnosti, jak vhodným výběrem a nastavením GC tento problém minimalizovat.

- 52 -

Dalším faktorem ovlivňujícím zpoždění je například hardwarová konfigurace serveru, na kterém aplikace běží, případně přítomnost nějakého druhu hypervisoru. Při nedostatečném výkonu navrhuje text sestavit cluster serverů, případně s volbou vysoké dostupnosti, která ale snižuje výkon. Posledně, zpoždění bude ovlivněno druhem aplikace (proxy, B2BUA (Back to Back User Agent)), na kterém závisí náročnost zpracování každé SIP zprávy procesorem a uchovávání stavu dialogů v paměti. To společně s množstvím příchozích zpráv za jednotku času a dobou trvání hovorů bude ovlivňovat zatížení CPU (Central Processing Unit) a zaplnění RAM (Random Access Memory). Vliv na výkon bude také mít to, zda aplikace bude provádět nějakou formu SIP autentizace.

Metoda měření Společnost CMG používá automatizovaný testovací systém sestavený z Bash skriptů, který umí spustit na testované aplikaci řadu testů s různě nastavenými parametry a sbírat při tom výsledky testů. Použitý generátor zátěže je zřejmě vlastní konstrukce (v textu nazýván jen „Load Driver“). Jeden takový test vypadá tak, že systém má nejdříve popsat prostředí testu a svou konfiguraci a uvést SUT (System Under Test) do čistého stavu – vypnout testované aplikace, smazat soubory se záznamy a zase aplikace spustit. Dále následuje fáze, kdy se SUT zatěžuje slabou zátěží, aby se načetly používané soubory do vyrovnávací paměti a v případě Java se za běhu zkompilovaly často používané třídy (technologie JIT, Just In Time). Pak se aplikuje požadovaná zátěž na definovanou dobu. Naměřená data a soubory se záznamy činnosti aplikace uloží na souborový server ve formátu .zip pro pozdější analýzu. Součástí výsledků je i záznam zatížení CPU a RAM nástrojem „nmon“ a soubor se zachyceným síťovým provozem z doby začátku a konce testu.

Zpracování výsledků Výsledky testů zpracovávali v CMG tak, že si ručně prohlédli záznam síťového provozu, zda při testu nedocházelo k retransmisím, v případě selhaného testu prohlédli záznamy aplikace. Dokument zdůrazňuje důležitost udržování latence pod hranicí, která spouští retransmisi, protože při velkých množstvích požadavků mají časté retransmise velmi špatné následky. Pak sestavili a prohlédli grafy vytížení testovaného systému, na kterých často objevili zajímavé fenomény, jako např. pilovitý průběh zatížení, který by při uvedení pouhého průměru vytížení byl přehlédnut. Tento fenomén byl prý způsoben vysokou latencí DNS (Domain Name System) dotazů, kterou vyřešilo nasazení vyrovnávací paměti „nscd“.

- 53 -

3.3.2 Infrastruktura Práce pocházející z Vysoké školy báňské – Technické univerzity Ostrava [67] předkládá metodu testování SIP infrastruktury a ověřuje ji na serveru Asterisk.

Souhrn V úvodu práce zdůvodňuje svou existenci tím, že výkonnostní testování SIP je předmětem výzkumu, a neexistují žádné přijaté normy, jak ho provádět (V době jejího vzniku nebylo schváleno ještě ani RFC 6076 [63], které ve formě návrhu také cituje.). Zavrhuje proprietární testovací nástroje pro obtížnost porovnání získaných výsledků a navrhuje způsob použití otevřeného zátěžového generátoru SIPp v souladu s dostupnými návrhy standardů IETF. Práce se zaměřuje na srovnání výkonu serveru Asterisk s a bez překódování hlasových signálů RTP (Real-time Transport Protocol) mezi různými kodeky; argumentuje, že vzniklé poměry výkonu jsou univerzálně platné, nezávislé na výkonu použitého hardware.

Metoda měření Kolegové z VSB (Vysoká škola báňská) použili SIPp k simulaci obou konců SIP dialogu, UAC (User Agent Client) a UAS (User Agent Server), mezi nimi byla testovaná infrastruktura, představovaná serverem Asterisk, který se z hlediska SIP chová jako registrační server a B2BUA. Vliv podpůrné síťové infrastruktury byl minimalizován tím, že všechny stroje účastnící se testu byly zapojeny do jednoho přepínače. Měření probíhalo postupným zvyšováním zátěže ve smyslu počtu navazovaných hovorů (SAR, Session Attempt Rate) po krocích. Každý krok trval 15 minut a skládal se z hovorů o době trvání (Call Hold Time) 60 s, včetně datových toků. SIPp bylo vybaveno testovacím scénářem (viz. kapitola 3.4), ve kterém proběhla registrace a ihned po ní hovor. Ve scénáři byly definovány body měření času tak, aby se sbíraly metriky RRD (Registration Request Delay) a SRD (Session Request Delay). Oproti takto nastavenému SIPp bylo další SIPp, se scénářem emulujícím UAS, které odpovídalo na SIP požadavky. Zajímavý prvek je, že mimo instancí SIPp provádějících zátěžový test vyčlenili kolegové zvlášť jednu, která navázala jediný hovor s přidruženým RTP tokem a na té měřili kvalitativní ukazatele RTP.

Měřené ukazatele Jak již bylo řečeno, zátěžový generátor SIPp v roli UAC měřil zpoždění RRD a SRD. Mimo toho se zde zaznamenávalo množství neúspěšných hovorů, podle kterého se určovalo, kdy test ukončit. Generátory spouštěli na VSB vzdáleně pomocí SSH a Bash skriptu. Výsledky pak zřejmě zjišťovali ručně pohledem na terminály počítačů.

- 54 -

Na měřeném serveru se sbíraly údaje o zatížení CPU a zaplnění RAM pomocí nástroje System Activity Reporter (SAR). Kvalita hlasového toku RTP se pak prozkoumala programem Wireshark, který disponuje komplexními nástroji na analýzu RTP. Jako kritérium pro posouzení kvality signalizace je uvedeno, že zpoždění SRD nesmí přesáhnout 300 ms a test se ukončí, když začne tento ukazatel rapidně růst. Pro kvalitu datového toku nasadili kolegové horní mez zpoždění 90 ms. Podle mého názoru lze těchto hodnot dosahovat pravidelně pouze v laboratoři, či ve firmě s dobře nastavenou sítí používající Asterisk jako softwarovou telefonní ústřednu. V reálných telefonních sítích se dá SRD čekat až v řádu několika málo sekund, v mobilních sítích (např. GPRS (General Packet Radio Service) a EDGE (Enhanced Data for GSM Evolution)) pak může zpoždění RTP toku dosáhnout stovek ms až jednotek sekund. Důležité ale je, aby variabilita zpoždění (jitter) byla nízká, menší, než rozsah vyrovnávacích pamětí v telefonech (viz. 2.1.3). Stolní SIP telefony mají dle mé znalosti paměť běžně 150 ms, ale nevylučuji, že u mobilních telefonů bude paměť s ohledem na charakter sítě konstruována větší.

Výsledek Z textu se dozvídáme, že SIPp na poměrně silných jednoprocesorových strojích dokázal vygenerovat ne více než 200 hovorů jako UAC a 400 jako UAS, dost výkonu strojů ale zabíralo generování datových toků RTP. Testovaný server byl dvouprocesorový a tak kolegové odhadli podle manuálu k Asterisk jeho kapacitu na ne více než 1000 sps (Sessions per Second), pročež použili 4 UAC a 2 UAS. Odhad se ukázal jako správný. Dále obsahuje dokument hlavně srovnání výkonnosti v případech s různými použitými hlasovými kodeky.

3.3.3 SIPstone Dokument z Columbia University s názvem SIPstone [68] je poměrně starý, ale problematiku měření SIP pojímá nejobecněji a zdá se, že je de-facto standardem v oboru.

Souhrn Článek se zabývá návrhem standardní implementace srovnávacího testu (benchmark) pro SIP proxy a přesměrovací servery, který bude používat dobře definovatelnou a opakovatelnou zátěž. Zátěž bude generována nástroji simulujícími uživatelské zařízení a bude se skládat se směsi registrací a úspěšných a neúspěšných pokusů o hovor. Práce podotýká, že je obtížné najít reprezentativní složení směsi, protože například domácnost i call centrum budou mít stejný interval registrací (běžně nastavený na hodinu), ale nepoměrně rozdílný poměr počtu hovorů k těmto

- 55 -

registracím (navrhuje hodnoty 20 a 1 hovor za hodinu). Na výkonnost testovaného systému bude také mít vliv typ použité databáze uživatelů (v paměti, na disku, na externím stroji) a velikost v ní obsažené uživatelské základny. Záměrem srovnávacího testu má být zjištění maximálního počtu souběžných pokusů o navázání hovoru ve špičce (busy hour call attempts) pro účely plánování sítě. Neklade si za cíl ověření stability testovaného systému. Standard například navrhuje dobu testování 15 minut, ale připouští, že například server s chybou typu únik paměti (memory leak) může při stejné míře zátěže spadnout o minutu později.

Metoda měření Zátěžový test SIPstone je navržen od počátku s distribuovanou architekturou. Testovací prostředí by měly tvořit generátory zátěže v režimu UAC, u kterých lze nastavit typ zasílaného požadavku, počet požadavků, rychlost generování (která se bude po krocích zvyšovat) a transportní protokol, nebo, pokud bude generátorů více než jeden, se tyto parametry nastaví centrálně na koordinátoru testu. Požadavky prochází přes SUT (System Under Test), kterým je myšlen SIP server, všechny podpůrné servery, které používá (DNS, databáze) a infrastruktura mezi nimi. Na požadavky odpovídají generátory zátěže v režimu UAS. Na jejich výkonnost je kladen požadavek, aby všech stupních zátěže během testu odpověděly na SIP zprávy nejpozději do 100 ms. Emulátory UAS před testem zaregistrují uživatele, kteří se mají jmenovat A000000-A999999 a má jich být zaregistrováno tolik, aby se během testu (nebo alespoň během jednoho kroku testu) každý použil jen jednou. Jako charakteristiku příchodů hovorů na server doporučuje práce osvědčený Poissonův proces a mimo doby mezi jednotlivými hovory identifikuje dva další intervaly, na které se dá aplikovat exponenciální rozložení. Tím nejnápadnějším je doba hovoru (Call Hold Time). O té ovšem říká, že nemá prakticky žádný význam, protože klasický SIP proxy server udržuje pouze stav transakcí, nikoli dialogů. Proto je důležitější doba vyzvánění, která je součástí transakce INVITE a dle statistik je prý průměrně 38 s; SIPstone volí dobu 20 s. Dokument pak definuje pět scénářů, se kterými by se SUT měl testovat, všechny by měly proběhnout dvakrát, po UDP i TCP. Definované scénáře jsou: registrace (včetně autentizační výzvy metodou Digest), odchozí proxy (generátor posílá požadavky na hovory přes SUT), přesměrování (SUT odpovídá zprávami 3xx), proxy požadavek na neregistrovaného uživatele (s odpovědí 480), proxy požadavek (s odpovědí 200, dialog uzavřený BYE). Samotný test pak probíhá v krocích, kdy se postupně zvětšuje zátěž na testovaný systém. Kroky by měly trvat 15 min; při prvním průchodu, kdy se hrubě odhaduje kapacita SUT, stačí 5 min. Test se ukončuje v okamžiku, kdy množství neúspěšných scénářů přesáhne 5%.

- 56 -

Měřené ukazatele Primárním výstupem testu jsou maximální dosažitelné hodnoty RPS (Registrations per Second) a CPS (Calls per Second). Dále ještě doporučuje vykreslení grafu doby transakcí v závislosti na zátěži. (TRT, Transaction Response Time, měřeno od první zprávy v transakci do poslední) a zátěže CPU a RAM testovaného systému. Ve zprávě o měření by samozřejmě mělo být co nejlépe popsáno celé testovací prostředí. Stejně, jako první citovaný dokument [66], zdůrazňuje SIPstone požadavek udržet latenci odpovědí (zvláště 100 Trying) pod hodnotou časovače T1, tj. běžně 500 ms, minus síťové zpoždění, protože přílišné retransmise mohou rychle vést ke kolapsu serveru. Navíc zavádí ještě přísnější normy, například pro autentizační výzvu ve scénáři registrace 200 ms a na odpověď 100 Trying 100 ms. To jsou hodnoty, kterých v mobilních sítích dosáhneme stěží. Relevantní je ovšem způsob odvození požadavku na maximální prodlevu 2 s při spojování hovoru – cituje se zde standard E.721, který prý uvádí maximální zpoždění při spojování ISDN (Integrated Services Digital Network) hovoru mezi sítěmi 8 s, a z počtu 4 proxy serverů mezi uživateli v sítích 3GPP (čili IMS, Internet Multimedia Subsystem) vyvozuje maximální zpoždění 2 s na každý proxy server. Podle výsledků mého hledání na internetu zřejmě původně existoval program nazvaný přímo SIPstone, již dávno ale není udržovaný, a k tomu, že implementuje test SIPstone, se nyní hlásí generátor zátěže SIPp [51].

3.3.4 ETSI TS 186.008 Dodatečně (z referencí generátorů zátěže) jsem objevil standard jménem ETSI TS 186.008 [54], který se věnuje specificky zátěžovému testu pro sítě IMS. Standard vznikl v organizaci ETSI (European Telecommunications Standards Institute), ale je relevantní nejen pro jejich vývojovou větev IMS TISPAN NGN (Telecommunications and Internet converged Services and Protocols for Advanced Networking; Next Generation Network), ale i pro hlavní větev z 3GPP (Third Generation Partnership Project), protože se zabývá měřením výkonu z pohledu uživatele, pro kterého se obě varianty jeví stejné. Na případné rozdíly, jako sloučení S-CSCF a I-CSCF (Serving a Interrogating Call Service Control Function) a přejmenování HSS (Home Subscriber Server) na UPSF (User Profile Storage Function), dokument sám upozorňuje. Shrnutí podstatných rysů standardu poskytuje dokument firmy Intel [69].

Shrnutí Dokument se zabývá navržením standardu pro měření sítí nové generace typu IMS. Argumentuje, že výkon IMS serverů, které lze nasadit na běžných počítačích, ovlivňuje mnoho parametrů počítačového světa, jako různé lokální datové sítě, operační systémy, sběrnice a procesory, takže klasické srovnávací

- 57 -

testy z telekomunikačního světa přestávají být relevantní. Na druhé straně, testy z počítačového světa jsou zaměřeny na měření hrubého výpočetního výkonu a nezohledňují požadavek poskytovatelů služeb na výsledky zaměřené na počty transakcí. Proto je potřeba navrhnout nový standard testování. Standard je rozložen do 3 oddělených dokumentů. První obsahuje úvod, celkový přehled o architektuře testu, definici testovaného a testovacího systému, měřených veličin a návrh zprávy o testu. Druhá část blíže rozebírá složení SUT (System Under Test) a podrobně popisuje testovací scénáře včetně kvalitativních metrik a jejich hraničních hodnot, ačkoli v textu se píše, že tyto normy budou s časem dolaďovány. Třetí část se zabývá doporučeným procentuálním zastoupením scénářů v testu a časovým průběhem měření.

Metoda měření Protože se standard snaží zaměřit na testování výkonu IMS sítě z pohledu uživatele, začíná jeho definice u pojmu případů užití (use cases), které může uživatel chtít se systémem provádět. Ty jsou identifikovány tři, a to registrace, volání a poslání textové zprávy. Případy užití mohou probíhat různými způsoby, které se v názvosloví standardu nazývají scénáře. Například případ užití registrace reprezentují scénáře registrace, registrace se synchronizací sekvenčního čísla AKA (Authentication and Key Agreement), re-registrace apod. Druhá část dokumentu popisuje detailně celkem 36 možných scénářů, včetně jejich vysvětlení a průběhu, a třetí jejich doporučený poměr v procentech. Ne všechny scénáře jsou v doporučeném složení testu zahrnuty, celkem jsou tam 3 za případ užití registrace, 4 úspěšné hovorové scénáře a 9 neúspěšných a 2 scénáře ze skupiny textových zpráv. Generátory zátěže mají generovat scénáře v daném poměru a s exponenciálním rozložením doby mezi jednotlivými pokusy; testovací systém tedy simuluje Poissonův proces příchodu požadavků na SUT. Stejně jako minulý dokument, mluví standard o zavedení uživatelské základny fiktivních uživatelů do testovaného systému. Není zde požadavek, aby během testu byl každý uživatel použit jen jednou, ale uživatelé by se měli chovat tak, jako v reálném světě. Součástí testu by tedy ideálně mohl být i statistický popis chování uživatelů. Podle něj by se určil počet simulovaných uživatelů, například počítáme-li s poměrem jeden hovor na jednu registraci a jednu registraci za hodinu, měli bychom zavést nejméně 3600 * DOC (viz. níže) uživatelů. Testovací scénáře by měly uvažovat momentální stav simulovaných uživatelů. Například pro scénář registrace by měl být vybrán účet, který není registrován, naopak pro scénář volání je třeba vybrat registrovaného uživatele. Průběh testu by měl vypadat tak, že se nejdříve provede inicializace SUT. Ta zahrnuje zavedení uživatelské základny, provedení registrace její definované části a spuštění transakcí s touto uživatelskou základnou, aby se stav systému stal více náhodným, blízkým ke stavu, jako by systém běžel

- 58 -

nějakou dobu s reálnými uživateli a provozem. Pak se začne systém zatěžovat definovanou počáteční zátěží, která se bude po krocích zvyšovat. Dobu trvání, počet kroků a jejich výšku standard nedefinuje; ukončení testu nastává buď po zadaném počtu kroků nebo při přetížení SUT.

Měřené ukazatele Primárním výstupem testu je ukazatel nazvaný DOC (Design Objective Capacity). Je definován jako nejvyšší zátěž, kterou SUT snese, aniž by množství selhaných scénářů překročilo stanovanou hranici (pro tyto dva pojmy zavádí norma označení IHS (Inadequately Handled Scenario) a DO (Design Objective)). Zátěž se měří v jednotkách SAPS (Scenario Attempts per Second), které jsou zobecněním jednotek rps (Registrations per Second) a cps (Calls per Second) pro registrace a hovory, navíc je zde ještě případ užití textových zpráv. Selhaný scénář je takový, na který testovaný systém odeslal odpověď jinou než očekávanou nebo takový, kde odpověď nepřišla ve stanoveném časovém intervalu. Testovací prostředí musí být nastaveno tak, aby nesprávná odpověď byla zaslána jen kvůli chybě nebo přetížení SUT, nikoli chybě v nastavení. IHS se měří ve stavu, kdy je SUT pod stálou zátěží. Tvůrci standardu počítají s tím, že při náhlém zvýšení zátěže se objeví špička v počtu selhaných scénářů, a zavádějí na začátku každého kroku měření „dobu hájení“, kdy se hodnota IHS nezaznamenává. Pokud by kapacita testovacího systému byla nižší, než kapacita testovaného, připouští standard použití zátěže na pozadí (background load). Způsob jejího generování ovšem musí být adekvátně popsán. Další měřené metriky jsou TRT (Transaction Response Time, definovaný stejně jako u SIPstone [68]), dále zátěž CPU a zaplnění RAM, poměř retransmisí k počtu odeslaných zpráv (RETR), počet současně běžících scénářů (SIMS, ekvivalent Standing Call Rate) a IHS. TRT je zde jen obecné označení metriky. Druhá část standardu definuje pro každý scénář zvláštní názvy pro jednotlivé zajímavé intervaly. Jsou zde uvedeny i mezní hodnoty, při jejichž překročení se má scénář prohlásit za selhaný. Můžeme tam například najít metriku PX_TRT-SES1 s maximální hodnotou 8s, která přesně odpovídá požadavku z dokumentu SIPstone na 8s zpoždění při sestavování hovoru mezi dvěma uživateli. Limity na první odpověď na jednotlivé zprávy (REGISTER, MESSAGE, INVITE) jsou prakticky ve všech případech nastaveny na 2 s, což odpovídá nastavení časovače T1 v IMS. Text popisuje poměrně detailně i formát zprávy o měření. Ta by měla obsahovat popis konfigurace testovaného a testovacího systému, hlavní metriku DOC a další metriky ve formě grafů a tabulek průměrných hodnot v jednotlivých krocích testu, návod na interpretaci zprávy a případná další pozorování z průběhu testu. Vyžadované grafy jsou uvedeny ve třetí části

- 59 -

standardu a jsou to grafy IHS, TRT a RETR pro každý měřený scénář a grafy zátěže CPU a RAM pro každou komponentu SUT.

3.4 Generátory zátěže Všechny uvedené standardy mají jeden společný bod, a to nějaký druh generátoru zátěže emulujícího uživatelské agenty SIP (Session Initiation Protocol). Většinou je výběr generátoru ponechán na implementátorovi testu, proto jsem se pustil do průzkumu internetu, abych zjistil, jaké generátory jsou dostupné a jaké mají vlastnosti. Výběr v této oblasti je poměrně velký, zvláště v oblasti komerčních produktů. Pouze malá část nalezených programů a hardwarových zařízení ale splňuje mnou požadované parametry, tedy aby podporovaly specifika sítě IMS (Internet Multimedia Subsystem) a umožňovaly distribuované generování zátěže. Uvádím zde nalezené produkty seřazené vzestupně podle vhodnosti. Candelatech CT506 LANforge-FIRE [72] – generátor zátěže dodávaný ve formě 1U policového (rack) serveru. Dokáže vygenerovat jen 280 SIP hovorů s RTP (Real-time Transport Protocol) datovým tokem; je možné sestavit cluster více strojů. Umí testovat i další protokoly, ale v materiálech není žádná zmínka o IMS. Jako jediný výrobce uvádí Candelatech cenu, a to $42 395 při zakoupení a $29 900 při pronájmu na rok. Arca Technologies Emutel Harmony [77] – rozšiřitelný hardwarový, nebo softwarový generátor hovorové zátěže. Dodává se ve formě šasi, do kterého se vkládají testovací karty s různými rozhraními, případně jako počítačový program. Hardwarová varianta generuje hovory rychlostí 80 cps (Calls per Second) bez datového toku na kartu, do největšího šasi se vejde 15 karet. Hardwarová i softwarová verze podporuje maximálně 5000 současných hovorů (standing calls) bez RTP. Má podporu pro psaní vlastních testovacích scénářů, nikde ale není zmínka o IMS a zřejmě nejde nasadit distribuovaně. Touchstone WinSIP [71] – softwarový generátor SIP zátěže. Dokáže vygenerovat několik tisíc cps na běžném počítači, včetně analýzy mediálních toků. Scénáře jsou skriptovatelné, ale v materiálech se nikde nevyskytuje zmínka o podpoře distribuovaného testování nebo IMS. Zřejmě nepodporuje autentizační schéma AKA (Authentication and Key Agreement). GL Communications PacketGen [73] – distribuovaný softwarový generátor SIP zátěže. Dokáže vygenerovat přes tisíc cps na výkonném počítači, včetně RTP provozu. To je podobné jako u WinSIP ale s PacketGen je možné sestavit distribuované prostředí z více generátory. Hlásí se k podpoře standardu SIP s rozšířením 100rel, nikoli však IMS a zřejmě nepodporuje skriptování scénářů. pjsip-bench [79] – jednoduchý otevřený (open-source) softwarový generátor SIP zátěže. Pjsip je rychlá knihovna psaná v jazyce C a

- 60 -

umožňující tvorbu vestavných SIP aplikací. Pjsip-bench je nástroj napsaný k otestování její rychlosti. Dokáže měřit rychlost slepého generování zpráv, zpracování transakcí i zpracování dialogů, tedy všechny tři vrstvy protokolového zásobníku SIP. Nástroj nezpracovává RTP a neřeší otázku statistického rozložení příchodu zpráv, pouze generuje zprávy tak rychle, jak mu to počítač umožní. Tato rychlost je ale úctyhodná, asi 3000 cps na počítači Pentium 4. Není distribuovaný a má jen ty nejjednodušší scénáře. Přes tyto nedostatky ho zařazuji před komerční produkty, které také mnou kladené požadavky nesplňují, protože ty nelze nijak upravovat, naopak tento program by mohl být dobrým základem pro nový výkonný softwarový generátor zátěže. Ameritec IPXtreme NLG-IPX [70] – hardwarový generátor SIP zátěže. Tvrdí o sobě, že je nejmenší vysokokapacitní generátor zátěže na světě a že má nejlepší poměr cena/výkon. Dokáže simulovat přes 60 000 koncových uživatelů a generovat až 20 000 cps. Více jednotek se dá ovládat z jednoho rozhraní. Podporuje měření kvality RTP toků (evidentně ne rychlostí udávanou pro zátěžové měření signalizace, osazený 100 Mb/s Ethernet port by zdaleka nestačil). Má upravitelné testovací scénáře. V informační brožuře se píše, že se dá použít na testování sítí NGN (Next Generation Networks), nevyskytuje se v ní ale zmínka o IMS nebo nějakém podporovaném standardu. Spirent Abacus [76] – rozšiřitelný hardwarový generátor hovorové zátěže. Dodává se ve formě šasi, do kterého se dají dokupovat testovací karty pro datové i telekomunikační sítě. Karta pro testování IMS a SIP se nazývá ICG3 a výkonově zvládne 20 000 současných hovorů bez média a 10 000 s G.711. Dokáže na testovaný systém registrovat 65 000 simulovaných uživatelů. Karet se do systému vejde 12. Celkově systém dokáže vygenerovat zátěž 25 000 cps. Podporuje zabezpečení IPSec (Internet Protocol Security) a SRTP (Secure RTP), volitelně IPv6 (Internet Protocol version 6). Seagull [80] – otevřený softwarový generátor zátěže. Pochází z firmy HP (Hewlett Packard), stejně jako SIPp, a zaměřuje se na zátěžové testování všech protokolů používaných v IMS, mj. také SIP, čímž částečně konkuruje SIPp. Podporuje skriptování v scénářů v XML (Extensible Markup Language) souborech, ale u SIP mu oproti SIPp chybí podpora pro nepovinně přijaté (např. 183 při prodlevě) a duplikátní odpovědi (např. při retransmisi), které pak zřejmě označí za neočekávané a scénář za selhaný. Podporuje TLS (Transport Layer Security), po IPv6 pouze protokol Diameter. Obsahuje autentizační mechanismus AKA. Uvádím ho zde spíše pro kompletnost, pro testování protokolu SIP bude zřejmě vhodnější specializovaný nástroj SIPp.

- 61 -

SIPp [51] – otevřený softwarový generátor SIP zátěže. Vytvořen ve firmě HP a uvolněn jako otevřený software. Podporuje generování SIP zpráv na základě XML scénářů. V programu je pro snadné nasazení přímo zakompilováno několik jednoduchých scénářů, použitelných pro test SIPstone [68] citovaný v kapitole 3.3.3. Na stránkách projektu, v sekci Wiki (která ale nebyla v době psaní této práce funkční, bylo třeba použít služby www.archive.org), se nachází i několik jednoduchých scénářů pro IMS. Program podporuje autentizační metodu AKA, dále IPv6, TLS a vysílání RTP toků s ozvěnou na straně UAS. Ve scénářích je možné určit statistické rozložení mezer mezi generovanými zprávami. Má velmi kvalitní dokumentaci. Ohledně jeho výkonnosti a možnosti nasazení na více strojů s centrálním ovládáním dobře informuje práce [67] citovaná v kapitole 3.3.2. Ixia IxLoad [74] – rozšiřitelný hardwarový generátor zátěže. Dodává se ve formě šasi, do kterého se dají dokupovat testovací karty s vlastními procesory a pamětí. Existuje softwarová verze testovacích karet ve formě virtuálního stroje, čehož by mohlo jít využít pro distribuované nasazení. Produkt se zaměřuje na kombinované poskytovatele služeb (tripleplay) a podporuje širokou škálu protokolů, mj. SIP. Dokáže generovat 80 Gb/s provozu, 20 Gb/s se zabezpečením IPSec, podporuje IPv6. Pro SIP uvádí až 96 000 aktivních simulovaných účastníků včetně RTP médií s jedním testovacím modulem. Modulů se do největšího šasi vejde 12. Obsahuje podporu pro velké množství SIP rozšíření (extensions) a má vestavěné scénáře pro IMS. Zřejmě je podporováno i skriptování vlastních. Empirix Hammer G5 [75] – distribuovaný generátor IMS zátěže dodávaný ve formě 2U policového serveru. Dokáže generovat zátěž několika protokoly, všechny jsou ale zaměřeny na VoIP. Podporuje testování všech možných komponent IMS sítě, a to samostatně nebo sítě jako celku. Testovací scénáře je možné upravovat. Podporuje IPv6 a TLS, umí analyzovat datové toky. Uvádí, že jeden server dokáže emulovat 32 000 klientů a „Mega-Controller“ umožňuje centrální ovládání asi 20 serverů, pro celkových maximálně 300 000 emulovaných účastníků. SIPNuke [78] – distribuovaný standardní softwarový generátor IMS zátěže. Tento program byl napsán v institutu Fraunhofer FOKUS na testování jejich dalšího produktu Open IMS Core. Hlásí se ke standardům ETSI pro výkonnostní test (ETSI TS 186.008 [54]) a test interoperability. Snaží se o vysokou flexibilitu skriptování scénářů v jazyce Lua a vysoký výkon – tvrdí, že dokáže simulovat až milion uživatelů a saturovat provozem 100 Mb/s linku. Na běžném serveru z roku 2008 zpracuje 5000 transakcí za sekundu. Podporuje RTP. Je možné ho nasadit i distribuovaně s centrálním ovládáním. K dispozici je zkušební

- 62 -

licence a několik komerčních, je zakázáno publikovat data naměřená se zkušební verzí, naopak s nejvyšším stupněm komerční jsou dodávány i zdrojové kódy. Webové stránky jsou z roku 2008 a jsou místy nedokončené. Špatná dokumentace je zřejmě pro Fraunhofer FOKUS příznačná. IMS Bench SIPp [51] – distribuovaný standardní otevřený softwarový generátor IMS zátěže. Jde o generátor zátěže SIPp upravený firmou Intel tak, aby implementoval výkonnostní test IMS dle standardu ETSI TS 186.008 [54]. Úpravy spočívají v přiložení podmnožiny scénářů ze standardu (chybí 4 varianty navázání hovoru a scénáře končící neúspěchem) a automatického generátoru konfigurace testu a generátoru výstupních zpráv o testu. SIPp byl přeměněn na pravý distribuovaný systém (nikoli jen centrálně řízený) přidáním komponenty pro centrální řízení testu a XML značek ve scénářích pro synchronizaci jednotlivých generátorů zátěže. SIPp agenti jsou schopni si sdělovat, jaké uživatelské účty se mají pro scénáře použít, takže je ctěn požadavek standardu na použití uživatelských účtů v závislosti na jejich stavu (registrován nebo neregistrován). Také je podporováno distribuované měření zpoždění SIP zpráv mezi odesilatelem a příjemcem pro měření metrik typu TRT (Transaction Response Time). Vzhledem k tomu, že SIPp agenti spolu komunikují po dvojicích a synchronizace nezatěžuje centrální bod, očekával bych velmi dobrou škálovatelnost testovacího systému. Oproti originálnímu SIPp byla přidána podpora pro více načtených scénářů a výběr použitého scénáře dle zadaného pravděpodobnostního rozložení. Také byly provedeny některé optimalizace pro vyšší výkon generování zátěže. Přiložen je program na záznam zatížení CPU (Central Processing Unit) a RAM (Random Access Memory) jedné nebo několika komponent testovaného systému. Během úprav inženýři z firmy Intel rozbili některé funkce SIPp, a to TLS, IPv6, původní synchronizační nástroj SIPp „3PCC“ a přehrávání/echo RTP (v manuálu je u něho napsáno „netestováno“, mě se SIPp s touto volbou nepodařilo ani zkompilovat). Oprava těchto funkcí by ale měla být možná.

- 63 -

3.5 Návrh metody měření Jako měřící metodiku zvolím standard ETSI TS 186.008 [54]. Standard se zabývá přesně stejným problémem, jako tato práce, tedy měřením výkonu jádra IMS sítě z hlediska maximálního počtu registrací, hovorů či zpráv zpracovaných za jednotku času, takže jeho použití je vhodné. Měření podle standardu je výhodnější, než ad-hoc pokus, protože dává pokusu určitý řád a zvyšuje jeho věrohodnost a opakovatelnost. Zvolený standard navíc pokrývá snad všechny měřitelné parametry, jak kvalitativní, tak výkonnostní, které se vyskytují v ostatních citovaných dokumentech, a v metodice jejich sběru s nimi souhlasí, případně ji i upřesňuje. Z existujících generátorů zátěže podporují zmíněný standard pouze dva, a to SIPNuke a IMS Bench SIPp. Mezi těmito dvěma je dle mého názoru IMS Bench SIPp jasnou volbou. Oba vypadají jako nástroje, na kterých probíhá vývoj, ale IMS Bench SIPp je lépe dokumentován a jeho stránky jsou aktuálnější než u SIPNuke. IMS Bench SIPp má také nezanedbatelnou výhodu v tom, že je zdarma, a to včetně zdrojových kódů. Pokud by v něm bylo třeba něco opravit, nebylo by nutné procházet přes technickou podporu. Osobně bych si nedovolil něco s tak nedůvěryhodnou prezentací, jakou má SIPNuke, vydávat za komerční nástroj. Ostatní komerční generátory zátěže mají oproti těmto dvěma velkou nevýhodu. Jde o víceméně centralizované měřící systémy a tato práce je zaměřena na distribuované generování zátěže. S malým softwarovým balíkem typu výše zmíněných dvou můžeme vytvořit skutečně masivně distribuovaný systém o stovkách měřících agentů, se kterým by operátor mohl komplexně otestovat svou síť včetně jejích okrajových částí a nasimulovat tak zátěž podobného druhu, jako vytvářejí reální uživatelé. Měřící agenty SIPp, které jsou k dispozici ve formě zdrojového kódu, je možné zkompilovat pro jakoukoli architekturu a provozovat například na mobilních telefonech obsahujících jádro Linux, nebo na zařízení v základnových stanicích mobilní sítě. Agenty na takových zařízeních by sice jednotlivě negenerovaly velké datové toky, ale v součtu by vznikla velká zátěž rozložená po síti. Komerční produkty jsou oproti tomu zaměřené na generování velkých objemů zátěže na jednom nebo několika málo místech. Dají se tak s úspěchem použít přímo v jádru sítě nebo na jejích páteřních linkách, kde je potřeba generovat vysoké datové toky, které by se bez hardwarové akcelerace vytvářely obtížně. Přesto by mohlo být zajímavé otestovat možnosti některých zmíněných komerčních produktů (zvláště firem Empirix, Ixia, Spirent a Ameritec), zvláště pak srovnat jejich schopnosti s nástroji dostupnými zdarma a výstupy s dostupnými standardy.

- 64 -

Má práce měla nulový rozpočet, takže jsem navrhl oslovit firmy jménem Katedry telekomunikací s žádostí o možnost vyzkoušení zdarma. Má žádost byla zamítnuta, už proto, že většinou nejde o distribuované generátory zátěže a mé práce by se tak týkaly jen okrajově. Toto srovnání tedy předkládám jako možnost dalšího výzkumu. Práce se tedy bude dále zabývat měřením zatížitelnosti jádra IMS (IP Multimedia Subsystem) pomocí generátoru zátěže IMS Bench SIPp včetně jeho případných nedostatků. Mezi ty patří absence podpory pro IPv6 (Internet Protocol version 6) a zabezpečení provozu, nedal by se tedy nasadit na plně standardní IMS síť, pouze na síť využívající počátečních úlev (early IMS). Generátor zátěže, který by podporoval standard ETSI a zároveň tyto funkce, ale neexistuje. Případnému zájemci o tyto funkce by nezbylo než je do IMS Bench SIPp doplnit. Druhým identifikovaným nedostatkem je absence kompletní sady scénářů popsané ve standardu (SIPNuke zřejmě obsahuje všechny). Myslím si ale, že všechny scénáře ze standardu by v mém prostředí stejně nebyly relevantní. Například případ užití volání je v něm rozdělen do čtyř scénářů podle toho, zda se na každé ze zúčastněných stran bude provádět rezervace pásma (QoS, Quality of Service). V prostředí bez QoS nemá rozdělení smysl. Stejně tak registrace a re-registrace bude v prostředí bez IPSec (Internet Protocol Security) probíhat stejně. Počet potřebných testovacích agentů nemůžeme předem odhadnout tak, jako to udělali v práci [67] citované v kapitole 3.3.2, protože na rozdíl od nich nemáme k dispozici hrubý odhad výkonu testovaného systému, ostatně ani testovacího systému, protože manuál k IMS Bench SIPp [51] uvádí, že oproti původnímu SIPp došlo k výkonovým optimalizacím. Začneme tedy s měřením s jedním generátorem zátěže a další budeme přidávat dle potřeby, dokud nedosáhneme kapacity testovaného systému. K tomu použijeme hardware dostupný na fakultě, při jeho nedostatku by se daly využít služby typu infrastruktura jako služba (IAAS, Infrastructure as a Service), které často dávají na výzkumné účely slevy. V tomto případě by se ale musel dát pozor na kvalitu internetových linek mezi testovacími agenty a testovaným systémem z hlediska propustnosti a zpoždění. Obecně bude průběh pokusu vypadat tak, že nejdříve použiji softwarový telefon pro IMS a vyladím testovaný systém tak, aby umožnil registraci a hovor jednotlivého uživatele, pak nasadím automatizovaný generátor zátěže a pokusím se generovat hovory ve větším měřítku. Po odladění případných problémů se SUT (System Under Test) či generátorem při malém provozu se pokusím intenzitu generovaného provozu zvyšovat až do dosažení DOC (Design Objective Capacity) testovaného systému.

- 65 -

4 Průběh měření 4.1 Seznámení s Open IMS Core Prvním krokem pro mne bylo seznámení se s testovaným systémem, který byl pro moji práci (a ještě alespoň dvě příbuzné) připraven v serverovně Fakulty elektrotechnické v Dejvicích. Stroj, na němž testovaný software běžel, měl následující parametry (zjištěno příkazem „lshw“): Model: Dell PowerEdge 1955 blade server CPU: Intel Xeon 5160, 2 jádra, každé 2 vlákna, frekvence 3 GHz RAM: 4 GB DDR2 667 MHz Síť: Broadcom NetXtreme II, 1 Gb/s Ethernet, PCI-X Řadič disku: LSI Logic Fusion-MPT SAS, PCI-X Disk: 2x Fujitsu MAY2073RC, 10 kRPM, 83 GB, SAS spojené řadičem do RAID 1, souborový systém Reiserfs 3.6 Operační systém Linux 2.6.32, architektura AMD64, distribuce Gentoo verze 1.12.14. Po průzkumu testované infrastruktury jsem přešel k seznámení se samotným Open IMS Core. Software se standardně instaluje do adresáře /opt/OpenIMSCore, kde se nacházel i na zapůjčeném serveru. V tomto adresáři se nachází podadresáře FHoSS a ser_ims, do nichž jsou instalovány oba softwarové balíky, z nichž se Open IMS Core skládá.. Konfigurace FHoSS (FOKUS Home Subscriber Server) se provádí přes webové rozhraní. Přihlašovací údaje se nastavují v souboru FHoSS/deploy/conf/tomcat-users.xml, samotné rozhraní se po spuštění programu objeví na adrese http://localhost:8080/. Konfigurační soubory se v posledním kroku instalace dle návodu na stránce projektu [41] kopírují ze vzorových verzí v ser_ims/cfg do kořenového adresáře instalace spolu se skripty, kterými se jednotlivé komponenty spouštějí. Jsou tu konfigurační skripty (mimo jiné) pcscf.cfg, icscf.cfg a scscf.cfg. Tyto skripty jsou rozděleny do třech částí, a to základní konfigurace, kde se dá nastavit úroveň ladících výpisů, na jaké adrese a portu bude server naslouchat, kolik se spustí procesů na obsluhu požadavků a jaké je jeho doménové jméno. Ve druhé části se definuje, jaké moduly SER (SIP Express Router) se mají zavést. Mezi nimi jsou i moduly s názvy CSCF (Call Service Control Function) serverů, jejichž zavedením se nastaví chování serveru SER na daný CSCF server. Direktivou „modparam“ pro tyto moduly se zde nastavuje například maximální množství dialogů a jejich expirační doba, jsou zde zakomentované sekce, jejichž aktivací se nastaví různé funkce, u P-CSCF (Proxy CSCF) například RTP (Real-time Transport Protocol) proxy, IPSec (Internet Protocol Security) nebo TLS (Transport Layer Security), komunikace parametrů QoS (Quality of Service) s PCRF (Policy and Charging Rules Function) a podpora nouzových hovorů.

- 66 -

Parametry S-CSCF (Serving CSCF) jsou například doba platnosti autentizační výzvy, výchozí doba vypršení registrace a výchozí autentizační algoritmus. U I-CSCF (Interrogating CSCF) se nastavuje v zásadě jen umístění databáze. Poslední sekcí konfiguračních souborů je automat pro zpracování a směrování požadavků, který společně s programovým modulem pro konkrétní CSCF určuje chování SER serveru. Průzkumem konfiguračních souborů jsem zjistil, že Open IMS Core je zkonfigurován nikoli s výchozí doménou open-ims.test, ale mám k dispozici veřejnou doménu druha.ims-test.cz, ve které je zaregistrována veřejná adresa serveru pod názvy pcscf, icscf, scscf a hss. DNS (Domain Name Server) běží externě a nemám k němu přístup. Systém je nastaven tak, aby fungoval na IPv4 (Internet Protocol version 4), bez QoS a zabezpečení. Nativní konektivita IPv6 (IP version 6) není k dispozici. MySQL server běží lokálně na serveru a jsou do něj zavedeny vzorové SQL (Structured Query Language) soubory, které jsou jinak po čerstvé instalaci k nalezení v FHoSS/scripts. Další fází bylo Open IMS Core spustit. Doporučovaný postup je použít nástroje „screen“ pro vytvoření persistentního multiplexovaného terminálu a v něm spustit postupně ve vlastních oknech skripty pcscf.sh, icscf.sh, scscf.sh a fhoss.sh. Všechny komponenty se rozběhly v pořádku, jen u P-CSCF jsem si všiml hlášky „setkey: command not found“, která odkazuje na nástroj na nastavení IPSec z balíku „ipsec-tools“, který se mi ovšem na Gentoo nepodařilo nainstalovat, protože ho zřejmě nelze zkompilovat pro architekturu amd64 (chybové hlášení „masked by: ~amd64 keyword“). Naopak podařilo se mi nainstalovat balík „rtpproxy“, který umí přeposílat datové toky RTP a s nímž komponenta P-CSCF umí spolupracovat. Ve výchozím nastavení vypisují komponenty Open IMS Core na terminál ladící hlášky (v konfiguračních souborech je nastavená úroveň „debug=3“). Při pokusech s IMS klienty jsem je nechal zapnuté, při měření výkonu pak vypnul („debug=0“), aby zbytečně nezvyšovaly režii. Komponenty pak vypisovaly pouze chybové zprávy.

- 67 -

4.2 Softwarové telefony pro IMS Než jsem se mohl pustit do jakéhokoli zátěžového testování, bylo třeba vyzkoušet, zda se dokážu na spuštěný server zaregistrovat jednotlivým IMS (IP Multimedia Subsystem) klientem a zda dokážu mezi dvěma takovými klienty navázat hovor. Tomu ovšem předcházel, jak se ukázalo, netriviální úkol – nalézt a spustit nějaký IMS klient. Stránka Open IMS Core [41], sekce častých dotazů a odpovědí, doporučuje jako IMS klienty Monster, UCT IMS Client a IMS Communicator. Dále jsem našel dokument [44], který se zabývá návrhem nového IMS klienta, ovšem zatím nenabízí žádný hotový výsledek. V tomto dokumentu je varování, že program IMS Communicator je zastaralý a již se nevyvíjí, naopak doporučuje UCT IMS Client. Zmiňuje jeden další program, Mercuro. Další zmínky o vývoji IMS klientů na internetu se většinou týkaly uzavřeného vývoje pro výrobce mobilních telefonů.

4.2.1 Monster Klient Monster je podle svých webových stránek [45] produktem Fraunhoferova institutu, stejně jako Open IMS Core. Od doby psaní stránky Open IMS Core se klient přejmenoval na „myMONSTER - Telco Communicator Suite“ a tvrdí o sobě, že je rozšiřitelnou platformou pro využití služeb IMS, podporující multimediální telefonii, zasílání správ, publikaci informací o dostupnosti a umístění a nouzové hovory. Jediná viditelná datace na webových stránkách udává rok 2009, stažený soubor instalátoru verze 0.9.19 pro Windows ale má datum listopad 2010. Jsou dostupné verze pro Linux, Windows a Windows Mobile. Licence je zdarma pro nekomerční použití s možností modifikace zdrojového kódu. Program je napsán v jazyce Java se závislostmi na externích knihovnách, jako „gstreamer“ pro zpracování multimédií. Existuje pouze vývojářská dokumentace, diskusní fórum je od roku 2009 neaktivní. Nainstaloval jsem tedy Monster a nakonfiguroval ho, aby se připojil k serveru jako [email protected], tj. vyplnil pole pro privátní a veřejnou identitu, doménu domácí dítě a ručně zadal adresu pcscf.druha.ims-test.cz:4060 pro P-CSCF (Proxy Call Service Control Function). Připojení k serveru ale selhalo a na konzoli komponenty HSS (Home Subscriber Server) se objevila zpráva „IMS_Diameter_Error_Roaming_Not_Allowed“. Hledání na internetu mi s řešením tohoto problému nijak nepomohlo, diskusí na téma Open IMS Core není mnoho, neboť se jedná o experimentální technologii. Napadlo mě ale prozkoumat webové rozhraní HSS (připojení k němu je možné ve výchozím nastavení pouze s lokálního stroje, takže jsem použil služby přesměrování portů SSH (Secure Shell)), ve kterém v záložce konfigurace sítě (Network Configuration) je možnost nastavit seznam povolených navštěvovaných sítí. V něm byla pouze výchozí doména

- 68 -

open-ims.test. Zřejmě je třeba v tomto seznamu mít i síť domácí, přidal jsem tedy svou doménu druha.ims-test.cz. Dále bylo ještě nutné povolit oběma implicitním uživatelům (Alice a Bob) roaming v této doméně (ačkoli je to jejich domácí doména), a to v menu Uživatelské identity (User Identities) – Veřejné identity (Public User Identity). Všeobecně jsem musel projít konfigurační soubory SER (SIP Express Router) a webové rozhraní FHoSS (FOKUS Home Subscriber Server) a všude domény opravit. Po opravě nastavení Open IMS Core se klientu Monster podařilo uživatele zaregistrovat (podle výpisů na konzoli serveru a záznamu paketů programem „tcpdump“), ovšem dál jakákoli jeho činnost skončila, neobjevilo se mi ani uživatelské rozhraní jiné, než to na zadání registračních údajů. Program měl zřejmě problémy s kompatibilitou s mou platformou Windows XP x64 Edition. V diskusní skupině okolo Open IMS Core je tento klient doporučovaný (ovšem ve starší verzi 0.9.13) jako zřejmě jediný s podporou IPv6 (Internet Protocol version 6) [46]. Já se s ním ale dále nezabýval. Z tohoto pokusu jsem ale zjistil, že komponenta P-CSCF má funkční podporu pro NAT (Network Address Translation). Fakt, že je klient za překladem adres, je viditelný z výpisu registrovaných uživatelů na konzoli serverů P-CSCF a S-CSCF (Serving CSCF), a v SIP (Session Initiation Protocol) odpovědích je do hlaviček Via přidáván parametr „received“.

4.2.2 IMS Communicator Jako další jsem vyzkoušel program IMS Communicator. Podle své stránky [47] je to produkt portugalské firmy Inovacao, zabývající se mimo jiné vývojem softwaru pro sítě IMS [48]. Jde o úpravu SIP klienta SIP Communicator, je psán v jazyce Java a je k dispozici pod otevřenou licencí. Vývoj se zastavil v roce 2008 a z té doby jsou k dispozici verze pro Windows i Linux. Internetová diskuse projektu existuje, ale není v ní již mnoho příspěvků. K dispozici je krátký manuál k nastavení. Stáhl jsem si verzi pro Windows a po několika pokusech se mi podařilo ji nastavit tak, aby se zaregistrovala na server. Na nastavení je silně vidět, že jde o experimentální kus softwaru, volby původního SIP Communicator pro SIP jsou promíchané s nastaveními pro IMS. Při každé neočekávané SIP zprávě zobrazí program výjimku. Nepodařilo se mi s tímto klientem zprovoznit hlasové hovory (V tom smyslu, že program neodesílal hlasové toky. Nevylučuji, že na jiné platformě bych měl větší úspěch.), nicméně SIP signalizace byla v pořádku a bylo možné posílat textové zprávy. Toto jsem ale zjistil až po nastavení dalšího klienta na jiném počítači.

4.2.3 UCT IMS Client Tímto dalším klientem byl UCT IMS Client. UCT je zkratka Univerzity v Kapském Městě, takže jde o další produkt akademické půdy, v tomto případě z Jižní Afriky. Na stránce projektu [49] je uvedeno, že cílem projektu je kompatibilita s Open IMS Core. Další související projekty jsou server a klient

- 69 -

internetové televize založené na IMS, funkce politik a účtování pro IMS a IMS B2BUA, jejich testování je ale mimo rámec této práce. Klient je šířený pod licencí GPL (General Public License) a je psaný v jazyce C. Poslední verze z roku 2009 je k dispozici jako zdrojový kód a binární balík pro distribuci Ubuntu Intrepid. Na poslední verzi distribuce Debian se mi nepodařilo binární balík nainstalovat, instalace ze zdrojových kódů je určitě možná, ale je závislá na značném množství knihoven. Proto jsem raději nasadil virtuální stroj s obrazem poněkud zastaralého operačního systému Ubuntu Intrepid, na kterém se klient nainstaloval zcela bezproblémově. Na programu je vidět, že jde o experimentální software, ovšem v dobrém slova smyslu. Vše fungovalo hladce, experimentální povaha je vidět na ovládacích prvcích programu – na hlavní obrazovce je přímo umístěn prostor, do kterého se vypisují přijaté a odeslané SIP zprávy, v menu jsou funkce „Registuj jako Alice/Bob“ a „Zavolej Alici/Boba“, které zřejmě fungují při experimentálním nasazení Open IMS Core na doméně open-ims.test. Samozřejmě existuje i možnost vyplnit si vlastní registrační údaje a volat jiné identity. Registrace uživatele na server, hlasové hovory i zprávy metodou MESSAGE fungovaly dobře.

4.2.4 Mercuro Nakonec jsem vyzkoušel IMS klient Mercuro, u nějž bylo největším problémem ho sehnat. Tento program byl produktem firmy Inexbee, která podle neoficiálních stránek projektu [50] zkrachovala v polovině roku 2010. Oficiální stránky programu Mercuro ani firmy Inexbee nejsou dostupné. Program existoval ve 3 verzích: Bronze, která byla zdarma a nabízela základí funkcionalitu, Silver s podporou IPv6, IPSec (IP Security), TLS (Transport Layer Security), SigComp a verze Gold pro korporátní zákazníky s podporou QoS (Quality of Service) a licencovaných kodeků. Byl to zřejmě jediný klient pro platformu Windows (a Windows Mobile) s takto širokou podporou funkcí. Verzi Bronze, která zabezpečení postrádá, je možné na internetu dohledat a stáhnout z pochybných zdrojů typu RapidShare. I tak bych tento program označil jako nejlepší volbu pro provozování s Open IMS Core na platformě Windows, na platformě Linux by jí pak byl UCT IMS Client. Zajímavé v této konfiguraci bylo, že hovory směrem z Mercuro na UCT IMS Client prošly v pořádku, ale opačně se nesestavily a v okně UCT IMS Client byla vidět zpráva 420 Bad Extension. Rozborem pomocí síťového analyzátoru Wireshark jsem objevil hlavičku „Unsupported: precondition“ od klienta Mercuro (který mechanismus „precondition“ související s QoS ve freeware verzi nepodporuje). Řešením bylo vypnout volbu QoS v UCT IMS Client. Výsledkem mých pokusů s IMS klienty je mimo tohoto shrnutí dostupných programů i to, že jsem odladil konfiguraci Open IMS Core a otestoval registraci, hlasové hovory a zasílání zpráv mezi dvěma počítači. Jelikož

- 70 -

v konfiguračním souboru P-CSCF nebyl nastavený RTP (Real-time Transport Protocol) Proxy, datový tok šel mezi počítači přímo (zjištěno pod Windows výpisem síťových spojení aplikací TaskInfo).

4.3 IMS Bench SIPp 4.3.1 Instalace Po otestování funkčnosti jádra IMS (IP Multimedia Subsystem) pomocí jednotlivých IMS klientů jsem pokračoval instalací distribuovaného zátěžového testeru IMS Bench SIPp. Jeho zdrojový kód jsem dle instrukcí v instalačním manuálu na stránkách projektu [51] stáhl nástrojem Subversion. Poslední verze pochází z října 2010. Před vlastní kompilací bylo třeba postarat se o závislosti programu IMS Bench SIPp. Těmi jsou matematická knihovna GSL (GNU Scientific Library) na generování statistických rozložení, „gnuplot“ na vykreslování grafů a modul XML::Simple pro Perl na čtení konfiguračních souborů. Tyto balíky se dají nainstalovat v distribucích Debian i Gentoo bez problémů. Dále manuál doporučuje překompilovat jádro operačního systému s tím, že se nastaví frekvence časovače na 1000 Hz, aby bylo možné měřit čas s přesností na milisekundy za účelem přesné reprodukce statistického rozložení (jinak může SIPp generovat požadavky v dávkách několika současně, což odporuje definici Poissonova procesu, který se snaží simulovat, viz. kapitola 3.1). Tento krok jsem vynechal, protože dnes již většina distribucí toto nastavení používá jako výchozí, navíc Linux na základních deskách s hardwarovým časovačem HPET (High Precision Event Timer) podporuje tzv. režim „dynticks“, při kterém se časovač nastavuje dle potřeby s přesností na mikrosekundy. Tato funkce je v jádře Linux od verze 2.6.21 a instalační manuál IMS Bench SIPp je psán pro jádro 2.6.18, takže je dle mého názoru neaktuální. [52, 53] Manuál ještě doporučuje zvýšit v jádře nastavení parametru UDP_HTABLE_SIZE, pokud má instance SIPp reprezentovat více než několik desítek tisíc uživatelů. Tento parametr jsem ale v jádře 2.6.32 nenalezl. Můžeme spekulovat, že byl tento subsystém jádra optimalizován a toto nastavení již nebude problémem. Vlastní kompilace se provádí standardně nástrojem „make“, je možné sestavit odděleně komponenty „manager“, SIPp a „cpumem“. Kompilace proběhla na obou používaných distribucích bezproblémově.

4.3.2 Seznámení s programem Na rozdíl od obyčejného SIPp, k jehož použití stačí jen jediný binární soubor s integrovanými testovacími scénáři, skládá se IMS Bench SIPp ze 4 různých částí a potřebuje číst různé datové soubory.

- 71 -

Manager Centrálním bodem distribuované architektury je program Manager. Je to nevelký program v C++, jehož úkolem je do vzdálených agentů SIPp zavést testovací scénáře z XML (Extensible Markup Language) souborů, jejich poměr, statistické rozložení v čase a parametry, jako doba vyzvánění a hovoru (a rozložení délek těchto intervalů). Po zavedení synchronizuje start agentů a monitoruje průběh testu, ve smyslu počtu úspěšných a neúspěšných scénářů. Průběh testu zobrazuje na konzoli a zapisuje do souboru. Podle svého konfiguračního souboru manager.xml mění v čase parametry testu, tj. poměr scénářů, statistické rozložení a střední interval jejich spouštění. Dokáže po síti posílat měřícím agentům SIPp stisky kláves a tak umožnit uživateli je centrálně ovládat.

SIPp SIPp je vlastní generátor zátěže. Na rozdíl od originální verze SIPp může mít zavedeno zároveň několik testovacích scénářů a vybírat z nich podle zadané pravděpodobnosti výskytu. Při startu načítá CSV (Comma Separated Values) soubor se seznamem uživatelů, které má reprezentovat. S těmito uživatelskými údaji pak odesílá požadavky přes testovaný systém na nějaký další agent SIPp, vybraný náhodně z množiny testovacích agentů zavedené při startu managerem (může komunikovat i sám se sebou). Vybrané uživatelské údaje komunikuje s ostatními agenty přímo. Oba agenti jsou pak na hovor mezi oběma vybranými uživateli připraveni a jsou schopni distribuovaně změřit dobu, kterou scénář trval (metriky TRT, Transaction Response Time). Uživatelé jsou udržováni v několika skupinách (pools) podle toho, zda jsou registrovaní či součástí hovoru. Významy skupin jsou konfigurovatelné v rámci testovacích scénářů, v přiložených scénářích je význam tento: Pool 0 neregistrovaní, 1 – probíhá pokus o registraci, 2 – registrovaní, 3 – účastníci hovoru. Účelem skupin je, aby se scénáře provozovaly s uživateli ve vhodném stavu, např. aby nezahajoval hovor neregistrovaný uživatel. Scénáře musí uživatele mezi skupinami přesouvat podle svého výsledku. Pokud v nějaké skupině uživatelé dojdou, začnou scénáře hlásit chyby a test selže. [55] SIPp zaznamenává průběh testu do třech CSV souborů za účelem vykreslování grafů. Do jednoho se ukládá vytížení stroje s generátorem zátěže, ve druhém je průběh testu z hlediska scénářů – čas spuštění, druh scénáře, úspěšnost a TRT mezi definovanými zprávami scénáře, v posledním CSV souboru se ukládá statistika opakovaných odesílání zpráv. Chybové zprávy program ukládá do zvláštního souboru pro každý běh testu. Jsou v nich vidět jak interní chyby generátoru zátěže (např. když dojdou v některé skupině uživatelé), tak i neočekávané SIP zprávy od testovaného systému, což je užitečné při ladění – není nutné používat externí síťový analyzátor.

- 72 -

Na konzoli vypisuje program užitečné informace jako dobu testu, rychlost generování hovorů, momentální a maximální množství probíhajících hovorů (standing call rate) a průběhy scénářů z hlediska množství zpráv, retransmisí a chyb v jejich průběhu. Mezi zobrazeními různých scénářů se přepíná klávesami ‘<’ a ‘>’. Jsou k dispozici i další statistické obrazovky, jejich informační hodnota se mi ale nezdála vysoká. Při použití nástroje IMS Bench SIPp v distribuovaném režimu musí mít uživatel na paměti, že informace zobrazované SIPp se týkají jen jedné konkrétní instance. Celkové statistiky se zobrazují na konzoli programu Manager. Chybí tam ovšem důležitý parametr počtu probíhajících hovorů, ten může člověk odhadnout tak, že vynásobí množství odečtené z obrazovky SIPp počtem agentů.

CPUmem Program „cpum“ je určen k nasazení na testovaná zařízení (může jich být i více). Jeho účel je jednoduchý, a to zaznamenávat zatížení procesoru a množství volné paměti. Nutno konstatovat, že tyto dva údaje nedávají celkový obraz o zatížení systému. Nepostihují například velikost souborové vyrovnávací paměti, odkládacího souboru, vytížení sítě nebo zatížení jednotlivých procesorů v SMP (Symmetric Multi-Processor) systému. Na druhou stranu zaznamenávání všech těchto údajů by ztížilo čtení výstupů testu. Proto jsem si s těmito dvěma údaji vystačil a ostatní sledoval v reálném čase na terminálu testovaného stroje. CPUmem se spouští na testovaném stroji ručně a jako parametr má IP (Internet Protocol) adresu stroje, kde běží komponenta Manager. Měřené údaje se posílají v reálném čase na Manager, kde se ukládají do CSV souboru. To kontrastuje s měřením zátěže strojů se SIPp (které má integrované stejné funkce jako „cpum“), ukládajících naměřené hodnoty lokálně. Zřejmě to tak bylo vymyšleno proto, aby se dal testovat i systém, ke kterému není terminálový přístup. Stačí jen poprosit správce, aby spustil „cpum“. V instalaci IMS Bench SIPp je také adresář tools/monitor, který obsahuje skripty pro vyčítání zátěže SUT (System Under Test) pomocí protokolu SNMP (Simple Network Management Protocol) a převod naměřených hodnot do CSV formátu, jsou ale evidentně určené pro čistý SIPp a s programem Manager nebudou spolupracovat. Pro případ, že by někdo testoval hardwarovou ústřednu bez možnosti spuštění binárního programu, zde existuje základ, na kterém může stavět.

Konfigurační a spouštěcí skripty Nastavení parametrů testu a generování zpráv podle specifikace ETSI TS 186 008 [54], kopírování souborů na testovací systémy, spouštění agentů SIPp a stahování výsledků zajišťují skripty napsané z větší části v jazyce Perl, některé v Bash.

- 73 -

Tyto skripty jsou uložené v adresáři scripts v instalaci IMS Bench SIPp a prvním, se kterým se setkáte, je ims_bench.pl. Tento skript slouží ke konfiguraci a přípravě testu. S uživatelem komunikuje pomocí textových menu, v nichž lze nastavit: Parametry testovacího systému – IP adresa stroje s komponentou Manager, množství a IP adresy strojů s agenty SIPp jejich umístění v adresářové struktuře a zda se mají SIPp automaticky spustit při startu Manager (tato volba mi nefungovala, nicméně existuje ještě skript na vzdálené spuštění přes SSH (Secure Shell)). Nastavuje se zde druh transportního protokolu pro SIP zprávy – TCP (Transmission Control Protocol) nebo UDP (User Datagram Protocol). V tomto menu je i volba maximálního rozdílu hodin mezi testovacími stroji a strojem s Manager v mikrosekundách. Manager zpoždění hodin při spuštění testu kontroluje a při příliš velkém rozdílu se vypne, aby zabránil naměření nesmyslných dob odezvy mezi testovacími systémy. Ve výchozím nastavení je zde hodnota 250 µs, jež se mi zdá nesmyslně přísná. Této přesnosti zřejmě lze dosáhnout na běžných PC (Personal Computer) s použitím protokolu PTP (Precision Time Protocol), já jsem nicméně nasadil synchronizaci pouze s NTP (Network Time Protocol) a přesnost hodin relaxoval na 10 ms, což je dle mého názoru hodnota zcela dostačující (z implicitní doby retransmise 500 ms představuje 2%). Parametry testovaného systému – zde se nastavuje pouze IP adresa a port komponenty P-CSCF (Proxy Call Service Control Function). Časový profil testu – v tomto menu se nastavují parametry pro vygenerování průběhu testu podle [54 1.část] a maximální chybovosti scénářů v testu (IHS, Inadequately Handed Scenarios). Generovaný průběh testu má tři hlavní části, a to předregistraci uživatelů (nastavuje se rychlost požadavků (s konstantním rozložením) a max. IHS), fázi míchání (stir), která má systém po registraci postupným aplikováním smíšené zátěže uvést do provozního stavu (nastavuje se doba, počet kroků a max. IHS), a konečně vlastní test, kdy se po krocích zvyšuje zátěž do dosažení cílové kapacity návrhu (DOC, Design Objective Capacity). U vlastního testu se nastavuje počáteční zátěž, velikost kroku, doba trvání kroku, max. počet kroků a doba hájení, ve které se neměří IHS. Složení testu – obsahuje podmenu, kde se dá nastavit poměrné zastoupení scénářů v testu a maximální IHS každého z nich (toto nastavení představuje DO, Design Objective), dále se zde nastavuje rozložení a průměrná hodnota doby vyzvánění a hovoru pro scénář navázání hovoru a rozložení a velikost zprávy pro scénář s metodou MESSAGE. Je tu i nastavení expirační doby registrací. Toto jsou zřejmě nejdůležitější parametry určující trvání a intenzitu testu. Během pokusů jsem je nastavoval na různé hodnoty, postupně od

- 74 -

nižších směrem vzhůru, jen počet kroků testu doporučuji nastavit na vysokou hodnotu, pokud uživatel předem neví, při jaké hodnotě SAPS (Session Attempts per Second) test skončí. Důvodem pro nastavení konkrétní hodnoty může také být, že tester nechce testovaný systém zcela přetížit, je-li například testování prováděno za provozu. Limit pro IHS je ve výchozím nastavení 0,1 %, což se v mém prostředí ukázalo jako nepřiměřeně nízká hodnota. Test se zastavoval při sebemenší chybě. Nastavil jsem proto tuto hodnotu vysoko, na 50 %, takže se test zastavil až při úplném přetížení systému, a krok, kdy již IHS začalo stoupat, jsem odečítal ručně ze zprávy testovacího nástroje. Směs scénářů je ve výchozím nastavení: 2,5 % registrace, 2,5 % deregistrace, 15 % reregistrace, 50 % hovor, 30 % zpráva. Myslím, že tato směs by měla rozumně reprezentovat zátěž ve špičce (kdy uživatelé aktivně volají a hovorů je tudíž více než registrací). Uživatelské účty – zde se nastavují parametry masového generování uživatelských účtů, a to formát privátních a veřejných identit a hesel (skládající se z konstantních řetězců a číselné řady), doména, ve které síť běží, a celkový počet generovaných uživatelů s údajem, kolik procent se má na začátku testu registrovat. Také je tu nastavení, které prácí s uživatelskými účty vypne a vynutí posílání SIP zpráv přímo na IP adresu a port SIPp. [55] Výchozí počet generovaných uživatelů je 24000, což je hodnota, kterou jsem původně také nastavil. Po dokončení nastavení a vystoupení z menu vygeneruje skript adresář ims_bench_0 (číslo se po každé konfiguraci zvyšuje), který obsahuje soubory scénářů, seznam uživatelských účtů rozdělený na části pro jednotlivé agenty, konfigurační soubor ims_bench.xml, který předaný jako parametr konfiguračnímu skriptu umožňuje měnit minulou konfiguraci a nezačínat od nuly, a konfigurační souboru programu Manager manager.xml. Jsou zde také skripty v Bash, a to prepare.sh, který nakopíruje agenty SIPp na testovací stroje. Před jeho spuštěním je vhodné mít nastavené přihlašování na testovací stroje pomocí SSH s RSA (Rivest, Shamir, Adleman) klíči, jinak bude nutné na každý stroj zadávat ručně heslo, ke kopírování se totiž používá nástroj SCP (Secure Copy). Druhým skriptem je run_sipp.sh, který na všech strojích spustí testovacího agenta. Lepší možností je ale použít lokálně na testovacích strojích skripty run_<číslo stroje>.sh, které tam jsou nakopírovány, což umožní sledovat na terminálech strojů průběh testu. Před spuštěním agentů SIPp je nutné spustit Manager, což se udělá z adresáře s vygenerovanými parametry testu příkazem „../manager -f manager.xml“, který ostatně vypíše po svém skončení jako nápovědu skript prepare.sh. Agent CPUmem může běžet neustále, pouze když není k dispozici Manager, tak vypisuje chyby.

- 75 -

Před spuštěním SIPp se ještě ukázalo, že je nutné zvýšit systémový limit počtu otevřených souborových deskriptorů, protože SIPp hned při startu začne naslouchat na jednom portu pro každého nastaveného uživatele. Počet simulovaných uživatelů také nejpodstatněji ovlivňuje spotřebu paměti SIPp, při čísle 24000 to bylo asi 150 MB. Zvednutí limitu se docílí příkazem „ulimit –n 65535“. Po spuštění testovacích agentů je třeba už jen v terminálu s programem Manager stisknout klávesu E a test se rozběhne. (Tedy pokud funguje synchronizace hodin testovacích strojů.)

Generátor zprávy o testu Po prvním úspěšném běhu (který chronologicky následoval po zavedení uživatelů, viz. další kapitola) jsem mohl vyzkoušet skripty na generování zprávy o testu. Po dokončení úspěšného průběhu testu se použije nejdříve skript getResults.pl, který stačí spustit s aktuálním adresářem nastaveným na ims_bench_<pořadí>. Skript se postará o stažení CSV souborů z testovacích strojů pomocí SCP a o jejich spojení do jednoho souboru s položkami řazenými podle času. Nakonec se z adresáře s testem spustí doReport.pl, který vygeneruje HTML (Hypertext Markup Language) soubor s výsledky testu, voláním „gnuplot“ vykreslí grafy a přiloženým skriptem html2mht.pl převede na MHTML (Multipurpose Internet Mail Attachment HTML) archiv (lze zakázat). Parametry zprávy, jako generované části zprávy, znění vložených textů, formát a popisky grafů a zda se zobrazí poslední krok měření (ve kterém SUT selhal), lze ovlivnit konfiguračním XML souborem reportConfig.xml v adresáři scripts. Příklad výsledné zprávy o testu je možné vidět v manuálu IMS Bench SIPp na [51], zprávy z průběhů testů naměřených v rámci této práce jsou k nalezení v příloze.

4.4 Zavedení uživatelů V minulé kapitole jsem popsal postup spuštění IMS Bench SIPp. Testovací běh ovšem v současném stavu pouze generoval chyby, protože chyběly testovací uživatelské účty na serveru Open IMS Core. Ruční zadávání uživatelů přes webové rozhraní HSS (Home Subscriber Server) je sice možné, a má tu výhodu, že člověk zjistí, jaké všechny parametry lze či je nutné nastavit, na zadávání desítek tisíc uživatelů je ale nepoužitelné. K Open IMS Core je ale přiložen skript add-imscore-user_newdb.sh, který slouží k přidání uživatelů včetně všech druhů identit a vazeb mezi nimi přímo do databáze MySQL. Tento skript ovšem přidává pouze jednoho uživatele, takže bylo nutné napsat jednoduchý skript na variaci jeho parametrů:

- 76 -

#!/bin/bash for i in `seq -w 0 24000`; do ./add-imscore-user_newdb.sh -u test$i -r druha.ims-test.cz -a done

Parametr -u určuje jméno vytvářeného uživatele (stejné jméno pro privátní a veřejnou identitu a heslo; jiné parametry je umožňují nastavit také odděleně), -r určuje doménu a -a způsobí přidání záznamu do databáze (alternativně –d záznamy odstraňuje). Po vyzkoušení doporučuji ještě volbu -c, která způsobí odstranění vytvořených SQL (Structured Query Language) skriptů, které jinak zaberou dost diskového prostoru. Přiložený skript na přidání uživatele ale nefungoval, musel jsem v něm opravit 2 chyby, a to: skript počítá s možností přihlášení k databázi MySQL jako uživatel „root“ bez hesla. Upravil jsem ho tak, že uživatele a heslo lze zadat jako proměnné uvnitř skriptu, poblíž jeho začátku. Tyto proměnné jsou pak předány na příkazovou řádku příkazu „mysql“ volaného skriptem. Druhá chyba spočívala v tom, že ani poté, co skript dokázal do databáze uživatele přidat, nebyly jejich účty funkční. Pokus zaregistrovat vytvořeného uživatele pomocí některého IMS (Internet Multimedia Subsystem) klienta skončil chybovou odpovědí 600 Busy Everywhere - Empty list of S-CSCFs. Pohledem do webového rozhraní HSS jsem zjistil, že na rozdíl od funkčních uživatelů nemá nově přidaný vyplněno v sekci „IMS Subscriptions“ preferované S-CSCF (Serving Call Service Control Function). S-CSCF se nastavují ve skupinách v sekci „Network Configuration – Preferred S-CSCF Sets“. Pohledem do databáze (doporučuji interaktivní prohlížeč SQL databází Emma) jsem zjistil interní název nevyplněného pole, a do skriptu přidávajícího klienty do databáze přidal toto pole (id_preferred_scscf_set), nastavené pevně na první skupinu S-CSCF v databázi (ID 1). V případě distribuce tohoto skriptu by bylo vhodné exportovat toto nastavení jako parametr skriptu. Upravený funkční skript je v příloze práce. Po opravě skriptu jsem do databáze zavedl doporučované výchozí množství 24000 uživatelů. Zvolený návrh skriptu v Bash není výkonově optimální kvůli velkému množství systémových volání na vytváření nových procesů. Režie jejich inicializace způsobila, že skript běžel několik desítek minut, ale vzhledem k tomu, že se jedná o jednorázovou akci, je toto přijatelné. Velké množství uživatelských účtů v databázi je vzhledem k návrhu IMS Bench SIPp (konformním s doporučením ETSI [54]) nutné, a podmiňuje maximální dosažitelnou hodnotu současného počtu hovorů (standing calls). Dojdou-li agentu SIPp uživatelské účty, přestane generovat SIP provoz a do záznamu začne hlásit chyby typu „pick_user() returned NULL in pool 2.“ a „Action 'move_user' without a user assigned!.“ (Viz. odstavec o SIPp agentu v kapitole 4.3.2 a [55].) Na Manager pak hlásí neúspěšné scénáře a test předčasně skončí. Řešením je buďto zkrátit intervaly vyzvánění a hovoru nebo zavést do databáze více

- 77 -

uživatelů a vygenerovat nové CSV (Comma Separated Values) soubory s účty pro SIPp agenty. V průběhu měření jsem použil obě řešení, validitu prvního argumentuji tím, že Open IMS Core v použitém nastavení velký počet souběžných hovorů nijak zvlášť nezatěžoval. Přes server nešly žádné datové toky, které by spotřebovávaly šířku pásma sítě, natož pak zatěžovaly CPU (Central Processing Unit) překódováním kodeků. Byla vidět závislost paměťové náročnosti S-CSCF na počtu současně registrovaných uživatelů (Při 100 000 registrovaných uživatelích, viz. níže, byla téměř 1 GB, ale toto číslo pouze rostlo, po vypršení expirační doby registrací se žádná paměť neuvolnila a při dalších opět rostla.), a je možná závislost spotřeby paměti serverů P-CSCF (Proxy CSCF) a S-CSCF na počtu současných dialogů, ale při tomto množství uživatelů a dostupné paměti se výrazně neprojevila. Naopak velikost databáze se již pohybovala v jednotkách GB, takže se dá předpokládat, že diskový prostor by došel dříve, než paměť, nebo by paměť dříve zabraly tabulky registrací. Počet současných hovorů (standing call ratio) má v této konfiguraci zanedbatelný vliv na výkon v porovnání s rychlostí příchodu SIP zpráv.

- 78 -

4.5 Testovací pokusy, pozorování 4.5.1 Prvotní pokusy, ladění parametrů Open IMS Core První pokusy s měřícím systémem IMS Bench SIPp jsem provozoval na svém domácím serveru. Parametry nejsou důležité, protože z této fáze nepředkládám žádné zprávy o měření, ale jednalo se o stroj Intel Atom N270 1,6 GHz, 1 GB RAM, OS Debian 6, architektura i686. Na počítači běžel jak Manager, tak SIPp. Internetová linka byla zajištěna přes CZFree.Net s několika segmenty na různých bezdrátových technologiích. Maximální propustnost 4 Mb/s symetricky, bez veřejné IPv4 (Internet Protocol version 4) adresy a zajištění QoS (Quality of Service). Zpočátku jsem intenzity zátěže nastavil velmi nízké, to je například ve fázi počátečních registrací 10 SAPS (Session Attempts per Second), míchací fáze dvě minuty od 2 do 10 SAPS a hlavní testovací fáze od 10 SAPS dále s krokem 10 za dvě minuty. Měřil jsem s výchozím poměrem scénářů Zjistil jsem, že výchozí hodnota limitu IHS (Inadequately Handled Scenarios) 0,1 % je nereálná. I při tak nízkých zátěžích jako 6 SAPS přesahovalo množství chyb limit a test se ukončoval. Proto jsem ho zvýšil přes 10 % až na finálních 50 %, při kterých automatický test zachytí již jen fatální chyby a interpretace výsledku je zcela na uživateli. Důvodem byla hlavně výpadkovost paketů na mé WiFi (Wireless Fidelity) lince, která občas dosahuje až 5 % (Kterážto hodnota není v bezdrátových a mobilních sítích nic neobvyklého.). V souvislosti s tím jsem ve výpisech SIPp viděl občasné SIP (Session Initiation Protocol) zprávy 480 Request Timeout.

Problém s limitem sdílené paměti Horší chybou ale byla 500 Error forwarding towards next S-CSCF, kterou začal posílat I-CSCF (Interrogating Call Service Control Function) server po asi 2400 úspěšně registrovaných uživatelích. Zároveň hlásil na terminálu „failed to resolve "scscf.open-ims.test"“, což mi bylo podezřelé natolik, že jsem vyhledával tento řetězec v databázi i v celém instalačním adresáři Open IMS Core s tím, že jsem zřejmě někde zapomněl změnit doménu. Ukázalo se, že ze všech konfiguračních souborů a databáze byl odstraněn, ale je nastaven jako výchozí hodnota na mnoha místech zdrojového kódu. Důvodem chyby byl zvláštní stav, do kterého se dostal S-CSCF (Serving CSCF). Projevoval se zprávami „Error retrieving an auth vector“ na terminálu, které by ukazovaly na rozpad komunikace s HSS (Home Subscriber Server), a jeho odstranění bylo možné jen restartem komponenty S-CSCF, po které registrace okamžitě zase začaly probíhat. Internetové diskuse jako obvykle při problémech s IMS (IP Multimedia Subsystem) nepomohly, dokonce ani dotazy do diskusní skupiny. Již jsem se chystal testování ukončit s tím, že S-CSCF nesnese více než 2000

- 79 -

registrovaných uživatelů a měřit s tímto faktem omezeným maximálním počtem současných hovorů, když jsem čirou náhodou objevil parametr -m programu SER (Sip Express Router), který určuje maximální hodnotu sdílené paměti mezi obslužnými procesy. Ve výchozím stavu spouštěly skripty pcscf.sh, icscf.sh a scscf.sh SER s tímto parametrem nastaveným na 32 (MB). Po zvýšení na 1024 potíže přestaly a bylo možno zaregistrovat celých 24000 uživatelů.

Problém s NAT (Network Address Translation) Po překonání potíží s úvodními registracemi jsem narazil na problém, který mě přiměl svůj domácí server opustit a přesunout se s testováním do lepších podmínek. Projevoval se selháváním scénářů postupně narůstajícím v čase a zprávami „P-CSCF:Found old received parameter!! This might indicate an attack.“ a „S-CSCF: no matching auth vector found - maybe timer expired“. Jako zdroj problému jsem identifikoval expirující mapování portů na NAT u mého poskytovatele internetu. K tomuto NAT jsem neměl přistup a tedy nemohl zvýšit trvanlivost mapování. V manuálu k IMS Bench SIPp na [51] je sice zmínka o nové funkci udržování NAT spojení pomocí prázdných UDP (User Datagram Protocol) paketů (originální SIPp ji nemá), které jsou posílány periodicky na testovaný systém, povolí-li se tato funkce na příkazové řádce a ještě upraví testovací scénáře z případu užití registrace, aby po registraci uživatele funkci zapnuly a po deregistraci vypnuly, ale rozhodl jsem se tuto funkci nepoužít, protože by zvýšila zatížení procesorů testovaného i testovacího stroje (v manuálu je varování o neefektivní implementaci) a generovala zbytečný síťový provoz.

4.5.2 Přesun na finální platformu, potíže se stabilitou serveru Testovací prostředí Místo obcházení problémů s NAT jsem se, tuše, že bych na svém slabém stroji a internetové lince narazil na další překážky, přesunul na testovací stroj zapůjčený Katedrou kybernetiky na Karlově náměstí. Stroj měl následující parametry: CPU: Intel Xeon 5130 , 2 jádra, každé 2 vlákna, frekvence 2 GHz RAM: 4 GB HDD: 80 GB Síť: 1 Gb/s Ethernet Operační systém: VmWare ESXi 4 Na hypervisor ESXi jsem po síti nakopíroval již zmíněný obraz operačního systému Ubuntu Intrepid pro 32 bitovou architekturu (důvod jeho použití je ten, že již jsem ho měl připraven z fáze testování IMS klientů, viz. kapitola 4.2.3), rezervoval jsem mu (po předchozích zkušenostech se spotřebou paměti SIPp) 256 MB operační paměti a přidělil maximální prioritu na CPU

- 80 -

(Central Processing Unit). Procesor jsem virtuálnímu počítači přidělil jen jeden, protože SIPp běží jako jednovláknový proces a SMP neumí využít. Mimo mého měření běžel na hypervisoru ještě centrální server experimentální cloud computing platformy Eucalyptus, který fyzický počítač vytěžoval jen minimálně, protože cloud computing se na Katedře kybernetiky provozuje pouze v noci a ve dne slouží výpočetní uzly jako výukové počítače pro studenty. Mezi testovaným a testovacím strojem byly v tomto případě linky interní sítě FEL ČVUT a síť Pasnet. Podle mých informací mají všechny propustnost alespoň 100 Mb/s, ne-li 1 Gb/s. Během testu nevykazovala síť žádnou pozorovatelnou variaci zpoždění nebo výpadky.

Měření se smíšenými scénáři Po přesunu do lepšího testovacího prostředí jsem nastavil vyšší rychlosti generování hovorů. Jmenovitě úvodní fázi registrací jsem nastavil na 33 SAPS (Session Attempts per Second), kteroužto hodnotu jsem empiricky určil jako optimální při předchozích pokusech. Fáze míchání trvala 2 minuty a měla 4 fáze od 50 do 200 SAPS, testovací fáze začínala na 200 SAPS se zvyšováním o 50 SAPS po 2 minutách. Stále jsem používal výchozí směs testovacích scénářů. S tímto nastavením snesl testovaný systém 250 SAPS, ale ke konci tohoto intervalu, těsně před zvýšením, spadl. Ohodnocení kapacity DOC (Design Objective Capacity) by tedy vycházelo na 200 SAPS. Zpráva o výsledku testu je 1. přiložená. Z grafů můžeme vidět, že pád P-CSCF (Proxy CSCF) se projeví náhlým zvýšením spotřeby CPU a paměti, po ukončení procesu se zprávou „Segmentation fault“ se oba prostředky uvolní a systém přestane akceptovat SIP zprávy. Vliv jazyka Java Na grafech IHS (Inadequately Handled Scenarios) a retransmisí se objevují ke konci periody registrací dvě špičky a dále přibližně se stejnou periodou pokračují. Původně jsem myslel, že jsou to očekávané přechodné jevy, kvůli kterým standard ETSI [54] zavádí dobu hájení, ale ukázalo se, že špičky nastávají až nějakou dobu po zvýšení zátěže. Jsem přesvědčen, že tyto špičky jsou následkem spouštění sběrače odpadu (GC, Garbage Collector) virtuálního stroje jazyka Java a že perioda 2 s je buď nějakým vnitřním parametrem virtuálního stroje Java nebo že jde o čistě náhodnou hodnotu vyplývající z rychlosti zaplňování paměti. Toto tvrzení podporuje pozorování chování systému v reálném čase pomocí nástroje „top“ s odděleným zobrazením jednotlivých CPU. Na něm bylo vidět více, než na výstupu CPUmem, zachyceném na grafu a představujícím celkové vytížení všech CPU.

- 81 -

Vlastní FHoSS (FOKUS Home Subscriber Server) je psaný vícevláknově. Během fáze registrací byla všechna CPU vytížena přibližně stejně, VM (Virtual Machine) Java spotřebovával většinu výkonu, kolem deseti procent vzal server MySQL a procesy SER pouze několik procent. Během doby, kdy nastala špička v neobsloužených registracích jsem pozoroval, že jedno CPU je vytíženo na 100%, zatímco ostatní výrazně méně. Tento stav nastal, když spotřeba paměti VM (Virtual Machine) Java dosáhla (z původních asi 150 MB po startu FHoSS) hodnoty 1,1 GB, tedy asi čtvrtiny fyzické paměti. Z toho soudím, že VM Java se dostal do stavu paměťové nouze a spustil sběrač odpadu, což je evidentně neškálující sekvenční proces, který navíc zabraňuje v běhu užitečným procesům obsluhujícím registrace, a způsobil tak nadměrné prodlevy, které měřící systém vyhodnotil jako nedostatečně obsloužené scénáře (IHS). Diagnostika nestability P-CSCF Na pád P-CSCF jsem zprvu reagoval tak, že jsem měl výsledek 200 SAPS za finální, a pokusil se nastavit parametry testu tak, aby daly lépe vypadající zprávu s více stupni zátěže. Změnil jsem tedy iniciální zátěž na 100 SAPS a test spustil znovu. Výsledkem je nejčistěji naměřená zpráva celého pokusu, číslo 2 v příloze. Sice i při tomto testu došlo k pádu (těsně na pravém okraji grafů), ale ten nastal až po klasickém přetížení testovaného systému, které nastalo při 300 SAPS. Zatížitelnost DOC tedy vyšla 250 SAPS, což je hodnota finální a reprodukovatelná. Přetížení opět není na grafu viditelné, protože ho způsobil sekvenční proces, který přetížil jeden ze čtyř CPU. V dalších pokusech, zachycených ve zprávách číslo 3 a 4 (Počet provedených pokusů zdaleka neodpovídá počtu přiložených zpráv, byly vybrány jen ty s nějakou vypovídací hodnotou.), jsem se pokusil pokus zopakovat s delšími kroky měření, postupně 4 minuty a 10 minut. Výsledkem jsem ale byl zklamán, protože s delšími intervaly zvyšování zátěže jsem nebyl schopen původní výsledek reprodukovat. Test skončil vždy pádem komponenty P-CSCF, a ten nastal při tím nižší hodnotě scénářů za vteřinu (SAPS), čím delší byly kroky; jmenovitě při 200 SAPS při čtyřminutových krocích a 150 SAPS při deseti minutách. Hodnoty DOC by byly ještě o 50 SAPS (výška kroku) nižší. Na základě pozorování, že celková hodnota počtu hovorů na terminálu SIPp byla při pádu testovaného systému vždy kolem 200 000, spekuluji, že v komponentě P-CSCF je chyba typu únik paměti (memory leak), která vždy po více méně konstantním množství hovorů způsobí přetečení nějakého pole či podobného kontejneru, které není adekvátně ošetřeno. Následně začne proces nekontrolovatelně narůstat ve spotřebě paměti a poté, co přepíše nějaký důležitý ukazatel, je ukončen operačním systémem.

- 82 -

Tento problém jsem se pokusil řešit nejdříve s diskusní skupinou Open IMS Core (odkaz [56] a navazující zprávy shrnují celou moji konverzaci s diskusní skupinou), kde mi ovšem nebyla nabídnuta žádná užitečná rada, mimo toho, že jde zřejmě o únik paměti. Výpis obsazení paměti, který mi poradil Dragos Vingarzan, neobjevil žádnou abnormálně rostoucí položku. Rada, že vytvářím dialogy, ale neukončuji je, se mi nezdá validní, protože scénář hovoru je ukončen metodou BYE, která dialog zavírá. Dále jsem se pokusil zopakovat dříve úspěšný trik se zvýšením limitu sdílené paměti. Zvýšil jsem limit na 4 GB, ačkoli procesy P-CSCF zdaleka nezabíraly 1 GB RAM (Random Access Memory), ale jediným výsledkem bylo, že P-CSCF během pádu obsadil skutečně veškerou paměť. Z toho soudím, že problém není ve strukturách v paměti sdílené mezi procesy, ale v paměti vlastní jednotlivým obslužným procesům. To podporuje i fakt, že při zvýšení počtu obslužných procesů z výchozích čtyř na vyšší hodnotu, se pád procesu oddálí. Toho jsem pak využil při měření s vyššími rychlostmi generování zpráv, kdy celkový počet zpráv rychle narůstá. S počtem procesů ovšem roste i výkon zmařený jejich přepínáním a paměť obsazená jejich privátními daty. Zvyšování počtu procesů tedy problém uspokojivě neřeší. To, že je pád interně závislý na celkovém počtu zpráv, spíše než na rychlosti jejich příchodu či množství současných hovorů, dokazují měřící zprávy 5 a 6, kdy byl testovaný systém zatěžován po dobu 10 a 30 minut zátěží 200 SAPS a kde ve zprávě č.5 skončí měření při přechodu na 250 SAPS, ale v č.6 spadne pouze asi o minutu později, při absenci jakéhokoli přechodového jevu. Na těchto zprávách jsou také vidět periodické „vlny“ v grafu IHS, způsobené spouštěním sběrače odpadu.

Měření pouze registračních scénářů Protože jsem dříve empiricky určil nejvyšší hodnotu množství registrací za sekundu na 33 rps (Registrations per Second), a test se smíšenými scénáři dával daleko lepší výsledky, a zdálo se mi, že komponenta HSS (Home Subscriber Server) je limitujícím článkem celého systému, rozhodl jsem se ještě změřit odděleně scénáře zabývající se registrací a hovory. Výsledkem přiložená zpráva číslo 7, která byla naměřena pouze se scénáři zahrnujícími HSS, tj. registrace, deregistrace a reregistrace (Reregistrace probíhaly, podle výstupu počtu zpráv na terminálu SIPp, stejně jako registrace, tj. včetně výpočtu autentizačních funkcí.). Fáze úvodní registrace, nutná kvůli mechanismu skupin (pools) uživatelů, byla provedena s osvědčenou rychlostí 33 SAPS, míchání trvalo minutu a mělo 2 stupně, 5 a 10 SAPS, vlastní test běžel od 10 SAPS s krokem 10 SAPS po 2 minutách. Test se zastavil na 70 SAPS naprostým přetížením testovaného systému, které se opět projevilo vytížením pouze jednoho ze čtyř CPU na 100%. Nyní

- 83 -

tedy nastává otázka, co prohlásit za finální hodnotu DOC. Zodpovědět ji není triviální, protože chování VM Java je poměrně nepředvídatelné. Test běžel, jako ostatně všechny, s čerstvě restartovaným FHoSS, ovšem již na konci periody předregistrací došlo k zaplnění paměti po limit daný VM Java, takže běžel celou dobu na hranici paměťové nouze. Okamžik zastavení testu by ukazoval na DOC 60 rps, ovšem už v této fázi vyskočila hodnota IHS na poměrně dlouhou dobu na 100%. I při hodnotě 50 SAPS je poměrně velká špička, během níž server neobsluhoval požadavky. Klonil bych se, i na základě předchozích pozorování, k závěru, že systém nezvládne bez problému množství registrací větší, než 40 rps.

4.5.3 Distribuovaný režim – hovorové scénáře Po změření chování systému pouze pod registrační zátěží jsem přešel k měření zátěže pouze hovorové. Do testu jsem zahrnul pouze jeden scénář, navázání hovoru (Odpovídající scénář pro UAS (User Agent Server) se zavedl automaticky.). Záhy jsem ale narazil na limit testovacího systému; při 500 cps (Calls per Second) se přetížil CPU stroje se SIPp a test selhal. Nutno konstatovat, že počet hovorů zpracovaných jediným testovacím strojem je efektivně dvojnásobný, protože se chová jako UAC (User Agent Client) a zároveň na své požadavky jako UAS odpovídá. Usoudil jsem tedy, že nastal čas přejít na distribuovaný režim měření, a udělal kopii zmíněného VM se systémem Ubuntu Interpid, oběma virtuálním strojům jsem pak přidělil stejné prostředky a spustil je. Bylo by sice možné spustit na jednom víceprocesorovém počítači více instancí SIPp, případně mu i přidělit více IP (Internet Protocol) adres, ale pak by během práce nedošlo k vyzkoušení distribuované architektury testu. Rád bych zde zmínil pozorování, že maximální počet uživatelů představovaných jedním SIPp na jedné adrese je 65536 (teoreticky, v praxi o něco méně), protože každý uživatel, aby byl rozlišitelný, musí být registrován s jiným UDP portem, jejichž adresní prostor je 16 bitový. Proto (a kvůli údajným problémům se škálovatelností velkého množství otevřených portů u jádra Linux [51]) má SIPp i volbu rozdělení uživatelů na více IP adres. Toto nastavení jsem ale nezkoušel, tolik uživatelů jsem nepotřeboval.

Dva stroje Se dvěma testovacími systémy byla naměřena zpráva č.8. Nastavení testu zde bylo omezeno dvěma faktory, jednak nestabilitou P-CSCF, která mě donutila zkrátit testovací kroky ze 2 min na 20 s s pětisekundovou dobou hájení, a také počtem uživatelů zavedených do systému, který při dosahovaných počtech souběžných hovorů přestával stačit i na takto krátký test; při 1000 SAPS uživatelské účty došly a test havaroval. Zároveň je již při 900 SAPS vidět, že se na testovacím systému přetěžují procesory. Zpráva 8 tedy nepřináší žádný validní závěr, ale je na ni možno pozorovat, že kolem 1000 cps se zatížení procesoru testovaného systému dosahuje 50%,

- 84 -

z čehož jsem usoudil, že finální limit bude kolem 2000 cps a přidal do testovacího systému další dva virtuální stroje. Také jsem do databáze zavedl více uživatelů, celkem 100000, což je zhruba čtyřnásobek původního počtu, což by mělo být více než dostatečné k tomu, aby mě již jejich počet nelimitoval.

Čtyři stroje Zpráva 9 je již naměřena se čtyřmi testovacími stroji při větším počtu registrovaných uživatelů a stejné délce kroku, tedy 20 s. Zatížení během testu stoupalo v krocích po 100 SAPS od 400 SAPS až na hodnotu 1800 SAPS, které ale nebylo reálně dosaženo. Při ohledání tabulek ve zprávě zjistíme, že při 1400-1500 SAPS se přetížil testovací stroj. To podporují i hodnoty zatížení CPU testovaného stroje, které za hranicí 1400 cps nestoupají. Extrapolací ze zatížení CPU testovaného systému v bodě 1400 cps dostáváme opět hodnotu očekávané zatížitelnosti 2000 cps. Dosažená hodnota 1400 SAPS je očekávatelná a ve skutečnosti představuje oproti původním 1000 SAPS lineární škálování testovacího systému. Důvodem je, že testovací server neměl ve skutečnosti čtyři procesorová jádra, jak jsem si původně myslel, ale pouze dvě s technologií HyperThreading, jejíž výkonový zisk obecně bývá kolem 30-50%. Bohužel, vyšších hodnot se mi již během měření nepodařilo dosáhnout. I replikace těchto výsledků byla téměř nemožná kvůli nestabilitě testovaného systému. V tomto bodě jsem se pokoušel nalézt řešení nestability. Vzhledem k tomu, že ze záznamů služby Subversion projektu Open IMS Core vím, že na programu SER (SIP Express Router) probíhají opravy chyb, pokusil jsem se přeinstalovat ho poslední verzí. Stažení poslední verze a její kompilace proběhly bez problémů, ovšem pády aplikace přetrvaly. Pokusil jsem se získat přístupové údaje k systému na sledování chyb projektu, ale neobdržel jsem je. Na zprávy do diskusní skupiny jsem další reakce neobdržel. Nejlepší možnost oddálení pádu, na kterou jsem přišel, bylo zvýšení počtu obslužných procesů P-CSCF. Jejich počet jsem z původní hodnoty 4 zvýšil postupně až na 64 a s tímto nastavením byla naměřena zpráva č. 10. Profil testu byl zvolen od 1000 SAPS po 100 SAPS, délka kroku 2 min. Test skončil při 1300 SAPS pádem P-CSCF, již při 1200 SAPS ale vykazoval velké množství selhaných scénářů. DOC tedy vyšel pouze 1100 cps, což bylo daní za zvýšený počet procesů, který ovšem pádu nezabránil, ale pouze ho oddálil z celkového množství hovorů kolem 200 000 na asi 2 000 000. Zvýšené zatížení je vidět na grafu CPU testovaného stroje. Další pokusy jsem kvůli nestabilitě testovaného systému již neprováděl. I kdybych nasadil další testovací stroje a přidal je do distribuovaného systému, dosáhnout vyšších čísel by bylo prakticky nemožné, protože při dosahovaných hodnotách hovorů za sekundu rostl celkový počet hovorů tak rychle, že pád P-CSCF nastal vždy do několika minut. Práce v režimu, kdy se půl hodiny

- 85 -

provádí registrace uživatelských účtů bržděná pomalým HSS a jen několik minut běží test, je totiž vysoce neproduktivní.

Dodatek k distribuovanému testování Rozdíl v použití IMS Bench SIPp na jednom stroji a distribuovaně je minimální, způsob použití je stále stejný. Jen je třeba definovat v konfiguraci více testovacích agentů a při testu je spustit. Konfigurační soubor manager.xml je poněkud nejednotný v tom, zda jsou hodnoty globální, či se násobí počtem testovacích agentů. Například hodnoty SAPS jsou globální a nastavená hodnota je skutečně ta, co dorazí na testovaný systém, naopak počet registrovaných uživatelů platí pro každý testovací systém, takže nastavení 20 000 při 4 testovacích strojích zaregistruje 80 000 uživatelů. Při více než jednom testovacím stroji se musí dát pozor při čtení obrazovek SIPp, protože zobrazované hodnoty platí pouze pro jeden konkrétní testovací stroj. Hodnoty jako počet souběžných hovorů nebo celkový počet hovorů, které nejsou na konzoli Manager k dispozici, si musí člověk násobit v hlavě. V jednom běhu testu nelze mít zároveň uživatele představující poměrem scénářů domácnosti a call centra, je třeba buď sestavit celkový pravděpodobnostní model všech uživatelů, nebo využít možnosti provozu na pozadí (background traffic), kterou standard ETSI [54] nabízí. Na rozdíl od testu s jedním strojem mohou nastat potíže se synchronizací času, které jsem ve svém malém testovacím prostředí řešil vynuceným voláním „ntpdate“, ale při nasazení na větší počet strojů by bylo nutné buďto nasadit protokol PTP dle doporučení z manuálu na stránkách IMS Bench SIPp [51], nebo dále relaxovat požadavky na měření času. Při nastavení více testovacích strojů se rozdělí automaticky generovaný seznam uživatelských účtů na části, které se kopírují na testovací stroje. Při změnách konfigurace testovacího systému jsem si všiml vyššího poměru neúspěšných registračních scénářů a vyšší spotřeby CPU procesem MySQL, způsobené zřejmě přepisováním záznamů o IP adresách v databázi. Uživatel by tedy dosáhl realističtější zátěže simulující pohybující se uživatele, kdyby mezi testy soubory s uživateli promíchal.

- 86 -

5 Závěr Práce se zabývá tematikou měření výkonnosti sítí IMS (IP Multimedia Subsystem). Než se ale začne věnovat tomuto tématu, rozebírá ve druhé kapitole obecné vlastnosti internetové telefonie, její historii a problémy, se kterými se přenos hlasu po datových sítích obecně potýká. Mluví o jejích možných použitích a jejich výhodách a nevýhodách. Dále se přesouvá k popisu protokolu SIP (Session Initiation Protocol), na kterém je síť IMS z větší části založena. Znalost tohoto protokolu až na úroveň jednotlivých hlaviček a jejich významu je pro měření výkonu zásadní, neboť bez ni by bylo nemožné diagnostikovat jakékoli selhání. Od protokolu SIP se přesouvá jeho nejnovějšímu způsobu nasazení, tedy sítím IMS. Shrnuje jejich vlastnosti, odlišnosti od klasického nasazení SIP, identifikuje vrstvy sítě a popisuje funkcionalitu jednotlivých jejích prvků a rozhraní mezi nimi. Nakonec se mluví o jediné v současné době dostupné, více méně funkční, otevřené implementaci jádra IMS sítě, Open IMS Core [41]. Ve třetí kapitole se práce věnuje svému primárnímu cíli, tedy návrhu metody měření propustnosti sítě IMS z hlediska hovorové zátěže na protokolu SIP. Začíná lehkým teoretickým úvodem do problému z hlediska teorie hromadné obsluhy, s pomocí standardů IETF (Internet Engineering Task Force) popisuje měřené veličiny kvalitativní a výkonnostní a s pomocí několika krátkých vědeckých prací ilustruje obvyklé metody jejich sběru. Po analýze dostupných měřících nástrojů pro SIP servery s důrazem na podporu standardů použitých v sítích IMS a distribuované generování zátěže se ustaluje na měření dle standardu ETSI TS 186.008 [54] s použitím volně dostupného programu IMS Bench SIPp [51]. V kapitole čtvrté se pouští do splnění svého sekundárního cíle, tedy ověření navržené metody a změření výkonnosti předloženého testovacího serveru Open IMS Core. Nejdříve zkoumá vlastnosti testovaného systému, pak se věnuje srovnání dostupných softwarových telefonů pro IMS a zároveň úpravě konfigurace Open IMS Core, aby se s těmito klienty daly realizovat hovory. Pak podrobně rozebírá vlastnosti nástroje IMS Bench SIPp, jeho komponent a možností konfigurace, a po popisu možností zavedení velkého množství simulovaných uživatelů do databáze Open IMS Core nasazuje tento nástroj na testování pokusné sítě, nejdříve zkusmo, přičemž je odladěno několik problémů testovaného systému, pak na ostré konfiguraci testovacího systému. Měření bohužel prokázalo pravdivost citátu ze stránky referencí Open IMS Core [41] o nemožnosti nasazení tohoto balíku bez dozoru ani v laboratorním prostředí. Tento systém se vskutku ukázal být tak nestabilním, že se v žádném případě nedá doporučit jeho nasazení v produkčním prostředí (čímž bohužel padlo mé očekávání, že by Open IMS Core mohlo být platformou pro snadné spojování firemních VoIP (Voice over Internet Protocol) sítí, uvedené v úvodu).

- 87 -

Programátoři z institutu Fraunhofer FOKUS na tomto programovém balíku demonstrovali nevýhody obou použitých programovacích jazyků, C i Java. Součásti psané v C vykazují značnou nestabilitu a evidentní chyby typu úniku (leak) či přinejmenším fragmentace paměti, naopak FHoSS (FOKUS Home Subscriber Server) psaný v Java je sice stabilní, ale ve srovnání se zbytkem systému je extrémně pomalý, vykazuje spotřebu paměti neúměrnou svému účelu a periodická zastavení činnosti vlivem spuštění sběru odpadu (garbage collection) ve VM (Virtual Machine) Java. Na druhé straně, projekt Open IMS Core předem varuje, že nikdy nebyl zamýšlen jako produkční systém a nikdy jím asi nebude. Přesto slouží v telekomunikačních laboratořích po celém světě a svou snadnou dostupností a otevřenou povahou jim umožňuje dělat výzkum zaměřený na IMS. Svou funkcionalitou (nikoli stabilitou) se stal uznávanou, de-facto referenční, implementací jádra IMS sítě. Pokud odhlédneme od problémů se stabilitou, je DOC (Design Objective Capacity) testovaného systému 250 SAPS (Scenario Attempts per Second) při měření se smíšenou zátěží registrací, pokusů o hovor a textových zpráv v poměru daném výchozím nastavením nástroje IMS Bench SIPp (Bohužel nikoli v poměru daném standardem, protože nástroj implementuje standard jen částečně, viz. kapitola 4.3.2) Vliv neefektivní implementace HSS (Home Subscriber Server) byl demonstrován měřením pouze scénářů z případu užití registrace, kdy DOC byla odhadnuta na 40 rps (Registrations per Second). Argument ospravedlňující výkon FHoSS tím, že zpracování registrací musí být pomalejší kvůli výpočtům autentizačních algoritmů, není pravdivý, protože zátěž CPU (Central Processing Unit) počítače se SIPp, provádějícího stejné výpočty, byla pouze několik procent. S výkonem HSS kontrastuje propustnost subsystému CSCF (Call Service Control Function), která byla měřena izolovaným spuštěním scénáře navázání hovoru a rychle překročila kapacitu jediného generátoru zátěže (která byla odhadnuta na 500 SAPS, obecně jsou SIPp a SER (SIP Express Router) výkonově velmi vyrovnané). Poté bylo vyzkoušeno distribuované generování zátěže se dvěma a čtyřmi generátory a finální hodnota DOC odhadnuta extrapolací na přibližně 2000 cps (Calls per Second). Výkon testovacího systému přestal stačit již při 1400 SAPS, ale pokusy dál nepokračovaly, protože při těchto intenzitách zátěže padal testovaný systém po několika minutách a od jeho nestability již nebylo technicky možno odhlížeti. Naměřené hodnoty jsou k dispozici v elektronické příloze v automaticky generovaných zprávách z testů. Pokud bychom povahu zjištěné nestability při určování DOC brali v úvahu, musela by nutně vyjít hodnota 0, či číslo nule velmi blízké, protože standard neudává dobu trvání testovacího kroku a jsem přesvědčen, že komponenta P-CSCF (Proxy CSCF) by havarovala při libovolně nízké zátěži, pokud by tato byla aplikována po dostatečně dlouhou dobu.

- 88 -

Bohužel, zjištěné nedostatky nebylo komu ohlásit, protože systém správy závad na stránkách Open IMS Core vyžaduje přihlašovací údaje a na můj pokus je získat nikdo nereagoval. Na mé komentáře do diskusní skupiny jsem také zaznamenal jen minimální odezvu. Vzhledem k tomuto neutěšenému stavu Open IMS Core bych doporučil se zájmem sledovat vývoj projektu Kamailio [43], který slibuje znovuotevření vývoje komponent CSCF a napsání efektivnějšího serveru HSS v jazyce C [42]. Takový server existuje pod jménem CHeSS i v institutu Fraunhofer FOKUS, ale není uvolněn pro veřejnost [69, 81]. Naopak použitý generátor zátěže se osvědčil výborně, jeho nasazení je bezproblémové, generuje standardní zprávy o měření s dobře čitelnými tabulkami naměřených hodnot a grafy. Pokud je nasazení na dvou a čtyřech strojích nějakou indikací, tak distribuovanost měření výrazně neovlivňuje výkon jednotlivých generátorů; v každém případě by tomu napovídal způsob návrhu distribuovaného systému. V případě zájmu by nasazení na desítky až stovky testovacích systémů mohlo být námětem k dalšímu výzkumu, bylo by pak ale třeba postavit výkonnější testovaný systém, než ten, co jsem měl k dispozici. Zvýšení výkonu Open IMS Core by bylo možné již pouhým nasazením každé komponenty na zvláštní stroj. S-CSCF (Serving CSCF) je možné nasadit dokonce na několik strojů, protože I-CSCF (Interrogating CSCF) jsou připravené na úlohu rozkládání zátěže. P-CSCF je také možné nasadit několik, každé by pak obsluhovalo svou podmnožinu uživatelů. I-CSCF pravděpodobně nebude úzkým hrdlem. Pouze HSS by se škálovalo špatně, protože Open IMS Core neobsahuje funkci SLF (Subscriber Location Function) a každému S-CSCF se jeden HSS nastavuje ručně. Nevýhodou je jeho nedokončený stav – nepodporuje IPv6 (Internet Protocol version 6) ani IPSec (IP Security) nebo TLS (Transport Layer Security) a neimplementuje všechny testovací scénáře ze standardu. V případě zájmu by ale neměl být velký problém tyto závady napravit a z průzkumu trhu vyplývá, že lepší nástroj distribuované generování zátěže IMS sítě v současné době neexistuje. Jeho použitelnost pro distribuované testování sítí mobilních operátorů, jak jsem nastínil v kapitole 3.5, tedy v současném stavu závisí na tom, zda operátoři nasadí síť IMS od počátku na IPv6 a se zabezpečením IPSec, nebo využijí úlev „early IMS“. Standard ETSI a potažmo použitý generátor zátěže neřeší měření parametrů QoS (Quality of Service) RTP (Real-time Transport Protocol) toků, pouze SIP signalizace. Pokud by toto mělo být cílem měření, doporučil bych postupovat podobně jako v práci [67] citované v kapitole 3.3.2 a sestavit centrálně ovládaný systém generování zátěže z originálního programu SIPp, plus scénářů upravených z distribuce IMS Bench SIPp. Tak by bylo možné vygenerovat RTP toky mezi jednotlivými dvojicemi SIPp agentů a na některých z nich pak pomocí nástrojů na zachytávání síťového provozu analyzovat kvalitu RTP.

- 89 -

6 Seznam literatury [1]

POLÁCH, Eduard. PRAVIDLA SAZBY : diplomových prací [online]. České Budějovice : Jihočeská univerzita v Českých Budějovicích, Pedagogická fakulta, 12. 10. 1998, 26. 1. 2000 [cit. 2011-01-26]. Dostupné z WWW: . [2] TICHÁ, Ludmila, et al. Jak psát vysokoškolské závěrečné práce [online]. Praha : ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE, ÚSTŘEDNÍ KNIHOVNA ČVUT, Květen 2010 [cit. 2011-01-26]. Dostupné z WWW: . [3] KMa Webdesign. Citace.com [online]. Verze 2.0. 2009 [cit. 2011-01-26]. Dostupné z WWW: . [4] RFC 3261. SIP : Session Initiation Protocol. [s.l.] : Internet Engineering Task Force, June 2002. 269 s. Dostupné z WWW: . [5] POIKSELKÄ, Miikka; MAYER, Georg. THE IMS : IP MULTIMEDIA CONCEPTS AND SERVICES. THIRD EDITION. Chichester (West Sussex) : Wiley, 2009. 533 s. ISBN 978-0-470-72196-4. [6] Isdn. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 8 November 2007, last modified on 24 December 2009 [cit. 2011-01-28]. Dostupné z WWW: . [7] Voice over IP. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 23 August 2002, last modified on 27 January 2011 [cit. 2011-01-28]. Dostupné z WWW: . [8] 3GPP : A Global Initiative [online]. 2011 [cit. 2011-01-28]. Releases. Dostupné z WWW: . [9] VoLGA : Voice over LTE Via Generic Access [online]. Milpitas, CA : Kineto Wireless, Inc., 2009 [cit. 2011-01-28]. Dostupné z WWW: . [10] BEČÁN, Martin. MB Data : komunikační a informační firemní řešení [online]. 2006-01-18, 2007-09-16 [cit. 2011-01-29]. Úvod do VoIP. Dostupné z WWW: . [11] Cisco [online]. Feb 02, 2006 [cit. 2011-01-29]. Understanding Delay in Packet Voice Networks. Dostupné z WWW: . [12] BEZPALEC, Pavel. Moderní technologie Internetu : VoIP stručně. Praha, 2009. 25 s. Přednáška. FEL ČVUT v Praze, Katedra telekomunikační techniky.

- 90 -

[13] Internet Phone Release 4. CTI For Management : The Management Magazine of Computer-Telephony Integration [online]. 1996, 1996/1997 Buyer's Guide, [cit. 2011-01-29]. Dostupný z WWW: . [14] H.323. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 30 July 2002, last modified on 27 January 2011 [cit. 2011-01-29]. Dostupné z WWW: . [15] Voip-info.org : A Reference Guide to All Things VoIP [online]. Thu 04 of Sep, 2003, Wed 29 of Sep, 2010 [cit. 2011-01-29]. IAX. Dostupné z WWW: . [16] Fayn [online]. 2011 [cit. 2011-01-30]. Často kladené otázky. Dostupné z WWW: . [17] Telephone number mapping. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 14 August 2003, last modified on 7 November 2010 [cit. 2011-02-01]. Dostupné z WWW: . [18] PRAVDA, Ivan. Principy telekomunikačních systémů : Metody multiplexování, přenosové systémy PDH a SDH. Praha, 2008. 31 s. Přednáška. FEL ČVUT v Praze, Katedra telekomunikační techniky. [19] Voip-info.org : A Reference Guide to All Things VoIP [online]. Thu 04 of Sep, 2003, Tue 04 of Jan, 2011 [cit. 2011-02-06]. SIP. Dostupné z WWW: . [20] Voip-info.org : A Reference Guide to All Things VoIP [online]. Fri 12 of Sep, 2003, Sat 29 of Sep, 2007 [cit. 2011-02-06]. DNS SRV. Dostupné z WWW: . [21] Real-time Transport Protocol. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 25 February 2002 , last modified on 23 January 2011 [cit. 2011-02-06]. Dostupné z WWW: . [22] RFC 3551. SIP : RTP Profile for Audio and Video Conferences with Minimal Control. [s.l.] : Internet Engineering Task Force, July 2003. 44 s. Dostupné z WWW: . [23] Session Initiation Protocol. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 29 October 2001, last modified on 14 February 2011 [cit. 2011-02-15]. Dostupné z WWW: . [24] IpTelWiki [online].Cesnet, 2007/03/19 [cit. 2011-02-16]. SIP. Dostupné z WWW: . [25] Digest access authentication. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 10 January 2005, last modified on 24 January 2011 [cit. 2011-02-23]. Dostupné z WWW: .

- 91 -

[26] Secure Real-time Transport Protocol. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 28 August 2005 , last modified on 29 January 2011 [cit. 2011-02-25]. Dostupné z WWW: . [27] WRIGHT, James. Konnectic [online]. 31.7.2010 [cit. 2011-02-25]. Session Description Protocol. Dostupné z WWW: . [28] Session Initiation Protocol. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 8. 5. 2006, last modified on 13. 11. 2010 [cit. 2011-02-25]. Dostupné z WWW: . [29] RFC 3655. Session Initiation Protocol (SIP): Basic Call Flow Examples. [s.l.] : Internet Engineering Task Force, December 2003. 94 s. Dostupné z WWW: . [30] SIP Center [online]. 2011 [cit. 2011-03-05]. IMS IP Multimedia Subsystem. Dostupné z WWW: . [31] SALCHOW, Ken, Jr. F5 [online]. August 2007 [cit. 2011-03-05]. Introduction to the IP Multimedia Subsystem (IMS): IMS Basic Concepts and Terminology. Dostupné z WWW: . [32] STADLER, Johannes. IP Multimedia Subsystem [online]. Wien : Forschungszentrum Telekommunikation Wien, 2005 [cit. 2011-03-11]. Dostupné z WWW: . [33] IPv6 [online]. 2008 [cit. 2011-03-11]. IP IMS. Dostupné z WWW: . [34] Diameter (protocol). In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 26 October 2004, last modified on 1 March 2011 [cit. 2011-03-13]. Dostupné z WWW: . [35] IP Multimedia Subsystem. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 10 November 2004, last modified on 25 February 2011 [cit. 2011-03-13]. Dostupné z WWW: . [36] RFC 3310. SIP : Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA). [s.l.] : Internet Engineering Task Force, September 2002. 18 s. Dostupné z WWW: .

- 92 -

[37] 3GPP TS 33.102 : Security Architecture [online]. V3.7.0. Valbonne FRANCE : 3GPP, 2000-12 [cit. 2011-03-15]. 6.3.3 Authentication and key agreement , s. . Dostupné z WWW: . [38] RFC 3319. Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers. [s.l.] : Internet Engineering Task Force, July 2003. 7 s. Dostupné z WWW: . [39] RFC 2915. The Naming Authority Pointer (NAPTR) DNS Resource Record. [s.l.] : Internet Engineering Task Force, September 2000. 18 s. Dostupné z WWW: . [40] NAPTR record. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 17 February 2005, last modified on 19 February 2011 [cit. 2011-03-19]. Dostupné z WWW: . [41] OpenIMSCore.org : Open Source IMS [online].Fraunhofer FOKUS, (C) 2004-2008 [cit. 2011-04-15]. Dostupné z WWW: . [42] Kamailio (OpenSER) SIP Server [online]. January 17th, 2011 [cit. 201104-15]. IMS Extensions Available for Testing. Dostupné z WWW: . [43] Kamailio SIP Server [online]. 2010 [cit. 2011-04-15]. Dostupné z WWW: . [44] SPIERS, Richard; VENTURA, Neco. A Converged IMS Client for the IP Multimedia Subsystem [online]. Rondebosch, South Africa : University of Cape Town, 19.7.2010 [cit. 2011-04-26]. Dostupné z WWW: . [45] MyMONSTER : Telco Communicator Suite [online].Fraunhofer Institute FOKUS, 2009 [cit. 2011-04-26]. Dostupné z WWW: . [46] G, The. OpenIMSCore-Users [online]. Apr 12 2011 [cit. 2011-04-26]. Open IMS Core IPv6 supported clients. Dostupné z WWW: . [47] IMS Communicator [online]. 2008 [cit. 2011-04-26]. Dostupné z WWW: . [48] PT Inovacao [online]. 2011 [cit. 2011-04-26]. Dostupné z WWW: . [49] UCT IMS Client [online]. Cape Town : University of Cape Town, South Africa, 18 Dec 2006, 1 June 2009 [cit. 2011-04-26]. Dostupné z WWW: .

- 93 -

[50] Mercuro IMS Client [online]. 2008-08-04, 2010-08-29 [cit. 2011-04-26]. Dostupné z WWW: . [51] SIPp [online]. 10/25/2010 [cit. 2011-04-26]. Dostupné z WWW: . [52] Kernel Trap [online]. February 21, 2007 [cit. 2011-04-27]. Linux: 2.6.21rc1, Dynticks Merged. Dostupné z WWW: . [53] High Precision Event Timer. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 21 August 2005 , last modified on 4 February 2011 [cit. 2011-04-27]. Dostupné z WWW: . [54] ETSI TS 186 008. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) : IMS/NGN Performance Benchmark. Sophia Antipolis Cedex - FRANCE : European Telecommunications Standards Institute, 2007-10. 28+38+18 s. Dostupné z WWW: . [55] [email protected] [online]. May 12, 2010 [cit. 2011-0428]. Re: sipp ims bench. Dostupné z WWW: . [56] VONDRA, Tomáš. OpenIMSCore-Users [online]. Apr 15 2011 [cit. 2011-04-29]. Trouble loading with IMS Bench SIPp. Dostupné z WWW: . [57] Queueing theory. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 27 April 2002, last modified on 27 April 2011 [cit. 2011-04-30]. Dostupné z WWW: . [58] KAPOUN, Vladimír. Teorie hromadné obsluhy v praxi. Elektrorevue [online]. 25.3.2002, 2002, 19, [cit. 2011-04-30]. Dostupný z WWW: . [59] ŠIROKÝ, Jaromír. Modelování a simulace v dopravě : Systémy hromadné obsluhy [online]. Ostrava Poruba : Vysoká škola báňská Technická univerzita Ostrava, 2004 [cit. 2011-04-30]. Dostupné z WWW: . [60] ZUKERMAN, Moshe. Introduction to Queueing Theory and Stochastic Teletraffic Models [online]. Melbourne : University of Melbourne, 2011 [cit. 2011-04-30]. Dostupné z WWW: <www.ee.cityu.edu.hk/~zukerman/classnotes.pdf>.

- 94 -

[61] FRIEBELOVÁ, Jana. Rozhodovací modely v praxi : Teorie hromadné obsluhy [online]. České Budějovice : Jihočeská univerzita v Českých Budějovicích, Zemědělská fakulta , 12. 2006 [cit. 2011-04-30]. Dostupné z WWW: . [62] WU, Jung-Shyr; WANG, Peir-Yuan. The Performance Analysis of SIP-T Signaling System in Carrier Class VoIP Network [online]. Xian, China : IEEE, 2003 [cit. 2011-04-30]. Dostupné z WWW: . [63] RFC 6076. Basic Telephony SIP End-to-End Performance Metrics. [s.l.] : Internet Engineering Task Force, January 2011. 27 s. Dostupné z WWW: . [64] draft-ietf-bmwg-sip-bench-term-03. Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices. [s.l.] : Internet Engineering Task Force, March 2011. 35 s. Dostupné z WWW: . [65] draft-ietf-bmwg-sip-bench-meth-03. Methodology for Benchmarking SIP Networking Devices. [s.l.] : Internet Engineering Task Force, March 2011. 19 s. Dostupné z WWW: . [66] HRISCHUK, Curtis; DEVAL, Gary. A tutorial on SIP application server performance and benchmarking [online]. Turnersville, NJ, USA : The Computer Measurement Group, 2006 [cit. 2011-05-03]. Dostupné z WWW: . [67] VOZNAK, Miroslav; ROZHON, Jan. SIP Infrastructure Performance Testing [online]. Ostrava : VSB – Technical University of Ostrava, 5/2010 [cit. 2011-05-03]. Dostupné z WWW: . [68] SCHULZRINNE, Henning, et al. SIPstone : SIPstone - Benchmarking SIP Server Performance [online]. Ubiquity : Columbia University, April 12, 2002 [cit. 2011-05-03]. Dostupné z WWW: . [69] DETREZ, Jean-Luc. ETSI TS 186.008 : a Standard-Based Benchmark for IMS [online]. Kontich : Intel Corporation, 1/2008 [cit. 2011-05-05]. Dostupné z WWW: . [70] Ameritec [online]. 2011 [cit. 2011-05-07]. IPXtreme. Dostupné z WWW: . [71] Touchstone [online]. 2010 [cit. 2011-05-07]. WinSIP. Dostupné z WWW: .

- 95 -

[72] Candelatech [online]. 3/2011 [cit. 2011-05-07]. CT506 LANforge-FIRE VoIP Call Generator. Dostupné z WWW: . [73] GL Communications [online]. 2007 [cit. 2011-05-07]. PacketGen. Dostupné z WWW: . [74] IxLoad [online]. 2011 [cit. 2011-05-07]. Ixia. Dostupné z WWW: . [75] Empirix [online]. 10/2010 [cit. 2011-05-07]. Hammer G5. Dostupné z WWW: . [76] Spirent [online]. 2011 [cit. 2011-05-07]. Abacus. Dostupné z WWW: . [77] Arca Technologies [online]. 2011 [cit. 2011-05-07]. Emutel Harmony. Dostupné z WWW: . [78] Fraunhofer FOKUS. SIPNuke [online]. 2008 [cit. 2011-05-07]. Dostupné z WWW: . [79] Pjsip.org [online]. July 11th, 2006 [cit. 2011-05-07]. Benchmarking PJSIP. Dostupné z WWW: . [80] Seagull : an Open Source Multi-protocol traffic generator [online]. 2/2009 [cit. 2011-05-07]. Dostupné z WWW: . [81] OpenIMSCore-Users [online]. 11/2009 [cit. 2011-05-08]. Time mesurements on openIMS. Dostupné z WWW: .

- 96 -

7 Příloha A - Seznam zkratek 3GPP – Third Generation Partnership Project ACELP – Algebraic Code Excited Linear Prediction ADPCM – Adaptive Differential Pulce Code Modulation AES – Advanced Encryption Standard AKA – Authentication and Key Agreement ALG – Application Level Gateway AS – Application Server ATA – Analog Telephone Adapter AuC – Authentication Center AVP – Attribute-Value Pair B2BUA – Back to Back User Agent CCITT – Comité Consultatif International Téléphonique et Télégraphique CDMA2000 – Code division multiple access 2000 CPS – Calls per Second CPU – Central Processing Unit CRAM-MD5 – Challenge-Response Authentication Mechanism - MD5 CSCF – Call Service Control Function CSV – Comma Separated Values ČVUT – České vysoké učení technické DECT – Digital Enhanced Cordless Telecommunications DHCP – Dynamic Host Configuration Protocol DNS – Domain Name Service DOC – Design Objective Capacity DSCP – Differentiated Services Code Point EDGE – Enhanced Data for GSM Evolution ENUM – E.164 NUmber Mapping ESP – Encapsulation Security Payload ETSI – European Telecommunications Standards Institute FEL – Fakulta elektrotechnická FHoSS – FOKUS Home Subscriber Server GGSN – Gateway GPRS Support Node GNU – GNU is Not Unix GPL – General Public License GPRS – General Packet Radio Service GRUU – Globally Routable User-agent URI GSL – GNU Scientific Library GSM – Groupe Spécial Mobile HLR – Home Location Register HMAC – Hash-based Message Authentication Code HPET – High Precision Event Timer HSS – Home Subscriber Server HTML – Hypertext Markup Language

- 97 -

HTTP – Hypertext Transfer Protocol IAX – Inter-Asterisk Exchange ICE – Interactive Connectivity Establishment I-CSCF – Interrogating CSCF IETF – Internet Engineering Task Force IHS – Inadequately Handled Scenario IKE – IPSec Key Exchange iLBC – Internet Low Bit Rate Codec IMS – Internet Multimedia Subsystem IMSI – International Mobile Subscriber Identity IP – Internet Protocol IPSec – Internet Protocol Security ISATAP – Intra-Site Automatic Tunnel Addressing Protocol ISC – IMS Service Control ISDN – Integrated Services Digital Network ISIM – IP Multimedia Services Identity Module ITU-T – International Telecommunication Union - Telecommunication Standardization Sector (dříve CCITT) JIT – Just In Time kodek – kodér-dekodér LTE – Long Term Evolution MAC – Message Authentication Code MD5 – Message Digest 5 MHTML – Multipurpose Internet Mail Attachments Hypertext Markup Language MIKEY – Multimedia Internet KEYing MIME – Multipurpose Internet Mail Extensions MITM – Man in the Middle MLQ – Maximum Likelihood Quantisation NAPTR – Name Authority Pointer NAT – Network Address Translation NAT-PT – Network Address Translation - Protocol Translation NDS – Network Domain Security NGN – Next Generation Network NTP – Network Time Protocol OSI – Open Systems Interconnection PC – Personal Computer PCEF – Policy and Charging Enforcement Point PCI-X – Peripheral Component Interconnect - eXtended PCM – Pulse Code Modulation PCRF – Policy and Charging Rules Function P-CSCF – Proxy CSCF PDP – Packet Data Protocol PKI – Public Key Infrastructure

- 98 -

PoC – Push-to-talk Over Cellular PTP – Precision Time Protocol QoS – Quality of Service RADIUS – Remote Authentication Dial-In User Service RAID – Rendundant Array of Inexpensive Devices RAM – Random Access Memory RFC – Request For Comments RPM – Revolutions per Minute RPS – Registration per Second RRD – Registration Request Delay RSA – Rivest, Shamir, Adleman RTCP – RTP Control Protocol RTP – Real-time Transport Protocol SAPS – Scenario Attempts Per Second SAR – Session Attempt Rate SAS – Serial Attached Small Computer Systems Interface SCP – Secure Copy S-CSCF – Serving CSCF SCTP – Stream Control Transmission Protocol SDES – Security Descriptions for Media Streams SDH – Synchronní digitální hierarchie SDP – Session Description Protocol SEG – Security Gateway SER – SIP Express Router SHA – Secure Hash Algorithm SIM – Subscriber Identity Module SIP – Session Initiation Protocol SLF – Service Locator Function SMP – Symmetric Multi-Processing SMTP – Simple Mail Transfer Protocol SNMP – Simple Network Management Protocol SPS – Sessions per Second SQL – Structured Query Language SRD – Session Request Delay SRTP – Secure Real-time Transport Protocol SRV – Service record SSH – Secure Shell STUN – Session Traversal Utilities for NAT SUT – System Under Test TCP – Transmission Control Protocol THIG – Topology Hiding Internetwork Gateway TISPAN – Telecommunications and Internet converged Services and Protocols for Advanced Networking TLS – Transport Layer Security

- 99 -

TRT – Transaction Response Time UA – User Agent UAC – User Agent Client UAS – User Agent Server UCT – University of Cape Town UDP – User Datagram Protocol UICC – Universal Integrated Circuit Card UMTS – Universal Mobile Telecommunications System URI – Uniform Resource Identifier USIM – Universal Subscriber Identity Module UTF-8 – Unicode Transformation Format 8 VCC – Voice Call Continuity VM – Virtual Machine VoIP – Voice over Internet Protocol VoLGA – Voice over LTE Via Generic Access VPN – Virtual Private Network WiFi – Wireless Fidelity WLAN – Wireless Local Area Network XML – eXtensible Markup Language ZRTP – Zimmerman RTP

- 100 -

8 Příloha B - Obsah přiloženého CD Diplomová práce.doc – Elektronická podoba textu ve zdrojovém tvaru Diplomová práce.pdf – Elektronická podoba textu ve tvaru nezávislém na zařízení add-imscore-user_newdb.sh – upravený skript na přidání uživatele do databáze MySQL v Open IMS Core report1_200-300.mht – 1. naměřená zpráva. Postřehy (shrnutí z textu práce): pád skokově spotřebuje paměť a CPU, které jsou v zápětí uvolněny. Nezodpovězené SIP zprávy zvyšují spotřebu RAM SIPp (neukončené transakce). Ke konci periody registrací je vidět periodické zvýšení IHS, stejně, jako v periodách hájení – je možné, že doba kroku testu 2 min je stejná jako perioda GC Java? report2_100-300.mht – 2. naměřená zpráva. Začátek testu nastaven níže, průběh měření se nejlépe blíží normálu, není ovlivněn pádem. report3_100-250.mht – 3. naměřená zpráva. Doba kroku testu při stejných parametrech prodloužena na 4min, test končí pádem. report4_50-150.mht – 4. naměřená zpráva. Doba kroku prodloužena na 10 min a naměřená DOC je opět nižší. report5_200-250-vlny.mht – 5. naměřená zpráva. Měření začíná na 200 SAPS a výborně ukazuje periodicitu IHS zaviněnou GC Java. Systém spadne při přechodu na vyšší intenzitu provozu. report6_200-padne_stejne.mht – 6. naměřená zpráva. Doba testu zdvojnásobena oproti minulému. Ukazuje, že systém spadne i bez přechodu. report7_reg.mht – 7. naměřená zpráva. Měřen pouze případ užití registrace. Graf CPU nezachycuje vliv neškálujících sekvenčních algoritmů. report8_dist2-900.mht – 8. naměřená zpráva. Měřeno se 2 testovacími systémy a pouze se scénářem navázání hovoru. Test skončil přetížením CPU SIPp. V grafu CPU je vidět jen jeden průběh – oba testovací systémy se jmenovaly stejně (stejný hostname). Neměřeno znovu a nasazeny 4 systémy. report9_dist4-600-1800.mht – 9. naměřená zpráva. 4 testovací systémy. Kvůli nestabilitě bylo nutné použít velmi kratké kroky. Při 1500 SAPS je vidět přetížení SIPp, reálná generovaná zátěž stejná jako při 1400 SAPS. report10_dist4-1000-1400.mht – 10. naměřená zpráva. 4 testovací systémy. Naměřeno po zvýšení počtu procesů P-CSCF. Vyšších hodnot SAPS se nepodařilo dosáhnout ani při posunutí začátku testu výše, kvůli pádům systému, které nastaly po několika minutách. Údaj o volné paměti na SUT je zavádějící, systém nebyl přetížen a mohl ještě čerpat pamět uvolňováním vyrovnávacích pamětí.

- 101 -