BAKALÁRSKA PRÁCA. Ľuboš Magic Telefón do embedded systému

Transcription

1 Univerzita Karlova v Prahe Matematicko-fyzikálna fakulta BAKALÁRSKA PRÁCA Ľuboš Magic Telefón do embedded systému Ústav formálnej a aplikovanej lingvistiky Vedúci bakalárskej práce: Mgr. David Kolovratník Štúdijný program: Informatika, Správa počítačových systémov 2009

2 Ďakujem Mgr. Davidovi Kolovratníkovi za poskytnuté konzultácie k danej téme. Prehlasujem, že som svoju bakalársku prácu napísal samostatne a výhradne s použitím citovaných prameňov. Súhlasím s požičiavaním práce a jej zverejňovaním. V Prahe dňa 5. augusta 2009 Ľuboš Magic 2

3 Obsah 1 Úvod Internetovételefonovanie Históriainternetovéhotelefonovania Súčasnýstavaanalýzaproblému Postuppráce Popis použitých protokolov SDP SessionDescriptionProtocol RTP Real-timeTransportProtocol SIP SessionInitiationProtocol Možnosti embedded zariadení Oembeddedzariadeniach Dostupnývýkon Používanéoperačnésystémy Nárokyexistujúcichsoftwareovýchtelefónov Twinkle Ekiga Linphone Požiadavkymojejimplementácie Potrebnýdiskovýpriestor Zhodnotenie Kompatibilita Možnosti NajznámejšieimplementácieSIPservera Kompatibilitasinýmitelefónmi Zhodnotenie

4 5 Ovládanie telefónu Užívateľskérozhraniaembeddedzariadení Mojaimplementáciaovládania Zhodnotenie Možné vylepšenia implementácie Funkčnévylepšenia Rozširujúcevylepšenia Praktická skúsenosť s implementáciou v embedded systéme Zariadenie Použitieimplementácienazariadení Zhodnotenie Záver 37 Literatúra 39 A Obsah priloženého CD 42 B Užívateľská príručka 43 B.1 Prerekvizity B.2 Predpokladyúspešnejkompilácie B.3 Predprvýmspustením B.4 Spustenieaovládanieprogramu

5 Zoznam obrázkov 2.1 HlavičkaRTPprotokolu[7] PríkladpoužitiaprotokoluSIP TestovanieprogramuTwinkle TestovanieprogramuEkiga TestovanieprogramuLinphone Testovaniemojejimplementácie ZariadenieVIAEpiaMini-ITX

6 Názov práce: Telefón do embedded systému Autor: Ľuboš Magic Katedra(ústav): Ústav formálnej a aplikovanej lingvistiky Vedúci bakalárskej práce: Mgr. David Kolovratník vedúceho: David.Kolovratnik@mff.cuni.cz Abstrakt: Cieľom tejto práce je vytvoriť program na telefonovanie po IP sieťach s podporou protokolu SIP. Program sa orientuje na nízku spotrebu systémových prostriedkov vzhľadom k využitiu v embedded systéme. Práca informuje o princípoch použitých aplikačných protokolov SIP, SDP a RTP. Súčasťou práce je aj zhodnotenie výsledneho programu z hľadiska kompatibility s inými implementáciami, nárokmi programu na systémové prostriedky a možnosťami variabilného ovládania programu. Záver práce popisuje možné vylepšenia a rozšírenia programu a opisuje skúsenosti s využitím programu vo vhodne zvolenom zariadení. Kľúčové slová: telefón, VoIP, SIP, embedded Title: VoIP for an embedded system Author: Ľuboš Magic Department: Institute of Formal and Applied Linguistics Supervisor: Mgr. David Kolovratník Supervisor s address: David.Kolovratnik@mff.cuni.cz Abstract:Theaimofthisworkistocreateanapplicationusedtointernet telephony over the IP networks with support of the SIP application protocol. The application is focused on low system requirements, therefore it could be used in the embedded system. This document informs about the most significant principles of used application protocols, such as SIP, SDP and RTP. Animportantpartoftheworkisaconclusionofthefinalapplication.Itconsists of the discussion about the compatibility with others implementations, system requirements and the possibilities of variable controls extension. The end of this work is dedicated to possible improvements, discussion about the future development and informations about usability of the implementation in a real embedded system. Keywords: softphone, VoIP, SIP, embedded 6

7 Kapitola 1 Úvod 1.1 Internetové telefonovanie Internetovételefonovanie,alebotiežVoIP 1 jepojemzastrešujúcitechnológie používané na prenos hlasu pomocou IP sietí na základe prepájania paketov. Jedným zo základných krokov umožňujúcich prenos hlasu pomocou IP sietí, napríklad internetu, je prevod analógového signálu, v ktorom sa získava hlas, do digitálnej podoby. Hlas v digitálnej podobe musí byť následne obalený IP hlavičkou, aby mohol byť prenesený po sieti. Takto prenesený hlas musí na druhom konci prejsť rovnakým procesom, avšak v opačnom poradí. Technológie zastrešujúce internetové telefonovanie obsahujú aj rôzne hlasové kódeky, ktoré umožňujú zmenšiť objem dát prenášaných po sieti a rôzne štandardy definujúce nadväzovanie a ukončovanie hovorov. Existujú mnohé ucelené riešenia dannej problematiky na základe rôznych prístupov a za použitia rôznych technológií. Dôvodov, prečo majú technológie okolo VoIP úspech je niekoľko. Medzi najdôležitejšie sa radí možnosť prenášať hlas súčasne s inými dátami, takže nie je potrebná ďaľšia telefonická sieť, čo implikuje aj finančné úspory. VoIP týmto získava väčšiu pridanú hodnotu za nižšiu cenu, ako klasické telefónne linky a hovory, keďže je možné popri klasickom telefónnom hovore viesť aj videohovor, alebo uskutočňovať konferenčné hovory s viacerými užívateľmi naraz. 1 VoiceoverInternetProtocol 7

8 1.2 História internetového telefonovania Najdôležitejšie udalosti, ktoré ovplyvnili vývoj internetového telefonovania [1]: 1995 malá súkromná spoločnosť VocalTec predstavuje prvý internetový telefón 1996 ITU T 2 začínaprocesštandardizácievoippomocouh.323 štandardu 1996 žiadosť telekomunikačných spoločností požadujúca zákaz používania internetového telefonovania adresovaná Kongresu Spojených štátov amerických 1999 špecifikáciaprotokolusip prváopensource 4 implementáciasippobočkovejústredne Asterisk 2003 betaverziaprogramuskype 2005 začiatok používania video prenosov spoločne s prenosom hlasu 2008 viac ako 400 miliónov Skype užívateľských účtov 1.3 Súčasný stav a analýza problému Rozvoj internetového telefonovania napreduje súčasne s rozšírením širokopásmového internetu. V roku 2006 existovalo v Českej republike viac ako 20 poskytovateľov VoIP služieb a ich počet stále rastie[2]. Zo služby, ktorá bola pôvodne určená na rozhovory medzi priateľmi sa postupne stáva služba, o ktorej sa uvažuje ako o nástupcovi klasickej verejnej telefónnej siete, čo z nej robí zaujímavú oblasť podnikania. VoIP operátory umožňujú prepojiť hovory na klasické pevné linky, ako aj do mobilných sietí. Takto uskutočnené hovory sú z pravidla lacnejšie ako u konkurencie v podobe klasickej telefónnej siete. Hovory, ktoré ostávajú v sieti VoIP operátora sú vo väčšine 2 InternationalTelecommunicationUnion TelecommunicationStandardizationSector 3 SessionInitiationProtocol RFC otvorenýzdrojovýkód 8

