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

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Systémy pro VoIP BAKALÁŘSKÁ PRÁCE Ivan Novotný Brno, podzim 2006

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Jan Kasprzak ii

Shrnutí Tato práce shrnuje základní poznaky o Voice over IP službě, která se začíná velice rychle rozvíjet. V první kapitole práce popisuje nutné administrativní kroky k poskytování VoIP, v druhé kapitole popisuje instalaci a použití softwarové telefonní ústředny Asterisk, ve třetí kapitole je popsán způsob napojení telefonní ústředny na externí informační systém, čtvrtá kapitola popisuje zprovoznění služby automatického odpovídače a v páté kapitole jsou uvedena měření výkonu počítače nutného pro provoz softwarové telefonní ústředny Asterisk. iii

Klíčová slova Asterisk, VoIP, SIP, IAX, H.323, Zaptel, Voice over IP, Telephony, Phone iv

Obsah 1 Řesení poskytování VoIP................................. 1 1.1 Požadavky....................................... 1 1.2 Potřebná povolení Českého Telekomunikačního Úřadu............. 1 1.3 Technické řešení.................................... 2 2 Softwarová telefonní ústředna Asterisk......................... 3 2.1 Asterisk základní informace............................ 3 2.2 Instalace Asterisku.................................. 3 2.3 Číslovací plán (extensions.conf)........................... 4 2.4 VoIP protokoly..................................... 6 2.4.1 IAX....................................... 7 2.4.2 SIP....................................... 7 2.4.3 H.323...................................... 8 2.4.4 Využití protokolů v praxi.......................... 9 2.5 Kodeky......................................... 9 2.6 Lokalizace audio nahrávek.............................. 10 2.7 Kvalita služby..................................... 11 2.7.1 SCTP...................................... 11 2.8 Propojení Asterisku s pevnou telefonní sítí.................... 11 2.9 Použití konzole programu Asterisk......................... 13 3 Propojení Asterisku s informačním systémem společnosti............. 14 3.1 Požadavky....................................... 14 3.2 Struktura informačního systému.......................... 14 3.2.1 Datový model................................. 14 3.3 Generování SIP konfigurace............................. 15 3.4 Generování číslovacího plánu............................ 15 3.4.1 Generování seznamu blokovaných čísel a blokovaných destinací... 15 3.4.2 Generování konfigurace hlasových schránek............... 16 3.5 Transport informací o volání............................. 17 3.6 Určení ceny za volání (Billing)............................ 17 3.7 Mesíční fakturace (postpaid)............................. 18 4 Lokální telefonní ústředna................................ 22 4.1 Požadavky....................................... 22 4.2 Softwarové řešení................................... 23 4.2.1 Směrování hovorů.............................. 23 4.2.2 Registr zmeškaných hovorů, vedení statistiky.............. 23 5 Koncoví klienti, zátěžové testy.............................. 24 5.1 Softwaroví koncoví klienti.............................. 24 5.1.1 Twinkle.................................... 24 5.1.2 Ekiga...................................... 24 5.1.3 X-Lite...................................... 24 v

5.2 Zátěžový test ústředny................................ 24 5.2.1 Použitý hardware a software........................ 25 5.2.2 Konfigurace Asterisku............................ 25 5.2.3 Řízení testování................................ 26 5.2.4 Shrnutí výsledků testů............................ 27 6 Závěr............................................. 29 6.1 Přínosy práce..................................... 29 6.2 Možnosti rozšíření softwarového řešení...................... 29 7 Přílohy............................................ 30 7.1 Obsah CD....................................... 30 Bibliografie............................................ 31 vi

Kapitola 1 Řesení poskytování VoIP Lokální poskytovatel internetu se rozhodl ve své síti poskytovat internetovou telefonii. Tato bakalářská práce řeší úvodní část přípravy poskytování VoIP řádově maximálně stovkám klientů, pro širší použití je třeba ještě nějaký čas pokračovat ve vývoji. 1.1 Požadavky Navrhněte a implementujte systém, který umožní uživatelům sítě používat Voice over IP, umožní jim volat z a do pevné a mobilní telefonní sítě, dokáže účtovat cenu za příchozí a odchozí hovory dle definovaných tarifů a případně zpřístupní další služby výhodné pro sít. 1.2 Potřebná povolení Českého Telekomunikačního Úřadu K provozování VoIP jsou potřeba povolení od Českého telekomunikačního úřadu, zejména pokud potřebujeme vlastní rozsah telefonních čísel. V tomto případě je nutné správně vyplnit dva formuláře a zaslat je na Český Telekomunikační úřad (ČTÚ). Prvním formulářem zaregistrujeme subjekt k poskytování služeb dle zákona 127/2005. Subjekt může být zaregistrován k činnostem: Veřejně dostupná telefonní služba Ostatní hlasové služby Pronájem okruhů Šíření rozhlasového a televizního signálu Služby přenosu dat Služby přístupu k síti internet V případě poskytování VoIP je nutno oznámit poskytování Veřejně dostupné telefonní služby a Ostatních hlasových služeb s atributem Veřejně dostupná služba, čímž jsme povinni zprostředkovat službu každému v naší lokalitě, pokud je to technicky možné. Dále je nutno popsat předpokládané zahájení služby, lokalitu, ve které budeme službu poskytovat a zdali budeme službu poskytovat také velkoobchodně. 1

1.3. TECHNICKÉ ŘEŠENÍ K formuláři je nutno doložit výpis z evidence rejstříku trestů osob oprávněných jednat za registrovaný subjekt ne starší tří měsíců, informaci o bezdlužnosti právního subjektu vůči finančnímu úřadu a čestné prohlášení o bezdlužnosti vůči zdravotním pojišt ovnám a správě sociálního zabezpečení. Náklady spojené s registrací firmy činí 5000 Kč bez DPH. Druhý formulář obsahuje žádost o přidělení segmentu telefonních čísel. ČTÚ přiděluje telefonní čísla po segmentech, které obsahují minimálně 10 000 telefonních čísel. V tomto ohledu mi úloha ČTÚ přijde podobná RIPE, která přiděluje segmenty IP adres. Telefonní čísla můžeme dělit na dvě základní oblasti: Geografická telefonní čísla tato telefonní čísla jsou pevně spjata s oblastí, ve které jsou umístěna. Seznam prefixů geografických telefonních čísel lze najít na internetu 1. V rámci internetu můžeme samozdřejmě svůj telefonní přístroj technicky umístit do jiného kraje, popř. jiného státu, ale tím riskujeme, že se v případě volání na tísňové linky dovoláme na tísňovou linku lokality, ve které je zaregistrován telefonní přístroj. Negeografická telefonní čísla tato čísla nejsou svázána s polohou zařízení, jde například o internetová čísla s předčíslím 910. Druhý Formulář musí být doložen stejnými přílohami jako první formulář. Za přidělení segmentu čísel platíme roční poplatek ve výši 1Kč/číslo. To v případě segmentu čísel dělá 10 000Kč/rok bez DPH. Analogicky, paušální ocenění veřejné IP adresy by mohlo vést k žádoucímu vyvážení počtu přidělených IP adres. Pro zajímavost lze uvést, že v České republice je základní rozdělení čísel následující: čísla začínající číslicemi 2,3,4,5 jsou pevné telefonní linky; 6,7 jsou mobilní telefony, 8 a 9 jsou převážně služby. Ustanovení definující rozdělení čísel lze najít na přiloženém CD. ČTÚ má na vyřízení každé žádosti 31 dní v případě správného vyplnění všech údajů a zaplacení správních poplatků. 1.3 Technické řešení Pro telefonní ústřednu jsem použil opensource program Asterisk, běžící na vyhrazeném počítači (Pentium IV; 2,4GHz; 512MB RAM), kterou jsem umístil na rozhraní mezi internetem a lokální počítačovou sítí. VoIP klienti z lokální sítě se připojí přes session initialization protocol (SIP), protože VoIP telefony podporující tento protokol jsou rozšířenější a tím pádem levnější než ostatní produkty. Internetové rozhraní je použito pro komunikaci s externí telefonní (Asterisk) ústřednou jiné firmy, která nám sprostředkovává telefonní hovory do jiných telefonních sítí. Pro tuto komunikaci byl zvolen protokol Inter Asterisk exchange, který má, v případě více telefonních hovorů, menší nároky na šířku pásma a je navržen na propojení Asteriskových ústředen. Více o těchto protokolech lze najít v kapitole 2.4. 1. http://www.ctu.cz/main.php?pageid=74 2

