Výukový program: ICT a elektrotechnika pro praxi. Voice over IP. Miroslav Vozňák Filip Řezáč

Transkript

1 Výukový program: ICT a elektrotechnika pro praxi Voice over IP Miroslav Vozňák Filip Řezáč 2010

2 Miroslav Vozňák a Filip Řezáč, 2010 Fakulta elektrotechniky a informatiky Vysoká škola báňská Technická univerzita Ostrava 17. listopadu 15, Ostrava Poruba Výukový program: ICT a elektrotechnika pro praxi Název modulu: Voice over IP Název: Voice over IP Autor: Miroslav Vozňák, Filip Řezáč Vydání: první Místo: Ostrava Rok: 2010 Vydavatel: VŠB Technická univerzita Ostrava Počet stran: 110 Neprodejné 2

3 PŘEDMLUVA Výukový text s názvem Voice over IP reflektuje na současný trend hlasových komunikačních systémů. VoIP lze chápat jako technologii, která využívá prostředky sítě Internet k přenosu hlasu, v aplikační rovině pak vidíme IP telefonii jako aplikaci nad VoIP. První pokusy s přenosem hlasu, tehdy v prenatálním věku Internetu, uskutečnil Danny Cohen v roce Komerční úspěch Internetu znamenal podnět k intenzivnímu vývoji v této oblasti a přijetí mezinárodně uznávaných standardů, a to především H.323 v roce 1996 z organizace ITU-T a SIP doporučení v roce 1999 z dílny IETF. V naší publikaci se budeme orientovat na SIP, a to vzhledem k faktu, že SIP se stal defacto stěžejním protokolem pro IP telefonii a s přihlédnutím k rozsahu publikace a užitné hodnotě informací byl pro autory jednoznačnou volbou. V první části se čtenář seznámí s nezbytnými teoretickými základy VoIP technologie a SIP protokolu, které zužitkuje v druhé části věnované Asterisku. Tak jako je Apache symbolem úspěšného projektu webového serveru, tak analogicky Asterisk představuje v IP telefonii uznávané komunikační řešení pro nasazení IP telefonie. Autorský kolektiv si je vědom, že nejlepší cestou k pochopení výkladu a souvislostí je experiment, a proto je třetí část publikace věnována praktickým příkladům. Na publikaci se podíleli Miroslav Vozňák a Filip Řezáč. Prvně uvedený je garantem publikace a je na pozici docenta na Fakultě elektrotechniky a informatiky VŠB-Technické univerzity v Ostravě. Filip Řezáč je asistentem na stejné fakultě, oba autoři působí na Katedře telekomunikační techniky. Poděkování za pomoc při realizaci publikace patří Martinu Tomešovi, který se jako student Fakulty elektrotechniky a informatiky v Ostravě podílel na tvorbě obrázků publikace a praktických příkladech konfigurace Asterisku. Miroslav Vozňák a Filip Řezáč V Ostravě, Listopad

4 OBSAH 1 Přenos sítí Internet v reálném čase Real Time Protocol Timestamp a rozptyl zpoždění Stanovení zpoždění z RTP Řídící protokol RTCP Zabezpečení přenosu RTP Zabezpečení pomocí SRTP Návrh vylepšení SRTP pomocí ZRTP Přenos DTMF a jiných tónů přes RTP Audio v přenosovém řetězci od odesílatele k příjemci Nároky na přenos audia v IP sítích Kodeky PCM ADPCM LPC CELP 23 2 Protokol SIP Základní popis protokolu SIP Prvky SIP řešení User Agent a Back to Back User Agent SIP Proxy Server SIP Registrar Server SIP Redirect Server SIP žádosti a odpovědi Základní popis SIP hlavičky typické žádosti SIP metody SIP odpovědi Transakce Dialog Transakce a dialog v příkladu SIP časovače a retransmise Zabezpečení v SIPu Registrace Směrování Směrování dle RURI a Via SIP trapezoid Udržení SIP Proxy v signalizační trase 53 4

5 2.6 SDP- protokol popisu relace Konstrukce položek SDP pro komunikaci SIP/SDP Offer/Answer model 57 3 Asterisk Popis Asterisku Režimy Asterisku Kodeky a prokoly Asterisku Verze Asterisku Instalace Asterisku Instalace pomocí balíčku s příponou.deb Instalace pomocí balíčku s příponou.rpm Instalace pomocí kompilace zdrojových kódů Úvod do konfigurace SIPu a plánu volby Konfigurace Asterisku Spuštění, zavolání Hello World a zastavení Asterisku Volání Hello-World pomocí SIP telefonu Minimální konfigurace Asterisku se dvěma SIP účty Nastavení práv na základě kontextů Dialplan Kontexty - Contexts Pravidla - Extensions Priority - Priorities Vzory Pattern Matching Vložené kontexty Include Statements Časové Vložené kontexty Proměnná ${EXTEN} a funkce ${CALLERID(num)} Programová struktura Aplikace Set ( ) Štítky a Goto ( ) Smyčky a While ( ) Podmínka a Gotoif ( ) Podprogramy a Gosub ( ) Proměnné Makra Asterisk Extension Language (AEL) CLI příkazy pro AEL Aelparse Srovnání extensions.conf s extensions.ael Kontexty, extensions a priority v AEL Vložené kontexty Include Statements v AEL 83 5

6 3.5.6 Štítky, goto a přeskakování v AEL Podmínky v AEL Smyčky v AEL Makra Filtrování na základě ID volajícího Voic IVR Interactive Voice Reponse Jednoduché IVR Neplatný vstup (extension i) Pauzy Víceúrovňové IVR Databáze Asterisku Zápis hodnot do databáze Čtení hodnot z databáze Mazání hodnot z databáze Přístup do databáze z CLI Zápis hodnot do databáze pomocí CLI Čtení hodnot z databáze pomocí CLI Mazání hodnot z databáze pomocí CLI Zobrazení obsahu databáze v CLI Přístup do databáze z příkazové řádky Záloha databáze Příklad přesměrování Služby Asterisku 97 4 Asterisk v praktických příkladech Nastavení SIP účtů Nastavení IAX účtů Dialplan a jeho nastavení Další užitečná nastavení pro Asterisk Rozšířené nastavení SIP povolení videopřenosu Peering mezi dvěma Asterisky Zabezpečení médií v Asterisku pomocí SRTP Zabezpečení signalizace v Asterisku pomocí SIPS Literatura Rejstřík 109 6

7 1 Přenos sítí Internet v reálném čase Transportní protokoly Internetu nabízí spolehlivou službu s potvrzováním doručených datagramů pomocí spojově orientovaného protokolu TCP (Transmission Control Protocol) anebo nespolehlivou službu na nespojově orientovaném protokolu UDP (User Datagram Protocol). UDP protokol přidává k IP záhlaví důležitá pole, kterými jsou: zdrojový a cílový port služby, délka přenášených dat včetně záhlaví a kontrolní součet pseudozáhlaví. Nepochybně stojí za zmínku, že UDP nezaručuje doručení ve správném pořadí, což některým aplikacím přináší komplikace. Je zřejmé, že u požadavku na realtime přenos není možné použít službu s potvrzováním datagramů, neboť informace pozbývá svou platnost s časem a pro IP telefonii je nutné použit transportní službu zajišťovanou UDP [voz92]. UDP protokol je vhodnější pro Real-time aplikace, umožňuje sice nespolehlivé, ale rychlé doručování. I tady ovšem najdeme nedostatky a potřebu adaptace pomocí dalšího protokolu nad UDP, řešením je protokol přenosu v reálném čase RTP, struktura zprávy je na zobrazena na obr. 1. [voz92]. Obr.1. Struktura zprávy pro real-time přenos. 1.1 Real Time Protocol Real Time Protocol je označován jako protokol aplikační vrstvy, který využívá transportní protokol UDP, ale dle účelu a obsahu polí hlaviček nese důležité znaky transportního protokolu a tak se jeví logičtější ho zařadit na transportní vrstvu hned nad UDP, jehož přenos vylepšuje. Tento pohled je ale spíše filozofický a neřeší nic zásadního, pojďme se podívat na jednotlivá pole RTP a způsob adaptace real-time aplikací na přenos v Internetu, viz. obr. 2. RTP protokol především zajišťuje seřazení zaslaných paketů (Sequence Number) a jejich časové značkování (Timestamp), další vlastnost, která ho řadí do transportní vrstvy je multiplexování a demultiplexování. Pokud si vezmeme postup odesílání hlasu v IP sítí, tak tok bitů digitalizovaného hlasu ve zvoleném formátu (např. PCM) je naporcován do bloků (typicky 20 B až 160 B) a každý blok je opatřen hlavičkou RTP o velikosti 12 B, dále se před hlavičku zařadí 8 B hlavičky UDP, viz. obr. 1. Tím je datagram připraven ke vstupu do vrstvy síťové, kde dostane IP hlavičku o velikosti 20 B, celkově tedy bylo k užitečné zátěži přidáno 40 B. Jednotlivá pole RTP obsahují tyto položky, viz. obr.2 : V je verze. Určuje verzi RTP, P je doplnění. Pokud je nastaveno, paket obsahuje na konci jeden či více doplňkových oktetů, které nenesou užitečná data, 7

8 X je rozšiřující bit. Pokud je nastaven, pak pevné záhlaví je následováno právě jedním rozšířením záhlaví, které má definovanou strukturu, CC je CSRC count obsahuje číslo identifikátoru příspěvku zdroje, M je značka. Interpretace značky je různá. Lze jí použít např. jako označení konce rámce v paketovém toku, na své využití ještě čeká. Payload Type určuje formát užitečného zatížení RTP a stanovuje jeho význam pro aplikaci. Další kód typu užitečného zatížení je definován dynamicky, ale ne již přes RTP, Sequence number se zvyšuje o jeden pro každý vyslaný RTP paket Přijímač jej využívá pro určení případné ztráty paketu a pro obnovení souslednosti paketu, Timestamp vyjadřuje vzorkovací značku prvního oktetu v RTP paketu. Vzorkovací značka musí být odvozena od lineárního časovače z důvodu synchronizace a korekce rozptylu zpoždění (jitter). Rozlišení časovače musí být dostatečné pro požadovanou synchronizační přesnost a pro zjištění jitteru příchozího paketu (např. jeden kmit za videosnímek není dostačující), SSRC identifikuje synchronizační zdroj. Tento identifikátor je zvolen náhodně s tím, že žádné dva synchronizační zdroje v rámci jedné RTP relace nemají stejný SSRC identifikátor, CSRC je identifikační seznam přispívajících zdrojů. Identifikuje přispívající zdroj z důvodu užitečné informace obsažené v tomto paketu. Obr.2. Jednotlivá pole RTP dle specifikace RFC Samotný přenos audia/videa v RTP bývá doplněn o dohledový protokol RTCP (Real Time Control Protocol), který nese statistické informace o průběhu přenosu. Port pro RTCP je nastaven o jedničku vyšší než RTP, minimální doba pro odeslání RTCP je stanovena na 2 sec., např. u G.711 by to znamenalo jeden paket RTCP na sto paketů RTP, pro čísla portů platí (1), přičemž portům RTP jsou přidělována sudá čísla. port_rtcp=port_rtp+1 (1) V současné době prošel Real-Time protokol třemi verzemi, a to: RFC 1889, z roku 1996 (Transport Protocol for Real-Time Applications), původní doporučení; RFC 3550, z roku 2003, drobná vylepšení oproti RFC 1889 především v části dohledu nad RTP tokem, tím původní RFC 1889 zastaralo; RFC 3711, z roku 2004, specifikuje zabezpečený přenos RTP jako SRTP (Secure Real-time Transport Protocol). 8

9 Hlavička RTP může být komprimována ze 40B na 2-3B s použitím kompresního protokolu crtp (compressed RTP), jelikož je vyžadována podpora na obou stranách, tak je použití víceméně omezeno na dvoubodové spoje a crtp není příliš rozšířen [coli]. Typickým portem RTP je 5004 a RTCP tím pádem 5005, ale v zásadě může být použit jakýkoliv port vyšší než 1024, např. Cisco zařízení alokují pro RTP porty v rozmezí až Timestamp a rozptyl zpoždění RTP pakety jsou odesílány obvykle v pravidelných intervalech t [s]. Pokud zachytíme RTP tok, tak tento interval zjistíme z časových značek (timestamp). Pro timestamp platí, že údaje v políčku jsou odvozeny od lineárního časového zdroje. Interval odesílání (timing) se z RTP paketů vypočte ze dvou po sobě jdoucích časových značek dle rovnice (2). timestamp{n+1} timestamp{n} t= (2) sampling_frequency Vzorkovací kmitočet je obvykle 8KHz, na obrázku níže jsou zachyceny RTP pakety s PCM kódováním G.711-Alaw. Rozdíl dvou po sobě jdoucích údajů zachycených na obr.3. v položce Time úplně vpravo (timestamp) je 160, pochopitelně odcházejících ze stejné IP adresy (source). Po vydělení vzorkovacím kmitočtem 8KHz dostáváme 20 ms, což je časování odesílání paketů ze zdroje. V uvedeném případě můžeme očekávat tedy 50 paketů za sekundu. Obr. 3. Inkrementace hodnoty pole timestamp. Ačkoliv datagramy byly odeslány v intervalech 20 ms, tak pokud bychom určili rozdíly mezi vyslanými na straně odesílatele a srovnali je s rozdíly mezi přijatými datagramy na straně příjemce, zjistili bychom, že se liší. Jelikož pakety neměly stejné podmínky přenosu, způsobené především odlišným časem stráveným ve frontách na směrovačích, tak došlo k rozdílu mezi časem skutečného a očekávaného příchodu, tento rozdíl označujeme jako rozptyl (jitter). Označme Si jako hodnotu časové značky v i-tém RTP paketu (timestamp) a Ri čas skutečného doručení paketu i příjemci, potom pro dva dva pakety i a i-1 bude platit pro výpočet rozptylu jejich doručení příjemci rovnice: D = (R R ) (S S ) = (R S ) (R S ) (3) i i i 1 i i 1 i i i 1 i 1 Podmínkou platnosti vztahu je, že RTP pakety jsou přijaty z jednoho zdroje synchronizace (SSRC pole v RTP hlavičce). 9

10 Obr. 4. Rozptyl zpoždění zjištěný při příjmu RTP toku. Zatímco Di [ms] představuje okamžitý jitter, tak v praxi se využívá k sledování rozptylu klouzavý průměr, který reflektuje jeho dosavadní průběh, na druhé straně je ale potřebnost rychlé konvergence k aktuálním hodnotám [cad]. Pro tento účel se nejčastěji používá následující vztah pro výpočet sledované hodnoty rozptylu Ji, přičemž empiricky získaná hodnota 16 zahrnující průměr 16-ti předchozích rozptylů reflektuje vlastnosti zmíněné v předchozí větě. [ Di J i 1] 15 Di Ji = Ji 1 + = Ji 1 + (4) Stanovení zpoždění z RTP RCTP XR definuje rozšířené posílání zpráv XR (Extended Reports) v rámci dohledu nad RTP tokem, které zajišťuje protokol RTCP (Real Time Control Protocol). RTCP XR je obsažen v doporučení RFC 3611 z konce roku 2003, XR pakety jsou složeny z jednotlivých bloků oznámení (report blocks) a jedním z těchto bloků je i VoIP Metrics Report Block, který uceleně informuje o kvalitativních parametrech VoIP [voz70], [voz73] a [voz92]. RTD + ESD(A) + ESD(B) OWPD = (5) 2 Jednosměrné síťové zpoždění OWPD (5) může být stanoveno z RTD (Round Trip Delay) [ms], což je doba oběhu zprávy od odesílatele k příjemci a zpět neboli odezva. Jelikož je nutné vyjádřit celkové E2E zpoždění, tak RFC 3611 zavádí parametr odhadu systémového zpoždění ESD (Estimated System Delay) [ms], který je definován součet všech přírustků zpoždění na zařízení. RTCP-XR stanovuje, že na straně vysílací je v ESD(A) zahrnuto celkové zpoždění vzniklé kódováním a paketizací, na straně přijímací je ESD(B) tvořenou součtem nastavené doby mezipaměti vyrovnání rozptylu (de-jitter buffer) a zpožděním při dekódování. Je zaveden parametr jednosměrného symetrického zpoždění hlasové cesty OWPD (one way symmetric voice path delay), který je vyjádřen vztahem (5). 10

11 1.4 Řídící protokol RTCP Původní RFC 1889 pro RTP z ledna 1996 vydrželo poměrně dlouho a další RFC pro RTP bylo uvolněno až v červnu roku Implementace RTP dle RFC 3550 si dokáže poradit se starší RFC 1889, neboť ve formátu paketu či v obsahu hlaviček nedošlo ke změnám, změny jsou v RTCP, čili v protokolu dohledu toku médií. Změnila se pravidla a algoritmy užití protokolu, nejvýznamnější změnou je specifikace typů zpráv RTCP a rozšíření týkající se pravidel odesílání RTCP (jedná se o algoritmus časování odesílání RTCP). RTCP shromažďuje statistiky přenosu na RTP, informace o množství odeslaných bajtů a počtu paketů, ztracených paketů, rozptylu zpoždění. Dle RFC 3550 je definováno celkem pět typů zpráv: SR (Sender Report) soubor statistik od odesílatelů, posílá se aktuální identifikace zdroje synchronizace (SSRC), časová značka (timestamp), počet odeslaných paketů a odeslaných bajtů, RR (Receiver Report) soubor statistik od příjemců, obsahuje jednak podíl ztracených paketů k celkovému množství očekávaných, počet ztracených paketů, aktuální sekvenční číslo (SN), jitter, poslední timestamp a čas, který uběhl od poslední zprávy SR, SDES (Source DEScription) vlastnosti odesílatelů RTP komunikace (jejich vizitky ), jednak je to SSRC a jméno (obvykle URI), BYE (End message) signalizuje ukončení relace; APP funkce specifické pro jednotlivé aplikace. 1.5 Zabezpečení přenosu RTP Použitím nešifrovaného přenosu pomocí RTP zvyšujeme riziko odposlechu hovoru [voz191], [voz193]. Oblíbený síťový softvérový analyzátor Wireshark umí ze zachyceného RTP toku rekonstruovat původní zvukovou stopu. Získání zvukové stopy z RTP paketů a její následné přehrání či uložení, je v aplikaci Wireshark možné pouze u kodeků PCM A-law a µ-law, ovšem existuje řada placených analyzátorů, které zpracují pro přehrání audio signál i s jinými kodeky (např. Observer). Nešifrovaný přenos RTP je proto velkým hazardem a zabezpečení je nezbytné. U transportních protokolů užívaných pro multimédia musíme hlavně brát zřetel na to, že komunikace pomocí těchto protokolů probíhá v reálném čase, proto i zabezpečovací techniky musí byt implementovány tak, aby vznikalo minimální časové zpoždění [voz138], [voz166] a [voz194] Zabezpečení pomocí SRTP Stejně jako u signalizačních protokolů, tak ani nejpoužívanější protokol RTP neobsahuje ve svém základu žádné ochranné metody či mechanizmy, a proto byl v roce 2004 v RFC 3711 definován protokol SRTP (Secure Real-time Transport Protocol). Formát paketu SRTP je odvozen od RTP, šifrován je přenášený obsah užitečné informace (payload) a integrita polí hlaviček je zajištěna pomocí autentizační značky (authentication tag), která je získána algoritmem HMAC-SHA-1. Do této hašovací funkce vstupuje klíč auth_key a užitečná zátěž RTP, výstupem je autentizační značka, která je přidána do poslední položky zabezpečeného SRTP datagramu. 11