9 prípadov zadarmo. Existujú 3 základné možnosti pripojenia sa do siete VoIP operátorov: Analógový telefónny adaptér umožňuje prepojenie existujúcej klasickej telefónnej prípojky s IP sieťou VoIP operátora. Najjednoduchšie adaptéry ponúkajú možnosť prepojiť jeden analógový telefón ukončený koncovkou RJ-11 s počítačom pomocou USB konektoru. Ďaľšie spracovanie prebieha pomocou programového vybavenia počítača, ktorý je pripojený do IP siete. Zložitejšie adaptéry ponúkajú priamo ethernetový port s koncovkou RJ-45 na pripojenie do internetu a niekoľko RJ-11 portov na pripojenie analógových telefónov. Tieto adaptéry dokážu digitalizovať hlas, použiť potrebný kódek a komunikačný protokol a pripájajú sa priamo na poskytovateľa VoIP služieb[3]. Takéto pripojenie je pre koncového užívateľa takmer nerozoznateľné od klasickej telefónnej siete. VoIP telefón hardwareový telefón, ktorý sa pripája priamo do IP siete bez nutnosti použitia počítača. Takýto telefón sa môže s verejnou telefónnou sieťou prepojiť pomocou VoIP operátora, alebo pomocou použitia vlastnej pobočkovej ústredne. Softwareový telefón program, ktorý sa pomocou počítača pripojí do siete a umožňuje telefonovanie bez použitia ďaľšieho hardware. Zameriame sa na softwareové telefóny. Uskutočniť telefónny hovor priamo medzi dvomi softwareovými telefónmi je možné v prípade, ak tieto dva telefóny používajú rovnaký komunikačný protokol a majú aspoň jeden spoločný audio kódek. Medzi hlavné používané komunikačné protokoly patria: H.323 štandard ITU T zastrešujúci protokoly pre audio-vizuálne prenosy v akejkoľvek paketovej sieti. V súčasnosti sa od jeho využívania prechádza k použitiu protokolu SIP. Hlavný zástupcovia softwareových telefónov používajúcich tento štandard sú telefóny NetMeeting alebo Ekiga. SIP protokoldefinovanýskupinouietf 5 vrfc2543,neskôrvrfc Podrobnejšiemu popisu sa venujem v nasledujúcich kapitolách. 5 InternetEngineeringTaskForce 9

10 Tento protokol je implementovaný vo veľkom množstve internetových telefónov, napríklad v telefóne Twinkle, či telefóne QuteCom. XMPP 6 protokolzaloženýnaxml,bolpôvodnevyvinutýprepotreby Instant Messagingu a zobrazovania informácií o aktuálnej dostupnosti užívateľov, avšak neskôr bol rozšírený o možnosť podpory VoIP. Hlavným zástupcom telefónov používajúcich tento protokol je GoogleTalk. IAX 7 protokolvyvinutýšpeciálneprenajrozšírenejšítyppobočkovej ústredne Asterisk s dôrazom na minimalizáciu prenášaných dát. proprietátne protokoly uzavreté protokoly s neznámou implementáciou. Najznámejším zástupcom z tejto skupiny je Skype. Účelom použitia audio kódekov je zmenšiť množstvo prenesených dát po sieti. Slovo kódek vzniklo spojením slov kódovanie a dekódovanie, čo prezrádza spôsob, akým sa docieľuje redukcia. Zvuk sa na jednej strane spojenia zakóduje, zmenšený objem dát sa prenesie po sieti a na druhej strane spojenia sa tieto dáta použitím rovnakého kódeku dekódujú. Každý kódek implementuje kódovanie a dekódovanie vlastným algoritmom, pričom tento algoritmus sa môže špecializovať na rôzne oblasti, ako napríklad nízka spotreba systémových prostriedkov, zachovanie čo najvyššej kvality zvuku alebo minimalizácia objemu dát. Medzi najviac používané kódeky by sme mohli zaradiť: G.711 jeden z najpoužívanejších kódekov v telekomunikáciách. Vznikol v roku 1972 ako štandard ITU-T. Svojou jednoduchosťou je šetrný k systémovým prostriedkom, avšak za cenu nižšej efektivity kódovania. Vzorkovacia frekvencia je 8 khz a pri kódovaní sa využíva logaritmická kompresia14alebo13na8bitov,zčohovyplýva64kbpsprenosdát [4]. Existujú dve jemne odlišné varianty tohoto kódeku: A-law variantapoužívanáveurópeaaustrálii,kdesana prenos hlasu využíva všetkých 8 bitov a na signalizáciu je použitý samostnatný kanál. 6 ExtensibleMessagingandPresenceProtocol 7 Inter-AsteriskeXchange 10

11 µ-law varianta používaná v severnej Amerike a Japonsku, kde je použitá vyššia kompresia, pretože v telefónnych sieťach v týchto krajinách je na prenos hlasu vyhradených iba 7 bitov, pričom 8. bit sa používa na signalizáciu. G.726 štandard ITU-T nahradzujúci staršie G.721 a G.723. Kódek podporujeprenosdátpomocou16,24,32a40kbps. GSM efektívna vysoká kompresia, ktorá nie je náročná na systémové prostriedky a potrebuje šírku pásma iba 13 kbps. Tento kódek používa algoritmusoznačovanýakogsm06.10rpe-ltp 8. Speex jedinýzvyššieuvedenýchkódekov,ktorýjeúplnevoľnedostupný a nie je zaťažený žiadnym patentom. Dokáže detekovať hlasovú aktivitu, čo využíva na zníženie objemu prenášaných dát použitím variabilnej šírky pásma. 1.4 Postup práce Program na telefonovanie po IP sieťach bude implementovaný na operačnom systéme Linux, pomocou programovacieho jazyka C/C++. Pri implementácii programu budem postupovať podľa nasledujúceho plánu: získanie hlasu v digitálnej podobe k splneniu využijem knižnicu ALSA 9,ktorámiumožnípomocouPCM 10 skonvertovaťhlaszanalógovej podoby komprimácia hlasu v digitálnej podobe budem používať zvukový kódek GSM 6.10 prenos skomprimovaného hlasu po sieti prenos dát bude prebiehať pomocouprotokolurtp 11 zaistenie zahájenia a ukončenia hovoru použijem protokol SIP oddelenie ovládania od jadra programu užívateľské rozhranie bude konzola komunikujúca s jadrom pomocou soketov 8 Regular-PulseExcitationLong-TermPredictor 9 AdvancedLinuxSoundArchitecture 10 Pulse-codemodulation 11 Real-timeTransportProtocol 11