Kapitola 2 Softwarová telefonní ústředna Asterisk Název této telefonní ústředny znamená hvězdička jejím cílem je pokrýt veškeré možnosti telefonních ústředen. Kupodivu se jí to přes nelehkost takového úkolu, dle mého názoru, docela daří. 2.1 Asterisk základní informace První verze Asterisku byla vytvořena panem Markem Spencerem z firmy Digium v roce 1999. Asterisk je vydán pod licencí GPL, která, stručně řečeno, dovoluje jeho bezplatné užívání, studium a modifikaci zdrojových kódů programu. Asterisk funguje na několika operačních systémech Linux, Mac OS X, OpenBSD, FreeBSD a Sun Solaris. Asterisk má velké využití a dnes patří k nejvíce populárním open source programům. Asterisk může být použit například v těchto aplikacích (citováno z [2]). VoIP gateway podporující různé protokoly Pobočková ústředna PBX Voicemail služby s adresářem Softwarová ústředna (Softswitch) Konferenční server (meetme.conf) Překlad čísel Aplikace Calling card 2.2 Instalace Asterisku Pro instalaci Asterisku jsem zvolil linuxovou distribuci Debian Sarge s jádrem řady 2.6. Asterisk je určen primárně pro jádra verze 2.4, ve kterých by měl být dle manuálových stránek stabilnější, než s jádry řady 2.6, ale protože byl Asterisk velice stabilní i na jádře řady 2.6, nebylo třeba měnit jádro. Asterisk není doporučeno provozovat na strojích s procesorem pomalejším než 500MHz, pro nasazení je doporučen procesor o výkonu minimálně 2GHz. 3

2.3. ČÍSLOVACÍ PLÁN (EXTENSIONS.CONF) Dle mých zkušeností se vytížení procesoru i při několika souběžných hovorech na 2GHz procesoru nedostane nad 10%. Zvolil jsem instalaci Asterisku ze zdrojového kódu. Zde popisuji postup instalace: 1. Stáhnutí zdrojových kódů z ftp firmy Digium 1. Budeme potřebovat zdrojové kódy samotného Asterisku asterisk-verze.tar.gz (zde jsou dále audio soubory s nahrávkami a zdrojové kódy zvukových kodeků) a dále přídavné moduly k Asterisku asterisk-addons-verze.tar.gz (zde najdeme podporu komunikace Asterisku s mysql, podporu ukládání informace o hovorech do mysql databáze). 2. Rozbalení a kompilace zdrojových kódů. Asterisk bude nainstalován do adresáře /usr/local, pokud chceme instalační adresář změnit, při použití skriptu configure použijeme parametr prefix=$cesta. Další parametry skriptu configure není nutno měnit. tar xzvf asterisk-verze.tar.gz tar xzvf adsterisk-addons-verze.tar.gz cd asterisk-verze./configure make cd../asterisk-addons-verze./configure make 3. Pro instalaci jsou potřeba práva superuživatele. Doporučuji vytvořit vzorovou konfiguraci. su cd asterisk-verze make install make samples cd../asterisk-addons-verze make install make samples 4. Samotný Asterisk nyní spustíme příkazem asterisk -vvvc a můžeme sledovat, zdali je vše v pořádku spuštěno. 2.3 Číslovací plán (extensions.conf) V možnosti programování číslovacího plánu tkví, dle mého názoru, největší síla Asterisku. Programování číslovacího plánu trochu připomíná psaní kódu v G-Basicu jde o trochu kostrbatější řádkový skriptovací jazyk, který nám ale dovoluje dělat prakticky všechno, co nás v telefonii napadne. Nebere se zde v úvahu velikost písma. Soubor extensions.conf se dělí na hlavní skupiny tzv. kontexty; v rámci jednoho kontextu nastavujeme akce pro jednotlivá vytočená čísla, popř. masky. Tvar: 1. http://ftp.digium.com/pub/asterisk/releases/ 4