12 Obr. 5. HMAC-SHA1 funkce Použití SRTP autentizační značky je v RFC 3711 doporučeno vždy, zatímco další značka SRTP MKI je nepovinná. MKI (Master Key Identifier) je prezentován jako hlavní klíč a může být použit pro správu klíčů (key management), využití je pro účely obměny klíčů během relace, identifikuje konkrétního hlavní klíč (master_key) užívaného v SRTP, z něj jsou odvozeny další důležité klíče, což je zobrazeno v obr. 10. MKI zvyšuje bezpečnost, protože během jedné relace mohou být klíče střídány [voz120]. Obr. 6. Obsah polí hlavičky SRTP Podívejme se nyní na kryptografické mechanizmy užité v RFC SRTP definuje používání režimu šifrování AES-CTR (Counter Mode) anebo AES-f8, přičemž výchozím módem je AES-CTR. Povinně implementováno musí být šifrování AES-CTR a případně může být nepovinně podporován i algoritmus AES-f8. Zatím jsme se s implementací algoritmu AES-f8 v SRTP dosud nesetkali, všichni implementují AES-CTR. V případě f8 jde o aplikaci módu OFB (Output Feedback) a používá se pro šifrování v UMTS sítích. U OFB se otevřený text sčítá na členu nonekvivalence s výstupním blokem získaným aplikací blokové šifry, viz. obr

13 Obr. 7. Režim šifrování OFB. První výstupní blok je vytvořen šifrovací funkcí CIPH K z inicializačního vektoru a je zároveň vstupem do druhého bloku, kde po aplikaci šifrovacího algoritmu získáme druhý výstupní blok, který je opět vstupem do dalšího. Obr. 8. CTR režim šifrování. Šifrový text získáme operací exkluzivní disjunkce, vstupními hodnotami jsou jednak bity otevřeného textu a jednak bity z jednotlivých výstupních bloků. Jedná se o režim proudové šifry (stream cipher mode) anebo exaktně řečeno, u OFB dochází k převodu blokové šifry na proudovou. 13

14 Čítačový režim CTR, viz. obr. 8, je zjednodušenou verzi zpětnovazební šifry OFB, kdy při šifrování je namísto vazby na předchozí blok použita vazba s hodnotou inkrementálního čítače, viz. obrázek. Opět dochází převodu blokové šifry na proudovou. CTR rovněž využívá inicializační hodnotu, která se načte do vstupního registru (Counter 1) a po zašifrování funkcí CIPH K dostáváme první výstupní blok, který se sčítá na členu XOR s otevřeným textem. Poté doje k aktualizaci čítače (obvykle přičtením jedničky) a získáváme Counter 2, opět se opakuje jeho šifrování a operace operací exkluzivní disjunkce s otevřeným textem. Aktualizace čítače je definována poměrně volně, hodnota nemusí být inkrementována o jedničku, musí být ovšem splněna podmínka, že obsah čítačů nesmí být stejný. Obr. 9. Blokové schéma šifrování obsahu RTP Podívejme se nyní na aplikaci AES-CTR v SRTP, viz. obr. 9. Důvěrnost přenášených dat v paketu zajišťuje kryptografický primitiv AES, který funguje v tomto případě jako generátor pseudonáhodných klíčů. Vstupem do generátoru je šifrovací klíč encr_key a inicializační vektor IV, který sestává z kontrolního součtu salt key, SSRC a indexu paketu. Výsledný klíč je pomocí logické operace XOR aplikován na nezašifrovaný obsah paketu, což odpovídá CTR režimu šifrování. Inicializační vektor IV je získán z rovnice (6), ve které SSRC je identifikátor synchronizace, k s je sůl a i je index SRTP paketu odesílatele IV (k s 2 ) (SSRC 2 ) (i 2 ) = (6) Šifrovací klíče encr_key a salt_key, jsou získány opět pomocí AES-CTR, přičemž jsou odvozeny z hlavního klíče master_key, viz. obr. 10. Problém je ovšem v distribuci hlavního klíče, který je distribuován během sestavení spojení, v signalizaci SIP se používá SDP (Session Description Protocol). Pokud je šifrování provedeno na úrovni SIP, není pochopitelně nutné používat silné kryptografické algoritmy pro přenášení informací uvnitř SIP, sice je to možné, ale je to zbytečné plýtvání výpočetním výkonem. Jako ukázku naprosto nevhodného přenosu důležitého klíče master_key uvádíme příklad zachycený při použití MS Messenger, pod obr. 10. Pro přenos klíče bylo použito kódování base64, což je triviální způsob, který lze dekódovat ručně s papírem, tužkou a ASCII tabulkou po ruce a navíc interoperabilita s dalšími zařízeními bude problematická. 14

15 Obr. 10. Odvození klíčů pro šifrovací schéma. Použití base64 k ochraně hesla je přípustné pouze v případě zabezpečení SIP pomocí TLS anebo S/Mime, což je vysvětleno v kapitole věnované zabezpečení SIPu. k=base64:d0c7ni7jtkf+mjjy7bfxioihnje6rrckz46gstvxele= Použití v dalším příkladu je ukázkou správné implementace ochrany master_key v nešifrovaném SIP protokolu. Pro utajení hlavního klíče během přenosu je použita kryptografická hašovací funkce HMAC-SHA1. Využívá se způsobu vyjednávání klíčů popsaného v RFC 4568 z roku 2006, jedná se o SDES (Security Descriptions for Media Streams). Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): IN IP Session Name (s): SIP Call Connection Information (c): IN IP Time Description, active time (t): 0 0 Media Description, name and address (m): audio 5004 RTP/SAVP 0 Media Attribute (a): sendrecv Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:nuc6m+o/eo+bejivqdtozo4j3pb4awzyq05z07qd Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): ptime:20 Se způsobem distribuce master_key ovšem nebyl spokojen Philip Zimmermann, který přišel s dalším vylepšením zabezpečení transportu dat v reálném čase. Philip Zimmermann již zanechal ve světě sítí důležitou stopu v oblasti šifrování ové komunikace a proslavil se protokolem PGP (PGP Pretty Good Privacy). Jelikož produkt svého intelektu poskytl v roce 1991 k volnému použití pro tehdy rodící se Internet, tak si zasloužil v USA obvinění z nelegálního vývozu kryptografického softvéru, na který se tehdy stahovalo embargo a tři roky byl vyšetřován a pronásledován FBI, než byl 15

16 zbaven tohoto absurdního obvinění. Návrhem nového zabezpečení RTP s označením ZRTP se bude zabývat další podkapitola Návrh vylepšení SRTP pomocí ZRTP ZRTP (Zimmermann Real-time Transport Protocol) neslouží jako náhrada za SRTP, ale pouze jako nadstavba pro jeho lehčí použití a implementaci. ZRTP rozšiřuje SRTP protokol o mechanismus pro počáteční dohodu na klíčích a dokáže chránit i proti útokům zvaných jako MiTM (Man in the middle). Zimmermann si všiml způsobu distribuce hlavního klíče v SRTP, ve kterém viděl slabinu a možnost prolomení šifrované komunikace třetí stranou. Zásadním rozdílem je, že výměna probíhá v dohodnuté trase pro média a zprávy jsou transportovány přes stejné porty jako RTP. Návrh ZRTP používá při dohodě na klíčích Diffie-Hellmanův algoritmus, komunikující strany si vyměňují řetězce, ze kterých je odvozen utajený šifrovací klíč, tento klíč se přitom nepřenáší, jeho získání z přenášených zpráv třetí osobou je velmi časově náročným matematickým problémem řešení diskrétního logaritmu s velkými čísly. Detekce MiTM útoků se řeší zobrazováním krátkých autentizačních řetězců SAS (Short Authentication String). ZRTP užívá tři fáze k tomu, aby zjistil a nastavil potřebné klíče a přešel na SRTP mód [voz142]: detekce, zda-li účastníci podporují ZRTP implementaci, výměna hodnot pro dohodu na klíčích s využitím DH algoritmu přepnutí do SRTP módu a úspěšné používání SRTP. V první fázi si oba ZRTP účastníci vymění mezi sebou informace o šifrování, dohodnutých klíčích a způsoby autentifizace, které budou používat. Současně ZRTP specifikace tyto šifrovací režimy: AES Counter Mode s délkou klíče 128 bit, AES Counter Mode s délkou klíče 256 bit. Pro dohodu na klíči se používá ZRTP Diffie-Hellmanův algoritmus. Pro tento algoritmus ZRTP může využívat dva různé módy: 3072 bit Diffie - Hellman hodnoty, 4096 bit Diffie - Hellman hodnoty. Jakmile se pomocí ZRTP vyjednají klíče, tak je nastavena v SRTP kryptografická souvislost a komunikace se přepne do SRTP módu. Nakonec ZRTP změní některé kontrolní informace, aby si mohl ověřit, zda celá operace proběhla úspěšně. ZRTP řeší také ochranu proti útoku MITM, kde se případný útočník snaží řídit a kontrolovat spojení mezi komunikujícími stranami. Pro zamezení tohoto útoku ZRTP používá metody Short Authentication String (SAS) a Retained Secrets (RS). Zajímavým projektem implementace ZRTP je Zfone [zph]. Philip Zimmermann udělal svým návrhem ZRTP velký krok jiným směrem, než by chtěla jakákoliv vláda, regulátor či úřední moc. Dosud bylo možné spojení odposlechnout a pokud bylo šifrováno SRTP, tak výměnu klíče odchytit a rozšifrovat, případně šifrovat spojení hop-by-hop. ZRTP zaručuje šifrování end-to-end a v případě MITM budou jeho uživatelé aspoň upozorněni, že spojení není bezpečné. ZRTP je významný krok v bezpečném přenosu médií a bude mít značný dopad zvláště v USA, kde platí od roku 2007 rozšíření CALEA (The Communications Assistance for Law Enforcement Act) i na IP telefonii. CALEA jsou pravidla právně vynucovaného nahrávání hovorů, které stanovily Ministerstvo 16

17 spravedlnosti a FBI. V USA platí CALEA pro všechny poskytovatele telefonních služeb a od roku 2007 nevyjímaje poskytovatele hlasových služeb na VoIP. I tito poskytovatelé musí v USA poskytnout asistenci při nahrávání hovorů, to platí i např. pro Skype, pokud je alespoň jeden účastník spojení v USA. 1.6 Přenos DTMF a jiných tónů přes RTP V roce 2000 bylo uvolněno RFC 2833 (RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals), které specifikuje způsob přenášení tónové volby a obecně tónů pomocí RTP protokolu. Dnes je RFC 2833 nejpoužívanější způsob pro přenos DTMF (tónové volby). Pomocí RFC 2833 lze obecně přenášet tóny, jde o způsob přenosu out-of-band, čili mimo hovorové pásmo, tóny jsou popsány určitou formou (u DTMF postačí čísla, lze i kmitočet) a příjemce je generuje z popisu. Druhý způsob přenosu in-band vyžaduje použití PCM a tóny v pásmu Hz jsou přenášeny v digitalizované podobě dané standardem ITU-T G.711. Třetím způsobem je přenos pomocí SIP metody INFO, který je používán zřídka. Pro přenos DTMF se dle výše uvedeného používají tři způsoby: in-band, v pásmu Hz pomocí PCM (G.711) out-band, pomocí RFC 2833 (modifikovaný RTP) out-band, pomocí SIP metody INFO 1.7 Audio v přenosovém řetězci od odesílatele k příjemci V řetězci cesty audia od odesílatele k příjemci nacházíme tři podstatná místa, viz. obr. 11 [voz111]: u odesílatele dochází k paketizaci audia a odeslání RTP paketů, IP sítí probíhá přenos RTP v Internetu, a nakonec u příjemce se opětovně získávají hlasové informace z RTP paketů. Místa výše uvedená jsou zdrojem zpoždění, které může zásadním způsobem ovlivnit výslednou kvalitu řeči. Komponenty zpoždění v souladu s jejich umístěním můžeme klasifikovat následovně: paketizační zpoždění (packetization) a zpoždění v kodéru (coder), zpoždění čekáním ve frontách (queuing), serializační (serialization) způsobené odesíláním přes rozhraní síťových zařízení a propagační (propagation) způsobené šířením signálu přenosovým prostředím nakonec zpoždění v mezipaměti přijímače (De-jitter) a zpoždění při zpracování přijaté informace na dekodéru (decompression). 17

18 Obr. 11. Cesta audia od odesílatele k příjemci. Při zpracování audio signálu na straně odesílatele dochází k následujícím operacím [voz111]: audio je kódováno na kodéru (např. do formátu PCM), bitový tok z kodéru je doslova naporcován do balíčků o konstantní velikosti (u PCM jsou to balíčky o velikosti 160B), k užitečné zátěži s audio informací dochází k přidání RTP hlavičky (12B) a UDP hlavičky (8B) a IP hlavičky (20B), audio je enkapsulováno napříč jednotlivými protokolovými vrstvami, nakonec dojde k vytvoření rámce (doplnění fyzických adres a kontrolního součtu) a jeho odeslání. Audio Signal Voice Encoder Packetizer RTP Packets Obr. 12. Cesta audia od odesílatele a jeho zpracování u příjemce. Při přenosu audia IP sítí dochází k časovému posunu mezi RTP pakety především vlivem jejich řazení ve frontách na směrovačích, viz. obr. 13 a vzniká jitter, což bylo již vysvětleno v kapitole 1.2. Na tento problém bylo pamatováno při návrhu standardu RFC 1889 pro RTP protokol a v hlavičce paketu je přenášena položka Timestamp vyjadřující vzorkovací značku v RTP paketu odvozenou od lineárního časovače. Díky této značce je možné jitter přesně rozpoznat a jeho vliv eliminovat. Na straně příjemce je přijatý paket zařazen do vyrovnávací mezipaměti (de-jitter buffer neboli playout buffer), tím je minimalizován vliv rozptylu zpoždění, viz. obr. 12. Následně jsou data z mezipaměti 18

19 předávány k dekódování, mezipaměť je vhodné nastavit na násobky dob trvání kódovaných hlasových fragmentů při paketizaci (např. 60 ms je nejvhodnější, neboť vyhovuje pro kódování G.711, G.729 i G ), některá zařízení umožňují samokorekci velikosti mezipaměti a pomocí adaptivních algoritmů přizpůsobují její hodnotu aktuální situaci. Obr. 13. Řazení ve frontách směrovačů. 1.8 Nároky na přenos audia v IP sítích Základními kroky předcházející odeslání hlasu v RTP paketu je kódování určitým typem kodeku a paketizace. RTP pakety jsou odesílány v dedikovaných intervalech a načasování odeslání bude záviset jednak na velikosti užitečné zátěže a jednak rychlosti výstupního toku z kodéru. Základní rovnice, která vyjadřuje časování odesílání RTP je vyjádřena jako P t= C S (7) R t [s] je časování, P [b] je velikost užitečné zátěže a kde S C R [bit/s] představuje rychlost proudu bitů z kodéru. Informace o časování jsou uloženy v RTP paketech v časových značkách (timestamp) a mohou být zpětně získány, viz. vztah (1). Na aplikační vrstvě můžeme do vztahu (8) vyjádřit jednak payload P a velikost RTP hlavičky H, což je 12B. S SAL = H RTP + PS (8) Nyní je důležité vyjádřit velikost dalších hlaviček v jednotlivých vrstvách OSI modelu, což je provedeno jako suma RTP 3 H j. Jednak se jedná o 8B na UDP, 20B na IP poté 26B v případě j = 1 Ethernetu jako velikost polí v rámci IEEE Nyní můžeme vyjádřit hodnotu BW M nárokovaného pásma RTP toků pro M hovorů jako sumu jednotlivých příspěvků velikosti rámců S Fi, které je nutné přenést v intervalu t : 19

20 BW M = S Fi M i= 1 t i (9) Pokud všechny hovory používají stejný kodek, tak (7) a (8) do vztahu (9) získáváme pro výpočet nároků všech RTP toků (10). 3 H RTP + H BW M = M C 1 j j = R 1+ P S (10) Z výše uvedené rovnice můžeme graficky vyjádřit, jak závisí nárokované pásmo na velikosti užitečné zátěže v RTP a počtu hovorů, obr. 14. V 3D zobrazení vidíme, že s klesající velikostí užitečné zátěže rostou nároky na pásmo, což je způsobeno režií hlaviček, jejichž poměr vůči klesajícímu množství přenášené informaci roste. Obr. 14. Závislost pásma na velikosti zátěže a počtu hovorů 1.9 Kodeky Kodek je zařízení nebo algoritmus, který slouží ke zmenšení jinak zbytečně velkého objemu audiovizuálních dat. Slovo kodek vzniklo složením slov kodér a dekodér, tj. zařízení jež je na jedné straně schopné data zakódovat a na druhé straně opět rozkódovat. Při použití osobního počítače je typicky vstupem kodeku zvuková karta, data získaná z mikrofonního vstupu kodér zpracuje a předá je RTP vrstvě, vzniklé protokolové datové jednotky se enkapsulují v jednotlivých vrstvách OSI modelu, až jsou nakonec vyslána příjemci. Přijatá data převede do původní podoby dekodér a pošle na audio výstup zvukové karty. Kodeky velmi často používají ztrátovou kompresi a proto dekódovaná data nejsou totožná s daty, která byla zakódována [voz142]. 20

