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

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya VoIP klient BAKALÁŘSKÁ PRÁCE Michal Vávra Brno, jaro 2008

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

Poděkování Tímto bych chtěl poděkovat vedoucí práce RNDr. Evě Hladké, Ph.D. za hodnotné rady a odborné vedení během mé práce. iii

Shrnutí Účelem této práce bylo srovnání dnes používaných VoIP klientů a nalezení kriterií pro jejich hodnocení. Nejprve popíši technologie používané pro VoIP, následně provedu porovnání šesti VoIP klientů a z výsledků sestavím kriteria pro jejich hodnocení. V poslední části se pak věnuji návrhu a popisu použití VoIP klientu, který byl vytvořen v rámci této práce. iv

Klíčová slova IP telefonie, Voice over Internet Protocol, Session Initiation Protocol, Real-time Transport Protocol, Java, VoIP klient v

Obsah 1 Úvod................................... 1 2 Protokoly a technologie používané pro VoIP............ 2 2.1 Session Initiation Protocol.................... 2 2.1.1 Principy fungování SIPu................. 3 2.1.2 Entity v SIPu....................... 5 2.2 Session Description Protocol................... 5 2.3 Real-time Transport Protocol.................. 6 2.4 Zvuk, jeho získávání a kódování................ 6 2.5 Průběh běžného VoIP hovoru nad protokolem SIP...... 7 3 Přehled klientů............................. 9 3.1 Metodika testování........................ 9 3.2 Ekiga................................ 10 3.3 X-Lite................................ 11 3.4 SJphone............................... 12 3.5 Linphone.............................. 13 3.6 WengoPhone............................ 14 3.7 SIP Communicator........................ 15 3.8 Závěrečné zhodnocení porovnávaných VoIP klientů..... 16 4 Návrh a vývoj vlastního VoIP klientu................ 18 4.1 Návrh klientu........................... 18 4.2 Použité technologie........................ 19 4.3 Popis použití............................ 19 5 Závěr................................... 22 A Příloha A................................. 24 B Příloha B................................. 25 vi

Kapitola 1 Úvod Koncem 90. let 20. století bylo vytáčené spojení nejběžnějším způsobem připojování se k Internetu. Docházelo tak vlastně k vytváření paketové sítě nad spojovanou sítí telefonní. Dnes, o deset let později, je situace téměř opačná a dochází k vytváření spojované sítě nad sítí paketovou. Většina domácností vlastní vysokorychlostní přípojku k Internetu a masově se začíná projevovat fenomén známý jako IP telefonie či Voice over Internet Protocol (dále jen VoIP), ve volném překladu hlas přenášený po Internetu či jednodušeji, telefonování po Internetu. Během tohoto poměrně rychlého vývoje bylo vytvořeno několik signalizačních a přenosových protokolů pro VoIP a mnoho klientů, které nad nimi fungují. Jako přední dva signalizační protokoly se ukázaly H.323[1] a Session Initiation Protocol[2] (dále jen SIP). Tato práce se bude v teoretické části zabývat srovnáním VoIP klientů pracujících nad protokolem SIP a nalezením vhodných kritérií pro jejich srovnávání. Hlavním důvodem pro upřednostnění protokolu SIP je fakt, že díky svému návrhu a použití textové komunikace je daleko pružnější než již zmiňovaný protokol H.323. V praktické části je popsán návrh, vývoj a návod k použití mého vlastního jednoduchého VoIP klientu, který byl napsán tak, aby reflektoval kritéria pro hodnocení VoIP klientů shrnutá v teoretické části práce. 1

Kapitola 2 Protokoly a technologie používané pro VoIP Abych mohl naplnit cíle práce, které jsem nastínil v úvodní kapitole, je třeba znát alespoň základní charakteristiky jednotlivých protokolů a technologií, které se pro VoIP používají. Proto v této kapitole postupně vysvětlím, jak funguje signalizační protokol SIP, protokol pro popis spojení Session Description Protocol[3] (dále jen SDP), protokol pro přenos multimediálních dat Real-time Transport Protocol[4] (dále jen RTP), jak samotná multimediální data, v tomto případě konkrétně audio data, získat, připravit pro přenos a jak je následně prezentovat na straně příjemce. Na konci této kapitoly pak na jednoduchém příkladu popíši, jak všechny tyto části fungují dohromady při běžném internetovém telefonním hovoru. 2.1 Session Initiation Protocol Session Initiation Protocol, v českém překladu protokol pro ustavení spojení, je v současnosti nejperspektivnějším signalizačním protokolem v prostředí VoIP. Dokumentaci nalezneme v RFC 3261[5]. Slovo signalizační znamená, že protokol sám o sobě nepřenáší hlas či video, nýbrž slouží jako prostředek k dohodě komunikujících stran o tom, v jakém formátu, jakým způsobem a na jakém portu bude docházet k samotnému přenosu multimediálního obsahu. SIP ale nemusí sloužit jen pro VoIP. Díky vhodnému návrhu ho lze použít například pro Instant Messaging aplikace, tedy aplikace určené pro výměnu textových zpráv, jako je například v České republice velmi oblíbené ICQ. Na následujících stránkách popíši, na jakém principu SIP funguje a jaké v něm figurují entity. 2

2.1.1 Principy fungování SIPu 2. PROTOKOLY A TECHNOLOGIE POUŽÍVANÉ PRO VOIP SIP je protokol, který je v principu velmi podobný známému protokolu HTTP 1. Stejně jako HTTP pracuje na principu Request Response, v překladu Požadavek Odezva, a stejně jako u HTTP se jedná o textový protokol. Všechny zprávy jsou posílány ve formě textu, který člověk může bez problémů číst. Právě tato vlastnost dovoluje SIPu být mnohostraně použitelným, nebot vývojář není při tvorbě aplikací pevně vázán na původní přesně specifikované zprávy. Další důležitou vlastností SIPu je jeho nezávislost na přenosovém protokolu. SIP funguje jak nad UDP 2, tak nad TCP 3. O několik řádků výše jsem zmínil, že SIP funguje na principu Požadavek Odezva. Následuje popis jednotlivých požadavků, které jsou specifikovány v RFC 3261. Jedná se o následujících šest požadavků: INVITE Slouží jako pozvánka k hovoru. ACK Slouží jako potvrzení, že odesílateli dorazila finální odezva. Na tento požadavek se nijak nereaguje. BYE Slouží pro ukončení hovoru, byl-li již potvrzen, tedy pokud byla zaslána odpověd 200 OK. CANCEL Slouží k ukončení hovoru, nebyl-li ještě potvrzen, tedy pokud nebyla zaslána odpověd 200 OK. OPTIONS Slouží k zjištění, co vše může server, kterému je tento požadavek zaslán, vykonávat. REGISTER Slouží k registraci odesílatele požadavku na takzvaném registrar serveru (viz. kapitola 2.1.2). Odezvy v SIPu maji velmi podobné kódy i význam jako odezvy v HTTP. Odezev je velké množství, takže pouze uvedu, co které rozsahy kódů znamenají, a vypíši jen ty důležité. Odezvy 100 až 199 Informují o stavu spojení. Odezva 180 Ringing Slouží jako odezva na požadavek INVITE a informuje odesílatele požadavku, že se čeká na příjem či odmítnutí hovoru volaným. 1. HTTP, http://en.wikipedia.org/wiki/http 2. UDP, http://en.wikipedia.org/wiki/user_datagram_protocol 3. TCP, http://en.wikipedia.org/wiki/transmission_control_protocol 3