[nazevkontextu] exten => extension, priorita, funkce 2.3. ČÍSLOVACÍ PLÁN (EXTENSIONS.CONF) extension = telefonní klapka může být speciální klapka, volané číslo, _maska volaného čísla[/číslo volajícího,_maska čísla volajícího] telefonní číslo je definováno regulárním výrazem [0-9*#]+ masky jsou definovány rozšířeným regulárním výrazem _[0-9*#NZX]+[\.]? 0-9*# odpovídající čísla X = [0-9] Z = [1-9] N = [2-9]. =.* Speciální klapka je definována znaky [ishtto] s = start = použije se, není-li známo volané číslo i = invalid = byla vytočena nedefinovaná klapka (v případě nedefinování i a vytočení nedefinovaného čísla klapky dostaneme chybu 484) t = timeout v časovém limitu nebyla vytočena klapka (nastavení: Set(TIMEOUT(extension) = sekund)) T = absolutní timeout hovor překročil časový limit (nastavení Set(TIMEOUT(absolute) = sekund)) o = operator použití ve voicemailu h = hungup akce při ukončení hovoru Pro každého připojeného klienta, popř. příchozí volání definujeme kontext, který má být použit na jeho volání. Dle vytočeného čísla, popř. čísla volajícího se najde klapka, která vyhovuje a je nejvíce určitá ta se spustí. Priorita je číslo od 1 do n, je to nepřerušená posloupnost čísel řádků skriptu. [mujkontext] exten => _N., 1, Answer() #zvednu sluchátko exten => _N., 2, Dial(SIP/${EXTEN},60) #zavolam pres sip #na obsah proměnné EXTEN = volané číslo a zvoním 60 sekund #pokud je hovor spojen, skript končí #pokud není volající dostupný, pokračujeme prioritou n+1 #pokud je volající obsazený, pokračujeme prioritou n+101 exten => _N., 3, PlayBack(nebereto) #přehraje audio soubor exten => _N., 4, Hangup() exten => _N., 103, PlayBack(obsazeno) exten => _N., 104, Goto(4) #skok na prioritu 4 5

2.4. VOIP PROTOKOLY 2.4 VoIP protokoly Citováno z [5]: Pro přenos hlasu se používá na třetí vrstvě OSI modelu protokol IP, na čtvrté vrstvě protokol UDP. V těle jednotlivých UDP datagramů se kromě dalších údajů přenáší malý úsek telefonního hovoru, zakódovaný podle určitého pravidla (algoritmu) k dosažení úspory objemu přenášených dat. Kódovací a dekódovací algoritmy, zkráceně kodeky, mají různá označení (G.711, G.723, G.729,...) a jsou standardizovány a ze značné části bohužel i patentovány. Kvalitní kodek speciálně vyvinutý pro VoIP a neomezovaný softwarovými patenty je například SPEEX. Kromě UDP datagramů, nesoucích o vrstvu výš v protokolu RTP 2 zapouzdřené úseky vlastního hovoru, zahrnuje VoIP přenos ještě další pakety. Jsou to např. ICMP pakety a též datagramy TCP a UDP. Ty řídí přenos, nesou telefonní signalizaci, ověřují dostupnost komunikujících zařízení atd. Rozbor protokolů samozřejmě nekončí na čtvrté vrstvě. Jak bylo naznačeno, na páté vrstvě obsahují hovorové UDP datagramy protokol RTP (Real Time Protocol) a ten teprve má jako náklad v sobě zakódované kousky hovoru. Asterisk podporuje tyto protokoly a kodeky: IAX (= IAX2) SIP H.323 MGCP Skinny/SCCP UNISTIM Pro modulaci a demodulaci hlasu používá tyto kodeky, které se liší hlavně použitou šířkou pásma a kvalitou přenášených multimediálních dat. G.711 G.726 G.723.1 G.729A GSM ilbc 2. RFC 2198, 2733, 2793, 2833, 2959, 3389, 3550, 3551, 3611, 3711 6

2.4. VOIP PROTOKOLY Speex MP3 Paketové sítě byly vytvořeny hlavně pro potvrzené doručování paketů, ale u přenosu multimediálních dat je důležitější neměnné zpoždění u hlasové komunikace, než ztráta několika slabik. Proto se zde používá nepotvrzovaný přenos dat, který má pro tuto činnost lepší předpoklady, protokol UDP. VoIP spojení funguje na dvou vláknech (příchozí a odchozí data) mezi každými dvěma body na cestě. Pojmy: Realtime Transport Protokol slouží pro přenos multimediálních dat. Používá UDP porty 10 000 až 20 000. signalizace slouží pro předávání zpráv (navázání hovoru, položení sluchátka, apod..). 2.4.1 IAX IAX (Inter Asterisk exchange) protokol vznikl, již dle názvu, kvůli propojení dvou ústředen Asterisk, ale díky jeho vlastnostem se jeho použití rozšířilo a dnes již můžeme najít i VoIP hardwarové telefony podporující tento protokol. Jeho zvláštností je hlavě použití jediného portu (UDP, 4569) pro komunikaci. Vkládá zde RTP i signalizaci, dále do tohoto datového proudu dokáže vložit mnoho různých spojení. Tento přístup má mnoho výhod: 1. Menší nároky na šířku pásma (ušetříme hlavičky paketů) 2. Jednodušší nastavení firewallu a klasifikace provozu 3. Dokáže se lépe vypořádat s NATem než ostatní protokoly IAX byl optimalizován pro přenos hlasu, prozatím není optimalizovám pro přenos videa. IAX nebyl zatím standardizován a je otevřený, tj. každý na něm může dále pracovat. Je binární pro signalizaci zde slouží 4 byty, což je oproti textové SIP signalizaci výhoda jednoúčelová zařízení používající tento protokol mohou být řádově jednodušší, na druhou stranu textovou SIP signalizaci dokážeme jednodušeji ladit. IAX podporuje tři typy autentizace: plain text, MD5 hash, výměnu RSA klíčů; bohužel prozatím nepodporuje šifrování vlastní komunikace. Pro šifrování vlastní komunikace by bylo dobré použít šifrovaný tunel. Podporu pro protokol IAX v Asterisku zajistuje modul chan_iax2.so. 2.4.2 SIP Session Initiation Protocol 3 byl vydán v roce 1999 je dnes nejrozšířenějším protokolem na poli VoIP. Na trhu se velice rychle prosadil na úkor v minulosti dominantního protokolu H.323 dnes je již velice těžké nalézt hardwarové telefony nepodporující tento protokol. 3. RFC 2543, 3261-3265, 3853 7

2.4. VOIP PROTOKOLY Používá oddělený signalizační a datový tok pro signalizaci používá TCP nebo UDP protokol (standardně port 5060) a pro RTP používá UDP protokol. Byl vytvořen, jak již název napovídá, k navazaní spojení mezi dvěmi a více stranami a stanovení parametrů spojení. SIP signalizace je, podobně jako další internetové protokoly(http, SMTP) textová, tudíž se s ní dá jednoduše pracovat. SIP servery mohou fungovat jako SIP proxy v této roli zastupují klienty při předávání sip požadavků na další server. Dále znají redirect umí transitivně přesměrovat datový tok na další server na cestě. V Asterisku je standardně zapnuta funkce canreinvite, díky které může Asterisk propojit RTP streamem přímo koncová zařízení tudíž datově nenáročná signalizace prochází dále přes Asterisk, ale hlas jde přímo mezi oběma body. Bohužel, tato velice hezká vlastnost má problémy s Network Address Translation (s NAT). Pokud jsou totiž obě strany spojení za NAT, pak nemůže žádná z obou stran adresovat tu druhou. Protože je velice těžké postihnout všechny případy, je nutno v mnoha případech funkci canreinvite vypnout. SIP byl vytvořen pro přenos jakéhokoliv real-time multimédia, at již hlasu, videa, či hudby díky tomu ho pravděpodobně čeká velká budoucnost. SIP pro komunikaci používá TLS Transport Layer Security pro navázání spojení mezi volajícími a volanými, bohužel již nešifruje RTP, které musíme zašifrovat odděleně. SIP je náchylný na Denial of Service (DoS) útoky SIP proxy přijímá požadavek INVITE, na který odpovídá řetězcem, který se použije, spolu s heslem, na vytvoření MD5 hashe. Je velice snadné poslat SIP proxy serveru mnoho INVITE požadavků a tím jej zahltit. Podporu pro protokol SIP v Asterisku zajišt uje modul chan_sip.so. 2.4.3 H.323 H.323 4 Je jeden z prvních VoIP protokolů, byl vytvořen v roce 1996. Měl přenášet hlas, video, data a faxovou komunikaci přes IP paketové sítě a udržovat spojení s pevnou telefonní sítí. Ve své době se stal velice rozšířeným protokolem. Je to velice komplexně navržený protokol, což je dnes spíše na škodu věci. Je rychle vytlačován novějšími protokoly, jako jsou SIP nebo IAX. Jeho budoucnost není dobrá přes svou složitost neposkytuje pro IP sítě lepší vlastnosti než výše zmíněné protokoly SIP a IAX. Také H.323 používá protokol RTP pro přenos multimediálních dat, který je nešifrovaný pro šifrování je potřeba protokol zabalit do šifrovaného tunelu. Protože H.323 protokol používá RTP stejným způsobem jako SIP, má také podobné problémy při průchodu NATem. Kvůli tomuto problému existuje například OpenH323 Gatekeeper 5. Asterisk nedokáže fungovat jako H.323 gatekeeper. V Asterisku pro H.323 protokol podporu zajišt uje modul chan_h323.so dodaný s Asteriskem, popř. doplňujícím modulem chan_oh323.so. 4. RFC 2205, 3550, 3551 5. http://www.gnugk.org 8

2.5. KODEKY 2.4.4 Využití protokolů v praxi Pro propojení Asteriskových ústředen je dle mého názoru nejlepší protokol IAX, který činnost byl pro tuto činnost přímo navržen. Oproti SIP i H.323 protokolu využívá pouze jediné trvalé spojení, což přináší mnoho výhod oproti protokolu SIP potřebuje menší šířku pásma. Výhoda jediného kanalu pro signalizaci i datový proud je jednodušší detekce chyby spojení bud funguje, nebo nefunguje. U jiných protokolů se může stát, že přijde signalizace zvednutí sluchátka, ale nemusíme nic slyšet problém při navázání RTP spojení. SIP je oproti H.323 otevřený standard, který se stále vyvíjí. Je mnohem jednodušší zde přidávat nové funkce a můžeme očekávat větší flexibilitu. Například pro identifikaci volaného můžeme použít textový řetězec a ne pouze telefonní číslo. Pro propojení Asteriskových ústředen jsem z výše uvedených důvodu použil protokol IAX a pro koncové klienty protokol SIP. 2.5 Kodeky Kodek (COde, DECode) je matematický algoritmus, který zajišt uje kódování a dekódování zvukového signálu do digitální podoby. Je jich několik druhů jejich hlavními parametry jsou: Šířka pásma nutná pro přenos zvuku Kvalita přenášeného zvuku (MOS) Zátěž na procesor (převážně při kódování) Zdali je kodek volně k použití, nebo si musíme koupit licenci Různí klienti podporují proměnnou periodu vzorkování/paketizaci. Asterisk však podporuje pouze paketizaci 20ms v RTP založených protokolech, je tedy potřeba klienta s ohledem na tuto skutečnost nakonfigurovat. Citováno[2]. Název kodeku Algoritmus Šířka pásma MOS Licencován G.711 (ulaw, alaw) PCM 64Kbit/s 4.1 ne G726 ADPCM 32Kbit/s 3.85 ne G.729 CS-ACELP 8Kbit/s 3.92 ano G723.1 MP-MLQ/ACELP 5.3/6.3Kbit/s 3.9 ano GSM RPE-LP 13Kbit/s 3.5 ne SPEEX SPEECH 2-24Kbit/s? ne Tabulka 2.1: Tabulka kodeků U kodeků, které používají patentované algoritmy, si musíme koupit licenci na každý souběžně otevřený hovorový kanál používající tento kodek pro 10 simultálně běžících 9

2.6. LOKALIZACE AUDIO NAHRÁVEK hovorů nad kodekem G.729 si musíme koupit 10 licencí. Cena licence na použití G.729 kodeku se dnes pohybuje okolo deseti doladů na jeden probíhající hovor. Licenci si musíme kupovat pouze v případě, kdy kódujeme nebo dekódujeme kodekem G.729 pokud děláme most mezi dvěma G.729 kódovanými proudy dat, licenci nepotřebujeme. Některé kodeky přenášejí přímo syrová data, některé se snaží data komprimovat, aby se snížila šířka pásma nutná pro přenos zvuku zde je nevýhoda větší zátěže CPU počítače. Pokud Asterisk dělá bránu mezi spojeními fungujícími na rozdílných kodecích, musí dvakrát dekódovat a kódovat data, což při větším počtu hovorů přináší netriviální zátěž procesoru. Kodeky jako G.729 se například na zvuk snaží napasovat vzory, které odpovídají lidskému hlasu, některé další kodeky se snaží posílat diference mezi jednotlivými časovými úseky, což ale při přenosu přes nekvalitní médium může přinášet velice nekvalitní přenos hlasu. Dle tabulky je vidět, že šířka pásma u určitých kodeků je řádově jiná. 2.6 Lokalizace audio nahrávek Asterisk dovoluje připojenému klientovi přehrát audio soubor, který má uložený na disku tohoto se v telefonii využívá pro různá hlasová menu a pro další informování volající strany. V Asterisku se nejvíce používají audio soubory gsm formátu. Pokud ale hovor probíhá v jiném kodeku, potom musí Asterisk provést retranslaci do zvoleného kodeku, což je výpočetně náročná operace. Proto je vhodné při velkém využívání audio nahrávek mít nahrávky uložené ve vhodném formátu. Spuštění přehrávání souboru nastavíme v číslovacím plánu souboru extensions.conf (2.3). Audio soubory jsou standardně uložené v adresáři /var/lib/asterisk/sound. Zde najdeme podadresáře, jejichž název udává jazyk, ve kterém jsou audio nahrávky. V našem případě vytvoříme adresář cs, do kterého umístíme audio soubory. Adresář by měl obsahovat standardní audio soubory jako číslovky, uvítání do hlasové schránky (VoiceMailu), apod. Použitý jazyk nastavíme v globální proměnné LANGUAGE v číslovacím plánu: exten => s,1,set(language=cs) Adresáře se zvukovými soubory nemusíme rozdělovat jen podle jazyků, ale zdřejmě také podle vlastního kritéria (např. mužský/ženský hlas). Pro převod wav souborů na gsm soubory je možno použít program Sox 6. Příklad použití programu Sox: sox soubor.wav -r 8000 soubor.gsm resample -ql Příkaz převede wav soubor do gsm při vzorkování 8kHz. 6. http://sox.sourceforge.net 10

2.7. KVALITA SLUŽBY 2.7 Kvalita služby Pro přenos hlasu přes IP je nutná jistá úroveň kvality služeb (Quality of Service, QoS). Pro zhruba plynulou komunikaci stačí, aby se latence mezi oběma účastníky hovoru pohybovala maximálně mezi 200-300ms, při zhruba 500ms se objevuje efekt vysílačka jedna strana mluví a druhá poslouchá. Pro přenos hlasu je samozdřejmě mnohem lepší použít protokol UDP, protože nám nevadí případná ztráta paketu, zato potřebujeme co nejlepší latenci. Z hlediska klasifikace provozu je pro nás nejjednodušší zachytit komunikaci s protokolem IAX, protože používá jediný port, u ostatních protoklů bych doporučil klasifikovat provoz dle IP adres známých VoIP zařízení a serverů. #Značkování VoIP paketů na routerech #IAX iptables -t mangle -A FORWARD -p udp --dport 4569 \ -j MARK --mark $voipmark #SIP #stačí značkovat RTP, signalizace není tak důležitá foreach $voipdev ($voipdevs) { iptables -t mangle -A FORWARD -p udp \ -s $voipdev -d $Asterisk -j MARK --mark $voipmark iptables -t mangle -A FORWARD -p udp \ -d $voipdev -s $Asterisk -j MARK --mark $voipmark } 2.7.1 SCTP Stream Control Transmission Protocol (SCPT) 7 protokol, který má vzít to nejlepší z TCP a UDP pro přenos hlasu. Především by měl poskytnout nižší latenci pro datové přenosy v reálném čase a lepší ochranu např. proti útokům odmítnutí služby. 2.8 Propojení Asterisku s pevnou telefonní sítí Asterisk také umožňuje propojení s pevnou telefonní sítí s public switched telephone network (PSTN). To nám umožňuje využít výhod PC softwarové telefonní ústředny na pevné síti, dokonce můžeme hovor jdoucí po IP síti poslat na pevnou telefonní sít a naopak. Asterisk se k pevné telefonní síti dá připojit pomocí ISDN pro jednokanálové spojení, pro vícekanálové propojení můžeme použít Zaptel rozhraní tyto PCI karty prodává například firma Digium, která zastřešuje vývoj samotného Asterisku. Tyto karty mají jeden a více portů pro konektor RJ11, který je používán v klasické, analogové telefonii. Pro použití Zaptel rozhraní je třeba mít nainstalovaný kernelový modul, jehož zdrojové 7. RFC 2960 11

2.8. PROPOJENÍ ASTERISKU S PEVNOU TELEFONNÍ SÍTÍ kódy se dají stáhnout na FTP firmy Diginum 8. Pro jádro řady 2.6 zkompilujeme zdrojové kódy Zaptelu (je nutno mít zdrojové kódy jádra):./configure make clean make linux26 (pro jadra verze 2.6) make install-udev (pokud používáme udev) Vlastní modul načteme pomocí příkazu: modprobe zaptel modprobe modul_karty ;dle typu karty Pro konfiguraci Zaptel rozhraní používáme dva konfigurační soubory: /etc/zaptel.conf nastavení hardwaru například nastavení jazyka tónů ( tone language ) rozpoznání oznamovacího tónu, obsazené linky a podobně. Různé země používají různé jazyky tónů. V nových verzích Asterisku je doporučeno použít program genzaptelconf, který provede automatické vygenerování konfigurace. Znovunačtení konfiguračního souboru provedeme pomocí příkazu /sbin/ztcfg -vv. /etc/asterisk/zapata.conf konfigurace rozhraní Asterisku pro přístup k Zaptel hardwaru. V nových verzích Asterisku je zde umístěn typ signalizace, který byl dříve v zaptel.conf. Znovunačtení konfiguračního souboru provedeme pomocí příkazu reload z konzole Asterisku. Základní rozdělení signalizace na PSTN síti je na FXO a FXS signalizaci. FXO signalizace negeneruje vyzváněcí tón tudíž ji použijeme při propojení Asterisku s telefonní sítí telefonního operátora. FXS vyzváněcí tón generuje, tudíž k tomuto portu můžeme připojit standardní pevnou telefonní linku. Podrobnější popis signalizací lze najít v literatuře[4]. Základní konfigurace zapata.conf vypadá: ;zapata.conf language=en context=prichozi signalling=fxo_ks callerid=571999111 ;jazyk použitý pro přehrávání zvukových souborů ;kontext, do ktereho se smeruji prichozi hovory ;typ signalizace ;nase cislo Konfigurační soubor zapata.conf mnoho dalších nastavení, které lze najít v literatuře[4]. Díky Zaptel rozhraní je Asterisk velice silným nástrojem, který dovoluje dělat most mezi analogovou a IP telefonní sítí, popř. mezi různými analogovými sítěmi. Dokáže velice dobře zastoupit drahá (ve smyslu výkon/cena) a mnohem méně robustní řešení. 8. ftp://ftp.diginum.com/pub/telephony/zaptel/ 12

2.9 Použití konzole programu Asterisk 2.9. POUŽITÍ KONZOLE PROGRAMU ASTERISK Program Asterisk obvykle běží na pozadí jako démon a můžeme se k němu připojit z lokálního počítače pomocí konzole. Pokud jsme připojení, můžeme sledovat akce, které provádí Asterisk a sami mu zadávat příkazy. V této podkapitole bych rád upozornil na často používané akce. Operace příkazové řádky: asterisk spuštění vlastního démona Asterisk asterisk -r připojení ke konzoli asterisk -vvvr připojení ke konzoli, úroveň upovídanosti 3 asterisk -rx "cmd" spuštění příkazu konzole z shellu Operace konzole Asterisku: sip show peers ukáže připojené SIP klienty, jejich IP, pokud je nastaven atribut klienta qualify na yes, pak ukáže také latenci mezi Asteriskem a klientem iax2 show peers podobně jako u SIP reload kompletní znovunačtení konfigurace probíhající hovory nejsou přerušeny restart gracefully restart ústředny v okamžiku, ve kterém neprobíhá žádný hovor show channels zobrazí seznam kanalů vhodné ke sledování probíhajících hovorů database show zobrazí obsah interní databáze Asterisku tvar klíč, hodnota Konzole Asterisku se velice dobře používá umí doplňovat příkaz pomocí tabulátoru a vše je hezky logicky uspořádané. Dále je zde možno sledovat probíhající volání průchod volání číslovacím plánem a další informace o běhu Asterisku. Při větším vytížení programu je lepší pro tento případ využít logovacích souborů, než konzole Asterisku. 13

Kapitola 3 Propojení Asterisku s informačním systémem společnosti 3.1 Požadavky Je třeba vytvořit uživatelsky přívětivé rozhraní pro základní konfiguraci Asterisku, integrované do informačního systému společnosti. Toto rozhraní by se mělo by se o: 1. Generování konfiguračního souboru sip.conf z tabulky připojených zařízení 2. Generování konfiguračního souboru extensions.conf (dialplan) směrování hovorů, blokování hovorů, Voicemail 3. Vést tabulku hovorů (volání odkud, kam, délka volání) 4. Zjištění ceny hovorů (billing) 3.2 Struktura informačního systému 3.2.1 Datový model Část informačního systému společnosti, která se stará o VoIP služby komunikuje i s ostatními částmi informačního systému, zejména pak s účtováním služeb a testem klienta, jestli má splacené veškeré pohledávky vůči firmě. Klient, který tuto podmínku nesplňuje, bude mít volání z VoIP telefonu zablokováno (příjem hovorů zústane aktivní). V ERD diagramu najdeme především tabuky VoipBill, VoipCalls, VoipNets, VoipTariffs, VoipPrefix tyto tabulky obsluhují výhradně VoIP služby. Tabulky Clientstech, Clients, Money patří do jiné části informačního systému, s VoIP mají spojitost po řadě se seznamem povolených VoIP zařízení, seznamem klientů a seznamem pohledávek vůči klientům. Vkládání údajů o povolených VoIP zařízeních je prováděno přes rozhraní informačního systému, ostatní (převážně statické) údaje jako je seznam prefixů VoIP sítí, ceny za volání do jednotlivých sítí jsou vkládány přímo do databáze. Operátor vkládá do systému údaje o VoIP zařízeních jednotlivých klientů, po vložení údajů dá povel k novému generování a znovunačtení konfigurace ústředny. Ve většině případů lze znovunačtení konfigurace provést bez restartu ústředny.ústředna poskytuje informace o proběhlých hovorech, které se ukládají do entity money, z které je na konci měsíce vygenerována pohledávka vůči zákazníkovi. 14

3.3. GENEROVÁNÍ SIP KONFIGURACE 3.3 Generování SIP konfigurace SIP konfiguraci generuji z tabulky clientstech, ktera vede informace o vsech zarizenich na siti ip adresa, mac, dns, propojeni s tabulkou klientu, atd.. Pro ucely VoIP jsem pridal pole: VoIP atribut, který uvádí, že jde o VoIP zařízení Voipnum číslo telefonu, zároveň sip login do Asterisku Voippass sip heslo do Asterisku Voiptariff spoj s tabulkou tarifů, kvůli účtování Voipmask další číslo, pod kterým je telefon dostupný v rámci naší ústředny (tvar *číslo) Z některých z výše uvedených hodnot generuji konfigurační soubor Asterisku sip.conf. Soubor obsahuje třídu pro každého SIP klienta: [$Voipnum] ;název třídy, na který se odkazujeme ;např. u funkce Dial(SIP/$VoipNum) username=$voipnum ;login type=friend ;zařízení může volat skrz Asterisk ;a Asterisk může volat na zařízení qualify=no ;neprovádět ping port=5060 nat=never ;na síti nepoužívám NAT mezi telefony a ústřednou mailbox=$email ;zde jsou zasílány hovory zaznamenané voicemailem host=dynamic ;autentizace dle jména a hesla, nikoliv dle IP secret=$voippass ;heslo dtmfmode=rfc2833 ;způsob přenosu signalizace context=$callcontext ;kontext, který je použit při volání callerid=$clients.name ;jméno volajícího Po vygenerování konfiguračního souboru provedu znovunačtení SIP konfigurace Asterisku příkazem asterisk -rx "sip reload". 3.4 Generování číslovacího plánu 3.4.1 Generování seznamu blokovaných čísel a blokovaných destinací SIP klienti, kteří jsou připojeni k ústředně, mají při vytočení čísla nastaven kontext, který testuje, zdali je volání z tohoto čísla povoleno a zdali je povoleno volání na cílovou destinaci. Tento kontext obsahuje konkrétní pravidla, která zablokují volání. Pokud hovor není zablokován, volání je předáno do volajícího kontextu. Blokování všech hovorů z čísla je v číslovacím plánu zapsáno: 15

3.4. GENEROVÁNÍ ČÍSLOVACÍHO PLÁNU exten => _[0-9*#+]./$CISLO,1,Playback(blokovan,noanswer) exten => _[0-9*#+]./$CISLO,n,Wait,4 exten => _[0-9*#+]./$CISLO,n,Goto(1) Parametr noanswer způsobí, že zvukový soubor je přehrán bez automatického zavolání funkce Answer volajícímu není zaúčtováno volání. Bez zavolání funkce Answer není možno zasílat data směrem k volanému, lze zasílat data pouze od volaného k volajícímu. Blokování hovorů na určitou destinaci (v tomto případě na prefix destinace) z telefonního čísla je v číslovacím plánu zapsáno: exten => _$DESTINACE./$CISLO,1,Playback(blokovan,noanswer) exten => _$DESTINACE./$CISLO,n,Wait,4 exten => _$DESTINACE./$CISLO,n,Goto(1) Pokud není hovor zablokován, je přesměrován do kontextu obsluhujícím volání: exten => _[0-9*#+]., 1, Goto(default,${EXTEN},1) Kontext obsluhující volání zachytává volání na lokální čísla a pokud není volání zachyceno, pak je volání přesměrováno IAX spojením na Asterisk server firmy poskytující propojení s ostatními telefonními sítěmi. Pokud není v časovém limitu hovor přijat, je přesměrován do hlasové schránky. exten => $CISLO,1,Dial(SIP/$CISLO,50,r) exten => $CISLO,2,VoiceMail($CISLO@default); exten => $CISLO,3,Hangup Přesměrování hovoru na jiný Asterisk server: exten => _X.,1,Dial(IAX2/login:password@server/${EXTEN}) exten => _X.,2,Hangup 3.4.2 Generování konfigurace hlasových schránek Soubor voicemail.conf obsahuje definice a nastavení hlasových schránek ve tvaru: [třída] číslo_schránky => heslo, jméno, email, pager email, nastavení Pokud chceme do hlasové schránky nahrát vzkaz, v číslovacím plánu zavoláme funkci VoiceMail(číslo_schránky@třída). Pomocí skriptu createsip.pl generuji také tento soubor, a to ve tvaru: [default] $telefonní_číslo =>, $jméno, $email,, attach=yes Nastavení attach=yes způsobí, že dokončení nahrávání hlasové zprávy Asterisk zašle notifikaci o správě ve schránce na email uživatele a nahranou zprávu zašle v emailové příloze (formát souboru wav). Heslo je pro přístup ke hlasové schránce přes telefonní přístroj tuto možnost v Asterisku nepoužívám. 16

3.5. TRANSPORT INFORMACÍ O VOLÁNÍ 3.5 Transport informací o volání Asterisk u sebe ukládá informace o volání do mysql databáze nazvané Asteriskcdrdb. Najdeme v ní veškeré údaje o volání, která procházela přes náš Asterisk server u každého volání najdeme: datum a čas volání, zdrojové a cílové číslo, použitý kontext, délku volání (včetně zvonění), délku vlastního hovoru (sloupec billsec), stav volání(no answer, answered)... Pro naše účely jsou důležitá odpovězená volání, která jdou z telefonů našich klientů a mají nenulovou délku vlastního hovoru. Údaje o těchto volání přenáším pomocí skriptu transfer.pl z Asteriskové ústředny do vlastní databáze do tabulky voipcalls. Abychom přenášeli pouze nová data, přidal jsem do tabulky cdr databáze Asteriskcdrdb příznak transfered. Přenos spouští každých 5 minut program cron. Nyní všechna přesunutá data již jen čekají na ocenění. 3.6 Určení ceny za volání (Billing) O určení ceny u každého hovoru se stará oddělený proces, který cron spouští každých 5 minut v případě oceňování většího počtu volání mohu tento proces volat méně často. Každý hovor má v tabulce voipcalls příznak charged, který určuje, zda-li byl tento hovor již oceněn. Ocenění hovoru závisí především na: 1. Tarifu volajícího 2. Cílové telefonní síti 3. Denní době (ve špičce/mimo špičku) O vlastní ocenění hovorů se stará skript charge.pl, zejména SQL dotaz, který minimalizuje počet připojení k databázi: #SQL select CALL. id,voipprefix.netid, #výpočet času, který se má zaúčtovat \@chargedtime:= ((firstunit/60+ if (sec-firstunit<=0,0, ((sec - firstunit-1) div nextunit + 1) *nextunit/60) )*60), #výpočet ceny (connectfee + if ( CALL. time >= $CONFIG::OFFPEAKSTART 17

or CALL. time <= $CONFIG::OFFPEAKEND, offpeak,unitfee) * \@chargedtime/60 ) as prize 3.7. MESÍČNÍ FAKTURACE (POSTPAID) from (select voipcalls.id,src, dst, max(format) as format, time(calldate) as time,sec from voipcalls, voipprefix WHERE dst LIKE format AND charged = 0 group by voipcalls.id,dst) as CALL, #zjištění prefixu volané sítě voipprefix, clientstech, voipbill, voipnets where voipprefix. format = CALL. format and CALL. src LIKE concat( %,clientstech.voipnum) and voipbill.tariffid = clientstech.voiptariff and voipbill.netid = voipprefix.netid and voipprefix.netid = voipnets.id group by CALL. id Rád bych zmínil především způsob, jakým zjišt uji, která cílová sít je odpovídající. Pokud mám hovor na některé cílové číslo, pak musím najít cílovou sít, která odpovídá zadané masce (voipnets.format) a přitom je nejvíce určitá podobně, jako v IP směrovací tabulce. Vycházím z toho, že ord( % ) a ord( _ ) je menší, než ord( 0 ) a zároveň znaky % a _ se dají v SQL jazyce použít jako zástupné znaky.* a.. Kvůli zjednodušení vedu záznamy o sítích v tomto tvaru (pole voipnets.format). Pokud nyní použiji SQL: WHERE dst LIKE format, kde dst je volané číslo, dostanu seznam podezdřelých sítí. Pokud z tohoto seznamu vezmu maximální prvek (funkce max), dostanu kýženou nejpřesněji určenou sít. Po tomto kroku mám již oceněné jednotlivé hovory a stačí vystavit a poslat fakturu. 3.7 Mesíční fakturace (postpaid) Z údajů o ceně jednotlivých hovorů program makepays.pl na konci každého měsíce přesune podklady o ceně hovorů do seznamu pohledávek vůči klientovi. Z těch poté jiná část informačního systému vystaví fakturu. Výsledný tvar pohledávky: Volání 9. měsíc, 2006 sít : Česko -- mobilní sítě, čas: 20:00 minut; cena 80,0 Kč Volání do jednotlivých sítí mohu rozlišit dle pole netid tabulky voipbill. 18

