}w!"#$%&'()+,-./012345<ya

Rozměr: px
Začít zobrazení ze stránky:

Download "}w!"#$%&'()+,-./012345<ya"

Transkript

1 Masarykova univerzita Fakulta informatiky }w!"#$%&'()+,-./012345<ya Měření VoIP provozu pomocí IP toků Diplomová práce Jan Vojtěch Brno, jaro 2014

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně dne 8. ledna 2014 Jan Vojtěch Vedoucí práce: RNDr. Rostislav Vocilka ii

3 Poděkování Chtěl poděkovat společnosti INVEA-TECH za poskytnutí zkušeností a technického zázemí při vývoji a testování navrženého monitorovacího systému. Mé poděkování si zaslouží také pan Tomáš Koníř, autor programu FlowMon Exportér, který mi poskytl cenné rady a zkušenosti při psaní rozšiřujícího modulu process-voip. Dále děkuji panu Mgr. Petru Velanovi, autorovi programu ipfixcol, za užitečné rady a velmi rychlé opravy chyb. Nakonec bych chtěl poděkovat Ing. Pavlu Čeledovi, Ph.D. a RNDr. Pavlu Minaříkovi, Ph.D. za konzultace během psaní práce, věcné připomínky a korektury textu. iii

4 Shrnutí Diplomová práce popisuje principy fungování VoIP telefonů založených na protokolu SIP, vysvětluje způsob činnosti protokolů SIP, SDP, RTP a RTCP a poukazuje na nedostatky tohoto konceptu. Je zde uveden příklad průběhu telefonního hovoru podle RFC 3261 a dále ukázka toho, jak telefonní hovor dnes opravdu probíhá u předních českých VoIP poskytovatelů. Druhá část práce se věnuje problematice monitorování protokolu SIP, RTP a RTCP na vysokorychlostních sítích. Je zde popsána architektura celého systému a vysvětlen způsob začlenění navrženého systému do řešení INVEA-TECH Flow- Mon. Následuje diskuze implementačních detailů na straně sondy i kolektoru. V závěru je provedeno zhodnocení vytvořeného systému a testy výkonu. Klíčová slova SIP, SDP, RTP, RTCP, vysokorychlostní sítě, VoIP, FlowMon, NetFlow, IP- FIX, Ipfixcol. iv

5 Obsah 1 Úvod Principy fungování VoIP telefonie Komunikační protokoly používané v internetové telefonii Protokol SIP Protokol SDP Protokol RTP Protokol RTCP Průběh telefonního hovoru řízeného protokolem SIP Hovor podle RFC Problémy způsobené překladem IP adres SIP telefonní hovor v praxi Vyzváněcí tóny Speciální případy hovoru Monitorování VoIP provozu na vysokorychlostních sítích Architektura systému pro sběr NetFlow dat Cisco AVC Existující nástroje pro monitorování VoIP provozu VoIPmonitor PRTG Network Monitor VoIP & Network Quality Manager Homer nprobe a ntop Monitorování VoIP provozu pomocí řešení FlowMon Programové vybavení síťové sondy FlowMon Exportér Základní použití Rozšiřující moduly Aplikační rozhraní rozšiřujících modulů Procesní plugin process-voip Implementace pluginu process-voip Rozpoznávání protokolu SIP Zpracování protokolu SIP v

6 4.2.4 Detekce a zpracování protokolů RTP a RTCP Agregace paketů Programové vybavení kolektoru Instalace programu ipfixcol Integrace vlastního rozšíření do FlowMon GUI VoIP Explorer Výpis toků Poslední hovory Podrobné informace o hovoru Zhodnocení a testy navržených pluginů Agregace statistik a dělení toků Měření výkonu Závěr A Význam jednotlivých bitů v polích SIP_STATS A.1 Typ 1: Servisní požadavky A.2 Typ 2: Odpovědi na servisní požadavky A.3 Typ 3: Požadavky týkající se hovoru A.4 Typ 4: Odpovědi na požadavky týkající se hovoru vi

7 Kapitola 1 Úvod Internet je fenoménem současné doby. Počet jeho uživatelů neustále roste, vznikají na něm nové mediální služby, a ty staré analogové, například rozhlasové a televizní vysílání, se na něj postupně přesouvají. Pro řadu lidí je počítač prostředkem každodenní komunikace a elektronická pošta se společně s chatem stala běžnou součástí našich životů. V posledních letech zažívá rozmach nejen textová, ale především hlasová komunikace prostřednictvím celosvětové sítě. Tato práce se zabývá měřením technických a kvalitativních parametrů telefonních hovorů uskutečňovaných přes internet. Technologie umožňující přenos hlasu po internetu souhrnně označujeme termínem VoIP (Voice over Internet Protocol). Z těch mezi uživateli nejznámějších jmenujme například program Skype a přenosový protokol SIP (Session Initiation Protocol), který používají jak počítačové programy vytvořené pro přenos hlasu, tak i specializované telefonní přístroje určené pro internetové volání. Díky výrazné úspoře provozních nákladů přešlo na VoIP mnoho významných podniků, univerzit, veřejných institucí i domácností. Současný trh nabízí poměrně širokou škálu dedikovaných přístrojů umožňujících internetové volání, díky jejichž snadné obsluze a podobnosti s běžnými telefony řada uživatelů ani nepozná, že nepoužívá klasickou telefonní síť. Avšak používání VoIP s sebou přináší také řadu nevýhod a rizik. Pro správnou funkci telefonů je nutné připojení k internetu s dostatečnou přenosovou kapacitou, navíc výpadek počítačové sítě zpravidla způsobí také výpadek sítě telefonní. Pokud chceme garantovat dostatečnou kvalitu telefonních hovorů, je nutné preferovat hlasová data před ostatním provozem na síti, což nebývá vždy snadné. Dalším rizikem je možnost odposlechu telefonních hovorů, útok zaměřený na jeden nebo více telefonních uzlů nebo unesení telefonního čísla a volání na cizí účet. Aby bylo možné efektivně řešit problémy související s VoIP technikou, kontrolovat kapacitu síťových spojů, řešit bezpečnostní incidenty, vyhodnocovat kvalitu hovorů a mapovat využití telefonní sítě, je zapotřebí mít kvalitní monitorovací nástroje. 1

8 1. Úvod Tato diplomová práce se zabývá problematikou monitorování telefonních sítí pracujících s protokolem SIP. V následujících kapitolách vysvětluji princip činnosti tohoto protokolu a zmiňuji se také o protokolech SDP, RTP a RTCP, které se rovněž podílí na telefonních hovorech vedených přes počítačovou síť. Po vysvětlení základních pojmů následuje krátká ukázka průběhu telefonního hovoru a vysvětlení součinnosti výše zmíněných protokolů. Následně zasazuji teoretický koncept do praxe a ukazuji, jakým způsobem se telefonní hovory v dnešní době opravdu navazují. Druhá polovina diplomové práce je více praktická a zabývá se rozšířením monitorovacího systému FlowMon společnosti INVEA-TECH o možnost detailního sledování telefonních sítí založených na protokolu SIP. Po stručné definici požadavků a vysvětlení architektury celého systému představuji rozšiřující moduly vytvořené pro sondu a kolektor. Popsané algoritmy vycházejí z principů činnosti VoIP sítí, které jsou popsány v první části textu. Výsledkem práce je obsáhlé shrnutí principu činnosti VoIP telefonů a dále funkční monitorovací nástroje, které bude možné po menších úpravách začlenit přímo do monitorovacího systému FlowMon. 2

9 Kapitola 2 Principy fungování VoIP telefonie V současném světě VoIP technologií se vyskytuje celá řada komunikačních protokolů, které umožňují přenášet zvuk nebo i video. Obecně je lze rozdělit do čtyř základních skupin: Standardizované protokoly zejména SIP a starší H.323. Hybridní protokoly, které spojují standardizované protokoly a různá proprietární rozšíření například program GoogleTalk založený na protokolu XAMPP. Proprietární, ale dobře dokumentované protokoly například Cisco Skinny. Proprietární uzavřené protokoly například Skype. Výhodou standardizovaných protokolů je široká podpora ze strany výrobců programů i specializovaných zařízení, například VoIP telefonů a tzv. VoIP bran umožňujících používat analogové telefony pro internetové volání. Některé specializované směrovače umožňují prioritizovat VoIP provoz, čímž zajišťují kvalitu hovorů i na zatížené síti. Proprietární protokoly se používají téměř výhradně na počítačích a mobilních telefonech a jejich výrobci většinou těží z reklamy, která se zobrazuje v klientské aplikaci. Někteří uživatelé mohou využívat faktu, že struktura těchto protokolů není tak dobře popsána nebo se dokáží maskovat za jiné běžně používané protokoly (HTTP), a proto se v sítích obtížněji detekují a filtrují. Například blokace programu Skype může být na některých typech firewallů poměrně obtížná až nemožná. Největším problémem všech VoIP technologií je, že nezaručují kvalitu hovoru. Velké firmy proto často investují své prostředky do monitorování síťového provozu mimo jiné i za účelem kontroly a zlepšování kvality telefonních hovorů. V těchto podnicích se používají většinou dedikované telefonní přístroje, které komunikují prostřednictvím protokolu SIP. Proto se budu 3

10 2. Principy fungování VoIP telefonie v následujících kapitolách této diplomové práce věnovat právě tomuto komunikačnímu protokolu. 2.1 Komunikační protokoly používané v internetové telefonii V diplomové práci se věnuji především protokolu SIP, nicméně ten sám o sobě slouží pouze pro navázání spojení. Aby mohl vzniknout telefonní hovor, je potřeba také dohodnout jeho parametry, k čemuž se používá protokol SDP (Session Description Protocol). Samotná hlasová komunikace se nejčastěji přenáší prostřednictvím protokolu RTP (Real-time Transport Protocol) a je kódována za pomoci určitého kodeku, například PCMA, G.722, G.723.1, G.711a, G.711u nebo G.729a. V této kapitole postupně představím výše zmíněné síťové protokoly tak, aby čtenář získal představu o jejich základní struktuře a možnostech využití. Potom bude následovat praktická ukázka telefonního hovoru vycházející ze znalostí získaných v této kapitole Protokol SIP SIP (Session Initiation Protocol) je signalizační protokol, který byl v roce 2002 standardizován dokumentem RFC 3261 [2]. Protokol SIP oficiálně používá port 5060/UDP, nicméně v některých síťových konfiguracích jej můžeme vidět i na jiných portech nebo nad protokolem TCP. Jak již napovídá slovo signalizační, nezabývá se samotným přenosem hlasu, nýbrž jen nalezením volaného účastníka, žádostí o hovor a jeho ukončením. Protokol SIP umožňuje následující: Nalezení volaného uživatele, zjištění, zda je tento uživatel ochoten komunikovat, dohodu parametrů spojení, sestavení spojení, řízení spojení, změny parametrů a ukončení spojení. SIP je textový protokol inspirovaný protokolem HTTP. Jeho zprávy můžeme rozdělit na dva základní typy: požadavky a odpovědi účastník zasílá požadavky jinému uzlu v síti a ten na ně odpovídá. Každý požadavek má na prvním řádku hlavičky uveden název metody, identifikátor adresáta a jméno 4

11 2. Principy fungování VoIP telefonie protokolu s verzí. Zbylé řádky hlavičky obsahují povinná a volitelná pole, u kterých nezáleží na pořadí ani na velikosti písmen. Jméno každého pole končí dvojtečkou, která uvozuje hodnotu, jež může zabírat jeden nebo i více řádků. Hlavičku odděluje od těla zprávy prázdný řádek. Norma připouští dvě verze názvů polí dlouhé a jednoznakové. Pro lepší čitelnost budu v této práci používat dlouhou variantu. REGISTER sip : sip. fayn.cz SIP /2.0 CSeq : 23 REGISTER Via : SIP /2.0/ UDP :5060; branch = z9hg4bk ; rport User - Agent : Ekiga /3.3.2 From : <sip : jvojtech98@sip. fayn.cz >; tag =9 c6c4a91 Call -ID: a e be -001 c2594a0d6@milacek To: <sip : jvojtech98@sip. fayn.cz > Contact : <sip : jvojtech98@ :5060 > Expires : 3600 Content - Length : 0 Max - Forwards : 70 Výpis kódu 2.1: Ukázka SIP požadavku. Odpovědi mají stejný formát jako požadavky, liší se jen prvním řádkem, který obsahuje jméno protokolu, jeho verzi a stavový kód odpovědi následovaný jeho slovním popisem. SIP / Forbidden ( Bad auth ) Via : SIP /2.0/ UDP :5060; branch = z9hg4bk ; received = ; rport =5060 From : <sip : jvojtech98@sip. fayn.cz >; tag =9 c6c4a91 To: <sip : jvojtech98@sip. fayn.cz >; tag = as693b0a64 Call -ID: a e be -001 c2594a0d6@milacek CSeq : 23 REGISTER User - Agent : CANISTEC - MATRIX - T100 Supported : replaces Content - Length : 0 Výpis kódu 2.2: Ukázka SIP odpovědi. Účastníci komunikace na sebe odkazují pomocí tzv. SIP URI (Uniform Resource Identifier), což je jednoznačný identifikátor uživatele, který má následující tvar: sip:<uživatel>@<server> Identifikátor začíná jménem protokolu, které může být buď sip nebo sips. Druhá varianta se používá pro šifrované spojení. Následuje jméno uživatele a název nebo IP adresa serveru, na němž lze uvedenou osobu kontaktovat. 5

12 2. Principy fungování VoIP telefonie Každý SIP paket musí povinně obsahovat pole To, From, CSeq, Call-ID, Max-Forwards, a Via. Pole To a From obsahují SIP URI adresáta a odesílatele požadavku, volitelně mohou obsahovat i uživatelsky přívětivé jméno (podobně jako je tomu v hlavičce u). Pokud je paket součástí dialogu (viz níže), přidává se k oběma polím ještě parametr tag, který je pro daný dialog jednoznačný. Pole CSeq představuje pořadové číslo požadavku doplněné o jméno metody, která byla předmětem požadavku. Díky němu je možné snadno přiřadit doručené odpovědi k již odeslaným požadavkům. Pole Call-ID je identifikátorem aplikace a společně s tagy v polích From a To jednoznačně určuje SIP komunikaci (telefonní hovor). Pole Max-Forwards definuje maximální počet skoků SIP paketu. S každým přeposláním požadavku se uvedené číslo o jedničku sníží a při dosažení čísla nula se paket zahodí. To zabraňuje SIP paketům, aby do nekonečna bloudily sítí. Poslední povinné pole nese označení Via a používá se k záznamu trasy, kterou prochází požadavek. To je nutné proto, aby bylo možné odesílat odpovědi zpět stejnou cestou, z jaké přišly požadavky. Každý server, který požadavek zpracovává, přidává další pole Via se svou vlastní adresu a portem. Při posílání odpovědi se pole Via odpovídající mezilehlým uzlům opět odebírají. Kromě toho je v poli Via uveden také parametr branch, což je jedinečný identifikátor požadavku. Pomocí protokolu SIP spolu komunikují následující subjekty: Uživatelský agent (UA) libovolný program nebo zařízení (telefon) umožňující uživateli obousměrnou komunikaci prostřednictvím protokolu SIP. SIP proxy internetový server, který přeposílá žádosti UA dalším SIP proxy nebo UA. Často funguje zároveň jako brána pro volání do běžné telefonní sítě. Využívání SIP proxy podléhá zpravidla autentizaci a bývá zpoplatněno. SIP registrar internetový server, na který se přihlašují UA a sdělují mu svou aktuální pozici (IP adresu a port). Server si tuto informaci uloží a na vyžádání ji předá například jinému UA nebo SIP proxy. SIP proxy bývají zároveň i SIP registrary. Jak již bylo řečeno, komunikace je založena na výměně požadavků a odpovědí. Každý požadavek začíná jménem metody, jejichž výčet pro základní protokol SIP bez rozšíření je uveden níže: INVITE Navázání hovoru nebo úprava parametrů spojení. ACK Potvrzení o přijetí odpovědi na požadavek INVITE. 6

13 BYE Ukončení telefonního hovoru. 2. Principy fungování VoIP telefonie CANCEL Zrušení probíhajícího požadavku. OPTIONS Dotaz na seznam podporovaných služeb. REGISTER Oznámení polohy uživatele SIP registrar serveru. V dnešní době se používají i další metody, které se definují v různých rozšířeních protokolu. Jedná o metody umožňující oznamování událostí (SUB- SCRIBE, NOTIFY, PUBLISH), získávání informací během hovoru (INFO), přepojování hovorů (REFER), předávání textových zpráv (MESSAGE) a úpravu parametrů hovoru (UPDATE). Tyto metody však nejsou pro monitorování SIP provozu, kterému se věnuje tato práce, klíčové, a proto se jim nebudu dále věnovat. Odpovědi na SIP požadavky mají na prvním řádku místo jména metody stavový kód a jeho textový přepis. Jméno metody je uvedeno v povinném poli CSeq. Stavové kódy mají tři cifry a jejich rozdělení je inspirováno protokolem HTTP. První číslice určuje obecný stav požadavku, další dvě pak konkrétní událost nebo chybu. Následuje výčet všech skupin a příklady nejpoužívanějších kódů: 1xx informace o průběhu zpracování požadavku. Požadavek nesmí nikdy skončit odpovědí s tímto kódem, vždy musí nakonec přijít zpráva s vyšším kódem, která informuje o výsledku zpracování. Nejčastěji se používají kódy 100 Trying, 180 Ringing a 183 Session Progress. 2xx informují o úspěšném splnění požadavku, nejčastěji můžeme vidět odpověď 200 OK. 3xx informují o nové pozici uživatele nebo o tom, jak ho správně kontaktovat. Často se používají kódy 301 Moved Permanently, 302 Moved Temporarily a 305 Use Proxy. 4xx chyby klienta. Specifikace udává, že po přijetí tohoto chybového kódu by neměl klient nikdy poslat stejný požadavek znovu, protože je v něm chyba. Nejčastěji můžeme vidět kódy 400 Bad Request, 401 Unauthorized, 403 Forbidden, 407 Proxy Authentication Required a 486 Busy Here. 5xx chyby na straně serveru, kvůli kterým není možné splnit požadavek. Nejčastější je 500 Internal Server Error. 7

14 2. Principy fungování VoIP telefonie 6xx globální chyby. Například 603 Decline (uživatel odmítl hovor) nebo 606 Not Acceptable (oba uživatelé se nedokázali shodnout na přijatelných parametrech spojení) Protokol SDP Protokol SDP (Session Description Protocol) [3] se používá pro dohodu parametrů mediálního spojení mezi dvěma uzly v síti. Sám o sobě neposkytuje žádné prostředky pro vyhledání druhého účastníka, a proto se vkládá do těla zprávy protokolu SIP, který právě tuto chybějící funkcionalitu doplňuje. Příklad protokolu SDP je vidět na výpisu 2.3. Iniciátor spojení nabízí formou tohoto protokolu IP adresu a porty, na kterých očekává připojení druhého účastníka. Může nabídnout jedno nebo i více mediálních spojení (typicky audio a video relaci), ke každému uvádí zvlášť seznam portů a kodeky, které je schopen zpracovat. Oslovený počítač se po obdržení zprávy může připojit k příslušnému portu a posílat data kódovaná jedním z nabídnutých kodeků. v=0 o= IN IP s= Ekiga /3.3.2 c= IN IP t=0 0 m= audio 5086 RTP / AVP a= sendrecv a= rtpmap :8 PCMA /8000/1 a= rtpmap :101 telephone - event /8000 a= fmtp : ,32,36 a= rtpmap :100 NSE /8000 a= fmtp : a= maxptime :240 m= video 5090 RTP / AVP 31 b=as :4096 b= TIAS : a= sendrecv a= rtpmap :31 h261 /90000 a= fmtp :31 CIF =1; QCIF =1 Výpis kódu 2.3: Ukázka protokolu SDP. Z ukázky je zřejmé, že se jedná opět o textový protokol s velmi jednoduchým formátem: Každý řádek obsahuje jeden atribut a jeho hodnotu oddělené znakem rovnítka. Hodnoty některých atributů (např. m) jsou složitější a obsahují více hodnot oddělených mezerou. Atribut v (version) obsahuje číslo verze protokolu, momentálně má vždy hodnotu nula. Atribut o (origin) 8

15 2. Principy fungování VoIP telefonie obsahuje informace o iniciátorovi spojení a je rozdělen na několik dílčích hodnot: o=< username > <sess -id > <sess - version > <nettype > <addrtype > <IP > Výpis kódu 2.4: Struktura atributu o protokolu SDP. Username je přihlašovací jméno uživatele a v naší ukázce není uvedeno (hodnota -). Pole sess-id je řetězec, který má společně s ostatními poli tvořit jedinečný identifikátor spojení. Náš uživatelský agent použil pro identifikaci spojení aktuální čas. Význam pole sess-version je ponechán na autorovi konkrétní aplikace. Nettype představuje typ zdrojové sítě, IN znamená internet. Addrtype je označení typu adresy (IPv4 nebo IPv6) a IP je samozřejmě adresa iniciátora spojení. Atribut s (session name) obsahuje jméno uživatelského agenta, který spojení navazuje. V našem případě se jedná o program Ekiga. Pole c (connection data) obsahuje typ sítě, protokol a IP adresu, na které očekáváme připojení kontaktovaného uzlu. Jeho formát je obdobný jako v případě pole o, ale obsahuje jen položky nettype, addrtype a IP. V poli t (timing) je uveden čas začátku a konce mediální relace, což by mělo usnadnit uživatelským agentům plánování využití pásma. V praxi toto pole však zůstává často nevyplněno (hodnoty nula) i přesto, že to specifikace protokolu nedoporučuje. Z hlediska monitorování telefonních hovorů je nejdůležitější pole m (media descriptions), které definuje parametry nabízeného mediálního spojení. Má následující formát: m=< media > <port > <protocol > <codecs > Výpis kódu 2.5: Struktura atributu m protokolu SDP. Media označuje typ dat, která očekáváme. Na výběr jsou následující možnosti: audio, video, text, application. V případě telefonních hovorů se samozřejmě setkáme pouze s prvními dvěma typy. Protocol je označením protokolu, který se použije pro přenos mediálních dat. Nejčastěji se používá protokol RTP popsaný v kapitole 2.1.3, který funguje jako rámec pro kódovaná mediální data. Posledním parametrem je seznam nabízených kodeků. Kodeky se nedefinují pomocí svých názvů, ale používají se jejich číselné kódy. Význam těchto číselných kódů je definován v normě [5]. Některé hodnoty mají pevný význam, zatímco jiné jsou definovány pro tzv. dynamické použití. Aby bylo možné zjistit, jaký kodek se skrývá pod dynamickým označením, je zapotřebí, aby iniciátor spojení explicitně uvedl jeho název. To může učinit po- 9