21 Tato kapitola je věnována popisu kodeků, které se v IP telefonii nejčastěji vyskytují. Zdrojem hovorového signálu jsou řečové orgány, které se skládají z hlasivek, hrdelní dutiny, ústní dutiny, nosní dutiny, měkkého a tvrdého patra, zubů a jazyka. Zdrojem buzení této soustavy jsou plíce ve spolupráci s dýchacími svaly. Vlivem tlaku proudu vzduchu vycházejícího z plic dochází k jeho modulaci hlasivkami. Kmitočet závisí na tlaku vzduchu na svalovém napětí hlasivek. Kmitočet hlasivek je charakterizován základním tónem lidského hlasu, který tvoří základ znělých zvuků. Kmitočet základního tónu je různý u dětí, dospělých, mužů i žen, pohybuje se většinou v rozmezí 150 až 400 Hz. V klidu je štěrbina hlasivek otevřena a proud vzduchu volně prochází hlasivkami. Vytvářený zvuk je po průchodu hlasivkami formován ústní dutinou a je vyřazován do volného prostoru. Sdělení zprostředkované řečovým signálem je diskrétní, tzn. může být vyjádřeno ve tvaru posloupnosti konečného počtu symbolů. Každý jazyk má vlastní množinu těchto symbolů - fonemů, většinou 30 až 50. Lidská řeč je souvislý časově proměnný proces, z toho plyne i náročnost popisu lidské řeči a jejího modelování. Hovorový signál snímáme mikrofonem, který převádí modulovaný proud vzduchu na elektrický signál. Přístupy ke kódování jsou následující: kódování vlny (waveform coding), zpracování vychází z přeměny hovorového signálu ve tvaru elektrického signálu. Tento signál je vzorkován, kvantován a následně kódován, kódování parametrů zdroje hovorového signálu (Source Coding), a hybridní, do této kategorie patří kodeky založené na adaptivních predikčních metodách, na metodách vektorové kvantizace, složkovém kódování anebo adaptivním transformačním kódování PCM Nejznámější a nejpoužívanější kodek je PCM ITU-T G.711, výstupem kodéru je bitový tok 64 kbit/s. Kódování PCM (Pulse Code Modulation) se sestává ze tří kroků: vzorkování 8KHz, hodnoty spojitého analogového signálu ve frekvenční oblasti Hz se odečítají v diskrétním čase, kvantování, ke každému vzorku získanému v předchozím kroku se přiřadí bitová sekvence z možných diskrétních úrovní, a nakonec kódování. Vzorkuje se 8KHz a jednotlivé vzorky jsou reprezentovány osmibitovými sekvencemi. Při kvantování ovšem vzniká kvantizační zkreslení, protože každému vzorku je přiřazen jemu nejbližší kvantizační stupeň a počet hodnot je omezený. Kodér přiřadí každému kvantizačnímu stupni číselnou kódovou kombinaci a kvantovaný vzorek do ní zakóduje. Příčinou kvantizačního zkreslení je rozdíl mezi nekonečným počtem vstupních a konečným počtem výstupních hodnot, nižší hodnoty budou u lineární stupnice více zkresleny. Proto se u digitálních modulací používá komprese, výšky malých vzorků se zvýrazní a výšky velkých vzorků se ponechají tak, aby útlum kvantizačního zkreslení byl konstantní. Pomocí expanze v přijímači se vzorkům vrátí původní rozsah a poměr jednotlivých výšek. Pro zajištění rovnoměrné hodnoty odstupu kvantizačního zkreslení se v pracovním rozsahu kodéru PCM používají logaritmické křivky A-law a µ-law (Severní Amerika). Použítí logaritmické kvantizační stupnice namísto lineární nízké hodnoty vzorků se na vysílací straně zesílí a vysoké naopak zeslabí. Na přijímací straně proběhne inverzní proces. 21

22 1.9.2 ADPCM Kódování ADPCM (Adaptive Differential Pulse Code Modulation) vychází z DPCM. Kódování DPCM (Differential Pulse Code Modulation) je modifikací PCM kódování, nekódují se navzorkovaná data, ale jejich rozdíl oproti odhadnutému průběhu signálu, průběh signálu je možné částečně odhadnout, navzorkovaný průběh a odhadnutý průběh jsou si podobné, výsledný rozdíl má mnohem menší dynamický rozsah a je možné ho zakódovat pomocí menšího počtu bitů, tedy množství přenášených dat se snižuje. ADPCM je vylepšeno tak, že generátor srovnávacího průběhu je adaptivní a přizpůsobuje se konkrétní řeči, která se kóduje. Výsledkem je ještě menší dynamický rozsah než v případě DPCM a tedy opět menší počet bitů nutný k zakódování. Kromě toho se mění i vlastnosti kvantifikace pro charakteristiku konkrétní řeči. Nejznámějším představitelem ADPCM je ITU-T G.726 (32 kbit/s), ale jsou možné i jiné rychlosti výstupního toku z kodéru v závislosti na použitém adaptivním algoritmu, G.726 a G.727 umožňují 40, 32, 24 a 16 kbit/s. Vůbec prvním standardem ADPCM bylo doporučení ITU-T G.721 pro 32 kbit/s. MOS 4,2 4,1 G.711 4,0 3,9 3,8 3,7 G.729 G.723.1/6,3 G.729A G.726 3,6 G.723.1/5,3 G.728 3,5 3,4 GSM Rychlost kodeku[kbit/s] Obr. 15. MOS v závislosti na bitové rychlosti kodeků LPC LPC (Linear Predictive Coding) je způsob kódování založený na úplně jiném principu než PCM nebo ADPCM, ty vycházely z kvantifikace průběhu signálu. Metoda LPC vychází naopak ze znalostí o mluvícím traktu (tj. hlasivkách a krku). Tato metoda se snaží vytvořit model hlasového ústrojí člověka. LPC využívá předpokladu že hlasový signál je generován bzučákem na konci trubky, štěrbina mezi hlasivkami produkuje bzukot, který je charakterizován hlasitostí a frekvencí. Mluvící ústrojí (krk, ústa) vytváří trubku, která je charakterizována svými rezonancemi nazývanými formanty. LPC analyzuje řeč aproximováním formantů, odstraněním jejich působení z hlasového signálu a odhadem intenzity a frekvence zbývajícího signálu, který je generován hlasivkami. Proces odstranění formantů se nazývá inverzní filtrování. LPC vytváří signál řeči obráceným procesem, vygeneruje se signál s příslušnou hlasitostí a frekvencí a z formantů se vytvoří filtr. Tímto filtrem se potom vygenerovaný 22

23 signál zpracuje a výsledkem je signál podobný původnímu signálu řeči. Protože vstupní signál se mění v závislosti na čase, je nutné tento proces opakovat pro kratší časové intervaly, tzv. rámce. Pro rozumnou kvalitu výsledné řeči se používá 30 až 50 rámců za vteřinu. Představitelem je LPC kodek s výstupním tokem 4,8 kbit/s nebo kodek LPC-10 s tokem 2,4 kbit/s CELP Kódování CELP (Code Excited Linear Prediction) zásadně vylepšuje LPC. Problém metody LPC je v tom, že to, co zbude po odfiltrování formantů, není pouze signál bzučáku. Důvodem je, že v řeči se vyskytují složky reprezentující třeba sykot. Takovéto zvuky nebudou jednoduchým LPC kodekem správně aproximovány. Nepřesnosti při odhadu formantů způsobí, že více informací o signálu zůstane v reziduu (zbytek po odfiltrování formantů). To platí pro zvuky které neodpovídají jednoduchému LPC modelu, platí to například pro zvuky generované různou pozicí jazyka atd. Tedy reziduum obsahuje důležité informace o tom, jak má řeč znít, tyto informace se zakódováním pomocí LPC ztratí, protože reziduum se zakóduje pouze pomocí dvou parametrů, frekvence a amplitudy signálu. Vzniká tedy otázka, jak reziduum zakódovat lépe tak, aby se příliš nezvýšil nárok na šířku pásma a tyto důležité informace se přitom neztratily. Jednou z nejúčinnějších metod je použití codebooku. Kódová kniha je tabulka obsahující typické průběhy rezidua. Kodér potom porovnává průběh rezidua s hodnotami v tabulce a použije tu, která odpovídá nejvíc, index této hodnoty z tabulky se potom přenáší. Druhá strana má stejnou tabulku a po příjmu indexu dokáže průběh rezidua z tabulky obnovit, toto reziduum potom slouží jako budič pro filtr aproximující formanty. Výsledkem je lepší aproximace hlasového signálu než v případě jednodušší metody LPC. Tato metoda se nazývá Code Excited Linear Prediction, zkratka CELP. Aby metoda CELP správně fungovala, tabulka obsahující typické průběhy rezidua musí být velmi rozsáhlá, pokud je ale tabulka velká, bude vyhledávání v tabulce trvat rovněž velmi dlouho. Dalším problémem je, že tabulka by musela obsahovat vzorky pro různě vysoký hlas, taková tabulka by však byla extrémně rozsáhlá. Tento problém se řeší vytvořením dvou tabulek. Jedna tabulka je vytvořená při tvorbě kodeku a obsahuje vzorky pro právě jednu výšku hlasu. Druhá tabulka je adaptivní, ze začátku je prázdná a průběžně se plní předešlými vzorky rezidua zpožděnými o určitou hodnotu. Právě hodnota zpoždění určuje výšku hlasu, popsaný algoritmus poskytuje dobrou kvalitu přenášené řeči už při šířce pásma 4,8 kbit/s. Typickými představiteli jsou ACELP dle G s tokem 5,3 kbit/s, CS-ACELP dle G.729 s tokem 8kbit/s anebo LD-CELP dle G.728 s tokem 16 kbit/s. Tab. 1 Typ kódování, MOS, rychlost a náročnost na výpočetní výkon. 23

24 Mezi modifikace CELP patří ACELP (Algebraic Code Excited Linear Prediction), LD-CELP (Low Delay Code Excited Linear Prediction) a CS-ACELP (Conjugate Structure Algebraic Linear Code Prediction). Následně si popíšeme nejpoužívanější kodeky, ty jsou specifikovány v doporučeních ITU-T: G.711 je základní kodek PCM, který se používá i v klasické telefonní síti. Kvalita přenášeného hlasu je totožná s kvalitou hlasu při běžném telefonním hovoru, MOS má hodnotu 4,2, rámec trvá 0,125 ms; G používá buď kódování MP-MLP nebo ACELP. První typ kódování vyžaduje šířku pásma 6,3 kbit/s, druhý typ 5,3 kbit/s. Jeden rámec obsahuje úsek trvající 30 ms a MOS skóre je 3,9 při použití kódování MP-MLQ a 3,65 při použití ACELP; G.726 kodek používá kódování ADPCM, potřebná šířka pásma je 16, 24, 32 a 40 kbit/s. Kodek může zpracovávat bloky různé délky podle toho, jak velké zpoždění je požadováno, pro 32 kbit/s se uvádí MOS=3,85; G.728 používá kódování LD-CELP. Potřebná šířka pásma je 16 kbit/s, MOS skóre je přibližně 3,6; G.729 Použité kódování je CS-ACELP - Conjugate Structure Algebraic Code Excited Linear Prediction. Rámec trvá 10 ms a potřebná šířka pásma je 8 kbit/s, MOS je hodnocen 3,92; GSM kodek, šířka pásma je 13 kbit/s (Full Rate GSM FR). Kodek je založen na kódování LPC. Dalším rozšířením v roce 1997 byl kodek GSM EFR (Enhanced Fulll Rate) s rychlostí 12,2 kbit/s a rámcem 20 ms (obsahuje 244 bitů). V roce 1998 přišlo další kódovací schéma, a to AMR kodek (Adaptive Multi-Rate), který je používán i v UMTS. AMR používá ACELP techniku kódování a rychlosti se pohybují od 4,75 (AMR 4,75) do 12,2 kbit/s (AMR 12,2). AMR 12,2 je kompatibilní s GSM EFR. ilbc - internet Low Bit Rate Codec, tento kodek byl vyvinut firmou Global IP Sound, potřebná šířka pásma je kbit/ /s, rámec obsahuje úsek trvající 30 ms. Kodek umožňuje elegantní snížení kvality přenášeného signálu v případě zpoždění nebo ztráty paketů. Použitý algoritmus je Block Independent Linear Predictive Coding. Každý rámec je komprimován na 399 bitů, které se potom přenáší. V tabulce 2 můžeme vidět srovnání nejpoužívanějších kodeků, ve čtvrtém sloupci tabulky je uvedena typické časování odesílání paketů, v dalším sloupci je doba trvání rámce a po sečtení s look-ahead (dopředným výpočetním zpožděním u kodeků pracujících s predikcí) dostaneme celkové minimální zpoždění, které lze u kodeku teoreticky dosáhnout. Tab. 2 Typ kódování, rychlost, typická paketizace, rámec a zpoždění. V posledním řádku je použit kodek G.729A, což je dodatek ke kodeku G.729, tento dodatek implementuje G.729 s nižší výpočetní náročností, G.729A vyžaduje pouze 111 MIPS, klesá ale MOS 24

25 na 3,6. Dalším používaným dodatkem G.729 je implementace detekce ticha VAD s označením G.729B, často najdeme i kodek s oběma dodatky s označením G.729AB. Implementace VAD do G je označována jako G.723.1A. VAD (Voice Activity Detection) nebo taky někdy označována jako SS (Silence Suppression) je funkce potlačení ticha, ticho během hovoru se nepřenáší, neboť nenese žádnou informaci. V průměrném hovoru ticho tvoří 40-60% celkové doby spojení. Během ticha se tedy nebudou přenášet RTP pakety a u příjemce se zapne generování šumu CNG (Comfort Noice Generator). Princip aktivace a deaktivace SS je založena na překročení prahových úrovní odstupu signálu od šumu, pokud se detekuje úroveň signálu setrvávající stanovený čas pod či nad prahovou úrovní, tak se aktivuje či deaktivuje SS. V praxi je ovšem zkušenost taková, že funkce VAD může způsobovat ořezávání prvních slabik slov po odmlkách, jelikož aktivace je záležitostí typicky cca 20 ms, funkce VAD proto není používána při broadband konektivitě. Cisco IOS má pro aktivaci a deaktivaci jednoduché příkazy, a to VAD a no VAD, pokud ovšem není použita G.729B či G.723.1, potom je VAD součástí kodeku a funkce se nedá řídit. 25

26 2 Protokol SIP SIP (Session Initiation Protocol) je protokolem pro sestavení, modifikaci a terminaci obecné relace v Internetu a nejčastěji je používán pro audio. Byl vyvíjen od roku 1996 pracovní skupinou MMUSIC (Multiparty Multimedia Session Control) v rámci IETF (Internet Engineering Task Force). V roce 1999 byl předložen ve formě navrhovaného standardu (Proposed Standard) v RFC Téhož roku na popud IETF vznikla nová pracovní skupina, nazvaná příznačně SIP, která převzala vývoj hlavního jádra protokolu. Její práce v květnu roku 2002 vyústila v nový standard RFC Dnes existuje kolem stovky dalších RFC, které se přímo týkají SIPu nebo na něj navazují, ať už jde přímo o nové metody komunikace anebo např. rozšíření položek v hlavičkách. 2.1 Základní popis protokolu SIP SIP pracuje na aplikační vrstvě, byl navržen tak, aby byl snadno implementovatelný, rozšiřitelný a dostatečně flexibilní. Protokol je užíván pro sestavení, modifikaci a ukončení spojení s jedním nebo více účastníky, ale není jediným protokolem, který je potřebný pro audiovizuální komunikaci, ve spojení se SIPem jsou nejčastěji používány ještě dva další protokoly, RTP (Real-Time Protocol) pro přenos vlastního obsahu a SDP (Session Description Protocol) pro popis přenášeného obsahu [sin1], [sin2]. SIP je end-to-end orientovaný signalizační protokol, což znamená, že veškerá logika je uložená v koncových zařízeních, koncová zařízení znají i jednotlivé stavy komunikace, chování lze popsat stavovým diagramem, ve kterém se v rámci dialogu (spojení) probíhají jednotlivé transakce (žádosti a odpovědi). Tím je zvýšena odolnost komunikace proti chybám. Cena, která se musí zaplatit za decentralizaci a dostupnost služby, je vyšší režie hlaviček zpráv. Nepochybně stojí za zmínku, že end-to-end koncept SIPu je zásadně odlišný od klasického řešení PSTN (Public Switched Telephone Network), kde logika je uložena v síti a koncová zařízení jsou primitivní. Jedním z cílů SIPu je zajistit stejnou funkcionalitu jakou mají klasické PSTN, ale end-to-end návrh umožňuje v SIPu podstatně snadnější implementaci nových služeb a některé z nich mohou být jen stěží nasazeny v klasických PSTN. SIP je textově orientovaný protokol z rysy podobnými HTTP a SMTP protokolu. HTTP a SMTP jsou nepochybně nejúspěšnějšími a nejpoužívanějšími protokoly v Internetu, volba osvědčeného modelu komunikace zaručuje SIPu robustnost a nadčasovost. Klient posílá požadavky na server, který zasílá odpovědi obdobně jako u HTTP, v hlavičkách najdeme položky From, To či Subject jako u mailové komunikace pomocí SMTP. SIP entita je vázána k doméně obsluhovanou SIP Proxy a 26

