Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů
Bakalářská práce
Extrakce a zpracování hlasu z VOIP paketů Josef Kučera
Vedoucí práce: Mgr. Jan Starý, Ph.D.
12. května 2015
Poděkování Poděkovat bych chtěl především mému vedoucímu bakalářské práce Mgr. Janu Starému, PhD. za příkladné vedení, konzultace a cenné rady, které mi pomohly v tvorbě této práce. V neposlední řadě bych chtěl poděkovat celé rodině a přítelkyni za velkou podporu během mého studia.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou, a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla, a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.
V Praze dne 12. května 2015
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2015 Josef Kučera. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Kučera, Josef. Extrakce a zpracování hlasu z VOIP paketů. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2015.
Abstrakt Cílem této práce je srovnat možnosti nahrávání hovorů a implementovat aplikaci pro systém UNIX, která z uložených metainformací v databázi a VoIP paketů extrahuje a sestaví audio data hovorů. Práce též obsahuje programátorskou dokumentaci, manuálovou stránku a popis testování. Klíčová slova VoIP, zpracování paketů, extrakce zvuku, SIP, RTP
Abstract The purpose of this thesis is to consider the posibilities of recording VoIP calls and implement a UNIX application that extracts actual audio streams from captured VoIP packets. The work also contains a manual, a programm’s documentation and a testing report. Keywords VoIP, packets processing, audio extraction, SIP, RTP
ix
Obsah Úvod
1
1 Analýza 1.1 Co je to VoIP . . . . . . . . . 1.2 Historie a vývoj . . . . . . . . 1.3 Princip fungování . . . . . . . 1.4 Způsoby přenosu hlasu . . . . 1.5 Signalizační protokoly . . . . 1.6 RTP, RTCP . . . . . . . . . . 1.7 Kodeky . . . . . . . . . . . . 1.8 Kvalita služby . . . . . . . . . 1.9 Legislativa a nahrávání hovorů
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
3 3 3 4 5 5 7 8 11 12
2 Dostupná řešení 2.1 Homer . . . . 2.2 VoIP monitor 2.3 Wireshark . . 2.4 Xplico . . . . 2.5 Ostatní . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
13 13 13 14 14 14
3 Návrh řešení 3.1 PCAP . . . . . . . 3.2 Programovací jazyk 3.3 Operační systém . 3.4 Databáze . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
15 16 16 17 17
. . . . .
. . . . .
4 Instalace, konfigurace a použití xi
19
4.1 4.2 4.3 4.4 4.5 4.6 4.7
Instalace aplikace . . Konfigurační soubor Vytvoření výstupního Spuštění aplikace . . Logování . . . . . . . Ukončení aplikace . . Dokumentace . . . .
5 Implementace 5.1 Rozdělávání paketů 5.2 Třída Call . . . . . 5.3 Třída Callstream . 5.4 Jitter buffer . . . . 5.5 Třída Context . . .
. . . . .
. . . . . . . . . . souboru . . . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
19 19 20 20 22 22 22
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
23 23 23 24 24 24
. . . . .
27 27 27 28 28 28
. . . . .
. . . . .
. . . . .
6 Testování 6.1 Testování přenositelnosti . . 6.2 Použitá data . . . . . . . . . 6.3 Otestované scénáře . . . . . 6.4 Neotestované scénáře . . . . 6.5 Nalezené problémy a řešení .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Závěr 31 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Možnosti rozšíření . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Literatura
33
A Seznam použitých zkratek
37
B Obsah přiloženého CD
39
xii
Seznam obrázků 1.1 1.2
SIP signalizace . . . . . . . . . . . . . . . . . . . . . . . . . . . RTP hlavička . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7
3.1
Schéma projektu . . . . . . . . . . . . . . . . . . . . . . . . . .
16
xiii
Seznam tabulek 1.1
Přehled kodeků . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.2 4.1
Přehled přepínačů . . . . . . . . . . . . . . . . . . . . . . . . . Přehled direktiv . . . . . . . . . . . . . . . . . . . . . . . . . . .
20 21
xv
Úvod Hlasová komunikace je základem dorozumívání ve společnosti a vyvíjí se již po několik tisíciletí. Alexander Graham Bell s vynálezem telefonu však udal komunikaci mezi lidmi úplně nový směr, který člověk ve 20. století rozvíjel do dnešní podoby, a to mít možnost komunikovat s druhým i přes celý svět. Vývoj Internetu v posledních desítkách let dovolil nástup nového, levnějšího a kvalitnějšího způsobu komunikace – VoIP telefonii. Téma mé bakalářské práce je seznámit se s technologií VoIP (Voice over Internet Protocol), analyzovat možnosti skenování a zpracování VoIP dat ze sítě. Následně vytvořit aplikaci, která dokáže zpětně sestavit hovor ze získaných dat a uložit ho v některém z běžně dostupných audio formátů. Tento typ aplikace nachází uplatnění převážně ve společnostech zabývajících se telemarketingem, kde může pomoci s kontrolou uskutečněných hovorů a obchodů, nebo ve společnostech uzavírajících smlouvy po telefonu, které mají dokonce zákonnou povinnost archivovat záznamy hovorů až po několik let.
1
Kapitola
Analýza V této kapitole představím VoIP telefonii a budu se zabývat technologiemi, na kterých stojí. V závěru kapitoly také shrnu potřebnou legislativu pro nahrávání a archivování hovorů.
1.1
Co je to VoIP
VoIP je komunikační technologie, která přenáší v reálném čase digitalizovaný hlas pomocí internetového protokolu privátní nebo veřejné sítě. Obrovskou výhodou VoIP je využití již zavedené přenosové infrastruktury a možnost volat kamkoliv po světě bez současných obrovských poplatků za spojení a ve vyšší audio kvalitě, než mohou poskytnout klasické telefonní sítě. Telefonát se může uskutečnit i mezi klasickým telefonem a IP telefonem, ale musí se zajistit převod signálu. VoIP dovoluje vytvořit hovor přímo z počítače vybaveného programem, mikrofonem se sluchátky nebo reproduktorem, ze speciálního VoIP telefonu nebo z obyčejného telefonu připojeného na Internet s nainstalovanou aplikací k tomu určenou (softphone).
1.2
Historie a vývoj
Počátky technologie VoIP sahají do roku 1989, kdy Alon Cohen založil v Izraeli společnost Vocaltec. Ta v polovině 90. let vytvořila software „InternetPhone“ schopný komunikovat přes síť. Zatím ovšem fungovalo volání pouze mezi účastníky vybavenými stejným programem. Dalším významným posunem byl rok 1998, kdy vznikla v Severní Americe služba na volání z počítače na mobil a později i z mobilu na mobil. 3
1
1. Analýza Každý uskutečněný hovor začínal a končil reklamou, kterou si musel volající poslechnout. Bylo tedy možné uskutečnit meziměstské hovory úplně zdarma. Ve stejném roce byly představeny první IP přepínače, které ve standardním vybavení měly software pro VoIP směrování. V této době představovala technologie VoIP pouze 1% celkového telefonního provozu, o dva roky později kolem 3%, v roce 2005 necelých 30% a dnes se provoz pohybuje již kolem 50%.[1] Hlavním důvodem pro větší rozšíření VoIP bylo především redukování nákladů na spojení meziměstských a mezinárodních hovorů, které u poskytovatelů telefonních přípojek a sítí byly vysoké, závisely na vzdálenosti mezi účastníky a času, kdy se hovor uskutečnil. V dnešní době již mnoho společností přešlo celkově na VoIP technologii a těží z jejích benefitů. Současným nejpoužívanějším VoIP klientem ve světě je Skype, který používá vlastní proprietární a s nikým nekompatibilní šifrovaný protokol.
1.3
Princip fungování
Na provoz VoIP technologie je zapotřebí protokol, který zabezpečí signalizaci pro uskutečnění a řízení hovorů. V sítích jsou přítomny proxy servery, jejichž úkolem je registrovat VoIP telefony a koordinovat signalizování především mezi vícero sítěmi. Pokud je voláno na standardní telefonní číslo, pakety jsou převáděny na signál do klasických telefonních sítí na speciálních VoIP bránách. Většinou je potřeba, aby se účastníci nejprve zaregistrovali u některé řídící jednotky (VoIP operátor, call-manager), která zprostředkuje prvotní sestavení hovoru. Další možností je, že tento zprostředkovatel vytvoří dvě spojení a funguje jako „man in the middle“. Poté je hovor průběžně rozdělován do malých fragmentů po několika milisekundách (5–20 ms), které jsou zakódovány jedním z předem dohodnutých kodeků a přenášeny protokolem RTP (Real-time Transport Protocol) k příjemci. Důležitou podmínkou pro fungování VoIP je nízká odezva mezi volajícími a podpora kvality služby (Quality of Service) na síťových prvcích, kde by tyto pakety měly být zpracovávány prioritně. Pro VoIP platí, že je lepší paket zahodit, než se ho snažit se zpožděním za každou cenu doručit. Proto se především využívá nepotvrzovaný protokol UDP (User Datagram Protocol) oproti TCP (Transmission Control Protocol), který lze ovšem také použít. 4
1.4. Způsoby přenosu hlasu
1.4
Způsoby přenosu hlasu
Ve světě telekomunikace existují dva rozdílné typy přenosu hlasu.
1.4.1
Na základě přepojování okruhů
Tento způsob se používá u obyčejných telefonních sítí, ale nadále je praktikován i u modernějších mobilních sítí. V případě přenosu dat (při telefonním hovoru) se vyhradí kanál od odesílatele (volajícího) až k příjemci (volanému), který je vyhrazen po celou dobu přenosu. To znamená, že každá ústředna, která je na cestě, musí pro tento hovor vyhradit potřebný kanál. Pokud jedna z ústředen po cestě nemůže tento kanál alokovat, volajícímu je odeslán signál znamenající obsazenost linky. Výhody jsou zřejmé a to, že kvalita hovoru nekolísá v závislosti na šířce pásma. Nevýhodou ovšem zase je, že efektivita takto využívaného pásma může být velmi malá.
1.4.2
Na základě přepojování paketů
Oproti tomu v počítačově zaměřených sítích se informace rozdělí na části a tyto části putují po trase, která se může dynamicky měnit. Přenášená informace, která je takto rozdělena na části, které jsou poté spolu s hlavičkou nesoucí řídící informace (např. o adrese příjemce a odesílatele, kontrolní součet atd.) vkládány do tzv. paketů. V této podobě jsou data vyslána směrem k příjemci a jednotlivé pakety mohou díky hlavičce putovat sítí různými směry. Jednotlivá zařízení, která jsou po cestě k příjemci, poznají z hlavičky adresu příjemce a podle svých interních směrovacích tabulek pošlou paket nejkratší cestou k příjemci. Ten poté přijaté pakety sestaví do původní podoby a získá přenášenou informaci. Výhodou tohoto typu přenosu je šetření šířky pásma a obecně levnější technologie, která tento typ přenosu umožňuje. Mezi nevýhody této technologie patří kolísání kvality hovoru.
1.5
Signalizační protokoly
K založení hovoru je potřeba některý ze signalizačních protokolů, který nalezne ostatní účastníky a oznámí jim, že s nimi chceme komunikovat, zabezpečí navázání spojení mezi volajícími a také řádné ukončení. To odlišuje 5
1. Analýza internetové volání od ostatních multimediálních služeb, jako je všesměrové vysílání (multicast) nebo média na vyžádání (media on demand). Signalizace musí zařídit mnoho dalších důležitých funkcionalit jako překlad jména, nalezení účastníka, zjištění stavu (zavěšeno, obsazeno, přesměrováno) nebo zajištění, jakým způsobem se mohou do konference zapojit další účastníci. Strany si také musí vyměnit informaci o tom, kterými kodeky a přenosovou rychlostí jsou schopni navzájem komunikovat a vybrat si nejvhodnější z nich. Minimálně však musí podporovat základní kodek G.711. Pak existuje několik dalších (G.723.1, G.729, GSM, atd.) s lepší kompresí, s vyšší kvalitou zvuku nebo vyváženým poměrem mezi kvalitou a kompresí. Při změně počtu účastníků v konferenci mohou strany přejít i na jiný podporovaný kodek. Nejčastějším protokolem je SIP, v Cisco sítích se využívá proprietární Skinny protokol (SCCP) a již na ústupu je složitý a nejstarší H.323. Dříve se používal i protokol Megaco.
1.5.1
SIP
SIP (Session Initiation Protocol) byl vyvinut v roce 1996 skupinou IETF (Internet Engineering Task Force). Od začátku byl připravován pouze pro IP sítě a dokáže zahajovat nejen hlasová spojení, ale například i videopřenos. Je to end-to-end protokol, což znamená, že veškerá logika je umístěna v koncových zařízeních (kromě směrování SIP zpráv po cestě). Protokol je velice jednoduchý, textově orientovaný a používá mnoho standardů z HTTP nebo SMTP. Pro domluvu mezi účastníky nad podrobnostmi spojení a nad způsobem komunikace se využívá protokol SDP (Session Description Protocol). Nejčastěji se pro řízení hovoru používají tyto druhy zpráv (celkově jich je 14): • REGISTER: Používá se pro registrování účastníka u řídícího zařízení. • INVITE: Slouží k založení spojení mezi účastníky. • ACK: Potvrzuje přijatou zprávu. • CANCEL: Ruší čekající žádost. • BYE: Ukončuje probíhající spojení. • OPTIONS: Žádost o poslání informací a možnostech spojení ještě před založením spojení. Často používán pro otestování života druhé strany. 6
1.6. RTP, RTCP
Obrázek 1.1: Příklad navázání relace přes několik proxy serverů.[2]
1.6
RTP, RTCP
RTP je protokol určený především pro přenos zvukových a obrazových, živě vysílaných dat přes internetové sítě. Byl vyvinut v „Audio/Video Transport Working Group“ při institutu IETF, poprvé publikován v roce 1996 a dnes veden jako standard RFC3550.[3]
Obrázek 1.2: Rozložení RTP hlavičky [4] 7
1. Analýza Hlavička paketu poskytuje informace pro správné sestavení obsahu, pokud při cestě na méně kvalitních sítích došlo k pozměnění pořadí, zpoždění, zduplikování nebo ztrátě či poškození paketů. Ty se dále využívají například v jitter bufferu, který eliminuje problém pozměněného pořadí a mírného zpoždění paketů. Tato schopnost je velice důležitá, protože pro provoz RTP se téměř vždy využívá nepotvrzovaný transportní protokol UDP, který nic podobného nepodporuje. Další výhodou je, že se mohou odesílat RTP pakety z jednoho zdroje ke skupině více koncových stanic, tzv. multicast. Dalšími transportními protokoly, nad kterými funguje RTP, jsou SCTP (Stream Control Transmission Protocol) a DCCP (Datagram Congestion Control Protocol). Ovšem nejsou používány zdaleka v takové míře jako UDP. Kontrolním protokolem je RTCP (RTP Control Protocol). Slouží k řízení RTP spojení na základě sledování kvality toku (kolísání zpoždění, počet ztracených paketů, atd.). Telefon potom může zareagovat například změnou kodeku, kterou spolu účastníci komunikují. Tyto informace není potřeba sbírat tak často, a mezi RTCP pakety je tudíž až několik vteřin. Jejich výskyt by neměl přesáhnout 5% celkového počtu všech RTP paketů. Pro RTCP se většinou používá číslo portu, které je o jedničku vyšší než má RTP spojení. Pro šifrování celé komunikace a ověřování přijatých zpráv a integrity dat může být spojení šifrováno pomocí sesterského protokolu SRTP (Secure Real-time Transport Protocol). I zde existuje stejně jako u RTP kontrolní protokol SRTCP (SRTP Control Protocol), který má velmi podobné funkcionality. Na začátku relace musí dojít k sestavení šifrovacího a dešifrovacího klíče. Zde se protokol spoléhá na externí zdroj, například na ZRTP (Z Realtime Transport Protocol), kde se použije Diffieho-Hellmanova výměna klíčů.
1.7
Kodeky
V dobách klasické telefonie se zvuk přenášel analogově, ale postupem času bylo nutné signál zdigitalizovat, a proto se musely vymyslet nové postupy a algoritmy pro převod a kompresi zvukového signálu. Cílem je co nejpřesněji zachovat vstupní signál a přitom použít co nejméně bitů k uložení informace. Samozřejmě bychom v ideálním případě neměli vůbec rozpoznat zdigitalizovaný vzorek od analogového. Pro zaznamenání zvuku se musí zvolit správná vzorkovací frekvence. Nyquistův-Shannonův-Kotělnikovův teorém říká: „Přesná rekonstrukce spojitého, frekvenčně omezeného signálu z jeho vzorků je možná tehdy, pokud byla vzorkovací frekvence vyšší než dvojnásobek nejvyšší harmonické složky 8
1.7. Kodeky vzorkovaného signálu.“ [5] V praxi to znamená, že se má použít dvakrát větší vzorkovací frekvence plus nějaká rezerva navíc, než je nejvyšší přenášená frekvence. VoIP komunikace je zaměřená primárně na přenos lidského hlasu, což je od 300 do 3400 Hz, tudíž by se měla používat frekvence nejméně 8000 Hz. Kodeky se dají rozdělit do tří základních skupin: • Waveform kodeky – tento druh kodeku se používá s vysokým počtem bitů za sekundu a snaží se co nejpřesněji zaznamenat signál. Na výstupu dává velmi kvalitní zvuk. • Source kodeky – zde se používá daleko menší počet bitů za sekundu, ale zbytek se matematicky dopočítá. Na výstupu dává menší datovou náročnost, na druhou stranu zní trochu uměle a také je nutný vyšší výpočetní výkon. • Hybridní kodeky – tyto kodeky si vždy berou něco z obou předchozích a dávají vyvážený poměr mezi kvalitou, datovou náročností a nároky na výpočetní výkon. Pro porovnávání kodeků se používá několik dalších metrik. Jedním z nich je MOS (Mean Opinion Sore), který vyjadřuje subjektivní kvalitu přenášeného zvuku, vyšší číslo znamená vyšší kvalitu. Hodnota se uvádí v rozmezí 1 až 5. Dalším je například MIPS (Million Instruction Per Second), které udává náročnost kodeku v přepočtu na milión operací za sekundu. Přehled nejpoužívanějších kodeků je v tabulce 1.1. Tabulka 1.1: Přehled kodeků a jejich parametrů.[6] Název G.711 A-law G.711 µ-law GSM G.723.1 G.726 G.729 Speex iLBC
Bitrate 64 64 12,2 6,3 32 8 2,5–24,6 15,2
MOS 4,1 4,0 4,1 3,8 4,1 3,92 2,8–4,2 3,9
MIPS 1 1 ≈20 <18 ≈1 <20 8–25 15
Pro komunikaci se používá celá paleta různých kodeků, které se od sebe navzájem liší vzorkovací frekvencí, kompresí a datovou náročností. Některé otevřené z nich, které jsem přímo použil v práci, podrobněji představím. 9
1. Analýza
1.7.1
G.711
Nejstarším z nich je G.711, který tvoří minimální základ pro uskutečnění hovoru. Je zároveň nejrozšířenějším, nejpoužívanějším a nejjednodušším audio kodekem v telekomunikaci. Byl představen již v roce 1972 pod názvem „Pulse code modulation of voice frequencies“ (PCM) a v roce 1988 byl schválen jako standard ITU-T. Spadá do skupiny waveform kodeků. Jednoduchost tohoto kodeku je ovšem vykoupena náročností na datový objem přeneseného zvuku. Vzorkovací frekvence je 8 kHz. Pro reprezentaci jednoho vzorku se používá 8 bitů, což ve výsledku dává datovou náročnost 64 kbit/s. Data jsou pak rozdělena do paketů po 20 ms a každý z nich obsahuje 160 vzorků. Pro kódování se využívá logaritmická komprese, kdy se vytvoří osmibitový signál z třinácti nebo čtrnáctibitového signálu. V telekomunikaci se využívají dva typy komprese – µ-law a A-law. Na přechodu sítí provozujících různé kodeky musí dojít ke správné konverzi.
1.7.1.1
µ-law
Kódování µ-law (občas označován jako ulaw, G.711Mu nebo G.711µ) se používá především v Severní Americe a Japonsku. Kódují se čtrnáctibitové vzorky do sedmibitových. Zde se využívá o něco vyšší komprese než u Alaw, protože se nepoužívá všech osm bitů pro přenos zvuku, ale jenom sedm. Poslední bit je určen pro signalizaci hovoru. V signalizaci je také přenášena informace, v jakém kódování putují zvuková data.
1.7.1.2
A-law
Druhý způsob je používán ve zbytku světa. Zde se kóduje z třináctibitových vzorků od osmibitových, a tudíž se pro přenos zvuku využívají všechny bity. Signalizace je vedena samostatným kanálem. Kvalita výsledného zvuku je při této kompresi o trochu lepší oproti µ-law. A-law je také jednodušší a levnější pro zpracování počítači. 10
1.8. Kvalita služby
1.7.2
GSM
První digitální kodek, původně určený jen pro mobilní sítě GSM (Global System for Mobile communications), patří do skupiny hybridních kodeků, tudíž část signálu umí lineárně předpovídat. Používá se jako standard pro mobilní komunikaci v Evropě i jiných státech po světě. Existuje několik variant GSM kodeku, ovšem nějčastěji se pracuje s bitratem 13 kbit/s. Signál je rozdělován po 20 ms a v každém se vyskytuje 160 vzorků, stejně jako u G.711.
1.8
Kvalita služby
Velkým problémem u VoIP je, že oproti sítím s přepojováním okruhů není v IP sítích vyhrazená cesta, po které by mohl stále proudit hlas. V IP sítích se data musí rozdělit do paketů, označit hlavičkami a odeslat. To není problém, pokud síťové prvky nejsou zatíženy. Než dojde paket k příjemci, musí většinou projít přes několik takových stanovišť a zpoždění se začíná nasčítávat. Rychlost doručení zde hraje velikou roli, tudíž je nutné, aby po cestě existovala možnost pakety přednostně vyřídit. Tato technologie se nazývá kvalita služby (Quality of Service). Lidský hlas může být docela dobře předvídatelný a mozek umí malou ztrátu paketu kompenzovat. Problém nastává, pokud ztráta takových paketů překročí 1%. Poté se stává hovor obtížně poslouchatelný. Samozřejmě také závisí na použitém kodeku a jeho kompresi. Platí, že čím větší komprese se použije, tím jsou na výsledný hovor horší dopady. [7] Správce zařízení, například poskytovatel internetového připojení, může nastavit, které druhy dat budou obslouženy přednostně při zvýšení provozu. Jsou to nejčastěji data VoIP komunikace, video konference, signalizační protokoly nebo streamované video. Tyto pakety obsahují v IP hlavičce informaci o tom, jaký druh obsahu nesou a síťové prvky se umějí podle toho zařídit. Při velkém zatížení také dochází k zahazování méně prioritních paketů. Kvalita služby se tedy snaží poskytovat uživatelům služby s předem garantovanou kvalitou, aby nedocházelo ke zpoždění nebo ztrátě paketů. 11
1. Analýza
1.9
Legislativa a nahrávání hovorů
Omezení a povinnosti v oblasti nahrávání a monitorování hovorů jsou velmi podrobně stanoveny v zákonech České republiky. Jedním z nejdůležitějších předpisů, ze kterých bychom měli vycházet, je samotná Úmluva o ochraně lidských práv a svobod. Podle článku 8: „Každý má právo na respektování svého soukromého a rodinného života, obydlí a korespondence.“ a dále: „Státní orgán nemůže do výkonu tohoto práva zasahovat kromě případů, kdy je to v souladu se zákonem a nezbytné v demokratické společnosti v zájmu národní bezpečnosti, veřejné bezpečnosti, hospodářského blahobytu země, ochrany pořádku a předcházení zločinnosti, ochrany zdraví nebo morálky nebo ochrany práv a svobod jiných.“ Dále podle článku 13: „Nikdo nesmí porušit listovní tajemství ani tajemství jiných písemností a záznamů, ať již uchovávaných v soukromí, nebo zasílaných poštou anebo jiným způsobem, s výjimkou případů a způsobem, které stanoví zákon. Stejně se zaručuje tajemství zpráv podávaných telefonem, telegrafem nebo jiným podobným zařízením.“ Tedy bez svolení účastníků smí být hovor nahráván pouze při ochraně společnosti před trestnými činy a jejich případné potrestání státní mocí (Policie ČR, BIS). [8]
1.9.1
Správce osobních údajů
Správce osobních údajů je osoba, která zpracovává osobní údaje jiných lidí, tzv. subjekty údajů. Správcům jsou při ochraně osobních údajů ukládány hlavně povinnosti, zatímco subjektům údajů jsou dána práva. Podle § 316 odst. 2 zákona č. 262/2006 Sb., nesmí zaměstnavatel bez závažného důvodu, který závisí na povaze činnosti zaměstnance (příkladem může být uzavírání smluv na dálku), narušovat soukromí zaměstnance na pracovištích tím, že vystavuje zaměstnance otevřenému nebo skrytému sledování, odposlechu a záznamu jeho telefonických hovorů, kontrole elektronické pošty nebo kontrole listovních zásilek adresovaných zaměstnanci. Velice podrobně jsou tyto možnosti a povinnosti popsány v zákoně č. 89/2012 Sb. občanského zákoníku. Pokud se nejedná o záznam k úředním účelům na základě zákona, není možné pořizovat zvukové záznamy telefonních hovorů bez vědomí a svolení zaměstnanců a zákazníků. Při zahájení záznamu je správce povinen dotyčnou osobu o této skutečnosti informovat. Pokud osoba i poté pokračuje v rozhovoru, lze takový postup považovat za vyjádření souhlasu s nahráváním a zpracováním. Souhlas je správce povinen prokázat po celou dobu až do likvidace nahrávky. [9]
12
Kapitola
Dostupná řešení V této kapitole porovnám současná dostupná řešení pro přehrávání hovorů z již uložených nebo právě probíhajících hovorů. Některé fungují jako ucelený systém pro monitorování, nahrávání a archivování hovorů a jiné poskytují pouze cílenou funkcionalitu, kterou lze pro extrakci použít.
2.1
Homer
Homer je komplexní, profesionální a jedna z nejoblíbenějších aplikací pro monitorování VoIP hovorů. Má otevřený zdrojový kód a její použití je zcela zdarma. Architekturou je velice blízko našemu řešení. Celá aplikace je ovládána prostřednictvím webového rozhraní a v síti má nasazeny naslouchací agenty, kteří odesílají zachycená data na server s dekodérem a databází. Umí také získávat data přímo od SIP serverů (např. Asterisk nebo Kamailio) a poskytnou je uživatelům. Podporuje velké množství kodeků a umí také pracovat se šifrovanými hovory. Řekl bych, že ze všech podobných aplikací má tato určitě největší možnost uplatnění. [10]
2.2
VoIP monitor
Aplikace VoIP monitor je také blízko našemu konceptu projektu. Je ovládána skrze přehledné webové uživatelské rozhraní s velkým množstvím různých statistických údajů, umožňuje ukládání paketů z několika míst současně a také přehrávat právě probíhající hovory. [11] Má otevřený zdrojový kód ke stažení, ale jeho používání je k vyzkoušení pouze po dobu prvních 30-ti dnů. Dále se cena odvíjí podle maximálního počtu souběžně nahrávaných hovorů. Velkým kladem u této aplikace je, že 13
2
2. Dostupná řešení pokud se neplánuje obrovské zatížení, může být kompletně provozována za mírně vyšší poplatek na serverech vývojářů s omezenou velikostí úložného prostoru.
2.3
Wireshark
Wireshark je multiplatformní protokolový analyzér a paketový sniffer [12], který dokáže dekódovat celý uskutečněný hovor a rekonstruovat audio. Nepodařilo se nám ovšem nalézt, jak lze přímo vytvořit audio soubor bez uživatelského grafického rozhraní, proto ho pro automatickou extrakci nejspíše nelze použít. Také nepodporuje připojení k databázi, která je nutná pro správu všech hotových hovorů.
2.4
Xplico
Xplico je síťový forenzní analytický nástroj, který dokáže rekonstruovat obsah zachycený přímo na síti, nebo dokonce ze souboru se záznamem komunikace. Podporuje mnoho protokolů včetně hovorů signalizovaných pomocí SIP. Je tedy převážně určený na rekonstruování dat oproti Wiresharku, jehož hlavním úkolem je analýza samotných paketů a síťové komunikace.[13]
2.5
Ostatní
Dále se mi podařilo nalézt několik zajímavých skriptů v jazyce Python, například [14], které mají za úkol pouze jedinou věc, a to převést zadaný RTP proud na audio soubor, ale dále se musí využít externích nástrojů jako je například SoX [15], který spojí dohromady vytvořené audio soubory. V těchto skriptech neexistuje možnost připojit se na databázi a uložit výsledky extrakce.
14
Kapitola
Návrh řešení V této kapitole se budu zabývat samotným návrhem aplikace pro vytváření audio souborů ze záznamu RTP paketů VoIP komunikace, která je součástí uceleného projektu pro nahrávání a archivaci hovorů. Všechny části projektu mohou běžet odděleně na vlastních strojích, jak je ilustrováno na obrázku 3.1, nebo také vše na jednom stroji. Návrh řešení je následující:
• Sniffer (součást jiné bakalářské práce [16]) poslouchá na síti a RTP pakety z hovoru ukládá do speciálního souboru formátu PacketCapture (PCAP). • Veškeré informace o hovorech jsou nahrávány do databáze. • Moje aplikace (extractor) se v pravidelných intervalech ptá databáze a dostává případné hovory k extrakci. Výsledek poté nahraje zpět do databáze. • Poslední částí je webové rozhraní, které zobrazuje informace o hovorech a může do databáze vkládat další nastavení, například pravidla nahrávání pro sniffer (také spolu s databází součást jiné bakalářské práce [17]).
15
3
3. Návrh řešení
Obrázek 3.1:
3.1
PCAP
Pro ukládání paketů jsme zvolili typ souboru PacketCapture (PCAP), který byl představen v roce 1996 v Lawrence Berkeley Laboratory [18] a dnes představuje naprostý standard pro rychlé ukládání paketů a následnou analýzu. Pro správnou manipulaci s těmito soubory byla vytvořena pro UNIX systémy knihovna libpcap, kterou budu v implementaci využívat.
3.2
Programovací jazyk
Aplikace musí být navržena tak, aby dokázala zpracovat velké množství hovorů v co nejkratším čase, proto bude od začátku koncipována jako více vláknová. Jedním z hledisek pro výběr jazyka byla úspornost z hlediska 16
3.3. Operační systém spotřebované paměti a procesorového času. Pro implementaci jsem tedy zvolil jazyk C++. Pro paralelizaci v programu jsme upřednostnili vlákna před procesy, jelikož jejich celková režie pro vytvoření, přepínání kontextu a zrušení je u procesů mnohem vyšší než u vláken. Dalším důvodem pro vlákna byla určitě jednodušší práce se sdílenou pamětí. Jediným problémem je vícenásobné nastavení a zkompilování filtru v knihovně libpcap, která není threadsafe. Tato část bude tvořit kritickou sekci obalenou synchronizačním mechanizmem pro vstup pouze jednoho vlákna současně.
3.3
Operační systém
Aplikace bude nasazena v operačních systémech typu UNIX. Dle požadavku v zadání by výsledná aplikace měla být přenositelná mezi různými systémy a naším cílem je tuto přenositelnost zajistit a otestovat. Pro správné fungování mé aplikace musí být podporován v systému standard POSIX, například kvůli ovládání vláken knihovnou pthread.h.
3.4
Databáze
Prostředníka mezi všemi aplikacemi tvoří databáze. Zvolili jsme PostgreSQL [19] databázi, protože je volně přístupná a její administrace velmi jednoduchá. Pro komunikaci s ní budu v programu používat knihovnu libpq, která je přímo od vývojářů PostgreSQL a pracuje se s ní velice jednoduše. Schéma a údržba databáze je spolu s webovým rozhraním součástí jiné bakalářské práce [17]. Každý sniffer i extractor budou mít přidělené ID registrace od databáze, kterým se do ní nejprve přihlásí a až poté mohou manipulovat s hovory. Na konci programu se také musí aplikace z databáze odhlásit funkcí k tomu určenou.
17
Kapitola
Instalace, konfigurace a použití 4.1
Instalace aplikace
Před zkompilováním aplikace je potřeba zajistit dostupnost všech knihoven nutných pro běh. Těmi jsou libsndfile (zápis audia do souboru), libpcap (čtení paketů z PCAPu) a libpq (komunikace s databází PostgreSQL). Pro zkompilování stačí ve složce se zdrojovými kódy zadat příkaz make, který zkompiluje aplikaci. Dále lze aplikaci nainstalovat pomocí příkazu make install. Nejprve je ale nutné si ověřit instalační prefix v Makefilu, zda mám právo do tohoto adresáře zapisovat nebo si prefix upravit dle svých potřeb. Samozřejmě je nutné si také připravit databázové schéma vytvořené pro tento projekt a získat z něj nové ID pro extractor (podrobněji v přiloženém souboru INSTALL).
4.2
Konfigurační soubor
Nastavují se zde povinné přístupové údaje do databáze, jméno adresáře a formát výsledného souboru. Dále například velikost jitter bufferu v milisekundách, maximální počet souběžně zpracovávaných hovorů nebo místo pro logování v aplikaci. Nejprve jsou v aplikaci načteny výchozí hodnoty a dále přepsány direktivy z konfiguračního souboru. Výchozí cesta pro hledání konfiguračního souboru je v adresáři se spouštěnou aplikací. Pokud uživatel chce použít jiný soubor, musí k němu uvést cestu za přepínač -c při spuštění. V konfiguraci lze používat komentáře, které začínají znakem #. Zbytek řádky je poté ignorován. Pokud je nutné použít samotný znak # v parametru 19
4
4. Instalace, konfigurace a použití pro direktivu, musí být ochráněn pomocí sekvence \#, ze které je pro další použití odebráno zpětné lomítko. V celém souboru lze používat vícero mezer a tabelátorů pro oddělení direktiv od hodnot a zpřehlednění konfigurace.
4.3
Vytvoření výstupního souboru
Pro vytvoření výsledného audio souboru jsou zadány dva parametry v konfiguračním souboru. První je pro vytvoření cesty, kam se má soubor uložit. Může obsahovat formátovaný text formátu strftime (3), a také navíc i nahrazovaný řetězec %f za IP adresu volajícího nebo %t za adresu volaného, které se v jazyku strftime (3) nevyskytují, nebo znamenají znak pro tabelátor. Celá cesta je dále zkontrolována, zda každý adresář existuje. Pokud ne, je vytvořen, jinak dojde k chybě při extrakci a důvod je nahrán do databáze. Stejné pravidlo existuje i pro samotný audio soubor. Zadaný parametr je také nejprve prohledán pro sekvence %f, %t a poté předán stejné funkci. Na konec souboru je přidán audio formát .wav nebo .au, který je také dán konfiguračním souborem. Pokud již soubor se stejným názvem existuje, přidává se před formát souboru znak X, dokud se vytvoření souboru nepodaří. Pro interpretaci časových údajů je použité časové razítko vzniku hovoru z databáze, nebo se používá časové razítko prvního RTP paketu z PCAPu.
4.4
Spuštění aplikace
Při spuštění aplikace si lze vybrat mezi dvěma režimy. První je výchozí pro spojení s databází a druhý je pro extrakci pouze jednoho souboru PCAP. Pro tento režim se musí zadat v příkazové řádce cesta k souboru PCAP, IP adresa volajícího a IP adresa volaného. Běh aplikace lze ovlivnit několika přepínači: Tabulka 4.2: Přehled přepínačů aplikace v příkazové řádce. Přepínač -c -d -h -n 20
Parametr „configfile“ -
Popis Cesta ke konfiguračnímu souboru Neodpojovat aplikaci od terminálu Vypsat použití a skončit Vypsat konfiguraci a skončit
4.4. Spuštění aplikace Tabulka 4.1: Přehled direktiv v konfiguračním souboru a jejich parametry. Direktiva DBhost DBport DBname DBuser
Typ string string string string
Výchozí hodnota 127.0.0.1 5432 voipcall voipcall
DBpass registerID
string integer
voipcall 1
maxFetch
integer
10
nextFetch
integer
15
PCAPpath
string
-
deletePCAP
string
no
extractPath
string
calls-%Y%m%d
filename fileformat
string string
%H%M%S-%f-%t wav
mode
integer
0600
callWorkers
integer
3
jitter
integer
60
logTo
string
syslog
facility
string
local0
logLevel
string
warning
Popis Adresa databáze Číslo portu databáze Jméno databáze Jméno uživatele do databáze Heslo do databáze ID, kterým se aplikace přihlásí do databáze Maximum stažených hovorů z databáze v jednom dotazu Počet sekund mezi dotazy do databáze Předpona pro cestu k PCAPu z databáze Smazat PCAP po extrakci (yes, no) Cesta, kde mají být vytvořeny audio soubory Jméno audio souboru Formát vytvořeného audio souboru (wav, au) Práva vytvořeného audio souboru Počet zpracovávaných hovorů současně Velikost jitter bufferu v ms Kam se bude logovat (stdout, stderr, syslog, „filename“) Facilita pro syslog (local0 – local7) Minimální úroveň pro logování (err, warning, info, debug)
21
4. Instalace, konfigurace a použití
4.5
Logování
Uživatel aplikace má k dispozici několik způsobů, kam se mohou logovat hlášky. Výchozí místo pro logování je syslog (3) s facilitou local0 a úrovní hlášek alespoň LOG_WARNING. Dále může uživatel určit, že chce logovat přímo do souboru a k direktivě v konfiguračním souboru uvede cestu. Pokud takový soubor již existuje, jsou logy přidávány na konec souboru. Pokud se spustí aplikace s přepínačem -d, bude vše logováno přímo na standardní výstup. Aplikace podporuje signál SIGUSR1, který vypíše počet právě zpracovávaných hovorů na logovací místo definované konfiguračním souborem.
4.6
Ukončení aplikace
K ukončení aplikace může dojít několika způsoby. Jedním je, že program dostane ke zpracování pouze jeden hovor z příkazové řádky a je po provedení extrakce ukončen. Při napojení na databázi lze program řádně ukončit posláním signálu SIGQUIT, který zabezpečí zpracování již obdržených hovorů a nahrání výsledku do databáze. Žádné další hovory již nejsou stahovány z databáze. Další možností, jak ukončit program, je poslání signálu SIGINT nebo SIGTERM, který ukončí program okamžitě. Práce na všech zpracovávaných hovorech je ztracena a program se pouze pokusí odregistrovat z databáze, aby mohla nedokončené hovory poskytnout jinému dekodéru, nebo znovu přidělit při dalším spuštění. Samozřejmě k ukončení aplikace dojde i po některé z kritických chyb, jako například nenalezení konfiguračního souboru, nesprávné parametry u direktiv v konfiguračním souboru nebo chyba při zpracování přepínačů.
4.7
Dokumentace
Pro zdokumentování použití programu a konfiguračního souboru jsem napsal v jazyce mdoc [20] manuálové stránky. Ve složce se zdrojovými soubory je umístěn textový soubor INSTALL, který slouží jako jednoduchý návod pro správné nastavení všech potřebných nástrojů pro běh aplikace. Pro lepší porozumění zdrojovému kódu jsem vše zdokumentoval pro nástroj Doxygen [21]. Výsledná dokumentace je přiložena ve formátu HTML na CD a může být znovu vygenerována pomocí souboru Makefile.
22
Kapitola
Implementace V této kapitole popíši, jak fungují jednotlivé části programu.
5.1
Rozdělávání paketů
Každý obdržený paket z PCAPu se musí správně rozebrat po vrstvách až k RTP hlavičce. Tuto funkcionalitu obstarává jedna funkce, která volá další menší funkce zpracovávající různé protokoly vrstev TCP/IP modelu. V současné době program správně zpracuje z linkové vrstvy standard Ethernet II a pakety z loopbacku, z internetové vrstvy protokoly IPv4 a IPv6 a z transportní vrstvy UDP protokol.
5.2
Třída Call
Základní třída celého programu, která reprezentuje jeden uskutečněný hovor. Obsahuje všechny potřebné informace o hovoru z databáze a metody, které umožní extrakci hovoru. Třída obsahuje metodu AnalyzePCAP, která otevře PCAP soubor a testuje, zda obsahuje nějaké pakety. Pokud program zpracovává pouze jeden hovor a má skončit, tak si všechny potřebné údaje pro extrakci zjistí z prvního RTP paketu místo z databáze. Dále si třída vytvoří instance tříd Callstream, které extrahují jeden směr hovoru z PCAPu. Pro každý Callstream je vytvořeno vlastní vlákno kvůli lepší rozložení zátěže. Po úspěšné extrakci proudů se musí všechny spojit do jednoho souboru. K tomu využívám funkci Interleave od tvůrců libsndfile [22], která je otevře a průběžně prokládá proudy mezi sebou do výstupního souboru v požadovaném formátu. Knihovna libsndfile podporuje velké 23
5
5. Implementace množství kodeků a audio souborů, které jsou volně k použití. V této práci ale využíváme pouze audio formát WAV, Au a kodeky G.711, GSM.
5.3
Třída Callstream
Třída Callstream reprezentuje jeden RTP proud mezi účastníky. Typicky se tedy budou v hovoru vyskytovat pouze dva proudy. Nejprve si otevře PCAP s RTP pakety hovoru, z kterých vyfiltruje pouze potřebný směr. Dále si vytvoří instanci jitter bufferu (viz dále). Každý paket rozdělá až k samotné RTP hlavičce a předá získaná data do jitter bufferu. Vrácená data z jitter bufferu ukládá do dočasného souboru, který se později využije při výsledném prolínání proudů hovoru.
5.4
Jitter buffer
Třída umožňující velice důležitý nástroj pro správné uspořádání došlých paketů a pro lepší výsledný zvukový projev. Základem je kruhový buffer, jehož velikost je dána počtem milisekund z konfiguračního souboru. Protože extrahujeme hovory, které se již staly v minulosti a při přenosu mohlo dojít k výpadku většího množství paketů, než je velikost kruhového bufferu, museli jsme implementovat vedlejší setříděný spojový seznam. Ten si drží právě pakety s větším skokem v sekvenčním čísle. Při každém výstupu paketu z bufferu se kontroluje, zda může být první paket ze spojového seznamu vložen do kruhového bufferu. Maximální počet všech paketů v jitter bufferu je omezen stejnou hranicí. Po celou dobu extrakce se v jitter bufferu shromažďuje statistika o příchozích paketech, například kolik jich bylo celkově zpracováno, kolik jich dorazilo pozdě a musely být zahozeny, počet ztracených paketů a také těch, které dorazily mimo správné pořadí. Všechny statistiky jsou po úspěšném dokončení nahrány do databáze k hovoru.
5.5
Třída Context
Tato třída obstarává veškerou synchronizaci vláken uvnitř programu a drží si spojení s databází. Při inicializaci vytvoří několik vláken, která buď komunikují s databází, nebo se věnují extrakci. Vznikl zde tedy typický problém konzument-producent. Jedno vlákno si v pravidelném intervalu podle konfiguračního souboru stahuje z databáze připravené hovory pro extrakci, vytvoří instanci třídy 24
5.5. Třída Context Call s obdrženými informacemi a vloží ji do fronty hovorů k extrakci. Vlákna pro extrahování si z fronty vyzvednou práci, provedou extrakci a její výsledek vloží do výstupní fronty. Tuto frontu obsluhuje poslední vlákno, které se veškeré výsledky pokusí nahrát zpět do databáze. Pokud se to nepovede, výsledek pošle na logovací místo definované v konfiguračním souboru. Pro extrakci pouze jednoho hovoru je instance třídy Context také vytvořena kvůli synchronizaci extrakce Callstreamů, ale neobsahuje žádná spojení a vlákna pro obsluhu databáze.
25
Kapitola
Testování V této kapitole popíši klíčovou část vývoje aplikace. Během testování jsme se snažili vymyslet co nejvíce scénářů, se kterými se může uživatel potkat, a otestovat rychlost a správnost běhu programu.
6.1
Testování přenositelnosti
Zkoušeli jsme a ladili běh aplikace na různých operačních systémech UNIXového typu jako Linux, OpenBSD nebo Mac OS X. Spouštění pod operačním systémem OpenBSD jsme dokonce testovali na více architekturách (x86, ARM, PowerPC).
6.2
Použitá data
V testování správné extrakce audia jsme využívali testovací nástroje pro hromadné vytváření VoIP hovorů. Nástroje se jmenují Halali [23] a Hydra [24] a přístup k nim nám byl povolen od českého VoIP operátora xPhoNet. Díky ním jsme mohli vytvořit stovky hovorů a otestovat, jak se bude extractor chovat pod velkým náporem hovorů z databáze a také s cíleně vypadlými nebo zduplikovanými pakety. Ručním vytvářením každého hovoru bychom zátěžového testu nejspíše nebyli schopni dosáhnout, ale pro testování správnosti extrakce audia jsme také zkoušeli ručně volat mezi mnoha klienty a VoIP operátory. 27
6
6. Testování
6.3
Otestované scénáře
• testování validity konfiguračního souboru • správná extrakce obyčejného hovoru • základní spuštění bez zadaných parametrů s výchozími hodnotami • korektní ukončení po obdržení signálu SIGQUIT • násilné ukončení pomocí SIGTERM • správné logování hlášek všechny možné výstupy aplikace • extrakce hovoru s velice rozbitým pořadím RTP paketů • ztráta připojení k databázi během extrakce • zpracování stovek hovorů po připojení k databázi • běh s různými počty vláken pro extrakci • spuštění na OpenBSD, Linux a Mac OS X • testování na architekturách PowerPC, ARM, x86 a amd64
6.4
Neotestované scénáře
• provoz na IPv6 - nemáme infrastrukturu • exktrakce hovoru probíhající kodekem GSM - nemáme VoIP telefony podporující tento kodek • provoz na VLAN - nemáme infrastrukturu
6.5
Nalezené problémy a řešení
Jedním z nalezených problémů bylo, že když proudy hovoru nebyly stejně dlouhé, tak se opakovalo několik posledních milisekund kratšího proudu až do úplného konce hovoru. Nejprve jsem měl podezření na chybu v jitter bufferu, ovšem postupně jsem se dopracoval až k prolínání proudů ve funkci Interleave, kde se stále dokola zapisoval nevyčištěný buffer. Tuto 28
6.5. Nalezené problémy a řešení chybu jsme odeslali vývojářům libsndfile s návrhem řešení, které akceptovali a začlenili do příštího vydání aktualizace.1 Testovali jsme program, zda správně zachází s přidělenou pamětí od operačního systému. Našli jsme, že dochází k neuvolnění malé paměti na konci programu v knihovně libpcap a také k docela velkému množství v knihovně openssl, kterou využívá knihovna libpq pro komunikaci s databází. Při testování na architektuře ARM se objevil problém, kdy mi program vždy skončí neočekávaně s návratovou hodnotou 1. Tato chyba se nám zatím nepodařila, i po velice důkladném zkoumání, odhalit. Další problém nastal při testování na operačním systému Mac OS X 10.5.8, kdy můj program i sniffer skončil s obdrženým signálem Bus error.
1
https://github.com/erikd/libsndfile/commit/95c6970e6df936b8c13c2970594626795e677b22
29
Závěr Shrnutí V rámci této bakalářské práce jsem se snažil přiblížit technologii VoIP a vysvětlit rozdíly oproti klasické telefonii. Srovnal jsem možnosti, jak tyto hovory nahrávat a extrahovat a také uvedl nejpodstatnější legislativu, která určuje pravidla a možnosti nahrávání. Dále jsem v bakalářské práci navrhl, implementoval a otestoval aplikaci, která spolu s dalšími aplikacemi tvoří ucelený systém pro přehrávání, monitorování a archivaci hovorů. Systém v době odevzdání ještě nefunguje v plném provozu, jelikož bakalářská práce týkající se webového rozhraní a databáze má jiné datum odevzdání, ale funkčnost zbývajících dvou aplikací by tím neměla být podstatně dotčena. Ve VoIP komunikaci spatřuji velkou budoucnost, protože díky neustálému připojení mobilních telefonů na Internet, narůstající rychlosti připojení a zkracujícímu se zpoždění dat na cestě, se bude postupně, dle mého názoru, čím dál častěji přecházet na tento způsob telekomunikace. V posledních letech rozvíjejí současní mobilní operátoři technologii VoLTE (Voice over Long Term Evolution), díky které se z nich, jistě ale pomalu, stanou pouze internetoví poskytovatelé.
Možnosti rozšíření V budoucnu bych chtěl zapracovat na rozšíření podporovaných kodeků, tedy nejspíše použít lepší knihovnu než je libsndfile. Řešením by také bylo vytvoření si vlastního chytrého dekodéru z jiných již dostupných knihoven, jako je libavcodec. 31
Závěr Dalším možným rozšířením by bylo zapracovat konferenční hovory, což by znamenalo upravit celý projekt od základu včetně schéma databáze. Dále také reflektovat případnou změnu dohodnutého kodeku během hovoru, tudíž naučit aplikaci rozeznávat RTCP pakety. Velice zajímavým rozšířením, které bych chtěl v budoucnu začlenit do projektu, je možnost přehrávat v reálném čase hovory právě probíhající na síti. To by nejspíše znamenalo vytvořit si vlastní protokol, kterým by se části projektu navzájem dorozumívaly.
32
Literatura [1] Sipnology: VoIP Growing Statistics [online]. [cit. 2015-04-07]. Dostupné z: http://www.sipnology.com/company/20-voip-growingstatistics [2] Serych: Ukázka SIP transakce (podle RFC3261) [online]. Wikipedia: the free encyclopedia, 2006, [cit. 2015-04-07]. Dostupné z: http:// commons.wikimedia.org/wiki/File:SIP_transakce.png [3] Schulzrinne, H.; Casner, S. L.; Frederick, R.; aj.: RTP: A Transport Protocol for Real-Time Applications [online]. červen 2003, [cit. 201504-07]. Dostupné z: http://www.rfc-editor.org/rfc/rfc3550.txt [4] DK-projects: RTP packet header [online]. 2014, [cit. 2015-04-25]. Dostupné z: http://www.dk-projects.org/wp-content/uploads/2014/ 07/tshark_02.png [5] Nyquist, H.: Certain topics in telegraph transmission theory. AIEE Trans., 1928. [6] Karapantazis, S.; Pavlidou, F.-N.: VoIP: A comprehensive survey on a promising technology [online]. 2009, [cit. 2015-04-15]. Dostupné z: http://www.sciencedirect.com/science/article/pii/ S1389128609001200 [7] Voip Think: Packet Loss. [cit. 2015-05-10]. Dostupné z: http:// www.en.voipforo.com/QoS/QoS_PacketLoss.php [8] Česká republika: Listina základních práv a svobod. 1993, 17-23 s., ISSN 1211-1244. [cit. 2015-04-30]. Dostupné z: http://www.psp.cz/docs/ laws/listina.html 33
Literatura [9] Úřad pro ochranu osobních údajů: Pořizování nahrávek telefonických hovorů [online]. 2015, [cit. 2015-05-02]. Dostupné z: https://www.uoou.cz/porizovani-nahravek-telefonickychhovoru/d-14882 [10] Dubovikov, A.; Mangani, L.: Homer [online]. [cit. 2015-05-10]. Dostupné z: http://www.sipcapture.org/ [11] VoIPmonitor: What is VoIPmonitor [online]. [cit. 2015-05-02]. Dostupné z: http://www.voipmonitor.org [12] Wireshark: Wireshrak About [online]. [cit. 2015-04-25]. Dostupné z: https://www.wireshark.org/about.html [13] Costa, G.; Franceschi, A. D.: Xplico [online]. [cit. 2015-05-09]. Dostupné z: http://www.xplico.org/about [14] Sdet.us: Python Pcap Parsing (Listening to Audio from a SIP call) [online]. 2014, [cit. 2015-04-28]. Dostupné z: http://sdet.us/pythonpcap-parsing-audio-from-sip-call [15] SoX - Sound eXchange [online]. [cit. 2015-05-09]. Dostupné z: http: //sox.sourceforge.net/ [16] Šuster, F. Extrakce a zpracování hlasu z VOIP paketů. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2015. [17] Robejšek, V. Webové rozhraní k VOIP hovorům. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2015. [18] Mccanne, S.; Jacobson, V.: The BSD Packet Filter: A New Architecture for User-level Packet Capture [online]. Lawrence Berkeley Laboratory, 1992, [cit. 2015-05-09]. Dostupné z: http://www.tcpdump.org/papers/ bpf-usenix93.pdf [19] PostgreSQL: PostgreSQL [online]. [cit. 2015-04-15]. Dostupné z: http: //www.postgresql.org [20] Schwarze, I.; Dzonsons, K.: mdoc [software]. [přístup 2015-05-10]. Dostupné z: http://mdocml.bsd.lv/ [21] van Heesch, D.: Doxygen [software]. [přístup 2015-05-10]. Dostupné z: http://www.stack.nl/~dimitri/doxygen/index.html 34
Literatura [22] de Castro Lopo, E.: libsndfile [online]. [cit. 2015-04-15]. Dostupné z: http://www.mega-nerd.com/libsndfile/ [23] Heliot: Halali - příchozí telefoní hláska [online]. [cit. 2015-05-11]. Dostupné z: http://www.heliot.cz/halali-prichozi-telefonnihlaska.html [24] Heliot: Hydra - odchozí telefonní volačka [online]. [cit. 2015-0511]. Dostupné z: http://www.heliot.cz/hydra-odchozi-telefonnivolacka.html
35
Příloha
Seznam použitých zkratek IETF Internet Engineering Task Force ITU International Telecommunication Union MIPS Million Instruction Per Second MOS Mean Opinion Score QoS Quality of Service RTCP RTP Control Protocol RTP Real-time Transfer Protocol SCCP Skinny Client Control Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol UDP User Datagram Protocol VoIP Voice over Internet Protocol VoLTE Voice over Long Term Evolution
37
A
Příloha
Obsah přiloženého CD
readme.txt ................................ stručný popis obsahu CD doc.................................adresář s dokumentací k aplikaci index.html......................dokumentace ve formátu HTML src impl.................................zdrojové kódy implementace thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce BP_Kucera_Josef_2015.pdf...........text práce ve formátu PDF 39
B