2. PROTOKOLY A TECHNOLOGIE POUŽÍVANÉ PRO VOIP Odezvy 200 až 299 Informují o úspěchu požadavku, na který reagují. Odezva 200 OK Informuje, že požadavek byl zpracován úspěšně. Odezvy 300 až 399 Informují o přesměrování požadavku. Odezvy 400 až 499 Informují o selhání z důvodu špatného požadavku. Odezva 404 Not Found Informuje, že adresát požadavku nebyl nalezen. Odezvy 500 až 599 Informují o selhání z důvodu chyby na serveru. Odezvy 600 až 699 Informují o selhání z důvodu obecné chyby. Každá zpráva, at už požadavek či odezva, se skládá z úvodní řádky, jednotlivých hlaviček a případého obsahu těla zprávy. Než přistoupím k popisu důležitých hlaviček, je třeba vysvětlit pojem SIP URI. SIP URI je velmi podobný e-mailové adrese a slouží pro jednoznačnou identifikaci každého účastníka v SIPové telefonní síti. Je tvaru uživatel@server, tedy například pokud by uživatel Bob měl domovský server brno.cz, bude jeho SIP URI bob@brno.cz. Nyní přejdu k popisu úvodní řádky a nejdůležitějších hlaviček. Úvodní řádka Je rozdílná pro požadavek a pro odezvu. Úvodní řádka pro požadavek obsahuje typ požadavku (INVITE, BYE apod.), SIP URI adresáta požadavku a verzi protokolu (dnes výhradně SIP/2.0). Úvodní řádka odezvy obsahuje verzi protokolu, kód odezvy a řetězec s důvodem dané odezvy. Hlavička To Určuje, komu je zpráva určena. Adresa má tvar SIP URI. Hlavička From Určuje odesílatele zprávy, tedy komu budou zasílány případné odpovědi. Adresa má tvar SIP URI. Hlavička CSeq Identifikuje transakci. Hlavička Via Jednoznačně identifikuje každý hovor. Hlavička Contact Tato hlavička v požadavku typu REGISTER určuje jméno, pod kterým má registrar server evidovat adresu, ze které tento požadavek přišel. Jméno má tvar SIP URI. Tato hlavička se může opakovat. Hlavička Content-Type Tato hlavička určuje typ obsahu těla zprávy, pokud nějaký existuje. Pokud je přítomna, musí být přítomna i hlavička Content-Length, která určuje délku obsahu těla zprávy. 4

2.1.2 Entity v SIPu 2. PROTOKOLY A TECHNOLOGIE POUŽÍVANÉ PRO VOIP V SIPu rozeznáváme 4 typy entit User Agent, Proxy Server, Redirect Server a Registrar Server. User Agent Reprezentuje koncový bod, kterým je například VoIP klient. Protože každý klient může posílat i přijímat požadavky, vnitřně se každý User Agent dělí na User Agent Client (dále jen UAC) a User Agent Server (dále jen UAS). Zatímco UAC požadavky zasílá, UAS požadavky zpracovává a zasílá na ně odezvy. Proxy Server Chová se jako UAC i UAS, tedy přijímá požadavky i zasílá odpovědi. Nejedná se však o koncový bod v SIPové architektuře. Proxy server může přijímat požadavky, jednat ve jménu původního zasilatele požadavku a poté mu zaslat finální výsledek transakce. Redirect Server Přijímá požadavky od klientu a mění pole adresáta požadavku na aktuální adresu volaného. Následně vrací tyto požadavky volajícímu. Tedy informuje volajícího o změně adresy volaného. Registrar Server Toto je speciální typ serveru, který přijímá požadavky typu REGISTER a podle hodnot jejich hlavičky či hlaviček typu Contact upravuje vlastní databázi o umístění daného uživatele. 2.2 Session Description Protocol Session Description Protocol[3], v českém překladu protokol pro popis spojení, slouží pro ustanovení konkrétního kodeku (viz. kapitola 2.4), který se má použít pro přenos multimediálních dat. Bývá součástí SIPového požadavku typu INVITE, a to jako obsah těla tohoto požadavku. VoIP klient volajícího v této zprávě specifikuje, jaké kodeky podporuje a na jaké adrese a portu očekává multimediální data. VoIP klient volaného poté vyhodnotí obsah této zprávy a pokud zjistí, že obě strany podporují alespoň jeden stejný kodek, bude tento použit pro výměnu multimediálních dat. V případě, že je k dispozici kodeků více, vybere se ten s nejvyšší prioritou, což už je ale záležitost každého konkrétního VoIP klientu. V případě, že volaný hovor přijme, odešle se v těle jeho odezvy 200 OK zpráva protokolu SDP, obsahující identifikátor vybraného kodeku, adresu a port, na kterém volaná strana očekává multimediální data. 5