16 2. Principy fungování VoIP telefonie mocí atributu a (attributes), který slouží pro rozšíření protokolu. Pokud chceme uvést jméno kodeku, použijeme syntaxi uvedenou na výpisu 2.6. a= rtpmap :< payload_type > <encoding >/ < clock > [/ < parameters >] Výpis kódu 2.6: Struktura atributu a protokolu SDP. Payload type je číselný identifikátor kodeku uvedený v atributu m, encoding je jeho slovní popis. Clock odpovídá požadované rychlosti vzorkování dat za sekundu (např Hz). Poslední pole je závislé na konkrétním kodeku a není povinné Protokol RTP Protokol RTP (Real-time Transport Protocol) [4] se používá jako rámec, do kterého se vkládají multimediální data kódovaná příslušným kodekem. Tento protokol funguje nad protokolem UDP a nepoužívá žádné ustálené číslo portu. Port se alokuje dynamicky při navazování mediálního spojení, a jeho číslo se posílá druhému účastníkovi pomocí protokolu SDP. Protože se jedná o přenos dat v reálném čase, posílá se velké množství malých paketů v pravidelných intervalech. Časový rozestup těchto paketů je dán typem použitého kodeku a požadovanou kvalitou přenosu. Aby se co nejvíc uspořila šířka pásma, je nezbytné, aby hlavička protokolu RTP obsahovala opravdu jen nejnutnější údaje a režijní data se posílala jiným přenosovým kanálem (tím jsou protokoly SIP, SDP a RTCP) V P X CC M PT sequence number timestamp synchronization source (SSRC) identifier contributing source (CSRC) identifiers... Obrázek 2.1: Hlavička RTP paketu podle [4]. RTP je binární protokol a jeho základní hlavička má velikost 12 B. Obsahuje pole V, které označuje číslo verze a momentálně má vždy hodnotu 2. Nastavený bit P informuje o použití paddingu (tj. paket byl doplněn nulami tak, aby jeho délka byla násobkem 4 bytů). Příznak X indikuje skutečnost, že 10

17 2. Principy fungování VoIP telefonie za hlavičkou následuje právě jedno její rozšíření. V poli CC je uložena délka seznamu zdrojů, které přispívají do přenášených dat (CSRC). Pole M (Mark) nemá přesně dané využití a je ponecháno konkrétní aplikaci, která pomocí něho může například označovat důležité pakety apod. Z hlediska vyhodnocování kvality hovoru je významné pole PT (payload type), které udává identifikátor použitého kodeku. Seznam kodeků a jejich identifikačních čísel je možné najít v [5]. Neméně důležitým polem je sequence number (pořadové číslo zprávy), pomocí kterého lze snadno detekovat chybějící zprávu nebo seřadit pakety, které se během přenosu promíchaly. Pole SSRC (synchronization source) obsahuje 32bitový identifikátor zdroje dat, který náhodně zvolí vysílající. Komunikace protokolem RTP je jednosměrná, takže se při telefonním hovoru musí vytvořit dva RTP toky. Pokud uživatel požaduje videohovor, je zapotřebí vytvořit toky čtyři. Vzhledem k povaze přenášených dat nemá smysl přeposílat ztracené pakety. Během přenosu dat oba účastníci monitorují kvalitu hovoru a podávají zpětnou vazbu pomocí řídicího protokolu RTCP, který je popsán v následující kapitole Protokol RTCP Protokol RTCP (Real-time Transport Control Protocol) se používá pro řízení toku dat, která se přenášejí protokolem RTP. I přesto, že se jedná o zvláštní protokol, je s protokolem RTP velmi úzce spjat a dokonce je oba definuje stejný dokument [4]. Hlavním důvodem oddělení obou protokolů je snaha o maximální jednoduchost a minimální objem RTP paketů. Stejně jako protokol RTP nemá ani RTCP pevně definovaný přenosový port, nicméně zde platí jednoduchá konvence: Pokud se RTP data přenášejí portem číslo x, potom se RTCP data přenášejí pomocí portu x + 1. Protokol RTP využívá sudá čísla portů, zatímco RTCP komunikuje na lichých číslech. Protokol RTCP zajišťuje následující funkcionality: Poskytování informací o kvalitě hovoru a zábrana zahlcení sítě, identifikace zdrojů RTP paketů a synchronizace přenosových kanálů, zjištění celkového počtu účastníků komunikace, poskytování dodatečných informací o spojení (volitelně). Protokol RTCP používá několik typů zpráv, které mají shodnou počáteční hlavičku o délce 8 B (obrázek 2.2). Pole V obsahuje verzi protokolu (zatím vždy 2) a informaci o použití paddingu v bitu P. Počet obsažených 11

18 2. Principy fungování VoIP telefonie receiver reportů je uveden v poli RC, následuje typ zprávy (payload type) v poli PT a délka zprávy v poli length V P X RC PT length Obrázek 2.2: Společná hlavička RTCP paketu podle [4]. Pro úsporu přenosové režie je možné vložit několik typů zpráv do jednoho paketu, čímž vznikne složený paket. Ve složeném paketu se nepoužívají žádné oddělovače, zprávy jsou naskládány jedna za druhou, což je možné díky informaci o délce zprávy, kterou obsahuje hlavička. Následuje seznam typů zpráv a jejich popis. SR (Sender report) Zpráva obsahuje identifikátor původce dat (SSRC of sender), časové značky potřebné pro synchronizaci příjemců (NTP timestamp, RTP timestamp) a dále počet odeslaných paketů (Sender s packet count) a bajtů (Sender s ocetet count), podle něhož si mohou příjemci zkontrolovat, kolik dat se během přenosu ztratilo. Za údaji o odeslaných datech následují statistiky dat přijatých, tzv. receiver reporty. V případě telefonního hovoru zpráva obsahuje většinou jen jediný report, který podává informace o kvalitě dat přicházejících od druhého účastníka. Pokud se jedná o hovor konferenční, může být ve zprávě reportů více. Pokud účastník data pouze odesílá, je tato sekce prázdná. Při monitorování kvality hovoru pro nás může být velmi užitečné měřit počet skutečně přenesených paketů a porovnávat jej s polem Sender s packet count. Dalšími užitečnými metrikami jsou například rozptyl a počet ztracených paketů, o kterých bude řeč v následující kapitole. RR (Receiver report) Zprávy typu receiver report odesílají všichni účastníci RTP komunikace, kteří do sítě neposílají žádná RTP data. Příkladem takových účastníků mohou být posluchači telekonference nebo dva uživatelé provozující videohovor, z nichž pouze jeden má webkameru. Struktura zprávy je velice podobná zprávě typu sender report, pouze neobsahuje informace o odeslaných datech (tj. druhý 12

19 2. Principy fungování VoIP telefonie V P X RC PT=SR=200 length SSRC of sender NTP timestamp, most significant bits NTP timestamp, least significant bits RTP timestamp Sender s packet count Sender s octet count SSRC_1 of first source Fraction lost Cumulative number of packets lost Extended highest sequence number received Interarrival jitter Last SR Delay since last SR (DSLR) SSRC_2 of second source... Obrázek 2.3: Zpráva typu sender report protokolu RTCP (převzato z [4]). blok na obrázku 2.5). Tato kapitola se věnuje pouze vybraným polím z části receiver report, zbytek informací je možné najít v kapitole O počtu ztracených paketů informují pole Fraction lost a Cumulative number of packets lost. První z nich udává podíl ztracených a očekávaných paketů od posledního reportu vyjádřený jako číslo v rozsahu 0 255, zatímco druhá hodnota obsahuje celkový počet ztracených paketů od začátku komunikace. Při diagnostice fungování sítě může být zajímavé právě druhou zmíněnou hodnotu porovnat s vlastním měřením, což může pomoci při hledání místa, kde se ztrácejí pakety. Pole Extended highest sequence number received obsahuje poslední dosud přijaté pořadové číslo paketu. Je užitečné zejména pro odesílatele dat, který na základě něho může například znovu odeslat klíčový snímek videa apod. Interarrival jitter je průměrná odchylka příchodu RTP paketů, tj. jak hodně se liší skutečné časy příchodu paketů od těch očekávaných. Udává se jako celé číslo v jednotkách RTP hodin (jejich perioda závisí na použitém 13

20 2. Principy fungování VoIP telefonie kodeku). Výpočet hodnoty se provádí podle [4] následovně: Pro každé dva po sobě příchozí RTP pakety i a j se nejprve stanoví rozdíl D na základě časové známky paketu Si a skutečného příchodu paketu Ri: D(i, j) = (Rj Ri) (Sj Si) = (Rj Sj) (Ri Si) (2.1) Získaný výsledek se přičte k celkovému průměru následovně: J(i) = J(i 1) + D(i 1, i) J(i 1) 16 (2.2) Při sledování kvality hovoru je užitečné měřit rozptyl RTP paketů na mezilehlém uzlu v síti a porovnávat jej s hodnotami získanými v koncových uzlech. Postup měření je stejný jako na koncovém uzlu, jedinou komplikací může být zjištění převodního vztahu mezi skutečným časem příchodu paketu a RTP hodinami, který je nezbytný pro korektní odečtení hodnot Ri a Si ve vztahu 2.1. Perioda RTP hodin je totiž závislá na použitém kodeku a většinou odpovídá například rychlosti vzorkování posílaného signálu. Protože mezilehlý uzel periodu RTP hodin nezná, je zapotřebí ji určit na základě použitého kodeku, který je uvedený v poli PT (payload type) v hlavičce každého RTP paketu. Například pokud má pole PT hodnotu 8, zjistíme podle tabulky kodeků [5], kterou vydává společnost IANA, že se jedná o kodek PCMA, jenž používá vzorkovací frekvenci 8000 Hz. Periodou RTP hodin je převrácená hodnota frekvence, tedy s. Receiver report končí poli Last SR a Delay since last SR. První z nich obsahuje časovou známku posledního obdrženého sender reportu, zatímco ve druhém je uvedena prodleva mezi přijetím posledního sender reportu a odesláním tohoto receiver reportu. SDES (Source description) Zpráva typu source description přenáší bližší informace o zdroji RTP dat. Může se jednat jak o hlavní zdroj dat (synchronization source), tak i o zdroj, který jen přispívá daty hlavnímu zdroji (contributing source). Ve zprávě může být nula nebo více popisovačů a jejich počet je uveden v hlavičce, konkrétně v poli SC. Každý popisovač zdroje se skládá z identifikátoru zdroje (pole SSRC/CSRC) a libovolného počtu polí s popisem zdroje (SDES items). Každá položka popisovače začíná svým osmibitovým kódem (pole type) a délkou (pole length). Pak už následují samotná data. 14

21 2. Principy fungování VoIP telefonie V P SC PT=SDES=202 length SSRC/CSRC_1 CNAME=1 length user and domain name =3 length address... SSRC/CSRC_2 SDES items... Obrázek 2.4: Zpráva typu SD protokolu RTCP (převzato z [4]) type length data Obrázek 2.5: Pole SDES protokolu RTCP (převzato z [4]). Norma definuje mimo jiné pole pro uložení textového označení zdroje (type = 1), uživatelského jména (type = 2), u (type = 3), telefonu (type = 4) a zeměpisných souřadnic (type = 5). Typ číslo 8 je ponechán pro využití v závislosti na aplikaci. I přesto, že protokol RTCP může přenášet poměrně zajímavé informace o zbylých účastnících hovoru, většina komunikačních programů upřednostňuje popisné informace, které poskytuje protokol SIP (například jméno volajícího apod.). Některé VoIP telefony dokonce neposílají SDES zprávy vůbec a nebo je nechávají prázdné. Hlavním důvodem je patrně fakt, že SIP spojení se navazuje dříve než spojení RTP, a proto přicházejí informace z protokolu RTCP až v době, kdy už nejsou potřeba. BYE Zpráva typu BYE informuje to tom, že jeden nebo více účastníků přestává být aktivní. Za ustálenou hlavičkou následuje seznam zdrojů, kterých se zpráva týká. Volitelně je možné udat i důvod ukončení spojení. 15

22 2. Principy fungování VoIP telefonie APP Zpráva typu APP nemá definován žádný pevný význam a její využití je ponecháno na konkrétní aplikaci. Za ustálenou hlavičkou následuje pole SSRC označující zdroj dat a name označující jméno aplikace. 2.2 Průběh telefonního hovoru řízeného protokolem SIP Navazování telefonního hovoru se provádí prostřednictvím protokolu SIP a probíhá v několika krocích. Jak již bylo dříve řečeno, protokol SIP slouží k nalezení druhého účastníka hovoru a dohodě parametrů přenosu dat. Samotný hlas se přenáší zvláštním datovým kanálem, typicky pomocí protokolu RTP. Konkrétní sled zpráv protokolu SIP závisí na tom, zda navazujeme hovor přímo a nebo přes proxy server. SIP proxy může navíc přenášet buď jen signální nebo signální i hlasová data. Ve většině případů probíhá telefonní hovor podle jednoho z následujících scénářů: Přímé spojení nejjednodušší, nicméně nejméně používaná varianta. Navazování spojení probíhá přímo mezi dvěma účastníky, SIP proxy ani registrar servery se zde nepoužívají. Je nutné, aby volající znal IP adresu volaného a tato adresa mu byla přímo dostupná (např. veřejná IP adresa v internetu nebo privátní IP adresa ve stejné síti). Signalizace přes proxy nebo registrar server parametry telefonního hovoru se domlouvají za účasti SIP registrar/proxy serverů, samotný telefonní hovor se přenáší přímo mezi oběma účastníky (viz obrázek 2.6). S touto variantou primárně počítá dokument RFC 3261 [2], který definuje SIP. Úplné spojení přes proxy server veškerá komunikace probíhá přes SIP proxy server. To odstraňuje problémy s procházením NATu a na základě provedených měření se jedná o dnes nejpoužívanější schéma. V následujícím textu bude postupně představen způsob navázání hovoru tak, jak jej definuje RFC 3261 [2], později se budu věnovat nedostatkům tohoto přístupu a vysvětlím, jak v současné době používá protokol SIP většina VoIP poskytovatelů. 16

23 2.2.1 Hovor podle RFC Principy fungování VoIP telefonie Obrázek 2.6 ukazuje průběh hovoru mezi Alicí a Bobem. Přenášená data jsou označena šipkami, u každé z nich je uvedeno pořadové číslo a název zprávy, která se přenáší. Předtím, než je možné začít telefonovat, musí se oba účastníci přihlásit k registrar serveru svého poskytovatele (na obrázku jsou znázorněny SIP proxy, které mimo jiné plní také funkci registrar serverů). To se provede posláním zprávy REGISTER. Registrar odpovídá 200 OK a ukládá si IP adresu a port, ze kterého přišel požadavek (zná aktuální polohu uživatele). Samotný hovor začíná zprávou INVITE, kterou posílá Alice na svou proxy. Ve zprávě je napsáno mimo jiné SIP URI volaného účastníka, v našem případě bob@fayn.cz. Za hlavičkou SIP zprávy následuje protokol SDP, který popisuje parametry nabízeného spojení. Je zde uveden zejména port a IP adresa, na kterých Alice očekává mediální data od Boba, a dále seznam kodeků, které podporuje Alicin telefon. SIP proxy odpoví stavovým kódem 100 Trying a provede lokalizaci účastníka podle následujícího postupu: Pokud je v SIP URI napsáno cizí doménové jméno, předá se zpráva příslušné SIP proxy. Pokud doménové jméno v SIP URI patří této proxy a před zavináčem je platné jméno uživatele této proxy, pak se kontaktuje tento uživatel. Pokud doménové jméno v SIP URI patří této proxy a před zavináčem je platné telefonní číslo, přepojí se hovor do analogové telefonní sítě (pokud SIP proxy tuto funkci podporuje). Jinak hovor skončí s chybou 404 Not Found. V našem případě proxy zvolí první variantu, pomocí DNS serveru (není na obrázku) získá IP adresu proxy fayn.cz a přepošle jí zprávu INVITE. Do hlavičky zprávy přidá pole Via, do kterého uvede svou IP adresu a port. Díky této informaci se bude moci požadavek vrátit stejnou cestou zpět. Proxy fayn.cz odpoví opět stavovým kódem 100 Trying a pokusí se lokalizovat volaného účastníka. Protože SIP URI obsahuje její doménové jméno a Bob je jejím platným uživatelem, přepošle mu zprávu, do níž i ona vloží pole Via se svou IP adresou a portem. Bobovu IP adresu zná proxy z požadavku REGISTER, který Bob již dříve poslal. Bobův počítač přijímá zprávu INVITE a protože je jejím adresátem, odpoví stavovým kódem 180 Ringing a na displeji zobrazí zprávu o příchozím hovoru. Dříve než si Bob vůbec všimne příchozího volání, přepošle Bobova 17

24 2. Principy fungování VoIP telefonie SIP proxy ustredna.mikrotech.cz 5. INVITE SIP proxy sip.fayn.cz Trying Ringing OK 1. REGISTER 2. OK 3. INVITE Trying Ringing OK 7. INVITE Ringing OK 4. OK 3. REGISTER 14. ACK 15. Přenos hlasu pomocí RTP 16. BYE 17. OK Alice Obrázek 2.6: Průběh telefonního hovoru podle RFC 3261 [2] Bob SIP proxy stavový kód 180 Ringing Alici (přes její proxy), takže Alice vidí, že Bobovi začal vyzvánět telefon, a čeká, až Bob přijme hovor. Po přijetí hovoru odesílá Bobův počítač stavový kód 200 OK, který signalizuje začátek hovoru. Součástí této SIP zprávy jsou také data protokolu SDP (podobně jako u zpávy INVITE), v nichž Bobův počítač informuje o IP adrese a portu, na nichž očekává mediální data. Zpráva se okamžitě přepošle Alici stejně jako předchozí stavové kódy. Alice potvrzuje přijetí stavové zprávy metodou ACK, na kterou Bobův počítač odpovídá 200 OK. Na rozdíl od předchozích zpráv se zpráva ACK již neposílá přes SIP proxy. Oba účastníci totiž už vzájemně znají svou aktuální polohu. Předali si ji ve zprávách SIP tak, že v hlavičce uvedli pole Contact se svou aktuální IP adresou a portem. Po odeslání zprávy ACK se začínají přenášet hlasová data prostřednictvím protokolu RTP mezi IP adresami a porty, které si Alice a Bob dohodli během navazování spojení prostřednictvím protokolu SDP. Hovor končí ve chvíli, kdy jeden z účastníků pošle zprávu BYE. V našem případě tak učiní Alice. Bobův počítač odpovídá stavovým kódem 200 OK a přestává posílat hlasová data. Při ukončení přenosu dat protokolem RTP se posílá také řídicí zpráva BYE protokolem RTCP. 18

25 2. Principy fungování VoIP telefonie Výše uvedený postup bohužel počítá se skutečností, že Alice i Bob disponují veřejnou IP adresou, což v praxi platí jen málokdy (alespoň v rámci dnes nejvíce používaného protokolu IP verze 4). Díky nutnosti použití veřejných adres se můžeme snadno dostat do situace, kdy se hlasová data posílají korektně jen jedním směrem a nebo se zvuk nepřenáší vůbec Problémy způsobené překladem IP adres Aby se podařilo korektně navázat telefonní hovor za použití postupu popsaného v předchozí kapitole, musí oba účastníci vzájemně znát svou IP adresu a port, na němž očekávají příchozí data. Problém může nastat ve chvíli, kdy v síti dochází na mezilehlých směrovačích k nějakým úpravám IP adres a portů v hlavičkách paketů. Nejčastěji se můžeme setkat s tzv. NATem (Network Address Translation), který maskuje za jednu veřejnou IP adresu celou podsíť počítačů s privátními adresami. IP adresa koncového uživatele se přenáší nejen v hlavičce SIP paketu, ale také v datech protokolu SDP. Drtivá většina směrovačů přepíše IP adresu pouze v hlavičce paketu a druhému účastníkovi hovoru tak přijde v protokolu SDP nesmyslná informace, která odkazuje na privátní IP adresu. Na první pohled se může zdát, že by stačilo, aby uživatel ve svém telefonu nastavil jeho veřejnou IP adresu a telefon by ji pak posílal v protokolu SDP místo té privátní. Bohužel stejným způsobem, jako se překládají IP adresy, se mohou měnit i porty. V závislosti na konfiguraci sítě se může toto mapování navíc v čase měnit. Určitým východiskem může být dynamické zjištění aktuální veřejné IP adresy a portu, nicméně ani toto řešení nefunguje na všech typech NATu správně. Z důvodu nedostatečného množství IP verze 4 adres je NAT běžný u velké části tuzemských i zahraničních poskytovatelů internetu, a proto je zapotřebí zajistit, aby se hovor úspěšně navázal i za jeho použití. V následujících kapitolách se budu věnovat řešení problémů spojených s překladem IP adres a portů. Hlavní myšlenky, které se chystám prezentovat, vychází z článku NAT Traversal in SIP [6]. Používané typy NATu V praxi se používají celkem čtyři typy NATu. Všechny mají stejný účel tj. mapovat privátní IP adresy na jednu nebo více veřejných IP adres. Mapování se provádí tak, že hraniční směrovač přepíše u odchozích paketů zdrojovou adresu na svou vlastní IP adresu a případně změní i číslo zdrojového portu (například pokud dvě stanice za NATem používají stejný zdrojový port). 19

26 2. Principy fungování VoIP telefonie Poté si do své interní tabulky uloží (nový) zdrojový port a k němu odpovídající privátní IP adresu a port. Díky této tabulce je schopen u příchozích paketů přepsat v hlavičce IP adresu a port na původní hodnoty a paket přeposlat příslušné stanici v privátní síti. Níže uvedené typy NATu se liší především v omezeních, která se týkají přeposílání příchozích zpráv do privátní sítě: Plný kužel Provádí pouze mapování IP adres a portů a neklade žádná omezení přístupu. Jak je vidět na obrázku 2.7, pokud počítač za NATem s IP adresou vyšle požadavek z portu 8000, dorazí k serveru B jako paket s IP adresou a portem Pokud zná libovolný počítač v internetu toto aktuální mapování (na obrázku počítač A), může poslat data klientovi za NATem na IP adresu a port Směrovač mapování portu používá tak dlouho, dokud přes něj chodí data. Pokud port přestane být aktivní, je po vypršení časového limitu (řádově minuty) odstraněn z mapovací tabulky. Klient IP: Port: 8000 NAT IP: Port: Počítač A IP: Port: Počítač B IP: Port: Obrázek 2.7: NAT typu Plný kužel [6] Omezený kužel Provádí mapování stejně jako plný kužel, ale do vnitřní sítě přeposílá jen pakety přicházející od počítačů v internetu, které dříve kontaktoval klient ve vnitřní síti. Například počítač na obrázku 2.7 kontaktoval počítač B, čímž se vytvořilo mapování portu 8000 na port pro počítač B. Ten může posílat klientovi za NATem data na IP adresu a port Na rozdíl od plného kuželu, pokud na tu samou adresu a port pošle data počítač A, nebudou doručena. Pokud by chtěl klient přijímat data i od počítače A, musel by mu nejprve nějaká data sám poslat, čímž by se vytvořilo mapování i pro počítač A. Kužel omezený na porty Funguje velmi podobně jako Omezený kužel, nicméně mapování se nevytváří nejen pro konkrétní počítač 20