12 Kapitola 2 Popis použitých protokolov 2.1 SDP Session Description Protocol ProtokolsavTCP/IPmodelenachádzanaaplikačnejvrstveaslúžikpopisu vlastností spojenia učastníkov za účelom multimediálneho prenosu dát. Pomocou tohoto protokolu sa neprenášajú multimediálne dáta samotné, prenášajú sa iba parametre spojenia. Súbor parametrov spojenia sa nazýva relačný profil. Možnosti relačného profilu sú navrhnuté tak, aby bolo možné jednoduché pridávanie nových parametrov spojenia. Tento protokol je vo veľkej miere využívaný súčasne s protokolom SIP, kde použitie protokolu SDP oznámime pomocou hlavičky Content-Type: application/sdp. Protokol SDP je textový a pozostáva z riadkov v tvare type=value, pričom niektoré riadky sú povinné, iné sú voliteľné. Popis jednotlivých riadkov, pričom voliteľné su označené*[5]: Popis spojenia v= (verzia protokolu) o= (iniciátor spojenia a identifikátor relácie) s= (názov spojenia) i=* (informácie o spojení) u=* URI popisu) e=* ( ová adresa) p=* (telefónne číslo) c=* (informácie o pripojení) b=* (informácie o šírke pásma) Jedna, alebo viac časových informácií 12

13 z=* (nastavenie časového pásma) k=* (kryptovací kľúč) a=* (žiadne, alebo niekoľko ďaľších parametrov spojenia) Nula, alebo viac informácií o multimediálnom prenose Časové informácie t= (čas, kedy je spojenie aktívne) r=* (nula alebo viac opakovacích časov) Popis multimediálneho prenosu, ak je prítomný m= (typ multimediálneho prenosu a transportná adresa) i=* (názov média) c=* (informácie o pripojení) b=* (nula, alebo viac informácií o šírke pásma) k=* (kryptovací kľúč) a=* (žiadne, alebo niekoľko ďaľších parametrov spojenia) Príklad, ako môže vyzerať reálne SDP vytvorené programom Twinkle pri zahajovaní spojenia: v=0 o=sems IN IP s=session c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:3 GSM/8000 a=rtpmap:97 speex/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: Podrobné vysvetlenie niektorých riadkov protokolu v príklade: v=0 RFC4566definujeverziuprotokolu0. o=sems IN IP sems je užívateľské meno iniciátora, nasledujú dve polia numerických identifikátorov, ktoré jednoznačne identifikujú dané spojenie, IN pole určuje typ 13

14 siete, IP4 pole určuje typ adresy a posledné pole určuje na základe predchádzajúcich dvoch polí IPv4 adresu iniciátora. t=00 značí,žezačiatočný,ajkoncovýčasje0,čímoznamuje,že v danom relačnom profile tento parameter nie je dôležitý. m=audio35820rtp/avp audiourčujetypmédia, je port, na ktorý sa posielajú dáta, RTP/AVP označuje transportný protokol, v tomto prípade konkrétne sa použije protokol RTP saudioavideoprofilomcezudp.nasledujúpolia,ktoréurčujútyp obsahu RTP protokolu. a=rtpmap:3 GSM/8000 v nádväznosti na m= riadok určuje konkrétnetypobsahurtpprotokolu,vdanomprípadetojetyp3zodpovedajúci GSM kódovaným dátam pri frekvencií 8000 Hz. Možné hodnotysúzhrnutévprotokolerfc3551[6]. VpraxipripoužitísoSIPprotokolomsaSDPzašlespolusožiadosťou o začiatok rozhovoru. Ak je na žiadosť odpovedané kladne, pripája sa k odpovedi aj SDP, ktoré reflektuje prijatú ponuku. Odosielateľ vo svojom SDP vriadkochm=aa=ponúknemožnétypyprenosuspreferenciou(najvyššie je ponuka s najvyššou preferenciou), prijímateľ následne skontroluje svoje možnosti prenosu a v odpovedi uvedie vybraný typ. 2.2 RTP Real-time Transport Protocol Protokol štandardizujúci prenos real-time audio a video dát po internete. Protokol, ktorý bol prvýkrát definovaný v RFC 1889 zahŕňa určenie užitočného zaťaženia, zaručenie správneho poradia prijatých dát, časové razítkovanie a sledovanie prenosu. Tento protokol je v modele TCP/IP na aplikačnej vrstve a jeho implementácie využívajú ako transportnú vrstvu protokol UDP. Aplikácie využívajúce protokol RTP sú charakterizované potrebou doručenia paketov v istom časovom horizonte a zároveň si môžu dovoliť výpadok niekoľkých paketov. Samotné RTP môžme rozdeliť na dve komponenty: protokol na samotný prenos dát a kontrolný protokol. Protokol na samotný prenos zabezpečuje real-time doručovanie audio alebo video dát medzi koncovými bodmi spojenia. V hlavičke definuje napríklad obsah paketov, sekvenčné poradie paketov alebo časové razítka. Je zvykom, 14

15 že tento protokol využíva párny port, ktorý je zadefinovaný napríklad protokolom SDP. Kontrolný protokol označovaný aj ako RTCP zabezpečuje sledovanie kvality prenosu. Tento protokol neprenáša žiadne audio alebo video dáta. Jeho úlohou je len poskytovať pravidelnú spätnú väzbu ohľadom niektorých aspektov prenosu, ako napríklad počet odoslaných bajtov, počet odoslaných a stratených paketov, oneskorenie, kolísanie oneskorenia a iné. Je zvykom, že RTCP protokol beží súčasne s protokolom na samotný prenos dát na najbližšom vyššom porte. Pri využití protokolu na prenos viacerých typov dát, napríklad súčasne audioavideodát,nakaždýztýchtoprenosovjepoužitýinýrtpstream 1. Jedným zo zámerov pri tvorbe tohoto protokolu bola podpora širokej škály typov prenášaných dát. RTP definuje tzv. profily a k nim prislúchajúce obsahové formáty. Ku každému profilu patrí niekoľko informácií o obsahu, ktoré popisujú špecifiká daného mediálneho formátu. Obr. 2.1: Hlavička RTP protokolu[7] Všetky dáta určené na odoslanie sa obaľujú RTP hlavičkou, aby ich bolo možné na druhej strane prenosu spracovať. Ich veľkosť je vopred známa vďaka definovanému profilu. RTP hlavička dátového prenosu, ktorej štruktúru môžete vidieť na obrázku 2.1, má veľkosť minimálne 12 bytov. Po hlavičke nasledujú voliteľné rozšírenia a samotný multimediálny obsah, ktorého formát je daný v hlavičke. Presný formát hlavičky RTP protokolu[8]: Ver. verzia protokolu, pričom aktuálna verzia je 2. P indikuje prítomnosť extra bytov nakonci RTP paketu, ktoré môžu byť užitočné napríklad pri šifrovaní. 1 prúddát 15