27 mezidoménová komunikace je tedy mezi různými SIP Proxy, výjimkou je multidoménová SIP Proxy. SIP entity jsou identifikovány použitím SIP URI (Uniform Resource Identifier), řekli bychom jednoduše jmennými identifikátory, jejich obecný tvar je uveden níže. SIP URI se skládá jednak z části username identifikující uživatele a jednak z host vztažené k doméně neboli hostiteli, který poskytuje uživateli určité prostředky k zajištění komunikace, následuje pole password jehož použití není doporučeno. Port je standardně 5060 na UDP, případné parametry se oddělují středníkem a pokud je potřebné přímo do URI zadat i nějaké parametry hlavičky, tak se uvádějí za otazníkem. Většinou ale uvidíme SIP URI v podobě jednoduché konstrukce sip:user@host, což nápadně připomíná ovou adresu. Příkladem SIP URI může být: sip:voznak@cesnet.cz sip: @cesnet.cz SIP tedy pracuje se jmennými identifikátory a číslo můžeme přeložit na URI pomocí DNS, kde jsou k tomu určeny záznamy NAPTR (Name Authority Pointer) a technika mapování URI na tel. čísla (standard ITU-T E.164) se nazývá ENUM (E.164 NUmber Mapping). URI je obecně prezentováno řetězcem znaků, jehož cílem je umožnit interakci se zdrojem pomocí určitého protokolu, tzn. musí nutně obsahovat název schématu (protokol) a adresu zdroje, za schématem následuje dvojtečka. URI dle RFC 3986 je definováno následovně: <scheme name> : <hierarchical part> [? <query> ] [ # <fragment> ] Příklady pro scheme name jsou: sip, sips, h323, tel, http, https, ftp, imap, ldap, mailto, telnet, im, pop, news, atd... Hierarchical part nese informaci o identifikaci zdroje, obvykle začíná dvojitým lomítkem // a následuje např.: domain name, IP address, username:password@, user@host. Pokud je specifikováno číslo portu, tak se začíná znakem :, např. :5060, :8080, :8085, atd... Query je nepovinná část, která obsahuje doplňující informace, obecná syntaxe není definována, obvykle se objevuje ve formě <key>=<value>, kde jednotlivé hodnoty jsou odděleny znakem &, např. key1=value1&key2=value2&key3=value3. Fragment je nepovinná část umožňující nepřímo identifikovat další zdroj a začíná znakem #. SIP adresa je vázána k doméně, a proto následuje několik základních informací k DNS. Jména domén jsou vyjádřena pomocí adres 32-bitových (IPv4) A záznam nebo 128 bitových (IPv6) - AAAA záznam. Systém DNS zajišťuje překlad doménových jmen na IP adresy, stejně tak zajišťuje zpětný překlad IP adresy na doménové jméno - PTR záznam. Doménová jména jsou vytvářena hierarchicky, 27

28 stejně jako jsou hierarchicky organizovány DNS servery. Prostor doménových jmen tvoří strom, jeho kořenem je kořenová doména, která se zapisuje jako samotná tečka, pod ní se v hierarchii nacházejí tzv. domény nejvyšší úrovně (Top-Level Domain, TLD). Při vyhledávání v DNS provádějí klienti obvykle dopředné vyhledávání, což je hledání založené na názvu DNS jiného počítače, který je uložen v záznamu o prostředku hostitele (A). U odpovědi na tento typ dotazu se jako údaj o prostředku očekává adresa IP. Systém DNS poskytuje rovněž zpětné vyhledávání, při kterém klienti používají známou adresu IP a hledají název počítače na základě jeho adresy, pro tento účel byla ve standardech DNS definována speciální doména in-addr.arpa. V rámci domény in-addr.arpa jsou pomocí opačného pořadí čísel adres IP v desítkovém formátu s tečkou vytvořeny subdomény, které tvoří obor názvů pro zpětné dotazy. Stromová struktura domény inaddr.arpa integrovaná do systému DNS vyžaduje definování dalšího typu záznamu o prostředku - záznamu o prostředku ukazatele (PTR). Tento záznam o prostředku vytváří v zóně zpětného vyhledávání mapování, které obvykle koresponduje se záznamem prostředku hostitele (A) pro název počítače DNS hostitele v jeho zóně dopředného vyhledávání. Strom je administrativně rozdělen rozdělit do zón, které spravují jednotliví správci. Obsah zóny (domény či několika domén) je uložen v tzv. zónovém souboru, skládá se z jednotlivých záznamů (resource records, RR) obsahujících dílčí informace. Zónový soubor vždy musí začínat záznamem typu SOA. Nejčastěji se používají následující typy záznamů: A (address record) obsahuje IPv4 adresu přiřazenou danému jménu, například neco.vsb.cz má IP adresu , zónový soubor pro doménu vsb.cz bude obsahovat záznam, neco IN A , CNAME (canonical name record) je alias - jiné jméno pro jméno již zavedené, jeho definice pomocí přezdívky umožňuje jej později snadno přestěhovat na jiný počítač, např. neco.vsb.cz má sloužit zároveň jako nic.vsb.cz, v zónovém souboru přibude nic IN CNAME neco, SOA (start of authority record) je zahajující záznam zónového souboru. Obsahuje jméno primárního serveru, adresu elektronické pošty jejího správce a další údaje (serial, refresh, retry, expire a TTL). 2.2 Prvky SIP řešení Ačkoliv v nejjednodušší konfiguraci je možné použít dva UA posílající si navzájem SIP zprávy, typická SIP síť bude obsahovat více než jeden typ prvků User Agent a Back to Back User Agent Základními SIP prvky jsou: SIP user agent (UA), který je prezentován koncovým terminálem, SIP proxy, registrar, redirect a location servery, často označováno jako SIP server. Jednotlivé servery jsou většinou stavěny jako logické části SIP serveru, jelikož z pohledu nákladů je efektivnější jejich provoz na jednom společném HW, každopádně filozofie návrhu SIP architektury 28

29 umožňuje jejich plnou dekompozici, což je výhodou pro velká řešení, distribuovaná architektura vede ke zvýšení robustnosti. Koncové body, kde vzniká a je terminována SIP relace, jsou nazývány jako user agents (UA). UA obvykle jsou představovány koncovými terminály ve formě HW SIP telefonu nebo aplikace, SIP UA mohou být IP telefony, Smartphones, PSTN brány (GW), IVR systémy, atd. UA jsou vztaženi k User Agent Server (UAS) a User Agent Client (UAC). UAS a UAC jsou pouze logické entity, každý UA obsahuje UAC a UAS: UAC je část vysílající požadavky a přijímající odpovědi, UAS je část přijímající požadavky a odesílající odpovědi. Žádost a odpověď jsou dva základní typy SIP zpráv. Protože koncové zařízení téměř vždy obsahuje UAC a UAS, tak používáme pouze označení UA namísto UAC a UAS. Například, volající UA funguje jako UAC, když odesílá zprávu INVITE (požadavek na sestavení spojení) a přijímá odpověď na požadavek. Volaný UA se chová jako UAS, když obdrží zprávu INVITE a odesílá odpověď. Ale tato situace se mění, když volaný se rozhodne zavěsit a odesílá se zpráva BYE a ukončuje spojení. V tomto případě se volající chová jako UAC a volaný jako UAS. INVITE INVITE Obr. 16. Rozeslání INVITE více příjemcům. Obr. 16 ukazuje tři UA a SIP Proxy. UAC inicializuje spojení odesláním žádosti INVITE na SIP Proxy, ta je přeposlána adresátovi, jelikož je příjemců více, tak dochází k rozeslání na dva UAS (forking). Na prvním z nich, který přijme volání, tak je sestaveno spojení. Při ukončení spojení odesílá UAC zprávu BYE přímo na UAS. B2BUA je speciální typ UA vkládaného do cesty a vytvářejícího dvě spojení, na B2BUA je ukončeno jedno spojení a sestaveno nové na cíl, B2BUA zprávy a odpovědi narozdíl od SIP Proxy nepřeposílá, ale vytváří nové směrem k oběma komunikujícím stranám. Koncový terminál ovšem nerozezná rozdíl mezi voláním přes B2BUA a SIP Proxy. B2BUA má rozsáhlejší možnosti než SIP Proxy, ovšem výkon vyjádřený počet obsloužených požadavků na spojení za jednotku času je podstatně menší oproti klasickým SIP Proxy, což vyplývá z rozdílného přístupu k obsluze SIP zpráv [voz188] a [voz191]. 29

30 Použití B2BUA je poměrně časté, typickým příkladem je ASTERISK, který má rozsáhlé možnosti doplňkových služeb pro koncové uživatele, je používán jako pobočková ústředna do velikosti řádově tisíců uživatelů. Jako představitele klasické SIP PROXY si uveďme KAMAILIO, řešení je vhodné i pro velké poskytovatele s dimenzování až pro stovky tisíc uživatelů [voz133], [voz146] a [voz191] SIP Proxy Server SIP umožňuje vytvořit infrastrukturu sítě hostitelů nazývaných jako SIP Proxy servery. Koncové terminály UA mohou odesílat zprávy na SIP Proxy server. SIP Proxy servery jsou důležité entity infrastruktury. Zajišťují směrování žádostí o spojení dle aktuálního umístění adresáta, mohou provádět autentizaci, účtování a realizovat doplňkové služby (např. přesměrování). Nejdůležitější úloha SIP Proxy serveru je směrovat žádosti o sestavení spojení blíž k volanému. Při inicializaci sestavení spojení je základní úlohou SIP Proxy nalézt další SIP Proxy, která obslouží požadavek a na tuto danou zprávu odeslat. K nalezení SIP proxy pro next hop může kromě statického záznamu i vyhledávat v DNS. Požadavek na sestavení spojení je tedy směrován přes jednotlivé SIP Proxy a volaný nakonec žádost akceptuje nebo odmítne. Máme dva základní typy SIP proxy serverů: stateless (bezestavový), stateful (a s informací o stavech). Kromě SIP Proxy serveru máme následující servery: Redirect Server slouží pro přesměrování, vrací nové URI uživatele, Registrar Server přijímá požadavky na registraci, aktualizuje lokalizační databázi a mapuje logickou URI uživatele (user URI) na fyzickou URI zařízení (device URI), user URI je taky označována jako AOR (Address of Record), Location Server je úložištěm informací o umístění uživatelů a SIP Proxies, posledním případem je B2BUA, který je používán v režimu SIP serveru. Stateless SIP Proxy jsou poměrně jednoduché a pouze přeposílají zprávy nezávisle na jejich vzájemné vazby. Zprávy jsou většinou v pořádku z hlediska souslednosti a významu v signalizaci, bezestavové SIP Proxy servery neumí kontrolovat jejich výměnu z hlediska smysluplnosti, nezachytí replikaci zpráv, detekce nekonečných smyček jim trvá déle, nejsou srovnatelné se stateless SIP Proxy do rozsahu možností, neumí např. větvení či přesměrování. Stateless SIP Proxy servery jsou jednoduché, ale rychlejší než Stateful SIP Proxy. Využití mají jako balanční servery, pro jednoduché překládání zpráv a směrování. Stateful SIP Proxy servery jsou mnohem komplexnější. Po přijetí požadavku, server vytvoří záznam stavu a drží důležité informace, dokud nedojde k ukončení transakce či dialogu, dělí se tak na dva typy. transakční, drží stavy k žádosti (dokud není definitivně vyřízena), dialogové, drží stavy dialogu (dokud neskončí celé spojení). Některé transakce, zejména vytvořené zprávou INVITE, mohou trvat poměrně dlouho (dokud volaný nevyzvedne nebo se neukončí volání). Protože proxy servery s informací o stavech musí udržovat stav po celou dobu dané transakce, je jejich výkon limitován. 30

31 Schopnost přiřazovat SIP zprávy do transakcí dává serveru některé zajímavé vlastnosti, například může provádět větvení, na přijetí jedné zprávy, může být odesláno více zpráv (uživatel má např. vícenásobnou registraci). Stateful SIP Proxy server může zachytit opakování zpráv, protože ze stavu transakce ví, jestli byla stejná zpráva už přijata (Stateless Sip Proxy nemůže ověřovat, protože nedrží stav). Stateful SIP Proxy server může aplikovat komplikovanější metody nalezení uživatele, například možnost zkusit volat na telefon v zaměstnání a v případě neohlášení volání přesměrovat na mobilní telefon, zatímco stateless SIP Proxy žádost přepošle a už o nemá k ní informacemi, čili nemůže tedy provést např. přesměrování po čase. Většina SIP Proxy serverů je stateful, často nabízejí generování záznamů o spojeních, větvení, některé druhy podporují i NAT. SIP je připraven na situaci, kdy každá jednotka (např. firma) bude mít vlastní SIP proxy server, který je užíván všemi UA v rámci administrované jednotky [voz90]. Předpokládejme, že jsou dvě firmy A a B a každá z nich má svůj Proxy server. Obr. 17 ukazuje situaci, kdy Alice z firmy A inicializuje spojení na Boba z firmy B. Uživatel Alice volá Boba a použije URI adresu sip:bob@b.com. UA neví, kam má poslat žádost o sestavení spojení, ale je nakonfigurován tak, že veškerý odchozí provoz (outbound traffic) posílá na SIP Proxy server své firmy A s adresou proxy.a.com. Proxy server zjistí, že uživatel sip:bob@b.com je v jiné firmě a tak vyhledá odpovídající SIP Proxy server, kam pošle žádost. Odpovídajícím serverem je proxy.b.com a je zadán staticky v proxy serveru firmy A anebo bude Proxy vyhledán pomocí záznamu DNS SRV, kterým je zjištěno, kdo poskytuje službu SIP v doméně b.com. Žádost tedy dorazí na proxy.b.com. SIP Proxy ví, že Bob je aktuálně ve své kanceláři a dosažitelný na telefonu na svém stole, jež má IP adresu , takže SIP Proxy přeposílá žádost INVITE. #1 INVITE #5 INVITE Obr. 17. Sestavení spojení přes dvě SIP Proxy. 31

32 2.2.3 SIP Registrar Server Zmínili jsme se, že SIP Proxy na proxy.b.com zná současnou polohu Boba, ale neřekli jsme, jak Proxy může lokalizovat uživatele. Bobův UA (SIP telefon) musí být registrován na SIP Registrar serveru. Registrar server je speciální část SIP serveru, která přijímá od uživatelů požadavky na registraci, tím získává informaci o jejich aktuální poloze (IP adresa, port a uživatelské jméno) a ukládá informaci do lokalizační databáze (location database). Obr. 18. Průběh registrace. V lokalizační databázi v našem případě došlo k namapování adresy User URI sip:bob@b.com k adrese Device URI sip:bob@ :5060. Lokalizační databáze je pak užívána Proxy serverem. Když inbound Proxy server obdrží žádost pro sip:bob@b.com, vyhledá v lokalizační databázi záznam sip:bob@ :5060 a na danou IP adresu pošle žádost. Registrar server je velmi často pouze jako logická část SIP serveru, jelikož je těsně svázán s Proxy serverem. Obr. 18 znázorňuje typickou SIP registraci. Zpráva REGISTER je vyslána do Registrar serveru a obsahuje adresu záznamu User URI sip:bob@biloxi.com a kontaktní adresu Device URI sip:bob@ :5060, kde je IP adresa telefonu. Registrar zaznamenává tyto informace do lokalizační databáze. Pokud registrace proběhla správně, tak Registrar server posílá odpověď 200 OK a proces registrace je ukončen. Každá registrace má limitovanou dobu platnosti, doba platnosti je v hlavičce kontaktu (Expires), do té doby musí UA obnovit registraci, jinak bude nedostupný SIP Redirect Server Jak již bylo řečeno, SIP URI je vázána k doméně, ta je nezávislá na síťové topologii, a například SIP server v doméně vsb.cz můžu používat odkudkoliv. Může být ovšem někdy nepraktické jej používat, pokud jsem v doméně cvut.cz a nabízí se mi možnost využívat jejich SIP Proxy, v tom případě by ale někdo měl vědět o mém novém SIP URI a zajistit přesměrování, viz. obr. 64. Entita, která přijímá požadavek a odesílá zpět odpověď obsahující lokalizaci konkrétního uživatele se nazývá Redirect server. Redirect server přijímá požadavky a vyhledává zamýšlené příjemce v lokalizační databázi 32

33 vytvořené registrar serverem. Následně vytváří seznam aktuálních lokalizací uživatele a posílá jej odesílateli požadavku v odpovědi zařazené do třídy 3xx. Odesílatel požadavku poté dostává seznam destinací a odesílá další požadavky přímo na ně. Obr. 19 ukazuje způsob přesměrování, Alice volá Boba a odeslaný INVITE přijme Redirect server, který zjistí, že Bob má nový kontakt a vrací odpověď 302 Moved Temporarily, ve které do pole contact zapíše SIP URI, na kterou je Bob přesměrován. Alice zasílá nový INVITE na URI z kontaktu předaného Redirect serverem a INVITE již s novou požadovanou URI se dostává na SIP Proxy sip.cvut.cz, kde už o Bobovi vědí a umí INVITE na něj přeposlat. #1 INVITE sip:bob@vsb.cz #2302Moved Temporarily Obr. 19. Průběh přesměrování. 2.3 SIP žádosti a odpovědi Komunikace v SIPu je tvořena zprávami, které jsou obvykle přenášeny v samostatných UDP datagramech. Každá zpráva obsahuje hlavičku zprávy (header) a může obsahovat vlastní tělo zprávy s popisem médií (body, většinou SDP), hlavička a tělo jsou odděleny volným řádkem (CRLF). generic-message = start-line *header fields CRLF [ message-body ] V prvním řádku zprávy je identifikován její typ. Známe dva typy zpráv, jednak žádost (neboli metoda) a jednak odpověď Základní popis SIP hlavičky typické žádosti Žádosti jsou obvykle užívány k registraci uživatele, sestavení, modifikaci či ukončení spojení anebo může jít o další služby (presence, instant messaging). Odpovědi jsou užívány k potvrzení přijetí žádosti a její vyřízení, obsahují konkrétní status. Typická SIP žádost vypadá následovně: 33

34 Request-Line: INVITE SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK9ec4c0248acd d7;rport From: "SJphone" To: Contact: Call-ID: C EB9B1443F8B448CC2830x9ec4c020 CSeq: 2 INVITE Max-Forwards: 70 User-Agent: SJphone/ a (SJ Labs) Content-Length: 321 Content-Type: application/sdp (v): 0 (o): IN IP (s): SJphone (c): IN IP (t): 0 0 (m): audio RTP/AVP (a): rtpmap:18 G729/8000 (a): rtpmap:3 GSM/8000 (a): rtpmap:8 PCMA/8000 (a): rtpmap:0 PCMU/8000 První řádek nám říká, že se jedná o zprávu INVITE, jež je užívána k sestavení spojení. URI na prvním řádku sip: @asterisk.vsb.cz se nazývá Request URI a obsahuje URI dalšího skoku zprávy (next hop, směruje se dle RURI). V tomto případě bude hostitelem asterisk.vsb.cz a hledá se uživatel SIP žádost obsahuje v hlavičce jedno nebo více polí Via, jež jsou použity k záznamu cesty žádosti. Následně jsou užívány ke směrování SIP odpovědí přesně takovou cestou, jakou byly odeslány. Naše INVITE zpráva obsahuje jedno pole Via, to bylo vytvořeno UA, který odeslal žádost. Z pole Via můžeme říct, že odpověď bude doručena UA na IP adresu a port Pole hlavičky From a To identifikuje iniciátora volání (volající) a příjemce (volaného). Pole From obsahuje parametr tag, který slouží jako identifikátor dialogu a bude popsán později. Pole hlavičky Call-ID je identifikátor dialogu a jeho cílem je identifikovat zprávy náležející jednomu volání. Takovéto zprávy mají stejný identifikátor Call-ID. V rámci dialogu jsou jednotlivé žádosti očíslovány v poli CSeq. Protože žádosti mohou být odeslány nespolehlivým přenosem, může docházet k opakováním a pořadové číslo je nutné, aby příjemce mohl detekovat opakování a správně tak selektovat žádosti. V SIP hlavičce je dále pole Contact obsahující IP adresu a port, na kterém odesílatel očekává další žádosti odesílané volaným, obě strany si vymění své kontakty v žádosti a odpovědi a pokud bude chtít jedna ze stran poslat další požadavek, např. ukončení spojení BYE, tak nemusí posílat žádost na SIP Proxy, ale pošle ji přímo. Samozřejmě že je možnost ovlivnit i cestu dalších žádostí v dialogu, ale to si vysvětlíme v dalších kapitolách. Hlavička zprávy je oddělena od těla zprávy prázdným řádkem. Tělo zprávy žádosti INVITE obsahuje popis médií vyhovující odesílateli a kódované v SDP. Z SDP jsme se dozvěděli, kdo poslal nabídku SDP a na které IP má být tok médií ukončen. A co se týče vlastní nabídky, tak ta obsahuje čtyři kodeky seřazené dle preferencí G.729, GSM, PCM (A-law) a PCM (µlaw). 34

35 2.3.2 SIP metody Žádosti neboli metody jsou obvykle užívány k inicializaci procedury (sestavení, aktualizaci či ukončení spojení). V jádru SIP protokolu je dle RFC 3261 specifikováno šest metod, které jsou následující: INVITE je žádost o inicializaci spojení nebo změnu parametrů již probíhajícího spojení (re- INVITE); ACK je metoda potvrzující přijetí konečné odpovědi na žádost INVITE. Sestavení relace používá 3-way hand-shaking, volaný periodicky opakuje odpověď (např. 200 OK), dokud nepřijme ACK, což indikuje, že odpověď byla doručena. Metoda ACK má řadu výjimek v pravidlech gramatice SIPu, které budou zmíněny později; BYE je zpráva užívána k ukončení sestaveného spojení; CANCEL se používá ke zrušení sestavovaného spojení, když není sestaven dialog, volaný ještě nepotvrdil konečnou odpovědí žádost INVITE a volající chce zrušit sestavování spojení; REGISTER je žádost registrace anebo odregistrování uživatele, sváže se logická jmenná adresa uživatele s jeho fyzickým umístěním (IP adresa a port), konkrétně jde o položky FROM a CONTACT ze SIP hlavičky. Registrace jsou časově limitovány a je nutné je periodicky obnovovat; OPTIONS je speciální typ metody k zjištění vlastností SIP zařízení, má stejnou strukturu jako INVITE, ale spojení není sestavováno, pouze se přijme odpověď. Využívá se např. nejen ke zjištění podporovaných funkcí, ale SIP Proxy může periodickými dotazy zjišťovat mezi registracemi, zda SIP UA odpovídá a je dostupný anebo naopak SIP UA může periodicky posílat Options přes NAT k udržení záznamu překladu a tím pádem průchodnosti zvenčí. Kromě výše vysvětlených šesti základních metod existují i další žádosti, které byly definovány dodatečně v některých dalších RFC, viz. níže. Kupříkladu vyžadujeme-li funkcionalitu spolehlivé doručování dočasných odpovědí (PRACK), tak je nutné zjistit, zda konkrétní zařízení podporuje RFC Pro základní telefonii postačí RFC 3261, pro přehled si uvedeme seznam metod užívaných SIPem s odkazem na konkrétní RFC: sestavení relace INVITE RFC 3261, potvrzení na INVITE ACK RFC 3261, ukončení existující relace BYE RFC 3261, zrušení dosud nevyřízené žádosti CANCEL RFC 3261, registrace (svázáno s URI) REGISTER RFC 3261, získání schopností entity OPTIONS RFC 3261, Další metody, které nejsou v RFC 3261, jsou následující: přenos informací během relace INFO RFC 2976, potvrzení dočasné (1xx) odpovědi PRACK RFC 3262, přihlášení k upozornění na událost SUBSCRIBE RFC 3265, doručení o události NOTIFY RFC 3265, aktualizace stavu relace UPDATE RFC 3311, zprávy pro instant messaging MESSAGE RFC 3428, požadavek jiného UA k relaci REFER RFC 3515, aktualizace prezence PUBLISH RFC

36 2.3.3 SIP odpovědi Jestliže UAS obdrží žádost, tak na žádost odesílá odpověď. Každá žádost musí být zodpovězena, výjimkou je metoda ACK, což je žádost, která má význam potvrzení doručení odpovědi na INVITE. Naproti tomu PRACK (Provisional Acknowledgement) se potvrzuje. Odpovědi jsou svou strukturou velmi podobné žádostem, kromě prvního řádku [col], [dav]. První řádek odpovědi obsahuje verzi protokolu (SIP/2.0) a kód odpovědi (reply code). Typická odpověď vypadá následovně: Status-Line: SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK9ec4c02048ace1a554;rport=5060 From: "SJphone" <sip:7002@asterisk.vsb.cz>;tag=164235a64f6 To: <sip:1194@asterisk.vsb.cz>;tag=as Call-ID: D73F3443CABCD68EE653C791C0x9ec4c020 CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:1194@ > Content-Type: application/sdp Content-Length: 312 (v): 0 (o): root IN IP (s): session (c): IN IP (t): 0 0 (m): audio RTP/AVP (a): rtpmap:0 PCMU/8000 (a): rtpmap:8 PCMA/8000 (a): rtpmap:3 GSM/8000 Kód odpovědi je celé číslo z rozsahu 100 až 699 a označuje typ odpovědi. Celkem je definováno 6 tříd odpovědí, buď jsou informativní 1xx anebo finální 2xx-6xx: 1xx jsou dočasné informativní odpovědi, které jsou odesílány na žádosti, které byly přijaty, ale výsledek zpracování ještě není znám, na základě této odpovědi musí odesílatel zastavit opakování odesílání dané žádosti. Obvykle SIP Proxy servery odesílají odpovědi s kódem 100 (Trying), jestliže začínají zpracovávat INVITE a UA odesílají odpovědi s kódem 180 (Ringing), které oznamují vyzvánění volaného, kód 183 Session Progress má stejný význam jako 180, ale je doplněn o popis médií (SDP), 2xx jsou pozitivní finální odpovědi, je to poslední odpověď, kterou odesílatel na svou žádost dostává, vyjadřuje výsledek zpracování konkrétní žádosti. Odpovědi s kódy 200 až 299 oznamují, že požadavek byl akceptován a úspěšně zpracován, například odpověď 200 OK je vyslána, jestliže uživatel akceptuje žádost INVITE. V případě větvení zprávy INVITE můžeme dosáhnout několik UAS a každý z nich bude akceptovat žádost. V tomto případě je každá odpověď rozlišena parametrem tag v poli To. Každá odpověď probíhá v odlišném dialogu s jedinečným identifikátorem dialogu, 3xx odpovědi jsou užívány k přesměrování. Tyto odpovědi dávají informaci o nové poloze uživatele nebo alternativní službě, která má být použita. Pokud Proxy přijme žádost a nezpracuje ji z nějakého důvodu, tak vyšle volajícímu v odpovědi požadavek na přesměrování a vloží do odpovědi jiné umístění, které má být kontaktováno. Může to být jiná Proxy nebo 36

37 aktuální umístění volajícího (z lokalizační databáze vytvořené registrar serverem). Volající následně znovu vyšle žádost na nové umístění, odpovědi 3xx jsou konečné, 4xx jsou negativní konečné odpovědi a znamenají problém na straně klienta. Žádost nemohla být zpracována, protože obsahuje chybnou syntaxi, 5xx znamenají problém na straně serveru. Žádost je zřejmě v pořádku, ale server selhal při zpracování, klient by měl obvykle požadavek zkusit znovu, 6xx představuje globální chybu a tento kód je vysílán, pokud žádost nemůže být splněna na žádném serveru, to je odpověď obvykle vysílaná serverem, když má informaci o konkrétním uživateli, např. UA vysílá 603 Decline response, když odmítá žádost o sestavení spojení, Kromě odpovědi odpovídající třídy obsahuje první řádka popis reason phrase, obsažený kód je určen ke zpracování, což je snadno analyzovatelné a popis jasně oznamuje výsledek. UA může popis zobrazit uživateli. Přiřazení žádosti k odpovědi je na základě pole CSeq v hlavičce, kromě pořadového čísla obsahuje také metodu korespondující žádosti, v našem případě to byla žádost INVITE. Níže je uveden seznam odpovědí, se kterými se můžeme setkat v SIP protokolu: 1xx = informational responses * 100 Trying * 180 Ringing * 181 Call Is Being Forwarded * 182 Queued * 183 Session Progress 2xx = success responses * 200 OK * 202 accepted: Used for referrals 3xx = redirection responses * 300 Multiple Choices * 301 Moved Permanently * 302 Moved Temporarily * 305 Use Proxy * 380 Alternative Service 4xx = request failures * 400 Bad Request * 401 Unauthorized: Used only by registrars. Proxys should use proxy authorization 407 * 402 Payment Required (Reserved for future use) * 403 Forbidden * 404 Not Found: User not found * 405 Method Not Allowed * 406 Not Acceptable * 407 Proxy Authentication Required * 408 Request Timeout: Couldn't find the user in time * 410 Gone: The user existed once, but is not available here any more. * 413 Request Entity Too Large * 414 Request-URI Too Long * 415 Unsupported Media Type * 416 Unsupported URI Scheme * 420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server * 421 Extension Required * 423 Interval Too Brief 37

38 * 480 Temporarily Unavailable * 481 Call/Transaction Does Not Exist * 482 Loop Detected * 483 Too Many Hops * 484 Address Incomplete * 485 Ambiguous * 486 Busy Here * 487 Request Terminated * 488 Not Acceptable Here * 491 Request Pending * 493 Undecipherable: Could not decrypt S/MIME body part 5xx = server errors * 500 Server Internal Error * 501 Not Implemented: The SIP request method is not implemented here * 502 Bad Gateway * 503 Service Unavailable * 504 Server Time-out * 505 The server does not support this version of the SIP protocol * 513 Message Too Large 6xx = global failures * 600 Busy Everywhere * 603 Decline * 604 Does Not Exist Anywhere * 606 Not Acceptable INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: AG <sip:usera@here.com>;tag=123 To: BG <sip:userb@there.com> Call-ID: @here.com Cseq: 1 INVITE Contact: AG <sip:usera@here.com> Content-Type: application/sdp Content-Length: 147 v=0 o=usera IN IP4 here.com s=session SDP c=in IP t=00 m=audio49172rtp/avp0 a=rtpmap:0 PCMU/8000 SIP/ OK Via: SIP/2.0/UDP here.com:5060 From: AG <sip:usera@here.com>;tag=123 To: BG <sip:userb@there.com>;tag=65a35 Call-ID: @here.com Cseq: 1 INVITE Contact: BG <sip:userb@there.com> Content-Type: application/sdp Content-Length: 134 v=0 o=userb IN IP4 there.com s=session SDP c=in IP t=00 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Obr. 20. Žádost a odpověď Na obr. 20 jsou pole žádosti INVITE a konečné odpovědi na ni 200 OK, zobrazeny jsou i obsahy SDP, obě strany si vyměnily na sebe kontakty, nabídku SDP a odpověď na ní, použit bude kodek PCM G.711 µ-law. 38

39 2.3.4 Transakce Transakce jsou v SIPu velmi důležité pro tok zpráv a zacházení s nimi, neboť většina SIP prvků jsou transakční stroje. Ačkoliv bylo řečeno, že SIP zprávy jsou posílány sítí nezávisle, tak obvykle jsou uspořádány do transakcí agenty UA a stavovými SIP Proxy servery. Obr. 21. Transakce v SIP protokolu. Transakce je sekvence SIP zpráv vyměňovaných mezi síťovými SIP prvky. Transakce obsahuje jednu žádost a všechny odpovědi vztažené k této žádosti. To může znamenat žádnou, jednu nebo i více dočasných odpovědí a jednu nebo více konečných odpovědí (např. při větvení v Proxy na zprávu INVITE ). Jestliže byla transakce zahájena žádostí INVITE, pak stejná transakce obsahuje i zprávu ACK, ale dle RFC 3261 pouze tehdy, jestliže finální odpověď nebyla třídy 2xx, potom ACK není součástí dané transakce. Důvodem je, že odpověď je zpráva 200 OK, viz. obr. 21. Jiná situace je po přijetí non-2xx odpovědi, např. 407 Proxy Authorization Required, pak by žádost ACK do transakce patřila a v poli branch byl stejný identifikátor jako u předešlých zpráv stejné transakce. Především UA jsou zodpovědni za opakování odpovědi 200 OK, dokud nepřijmou ACK. SIP entity, které sledují tyto transakce, se nazývají stateful, vytvořený stav k žádosti je spojován s transakcí a je držen po celou dobu trvání transakce. Pokud přichází žádost nebo odpověď, tak je zkoušeno vždy přiřazení zprávy do probíhající transakce. Aby tato operace byla proveditelná, tak musí ze zprávy přečíst jednoznačný identifikátor transakce a porovnat jej s identifikátory probíhajících transakcí. Jestliže takováto transakce existuje, tak dochází k jejímu doplnění o další informace. V předchozím SIP RFC2543 (SIP 1.0) byl identifikátor transakce odvozován jako hash z důležitých informací v hlavičce zprávy (zahrnující pole To, From, Request-URI a CSeq), což bylo komplikované a zpomalovalo zpracování a při testech interoperability bylo zdrojem problémů. V aktuálně používaném RFC3261 (SIP 2.0) byl způsob výpočtu identifikátoru transakce zásadně změněn. Namísto komplikovaného určování z polí hlavičky teď obsahuje SIP zpráva identifikátor přímo v políčku Via s názvem branch. To je významné zjednodušení, ovšem stále existují staré 39

40 implementace, které nepodporují nový způsob určování identifikátoru transakce, proto musí být určování zpětně kompatibilní s oběma verzemi, noví UA a SIP Proxy musí rozeznat i předešlý způsob, skutečnost v praxi je ovšem mnohdy jiná. Způsob nového určení transakce poznáme dle začátku řetězce z9hg4bk v branch identifikátoru pole Via. branch=z9hg4bk9ec4c0248acd d7 Stavový transakční stroj okamžitě odpovídá 100 Trying na přijetí INVITE, čímž se potvrdí přijetí INVITE a zastaví se případné její opakování, pokud už odpověď 100 Trying byla jednou zaslána, tak se znovu nepřeposílá. Bezestavový stroj má jiné chování a přepošle vše, co dostane, neboť si nepamatuje stavy transakce. Rozdíl mezi SIP Proxy pracující s transakcemi nebo bez je vidět na obr. 22. Alice's UA Stateful Proxy Stateless Proxy Stateful Proxy Bob's UA INVITE 100 TRYING INVITE INVITE 100 TRYING 100 TRYING INVITE 100 TRYING 180 RINGING 200OK 180 RINGING 200OK 180 RINGING 200OK 180 RINGING 200OK ACK ACK ACK Media Session Obr. 22. Rozdílné zacházení se 100 Trying u stavových transakčních strojů Dialog V předchozím kapitole jsme si ukázali dvě transakce, viz. obr. 21, jedna transakce obsahovala zprávu INVITE a odpověď, druhá obsahovala zprávu BYE a následnou odpověď. Obě transakce však spolu souvisejí a náleží tak do jednoho dialogu, v první verzi SIPu RFC 2543 se používal pro dialog výraz call-leg. 40

41 Caller Callee INVITE 100 TRYING 180 RINGING Transaction#1 200OK ACK Dialog BYE 200OK Transaction#2 Obr. 23. Dialog. Dialog bychom mohli definovat jako soubor SIP zpráv peer-to-peer mezi dvěma UA, které mají vzájemnou spojitost. Dialogy popisují řazení a směrování zpráv mezi dvěma koncovými body. Dialogy jsou identifikované pomocí pole Call-ID, From (tag) a To (tag). Zprávy, které mají tyto tři identifikátory stejné, tak náleží jednomu dialogu. Ukázali jsme si, že pole CSeq je užíváno k řazení zpráv, je používáno k řazení zpráv uvnitř dialogu. CSeq číslo určuje transakci uvnitř dialogu, protože jsme řekli, že žádost a přidružená odpověď se nazývá transakce. To znamená, že v každém směru může být uvnitř dialogu aktivní pouze jedna transakce. Mohli bychom také tvrdit, že dialog je posloupnost transakcí. Pomocí CSeq snadno rozpoznáme zprávy dialogu. Dialogy usnadňují řízení komunikace, protože UA nedrží stavy dialogu. V uvedeném příkladu zpráva INVITE zahajuje dialog, neboť inicializuje spojení, všechny zprávy v tomto spojení patří do stejného dialogu, který je ukončen konečnou odpovědí na žádost BYE. Dialogy jsou vytvářeny generováním odpovědí typu non-failure (bez návratu chyby), pouze odpovědi typu 2xx a jsou schopny sestavit dialog, neboť vrací značku (tag) v poli To (To tag). RFC 3261 nepřináší zcela jednoznačnou definici, kdy je dialog přesně sestaven a proto rozeznáváme dva stavy: napůl sestavený (early dialog); potvrzený dialog (confirmed dialog). Pokud se hovoří o dialogu, tak jde o potvrzený dialog, zatímco v prvním případě se vždy uvádí plně jako early dialog. Early dialog je sestaven dočasnou (non-final) odpovědí , potvrzený dialog je sestaven pomocí pozitivní konečné odpovědi 2xx. Dialog při typickém sestavení spojení projde prvním stavem, než je potvrzen. Všimněme si, že dočasná odpověď typu 100 TRYING neumožňuje sestavit early dialog a v této odpovědi se nepřidává To tag. 41

42 2.3.6 Transakce a dialog v příkladu Určení transakce a dialogu si můžeme ukázat v následujícím příkladu, který odpovídá obr. 68, jde tedy o žádost INVITE s odpověďmi 100 TRYING, 180 RINGING, 200 OK, dále žádost ACK a nakonec BYE s odpovědí 200 OK. První zpráva #1 INVITE obsahuje branch=z9hg4bk7225f861, který najdeme ve zprávách #1 INVITE, #2 100 TRYING, #3 180 RINGING a #4 200 OK, tím je určena první transakce. Zpráva #5 ACK obsahuje branch=z9hg4bk , čili do první transakce nepatří a ani novou transakci nevytváří, neboť na tuto žádost není odpověď. Druhá transakce obsahuje branch=z9hg4bk011c16dd a je tvořena #6 BYE a #7 200 OK. Dialog je určen: pomocí tag=as396d4fbf z pole From, tag= d4b8 z pole To, řetězcem v Call-ID: 1c068e57440c89084bf549466dddfea0@ Early dialog je vytvořen přijetím #3 180 RINGING a dialog je sestaven přijetím #4 200 OK. Pole Cseq se v rámci dialogu inkrementuje s každou novou žádostí (výjimkou je ACK), všechny odpovědi k žádosti mají stejný Cseq, čili lze jednoduše určit, ke které žádosti odpověď patří a rovněž se snadno rozpoznají retransmise. # 1 INVITE Request-Line: INVITE sip:7002@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport From: "5779" <sip:5779@ >;tag=as396d4fbf To: <sip:7002@ > Contact: <sip:5779@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Type: application/sdp Content-Length: 422 (v): 0 (o): root IN IP (s): session (c): IN IP (t): 0 0 (m): audio RTP/AVP (a): rtpmap:0 PCMU/8000 (a): rtpmap:8 PCMA/8000 (a): rtpmap:3 GSM/8000 (a): rtpmap:18 G729/8000 #2 100 TRYING Status-Line: SIP/ Trying Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport=5060 From: "5779" <sip:5779@ >;tag=as396d4fbf To: "SJphone" <sip:7002@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 INVITE Content-Length: 0 Server: SJphone/ a (SJ Labs) 42

43 #3 180 RINGING Status-Line: SIP/ Ringing Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport=5060 From: "5779" To: "SJphone" Contact: Call-ID: CSeq: 102 INVITE Content-Length: 0 Server: SJphone/ a (SJ Labs) #4 200 OK Status-Line: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK7225f861;rport=5060 From: "5779" <sip:5779@ >;tag=as396d4fbf To: "SJphone" <sip:7002@ >;tag= d4b8 Contact: <sip:7002@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 INVITE Content-Length: 274 Content-Type: application/sdp Server: SJphone/ a (SJ Labs) (v): 0 (o): IN IP (s): SJphone (c): IN IP (t): 0 0 (m): audio RTP/AVP 0 (a): rtpmap:0 PCMU/8000 #5 ACK Request-Line: ACK sip:7002@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK ;rport From: "5779" <sip:5779@ >;tag=as396d4fbf To: <sip:7002@ >;tag= d4b8 Contact: <sip:5779@ > Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 #6 BYE Request-Line: BYE sip:7002@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK011c16dd;rport From: "5779" <sip:5779@ >;tag=as396d4fbf To: <sip:7002@ >;tag= d4b8 Call-ID: 1c068e57440c89084bf549466dddfea0@ CSeq: 103 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 43

44 #7 200 OK Status-Line: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK011c16dd;rport= =5060 From: "5779" To: "SJphone" Contact: Call-ID: CSeq: 103 BYE Content-Length: 0 Server: SJphone/ a (SJ Labs) SIP časovače a retransmise Jelikož se v SIP signalizaci používá mnohdy nespolehlivý přenos (UDP), musí být ošetřeny retransmise žádostí v transakcích. Tab. 3 Časovače dle RFC Po odeslání žádosti INVITE klientem se zprávy v transakcích opakují po dosažení časovače T1 a následně vždy po dosažení dvojnásobné doby od poslední retransmise, tzn. poprvé T1, podruhé 44

45 2*T1, dále 4*T1 a 8*T1. Základní časovač T1 je odvozen od RTT (Round Trip Time) a jeho výchozí hodnota je nastavena na 500 ms. Téměř všechny časovače jsou od T1 odvozeny a změna T1 se tak do nich promítá. Retransmise se neuplatňují při použití spolehlivého přenosu (TCP). Přijetí dočasné informativní odpovědi 1xx zastavuje retransmise žádosti INVITE a UAC musí čekat na přijetí dalších odpovědí. UAS může opakovat dočasnou odpověď 1xx před zasláním finální odpovědi, pokud se používá nespolehlivý přenos. Každá finální odpověď na INVITE je potvrzena ACK. Na straně UAC je dohlížen timeout transakce, žádná transakce by neměla trvat déle než 64*T1 (časovač B). Pokud vyprší časovač A, tak se provede retransmise a časovač se zvedne na 2*T1, pokud i tento čas vyprší, tak se zase zdvojnásobí. Níže jsou popsány časovače uvedené v RFC Zabezpečení v SIPu Protokol SIP je přenášen jako otevřený text a je snadněji analyzovatelný než H.323, který je kódován v ASN.1 PER. Pro zachycení a nahlídnutí do SIPové komunikace nepotřebujeme analyzátory, vystačíme si např. s linuxovým příkazem ngrep. Principy způsobu komunikace v SIPu jsou podobné HTTP a díky této podobnosti se využívají stejné bezpečnostní mechanismy, které používá právě Hypertext Transfer Protocol [voz159], [voz174] a [voz180].. HTTP Basic Authentication je prvním mechanizmem, který zajišťuje autentizaci pomocí sdíleného hesla. Data nejsou šifrována a není také zaručena integrita zprávy, obsahuje pouze základní kódování schématem Base64. HTTP Digest Authentication vychází z předchozí metody s tím rozdílem, že místo přenosu otevřeného hesla ho šifruje pomocí hashovaní funkce MD5 nebo SHA. Ta funguje tak, že heslo vytvoří z náhodně generovaného řetězce, loginu a hesla. Tato metoda ověřuje autenticitu na základě sdíleného hesla. Obsah zprávy se však nijak nešifruje. Secure MIME (S/MIME) je, jak z názvu vyplývá, zabezpečení tzv. MIME (Multipurpose Internet Mail Extension). Konkrétně tato metoda zabezpečí obsah zprávy a zaručí i její integritu. Existuji dva způsoby šifrování obsahu dat MIME. První application/pkcs7-mime dokáže digitálně podepsat a zašifrovat data. Druhý způsob multipart/signed je podobný prvnímu s tím rozdílem, že zpráva obsahuje šifrovaná i nešifrovaná data. K ověření autentizace se používá architektura veřejných klíčů (PKI). Pro utajení obsahu zprávy jsou využity symetrické kryptografické primitivy (DES, 3DES, AES). SIPS URI (TLS) využívá architekturu veřejných klíčů pro ověření autentizace. Při použití této metody se mění prefix identifikační hlavičky na sips. Aby byla zaručena bezpečná komunikace, používá tato metoda šifrovaný protokol Transfer Layer Security (TLS). Tento protokol využívá asymetrické šifrování (RSA), symetrické algoritmy (DES, 3DES, AES) a hashovací funkci. Při použití této metody je kladena podmínka, že protokol TLS je použit na celé cestě zprávy a pro SIP musí být použit protokol TCP. Princip používané metody HTTP digest bude prakticky vysvětlen v následující kapitole zabývající se registrací, u registrace se neautentizovaná zpráva REGISTER odmítá pomocí 401 Unauthorized, v případě INVITE je to 407 Proxy Authentication Required, následně se pošle REGISTER nebo INVITE s autentizačním řetězcem, který je ověřen. Pokud je použito TLS, tak další autentizace pomocí HTTP digest je zbytečná a nepoužívá se, neboť už sestavení TLS obsahuje jeden z kroků, u kterého se klient prokazuje certifikátem a zabezpečení je na mnohem vyšší úrovni. Řada aplikací volně dostupných na Internetu se dá použít buď ke generování útoků, odposlechu 45

46 hovoru či modifikaci paketů spojení, proto je otázka zabezpečení nejen signalizace, ale i vlastního hovoru velmi důležitá, což je argument pro použití TLS. Například aplikace SCAPY umožňuje nejen prolomení základních způsobů zabezpečení, ale i modifikaci obsahu paketů v reálném čase. SIPp je open-source generátor provozu, pomocí kterého zvládneme připravit DoS (Denial of Service) anebo DDOS útok (distribuovaný DoS). Aplikace voipbot umí pět různých typů útoků a sipdump se sipcrack umožňují uhodnutí hesla v autentizací s MD5. Zajímavou aplikací s použitím pro testování výkonnosti SIP serveru anebo pro útoky je VoIPER. 2.4 Registrace Při registraci se sváže User URI z pole From s Device URI z pole Contact hlavičky SIP. Pokud pole Contact hlavička žádosti Registrace neobsahuje, tak se z Registrar serveru ve 200 OK vrátí seznam platných registrací k SIP URI z pole From. Device URI nese IP adresu a port, na kterém je uživatel se svou SIP URI k dosažení, např. pro SIP URI sip:voznak@vsb.cz může být device URI sip:voznak@ :5060. Doba platnosti registrace je dána parametrem expires v hlavičce, tento čas je Registrar serverem upravován, pokud UAC v návrhu nezadá čas, který by ležel v povoleném intervalu mezi minimální a maximální dobou registrace na Registrar serveru. Pokud se pošle nulová hodnota doby registrace expires=0, tak to znamená zrušení registrace, viz. níže. Request-Line: REGISTER sip:cesnet.cz SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK-d8754zdf2acad8754z-;rport Max-Forwards: 70 Contact: <sip:voznak@ ;rinstance=45b13194f4a07bb>;expires=0 To: "voznak"<sip:voznak@cesnet.cz> From: "voznak"<sip:voznak@cesnet.cz>;tag= d Call-ID: MjY0YzU5OTdiMDYxNTI4YzgzNTIwYzE2NTUzNzgyZGM. CSeq: 5 REGISTER User-Agent: X-Lite release 1100l stamp Authorization: Digest username="voznak",realm="cesnet.cz", nonce="48ad92308a4f8ee", uri="sip:cesnet.cz",response="6e6f1ca5803c805ac885f8cb4a8a1df1",algorithm=md5 Content-Length: 0 Odregistrování všech lokalizací konkrétního URI uživatele se docílí tak, že do pole Contact se zadá znak * a zároveň s nulovou hodnotu do expirace expires=0. UA Registrar Server A@ B@ C@ REGISTER 401 UNAUTHORISED REGISTER with AUTH. 200OK Obr. 24. Registrace s autentizací. 46

47 Nepochybně je žádoucí, aby se uživatel při registraci autentizoval. Předpokládejme, že uživatel obdržel důvěryhodným způsobem uživatelské jméno a heslo, které si uložil ve svém IP telefonu. SIP používá stejnou metodu autentizace jako HTTP, a to HTTP digest authentication. Metoda spočívá v tom, že obě strany, jak server tak i klient, mají sdílené tajemství (heslo) a pomocí daných vstupních parametrů je jednosměrnou funkcí vygenerován otisk (hash). Vlastnost jednosměrné funkce spočívá v tom, že není možné z otisku zpětně získat vstupní proměnné funkce, přesněji řečeno pravděpodobnost získání vstupů je mizivá a otisk je jedinečný, tzn. neexistují dva stejné otisky pro různé vstupy hashovací funkce. Pokud hash zaslaná klientem bude souhlasit s řetězcem, který spočítal server, tak autentizace bude úspěšná a kladně tak vyřízena. Na obr. 24 je znázorněna výměna při registraci s autentizací. Žádost INVITE je odeslána bez autentizačních údajů na SIP Proxy, ta odmítá odpovědí 401 Unauthorized, v odpovědi posílá bližší informace k autentizaci. Klient akceptuje zaslané informace a vypočte hash, kterou zašle ve zprávě REGISTER, tentokrát je úspěšně autentizován a dostává 200 OK s potvrzením registrace. Status-Line: SIP/ Unauthorized Message Header Via: SIP/2.0/UDP :18188;branch=z9hG4bKd8754z-d8754z-;rport=33209 To: "voznak"<sip:voznak@cesnet.cz>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.10f8 From: "voznak"<sip:voznak@cesnet.cz>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 1 REGISTER WWW-Authenticate: Digest realm="cesnet.cz", nonce="48ad92c" Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Request-Line: REGISTER sip:cesnet.cz SIP/2.0 Via: SIP/2.0/UDP :18188;branch=z9hG4bK-d8bc45e75b347-;rport Max-Forwards: 70 Contact: <sip:voznak@ :18188;rinstance= > To: "voznak"<sip:voznak@cesnet.cz> From: "voznak"<sip:voznak@cesnet.cz>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 2 REGISTER Expires: 3600 User-Agent: X-Lite release 1100l stamp Authorization: Digest username="voznak",realm="cesnet.cz",nonce="48ad92c", uri="sip:cesnet.cz",response="1ca1df39a865353b cbdfbb062",algorithm=md5 Content-Length: 0 Na příkladu výše je odpověď 401 Anauthorized, která obsahuje v odmítnutí výzvu k autentizaci a podává klientovi realm a nonce pro hashovací funkci. Klient posílá žádost REGISTER znovu, ale tentokrát již s autentizačními údaji, je použit algoritmus MD5, pro hash se použije username, realm, nonce a password, což je sdílené tajemství. Výsledný hash je v poli response. 2.5 Směrování Zásadním problémem směrování je, jak z URI adresy určit cíl. SIP v tomto směru může využít buď DNS anebo statických směrovacích záznamů a dalších údajů lokalizace UA v databázi, do které se dostaly přes Registrar server. Pokud se cíl určí a spojení je uskutečněno, tak se objevují další 47

48 zásadní otázky. Kudy budou směrovány další žádosti, zda by měla SIP Proxy být prostředníkem v komunikaci a zůstávat v SIP signalizační trase či nikoliv. Noční můrou každého signalizačního protokolu je vznik nekonečné smyčky (zacyklení), v tomto ohledu má SIP dva silné nástroje. Prvním je detekce smyček pomocí branch parametru v poli Via, který si umí zapamatovat ovšem pouze stateful SIP Proxy, pomocí branch zjistí, že zpráva patří do jedné transakce a může tak limitovat počet zpráv v transakci. Druhým nástrojem je povinné pole Max- Forwards v SIP hlavičce, které se snižuje o jedničku na každém skoku (výchozí hodnota je obvykle 70), tzn. s každým průchodem přes SIP Proxy se hodnota sníží, až dosáhne 0, tak SIP Proxy odešle 483 Too Many Hops a zpráva zanikne. V obr. 25 je znázorněn tok zpráv v rámci jednoho SIP Proxy serveru, ze kterého je čitelná souslednost konkrétních žádostí a odpovědí. Směrování mezi SIP Proxy servery je obsahem dalších kapitol. Obr. 25. Tok SIP zpráv v rámci SIP Proxy Směrování dle RURI a Via Žádosti jsou směrovány dle prvního řádku (RURI) SIP metody a odpovědi na žádost dle prvního záznamu ve Via., viz. obr. 26. Alice volá Boba, odesílá se INVITE, původní SIP URI se zapisuje do pole To, kde je logická adresa příjemce AOR (Address of Record) a neměl by ho po cestě nikdo změnit. První řádek obsahující RURI (Request URI) může SIP Proxy změnit dle aktuálních směrovacích informací, INVITE nakonec zastihne Boba na sip:bob@pc42.cs.columbia.edu. Alicin UA zapisuje do pole Via na první řádek sám sebe (a.example.com nebo svou IP), každá další Proxy po cestě udělá to samé, opět se vepíše na první řádek, a tak INVITE, který dostane Bob, bude mít 48

49 čtyři záznamy ve Via, viz. obr. 26. Jelikož odpověď je směrována dle Via, tak prochází stejnou cestou jako žádost, každý první záznam je z Via odstraněn ihned po přijetí odpovědi SIP Proxy, a tak je aktuální informace ve Via vždy první. Jakmile si koncové komunikující strany vymění na sebe kontakty (pole Contact v hlavičce), tak další žádosti mohou být odesílány napřímo. Ovšem i tato cesta se dá ovlivnit, viz. další kapitola. bob_doe@yahoo.com bob@columbia.edu INVITE Via: a.example.com Via: y1.yahoo.com Via: a.example.com Via: a.example.com alice@example.com Via: y1.yahoo.com Via: a.example.com Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com Via: cs.columbia.edu Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com bob@pc42.cs. columbia.edu bob@cs.columbia.edu 200OK Via: cs.columbia.edu Via: sip.columbia.edu Via: y1.yahoo.com Via: a.example.com Obr. 25. Směrování žádostí a odpovědí SIP trapezoid SIPu trapezoid je typickým příkladem směrování zpráv v SIPu, předpokládáme, že Alice (sip:alice@atlanta.com) volá Boba z jiné domény (sip:bob@biloxi.com). INVITE je zaslán na SIP Proxy domény atlanta.com, která vyhledá SIP Proxy obsluhující doménu biloxi.com a tam INVITE odešle, SIP Proxy domény biloxi.com zná umístění Boba a přepošle tedy INVITE Bobovi. Odpovědi jdou stejnou cestou jako žádost dle položky Via. ACK je další žádostí (potvrzení doručení finální odpovědi) a ta je zaslána přímo Bobovi dle pole Contact. Alice provede hovor s Bobem a relaci ukončí Bob odesláním žádosti BYE, která odchází na Alici přímo dle pole Contact. Tok zpráv připomíná geometrický útvar trapezoid, viz. obr. 27. Následně se podíváme do hlaviček SIP zpráv při sestavení spojení a popíšeme si, jak prvky na trase pracují s vybranými položkami hlavičky (bez SDP, popis médií je obsahem samostatné kapitoly), budeme pracovat se stateful SIP Proxy. První řádek obsahuje Request-URI a tato URI je zapsána do pole To jako AOR, tam nebude měněna. Do Via se 49

50 zapíše odesílatel a přidá branch pro identifikaci transakce, když se mu vrátí odpověď se stejným branch, tak ji zařadí do této transakce. INVITE INVITE Obr. 27. SIP trapezoid. Do pole From zapíše odesílatel svou logickou SIP URI (AOR), přičemž text před úhlovými závorkami se zobrazuje na displeji jako textová identifikace odesílatele. Do pole Contact zapíše odesílatel svou device SIP URI, na které je k zastižení. Je vytvořeno nové jedinečné Call-ID, pořadí transakce Cesq a za ním název metody, nakonec je v hlavičce odkaz na tělo SDP (v naší ukázce odebráno). INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 INVITE dorazil na SIP Proxy atlanta.com a jelikož je statefull, tak ihned odesílá 100 TRYING. Odpověď 100 TRYING obsahuje stejné hodnoty To, From, Call-ID, Cseq jako v přijatém INVITE. Parametr received je přidán do pole Via, kde SIP Proxy doplní stroj, ze kterého byla žádost přijata pc33.atlanta.com (může být i IP). SIP/ Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE 50

51 Content-Length: 0 SIP Proxy atlanta.com najde SIP Proxy, která obsluhuje doménu biloxi.com, ve které je volaný Bob. Nejdříve zjistí, zda už nemá destinaci ve své lokalizační databázi a pokud ne, tak provede vyhledání v DNS (DNS lookup), bude se hledat SRV záznam, ten obsahuje identifikaci stroje, který poskytuje službu SIP v dané doméně. INVITE teď SIP Proxy přepošle na zjištěnou cílovou SIP Proxy, přičemž připíše parametr received do prvního záznamu ve Via, následně zapíše sebe jako první záznam ve Via a sníží hodnotu v položce Max-Forwards. Další položky SIP hlavičky zůstávají nezměněny. INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 INVITE byl přijat SIP Proxy biloxi.com, která ihned odesílá 100 TRYING, obdobně předchozím kroku je přidán parametr received do Via. jako v SIP/ Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Content-Length: 0 SIP Proxy biloxi.com vyhledává ve své lokalizační databázi záznam Boba, který byl vložen při registraci, v lokalizační databázi je device URI z pole Contact svázána s logickou URI sip:bob@atlanta.com. Proxy biloxi.com odesílá INVITE Bobovi, přičemž připíše received do prvního záznamu ve Via, následně zapíše sebe jako první záznam ve Via a sníží hodnotu v položce Max- Forwards, zbytek hlavičky nemění. INVITE sip:bob@ SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= Max-Forwards: 68 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length:

52 Dále si ukážeme obsah odpovědi 180 RINGING odesílanou z Bobova UA. Bobův UA vyzvání a odesílá 180 RINGING, do hlavičky připíše received do prvního záznamu ve Via a přidává tag do pole To. Ačkoliv dialog není ještě sestaven, tak jsou už definovány všechny tři části, dle kterých se identifikuje (Call-ID, from Tag a to Tag). Do pole Contact zapisuje Bob svou device URI, na které je k zastižení, přičemž v příchozím INVITE získal kontakt na Alici. SIP/ Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 Contact: <sip:bob@ > CSeq: INVITE Odpověď 180 RINGING je přeposílána přes SIP Proxy Alici, přičemž každá SIP Proxy po přijetí smaže první řádek v pořadí ve Via, a přepošle na další stroj v pořadí ve Via, odpověď se tak postupně dostane až k odesílateli žádosti. Bobův UA vyzvání a na displeji zobrazuje text z pole From přijatý v INVITE, tzn. vidí na displeji nápis Alice. Po přijetí volání odesílá Bobův UA odpověď 200 OK s obdobnou konstrukcí jako 180 RINGING, akorát se posílá i SDP, což v ukázce teď není. Jelikož jde o odpověď finální, tak se ukončuje transakce mezi biloxi.com a Bobem identifikovanou branch=z9hg4bk4b43c2ff8.1, pořadí ukončené transakce je dané polem CSeq: INVITE. SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds8;received= To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:bob@ > Content-Type: application/sdp Content-Length: 131 Přijatá odpověď 200 OK je přeposlána na SIP Proxy atlanta.com a ukončí transakci mezi biloxi.com a atlanta.com branch=z9hg4bk77ef4c se CSeq: INVITE. Nakonec je 200 OK přeposlána ze SIP Proxy atlanta.com Alici a ukončí na obou strojích transakci branch=z9hg4bknashds8 se CSeq: INVITE. Alicin UA přestává indikovat vyzvánění a kontrolní vyzváněcí tón umlkne, Alice může začít mluvit. Dokud Bobův UA neobdrží žádost ACK, tak nebude mít jistotu, že odpověď 200 OK byla doručena a bude opakovaně odesílat 200 OK (retransmise). ACK žádost je zaslána přímo na Bobův UA a obchází obě SIP Proxy, k tomuto dochází, protože obě strany si uložily na sebe kontakty z pole Contact SIP hlaviček. Jelikož ACK nepatří do předchozí transakce, tak se vytvoří nový branch=z9hg4bknashds9, ale nezvedá se Cseq, neboť na žádost ACK není žádná odpověď a nevytváří tak novou transakci. Jedná se o stejný dialog, a tak se musí zachovat značky From tag, To tag a Call-ID. 52

53 ACK SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bknashds9 Max-Forwards: 70 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: ACK Content-Length: 0 Hovor ukončí Bob, zavěsí a jeho UA odesílá žádost BYE, opět přímo na Alici. Jedná o novou transakci, takže se zvedne Cseq a zachová se From tag, To tag a Call-ID (patří do dialogu). Po přijetí finální odpovědi 200 OK na BYE se dialog ukončí. BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: BYE Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 CSeq: BYE Content-Length: Udržení SIP Proxy v signalizační trase V předchozí kapitole byly další žádosti v dialogu zasílány přímo mezi koncovými účastníky spojení a signalizace tak obcházela SIP Proxy. Nástrojem, který v SIPu umožní zachovat libovolný prvek v signalizační trase během celého dialogu, je pole Record-route SIP hlavičky pro uložení záznamu o cestě a pole Route, dle kterého se žádost směruje. Without record routing With record routing UA1 SIP Proxy UA2 UA1 SIP Proxy UA2 BYE 200OK BYE 200OK BYE 200OK Obr. 28. Rozdíl v komunikaci při použití Record-route pole 53

54 Do hlavičky žádosti INVITE se vloží pole Record-route obsahující záznam prvku, který chceme udržet v trase, tzn. že SIP Proxy do INVITE přidá sebe např. p1.atlanta.com a pokud INVITE prochází další SIP Proxy, která se chce udržet v trase, tak se opět zapíše do hlavičky jako např. p2.biloxi.com, v INVITE nám tedy přibude: Record-route: <sip:p2.biloxi.com;lr> Record-route: <sip:p1.atlanta.com;lr> INVITE dorazil cílovému příjemci, pokud je detekováno pole Record-route, tak UA si nastaví cestu odesílání žádostí dle seznamu URI v Record-route seřazeném tak, jak byly zapsány v přijatém INVITE. Poté UA zkopíruje Record-route položky do odpovědi 180 RINGING a ta putuje původnímu odesílateli INVITE, v odpovědi nikdo nesmí Record-Route změnit. Příjemce odpovědi si nastaví cestu odesílání žádostí dle seznamu Record-route v obráceném pořadí. Pro další krok, je nutné vysvětlit dva přístupy ke směrování SIP žádostí: Strict routing přepíše RURI (Request-URI, první řádek SIP žádosti) dle údaje v Route poli hlavičky, přepisuje RURI na každém skoku a prochází jen přes servery uvedené v Route poli hlavičky; Loose routing je metoda která se mnohem více užívá a její aplikaci vyjadřuje parametr lr v poli Record-Route či Route. V tomto případě se nepřepisuje RURI, ale žádost se směruje dle URI v Route poli hlavičky, na každém skoku se dané URI z Route hlavičky odstraní, až neexistuje žádné URI v poli Route a potom se odsměruje dle RURI. Další žádost (např. ACK) odešle UA tak, že sestaví Request-URI standardně z pole Contact v odpovědi na INVITE, ale vytvoří Route pole v hlavičce ACK, které bude obsahovat: Route: <sip:p1.atlanta.com;lr>, <sip:p2.biloxi.com;lr> Údaje byly získány v Record-route a pořadí bylo obráceno (jelikož údaje byly získány z odpovědi). Žádost je odsměrována dle prvního URI v route hlavičce. ACK tak dorazí na SIP Proxy p1.atlanta.com, kde je odstraněn první záznam v pořadí z pole Route a na další je ACK odesláno, a tak dorazí na SIP Proxy p2.biloxi.com, kde je opět odstraněn první záznam v pořadí, a jelikož je Route pole prázdné, tak se dále směruje dle RURI. 2.6 SDP- protokol popisu relace SDP je Session Description Protocol, který obecně slouží k popisu kterékoliv relace a je se SIP signalizací velmi často používán. Používá se často se SIPem a proto se v souvislosti se SIPem objevuje označení SIP/SDP. SDP protokol prošel třemi zásadními verzemi: Session Description Protocol, RFC 2327 z roku 1998 je původní verze; Support for IPv6 in Session Description Protocol (SDP), RFC 3266 z roku 2002 je aktualizací RFC 2327 a rozšířením o IPv6; Session Description Protocol, RFC 4566 z roku 2006 je nahrazením obou předešlých, uvolněním RFC 4566 zastaraly obě RFC 2327 i 3266, ale je zde zpětná kompatibilita, tzn. že implementace dle RFC 4566 dokáže porozumět starším verzím. 54

55 SDP se skládá z řádků obsahující text ve formě položek typ a hodnota oddělených rovnítkem, položky, u kterých je symbol *, jsou nepovinné: <type>=<value> Položky jsou rozděleny do třech skupin: Session description, popis relace, Time description, popis časování, Media description, popis médií. Následně si projdeme seznam položek SDP dle skupin uvedených RFC Skupina Session description obsahuje položky v,o,s,i,u,e,c,b,z,k,a, kde: v= (protocol version), vždy je nastaveno v=0, o= (owner/creator and session identifier), označuje iniciátora relace a má následující syntaxi: o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address> s= (session name), název relace, pole je povinné a nesmí být prázdné, často se do něj zadává mezera, pomlčka anebo tečka, i=* (session information), textová informace o relaci, u=* (URI of description), URI adresa odkazující na dodatečné informace k relaci, e=* ( address) p=* (phone number), kontaktní a tel.č., c=* (connection information - not required if included in all media), udává informace o připojovaném koncovém bodu relace ve formátu c=<nettype> <addrtype> <connectionaddress>, b=* (bandwidth information), informace o využívaném pásmu, z=* (time zone adjustments), ošetřuje posuny času, dají se naplánovat opakované přechody letního a zimního času. k=* (encryption key), pokud je SDP transportován přes důvěryhodný transportní kanál, tak může být pole k využito pro zprostředkování výměny klíčů ve formátu k=<method>:<encryption key>, a=* (zero or more session attribute lines), rozšiřující atributy ve formátu a=<attribute>:<value>, např. a=recvonly. Skupina Time description obsahuje položky t a r, kde : t= (time the session is active), řádek specifikuje v relaci časové značky pro start a stop ve formátu t=<start-time> <stop-time>, pokud jsou značky nastaveny 0 0, tak jde o permanentní přehrávání relace, r=* (zero or more repeat times), časy opakování relace ve tvaru r=<repeat interval> <active duration> <offsets from start-time>, Skupina Media description obsahuje položky m, c, b, k, a, kde: m= (media name and transport address), SDP může obsahovat více m řádků, každý je chápán jako nabídka jednoho toku, který se udává ve formátu m=<media> <port> <proto> <fmt>, jako média se uvádí audio, video, text, application nebo message, port udává transportní port a fmt je popis formátu médií, c=* (connection information - optional if included at session-level), 55

56 b=* (bandwidth information), k=* (encryption key), a=* (zero or more media attribute lines) Konstrukce položek SDP pro komunikaci SIP/SDP Povinnými položkami hlavičky SDP jsou řádku v, o, s, t, m : v=0 o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-addr.> s= název relace t= 0 0 m=m=<media> <port> <proto> <fmt> Popis médií v m řádku se obvykle doplňuje nepovinnými atributy, tyto atributy jsou specifikovány v dalších RFC a jde o tyto atributy: a=ptime:<packet time>, [RFC4566] a=rtpmap:<payload type> <encoding name>/<clock rate> <encoding parameters>, [RFC4566] a=orient:<orientation>, [RFC4566] a=framerate:<frame rate>, [RFC4566] a=quality:<quality>, [RFC4566] a=fmtp:<format> <format specific parameters>, [RFC4566] a=maxptime:<maximum packet time>, RFC3267, RFC4566 a=curr:<precondition-type> <status-type> <direction-tag>, [RFC3312] a=des:<precondition-type> <strength-tag> <status-type> <direction-tag>,[rfc3312] a=conf:<precondition-type> <status-type> <direction-tag>, [RFC3312] a=mid:<identification-tags>, [RFC3388] a=rtcp:<port>, [RFC3605] a=crypto:<tag> <crypto-suite> <key-params> [<session-param>], [RFC4568] a=label:<pointer>, [RFC4574] a=floorctrl:<role>,[rfc4583] a=confid:<conference-id>, [RFC4583] a=floorid:<token>, [RFC4583] a=content:<mediacnt-tag>, [RFC4796] Uvedené atributy jsou použity výhradně pro média, dále existují atributy relace, které neuvádím, neboť v SIP/SDP se s nimi nepotkáme, ale ještě máme atributy používané na obou úrovních, jak pro popis médií, tak i relace, a ty si uvedeme: a=recvonly, [RFC4566] a=sendrecv, [RFC4566] a=sendonly, [RFC4566] a=inactive, RFC3108, RFC4566 (and used in RFC3264) a=sdplang:<language tag>, [RFC4566] a=lang:<language tag>, [RFC4566] a=maxprate:<packet-rate>, [RFC3890] a=setup:<role>, [RFC4145] a=connection:<conn-value>, [RFC4145] 56

57 a=key-mgmt:<prtcl-id> <keymgmt-data>, [RFC4567] a=source-filter:<filter-mode> <filter-spec>, [RFC4570] a=fingerprint:<hash-func> <fingerprint>, [RFC4572] Níže je uveden příklad obsahu SDP připojeného k SIP žádosti INVITE, ve kterém jsou nabídnuty dva RTP toky. První je audio s preferencí kodeků PCM µ-law, A-law, GSM, ilbc a G.729, GSM, očekávaný na portu a druhý tok je video H.263 na portu 15014, oba toky mají být zakončeny na IP INVITE sip:7002@ SIP/2.0 (SIP hlavička, volný řádek a SDP) v=0 o=root IN IP s=session c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 ilbc/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=silencesupp:off m=video RTP/AVP 34 a=rtpmap:34 H263/90000 Odpověď přišla v SDP připojeného k odpovědi 200 OK na INVITEN. Druhá strana sděluje, že naslouchá G.729 na portu a IP a druhý m řádek s videem H.263 je vrácen s portem 0, což znamená odmítnutí celého m řádku (toku), video tedy odesílatel SDP neumožňuje. SIP/ OK (SIP hlavička, volný řádek a SDP) v=0 o= IN IP s=sjphone c=in IP t=0 0 m=audio RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no m=video 0 RTP/AVP Offer/Answer model Vyjednávání probíhá v modelu označovaného jako Offer/Answer model specifikovaném v RFC RFC 3264 z roku Doporučení zavádí následující pojmy: Offerer, UA zasílající SDP jako požadavek na vytvoření či modifikaci relace, Offer, nabídka, kterou zasílá offerer, Answerer, UA přijímací SDP a zasílající na ní odpověď s popisem vlastních médií, Answer, je SDP odpověď na nabídku, 57

58 Media Stream, je tok médií (např. video, audio,...), každý media stream je popsán konkrétním m řádkem a jeho přidruženými atributy. U SDP řádek s= (subject) nesmí být volný. Jelikož v SIPu relaci vytváříme a ukončujeme pomocí SIP signalizačních zpráv, tak nepoužíváme start a stop značky v SDP a relaci zde necháváme jako permanentní pomocí řádku t = 0 0. Pokud odešleme nabídku s SDP, tak dokud není zaslána odpověď, nesmí se odeslat další SDP nabídka, tzn. probíhá vždy pouze jedno vyjednávání. Jelikož offer/answer model je řízen protokolem vyšší vrstvy (SIP), tak musí být následující situace ošetřena na úrovni signalizace SIP: UA nesmí generovat novou SDP nabídku, jestliže přijal nabídku, kterou dosud nezodpověděl nebo neodmítnul; UA nesmí generovat novou nabídku, jestliže předtím odeslal nabídku a dosud neobdržel odpověď nebo odmítnutí. Přesto může dojít výjimečně k situaci, kdy jsou zaslány dvě nabídky (např. INVITE a re-invite v rámci offer/answer), tato situace se označuje jako SIP glare. Jestliže UAS obdržel druhý INVITE, když předtím odeslal v témže dialogu odpověď na první INVITE s nižším Cseq, tak musí vrátit odpověď 500 Server Internal Error na přijatý druhý INVITE a do hlavičky odpovědi přidat pole Retry- After s náhodně zvolenou hodnotou v rozsahu 0 až 10. Jestliže UAS dostane INVITE v dialogu, v rámci kterého má nevyřízený INVITE (před chvíli sám INVITE odeslal a dosud nedostal odpověď), tak musí na přijatý INVITE vrátit odpověď 491 Request Pending. Nabídka buď neobsahuje žádný nebo obsahuje jeden anebo více média toků a každý je popsán v jednotlivém m řádku s přiřazenými atributy. Pokud neobsahuje žádný, tak si strana nabízející SDP přeje komunikovat později a až získá odpověď na nabídku, tak bude svou nabídku modifikovat (zašle novou). Pokud obsahuje více m řádků, tak každý musí popisovat jiný typ toku, neboť nelze žádat o vícenásobný tok stejného typu (paralell stream), typ toku je určen portem, profilem a kodeky, takže např. můžu si nechat poslat jeden šifrovaný tok a druhý nešifrovaný RTP či poslat jeden tok audio a druhý video. Na nabídku jednotlivých toků druhá strana odpovídá tak, že v odpovědi uvede na základě nabídky své typy toků (port, kodeky), v odpovědi je uveden stejný počet m řádků obsažených v nabídce a to i ve stejném pořadí. Nabídka toku může být odmítnuta z jakéhokoliv důvodu (nepodporovaný tok např. video), odmítá se konkrétní m řádek a to tak, že v odpovědi se v m řádku nastaví port na hodnotu 0. 58

59 3 Asterisk Asterisk je fenomén posledních let, to co představuje Apache v oblasti webových serverů, tak obdobné postavení má Asterisk v IP telefonii. Trend nasazování IP telefonie je dlouhodobý a telefonie se ocitá v roli aplikace na IP sítích. Alfou a omegou IP telefonie ve firemním prostředí je pobočková ústředna (PBX), v operátorském je to softswitch. V případě pobočkové ústředny se častěji mluví o komunikačním serveru, protože většina nasazovaných řešení PBX může sloužit jako aplikační server, překladová média brána či poskytovat podporu dalších služeb. V současné době nejrozšířenější volně dostupnou softwarovou realizací takové ústředny představuje produkt Asterisk od firmy Digium. V následujících kapitolách provedeme čtenáře jednotlivými konfiguracemi služeb, tak aby byl po přečtení textu schopen vytvořit fungující systém a infrastrukturu umožňující efektivní používání VoIP telefonie v praxi. Nejdříve ovšem pár vět k původu Asterisku. Při vzniku Asterisku byl Mark Spencer, čerstvý absolvent Auburn University v Alabamě, který se v roce 1999 rozhodl napsat pro linux svůj vlastní softvér realizující pobočkovou ústřednu s hlasovou poštou (voic ) namísto zakoupení komerčního produktu, údajně nebylo na PBX dost prostředků. Výstup své práce zveřejnil jako open-source a nabídl tím široké komunitě uživatelů, testerů i vývojářů. I was so excited the first time I got a phone call delivered through my PC using my own software. Mark Spencer Nevíme, nakolik je historka pravdivá, ale každopádně v roce 1999 vznikl jeden z nejvýznamnějších open-source projektů. Mark Spencer založil o tři roky později firmu Digium, která dlouhodobě stojí za vývojem Asterisku a protože SW Asterisk se prodávat nedá, tak její profit je z především z technické podpory a z prodeje HW, který je plně kompatibilní s Asteriskem, jedná se o Digium Cards jako je T1/E1/FXO/FXS. Dnes je vývoj Asterisku z větší části záležitostí open-source komunity a díky tomu má aktuální vývoj asi 400 přispěvovatelů, což je velká síla, do poslední verze přispěli více než dvěmi třetinami. Pro ilustraci vývoje uvádíme, že verze Asterisku 1.4 byla uvolněna v prosinci roku 2006, verze Asterisku 1.6 v roce 2008 a verze 1.8 v roce Popis Asterisku Asterisk je open-source softwarová PBX určená pro instalaci na standardních PC a spolu se správným rozhraním může být použita jako PBX pro domácí uživatele, podniky, poskytovatele VoIP 59

60 služeb a telefonní společnosti. Asterisk je rovněž open-source komunita a komerční produkt od firmy Digium. Systém je navržen tak, aby vytvořil rozhraní mezi telefonním hardwarem či softwarem a libovolnou telefonní aplikací. S jednotlivými protokoly SIP, IAX, H.323 pracuje Asterisk jako s kanály navázanými na jádro, DAHDI (Digium Hardware Device Interface) představuje rozhraní směrem k PSTN, může se jednat o ISDN BRI či PRI karty, FXS, FXO, apod. Příkazový řádek CLI je silným nástrojem Asterisku, stejně jako Manager Interface. Srdcem Asterisku je Dialplan, kde je definováno chování v případě obsluhy požadavku, ať už odchozího či příchozího volání anebo požadavku na vyvolání služby, viz. obr. architektury Asterisku. Obr. 29. Architektura Asterisku Režimy Asterisku Jak již bylo naznačeno v úvodu, Asterisk může mimo jiné sloužit jako: Různorodá VoIP gateway mezi protokoly (MGCP, SIP, IAX, H.323). Pobočková ústředna (PBX). Voic služba s adresářem. Interaktivní hlasový průvodce (IVR server). Softwarová ústředna (Softswitch). Konferenční server. Packet voice server. Šifrovací médium telefonních nebo faxových volání. Překladač čísel. Aplikace Calling card, Prediktivní volič, 60

61 Vzdálená kancelář pro existující PBX. A další... Asterisk také podporuje služby, které byly dříve součástí pouze pokročilých firemních řešení: Hudba pro zákazníky v pořadí čekající ve frontě na hovor, podpora streamování médií a MP3 souborů. Fronty volajících, kdy tým agentů může odpovědět na volání a může sledovat fronty (vhodné pro Call Centra). Integrace Text-to-speech modulů a rozpoznávání hlasu. Podrobné záznamy o hovorech jsou převáděny do textových souborů a SQL databází. Propojení s PSTN sítí skrze digitální a analogové linky Kodeky a protokoly Asterisku Obvykle je snaha, aby bylo možné v dané datové sítí realizovat co nejvíce hlasových spojení. Kodeky poskytují nové možnosti pro digitální přenos hlasu, včetně komprese, která je jednou z nejdůležitějších vlastností, mezi další vlastnosti patří detekce hlasové aktivity, vyrovnání paketové ztráty, a generování výplňového šumu. V Asterisku jsou podporovány následující kodeky s uvedenou šířkou pásma. Ty mohou být samozřejmě transparentně překládány z jednoho na druhý. G.711 ulaw (USA) - (64 Kbps). G.711 alaw (Europe) - (64 Kbps). G.722 (širokopásmový kodek) (64 Kbps). G pouze pass-through režim G (16/24/32/40kbps) G.729 nutná licence (8Kbps) GSM - (12-13 Kbps) ilbc - (15 Kbps) LPC10 - (2.5 Kbps) Speex - ( Kbps) Odesílání dat z jednoho telefonu do druhého by mělo být snadné za předpokladu, že si data samy najdou cestu skrze síť. V praxi je nutné pro toto směrování využívat signalizační protokoly, dominantním a nejpoužívanějším signalizačním protokolem je SIP. Přesto existuje stále spousta systémů, které pro signalizaci ve VoIP síti využívají starších protokolů jako jsou např. H.323. Jiný protokol IAX je zase nativním protokolem Asterisku a výborně prochází NATem. Seznam podporovaných signalizačních protokolů v Asterisku je uveden níže: SIP H323 IAX2 MGCP SCCP (Cisco Skinny) Nortel unistim 61

62 3.1.3 Verze Asterisku První oficiální funkční verze Asterisku pod označením 1.0 vyšla 23. září O rok později, konkrétně 15. Listopadu 2005 byla představena verze 1.2, která přinášela oproti verzi 1.0 více než 3000 vylepšení a oprav. Mezi ty největší patřily: vylepšení funkcí hlasové schránky (voic ), přidání DUNDi (Distributed Universal Number Discover) protokol, jednodušší konfigurace Asterisku, větší podpora pro SIP protokol, využití hudby pro čekání na hovor, podpora ISDN PRI a mnoho dalších. Jak už se u firmy Digium stalo zvykem, další verze přišla opět po roce a to 26. prosince Jednalo se o verzi 1.4 a tato se stala nejvíce rozšířenou a používanou i dlouho poté, co byla 2. října 2008 představena verze 1.6. Verze 1.6 má již nativně plně implementovanou podporu pro šifrování SIPu, podporuje signalizaci SS7 a obsahuje spoustu dalších nových vylepšení. Momentálně je dostupná verze 1.8, která byla uvolněna na podzim 2010, je označována jako LTS (Long Term Supported), přibyla v ní především SRTP a kalendářů. Obr.30. Loga jednotlivých distribucí Veškeré výše uvedené verzee představují tzv. klasický Asterisk, který se instaluje v podobě softvérového programu na linuxové distribuce a veškerá jeho nastavení či konfigurace se provádí přes příkazovou řádku operačního systému tzv. shell, neboli interpret příkazů. Existují však i distribuce Asterisku určeny pro začínající uživatele, které jsou instalovány z ISO souboru a představují celý operační systém založen na Linuxové distribuci a obsahující Asterisk, všechny potřebné balíčky k jeho provozu a hlavně webový server a grafické webové rozhraní (založené na FreePBX), pomocí něhož se ústředna konfiguruje. Těchto distribucí je několik, společnost Digium podporuje vývoj AsteriskNOW v současnosti dostupné ve verzi 1.7. Verze 1.7 obsahuje Asterisk 1.6 tzn. služby podporované v této verzi jsou dostupné i v AsteriskNOW. Další z grafických distribucí je například Trixbox. Jedná se opět o kompletní operační systém velice podobný AsteriskNOW, používá však vlastní webové rozhraní. Momentálně je dostupný ve verzi 2.8 a používá taktéž Asterisk ve verzi 1.6. Tento text se primárně zaměřuje na popis konfigurace klasického Asterisku pomocí příkazové řádky a konfiguračních souborů, jelikož grafické nástavby nakonec využívají právě tento klasický Asterisk a pouze automatizují proces konfigurace. Pokud tedy budeme znát problematiku konfigurace klasického Asterisku, budeme znát i způsob konfigurace pomocí grafických distribucí. 3.2 Instalace Asterisku Následující kapitola popisuje instalaci klasického Asterisku ve verzi 1.6 přímo pomocí balíčku pro jednotlivé linux distribuce a také pomocí kompilace. 62

63 3.2.1 Instalace pomocí balíčku s příponou.deb Tato instalace je určena pro Linuxové distribuce, které využívají balíčkovací systém deb. Jedná se například o distribuce Debian či Ubuntu a jeho deriváty. Ke správě systému využívají nástroj apt nebo aptitude. Níže popsaná instalace je vyzkoušena na distribucích Debian Squeeze a Ubuntu 10.04(10.10). Pozn.: Starší verze distribucí nemusí mít aktualizované repozitáře a mohou obsahovat starší verzi Asterisku, například 1.4). Instalace je velice jednoduchá. Do příkazového řádku pod uživatelem root napište: apt-get install asterisk Potvrďte instalaci stiskem klávesy Y a do formuláře vyplňte mezinárodní telefonní předvolbu české republiky 420. Po instalaci je jíž ústředna plně funkční a připravena k použití. Zda je Asterisk funkční můžete otestovat příkazem: asterisk -vvvgci Obr.31. Vyplnění mezinárodní předvolby Instalace pomocí balíčku s příponou.rpm Tato instalace je určena pro Linuxové distribuce, které využívají balíčkovací systém rpm. Jedná se například o distribuce Fedora, RedHat,CentOS či Gentoo. K správě systému využívají nástroj yum. Níže popsaná instalace je vyzkoušena na distribucích CentOS 5 a RedHat Enteprise Linux 5. Před samotnou instalací je nutno aktualizovat repozitáře systému o nové zdroje. Pomocí textového editoru dle Vašeho výběru vytvořte nový soubor: centos-asterisk.repo v adresáři: /etc/yum.repos.d a do vytvořeného souboru vložte následující text: [asterisk-tested] name=centos-$releasever - Asterisk - Tested 63