3.7. MESÍČNÍ FAKTURACE (POSTPAID) Každá telefonní sít může mít dle ERD více prefixů ve tvaru číslo země + předčíslí sítě. U prefixu sítě můžeme použít zástupný znak % pro více číslic, zástupný znak _ pro jednu číslici. Volání do každé sítě je ceněno dle tarifu zákazníka a denní době hovoru. Každý tarif má kromě ceny hovoru ve špičce a mimo špičku i cenu za spojení, délku první jednotky a délku každé další. Entity clientstech, clients a Money jsou součástí jiné části informačního systému společnosti, zmiňuji zde pouze důležité atributy těchto entit. Obrázek 3.1: ERD diagram VoIP ISu 19

3.7. MESÍČNÍ FAKTURACE (POSTPAID) Entity money(pohledávky) a clients(klienti) jsou externí součásti systému. Obrázek 3.2: Kontextový diagram VoIP ISu 20

3.7. MESÍČNÍ FAKTURACE (POSTPAID) Obrázek 3.3: DFD0 diagram VoIP ISu 21

Kapitola 4 Lokální telefonní ústředna Tato kapitola ukazuje další velice užitečné použití Asterisku jako lokální telefonní ústředny. 4.1 Požadavky Kvůli častým telefonickým dotazům uživatelů na telefonní operátory firmy vznikla nutnost nějakým způsobem rozdělit telefonické hovory do kategorií a na základě podmínek (zejména časových údajů) přesměrovat hovor na určené místo. Tato kapitola lze použít jako příklad řešení modelové situace využití softwarové telefonní ústředny Asterisk vhodným nastavením Číslovacího plánu a vytvořením externí aplikace. Důvody podrobně: Volání klientů mimo pracovní dobu Volání klientů na telefonní číslo určené jiné službě Necentralizované přesměrování hovorů v případě nedostupnosti jednoho pracovníka Chybějící vedení statistik hovorů Řešení se bude opírat o jediné telefonní číslo pro klientelu, na kterém bude jednoduché hlasové menu, které klientův požadavek přepošle dále. Požadavky podrobně: Rozdělení menu na čtyři části: Informace pro nové klienty Fakturace Servis Ostatní V případě dostupnosti více pracovníků řešící danou oblast vybrat vhodného. V případě nedostupnosti pracovníka přesměrovat hovor na někoho jiného, popř do hlasové schránky. 22