16 X indikuje prítomnosť rozšírenia nasledujúceho za hlavičkou. CC počet CSRC identifikátorov, ktoré nasledujú za hlavičkou s pevnou dĺžkou. M niektorédátamôžumaťšpeciálnyvýznampredanýprofil,vtom prípade sa nastaví tento bit PT uvádzatypobsahu,ktorýješpecifikovanýrtpprofilom. Sequence Number číslo, ktoré sa inkrementuje s každým zaslaným paketom. Umožňuje sledovať straty paketov. Inicializačná hodnota je kvôli bezpečnosti náhodná. Timestamp časová známka umožňuje príjemcovi prehrávať vzorky vo vhodných intervaloch. SSRC synchronization source identifikátor, ktorý jednoznačne identifikuje zdroj vysielania. CSRC contributing source identifikátory, ktoré jednoznačne určujú všetky zdroje, ktoré prispievajú do dátového toku. Ako príklad použitia viacerých CSRC môže slúžiť konferenčný hovor. 2.3 SIP Session Initiation Protocol Protokol sa používa na prenos signalizácie v multimediálnych reláciách a je inšpirovanýhttp 2.Protokoljetextový,čímsizískalveľkúobľubumedzi programátormi. Pri použití tohoto protokolu je komunikácia riadená koncovými uzlami a sieť zabezpečuje iba nutné smerovanie správ, čo je aj jedným z hlavných rozdielov od verejnej telefónnej siete, kde je hlavná logika sústredená do siete. SIP umožňuje väčšiu funkcionalitu ako verejná telefónna sieť a vzhľadom k navrhnutému vzoru inteligencie v koncových zariadeniach je aj výrazne jednoduchšie funkcionalitu zvyšovať pridávaním nových služieb. Využitie protokolu závisí od viacerých komponentov, ktoré protokol definuje: UserAgent koncovýuzol. 2 HypertextTransferProtocol 16

17 SIP Registrar server databáza, ktorá obsahuje informácie o IP adresách koncových uzlov v rámci domény. SIP Proxy server akceptuje požiadavku na zahájenie relácie od koncového uzla a požiada SIP Registrar server o adresu volaného užívateľa. Ak je volaný užívateľ zaregistrovaný v rovnakej doméne, zašle pozvánku na zahájenie relácie priamo volanému užívateľovi, inak zašle dotaz na Proxy Server v doméne, kde je volaný užívateľ zaregistrovaný. SIP Redirect server umožňuje SIP Proxy serveru preposielať pozvánky na zahájenie relácie do externých domén. SIPRegistrarserver,SIPProxyserveraSIPRedirectserversúvoväčšine prípadov jeden celok, ktorý môžeme pomenovať SIP server. User Agent pozostáva zo serverovej a klientskej časti. User Agent server prijíma SIP požiadavky a zasiela na ne odpovede, zatiaľ čo User Agent klient generuje požiadavky a prijíma nadväzujúce odpovede. Užívatelia si vytvárajú na SIP serveroch užívateľské účty a získavajú tzv. SIP URI, ktoré je v rámci domény jednoznačné. Tvar SIP URI je sip:užívateľ@doména. Podobnosť s ovými adresami nie je čisto náhodná a odporúča sa, aby užívatelia využívali rovnaké adresy, čo uľahčí ich zapamätanie. Základným prvkom v komunikácii pomocou protokolu SIP sú žiadosti a odpovede. RFC 3261 definuje šesť základných metód určených na tvorbu žiadostí[9]: REGISTER slúži na zaregistrovanie koncového uzla s aktuálnou IP adresou na Registrar servery, čím koncový uzol súčasne informuje o svojej prítomnosti. INVITE slúži na zahájenie relácie medzi užívateľmi. ACK potvrdzovanie niektorých operácií. BYE ukončuje nadviazanú reláciu medzi užívateľmi. CANCEL ruší žiadosť, ktorá ešte nebola potvrdená. OPTIONS slúži na zistenie informácií o možnostiach koncového uzla bez nadviazania relácie. 17

18 SIP definuje odpovede na základe trojmiestnych číselných kódov, ktoré sú kategorizované po stovkách: 1xx dočasný typ odpovede. Žiadosť bola prijatá a spracováva sa. 2xx kladná odpoveď. Žiadosť bola prijatá, pochopená a spracovaná. 3xx presmerovanie.jepotrebnéabysavykonaliďaľšieakciena splnenie požiadavky. 4xx chybanastraneklienta.žiadosťmázlúsyntax,alebojejnemôže byť vyhovené. 5xx chyba na strane servera. Server nemôže spracovať správnu požiadavku. 6xx globálne zlyhanie. Žiadosť nemôže byť spracovaná na žiadnom servery. Aby bol užívateľ dosiahnuteľný ostatnými, bez znalosti jeho aktuálnej IP adresy, musí sa zaregistrovať na SIP Registrar servery. Táto registrácia môže byť zabezpečená menom a heslom. Keďže protokol SIP vznikol z protokolu HTTP, používa na autentifikáciu rovnakú metódu HTTP Digest authentication. Pôvodne sa používala aj jednoduchšia forma autentifikácie HTTP Basic, ktorá je však už zakázaná. Digest autentifikácia umožňuje zaslanie hesla po sieti v zahešovanej forme. Štandartne sa hešuje pomocou algoritmu MD5. Na zamedzenie niektorým typomútokovsadohešuprimiešavaajtzv.nonce 3. Server oznámi užívateľovi potrebu autentifikovať sa odmietnutím jeho žiadosti špeciálnym kódom a pridaním WWW-Authenticate: hlavičky do odpovede. Užívateľ následne zašle žiadosť znovu s pridanou hlavičkou WWW- Authenticate: v ktorej je obsiahnuté zahešované uživateľské meno aj heslo. Ak sú údaje správne, server odpovie kódom 200. Rovnaký typ autentizácie s mierne odlišnými hlavičkami funguje aj pri komunikácii s proxy serverom. Základným príkladom použitia protokolu môže byť komunikácia medzi dvomi užívateľmi, Alicou a Bobom, znázornená na obrázku 2.2. Alica používa aplikáciu na telefonovanie na svojom počítači a chcela by zavolať Bobovi, ktorý vlastní SIP telefón. Alica je zaregistrovaná na doméne 3 numberusedonce 18