64 baseurl= enabled=0 gpgcheck=0 #gpgkey= [asterisk-current] name=centos-$releasever - Asterisk - Current baseurl= enabled=1 gpgcheck=0 #gpgkey= Uložte soubor a vytvořte další nový s názvem: centos-digium.repo a vložte do něj následující text: [digium-tested] name=centos-$releasever - Digium - Tested baseurl= enabled=0 gpgcheck=0 #gpgkey= [digium-current] name=centos-$releasever - Digium - Current baseurl= enabled=1 gpgcheck=0 #gpgkey= Nyní je systém aktualizovaný pro instalaci Asterisku z nových repozitářů. Pro samotnou instalaci potřebných balíčků i samotné Asterisku zadejte do příkazové řádky: yum install asterisk16 asterisk16-configs asterisk16-voic dahdi-linux dahdi-tools libpri V průběhu instalace bude potřeba dvakrát potvrdit pokračování klávesou Y. Po instalaci je jíž ústředna plně funkční a připravena k použití. Zda je Asterisk funkční můžete otestovat příkazem: asterisk vvvgci Instalace pomocí kompilace zdrojových kódů Instalace pomocí kompilace zdrojových kódů je určena převážně pro zkušenější uživatele, umožňuje však nainstalovat Asterisk na různé distribuce operačních systémů, bez potřeby určitých správců systémů typu apt či yum. Níže popsaná instalace je vyzkoušena na distribucích Debian. Samotná kompilace vyžaduje přítomnost některých balíčků v systému. Ty je nutné nejprve doinstalovat. Nejdříve se provede instalace kernel hlaviček: 64