4.2. SOFTWAROVÉ ŘEŠENÍ Možnost naplánování pohotovosti pokud bude klient volat mimo pracovní dobu, pak přesměruj volání na pohotovostní číslo. Na každý den by mělo být možno nastavit jiné pohotovostní telefonní číslo každý den může mít pohotovost jiný pracovník. 4.2 Softwarové řešení 4.2.1 Směrování hovorů Směrování hovorů řeším v souboru na přiloženém CD menu.conf, který je používán číslovacím plánem. Při vytvoření spojení je klientovi přehrán zvukový soubor, který se volajícímu dá na výběr z několika možností. Volající stiskem klávesy vybere jednu z nich a dle aktuálního času pokud volá v pracovní době je přesměrován na telefonního operátora, v jiném případě je přesměrován na pohotovostní číslo, popř. do hlasové schránky. V pracovní době se ústředna snaží spojit s více telefonními čísly a hovor je přesměrován na prvního telefonního operátora, který je volný. Pomocí funkce Monitor je hovor (pokud je spojen) nahráván a ukládán do wav souboru pro pozdější dohledání v případě výskytu problému v telefonickém rozhovoru. Plánování pohotovosti je řešeno databázovou tabulkou obsahující den jako primární klíč a pohotovostní telefonní číslo. Každý den o půlnoci provádím celkový reload konfigurace ústředny při tomto reloadu nastavím do proměnné [query] POHOTOVOST [/query] v číslovacím plánu pohotovostní telefonní číslo pro tento den. 4.2.2 Registr zmeškaných hovorů, vedení statistiky V souboru menu.conf, který se stará o správné směrování hovorů lokální telefonní ústřeny používám klapku h, která je volána po ukončení hovoru. Zde do interní databáze Asterisku pomocí funkce Set(DB(klíč)=hodnota) ukládám informace o volání, které jsou potřeba pro vedení statistiky. 23