2. PROTOKOLY A TECHNOLOGIE POUŽÍVANÉ PRO VOIP 2.3 Real-time Transport Protocol Real-time Transport Protocol, v českém překladu protokol pro přenos dat v reálném čase, je určen pro přenos multimedií. Tento protokol je definován v RFC 3550[6]. RTP pracuje nad transportním protokolem UDP a nemá žádný pevně definovaný port, který by používal. Jediným pravidlem je, že číslo portu pro RTP je sudé a následující port se použije pro protokol RTCP[7], sesterský protokol k RTP, sloužící k výměně informací o spojení mezi komunikujícími stranami. Obecně pro UDP platí, že se jedná o protokol s nezajištěným přenosem, negarantující doručení paketů ani jejich případné správné pořadí. Dokáže však pakety posílat rychleji než TCP, což je právě pro multimedia žádaná vlastnost. RTP posílá v paketu s multimediálními daty také informaci o typu multimediálních dat, která přenáší, o pořadí daného paketu, aby bylo možno na straně příjemce data rekonstruovat, a v neposlední řadě časové razítko pro kontrolu rozptylu času, který potřebují pakety na cestu k cíli. 2.4 Zvuk, jeho získávání a kódování Zvuk je ve své podstatě podélné mechanické vlnění v látkovém prostředí (v tomto případě ve vzduchu), které je schopné v lidském uchu vyvolat sluchový vjem. [8] Zvukové vlnění je tedy analogová spojitá veličina, kterou chceme převést do diskrétních hodnot. Toho se dociluje použitím technik vzorkování a kvantování. Při vzorkování dochází k odebírání vstupního signálu v definovaných intervalech, takzvané vzorkovací frekvenci. Typické vzorkovací frekvence jsou: 8 khz Odpovídá kvalitě telefonního hovoru. 11 khz Odpovídá lidské řeči. 44,1 khz Odpovída CD kvalitě. 48 khz a vyšší Odpovídá DVD kvalitě. Po navzorkování signálu nastupuje kvantování, při kterém se každému navzorkovanému bodu přiřadí jeho zvuková intenzita. Nejčastěji používané jsou hodnoty: 8 bitů 256 úrovní Dostačuje pro telefonní hovor. 6

2. PROTOKOLY A TECHNOLOGIE POUŽÍVANÉ PRO VOIP 16 bitů 65 536 úrovní Odpovídá CD kvalitě. 24 bitů 16 777 216 úrovní Odpovídá DVD kvalitě. Po provedení vzorkování a kvantování dostaneme diskrétní signál ve formátu zvaném Pulse Code Modulation, dále jen PCM. Výsledná šířka přenosového media se poté spočte jako vzorkovací frekvence hodnota kvantování v bitech. Šířka pásma nutná pro VoIP hovor je tedy 8000 (vzorkovací frekvence 8 khz) 8 bitů = 64kb/s v jednom směru. Tato hodnota může být na některých linkách problémem, proto je nutné používat různé další kodeky. Kodek je program pro kompresi a následnou dekompresi multimediálních dat, tedy pro snížení nároků na šířku přenosového pásma. Pro VoIP je velmi polulární rodina kodeků Speex, které nejsou zatíženy patenty a jsou dostupné pod BSD licencí 4. Každý kodek kromě snížení nároků na přenosové pásmo také vnáší do přenosu určité zpoždění, způsobené kompresí dat u odesílatele a dekompresí u příjemce. Všechny ztrátové kodeky navíc více či méně zhoršují kvalitu přenášeného zvuku. 2.5 Průběh běžného VoIP hovoru nad protokolem SIP Nyní, když jsem nastínil všechny základní technologie používané pro VoIP, mohu ukázat průběh běžného VoIP hovoru nad protokolem SIP. Hovor bude probíhat mezi dvěma účastníky, Alicí a Bobem. Alice má domovský server s adresou adamov.cz, její SIP URI tedy je alice@adamov.cz. Bob má domovský server brno.cz a SIP URI bob@brno.cz. Alice chce volat Bobovi, zadá tedy do svého VoIP klientu bobovu SIP URI bob@brno.cz. Alicin VoIP klient vytvoři požadavek INVITE, obsahující ve svém těle údaje protokolu SDP, který zašle bobovu domovskému serveru brno.cz. Tento server ve zprávě přepíše adresu odesílatele na svoji adresu a pošle zprávu na adresu, na níž se aktuálně Bob nachází. Bobův VoIP klient zprávu přečte, podle údajů protokolu SDP ve zprávě zkontroluje, zda podporuje alespoň jeden stejný zvukový kodek jako Alicin VoIP klient, zašle Alici prozatimní odpověd 180 Ringing a informuje Boba, že má příchozí hovor. V případě, že by Bob hovor odmítl, odešle jeho klient odpověd 603 Declined, na kterou Alicin VoIP klient zareaguje potvrzujícím požadavkem ACK a dojde k ukončení hovoru. 4. BSD licence, http://en.wikipedia.org/wiki/bsd_licence 7

2. PROTOKOLY A TECHNOLOGIE POUŽÍVANÉ PRO VOIP V případě, že Bob hovor přijme, jeho VoIP klient zašle Alici konečnou odpověd 200 OK, obsahující ve svém těle údaje protokolu SDP. Alicin VoIP klient odešle požadavek ACK, aby dal najevo, že přijal odpověd 200 OK. V této chvíli oba VoIP klienty začnou naslouchat na portech, na kterých ve zprávách protokolu SDP specifikovaly, že očekávají multimediální data. Zárověň začnou sbírat, komprimovat a odesílat zvuková data na adresu a port svého protějšku, kde jsou tato data dekomprimována a prezentována. Jakmile si jeden z účastníků hovoru přeje hovor ukončit, stiskne k tomu určené tlačítko, či provede jinou akci a jeho VoIP klient druhému účastníku zašle požadavek BYE. Zároveň přestane posílat zvuková data a naslouchat na portu pro příchozí zvuková data. Když zpráva dorazí druhému účastníku hovoru, tento taktéž uzavře svůj naslouchací port, přestane vysílat zvuková data a zašle svému protějšku zprávu 200 OK, aby dal najevo, že rozuměl. Po přijetí odezvy 200 OK odesílatel požadavku BYE zašle požadavek ACK pro potvrzení přijetí odezvy na svůj požadavek BYE a tímto je hovor definitivně ukončen. 8