65 apt-get install linux-headers-`uname r` ln -s /usr/src/kernel-headers-`uname -r` /usr/src/linux Poté instalace samotných balíčků potřebných pro kompilaci: apt-get install bison openssl libssl-dev libusb-dev fxload libasound2-dev libc6-dev libnewt-dev libncurses5-dev zlib1g-dev gcc g++ make doxygen libxml2-dev Nyní stáhneme zdrojové kódy z repozitářů Asterisku do adresáře /usr/src. Zkontrolujte prosím aktuálnost verzí: cd /usr/src wget wget wget Dále je nutné stáhnout zdrojové kódy DAHDI. Projekt DAHDI vznikl jako následník projektu Zapata. Projekt Zapata založil Jim Dixon, který byl také zodpovědný za vývoj tohoto revolučního hardwaru pro použití s Asteriskem. Cílem produktu Zapata byla architektura nazývána Zaptel (nedávno přejmenována na Digium Asterisk Hardware Driver Interface - DAHDI). Jednou z hlavních výhod této architektury je schopnost používat procesor počítače pro zpracování streamovaných médií, eliminaci ozvěny a kódování. Do té doby všechny karty používaly k plnění těchto úkolů digitální signálové procesory (DSP). Používání CPU místo DSP rapidně snížilo cenu hardwaru a spousta výrobců začala karty s DAHDI architekturou vyrábět. Na druhou stranu tyto karty vyžadují velké výpočetní prostředky na CPU a to může při větším zatížení negativně ovlivnit kvalitu hlasu. wget wget Všechny stažené soubory dekomprimujeme příkazem: tar xzvf název_souboru.tar.gz Po dekomprimaci zkompilujeme DAHDI moduly: cd /usr/src/dahdi-linux make make install cd /usr/src/dahdi-tools /configure make menusect (volitelné, můžete zvolit několik možností) make make install make config (volitelné, nainstaluje inicializační skripty) Pokud je zadáno make menuselect je možno vybrat pouze nutné moduly pro instalaci. 65