27 2. Principy fungování VoIP telefonie v internetu, ale také pro konkrétní port. Pokud pošle klient na obrázku 2.7 data počítači A na port 80, musí mu počítač A odpovědět přímo ze zdrojového portu 80. Pokud pošle data z jiného portu, nebudou doručena (podobně jako data od jiných počítačů v případě Omezeného kuželu). Pokud chce klient přijímat data z více portů počítače A, musí mu poslat na každý port zvláštní požadavek, kterým otevře NAT. Symetrický NAT U předchozích třech typů NATu se pro jeden odchozí port klienta vytvořilo právě jedno mapování privátního portu na veřejný. Pokud klient posílal z jednoho portu požadavky na více serverů, všechny servery zasílaly odpovědi na stejný veřejný port. V případě NATů typu Omezený kužel a Kužel omezený na porty se navíc povolovaly další příchozí adresy resp. porty. Symetrický NAT se liší v tom, že pro každé spojení vytváří zvláštní mapování portů. Například pokud klient na obrázku 2.8 vytvoří z jednoho portu spojení se dvěma servery, bude serveru A přidělen veřejný port a serveru B veřejný port Zároveň platí stejná omezení jako u NATu typu Kužel omezený na porty, tj., každý server může používat jen veřejný port, přes který mu klient dříve poslal nějaká data. Klient IP: Port: 8000 NAT IP: Port: IP: Port: Počítač A IP: Port: Počítač B IP: Port: Obrázek 2.8: Symetrický NAT [6] Protokol SIP a procházení NATu Protokol SIP nemá většinou s procházením NATu problémy, neboť SIP proxy (podobně jako každá jiná veřejná služba na internetu) má veřejnou IP adresu. Pro správnou funkci protokolu stačí, aby SIP proxy poslala odpověď na stejnou adresu a port, odkud požadavek přišel. Díky tomu se paket dokáže vrátit i do sítí s NATem typu Kužel omezený na porty nebo do sítí se symetrickým NATem (viz kapitola 2.2.2). Jak již bylo řečeno v kapitole 2.2.2, mapování portů na směrovači provádějícím NAT se může v čase měnit. To může způsobovat problémy s přícho- 21

28 2. Principy fungování VoIP telefonie zími hovory, neboť SIP proxy má uloženu aktuální IP adresu a port každého uživatele, aby ho mohla v případě potřeby kontaktovat. Pokud se mapování IP adresy nebo portu změní (případně zmizí) bez vědomí SIP proxy, nebude možné informovat uživatelského agenta o příchozím hovoru. Proto většina uživatelských agentů podporuje zasílání tzv. keepalive paketů, které mají mapování NATu udržet. Keepalive paket může být libovolná SIP zpráva (typicky zpráva REGISTER), která se odesílá v pravidelných časových intervalech na SIP proxy. Díky tomu směrovač ví, že se mapování příslušného portu stále používá, a nevymaže ho z paměti ani po desítkách hodin provozu. Dalším důležitým mechanismem průchodu NATu jsou pole Via v hlavičce SIP požadavku. Když uživatelský agent vytváří SIP zprávu, vloží do ní jedno pole Via se svou aktuální IP adresou a portem. Pokud je za NATem, pak vkládá svou privátní IP adresu. Každá proxy, přes kterou požadavek prochází, provádí dva úkony: Do posledního pole Via přidá tagy received a rport, do kterých uvede skutečnou IP adresu a port, z nichž jí požadavek přišel. Přidá nové pole Via, do kterého uvede svou vlastní IP adresu a port. Díky polím Via se může vrátit odpověď na SIP požadavek stejnou cestou zpátky a navíc uživatelský agent zjistí z tagů v poli Via svou IP adresu a port tak, jak je vidí jeho nejbližší SIP proxy. Díky tomu může v příštích požadavcích uvádět správnou IP adresu a port (zejména v poli Contact, které slouží k přímému kontaktování uživatelského agenta). Jedinou nevýhodou tohoto řešení je fakt, že tagy received a rport nejsou normou přímo vyžadovány a některé starší SIP proxy je nepoužívají. Vyplňování těchto tagů může částečně vynutit uživatelský agent tak, že do pole Via přidá prázdný tag rport, ale ne vždy je to respektováno. Naštěstí je používání těchto starých SIP proxy na ústupu a zejména u komerčních VoIP poskytovatelů se může uživatel spolehnout na to, že signalizace protokolem SIP bude fungovat bez problémů i za symetrickým NATem. Protokol RTP a procházení NATu Zatímco protokol SIP funguje za NATem většinou bez problémů, u protokolu RTP je situace mnohem komplikovanější. Je totiž zapotřebí navázat peerto-peer spojení a pokud jsou oba účastníci za NATem, nemusí mít tento problém vůbec řešení. 22

29 2. Principy fungování VoIP telefonie Při navazování spojení se v těle zprávy INVITE posílá protokolem SDP IP adresa a port, na kterých očekává účastník příchozí hlasová data. Aby bylo možné doručit tato data skrz NAT, je zapotřebí, aby účastník sdělil svému protějšku platnou veřejnou IP adresu a port, otevřel NAT tak, aby se k němu příchozí data skutečně doručila. U některých uživatelských agentů je možné zadat rozsah portů, které mají používat pro příchozí hlasová data. To je užitečné v případě komplikací, protože správce sítě může nastavit směrovač tak, aby daný rozsah portů vždy přeposílal příslušnému VoIP zařízení. Díky tomu není nutné otevírat NAT a porty se mapují 1 : 1. I když toto nastavení často velmi spolehlivě vyřeší problémy s nefunkčním přenosem zvuku, nelze jej použít vždy například uživatel nemusí mít přístup k nastavení směrovače a nebo si přeje používat VoIP telefon v dané síti jen dočasně a nechce proto měnit její konfiguraci. Ve zbytku textu proto budeme předpokládat, že přeposílání portů na směrovači nemůžeme změnit, a že se porty pro příchozí RTP data volí automaticky, náhodně. V tomto případě je nutné před každým hovorem zjistit, jakou má uživatelský agent veřejnou IP adresu, a jak nastavil hraniční směrovač mapování náhodně zvoleného portu. Do těla zprávy INVITE se poté napíše veřejná IP adresa a port, na který směrovač namapoval privátní port uživatelského agenta. Zjištění veřejné IP adresy je poměrně jednoduché lze ji získat od SIP proxy, která ji ukládá do tagu received, nebo se zjistí pomocí serveru STUN (Simple Traversal Utilites for NAT), případně ji uživatel zadá ručně. Mnohem složitější je zjištění veřejného portu. Zde se nabízí dvě možnosti: zeptat se směrovače, jak bude port mapovat, zeptat se serveru v internetu, jakou vidí zdrojovou adresu a port u požadavku vyslaného uživatelským agentem. Některé směrovače podporují protokol UPnP (Universal Plug and Play), kterým se může stanice za NATem dotázat, jak se bude mapovat port, na kterém očekává příchozí data. Nevýhodou tohoto řešení je malá rozšířenost podpory protokolu UPnP a zejména fakt, že se na cestě může vyskytovat několik NATů kaskádovitě za sebou. Například pokud poskytovatel internetu používá NAT, aby nemusel dávat všem zákazníkům veřejné IP adresy, a zároveň i samotný zákazník používá domácí router s NATem, aby mohl rozvést jednu internetovou přípojku do více počítačů v domácnosti. Většinou je proto nutné použít druhou metodu a dotázat se na veřejnou IP adresu a port nějakého serveru v internetu. 23

30 2. Principy fungování VoIP telefonie Principiální schéma dotazu na mapování veřejného portu je znázorněno na obrázku 2.9. Dříve než Alice pošle Bobovi zprávu INVITE obsahující mimo jiné IP adresu a port, na nichž očekává zvuková data od Boba, pošle dotaz NAT sondě, která se nachází ve veřejném internetu (má svou veřejnou IP adresu). Dotaz vychází z portu 3070, který alokoval operační systém Alicina počítače jejímu uživatelskému agentovi pro přenos zvuku. Dotaz prochází skrz hraniční směrovač, který přepisuje jeho IP adresu a port, a k NAT sondě se dostává jako paket se zdrojovou IP adresou a portem NAT sonda posílá zpět odpověď, do níž napíše zdrojovou IP adresu a port odkud jí přišel požadavek. Díky tomu Alice ví, jak se její privátní IP adresa a port zobrazují světu, a posílá Bobovi zprávu INVITE. Do těla zprávy (protokol SDP) zapisuje IP adresu a port, které obdržela od NAT sondy. IP: Port: NAT sonda Alice IP: NAT INVITE IP: Port: 5091 Veřejný internet Bob IP: Port: Obrázek 2.9: Princip zjištění veřejného portu podle [6] Obrázek 2.9 také ukazuje zjednodušený princip činnosti protokolu STUN (Simple Traversal Utilities for NAT), který používá řada SIP klientů pro detekci veřejné adresy a portu. NAT sonda použitá v našem příkladu je zjednodušeným modelem STUN serveru, který zpravidla obsahuje alespoň dvě síťová rozhraní s veřejnými IP adresami nebo je implementován jako dva oddělené servery, které spolupracují. Za použití STUN serveru může Alice pomocí nejvýše 4 dotazů zjistit nejen svou veřejnou IP adresu a port, ale také typ NATu, za kterým se nachází. Toho se docílí tak, že se ptá na obou IP adresách STUN serveru a pak porovnává odpovědi, které dostala. Například pokud jí každá IP adresa STUN serveru vrací jiný veřejný port na dotaz odeslaný ze stejného privátního portu, je jasné, že se nachází za symetrickým NATem (viz kapitola 2.2.2). Pokud uživatelský agent zjistí veřejnou IP adresu a port pomocí STUN serveru, bude přenos zvuku probíhat korektně za splnění následujících podmínek: 24

31 2. Principy fungování VoIP telefonie klient musí posílat a přijímat RTP data na stejném portu, klient musí odeslat SIP zprávu krátce po provedení STUN dotazu, jinak se může změnit mapování portů, v případě, že je klient za NATem typu Omezený kužel nebo Kužel omezený na porty, musí odeslat nejdříve nějaká data druhému účastníkovi, čímž otevře NAT. Zejména třetí podmínka si zaslouží bližší rozbor: už samotným STUN dotazem se nastaví mapování portů na hraničním směrovači. Například na obrázku 2.9 si hraniční směrovač nastavil mapování portu 3070 na port Pokud však použitý typ NATu klade omezení na IP adresy nebo dokonce porty (viz kapitola 2.2.2), je zapotřebí poslat alespoň jeden paket také účastníkovi, od kterého se chystáme přijímat data, jinak NAT doručí pouze data od STUN serveru. V našem příkladu by tedy musela Alice poslat před zprávou INVITE ještě jednu zprávu z portu 3070 Bobovi, čímž by se otevřel NAT i pro něho. Obsah této zprávy není důležitý, například SIP klient Ekiga posílá před začátkem RTP komunikace prázdný paket. Pokud by Alice tento krok neučinila, začala by přijímat data od Boba až ve chvíli, kdy by mu nějaká data sama poslala (tím by se otevřel NAT). Bohužel ani za použití STUN serveru nemáme úplnou jistotu, že se podaří přenést zvukový signál bez problémů. Výše uvedené řešení totiž nefunguje na symetrickém NATu. Jak již bylo řečeno v kapitole 2.2.2, symetrický NAT alokuje pro každou cílovou IP adresu jiný port. Na obrázku 2.9 mapuje směrovač port 3070 pro IP adresu NAT sondy na port Pokud by tento směrovač prováděl symetrický NAT, bylo by mapování tohoto portu pro Bobovu IP adresu jiné. Při použití modelové NAT sondy by Alice o existenci symetrického NATu nevěděla a poslala by Bobovi port, který jí sdělila NAT sonda. Bob by posílal data na port, který je mapován pouze pro NAT sondu a směrovač by tato data zahazoval. Při použití STUN serveru by Alice sice zjistila, že je za symetrickým NATem, nicméně by stejně neměla žádné další prostředky (mimo UPnP), jak by mohla zjistit správné mapování portů. Connection oriented media Connection oriented media je alternativní způsob řešení problému s procházením NATu. Na rozdíl od řešení uvedených v předchozí kapitole se volající nesnaží za každou cenu zjistit mapování IP adresy a portu, na kterých bude 25

32 2. Principy fungování VoIP telefonie očekávat připojení partnera, nýbrž sám se ujímá navazování spojení a posílá data svému partnerovi jako první, čímž zajistí otevření NATu. Volaný účastník ignoruje IP adresu a port, které mu přišly v protokolu SDP, a místo nich očekává příchod prvního RTP paketu. Kvůli snazšímu procházení NATu se drží všichni uživatelští agenti jednoduché konvence odesílají RTP data z portu, na kterém očekávají RTP data z opačného směru. Díky této konvenci zjistí uživatelský agent volaného účastníka hned z prvního RTP paketu, kam má posílat data v opačném směru tj. na IP adresu a port, které jsou v příchozím RTP paketu uvedeny jako zdrojové. Navíc díky použití stejných čísel portů není třeba otevírat NAT (o to se postaral již zmiňovaný první příchozí RTP paket). Aby tento postup fungoval, musí být splněny dvě podmínky: druhý účastník musí vědět, že má ignorovat IP adresu a port uvedené v protokolu SDP, druhý účastník nesmí použít stejný způsob navázání spojení. Aby uživatelský agent věděl, že má ignorovat informaci uvedenou v protokolu SDP, měl by se v protokolu SDP uvést atribut a=direction:active. Bohužel zdaleka ne všichni uživatelští agenti toto podporují. Další možností je poslat protokolem SDP nulovou IP adresu a port, díky čemuž druhému účastníkovi nezbude nic jiného, než čekat na spojení, pokud to podporuje. Tato metoda navazování spojení samozřejmě nefunguje v případě, kdy oba účastníci čekají na to, až se připojí ten druhý. Proto je zapotřebí ji používat jen v nutných případech, zejména když uživatelský agent zjistí, že se nachází za symetrickým NATem. V případě, že se za symetrickým NATem nachází oba účastníci, je tato metoda nepoužitelná. RTP relay RTP relay je internetový server, který zprostředkovává přenos hlasových dat podobně, jako SIP proxy přenáší data signalizační. RTP relay slouží jako prostředník mezi dvěma účastníky, kteří se například díky symetrickým NATům na obou stranách nejsou schopni spojit přímo. Hlavní výhodou RTP relay je veřejná IP adresa, ke které se mohou oba uživatelští agenti snadno připojit a odesílat zvuková data. Pokud se uživatelskému agentovi podaří zjistit veřejnou IP adresu a mapování RTP portu, může uvést tuto informaci v protokolu SDP. RTP relay se k němu připojí a začne mu posílat hlasová data. Pokud se mu to nepodaří, může použít metodu Connection oriented media probranou v předchozí kapitole. Tato metoda funguje vždy, neboť má 26

33 2. Principy fungování VoIP telefonie RTP relay veřejnou IP adresu. Aby se vytvořilo spojení přes RTP relay, je zapotřebí požádat RTP relay o přidělení portů pro hovor, do protokolu SDP uvést přidělený port a IP adresu RTP relay místo svých vlastních. O obě výše zmíněné funkce se stará většinou SIP proxy, která bývá s RTP relay velmi úzce spjata. Ukázka telefonního hovoru za použití RTP relay je vidět na obrázku 2.10: Alice i Bob používají symetrický NAT, a proto se jejich hovor uskuteční s pomocí RTP relay serveru. Alice posílá zprávu INVITE, v níž uvádí svou privátní IP adresu a port. Její SIP proxy se rozhodne použít RTP relay (například na základě toho, že Alice nabízí pro příchozí data neroutovatelnou IP adresu), a proto posílá žádost RTP relay o vytvoření hovoru. RTP relay vytváří nový hovor a v odpovědi posílá porty 4021 a 4022 vyhrazené pro přenos zvuku. Alicina SIP proxy (ustredna.mikrotech.cz) vkládá vyhrazený port a IP adresu RTP relay do zprávy INVITE namísto původní privátní IP adresy a portu IP: Port: 5062 INVITE /3000 Alice IP: NAT SIP proxy ustredna.mikrotech.cz 3123 RTP Setup session OK, 4021, INVITE / OK /4021 RTP relay IP: SIP proxy sip.fayn.cz NAT 5060 RTP IP: Port: OK /3700 Bob IP: Obrázek 2.10: Princip činnosti RTP relay Když zpráva dorazí k Bobovi, vidí v ní port 4022 a IP adresu RTP relay. Oba údaje jsou platné a Bob na ně může začít posílat hlasová data. Bob přijímá hovor a posílá Alici stavový kód 200 OK. I Bob nabízí pro připojení svou privátní IP adresu a port 3700, který po průchodu NATem již nebude platný. Stavová zpráva dojde až k Alicině SIP proxy, která změní její obsah a v protokolu SDP nahradí Bobovu privátní IP adresu a port údaji, které odpovídají RTP relay. Takto změněná zpráva dojde k Alici a hovor může začít. Dejme tomu, že Alice se připojuje k RTP relay první a posílá jí zvuková data pro Boba. RTP relay zatím nezná Bobovu adresu, a proto data pro Boba zahazuje nebo je krátkodobě ukládá do bufferu. Ve chvíli, kdy se připojí Bob, 27

34 2. Principy fungování VoIP telefonie RTP relay zjistí jeho IP adresu a mapování portů a začne mu přeposílat data od Alice. Stejně tak je možné začít okamžitě posílat hlasová data od Boba Alici, protože RTP relay už zná její IP adresu a mapování portů. RTP relay tedy používá postup, který je principiálně shodný s Connection oriented media. Chování RTP relay není definováno žádným standardem, a proto do značné míry závisí na konkrétní implementaci. Z pozorování prováděných v rámci diplomové práce vyplývá, že některé SIP proxy záměrně ignorují IP adresu a port uvedené v protokolu SDP a všechny hovory automaticky přepojují přes RTP relay. Nevýhodou tohoto řešení je samozřejmě jisté plýtvání šířkou pásma a výkonem RTP relay, neboť data, která by normálně tekla přímo mezi dvěma účastníky, musí procházet navíc přes RTP relay a to i v případě, kdy jsou oba účastníci například ve stejné síti. RTP relay také zanáší do hovoru jisté nepatrné zpoždění. RTP relay servery poskytují vysoký uživatelský komfort (není potřeba složitá konfigurace), vysokou spolehlivost (fungují na všech typech NATu) a navíc umožňují i přesný výpočet ceny hovoru. Pokud by totiž hlasová data netekla přes RTP relay, mohl by jeden z účastníků například poslat své SIP proxy zprávu BYE, čímž by VoIP poskytovatel zastavil účtování hovoru, který by přitom dále pokračoval bez účasti SIP proxy. Kromě procházení NATu lze RTP relay použít také například ke konverzi formátu hlasových dat nebo jako rozhraní mezi VoIP telefonem a běžnou telefonní sítí SIP telefonní hovor v praxi V předchozích kapitolách byla probrána různá úskalí navazování telefonního hovoru v sítích, kde dochází k překladu IP adres a portů. Protože je NAT v dnešní době velmi rozšířený, byli komerční VoIP poskytovatelé, kteří se snaží vycházet maximálně vstříc svým zákazníkům, nuceni zareagovat a začít používat protokol SIP trochu jinak, než jak předpokládá dokument RFC 3261 [2] definující SIP. Další motivací ke změně architektury systému byl fakt, že se uživatelé nechtějí omezovat jen na volání v rámci internetu VoIP operátoři umožňují volat do klasické pevné telefonní sítě i na mobilní telefony. V podání dnešních VoIP operátorů se stal protokol SIP jakýmsi rozhraním pro přístup do globální telefonní sítě, která používá své vlastní způsoby přenosu dat. Protokol SIP ve své klasické podobě zůstává zachován jen ve velkých institucích, které jej používají pro spojování hovorů v rámci budovy (hovory na běžná telefonní čísla se přepojují do globální telefonní sítě). 28

35 2. Principy fungování VoIP telefonie Průběh telefonního hovoru tak, jak probíhá u předních českých VoIP poskytovatelů v době psaní této práce, je vidět na obrázku Předpokládejme, že oba účastníci hovoru již poslali zprávy REGISTER svým SIP proxy, které jejich registrace přijaly. Alice posílá zprávu INVITE své SIP proxy a uvádí v ní Bobovo telefonní číslo ve formátu SIP URI. SIP proxy fayn.cz Veřejná telefonní síť SIP proxy ustredna.mikrotech Trying 1. INVITE 12345@fayn.cz Ringing OK 8. ACK 12. BYE OK 10. Přenos hlasu (RTP) RTP relay RTP relay OK 11. Přenos hlasu (RTP) 9. ACK 13. BYE OK 3. INVITE 12345@ Ringing Alice Obrázek 2.11: Skutečně zjištěný průběh hovoru Bob Alice dostává jako odpověď stavový kód 100 Trying a její proxy se připojuje k Bobovi pomocí globální telefonní sítě. Telefonní síť zjistila, že Bobovo číslo spravuje server ustredna.mikrotech.cz a posílá mu požadavek na spojení. Bobova SIP proxy generuje zcela nový požadavek INVITE a ten posílá Bobovi. Bobův počítač zobrazuje hlášení o příchozím hovoru a posílá své proxy stavový kód 180 Ringing, který se přepošle skrz telefonní síť až k Alicině proxy, která vytváří novou stavovou zprávu 180 Ringing a posílá ji Alicině telefonu. Stejným způsobem se doručí i stavový kód 200 OK ve chvíli, kdy Bob zvedne telefon. Hlasová data se posílají přes RTP relay servery, které vlastní oba VoIP poskytovatelé. RTP relay může běžet na stejné IP adrese jako SIP proxy, zpravidla se však jedná o dedikovaný stroj nebo o jeden z několika dedikovaných strojů (v závislosti na počtu zákazníků, které operátor obsluhuje). SIP proxy je s RTP relay servery velmi úzce spojena a přiděluje jim požadavky na přenos jednotlivých hovorů. 29

