FAKULTA INFORMATIKY MASARYKOVY UNIVERZITY
Návrh systému clicktocall s využitím Asterisku Bc. Ivan Novotný
ii
iii
Prohlášení: Prohlašuji, ţe tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování pouţíval nebo ze kterých jsem čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
V Brně dne 10. března 2011 Bc. Ivan Novotný
Vedoucí práce: Ing. Josef Hájek
iv
v
Poděkování: Děkuji panu Ing. Josefu Hájkovi za cenné rady, připomínky a čas, který mi při psaní této diplomové práce věnoval, dále děkuji panu RNDr. Václavu Lorencovi za garanci této práce v rámci Fakulty informatiky Masarykovi Univerzity.
vi
Shrnutí: Diplomová práce pojednává o návrhu systému pro spojování telefonních hovorů třetí stranou softwarovou telefonní ústřednou Asterisk. Hovor je iniciován ústřednou, nejprve dojde ke spojení hovoru mezi ústřednou a zákazníkem sluţby, tento hovor je nadále spojen s volaným číslem. Práce dále pojednává o hledání nejlevnější a nejvhodnější cesty pro spojení telefonního hovoru, o účtování, o rozloţení zátěţe mezi servery sluţby, o odolnosti systému vůči výpadku jednoho ze serverů a popisuje, jaké jsou zkušenosti s reálným provozem systému.
Klíčová slova: VoIP, Asterisk, Clicktocall, 3pcc, High availability, Load ballancing, VoIP billing, Least cost routing
vii
viii
Obsah 1
2
Popis sluţby clicktocall .................................................................................................................... 1 1.1
Co je clicktocall ........................................................................................................................ 1
1.2
Současný stav řešené problematiky clicktocall ......................................................................... 2
Vyuţité komponenty a technologie .................................................................................................. 3 2.1
Základní popis technologií ........................................................................................................ 3
2.2
Voip protokoly .......................................................................................................................... 4
2.2.1
SIP ................................................................................................................................... 4
2.2.2
RTP.................................................................................................................................. 5
2.3
Kodek ........................................................................................................................................ 6
2.4
Asterisk ..................................................................................................................................... 7
2.4.1
Vytáčecí plán ................................................................................................................... 7
2.4.2
Asterisk Management Interface ....................................................................................... 9
2.4.3
AGI .................................................................................................................................. 9
2.5
Perl ............................................................................................................................................ 9
3
Poţadavky na systém ..................................................................................................................... 10
4
Návrh.............................................................................................................................................. 10 4.1
Komponenty systému.............................................................................................................. 10
4.2
Komunikace mezi komponentami systému pomocí fronty příkazů ........................................ 13
4.3
Propojení s terminacemi ......................................................................................................... 14
4.4
Základní průběh hovoru .......................................................................................................... 15
4.4.1
Vyčerpání kreditu na účtu ve vztahu k hovoru .............................................................. 16
4.4.2
Zaloţení hovoru pomocí rychlé volby ........................................................................... 17
4.4.3
Vlastní směrování hovoru.............................................................................................. 17
4.5
5
Uloţení dat a struktura databáze ............................................................................................. 18
4.5.1
Import ceníků terminací ................................................................................................ 18
4.5.2
Výpočet ceny účtované zákazníkovi ............................................................................. 27
4.5.3
Evidence zákazníků ....................................................................................................... 31
4.5.4
Tabulky uchovávající informace o hovorech ................................................................ 38
4.6
Administrativní rozhraní systému ........................................................................................... 41
4.7
Zabezpečení ............................................................................................................................ 42
4.8
Kodeky .................................................................................................................................... 42
Průchody systémem ....................................................................................................................... 43 5.1
Spojení hovoru přes zákaznický web ...................................................................................... 43
5.2
Funkce rychlé volby................................................................................................................ 45
5.3
Hovor a výpadek serveru ........................................................................................................ 46
5.4
Další průchody systémem ....................................................................................................... 46 ix
6
Implementace a nastavení komponent systému ............................................................................. 47 6.1
Asterisk ................................................................................................................................... 47
6.2
Konvence uloţených databázových procedur ......................................................................... 47
6.2.1
Vzorové uloţené procedury pro klientské rozhraní ....................................................... 47
6.2.2
Uloţené procedury pro práci s frontou příkazů ............................................................. 49
6.3
7
Zabezpečení ............................................................................................................................ 50
6.3.1
Zabezpečení vůči zneuţití terminací ............................................................................. 50
6.3.2
Zabezpečení administrátorského přístupu a přístupu ke stavům hovorů ....................... 50
6.3.3
Implementace firewallových a směrovacích pravidel ................................................... 51
Závěr .............................................................................................................................................. 53 7.1
Zkušenosti s nasazením a během systému .............................................................................. 53
7.2
Shrnutí..................................................................................................................................... 55
8
Bibliografie .................................................................................................................................... 56
9
Přílohy ............................................................................................................................................ 58 9.1
Obrázky frontendu sluţby klikniavolej.cz .............................................................................. 58
9.2
Obrázky administrativního rozhraní ....................................................................................... 60
9.3
Přiloţené soubory ................................................................................................................... 61
x
1
Popis služby clicktocall
1.1 Co je clicktocall Telefonní hovory jsou obvykle spojovány vytočením telefonního čísla druhé strany na telefonním přístroji. V případě úspěšného spojení probíhá hovor mezi stranou, která poţádala o spojení a stranou, která je identifikována zvoleným telefonním číslem. Systémy clicktocall vyuţívají moţnosti spojit telefonní hovor třetí stranou - „third party call kontrol” – 3pcc[1].
3pcc ústředna
Strana A
Strana B Obrázek 1-1: Schéma komunikace 3pcc ústředny.
3pcc ústředna se nejprve pokusí vytvořit komunikační kanál se stranou A, pokud je hovor úspěšně spojen, vytvoří komunikační kanál se stranou B, v případě úspěchu oba kanály spojí a hovor můţe probíhat stejně, jako by šlo o přímé propojení mezi stranami A a B s tím rozdílem, ţe signalizace stavu hovoru a v některých případech i zvuková data procházejí přes 3pcc ústřednu.
Jelikoţ hovory zahajuje 3pcc ústředna, náklady na spojení hovoru jsou (minimálně v českých podmínkách) na straně vlastníka 3pcc.
Hovor je zahájen na základě externí události. Příklady vyuţití sluţby:
spojení hovoru v určitém čase – budík, připomenutí schůzky externím systémem reakce na kritickou událost – např. při správě počítačové sítě – Strana B je nahrazena audiozáznamem popisující nastalou událost. 3pcc ústředna zavolá technika, jeţ má sluţbu a tento audiozáznam mu přehraje. Výhoda oproti sms notifikaci je v tom, ţe systém má zpětnou informaci o tom, zdali technik správu převzal. zahájení přes webové stránky o náhrada za zelenou linku – zákazník má zájem o telefonní spojení s firmou, na jejích webových stránkách vyplní své telefonní číslo a 3pcc jej spojí a to na náklady firmy. Tímto způsobem clicktocall sluţbu vidí wikipedie [2] o levnější volání – v některých případech je volání pomocí 3pcc levnější neţ přímé telefonní spojení. Jedná se zejména o mezinárodní hovory. pomocí sms – zahájení hovoru pomocí mobilního telefonu Zahájení prozvoněním určitého telefonního čísla – zahájení hovoru pomocí jakéhokoliv telefonního přístroje
1
Vyuţití systému, který budu dále popisovat, je zejména v levném mezinárodním volání mezi telefony pevné telefonní sítě a v náhradě za zelenou linku. Zahájení hovoru je moţno provést pomocí webu a prozvoněním telefonního čísla.
1.2 Současný stav řešené problematiky clicktocall Je obtíţné najít technické informace k systémům, které se podobají systému navrţeném v této diplomové práci. Většina z nich funguje na komerční bázi, jsou to poskytovatelé sluţeb clicktocall, mají své vlastní řešení, jehoţ dokumentace není dostupná. Ze systémů, které nabízejí clicktocall bych rád zmínil:
jajah.com – pravděpodobně nejvíce známá a pokročilá sluţba s obrovským počtem uţivatelů o podobně jako systém popsaný v této diplomové práci umí: spojit 2 telefonní čísla přes web autentizace telefonního čísla je provedena tak, ţe sluţba zavolá na zaregistrované telefonní číslo a zde stiskem klávesy 1 dojde k aktivaci účtu. Varianta popsaná v této práci je jiná – volání musí provést aktivně zákazník sluţby, prozvoní číslo sluţby clicktocall, kde mu je v jednostranně přehranném audiu řečeno, ţe sluţba byla aktivována. Tento typ hovoru je zdarma. Varianta vyuţitá sluţbou Jajah není zdarma. Na druhou stranu není moţno autentizované číslo podvrhnout změnou čísla volajícího (callerid) o oproti navrţenému systému umí spojit konferenční hovor, tj. 3 a více účastníků o umoţňuje přiřadit lokální telefonní čísla pro kontakty, které jsou pro zákazníka zahraniční. Zákazník volá na lokální telefonní číslo sluţby jajah ve své zemi, platí lokální propojovací poplatek svému telefonnímu operátorovi a sluţbě Jajah platí peníze za propojení se zahraničním telefonním číslem. V součtu by to mělo vyjít levněji, neţ přímé volání. Pro tuto sluţbu má systém navrţený v této práci alternativu, která je aktivována prozvoněním lokálního telefonního čísla sluţby clicktocall. Poté dojde ke spojení z 3pcc ústředny, více kapitola 4.4.2. Výhoda tohoto řešení spočívá v levnějším navázání hovoru, nevýhodou je trochu obtíţnější pouţití, které se vymyká běţnému vyuţití telefonního přístroje. o má webovou aplikaci umoţňující vytvářet hovory z mobilního telefonu. Sluţba, která je poskytována na základě návrhu v této práci, toto rozhraní nemá o Jajah dále navíc obsahuje rozhraní pro navázání hovorů v rámci sociální sítě Facebook, či Twitter o nejsem schopen srovnat, jakým způsobem má Jajah řešeno přímé propojení telefonních čísel, zdali vyuţívá sluţeb třetích celosvětových operátorů, jako sluţba navrhnutá v této práci, nebo jestli má přímá propojení s telekomunikačními operátory provozující pevné telefonní sítě (PSTN, vysvětleno dále).
Mezi open source existují řešení, která mají některé schopnosti systému navrţeného v této práci. Je ale problém je spojit v jeden funkční celek, který například zajišťuje dostupnost sluţby při výpadu jednoho ze serverů.
2
Perlový modul Asterisk::LCR[3] – umoţňuje vygenerovat statický vytáčecí plán (viz kap. 2.4.1) na základě cen několika pevně daných terminačních operátorů (starají se o ukončení hovoru v pevné telefonní síti). Nedává však zpětnou vazbu, zdali se hovory přes daného operátora podařilo navázat. Při kaţdé změně konfigurace je nutno znovu vygenerovat další statický vytáčecí plán. o systém popsaný v této práci pracuje s aktuálním stavem databáze, zaznamenává v ní informace o hovorech, které se přes daného terminačního operátora nepodařilo navázat. Příště tohoto operátora znevýhodní při volbě. vysoká dostupnost softwarových telefonních ústředen je ve většině případů vyřešena pomocí plovoucí IP adresy, která je přiřazena hlavní (MASTER) ústředně. V případě jejího pádu dojde k jejímu přesunu na záloţní ústřednu. K tomuto vyuţívají různé variace na VRRP protokol [4], které monitorují stav druhé telefonní ústředny. o tyto systémy nemonitorují aktuálně probíhající hovory na jednotlivých serverech sluţby, a tudíţ při výpadku sluţby nedokáţí přesně stanovit cenu proběhlých hovorů
Výhody v systému navrţeném v této diplomové práci jsou v tom, ţe je systém postaven na open source komponentách, případně na komponentách, které jiţ měl odběratel systému zakoupeny (MSSQL databáze). Odběrateli tudíţ, kromě nákladů na návrh systému, jeho implementaci a hardware, nevznikaly ţádné další náklady pro spuštění. Vazba na typ databáze je volná, implementaci systému lze v rozumném čase přepsat do jiného SQL dialektu.
2 Využité komponenty a technologie 2.1 Základní popis technologií Voice over Internet Protocol (dále VoIP) je technologie pro přenos digitalizovaného hlasu pomocí datových paketů vyuţívající IP protokol [5]. Dnes se pro VoIP komunikaci pouţívá nejčastěji kombinace protokolů.
SIP [6] – Session Invitation Protocol – stará se vlastní navázání a přenos signalizace (stavu) hovoru. Pracuje na UDP protokolu. SDP[7]– Session Description Protocol – slouţí pro vyjednání parametrů hovoru, jako je pouţitý kodek [8], transportní protokol či přenosová rychlost [9]. o RTP [10] – Realtime Transport Protocol – přenáší hlasová (video) data, která jsou digitalizována pomocí kodeků. Pracuje na UDP protokolu.
Public Switched Telephone Network (dále PSTN) je síť zaloţená na pevném propojování okruhů – na začátku spojení dojde ke stanovení trasy, po které proudí data. Výpadek na trase znamená výpadek celého hovoru. Je to pevná a mobilní telefonní síť, která nevyuţívá internetu jako prostředku pro propojení telefonního hovoru.[11]
3
2.2 Voip protokoly 2.2.1 SIP Session Initiation Protocol[6], který 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. Drtivá většina dnes pouţívaných hardwarových a softwarových telefonů vyuţívá SIP protokol. SIP pouţívá oddělený signalizační a datový tok – pro signalizaci pouţívá TCP nebo UDP protokol (standardně port 5060) a pro multimediální data pouţívá zejména RTP protokol fungující nad UDP. Byl vytvořen, jak jiţ název napovídá, k navázaní spojení mezi dvěma 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 multimediální datový tok na další server na cestě. V Asterisku je standardně zapnuta funkce canreinvite, díky které můţe Asterisk propojit RTP proudem 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 (NAT [12]). 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 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šťuje modul chan_sip.so. Obrázek Obrázek 2-1 ukazuje schéma komunikace mezi dvěma účastníky VoIP hovoru.
4
Obrázek 2-1: Schéma navázání a průběhu VoIP hovoru založeného na SIP protokolu [6].
2.2.2 RTP Real-time Transport Protocol (dále RTP) je protokol standardizující paketové doručování zvukových a obrazových (video) dat po IP sítích. Protokol se často pouţívá v systémech proudového přenosu, jako zejména IP telefonie a videokonference. Přenáší pro ně datové toky vyjednané signálními protokoly, (jako jsou H.323, SIP – nebo přesněji SDP), čímţ je jedním z technických základů VoIP technologií. [13] Přestoţe je RTP schopno vyuţít také moţností TCP protokolu, převáţná většina implementací vyuţívá UDP. U audio nebo video záznamu nehraje ztráta paketu takovou roli. Buď dojde ke krátkému výpadku videa, nebo zvuku, nebo korekční algoritmy (dopředné opravování chyb) kousek záznamu zrekonstruují. U TCP protokolu při výpadku paketů dojde ke sníţení velikosti Congestion window [13], coţ můţe při nedostatečné velikosti vyrovnávacích pamětí na cíli znamenat mnohem větší ztráty – zaseknutí komunikace do doby, neţ se velikost Congestion window dostane na rychlost, která je nutná pro přenos daného hlasu nebo videa. Pro sledování kvality RTP proudu slouţí protokol Real-Time Transport Control Protocol (dále RTCP). RTCP slouţí pro sledování latence, jitteru (rozptylu latence) a počtů ztracených paketů. Tyto informace slouţí jako zpětná vazba o kvalitě sluţby. Zatímco RTP pouţívá sudé UDP porty, RTCP obvykle komunikuje na portu o 1 vyšším neţ aktuální RTP relace [14].
5
Asterisk vyuţívá sluţeb RTP u H.323 a SIP protokolů, v případě propojení na IAX2 (Inter-Asterisk eXchange) [15] protokolu vyuţívá pro přenos signalizace, zvukových a video dat schopností IAX2 protokolu – nedochází k rozdělení dat do více nezávislých proudů.
2.3 Kodek Kodek (COde, DECode) je matematický algoritmus, který zajišť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 – hodnoceno lidmi (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 nakonfigurovat s ohledem na tuto skutečnost [10].
Tabulka 2.1. Tabulka kodeků 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
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 hovorů nad kodekem „G.729“ si musíme koupit 10 licencí. Cena licence na pouţití G.729 kodeku se dnes pohybuje okolo deseti dolarů 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.
6
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.4 Asterisk Asterisk je softwarová telefonní ústředna. První verze Asterisku byla vytvořena Markem Spencerem z firmy Digium v roce 1999. Asterisk je vydán pod licencí GPL [16], která dovoluje jeho bezplatné uţívání, studium a modifikaci zdrojových kódů programu. Asterisk funguje na několika operačních systémech – Windows, Linux, Mac OS X, OpenBSD, FreeBSD a Sun Solaris. Asterisk má velké vyuţití a dnes je v oblasti IP telefonie jednou z nejvíce pouţívaných telefonních ústředen. Asterisk můţe být pouţit například v těchto aplikacích [10]:
VoIP gateway podporující různé protokoly Gateway propojující pevnou PSTN a IP telefonní sítí pobočková ústředna – PBX Voicemail sluţby s adresářem softwarová ústředna (Softswitch) konferenční server (meetme.conf) 3PCC
Asterisk umí komunikovat s VoIP telefonní sítí, pomocí dodatečnému hardwaru je schopný komunikovat i s PSTN. Lze pouţít jako most mezi PSTN a VoIP sítí. Pro spojení s okolní telefonní sítí (dále komunikační spojení) pouţívá tyto prostředky a protokoly:
VoIP o o o PSTN o o o
SIP IAX H323 T1, E1 – umoţňují vícekanálové propojení FXO, FXS – pro malé instalace, připojující jednotlivé telefonní analogové přístroje Cellilax ovladače – umoţňují propojení s mobilní telefonní sítí [17]
Souseda, se kterým mám navázáno komunikační spojení, budu dále v textu nazývat Peerem, případně Terminací.
2.4.1 Vytáčecí plán Vytáčecí plán (dále Dialplan) je součást konfigurace Asterisku, skriptovací programovací jazyk, ve kterém je naprogramován průběh telefonních hovorů. 7
Kaţdý klient, který je připojen k Asterisk serveru, myšleno i klient PSTN sítě, případně 3PCC, má v Dialplanu vstupní bod – kontext, ve kterém je řečeno, jakým způsobem s telefonátem od klienta zacházet. Dialplan na základě zdrojového telefonního čísla, cílového telefonního čísla, kláves stisknutých v průběhu hovoru (DTMF[18]) a případných dalších atributů provede nakonfigurované akce. Nejdůleţitější akce jsou:
vytočení telefonního čísla přes některé z aktivních komunikačních spojení (v případě VoIP protokolů je moţno místo telefonního čísla pouţít URI). Asterisk umoţňuje zjistit, zdali se spojení povedlo a případně vytočit další telefonní číslo, nebo provést jinou akci přehrání zvukového záznamu (základ telefonních menu) zaznamenání hovoru na pevný disk volání externího skriptu
Díky velice zdařilému zobecnění programujeme Dialplan prakticky stejně, ať jiţ pracujeme s VoiP telefonní sítí nebo s PSTN.
Klapka (extension) je nejdůleţitějším atributem, který je předáván protokolu, díky kterému je spojován hovor. Ve většině případů je klapka telefonní číslo, ale můţe jít o libovolný alfanumerický řetězec. Na základě klapky a kontextu (odkud vlastně hovor přišel) cílová terminace zvolí, jakou akci s hovorem (hovorovým kanálem – viz dále) provede.
2.4.1.1 Funkce Dial, pojem kanálu Funkce Dial je jednou ze základních funkcí vytáčecího plánu, která se stará o samotné volání. Má 3 povinné parametry: 1. řetězec pro spojení hovoru: PROTOKOL/parametry, příklad: SIP/klapka@terminace – volá pomocí SIP protokolu na klapku za pouţití terminace IAX2/login@terminace/klapka - volá pomocí IAX2 protokolu na danou terminaci LOCAL/klapka@kontext – vytvoří kanál, který se spojí s lokálním Asteriskem na danou klapku a kontext 2. timeout – čas, po kterém je funkce dial ukončena, pokud nedojde ke spojení hovoru. Po tuto dobu funkce Dial čeká na spojení hovoru, který je například ve stavu vyzvánění 3. parametr obsahující další nastavení, například: nastavení maximální délky uskutečněného hovoru (vyuţito v aplikaci pro nastavení maximální délky hovoru na základě kreditu zákazníka) chování po dokončení hovoru (zdali pokračovat ve vytáčecím plánu a podobně) povolení přesměrování hovoru hraní musiconhold – hudby na pozadí, která hraje místo vyzváněcího tónu
8
V Asterisku je po zavolání funkce Dial nebo po přijetí hovoru druhé strany vytvořen tzv. kanál. Ten se objeví v určitém stavu (vyzvánění, hovor uskutečněn, apod.). Pojem kanálu dobře ilustruje příklad volání z VoIP telefonu skrz Asterisk: 1. VoIP telefon je připojen k ústředně Asterisk pomocí SIP protokolu. Na telefonu je vytočeno telefonní číslo. 2. mezi telefonem a Asteriskem je vytvořen kanál 3. Asterisk zavolá funkci Dial na cílové telefonní číslo pomocí některé ze sluţeb, které poskytuje; To vytvoří nový kanál 4. Asterisk propojí oba kanály, přes které jdou informace o stavu hovoru a v některých případech také zvuková, či video data hovoru
2.4.2 Asterisk Management Interface Asterisk Management Interface (dále AMI) je rozhraní Asterisku, které pomocí plaintext protokolu umoţňuje komunikovat s Asteriskem externím programům. Po plaintext autentizaci je moţno vyuţít AMI pro:
vyvolání akce Asterisku sledování, jak vyvolaná akce dopadla sledování Asterisk událostí vyvolané jádrem Asterisku, nebo Asterisk
Příklady konkrétního vyuţití:
sledování stavu hovoru (kanálu) vytvoření kanálu (hovoru) ukončení hovoru nastavení maximální délky hovoru, po které jej Asterisk sám ukončí zjištění stavu peeringu – propojení s ostatními telefonními ústřednami
2.4.3 AGI Asterisk gateway interface umoţňuje v číslovacím plánu vyvolat externí skript, který na základě vstupních hodnot vrátí část číslovacího plánu. Toto jej dělá dynamickým. S externím skriptem je také moţno komunikovat pomocí TCP soketu. V systému navrţeném touto diplomovou prací je AGI vyuţito zejména pro inteligentní výběr vhodné a funkční terminace.
2.5 Perl Perl je skriptovací programovací jazyk, který byl vytvořen Larry Wallem v roce 1987. Původně to měl být silný nástroj pro zpracování textů, coţ lze vidět v tom, ţe velkou součástí syntaxe jazyka jsou regulární výrazy. V 90 letech získal PERL popularitu jako CGI skriptovací jazyk. Perl je výborný pro programy, které ve velké míře dělají rozhraní mezi jinými systémy, oblíbenými oblastmi jsou kombinace webových sluţeb, databáze, či generování konfiguračních souborů pro programy unixových systémů.
9
3 Požadavky na systém Systém byl navrţen a naprogramován pro společnost MAFRA, a.s., která byla provozovatelem sluţby klikniavolej.cz. Původní poţadavky jsou shrnuty do následujících bodů:
vysoká dostupnost (high availability) – při výpadku komponenty systému nesmí dojít k jeho kompletní nefunkčnosti Load balancing – systém bude rozkládat zátěţ rovnoměrně mezi servery sluţby Prepaid - účtování pomocí předplaceného kreditu – kaţdý uţivatel má svůj účet obsahující kredit počet souběžně fungujících hovorů – jeden telefonní server musí zvládat minimálně 150 souběţných telefonních hovorů zobrazení aktuálního stavu hovoru – na webové stránce je vidět, v jakém stavu se aktuální hovor nalézá MSSQL – Systém musí pouţívat MSSQL databázi – poţadavek MAFRy, a.s. – tuto databázi pouţívají pro svá data pro jiné sluţby, mají vyřešené zálohy databáze při výpadku serveru Minimalizace vytížení databáze – pokud je to moţné, snaţit se data cachovat, nebo nějakým způsobem obcházet databázi, aby nedocházelo k jejímu zbytečnému vytěţování terminace – systém musí umoţňovat propojení s PSTN pomocí více peerů připojených pomocí SIP protokolu detekce nedostupnosti terminace – systém automaticky zjistí nefunkčnost terminace a v tom případě přes ni nebude směrovat hovory a upozorní dohled systému detekce nedostupnosti předvolby – pokud přes některou terminaci nefunguje určitá předvolba, pak systém automaticky znevýhodní volaní na předvolbu touto terminací. Operace má vyšší prioritu neţ Least Cost Routing. Least Cost Routing – systém musí být schopen vybrat nejlevnější funkční cestu do cílové telefonní sítě rychlá volba – systém umoţňuje zaloţit hovor pomocí prozvonění určitého telefonního čísla zabezpečení – systém musí být zabezpečen proti zneuţití, zejména takovém, ve kterém můţe dojít k finančním škodám registrace telefonů – jelikoţ pro 3PCC je třeba změnit zdrojová telefonní čísla, je třeba zabránit zneuţití sluţby ke spojování cizích telefonních čísel. Toto je provedeno registrací a autentizací telefonů vůči systému
4 Návrh V této kapitole je popsán návrh jednotlivých částí systému – kaţdé části samostatně. Propojení jednotlivých částí je popsáno v kapitole 5, která přibliţuje, jakým způsobem dochází k vytvoření a průběhu vlastního hovoru, přičemţ se vyuţijí všechny komponenty systému.
4.1 Komponenty systému Systém se skládá z následujících komponent. Schéma jejich komunikace je znázorněno v obrázku Obrázek 4-1. U všech komponent jde o tzv. backend sluţby clicktocall, kromě vyznačeného frontendu. 10
http
FRONTEND Klientský interface (.NET) Admin interface (Perl)
http
telnet
Ramdisk
Ramdisk telnet Databáze - MSSQL
fronta příkazů; SQL Démon 2 (POE)
Démon 1 (POE)
AGI, AMI
AGI, AMI
Asterisk 2
vrrp
Asterisk 1
SIP, RTP
SIP, RTP SIP
Terminace 1
SERVER 1
Terminace 2
Terminace rychlé volby
SERVER 2
Obrázek 4-1: Schéma komunikace komponent systému.
Systém se skládá z frontendu a backendu:
frontend jsou webové stánky pro zákazníky projektu klikniavolej.cz backend se stará o veškerou funkcionalitu
Backend je provozován na 2 serverech, které obsahují softwarovou telefonní ústřednu Asterisk, démona, který se stará o velkou část systému clicktocall, databázi, která je pamětí systému a terminační operátory, kteří se starají o zakončení hovoru v cílové síti (PSTN). V případě nedostatečného výkonu serverů je moţno zvýšit výkon systému přidáním dalšího – systém je moţno velice dobře škálovat. Vysoká dostupnost (High availability) ústředny je zajišťována tím, ţe se většina stavové informace ukládá do databáze. V případě výpadku démona, či Asterisku dojde k přerušení hovorů, které fungují skrz aktuální server, ale velká většina stavových informací je uloţena v databázi, jejíţ vysoká dostupnost je zajištěna mimo téma této diplomové práce. Zde je popis jednotlivých komponent systému:
11
databáze – v zadání projektu bylo vyuţití MSSQL databáze, kterou provozovatel clicktocall projektu vyuţívá také pro další sluţby, má zajištěnou zálohu databáze v případě výpadku jednoho z databázových serverů. asterisk – viz. kapitola Chyba! Nenalezen zdroj odkazů.. Stará se o vlastní uskutečnění telefonního hovoru. démon – hlavní součást systému – stará se o komunikaci mezi jednotlivými komponentami systému, zejména mezi Asterisky a databází. Zpracovává události, které nastávají v Asterisku, reaguje na události, které byly přidány do fronty příkazů, a podobně. terminace (1..N) – starají se o vlastní ukončení hovorů v PSTN terminace rychlé volby – na tuto terminaci je zaregistrováno 1000 telefonních čísel, pokud je na ně zavoláno z PSTN, tato událost se pomocí SIP protokolu a VRRP dostane na aktivní Asterisk ústřednu, která je za pomocí démona schopna na toto volání reagovat admin interface – webové rozhraní pro administrátory systému ramdisk – zde démon ukládá informace o stavu jednotlivých hovorů, které jsou pomocí webového serveru poskytovány frontendu. Frontend se na stav hovorů můţe ptát také databáze, toto řešení bylo zvoleno kvůli sníţení zátěţe databáze. Klientské rozhraní se opakovaně ptá (polling, kaţdou sekundu) na stav hovoru, coţ v případě více současných telefonních hovorů zbytečně zatěţuje databázový server. Zobrazení stavu hovoru, které je uloţené na ramdisku, je méně náročné.
Komponenty systému spolu komunikují:
asterisky s terminacemi spolu komunikují pomocí SIP a RTP protokolu – kaţdý server sluţby má aktivní SIP propojení se všemi terminacemi, tj. kaţdý server je schopen volat přes všechny terminace do celého světa. Telefonní hovor je spojen jedním konkrétním Asteriskem, tj. pakety RTP a SIP protokolu jdou ze zdrojové terminace na ústřednu sluţby a zde pokračují do cílové terminace. terminace rychlé volby je propojena s jedním konkrétním Asteriskem, který vyhrál volby vrrp protokolu, tj. pokud dojde k výpadku serveru s plovoucí vrrp IP, dojde k vytvoření SIP spojení se serverem, který má nastavenou další nejvyšší prioritu démoni komunikují s Asterisky pomocí AGI a AMI protokolu o AMI – Asterisk Management Interface umoţňuje posílat příkazy Asterisku jako je zahájení hovoru a podobně o AGI – Asterisk Gateway Interface umoţňuje dynamicky měnit vytáčecí plán démoni komunikují s MSSQL databází pomocí SYBASE modulu, perl pro tyto databáze vyuţívají společného rozhraní administrátorské rozhraní je CGI skript vyuţívající databázi. Jako webový server byl zvolen lighttpd, který je výborný pro menší webové aplikace. administrátorské rozhraní komunikuje pomocí plaintext tcp s démonem, zjištuje stav: o funkčnosti démona o zdali běţí spojení démona s Asteriskem o zdali funguje spojení démona s databází démon ukládá data o hovorech na ramdisk, jeho obsah je pomocí webového serveru (lighttpd) poskytován klientskému rozhraní 12
4.2 Komunikace mezi komponentami systému pomocí fronty příkazů Fronta příkazů (commandQueue) systému umoţňuje komunikovat mezi jeho komponentami následujícím způsobem:
1. ke komponentě systému commandQueueFetcher, která se stará o vyzvedávání příkazů z CommandQueue, se registrují další komponenty, které při registraci uvedou, které příkazy fronty umí obslouţit 2. kterákoliv součást systému přidá do fronty příkazů příkaz (např. pro zaloţení hovoru) 3. CommandQueueFetcher přečte z commandQueue příkaz, který umí obslouţit, smaţe jej odtud a postará se jeho provedení. Je zajištěno, ţe jeden příkaz můţe být naráz přečten a proveden pouze jedním démonem.
Příkazy, u kterých je nutné vyuţívat load ballancing a high availability, vyuţívají pro komunikaci frontu příkazů.
high availability o z commandQueue čtou příkazy pouze aktivní démoni, tudíţ není narušena obsluha sluţeb o v případě, ţe je přes commandQueue poslán příkaz pouze konkrétnímu démonovi, ten si jej vyzvedne, aţ bude aktivní o v případě, ţe dojde k výpadku serveru při zpracovávání příkazu z commandQueue, pak záleţí na typu příkazu, jakým způsobem se s výpadkem systém vyrovná load ballancing o démon, který dříve vybere příkaz z fronty, jej také zpracuje o při větším rozdílu mezi vytíţení jednotlivých serverů a démonů na serverech dojde k tomu, ţe soutěţ o vyzvednutí příkazu z fronty vyhraje méně vytíţený démon
Obrázek 4-2: Entita fronty příkazů
Na obrázku Obrázek 4-2 jsou entity Daemon (démon) a CommandQueue. Entity jsou propojeny neidentifikující vazbou Daemon:CommandQueue 0-1:0-N. Popis polí entity Daemon: 13
Id – jednoznačný identifikátor Host – ip adresa serveru, na kterém démon běţí Port – komunikační port, na kterém je moţno zjistit stav démona a provést několik základních příkazů (restart démona,….). Je moţno jej vyuţít přes telnet, dále jej vyuţívá webové administrativní rozhraní. statePort – port, na kterém běţí webový server poskytující stavy hovorů online – informace, zdali je daný démon funkční
Popis polí entity CommandQueue
Id je jednoznačným identifikátorem příkazu, umoţňuje manipulaci s neprovedeným příkazem objektu, který jej například vytvořil Command je příkaz, který má být proveden. S kontkrétním příkazem umí pracovat pouze 1 komponenta systému. Parameters je nepovinný atribut obsahující parametry příkazu Inserted je datum vloţení příkazu Asterisk je nepovinné pole, je cizím klíčem tabulky Daemons o hodnota NULL znamená, ţe si příkaz můţe vyzvednout kterýkoliv z démonů o číselná hodnota s ID Asterisku umoţňuje nastavit konkrétního démona, který se má o daný příkaz postarat
To, ţe většina stavové informace není uloţena v rámci paměti démonů, ale je uloţena v databázi a ve frontě příkazů, přináší, ţe při výpadku serveru, či démona, běţícím na serveru, dojde jen k minimální ztrátě stavové informace, která není pro systém kritická a systém se z ní umí vyléčit.
4.3 Propojení s terminacemi Propojení s terminacemi je realizováno pomocí SIP a RTP protokolu, terminace se starají o zakončení hovoru v PSTN. Pro volání přes terminace je nutné nastavit tyto parametry:
název terminace – zobrazuje se v systému v polích označujících danou terminaci kanonický název terminace – vyuţit pro identifikaci v konfiguračních souborech měna – měna, ve které od terminace dostáváme ceníky – nutné pro výpočet nákladů parametry pro Dial funkci – vysvětleno dále formát čísla pro nastavení callerid – nastavení formátu čísla volajícího; vysvětleno dále konfigurace SIP protokolu – popisuje způsob propojení s terminací, generuje konfigurační soubor SIPu pro Asterisk, vysvětleno dále informaci, zdali je terminace aktivní
Parametry pro dial funkci – zde nastavujeme, jakým způsobem volat přes danou terminaci:
řetězec pro Dial – obsahuje sluţbu (v případě clicktocall SIP) a formát volaného čísla – u některých terminací je před volané telefonní číslo nutno přidat řetězec (dále prefix), který nastavuje, jak s hovorem zacházet. Terminace například poskytuje 3 14
úrovně kvality spojení hovoru s rozdílnou cenou, prefixem tuto kvalitu zvolíme. Obsah pole řetězec pro Dial nám také umoţňuje na základě volaného čísla modifikovat prefix. Například:
1=>SIP/${NUMBER}@broadvox, SIP/011${NUMBER}@broadvox
příklad ukazuje volání přes terminaci broadvox. V případě, ţe voláme na číslo začínající na 1, pak je pouţito první pravidlo, v ostatní případech je pouţito pravidlo druhé – nastaví prefix na 011. atributy Dial funkce – zde nastavíme další nepovinné parametry Dial funkce (viz kapitola 2.4.1.1)
V případě volání je potřeba nastavit tzv. callerid – jde o číslo volajícího, které je zobrazeno na zařízení, na které je voláno. Terminační operátoři umoţňují toto číslo nastavit prakticky bez omezení; ve sluţbě clicktocall je číslo volajícího třeba nastavit, více viz. kapitola Základní průběh hovoru4.4. Různé terminace potřebují nastavit callerid v různém formátu (jde zejména o stanovení prefixu), toto je umoţněno pomocí pole „Formát čísla volajícího“ v nastavení terminace.
Informace o nastavení terminací jsou uloţeny v databázi v entitě Terminations, jejíţ entity diagram je znázorněn na obrázku Obrázek 4-3.
Obrázek 4-3 : Entita Terminations.
4.4 Základní průběh hovoru Zaloţení a průběh hovoru má v systému clicktocall následující průběh: 1. Kontrola, zdali má volající dostatečný kredit 2. 3pcc ústředna pomocí funkce dial vytvoří kanál mezi sebou a volajícím, vyuţije k tomu nejlevnější terminaci, která je schopna kvalitně vytvořit spojení s daným číslem. V databázi jsou uloţeny náklady na hovory pro různé terminace v různých měnách, pro hledání nejlevnější terminace je pouţit aktuální směnný kurz. Nastaví callerid na číslo volaného. Jelikoţ je hovor jiţ zpoplatněn terminací, zákazníkovi není počítán ţádný kredit a volaný nemusí hovor po dlouhou dobu zvednout, pak je toto volání omezeno na 30 sekund. 3. Jakmile je hovor přijat ústřednou, je vytvořen kanál mezi ústřednou a volaným, callerid je nastaveno na číslo volajícího. Volaný tudíţ nepozná, ţe je hovor spojen jinak, neţ obvyklým způsobem. 4. V případě zvednutí hovoru volaným dojde ke spojení hovoru. 5. Po ukončení hovoru (volaným, volajícím, dojitím kreditu, nebo zásahem administrátora) dojde k odečtení provolaného kreditu. 15
4.4.1 Vyčerpání kreditu na účtu ve vztahu k hovoru Existují 2 základní cesty, jakým způsobem ukončit hovor v případě, ţe zákazníkovi sluţby dojde kredit. 1. Zákazníkovi periodicky po malých časových intervalech (1-5 sekund) sniţovat kredit, jakmile se dostane na 0, ukončit všechny jeho aktivní hovory. 2. Při započetí hovoru spočítat maximální délku hovoru na základě aktuálního kreditu a ceny hovoru a tuto délku Asterisku nastavit v parametru funkce Dial. Asterisk se sám postará o ukončení hovoru. Výhody (+) a nevýhody (-) jednotlivých řešení: 1. řešení + Jednodušší implementace 2. řešení + Řádově méně přístupů k databázi – mnohem sloţitější implementace, zejména v případě více aktivních hovorů zároveň – nutnost dopočítání kreditu v případě pádu serveru systému
Bylo zvoleno řešení 2, zejména kvůli minimalizaci přístupů do databáze. V případě mnoha hovorů by docházelo k netriviálnímu mnoţství úprav (SQL UPDATE) databáze, systém dle poţadavků musí umět vyhovět naráz stovkám hovorů. Průběh zaloţení hovoru při 2. řešení – z finančního hlediska : 1. Pokud je kredit = 0, pak ukonči zakládání hovoru. 2. Pokud účastník nemá povoleno naráz vytvořit více hovorových kanálů, neţ je počet jiţ aktivních, ukonči zakládání hovoru. 3. Zjisti aktivní hovory účastníka, jejich aktuální délku a minutovou sazbu. Díky minutové sazbě, která je účtována zákazníkům, je výpočet jednodušší 4. Podle rovnice (4.1.) vypočítáme novou délku hovorů. Proměnné delkahovoru a minzazba (minutová sazba) se odkazují na stávající hovory. Proměnná delkahovoru je počet minut hovoru zaokrouhlený nahoru. 5. Nová délka hovorů je zaokrouhlena směrem dolů – chceme, aby zákazníkovi po ukončení hovoru zůstal malý, nenulový kredit. 6. Všem hovorům – tj. novému hovoru, i stávajícím hovorům nastavíme novou, stejnou délku hovoru.
(4.1.)
Nyní hovory probíhají, při ukončení hovoru dojde z hlediska financí k následujícím akcím: 1. zákazníkův kredit je sníţen o cenu provolaného hovoru 16
2. pokud je počet zákazníkových hovorů = 0, pak je průběh funkce ukončen 3. dojde k přepočítání aktuální minutové tarifikace přes všechny aktivní hovory 4. všem hovorům je nastavena nová, stejná délka hovoru podle vzorce (4.2.)
(4.2.)
Všechny výše uvedené akce budou řešeny v rámci uloţených procedur databáze. Nastavení maximální délky hovorů je posláno Asterisk démonům pomocí centrální fronty příkazů.
4.4.2 Založení hovoru pomocí rychlé volby Rychlá volba umoţňuje zákazníkovi spojit telefonní hovor jen s pomocí telefonního přístroje. V praxi pouţití rychlé volby probíhá:
zákazník v klientském systému přidá k telefonnímu kontaktu číslo rychlé volby. Toto číslo je jedno z čísel, které náleţí systému clicktocall a je určeno pro rychlou volbu. zákazník na toto telefonní číslo zavolá, systém hovor zaznamená a hovor ukončí na základě čísla, ze kterého došlo k prozvonění a čísla, které bylo prozvoněno, provede systém vytvoření hovoru mezi volajícím a telefonním kontaktem v adresáři
Více o rychlé volbě obsahují kapitoly 4.5.3.1 a 5.2.
4.4.3 Vlastní směrování hovoru Tato kapitola popisuje, jakým způsobem je provedeno směrování hovoru a jakým způsobem systém propojí ústřednu s libovolným telefonním číslem. Kaţdá strana – tj. zdroj a cíl – je směrována zvlášť. Cílem je určit pořadí terminací, ve kterých se má volat na telefonní číslo.
Nejdříve pomocí Longest prefix match dojde k nalezení skupiny prefixů, ke které náleţí volané telefonní číslo. Na základě této informace víme, které terminace a za jakou cenu jsou schopny toto telefonní číslo spojit. Nyní dojde k aplikaci statické a dynamické priority, která je přiřazena k uspořádané dvojici (síť, terminace) – tato informace je uloţena v tabulce Priorities (viz obrázek Obrázek 4-13).
statická priorita je určena administrátorem systému a umoţňuje preferovat terminaci do dané sítě dynamická priorita je počítána na základě neúspěšnosti propojování hovorů do dané sítě přes danou terminaci, více viz kap. 4.4.3.1.
17
Pokud existuje více terminací se stejnou prioritou – coţ je výchozím stavem – pak dojde k řazení terminací podle nákladů za volání – Least cost routing.
Démon nyní můţe na základě uspořádaného seznamu přes terminace volat na dané číslo. V případě, ţe volání přes terminaci nevyjde, volá přes další terminaci v pořadí. Více viz kapitola 5.1.
4.4.3.1 Černé body V případě, ţe dojde k neúspěšnému volání do určité sítě přes určitou terminaci, pak dojde k přidání tzv. černých bodů, které sniţují prioritu terminace při jejím dalším výběru. V případě, ţe terminace, která obsahuje černé body, spojí hovor správně, pak dojde k odmazání černých bodů. Černé body tímto způsobem tvoří statistiku spolehlivosti volání přes terminace do jednotlivých sítí. Černé body s určitou vahou modifikují prioritu terminace. Pouţívané nastavení vah v systému je
chyba při spojení do dané sítě: +3 bod správně spojené volání: -6 bodů (počet černých bodů zůstává nezáporný) celková priorita sítě = administrativní priorita + zaokrouhli_dolů(černébody/9)
V důsledku úspěšný hovor pokryje sníţení priority, které nastane u 2 neúspěšných hovorů. Celková priorita sítě se změní aţ po 3 neúspěšných hovorech, které proběhnou za sebou. Niţší hodnota celkové priority sítě znamená upřednostnění terminace v rámci směrování.
4.5 Uložení dat a struktura databáze Tato kapitola obsahuje informace o struktuře dat uloţených v databázi a jakým způsobem se s daty pracuje. Kaţdá podkapitola obsahuje ER diagram, který je dále rozebírán. Podkapitola Import ceníků terminací hovoří o výpočtu směrovacích tabulek telefonních hovorů a jakým způsobem je vytvořena struktura světových telefonních sítí. Podkapitola Výpočet ceny účtované zákazníkovi mluví o tom, jakým způsobem jsou vypočítány ceny volání mezi jednotlivými sítěmi. Podkapitola Evidence zákazníků ukazuje systém evidence zákaznických účtů, jejich plateb, poţadavků na podporu a adresáře kontaktů. Ukazuje, jakým způsobem jsou uloţena čísla nutná pro funkčnost rychlé volby. Podkapitola Tabulky uchovávající informace o hovorech hovoří o části databáze uchovávající informace pro správné směrování hovorů, nejen podle nákladové ceny ale také podle kvality terminace, také se zde píše o uloţení informací o proběhlých hovorech.
4.5.1 Import ceníků terminací Ceníky nákladů sluţby clicktocall, které jsou poskytovány terminacemi, jsou v různém formátu. Pro import do clicktocall systému je nutno je transformovat do formátu CSV, nebo excelové tabulky se sloupci podle obrázku Obrázek 4-4. 18
Obrázek 4-4: Příklad ceníku zahraniční terminace; ukazuje jakým způsobem vidí české telefonní sítě.
Vysvětlení významu jednotlivých polí:
Prefix – prefix volaného telefonního čísla. Tarifikaci hovoru na určité telefonní číslo skrz tuto terminaci zjistíme, pokud provedeme longest prefix match (vysvětleno dále) pomocí pole prefix na volané telefonní číslo networkName – název sítě rate – cena za 60 sekund hovoru v měně, ve které provozovatelem sluţby clicktocall placen kredit terminaci rateConnection – cena za spojení hovoru – zaúčtuje se při úspěšném spojení hovoru unitLength – délka druhé a další jednotky v sekundách firstUnitLength – délka první účtované jednotky v sekundách. Unit a firstUnitLength nastavují tarifikaci (např. 60+30; 1+1; apod.)
Hledání nejdelšího prefixu (dále Longest prefix match) je pojem vyuţívaný v počítačových sítích pro hledání nejkonkrétnější cesty ve směrovací tabulce routeru. Dovolil jsem si pojmu vyuţít i v hledání nejkonkrétnější cesty v případě telefonního hovoru, jelikoţ fungují na stejném principu. Na začátku máme vstup – tj. číslo, pro které hledáme nejvíce konkrétní prefix a tabulku všech prefixů, které jsou rozdílné délky. Čím je prefix delší, tím je více konkrétní. Princip spočívá v tom, ţe tabulce prefixů rozdílné délky hledáme nejdelší řetězec, který je prefixem vstupu. 19
Příklad: Tabulka prefixů obsahuje pouze a jen prefixy +420603, +4206, +420. Pokud voláme na číslo +420604123123, pak spadneme do skupiny +4206.
Celková cena hovoru v českých korunách přes terminaci je vypočítána rovnicí (4.3.).
(4.3.)
Legenda:
c – cost – celková cena hovoru v CZK cl – call length – délka hovoru ful – firstUnitLength ul – unitLength r – rate – minutová sazba hovoru v původní měně k – kurz měny vůči CZK
20
Obrázek 4-5: ERD pro import ceníků terminací
V obrázku Obrázek 4-5 je pohled na ERD obsahující entity, které mají přímou návaznost na import ceníků terminací.
červená barva jsou entity, které jsou obrazem importovaných ceníků a informací o importních bodech ţlutá barva obsahuje vypočítané importní body (vysvětleno dále), které se zaktivují v určitý čas modrou barvou jsou označeny entity, přes které probíhá směrování a least cost routing aktuálních hovorů
Při importu ceníku do systému zvolíme terminaci, které ceník náleţí. Při importu jednoho ceníku dojde k vyplnění databázových tabulek RateLists a RateListPrefixes. 21
tabulka RateLists obsahuje 1 záznam na kaţdý importovaný ceník. Kaţdý záznam je identifikován primárním klíčem (id), tabulka dále obsahuje id terminace, pro kterou daný ceník je, čas importu a komentář tabulka RateListPrefixes obsahuje jednotlivé záznamy o cenách hovorů do daných sítí. Primárním klíčem tabulky je uspořádaná dvojice rateList (odkaz na id z tabulky RateLists) a prefix. Ostatní pole popisují ceny za volání do dané sítě (viz začátek kapitoly) tabulka RateLists s RateListPrefixes je spojena vazbou 1:N
Skupina ceníků – pro kaţdou aktivní terminaci jeden – tvoří takzvaný importní bod. Ten jiţ obsahuje kompletní informaci pro směrování hovorů podle ceny (least cost routing) v celém clicktocall systému. Importní bod je pouze připravená neaktivní skupina ceníků, do aktivního provozu je překlopen aţ v určitý čas.
Tabulka RateImports obsahuje informaci o tom, které ceníky kterých terminací jsou spojeny do importního bodu pomocí asociativní entity ImportFiles. Její další atributy jsou: o o o
effectTime – čas, ve kterém má být importní bod aktivován state – stav importního bodu – informace, zdali je jiţ kompletně připraven – spočítán, jestli je aktivní, nebo jiţ byl nahrazen jiným, novějším importním bodem activationCommand – id příkazu v commandQueue (viz kapitola 4.2), pokud bude administrátor systému chtít manipulovat s časem aktivace importního bodu, pak musíme upravit svázaný záznam v commandQueue
Díky tabulkám, které jsou v obrázku Obrázek 4-5 označeny červeně, má systém veškeré vstupní informace, které je nutno transformovat do informace pouţitelné pro systém; tato transformovaná data jsou uloţeny ve ţlutých tabulkách.
Transformace vstupních dat přináší moţnosti: o o o
vyuţít least cost routing sjednotit názvy sítí, které se mezi terminacemi liší vyřešení kolizí v cenících
Importní skupina je skupina prefixů, které patří do jedné sítě a mají přes jednu terminaci jednu cenu za volání do sítě (například český T-Mobile). Uspořádaná dvojice (skupina, terminace) definuje cenu hovoru přes danou terminaci do dané skupiny. Vazbu mezi sítí, skupinou prefixů a terminacemi ukazuje obrázek Obrázek 4-6.
22
Skupiny prefixů se stejnou cenou v rámci 1 terminace
Síť
Prefixy různé délky
Ceny volání do skupiny přes různé terminace
Terminace
Obrázek 4-6 : Vztah mezi sítí, skupinami prefixů a terminacemi
Vlastní least cost routing hovor je realizován tak, ţe je pomocí longest prefix match nalezena síť, konkrétněji skupina prefixů, a pak je zjištěno, která terminace má nejlepší cenu. Dále se vezme v úvahu stabilita terminace pro daný prefix, popř. pokud má daná terminace dovoleno volat na tyto prefixy a hovor je spojen, více viz kapitola 4.4.3. Telefonní síť je reálný administrativní celek, ve většině případů telefonní operátor (např. T-Mobile CZ). Kaţdý terminační operátor pro ní můţe mít jiný (mírně rozdílný) název a můţe do ní zařazovat mírně rozdílné prefixy. Systém clicktocall se sítí pracuje jako s určitým celkem, kaţdá terminace má vůči síti uloţeny tyto údaje:
prioritu v rámci směrování černé body informace o blokaci
Pojem telefonní sítě je dále vyuţit:
telefonní síť se zobrazuje zákazníkovi, ví, kam volá administrátoři systému starající se o finance nastavují ceny za volání mezi sítěmi pro zákazníky o to byla původní idea – cena pro zákazníky je určena uspořádanou dvojicí (zdrojová sít, cílová síť), v systému není závislá na nákladech Návrh ale nebyl dobrý, sítí je příliţ mnoho – nebylo moţno systém rozumně administrovat, došlo ještě ke sjednocení sítí do větších skupin, jejichţ granularita byla na základě státu a typu (skupiny) sítě (pevná, mobilní, volání zdarma,…).
Ţluté tabulky obrázku Obrázek 4-5:
ImportPrefixes – seznam prefixů, pro uspořádanou dvojici (importní bod, skupina) o Prefix – primární klíč o rateImport – importní bod, cizí klíč z ImportGroups o group – skupina, cizí klíč z ImportGroups ImportGroups - skupina prefixů přiřazená k síti a importnímu bodu o Id – primární klíč 23
rateImport – importní bod, cizí klíč z ImportGroups, součást primárního klíče network – identifikátor sítě, cizí klíč z tabulky Networks. Tento údaj lze vypočítat aţ po vyřešení kolizí, ve kterých se na prefixy a názvy sítí dívají různé terminace různě ImportGroupTerminations – asociativní entita, která propojuje terminace se skupinami prefixů, určuje cenu, za kterou se volá v rámci dané terminace na danou skupinu prefixů v rámci sítě (Network) o primární klíč rateImport – importní bod group – skupina termination – terminace o atributy networkName – název sítě z importovaného ceníku network – cizí klíč tabulky Networks, jde o identifikátor sítě, do které skupina prefixů patří. Hodnota atributu je spočítána podle networkName (viz kapitola 4.5.1.1) rate, rateConnection, unitLength, firstUnitLength – vysvětleno na začátku kapitoly 4.5.1 o o
Světle modré tabulky obrázku Obrázek 4-5:
Networks – obsahuje informace o telefonních sítích, jde o strom telefonních sítí. např. otec je česká republika s prefixem +420, dítě jsou české mobilní sítě s prefixy +420[67], jejich děti jsou konkrétní mobilní operátoři o Id – primární klíč, jde o jednoznačný identifikátor v systému o Parent – identifikátor rodiče o Name – název sítě o Country – země telefonní sítě, cizí klíč tabulky Countries o showToClient - identifikátor, zdali se síť má ukazovat zákazníkovi Terminations – tabulka obsahující informace o jednotlivých terminacích; Atributy obsahují nastavení viz kapitola 4.3 GroupTerminations – jde o běhový obraz tabulky ImportGroupTerminations, oproti ní jí chybí jiţ nepotřebná pole název a id sítě Groups – běhový obraz tabulky ImportGroups Prefixes – běhový obraz tabulky ImportPrefixes
Světle modré tabulky (kromě entit Terminations a Networks) obsahující informaci o aktuálním (běhovém) nastavení clicktocall systému jsou vytvořeny tak, ţe při potvrzení připravenosti nového importního bodu dojde ke zkopírování údajů importního bodu ze ţlutých do modrých tabulek. V čase přepnutí dojde k překlopení na nový importní bod – změní se údaj, který importní bod je právě aktivní. Bylo moţno vyuţít pouze ţlutých tabulek, a změnou id aktivního importního bodu začít vyuţívat nové nastavení, avšak kvůli optimalizaci dotazů bylo zvoleno zkopírování dat do tabulek, které pak mají pořád přibliţně stejnou velikost, zatímco velikosti tabulek Import* lineárně rostou – tabulky obsahují 24
data pro kaţdý importní bod v minulosti. Světle modré tabulky také neobsahují některé atributy, které nejsou nutné pro běh systému.
4.5.1.1 Stromová struktura sítí Sítě jsou uspořádány do více stromů (do lesa) sítí. Tento strom ukazuje, která síť je nadsítí jiné sítě. V praxi je v kořenu stromu stát, který pod sebou má větvě mobilních a pevných sítí, ty pod sebou mají jednotlivé operátory. Uspořádání sítí reflektuje ve většině případů uspořádání prefixů. Například:
Prefixy +4206; +4207 jsou české mobilní sítě o Prefix +420602 je síť O2, která je potomkem českých mobilních sítí
4.5.1.2 Rozdíly v pohledu na sítě mezi jednotlivými terminacemi V této kapitole je popsáno, jakým způsobem dochází ke sjednocení názvů telefonních sítí. Cílem systému je, aby pro kaţdý prefix měl jasně definováno, do které telefonní sítě a s jakými atributy patří (pevná/mobilní síť,…). Informace z ceníků terminací jsou bohuţel hodně rozdílné a proto je nutno tyto údaje sjednotit.
Na obrázku Obrázek 4-7 vidíme pohled na prefixy české republiky od jiného terminačního operátora, neţ na obrázku Obrázek 4-4.
Obrázek 4-7: Alternativní ceník volání do sítí České republiky.
25
Na cenících za volání od rozdílných terminací vidíme, jak mají rozdílný pohled na prefixy v rámci české republiky.
Terminace z obrázku Obrázek 4-4
Terminace z obrázku Obrázek 4-6
Rozlišuje T-Mobile, O2 a Vodafone mobilní sítě
Rozlišuje pouze T-Mobile a ostatní mobilní sítě
Neumí směrovat prefix 420609
Tvrdí, ţe umí směrovat 4206091
Systém povolí volání přes určitou terminaci pouze pokud ví, ţe daný hovor umí terminace spojit, tj. prefix telefonního čísla, na které voláme, je obsaţen v jejím ceníku. Pokud tomu tak není, terminace je vyloučena ze směrování hovorů. To systému umoţňuje mít terminaci terminující např. jednu jedinou zemi.
4.5.1.3 Vytvoření importního bodu Vytvoření samotného importního bodu probíhá v následujících krocích. Cílem je sjednotit údaje z ceníků a předpočítat některá data pro směrování hovorů. 1. Dojde ke sjednocení všech prefixů ze všech ceníků importního bodu. Prefixy jsou seřazeny vzestupně, duplicitní prefixy jsou odstraněny. 2. Nyní je třeba předpočítat ceny volání do všech prefixů nezávisle na tom, jestli má daná terminace obecnější, nebo méně obecné prefixy. Toto umoţní při směrování hovoru pomocí jediného longest prefix match zjistit, do jaké skupiny prefixů cílové číslo patří. To je provedeno tak, ţe pro kaţdý prefix z mnoţiny všech prefixů je proveden longest prefix match přes kaţdou z terminací. 2.1. Díky tomu dostaneme tabulku, která pro kaţdou uspořádanou dvojici (prefix, terminace) obsahuje cenu za volání a název sítě, jak je pojmenována danou terminací 2.2. Pro kaţdý prefix zřetězíme výše uvedená pole – tj. pro kaţdý prefix získáme řetězec [(terminace1, názevsítě1, cena1), (terminace2, názevsítě2, cena2),…] 2.3. Vytvoříme skupiny prefixů, skupina prefixů jsou prefixy, které mají stejný řetězec. 2.3.1. Skupina prefixů je zajímavá v tom, ţe má jasně definováno, v jakém pořadí mají být vyuţity terminace při volání na kterýkoliv prefix dané skupiny. 2.4. Systém předpokládá, ţe názvy sítě v řetězci jsou aliasy pro jednu jedinou síť, ale tuto operaci musí potvrdit administrátor systému 3. U nového názvu sítě, jehoţ prefixy nejsou v systému, je nutno určit, zdali jde o novou síť, nebo pouze o alias k síti. Na níţe uvedeném příkladu musí administrátor určit, zdali jde o jednu síť s více aliasy, nebo jde o 2 různé sítě. 3.1. +4206 – název sítě: Czech mobile 3.2. +420602 – název sítě: O2 4. V tomto případě jde o 2 různé sítě, systém k nim přistupuje zvlášť, kaţdá má svou prioritu, černé body, popř. můţe být zvlášť zablokována 5. Po dokončení administrátorských úprav je importní bod připraven k pouţití
1
Prefix pro placené sluţby, dnes nepřidělen (viz vyhledávací databáze ČTU k 24.5.2011)
26
4.5.2 Výpočet ceny účtované zákazníkovi Jelikoţ zákazníkovi sluţby není moţno prezentovat ceník obsahující seznam všech sítí světa pro zdrojová čísla a seznam všech sítí světa pro cílová čísla, tj. počet sítí na druhou, byl počet sítí zobrazených zákazníkovi hodně zredukován:
zdrojové číslo můţe být pouze z české pevná, nebo mobilní sítě zákazníkovi sluţby jsou zobrazeny ceny za volání do určitého státu dohromady pro všechny pevné sítě daného státu a pro všechny mobilní sítě o Toto sice neodpovídá nákladům za spojení, ale velice to zjednodušuje informování zákazníka o cenách a marketing, který sluţbu clicktocall prodává
Obrázek Obrázek 4-8 ukazuje, jakým způsobem má být cena sluţby prezentována koncovému zákazníkovi sluţby. K dosaţení tohoto cíle je nutné rozdělit telefonní sítě (entita Networks) do větších celků. V původním návrhu bylo počítáno s automatickým výpočtem ceny za volání, ale v průběhu návrhu systému došlo ze strany provozovatele sluţby ke změnám, které nakonec vyústili v řešení, které poskytuje obrázek. Systém byl navrţen pro jistotu obecněji, aby bylo moţno v budoucnu změnit zákaznické účtování.
Obrázek 4-8: Ceník prezentovaný zákazníkům služby.
4.5.2.1 Rozdělení sítí do skupin Entita Networks obsahuje seznam většiny světových sítí, obrázek Obrázek 4-9 ukazuje, jakým způsobem jsou sítě dále rozděleny.
27
Obrázek 4-9: Rozdělení telefonních sítí do skupin.
Tato část databáze dovoluje sítím dávat štítky, do jaké patří skupiny. Síť můţe patřit do více skupin současně, dále umoţňuje dávat sítím alternativní názvy – aliasy, dělit sítě podle země, ve které se nachází, do skupin a lokalizovat názvy zemí do více jazyků.
Popis jednotlivých entit obrázku Obrázek 4-9:
NetworkGroups je entita obsahující názvy skupin sítí o Id – jednoznačný identifikátor, klíč o Name – název skupiny sítí NetworkGroupMembers je asociativní entita mapující entitu Networks na entitu NetworkGroups, tj. entita, která sítě štítkuje. Kaţdá síť můţe být v 0 aţ N skupinách, ve skupině můţe být 0 aţ N sítí o Network – cizí klíč entity Networks (atributu id) o networkGroup – cizí klíč entity NetworkGroups (atributu id) NetworkAliases je entita pomáhající při importu ceníků, obsahuje informace o alternativních názvech sítě, které pro danou síť pouţívají různé terminace; obsahuje alternativy k poli name z entity Networks Countries je tabulka obsahující informace o zemích o Id – interní identifikátor země 28
o mainName – název země vyuţitý v administraci systému o prefix – prefix země Languages je tabulka obsahující jazyky, do kterých je lokalizován frontend sluţby clicktocall. Backend poskytuje frontendu veškeré informace týkající se volání, včetně toho, kam zákazník volá a to lokalizovaně o code – kód jazyka o name – název jazyka CountryLocales – asociativní entita obsahující názvy zemí ve všech systémových jazycích o primární klíč country – země, cizí klíč language – jazyk, cizí klíč o name – název země v daném jazyku
4.5.2.2 Stanovení ceny mezi sítěmi Systém umoţňuje stanovit cenu za spojení hovoru mezi jednotlivými sítěmi, a protoţe je sítí velký počet, tak umoţňuje nastavit cenu i mezi skupinami sítí (viz kapitola 4.5.2.1). Aby bylo účtování co nejvíce flexibilní, bylo realizováno následujícím způsobem:
máme prázdnou mnoţinu cen mezi kaţdými dvěma sítěmi naplníme ji kombinací všech sítí se všemi s nastavenou implicitní cenou dále máme uspořádanou mnoţinu transformací cen mezi sítěmi sítí o transformace je definována zdrojovou sítí, nebo skupinou sítí, cílovou sítí, nebo skupinou cílových sítí cenou a prioritou pro vyplnění mnoţiny cen mezi kaţdými dvěma sítěmi seřadíme transformace podle priority a aplikujeme je na mnoţinu cen mezi kaţdými dvěma sítěmi
Výše popsaný přístup umoţňuje nastavit několik globálních cenových pravidel s nízkou prioritou a potom nastavení přebít jinými pravidly pro konkrétní sítě. Bylo uvaţováno také o jiném přístupu – nastavit prioritu podle počtu dotčených sítí – pravidla, které se týkají velkého počtu sítí by byla aplikována nejdříve a konkrétnější pravidla by byla aplikována později. Toto řešení nebylo zvoleno, ačkoliv by zjednodušilo systém priorit – administrátor systému nemá absolutní přehled o počtu prvků skupin sítí a neměl by absolutní jistotu, které pravidlo bude aplikováno dříve.
29
Obrázek 4-10: ERD pro stanovení ceny hovoru pro koncové zákazníky.
Popis entit obrázku Obrázek 4-10:
NetworkToNetworkRates – uchovává cenu za volání mezi mezi dvěma sítěmi o primární klíč network1 – zdrojová síť network2 – cílová síť o rate – cena v Kč za minutu hovoru (atribut) Networks – strom všech telefonních sítí NetworkGroups – skupiny sítí NetworkGroupMembers – asociativní tabulka mezi Networks a NetworkGroups, umoţňující danou síť vloţit do více skupin NetworkToNetworkTransformations – tabulka transformací o id – primární klíč, jedinečný identifikátor transformace o identifikace zdroje a cíle, musí být vyplněn právě 1 zdroj a 0 aţ 1 cílů, ostatní hodnoty musí být NULL. V případě, ţe není vyplněn cíl, pak jsou cílem všechny telefonní sítě Group1 – zdrojová skupina sítí 30
o o
Group2 – cílová skupina sítí Network1 – zdrojová síť Network2 – cílová síť priority – priorita transformace určující pořadí, v jakém bude transformace aplikována rate - cena v Kč za minutu hovoru
Při editaci jednotlivých transformací není tabulka cen mezi sítěmi přepočítávána, je přepočítána aţ na ţádost administrátora systému.
4.5.3 Evidence zákazníků V této kapitole je popsáno, jakým způsobem systém eviduje zákaznické účty, jaký je rozdíl mezi uţivatelským účtem a uţivatelským loginem, jak jsou uloţeny informace o administrátorském systému, a jakým způsobem je vyřešena jednoduchá uţivatelská podpora. V podkapitole 4.5.3.1 je popsáno, jakým způsobem jsou uchovány kontakty zákazníka sluţby. Na obrázku Obrázek 4-11 je ERD popisující, jak jsou uloţena data zákazníků.
UserAccounts je tabulka, která obsahuje informace o klientském účtu, zejména kreditu, který na daném účtu je. Na tuto tabulku je připojena tabulka loginů (např. firma má 1 účet s kreditem, který vyuţívá více zaměstnanců firmy, ti mají své loginy). Popis atributů tabulky:
id – jednoznačný identifikátor účtu, primární klíč type – typ účtu o Soukromý o Firemní created – datum a čas vytvoření účtu credit – zůstatek kreditu na účtu bonusCredit – zůstatek kreditu na účtu, který byl přidán jiným způsobem, neţ vloţením finanční hotovosti. Je velice důleţité jej oddělit od finančně pokrytého kreditu ať jiţ z účetních důvodů, popř. pokud chce zákazník vrátit kredit creditExpiration – po stanovené době (1 rok) dojde k expiraci kreditu, pokud si zákazník během této doby nenabije kredit.
Tabulku UserAccounts v případě, ţe je uţivatelem sluţby firma, doplňuje tabulka Companies, ve které jsou uloţeny firemní údaje:
name - název firmy ico – jednoznačný identifikátor organizace v rámci ČR dic – daňový identifikátor organizace address1, address2, city, postcode – adresa firmy po řádcích, město a PSČ country – země, ve které se firma nachází, cizí klíč tabulky Countries phoneContact – telefonní kontakt 31
Tabulka UserLogins obsahuje vlastní loginy uţivatelů, ke které je navázána většina tabulek systému, které potřebují identifikátor uţivatele. Obsahuje pole:
id – jednoznačný identifikátor uţivatele, primární klíč username – přihlašovací jméno password – přihlašovací heslo uţivatele, zahashované pomocí MD5 accountAdministration – příznak, zdali má uţivatel právo spravovat tabulku userAccounts, tj. můţe k účtu přidávat další loginy. Toto oprávnění má v zákaznické firmě člověk, který má na starost správu uţivatelů systému clicktocall language – informace, v jaké lokalizaci se mají zobrazovat klientské webové stránky name, surname – jméno a příjmení zákazníka address, city, postcode – informace o bydlišti zákazníka country – země, ze které zákazník pochází disabled – příznak, zdali je uţivatelský login zakázaný email – kontaktní email zákazníka
UserLoginCodes je tabulka vyuţitá pro přihlášení zákazníka do klientského informačního systému. Při přihlášení uţivatele do systému je vygenerováno velké náhodné číslo – kód relace, které je zasláno prohlíţeči klienta sluţby a je uloţeno v této tabulce, prohlíţeč toto číslo posílá při kaţdé akci, kterou zákazník provede. Na serveru toto číslo identifikuje přihlášeného zákazníka. Kód relace je tajný, v případě zcizení toto kód relace nahrazuje jméno a heslo. Pokud není kód relace po nějakou dobu pouţit, pak relace vyprší a je třeba se znovu přihlásit. Jeden uţivatel můţe mít více souběţných relací. Popis polí tabulky:
id – primární klíč, jednoznačný identifikátor relace userLogin – vazba na login, cizí klíč tabulky UserLogins code – kód relace – 32 bytů dlouhý řetězec when – datum a čas posledního vyuţití relace, díky tomuto poli je moţno provést vypršení (timeout) relace
AdminUsers je tabulka uţivatelů, kteří spravují systém clicktocall. Obsahuje oprávnění, které jednotliví administrátoři mají, v některých případech vyuţívá tabulky UserLogins pro uţivatelské akce. Popis polí tabulky:
id – primární klíč, jednoznačný identifikátor administrativního uţivatele username – přihlašovací jméno (není v UserLogins, aby nedošlo ke kolizi se zákazníkem) name – reálné jméno manageUsers – oprávnění, zdali administrátor můţe spravovat uţivatele sluţby (tj. upravovat jejich údaje, přidávat bonusový kredit, autorizovat telefonní čísla,…) manageRates – oprávnění, zdali administrátor můţe importovat ceníky terminací a nastavovat ceny za volání klientům sluţby service – oprávnění pro řešení technických problémů uţivatelů, tj. zobrazení tiketů, dále zobrazení seznamu hovorů uţivatele administrace – oprávnění pro administraci administrátorských uţivatelů 32
userLogin – cizí klíč tabulky UserLogins, kaţdý administrátor má svůj userLogin o v tabulce UserLogins je uloţeno heslo administrátora o userLoginId je vyuţito při zakládání administrátorských hovorů z administrativního rozhraní o uţivatelský login se vyuţívá všude, kde je potřeba dát administrátorovi schopnosti uţivatelského účtu o na uţivatelský login, který je svázán s administrátorským účtem se nedá přihlásit v klientském rozhraní
Tabulka SupportIssues obsahuje tikety zákazníků, kteří mají nějaký problém se sluţbou, či nějaký dotaz na administrátory systému. Kaţdý uţivatel můţe zaloţit 0 aţ N tiketů a kaţdý administrátor se můţe starat o vyřešení 0 aţ N tiketů. Tiketů je více typů (tabulka SupportTypes), které jsou lokalizovány do jazyka uţivatele. Atributy tabulek podpory:
tabulka SupportTypes obsahuje seznam typů podpory v českém jazyce SupportTypeLocales je asociativní tabulka, která obsahuje lokalizace typu podpory do všech jazyků pouţitých v systému o Primární klíč supportType – typ podpory language – jazyk o name – název typu podpory v daném jazyce o defaultText – text podpory předvyplněný zákazníkovi
Tabulka SupportIssues: o o o o o o o o o o
Id – jednoznačný identifikátor tiketu supportType – typ podpory, cizí klíč tabulky SupportTypes language – jazyk, ve kterém je tiket napsán userLogin – uţivatelský účet, kterým byl tiket zadán. Můţe být NULL, pokud dotaz není od přihlášeného zákazníka name, email – pole, které uţivatel sluţby vyplní na webu, pokud není přihlášen when – datum a čas vytvoření tiketu text – vlastní text tiketu poslaný zákazníkem sluţby adminComment – komentář administrátora systému solver – řešitel tiketu, cizí klíč tabulky administrátorů done – čas, ve kterém byl tiket uzavřen
Tabulka Payments obsahuje informace o zákazníkových platbách. Vlastní realizace elektronických plateb není součástí této práce. Tabulka obsahuje tyto atributy:
id – jednoznačný identifikátor, primární klíč userAccount – cizí klič tabulky UserAccounts, vazba na zákazníka, který provedl platbu when – datum a čas připsání platby na kreditový účet zákazníka value – částka připsaná na účet zákazníka remoteSystemType – identifikátor systému, který provedl připsání platby na účet zákazníka. 33
remoteSystemId – identifikátor záznamu o platbě v cizím systému, který propojuje záznamy o platbách obou systémů
Definice entit Countries a Languages byly probrány v kapitole 4.5.2.1.
Obrázek 4-11: ERD popisující tabulky, ve kterých jsou uložena zákaznická data.
4.5.3.1 Evidence telefonních čísel a kontaktů zákazníka Tato kapitola bude hovořit o způsobu, jakým jsou evidována telefonní čísla zákazníka, jakým způsobem dochází k autentizaci – k důkazu, ţe telefonní číslo opravdu vlastní přihlášený uţivatel; 34
dále bude hovořit o kontaktech zákazníka a o tom, jakým způsobem jsou uloţena data určená pro rychlou volbu. Na obrázku Obrázek 4-12 je ERD databáze, ve kterém jsou uloţena data pro poskytnutí uvedených sluţeb.
Obrázek 4-12: ERD evidence telefonních čísel a kontaktů zákazníka.
Uţivatelský login obsahuje 0 a více telefonních čísel, kterým je vlastníkem a chce s nimi vyuţívat sluţby clicktocall. Tyto telefonní čísla jsou uloţena v tabulce Phones. Popis entit tabulky:
primární klíč 35
o userLogin – vazba na uţivatelský login, cizí klíč tabulky UserLogins o phoneNumber – číslo telefonního přístroje authorized – informace, zdali bylo telefonní číslo autorizováno, zdali bylo ověřeno, ţe číslo patří danému loginu. Jedno telefonní číslo můţe být autorizováno pouze u jednoho loginu. Pokud by tomu tak nebylo, nebylo by moţno vyuţít sluţeb rychlé volby, která je zaloţena na pevném navázání telefonního čísla na uţivatelský login. comment – komentář k telefonnímu číslu
Pro autorizaci telefonních čísel se vyuţívá tabulka PhoneAuthorizations. Po přidání telefonního čísla v klientském systému dojde k přidání poţadavku o autorizaci do tabulky PhoneAuthorizations. Vlastní autorizace je provedena tak, ţe je uţivateli řečeno, aby prozvonil jedno z čísel sluţby clicktocall, které je určeno pro autorizaci telefonů. Pokud zákazník sluţby vlastní telefon se zaregistrovaným telefonním číslem, pak prozvoní přidělené autorizační číslo a volání z jeho telefonu je nyní povoleno. Systém umoţňuje, aby existovalo více poţadavků na autorizaci telefonního čísla – z různých loginů – ale telefonní číslo můţe být nakonec autorizováno pouze a jen u jednoho uţivatelského loginu. Popis atributů tabulky PhoneAuthorizations:
id – jednoznačný identifikátor autorizace, primární klíč phoneNumber, userLogin – telefonní číslo a uţivatelský login, cizí klíč tabulky Phones confirmationNumber – autorizační číslo – telefonní číslo, které musí být prozvoněno, aby došlo k autorizaci, cizí klíč tabulky OurPhoneNumbers requestIp – ip adresa, ze které bylo poţádáno o autorizaci čísla – evidenční charakter requested – datum a čas, ve kterém došlo k poţádání o autorizaci requestTimeout – čas, po kterém ţádost o autorizaci vyprší confirmed – kdy došlo k prozvonění clicktocall systému a tudíţ k autorizaci telefonního čísla cancelled – pokud bylo v době prozvonění clicktocall systému aktivních více telefonních autorizací pro dané telefonní číslo (tyto autorizace musí mít různé confirmationNumber), pak dojde k autorizaci k jedinému loginu a ostatní ţádosti o autorizaci jsou zrušeny, je jim nastaven atribut cancelled
OurPhoneNumbers je tabulka obsahující seznam vlastních telefonních čísel sluţby clicktocall a k čemu jsou tato čísla vyuţita. Jde o 1000 telefonních čísel. Popis atributů tabulky:
number – telefonní číslo, primární klíč type – typ telefonního čísla o autorizační telefonní číslo o telefonní číslo pro rychlou volbu
AddressBookItems je tabulka obsahující kontaktní osoby zákazníka, popis jejich atributů:
id – jednoznačný identifikátor kontaktu, primární klíč userLogin – vazba na login uţivatele – cizí klíč name – název kontaktu email – email kontaktu 36
comment - komentář
Contacts je tabulka obsahující telefonní čísla kontaku, tato telefonní čísla mohou mít přidána rychlou volbu – tj. vytvářet spojení na tato čísla pomocí prozvonění systému clicktocall. Popis atributů tabulky:
id – primární klíč, identifikátor kontaktního telefonního čísla addressBookItem – vazba na tabulku adresářových poloţek zákazníka, cizí klíč phoneNumber – telefonní číslo kontaktu speedDial – telefonní číslo systému clicktocall, jehoţ prozvoněním z autorizovaných telefonních čísel zákazníka sluţby dojde ke spojení mezi číslem, z něhoţ došlo k prozvonění, a číslem kontaktu (phoneNumber). Speeddial číslo lze uloţit do telefonního seznamu na telefonu; zákazník sluţby tudíţ volá velice podobně, jako by volal ze svého telefonu obvyklým způsobem. Comment - komentář
37
4.5.4 Tabulky uchovávající informace o hovorech
Obrázek 4-13: Schéma tabulek využívaných ke spojování hovorů.
Na obrázku Obrázek 4-13 je ERD uchovávající data nutná k uskutečnění, uchování stavů a účtování hovorů. Entity jsou rozdělené podle barev na:
modrá – entity nutné pro spojení hovoru a uchování stavu aktivního hovoru v systému 38
zelená – entity týkající se uţivatelů a ukončených hovorů bílá – záznamy historie (logy) a ostatní
Popis jednotlivých entit:
priorities – tabulka priorit, která udává s jakou prioritou se bude volat přes jakou terminaci do dané sítě. Výběr terminace pro hovor je proveden tak, ţe jsou nejdříve vybrány terminace s nejvyšší prioritou pro danou síť, nad nimi se provede least cost routing a hovor se spojí. Pokud se přes danou terminaci hovor nepodaří spojit, pak se systém pokusit navázat spojení přes další terminaci a původní terminace obdrţí pro danou síť černé body (blackPoints), které ji v důsledku mohou sníţit prioritu a znevýhodnit při dalším spojování do dané sítě. Toto řešení řádově zvyšuje úspěšnost a rychlost spojení hovoru, terminace jsou samy o sobě nízkonákladové a tudíţ ne moc spolehlivé. o primární klíč termination – cizí klíč z entity Terminations networks – cizí klič z entity Networks o priority – administrátorem nastavená priorita, umoţňuje zvýhodnit volání do určité sítě přes určitou terminaci o blackPoints – modifikace priority, která je nastavuje automaticky podle toho, jak moc je daná terminace schopna směrovat danou síť Terminations – tabulka obsahující informace o terminacích TerminationStatus – log uchovávající změny ve stavu terminací – kdy došlo k jejich výpadku, kdy byly opět uvedeny do provozu a podobně. Tato data jsou získávána z démona. Poslední záznam této tabulky ukazuje aktuální stav spojení s terminací. o id – primární klíč, jednoznačný identifikátor záznamu o termination – identifikátor terminace, pro kterou záznam je, cizí klíč z terminations o daemon – identifikátor démona, cizí klíč z Daemons o when – datum a čas, ve kterém nastala změna stavu o status – stav, do kterého se terminace na daném serveru dostala, viz terminace připojena, odpojena, … ActiveCalls – entita uchovávající informace o aktivních hovorech. V případě, ţe by v systému nebyl kladen důraz na vysokou dostupnost, pak by obsah této tabulky byl v paměti procesu démon. Tabulka udrţuje konzistentní informace o aktivních hovorech, a to i v případě pádu některého ze serverů sluţby. o id – jednoznačný identifikátor hovoru, primární klíč o userLogin – identifikátor uţivatelského loginu, který hovor vlastní, cizí klíč z UserLogins o daemon – démon, který hovor obsluhuje, cizí klíč z Daemons, pole je vyplněno aţ po vyzvednutí poţadavku o hovor některým z démonů z commandQueue o srcTermination – zdrojová terminace, v poli je zapsána aktuální pouţitá terminace pro spojení, v případě, ţe daná terminace spojení nedokáţe nevázat, je pokračováno další terminací. Cizí klíč z tabulky Terminations o dstTermination – cílová terminace
39
rateImports – importní bod ceníků terminací, který je pro hovor vyuţit, vyuţívá se při překlopení mezi dvěma importními body, aby u aktivních hovorů bylo jasné, podle ceníku kterého importního počítat náklady spojení hovoru; cizí klíč z RateImports o state – stav spojení hovoru, uvádí počet fungujících spojení s telefony 0 – neexistuje ţádné spojení, ani se zdrojovým číslem, snaţíme se s ním spojit 1 – existuje spojení se zdrojovým číslem, navazujeme spojení s číslem cílovým 2 – existuje spojení se zdrojovým i cílovým číslem o added – čas vytvoření hovoru o code – název souboru obsahující stav hovoru, který backend poskytuje pomocí webového serveru přímo zákazníkovi sluţby (viz obrázek Obrázek 4-1) o twoWayStartTime – čas, ve kterém došlo ke spojení obou stran hovoru o type – typ hovoru normální hovor administrátorský testovací hovor hovor promo akce – zde mohou zákaznící sluţby vyzkoušet spojení dvou telefonních čísel bez registrace účtu a zdarma, ale na velice omezenou dobu rychlá volba zelená linka o cache atributy – atributy, jejichţ hodnoty jde dopočítat z ostatních tabulek. Výpočet některých atributů je více náročný, proto došlo k porušení třetí normální formy návrhu databáze a k uchování těchto duplicitních dat. Tato pole nejsou definována jako cizí klíče, nemusí docházet ke kontrole integrity dat srcGroup – zdrojová skupina prefixů, do které patří zdrojové telefonní číslo dstGroup – cílová skupina prefixů srcNetwork – zdrojová síť dstNetwork – cílová síť userAccount – uţivatelský účet, kterému bude hovor zaúčtován, díky tomuto atributu a atributu rate je moţno rychle dopočítat čas, po kterém dojde kredit uţivateli, který má více paralelních hovorů rate – cena za minutu hovoru v Kč o daemons – tabulka uchovávající informace o démonech o CommandQueue – tabulka příkazů, jejím prostřednictvím jsou zaloţeny poţadavky o zaloţení hovoru, které si vyzvedne jeden ze serverů sluţby UserLogins – tabulka loginů uţivatelů, kredit je uchován v tabulce UserAccounts, který můţe zdruţovat více loginů FinishedCalls – tabulka všech dokončených hovorů, je v ní vyhledáváno zejména podle uţivatele, který hovory uskutečnil o id – jednoznačný identifikátor dokončeného hovoru, primární klíč o srcNetwork – zdrojová síť hovoru, cizí klíč tabulky Networks o dstNetwork – cílová síť hovoru, cizí klíč tabulky Networks o userLogin – login uţivatele, který zaloţil hovor o startTime – čas, ve kterém došlo ke spojení obousměrného hovoru o srcNumber – zdrojové číslo o dstNumber – cílové číslo o
40
srcTermination – zdrojová terminace dstTermination – cílová terminace state – stav, ve kterém hovor zkončil (např. došlo jen ke spojení zdroje) oneWayDuration – doba, po kterou byl spojen pouze zdroj, v sekundách twoWayDuration – účtovaná doba hovoru srcCosts – celkové náklady na spojení zdroje dstCosts – celkové náklady na spojení cíle rate – minutová sazba účtovaná zákazníkovi rateTaxed – minutová sazba včetně DPH gain – celková trţba za hovor (utrţený kredit) gainTaxed – celková trţba za hovor včetně DPH (to je uloţeno v tabulce konfigurace systému) o terminated – stav ukončení hovoru srcHangup, dstHangup – zdroj, nebo cíl ukončil probíhající hovor srcBusy, dstBusy – obsazeno srcCancel, dstCancel – hovor byl odmítnut srcError, dstError – systém nedokázal spojit zdroj, nebo cíl z jiného důvodu o type – v jakém stavu byl hovor ukončen, stejné stavy, jako pole type v tabulce ActiveCalls Networks – seznam sítí uloţený do stromu Ringings – log prozvonění sluţby, tj. zákazník prozvoní jedno z telefonních čísel, které jsou pro sluţbu určeny. Prozvonění je vyuţíváno pro autentizaci telefonního čísla a k rychlé volbě, tato tabulka má pouze evidenční charakter o id – jednoznačný identifikátor události, primární klíč o when – datum a čas, kdy k prozvonění došlo o srcNumber – zdrojové telefonní číslo o dstNumber – cílové telefonní číslo o o o o o o o o o o o
4.6 Administrativní rozhraní systému Administrativní rozhraní umoţňuje správu systému, jde zejména o
správu uţivatelských účtů o Práce s kreditem, výpis volání nastavení terminací, sítí, importy ceníků terminací nastavení cen účtovaných zákazníkům dohled systému – informace, zdali běţí démoni, Asterisky a terminace obecná nastavení – jazyky, měny podpora uţivatelů statistiky vyuţití systému
Administrativní rozhraní je sada CGI skriptů, které jsou dostupné na všech serverech sluţby. Administrátoři se připojují na rozhraní, které je dostupné na plovoucí IP adrese VRRP protokolu. Na obrázku 9-5 je ukázáno, jak vypadá administrativní rozhraní systému.
41
4.7 Zabezpečení Zabezpečení VoIP je třeba věnovat velkou pozornost – útočník je kompromitací VoIP systému schopen přímo získat část financí oběti. Útoky probíhají podle velice podobného scénáře: 1. útočník získá přihlašovací údaje, které pouţívá VoIP klient k přihlášení k VoIP bráně, nebo získá přístup k VoIP přístroji, který mu umoţní spojovat hovory z daného přístroje. 2. útočník je nyní schopen vytočit číslo placené linky, toto volání je financováno obětí, příjmy z volání na placenou linku se rozloţí mezi operátora a útočníka, případně jeho komplice. 3. útočník vyuţije nejlépe sluţeb zahraniční placené linky – český operátor za spojení s danou linkou musí zaplatit zahraničnímu operátorovi nezávisle na tom, zdali mu český zákazník zaplatí. V důsledku českému operátorovi nezůstane jiná moţnost, neţ se soudit s českým zákazníkem o finance, které jiţ byly zaplaceny zahraničnímu operátorovi. Obrany proti tomuto typu útoku jsou: 1. vyuţití předplaceného kreditového systému – útočník získá maximálně částku, která je na účtu 2. denní limit na provolanou částku 3. blokace placených telefonních předčíslí Ideální je kombinace výše uvedených bezpečnostních mechanismů.
4.8 Kodeky Cílem systému je maximalizovat počet obslouţených hovorů na jednom počítačovém serveru. Úzkým hrdlem je zde procesor. Podle kodeku na vstupu a na výstupu z telefonní ústředny rozlišujeme 2 přístupy práce s médiem:
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
Dalším úzkým hrdlem je propustnost síťového rozhraní.
Nyní porovnáme 2 kodeky, které jsou principielně na opačných stranách barikády. G.711 je kodek, který se snaţí přenést co nejčistší hlas bez komprese, zatímco G.729 se pomocí samplování vzorků snaţí minimalizovat datovou náročnost, ale na druhou stranu je kódování do G.729 procesorově náročný úkon. Porovnání datové náročnosti kodeků G.711 a G.729 [19]:
Datová náročnost kodeku
G.711
G.729
64Kbit
8Kbit
42
Reţie (overhead)2 bez 802.1q[21]
23,2Kbit
23,2Kbit
Celková datová náročnost
87,2Kbit
31,2Kbit
Hovorů/100Mbit (1 hovor = 2 spojení)
573
1602
Překvapivá velikost reţie je dána velikostí samotných datových paketů a rámců, při 20ms paketizaci je její velikost:
RTP reţie
12B [20]
Hlavička UDP
8B
Hlavička IP
20B
Ethernet hlavička
18B [9]
802.1q hlavička
4B
Reţie celkem bez 802.1q
58B
Reţie celkem včetně 802.1q
62B
Vzhledem k tomu, ţe G729 má niţší kvalitu hlasu, je licencovaný (10$ za 1 celkově probíhající hovor3, v případě retranslace), kódování do něj hodně vytíţí CPU [19], oproti G.711 přes něj není moţno poslat fax, je při dnešních rychlostech internetu dosahujících řádově 10 MBit/s otázkou historie. Z výše uvedených důvodů bylo rozhodnuto pro vyuţití native bridge. Průnikem mnoţin kodeků, které nabízely terminace byl právě kodek G.711. Počet hovorů obslouţených na 100Mbit síťovém rozhraní také řádově převyšuje poţadavky na systém, tudíţ byl zvolen právě tento kodek.
5 Průchody systémem Tato kapitola popisuje vzorové průchody systémem, které ilustrují, jakým způsobem jednotlivé komponenty systému fungují a komunikují, ukazují, jak systém funguje jako celek. Průchody jsou vyvolány externí akcí mimo vlastní systém, případně v určitý čas. Popsat zde všechny průchody systémem je nad rámec této práce, většina ostatních průchodů je popsána pomocí uloţených procedur v přiloţených souborech.
5.1 Spojení hovoru přes zákaznický web Předpokládáme, ţe zákazník je přihlášen na zákaznickém webu. Zvolí zdrojové číslo ze svých autorizovaných čísel a zadá číslo (můţe vyuţít adresář), na které se chce dovolat. Pro představu, jak vypadá zákaznické rozhraní, se můţete podívat na obrázek Obrázek 9-3.
2
V případě 20ms paketizace, kterou vyuţívá Asterisk. Vyšší míra paketizace = větší reţie
3
http://store.digium.com/productview.php?product_code=G729CODEC
43
1. Po kliku na tlačítko klikni a volej dojde k zavolání uloţené procedury makecall, ta zkontroluje zadané údaje, kredit a zaloţí hovor – to znamená: a. vypočítá údaje o zdrojové a cílové síti, tj. určí zdrojovou skupinu prefixů (viz kap. 4.5.1), cílovou skupinu prefixů, zdrojovou a cílovou síť, nákladovou i účtovanou cenu b. přidá záznam s vypočítanými údaji do tabulky aktivních hovorů (ActiveCalls, viz kap. 4.5.4) c. přidá příkaz pro libovolného démona do tabulky příkazů (CommandQueue, viz kap. 4.2). 2. V rámci pravidelného vyzvedávání příkazů jeden z démonů vyzvedne příkaz ke spojení telefonního hovoru, který obsahuje identifikátor hovoru v tabulce aktivních hovorů. 3. Démon si z tabulky ActiveCalls přečte informace o hovoru, který má zaloţit a zahájí zakládání hovoru 4. Démon si udrţuje nacacheovanou směrovací informaci pro skupinu prefixů, tj. pořadí terminací, přes které se má do ní zkusit dovolat. Toto směrování má zvlášť pro zdroj a cíl. 5. Démon zaloţí pomocí AMI rozhraní (viz kap. 2.4.2) hovor na Asterisku, ke kterému je démon připojen, jedinými argumenty je identifikátor hovoru a timeout, po kterém se má pokus o spojení hovoru ukončit přes všechny terminace. 6. Asterisk začne provádět svůj vytáčecí plán (viz kap. 2.4.1), v němţ cyklicky volá AGI (viz kap. 2.4.3) rozhraní démona a. volání AGI informuje démona o aktuálním stavu hovoru a démon informuje Asterisk o akci, kterou má dále vykonat. V praxi jde o volání funkce Dial (viz kap. 2.4.1.1) – démon tímto říká, přes jakou terminaci má dojít ke spojení hovoru a na jaké telefonní číslo. Při volání funkce Dial je nastaveno zdrojové číslo (callerid) na číslo protistrany. Tudíţ příjemce hovoru nevidí rozdíl oproti běţnému hovoru. b. po volání funkce Dial dojde k opětovnému zavolání AGI démona, volání obsahuje informaci o stavu hovoru – o tom, zdali se volání podařilo i. pokud se volání přes danou terminaci nepodařilo, pak démon k přidá černé body pro uspořádanou dvojici (terminace, síť), viz kapitola 4.4.3.1, zvolí další terminaci, přes kterou má hovor jít a pokračuje bodem 6.a. Pokud strana hovor odmítla (hovor je odmítnut, nebo je obsazeno), pak je celý pokus o spojení telefonního hovoru ukončen. ii. pokud se kanál podařilo spojit, pokračuje se bodem 6.c c. informaci o změně stavu hovoru (o spojení strany) démon uloţí do tabulky aktivních hovorů d. nyní je spojen hovor se zdrojovou stranou a dojde ke spojení s cílovou stranou, a to stejným způsobem, jako popisuje bod 6.b. Pokud dojde při spojení s cílovou stranou k chybě, tj. hovor je odmítnut, nebo je obsazeno, pak je tato informace sdělena lokalizovanou zvukovou nahrávkou zdrojové straně e. po úspěšném spojení mezi ústřednou a zdrojovou stranou a ústřednou a cílovou stranou dojde ke spojení obou kanálů a začne probíhat vlastní hovor. Informace je sdělena databázi, do tabulky aktivních hovorů je sdělen přesný čas navázání obousměrného spojení. 7. Nyní se začíná účtovat hovor. Démon zavolá funkci, která nastaví maximální délku všech hovorů (viz kap. 4.4.1) zákaznickému účtu (pozor, ne loginu, viz kap. 4.5.3). Pokud by na
44
zákaznickém účtu byl úspěšně vytvořen další hovor, pak dojde k aktualizaci maximální délky i aktuálního hovoru. 8. V průběhu hovoru není, z důvodu minimalizace vytíţení, databáze vůbec vyuţívána. Zákazníkovi se informace o hovoru přenáší pomocí webového serveru, který čte informaci o hovoru z ramdisku (viz obrázek Obrázek 4-1). Tato informace je mu zobrazena na webové stránce, pro představu viz obrázek Obrázek 9-4. 9. Dále je na harddisk serveru uloţena informace, kdy byl naposled hovor aktivní. Tato informace se ukládá kaţdých 5 sekund a je vyuţívána v případě pádu serveru pro dostatečně přesný výpočet kreditu, který má být odečten zákazníkovi (viz kap. 5.3). 10. Po ukončení hovoru, který můţe být ukončen zavěšením jedné ze stran, zavěšením pomocí webového klientského rozhraní, zásahem administrátora, či vyčerpáním kreditu, dojde k následujícím akcím: a. AGI informuje démona u zavěšení hovoru b. démon zavolá proceduru finishCall, která se postará o dokončený hovor c. ta spočítá celkovou cenu hovoru, odečte zákazníkův kredit a přesune hovor z tabulky aktivních hovorů do tabulky ukončených hovorů (FinishedCalls). Cena hovoru je vypočítána vynásobením délky hovoru v započatých minutách a minutové sazby za spojení daných telefonních sítí. d. je aktualizována délka ostatních hovorů zákaznického účtu (viz kap. 4.4.1). e. dojde k opoţděnému smazání informace o stavu hovoru z ramdisku a harddisku serveru
5.2 Funkce rychlé volby Hovor se velice podobá standardnímu průběhu hovoru, liší se pouze tím, jak je hovor zaloţen. 1. Zákazník prozvoní ze svého telefonního čísla jedno z telefonních čísel ústředny sluţby clicktocall 2. Informace o prozvonění přijde od terminačního operátora, který se stará o směrování telefonních čísel sluţby na plovoucí VRRP ip adresu, která náleţí jednomu ze serverů 3. Hovor je převzat jedním z Asterisků, ten hovor nezvedne, ale je schopen pomocí jednostranného zvukového záznamu sdělit informaci o stavu rychlé volby bez toho, aby byl hovor zákazníkovi účtován 4. Pomocí AGI rozhraní se o hovoru dozví démon, který po konzultaci s databází určí, zdali jde o funkci rychlé volby. 5. Pokud ano, pak z databáze zjistí, k jakému uţivateli rychlá volba náleţí a jaké číslo má na základě rychlé volby spojit. 6. Systém provede stejné kontroly a akce jako pouţívá funkce makeCall, informaci o stavu řekne volajícímu lokalizovanou nahrávkou. Stavy mohou být: a. Rychlá volba přijata b. Neznámá rychlá volba (toto číslo rychlé volby není přiřazeno k ţádnému kontaktu zákazníka) c. Nemáte dostatečný kredit d. Hovor není povolen (cílová síť není povolena) e. Máte skryté číslo 45
Poté systém vyzve uţivatele k poloţení hovoru a po určité době jej sám poloţí. 7. Další rozdíl oproti makeCall je v tom, ţe inicializace hovoru (tj. přidání příkazu do fronty příkazů) není provedeno ihned, ale aţ po zavěšení hovoru – to z důvodu, aby nebyla zdrojová strana obsazena. 8. Dále jiţ hovor probíhá stejně, jako u standardního hovoru popsaného v kapitole 5.1
5.3 Hovor a výpadek serveru V případě, ţe dojde k výpadku serveru při probíhajících hovorech, pak dojde k výpadku těchto hovorů. Na harddisku serveru je uloţeno, kdy byl démon naposled aktivní. Z této informace a z informace o času započatí hovorů je po restartu serveru systém schopen dopočítat, jak dlouho dané hovory běţely a jaký má být odečten zákazníkovi kredit. Po restartu serveru tudíţ démon provede zakončení všech hovorů, které jsou evidovány v tabulce aktivních hovorů, ţe běţely na tomto serveru – tj. doplní celkovou délku hovorů, odečte kredit a přesune hovory do tabulky FinishedCalls. Démoni systému periodicky zjišťují, v jakém stavu jsou ostatní démoni, tuto informaci aktualizují v tabulce Daemons. Hovory, které jsou na neaktivním démonovi, systém nebere jako aktivní.
5.4 Další průchody systémem Autorizace telefonního čísla – podobá se rychlé volbě – zákazník musí v určitém čase prozvonit ze svého telefonního čísla správné číslo ústředny. Ta mu pomocí zvukového záznamu sdělí, zdali došlo k úspěšné autorizaci a hovor ukončí. Hovor není zvednut, tudíţ zákazníkovi není účtován ţádný poplatek jeho operátorem. Přidání dalšího terminačního operátora – jakmile administrátor přidá dalšího terminačního operátora, dojde k jeho uloţení do databáze a přidání příkazu na přegenerování SIP konfigurace do fronty příkazů zvlášť pro kaţdého démona. Démon po vyzvednutí příkazu na základě tabulky Terminations vygeneruje nový konfigurační soubor /klikni/Asterisk/generated/sip.conf a přes AMI rozhraní zavolá funkci Asterisku sip reload, která se postará o znovunačtení konfigurace SIP protokolu. Při změně stavu terminace (při jejím úspěšném spojení) přijde démonovi přes AMI rozhraní událost a ten do databáze uloţí stav spojení mezi svým Asteriskem a terminací. Změna priority terminace vůči síti – po změně priority terminace vůči síti (ať jiţ administrativním zásahem, nebo přidáním černých bodů) dojde k přidání příkazu do fronty příkazů pro kaţdého démona zvlášť, ať zneplatní svou cache, která se týká směrování dané telefonní sítě. Zákazník a informování o stavu hovoru – po kliknutí na tlačítko spojení hovorů je pro hovor vygenerováno dlouhé náhodné číslo, díky kterému je zákazníkův webový prohlíţeč schopen zobrazit stav hovoru. Démon běţící na serveru s Asteriskem ukládá informaci o stavu hovoru do souboru na ramdisku, který je zákazníkovi propagován pomocí webového serveru (lighttpd). Název souboru je právě vygenerované náhodné číslo. Démon informaci o aktuálním stavu hovoru zjišťuje pomocí AGI (proměnná DIALSTATUS) a také pomocí AMI (události, který vznikly v Asterisku). Po dokončení hovoru je soubor na ramdisku ještě uchován po dobu 30 sekund, aby se prohlíţeč dozvěděl o posledním stavu hovoru, poté je smazán.
46
6 Implementace a nastavení komponent systému 6.1 Asterisk Kaţdý démon je spojen právě s jedním Asteriskem. Komunikuje s ním pomocí AGI a AMI rozhraní (viz kap. 2.4.2 a 2.4.3). Asterisk vyuţívá následující soubory, které mají vazbu na systém clicktocall:
/klikni/asterisk/extensions.conf – vytáčecí plán, obsahující volání AGI démona. Tento soubor je statický /etc/asterisk/sip.conf – statický soubor, který includuje konfiguraci, která je generována clicktocall systémem o /klikni/asterisk/generated/sip.conf – obsahuje konfiguraci propojení s terminacemi, soubor je generován z databáze o /klikni/asterisk/sip.conf – obsahuje konfiguraci propojení s terminací, která se stará o směrování příchozích hovorů /etc/Asterisk/manager.conf – nastavuje parametry pro AMI – tj. přihlašovací údaje, oprávnění uţivatele AMI, dále zprávy jakého typu budou ze systému uţivateli rozhraní zasílány
Pokud se démon dostane do stavu blízkému pádu, pak démon restartuje Asteriska – účelem je ukončit všechny hovory. Pokud démon není schopen hovory řídit, pak je lepší, aby hovory byly ukončeny a systém zůstal v konzistentním stavu.
6.2 Konvence uložených databázových procedur Čtení záznamů z databáze je prováděno pomocí pohledů (VIEW) nebo uloţených funkcí (FUNCTION). Tyto nemohou modifikovat stav databáze. Funkce vrací tabulku, jejíţ sloupce jsou specifikované u kaţdé funkce. Modifikace databáze probíhá pomocí uloţených procedur (PROCEDURE). Procedura vrací jeden záznam obsahující sloupce:
result INT - má hodnotu 1, pokud operace byla úspěšná, jinak hodnota je 0 error VARCHAR(15) - označení chyby, specifikováno u dané procedury, nebo NULL, pokud byla operace úspěšná (nedošlo k chybě) id INT - vygenerovaný identifikátor záznamu, vracen jen procedurami, které přidávají záznam do tabulek s generovaným id další sloupce definované u dané procedury
Všechna telefonní čísla mají formát začínající mezinárodní předvolbou bez mezer. Před předvolbou není ţádná úvodní nula nebo +. České mobilní číslo můţe pak vypadat: 420602111345.
6.2.1 Vzorové uložené procedury pro klientské rozhraní Veškerá komunikace s frontendem sluţby je provedena za pomocí uloţených databázových procedur. V této kapitole ukazuji deklarace některých důleţitých uloţených procedur v MSSQL databázi.
47
makeCall – Procedura, kterou uţivatelské rozhraní ţádá o vytvoření hovoru pod uţivatelským loginem. Nejprve jsou zkontrolována oprávnění loginu (autorizace zdrojového čísla a další oprávnění) a výše kreditu na daném uţivatelském účtu. o
parametry:
o
userLogin INT - id loginu uţivatele, kvůli kontrole zdrojového telefonního čísla a kreditu srcNumber VARCHAR(25) - zdrojové telefonní číslo dstNumber VARCHAR(25) - cílové telefonní číslo callType INT = 0 - id typu volání - definuje další parametry hovoru, uţivatelské hovory mají tento atribut nastavený na 0 návratové hodnoty:
result INT
1 = hovor předán na spojení 0 = hovor nelze zaloţit
error VARCHAR(15)
'badLogin' - nesprávný uţivatelský login
'activeCall' - probíhá aktivní hovor pod tímto loginem
'badNumber' - zdrojové číslo není zaregistrováno k loginu nebo není autorizováno
'notAllowed' - hovor není povolen z jiných důvodů neţ 'badNumber'
'noCredit' - na účtu není dostatečný kredit
'noRoute' - systém neumí spojení uskutečnit
id INT - identifikátor volání – slouţí pro zjištění informací o hovoru z tabulky ActiveCalls
addSourceNumber – procedura, která přidá zdrojové neautorizované číslo k uţivatelskému loginu. Pokud je číslo jiţ autorizováno u jiného uţivatelského účtu, není moţno jej přidat k dalšímu. Pokud více uţivatelů provádí autorizaci stejného čísla, číslo je přiřazeno k účtu toho, který jej autorizuje nejdříve. o
o
Parametry:
userLogin INT - identifikátor uţivatelského loginu, k němuţ se má číslo přiřadit
phoneNumber VARCHAR(25) - číslo, které se má přiřadit
comment NVARCHAR(100) - poznámka k číslu (např. doma, z práce)
Návratové hodnoty:
o
result INT – hodnota 1, pokud číslo bylo přiřazeno k loginu a můţe být autorizováno
error VARCHAR(15) 48
o
'badLogin' = uţivatelský login definovaný userLogin neexistuje
'alreadyUsed' = číslo je uţ zaregistrované jako primární k jinému loginu (stejného nebo jiného uţivatelského účtu)
'depleted' = bylo dosaţeno limitu pro počet čísel k jednomu uţivatelskému loginu
'outOfNumbers' = není k dispozici ţádné volné číslo pro autorizaci
authorizeNumber VARCHAR(25) - číslo, které bude pouţito pro autorizaci přidaného čísla. Nové číslo bude autorizováno prozvoněním daného čísla.
6.2.2 Uložené procedury pro práci s frontou příkazů Tato kapitola popisuje deklaraci uloţených procedur pro práci s commandQueue. o
addCommand – přidá příkaz do příkazů, který je později vyzvednut procedurou fetchCommand o
o
parametry:
command VARCHAR(30) – identifikátor příkazu, identifikuje komponentu, pro kterou je daný příkaz určen
parameter1 INT – nepovinný parametr příkazu
parameter2 INT – nepovinný parametr příkazu
parameter3 INT – nepovinný parametr příkazu
daemon INT – nepovinný parametr, nastavuje démona, který se o daný příkaz má postarat. V případě implicitní hodnoty NULL je příkaz vyzvednut kterýmkoliv démonem
when DATETIME – čas, ve který má být příkaz vyzvednut k provedení, pokud je hodnota NULL, je příkaz vyzvednut ihned
návratová hodnota
commandId INT – vrací id příkazu, který je díky této hodnotě moţno např. smazat
FetchCommand je procedura, která se stará o získání příkazu z fronty příkazů. Zajišťuje atomické přečtení záznamu a jeho odstranění, k tomu vyuţívá explicitní zamykání řádku, které umoţňuje Transact-SQL. Tuto proceduru cyklicky volají démoni a provádějí příkazy, které jim procedura vrátí.
parametry: o daemon INT – identifikace démona volajícího proceduru návratové hodnoty: o id INT – jednoznačný identifikátor příkazu o command VARCHAR(15) - příkaz o
parameter1 INT – nepovinný parametr příkazu
o
parameter2 INT – nepovinný parametr příkazu 49
o
parameter3 INT – nepovinný parametr příkazu
o
when DATETIME – čas, ve který má být příkaz vyzvednut k provedení, pokud je hodnota NULL, je příkaz vyzvednut ihned
o
delay FLOAT – počet sekund od vloţení příkazu do fronty
6.3 Zabezpečení Útoky na sluţbu clicktocall, popř. její jiná nezákonná zneuţití jsou: 1. ukradení přístupu k terminacím, jeţ jsou placeny prepaid systémem – ale s obrovským kreditem řádově v desítkách, aţ stovkách tisíc Kč 2. ukradení zákaznického uţivatelského účtu 3. denial of Service [21] útok 4. změna callerid na callerid třetí osoby
6.3.1 Zabezpečení vůči zneužití terminací Pro komunikaci s terminacemi servery vyuţívají neznámých IP adres, které jsou vyuţity pouze k tomuto účelu. Tyto IP adresy znají pouze terminace a administrátoři systému. Autentizace vůči terminacím je prováděna pomocí uţivatelského jména, hesla a zejména IP adresy, ze které se klient (systém clicktocall) připojuje. Přístup na tyto IP adresy je povolen pouze z IP adres terminací a to na porty SIP a RTP protokolu. Pro jakékoliv jiné sluţby (včetně icmp zpráv) se tyto IP adresy jeví jako mrtvé (iptables cíl DROP). To, ţe útočník nemá jednoduchý způsob, jak zjistit na které IP adresy jsou vyuţity pro vlastní hovory mu znemoţňuje IP address spoofing útoky [22]. Podobným způsobem je ochráněna sluţba rychlé volby, systém clicktocall má zvláštní IP adresu, kterou pouţívá pro rychlou volbu, ke které mají přístup pouze servery terminací, které ji zajišťují. Jediný rozdíl je v tom, ţe tato IP adresa je plovoucí mezi všemi servery sluţby clicktocall vyuţívající Asterisk.
6.3.2 Zabezpečení administrátorského přístupu a přístupu ke stavům hovorů Přístup do administrátorského rozhraní je omezen na skupinu povolených zdrojových IP adres. Dále je třeba se přihlásit pomocí jména a hesla, při 3 neúspěšných pokusech o přihlášení je uţivatelský účet zablokován a informace o blokaci jsou zaslány ostatním uţivatelům systému, kteří mají oprávnění účet odblokovat. Administrátorské rozhraní je zpřístupněno pomocí https protokolu šifrujícím komunikaci a znemoţňující man-in-the-middle [23] útoky. IP adresa rozhraní, které zasílá informace o aktuálním stavu hovoru, je jediná IP adresa backendu sluţby clicktocall, která je přímo přístupná zákazníkům sluţby; tudíţ zde můţeme očekávat větší míru rizika útoku. Na této IP adrese běţí pouze webový server, který na základě správného poţadavku pošle informaci o stavu hovoru klientskému webovému prohlíţeči. Ostatní porty jsou blokovány, tato sluţba se můţe stát cílem potencionálního Denial of Service útoku. Proto je zde pomocí firewallu omezen počet paketů, které na něj přitéká na 1000 za sekundu pro kaţdou zdrojovou IP adresu.
50
6.3.3 Implementace firewallových a směrovacích pravidel Jako firewall byl zvolen linuxový iptables, systém vyuţívá tabulky filter pro filtrování paketů, které vstupují na síťová rozhraní serverů. Veškeré pakety, které přicházejí na tato rozhraní a jsou určeny pro lokální aplikace prochází řetězcem (dále chainem) INPUT. Zde jsou přijaty pakety, které:
jsou z loopback zařízení jsou z nejbliţší lokální sítě o zároveň jde o monitorovací sluţby – MUNIN o nebo jde o multicastové VRRP pakety s cílovou adresou 224.0.0.18 jde o pakety, která patří k jiţ uzavřeným spojením (např. z lokálního stroje), která mají záznam v connection tracking tabulce
Dále jsou pakety podle cílové ip adresy rozděleny do CHAINů: o
o o o
APPLICATIONS o povolení přístupu administrativního rozhraní k démonům mezi jednotlivými servery o SSH o zálohování SPEEDDIAL_ADMINACCESS – přístup na plovoucí VRRP IP, jeţ vyuţívá administrativní rozhraní systému a sluţba rychlé volby TERMINATIONS – v tomto chainu je povolen přístup z terminací na povolené SIP a RTP porty CALLSTATES – zde umoţňujeme omezený časově počet přístupů ze zdrojové ip adresy pomocí iptables modulu hashlimit
iptables -A CALLSTATES -p tcp -m tcp --dport 8080 -m hashlimit \\ --hashlimit-upto 1000/sec --hashlimit-mode srcip \\ --hashlimit-name CALLSTATES -j ACCEPT
Všechny pakety, které nejsou akceptovány výše uvedenými pravidly, jsou zalogovány a zahozeny chainem LOGANDFORBID. Dále se musíme postarat o to, aby pakety, které odchází ze serverů sluţby, měly správnou zdrojovou IP. To lze v některých případech vyřešit konfiguračními soubory sluţeb, zde je moţnost nastavit IP adresu, na kterém má sluţba poslouchat. Bohuţel toto neplatí po všechny sluţby, zejména u konfigurace SIP protokolu je moţno nastavit jedinou naslouchající IP adresu, ale není moţno nastavit pro různé peery různé naslouchající IP adresy. Toho je v systému ale třeba, protoţe pro rychlou volbu a pro terminace jsou vyuţity rozdílné IP adresy serverů a pro obě tyto spojení je třeba SIP protokolu. Pro řešení problému bylo vyuţito moţnosti úpravy směrovací tabulky linuxového systému. Záznam ve směrovací tabulce má obvykle tento tvar:
$DEST_NETWORK/$DEST_MASK via $GW dev $DEV src $SRCIP 51
Zápis znamená, ţe cílová síť $DEST_NETWORK je směrována přes bránu $HOST, k čemuţ síťové zařízení $DEV vyuţívá zdrojovou IP adresu $SRCIP. Pole src je nepovinné, pouţívá se zejména u cest typu kernel, které se starají o směrování paketů do sítě, ve které je dané síťové zařízení připojeno. Systém vyuţívá moţnosti definovat zdrojovou IP adresu pro směrování paketů do určité sítě. Protoţe záznam musí obsahovat také bránu, přes kterou pakety proudí do cílové sítě, je implicitní brána (default gateway) součástí konfigurace firewallu. Po modifikaci vypadají pravidla směrovací tabulky například:
94.186.162.0/24 via $GW dev eth0
src $SRC_IP
O nastavení sítě se starají programy v adresáři /klikni/network, konkrétně:
firewall.pl - stará se o vytvoření iptables pravidel tabulky filter, má atributy o start – vyplní tabulku filter o show – zobrazí iptables pravidla, která se při parametru start aplikují o stop – vymaţe obsah chainu INPUT, tudíţ dojde k povolení veškerého provozu, který je směrován lokálním aplikacím sourceroutes-static.pl – vytvoří cesty (routy) k serverům ostatních sluţeb s nastavením zdrojové ip adresy. Má parametry start a stop, parametr stop smaţe cesty. sourceroutes-keepalived.pl – vytvoří cesty podobně jako sourceroutes-static.pl s tím rozdílem, ţe tyto cesty jsou vytvořeny pouze, pokud je server keepalived-master. Keepalived je démon implementující VRRP protokol. V případě, ţe se server stane z masteru zálohou, dojde k zavolání skriptu s parametrem stop.
Dále se v adresáři nalézá soubor s konfigurací CONFIG.pm, který obsahuje ip adresy:
terminací serverů rychlé volby implicitní brány které mají přistup k administrativnímu rozhraní databáze a dalších sluţeb
Výše uvedené skripty čerpají konfiguraci z tohoto modulu. Dle mého názoru je zabezpečení navrţeno a provedeno kvalitně, za 2 roky provozu sluţby nebyl zaznamenán ţádný bezpečnostní incident.
52
7 Závěr 7.1 Zkušenosti s nasazením a během systému Implementaci systému provedl pan Bc. Luděk Svoboda (
[email protected]) na základě návrhu systému, který je obsahem této práce. Frontend byl naprogramován programátory společnosti MAFRA, a.s. ve které byl systém clicktocall také nasazen. Přístup na sluţbu byl realizován pomocí webových stránek www.klikniavolej.cz a ze stránek www.idnes.cz. Nyní byl systém prodán, společnost MAFRA, a.s. jej prodala nově zaloţené společnosti KlikniAVolej, s.r.o. Celkový počet uţivatelských účtů systému k dubnu roku 2011, díky propagaci systému na webových stránkách MAFRY, dosahoval 30 000. Tito uţivatelé pouţívají ale zejména další sluţby, které systém nabízí. Jeden z poţadavků na systém byl opravdu přehnaný. Byl jím počet souběţně spojených hovorů. Poţadavek byl původně na 150 souběţných hovorů na jeden server telefonní ústředny, v praxi však jde spíše o jednotky hovorů. Navrţený model se ukázal ve většině případů jako rozumný, při doplňování systému o nové sluţby zůstal prakticky tak, jak byl původně navrţen. Systém byl doplněn zejména o :
podporu zasílání SMS s podporou změny identifikátora odesílatele o jako odesílatel můţe být pouţit jakýkoliv alfanumerický řetězec omezené délky bránu poskytující zasílání SMS pro velkoodběratele – rozhraní vyuţívající http protokolu o tuto sluţbu vyuţívá např. společnost Baťa, a.s. promo akci – moţnost propojovat v omezené míře pevné telefonní linky v rámci ČR zdarma, avšak s omezeními na počet provolaných minut o zde došlo k přidělení volných minut pro kaţdou IP adresu a dále k přidělení minut pro větší podsítě (počet volných minut větší podsítě byl ostře menší, neţ suma minut pro kaţdou IP podsítě) – vše s cílem omezit zneuţití sluţby anonymizaci údajů – údaje o uskutečněných hovorech a odeslaných SMS jsou po 9 měsících smazány a zůstávají pouze obecné statistiky hovorů
Se systémem nebyly váţnější problémy. Ty byly zejména s terminacemi – vybrat terminace, které se chovaly k hovorům správně, nebylo vůbec jednoduché. Problémy, které nastávaly by se daly shrnout do následujících bodů:
chybná informace o stavu hovoru: o nezaslání informace o zvonění o tvrzení, ţe hovor byl spojen, ačkoliv spojen nebyl (na pozadí pouze šum) o občasné nepropojení hovoru a informování o obsazenosti. problémy se zpoţděním – v případě vyuţití zahraničních terminací mimo Evropské země docházelo při hovoru k obrovskému zpoţdění – v řádu jednotek sekund, problém byl vyřešen vyuţitím preferovaných terminací pro Evropu a zejména Českou republiku některé terminace měly problém s přenesenými čísly v rámci ČR, občas došlo k tomu, ţe jeden z českých telefonních operátorů přestal správně zakončovat hovory jedné z terminací
Jeden z největších omylů při návrhu systému byla snaha o sjednocení ceníků jednotlivých terminací v jeden strom, který je postaven zejména na názvech telefonních sítí a ne tolik na prefixech. Řešení 53
navrţené v této práci je příliš komplikované, náročné na modifikace a zejména administrátorům (a uţivatelům) sluţby sjednocování názvů sítí jednotlivých terminací nepřináší mnoho výhod. Mnohem lepší se mi nyní jeví model, ve kterém má kaţdá terminace svůj ceník – seznam prefixů s názvy sítí. Při navazování hovoru dojde ke zjištění ceny pomocí longest prefix match přes kaţdou terminaci a aţ poté se vybere terminace nabízející nejlevnější cenu hovoru. Následující grafy ukazují zatíţení strojů sluţby vykreslené pomocí monitorovacího software Munin. o o
Na obrázku Obrázek 7-1 vidíme počet souběţně aktivních hovorů, zde vidíme, ţe poţadavek na 150 současně běţících hovorů byl velice nadhodnocen Na obrázku Obrázek 7-2 je vidět vytíţení procesorů. Je vidět, ţe procesory jsou vytíţeny naprosto minimálně – při aktivním hovoru dochází pouze k rozbalení RTP hlaviček paketů, které jsou nahrazeny novými RTP hlavičkami – není zasahováno do vlastních multimediálních dat paketu. Dle mého názoru tato operace není řádově náročnější, neţ směrování paketu jádrem systému. Z obrázku je také zřejmé, ţe poţadavek na 150 souběţných hovorů je systém schopen obslouţit.
Obrázek 7-1: Počet aktivních hovorů v rámci měsíce na jednom ze serverů.
54
Obrázek 7-2: Využití procesorů na jednom ze serverů služby.
7.2 Shrnutí Práce hovoří o úspěšném návrhu systému pro spojování hovorů třetí stranou – third party call control. Dala mi zejména zkušenosti s návrhem většího komplexního systému, který sahá od zvolení správných softwarových a hardwarových prostředků, jejich propojení do funkčního celku aţ po návrh databázových struktur systému. Ukázala mi, jak je extrémně důleţitá komunikace s odběratelem software, jak je důleţité si na začátku vyjasnit, co za systém bude dodán a zejména, kde budou jeho hranice – které součásti do systému ještě za smluvených finančních podmínek náleţí a jaké jiţ nenáleţí. Práce přináší zajímavý pohled na řešení vysoké dostupnosti a rozdělení zátěţe, kdy je většina stavové informace uloţena mimo provozní stroje, je uloţena v databázi, ve které při výpadku serverů sluţby nedojde k její ztrátě. Po znovunastartování serverů dojde k plynulému navázání na minulý stav systému. V tomto můţe být práce inspirací pro analytiky navrhující systémy s vysokou dostupností. Dále ukazuje, jakým způsobem můţe být vytvořen systém volání přes více telefonních operátorů s vyhledáním operátora, který je schopen hovor propojit do dané sítě s nejvyšší kvalitou a také nejlevněji, který se učí za pomocí zpětné vazby.
55
8 Bibliografie 1. 3pcc. Wikipedie. [Online] http://en.wikipedia.org/wiki/3pcc. 2. Click to call. Wikipedie. [Online] [Citace: 03. 03 2011.] http://en.wikipedia.org/wiki/Click-to-call. 3. Hiver, Jean-Michel. Asterisk::LCR. The Comprehensive Perl Archive Network. [Online] 2006. [Citace: 01. 05 2011.] http://search.cpan.org/~jhiver/Asterisk-LCR-0.08/lib/Asterisk/LCR.pm. 4. Virtual Router Redundancy Protocol . CISCO. [Online] [Citace: 08. 04 2011.] http://www.cisco.com/en/US/docs/ios/12_0st/12_0st18/feature/guide/st_vrrpx.html. 5. Internet protokol. Wikipedie. [Online] [Citace: 08. 05 2011.] http://cs.wikipedia.org/wiki/Internet_Protocol. 6. SIP architekture. VoipThink. [Online] [Citace: 02. 03 2011.] http://www.en.voipforo.com/SIP/SIP_architecture.php. 7. Session Description Protocol. SearchUnifiedCommunications. [Online] 2007. http://searchunifiedcommunications.techtarget.com/definition/SDP. 8. Voip kodeky. voip-info.org. [Online] http://www.voip-info.org/wiki/view/Codecs. 9. Dykstra, P. Protocol Overhead. Phil Dykstra's Page. [Online] 2003. [Citace: 02. 03 2011.] http://sd.wareonearth.com/~phil/net/overhead/. 10. Tomáš Wija, David Zukal, Miroslav Vozňák. Asterisk a jeho použití. 2005. 11. Novotný, Ivan. Systémy pro VoIP. Brno : Fakulta Informatiky Masarykovy Univerzity, 2006. 12. Kjeld Borch Egevang, Paul Francis. RFC 3022: Traditional IP Network Address Translation (Traditional NAT). The Internet Engineering Task Force (IETF). [Online] 2001. [Citace: 01. 03 2011.] http://tools.ietf.org/html/rfc3022. 13. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. rfc 3550: RTP: A Transport Protocol for Real-Time Applications. The Internet Engineering Task Force. [Online] 2003. [Citace: 01. 04 2011.] http://tools.ietf.org/html/rfc3550. 14. rfc3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). The Internet Engineering Task Force. [Online] 2003. [Citace: 28. 03 2011.] http://tools.ietf.org/html/rfc3605. 15. IAX. Voip-Info.org. [Online] 2010. [Citace: 24. 03 2011.] http://www.voipinfo.org/wiki/view/IAX. 16. GNU GENERAL PUBLIC LICENSE v3. GNU operating system. [Online] 2007. [Citace: 12. 02 2011.] http://www.gnu.org/licenses/gpl.html. 17. Asterisk. voip-info.org. [Online] http://www.voip-info.org/wiki/view/Asterisk. 18. DTMF Signaling. UC Berkeley EECS Dept. [Online] [Citace: 24. 03 2011.] http://ptolemy.eecs.berkeley.edu. 19. Novotný, Ivan. Systémy pro VoIP. Brno : autor neznámý, 2006. 20. Hebel, Krzysztof. RTP: Real-time Transport Protocol. University of Waterloo. [Online] 2006. [Citace: 16. 04 2011.] http://www.multicom.uwaterloo.ca/pastseminars/RTP-presentation.pdf. 56
21. rfc4732: Internet Denial-of-Service Considerations. The Internet Engineering Task Force. [Online] 2006. [Citace: 15. 04 2011.] http://tools.ietf.org/html/rfc4732. 22. IP address spoofing. wikipedie. [Online] http://en.wikipedia.org/wiki/IP_address_spoofing. 23. Man in the middle. Wikipedie. [Online] [Citace: 07. 04 2011.] http://en.wikipedia.org/wiki/Man-inthe-middle_attack. 24. IEEE. Virtual Bridged Local Area Networks. New York : IEEE, 2005. 25. Asterisk. voip-info.org. [Online] [Citace: 10. 03 2011.] http://www.voipinfo.org/wiki/view/Asterisk. 26. TCP Extensions for High Performance. The Internet Engineering Task Force. [Online] 1992. [Citace: 05. 02 2011.] http://tools.ietf.org/html/rfc1323. 27. IP address spoofing. Wikipedie. [Online] [Citace: 05. 03 2011.] http://en.wikipedia.org/wiki/IP_address_spoofing. 28. The Difference Between VoIP and PSTN Systems. Webopedia. [Online] 2008. [Citace: 05. 04 2011.] http://www.webopedia.com/DidYouKnow/Internet/2008/VoIP_POTS_Difference_Between.asp. 29. J. Rosenberg, H. Schulzrinne, G. Camarillo¸A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. rfc 3261: SIP: Session Initiation Protocol. The Internet Engineering Task Force. [Online] 2002. [Citace: 27. 02 2011.] http://tools.ietf.org/html/rfc3261.
57
9 Přílohy 9.1 Obrázky frontendu služby klikniavolej.cz
Obrázek 9-1: Hlavní stránka služby.
58
Obrázek 9-2: Klientský web s aktivací telefonního čísla.
Obrázek 9-3: Klientský web po přihlášení.
59
Obrázek 9-4: Probíhající hovor.
9.2 Obrázky administrativního rozhraní
9-5: Editace sítí v administrativním rozhraní.
60
9.3 Přiložené soubory dp.pdf – text práce v PDF formátu klikni – adresář obsahující část systému o kterém se mluví v této práci erd – adresář obsahující ERD systému pictures – adresář obsahující obrázky ze systému
61