Kapitola 3 Přehled klientů Tato část mé bakalářké práce je zaměřena na testování jednotlivých VoIP klientů v praxi. Vybral jsem šest VoIP klientů, pracujících nad protokolem SIP. S žádným z těchto klientů jsem doposud neměl žádné zkušenosti, což bylo zárukou zcela jednotného a nezaujatého přístupu ke všem šesti mnou vybraným VoIP klientům. 3.1 Metodika testování Všechny mnou vybrané VoIP klienty existují jak ve verzi pro platformu Windows, tak pro platformu Linux. Z tohoto důvodu bylo prováděno testování každého VoIP klientu na dvou počítačích. Pro platformu Windows to byl počítač s dvoujádrovým procesorem Intel Core 2 Duo E6600 s taktem jader 2400 MHz, který byl vybaven 2 GB operační paměti. Pro platformu Linux sloužil počítač s procesorem Intel Pentium IV s taktem 3200 MHz a aktivovanou technologií Hyper-Threading, taktéž s 2 GB operační paměti. Další parametry počítačů neuvádím, jelikož ty již nejsou relevantní pro testování. Platformu Windows zastupoval operační systém Windows XP Professional s balíčkem aktualizací Service Pack 2 a všemi následujícími aktualizacemi. Platformu Linux pak zastupoval operační systém Ubuntu 8.04 LTS Hardy Heron, taktéž plně aktualizovaný. U každého klientu bylo zkoumáno, jak jednoduše je dostupný pro běžného uživatele, jak náročná je instalace daného klientu, jak rychle se klient spouští, kolik procent procesorového času a jak velké množství paměti potřebuje ve stavu nečinnosti a kolik systémových prostředků potřebuje, pokud probíhá hovor. Sít, na které veškeré testy probíhaly, používala privátní adresy v rozsahu 192.168.0.0 192.168.0.255. Zkušební počítač pro platformu Windows měl adresu 192.168.0.1, zkušební počítač pro platformu Linux měl adresu 9

3. PŘEHLED KLIENTŮ 192.168.0.204, registrar server, na kterém běžela ústředna Asterisk 1, měl adresu 192.168.0.230. Dále byly do testovací sítě zapojeny dva hardwarové SIPové telefony IP 300 Internet Phone. Všechny VoIP klienty byly nakonfigurovány tak, aby používaly pro přenos hlasu pouze formát PCM µ-law, neboli taktéž PCMU 2. Takto jsem eliminoval různé odchylky v měření spotřeby systémových prostředků, zpusobené použitím rozdílných kodeků. 3.2 Ekiga VoIP klient Ekiga 3, jehož starším jménem je GnomeMeeting, je šířen pod licencí GNU/GPL 4 a má otevřený zdrojový kód. Ekiga podporuje jak signalizaci nad protokolem SIP, tak nad protokolem H.323. Na platformě Linux je součástí některých distribucí, ale je i volně ke stažení ve formě již připravených instalačních balíků či zabalených zdrojových kódů. Pro platformu Windows existuje Ekiga jako betaverze. Aktuální verze Ekigy je 2.0.12, na Windows je zatím k dispozici instalace pouze pro verzi 2.0.11. Stažení i instalace na obou platformách jsou operace, které v případě použítí připravených binárních instalačních balíků zvládne i méně zkušený uživatel. Na platformě Windows je současně nainstalováno i GTK+, což je grafické prostředí, ve kterém Ekiga běží. Při prvním spuštění Ekiga otevře asistenta pro první nastavení, což je jednoduchý průvodce, který umožní v deseti krocích nastavit Ekigu dle potřeb uživatele. Za pozitivní považuji možnost vytvoření bezplatné SIPové adresy na serveru ekiga.net, která však není uživateli nijak vnucována. Další v dnešní době velmi užitečnou položkou asistenta je automatická detekce typu použitého překladu adres, takzvaného NATu. Po zjištění typu NATu Ekiga navrhne vhodná opatření, aby vše fungovalo jak má. Samotné provedení těchto opatření je již na uživateli samotném. Jakmile se Ekiga spustí, je možno v menu Účty nastavit, na které registrar servery se má Ekiga pokusit zaregistrovat a s jakými údaji. V menu Nastavení je možno měnit nastavení průchodu přes NAT včetně možnosti použití STUN 5 serveru. Mimo to můžeme v nastavení měnit množinu používaných zvukových kodeků či například nastavovat přesměrování SIPových hovorů. 1. Asterisk, http://www.asterisk.org/ 2. PCMU, http://en.wikipedia.org/wiki/%ce%9c-law_algorithm 3. Ekiga, http://www.ekiga.org/ 4. GNU/GPL Licence, http://en.wikipedia.org/wiki/gnu_general_public_license 5. STUN, http://en.wikipedia.org/wiki/simple_traversal_of_udp_over_nats 10

3. PŘEHLED KLIENTŮ Tabulka 3.1: Ekiga Windows Linux Verze 2.0.11 2.0.12 Rychlost prvního startu 12 s 3,2 s Využití CPU během hovoru 3 5 % 8 9 % Využití operační paměti během hovoru 21 860 kb 10 700 kb Využití CPU mimo hovor 0 % 0 % Využití operační paměti mimo hovor 21 210 kb 10 600 kb Způsoby překonávání NATu Odchozí proxy server STUN server Přímé nastavení veřejné IP adresy 3.3 X-Lite X-Lite je VoIP klient vyvíjený společností CounterPath, dříve známou jako Xten. X-Lite je dostupný na webové adrese společnosti CounterPath 6 a je ke stažení ve verzi 3.0 pro platformy Windows, Linux a Mac. Je dostupný zdrama, má však uzavřený zdrojový kód. Tento VoIP klient podporuje signalizaci pouze nad protokolem SIP. Společnost CounterPath vyvíjí ještě VoIP klienty Bria a eyebeam, které jsou však placené. Než je uživateli umožněno stažení tohoto VoIP klientu ze stránek výrobce, je třeba zadat e-mailovou adresu, na kterou je následně zaslána žádost o vyplnění dotazníku. Pro platformu Windows je ke stažení klient s instalátorem, pro Linux pouze zabalený binární soubor, který stačí rozbalit a spustit. Během instalace na Windows se X-Lite dotáže, zda se má spouštět okamžitě po naběhnutí systému. Při prvním spuštění se otevře konfigurační okno, kde je možno vyplnit všechny důležité údaje, jako je nastavení registrace na registrar server či zda má být použit proxy server pro odchozí hovory. Po tomto iniciálním nastavení je X-Lite okamžitě schopen fungovat. V menu lze ještě nastavit další SIPové účty, jaké zvukové kodeky se mají používat či jaký typ připojení k Internetu uživatel používá. V menu však není jakákoliv možnost nastavení průchodu přes NAT. X-Lite spoléhá na to, že sít, ve které bude provozován, bude obsahovat SIP proxy server, který 6. X-Lite, http://www.counterpath.com/x-lite.html 11