19 atlanta.com, zatiaľ čo Bob má účet u operátora biloxy.com. Na zahájenie spojenia Alica využíva SIP proxy server na jej doméne a snaží sa kontaktovať Bobovu SIP URI. Bobov telefón je zaregistrovaný u Registrar Servera jehodoményapretoajbobovproxyservervieojehoprítomnosti.takýto typspojeniaječastooznačovanýakosiptrapezoid 4 avobrázku2.2je znázornený bodkovanou čiarou. Alicin softwareový telefón zašle žiadosť obsahujúcu metódu INVITE adresovanú Bobovmu SIP URI na svoj proxy server. Žiadosť obsahuje niekoľko riadkov, na ktorých sa definujú rôzne hlavičky. Alicin proxy server prepošle žiadosťnaboboveproxyspomocoudns 5.BoboveProxyzistí,žeBobje prítomný a prepošle žiadosť na jeho telefón, ktorý začne zvoniť a informuje o tom späť svoje proxy, ktoré informáciu zašle ďalej. Podobe sa postupuje aj pri zodvihnutí Bobovho telefónu. Keď odpoveď dorazí až k Alici, jej telefón zašlepotvrdenie,žejevšetkovporiadkuazačínasavlastnýhovor.bob sa po niekoľkých minútach rozhovoru rozhodne rozhovor ukončiť, zloží telefón, ktorý o tom informuje Alicin telefón. Nakoniec Alicin telefón potvrdí ukončenie hovoru. Žiadosť s metódou INVITE, ktorú zaslala Alica mohla vyzerať podobne ako nasledujúci príklad: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 SDP je popísané v predchádzajúcej kapitole Prvý riadok obsahuje názov metódy, SIP adresu príjemcu správy a verziu protokolu. Nasleduje minimálny súbor hlavičiek, ktoré stručne popíšem: 4 SIPlichobežník 5 DomainNameSystem 19

20 Obr. 2.2: Príklad použitia protokolu SIP atlanta.com... biloxi.com. proxy proxy... Alicin Bobov telefón telefón INVITE > INVITE Trying > INVITE 4 < Trying > < Ringing Ringing 7 < Ringing 8 < OK 9 < OK 10 < OK 11 < < ACK > Samotný hovor <================================================> BYE 13 < OK > 20

21 Via: hlavička obsahuje adresu, na ktorej Alica očakáva odpoveď na svoju žiadosť a parameter branch, ktorý jednoznačne identifikuje reláciu, ktorá touto žiadosťou začína. Max-Forwards: limit preskokov po rôznych proxy serveroch, ktoré môže žiadosť pri svojej ceste za adresátom urobiť. Toto číslo je pri každom presmerovaní zmenšené o jedna. To: obsahujemenoasipuripríjemcu,ktorémubolažiadosťadresovaná From: obsahujemenoasipuritvorcužiadostiaparametertag, ktorý slúži na neskoršiu identifikáciu. Call-ID: globálne jedinečný reťazec identifikujúci tento konkrétny hovor. CSeq: tradičné sekvenčné číslo, ktoré obsahuje názov metódy. Pri každom ďaľšom použití tejto metódy sa toto číslo zväčší o jedna. Contact: informácie o priamom kontakte na tvorcu žiadosti. Content-Type: typ tela žiadosti, v tomto prípade SDP protokol. Content-Length: dĺžka tela žiadosti. Ako zaujímavosť by som uviedol, že RFC 3261 definuje náhodný reťazec použitý v parametri branch, ako reťazec začínajúci z9hg4bk. Táto predpona, nazývaná aj magic cookie zaručuje žiadosť vytvorenú podľa tohoto RFCaniestaršiehoRFC

22 Kapitola 3 Možnosti embedded zariadení 3.1 O embedded zariadeniach Embedded zariadenie je systém zameraný na poskytovanie jednej, alebo málo funkcií, neexistuje však jednotná špecifikácia, ktorá by umožnila zariadenie jednoznačne kategorizovať ako embedded. Úzka špecializácia umožňuje rozsiahle optimalizácie oproti klasickým osobným počítačom, čo výrazne znižuje ich cenu. Do skupiny embedded systémov sa zmestí široká škála zariadení, od digitálnytch hodiniek, svetelnej signalizácie na križovatkách až po mobilné telefóny, PDA a mnohé iné. Pri rozdelení sa mnohé zariadenia pohybujú na hranici medzi embedded systémom a plnohodnotným osobným počítačom. K embedded systémom sa približujú malými rozmermi, nízkou cenou a obmedzenými možnosťami ovládania, avšak programové vybavenie umožňuje ich plnohodnotné využitie takmer ako pri osobnom počítači. Rôznia sa aj systémové prostriedky zariadení. Od minimálnych požiadaviek na výpočtový výkon potrebný na pripočítanie jednotky, až po zariadenia s výkonom porovnatelným so súčasnými prenosnými počítačmi. 3.2 Dostupný výkon Výrobcovia ponúkajú množstvo špeciálnych procesorov pre embedded zariadenia. Tieto procesory sú prispôsobené požiadavkam, ako napríklad nízka spotreba, menšie rozmery, pasívne chladenie, nízka cena a iné. Existuje množstvo architektúr pre embedded procesory. Medzi najpoužívanejšie pat- 22

23 ria: ARM MIPS PowerPC x86 Mnohé z procesorov vyrábané pre embedded systémy poskytujú výkon, ktorý značne prekračuje požiadavky pre aplikáciu na prenos hlasu po IP sieti. Z prehľadu týchto procesorov som dospel k záveru, že obmedzujúci nie je dostupný výkon, ktorý je viac ako postačujúci, ale cena, ktorú sme ochotní zaplatiť[10]. 3.3 Používané operačné systémy Podľa prieskumu z roku 2008 je linux najpoužívanejší operačný systém v týchto zariadeniach[11]. Linuxové distribúcie zamerané na embedded systémy sú často okresané o nepotrebné ovládače, či aplikácie. Ich výhodou oproti iným proprietárnym systémom je otvorená licenčná politika bez poplatkov, širšia podpora a možnosť upraviť si systém podľa svojich konkrétnych potrieb. Niektoré distribúcie linuxu pre embedded zariadenia: Emdebian jedna z verzií asi najznámejšej distribúcie Debian. Vzhľadom k svojmu predkovi, z ktorého vznikla podporuje mnoho architektúr a existuje pre ňu neprieberné množstvo aplikácií a knižníc. Na rozdiel od Debianu je inštalačný balík menší, čo umožňuje použitie v zariadeniach s malou diskovou kapacitou[12]. Ubuntu Mobile verzia distribúcie Ubuntu pochádzajúca z Debianu. Verzia sa zameriava na použitie Internetu v embedded systémoch. Poskytuje priamu podporu pre technológie ako Ajax, Flash, Java a mnohé ďaľšie[13]. Opie systémzameranýnapoužitievpda.pochádzazprostredia Qtopia od Trolltechu, čo umožňuje využiť rozsiahle Qt knižnice[14]. 23