36 2. Principy fungování VoIP telefonie Ukončení hovoru probíhá obdobným způsobem jako jeho navázání: Alice posílá zprávu BYE, kterou její proxy přeloží do formátu používaném v telefonní síti. Telefonní síť přepošle informaci Bobově proxy, která vygeneruje novou zprávu BYE, jež pošle Bobovi. Bob odpovídá stavovým kódem 200 OK, který se přenese obdobným způsobem Vyzváněcí tóny Už z dob používání analogových telefonů jsou lidé zvyklí, že když začne volanému účastníkovi zvonit telefon, slyší volající ve sluchátku vyzváněcí tón. Stejně tak pokud volaný účastník právě hovoří, ozve se obsazovací tón, a svou zvukovou indikaci má také neplatné telefonní číslo. Všechny tři tóny můžeme samozřejmě slyšet také z VoIP telefonu. Mohou se generovat dvěma různými způsoby: přímo na VoIP telefonu, telefonní ústřednou. První způsob je starší a šetrnější k použité šířce pásma. Vyzváněcí nebo jiný tón generuje přímo telefon, ze kterého voláme. Nevýhodou tohoto řešení je fakt, že v různých zemích se používají různé vyzváněcí tóny. Některé přístroje mají proto tyto tóny nastavitelné pomocí speciálního zápisu lze definovat výšku tónu, jeho délku i opakování. Druhou možností je generování vyzváněcího tónu přímo na ústředně resp. RTP relay serveru. Pokud se použije tato varianta, nepatrně se změní schéma navazování hovoru: Kromě SIP zprávy 180 Ringing posílá SIP proxy ještě zprávu 183 Session Progress, která má ve svém těle v protokolu SDP napsánu IP adresu a port RTP relay, kam může volající účastník posílat data. Uživatelský agent na tuto zprávu zareaguje tak, že pošle první prázdný RTP paket směrem k RTP relay. Tím se otevře NAT (pokud je třeba) a RTP relay zjistí IP adresu a port volajícího účastníka. Poté mu začne prostřednictvím protokolu RTP posílat vyzváněcí případně jiný tón, podobně jako by se jednalo o běžný telefonní hovor. Když volaný účastník zvedne telefon, volajícímu přichází zpráva 200 OK s popisem spojení, který zpravidla odpovídá tomu ze zprávy 183 Session Progress. Výhodou tohoto řešení je fakt, že se místo vyzváněcího tónu může poslat i složitější melodie nebo například hlášení o nízkém stavu kreditu. 30

37 2.2.5 Speciální případy hovoru 2. Principy fungování VoIP telefonie Dosud se při popisu telefonního hovoru v této práci počítalo s nejběžnějším případem, když jeden účastník zavolá druhému, ten hovor přijme a po nějaké době jeden z nich hovor ukončí. Nicméně z hlediska monitorování VoIP telefonie, kterým se zabývá tato práce, je důležité znát i ostatní případy, kdy se hovor navázat nepodaří. V této kapitole je uveden jejich stručný přehled: Zavěšení před začátkem hovoru Jedná se o případ, kdy se volající rozhodne položit telefon ještě dříve, než ho volaný účastník vůbec zvedne. V terminologii protokolu SIP to znamená, že chceme zrušit již odeslanou zprávu INVITE dříve, než od volaného účastníka přišel stavový kód 200 OK. V tomto případě uživatelský agent posílá zprávu CANCEL ve které uvádí pořadové číslo (pole CSeq) požadavku INVITE, který chce zrušit. Pokud vše proběhne správně, SIP proxy odpovídá na požadavek CANCEL stavovým kódem 200 OK a na zrušený požadavek INVITE stavovým kódem 487 Request Canceled. Obsazeno Pokud volaný účastník právě hovoří, SIP proxy volitelně posílá stavový kód 183 Session Progress a přehrává zprávu Volaný účastník právě hovoří. Po skončení nahrávky posílá stavový kód 486 Busy Here. Volající potvrzuje zprávu metodou ACK a ukončuje hovor. Pokud se volající rozhodne ukončit hovor ještě předtím, než se přehraje celá zpráva, musí jeho uživatelský agent zrušit prováděný požadavek INVITE metodou CANCEL podobně jako v případu Zavěšení před začátkem hovoru. Nedostupné číslo Pokud je zadané číslo nedostupné, SIP proxy volitelně posílá stavový kód 183 Session Progress a přehrává zprávu o nedostupnosti čísla. Po skončení nahrávky Volané číslo je nedostupné posílá stavový kód 500 Service Unavailable. Volající tuto zprávu potvrzuje metodou ACK a ukončuje hovor. Ostatní případy Obecně lze říci, že telefonní hovor začíná stavovým kódem 200 OK, který přichází jako reakce na zprávu INVITE. Pokud dojde k chybě, posílá se stavový kód 400 nebo vyšší. Pokud chce operátor přehrát nějaké sdělení (například 31

38 2. Principy fungování VoIP telefonie upozornění na nízký stav kreditu), může tak učinit prostřednictvím stavového kódu 183 Session Progress a teprve poté buď začít hovor stavovým kódem 200 OK nebo skončit s nějakým chybovým kódem. Pokud chce volající ukončit hovor dříve než dostane stavový kód 200 nebo vyšší, musí poslat zprávu CANCEL, protože požadavek stále ještě probíhá. Zpráva INVITE se jako jediná zpráva protokolu SIP potvrzuje (zprávou ACK) a to nejen v případě úspěšného navázání hovoru, ale i v případě chyby nebo zrušení požadavku. 32

39 Kapitola 3 Monitorování VoIP provozu na vysokorychlostních sítích Existují dva základní přístupy k monitorování síťového provozu. První z nich ukládá všechny procházející pakety a jeho hlavní nevýhodou je špatná škálovatelnost. Ukládání celých paketů je na sítích s větším množstvím provozu velmi obtížné nebo i nemožné. Samozřejmě lze zachytávat jen pakety tekoucí na určitých IP adresách a portech, ale tím nezískáme celkovou představu o provozu v síti. Dnes se tato metoda používá především na diagnostiku problémů s nějakou konkrétní síťovou službou nebo aplikací. Pro účel dlouhodobého monitorování sítí se v dnešní době preferuje druhé řešení, které místo celých paketů zaznamenává jen jejich toky v síti. Síťový tok je skupina paketů, které sdílí nějaké společné vlastnosti. Většinou se za tok považují pakety, které mají stejnou zdrojovou a cílovou IP adresu, shodný zdrojový a cílový port, přenášejí data stejného protokolu čtvrté síťové vrstvy (TCP, UDP, ICMP) a vyskytují se přibližně ve stejném čase. Ke každému síťovému toku se ukládají součtové statistiky (například počet přenesených paketů a bajtů) a také agregované statistiky (například příznaky protokolu TCP, které se objevily během přenosu). Koncept měření síťových toků zavedla společnost Cisco v průběhu devadesátých let minulého století při vývoji svých směrovačů, které po příchodu prvního paketu vytvořily tzv. flow record, podle kterého směrovaly všechny následující pakety ze stejného toku. Síťové toky se tedy původně používaly pro interní potřeby síťových prvků, nicméně brzy přibyla podpora jejich exportu za účelem monitorování sítě. Dnes už se síťové toky používají výhradně pro monitorovací účely a kromě aktivních prvků firmy Cisco je umí exportovat i řada dalších zařízení. Pro účely přenosu NetFlow dat (síťových toků) vyvinula společnost Cisco stejnojmenný protokol, který postupně vylepšovala. V dnešní době se používají protokoly NetFlow 5 a NetFlow 9, který byl v roce 2004 standardizován dokumentem RFC O čtyři roky později se objevuje exportní protokol IPFIX, který vzniká už nezávisle na jmenované společnosti a dále rozšiřuje 33

40 LCD-Pro Esc ~ `! MENU SELECT - + # $ % ^ & * ( ) Q W E R T Y U I O P [ A S D F G H J K L Z X C V B N M Caps Lock ; Ctrl Alt LCD-Pro _ - + = { < Print Scrn SysRq Scro l Lock Pause Break Insert Home Delete Num CapsLock Scro l Lock Lock Page Up Num Lock End Page Down / \ : " ', } ] >.? / Alt Gr Ctrl 7 * Home PgUp End 2 + PHONE MIC LINE-IN USB SATA AUDIO CARD READER Esc ~ 3 0 Ins PgDn EJECT DVD-RW Del. POWER F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 `! # $ % ^ & * ( ) Print Scrn SysRq Scro l Lock Pause Break Insert Home Delete Num CapsLock Scro l Lock Lock Page Up Num Lock End Page Down / 7 * Home PgUp End 2 + Enter MENU SELECT - + Q W E R T Y U I O P [ A S D F G H J K L Z X C V B N M Caps Lock ; Shift Shift Ctrl Alt Alt Gr _ - + = { < \ : ', } ] > ".? / Ctrl PHONE MIC LINE-IN USB SATA AUDIO CARD READER 3 0 Ins PgDn EJECT DVD-RW Del. POWER Enter LCD-Pro Esc ~ `! MENU SELECT - + # $ % ^ & * ( ) Q W E R T Y U I O P [ A S D F G H J K L Z X C V B N M Caps Lock ; Ctrl Alt _ - + = { < Print Scrn SysRq Scro l Lock Pause Break Insert Home Delete Num CapsLock Scro l Lock Lock Page Up Num Lock End Page Down / \ : ', } ] > ".? / Alt Gr Ctrl 7 * Home PgUp End 2 + PHONE MIC LINE-IN USB SATA AUDIO CARD READER 3 0 Ins PgDn EJECT DVD-RW Del. POWER Enter 3. Monitorování VoIP provozu na vysokorychlostních sítích možnosti protokolu NetFlow 9. Protokoly NetFlow 9 a IPFIX nemají pevně danou strukturu přenášených dat, a proto jsou velmi flexibilní. 3.1 Architektura systému pro sběr NetFlow dat Jak již bylo řečeno, NetFlow data lze generovat přímo na některých síťových směrovačích. Další možností je použití samostatného zařízení, které se nazývá síťová sonda. Sonda je pasivní měřící prvek, který se připojuje na jednu nebo více monitorovaných linek pomocí tzv. TAPu (Test Access Port), který odbočuje přenášená data v obou směrech do sondy. Další možností je použití tzv. Mirror portu umístěném na některém ze switchů v síti. Možná zapojení síťové sondy jsou naznačena na obrázku 3.1. F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 Shift Shift Switch TAP Mirror port Mirror port F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 Shift Shift NetFlow 9 IPFIX Sonda Sonda Kolektor Obrázek 3.1: Architektura sběru NetFlow dat. Sonda může zjištěné síťové toky ukládat do svého interního úložiště (pokud jím disponuje), ale zpravidla je posílá některým ze standardních NetFlow protokolů na tzv. kolektor, což je zařízení určené pro sběr NetFlow statistik. Kolektor většinou disponuje velkokapacitním diskovým úložištěm, přijímá data z několika sond současně a umožňuje tato data agregovat, vyhodnocovat a prezentovat. 3.2 Cisco AVC Možnosti měření a analýzy síťového provozu neustále rostou, a proto společnost Cisco nezůstala jen u měření síťových toků. V řadě situací může být užitečné kromě hlavičky paketu analyzovat i jeho obsah. Například některé aplikace a viry posílají svá data úmyslně přes port 80, který je určený primárně protokolu HTTP, neboť tento port bývá kvůli prohlížení webu otevřen na drtivé většině firewallů. Při pouhém sledování síťových toků se dá jen těžko odhalit, že na portu 80 tekla jiná dat než WWW stránky. 34

41 3. Monitorování VoIP provozu na vysokorychlostních sítích Proto vznikla technologie Cisco AVC (Application Visibility and Control), která provádí tzv. hloubkovou prohlídku paketu, a z přenášených dat umožňuje určit, jakému protokolu zachycená zpráva odpovídá, nebo dokonce jaká aplikace tento paket odeslala. U řady oblíbených protokolů je možné zjistit i další informace, například URL přenášené WWW stránky u protokolu HTTP. Pro detekci jednotlivých aplikací používá Cisco AVC technologii NBAR (Network Based Application Recognition). Získaná data se exportují společně s NetFlow daty a je možné je dále vyhodnocovat a zpracovávat. Kromě pasivního monitorování umožňuje Cisco AVC na jednotlivé aplikace také odpovídajícím způsobem reagovat například upřednostňovat programy důležité pro chod podniku, detekovat škodlivý software v síti, vytvářet statistiky používaných služeb apod. Analýza obsahu přenášených paketů je trend, kterým se momentálně ubírají NetFlow monitorovací nástroje. Ostatně i tématem této diplomové práce je v podstatě hloubková analýza paketů protokolu SIP. 3.3 Existující nástroje pro monitorování VoIP provozu VoIP telefonie se těší stále rostoucí oblibě, a proto není divu, že v současné době existuje celá řada monitorovacích nástrojů určená pro sledování telefonních hovorů a odhalování problémů souvisejících s jejich kvalitou. Tato kapitola shrnuje současný stav monitorování VoIP provozu a představuje nejdůležitější dostupné produkty. Pro všechny z nich platí, že pro vyhodnocování telefonních hovorů používají jednu nebo dvě z následujících metod: Ukládání celých paketů týkajících se VoIP provozu. Čtení statistik Cisco IP-SLA. Export síťových toků s informacemi o VoIP provozu. Nejběžnější je první zmíněná metoda, která na jednu stranu poskytuje maximální množství informací o hovoru, ale na druhou stranu má i svá výkonnostní omezení. Paketů týkajících se VoIP provozu chodí sice i na velkých sítích poměrně málo, ale monitorovací nástroje musí být schopné je včas rozlišit od ostatního provozu. Pakety je sice možné filtrovat například podle portů nebo VLAN tagů, ale tím už sledujeme jen tu část sítě, kde VoIP provoz očekáváme. Druhou možností je čtení IP-SLA (Service Level Agreements) [15] statistik, které umožňují exportovat některé směrovače Cisco. Jedná se o poměrně snadný a přímočarý způsob získávání dat, nicméně statistiky podávají pouze 35

42 3. Monitorování VoIP provozu na vysokorychlostních sítích obecné informace o ztrátovosti paketů a jejich rozptylu. Informace o průběhu jednotlivých hovorů a volajících stranách jsou tudíž velmi omezené nebo se musejí získávat jiným způsobem. Navíc aby bylo možné použít tuto metodu získávání dat, je zapotřebí mít v síti směrovače, které podporují export IP- SLA dat. Poslední možností je rozšířit koncept NetFlow tak, aby umožňoval exportovat informace týkající se telefonních hovorů. Toto řešení nabízí vysoký výkon, ale ani zde se neukládají všechny dostupné údaje. Proto je zapotřebí velmi dobře zvážit, jaká data se budou ukládat, aby z nich získal operátor co nejlepší představu o dění v síti. Zatím jediným zástupcem tohoto postupu je rozšíření sondy nprobe, které implementoval Luca Deri. Tomuto tématu se věnuje také článek SIPFIX: A Scheme For Distributed SIP Monitoring [1], z něhož částečně vychází i tato diplomová práce VoIPmonitor VoIPmonitor [11] je komerční nástroj pro sledování VoIP provozu běžící na operačním systému Linux, který je založen na stejnojmenném otevřeném nástroji VoIP monitor [12]. Umožňuje zpracovávat protokoly SIP, RTP, RTCP a Cisco SKINNY (SCCP), vyhodnocovat rozptyl a ztrátovost paketů a určovat kvalitu hovoru podle doporučení ITU-T G.107 [10]. Zachycená data se ukládají do databáze MySQL nebo do jiné SQL databáze s rozhraním ODBC. VoIPmonitor umí uložit celý hovor jako soubor PCAP nebo dekódovat hlasovou komunikaci a uložit ji ve formátu WAV (pouze při použití některého z podporovaných kodeků). Dále je možné zobrazovat statistiky kvality a počtu hovorů, podíl návratových kódů SIP proxy, stav registrací jednotlivých SIP klientů, generovat události při výskytu určité akce (například telefonního hovoru) a posílat pravidelné reporty. VoIPmonitor má příjemnou obsluhu a vyniká rychlou odezvou. Uživatelé, kteří nepotřebují placenou podporu a vyladěné grafické rozhraní, mohou použít originální volně šiřitelnou verzi programu VoIP monitor, která je samozřejmě zdarma i pro komerční použití PRTG Network Monitor PRTG Network Monitor [13] je nástroj pro komplexní monitorování sítě. Umožňuje jak pasivní monitorování síťových spojů, tak aktivní kontrolu funkčnosti síťových služeb podobně jako například volně šiřitelný nástroj Nagios. PRTG se instaluje na počítače s operačním systémem Windows a pro své ovládání nabízí jak webové rozhraní, tak textovou konzoli a aplikace 36

43 3. Monitorování VoIP provozu na vysokorychlostních sítích pro mobilní telefony. Ze stránek výrobce bohužel není patrné, jaké množství síťového provozu je aplikace schopna měřit. Aplikace nabízí dva způsoby měření VoIP provozu: Pokud některý směrovač v síti podporuje technologii Cisco IP-SLA [15], umožňuje načítat informace podávané tímto směrovačem. V opačném případě je nutné použít tzv. QoS Sensor, kterým je možné měřit kvalitu VoIP hovorů v síti přímo. Bohužel aplikace nepodporuje dekódování signálních informací protokolu SIP (alespoň se o tom výrobce na svých stránkách nezmiňuje). Tento fakt pokládám za největší nevýhodu tohoto monitorovacího systému VoIP & Network Quality Manager VoIP & Network Quality Manager [14] od společnosti Solarwinds je velmi komplexní nástroj pro sledování sítě, který mimo jiné podporuje i analýzu VoIP provozu. Aplikace běží na systému Microsoft Windows a má poměrně vysoké systémové požadavky. Umožňuje zobrazovat seznamy hovorů pro předem definované regiony, hodnotí kvalitu hovoru na stupnici 1 5, zobrazuje statistiky ztracených paketů a jejich rozptyl a umí generovat výstrahy v případě výskytu nějaké definované události. Data o kvalitě hovorů umí získávat i ze směrovačů podporujících IP-SLA [15] Homer Homer je profesionální nástroj na monitorování VoIP telefonie na bázi protokolu SIP s otevřeným kódem. Na rozdíl od předchozích představovaných řešení umožňuje přijímat data přímo z některých typů SIP serverů (Kamailio, OpenSIPS a FreeSWITCH), takže může být vhodným nástrojem pro správce VoIP telefonních ústředen. Pokud není možné odbočit SIP komunikaci přímo ze serveru, lze ji zachytávat na monitorované síti pomocí knihovny libpcap. Homer běží na operačním systému Linux, data ukládá do databáze MySQL. Umožňuje zobrazovat seznamy uskutečněných hovorů, filtrovat je podle různých kritérií a v případě potřeby dokáže zobrazit celé SIP zprávy týkající se jednoho hovoru v textové i grafické podobě. Jeho součástí jsou i různé funkce pro generování statistik a hodnocení kvality hovoru. Často potřebná zobrazení je možné umístit ve formě widgetů na hlavní uživatelskou stránku. Na programu Homer nejvíce oceňuji řadu podporovaných vstupních rozhraní a dostupnost detailního záznamu a zobrazení informací o telefonním hovoru (včetně stažení celé komunikace ve formátu PCAP). 37

44 3. Monitorování VoIP provozu na vysokorychlostních sítích nprobe a ntop nprobe a ntop [18] jsou NetFlow sonda a kolektor s otevřeným kódem, které v rámci své výzkumné práce Open Source VoIP Traffic Monitoring [17] rozšířil italský vývojář Luca Deri o podporu rozpoznávání VoIP provozu. Zatímco všechna předchozí řešení spoléhají na zachytávání a ukládání celých paketů přenášejících VoIP data, rozšířená sonda nprobe ukládá pouze nejnutnější informace, které exportuje jako doplňující pole síťových toků. Kolektor ntop je upraven tak, aby dokázal přijímat tato rozšířená data, a umožňuje zobrazit základní údaje o telefonním hovoru. Bohužel se zdá, že vývoj těchto rozšíření od doby vydání vědeckého článku nijak výrazně nepokračuje, a proto zůstává toto řešení pro koncové uživatele zatím jen obtížně použitelné. 3.4 Monitorování VoIP provozu pomocí řešení FlowMon Řešení FlowMon vyvíjené českou společností INVEA-TECH je jedním z předních produktů pro záznam a vyhodnocování NetFlow dat v síti. Nabízí síťové sondy FlowMon Probe umožňující monitorovat jednu až čtyři metalické nebo optické linky o rychlosti až 10 Gb/s a zpracovat současně až 4 miliony toků. NetFlow data lze ukládat na vestavěný kolektor o kapacitě 500 GB nebo je exportovat na dedikovaný kolektor. FlowMon Probe podporuje exportní formáty NetFlow 5, NetFlow 9 a IPFIX. FlowMon Collector je zařízení pro sběr a vyhodnocování NetFlow dat o kapacitě až 12 TB. Díky podpoře standardních datových formátů může přijímat data nejen od sond FlowMon Probe, ale i od jiných zařízení generujících síťové toky ve formátech NetFlow nebo IPFIX. Produkty rodiny FlowMon jsou velmi flexibilní a umožňují snadno rozšiřovat funkce sondy i kolektoru pomocí pluginů. Cílem této diplomové práce je navrhnout sadu zásuvných modulů pro sondu a kolektor, které umožní monitorování VoIP telefonie založené na protokolu SIP. Navržený systém by měl mít následující vlastnosti: Práce na principu síťových toků. Podpora čtení paketů protokolu SIP, SDP, RTP a RTCP. Získání informací o hovoru kdo, kdy a komu volal, jak dlouho hovor trval a jestli vůbec proběhl. Schopnost přiřadit RTP tok k telefonnímu hovoru. 38