Kapitola 5 Koncoví klienti, zátěžové testy 5.1 Softwaroví koncoví klienti 5.1.1 Twinkle Twinkle je open source projekt fungující pod operačním systémem Linux, který pro komunikaci používá protokol SIP. Je možno jej připojit k ústředně, ale dovoluje také přímou komunikaci mezi dvěmi IP adresami. V programu můžeme používat více SIP účtů, program také dovoluje mít naráz otevřené dva komunikující kanály a libovolně mezi nimi přepínat. Program také dovoluje předávat hovory, hovory pozdržet, nebo také vytvořit konferenční hovory. Program nepodporuje videokonference. Twinkle podporuje kodeky G.711, gsm, speex, ilbc a G726. Má navíc velice příjemné ovládání, dle mého názoru je to ideální SIP klient. 5.1.2 Ekiga Ekiga je open source projekt fungující pod operačním systémem linux, který je dnes asi nejvíce rozšířený jeho původní název byl GnomeMeeting. Pro komunikaci používá protokoly H.323 a SIP, dokáže pracovat se stejnými kodeky, jako program Twinkle, navíc podporuje video kodeky. Oproti programu Twinkle podporuje také videokonferenční hovory. Ze všech uvedených programů obsahuje nejvíce funkcí. Na jejích webových stránkách je možno si zaregistrovat SIP účet. 5.1.3 X-Lite X-Lite je softwarový telefonní klient od firmy CounterPath používající protokol SIP. Funguje pod operačními systémy Linux, Mac OS a Windows. Tento klient nepodporuje videokonferenční hovory. Program podporuje méně kodeků podporuje pouze kodeky G.711, gsm, ilbc a Broadvoice-32. 5.2 Zátěžový test ústředny Jedním ze zajímavých témat je kolik telefonních hovorů dokáže zpracovat jedna softwarová telefonní ústředna Asterisk. V této kapitole ukazuji výsledky svých testů zátěže. 24