24 Slax operačnýsystémodčeskéhoautora.jemožnéposkladaťsi inštalačný balíček na webovom rozhraní z rôznych modulov pre svoju potrebu[15]. Existuje veľké množstvo operačných systémov pre embedded zariadenia založených na linuxe. Záleží na možnostiach hardware a požiadavkach užívateľa, aká distribúcia bude najvhodnejšia. 3.4 Nároky existujúcich softwareových telefónov Vybral som tri známe softwareové SIP telefóny implementované na linuxe a pomocou utility top, som hodnotil vyťaženie procesora a potrebu pamäte počas telefónneho hovoru s použitím hlasového kódeku GSM. Telefóny som testoval v základom nastavení v akom som ich nainštaloval, do nastavení som pridal iba údaje ohľadom SIP konta, prípadne, ak to bolo potrebné,zmenilsomzvukovýovládačnaalsuakódeknagsm. Test prebehol na zariadení s procesorom Intel Pentium M 1.70GHz a pamäťou 1.5GB, počas normálneho behu operačného systému Ubuntu Hovor prebiehal s iným SIP softwareovým telefónom cez internet za použitia rovnakého SIP Proxy serveru Twinkle 1.2 Robustný telefón s podporou SIP. Telefón sa defaultne spúšťa v grafickom režime vytvorenom pomocou knižníc Qt, test však prebehol v textovom režime, ktorý telefón tiež umožňuje, aby sa minimalizovalo ovplyvnenie výsledku potrebami užívateľského rozhrania. Twinkle počas hovoru využíval 20%- 35% procesoru a potreboval 0.9% pamäteakojemožnévidieťnaobrázku Ekiga Telefón s podporou SIP aj H.323, ktorý umožňuje aj videorozhovory. Telefón sa mi nepodarilo spustiť v textovom režime, pri každom pokuse sa následne spustilo aj grafické rozhranie. Test odhalil prekvapivé výsledky. Ekiga počas hovoru využívala 2% pamäte, aleaž75%-95%procesoruakojemožnévidieťnaobrázku

25 Obr. 3.1: Testovanie programu Twinkle Obr. 3.2: Testovanie programu Ekiga 25

26 3.4.3 Linphone Telefón umožňuje použitie grafického užívateľského rozhrania, avšak test prebehol v textovom režime telefónu. Linphone sa správal skromnejšie ako predchádzajúce telefóny, potreboval 0.6%pamäteavyťažoval7%-14%procesoruakojemožnévidieťnaobrázku 3.3. Obr. 3.3: Testovanie programu Linphone 3.5 Požiadavky mojej implementácie Moja implementácia nazvaná mcom pracuje s užívateľským rozhraním v textovom režime. mcom je sh skript, ktorý spustí dva programy mcom-core a mcom-console. PočasrozhovorumComvyužíva2%-7%procesorua0.8%pamäte,akoje možné vidieť na obrázku Potrebný diskový priestor Cenu embedded zariadenia výrazne ovplyvňuje aj potrebná disková kapacita. V tomto ohľade sa moja implementácia správa taktiež úsporne. Pomocouutilítlddadusomzistil,žepremôjtelefónjeajspoluspotrebnými knižnicami postačujúcich 7 MB priestoru. K tejto veľkosti je ešte potrebné pripočítať veľkosť jadra operačného systému. 26

27 Obr. 3.4: Testovanie mojej implementácie Ďaľší najúspornejší z telefónov je program linphone, ktorý spolu s knižnicami potrebuje 30 MB. Telefóny Ekiga a Twinkle potrebujú viac ako 40 MB. 3.7 Zhodnotenie Môj program vyťažoval procesor výrazne menej ako všetky ostatné telefóny. Spotreba pamäte je pri telefónoch bežiacich bez grafického rozhrania obdobná, moja implementácia skončila na druhom mieste za telefónom linphone, avšak s minimálnym rozdielom. Potrebný diskový priestor na beh môjho telefónu je takmer zanedbateľný. Zadanie práce z hľadiska nízkych nárokov na systémové prostriedky som splnil nad očakávania. 27

28 Kapitola 4 Kompatibilita 4.1 Možnosti Vzhľadom k rýchlemu rozširovaniu VoIP služieb vzniklo aj viacero technológií, ktoré prenos hlasu pomocou IP siete umožňujú. Súčasným trendom je však zbližovanie sa týchto technológií, aby bolo možné uskutočniť hovor medzi ľubovolnými užívateľmi, nezávisle na implementácií, ktorú používajú. Príkladom môže byť Skype, ktorý využíva uzavretý komunikačný protokol, avšak začiatkom tohoto roka predstavil službu Skype for SIP Beta, ktorá umožňuje prepojenie s užívateľmi SIP telefónov[16]. Ako som už uviedol v úvode práce, dve implementácie VoIP telefonovania sú kompatibilné, ak používajú rovnaký komunikačný protokol a majú aspoň jeden spoločný audio kódek. VmojejprácisomsazameralnaprotokolSIPakódekGSM.Vďaľšomtexte je potrebné, aby bol čitateľ oboznámený so základnými princípmi tohoto protokolu, ktoré som popísal v druhej kapitole. 4.2 Najznámejšie implementácie SIP servera V otázke kompatibility SIP zariadení hrajú dôležitú úlohu implementácie SIP servera. Medzi najznámejšie implementácie SIP servera s bezplatnou licenciou patria: Asterisk najrozšírenejšia implementácia, ktorá je aj najrobustnejšia. Táto implementácia podporuje aj protokol H.323 a môže slúžiť ako 28

29 brána do verejnej telefónnej siete[17]. SER SIP Express Router, medzi najväčšie výhody implementácie patrí výkonnosť, keď pri bežnom dvojjadrovom procesore dokáže obslúžiť stovky volaní za sekundu[18]. Kamailio v minulosti známy ako OpenSER. Programátori vyvíjajúci SERsavroku2004rozdeliliačasťznichzačalapracovaťnatomto projekte[19]. Niektorí zástupcovia s proprietárnou licenciou: Microsoft Office Communications Server robustné riešenie, ktoré je úzko späté najmä s produktami tejto firmy. Umožňuje aj prepojenie s verejnou telefónnou sieťou[20]. Oracle Multimedia Communication Engine riešenie zamerané na spoluprácu s implementáciami v Jave[21]. Siemens HiPath 8000 medzi hlavné výhody tohoto riešenia patrí garantovaná vysoká spoľahlivosť a škálovateľnosť až do užívateľov[22]. 4.3 Kompatibilita s inými telefónmi Moja implementácia podporuje komunikačný protokol SIP a umožňuje dve varianty uskutočnenia hovoru. Priame telefonovanie na zadanú verejnú IP adresu, alebo telefonovanie s využitím proxy servera na SIP adresu zaregistrovaného užívateľa. Pri priamom telefonovaní je jediným obmedzením kompatibility nutnosť podpory kódeku GSM zo strany protiľahlého telefónu. Tento kódek však patrí medzi najrozšírenejšie[23]. Pri telefonovaní s využitím proxy servera je kompatibilita obmedzená použitou implementáciou SIP servera. Môj program je plne kompatibilný s variantou servera SER. Pri použití inej implementácie sa môžu vyskytnúť určité anomálie, ako napríklad nekorektné ukončenie hovoru. Problém je spôsobený špecifickou tvorbou hlavičiek a zasielaním správ, ktoré moja implementácia nedokáže rozoznať. Môj program nie je plne kompatibilný s protokolom SIP a preto nepodporuje všetky rôzne typy týchto hlavičiek a správ. Rozsah dokumentu RFC 3261, ktorý definuje tento protokol 29