45 3. Monitorování VoIP provozu na vysokorychlostních sítích Detekce použitého kodeku. Kontrola kvality telefonního hovoru (počet ztracených paketů a jejich rozptyl). Schopnost vyfiltrovat toky týkající se jednoho hovoru. Odlišení VoIP toků od ostatních síťových toků, zobrazení seznamu posledních hovorů. Jednoduché grafické rozhraní pro vyhodnocování naměřených dat. Integrace do řešení INVEA-TECH FlowMon. Z výše uvedeného výčtu je vidět, že bude potřeba rozšířit funkce síťové sondy tak, aby mimo základních metrik síťového toku zaznamenávala také informace týkající se telefonních hovorů. Tyto informace se budou posílat na kolektor, který umožní jejich další vyhodnocení. Sondová část systému bude implementována jako rozšiřující modul do programu FlowMon Exportér, který se stará o generování NetFlow dat. Hlavní funkcí tohoto modulu bude identifikace a zpracování paketů protokolu SIP a rozšíření množiny NetFlow dat o další exportovaná pole. Uvedený modul umožní také identifikovat hlasová data posílaná protokolem RTP a měřit kvalitu hovoru. Kolektorovou část systému bude tvořit jednoduché uživatelské rozhraní, které se nainstaluje jako zásuvný modul do zařízení FlowMon, a umožní zobrazit rozšířené statistiky týkající se VoIP provozu, filtrovat toky svázané s určitým telefonátem a provádět automatickou analýzu hovorů. Data mezi sondou a kolektorem se budou přenášet pomocí protokolu IPFIX (IP Flow Information exchange) [8], který je považován za nástupce protokolu NetFlow 9 společnosti Cisco. Na rozdíl od něho umožňuje protokol IPFIX definovat vlastní pole v NetFlow datech, což výrazně usnadní přenos informací o telefonních hovorech ze sondy na kolektor. 39

46 Kapitola 4 Programové vybavení síťové sondy Síťovou sondou se rozumí zařízení, které je schopné pasivně monitorovat (tj. pouze poslouchat) síťový provoz, zpracovávat a exportovat naměřená data. Export dat se může provádět i do souboru, ale většinou se získaná data ihned odesílají (exportují) na kolektor. Pro účely této práce byla použita sonda FlowMon Probe společnosti INVEA-TECH, která mi poskytla zázemí při psaní této práce. FlowMon sonda se dodává buď ve formě samostatného serveru (procesor Intel Xeon, 4 GB RAM, pevný disk 500 GB) nebo jako virtuální stroj Vm- Ware ESXi. Na zařízení běží upravený operační systém CentOS 5. Každá sonda má jedno síťové rozhraní (eth0) určené pro vzdálenou správu a jedno nebo více monitorovacích rozhraní, která se připojují na měřenou linku. Získaná data lze ukládat buď na vestavěné úložiště o velikosti 500 GB nebo je exportovat na dedikovaný kolektor. 4.1 FlowMon Exportér 4.0 FlowMon Exportér je klíčovou součástí programového vybavení sondy. Umožňuje měřit síťový provoz o vysokých rychlostech (řádově sta tisíce paketů za sekundu) a agregovat ho do síťových toků. Pro výstupní data lze zvolit některý z běžně používaných formátů např. NetFlow 5, NetFlow 9 nebo IPFIX. Jeho funkčnost lze snadno rozšířit prostřednictvím zásuvných modulů, které používají veřejně dostupné aplikační rozhraní. Aktuální stabilní verze nese označení 3.5, nicméně tato diplomová práce se zabývá novou testovací verzí 4.0, která přináší mnohá vylepšení jak z hlediska funkcí, tak i výkonu. Exportér se spustí nad zvoleným síťovým rozhraním a zpracovává příchozí pakety. Výsledkem jejich zpracování jsou tzv. flow recordy, které obsahují mimo jiné následující údaje: Začátek toku, konec toku, 40

47 počet přenesených paketů, počet přenesených bajtů, id vstupního a výstupního zařízení, zdrojovou a cílovou IP adresu, přenosový protokol, 4. Programové vybavení síťové sondy zdrojový a cílový port (protokoly TCP a UDP), příznaky protokolu TCP (protokol TCP), typ ICMP zprávy (protokol ICMP). Získané flow recordy se ukládají do bufferu, který se nazývá flow cache. Pokud dojde k vložení záznamu, který odpovídá nějakému již existujícímu flow recordu (tj. shodují se zdrojová a cílová IP adresa, zdrojový a cílový port a protokol čtvrté síťové vrstvy), dojde k agregaci obou záznamů a to tak, že se aktualizuje původní záznam a ten nový se po dokončení agregace uvolní z paměti. Síťový tok se zdrží ve flow cache maximálně několik minut a opouští ji při splnění některé z následujících podmínek: Uplynul časový limit a k toku nepřibyl žádný další paket tok skončil. Tok trvá moc dlouho je třeba udělat průběžný export a rozdělit ho. Došlo ke kolizi ve flow cache je třeba uvolnit místo. Některý zásuvný modul rozhodl o tom, že se má tok ihned exportovat. Po opuštění flow cache je tok zařazen do fronty toků připravených k exportu. Obsah této fronty se v pravidelných intervalech prochází a exportuje. Cíl a formát výstupu je určen typem exportního pluginu Základní použití Aby mohl FlowMon Exportér začít pracovat, potřebuje znát alespoň název vstupního a exportního pluginu a jejich parametry. Jak již název napovídá, vstupní plugin zajišťuje čtení dat ze síťového rozhraní nebo ze souboru, zatímco exportní plugin zodpovídá za kódování výstupu například do formátu NetFlow nebo prostého CSV. Vstupní plugin se zadává pomocí přepínače -I, exportní plugin pomocí přepínače -E. Pokud chceme pluginu předat nějaké 41

48 4. Programové vybavení síťové sondy parametry, uvedeme za jeho názvem dvojtečku následovanou seznamem parametrů ve formátu parametr1=hodnota,parametr2=jiná_hodnota. Výpis všech dostupných pluginů se získá pomocí přepínače -l. Pokud používáme plugin, který čte data z fyzického síťového rozhraní (ne ze souboru), musíme spustit Exportér pod uživatelem root, aby měl práva přistupovat k požadovanému síťovému rozhraní. V tomto případě bychom neměli zapomenout uvést parametr -u uživatel, který umožní běžet Exportéru pod zadaným uživatelským účtem a oprávnění uživatele root používat jen pro přístup k síťovému rozhraní. Základní spuštění Exportéru může vypadat například takto: # flowmonexp -u flowmon -I rawnetcap : device = eth2, sampling =2,\ cache - size = E csv Výpis kódu 4.1: Spuštění FlowMon Exportéru se základními paramtery Uvedený příkaz spustí Exportér nad rozhraním eth2 a bude vypisovat exportované toky na standardní výstup ve formátu CSV. Pokud chceme spustit Exportér na pozadí, použijeme volbu -d. Pomocí přepínače -t a:i lze nastavit časový limit pro export toku v sekundách. Hodnota a odpovídá času pro export toku, který je stále ještě aktivní (průběžný export), zatímco hodnota i odpovídá času, po kterém se exportují toky, které nejsou již dále aktivní. Seznam dalších přepínačů lze zobrazit pomocí přepínače -h Rozšiřující moduly Jak již bylo řečeno, základní funkcionalitu Exportéru lze rozšířit pomocí pluginů, které zasahují do různých fází zpracování paketu (viz kapitola 4.1). Existuje celkem pět typů rozšiřujících modulů: Input zodpovídají za vstup paketů do Exportéru. Reflector umožňují přistupovat k celému obsahu paketu a zpracovávat ho vlastním způsobem (nevytváří flow recordy). Process dodatečně zpracovávají příchozí pakety, filtrují je a umožňují řídit jejich agregaci. Filter filtrují data před exportem. Export zajišťují export dat v určitém formátu. Rozšiřující moduly mají podobu sdílených knihoven (.so) a mohou implementovat jeden nebo i více typů pluginu najednou. K překladu rozšiřujícího 42

49 4. Programové vybavení síťové sondy modulu je zapotřebí mít v adresáři /usr/include/flowmonexp hlavičkové soubory Exportéru, které společnost INVEA-TECH poskytuje zdarma členům svého Community programu 1. Aby Exportér začal používat plugin, je zapotřebí příslušný soubor umístit do adresáře /usr/lib/flowmonexp resp. /usr/lib64/flowmonexp (podle architektury systému) nebo při spuštění uvést přepínač -X cesta/k/pluginu. Poté se nový modul zobrazí ve výpisu dostupných pluginů a lze jej používat stejně jako kterékoliv jiné rozšíření Aplikační rozhraní rozšiřujících modulů Hlavičky nejdůležitějších funkcí pro rozšiřující moduly najdeme v hlavičkových souborech record.c a plugin.h. První z nich obsahuje definici flow recordu a nabízí pomocné funkce pro práci s touto datovou strukturou. Druhý jmenovaný obsahuje výčet všech typů pluginů a konfigurační struktury. Dále je zapotřebí zmínit hlavičkové soubory pro jednotlivé typy pluginů. Například pokud vytváříme procesní plugin, budeme potřebovat soubor plugin_process.h. Tyto soubory obsahují hlavičky funkcí, které musí programátor pro daný typ pluginu definovat. V neposlední řadě je třeba uvést ještě soubor utils.h obsahující pomocné funkce a soubor debug.h obsahující funkce pro generování ladících výpisů. Každý rozšiřující modul musí obsahovat definici svého typu. Ta se provádí makrem SET_PLUGIN_TYPE, výčet možných hodnot je možné najít v souboru plugin.h. Dále je zapotřebí uvést aktuální verzi API, pro kterou plugin píšeme. Ta se řídí aktuální verzí hlavičkových souborů, které používáme. Proto stačí uvést jen makro pro výpis verze FLOWMON_API_VERSION, které provede definici za nás. Například začátek procesního pluginu by mohl vypadat podobně jako výpis # include <stdio.h> # include < stdlib.h>... # include < flowmonexp / plugin.h> # include < flowmonexp / plugin_ process.h > # include < flowmonexp / utils.h>... /* Set plugin type : */ SET_ PLUGIN_ TYPE ( PLUGIN_ TYPE_ PROCESS ) 1. O registraci do Community programu je možné požádat v kontaktním formuláři na stránce 43

50 4. Programové vybavení síťové sondy /* Include API version : */ FLOWMON_ API_ VERSION... Výpis kódu 4.2: Ukázka možného začátku procesního pluginu. Dále musí všechny typy pluginů obsahovat funkci desc(), která vrací základní informace o zásuvném modulu zabalené ve struktuře plugin_desc_t (výpis 4.3). Proměnné name a help obsahují jméno pluginu a jeho popis, který se zobrazí v seznamu pluginů při spuštění Exportéru s argumentem -l. Proměnná data_size udává délku privátních dat, která si potřebuje modul uložit do flow recordu. Délka extenze flow recordu musí být vždy konstantní! Poslední položka je obsahuje doplňující nastavení pluginu a liší se pro jednotlivé typy rozšíření. Možné hodnoty jsou k nalezení v hlavičkovém souboru plugin.h a nebudu se jim podrobněji věnovat. typedef struct { char * name ; char * help ; uint16_ t data_ size ; plugin_ flags_ t flags ; } plugin_desc_t ; Výpis kódu 4.3: Struktura plugin_desc_t Každý plugin definuje funkci init(), která se spouští po startu Exportéru (samozřejmě jen pokud je plugin povolen) a ve svých parametrech dostává argumenty z příkazové řádky a případně nějaká další nastavení. Hlavičky funkcí init() nejsou pro všechny pluginy stejné a jsou k nalezení v příslušných hlavičkových souborech. Důležité je, že všechny init() funkce vrací ukazatel na svá privátní data, která si během inicializace vytvoří (například zpracováním argumentů z příkazové řádky). Tento ukazatel je pak dostupný i v jiných funkcích, které se volají během života pluginu. Pokud funkce vrátí NULL, považuje se to za selhání inicializace pluginu. Všechny pluginy definují také funkcishutdown(), která se volá před ukončením Exportéru. U všech typů pluginů má funkce jediný parametr a tím je ukazatel na privátní data, který vrátila funkce init(). Plugin tak dostává před ukončením Exportéru možnost uvolnit alokovaná data a korektně se ukončit. Funkce shutdown() vrací hodnotu typu int, která zatím nemá žádný význam. Dále je třeba implementovat funkce uvedené v hlavičkovém souboru pro typ pluginu, který píšeme. Tato diplomová práce používá FlowMon Exportér k řešení konkrétního problému a neklade si za cíl napsat jeho podrobnou 44

51 4. Programové vybavení síťové sondy dokumentaci. Dále se proto budu věnovat už jen procesnímu pluginu, který je použit pro vyhodnocování VoIP provozu. Další informace o jednotlivých typech pluginů a jejich API jsou k dispozici členům INVEA-TECH Community programu. 4.2 Procesní plugin process-voip Rozšiřující modul process-voip představuje sondovou část navrženého systému pro monitorování VoIP telefonie a umožňuje Exportéru analyzovat pakety protokolů SIP, RTP a RTCP. Získaná data je možné zpracovávat stejně jako data získaná jinými pluginy nebo samotným Exportérem. Jistým omezením však může být použitý exportní plugin. Například protokoly NetFlow společnosti Cisco umožňují přenášet jen jistou pevně danou množinu polí, a proto s nimi není možné VoIP statistiky exportovat. Export VoIP metrik funguje bez problémů s výstupem do CSV (vhodný na testování) a s exportním pluginem ipfixx 2, který exportuje NetFlow data prostřednictvím protokolu IPFIX. Aktuální verze pluginu ipfixx zatím nepodporuje FlowMon Exportér 4.0, a proto doporučuji použít upravenou verzi, která se nachází na přiloženém CD v adresáři bin/flowmon-export-ipfix Exportovaná data je možné ukládat na libovolném NetFlow kolektoru, který podporuje protokol IPFIX. Kromě nových polí přidává rozšiřující modul také jemnější dělení toků protokolu SIP. Motivací k tomuto kroku byl fakt, že přidaná VoIP pole jsou schopna popsat parametry vždy nejvýše jednoho telefonního hovoru. Pokud by si mezi sebou dva účastníci volali například dvakrát za sebou, mohlo by se stát, že by oba hovory splynuly v jeden tok, čímž by se ztratila informace o druhém hovoru. Proto se toky rozdělují tak, aby jeden SIP tok odpovídal nejvýše jednomu hovoru. Zvláštní skupinu toků pak tvoří SIP provoz, který neodpovídá žádnému konkrétnímu hovoru. Ostatních typů provozu se toto zjemněné dělení toků nijak nedotýká. Zdrojové kódy zásuvného modulu process-voip se nachází na přiloženém CD v adresáři src/process-voip. Pokud chceme spustit Exportér s tímto rozšířením, je třeba jej nejprve přeložit zavoláním příkazu make ve zmíněném adresáři. K překladu jsou zapotřebí hlavičkové soubory programu FlowMon Exportér, které na požádání poskytne společnost INVEA-TECH. Použití pluginu je velmi jednoduché, neboť ke svému spuštění nevyžaduje žádnou konfiguraci. Do parametrů Exportéru stačí přidat jen název pluginu pomocí přepínače -P voip a eventuálně i cestu pomocí přepínače -X (pokud 2. Zdarma ke stažení na adrese velan/flowmon-export-ipfix/ 45

52 4. Programové vybavení síťové sondy Jméno pole EID ID Popis VOIP_PACKET_TYPE Typ paketu (ne-voip, přích. hovor, odch. hovor, přích. servisní data, odch. servisní data, RTP, RTCP). SIP_CALL_ID ID hovoru. SIP_CALLING_PARTY SIP URI volajícího. SIP_CALLED_PARTY SIP URI volaného. SIP_VIA SIP proxy, přes které šel požadavek. SIP_INVITE_RIN Čas zahájení hovoru/čas, kdy začal vy- GING_TIME zvánět telefon. SIP_OK_TIME Čas přijetí/odmítnutí hovoru. SIP_BYE_TIME Čas ukončení hovoru. SIP_RTP_IPV IPv4 adresa pro RTP data. SIP_RTP_IPV IPv6 adresa pro RTP data. SIP_RTP_AUDIO Port zvukového RTP kanálu. SIP_RTP_VIDEO Port obrazového RTP kanálu. SIP_STATS Agregované statistiky SIP zpráv. RTP_CODEC Použitý RTP kodek. RTP_JITTER Rozptyl RTP paketů pro RTP měřený sondou, pro RTCP udávaný příjemcem. RTCP_LOST Počet ztracených paketů nahlášený příjemcem. RTCP_PACKETS Počet odeslaných RTP paketů. RTCP_OCTETS Počet odeslaných bajtů v RTP datech. RTCP_SOUR Počet zdrojů RTP dat. CE_COUNT Tabulka 4.1: Pole exportovaná pluginem process-voip. se plugin nenachází v některém z přednastavených adresářů pro zásuvné moduly). Získané podrobnosti o telefonních hovorech se přidávají k základním polím NetFlow dat, která se exportují. Seznam všech přidaných polí je vidět v tabulce 4.1. Sloupce EID (Enterprise ID) a ID (Element ID) obsahují identifikační čísla polí, která se používají pro jejich přenos protokolem IP- FIX. Podle této tabulky lze na kolektoru přidělit nově přidaným polím jejich správná jména. Exportovaná pole lze rozdělit do čtyřech skupin podle toho, k jakému protokolu se váží. Pole VOIP_PACKET_TYPE tvoří samostatnou skupinu, exportuje se u všech toků a udává typ paketu z pohledu detekce VoIP provozu. Díky tomuto poli lze za pomoci bitové masky filtrovat i několik typů toků souvisejících s VoIP provozem současně. Může nabývat některé z následujících hodnot: 46

53 0 Data nesouvisející s VoIP. 1 Servisní požadavky protokolu SIP. 4. Programové vybavení síťové sondy 2 Odpovědi na servisní požadavky protokolu SIP. 3 SIP požadavky pro práci s hovorem. 4 Odpovědi na SIP požadavky pro práci s hovorem. 8 Hlasová data přenášená protokolem RTP. 16 Řídicí a statistické zprávy protokolu RTCP. Pole s předponou SIP se exportují pouze u toků, v nichž se přenášela data protokolem SIP. Protože procesní plugin rozeznává celkem čtyři druhy SIP zpráv, význam některých exportovaných polí se pro jednotlivé typy SIP toků liší a při jejich interpretaci je třeba přihlédnout také k hodnotě pole VOIP_PACKET_TYPE. Seznam těchto polí a jejich význam je uveden v tabulce 4.2. Jméno pole Typ Význam SIP_INVITE_RIN- 1, 2 GING_TIME 3 Čas poslání první zprávy INVITE. 4 Čas poslání prvního stavu 180 Ringing. SIP_OK_TIME 1, 2, 3 4 Čas přijetí nebo odmítnutí hovoru. SIP_BYE_TIME 1, 2, 4 3 Čas ukončení hovoru. SIP_RTP_IPV4 1, 2 3, 4 IPv4 adresa pro příjem RTP dat. SIP_RTP_IPV6 1, 2 3, 4 IPv6 adresa pro příjem RTP dat. SIP_RTP_AUDIO 1, 2 3, 4 Port pro příjem zvukových dat protokolem RTP. SIP_RTP_VIDEO 1, 2 3, 4 Port pro příjem obrazových dat protokolem RTP. SIP_STATS 1 Statistiky přenesených zpráv. Viz příloha A.1. SIP_STATS 2 Statistiky přenesených zpráv. Viz příloha A.2. SIP_STATS 3 Statistiky přenesených zpráv. Viz příloha A.3. SIP_STATS 4 Statistiky přenesených zpráv. Viz příloha A.4. Tabulka 4.2: Rozdílná interpretace některých SIP polí. Zvláštní pozornost si zaslouží zejména pole SIP_STATS, které obsahuje obsahuje počítadla nejčastějších druhů SIP zpráv nebo stavových kódů. Toto 47

54 4. Programové vybavení síťové sondy pole se exportuje jako 64bitové celé číslo a konkrétní statistiky z něho lze číst pomocí bitové masky. Význam jednotlivých bitů je uveden v příloze A na konci diplomové práce. Další skupinu polí tvoří ta s předponou RTP a týkají se pouze toků vedoucích komunikaci stejnojmenným protokolem. Jistou výjimku zde tvoří pole RTP_JITTER, které se exportuje i u toků protokolu RTCP. Rozdíl je opět ve významu. Zatímco u RTP toků toto pole udává rozptyl paketů měřený FlowMon sondou, u toků protokolu RTCP se do něj ukládá hodnota rozptylu, kterou hlásí příjemce dat. Poslední skupinu polí tvoří ta s předponou RTCP a obsahují statistické údaje vyčtené z paketů protokolu RTCP Implementace pluginu process-voip Zdrojový kód rozšiřujícího modulu je pro lepší přehlednost rozčleněn do několika souborů. Základem je soubor process-voip.c, který implementuje všechny povinné funkce pluginu. Hlavičkový soubor process-voip.h obsahuje všechny důležité struktury, které se v rozšiřujícím modulu používají. Při psaní pluginu byl kladen důraz na co možná nejvyšší výkon, a proto jsou v některých místech kódu použity ne zcela čitelné konstrukce přispívající ke zvýšení propustnosti systému. Vzhledem k tomu, že plugin ukládá poměrně velké množství dat, nebylo by je moudré přidávat přímo do základního flow recordu. Pokud by totiž byly flow recordy příliš velké, nemusely by se vejít do vyrovnávacích pamětí a tím by snižovaly výkon systému. Navíc VoIP provoz tvoří pouze malou podmonožinu celkového síťového provozu, a proto by velké množství flow recordů obsahovalo pouze nevyplněná pole pro VoIP data. typedef struct { /* Pointer to sip_data_t, rtp_ data_ t or rtcp_ data_ t : */ void * data ; } voip_record_t ; Výpis kódu 4.4: Struktura voip_record_t. Proto byl nakonec flow record rozšířen jen o strukturu voip_record_t. Jak je vidět na výpisu 4.4, struktura obsahuje pouze ukazatel na data, která se ukládají v dynamicky alokované paměti mimo flow record. Pokud má atribut data hodnotu NULL, nejedná se o VoIP záznam (pole VOIP_PACKET_TYPE bude mít hodnotu nula). V opačném případě ukazatel vede na strukturu sip_data_t, rtp_data_t nebo rtcp_data_t. Všechny tři jmenované struktury začínají 8bitovým atributem packet_type, který odpovídá exportnímu poli VOIP_PACKET_TYPE. Protože má toto pole ve všech třech strukturách 48