5.2. ZÁTĚŽOVÝ TEST ÚSTŘEDNY Následující testy ukazují, jak moc bylo vytížené PC se softwarovou ústřednou, přes kterou procházelo velké množství simulovaných telefonních hovorů. Hlavní rozdělení testů je rozdělení na hovory, na které musela být použita retranslace a na hovory, u kterých retranslace použita být nemusela (Asterisk použije native bridge ). retranslace je použita, pokud vstupní kodek je rozdílný od kodeku výstupního pak musí telefonní ústředna dekódovat (demodulovat) data do čisté podoby a pak je zakódovat (modulovat) pomocí druhého kodeku. native bridge je použit v případě, že kodek na vstupu, i na výstupu se shoduje. Ústředna pouze přeposílá multimediální data dále Je zřejmé, že při použití retranslace je hardware zatěžován mnohem více, než při použití mostu. Proto by měl administrátor ústředny zvolit vhodné kombinace kodeků navíc i s ohledem na minimalizaci pravděpodobnosti použití retranslace. Pro testy jsem použil tři osobní počítače s telefonní ústřednou Asterisk: 1. počítač generoval volání, 2. počítač byl most mezi volajícím a volaným, ze kterého jsou použita měření a 3. počítač byl použit jako ústředna odpovídající na volání. 5.2.1 Použitý hardware a software Pro testy byl použit tento hardware a software: Počítač generující volání: Intel Pentium IV, 2,4GHz, 512MB RAM, distribuce Ubuntu, jádro 2.6.17, Asterisk verze 1.2.12 Testovaný počítač most: Intel Pentium IV, 2,4GHz, 512MB RAM, linuxová distribuce Debian Etch, jádro 2.6.17, Asterisk verze 1.2.13 Počítač odpovídající: Intel Pentium IV, 2,4GHz, 1GB RAM, linuxová distribuce Ubuntu, jádro 2.6.17, Asterisk verze 1.2.12 5.2.2 Konfigurace Asterisku Jednotlivé počítače byly propojeny IAX2 trunkem s konfigurací: #iax.conf - PC - generovani volani [general] bindport=4569 bindaddr=0.0.0.0 disallow=all ; zakazeme vsechny kodeky a povolime pouze jeden allow=$kodek [most] type=friend 25