30 však spôsobuje, že plná kompatibilita je skôr výnimkou ako pravidlom. Ako príklad môžem uviesť telefón Twinkle, ktorý je široko rozšírený a aktívne vyvíjaný od roku 2005 a doteraz plne tento dokument nepodporuje[24]. Pri výbere SIP Registrar servera preto odporúčam používať doménu so SIP serverom SER, napríklad iptel.org, ktorý umožňuje bezplatú registráciu. 4.4 Zhodnotenie Telefonovanie s inými implementáciami telefónov je bezproblémové. Obmedzenie kódekom GSM vzhľadom k jeho rozšíreniu nepovažujem za podstatné. Môj telefón podporuje aj možnosť uskutočniť hovor pomocou proxy servera. Dosiahol som plnú kompatibilitu s implementáciou SIP servera SER a čiastočnú podporu iných implementácií. Podľa zadania som sa sústredil na kompatibilitu s inými implementáciami softwareových telefónov, ktorú som dosiahol v akceptovateľnej miere, takže túto časť zadania považujem za splnenú. Pripúšťam možné vylepšenia v otázke kompatibility s rôznymi implementáciami SIP serverov. 30

31 Kapitola 5 Ovládanie telefónu 5.1 Užívateľské rozhrania embedded zariadení Užívateľské rozhrania pre embedded systémy sa vzhľadom k širokej palete týchto zariadení líšia. Od zariadení bez možnosti interakcie s užívateľom až po zariadenia s dotykovým displejom a možnosťou ovládania hlasom ako napríklad u niektorých mobilných telefónov. Na pohodlné ovládanie môjho telefónu by postačovalo zariadenie s niekoľko riadkovým textovým displejom, s dvomi tlačidlami a numerickou klávesnicou, ktorú by bolo možné prepnúť do textového režimu, ako je zvykom u mobilných telefónov. Samozrejmosťou by bol reproduktor a mikrofón. 5.2 Moja implementácia ovládania Moja implementácia disponuje oddelenou časťou jadra od užívateľského rozhrania, čo výrazne rozširuje možnosti ovládania. Vďaka tomuto oddeleniu som umožnil ľahké vytvorenie špecifického rozhrania pre dané konkrétne zariadenie, s ohľadom na jeho možnosti. Užívateľské rozhranie som implementoval pomocou soketu, ktorý sa pripája na jadro na porte a jadro zasiela správy užívateľskému rozhraniu na porte pomocou protokolu UDP. Užívateľské rozhranie môže vytvoriť vlastný konfiguračný súbor, ktorého umiestnenie následne zašle jadru na spracovanie. Pomocou tohoto rozhrania je možné aj ovládanie jadra niekoľkými príkazmi. Komunikácia je podrobne popísaná v užívateľskom a programátorskom manuáli k programu. 31

32 5.3 Zhodnotenie Implementácia užívateľského rozhrania pomocou komunikácie s jadrom cez soket je dostatočne variabilná a umožňuje plné prispôsobenie ovládania možnostiam embedded zariadenia, do ktorého bude implementovaná. Zadanie v tejto časti preto považujem za splnené. 32

33 Kapitola 6 Možné vylepšenia implementácie 6.1 Funkčné vylepšenia Za mierny nedostatok mojej implementácie považujem obmedzenú kompatibilitu s niektorými variantami SIP serverov. Rozšírenie môjho programu o podporu rôzneho chovania viacerých týchto serverov by bolo nad rámec zadania práce, avšak prispelo by k väčšiemu užívateľskému komfortu. Tento problém by mohol byť vyriešený rozšírením podpory protokolu SIP. 6.2 Rozširujúce vylepšenia Medzi rozširujúce vylepšenia môjho programu by som zahrnul širšiu množinu podporovaných kódekov. Použitý kódek GSM je síce podporovaný takmer vo všetkých softwareových telefónoch, avšak na hovory do verejnej telefónnej siete, prípadne v budúcnosti aj do siete Skype sú potrebné kódeky G.711 asilk[26]. Ako ďaľšie vylepšenie sa ponúka možnosť šifrovania hovorov na zvýšenie bezpečnosti telefonovania. Súčasťou vylepšení môže byť aj podpora videohovorov, ktorá sa vzhľadom ku klesajúcim cenám webových kamier stáva čoraz dostupnejšou a obľúbenejšou medzi užívateľmi. 33

34 Kapitola 7 Praktická skúsenosť s implementáciou v embedded systéme 7.1 Zariadenie Na simuláciu chodu mojej implementácie v embedded systéme sa mi podarilo získať zariadenie VIA Epia Mini-ITX zobrazené na obrázku 7.1 Zariadenie je vybavené procesorom VIA Samuel 2 a operačnou pamäťou s veľkosťou KB. Zariadenie nie je vybavené pevným diskom, preto som použil live 1 usbsoperačnýmsystémomubuntu9.04. Počítač poskytuje rozhranie na pripojenie všetkých potrebných periférií. 7.2 Použitie implementácie na zariadení Použitie mojej implementácie na tomto zariadení bolo bezproblémové. Vzhľadom na použitý operačný systém, nebolo potrebné inštalovať žiadne ďaľšie knižnice. Do základnej konfigurácie systému bol pridaný iba prehrávač mplayer, ktorý je využívaný mojim užívateľským rozhraním programu na prehrávanie vyzváňacích tónov. Telefón počas hovoru vyťažoval procesor priemerne na 20% a potreboval 1.5% pamäte. 1 bootovateľné 34

35 Obr. 7.1: Zariadenie VIA Epia Mini-ITX 35

36 7.3 Zhodnotenie Počítač VIA Epia Mini-ITX, na ktorom som sa snažil simulovať chod môjho programu v embedded systéme patrí k výkonnejším zariadeniam v tomto segmente. Poskytnutý výkon ďaleko presiahol požiadavky mojej implementácie. Pri testovaní programu sa nevyskytli žiadne komplikácie, považujem preto simuláciu behu programu v embedded zariadení za úspešnú. 36