55 4. Programové vybavení síťové sondy stejnou pozici, lze zjistit typ paketu pomocí makra PACKET_TYPE() a teprve podle výsledku ukazatel přetypovat na příslušnou strukturu. Funkce init() Provádění pluginu začíná funkcí plugin_process_init, jejíž prototyp je uveden na výpisu 4.5. Parametr params je ukazatel na řetězec obsahující parametry předané na příkazové řádce. Getter_list je ukazatel na seznam getterů, které bude poskytovat Exportér výstupnímu pluginu. Getterem se rozumí funkce, která vrací hodnotu některého z exportovaných polí. Plugin potřebuje mít k dispozici seznam getterů proto, aby do něho mohl přidat své vlastní gettery pro vrácení VoIP metrik. void * plugin_ process_ init ( char * params, flow_ record_ getter_ t ** getter_list, int data_offset, int queue_ count ); Výpis kódu 4.5: Inicializační funkce pluginu. Dalším důležitým parametrem je data_offset, který udává pozici privátních dat pluginu ve flow recordu. Pro lepší pochopení si lze flow record představit jako strukturu, na za níž se postupně skládají struktury s privátními daty každého pluginu. Pokud chce plugin získat svá vlastní privátní data, musí k adrese flow recordu přičíst právě tento offset, čímž se dostane za hranici základního flow recordu, kde jsou uložena jeho data (v našem případě struktura voip_record_t). Posledním parametrem je queue_count, jenž udává počet front, které paralelně zpracovávají pakety. Funkce vrací ukazatel na privátní data pluginu v tomto případě se jedná o globální konfiguraci pluginu, nikoliv o extenzi flow recordu. V našem případě plugin registruje gettery pro všechna pole uvedená v tabulce 4.1 pomocí funkce plugin_input_getter_init() a vrací ukazatel na strukturu voip_private_t, jež obsahuje zejména proměnnou data_offset předanou stejnojmenným parametrem. Funkce init_queue() Po globální inicializaci pluginu dochází k volání funkce plugin_process_init_queue uvedené na výpisu 4.6 pro každou frontu na zpracování paketů, která se vytvoří. Funkce přijímá dva parametry: prvním z nich je base_plugin_private, který obsahuje ukazatel na privátní data pluginu, jenž vrátila funkce init(), a druhým je queue_id v němž je 49

56 4. Programové vybavení síťové sondy napsáno číslo fronty, která se právě inicializuje. Funkce vrací ukazatel na privátní data fronty (mohou být shodná s privátními daty pluginu). void * plugin_ process_ init_ queue ( void * base_ plugin_ private, int queue_ id ); Výpis kódu 4.6: Inicializační funkce pro frontu na zpracování paketů. Funkce init_queue() je vhodným místem pro alokaci zdrojů, které nelze sdílet mezi frontami (protože by se musely zamykat). V našem případě plugin dělá kopii globální konfigurace a poté volá funkci rtptable_create, kterou vytváří instanci tabulky pro zpracování RTP toků (bude probrána později). Funkce filter() Nejvíce zatíženým místem pluginu je funkce filter(), která zpracovává všechny příchozí pakety. Je třeba mít na paměti, že díky paralelnímu zpracování paketů může běžet ve více vláknech najednou. Funkce filter() přijímá dva parametry: plugin_private je ukazatel na privátní data fronty, zatímco packet je ukazatelem na strukturu flow_packet_t. Úkolem funkce je rozhodnout, zda paket prošel filtrem, či nikoliv. Podle toho funkce vrací návratový kód FLOW_FILTER_PASS nebo FLOW_FILTER_DROP. Procesní plugin vytvořený v rámci této práce neprovádí žádnou filtraci paketů, a proto za všech okolností vrací první návratový kód. Funkci ale využívá k analýze paketů, detekci SIP, RTP a RTCP provozu a generování statistik. Podrobný popis těchto činností bude popsán později. int plugin_ process_ filter ( void * plugin_private, flow_ packet_ t * packet ); Výpis kódu 4.7: Funkce pro filtraci paketů. Na výpisu 4.8 je vidět struktura flow_packet_t (definice v souboru record.h v hlavičkových souborech Exportéru), která si zaslouží hlubší rozbor. Ukazatel record vede na strukturu flow_record_t (k nalezení rovněž v souboru record.h), která obsahuje základní informace o toku například čas začátku, trvání toku, zdrojovou a cílovou IP adresu, počet přenesených bajtů apod. Tento flow record odpovídá zatím právě jednomu paketu, později bude agregován s jiným flow recordy. Ukazatel packet vede na začátek surového paketu, který byl zachycen na síťovém rozhraní. Jeho délka je uložená v atributu packet_len, zatímco atribut data_offseet udává pozici začátku dat čtvrté síťové vrstvy v rámci paketu. To je velmi užitečné, protože například při analýze protokolu SIP 50

57 4. Programové vybavení síťové sondy není nutné znovu procházet hlavičky nižších síťových vrstev stačí pouze přičíst data_offset k ukazateli packet. typedef struct { flow_ record_ t * record ; unsigned char * packet ; uint16_ t packet_ len ; uint16_ t data_ offset ; } attribute (( packed )) flow_packet_t ; Výpis kódu 4.8: Struktura flow_packet_t. Důležité je si uvědomit, že Exportér kvůli maximalizaci výkonu standardně nepředává filtrační funkci celý obsah paketu, ale pouze flow record. Pokud potřebujeme ve filtrační funkci přistupovat k celému obsahu paketu, musí funkce desc() vrátit v atributu flags struktury plugin_desc_t hodnotu PLUGIN_NEED_FULL_PACKET_INPUT! Funkce update() Funkce update() provádí agregaci síťových toků a volá se ve chvíli, kdy se Exportér pokouší zařadit do flow cache dva stejné toky. Její předpis je vidět na výpisu 4.9. Jejím prvním parametrem je opět ukazatel na privátní data fronty na zpracování paktů. Ukazatel record vede na aktuální verzi flow recordu, která je uložena ve flow cache, zatímco ukazatel packet vede na nový paket, který se do flow cache už nedostane. Úkolem agregační funkce je aktualizovat flow record record daty z nově příchozího paketu. Nový paket je po skončení funkce uvolněn z paměti. void plugin_ process_ update ( void * plugin_private, flow_ record_ t * record, flow_ packet_ t * packet ); Výpis kódu 4.9: Hlavička agregační funkce Rozpoznávání protokolu SIP Detekce protokolu SIP probíhá ve filtrační funkci. Protokol SIP používá standardně port 5060/UDP, nicméně v závislosti na konfiguraci může fungovat i na jiných portech nebo i nad protokolem TCP. Proto se při detekci SIP komunikace nehledí na čísla portů a kontroluje se obsah každého paketu. Naštěstí všechny SIP požadavky začínají názvem některé z deseti SIP metod a všechny odpovědi (hlášení stavu požadavku) začínají řetězcem SIP/

58 4. Programové vybavení síťové sondy Protože SIP pakety tvoří na běžné síti jen naprostou menšinu provozu, je zapotřebí, aby zejména zamítnutí testovaného paketu probíhalo co možná nejrychleji. Pokud chceme co nejefektivněji vyhodnotit, zda paket začíná některou z metod protokolu SIP, můžeme přetypovat začátek tohoto paketu na číslo a porovnat ho s číselnou konstantou, kterou získáme převodem názvu metody na ASCII kódy znaků, z nichž se skládá. Z hlediska počtu znaků jsou nejkratší metody BYE a ACK, které jsou dlouhé 3 znaky a čtvrtým znakem je mezera, která je za názvem metody povinná. Proto je vhodné přetypovat začátek paketu na typ uint32_t. Porovnání dvou čísel je velmi rychlé, procesor ho provádí v jednom nebo dvou taktech. Na detekci SIP paketu by v tomto případě bylo třeba 12 porovnání. Dále si můžeme všimnout, že některé SIP metody mají na určitých pozicích stejné znaky: Například metody REGISTER a INVITE mají obě jako čtvrtý znak písmeno I. Totéž platí i pro metody NOTIFY a OPTIONS. Pokud zjistíme, že začátek paketu nemá na čtvrté pozici písmeno I, nemá smysl testovat jej na metodu REGISTER, INVITE, NOTIFY ani OPTIONS. Podobné úvahy lze udělat i pro další metody protokolu SIP například metody PUBLISH a SUBSCRIBE mají společné písmeno B na třetí pozici. Pokud bychom pokračovali tímto způsobem dále (vše je popsáno na začátku souboru parser.c mezi definicemi konstant), podaří se nám sloučit všech 10 metod i hlášení o stavu do pouhých dvou konstant uvedených na výpisu Je jasné, že pokud se začátek paketu ani na jednom místě neshoduje s předloženou konstantou, nejedná se o SIP paket. # define SIP_ TEST_ 1 0 x /* ITAI */ # define SIP_ TEST_ 2 0 x /* BIS */ Výpis kódu 4.10: Vzorky pro detekci SIP paketů. Pokud se konstanta na některém bajtu shoduje s paketem, je třeba přistoupit k příslušné podmnožině z celkových 12 porovnání, které buď SIP paket potvrdí a nebo vyvrátí. Aby bylo toto řešení skutečně efektivnější než první navrhované, je třeba zajistit, aby se prováděl test shody s testovacím vzorkem co nejrychleji tedy ne po jednotlivých bajtech. K tomuto účelu lze použít podobný trik, jako používá knihovní funkce strlen() pro hledání konce řetězce. Postup je následující: 1. Do proměnné check uložíme exkluzivní součet začátku paketu a testovacího vzorku. Pokud se některý bajt paketu shoduje se vzorkem, bude ve výsledku tento bajt nulový. 52

59 4. Programové vybavení síťové sondy 2. K proměnné check přičteme testovací binární číslo , které má následující význam: přičteme-li k jeho libovolnému bajtu číslo větší než nula, dojde k přetečení a nejbližší vyšší nulový bit se změní na hodnotu K výsledku přičteme exkluzivním součtem negovanou proměnnou check, čímž nastavíme na hodnotu 1 bity, které zůstaly po přičtení testovacího binárního čísla nezměněné. Tím zkontrolujeme, zda v testovacím binárním číslu došlo na jednotlivých bajtech k přetečení. 4. Pokud je logický součin výsledku a negace testovacího binárního čísla větší než nula, začátek paketu se alespoň na jednom místě shoduje s testovaným vzorkem. Počet instrukcí provedených při hledání shody sice není dramaticky nižší než při běžném porovnání po bajtech, nicméně výše uvedený postup obsahuje pouze jediný skok a právě instrukce skoků jsou při svém provádění nejnáročnější = vzorek XOR = paket d 00 ce = check + 7e fe fe ff = testovaci binarni cislo Ob ff cd XOR ee f2 ff 31 = ~ check e f9 00 fc & = ~ testovaci binarni cislo > 0 Výpis kódu 4.11: Ukázka hledání shodného bajtu ve dvou binárních číslech. Výše uvedený postup se používá nejen pro identifikaci SIP paketů, ale také pro vyhledávání začátků řádků v SIP zprávách. Tam je jeho efektivita ještě o něco vyšší, neboť při práci na 64bitovém procesoru dokáže analyzovat až 8 znaků najednou Zpracování protokolu SIP Pokud je paket vyhodnocen jako SIP, je pro něj vytvořena struktura sip_data_t a provádí se jeho detailní analýza. Podle použité SIP metody 53

60 4. Programové vybavení síťové sondy dojde k rozhodnutí, zda se jedná o servisní požadavek nebo o telefonní hovor (požadavky INVITE, ACK, BYE a CANCEL). Pokud se jedná o stavovou zprávu (nikoliv o požadavek), rozhodnutí padne na základě obsahu pole CSeq, v němž je uvedeno jméno metody, na kterou stavová zpráva odpovídá. V závislosti na použité metodě se také nastaví příslušné počítadlo v poli SIP_STATS (které je interně implementováno jako struktura o délce přesně 64 bitů) na hodnotu 1. Dále se vyhledají pole From, To, Via a Call-ID a jejich hodnoty se zkopírují do vytvořené struktury. Pokud je nalezeno pole Content-Type a má hodnotu SDP, nastaví se příznak, který po skončení hlavičky zajistí zpracování těla SIP zprávy. Tělo SIP zprávy je od hlavičky odděleno prázdným řádkem. Čtení protokolu SDP je méně komplikované než čtení protokolu SIP, protože jednotlivá pole mají vždy jednoznakové názvy a jsou oddělena rovnítkem, před kterým nesmí být bílé znaky. Zásuvný modul hledá pouze pole c=, které obsahuje IP adresu, a dále pole m=, jež obsahují porty pro zvukový nebo obrazový přenos. Protokol SDP umožňuje předat neomezené množství portů nebo i jejich rozsahy. V praxi se však tato možnost nevyužívá a její podpora by komplikovala analýzu protokolu i přenos dat. Proto plugin podporuje pouze jeden port pro zvuk a jeden port pro video. Ostatní porty ignoruje. Pokud vše proběhne správně, uloží se do privátních dat pluginu umístěných ve flow recordu (struktura voip_data_t) odkaz na strukturu sip_data_t, čímž se z běžného toku stává SIP tok. Dále je nutné zaregistrovat callback funkci flow_destroyed_sip_callback, která se po odstranění flow recordu z flow cache postará o uvolnění struktury sip_data_t. Posledním velmi důležitým krokem je úprava CRC flow recordu. Exportér používá CRC jako jednoznačný identifikátor toku, pokud mají dva toky stejné CRC, pokusí se je agregovat. Protože struktura sip_data_t má k dispozici pole pro popis maximálně jednoho telefonního hovoru, je třeba zajistit, aby se každý telefonní hovor ukládal jako zvláštní tok. Toho se docílí tak, že se do existujícího CRC připočítá navíc prvních 8 znaků z pole Call-ID Detekce a zpracování protokolů RTP a RTCP Na rozdíl od protokolu SIP nelze pakety protokolů RTP a RTCP snadno detekovat. Protože se jich posílá velké množství, snaží se maximálně uspořit šířku pásma, a proto nepoužívají žádné složité hlavičky. V obou protokolech jsou konstantní pouze první dva bity mají hodnotou 10 a odpovídají verzi RTP. Bohužel na takto krátkém vzorku nelze postavit identifikaci protokolu. Proto je třeba provádět tzv. connection tracking, tj. sledovat data 54

61 4. Programové vybavení síťové sondy chodící v protokolu SIP a z nich usuzovat, na jakých adresách portech se dají očekávat RTP a RTCP pakety. Celou situaci navíc komplikuje fakt, že vše musí probíhat co nejrychleji. Za tímto účelem vznikla entita rtptable uložená ve stejnojmenném souboru. Jedná se o hashovací tabulku, která pro výpočet hashe používá číslo portu. Na každé pozici má uložen spojovaný seznam struktur rtptable_item_t (viz výpis 4.12), který obsahuje IP adresu a port, na nichž lze očekávat RTP pakety, a dále počet odkazů count a ukazatele na struktury rtp_data_t a rtcp_data_t. typedef struct rtptable_ item_ struct { /* Either IPv4 or IPv6 destination address : */ rtp_node_t rtp_node ; /* Destination port : */ uint16_ t port ; /* Number of links pointing to this record ( number of * inserts + number of running RTP streams ): */ uint16_ t count ; /* Pointer to RTP data record : */ rtp_data_t * rtp_data ; /* Pointer to RTCP data record : */ rtcp_data_t * rtcp_data ; /* Next item ( linear list ): */ struct rtptable_ item_ struct * next ; } rtptable_ item_ t ; Výpis kódu 4.12: Struktura rtptable_item_t. Tabulka rtptable se plní během zpracování protokolu SIP. Pokud se objeví SIP paket, který obsahuje IP adresu a porty pro RTP data, vloží se do tabulky. Pokud záznam v tabulce již existuje, dojde jen ke zvýšení hodnoty počítadla odkazů. Ve chvíli, kdy se SIP tok odstraňuje z flow cache, dochází i k vymazání záznamu v rtptable. Pokud je hodnota počítadla odkazů vymazávaného toku větší než 1, dojde pouze ke snížení hodnoty počítadla. Tento mechanismus zajišťuje, že se nebudou v tabulce hromadit staré porty, ale zároveň se žádný port nesmaže, dokud na něj vede alespoň jeden odkaz. Při detekci RTP nebo RTCP paketu dochází nejprve ke kontrole prvních dvou bitů, zda mají hodnotu 10. Pokud ne, paket se ihned zamítá. V opačném případě se zkontroluje, zda paket míří na sudý nebo lichý port. Pokud je číslo portu liché, nastaví se příznak RTCP paketu a číslo se o jedničku sníží. V rtptable se totiž ukládají pouze čísla portů protokolu RTP. Protokol RTCP používá port vždy o jedničku vyšší, proto není důvod tuto informaci explicitně ukládat. Následně se provede hledání v hashovací tabulce. Pokud 55

62 4. Programové vybavení síťové sondy se nepodaří najít žádný záznam se shodnou IP adresou a portem, paket se zamítá. V opačném případě se předává ukazatel na nalezenou položku v rtptable a vrací se typ paketu (pokud není nastaven příznak RTCP, jedná se o RTP paket a naopak). Jak již bylo řečeno, struktura rtptable_item_t obsahuje mimo jiné i odkazy na struktury rtp_data_t a rtcp_data_t. Pokud je paket identifikován jako protokol RTP nebo RTCP a ukazatel na odpovídající strukturu je prázdný, znamená to, že se jedná o první paket toku. V tom případě se vytvoří nová struktura rtp_data_t resp. rtcp_data_t a uloží se do tohoto ukazatele. Zároveň se ukazatel na ni uloží také do privátních dat pluginu ve flow recordu. Tím se z paketu stává RTP nebo RTCP paket. Dále dochází ke zvýšení hodnoty počítadla odkazů ve struktuře rtptable_item_t. To je nutné proto, aby záznam v rtptable zůstal i v případě, že se z flow cache již odstranily všechny SIP toky, které na něj odkazují. Aby záznam nezůstal v rtptable věčně, je třeba registrovat callback funkci flow_destroyed_rtp_callback, která jej odstraní (nebo sníží počet odkazů) ve chvíli, kdy flow cache opouští RTP tok, do něhož patří právě analyzovaný paket. Samotný rozbor RTP a RTCP paketů je již poměrně jednoduchý a provádí se v souboru rtp.c. Při analýze protokolů stačí jen přetypovat paket na příslušnou datovou strukturu a poté přečíst potřebná data. Pokud se jedná o složený RTCP paket (obsahuje víc zpráv za sebou), poznáme to podle toho, že délka dat paketu je větší než délka přiložené struktury. V tom případě stačí celý postup opakovat tak dlouho, dokud zbývají k přečtení nějaká data Agregace paketů Dosud byla řeč jen o zpracování jednotlivých paketů, nicméně tok se skládá málokdy jen z jednoho paketu, a proto je potřeba pakety v toku agregovat tak, aby se uložilo co nejvíc informací. O agregaci paketů se stará funkce update(), která řeší odděleně spojování SIP, RTP a RTCP paketů. Pokud se stane, že ve flow cache ještě nejsou uloženy žádné informace o SIP toku, zkopírují se všechny informace z nově příchozího paketu. Agregace nastává ve chvíli, kdy má u sebe nějaké informace jak tok ve flow cache, tak nově příchozí paket. V tom případě se provede sečtení SIP statistik a případně i aktualizace polí SIP_INVITE_RINGING_TIME, SIP_OK_TIME a SIP_BYE_TIME pokud stále ještě hodnotu nula. Pokud nově příchozí paket obsahuje informaci o RTP portech, prohazuje se tento údaj s informací, která je uložena ve flow cache. Důvodem je fakt, že každý SIP flow record má na sobě navázánu callback funkci, která uvolňuje 56

63 4. Programové vybavení síťové sondy nejen strukturu sip_data_t, ale i data z rtptable z paměti. Pokud by se údaj o RTP portech pouze zkopíroval z nově příchozího paketu, ihned po skončení agregace by došlo k uvolnění tohoto paketu z paměti a s ním by se zrušil i příslušný záznam v rtptable. Prohozením záznamů se dosáhne nejen zachování nového záznamu v rtptable, ale také odstranění starého záznamu, který byl až dosud uložen ve flow cache. Agregace RTP a RTCP provozu se provádí už ve filtrační funkci, zatímco ve funkci update se pouze předávají odkazy na data v případě, že první paket toku nebyl rozpoznán jako RTP resp. RTCP. Důvodem je fakt, že zejména RTP paketů chodí na síti velké množství, a proto by nebylo efektivní pro každý z nich alokovat novou strukturu rtp_data_t a ihned po agregaci paketů ji opět uvolňovat. Struktura rtp_data_t se proto vytváří jen pro první paket toku a odkaz na ni se ukládá do rtptable. Pokud dojde při analýze paketu k nalezení jeho IP adresy a portu v rtptable, získáme automaticky také ukazatele na struktury rtp_data_t a rtcp_data_t. Agregace dat ve filtrační funkci se proto přímo nabízí. Samotný proces agregace RTP a RTCP dat je poměrně jednoduchý. U protokolu RTCP obnáší sčítání sumárních statistik (počty přenesených paketů a oktetů), počítání průměru u hodnoty rozptylu a výběr maximální hodnoty u počtu zdrojů. U protokolu RTP je třeba průběžně počítat rozptyl paketů podle vztahu 2.1. Aby mohl proběhnout výpočet rozptylu korektně, je třeba znát frekvenci RTP hodin, která se vypočítá podle typu kodeku. Rozšíření process-voip sice neumí pracovat s dynamicky definovanými kodeky, ale podporuje 35 standardních kodeků [5]. U hovorů používajících dynamicky definovaný kodek se výpočet rozptylu neprovádí. 57

64 Kapitola 5 Programové vybavení kolektoru Součástí této diplomové práce není jen sběr dat o VoIP komunikaci, ale také jejich zpracování a vizualizace. Tyto úkony probíhají na kolektorové části navrženého systému. Pro vizualizaci nasbíraných dat byl vytvořen rozšiřující modul VoIP Explorer, který lze nainstalovat jak na sondu s vestavěným kolektorem, tak i na dedikovaný kolektor společnosti INVEA-TECH. 5.1 Instalace programu ipfixcol Zařízení společnosti INVEA-TECH standardně používají pro příjem a ukládání NetFlow dat program nfcapd, jehož podpora vlastních polí v protokolu IPFIX je bohužel poměrně omezená. Proto byl pro účely diplomové práce použit volně šiřitelný kolektor ipfixcol, který tímto nedostatkem netrpí. Pro ukládání dat bylo zvoleno úložiště FastBit, které ipfixcol nativně podporuje. Program ipfixcol lze zdarma stáhnout ze stránek sdružení Liberouter 1, nicméně jeho instalace na zařízení FlowMon postavených na systému CentOS 5 je poměrně komplikovaná. Proto doporučuji použít již hotové balíčky, které je možné najít na přiloženém CD v adresáři bin/ipfixcol-centos5. V tomtéž adresáři se nachází i návod na jejich snadnou instalaci. Kolektor nepotřebuje žádnou složitou konfiguraci, pouze je nutné povolit na firewallu port 4739/UDP a v souboru /etc/ipfixcol/elements.xml definovat pole exportovaná pluginem process-voip, aby je kolektor dokázal rozpoznat a uložit. Syntaxe je popsána přímo v konfiguračním souboru, identifikátory polí jsou uvedeny v tabulce 4.1. Podobnou úpravu je zapotřebí udělat také v souboru /usr/share/fbitdump/fbitdump.xml. Ukázky upravených konfiguračních souborů je možné najít rovněž na přiloženém CD v adresáři conf. Pokud se vše podaří správně nastavit, bude možné zobrazit toky rozšířené o VoIP položky pomocí příkazu na výpisu 5.1. Více informací o