66 Obr. 32. Volba modulů pomocí DAHDI menuselect Po zadání make config jsou nainstalovány inicializační skripty a spustí se detekce hardwarové karty a jejího ovladače. Výpis, který se zobrazí obsahuje informaci o detekovaném hardware a informaci o změně konfiguračního souboru. V našem případě jsme použili kartu Digium TE121: PCI- Express single-port T1/E1/J1 a závěr výpisu vypadá následovně: the DAHDI hardware you have on your system is: pcie:004/002 wcte12xp e2e1:1150 Digium-single no-firmware Systém kartu detekoval správně a nyní je nutné povolit ovladač wcte12xp v souboru /etc/dahdi/modules.ten si otevřeme pro editaci a okomentujeme příslušný řádek s označením ovladače: # Contains the list of modules to be loaded / unloaded by #/etc/init.d/dahdi. # # NOTE: Please add/edit /etc/modprobe.d/dahdi or /etc/modprobe.conf if you # would like to add any module parameters. # # Format of this file: list of modules, each in its own line. # Anything after a '#' is ignore, likewise trailing and leading # whitespaces and empty lines. # Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1 # Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1 # Digium TE220: PCI-Express dual-port T1/E1/J1 # Digium TE420: PCI-Express quad-port T1/E1/J1 #wct4xxp # Digium TE120P: PCI single-port T1/E1/J1 # Digium TE121: PCI-Express single-port T1/E1/J1 # Digium TE122: PCI single-port T1/E1/J1 wcte12xp # Digium T100P: PCI single-port T1 # Digium E100P: PCI single-port E1 #wct1xxp 66

67 Restartujte počítač a zkontrolujte, zda se ovladač nainstaloval správně. Nyní již můžeme zkompilovat samotný Asterisk: cd /usr/src/libpri make make install cd /usr/src/asterisk /configure make menuselect (volitelné, můžete zvolit několik možností) make make install make samples (volitelné, při zadání vytvoří ukázkové soubory Asterisku) make config (volitelné, při zadání nastaví startování Asterisku při bootování počítače) Obr.33. Volba modulů pomocí Asterisk menuselect Pokud se při kompilaci nevyskytly žádné chyby je jíž ústředna plně funkční a připravena k použití. Zda je Asterisk funkční můžete otestovat příkazem: asterisk vvvgci 3.3 Úvod do konfigurace SIPu a plánu volby Po úspěšné instalaci by měl adresář /etc/asterisk/ obsahovat potřebné soubory ke konfiguraci a provozu Asterisku. Pro jednoduchou ukázku konfigurace si vybere jeden: extension.conf. Pokud jsme prováděli instalaci přes kompilaci, je nutné při kompilaci zadat make samples,aby se daný ukázkový soubor vytvořil. Veškeré zde uváděné konfigurace jsou prováděny na operačním systému Linux Debian. 67