37 Kapitola 8 Záver Cieľom práce bolo vytvoriť program na telefonovanie po IP sieťach s podporou protokolu SIP a so špecializáciou na využitie v málo výkonných počítačoch. Podarilo sa mi vytvoriť implementáciu, ktorej nároky na systémové prostriedky sú výrazne nižšie ako nároky iných programov s podobným zameraním. Moja implementácia môže byť preto použitá v zariadení s menej výkonným procesorom a malou pamäťou, čo výrazne ovplyvní cenu tohoto zariadenia. Dosiahol som kompatibilitu s inými telefónmi používajúcimi komunikačný protokol SIP. Uskutočnenie hovoru je možné, ak implementácia podporuje jeden z najrozšírenejších kódekov GSM. Pri použití proxy servera je kompatibilita overená s implementáciou servera SER. Telefonovanie pri použití iného SIP serveru je možné, avšak vzhľadom na rozdielne chovanie a zasielanie správ v mierne odlišnom formáte sa môžu vyskytnúť isté anomálie, ako napríklad chybné ukončenie hovoru. Táto skutočnosť je spôsobená obmedzenou podporou štandardu RFC 3261 definujúceho SIP zo strany mojej implementácie, avšak vzhľadom na rozsah tohoto protokolu sa tento problém vyskytuje aj u iných telefónov. Aj keď kompatibilita s viacerými implementáciami SIP serverov nebola cieľom práce, pripúšťam možné vylepšenia v tejto oblasti. Variabilné ovládanie som umožnil pomocou oddelenia jadra programu od užívateľského rozhrania. Tieto dve časti spolu komunikujú cez soket, čo umožňuje jednoduché vytváranie vlastných užívateľských rozhraní prispôsobených potrebám a možnostiam embedded systému, do ktorého bude telefón nasadený. 37

38 Aj keď sa ako hlavné využitie implementácie predpokladá v embedded systéme, verím, že vzhľadom k funkcionalite aplikácie sa uplatnenie rozšíri aj o bežné využitie v rámci osobných počítačov. 38

39 Literatúra [1] Wikipedia, The Free Encyclopedia: Voice over Internet Protocol over Internet Protocol [2] Internet pro všechny: Přehled 21 poskytovatelů VoIP služeb [3] SearchUnifiedCommunications.com: Analog Telephone Adapter [4] ITU: Recommendation G [5] RFC 4566: Session Description Protocol [6] RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control [7] Wikipedia, The Free Encyclopedia: Real-time Transport Protocol Transport Protocol [8] RFC 3550: Real-time Transport Protocol [9] RFC 3261: Session Initiation Protocol [10] LinuxDevices.com: Embedded Processor and System-on-Chip Quick Reference Guide Articles/Embedded-Processor-and-SystemonChip-Quick-Reference- Guide/ 39

40 [11] LinuxDevices.com: Linux still top embedded OS OS [12] Emdebian: Embedded Debian Project [13] Ubuntu: Ubuntu Mobile Internet Device Edition [14] Opie: Open Palmtop Integrated Environment [15] Slax: Slax- your pocket operating system [16]Skype:SkypeforSIPBeta [17] Asterisk: About Asterisk [18] SER: About SIP Express Router [19] Kamailio: Kamailio wiki [20] Microsoft: Office Communications Server [21] Oracle: Oracle Communications Converged Application Server [22] Siemens: HiPath [23] Voip-Info: Codecs 40

41 [24] Twinkle: About Twinkle mfnboer/twinkle/index.html [25] Ditech Networks Solutions: Codec Normalization for Wholesale Voice Termination Providers [26] Skype: SILK Super Wideband Audio Codece 41

42 Dodatok A Obsah priloženého CD Priložené CD obsahuje: spustitelne subory skompilovaný program zdrojove kody zdrojové kódy k implementácií dokumentacia programátorská dokumentácia súbor bakalarska praca.pdf text bakalárskej práce vo formáte PDF súbor kontakt.txt kontakt na autora 42

43 Dodatok B Užívateľská príručka B.1 Prerekvizity Program je možné spustiť na operačnom systéme Linux. Na spustenie programu sú nutné knižnice: libasound libccrtp libgsm libccgnu libgpg-error Pri použití aktuálnej 32 bitovej verzie distribúcie Linuxu založenej na Debiane, ako napríklad Ubuntu 9.04, nie je potrebné kompilovať zdrojové kódy, ani doinštalovávať ďaľšie knižnice, je možné použiť poskytnuté spustiteľné súbory. Balík mplayer je potrebný na prehrávanie vyzváňacích tónov. B.2 Predpoklady úspešnej kompilácie Na úspešný priebeh kompilácie sú nutné dev verzie spomenutých knižníc a kompilátor g++. Program je možné skompilovať pomocou príkazu make. 43

44 B.3 Pred prvým spustením Pred prvým spustením programu je nutné upraviť konfiguračný súbor pomenovaný mcom.configure. Tento súbor ponúka nastavenie niektorých premenných súvisiacich s behom programu: Login užívateľské meno. Password heslo používané na SIP doméne. Sip Realm SIP doména na ktorej je užívateľ zaregistrovaný. Register at startup nastavenie možnosti zaregistrovať sa na SIP doménu pri štarte programu. Logging Destination názov súboru do ktorého sa v prípade logovania bude log zapisovať. Logging nastavenie logickej hodnoty pre vytvorenie logovacieho súboru. Alsadevice názovzariadenia,ktorésapoužívanazáznamaprehrávanie zvuku. SIPport port,ktorýsapoužijenaodosielanieaprijímaniesip správ. Network interface názov sieťového rozhrania, ktoré bude použité na odosielanie a prijímanie dát. Formát konfiguračného súboru je: Názov parametru: hodnota Pri niektorých parametroch sa nastavuje logická hodnota: 0 pre nie, 1 pre áno. Umiestnenie a pomenovanie konfiguračného súboru je možné zmeniť spustením užívateľského rozhrania s názvom súboru ako parametrom. 44

45 B.4 Spustenie a ovládanie programu Program sa spúšťa postupne, najprv jadro programu mcom-core, a následne užívateľské rozhranie mcom-console. Je možné využiť poskytnutý sh skript mcom, ktorý spustí jadro na pozadí a užívateľské rozhranie na popredí. Po spustení programu sa na základe nastavenia v konfiguračnom súbore môže vykonať registrácia na SIP server. V prípade, ak užívateľ zaregistrovaný nie je, je možné telefonovať a prijímať priame hovory. Ak je užívateľ zaregistrovaný, telefonuje a prijíma hovory pomocou SIP servra. Program sa ovláda pomocou piatich príkazov: call user@domain.tld pokúsi sa zavolať užívateľa s danou SIP adresou. calluser@ip pokúsisazavolaťnazadanúipadresu. call IP kratší formát predošlej varianty. ok prijmežiadosťorozhovorazahájihovor. bye odmietne žiadosť o rozhovor, prípadne ukončí prebiehajúci hovor. exit ukončí aplikáciu, prípadne ukončí aj prebiehajúci hovor. register zaregistruje užívateľa na SIP server. Ovládanie je intuitívne, program sa snaží informovať užívateľa o všetkých prebiehajúcich udalostiach. 45