65 5. Programové vybavení kolektoru práci s programem fbitdump je možné najít na jeho manuálové stránce. Seznam podporovaných formátovacích řetězců je definován v souboru /usr/shar/fbitdump/fbitdump.xml. fbitdump -R / data / ipfixcol -o sip "% voiptype > 0" Výpis kódu 5.1: Zobrazení VoIP dat pomocí programu fbitdump. 5.2 Integrace vlastního rozšíření do FlowMon GUI Zařízení společnosti INVEA-TECH používají pro svou správu webové rozhraní, které se skládá ze dvou základních částí. První z nich tvoří tzv. frontend, což je webová aplikace napsaná v jazyce Javascript. Jejím hlavním úkolem je poskytnout uživatelsky přívětivé prostředí pro konfiguraci zařízení a vizualizaci dat. Frontend používá populární javascriptové knihovny jquery 2, Underscore 3 a dále sadu knihoven napsanou přímo pro vývoj webového rozhraní FlowMon. Druhou částí je tzv. backend implementovaný jako webová aplikace v jazyce PHP založená českém MVC frameworku Nette 4. Backend přijímá požadavky od frontendu a dále je zpracovává (například aplikuje změny nastavení, které uživatel zadal ve frontendu apod.). Obě části spolu komunikují prostřednictvím HTTP požadavků, ve kterých přenáší data ve formátu JSON 5. Zdrojové kódy webového rozhraní se nachází v adresáři /var/www a jsou rozděleny do přehledné struktury odpovídající zvyklostem Nette. Kořenový adresář WWW serveru tvoří pouze podsložka /var/www/shtml, díky čemuž jsou ostatní adresáře skrz webové rozhraní nedostupné. Toto opatření zvyšuje bezpečnost systému. Ukázku struktury adresáře /var/www je možné vidět obrázku 5.1. Backendová část uživatelského rozhraní je uložena ve složce /var/www/app, která je dále rozdělena na jednotlivé funkční celky (moduly). Například adresář /var/www/app/fccmodule odpovídá FlowMon konfiguračnímu centru apod. Každý modul se dělí na modely, presentery a šablony, které odpovídají standardním součástem MVC frameworku. Modely se starají o tvorbu a zpracování dat, zatímco šablony o jejich správné zobrazení. Presentery tvoří mezivrstvu spojující modely a šablony. 2. Knihovna jquery dostupná na adrese 3. Knihovna Underscore dostupná na adrese 4. Framework Nette je dostupný na adrese 5. JSON (JavaScript Object Notation) je populární formát výměny dat. Více informací na 59