5.2. ZÁTĚŽOVÝ TEST ÚSTŘEDNY host=$ip_mostu username=login secret=password context=default trunk=yes PC, ktere přijímalo volání mělo iax konfiguraci stejnou, až na rozdílný kodek (v případě retranslace). Most měl iax konfiguraci také podobnou, pouze měl povolené všechny kodeky a obsahoval identifikaci obou dalších ústředen. Dále měl nastavený atribut notransfer na yes atribut znamenající to samé, jako negace atributu canreinvite u SIP (předávání RTP streamu). Konfigurace číslovacího plánu byla zajímavější. První konfigurační soubor je konfigurační soubor počítače generujícího volání první klapku používám pro loopback, druhou klapku pro volání na most: #volající server [default] #loopback exten=> 1,1, Answer() exten=> 1,n, Wait(1000) exten=> 1,n, Hangup() #volani na most exten=> 2,1, Dial(IAX2/$IP_MOSTU/1@default) Na mostu pouze předávám hovor dále: #most [default] exten=> 1,1,Answer() exten=> 1,2,Dial(IAX2/$IP_ODPOVIDAJICIHO/1@default) exten=> 1,3,Hangup() A na odpovídající ústředně jsem přehrával zvukový soubor: #odpovídající ústředna [default] exten=> 1,1, Answer() exten=> 1,n, PlayBack(testsound) exten=> 1,n, Goto(1,2) 5.2.3 Řízení testování Testování bylo řízeno skriptem v jazyce Perl, který běžel na dalším počítači. Řídící počítač spouštěl příkazy vzdáleně pomocí ssh klienta, kde autentizace probíhala pomocí rsa klíčů. Pro testování jsem zvolil kodeky gsm, alaw, ulaw a g726. Vlastní test probíhal: 26

5.2. ZÁTĚŽOVÝ TEST ÚSTŘEDNY 1. Zvolení dvojce kodeků 2. Nový start telefonních ústředen tímto krokem zajistím, aby průběh minulého testu nemohl ovlivnit test další 3. Postupné přidávání hovorů a měření zátěže testovaného počítače každých 5 sekund jsem přidal další hovor do maximálního počtu 200 hovorů a údaje s výsledky měření jsem uložil do souboru na řídícím počítači. Prováděl jsem měření těchto údajů: Vytížení procesoru v prostoru jádra Vytížení procesoru v uživatelském prostoru Využitá pamět Vytížení sítě Údaje o vytížení testovacího počítače jsem četl pomocí programů top (využitá pamět ) a sar (vytížení procesoru a sítě). Na systémech neběžel žádný další software schopný zkreslit údaje o vytížení. 5.2.4 Shrnutí výsledků testů Na přiloženém CD je možno nalézt výsledky testů ve formě textových souborů. Z testů vyplynulo, že Asterisk, pokud nemusí provádět retranslaci, zvládne na výše uvedených zařízeních 167 souběžně běžících hovorů. Po překročení tohoto čísla již není možno navazovat další hovory, při vzniku volání volající obdrží chybovou zprávu CHANUNAVAIL kanál není dostupný. V několika případech došlo dokonce i k jednotlivému zrušení některých spojení. K hromadnému rušení existujících spojení došlo až v případě, kdy jsem při velkém počtu souběžně běžících hovorů nastavil odpovídající Asterisk, aby prováděl funkci SayUnixTime() v tomto případě load average zařízení vystoupal k hodnotě cca 20 a poté došlo k okamžitému zrušení všech aktivních spojení. Z hodnot vytížení sítě je možno vysledovat, že při větším počtu hovorů (bez retranslace), kdy je vytížení procesoru trvale na 100%, dochází ke ztrácení dat na Asterisk přichází více dat, než z něj odchází. Předpokládám, že některé hovory při extrémním vytížení Asterisku ohluchly. Z těchto hodnot lze také vyčíst, že hovor v alaw formátu má šířku pásma 83,4Kbit a hovor v gsm formátu má šířku pásma 33,5Kbit. Celkově má IAX overhead zhruba 20Kbit. Při retranslaci mezi kodeky s rozdílným kódovacím algoritmem již Asterisk potřeboval více procesorového času při retranslaci z kodeku alaw do kodeku g726 Asterisk zvládl 113 hovorů, pokud jsme retranslaci prováděli opačným směrem, pak zvládl 152 hovorů. Vytížení procesoru při menším počtu aktivních hovorů bylo velice proměnlivé, při větším počtu hovorů se vytížení procesoru skokově dostalo ke skoro 100%. Pro toto chování 27