3. PŘEHLED KLIENTŮ bude obsluhovat veškeré požadavky přicházející z vnější sítě. Ve většině domácností ale takový stroj není, a to X-Lite dosti znehodnocuje. Tabulka 3.2: X-Lite Windows Linux Verze 3.0 3.0 Rychlost prvního startu 4,5 s 2,3 s Využití CPU během hovoru 1 % 1 % Využití operační paměti během hovoru 34 160 kb 14 110 kb Využití CPU mimo hovor 0 % 0 % Využití operační paměti mimo hovor 34 130 kb 13 700 kb Způsoby překonávání NATu Odchozí proxy server 3.4 SJphone SJphone je VoIP klient vyvíjený společností SJ Labs 7, dostupný ke stažení pro Windows, Linux, Mac a pro kapesní počítače vybavené platformou Windows CE. Stejně jako X-Lite je i SJphone dostupný zdarma a taktéž má uzavřený zdrojový kód. Podporuje signalizaci nad protokoly SIP, H.323 a XMPP 8. Stažení VoIP klientu SJphone není nijak limitováno. Pro platformu Windows je dostupný ve verzi 1.65.377a spolu s instalátorem, pro Linux pak ve verzi 1.60.299 jako zabalený binární soubor, doprovázený potřebnými knihovnami. Při instalaci na platformě Windows se SJphone bez jakéhokoliv vědomí uživatele přidá mezi programy spouštěné po nastartování systému a po dokončení instalace se okamžitě spustí. Na platformě Linux stačí rozbalit obsah staženého souboru a spustit binární soubor. Po prvním spuštění se otevře průvodce nastavením zvukových zařízení. Bohužel další nastavení musí uživatel v menu hledat sám. Menu je naštěstí docela přehledné. Lze v něm nastavovat vlastnosti zvuku, používané zvukové kodeky či vzhled klientu. Poměrně zvláštně je řešeno nastavení SIPu. Nejprve je třeba vybrat profil spojení. Po instalaci jsou pro SIP dostupné dva profily, přímé připojení a připojení přes odchozí proxy server. Pro tyto je pak nutno v konfigu- 7. SJ Labs, http://www.sjphone.org/ 8. XMPP, http://www.xmpp.org/ 12

3. PŘEHLED KLIENTŮ račním souboru zadat hodnoty. SJphone na své hlavní obrazovce ukazuje, jaký typ NATu detekoval a v menu je pro SIPový profil přímého připojení možnost nastavení použití STUN serveru. Tabulka 3.3: SJphone Windows Linux Verze 1.65.377a 1.60.299 Rychlost prvního startu 5,8 s 3,1 s Využití CPU během hovoru 1 % 1 % Využití operační paměti během hovoru 30 260 kb 3650 kb Využití CPU mimo hovor 0 % 0 % Využití operační paměti mimo hovor 30 100 kb 3510 kb Způsoby překonávání NATu Odchozí proxy server STUN server 3.5 Linphone Linphone 9 je projekt s otevřeným zdrojovým kódem, který je volně šiřitelný pod licencí GNU/GPL. Podporuje signalizaci pouze nad protokolem SIP. Linphone je ke stažení pro platformy Windows a Linux. U verze určené pro Windows je poznámka, že se jedná o nestabilní větev. Pro platformu Windows je aktuálně dostupná verze 0.5.1 a je ke stažení ve formě instalátoru. Pro Linux jsou dostupné instalační balíčky s verzí 2.1.1. Je také možno stáhnout zdrojové kódy a provést kompilaci VoIP klientu Linphone na svém počítači. Instalace na obou platformách probíhá naprosto bez potíží. Linphone při prvním spuštění nenabízí žádného průvodce nastavením. Paradoxně, i když má oproti všem ostatním porovnávaným VoIP klientům Linphone nejméně konfiguračních položek, umožňuje nastavit nejvíce relevantních parametrů. Samozřejmostí je možnost nastavení registračních údajů zasílaných na registrar server, nastavení zvukových zařízení a zvukových kodeků, které se mají používat. Co je ale důležitější, Linphone umožňuje v menu vybrat, jaká verze IP protokolu se má používat, jaké porty má používat pro přenos SIPových zpráv, audia a videa a jakou veřejnou IP adresu má uživatelův router. Po 9. Linphone, http://www.linphone.org/index.php/eng/ 13

3. PŘEHLED KLIENTŮ zadání těchto údajů je již nastavení firewallu a domácího routeru zcela jednoduché. A samozřejmě je tu stále možnost využít služeb STUN serveru. Bohužel jsem během testování zjistil, proč je Linphone pro Windows označen jako nestabilní. SIPová signalizace na začátku hovoru proběhla korektně, ale jakmile mělo dojít k navázání RTP spojení, Linphone provedl neplatnou operaci a předčasně se ukončil. Nebyl jsem schopen zjistit, zda je problém v RTP spojení či až v ovládání zvuku. Výsledkem bohužel je, že Linphone je na Windows aktuálně nepoužitelný. Je to velká škoda, protože na Linuxu je tento klient prakticky nejlepší z testovaných. Tabulka 3.4: Linphone Windows Linux Verze 0.5.1 2.1.1 Rychlost prvního startu 3,2 s 2,7 s Využití CPU během hovoru neměřeno 1 % Využití operační paměti během hovoru neměřeno 8 140 kb Využití CPU mimo hovor neměřeno 0 % Využití operační paměti mimo hovor neměřeno 8110 kb Způsoby překonávání NATu Odchozí proxy server STUN server Přímé nastavení veřejné IP adresy 3.6 WengoPhone VoIP klient WengoPhone 10, občas také nazývaný OpenWengo, má otevřený zdrojový kód a je volně šiřitelný pod GNU/GPL licencí. Podporuje signalizaci pouze nad protokolem SIP. Je dostupný pro platformy Windows, Linux a Mac. Navíc je možné WengoPhone stáhnout a používat i jako rozšíření do prohlížeče webových stránek Firefox 11. WengoPhone je dostupný pro Windows ve formě instalátoru, pro Linux je pak dostupný binární instalační balíček. V obou případech se aktuálně jedná o verzi 2.1.2. Instalace je na obou platformách bezproblémová. WengoPhone umožňuje při prvním spuštění zadat registrační údaje, registrar server a odchozí proxy server, případně vytvořit nový SIPový účet 10. WengoPhone, http://www.openwengo.org/ 11. Firefox, http://www.mozilla-europe.org/cs/products/firefox/ 14