66 5. Programové vybavení kolektoru Frontendovou část uživatelského rozhraní lze najít v již zmíněném adresáři /var/www/shtml. Kromě obrázků a kaskádových stylů ve složkách /var/www/shtml/img a /var/www/shtml/css ji tvoří zejména javascriptové části jednotlivých modulů v adresáři /var/www/shtml/js/app. /var/ adresář uživatelského rozhraní app... Zdrojové kódy backendové části aplikace. FccModule...Dílčí moduly backendové aplikace. models presenters templates FmcModule HomepageModule locale...soubory s překlady webového rozhraní. log...adresář pro ukládání chyb. shtml...kořenový adresář WWW serveru. css...kaskádové styly webových aplikací img... Obrázky webových aplikací fcc fmc homepage js...javascriptová část GUI. app... Skripty pro konkrétní webové aplikace. fcc fmc fwk...základní stavební prvky aplikací. lib...knihovny. utils... Doplňující skripty pro různé účely. index.php...soubor index.php vstupní bod aplikace. temp... Adresář pro dočasné soubory a cache. Obrázek 5.1: Adresářová struktura webového rozhraní FlowMon. Při psaní vlastního rozšiřujícího modulu nejprve vytvoříme jeho backendovou část, kterou umístíme do adresáře /var/www/app/*module (hvězdičku nahradíme jménem modulu). Nette framework provádí automaticky tzv. routování požadavků, což je proces, při kterém se vybírá obslužný kód pro daný požadavek. Pokud se modul jmenuje například VoipModule, pak bude přístupný na URL /voip a všechny požadavky začínající touto cestou bude obsluhovat právě tento modul. Podobným způsobem funguje routování i mezi 60

67 5. Programové vybavení kolektoru jednotlivými presentery. Tento proces je standardní součástí Nette a nebudu se mu dále věnovat, protože je popsán v oficiální dokumentaci na stránkách frameworku [9]. Vazbu mezi frontendovou a backendovou částí pluginu tvoří šablony v adresáři /var/www/app/*module/templates, které generují pro daný modul, presenter a akci výslednou HTML stránku. Protože frontendová část rozhraní je založena převážně na Javascriptu, většina těchto šablon se používá hlavně pro definici HTML kontejnerů, do nichž se pak umísťují javascriptové komponenty a formuláře z adresáře /var/www/shtml/js/app. Tvorba rozšiřujícího modulu je poměrně komplexní záležitost, která nespadá do kompetencí této diplomové práce, a proto se jí nebudu dále věnovat. Podrobná příručka o psaní rozšiřujících modulů pro zařízení Flow- Mon je dostupná členům Community programu společnosti INVEA-TECH, do kterého je možné se bezplatně registrovat na stránkách společnosti VoIP Explorer VoIP Explorer je rozšiřující modul pro grafické rozhraní zařízení FlowMon, který umožňuje vizualizovat data získaná pluginem process-voip popsaným v kapitole 4.2. Zatím se jedná spíše akademickou prací demonstrující funkčnost navrženého řešení, nicméně splňuje všechny náležitosti rozšiřujících modulů společnosti INVEA-TECH, a proto je možné z něho v budoucnu vytvořit samostatný volně dostupný balíček pro zařízení FlowMon. Obrázek 5.2: VoIP Explorer na rozcestníku FlowMon. Zdrojové kódy pluginu se nachází na přiloženém CD v adresáři src/gui. Instalace VoIP Exploreru je velmi snadná, protože stačí jen zkopírovat obsah 61

68 5. Programové vybavení kolektoru zmíněného adresáře do složky /var/www a do databáze PostgreSQL na cílovém zařízení přidat odkaz na plugin. Podrobný postup instalace je uveden v souboru src/gui/install. Po dokončení instalace se rozšíření objeví na úvodní obrazovce uživatelského rozhraní FlowMon (obrázek 5.2). Rozšiřující modul má mimo jiné následující funkce: Výpis zachycených toků s grafickým znázorněním těch, které se týkají VoIP provozu. Nalezení souvisejících toků, které se týkají jednoho hovoru. Zobrazení podrobností o telefonním hovoru SIP URI volajících stran, délka hovoru, kvalita (počet ztracených paketů a jejich rozptyl). Zobrazení seznamu posledních hovorů. VoIP Explorer nabízí dvě základní zobrazení dat: Prvním z nich je Výpis toků, který ukazuje seznam toků podobně jako FlowMon Monitorovací Centrum, ale navíc u každého z nich zobrazuje rozšířené informace získané pluginem process-voip. Druhé zobrazení se nazývá Poslední hovory a dává k dispozici prostý výpis telefonních hovorů seřazený od nejnovějších telefonátů až po ty nejstarší. V obou režimech výpisu je možné kliknutím na příslušný řádek tabulky zobrazit podrobné informace o hovoru Výpis toků Po kliknutí na záložku Výpis toků se zobrazí filtrační formulář, v němž je možné zadat časové rozmezí a maximální počet toků, které chce uživatel zobrazit. Důležitým polem je FastBitDump filtr, kam se zadávají filtrační kritéria za použití syntaxe programu fbitdump 6. Ve filtru lze samozřejmě používat pole exportovaná pluginem process-voip, jejichž aliasy se definují v souboru /usr/share/fbitdump/fbitdump.xml. Výchozí filtr (%voiptype > 2) zobrazuje pouze toky protokolu SIP týkající se telefonních hovorů a dále toky protokoů RTP a RTCP. Po kliknutí na tlačítko Zobrazit data se zobrazí požadovaný výpis obsahující mimo základních informací také SIP URI volajícího a volaného, port použitý pro přenos RTP dat a u protokolu RTP použitý kodek. Toky týkající se VoIP komunikace jsou navíc barevně odlišeny. Více informací lze zobrazit kliknutím na odkaz ve sloupci VOIP packet type. Ukázka výpisu toků je vidět na obrázku Syntaxi programu fbitdump lze najít na jeho manuálové stránce (man fbitdump). 62

69 5. Programové vybavení kolektoru Obrázek 5.3: VoIP Explorer výpis toků Poslední hovory Ke každému telefonnímu hovoru se váže vždy několik toků. Pokud chceme analyzovat jeden problémový hovor, může být pro tento účel zobrazení na úrovni toků nepohodlné. Zobrazení Posledních hovorů se snaží inteligentně filtrovat toky tak, aby se každý každý hovor zobrazil maximálně jednou. Možnosti filtrace jsou omezené pouze na čas a délku výpisu. Seznam se navíc řadí sestupně, takže se poslední hovory objevují hned na jeho začátku. Po kliknutí na telefonní hovor se zobrazí jeho podrobnosti včetně všech toků, které se hovoru týkají. Ukázku zobrazení posledních hovorů je možné vidět na obrázku 5.4. Obrázek 5.4: VoIP Explorer poslední hovory. 63

RTP = real=time protocol ST-II = Internet Stream Protocol (náhrada TCP pro streamy, řídicí protokol, datový přenos)

RTP = real=time protocol ST-II = Internet Stream Protocol (náhrada TCP pro streamy, řídicí protokol, datový přenos) RTP Real Time Protocol Cíle Mixery a translátory Řízení: uvědomění, QoS zpětná vazba Adaptace média RTP přehled RTP = real=time protocol ST-II = Internet Stream Protocol (náhrada TCP pro streamy, řídicí

Více

Michal Vávra FI MUNI

Michal Vávra FI MUNI Úvod do světa SIPových VoIP klientů Michal Vávra FI MUNI 08. 10. 2009 Obsah 1 Úvod 2 Signalizační protokol (SIP) 3 Další potřebné komponenty v síti 4 VoIP klienty Ekiga Linphone WengoPhone SIP Communicator

Více

SIP Session Initiation Protocol

SIP Session Initiation Protocol SIP Session Initiation Protocol Jiří Ledvina Projektování distribuovaných systémů Úvod Protokol aplikační úrovně Řídicí protokol (signalizační) pro Vytváření Modifikaci Ukončování spojení mezi dvěma účastníky

Více

Studium protokolu Session Decription Protocol. Jaroslav Vilč

Studium protokolu Session Decription Protocol. Jaroslav Vilč Studium protokolu Session Decription Protocol Jaroslav Vilč 5. února 2007 Session Description Protocol (SDP) SDP je určen pro popis multimediálních relací. Jedná se o dobře definovaný formát postačující

Více

6. Transportní vrstva

6. Transportní vrstva 6. Transportní vrstva Studijní cíl Představíme si funkci transportní vrstvy. Podrobněji popíšeme protokoly TCP a UDP. Doba nutná k nastudování 3 hodiny Transportní vrstva Transportní vrstva odpovídá v

Více

2N EasyRoute UMTS datová a hlasová brána

2N EasyRoute UMTS datová a hlasová brána 2N EasyRoute UMTS datová a hlasová brána Jak na to? Verze: SIP Calls www.2n.cz 1. SIP hovory V tomto dokumentu si ukážeme jak jednoduše ve 2N EasyRoute nastavit SIP účet. Zde je přehled toho, co v kapitole

Více

JAK ČÍST TUTO PREZENTACI

JAK ČÍST TUTO PREZENTACI PŘENOSOVÉ METODY V IP SÍTÍCH, S DŮRAZEM NA BEZPEČNOSTNÍ TECHNOLOGIE David Prachař, ABBAS a.s. JAK ČÍST TUTO PREZENTACI UŽIVATEL TECHNIK SPECIALISTA VÝZNAM POUŽÍVANÝCH TERMÍNŮ TERMÍN SWITCH ROUTER OSI

Více

Flow monitoring a NBA

Flow monitoring a NBA Flow monitoring a NBA Kdy, kde a jak? Petr Špringl, Zdeněk Vrbka, Michal Holub springl@invea.cz, vrbka@invea.cz, holub@invea.cz Obsah Monitorování datových toků = Flow monitoring Flow monitoring a bezpečnost

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Jak se měří síťové toky? A k čemu to je? Martin Žádník

Jak se měří síťové toky? A k čemu to je? Martin Žádník Jak se měří síťové toky? A k čemu to je? Martin Žádník Představení CESNET je poskytovatelem konektivity pro akademickou sféru v ČR Zakládající organizace jsou univerzity a akademi věd Obsah Motivace Popis

Více

Identifikátor materiálu: ICT-3-03

Identifikátor materiálu: ICT-3-03 Identifikátor materiálu: ICT-3-03 Předmět Téma sady Informační a komunikační technologie Téma materiálu TCP/IP Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí architekturu TCP/IP. Druh

Více

1 Pro účely této vyhlášky se rozumí a) základnovou stanicí základnová stanice veřejné komunikační sítě,

1 Pro účely této vyhlášky se rozumí a) základnovou stanicí základnová stanice veřejné komunikační sítě, Částka 133 Sbírka zákonů č. 357 / 2012 Strana 4733 357 VYHLÁŠKA ze dne 17. října 2012 o uchovávání, předávání a likvidaci provozních a lokalizačních údajů Ministerstvo průmyslu a obchodu v dohodě s Ministerstvem

Více

4. Síťová vrstva. Síťová vrstva. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si funkci síťové vrstvy a jednotlivé protokoly.

4. Síťová vrstva. Síťová vrstva. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si funkci síťové vrstvy a jednotlivé protokoly. 4. Síťová vrstva Studijní cíl Představíme si funkci síťové vrstvy a jednotlivé protokoly. Doba nutná k nastudování 3 hodiny Síťová vrstva Síťová vrstva zajišťuje směrování a poskytuje jediné síťové rozhraní

Více

NetFlow a NBA? FlowMon 7 umí mnohem více! (NPM, APM, VoIPM, packet capture) Petr Špringl springl@invea.com

NetFlow a NBA? FlowMon 7 umí mnohem více! (NPM, APM, VoIPM, packet capture) Petr Špringl springl@invea.com NetFlow a NBA? FlowMon 7 umí mnohem více! (NPM, APM, VoIPM, packet capture) Petr Špringl springl@invea.com Monitoring sítě Network visibility &security Perimeter security End point security Gartner doporučuje

Více

Hypertext Transfer Protocol (HTTP/1.1 RFC 2616) Počítačové sítě Pavel Šinták

Hypertext Transfer Protocol (HTTP/1.1 RFC 2616) Počítačové sítě Pavel Šinták Hypertext Transfer Protocol (HTTP/1.1 RFC 2616) Počítačové sítě Pavel Šinták 25.4.2005 Obsah Úvod Vrstvy podle TCP/IP Požadavek / Odpověď Metody požadavku Hlavičky Kódy odpovědi Ukázka 25.4.2005 Pavel

Více

2N VoiceBlue Next. 2N VoiceBlue Next & Siemens HiPath (series 3000) Propojení pomocí SIP trunku. Quick guide. Version 1.

2N VoiceBlue Next. 2N VoiceBlue Next & Siemens HiPath (series 3000) Propojení pomocí SIP trunku. Quick guide.  Version 1. 2N VoiceBlue Next 2N VoiceBlue Next & Siemens HiPath (series 3000) Propojení pomocí SIP trunku Quick guide Version 1.00 www.2n.cz 1 2N VoiceBlue Next má tyto parametry: IP adresa 192.168.1.120 Příchozí

Více

Nastavení telefonu Nokia N9

Nastavení telefonu Nokia N9 Nastavení telefonu Nokia N9 Telefon Nokia N9, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny. Některé položky v

Více

Zkrácení zápisu dvojitou dvojtečkou lze použít pouze jednou z důvodu nejednoznačnosti interpretace výsledného zápisu adresy.

Zkrácení zápisu dvojitou dvojtečkou lze použít pouze jednou z důvodu nejednoznačnosti interpretace výsledného zápisu adresy. Vlastnosti IPv6 (I) Minulé díly seriálu IPv6 vysvětlily proč se IPv4 blíží ke svému konci aže jeho nástupcem je nový Internetový Protokol verze 6 (IPv6). Tématem dnešního dílu jsou vlastnosti IPv6 protokolu.

Více

Analýza aplikačních protokolů

Analýza aplikačních protokolů ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická PROJEKT Č. 4 Analýza aplikačních protokolů Vypracoval: V rámci předmětu: Jan HLÍDEK Komunikace v datových sítích (X32KDS) Měřeno: 28. 4. 2008

Více

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly.

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly. 7. Aplikační vrstva Studijní cíl Představíme si funkci aplikační vrstvy a jednotlivé protokoly. Doba nutná k nastudování 2 hodiny Aplikační vrstva Účelem aplikační vrstvy je poskytnout aplikačním procesům

Více

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP.

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP. Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Jádro TCP/IP TCP/IP Jádro Pseudo terminal driver Uživatel u terminálu TCP spojení

Více

Při konfiguraci domácího směrovače a bezdrátové sítě se setkáte s obrovským počtem zkratek, jejichž význam je jen málokdy dostatečně vysvětlen.

Při konfiguraci domácího směrovače a bezdrátové sítě se setkáte s obrovským počtem zkratek, jejichž význam je jen málokdy dostatečně vysvětlen. 1 Při konfiguraci domácího směrovače a bezdrátové sítě se setkáte s obrovským počtem zkratek, jejichž význam je jen málokdy dostatečně vysvětlen. Bez jejich znalosti však jen stěží nastavíte směrovač tak,

Více

Datum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží

Datum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží Číslo projektu CZ.1.07/1.5.00/34.0394 Škola SOŠ a SOU Hustopeče, Masarykovo nám. 1 Autor Ing. Miriam Sedláčková Číslo VY_32_INOVACE_ICT.3.01 Název Teorie internetu- úvod Téma hodiny Teorie internetu Předmět

Více

Analýza komunikace při realizaci VoIP spojení

Analýza komunikace při realizaci VoIP spojení Analýza komunikace při realizaci VoIP spojení Tomáš Mácha Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Ústav telekomunikací, Purkyňova 118, 612 00 Brno, Česká republika

Více

EU-OPVK:VY_32_INOVACE_FIL9 Vojtěch Filip, 2013

EU-OPVK:VY_32_INOVACE_FIL9 Vojtěch Filip, 2013 Číslo projektu CZ.1.07/1.5.00/34.0036 Tématický celek Inovace výuky ICT na BPA Název projektu Inovace a individualizace výuky Název materiálu Komunikační protokoly v počítačových sítích Číslo materiálu

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Semestrální práce 37MK

Semestrální práce 37MK 4. ročník 25. 5. 2006 ČVUT FEL Semestrální práce 37MK Session Initiation Protocol OBSAH 1.... 2 1.1. Historie a vývoj... 2 1.2. Charakteristika protokolu... 2 1.3. Prvky SIP architektury... 2 1.4. SIP

Více

Inovace výuky prostřednictvím šablon pro SŠ

Inovace výuky prostřednictvím šablon pro SŠ Název projektu Číslo projektu Název školy Autor Název šablony Název DUMu Stupeň a typ vzdělávání Vzdělávací oblast Vzdělávací obor Tematický okruh Cílová skupina Anotace Inovace výuky prostřednictvím šablon

Více

pozice výpočet hodnota součet je 255

pozice výpočet hodnota součet je 255 IP adresa - IP address IP adresa je logická adresa zařízení v síti IP. Skládá se ze 4 částí zvaných octety, každá část je veliká 8 bitů, a zapisuje se oddělená tečkou. Adresa se většinou zapisuje v dekadické

Více

Počítačové sítě II. 14. Transportní vrstva: TCP a UDP. Miroslav Spousta, 2005

Počítačové sítě II. 14. Transportní vrstva: TCP a UDP. Miroslav Spousta, 2005 Počítačové sítě II 14. Transportní vrstva: TCP a UDP Miroslav Spousta, 2005 1 Transportní vrstva přítomná v ISO/OSI i TCP/IP zodpovědná za rozšíření vlastností, které požadují vyšší vrstvy (aplikační)

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] implementace přenosu informace o doručení SMS verze 166 / 1.3.2012 1 Obsah 1 Implementace platebního systému 3 1.1 Nároky platebního systému na klienta 3 1.2 Komunikace

Více

TFTP Trivial File Transfer Protocol

TFTP Trivial File Transfer Protocol TFTP Trivial File Transfer Protocol Jan Krňoul KIV / PSI TFTP Jednoduchý protokol pro přenos souborů 1980 IEN 133 1981 RFC 783 1992 RFC 1350 1998 RFC 1785, 2090, 2347, 2348, 2349 Noel Chiappa, Bob Baldvin,

Více

Nastavení telefonu Nokia 3220

Nastavení telefonu Nokia 3220 Nastavení telefonu Nokia 3220 Telefon Nokia 3220, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny. Pokud je potřeba

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

Schéma elektronické pošty

Schéma elektronické pošty Aplikační protokoly Elektronická pošta Schéma elektronické pošty odesilatel user agent (UA) SMTP mail transfer agent (MTA) SMTP mail transfer agent (MTA) SMTP příjemce user agent (UA) IMAP nebo POP mailbox

Více

Počítačové sítě. Lekce 4: Síťová architektura TCP/IP

Počítačové sítě. Lekce 4: Síťová architektura TCP/IP Počítačové sítě Lekce 4: Síťová architektura TCP/IP Co je TCP/IP? V úzkém slova smyslu je to sada protokolů používaných v počítačích sítích s počítači na bázi Unixu: TCP = Transmission Control Protocol

Více

Vlastnosti podporované transportním protokolem TCP:

Vlastnosti podporované transportním protokolem TCP: Transportní vrstva Transportní vrstva odpovídá v podstatě transportní vrstvě OSI, protože poskytuje mechanismus pro koncový přenos dat mezi dvěma stanicemi. Původně se proto tato vrstva označovala jako

Více

Model ISO - OSI. 5 až 7 - uživatelská část, 1 až 3 - síťová část

Model ISO - OSI. 5 až 7 - uživatelská část, 1 až 3 - síťová část Zatímco první čtyři vrstvy jsou poměrně exaktně definovány, zbylé tři vrstvy nemusí být striktně použity tak, jak jsou definovány podle tohoto modelu. (Příkladem, kdy nejsou v modelu použity všechny vrstvy,

Více

ATEUS - OMEGA Komunikační řešení pro malé a střední firmy

ATEUS - OMEGA Komunikační řešení pro malé a střední firmy ATEUS - OMEGA Komunikační řešení pro malé a střední firmy 2 varianty: - ATEUS - OMEGA Business - ATEUS - OMEGA Basic Propojení všech telekomunikačních služeb firmy Přímé propojení do sítí ISDN, GSM a VoIP

Více

Počítačové sítě pro V3.x Teoretická průprava II. Ing. František Kovařík

Počítačové sítě pro V3.x Teoretická průprava II. Ing. František Kovařík Počítačové sítě pro V3.x Teoretická průprava II. Ing. František Kovařík SŠ IT a SP, Brno frantisek.kovarik@sspbrno.cz Model TCP/IP - IP vrstva 2 Obsah 3. bloku IPv4 záhlaví, IP adresy ARP/RARP, ICMP, IGMP,

Více

Počítačové sítě Systém pro přenos souborů protokol FTP

Počítačové sítě Systém pro přenos souborů protokol FTP Počítačové sítě Systém pro přenos souborů protokol FTP Autorizovaný přístup do souborového systému hostitelského uzlu Informace o obsahu souborového systému hostitelského uzlu Obousměrný přenos kopií souborů

Více

Možnosti IPv6 NAT. Lukáš Krupčík, Martin Hruška KRU0052, HRU0079. Konfigurace... 3 Statické NAT-PT Ověření zapojení... 7

Možnosti IPv6 NAT. Lukáš Krupčík, Martin Hruška KRU0052, HRU0079. Konfigurace... 3 Statické NAT-PT Ověření zapojení... 7 Možnosti IPv6 NAT Lukáš Krupčík, Martin Hruška KRU0052, HRU0079 Abstrakt: Tento dokument ukazuje možné řešení problematiky IPv6 NAT. Součástí je návrh topologií zapojení a praktické otestovaní. Kontrola

Více

VoIP telefon Gigaset A580IP

VoIP telefon Gigaset A580IP VoIP telefon Gigaset A580IP Návod na instalaci a nastavení V tomto návodu popisujeme nastavení telefonu Gigaset A580IP. Instalace voip telefonu : Po vybalení z krabice telefon složíme podle přiloženého

Více

SSL Secure Sockets Layer

SSL Secure Sockets Layer SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou

Více

mbank.cz mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera

mbank.cz mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera 1/6 Obsah 1 SLOVNÍK POJMŮ... 3 2 ÚVOD... 4 3 POPIS ŘEŠENÍ NPM... 4 4 ZPŮSOB KOMUNIKACE EXTERNÍHO PARTNERA S MBANK - SPECIFIKACE

Více

PROTOKOL RDS. Dotaz na stav stanice " STAV CNC Informace o stavu CNC a radiové stanice FORMÁT JEDNOTLIVÝCH ZPRÁV

PROTOKOL RDS. Dotaz na stav stanice  STAV CNC Informace o stavu CNC a radiové stanice FORMÁT JEDNOTLIVÝCH ZPRÁV PROTOKOL RDS Rádiový modem komunikuje s připojeným zařízením po sériové lince. Standardní protokol komunikace je jednoduchý. Data, která mají být sítí přenesena, je třeba opatřit hlavičkou a kontrolním

Více

Kapitola 1 Představení SIP telefonu

Kapitola 1 Představení SIP telefonu SIP telefon Kapitola 1 Představení SIP telefonu SIP telefon je plně funkční IP telefon vhodný pro využívání v domácnostech. Podporuje SIP protokol dle RFC3261. Obsahuje dva síťové porty 10/100BaseT, pomocí

Více

Střední škola pedagogická, hotelnictví a služeb, Litoměříce, příspěvková organizace

Střední škola pedagogická, hotelnictví a služeb, Litoměříce, příspěvková organizace Střední škola pedagogická, hotelnictví a služeb, Litoměříce, příspěvková organizace Předmět: Počítačové sítě Téma: Počítačové sítě Vyučující: Ing. Milan Káža Třída: EK1 Hodina: 21-22 Číslo: III/2 4. Síťové

Více

Detekce zranitelnosti Heartbleed pomocí rozšířených flow dat

Detekce zranitelnosti Heartbleed pomocí rozšířených flow dat Detekce zranitelnosti Heartbleed pomocí rozšířených flow dat Václav Bartoš bartos@cesnet.cz Seminář o bezpečnosti sítí a služeb, 11. 2. 2015 Monitorování sítě CESNET2 Monitorování na bázi IP toků (flow)

Více

Voice over IP Fundamentals

Voice over IP Fundamentals přednáška pro studenty katedry elektroniky a telekomunikační techniky VŠB-TUO: Voice over IP Fundamentals Miroslav Vozňák Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky

Více

Provisioning VoIP koncových zařízení

Provisioning VoIP koncových zařízení Ing. Pavel Bezpalec, Ph.D. Katedra telekomunikační techniky FEL, ČVUT v Praze Pavel.Bezpalec@fel.cvut.cz VoIP koncová zařízení IP telefon telefon pro VoIP IP GW IP brána adaptér pro připojení analog. telefonu

Více

Identifikátor materiálu: ICT-3-14

Identifikátor materiálu: ICT-3-14 Identifikátor materiálu: ICT-3-14 Předmět Téma sady Informační a komunikační technologie Téma materiálu Offline a online komunikace po sítích Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí

Více

Monitorování datových sítí: Dnes

Monitorování datových sítí: Dnes Monitorování datových sítí: Dnes FlowMon Friday, 29.5.2015 Petr Špringl springl@invea.com Obsah Monitorování datových toků = Flow monitoring Flow monitoring a bezpečnost sítě = Network Behavior Analysis

Více

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP TCP/IP.

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP TCP/IP. Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Operační systém TCP/IP TCP spojení TCP/IP Pseudo terminal driver Operační systém

Více

Protokoly: IP, ARP, RARP, ICMP, IGMP, OSPF

Protokoly: IP, ARP, RARP, ICMP, IGMP, OSPF IP vrstva Protokoly: IP, ARP, RARP, ICMP, IGMP, OSPF UDP TCP Transportní vrstva ICMP IGMP OSPF Síťová vrstva ARP IP RARP Ethernet driver Vrstva síťového rozhraní 1 IP vrstva Do IP vrstvy náležejí další

Více

Flow Monitoring & NBA. Pavel Minařík

Flow Monitoring & NBA. Pavel Minařík Flow Monitoring & NBA Pavel Minařík minarik@invea.cz Formulace zadání Zákazník požaduje řešení pro monitorování a analýzu provozu datové sítě Měření provozu v prostředí multi-10gbps infrastruktury Historie

Více

Kerio Operator. Kerio Technologies

Kerio Operator. Kerio Technologies Kerio Operator Příručka uživatele Kerio Technologies 2011 Kerio Technologies s.r.o. Všechna práva vyhrazena. Tento manuál popisuje produkt: Kerio Operator ve verzi 1.1. Změny vyhrazeny. Aktuální verzi

Více

SPINEL. Komunikační protokol. Obecný popis. Verze 1.0

SPINEL. Komunikační protokol. Obecný popis. Verze 1.0 SPINEL Komunikační protokol Obecný popis Verze 1.0 OBSAH Obsah... 2 OBECNÝ POPIS PROTOKOLU SPINEL... 3 Obecný formát rámce pro ASCII kódování... 3 Obecný formát dat pro binární kódování... 3 Definované

Více

3.17 Využívané síťové protokoly

3.17 Využívané síťové protokoly Název školy Číslo projektu Autor Název šablony Název DUMu Tematická oblast Předmět Druh učebního materiálu Anotace Vybavení, pomůcky Střední průmyslová škola strojnická Vsetín CZ.1.07/1.5.00/34.0483 Ing.

Více

Nastavení telefonu Nokia Lumia 925

Nastavení telefonu Nokia Lumia 925 Nastavení telefonu Nokia Lumia 925 Telefon Nokia Lumia 925, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny. Některé

Více

Manuál pro nastavení telefonu Siemens C450 IP

Manuál pro nastavení telefonu Siemens C450 IP Manuál pro nastavení telefonu Siemens C450 IP Před nastavením se předpokládá kompletní připojení telefonu jak do elektrické sítě, tak do sítě ethernet. 1. Nastavení jazyka Zvolte Menu, poté Settings Handset

Více

Zabezpečení dat při přenosu

Zabezpečení dat při přenosu Zabezpečení dat při přenosu Petr Grygárek rek 1 Komunikace bez spojení a se spojením Bez spojení vysílač může datové jednotky (=rámce/pakety) zasílat střídavě různým příjemcům identifikace příjemce součástí

Více

FlowMon. Představení FlowMon verze 7.0. Petr Špringl, springl@invea.com Jan Pazdera, pazdera@invea.com Pavel Minařík, minarik@invea.

FlowMon. Představení FlowMon verze 7.0. Petr Špringl, springl@invea.com Jan Pazdera, pazdera@invea.com Pavel Minařík, minarik@invea. FlowMon Představení FlowMon verze 7.0 Petr Špringl, springl@invea.com Jan Pazdera, pazdera@invea.com Pavel Minařík, minarik@invea.com Obsah FlowMon řešení co to je, co zahrnuje? FlowMon novinky posledních

Více

Principy telefonní signalizace SIP

Principy telefonní signalizace SIP Principy telefonní signalizace SIP Teorie a praxe IP telefonie Skymia s.r.o. Petr Hruška petr.hruska@skymia.cz 6.12.2012 Historie protokolu SIP 1996 první pracovní verze 1999 schváleno RFC 2543 2002 schváleno

Více

Nastavení telefonu Sony Ericsson T300

Nastavení telefonu Sony Ericsson T300 Nastavení telefonu Sony Ericsson T300 Telefon Sony Ericsson T300, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny.

Více

IPv6. RNDr. Ing. Vladimir Smotlacha, Ph.D.

IPv6. RNDr. Ing. Vladimir Smotlacha, Ph.D. IPv6 RNDr. Ing. Vladimir Smotlacha, Ph.D. Katedra počítačových systémů Fakulta informačních technologií České vysoké učení technické v Praze Vladimír Smotlacha, 2011 Počítačové sít ě BI-PSI LS 2010/11,

Více

26 Evidence pošty. Popis modulu. Záložka Evidence pošty

26 Evidence pošty. Popis modulu. Záložka Evidence pošty 26 Evidence pošty Uživatelský modul Evidence pošty realizuje podrobnou evidenci všech došlých a odesílaných poštovních zásilek s možností přidělovat tyto zásilky uživatelům informačního systému k vyřízení,

Více

Asterisk a ENUM Ondřej Surý <ondrej@sury.org> Co je to VoIP? Jaké se používají protokoly? Co je to Asterisk? Co je to ENUM? Konfigurace Demo Otázky a

Asterisk a ENUM Ondřej Surý <ondrej@sury.org> Co je to VoIP? Jaké se používají protokoly? Co je to Asterisk? Co je to ENUM? Konfigurace Demo Otázky a Asterisk a ENUM Ondřej Surý Co je to VoIP? Jaké se používají protokoly? Co je to Asterisk? Co je to ENUM? Konfigurace Demo Otázky a odpovědi Co je to VoIP? VoIP je akronym pro Voice over

Více

Inovace výuky prostřednictvím šablon pro SŠ

Inovace výuky prostřednictvím šablon pro SŠ Název projektu Číslo projektu Název školy Autor Název šablony Název DUMu Stupeň a typ vzdělávání Vzdělávací oblast Vzdělávací obor Tematický okruh Inovace výuky prostřednictvím šablon pro SŠ CZ.1.07/1.5.00/34.0748

Více

Jak nastavit Email2SMS a SMS2Email na 2N StarGate - nové CPU 2013

Jak nastavit Email2SMS a SMS2Email na 2N StarGate - nové CPU 2013 Jak nastavit Email2SMS a SMS2Email na 2NStarGate - nové CPU 2013 V tomto FAQ naleznete veškeré potřebné kroky ke správnému nastavení Email2SMS a SMS2Email funkcí v bráně 2N StarGate. V první části tohoto

Více

Novinky ve FlowMon 6.x/FlowMon ADS 6.x

Novinky ve FlowMon 6.x/FlowMon ADS 6.x Novinky ve FlowMon 6.x/FlowMon ADS 6.x FlowMon je kompletní řešení pro monitorování a bezpečnost počítačových sítí, které je založeno na technologii sledování IP toků (NetFlow/IPFIX/sFlow) a analýze chování

Více

Přednáška 3. Opakovače,směrovače, mosty a síťové brány

Přednáška 3. Opakovače,směrovače, mosty a síťové brány Přednáška 3 Opakovače,směrovače, mosty a síťové brány Server a Client Server je obecné označení pro proces nebo systém, který poskytuje nějakou službu. Služba je obvykle realizována některým aplikačním

Více

Návod k obsluze. VoIP PBX ústředna. Soundwin WiPBX, ipbx

Návod k obsluze. VoIP PBX ústředna. Soundwin WiPBX, ipbx Návod k obsluze VoIP PBX ústředna Soundwin WiPBX, ipbx Popis produktu Soundwin WiPBX a ipbx jsou SOHO SIP PBX ústředny, které překvapí nejen velikostí, ale také nízkou cenou. Brány WiPBX a ipbx se mezi

Více

Schéma e-pošty. UA (User Agent) rozhraní pro uživatele MTA (Message Transfer Agent) zajišťuje dopravu dopisů. disk. odesilatel. fronta dopisů SMTP

Schéma e-pošty. UA (User Agent) rozhraní pro uživatele MTA (Message Transfer Agent) zajišťuje dopravu dopisů. disk. odesilatel. fronta dopisů SMTP Elektronická pošta Schéma e-pošty odesilatel UA disk SMTP fronta dopisů disk MTA SMTP MTA adresát UA disk POP IMAP poštovní schránka disk MTA SMTP UA (User Agent) rozhraní pro uživatele MTA (Message Transfer

Více

Nastavení telefonu Windows Phone 8S by HTC

Nastavení telefonu Windows Phone 8S by HTC Nastavení telefonu Windows Phone 8S by HTC Telefon Windows Phone 8S by HTC, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny.

Více

File Transfer Protocol (FTP)

File Transfer Protocol (FTP) File Transfer Protocol (FTP) protokol pro přenos souborů, jeden z klasických RFC 959 přehled specifikací na http://www.wu-ftpd.org/rfc/ opět architektura klient-server navržen s ohledem na efektivní využívání

Více

Nastavení telefonu Nokia 515

Nastavení telefonu Nokia 515 Nastavení telefonu Nokia 515 Telefon Nokia 515, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny. Pokud je potřeba

Více

Abychom se v IPv6 adresách lépe orientovali, rozdělíme si je dle způsobu adresování do několika skupin:

Abychom se v IPv6 adresách lépe orientovali, rozdělíme si je dle způsobu adresování do několika skupin: Adresy v internetovém protokolu verze 6 (I) V tomto a dalším díle IPv6 seriálu se budeme věnovat různým typům IPv6 adres, vysvětlíme si jejich formát zápisu, k čemu se používají a kde se s nimi můžeme

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 35.240.60 materiálem o normě. Dopravní telematika Vyhrazené spojení krátkého rozsahu (DSRC) Datová

Více

Avaya IP Office R8.0 - Jak ji nakonfigurovat s 2N Helios IP

Avaya IP Office R8.0 - Jak ji nakonfigurovat s 2N Helios IP Avaya IP Office R8.0 - Jak ji nakonfigurovat s 2N Helios IP Konfigurace Avaya IP Office Všechny změny konfigurace pro Avaya IP Office jsou dělány přes IP Office Manager. Všechny parametry jsou v následujících

Více

TRANSPORTY výbušnin (TranV)

TRANSPORTY výbušnin (TranV) TRANSPORTY výbušnin (TranV) Ze zákona vyplývá povinnost sledování přeprav výbušnin. Předpokladem zajištění provázanosti polohy vozidel v čase a PČR je poskytování polohy vozidla předepsaným způsobem. Komunikace

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_31_20 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

Rodina protokolů TCP/IP, verze 2.7. Část 11: VOIP, IP telefonie

Rodina protokolů TCP/IP, verze 2.7. Část 11: VOIP, IP telefonie Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokolů, verze 2.7 Část 11: VOIP, IP telefonie Jiří Peterka, 2011 terminologie VOIP (Voice over IP) obecné

Více

FlowMon ADS 3. Nová generace řešení pro analýzu provozu datové sítě. Pavel Minařík pavel.minarik@advaict.com

FlowMon ADS 3. Nová generace řešení pro analýzu provozu datové sítě. Pavel Minařík pavel.minarik@advaict.com 3 Nová generace řešení pro analýzu provozu datové sítě Pavel Minařík pavel.minarik@advaict.com Přehled produktu Plug-in pro řešení FlowMon Network Behavior Analysis Určen pro detekci provozních a bezpečnostních

Více

Další nástroje pro testování

Další nástroje pro testování Další nástroje pro testování PingPlotter grafická varianta programu ping umožňuje soustavné monitorování, archivování apod. www.pingplotter.com VisualRoute grafický traceroute visualroute.visualware.com

Více

Nastavení telefonu Sony Ericsson T230

Nastavení telefonu Sony Ericsson T230 Nastavení telefonu Sony Ericsson T230 Telefon Sony Ericsson T230, zakoupený v prodejní síti společnosti T-Mobile Czech Republic a.s., má potřebné parametry pro použití T-Mobile služeb již přednastaveny.

Více

X32MKO - Mobilní komunikace. projekt č.1 Sítě DECT, přenos hlasu, výstavba sítě a její rozšíření

X32MKO - Mobilní komunikace. projekt č.1 Sítě DECT, přenos hlasu, výstavba sítě a její rozšíření 31.10.2007 X32MKO - Mobilní komunikace projekt č.1 Sítě DECT, přenos hlasu, výstavba sítě a její rozšíření měřící skupina č.3 středa 14:30-16:00 Zadání: 1. Vybudování DECT sítě Vybudujte síť DECT podle

Více

Ing. Jitka Dařbujanová. E-mail, SSL, News, elektronické konference

Ing. Jitka Dařbujanová. E-mail, SSL, News, elektronické konference Ing. Jitka Dařbujanová E-mail, SSL, News, elektronické konference Elementární služba s dlouhou historií Původně určena pro přenášení pouze textových ASCII zpráv poté rozšíření MIME Pro příjem pošty potřebujete

Více

Základní nastavení brány 2N VoiceBlue MAX

Základní nastavení brány 2N VoiceBlue MAX Základní nastavení brány 2NVoiceBlue MAX 2N VoiceBlue MAX je zařízení umožňující přímé propojení VoIP sítě a podporující signalizační protokol SIP se sítěmi GSM. Lze jej použít i při přímém spojení se

Více

Směrování VoIP provozu v datových sítích

Směrování VoIP provozu v datových sítích Směrování VoIP provozu v datových sítích Ing. Pavel Bezpalec, Ph.D. Katedra telekomunikační techniky FEL, ČVUT v Praze Pavel.Bezpalec@fel.cvut.cz Obecné info o směrování používané směrovací strategie Směrování

Více

Telefonní přístroj. Instalační a konfigurační příručka

Telefonní přístroj. Instalační a konfigurační příručka Telefonní přístroj SPA 921/SPA 922 Instalační a konfigurační příručka 1 Krok 1: Nastavení síťových služeb pro SPA 921/922 Před konfiguraci Linksys SPA-921/922 si musíte zjistit následující informace, aby

Více

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt. C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt

Více

Semestrální projekt do předmětu SPS

Semestrální projekt do předmětu SPS Semestrální projekt do předmětu SPS Název projektu: Instalace a provoz protokolu IPv6 v nových verzích MS Windows (XP). Ověření proti routerům Cisco a Linux. Cíl projektu: Autoři: Cílem tohoto projektu

Více

1 Protokol TCP/IP (Transmission Control Protocol/Internet Protocol) a OSI model

1 Protokol TCP/IP (Transmission Control Protocol/Internet Protocol) a OSI model 1 Protokol TCP/IP (Transmission Control Protocol/Internet Protocol) a OSI model Protokoly určují pravidla, podle kterých se musí daná komunikační část chovat. Když budou dva počítače používat stejné komunikační

Více

Y36PSI Protokolová rodina TCP/IP

Y36PSI Protokolová rodina TCP/IP Y36PSI Protokolová rodina TCP/IP Jan Kubr - Y36PSI 1 11/2008 Program protokol síťové vrstvy IP podpůrné protokoly ICMP RARP, BOOTP, DHCP protokoly transportní vrstvy UDP TCP Jan Kubr - Y36PSI 2 11/2008

Více

Definice pojmů a přehled rozsahu služby

Definice pojmů a přehled rozsahu služby PŘÍLOHA 1 Definice pojmů a přehled rozsahu služby SMLOUVY o přístupu k infrastruktuře sítě společnosti využívající technologie Carrier IP Stream mezi společnostmi a Poskytovatelem 1. Definice základních

Více

Směrovací protokol Mesh (802.11s) na platformě Mikrotik

Směrovací protokol Mesh (802.11s) na platformě Mikrotik Směrovací protokol Mesh (802.11s) na platformě Mikrotik J. Bartošek, P. Havíček Abstrakt: V této práci je popsán princip fungování směrovacího protokolu mesh na platformě mikrotik. Na této platformě ovšem

Více

Elektronická pošta. elementární služba, výchozí pro některé další jedna z prvních síťových služeb vůbec. základní principy popisují

Elektronická pošta. elementární služba, výchozí pro některé další jedna z prvních síťových služeb vůbec. základní principy popisují Elektronická pošta elementární služba, výchozí pro některé další jedna z prvních síťových služeb vůbec v Internetu: protokol SMTP existují i další poštovní systémy, zpravidla propojeny s internetovou poštou

Více

B4. Počítačové sítě a decentralizované systémy Jakub MÍŠA (2006)

B4. Počítačové sítě a decentralizované systémy Jakub MÍŠA (2006) B4. Počítačové sítě a decentralizované systémy Jakub MÍŠA (2006) 5. Síťové technologie videokonference a multimediální přenosy, IP telefonie, IP verze 6. Vysokorychlostní počítačové sítě pro vědu a výzkum

Více