3. PŘEHLED KLIENTŮ u wengo.com. Bohužel, tím prakticky možnosti konfigurace sítě a SIPu končí. WengoPhone v případě použítí účtu u wengo.com používá pro překonání NATu proprietární řešení na bázi HTTP tunelu. Pokud je použit účet u jiného poskytovatele, nezbývá nic jiného, než se spolehnout na služby odchozího proxy serveru, který musí být v lokální síti. Vzniká tak podobná situace jako u VoIP klientu X-Lite. V nastavení zvuku je možno vybrat používaná zvuková zařízení a upravit prioritu zvukových kodeků. Kodeky bohužel nelze z výběru přímo odebrat. Ostatní nastavení už nejsou pro VoIP důležitá. Tabulka 3.5: WengoPhone Windows Linux Verze 2.1.2 2.1.2 Rychlost prvního startu 3,2 s 3,8 s Využití CPU během hovoru 1 2 % 2 5 % Využití operační paměti během hovoru 38 110 kb 19 210 kb Využití CPU mimo hovor 0 % 0 % Využití operační paměti mimo hovor 38 060 kb 18 920 kb Způsoby překonávání NATu Odchozí proxy server Vlastní proprietární řešení 3.7 SIP Communicator Posledním porovnávaným VoIP klientem je SIP Communicator 12. Jedná se o klient s otevřeným zdrojovým kódem, šířeným pod licencí GNU/GPL. Zvláštností tohoto klientu oproti ostatním testovaným je, že je napsaný v jazyce Java. Tím je zajištěna jeho funkčnost na obou testovaných platformách. SIP Communicator využívá signalizaci nad protokolem SIP. Krom toho ovšem implementuje i mnoho protokolů pro zasílání textových zpráv, jako jsou XMPP, AIM/ICQ, MSN, RSS a některé další. Ke stažení je SIP Communicator dostupný s instalátorem pro Windows, jako instalační balíčky pro Linux, s instalátorem napsaným v Javě, či jako zdrojové kódy. Instalace probíhá na obou platformách bez potíží. I přesto, že je SIP Communicator rozsáhlý projekt, má překvapivě málo konfiguračních položek. Prakticky jediné, co lze nastavit, jsou registrační údaje, adresa a port registrar serveru, adresa a port proxy server a způsob 12. SIP Communicator, http://www.sip-communicator.org/ 15

3. PŘEHLED KLIENTŮ udržování spojení. I tento VoIP klient tedy uživatele odsuzuje v případě potřeby překonat NAT k nutnosti použití odchozího proxy serveru. Žádná možnost nastavení zvukových zařízení ani kodeků se zde taktéž nenalézá. Tabulka 3.6: SIP Communicator Windows Linux Verze 1.0-alpha3 1.0-alpha3 Rychlost prvního startu 26 s 20,4 s Využití CPU během hovoru 1 3 % 1 % Využití operační paměti během hovoru 57 660 kb 47 590 kb Využití CPU mimo hovor 0 % 0 % Využití operační paměti mimo hovor 57 610 kb 47 520 kb Způsoby překonávání NATu Odchozí proxy server 3.8 Závěrečné zhodnocení porovnávaných VoIP klientů Dříve, než začnu hodnotit výsledky porovnávání výše uvedených VoIP klientů, chtěl bych shrnout jejich další vlastnosti, které jsem během testování zjistil a které jim jsou společné. U všech porovnávaných VoIP klientů jsem za pomocí ústředny Asterisk zkoumal, zda zasílají korektní SIPové zprávy. Byl jsem mile překvapen a mohu konstatovat, že všechny porovnávané VoIP klienty skutečně neporušují standardy definované v RFC 3261[5]. Dále mohu konstatovat, že všechny porovnávané VoIP klienty uspěly v testu, kdy jsem je nechal hodinu volat na linku, u které bylo nastaveno echo 13, a kdy jsem do vstupu pro mikrofon u daného počítače posílal hudbu a poslouchal výstup. Ani jeden z klientů ve stanoveném časovém úseku nezhavaroval. Tímto by byly společné vlastnosti všech porovnávaných VoIP klientů vyčerpány. Pokud bych se měl zaměřit na výběr kritérií, podle kterých VoIP klienty srovnávat, tak při pohledu na předchozí odstavce a tabulky docházím k závěru, že by to měla být ta následující, uvedená v pořadí podle důležitosti: Nároky na systémové prostředky Měly by být co nejnižší. Schopnost překonávat NAT Alespoň do doby, než se začne masově používat IPv6, je tato vlastnost pro úspěšný VoIP klient nutností. 13. Echo automatické zpětné zasílání zvuků 16

3. PŘEHLED KLIENTŮ Podpora kvalitních zvukových kodeků V době, kdy je širokopásmové připojení již dostatečně rozšířeno, není třeba srážet kvalitu telefonování přes Internet nekvalitním přenosem zvuku. Jednoduché ovládání Uživateli stačí, když nastaví údaje od poskytovatele SIP účtu a může telefonovat, určitě nechce trávit zbytečný čas dalším nastavováním a hledáním položek. Vše potřebné by mělo být viditelné či rychle přistupné. Tato kriteria na platformě Linux zdaleka nejlépe reflektuje VoIP klient Linphone. Díky vyšším nárokům na systémové prostředky končí Ekiga až za Linphonem, na třetí místo bych pak zařadil SJphone, kterému snižuje hodnocení hlavně méně možností řešení průchodu skrz NAT. Další pořadí klientů nestanovuji. Na platformě Windows je situace daleko vyrovnanější. Moji největší přízeň si získala Ekiga, především pro svou přehlednost a dostatek možností, jak procházet NATem. Za ní se pak svorně umístily X-Lite a SJphone. Zvláštní pozornost si i přes svou pamět ovou náročnost zasluhuje SIP Communicator. Díky použití programovacího jazyka Java není zavislý na platformě a opravdu jak na Windows tak na Linuxu funguje a vypadá shodně, což je vlastnost, kterou žádný jiný porovnávaný VoIP klient zcela nesplňoval. 17

Kapitola 4 Návrh a vývoj vlastního VoIP klientu 4.1 Návrh klientu Praktická část této práce spočívala ve vytvoření vlastního jednoduchého VoIP klientu. I můj VoIP klient, jako každý program, musel nejprve projít fází návrhu. Protože se nejedná o rozsáhlý projekt, rozhodl jsem se nepoužívat žádné sofistikované metody návrhu systémů a nekreslit DFD diagramy 1. Místo toho jsem si rozepsal, jaké části by můj VoIP klient měl obsahovat a co by každá z nich měla dělat. Základním prvkem každého programu, se kterým je možno interaktivně pracovat, je grafické uživatelské rozhraní (GUI 2 ). Třída GUI bude tedy vykreslovat všechny ovládací prvky VoIP klientu, bude reagovat na akce provedené uživatelem, a bude jej informovat o příchozích zprávách z ostatních tříd. Dále bude klient obsahovat třídu pro interakci s protokolem SIP, tedy vytváření, zasílání, přijímání a čtení SIPových zpráv. Tato třída bude předávat GUI všechny důležité informace o příchozích SIPových zprávách a zároveň bude od GUI dostávat povely k odeslání SIPových zpráv. Další třída se bude starat o získávání, paketizaci a odesílání audio dat a v opačném směru pak o příjem, depaketizaci a reprezentaci příchozích audio dat. Této třídě budou z GUI zasílány informace o tom, že má začít audio data zasílat na specifikovanou adresu, na jakém portu má naslouchat příchozím audio datům a že má ukončit vysílání a příjem audio dat. Klient sám o sobě nebude obsahovat žádnou možnost konfigurace v GUI. Aby bylo možno ovlivnit parametry, jako je zobrazované jméno, nebo zda se má pokusit připojit k registrar serveru, bude při startu VoIP klient pomocí další třídy číst XML soubor, ve kterém budou uloženy konfigurační údaje. 1. DFD diagramy, http://en.wikipedia.org/wiki/data_flow_diagram 2. GUI, Graphical User Interface 18

4.2 Použité technologie 4. NÁVRH A VÝVOJ VLASTNÍHO VOIP KLIENTU V zadání mé bakalářské práce stojí, že pro vytvoření mého VoIP klientu mám použít knihovny projektu Ekiga, tedy VoIP klienta napsat v jazyce C++. Během testování VoIP klientů v předchozí kapitole jsem však došel k názoru, že daleko lepším řešením bude použít jazyk Java[9] a vytvořit tak VoIP klient, který nebude závislý na platformě, kde poběží. Další otázkou bylo, zda si napsat kompletně vlastní třídy pro použití protokolu SIP a RTP, nebo využít již hotových tříd. Vzhledem k zadání padla nakonec volba na využití tříd již vytvořených. Jako SIP stack je využit projekt Jain-Sip 3 verze 1.2. Jako RTP stack pak slouží projekt Java Media Framework 4 ve verzi 2.1.1e. Jedinou nevýhodou použití JMF je, že uživatel musí mít tento projekt předem korektně nainstalovaný a nastavený, což ale na druhou stranu není nijak složité. 4.3 Popis použití Můj VoIP klient je distribuován jako archiv ve formátu ZIP. Po rozbalení kompletního obsahu do uživatelem zadaného adresáře, by tento měl obsahovat následující položky: Adresář lib, ve kterém se nacházejí knihovny potřebné pro běh mého VoIP klientu. Soubor voip.172871.fi.muni.cz.jar, který reprezentuje můj VoIP klient. Soubor settings.xml, do kterého jsou ukládána nastavení. Dávkové soubory win32.bat a linux.sh, určené pro spouštění mého VoIP klientu. Před prvním spuštěním je třeba provést úpravu souboru settings.xml a nastavit v něm správné hodnoty. Pro úpravu postačí běžný textový editor, jedinou podmínkou je, aby uměl číst a ukládat v kódování UTF-8. Pro běžné použití je třeba nastavit hodnotu značky registrar, kam se zapisuje adresa a port registrar serveru, který má být použit. V případě, že se nemá registrar server používat, stačí nechat 3. Jain-Sip, https://jain-sip.dev.java.net/ 4. Java Media Framework, http://java.sun.com/javase/technologies/desktop/media/jmf/ 19

4. NÁVRH A VÝVOJ VLASTNÍHO VOIP KLIENTU nastavenu hodnotu none. Jako hodnoty značek username a showname je třeba zadat přihlašovací jméno, které se zašle registrar serveru, respektive jméno, které se bude zobrazovat volaným. Nyní je můj VoIP klient připraven ke spuštění. Na platformě Windows se ke spouštění používá dávkový soubor win32.bat, na Linuxu pak dávkový soubor linux.sh. Pokud není v konfiguračním souboru v poli registrar nastavena hodnota none, pak můj VoIP klient zašle na specifikovanou adresu požadavek REGISTER s přihlašovacím a zobrazovaným jménem odpovídajícím konfiguračnímu souboru. Jakmile na tento požadavek přijde odpověd 200 OK, přepne se VoIP klient do stavu Registered. Ve stavu Registered VoIP klient, v případě zadání adresy volaného bez zavináče, automaticky za zadanou adresu doplní zavináč a adresu registrar serveru. Pokud je z jakéhokoliv důvod nutno VoIP klient přepnout do neregistrovaného stavu, stačí stisknout tlačítko Unregister. Taktéž je po uplynutí hodiny od posledního zaslání požadavku REGISTER třeba VoIP klient přepnout ze stavu registrované do neregistrovaného a zpět. Pro volání stačí zadat adresu volaného a stisknout tlačítko Call. Zavěsit pak může uživatel kdykoliv stiknutím tlačítka Hang up. V případě příchozího hovoru VoIP klient automaticky umožní stisk tlačítek Accept a Reject pro přijetí respektive odmítnutí hovoru. Můj VoIP klient posílá zvuková data ve formátu PCMU, tedy formátu, který podporují všechny VoIP klienty. Použití PCMU je zároveň zárukou dostatečné kvality zvuku. Můj VoIP klient nepoužívá žádnou přímou možnost přechodu přes NAT, pouze je možno specifikovat odchozí proxy server, který má používat. Tato položka však nebyla nikdy testována, a proto ji nedoporučuji zatím používat. 20

4. NÁVRH A VÝVOJ VLASTNÍHO VOIP KLIENTU Tabulka 4.1: Můj VoIP klient Windows Linux Verze 1.0 1.0 Rychlost prvního startu 12 s 10,7 s Využití CPU během hovoru 1 2 % 1 % Využití operační paměti během hovoru 29 120 kb 22 960 kb Využití CPU mimo hovor 0 % 0 % Využití operační paměti mimo hovor 27 930 kb 22 720 kb Způsoby překonávání NATu Experimentálně odchozí proxy server 21

Kapitola 5 Závěr Výsledky části práce, ve které jsem se zabýval porovnáním VoIP klientů, jasně ukazují, že je dostupné dostatečné množství kvalitních VoIP klientů pro různé platformy. Každý z těchto klientů je určen pro mírně odlišný typ uživatele a je tedy zaručeno, že hlasová komunikace přes Internet bude i nadále nabývat na oblibě. V praktické části práce se mi podařilo napsat VoIP klienta, kterého je možné volně přenášet mezi různými operačními systémy a beze změn ve funkčnosti ho na nich používat. Tento jednoduchý VoIP klient reflektuje většinu kriterií pro hodnocení VoIP klientů, jak jsou popsáná v závěru kapitoly tři této práce. V budoucnu pravděpodobně dojde k přesunu od běžného telefonování po Internetu k videohovorům. Již dnes většina VoIP klientů tuto možnost podporuje, ale přenosu kvalitního videa dnes většinou brání nedostatečná kapacita přenosových linek. 22

Literatura [1] H.323 - Wikipedia, the free encyclopedia. [online], citováno 27. 4. 2008. Dostupné na WWW: http://en.wikipedia.org/wiki/h.323. [2] Session Initiation Protocol - Wikipedia, the free encyclopedia. [online], citováno 27. 4. 2008. Dostupné na WWW: http://en.wikipedia. org/wiki/session_initiation_protocol. [3] Session Description Protocol - Wikipedia, the free encyclopedia. [online], citováno 27. 4. 2008. Dostupné na WWW: http://en. wikipedia.org/wiki/session_description_protocol. [4] Real-time Transport Protocol - Wikipedia, the free encyclopedia. [online], citováno 27. 4. 2008. Dostupné na WWW: http://en. wikipedia.org/wiki/real-time_transport_protocol. [5] SIP: Session Initiation Protocol. [online], citováno 27. 4. 2008. Dostupné na WWW: http://www.ietf.org/rfc/rfc3261.txt. [6] RTP: A Transport Protocol for Real-Time Applications. [online], citováno 27. 4. 2008. Dostupné na WWW: http://www.ietf.org/rfc/ rfc3550.txt. [7] Real-time Transport Control Protocol - Wikipedia, the free encyclopedia. [online], citováno 27. 4. 2008. Dostupné na WWW: http: //en.wikipedia.org/wiki/real_time_control_protocol. [8] LIŠKA Miloš. Skripta k předmětu PV188 Principy zpracování a přenosu multimédií. [online], citováno 29. 4. 2008. Dostupné na WWW: https://is.muni.cz/auth/el/1433/podzim2007/ PV188/um/slides-zpracovani_audia_a_videa.pdf. [9] JavaTM 2 Platform Standard Edition 5.0 API Specification. [online], citováno 29. 4. 2008. Dostupné na WWW: http://java.sun.com/ j2se/1.5.0/docs/api/. 23

Dodatek A Příloha A Součástí práce je přiložené CD, které obsahuje: zdrojový kód práce ve formátu L A TEX elektronickou verzi práce ve formátu PDF zdrojový kód VoIP klientu vzniklého v rámci práce dokumentaci zdrojového kódu VoIP klientu, vzniklého v rámci práce, ve formátu Javadoc archiv s binární distribucí VoIP klientu, vzniklého v rámci práce, ve formátu ZIP archiv obsahuje: binární distribuci VoIP klientu, vzniklého v rámci této práce ve formátu JAR knihovny potřebné pro běh VoIP klientu, vzniklého v rámci této práce v adresáři lib XML soubor settings.xml, obsahující nastavení VoIP klientu dávkový soubor win32.bat pro spouštění VoIP klientu v prostředí Microsoft Windows dávkový soubor linux.sh pro spouštění VoIP klientu v prostředí GNU/Linux 24

Dodatek B Příloha B Textová příloha obsahuje: Tabulka celkového srovnání porovnávaných VoIP klietů pro platformu Windows Tabulka celkového srovnání porovnávaných VoIP klietů pro platformu Linux 25

B. PŘÍLOHA B Tabulka B.1: Celkové srovnání klientů pro platformu Windows Windows Ekiga X-Lite SJphone Verze 2.0.11 3.0 1.65.377a Rychlost prvního startu 12 s 4,5 s 5,8 s Využití CPU během hovoru 3 5 % 1 % 1 % Využití operační paměti během hovoru 21 860 kb 34 160 kb 30 260 kb Využití CPU mimo hovor 0 % 0 % 0 % Využití operační paměti mimo hovor 21 210 kb 34 130 kb 30 100 kb Způsoby překonávání NATu Odchozí proxy server Odchozí proxy server Odchozí proxy server STUN server STUN server Přímé nastavení veřejné IP adresy Windows Linphone WengoPhone SIP Communicator Verze 0.5.1 2.1.2 1.0-alpha3 Rychlost prvního startu 3,2 s 3,2 s 26 s Využití CPU během hovoru neměřeno 1 2 % 1 3% Využití operační paměti během hovoru neměřeno 38 110 kb 57 660 kb Využití CPU mimo hovor neměřeno 0 % 0 % Využití operační paměti mimo hovor neměřeno 38 060 kb 57 610 kb Způsoby překonávání NATu Odchozí proxy server Odchozí proxy server Odchozí proxy server STUN server Vlastní Přímé nastavení proprietární veřejné IP adresy řešení 26

B. PŘÍLOHA B Tabulka B.2: Celkové srovnání klientů pro platformu Linux Windows Ekiga X-Lite SJphone Verze 2.0.12 3.0 1.60.299 Rychlost prvního startu 3,2 s 2,3 s 3,1 s Využití CPU během hovoru 8 9 % 1 % 1 % Využití operační paměti během hovoru 10 700 kb 14 110 kb 3 650 kb Využití CPU mimo hovor 0 % 0 % 0 % Využití operační paměti mimo hovor 10 600 kb 13 700 kb 3 510 kb Způsoby překonávání NATu Odchozí proxy server Odchozí proxy server Odchozí proxy server STUN server STUN server Přímé nastavení veřejné IP adresy Windows Linphone WengoPhone SIP Communicator Verze 2.1.1 2.1.2 1.0-alpha3 Rychlost prvního startu 2,7 s 3,8 s 20,4 s Využití CPU během hovoru 1 % 2 5 % 1 % Využití operační paměti během hovoru 8 140 kb 19 210 kb 47 590 kb Využití CPU mimo hovor 0 % 0 % 0 % Využití operační paměti mimo hovor 8 110 kb 18 920 kb 47 520 kb Způsoby překonávání NATu Odchozí proxy server Odchozí proxy server Odchozí proxy server STUN server Vlastní Přímé nastavení proprietární veřejné IP adresy řešení 27