VoIP telefon pro webové prostředí - IS MUNI

Masarykova univerzitaFakulta informatiky

VoIP telefon pro webovéprostředí

Diplomová práce

Lukáš Gryc

Brno, jaro 2018

Masarykova univerzitaFakulta informatiky

VoIP telefon pro webovéprostředí

Diplomová práce

Lukáš Gryc

Brno, jaro 2018

Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce aprohlášení autora školního díla.

Prohlášení

Prohlašuji, že tato diplomová práce je mým původním autorskýmdílem, které jsem vypracoval samostatně. Všechny zdroje, pramenya 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.

Lukáš Gryc

Vedoucí práce: doc. RNDr. Vlastislav Dohnal Ph.D.

i

Poděkování

Rád bych poděkoval panu RNDr. Pavlu Cenkovi za odborné konzul-tace, připomínky a návrhy k práci.

iii

Abstrakt

Diplomová práce se zabývá technologií WebRTC a možnostmi jejíhovyužití pro vytvoření webového telefonu, který bude bez instalacejakýchkoliv dodatečných modulů schopen napojení do VoIP infrastruk-tury na bázi signalizačního protokolu SIP. Pro realizaci telefonu jsoumimo technologii WebRTC využity technologie WebSocket, JavaScripta HTML5. V první části práce jsou vysvětleny technologie a protokoly,na kterých je telefon postaven. Ve druhé části je krátké shrnutí již exis-tujících aplikací. Třetí část se zabývá návrhem vlastního řešení výšepopsaného telefonu.

iv

Klíčová slova

WebRTC, VoIP, SIP, HTML5, WebSocket, SIP, Asterisk, JavaScript, SIP.js

v

Obsah

Introduction 1

1 Popis technologií 51.1 Telekomunikační technologie . . . . . . . . . . . . . . . . . 5

1.1.1 PSTN . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.2 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.3 IP PBX . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Signalizace . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.1 H.323 . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.2 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.3 SDP . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.4 STUN server . . . . . . . . . . . . . . . . . . . . . 231.2.5 TURN server . . . . . . . . . . . . . . . . . . . . 231.2.6 ICE . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2.7 WebSocket . . . . . . . . . . . . . . . . . . . . . . 25

1.3 Média . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.3.1 RTP, RTCP . . . . . . . . . . . . . . . . . . . . . . 291.3.2 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.4 Tvorba webu . . . . . . . . . . . . . . . . . . . . . . . . . . 351.4.1 HTML5 . . . . . . . . . . . . . . . . . . . . . . . 351.4.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . 351.4.3 Klientský JavaScript . . . . . . . . . . . . . . . . 361.4.4 Serverový JavaScript . . . . . . . . . . . . . . . . 36

1.5 WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.5.1 Architektura WebRTC . . . . . . . . . . . . . . . 381.5.2 MediaStream API . . . . . . . . . . . . . . . . . . 401.5.3 WebRTC signalizace . . . . . . . . . . . . . . . . 421.5.4 PeerConnection API . . . . . . . . . . . . . . . . 441.5.5 WebRTC Brána (gateway) . . . . . . . . . . . . . 461.5.6 DataChannel API . . . . . . . . . . . . . . . . . . 471.5.7 Zabezpečení WebRTC . . . . . . . . . . . . . . . 50

2 Analýza existujících řešení 532.1 Video-konferenční aplikace . . . . . . . . . . . . . . . . . . 53

vii

3 Návrh vlastního řešení 573.1 Požadavky kladené na aplikaci . . . . . . . . . . . . . . . . 573.2 Použité knihovny . . . . . . . . . . . . . . . . . . . . . . . 57

3.2.1 sipML5 . . . . . . . . . . . . . . . . . . . . . . . . 583.2.2 JsSIP . . . . . . . . . . . . . . . . . . . . . . . . . 583.2.3 SIP.js . . . . . . . . . . . . . . . . . . . . . . . . . 593.2.4 jQuery . . . . . . . . . . . . . . . . . . . . . . . . 593.2.5 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . 60

3.3 Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . . . 603.4 Architektura aplikace . . . . . . . . . . . . . . . . . . . . . 633.5 Popis nejdůležitějších částí kódu . . . . . . . . . . . . . . . 663.6 Testování . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.6.1 Testované scénáře . . . . . . . . . . . . . . . . . . 693.6.2 Testy audio kvality . . . . . . . . . . . . . . . . . 703.6.3 Ladící nástroje . . . . . . . . . . . . . . . . . . . . 713.6.4 WebRTC internals . . . . . . . . . . . . . . . . . 71

4 Závěr 75

Rejstřík 77

Bibliografie 79

viii

Seznam tabulek

1.1 Skupina odpovědí 1xx 171.2 Skupina odpovědí 2xx 171.3 Skupina odpovědí 3xx 181.4 Skupina odpovědí 4xx 181.5 Skupina odpovědí 5xx 191.6 Skupina odpovědí 6xx 191.7 Srovnání transportních protokolů UDP, TCP a SCTP 34

ix

Seznam obrázků

1.1 Srovnání IP PBX Asterisk, FreeSwitch, FreePBX, Kamalio.Dostupné z [2] 7

1.2 Průběh úspěšné SIP registrace 111.3 Průběh navázání spojení mezi Alicí a Bobem 141.4 Kódování DTMF tónů, dostupné z [10] 201.5 Použití STUN serveru k získání IP adresy a čísla

portu. 241.6 Použití STUN i TURN serverů současně 241.7 Struktura hlavičky RTP paketu, dostupné z [21] 301.8 Struktura hlavičky RTCP paketu, dostupné z [24] 321.9 Struktura SCTP paketu, dostupné z [26] 351.10 Hlavní webové prohlížeče a jejich podpora WebRTC

technologie, dostupné z [29] 371.11 Architektura WebRTC, dostupné z [30] 381.12 MediaStream API, dostupné z [26] 411.13 Princip JavaScript Session Establishmen Protocol,

dostupné z [26] 441.14 WebRTC lichoběžník, dostupné z [39] 461.15 Indikátor značící, že daná záložka využívá mikrofon

(Google Chrome) 522.1 Ukázka WebRTC aplikace GetOnSIP 542.2 Ukázka WebRTC aplikace Circuit 543.1 Ukázka uživatelského rozhraní telefonu 613.2 Ukázka uživatelského rozhraní telefonu 623.3 Ladící nástroj technologie WebRTC ve webovém

prohlížeci Google Chorme 723.4 Ladící nástroj technologie WebRTC, grafické znázornění

statistik ve webovém prohlížeci Google Chorme 73

xi

Úvod

Doba rozmachu klasických telefonních linek, které ve svých začát-cích představovaly přenos analogového signálu skrze měděné ka-bely, je již dávno pryč. Představa spojovatelky, která manuálně pro-pojuje dva měděné dráty, aby došlo k propojení hovoru mezi dvěmaúčastníky, je v dnešní době již poměrně úsměvná. Klasické telefonnílinky, referované jako PSTN (Public Switched Telephone Network), jsouv dnešní době na ústupu. Největší operátoři poskytující PSTN telefoniipostupně oznamují, že v horizontu několika let přestanou nabízeta podporovat volání přes klasické telefonní linky.

Rozmach internetu s sebou mimo jiné přinesl i posun v oblastitelekomunikací. Lidé si uvědomili, že protokol IP může být použitpro přenos digitalizovaného hlasu, což také vystihuje pojmenováníVoIP (Voice over IP). Jedním ze zásadních rozdílů mezi VoIP a PSTN jealokace přenosového kanálu. PSTN funguje na principu přepojováníokruhů, což ve zkratce znamená, že je celý kanál vyhrazen pouzejednomu hovoru. Na druhou stranu internetová telefonie využívátechniky zvané přepínání paketů (datových bloků přenášených sítí).Díky této technice může po jedné lince putovat více dat různých uži-vatelů a tedy i více hovorů. Volání přes internet tedy přineslo sníženíceny volání, jelikož je potřeba pouze internetové připojení.

V době vytáčeného připojení se sice u internetového volání nedalomluvit o vysoké kvalitě hovoru, ale v dnešní době je již běžně dostupnéinternetové připojení naprosto dostačující pro potřeby VoIP telefonie.

VoIP aplikace

Posun k VoIP telefonii s sebou přinesl i změnu koncových zařízeníhovoru. Postupem času bylo vyvinuto mnoho počítačových (i mo-bilních) aplikací, které slouží jako koncový bod VoIP hovoru. Mezinejrozšířenější z nich patří například aplikace Skype, která poskytujejak hlasovou komunikaci, tak video-konferenci. Obdobných aplikacíje nepřeberné množství a zpravidla jsou již v dnešní době poměrnědobře odladěné a funkční.

1

Webový prohlížeč

Časem bylo ovšem potřeba vyřešit situaci, kdy uživatel z nějakého dů-vodu nechce nebo snad nemůže do počítače instalovat aplikace, a přestochce využít internetového volání. To bylo jedním z důvodů, proč se ná-sledně objevila snaha o zpřístupnění RTC (Real-time Communication)komunikace skrze webový prohlížeč. Ještě před několika lety (okoloroku 2011) bylo pro realizaci RTC komunikace z webového prohlížečepotřeba doinstalování dodatečného modulu, což s sebou neslo častoznačné problémy jak se stabilitou webového prohlížeče, tak se zavede-ním bezpečnostních rizik. Řešení problémů s chybějící podporou RTCkomunikace přímo ve webových prohlížečích přinesl projekt WebRTC.WebRTC dodává webovým prohlížečům podporu pro přístup k mikro-fonu a kameře koncového zařízení, pro přenos dat (médií) v reálnémčase a v neposlední řadě pro přenos jakýchkoliv jiných dat (např.přenos souborů). WebRTC je zabudováno přímo v prohlížeči, čímžodpadá potřeba instalace dodatečných modulů (dříve potřebných proRTC komunikaci).

Obsah práce

Tato práce se zabývá technologií WebRTC a možnostmi jejího využitípro vytvoření webového telefonu, který bude bez instalace jakýchkolivdodatečných modulů schopen napojení do VoIP infrastruktury na bázisignalizačního protokolu SIP.

První část této práce se věnuje technologiím a protokolům, kteréjsou jsou potřeba pro vytvoření webového telefonu. Zejména je zdevysvětlen základní princip signalizačního protokolu SIP a v něm nade-finovaných zpráv a odpovědi. Dále pak práce pojednává o protokoluSDP používaném pro vyjednání parametrů spojení, protokolu Web-Socket, který slouží pro přenos signalizace mezi WebRTC klientema serverem. Opomenuty nejsou ani protokoly RTP, RTCP, SCTP, kteréslouží pro přenos dat. Jako poslední v této sekci je popsána samotnátechnologie WebRTC, její architektura, JavaScript API a obecný popiszabezpečení.

Druhá část uvádí krátký popis již existujících řešení webovýchtelefonů na bázi WebRTC a současnou situaci, co se využití WebRTCtýká.

2

Ve třetí části je pak uveden popis vlastního řešení výše popsa-ného webového telefonu. Jedná se o popis návrhu telefonu, funkcio-nalit, které telefon nabízí a ilustrace uživatelského rozhraní.

Ve čtvrté části je popsán způsob testování aplikace, testované scé-náře a nástroje, které pomáhají s laděním technologie WebRTC.

3

1 Popis technologií

1.1 Telekomunikační technologie

1.1.1 PSTN

Public Switched Telephone Network (PSTN) je telekomunikační síť, kteráje postavena na principu přepojování okruhů. Okruh je předem stano-vený, stabilní komunikační kanál, ve kterém je zajištěno doručení datve správném pořadí. Pro každý hovor je zde vyhrazen komunikačníkanál (přesněji okruh), kterým prochází veškerá komunikace oboukomunikujících stran. což zajišťuje vysokou stabilitu spojení a kva-litu přenášeného zvuku. Komunikační kanál je po ukončení hovoruuvolněn a přípraven k využití dalšími hovory.

1.1.2 VoIP

Prostředky pro modernější způsob telekomunikace představuje pro-tokol VoIP (Voice over Internet Protocol), který dodává podporu propřenos hlasu přes síť IP (Internet Protocol). Principem přenosu je pře-vod analogového signálu na digitální, tento signál je následně rozdělendo menších jednotek dat (paketů), které jsou poslány skrz IP síť. IPsíť funguje na principu přepínání paketů, což znamená, že jednotlivépakety pocházející od různých odesilatelů a určené různým příjem-cům jsou přenášeny společným přenosovým kanálem. Mezi nespornévýhody VoIP patří úspora nákladů, zpřístupnění nových služeb jakojsou video-hovory a v neposlední řadě zejména usnadnění integraceVoIP řešení.

Kvůli posílání digitalizovaného signálu po částech ovšem můžedojít ke zhoršení kvality přenášeného zvuku. Mezi hlavní problémy, sekterými je potřeba se v rámci VoIP potýkat, patří zpoždění, ztrátapaketů, jitter a ozvěna[1].

Zpoždění Ve VoIP sítích lze zpoždění charakterizovat jako čas, kterýje potřeba, aby informace jdoucí z úst mluvčího dorazila k uchunaslouchajícího. Ve VoIP sítích existují tři typy zpoždění. Prvnítyp zpoždění je způsoben šířením zvuku. Druhý typ zpoždění jezpůsoben zpracováním paketů pří směrování v rámci sítě. Třetí

5

1. Popis technologií

typ zpoždění vzniká při zahlcení výstupního rozhraní, kterénezvládá v daný moment odeslat dostačující množství paketů.

Ztráta paketů Pakety přenášející digitalizovaný zvuk jsou v rámciVoIP sítí posílány pomocí protokolu User Datagram Protocol(UDP), který nedává žádné záruky týkající se doručení paketů.Chybějící pakety mohou způsobit zhoršení kvality přenášenéhohlasu, případně v extrémních případech naprosto chybějící částzvukové stopy.

Jitter Jitter je problém vznikající v paketových sítích, kde mohou býtpakety směrování jinými cestami s různou časovou náročností kjejich překonání. Pakety tedy mohou do cíle dorazit v různémpořadí, což způsobuje zhoršení kvality přenášeného zvuku. Proomezení vlivu jitteru byly zavedeny jitter buffery, které dočasnědrží příchozí pakety, aby tak minimalizovaly rozdíly ve zpožděnípříchodu jednotlivých paketů.

1.1.3 IP PBX

Pobočková telefonní ústředna (Private Branch Exchange, zkráceněPBX) slouží k propojení telefonů v rámci podniku a jejich napojení dosítě PSTN. Její novější verze IP PBX používá k přenosu zvuku protokoluIP. Mezi hlavní zástupce open-source IP PBX patří Asterisk, FreeSwitch,FreePBX, Kamailio. Z obrázku 1.1 jde vidět, že tyto ústředny nabízíobdobnou funkcionalitu. Zásadní pro tuto práci je zejména poslednířádek, který udává podporu WebRTC.

Asterisk

Asterisk je jedním z nejrozšířenějších open source IP PBX systémů.Mezi jeho hlavní přednosti patří nízké nároky na vybavení počítačea vysoká míra modularity. Konfigurační soubory mají formu obyčej-ného textu. V posledních verzích už v základním instalačním balíkuobsahuje podporu pro technologii WebRTC.

6


Obrázek 1.1: Srovnání IP PBX Asterisk, FreeSwitch, FreePBX, Kamalio.Dostupné z [2]

1.2 Signalizace

Telefonní hovor se skládá ze dvou částí - signalizace a přenosu hlasu.Účelem signalizace je ustanovení, udržování a rozpojení hovoru. Nej-rozšířenějšími protokoly pro VoIP signalizaci jsou H.323 a SIP.

1.2.1 H.323

Protokol H.323 zastřešuje celou řadu dalších protokolů a je navrženpro podporu přenosu jak hlasových dat, tak i například video-hovoru.Struktura H.323 je oproti mladšímu protokolu SIP značně složitější,jelikož se nesoustředí pouze na hlasovou komunikaci. Protokol H.323má binární podobu, takže není pro člověka snadno čitelný a pro jehopřípadné ladění je třeba použít analyzátor.

7


1.2.2 SIP

Začátek vývoje protokolu SIP se datuje na rok 1996, kdy za ním stálaskupina MMUSIC (Multiparty Multimedia Session Control) v rámciIETF (Internet Engineering Task Force). V roce 1999 byl předložen veformě standardu (Proposed Standard) v RFC 2543 [3]. Téhož roku napopud IETF vznikla nová pracovní skupina, nazvaná příznačně SIP,která převzala vývoj hlavního jádra protokolu. Její práce vyústila vnový Proposed Standard - RFC 3261 [4].

SIP je na rozdíl od protokolu H.323 textově orientovaný a sestáváse z posloupnosti hlaviček, díky čemuž je dobře rozšiřitelný (přidá-ním nové hlavičky). Ve zprávě protokolu SIP je zapouzdřena zprávajiného protokolu, která obsahuje informace o vlastnostech relace jakokodeky1, čísla portů využitá pro přenos multimediálních dat, šifro-vání. Pro tento účel se nejčastěji využívá protokol Session DescriptionProtocol (SDP).

SIP síťové komponenty

∙ User agent

∙ Proxy server

∙ Redirect server

∙ Registrar server

∙ Lokalizační server

User Agent (Uživatelský Agent)

User Agent (UA) je koncovým bodem síťě SIP. UA je souhrnným náze-vem pro klientského UA (UAC) a serverového UA (UAS). UAC i UASpracují souběžně.

∙ Klientský UA (UAC) se stará navázaní spojení. A odesílá poža-davky na UAS a čeká na tyto požadavky odpovědi.

1. Softwarový program, který provádí kódování a dekódování digitálního datovéhoproudu nebo analogového signálu

8


∙ serverový UA (UAS) přijímá požadavky od klientů a odesílá natyto požadavky odpovědi.

Proxy server

Proxy server je síťový prvek, který zajišťuje přeposílání žádostí nacílový User Agent (UA), slouží tedy zejména ke směrování žádostí.Mezi jeho další funckce patří autentizace a autorizace UA.

Proxy server může fungovat ve dvou módech:

∙ Stateless (bezstavový) transakce - V tomto módu Proxy serverzapomene veškeré informace o žádosti hned po jejím dokončení.

∙ Statefull (drží informace o stavech) transakce - Proxy server siudržuje informace o přeposílaných žádostech, což může býtpotřeba pro složitějšími SIP scénáře.

Redirect server (Server přesměrování)

Redirect server je UAS, který na žádosti klientů vrací odpovědi 3xx salternativními URI (Uniform Resource Identifier). URI je adresa kon-cového zařízení. V SIP sítích se tedy Redirect server využívá (obdobnějako Proxy server) ke zjištění cílové IP adresy volaného uživatele, nic-meně na rozdíl od Proxy serveru nepřeposílá žádosti klienta. Redirectserver využívá k vyhledání IP adresy lokalizační služby.

Registrar server (Registrační server)

Registrar je server, ke kterému se mohou UA registrovat, čímž serverzískává jejich IP adresu, port, uživatelské jméno, které dále poskytnelokalizačnímu serveru. UA v registračním požadavku definuje dobu,po kterou chce být registrován. Pokud UA v požadavku o registracinespecifikuje dobu, po kterou chce být registrován, platí jeho registracepo dobu jedné hodiny. Po uplynutí registračního intervalu je potřebaregistraci obnovit.

Location server (Lokační server)

Location server poskytuje informace o umístění klientů (IP adresa,port, uživatelské jméno) Proxy serveru a Redirect serveru. K výměně

9


informaci s Proxy a Redirect serverem často využívá protokolu LDAP(Lightweight Directory Access Protocol), což je protokol pro přístupk datům na adresářovém serveru.

Zprávy používané pro signalizaci na bázi protokolu SIP

SIP zprávy se skládají ze tří až čtyř sekcí.

∙ První řádek SIP zprávy udává vždy typ požadavku.

∙ Poté nasledují povinné a rozšiřující hlavičky.

∙ Za SIP hlavičkami se nachází prázdný řádek.

∙ Za prázdným řádkem může a nemusí být tělo zprávy.

Některé ze zpráv definovaných protokolem SIP

∙ REGISTER - žádost o registraci klienta u registračního serveru

∙ INVITE - žádost o navázání spojení nebo o změnu parametrůjiž existujícího spojení.

∙ BYE - žádost o ukončení spojení

∙ ACK - žádost, kterou klient potvrzuje, že obdržel odpověď nažádost INVITE

∙ CANCEL - žádost o zrušení probíhající žádosti INVITE

∙ UPDATE - dovoluje klientovi aktualizovat parametry spojení

Registrace (Register)

Registrace je proces, během kterého UA zašle zprávu SIP REGISTERna Registrační server (viz. F1 na obrázku 1.2).

10


1. Užívatelský agent v tomto požadavku sdělí Registračnímu ser-veru svou Address of record (AOR) , což jsou identifikační údajeklienta ve formátu SIP:uživatel@doména. AOR je užitečné prosměrování na vyšší úrovni, ale jelikož může být asociováno svíce lokacemi (tedy více zařízeními), je k registraci konkrétníhozařízení potřeba specifičtější adresa, čehož se dosáhne spojenímAOR a adresy IP. Ve zprávách SIP slouží k propojení AOR a IPadresy hlavička Contact (viz. výpis 1.1).

2. Registrační server na požadavek o registraci odpoví zprávouSIP/2.0 401 Unauthorized (F2 v obrázku 1.2) s hlavičkouWWW-Authenticate, ta obsahuje data, která musí být klientempoužita k zašifrování hesla. Hlavička WWW-Authentacate obsa-huje zejména Nonce (Number Once) , což je číslo, které musíklient využít k zašifrování svého hesla a dále pak obsahuje ná-zev šifrovacího algoritmu.

3. Klient následně zašle na Registrační server druhou zprávuREGISTER (F3 v obrázku 1.2). Tato registrační zpráva musí ob-sahovat hlavičku Authorization, ve které je klientovo zašifrovanéheslo.

4. Pokud je heslo korektní, zašle Registrační server klientu odpověďSIP/2.0 200 OK.

Obrázek 1.2: Průběh úspěšné SIP registrace

11


SIP registrace jsou pouze dočasné, je tedy potřeba při registraciklienta definovat čas, po který má být daná registrace platná. V regis-trační zprávě k tomuto účelu slouží hlavička Expires. Pokud se jedná oobnovení registrace, musí zpráva REGISTER obsahovat v hlavičkáchTo, From, Contact, call-ID a From tag stejné hodnoty, jako původní regis-trační zpráva, v opačném případě je zpráva vyhodnocena jako pokuso novou registraci. Ke zrušení registrace se využívá zprávy REGISTERs hlavickou Expires obsahující hodnotou 0 [5].

Výpis 1.1: SIP zpráva REGISTERREGISTER sips:ss2.biloxi. example .com SIP /2.0Via: SIP /2.0/ TLS client.biloxi. example .com :5061; branch= z9hG4bKnashd92Max - Forwards : 70From: Bob <sips: bob@biloxi . example .com >; tag= ja743ks76zlflHTo: Bob <sips: bob@biloxi . example .com >Call -ID: 1 j9FpLxk3uxtm8tn@biloxi . example .comCSeq: 2 REGISTERContact : <sips: bob@client .biloxi. example .com >Authorization : Digest username =" bob", realm =" atlanta . example .com"nonce =" ea9c8e88df84f1cec4341ae6cbe5a359 ", opaque ="",uri =" sips:ss2.biloxi. example .com",response =" dfe56131d1958046689d83306477ecc "Content -Length: 0

SIP INVITE

Jak je vidět z obrázku 1.3, hovor je iniciován SIP zprávou INVITE, jejížstruktura je popsána v následující podsekci.

První řádek ve výpisu 1.2 udává typ SIP zprávy, cílového uži-vatele a verzi protokolu SIP. Z uvedené ukázky kódu lze odpozo-rovat, že se jedná o zprávu typu INVITE, jejímž cílem je uživatelsip:[email protected] a je využíván protokol SIP ve verzi 2.0(současná verze).

Hlavička Via určuje verzi protokolu SIP, transportní protokol (v pří-padě ukázky 1.2 jde o protokol TCP) a cestu, která by měla být dodr-žena při zaslání odpovědi. Parametr branch slouží k identifikaci a jehohodnota se v rámci odpovědí na jeden požadavek nemění. Hlaviček

12


Via může SIP zpráva obsahovat více, jelikož tato hlavička může býtpřidána dalšími servery, přes které zpráva prochází.

Hlavička Max-Forwards se používá k omezení počtu uzlů, přeskteré zpráva projde, než dojde cíli. Princip hlavičky Max-Forwards jepoměrně jednoduchý, každý uzel po cestě k cíli sníží hodnotu tétohlavičky o jedna. Pokud hodnota této hlavičky dosáhne 0 ještě předdosažením cíle, je celá SIP zpráva odmítnuta a odesílateli je odeslánaSIP zpráva s číslem 483 Too Many Hops. Využitím této hlavičky setak zamezí nekonečnému přeposílání zprávy. Standardní hodnotaMax-Forwards při vyslání zprávy odesílatelem je 70.

Hlavička From nám říká, od koho zpráva pochází. V případě ro-zebírané ukázky se jedná o zprávu od sip:[email protected] tag se využívá k identifikaci dialogu.

Hlavička To slouží k uložení příjemce zprávy, což je v případězmiňované ukázky <sip:[email protected]>. Tato hlavička neobsa-huje parametr tag, jelikož ten je doplněn až později příjemcem zprávy.

Hlavička Call-ID slouží k jednoznačné identifikaci hovoru. Všechnyzprávy v rámci konkrétního dialogu musí použít stejné Call-ID. Běž-ným způsobem, jak zajistit, že bude hodnota této hlavičky globálněunikátní, je vygenerování náhodného čísla (musí být unikátní proodesílatele) na straně odesilatele, za které se připojí odesilatelova IPadresa.

CSeq (Command Sequence) se používá k identifikaci počtu poža-davků určitého typu. V ukázce 1.2 jde o první zprávu typu INVITE.Číslo se zvyšuje s každou další zprávou daného typu.

Hlavička Contact obsahuje URI uživatele a váže na konkrétní za-řízení. Contact tedy obsahuje adresu, na které lze zařízení najít. Lzevyužít například pro přímé spojení bez serverů proxy. Tato hlavičkaje povinná u zpráv typu INVITE a odpovědí 200 OK.

Hlavička Content-type hlavička udává typ těla SIP zprávy (pokudje přítomné). Ve výše zmiňované ukázce INVITE zprávy se jedná otělo formátované dle protokolu SDP.

Content-Length udává velikost těla zprávy v bytech. V ukázcejde o tělo velkosti 151 bytů. Pokud zpráva žádné tělo nemá, je tatoskutečnost reprezentována hodnotou 0. [6]

13


Výpis 1.2: SIP zpráva INVITEINVITE sip: bob@biloxi . example .com SIP /2.0Via: SIP /2.0/ TCP client. atlanta . example .com :5060; branch= z9hG4bK74bf9Max - Forwards : 70From: Alice <sip: alice@atlanta . example .com >; tag =9 fxced76slTo: Bob <sip: bob@biloxi . example .com >Call -ID: 3848276298220188511 @atlanta . example .comCSeq: 1 INVITEContact : <sip: alice@client . atlanta . example .com; transport =tcp >Content -Type: application /sdpContent -Length: 151

v=0o=alice 2890844526 2890844526 IN IP4 client. atlanta . example .coms=-c=IN IP4 192.0.2.101t=0 0m=audio 49172 RTP/AVP 0a=rtpmap :0 PCMU /8000

Obrázek 1.3: Průběh navázání spojení mezi Alicí a Bobem

14


Průběh navázání spojení mezi Alici a Bobem

Průběh úspěšného ustanovení hovoru (viz. obrázek 1.3 probíhá násle-dovně:

1. Alice odešle zprávu INVITE na proxy server.

2. Po přijetí zprávy INVITE odpovídá Proxy server jejímu odesí-lateli ihned zprávou 100 TRYING, z čehož Alice zjistí, že nenípotřeba zprávu INVITE znovu přeposílat.

3. Dále Proxy server vyhledá adresu Boba v lokalizačním serverua přepošle na ni INVITE, který získal od Alice.

4. Jakmile Bob obdrží zprávu INVITE, zašle na proxy server zprávu180 RINGING, což znamená, že hovor začal u cíle vyzvánět.Proxy server přepošle 180 RINGING k Alici.

5. Pokud Bob hovor přijme, zašle Alici zprávuemph200 OK (viz. výpis 1.3).

6. Alice po přijetí 200 OK potvrdí spojení zprávou ACK. Současněs odesláním potvrzovací zprávy ACK je hovor ustanoven a meziAlicí a Bobem začnou proudit RTP pakety. [7]

I když jde zpráva 200 OK v opačném směru (tedy od Boba k Alici),hlavičky From a To zůstávají nezměněny a to z důvodu, že jde o od-pověď na žádost (INVITE). Zpráva 200 OK ve svém těle obsahujepreference Boba (kodeky, čísla portů, a podobně). [8]

Výpis 1.3: SIP odpověd 200 OKSIP /2.0 200 OKVia: SIP /2.0/ UDP ss2.biloxi. example .com :5060; branch= z9hG4bK2d4790 .1; received =192.0.2.222Via: SIP /2.0/ UDP client. atlanta . example .com :5060; branch= z9hG4bK74bf9; received =192.0.2.101From: Alice <sip: alice@atlanta . example .com >; tag =9 fxced76slTo: Bob <sip: bob@biloxi . example .com >; tag =314159Call -ID: 2 xTb9vxSit55XU7p8@atlanta . example .com

15


CSeq: 1 INVITEContact : <sip: bob@client .biloxi. example .com >Content -Type: application /sdpContent -Length: 147

v=0o=bob 2890844527 2890844527 IN IP4 client.biloxi. example .coms=-c=IN IP4 192.0.2.201t=0 0m=audio 3456 RTP/AVP 0a=rtpmap :0 PCMU /8000

BYE

Ukončení hovoru se provádí pomocí zprávy BYE (viz. výpis 1.4). Ho-vor může ukončit kterákoliv strana. Zprávu BYE je nutné potvrditpomocí zprávy 200 OK, jak je vidět na obrázku 1.3, kde Bob zašle Alicizprávu BYE pro ukončení hovoru a Alice ukončení potvrdí pomoci200 OK, které pošle zpět Bobovi.

Výpis 1.4: SIP zpráva BYEBYE sip: bob@client . chicago . example .com SIP /2.0Via: SIP /2.0/ UDP client. atlanta . example .com :5060; branch= z9hG4bK74bo4Max - Forwards : 70From: Alice <sip: alice@atlanta . example .com >; tag =9 fxced76slTo: Bob <sip: bob@biloxi . example .com >; tag =314159Call -ID: 2 xTb9vxSit55XU7p8@atlanta . example .comCSeq: 1 BYEContent -Length: 0

SIP odpovědi

Ve scénáři zachyceném na obrázku 1.3 je vidět pouze jedna z možnýchodpovědí, které SIP nabízí a to 200 OK. Odpovědi v protokolu SIPjsou rozděleny do šesti skupin dle jejich typu a to v rozmezí 100 až699. Každá odpověď je tedy označena trojciferným číslem, kde prvníčíslice značí typ odpovědi a zbyle dvě číslice pak konkrétní odpověď.

16


Skupina odpovědí 1xx

Skupina odpovědí 1xx (viz. tabulka 1.1) zahrnuje odpovědi informativ-ního charakteru. Tyto odpovědi jsou využívány během ustanovováníhovoru, kdy ještě není znám výsledek vyslaného požadavku. Klientse díky odpovědi typu 1xx dozví, že se jeho požadavek zpracovává.Těchto odpovědí může klient přijmout i více.

Tabulka 1.1: Skupina odpovědí 1xx

Kód Název100 Trying180 Ringing181 Call is Being Forwarded183 Session in Progress199 Early Dialog Terminated


Odpovědi skupiny 2xx (viz. tabulka 1.2) značí, že vyslaný požadavekbyl úspěšně zpracován. Nejčastěji se používá 200 OK.


Kód Název200 Ok202 Accepted204 No Notification


Skupina 3xx (viz. tabulka 1.3) obsahuje odpovědi týkající se přesmě-rování. UAC je pomocí těchto zpráv informován o jiné cestě k UAS.

17



Kód Název300 Multiple Choices301 Moved Permanently302 Moved Temporariry305 Use Proxy380 Alternate Service


Odpovědi ze skupiny 4xx (viz. tabulka 1.4) značí chybu ve zpracovánízprávy. Zprávy tohoto typu mohou pocházet od UAS nebo síťovéhoSIP prvku na cestě k UAS. Odpovědí ze skupiny 4xx je velké množství,takže zde uvedeme pouze ty častěji se vyskytující.


Kód Název400 Bad Request401 Unauthorized404 Not Found407 Proxy Authentication Required408 Request Timeout415 Unsupported Media Type


Skupina odpovědí typu 5xx (viz. tabulka 1.5) značí chybu na straněserveru. Tyto odpovědi jsou generovány proxy servery, lokalizačnímiservery a servery přesměrování.

18



Kód Název500 Server Internal Error501 Not Implemented502 Bad Gateway503 Service Unavailable504 Server Time-Out505 Version Not Supported513 Message Too Large580 Precondition Failure

Skupina odpovědi 6xx

Odpovědi ve formátu 6xx (viz. tabulka 1.6) značí globální chyby. Tytoodpovědi jsou platné v rámci celé sítě. [9]


Kód Název600 Busy Everywhere603 Decline604 Does Not Exist Anywhere606 Not Accepted

DTMF

Dual-tone multi-frequency (DTMF) je způsob kódování číslic, který lzevyužít například v Interactive Voice Systems (IVR). IVR jsou systémy,které vybízejí ke zmáčknutí čísla jako odpovědi na nějakou otázku.

DTMF funguje na principu vyhodnocení osmi od sebe dostatečněvzdálených frekvencí. Čtyři z nich patří do nižších a čtyři do vyššíchfrekvencí 1.4. Pro každou klávesu zazní jeden tón z nižší frekvence ajeden tón z vyšší frekvence, což jednoznačně identifikuje jednu z 16možných kláves.

19


Obrázek 1.4: Kódování DTMF tónů, dostupné z [10]

Pro přenos DTMF tónů muže být využita zpráva SIP INFO/NO-TIFY (out-of-band) a nebo v rámci RTP toku (in-band), což vyžadujepoužití neztrátových kodeků.

1.2.3 SDP

Session Description Protocol (SDP) je popsán v RFC 4566 [11]. SDP jeprotokol určený k vyjednání parametrů médií relace, jako je napříkladtyp média (audio, video), typ kodeku, adresa a port, na kterých klientmédia přijímá. [12].

Výpis 1.5: Session Descriptionv=0o=Andrew 2890844526 2890844526 IN IP4 10.120.42.3s= SDP Blogc=IN IP4 10.120.42.3t=0 0m=audio 49170 RTP/AVP 0 8 97a=rtpmap :0 PCMU /8000a=rtpmap :8 PCMA /8000a=rtpmap :97 iLBC /8000m=video 51372 RTP/AVP 31 32a=rtpmap :31 H261 /90000

SDP je textový protokol, což lze vidět na výpisu kódu 1.5, kterýse skládá z jednotlivých řádků ve formátu <znak>=<hodnota>, kde

20


<znak> je jediné písmeno (závisí na jeho velikosti) značící typ atributua <hodnota> je strukturovaný text obsahující patřičné informace. CeláSDP zpráva se skládá ze třech sekcí - popisu relace, popisu času apopisu médií. Každá SDP zpráva může obsahovat více sekcí s popisemčasu a médií (např. audio a video zároveň), ale pouze jednu sekci spopisem relace. [13]

SDP atributů existuje celá řada a jejich kompletní seznam lze naléztv RFC 4566 [11]. V tomto textu budou popsány pouze ty důležitější zatributů.

Atribut v (version) obsahuje číslo verze SDP protokolu, současněmá vždy hodnotu 0.

Atribut o (origin) obsahuje několik mezerou od sebe oddělenýchhodnot, které poskytují informace o tvůrci relace a identifikátorurelace. Formát atributu origin viz výpis 1.6

Výpis 1.6: SDP atribut o (origin)o=<username > <sess -id > <sess -version > <nettype >

<addrtype > <unicast -address >

∙ <username> - Přihlašovací jméno uživatele (pokud není uve-deno, je nahrazeno znakem „-“). Přihlašovací jméno nesmí ob-sahovat mezeru.

∙ <sess-id> - Unikátní číselný identifikátor relace.

∙ <sess-version> - Verze popisu relace. Význam této hodnoty jeponechán na vytvářecím nástroji. Pokud se ovšem změní datarelace, její hodnota musí být zvýšena. Je doporučeno naplnitčasovou stopou.

∙ <nettype> - Specifikuje typ sítě. Např. „IN“ značí internet.

∙ <addrtype> - Značí typ adresy <unicast-address>, např. IPv4,IPv6.

∙ <unicast-address> - Obsahuje adresu zařízení, které zahájilospojení.

Hodnotou atributu s (session name) je název relace. Pole nesmíbýt prázdné, tudíž pokud nemá relace název, je jako hodnota atributus použit znak „-“.

21


Atribut c (connection data) obsahuje mezerou oddělenou trojicihodnot, které mají obdobné využití jako u atributu o. Tento atributnám říká, odkud (z jaké IP adresy) přijdou média, případně kam majíbýt média posílána. Formát atributu c viz výpis 1.7.

Výpis 1.7: SDP atribut c (connection data)c=<nettype > <addrtype > <connection -address >

Atribut m (media descriptions) je v SDP zahrnut pro každý na-bízený typ média. Pokud například klient podporuje audio i videopřenos, bude SDP obsahovat dva řádky m=, jeden pro audio, druhýpro video. Obdobně SDP obsahuje dva řádky m, pokud klient nabízízabezpečený a nezabezpečený RTP přenos. Formát atributu mediadescriptions viz. výpis 1.8

Výpis 1.8: SDP atribut m (media descriptions)m=<media > <port > <proto > <fmt >

∙ <media> - Udává typ médií, možné hodnoty jsou „audio“,„video“, „text“, „application“ a „message“.

∙ <port> - Udává transportní port, na který jsou posílána média.

∙ <poroto> - Značí transportní protokol, možné varianty jsou„udp“ (pro blíže nespecifikovaný protokol běžící nad protoko-lem UDP), „RTP/AVP“, „RTP/SAVP“ (zabezpečená verze RT-P/AVP).

∙ <fmt> - Obsahuje seznam čísel představující podporované typyRTP payloadu. Jejich význam je definován v [14]. Některé typyjsou pevně stanoveny, jiné mají určitý rozsah hodnot. Bližší spe-cifikace payload typů se provádí pomocí atributu a.

Atribut a (attributes) slouží k mapování typu payloadu z řádku mna jméno kodeku. Dále poskytuje informace o rychlosti vzorkovánídat a mohou následovat nepovinné parametry konkrétního kodeku.Formát atributu a viz výpis 1.9.

Výpis 1.9: SDP atribut a (attributes)a=rtpmap:< payload type > <encoding name >/< clock rate >

[/< encoding parameters >]

22


1.2.4 STUN server

Kvůli nedostatku IP adres verze 4 (zkráceně IPv4) byl zaveden novýzpůsob pro překlad síťových adres s názvem NAT (Network AdressTranslation). NAT způsobí, že zařízením v rámci privátní sítě jsoupřiřazovány IP adresy unikátní pouze v rámci dané sítě, taková síťje skryta za zařízením, jako je například router. Router pak pomocíNAT funkcionality překládá IP adresy privátní sítě na jedinou adresuv rámci veřejné sítě (Internetu). Přestože uvedení NAT vyřešilo, neboalespoň odsunulo problémy docházejících IPv4 adres, adresace jakotaková se stala znatelně komplikovanější a přinesla tedy i nové pro-blémy, které je nutno řešit. Klient v privátní síti běžně nezná svojiveřejnou IP adresu, jelikož se při použití NAT funkcionality liší odjeho privátní adresy, musí klient nějakým způsobem svou veřejnou IPadresu zjistit.

STUN (Simple Traversal Utilities for NAT) server slouží právě kúčelu získání kombinace veřejné IP adresy a čísla portu aplikace, zekteré přišel požadavek na jeho zjištění. STUN server tedy příjme poža-davek na zjištění IP adresy a portu od klienta schovaného v privátnísítí za NAT a v odpovědi klientovi pošle IP adresu a port, ze kterépožadavek od klienta přišel [15]. Jedná se tedy o poměrně nenáročnouoperaci. Princip využití STUN serveru lze vidět na obr. 1.5.

1.2.5 TURN server

Traversal Using Relays around NAT (TURN) server je využit v pří-padě, že se nedaří navázat přímé spojení mezi klienty. To může býtzpůsobeno nastavením NAT, firewall2, případně jiných síťových prvků.TURN servery se nachází, stejně jako STUN servery, ve veřejné síti aslouží k přeposílání médií (viz 1.6), tím pádem je na ně kladena mno-hem větší zátěž, než je tomu u serverů STUN. Kvůli větším nárokůmnebývají, na rozdíl od STUN serverů, zdarma a jejich zapojení častovnáší do komunikace oproti přímému spojení mírné zpoždění, jelikožse do cesty přidává další uzel.

2. Zařízení nebo software, který řídí tok dat podle přesně stanovených pravidel,čímž brání před neoprávněnými průniky do sítě.

23


Obrázek 1.5: Použití STUN serveru k získání IP adresy a čísla portu.

Obrázek 1.6: Použití STUN i TURN serverů současně

24


1.2.6 ICE

Interactive Connectivity Establishment (ICE) je framework3, kterývyužívá STUN a TURN serverů pro překonání složitosti reálnýchsítí. ICE framework se pokusí najít nejlepší možnou cestu pro spojeníklientů a to tak, že se v první řadě za pomoci STUN serveru zjistit IPadresu ve veřejné síti a pokud se to nezdaří, využije pro přenos médiíTURN serveru.

Iniciující strana (dále referováno jako Alice) vyšle požadavky naSTUN server, ten vrátí kombinaci veřejné IP adresy a portu, ze kterépožadavek přišel, zpět Alici (Alice tedy získá svou veřejnou IP adresu).Získání párů IP adres a portů se anglicky nazývá gathering ICE candi-cates (sběr ICE kandidátů). Alice si všechny páry IP adres a portů uložía vloží je do SDP offer, kterou v rámci signalizace zaslšle na přijímajícístranu (dále referováno jako Bob). Bob provede na své straně opětsběr ICE kandidátů, ty uloží do SDP, které zašle jako odpověď Alici.Jakmile si obě strany vymění SDP, je pomocí ICE algoritmů vybrán párIP adresy a portu z SDP získané od protější strany (Alice tedy vybíráz SDP získaného od Boba a obráceně). Na vybranou kombinaci IP ad-resy a portu je zaslán STUN požadavek. Pokud je na tento požadavekodpovězeno, je kombinace IP adresy a portu považována jako validníICE kandidát. Jelikož je však sběr kandidátů poměrně pomalý, nečekáse na kompletní list, ale namísto toho jsou odesílány dávkově - tomutovylepšení se říká Trickle ICE. Trickle ICE s sebou nenese v porovnánís klasickým ICE žádné další nevýhody, jde tedy pouze o zrychlenícelého procesu. [16]

1.2.7 WebSocket

Web byl navržen na konceptu klient-server, ve kterém klient odesílápožadavky na server a server tyto požadavky obsluhuje. Šlo tedyvíceméně o kolekci mezi sebou propojených HTML stránek. Klientsi načetl stránku a na ní se nic nezměnilo, dokud uživatel neklikl nadalší stránku.

3. Znovupoužitelný software, který poskytuje určitou funkcionalitu, kterou lzevyužít v jiných softwarových programech.

25


Koncept webu se začal měnit s příchodem technologie AJAX4,díky čemuž se vývojářům otevřela možnost vývoje nového druhuwebových aplikaci, které ovšem vyžadují obousměrné spojení meziklientem a serverem. Základním problémem byl ovšem HTTP (Hy-pertext Transfer Protocol) model, u kterého spojení navazuje klient.Bylo navrženo mnoho přístupů, jak se s tímto problémem vypořádat.Jedním z nich je například long-polling, při kterém klient naváže seserverem HTTP spojení a server toto spojení udržuje otevřené, dokudnemá data, která chce klientu poslat. Nicméně žádný z přístupů ne-vyřešil hlavní neduhy HTTP komunikace, tedy zasílání zbytečnýchdat, případně opakovaného navazování spojení. Důvodem zasílánízbytečných dat je, že s každým HTTP požadavkem je na server ode-sláno několik často nepotřebných HTTP hlaviček a cookies (krátkétextové soubory uložené na straně klienta), což může způsobit zvýšeníodezvy v komunikaci mezi klientem a serverem. A právě zvýšenáodezva komunikace je v real-time aplikacích (např. hry ve webovémprohlížeči) velmi nevhodná.

Řešení problému obousměrné komunikace mezi klientem a ser-verem přinesl protokol WebSocket, který byl standardizován v roce2011 v RFC 6455 [17]. WebScoket protokol umožňuje ustanovení tr-valého obousměrného spojení mezi klientem a serverem, po kterémmůže každý z nich začít posílat data přes jedno TCP spojení. Spojeníje navázáno pomocí procesu nazývaného WebSocket handshake.

Data jsou přes WebSocket přenášena jako zprávy, z nichž každáse může skládat z více rámců. Každý rámec pak mimo přenášenádata obsahuje také informace o přenášených datech, což v konečnémdůsledku pomáhá ke snížení množství přenesených dat (přenáší semenší množství nepotřebných dat než u HTTP spojení) a tím i zrych-lení odezvy. [18]

WebSocket zároveň řeší problémy s proxy servery vytvořenímHTTP tunelu. HTTP tunel vznikne tak, že klient zašle proxy serveruzprávu HTTP CONNECT (viz. výpis 1.10), ve kterém je specifikováncíl a port zařízení, ke kterému se chce klient připojit. Proxy serverpak v reakci na HTTP CONNECT otevře TCP/IP spojení na cíl a port

4. Asynchronous JavaScript and XML - technologie umožňující změny obsahustránky bez jejich kompletního načtení.

26


specifikovaný v přijatém CONNECT požadavku. Po ustanovení tuneluuž už může další komunikace procházet skrze proxy server. [19]

Výpis 1.10: Požadavek na vytvoření HTTP tuneluCONNECT echo. websocket .org :80 HTTP /1.1Host: echo. websocket .orgProxy - Connection : keep -aliveConnection : keep -alive

WebSocket handshake

Celý proces ustanovení WebSocket spojení začíná tak, že klient odešleHTTP požadavek s hlavičkou Upgrade (viz. výpis 1.11), jejíž obsahemje textový řetězec „websocket“. Tím se příjemce (server) dozví, že chceklient navázat spojení přes WebSocket.

Výpis 1.11: Požadavek na otevření WebSocket spojeníGET ws :// websocket . example .com/ HTTP /1.1Origin: http :// example .comConnection : UpgradeHost: websocket . example .comUpgrade : websocket

Pokud server rozumí protokolu WebSocket, odpoví klientu HTTPodpovědí (viz. výpis 1.12), do které také přidá hlavičku „Upgrade:WebSocket“. Nově vzniklé WebSocket spojení nahradí původní HTTPspojení. WebSocket tedy využije stejné TPC/IP spojení, jako původníHTTP spojení. WebSocket defaultně využívá i stejné porty jako HTTPspojení, tedy 80 pro nešifrovanou verzi WebSocketu a port 443 prozabezpečenou verzi WebSocketu.

Výpis 1.12: Odpověď od serveru potvrzující vytvoření WebSocketspojeníHTTP /1.1 101 WebSocket Protocol HandshakeDate: Wed , 16 Oct 2013 10:07:34 GMTConnection : UpgradeUpgrade : WebSocket

27


SIP over WebSocket

Podprotokol SIP over Websocket popsaný v RFC 7118 [20] uvádí, jakvyužít WebSocket pro přenos SIP zpráv. Klient a server musí vyjednatužití pod-protokolu SIP over WebSocket během ustanovení WebSocketspojení. Klient musí do do svého požadavku o navázání spojení vložithlavičku Sec-WebSocket-Protocol s hodnotou „sip“ (viz výpis 1.13).

Výpis 1.13: Požadavek na vytvoření WebSocket spojení s využitímpodprotokolu SIP over WebSocketGET / HTTP /1.1Host: sip -ws. example .comUpgrade : websocketConnection : UpgradeSec -WebSocket -Key: dGhlIHNhbXBsZSBub25jZQ ==Origin: http :// www. example .comSec -WebSocket - Protocol : sipSec -WebSocket - Version : 13

Stejně tak server musí v odpovědi na požadavek o navázání Web-Socket spojení uvést hlavičku Sec-WebSocket-Protocol s hodnotou „sip“(viz. výpis 1.14). Po přijetí odpovědi od serveru je WebSocket spojeníustanoveno a připraveno k přenosu SIP žádostí a odpovědí.

Výpis 1.14: Odpověď od potvrzující využití pod-protokolu SIP overWebSocketHTTP /1.1 101 Switching ProtocolsUpgrade : websocketConnection : UpgradeSec -WebSocket -Accept: s3pPLMBiTxaQ9kYGzzhZRbK +xOo=Sec -WebSocket - Protocol : sip

Dále je třeba uvést některé zásady přenosu SIP zpráv skrze Web-Socket. Každá SIP zpráva musí být přenesena v rámci jedné WebSocketzprávy a zároveň WebSocket zpráva nesmí obsahovat více než jednuzprávu SIP. WebSocket umožňuje přenášet zprávy jak v textovýchrámcích, tak v binárních rámcích. Stejně tak SIP podporuje textové ibinární tělo SIP požadavků a odpovědí, kvůli čemuž musí WebSocketklient i WebSocket server přijímat zprávy v textové i binární podobě.

28


Přenos přes WebSocket zachovává velikost zpráv, tudíž není potřebav SIP zprávách využívat hlavičky Content-Length, což zjednodušujeanalyzování zpráv pro klienta i server.

SIP zprávy využívající jako transport WebSocket mají jako trans-port uvedeno „WS“ (značící přenos přes nezabezpečený WebSocket)nebo „WSS“ (viz. výpis 1.15), které značí přenos skrze zabezpečenýWebSocket.

Výpis 1.15: SIP zpráva REGISTER přenášená přes WebSocketREGISTER sip:proxy. example .com SIP /2.0Via: SIP /2.0/ WSS df7jal23ls0d . invalid ;branch= z9hG4bKasudfFrom: sip: alice@example .com;tag =65 bnmj .34 asdTo: sip: alice@example .com

1.3 Média

Pojem média zahrnuje vlastní audio a video data rozdělená do paketů,které se přenáší mezi koncovými zařízeními. Konkrétní parametrya vlastnosti spojení jako například transportní protokol, kodeky prokódování a mnohé další, jsou vyjednány v rámi signalizace.

1.3.1 RTP, RTCP

Real-time Transport Protocol (RTP) je binární protokol, který je popsánv RFC 3550 [21]. RTP poskytuje podporu pro přenos dat v reálném čase,přičemž takovými daty může být například audio a video přenos. Připřenosu zvuku a videa může dojít ke ztrátám paketů, avšak u přenosudat (audio, video) v reálném čase spíše záleží na rychlosti doručení,než na stoprocentním doručení všech paketů. Soudobé kodeky senavíc dokáží s mírnou ztrátou paketů vypořádat. Z těchto důvodůse pro přenos RTP většinou využívá transportního protokolu UDP,který sice nezaručí stoprocentní doručení paketů, ale na druhou stranunezpomaluje přenos přeposíláním nedoručených paketů.

Port, na který jsou zasílány RTP pakety, je alokován dynamicky přinavazování spojení. V rámci SIP signalizace je vyjednán pomocí SDPtěla SIP zprávy (řádek m=). Obvykle se jedná o UDP port v rozsahu od1024 do 65535, přičemž RPT typicky obsazuje sudá čísla portů a s ním

29


související RTCP protokol typicky obsazuje port s lichým číslem (ojedna větší než RTP). Data jsou po RTP toku posílána pouze v jednomsměru, takže je při telefonním hovoru pro každého účastníka vytvořenjeden tok, po kterém odesílá svá data. [22]

Struktura RTP paketu

Hlavička RTP paketu (viz obrázek 1.7) má základní velikost 12 B (byte),za ní může následovat rozšiřující hlavička. Dále už následují samotnápřenášená data.

Obrázek 1.7: Struktura hlavičky RTP paketu, dostupné z [21]

Hlavička RTP paketu obsahuje jako první informaci o verzi proto-kolu V (version number), jeho hodnota je současně 2. Dále následuje bitP (padding), který značí, zda je paket na svém konci doplněn nulamina určitou délku (může být vyžadováno některými aplikacemi neboalgoritmy). Bit X (extension) značí, zda je za základní hlavičkou ještěrozšiřující hlavička. Dále pole CC (CSRC count) obsahuje číslo , kteréznačí počet identifikátorů zdrojů přispívajících do přenášených dat. BitM (marker bit) nemá pevně dané využití, může sloužit pro označenínějakým způsobem významného paketu. Payload type (PT) obsahujeidentifikátor kodeku použitého pro kódování přenášených dat, popisjednotlivých kodeků lze nalézt na [14]. Pole Sequence number obsahujepořadové číslo paketu, které je s každým dalším paketem zvýšeno ojedna. Pořadové číslo paketu může být příjemcem použito k odhaleníztráty paketů, případně k seřazení paketů do správného pořadí, po-kud se po cestě k cíli jejich pořadí promíchalo. Dále následuje časové

30


razítko (timestamp) vygenerování přenášených dat, které se využívá prosynchronizaci. Synchronization source identifier (SSRC) obsahuje jedno-značný (náhodně zvolený) identifikátor zdroje vysílajícího přenášenádata. [22]

Real-time Transfer Control Protocol (RTCP) je svázán s protokolemRTP, dokonce jsou definovány v rámci stejného RFC 3550 [21]. Přestose protokol RTCP nepoužívá k přenosu dat v reálném čase. ProtokolRTCP se využívá k řízení toku dat přenášených pomocí protokolu RTP.RTCP protokol poskytuje účastníkům RTP relace informace o kvalitědoručování dat. [23]

Mezi hlavní funkce RTCP patří:

∙ monitorování kvality přenosu dat, poskytnutí zábrany proti za-hlcení sítě

∙ identifikace zdrojů RTP paketů

∙ odhad velikosti relace (počtu účastníků) a růstu množství kont-rolních dat

RTCP pakety obsahují informace pro monitorování kvality přenosudat. Pomocí zpráv SR a RR (popsaných v podsekcích 1.3.1 a 1.3.1) siúčastnící vyměňují informace o ztracených paketech, zpoždění a jitteru.Tyto informace mohou být využity pro monitorování vytíženosti sítěbez nahlížení na přenášená data. Zároveň je díky těmto informacímmožné nad UDP (na aplikační úrovni) vybudovat obdobu řízení tokudat známou z TCP.

RTCP pakety obsahují identifikátor CNAME (canoical name) všechúčastníků relace. Zdroje RTP paketů jsou sice identifikovány pomocíSSRC, ale aplikace může využívat více RTP toků, které mohou býtspolečně asociovány pomocí jediného CNAME.

Každý účastník relace (vyměňující data pomocí protokolu RTP)zasílá periodicky RTCP pakety všem účastníkům relace. S rostoucímpočtem účastníků relace tedy roste i množství RTCP paketů, které siúčastníci vyměňují. Aby nedošlo k zahlcení sítě, je množství těchtopaketů limitováno a to tak, aby RTCP pakety tvořily 5 % celkovéhomnožství přenesených paketů.

31


Formát RTCP paketu

Všechny RTCP zprávy obsahují stejnou hlavičku (viz obrázek 1.8, kteráje velmi podobná hlavičce RTP paketu. Pole V obsahuje verzi RTCPprotokolu, v současné době obsahuje hodnotu 2. Padding (P), stejnějako u RTP hlavičky, obsahuje informaci o doplnění velikosti paketu naurčitou velikost. V poli RC (reception report count) je uložen počet RR(receiver reportů) obsažených v rámci daného paketu. Dále následujepole payload type (PT), které značí typ RTCP paketu. V poli length jeuložena velikost RTCP paketu a hodnota uložená v poli SSRC (Syn-chronization source identifier) slouží k jednoznačné identifikaci zdrojedatového toku.

Obrázek 1.8: Struktura hlavičky RTCP paketu, dostupné z [24]

Typy RTCP zpráv:

∙ Sender report (SR)

∙ Receiver report (RR)

∙ Source description (SDES)

∙ BYE

∙ Application-specific message (APP)

Sender report (SR)

Sender report obsahuje časovou značku (počet sekund od 1. ledna1970), kterou může příjemce využít k synchronizaci RTP zpráv (na-příklad synchronizace datových toků přenášejících audio a video).Dále SR obsahuje počet odeslaných paketů a množství odeslanýchdat. Pomocí těchto informací může příjemce zjistit, kolik dat se běhempřenosu ztratilo.

32


Receiver report (RR)

Receiver report posílají účastníci RTP relace, kteří do sítě neodesílajíRTP pakety. Struktura RR je podobna struktuře zprávy SR, ale neobsa-huje informace o počtu odeslaných paketů. Naopak zpráva obsahuječíslo vyjadřující podíl ztracených a očekávaných paketů od posled-ního reportu. Dále pak obsahuje číslo, které vyjadřuje celkový početztracených paketů od začátku komunikace. RR obsahuje i nejvyššípřijaté pořadové číslo paketu a průměrnou odchylku příchodu paketů.

Source description (SDES)

Zpráva SDES poskytuje informace o zdroji RTP dat. Může se jednato synchronization source nebo contributing source. Popis zdroje seskládá z identifikátoru zdroje (SSRS nebo CSRS), který je popsándodatečnými informacemi - CNAME (canoical name) ve formátu uži-vatel@host, které je jako jediné povinné, NAME, EMAIL, geografickélokace (souřadnice), telefonní číslo, název aplikace (TOOL), poznámky(NOTE) a soukromého rozšíření (PRIV).

BYE

Pomocí BYE paketu informuje zdroj ostatní účastníky o svém odchoduz relace. Paket BYE může obsahovat i popis důvodu pro opuštěnírelace.

Application-specific message (APP)

Zpráva typu APP slouží pro rozšíření RTCP protokolu, její konkrétnívyužití tedy závisí na aplikaci, která jej využívá.

1.3.2 SCTP

Protokol Stream Control Transmission Protocol (SCTP) je definovanýv RFC 4960 [25]. SCTP je transportní protokol (obdobně jako UDP aTCP), který může pracovat přímo nad IP protokolem.

Tabulka 1.7 ukazuje srovnání některých základních vlastností trans-portních protokolů UDP, TCP a SCTP. Hlavní výhodou protokolu SCTP

33


je konfigurovatelnost dvou transportních vlastností - spolehlivosti do-ručení paketů a doručení paketů v pořadí, v jakém byly vyslány. Dáleje SCTP orientován na zasílání zpráv (stejně jako protokol UDP) aobdobně jako TCP obsahuje mechanizmus pro řízení datového toku azahlcení.

Tabulka 1.7: Srovnání transportních protokolů UDP, TCP a SCTP

UDP TCP SCTPSpolehlivost nespolehlivé spolehlivé konfigurovatelnéDoručení v pořadí neseřazené seřazené konfigurovatelnéPřenos zprávy byte zprávyŘízení dat. toku ne ano anoŘízení zahlcení ne ano ano

Struktura SCTP paketu

SCTP paket (viz. obrázek 1.9) tvoří hlavička, za kterou následuje řídícínebo datový blok (chunk) . Hlavička SCTP paketu obsahuje číslo zdro-jového a cílového portu, náhodně vygenerovanou verifikační značkuspojení (verification tag) a kontrolní součet celého paketu (checksum).

Datový blok pak obsahuje typ chunku (type), typy chunků jsoudefinovány v RFC4940 [25]. Bit U značí, zda má být tento chunk do-ručen v pořadí, v jakém byl vyslán. Bity B a E značí, zda byla zprávarozdělena do více bloků. Length obsahuje velikost datového bloku (hla-vička datového bloku a samotná data). Transmission Sequence Number(TSN) je číslo, které se používá pro potvrzení doručení chunku, pří-padně pro detekci chunku, který dorazil k příjemci vícekrát. StreamIdentifier je identifikátor toku, ke kterému chunk patří. Stream SequenceNumber slouží k číslování zpráv, přičemž zprávy rozdělené do na vícečástí mají hodnotu Stream Sequence Number stejnou. Payload ProtocolIdentifier (PPID) slouží k doplnění dodatečných informací ohledněpřenášeného chunku.

34


Obrázek 1.9: Struktura SCTP paketu, dostupné z [26]

1.4 Tvorba webu

1.4.1 HTML5

HyperText Markup Language je počRounter pak pomocí NAT funkci-onality překládá IP adresy azyk, který stvorbě webových stránek. Vjeho páté verzi označované jako HTML5 bylo přidáno mnoho novýchelementů a jeho celkový návrh se zaměřil na věci jako oddělení defi-nice vzhledu a obsahu stránky, optimalizaci vzhledu pro zařízení srůznými rozlišeními a v neposlední řadě podporu multimédií bez nut-nosti instalace dalších modulů. Právě přidání podpory pro zpracováníaudio a video elementů umožňuje rozvoj nových multimediálníchaplikací fungujících přímo v prohlížeči.

HTML5 dále uvedlo dva typy úložiště ve webovém prohlížeči.Prvním z nich je localonStorage, které umožňuje ukládat data trvale.Druhým je sessionStrage, které ukládá data jen do doby ukončenírelace (data jsou smazána, když je webový prohlížeč zavřen).Dříve proukládání dat musely být využity soubory cookie, které se přenášely skaždým požadavkem na server. WebStorage oproti cookies dovolujeukládat větší objem dat.

1.4.2 JavaScript

JavaScript je objektově orientovaný, multiplatformní skriptovací jazyk,který byl vyvinut firmou Netscape v roce 1995. Jde o odlehčený jazyk,který se může v hostitelském prostředí vázat na objekty a poskytovat

35


tak prostředky k jejich ovládání [27]. JavaScript může být rozšířen a todvěma směry.

1.4.3 Klientský JavaScript

Prvním z nich je klientský JavaScript, který poskytuje objekty proovládání objektového modelu dokumentu (DOM5). V tomto případěvše běží na straně klienta, což je zásadní rozdíl oproti jazykům jakoPHP. Jeho zdrojový kód je odeslán serverem a přijat klientem spoluse zdrojovým kódem stránky, kde je poté proveden, zmírňuje tedynároky na samotný server. Mezi hlavní kladné vlastnosti klientskéverze JavaScritpu patří zcela jistě schopnost dynamicky upravovatobsah a vzhled stránky. Mnoho operací na webové stránce je použitímJavaScriptu urychleno, jelikož jsou prováděny přímo na straně klientaa nevyžadují tak komunikaci se serverem. Může jít například o některévýpočty, případně ověření formátu polí formuláře, který není nutnéodesílat pro ověření na server, dokud jeho obsah nesplňuje určitýformát a jiné definované požadavky.

1.4.4 Serverový JavaScript

Serverový JavaScript, jak už název napovídá, se od klientského JS lišív tom, že běží na serveru. Umožňuje například komunikaci s databázía práci se soubory umístěnými na serveru.

1.5 WebRTC

Před uvedením WebRTC bylo k posílání dat v reálném čase přímo zprohlížeče závislé na instalaci dodatečného modulu, jelikož webovéprohlížeče neposkytovaly RTC6 podporu. Instalace dodatečných mo-dulů s sebou nesla často mnoho problémů týkajících se stability webo-vých prohlížečů, případně mohly představovat bezpečnostní problém.Přestože vývojáři modulu mohou na nalezený bezpečnostní problémzareagovat rychle, samotná aktualizace modulu na nejnovější verzi užje v rukou koncových uživatelů.

5. Document Object Model6. Real-time communication - komunikace v reálném čase

36


Obrázek 1.10: Hlavní webové prohlížeče a jejich podpora WebRTCtechnologie, dostupné z [29]

Situace se změnila, když byla společnost Global IP Solutions (GIPS),která vyvíjela mnoho komponent potřebných pro RTC, odkoupenaspolečností Google. Společnost Google pak tyto technologie zveřejnilajako open source. První implementace WebRTC projektu byla zveřej-něna v roce 2011. Jak webové prohlížeče podporují WebRTC v rocedobě psaní této práce je zobrazeno na obrázku 1.10, kde zelená barvapod ikonou webového prohlížeče značí, že obsahuje plnou podporuWebRTC, žlutá barva značí částečnou podporu WebRTC a prohlížeč(Safari iOS) označený červenou barvou zatím podporu pro WebRTCneposkytuje.

Web Real-time Communication (WebRTC) je sada protokolů, stan-dardů a JavaScrip API [28], jež společně dodávají webovým prohlí-žečům podporu pro přenos dat v reálném čase. Jelikož je WebRTCintegrováno přímo ve webových prohlížečích, není nutné pro RTCpřenos instalovat jakýkoliv další modul. Zabudování RTC podporydo webových prohlížečů zahrnovalo přidání velkého množství novéfunkcionality (jako zpracování audia a videa), zabudování nových pro-tokolů a API. Webové prohlížeče tuto problematiku odstiňují pomocítřech JavaScript API, které poskytují vše potřebné pro tvorbu aplikacís RTC funkcionalitou.

Cílem WebRTC je poskytnutí podpory pro telekonferenční apli-kace v rámci webového prohlížeče a to bez instalací dodatečnýchmodulů. Tím pádem musí být prohlížeč schopen zachytit a zpracovataudio a video vstup (mikrofon a kamera). Čisté audio a video vstupypřímo z mikrofonu a kamery ovšem nejsou dostačující pro RTC ko-munikaci a jejich kvalita musí být pro účely RTC upravena. Stejnětak musí být bitrate těchto datových toků (audio a video) průběžněupravován s ohledem na měnící se šířku pásma a odezvu spojení mezikomunikujícími stranami.

37


1.5.1 Architektura WebRTC

Obrázek 1.11: Architektura WebRTC, dostupné z [30]

Pro zpracování audio a video vstupů obsahuje WebRTC vlastní voice(hlasový) a video engine (jádro zpracovávající hlas a video), viz obrá-zek 1.11.

Voice engine

Datový tok přenášející zvukovou stopu je nejprve voice enginem upra-ven pomocí algoritmů na redukci šumu [31] a redukci ozvěny [32].Následně je datový tok zakódován pomocí některého z dostupných ko-deků a je na něj použit algoritmus, který pomáhá skrýt chyby vzniklépřenosem po síti (více na [33]).

WebRTC implementace musí podporovat audio kodeky OPUS,G.711 a CN.

OPUS Audio kodek podporující konstantní i variabilní přenosovourychlost od 6 kbit/s do 510 kbit/s. Zahrnuje různé vzorkovacífrekvence od 8 kHz do 48 kHZ, čímž pokrývá celé lidmi slyšitelnéspektrum frekvencí.

38


G.711 Ztrátový kodek poskytující průměrnou kvalitu (využívá frek-vence 300-3400 Hz) s kompresí na 64 kbit/s.

CN Umělý šum , který se mezi uživateli posílá, pokud odesílatel ne-posílá žádný zvukový záznam nad určitým prahem slyšitelnosti.Umělý šum pomáhá šetřit množství přenesených data a zároveňdíky umělému šumu není přenášeno pouze naprosté ticho, kterémůže navodit pocit ukončeného spojení.

Video engine

Video engine provádí úpravu datových toků přenášejících video, čehoždosahuje zejména optimalizací kvality obrázků (odstranění šumu),výběrem vhodného kodeku a aplikací technik k zamaskování chybvzniklých přesunem paketů po síti.

Pro kompresi videa se u klientů založených na WebRTC využívákodeků VP8, H.264

VP8 Kodek VP8 je open-source kodek od společnosti Google a vyu-žívá se jako hlavní video kodek ve všech WebRTC implemen-tacích. Pro přenos vyžaduje šířku pásma 100 až 2000 (a více)Kbit/s.

H.264 Kodek H.264 (známý také pod názvem MPEG-4 Part 10 & Adva-ced Video Coding) je široce rozšířený kodek, který se už dlouhoudobu využívá pro streamování videa na internetu (nejedná se opřenos v reálném čase).

Transport

Komponenty, které obstarávají RTP přenos, jsou postaveny na základěkomponent z libjingle [34]. Libjingle je kolekce open-source zdrojo-vých kódů napsaných v jazyce C++, které obstarávají vytvoření síťo-vého spojení (skrze NAT, firewall, proxy servery a různé další síťovépřekážky), vyjednání detailů relace a výměně dat.

Web API

Vrstva Web API zobrazená na obr. 1.11, představuje kolekci JavaScrip-tovových API, které mohou využívat vývojáři ve webových aplikacích

39


pro záznam a přenos audio a (nebo) video stop, případně přenosudat libovolného typu přímo z webového prohlížeče a to bez nutnostiinstalace jakýchkoliv dalších modulů. Vrstva Web API se skládá zetří JavaScriptových API - MediaStream, RTCPeerConnection a RTCData-Channel.

∙ MediaStream API poskytuje přístup k mikrofonu, kameře aobrazovce spolu s podporou pro práci s nimi. Základem APIje objekt MediaStream, ten obsahuje až několik objektů typuMediaStreamTrack, které reprezentují audio nebo video stopu.

∙ RTCPeerConnection API poskytuje podporu pro efektivní pře-nos voice a video dat mezi účastníky.

∙ RTCDataChannel API slouží k přenosu libovolných dat (mimovoice a video).

WebRTC C++ API

API pro vývojáře webových prohlížečů, které jim umožní zprostřed-kovat technologii WebRTC skrze JavaScriptové API.

1.5.2 MediaStream API

Pro přístup k mikrofonu a kameře ve webovém prohlížeči bylo podlouhou dobu zapotřebí využívat dodatečných modulů jako Flashnebo Silverlight. To se změnilo s příchodem HTML5, které poskytujepřístup k různým hardwarovým zařízením. Konkrétněji pro přístup kdatovým tokům z mikrofonu a kamery slouží MediaStream API (viz.obrázek 1.12).

Základním objektem je MediaStream, který reprezentuje RTC tok.MediaStream obsahuje vzájemně synchronizované audio a video stopy(jednu či více), tyto stopy jsou reprezentované objektem MediaStre-amTrack.

Objekt typu MediaStream může mít jako vstup lokální kamerua mikrofon, případně příchozí datový tok jiného účastníka komuni-kace. Výstupem objektu typu MediaStream může být lokální elementschopný přehrát audio, popřípadě video nebo může být výstupemobjektu typu MediaStream spojení s jiným uživatelem.

40


Obrázek 1.12: MediaStream API, dostupné z [26]

Získání přístupu k mikrofonu a kameře

Ve výpisu 1.16 se na řádku číslo 2 vytvoří proměnná constraints, kteráslouží k vymezení, ke kterým zařízením chceme přistoupit. V pří-padě ukázky kódu je vyžadován audio i video vstup (s preferovanýmrozlišením kamery 1280x720 pixelů).

Hlavní metodou je zde getUserMedia(constratins), která bere jakoparametr dříve definované constraints. V případě, že se jí povede získatpřístup k požadovaným zařízením, použije se získaný MediaStreamobjekt jako vstup pro HTML5 element schopný přehrávat videa (řádekčíslo 7) a jakmile jsou načtena metadata videa, začne se přehrávataudio a video zachycené mikrofonem a kamerou.

V případě, že se nepodaří získat přístp k zařízením specifikovanýmpomocí proměnné constraints, je do konzole webového prohlížečevypsáno chybové hlášení (řádek číslo 12).

Výpis 1.16: Získání přístupu ke kameře a mikrofonu [35]1 // Prefer camera resolution nearest to 1280 x720.2 var constraints = { audio: true ,

video: { width: 1280 , height: 720 } };

3 navigator . mediaDevices . getUserMedia ( constraints )

41


4 .then( function ( mediaStream ) {5 var video = document . querySelector (’video ’);7 video. srcObject = mediaStream ;8 video. onloadedmetadata = function (e) {9 video.play ();10 };11 })12 .catch( function (err) { console .log(err.name + ": " + err. message ); }); // always check for errors at the end.

1.5.3 WebRTC signalizace

WebRTC neobsahuje žádnou signalizaci, její výběr a implementacebyly ponechány na konkrétní aplikaci. Tím, že byla signalizace zá-měrně vynechána z WebRTC specifikace, je možné WebRTC zakompo-novat do širšího spektra již existujících telekomunikačních infrastruk-tur [26]. Tento přístup je popsán v rámci JavaScript Session Estab-lishmen Protocol (JSEP) [36].

„The thinking behind WebRTC call setup has been to fully specify andcontrol the media plane, but to leave the signaling plane up to the applicationas much as possible. The rationale is that different applications may prefer touse different protocols, such as the existing SIP or Jingle call signaling pro-tocols, or something custom to the particular application, perhaps for a noveluse case. In this approach, the key information that needs to be exchanged isthe multimedia session description, which specifies the necessary transportand media configuration information necessary to establish the media plane.“[36]

Signalizační kanál

Signalizace pro WebRTC pouze několik omezení - musí být zabez-pečená, obousměrná a druhá strana komunikace musí být schopnavyjednat parametry pomoci SDP nabídky a odpovědi. Jako komu-nikační kanál pro výměnu signalizačních zpráv může být využitoprotokolu HTTP, WebSocket, EventSource API a za speciálních pod-mínek i RTCDataChannel API.

Jelikož musí být signalizační kanál obousměrný, protokol HTTPv jeho základní podobě není pro realizaci signalizačního kanálu do-

42


stačující, ale je možné využit metody pro obejití klient-server modeluprotokolu HTTP zvané long-polling [37].

WebSocket protokol byl podrobněji popsán v sekci 1.2.7. Na rozdílod protokolu HTTP poskytuje WebSocket obousměrný komunikačníkanál, čímž se stává velmi vhodnou variantou pro přenos signalizač-ních zpráv WebRTC spojení.

EventSource API implementuje zasílání zpráv ze strany serverusměrem ke klientu. Klient se přihlásí k odběru zpráv SSE (Server-Sent Event) ze serveru. Když pak potřebuje server informovat klienta,využije k tomu právě zpráv SSE [38]. Pro komunikaci od klienta kserveru je pak možné využít XHR (XMLHttpPrequest), což je API,které umožňuje zasílat data z webového prohlížeče na server. Spo-jením EventSource API a XHR pak vzniká kanál, který umožňujeobousměrnou komunikaci.

RTCDataChannel může být s jistými omezeními využit pro sig-nalizaci. Bohužel však až po vyjednání IP adres, portů a využití ICE,z čehož plyne, že je v takovém případě potřeba pro prvotní signali-zaci využít některou z výše uvedeným možností (long-polling, Web-Socket, EventSoure API). Na druhou stranu může být signalizace skrzeRTCDataChannel mírné rychlejší, jelikož zasílá zprávy přímo mezikoncovými uživateli.

Signalizační protokoly pro WebRTC

Některými protokoly pro WebRTC signalizaci jsou například:

∙ Jednou z možností je protokol SIP, který byl popsán v sekci 1.2.2.Protokol SIP je běžně využíván k signalizaci v IP telefonii. Propropojení WebRTC klientů s existujícími SIP infrastrukturami sevyužívá signalizační protokol SIP over WebSocket, který spojujesignalizační protokol SIP a transportní protokol WebSocket.

∙ Jingle je rozšíření Extensible Messaging and Presence Protocol(XMPP), které XMPP přidává podporu pro správu VoIP (stejnětak pro videokonference) relací.

∙ Proprietarní protokol může být správnou volbou, pokud WebRTCaplikace není zamýšlena k používání s jinými sítěmi. Proprie-tární řešení může obsahovat pouze minimální signalizační funk-

43


cionalitu potřebnou pro danou aplikaci (na rozdíl od velmi roz-sáhlého protokolu SIP).

Vyjednání parametrů médií pomocí protokolu SDP

WebRTC využívá k vyjednání parametrů médií protokolu SDP. Nížebude popsán scénář z obrázku 1.13), ve kterém Amy zahajuje WebRTCkomunikaci s Bobem.

Obrázek 1.13: Princip JavaScript Session Establishmen Protocol, do-stupné z [26]

1. Amy vytvoří objekt RTCPeerConnection, vygeneruje SDP of-fer (nabídku) a ten si uloží do svého lokálního popisu médií(localDescription) a vygenerovanou SDP offer pošle Bobovi.

2. Jakmile Bob přijde SDP offer od Amy, vytvoří si vlastní RTCPeer-Connection objekt a do svého vzdáleného (remoteDescription)popisu médií si uloží SDP offer, který přijal od Amy.

3. Následně Bob vygeneruje SDP answer (odpověď), tu si uloží dosvého lokálního popisu médií a vygenerovanou odpověď odešleAmy.

4. Jakmile Amy přijme SDP odpověď od Boba, uloží si ji do svéhopopisu remoteDescription.

1.5.4 PeerConnection API

PeerConnection API představuje WebRTC spojení a je odpovědnéza efektivní přenos RTC dat mezi webovými prohlížeči. Mezi hlavní

44


úkoly PeerConnection patří získání parametrů lokálních médií (ko-deky, rozlišení, porty, atd.) ve formě SDP, navázání a správa spojení,zjištění ICE kandidátů, komunikace se STUN serverem, znovu vyjed-nání datových toků (v případě, že je vyžadováno). V neposlední řaděje nutno dodat, že objekt typu RTCPeerConnection je odpovědný zacelý životní cyklus RTC spojení.

Navázání WebRTC spojení

Aby bylo možné navázat RTC spojení, musí si být uživatele schopnivzájemně posílat pakety. To samozřejmě není problém, pokud jsou uži-vatelé ve stejné interní síti, jelikož mezi nimi není ani firewall, ani NAT.Pokud je ovšem každý z klientů připojen v jiné interní síti za NAT, jepotřeba mezi nimi najít cestu pro směrování paketu skrze veřejnousíť. O nalezení takovéto cesty se ve WebRTC stará ICE agent (mechani-zmus ICE je popsán v sekci 1.2.6), který součástí RTCPeerConnection.Ice agent má na starosti sběr lokálních ICE kandidátů a kontrolu ko-nektivity mezi účastníky spojení, na pozadí provádí zjišťování veřejnéIP adresy skrze STUN server a objevené lokální ICE kandidáty ukládádo objektu RTCPeerConnection.

Jakmile proběhne sběr ICE kandidátů, je na straně Amy vygene-rována SDP nabídka obsahující uložené ICE kandidáty. SDP nabídkaod Amy je následně odeslána Bobovi. Jakmile Amy přijme od BobaSDP odpověď (obsahující Bobovy ICE kandidáty), uloží si ji do svéhopopisu vzdálených médií (remote description). Pro ICE agenta je na-stavení remote description znamení, že má začít testovat konektivituna druhého uživatele (skrze přijatý seznam ICE kandidátů).

Pro otestování ICE konektivity posílá ICE agent zprávu STUNbinding request druhému účastníkovi, který na tuto zprávu musíodpovědět pomocí STUN response. Pokud je zpráva STUN bindingrequest odpovězena pomoci STUN reponse, je nalezena cesta mezioběma účastníky a tím pádem je mezi těmito účastníky vytvořenoWebRTC spojení. V případě, že není pomocí ICE kandidátů nalezenažádná směrovací cesta, je buďto využit TURN server, nebo je spojeníukončeno jako chybné.

45


1.5.5 WebRTC Brána (gateway)

Obrázek 1.14: WebRTC lichoběžník, dostupné z [39]

WebRTC Brána slouží k propojení WebRTC klientů s klienty komu-nikujícími skrze jiné protokoly (například SIP). Na obrázku 1.14 jevidět dvě WebRTC brány různých poskytovatelů (application provi-der X a application provider Y), které mezi sebou komunikují pomocísignalizačního protokolu SIP. Ke každé WebRTC bráně je připojenWebRTC klient, jelikož však WebRTC nemá pevně stanovený způsobsignalizace, mohou tito WebRTC klienti se serverem komunikovatjiným protokolem.

Pokud chce jeden WebRTC klient (připojený k poskytovateli X)na obrázku 1.14 zahájit konverzaci s druhým WebRTC klientem (při-pojeným na poskytovateli Y), jde signalizace od WebRTC klienta kWebRTC bráně (poskytovatel X), ta přeloží jeho signalizační proto-kol na SIP, kterým komunikuje s poskytovatelem Y. WebRTC brána uposkytovatele Y následně přeloží zprávu SIP do signalizačního proto-kolu, kterým komunikuje WebRTC klient připojený k WebRTC bráněu poskytovatele Y.

Stejně tak je možné kombinací WebRTC brány a PSTN brány propo-jit hovor z prohlížeče (WebRTC klient) s PSTN telefonem. Nutno dodat,že v tomto případě se nejedná o přímé spojení mezi prohlížečem aPSTN telefonem, RTP data jsou pak směrována skrze servery.

46


Překlad signalizace a RTC mezi WebRTC a SIP klienty

WebRTC brána musí v být schopna překládat jak signalizaci, tak RTCkomunikaci. WebRTC signalizace není nijak standardizovaná, nedáse tedy obecně říct, jak komplexní tento překlad signalizace bude. Vpřípadě, že WebRTC klient využívá pro signalizaci protokol SIP overWebSocket a má být napojen do existující SIP infrastruktury, WebRTCbrána pouze „změní“ transportní vrstvu SIP zpráv z protokolu Web-Socket na UDP/TCP/TLS (a opačně v případě zpráv jdoucích směremk WebRTC klientu).

WebRTC musí pro RTC přenos využívat protokolu SRTP (defino-váno WebRTC specifikací), ale ne všechny zařízení v rámci existujícíinfrastruktury musí nutně SRTP podporovat. Pokud zařízení SRTP ne-podporuje (nebo nemá jeho využití nastaveno), musí WebRTC bránamapovat média mezi SRTP a RTP. Stejně tak WebRTC specifikace dik-tuje jako povinné pouze dva audio kodeky - OPUS a G.711. V případě,že zařízení v SIP síti tyto kodeky neumí, musí WebRTC brána pře-kládat média mezi kodeky obou klientů a nejde tedy o přímé spojenímezi koncovými klienty.

1.5.6 DataChannel API

WebRTC není omezeno pouze na přenos médií, naopak umožňujeobousměrný přenos libovolných dat mezi koncovými uživateli. Propřenos dat libovolného typu slouží DataChannel API, které je na rozdílod PeerConnection API uzpůsobeno pro spolehlivý i pro nespoleh-livý přenos dat. Podpora spolehlivého přenosu je u DataChannel APIkriticky důležitá, jelikož například u přenosu souborů mezi klientymusí být zaručeno, že budou všechny pakety doručeny (na rozdíl odRTC komunikace, která se s mírnými ztrátami paketů dokáže vypořá-dat). Transportní protokol SRTP (využívaný PeerConnection API) neníkvůli jeho zaměření na přenos médií vhodný pro přenos dat skrzeRTCDataChannel. WebRTC specifikace klade na transportní protokolpro RTCDataChannel několik požadavků. [26]

Požadavky na transportní protokol pro RTCDataChannel

∙ Protokol musí podporovat doručení zpráv v odesílaném pořadíi mimo pořadí.

47


∙ Protokol musí podporovat spolehlivé i nespolehlivé doručovánízpráv.

∙ Každý kanál musí mít aplikací definovanou prioritní úroveň.

∙ Protokol musí poskytovat API založené na zprávách.

∙ Protokol musí poskytovat prostředky pro řízení toku dat a zahl-cení.

∙ Protokol musí poskytovat záruku integrity a důvěryhodnostipřenášených dat. [26]

∙ Protokol musí umožnit fragmentaci přenášených zpráv.

Kombinaci výše zmíněných požadavků splňuje protokol SCTP(popsaný v kapitole 1.3.2). SCTP je transportní protokol (obdobně jakoUDP a TCP), který může pracovat přímo nad IP protokolem. Přesto žeje protokol SCTP poměrně starý (jeho první specifikace vznikaly okoloroku 2000), není mnohými operačními systémy dodnes podporován(například operační systém Windows SCTP nepodporuje dodnes).Pro účely WebRTC je SCTP tunelováno přes zabezpečený DTLS tunel,který je vytvořen nad protokolem UDP. [40]

Požadavek na doručení zpráv je v SCTP umožněn díky identi-fikátoru Stream Sequence Number, které je přiděleno každé zprávě. Vpřípadě, že je zpráva rozdělena na více fragmentů, mají tyto fragmentystejné číslo zprávy.

K multiplexování se v SCTP využívá identifikátoru Stream iden-tifier, který identifikuje jednotlivé toky. Každý chunk obsahuje tentoidentifikátor, díky čemu lze poznat, ke kterému toku patří.

SCTP také řeší fragmentaci zpráv, využívají se k tomu hodnoty Ba E z hlavičky chunku.

Požadavky na integritu a důvěryhodnost přenášených dat jsousplněny díky tunelování přes zabezpečený DTLS tunel.

Prioritizace toků není možné dosáhnout pouze pomocí informacíz hlavičky SCTP paketu, takže tato funkcionalita musí být implemen-tována jinde (na vyšší vrstvě).

48


Navázání spojení pro přenos dat

Navázání WebRTC spojení pro výměnu dat probíhá obdobně jakou navázání hovoru nebo videokonference. V rámci signalizace musímezi klienty proběhnout výměna parametrů spojení pomocí mechani-zmu SDP nabídky a odpovědi. O vygenerování patřičné SDP nabídky(obsahující datový kanál) se stará RTCPeerConnection, ke kterémumusí být před vygenerováním SDP nabídky registrován datový kanál.

SDP nabídka musí obsahovat informace potřebné pro vyjednáníSCTP spojení. V ukázce 1.17 je v atributem m specifikován přenos přesSCTP protokol, který je tunelován přes DTLS spojení běžící nad UDPprotokolem. Dále je v atributu m specifikováno, že SCPT spojení budepoužito pro „webrtc-datachannel“. UPD využije port 54111 a SCTPvyužije port 5000 (řádek „a=sctp-port:5000“).

Výpis 1.17: Část SDP nabídky obsahující datový kanálm= application 54111 UDP/DTLS/SCTP webrtc - datachannelc=IN IP6 2001: DB8 :: A8FDa=dtls -id:abc3dla=setup: actpassa=sctp -port :5000a=max -message -size :100000

SCTP v jeho základní podobě neposkytuje podporu pro nespo-lehlivé doručování zpráv. Za tímto účelem musí WebRTC využívatrozšíření SCTP protokolu s názvem Partial Reliability Extension, defi-nované v RFC3758 [41].

Data přenášená skrze DataChannel nejsou na rozdíl od audio amédií přenášených skrze PeerConnection nikterak upravována (médiajsou dynamicky upravována podle dostupné šířky pásma). Datovýkanál data nikterak nekomprimuje, takže jsou přenášena ve své ori-ginální velikosti (o jejich případnou komprimaci se musí postarataplikace). K tomu je třeba započítat režijní náklady (ve smyslu množ-ství dat a zpomalení), které do přenosu zavádí přenos přes protokolyUDP, DTLS a SCTP.

49


1.5.7 Zabezpečení WebRTC

Jedním z hlavních problémů real-time komunikace je možnost odpo-slouchávání komunikace třetí stranou. V případě, že jsou data meziwebovými prohlížeči nebo webovým prohlížečem a serverem přená-šena v nezašifrované podobě, mohou se snadno stát cílem odposlou-chávání. Pokud jsou však data šifrována, stávají se pro třetí stranunečitelná, jelikož nevlastní šifrovací klíč potřebný k jejich dešifrování.

V rámci WebRTC je šifrování povinné a to jak pro signalizaci, takpro přenášená média a data. Díky faktu, že je WebRTC spolu se šifro-vacími mechanizmy zabudováno ve webových prohlížečích, nemusíšifrování řešit samotní vývojáři webových aplikací. Požadavky nazabezpečení nelze ani nijak obejít, WebRTC aplikace musí se serve-rem komunikovat přes zabezpečené spojení a média, případně datajsou také šifrována, díky čemuž lze WebRTC spojení považovat zazabezpečené.

Pro šifrování využívá WebRTC dva šifrovací protokoly. Prvním znich je Secure Real-time Transfer Protocol (SRTP), který se využívápro šifrování audio a video toků. Datagram Transfer Layer Security(DTLS) se využívá pro šifrování datových toků, tedy data jdoucí skrzeRTCDataChannel.

DTLS

Datové kanály jsou ve WebRTC šifrovány pomocí protokolu DTLS,který je (a musí být) podporován všemi webovými prohlížeči s pod-porou WebRTC. Protokol DTLS je založen na protokolu TLS, kterýposkytuje plnou podporu šifrování dat. TLS je postaveno nad spoleh-livým protokolem TCP, což způsobuje, že je vhodný spíše pro datovékanály WebRTC, jelikož VoIP řešení využívají povětšinou transport-ního protokolu UDP.

SRTP

Protokol RTP, který se využívá pro přenos médií, neposkytuje žádnéprostředky pro šifrování. Tím pádem není možné použít pro pře-nos médií protokol RTP v jeho základní podobě. Namísto něj se vyu-žívá protokol SRTP (Secure Real-time Transfer Protocol) definovanýv RFC3711 [42], který je odlehčenější než DTLS a tím pádem i více

50


vhodný pro RTC, která klade důraz na nízkou odezvu. Prvotní vý-měna klíčů je u SRTP provedena přímo mezi koncovými uživatelipomocí DTLS-SRTP.

Ustanovení zabezpečeného spojení

Mezi dvěma komunikujícími stranami jsou prvně vyměněna signali-zační data, je provedena kontrola ICE kandidátů a následně obě stranyzačnou ustanovovat zabezpečený kanál (nebo i více kanálů). Na všechkanálech ustanovených přes ICE je prvně proveden DTLS handshake,což je pro datové kanály dostačující, jelikož musí být dle WebRTCspecifikace šifrovány pomocí DTLS. Pro zašifrování SRTP jde využítnapříklad SDES nebo DTLS-SRTP.

Vyjednání klíčů pro SRTP

Jednou z metod pro vyjednání klíčů pro SRTP je SDP Security Descrip-tions for Media Streams (SDES), který k přenosu klíčů a parametrůzabezpečení využívá protokolu SDP. Materiál zabezpečení je tedy vtomto případě přenášen v rámci signalizace. Dalším podstatným fak-tem je, že z využití SDP také vyplývá, že jsou šifrovací klíče pro médiavyjednány v textové podobě a je tedy potřeba využít protokol prozašifrování signalizačního kanálu. Hlavním problémem SDES všakzůstává fakt, že jsou signalizace a média šifrovány zvlášť. To můžepotenciálně vést k situaci, ve které mají signalizace a média různéhouživatele. Jelikož však SDES neposkytuje žádné prostředky pro zajiš-tění stejného uživatele pro signalizaci i média, byla tato metoda provyjednání klíčů nahrazena protokolem DTLS-SRTP.

WebRTC specifikace nařizuje podporu DTLS-SRTP a stejně takjeho volby jako hlavního schéma pro výměnu klíčů k šifrování SRTP.Na rozdíl od SDES probíhá u DTLS-SRTP výměna klíčů v rámci médií,čímž odpadá nebezpečí jejich odhalení (což byl problém výměny klíčůve formě SDP).

Přístup k mikrofonu a kameře

WebRTC pracuje s mikrofonem, kamerou, případně soubory uživatelea bez řádného ošetření by mohlo být narušeno uživatelovo soukromí

51


- webová stránka mohla bez vědomí uživatele získat audio, videozáznamy z mikrofonu a kamery, či soubory z jeho počítače. WebRTCtento problém řeší vynucením povolení o přístup k mikrofonu, kameře,či souborům v počítači a WebRTC aplikace tedy nemá možnost získatpřístup k těmto zařízením bez vědomí uživatele. Webový prohlížeč jezároveň povinen zobrazit skutečnost o využití mikrofonu, případněkamery v rámci svého uživatelského prostředí (viz obrázek 1.15).

Obrázek 1.15: Indikátor značící, že daná záložka využívá mikrofon(Google Chrome)

SOP

Same Origin Policy je vlastnost webových prohlížečů, která vyžaduje,aby byly všechny součásti webové stránky získány ze stejného zdroje.Typicky se jedná o nové načtení stránky, případně o požadavek oznovu-načtení ze strany skriptu. SOP vsak nedovoluje, aby skriptzaslal požadavek na získání zdrojů na jakýkoliv server, nýbrž musíjít o server, ze kterého skript pochází. Jednotlivé skripty jsou v rámciwebových prohlížečů pouštěny v sandboxech7, které jsou společnépouze pro skripty získané se stejného zdroje. Sandboxy tedy zároveňumožňují komunikaci skriptů ze stejného zdroje a zabraňují výměněinformací mezi skripty s různým původem. [43]

7. Prostor vyhrazen pro běh programu, či skriptu, ve kterém nemůže způsobitrozsáhlé škody.

52

2 Analýza existujících řešení

Technologie WebRTC byla uvedena již před sedmi lety a přes skromnézačátky v posledních letech zažila obrovský rozmach. Na konci roku2018 prošlo týdně webovým prohlížečem Google Chrome přes 1,5bilionu minut audio a video komunikace, což je nárůst o 45 % oprotipředešlému roku. Zároveň WebRTC využívá přes 1300 společností aprojektů.

2.1 Video-konferenční aplikace

Díky velkému rozmachu WebRTC technologie v posledních letechbylo vyvinuto mnoho aplikací na bázi WebRTC, které jsou schopnynapojení do SIP infrastruktury. Většina aplikací nabízí obdobnou funk-cionalitu a to video-konference (dvou a více účastníku), zasílání zpráv,hromadné konverzace.

OnSIP

Jednou z těchto video-konferenčních aplikací je aplikace GetOnSIP1

(viz obrázek 2.1) od společnosti OnSIP . Jedná se o aplikaci společnosti,která zároveň stojí za vývojem JavaScript knihovny SIP.js popsané vsekci 3.2.3. WebRTC je však touto aplikací využíváno pouze v prohlí-žečích Chrome a Firefox.

1. Dostupné z https://www.onsip.com/getonsip

53

2. Analýza existujících řešení

Obrázek 2.1: Ukázka WebRTC aplikace GetOnSIP

Circuit

Další obdobnou aplikací je Circuit2 (viz obrázek 2.2) od společnostiUnify. Aplikace umožňuje skupinové video konference, skupinovétextové chaty, správu kontaktů, sdílení plochy a sdílení souborů.

Obrázek 2.2: Ukázka WebRTC aplikace Circuit

2. Dostupné z https://www.circuit.com/register-for-trial

54

2. Analýza existujících řešení

Další aplikace založené na WebRTC

Mezi další aplikace, které využívají WebRTC (i když ne nutně spo-jené se SIP infrastrukturou) ať už pro video-konference nebo přenossouborů, patří následující široce rozšířené komunikační platformy.

∙ Google Hangouts

∙ Facebook Messenger

∙ Whatsapp

∙ Discord

55

3 Návrh vlastního řešení

3.1 Požadavky kladené na aplikaci

Cílem implementační části této práce je vytvoření VoIP telefonu fungu-jícího na bázi technologie WebRTC, jež bude schopen napojení do VoIPinfrastruktury fungující na bázi signalizačního protokolu SIP. Telefonmá být vytvořen za pomoci jazyků HTML (ve verzi 5), JavaScript a tobez nutnosti instalace jakýchkoli doplňujících zásuvných modulů.

Telefon by měl být schopen navázat VoIP spojení jak s jinými webo-vými klienty, tak klasickými soft-klienty v rámci SIP infrastruktury.Mezi další funkcionalitu implementovaného telefonu by mělo patřitzasílání DTMF tónů.

3.2 Použité knihovny

Stěžejním krokem při vývoji aplikace fungující na bázi technologieWebRTC je bezesporu výběr vhodného mechanizmu signalizace. Sig-nalizační mechanizmy jdou rozdělit do dvou kategorií - první mož-ností je implementace vlastního signalizačního mechanizmu a za dru-hou možnost lze považovat využití nějaké již existující knihovny na-psané v jazyce JavaScript. Pro různé účely může mít každý z přístupůsvé výhody.

Vlastní implementace má zcela jistě výhodu účelnosti, zaměření nakonkrétní aplikaci. Nevýhodou je zejména náročnost implementace,jelikož signalizačnímu mechanizmu aplikace musí rozumět i server(resp. brána), jelikož musí signalizační protokol telefonu namapovatna SIP, který je využíván v rámci SIP infrastruktury.

Využití některé již existující JavaScript knihovny obstarávající sig-nalizaci má výhodu v jednoduchosti zabudování do aplikace (zdrojovékódy knihovny se pouze naimportují do zdrojových kódu aplikace).Jako nevýhodu využití existující knihovny lze pak uvést závislostfunkčnosti aplikace na funkčnosti knihovny třetí strany. U knihoventřetí strany nemáme garanci, že ji její vývojáři nepřestanou podporovata stejně tak neovlivníme kdy a jestli vůbec opraví její objevené chyby.

Jelikož má být aplikace schopna napojení do SIP infrastrukturyreprezentované některou volně dostupnou pobočkovou ústřednou

57

3. Návrh vlastního řešení

(např. Asterisk), jako vhodnější varianta se jeví využití některé jižexistující signalizační knihovny třetí strany. Řada pobočkových ústře-den totiž ve svých nejnovějších implementacích obsahuje WebRTCbránu, která je schopna přijímat a navazovat WebSocket spojení. Web-Socket se svými vlastnostmi (obousměrná komunikace, zabezpečení)jeví jako nejvhodnější kandidát pro přenos signalizace. Jako signali-zační protokol se nabízí protokol SIP over WebSocket, který popisujepřenos SIP signalizace přes WebSocket spojení. WebRTC brány v uve-dených pobočkových ústřednách tomuto protokolu rozumí a dokážípak zprávy přeložit na klasický SIP (změnou transportního protokoluna UDP/TCP/TLS) a obdobně v opačném směru.

3.2.1 sipML5

Knihovnu SipML51 má na svědomí společnost Doubango Telecom,což je telekomunikační společnost zaměřující se na open-source pro-jekty. SIP knihovna sipML5 je k dispozici pod BSD licenci (volné šířeníobsahu, ale musí být uveden autor). Knihovna je napsána v jazyceJavaScript a pro přenos SIP zpráv využívá WebSocket (SIP over Web-Socket). Knihovna podporuje i různá rozšíření jako sdílení obrazovky,prezenci, zasílání textových zpráv, DTMF signalizaci a přenesení ho-voru. Společnost poskytuje i vlastní WebRTC bránu, která slouží knapojení WebRTC klientů do klasické SIP infrastruktury. Dokumen-tace k této knihovně je psána strukturovaně a i samotné zdrojové kódyjsou poměrně dobře okomentovány.

3.2.2 JsSIP

JsSIP2 je knihovna napsaná v jazyce JavaScript a stejně jako simML5poskytuje plnou podporu pro signalizaci na bázi protokolu SIP. Stejnětak JsSIP využívá k přenosu signalizačních zpráv WebSocket, čímžse stává kompatibilní s řadou pobočkových ústředen. Knihovna jevydaná pod MIT licencí, což je opět svobodná licence, která vyžaduje,aby byl text této licence šířen spolu s produktem, ke kterému se váže.Jednou věcí, kterou se autoři knihovny JsSIP pyšní, je, že se na jejímvývoji podíleli autoři protokolu Sip over WebSocket (RFC7118 [20]).

1. Více informací na https://www.doubango.org/sipml5/2. Více informací na http://jssip.net/

58


Knihovna JsSIP má rozsáhlou a kvalitně zpracovanou dokumen-taci. Zdrojové kódy působí strukturovaně (jsou rozděleny do řádovědesítek souborů).

3.2.3 SIP.js

SIP.js3 je, stejně jako sipML5 a JsSIP, knihovna napsaná v jazyce Ja-vaScript a poskytuje i obdobnou funkcionalitu, dokumentaci i oko-mentovanost zdrojových kódů jako dvě předešle uvedené knihovny.Knihovna SIP.js vznikla z knihovny JsSIP, když tým OnSIP4, kterývyvíjel vlastní WebRTC telefon založený na knihovně JsSIP, zjistil, žejim tato knihovna nepostačuje. Vytvořili tedy vlastní knihovnu (zalo-ženou na knihovně JsSIP), kterou upravili a vylepšili dle svých potřeba následně vypustili pod MIT licencí.

Jak jde poznat ze stručného popisu jednotlivých knihoven, volbamezi nimi není snadná, jelikož nabízí velmi obdobnou funkcionalitu.Nakonec je pro implementaci této práce využita knihovna SIP.js a to zdůvodu, že webové stránky projektu sipML5 nepůsobí příliš profesi-onálně. Výběr tedy zůstal mezi JsSIP a SIP.js. Jelikož byla knihovnaSIP.js vytvořena za účelem doplnění funkcionality JsSIP, zdá se býtSIP.js jako lepší volba.

3.2.4 jQuery

jQuery je poměrně malá a rychlá knihovna napsaná v jazyce JavaScript.Tato knihovna usnadňuje práci s objektovým modelem dokumentu(DOM), ať už se jedná o zpracování událostí (jako např. kliknutí) neboúpravy vzhledu stránky. Dále jQuery umožňuje přidat různé animacepomocí pár příkazů, což patří mezi hlavní přednosti této knihovny.Celý koncept knihovny jQuery je zaměřen zejména na psaní menšíhomnožství kódu s větší funkcionalitou.

3. Více informací na https://sipjs.com/4. Více na https://www.onsip.com/

59


3.2.5 Bootstrap

Bootstrap je HTML, CSS, JavaScript framework, který slouží k usnad-nění vývoje uživatelského rozhraní webových stránek. Bootstrap obsa-huje předdefinované šablony, komponenty (tlačítka, formuláře, listy,tabulky a mnohé další), mřížkový (grid) systém pro rozvržení ele-mentů v dokumentu, což zároveň dodává podporu pro optimalizaciwebových stránek pro různá rozlišení displeje.

3.3 Uživatelské rozhraní

Aplikace se skládá ze dvou webových stránek vytvořených pomocíjazyků HTML, CSS a JavaScript a knihoven jQuery a Bootstrap. In-formování o úspěchu či neúspěchu některých akcí (např. registrace,odmítnutí hovoru, různé možné chybové odpovědi, atd.) jsou v apli-kaci řešeny pomocí upozornění, která po chvíli zmizí pod hlavičkoustránky.

Přihlašovací stránka

Úvodní stránkou je index.html, která obsahuje formulář pro regis-traci (myšleno jako SIP REGISTER) telefonu k SIP serveru. Formulářobsahuje pole:

1. Display name - zobrazované jméno uživatele

2. SIP adress - SIP adresa uživatele

3. WebSocket server - adresa WebSocket serveru, ke kterému semá aplikace připojit

4. Auth name - název uživatele

5. Password - heslo uživatele

Telefon

Hlavní stránka aplikace (lokace /main.html) obsahuje uživatelskérozhraní samotného telefonu. Po přihlášení

Popis uživatelského rozhraní z obrázku 3.1

60


Obrázek 3.1: Ukázka uživatelského rozhraní telefonu

1. Pole pro zadaní vytáčeného čísla.

2. Tlačítko pro vytočení čísla zadaného v poli 1.

3. Rozhraní zobrazující příchozí hovor ve stavu, kdy jsou klientispojeni.

4. Adresa volajícího účastníka

5. Popisek značící, zda jde o příchozí nebo odchozí hovor.

6. Tlačítko pro zavěšení hovoru

7. Tlačítko přepnutí hovoru do stavu hold

8. Pole pro zadání čísla, na které má být hovor přesměrován

9. Tlačítko přesměrování hovoru na číslo uvedené v poli

10. Skupina tlačítek pro zadávání DTMF tónů

11. Tlačítko sloužící ke skrytí nebo odhalení skupiny tlačítek

61


12. Tlačítko sloužící k odstranění uživatelského rozhraní konkrét-ního hovoru

13. Pole obsahující adresu přihlášeného uživatele

14. Tlačítko sloužící k odhlášení

15. Seznam kontaktů

Obrázek 3.2: Ukázka uživatelského rozhraní telefonu

Popis uživatelského rozhraní z obrázku 3.2

1. Tlačítko sloužící k přijmutí příchozího hovoru.

2. Tlačítko sloužící k odmítnutí příchozího hovoru.

3. Tlačítko sloužící ke zrušení odchozího hovoru (dokud není spo-jen).

62


3.4 Architektura aplikace

Celou aplikaci tvoří dvě HTML stránky (index.html, main.html), šestJavaScriptových tříd (LoginnHandler, WebPhone, SessionMgr, UserRe-gInfo, SIPSession, ContactMgr), SIP.js knihovna a jeden soubor obsa-hující stylování (style.css).

Knihovna SIP.js

Pro lepší porozumění je zde uveden i popis některých tříd z knihovnySIP.js.

SIP.UA

Uživatelský agent (UA) se stará a o přijímání a odesílaní SIP poža-davků. Zároveň se stará o navázání a udržování WebSocket spojení.SIP.UA poskytuje mimo jiné následující metody

∙ register() - Metoda slouží k registraci UA.

∙ unregister() - Metoda slouží k odregistrování UA.

∙ invite(target[, options, modifiers]) - Metoda slouží k odeslánízaslání zprávy SIP INVITE. Parametr target slouží ke specifikacicíle zprávy. Pomocí parametru options jde specifikovat dalšíparametry jako například zda požadujeme audio, video nebooboje. Metoda vrací objekt typu SIP.Session

SIP.UA zároveň generuje události, na které lze navázat callbackfunkce. Mezi zajímavější z nich patří následující události.

∙ registered - Generováno při úspěšné registraci UA.

∙ unregistered - Generováno při úspěšné deregistraci UA.

∙ registrationFailed - Generováno při neúspěšné registraci UA.

∙ invite - Generováno při přijmutí zprávy SIP INVITE

63


SIP.Session

Třída SIP.Session reprezentuje WebRTC relaci. Objekt typu SIP.Sessionvznikají jako reakce na navázání odchozího nebo příchozího spojení.Některé metody třídy SIP.Session jsou uvedeny níže. SIP.Session gene-ruje obdobně pojmenované události (například událost „accepted“ vreakci na přijmutí hovoru) .

∙ accept([options]) - Metoda slouží k přijmutí hovoru.

∙ reject([options]) - Metoda slouží k odmítnutí hovoru ze stranyvolaného účastníka ještě před spojením hovoru.

∙ cancel([options]) - Metoda slouží ke zrušení hovoru ze stranyvolajícího ještě před spojením hovoru.

∙ dtmf(tone[, options]) - Metoda slouží k odeslání DTMF tónu.

∙ bye([options]) - Metoda slouží k odeslání zprávy BYE.

∙ hold([options, modifiers]) - Metoda dočasně přeruší tok médií.

∙ unhold([options, modifiers]) - Metoda obět obnoví tok médií.

∙ refer(target[, options]) - Metoda slouží k přenesení hovoru najiného účastníka.

Třída WebPhone

Vstupním bodem celé aplikace je třída WebPhone, která reprezentujetelefon. Instance telefonu (třídy WebPhone) je vytvořena po přihlášení.Mezi její atributy patří zejména uživatelský agent a správce relací(reprezentovaný třídou SessionMgr). Vytvořenému UA je následněpřidána callback funkce obsluhující příchozí SIP zprávu INVITE.

Třída SessionMgr

Třída SessionMgr představuje správce relací. Instance této třídy exis-tuje v rámci telefonu pouze jedna a obsahuje seznam všech aktivních ineaktivních relací (relace mají typ SIPSession), které jsou zobrazeny v

64


rámci uživatelského rozhraní telefonu. Třída obsahuje metody pro vy-tvoření relací, přidání relací do seznamu i k jejích odebrání ze seznamu.Zároveň je v SessionMgr obsažen i správce kontaktů (ContactMgr).

Třída SIPSession

Třída SIPSession spojuje objekt třídy SIP.Session (třída z knihovnySIP.js) s prvky uživatelského rozhraní. Každá relace (ať už příchozí,tak odchozí) má v rámci uživatelského rozhraní své ovládací prvky.

Ovládací prvky jsou vytvořeny po zavolaní funkce createUI(uiTemplate,isIncoming), viz výpis kódu 3.1, kde uiTemplate představuje HTMLelement (neviditelnou šablonu uloženou na stránce). Parametr isInco-ming značí, zda jde o příchozí, či odchozí spojení. Element uiTemplatese následně naklonuje, zviditelní a všem obsaženým tlačítkům jsoupřiřazeny funkce zpracovávající událost z jejich zmáčknutí.

Výpis 3.1: Vytvoření UI pro příchozí či odchoží relaciSIPSession . prototype . createUI =

function (uiTemplate , isIncoming ){console .log (" SIPSession :: createUI (): isIncoming ="

+ isIncoming );// duplicate the UI element & make it visiblevar uiElements = uiTemplate . cloneNode (true );uiElements .style. display = "block ";...

}

Třída SIPSession zároveň obsahuje metodu addSessionEvtHandlers(),která objektu třídy SIP.Session přidá callback funkce na události, kterégeneruje během signalizace.

Třída ContactMgr

Pro alespoň částečnou náhradu listu kontaktů aplikace využívá HTML5úložiště localStorage. Po každém pokusu o navázání hovoru je v Con-tactMgr provedeno ověření, zda už obsahuje kontakt na uživatele, odkterého přišel invite, případně kterému byl odeslán invite.

V localStorage jsou pak kontakty ukládány jako obyčejný řetězec,ve kterém jsou jednotlivé kontakty rozděleny znakem středníku. Jako

65


klíč pro uložení do localStorage se využívá řetězce CONTACT:adresapřihlášeného uživatele. Při vyčtení je řetězec zase rozebrán na jednotlivékontakty.

3.5 Popis nejdůležitějších částí kódu

Registrace

Registrace (viz. výpis 3.2) proběhne vytvořením uživatelského agentaskrze SIP API (z knihovny SIP.js). Uživatelský agent musí být pro-vázán se SIP URI, ta je mu předána jako jeden z parametrů. Dalšímiparametry URI WebSocket serveru, ke kterému se má UA připojit auživatelovy přihlašovací údaje.

Výpis 3.2: Vytvoření uživatelského agenta (UA)var userAgent = new SIP.UA({

uri : uInfo.getUri (),wsServers : [uInfo. getServer ()],authorizationUser : uInfo. getUser (),password : uInfo. getPassword ()

});

userAgent .on( MESSAGE_TYPE_INVITE , this. handleInviteInc .bind(this ));

Příchozí hovor

Příchozí zpráva INVITE nejprve způsobí zavolání callback funkce han-dleInviteInc (viz. výpis 3.3), kde se nejdřív v HTML dokumentu najdešablona pro ovládací prvky příchozího hovoru. Pomocí SessionMgrse vytvoří nový objekt typu SIPSession, kterému se jako parametrpředá šablona ovládacích prvků a následně je tento tento objekt dosessionMgr i uložen. Poté se objektu typu SIPSession nastaví stavprogress.

Výpis 3.3: Callback funkce volaná jako reakce na událost „invite“WebPhone . prototype . handleInviteInc = function ( incSession ){

console .log (" WebPhone :: handleInviteInc (): Incoming invite from uri =" + incSession . remoteIdentity .uri. toString ());

66


var uiTemplate = document . getElementById (" SingleSessionInc ");

// create UI for new incoming sessionvar sipSession = this. sessionMgr .create(this , incSession ,

uiTemplate , true );// pass it to the Session Managerthis. sessionMgr .add( sipSession );this. setCallStatus (S_PROGRESS , sipSession );

};

Po provedení kódu z výpisu 3.3 je v uživatelském rozhraní vola-ného účastníka zobrazen nový element reprezentující příchozí hovor.Element obsahuje dvě tlačítka - Answer a Reject. Pokud uživatel ho-vor přijme zmáčknutím tlačítka Answer, je zavolána callback funkcehandleAnswerCall (viz. výpis 3.4). V této callback funkci se využijemetody accept() nad objektem session (třídy SIP.Session), což vede kodeslání SIP odpovědi 200 OK a tím pádem i spojení hovoru. ObjektusipSession jsou následně přidány callback funkce reagující na většinuudálostí generovaných objektem třídy SIP.Session.

Výpis 3.4: Příjmutí hovoru. Reakce na zmáčkuntí tlačitka Answer.WebPhone . prototype . handleAnswerCall = function ( sipSession ){

// accept the session & set it ’s handlerssipSession . session .accept ({

sessionDescriptionHandlerOptions : {constraints : {

audio: true ,video: false}

}});

sipSession . addSessionEvtHandlers ();};

Odchozí hovor

Pokus o navázání hovoru vznikne vyplnění čísla do pole označenéhočíslem 1 v obrázku 3.1 a po kliknutí na tlačítko Call. Callback funkcí

67


tlačítka Call je funkce handleInviteOut() (viz. výpis kódu 3.5), kterámimo jiné nad uživatelským agentem (SIP.UA) zavolá metodu invite().Metoda invite() bere dva parametry, jedním z nich je číslo volanéhouživatele a druhým parametrem jsou další dobrovolné parametryspojení. Ve výpisu 3.5 je druhým parametrem omezení pouze na audiospojení, tudíž budou od uživatele vyžadována pouze práva pro přístupk mikrofonu. Výstupem metody invite je objekt typu SIP.Session, kterýse následně uloží v sessionMgr, stejně jako u příchozího hovoru.

68


Výpis 3.5: Ustanovení odchozího hovoru. Reakce na zmáčkuntí tlačitkaCall.WebPhone . prototype . handleInviteOut = function (){

...// send an invite (audio only)this. session = this.sipUA.invite(this. calledNumInput .value , {

sessionDescriptionHandlerOptions : {constraints : {

audio: true ,video: false

}}

});...

};

3.6 Testování

Testování výsledných aplikací je neodmyslitelnou součástí vývoje. Ktestování existují různé přístupy a volba vhodné testovací metody prodanou aplikaci je jedním ze základních kamenů kvalitně vyvinutýchaplikací.

Pro tuto práci bylo zvoleno manuální testování. Aplikace byla otes-tována na několika základních scénářích ve webových prohlížečíchGoogle Chrome a Firefox. Jelikož aplikace slouží k telefonování, je jejízákladní testování poměrně snadné, stačí k němu dva páry slucháteks mikrofonem, pobočková ústředna a připojení k internetu. V tomtopřípadě byl využit Asterisk ve verzi 15.1.5 nainstalovaný na operač-ním systému Ubuntu 16.4 LTS. Pro otestování hovoru mezi aplikacía stolním SIP telefonem bylo připraveno testovací prostředí ve firměOptimSys5, která stojí za vypsáním tématu této práce.

3.6.1 Testované scénáře

∙ Hovor webový prohlížeč - webový prohlížeč

5. Více informací o firmě na: http://www.optimsys.com/

69


∙ Hovor webový prohlížeč - deskphone

∙ Hovor webový prohlížeč - softphone

∙ Odmítnutí hovoru před jeho ustanovením

∙ Zrušení hovoru před jeho ustanovením

∙ Přepnutí do stavu hold

∙ Přesměrování hovoru na jiného účastníka (blind tranfer)

∙ Odesílání DTMF signalizace

Popis problémového scénáře

V tomto scénáři volá Alice Bobovi (jde o scénář typu aplikace - apli-kace). Alice zadá do příslušného pole číslo Boba a zmáčkne tlačítkoCall. Bobovi se v aplikaci objeví nový element indikující příchozí ho-vor od Alice. Ještě než Bob hovor přijme, použije Alice tlačítko Cancel,čímž hovor zruší ještě před jeho ustanovením.

Z hlediska SIP signalizace se jedná o zprávu INVITE od Alice kBobovi. Následně Bob pošle 180 RINING Alici. Alice pošle BoboviCANCEL a Bob tento požadavek na zrušení INVITE přijme. U Bobaovšem nastává problém, že i když CANCEL přijal, SIP.js stack nevy-generuje příslušnou událost, na kterou by aplikace mohla reagovat.Bobovi zůstane v aplikaci element indikující příchozí hovor, i když jejiž hovor dávno zrušen.

Jde tedy o chybu SIP.js knihovny, se kterou v rámci aplikace nejdenijak řešit a musí se počkat na její opravení vývojáři, kteří knihovnuSIP.js vyvíjejí.

3.6.2 Testy audio kvality

Pro automatizované testování kvality nebyl nalezen žádný vhodnýnástroj (pouze placené nástroje). Z toho důvodu bylo nakonec srov-nání kvality audio přenosu mezi WebRTC aplikací a soft-klientemprovedeno pouze neexaktně pomoci sluchu.

Kvalita hovoru byla zkoumána za různých podmínek interneto-vého připojení. Pro testování byl využit unixový nástroj Traffic Control

70


(tc), který umožňuje navodit různá omezení připojení. TC napříkladumožňuje nastavit procentuální množství ztracených paketů, zvýše-nou latenci a omezení šířky pásma.

Oba klienti (WebRTC i softphone) si při různých pokusech s na-stavením velikosti odezvy, množství ztracených paketů a snižovánímšířky pásma vedli velmi obdobně. Kvůli neexaktnosti měření všaknelze provádět žádné závěry.

3.6.3 Ladící nástroje

Pro ladění byla zvoleno velmi jednoduchá forma výpisů do konzoleprohlížeče. Každá podstatnější funkce tedy obsahuje výpis (často i sparametry, se kterými byla volána), podle čehož jde poznat, kde a zajakých okolností nastal problém.

Pro zjištění problémů signalizace obsahuje SIP.js knihovna kon-figurační parametr „traceSip: true“, který zapne výpisy SIP zprávdo konzole prohlížeče. Tento parametr se udává jako jeden z volitel-ných parametrů při vytváření uživatelského agenta z knihovny SIP.js(SIP.UA).

3.6.4 WebRTC internals

Webový prohlížeč Google Chrome obsahuje nástroje pro monitorováníWebRTC komunikace. Tento nástroj je zabudován přímo ve webovémprohlížeči a umožní nahlédnout na základní WebRTC objekty - Me-diaStream (getUserMedia()), RTCPeerConnection a RTCDataChan-nel. Pro vstup do ladícího nástroje se využívá adresa chrome://webrtc-internals/.

71


Obrázek 3.3: Ladící nástroj technologie WebRTC ve webovém prohlí-žeci Google Chorme

1. oblast na obrázku 3.3 obsahuje záložky MediaStream (GetUser-Media) a RTCPeerConnection. Záložka MediaStream obsahujevolání MediaStream API.

2. oblast obsahuje informace o nastavení RTCPeerConnection

3. oblast obsahuje volání PeerConnection API i s jejich parametrya obslužnými metodami

4. oblast obsahuje statistické údaje

Tento nástroj také zobrazuje grafické znázornění statistik jako na-příklad ztracené pakety, odezva, počet přijatých paketů za sekundu amnohé další, což je možné vidět na obrázku 3.4.

72


Obrázek 3.4: Ladící nástroj technologie WebRTC, grafické znázorněnístatistik ve webovém prohlížeci Google Chorme

73

4 Závěr

Cílem práce bylo prozkoumání technologie WebRTC a vytvoření na nízaloženého webového telefonu, který pro své fungování nepotřebujeinstalovat žádné dodatečné moduly. Vytvořený telefon měl být scho-pen napojení do telefonní infrastruktury využívající signalizační proto-kol SIP, ta může být reprezentována například pobočkovou ústřednouAsterisk. Telefon by měl mimo volání umožňovat i tónovou volbu(DTMF).

První částí práce bylo prozkoumání technologie WebRTC. Z prů-zkumu vyšlo několik podstatných faktů. Technologie WebRTC jev dnešní době využívána velkým množstvím aplikací. Ze statistikzveřejněných společností Google vyplývá, že webovým prohlížečemGoogle Chrome projde týdně celkově přes 1,5 bilionu minut audio avideo hovorů využívajících pro přenos médií technologii WebRTC. Ktomuto číslu zcela jistě přispívá fakt, že je WebRTC využíváno velkýmikomunikačními platformami jako Hangouts (od společnosti Google),Facebook (v aplikaci Messenger), WhatsApp, Discord a mnohýmidalšími. WebRTC je v současné době podporováno valnou většinouhlavních webových prohlížečů (mimo Safari iOS). WebRTC je v posled-ních letech rapidně se rozvíjející a stále více využívanou technologií.Připravována je například podpora novějšího video kodeku VP9 (ná-stupce VP8).

WebRTC specifikace dále nakazuje, že veškerá WebRTC komuni-kace musí být zabezpečená (signalizace i přenos dat). O tuhle proble-matiku se ovšem starají vývojáři webových prohlížečů. Pro vývojářewebových aplikací jde pouze o fakt, se kterým se musí smířit, jelikožzabezpečení WebRTC komunikace nelze ani žádným způsobem obejít(vypnout).

Pro implementaci aplikace byly použity jazyky JavaScript a HTML5.WebRTC zprostředkovává přenosy médií (a dat), ale neposkytuježádný signalizační mechanizmus. Jelikož má být aplikace napojenado infrastruktury na bázi signalizačního protokolu SIP, jevila se jakonejlepší varianta jedna z volně dostupných JavaScriptových knihovenimplementující SIP signalizaci přes WebSocket spojení. Konkrétně jdeo knihovnu SIP.js ve verzi 0.10, která poskytuje vše potřebné pro pronavázání a realizaci RTC spojení.

75

4. Závěr

Aplikace je schopná navázat audio spojení s druhým webovýmprohlížečem i s klasickým koncovým zařízením SIP sítí (soft klienta deskphone). Dále pak aplikace umožňuje odesílat DTFM tóny anavíc proti požadavkům uvedeným v zadání práce umožňuje provéstpřenesení hovoru na jiného účastníka (blind transfer).

Aplikace se potýká s problémem, který vzniká, pokud je aplikacena straně příjemce dosud nespojeného hovoru a hovor je volajícím zru-šen ještě než jej příjemce zvedne. V terminologii protokolu SIP se jednáo situaci, kdy aplikace přijme zprávu INVITE a ještě před odeslánímzprávy 200 OK dostane zprávu CANCEL. V takovém případě je vidětve výpisu logů, že CANCEL přijala, ale knihovna SIP.js nevygenerujepatřičnou událost, a tak v aplikaci zůstane grafické rozhraní, kterévypadá jako aktivní příchozí hovor, i když s ním provázané spojení jejiž zrušeno.

Do budoucna by aplikace mohla být vylepšena o video-konferencea prezenci uživatelů z kontaktního listu. Obě tyto funkcionality byměly být knihovnou SIP.js podporovány.

76

Rejstřík

AAOR - Adress of Record, 11

Cchunk, 34CN - Comfort noise, 39

DDOM - Document Object Model,

36DTLS - Datagram Transfer Layer

Security, 50

IICE - Interactive Connectivity Es-

tablishment, 25IP PBX - IP Private Branch Exchange,

6

JJavaScript, 35JSEP - JavaScript Session Establishmen

Protocol, 42

NNonce - Number Once, 11

PPayload, 30PSTN - Public Switched Telephone

Network, 5

RRR - Receiver report, 33RTC - Real-time Communication,

36RTCP - Real-time Transfer Control

Protocol, 31

RTP - Real-time Protocol, 29

SSCTP - Stream Control Transmis-

sion Protocol, 33SDP - Session Description Proto-

col, 20SIP - Session Initiation Protocol, 8SOP - Same Origin Policy, 52SR - Sender report, 32SRTP - Secure Real-time Transfer

Protocol, 50SSR - Synchronization source iden-

tifier, 32STUN - Simple Traversal Utilities,

23

TTURN - raversal Using Relays around

NAT, 23

UUA - User Agent, 8

VVoIP - Voice over IP, 5

WWebRTC - Web Real-time Commu-

nication, 36WebSocket, 25

XXMPP - Extensible Messaging and

Presence Protocol, 43

77

Bibliografie

1. Impact of Packet Loss, Jitter, and Latency on VoIP [online]. PanagiotisVouzis [cit. 2016-16-07]. Dostupné z: https://netbeez.net/blog/impact-of-packet-loss-jitter-and-latency-on-voip/.

2. The Top 10 Best Free Open Source PBX Software. Matt Grech, 2016. Do-stupné také z: https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/.

3. SIP: Session Initiation Protocol [online]. M. Handley, 1999 [cit.2018-05-07]. Dostupné z: https://www.ietf.org/rfc/rfc2543.txt.

4. Signalizační protokol pro přenos hlasu přes datové sítě - SIP [online]. Brno:Ing. Michal Soumar, 2003 [cit. 2003-07-01]. Dostupné z: http://www.elektrorevue.cz/clanky/03003/index.html.

5. UNDERSTANDING SIP REGISTRATION [online]. Andrew Prokop,2014 [cit. 2018-05-07]. Dostupné z: https : / / andrewjprokop .wordpress.com/2014/05/29/understanding-sip-registration/.

6. THE ANATOMY OF AN INVITE REQUEST [online]. Andrew Prokop,2014 [cit. 2018-05-07]. Dostupné z: https : / / andrewjprokop .wordpress . com / 2014 / 04 / 21 / the - anatomy - of - an - invite -request/.

7. SIP - Basic Call Flow [online] [cit. 2018-05-07]. Dostupné z: https :/ / www . tutorialspoint . com / session _ initiation _ protocol /session_initiation_protocol_basic_call_flow.htm.

8. ŠACL, Vojtěch. SIP KLIENT S POKROČILÝMI FUNKCEMI [online].Brno, 2013 [cit. 2018-05-07]. Dostupné z: https://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=69103.

9. Understanding SIP responses [online] [cit. 2018-05-08]. Dostupnéz: https : / / andrewjprokop . wordpress . com / 2014 / 06 / 18 /understanding-sip-responses/.

10. Tónová volba. Dostupné také z: https://cs.wikipedia.org/wiki/T%C3%B3nov%C3%A1_volba.

11. SDP: Session Description Protocol [online]. M. Handley, 2006 [cit.2018-05-08]. Dostupné z: https://tools.ietf.org/html/rfc4566.

79

https://netbeez.net/blog/impact-of-packet-loss-jitter-and-latency-on-voip/

https://netbeez.net/blog/impact-of-packet-loss-jitter-and-latency-on-voip/

https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/

https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/

https://www.ietf.org/rfc/rfc2543.txt

https://www.ietf.org/rfc/rfc2543.txt

http://www.elektrorevue.cz/clanky/03003/index.html

http://www.elektrorevue.cz/clanky/03003/index.html

https://andrewjprokop.wordpress.com/2014/05/29/understanding-sip-registration/

https://andrewjprokop.wordpress.com/2014/05/29/understanding-sip-registration/

https://andrewjprokop.wordpress.com/2014/04/21/the-anatomy-of-an-invite-request/



https://www.tutorialspoint.com/session_initiation_protocol/session_initiation_protocol_basic_call_flow.htm



https://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=69103

https://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=69103

https://andrewjprokop.wordpress.com/2014/06/18/understanding-sip-responses/

https://andrewjprokop.wordpress.com/2014/06/18/understanding-sip-responses/

https://cs.wikipedia.org/wiki/T%C3%B3nov%C3%A1_volba

https://cs.wikipedia.org/wiki/T%C3%B3nov%C3%A1_volba

https://tools.ietf.org/html/rfc4566

BIBLIOGRAFIE

12. Session Description Protocol [online] [cit. 2017-03-04]. Dostupné z:https : / / cs . wikipedia . org / wiki / Session _ Description _Protocol.

13. UNDERSTANDING SESSION DESCRIPTION PROTOCOL (SDP) [on-line]. Andrew Prokop, 2013 [cit. 2018-05-08]. Dostupné z: https://andrewjprokop.wordpress.com/2013/09/30/understanding-session-description-protocol-sdp/.

14. Real-Time Transport Protocol (RTP) Parameters [online]. 2017 [cit.2018-05-08]. Dostupné z: https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml.

15. Getting Started with WebRTC [online]. Brno: Sam Dutton, 2012 [cit.2014-02-14]. Dostupné z: https : / / www . html5rocks . com / en /tutorials/webrtc/basics/.

16. ICE always tastes better when it trickles! [online]. Victor Pascual, 2013[cit. 2013-12-04]. Dostupné z: https://webrtchacks.com/trickle-ice/.

17. The WebSocket Protocol [online]. I. Fette [cit. 2018-05-08]. Dostupné z:https://tools.ietf.org/html/rfc6455.

18. An Introduction to WebSockets [online]. Matt West, 2013 [cit. 2018-05-08].Dostupné z: http://blog.teamtreehouse.com/an-introduction-to-websockets.

19. About HTML5 WebSocket [online] [cit. 2018-05-08]. Dostupné z: https://websocket.org/aboutwebsocket.html.

20. WebSocket as a Transport for SIP [online]. I. Baz Castillo, 2014 [cit.2018-05-08]. Dostupné z: https://www.rfc- editor.org/rfc/rfc7118.txt.

21. RTP: A Transport Protocol for Real-Time Applications [online]. H.Schulzrinne, 2003 [cit. 2018-05-08]. Dostupné z: https://tools.ietf.org/html/rfc3550.

22. Protocol overview: RTP and RTCP [online]. Tommi Koistinen [cit.2018-05-08]. Dostupné z: https://www.netlab.tkk.fi/opetus/s38130/k99/presentations/4.pdf.

23. VOJTĚCH, Jan. Měření VoIP provozu pomocí IP toků. 2014. Diplomovápráce. Masarykova univerzita.

80

https://cs.wikipedia.org/wiki/Session_Description_Protocol

https://cs.wikipedia.org/wiki/Session_Description_Protocol

https://andrewjprokop.wordpress.com/2013/09/30/understanding-session-description-protocol-sdp/



https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml

https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml

https://www.html5rocks.com/en/tutorials/webrtc/basics/

https://www.html5rocks.com/en/tutorials/webrtc/basics/

https://webrtchacks.com/trickle-ice/

https://webrtchacks.com/trickle-ice/


http://blog.teamtreehouse.com/an-introduction-to-websockets

http://blog.teamtreehouse.com/an-introduction-to-websockets

https://websocket.org/aboutwebsocket.html

https://websocket.org/aboutwebsocket.html

https://www.rfc-editor.org/rfc/rfc7118.txt

https://www.rfc-editor.org/rfc/rfc7118.txt



https://www.netlab.tkk.fi/opetus/s38130/k99/presentations/4.pdf

https://www.netlab.tkk.fi/opetus/s38130/k99/presentations/4.pdf

BIBLIOGRAFIE

24. RTP Control Protocol [online] [cit. 2018-05-08]. Dostupné z: https://en.wikipedia.org/wiki/RTP_Control_Protocol.

25. Stream Control Transmission Protocol [online]. R. Stewart, Ed., 2007 [cit.2018-05-10]. Dostupné z: https://tools.ietf.org/html/rfc4960.

26. WebRTC BROWSER APIS AND PROTOCOLS, CHAPTER 18 [online].O’Reilly [cit. 2018-05-08]. Dostupné z: https://hpbn.co/webrtc/.

27. Začínáme s JavaScriptem [online]. Michal Kacerovsky [cit. 2017-01-06].Dostupné z: https://developer.mozilla.org/cs/docs/Web/JavaScript/Guide/uvod.

28. WebRTC 1.0: Real-time Communication Between Browsers [online]. 2011[cit. 2018-05-08]. Dostupné z: http://w3c.github.io/webrtc-pc/.

29. Is WebRTC ready yet? [online] [cit. 2018-05-08]. Dostupné z: http://iswebrtcreadyyet.com/.

30. Architecture [online] [cit. 2018-04-20]. Dostupné z: https://webrtc.org/architecture/.

31. Noise reduction [online] [cit. 2018-05-08]. Dostupné z: https://en.wikipedia.org/wiki/Noise_reduction.

32. Echo cancellation [online] [cit. 2018-05-08]. Dostupné z: https://www.vocal.com/echo-cancellation/.

33. Error Concealment for Speech Transmission [online] [cit. 2018-05-08]. Do-stupné z: https://www.vocal.com/voice-quality-enhancement/error-concealment-for-speech-transmission/.

34. Introduction to libjingle [online] [cit. 2018-05-08]. Dostupné z: https://developers.google.com/talk/libjingle/developer_guide.

35. MediaDevices.getUserMedia(). Dostupné také z: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia.

36. Javascript Session Establishment Protocol [online]. J. Uberti, 2013 [cit.2018-05-08]. Dostupné z: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-1.1.

37. What is HTTP Long Polling? [online]. Joe Hanson, 2014 [cit. 2018-05-10].Dostupné z: https://www.pubnub.com/blog/2014-12-01-http-long-polling/.

81

https://en.wikipedia.org/wiki/RTP_Control_Protocol

https://en.wikipedia.org/wiki/RTP_Control_Protocol


https://hpbn.co/webrtc/

https://developer.mozilla.org/cs/docs/Web/JavaScript/Guide/uvod

https://developer.mozilla.org/cs/docs/Web/JavaScript/Guide/uvod

http://w3c.github.io/webrtc-pc/

http://iswebrtcreadyyet.com/

http://iswebrtcreadyyet.com/

https://webrtc.org/architecture/

https://webrtc.org/architecture/

https://en.wikipedia.org/wiki/Noise_reduction

https://en.wikipedia.org/wiki/Noise_reduction

https://www.vocal.com/echo-cancellation/

https://www.vocal.com/echo-cancellation/

https://www.vocal.com/voice-quality-enhancement/error-concealment-for-speech-transmission/

https://www.vocal.com/voice-quality-enhancement/error-concealment-for-speech-transmission/

https://developers.google.com/talk/libjingle/developer_guide

https://developers.google.com/talk/libjingle/developer_guide

https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia

https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-1.1

https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-1.1

https://www.pubnub.com/blog/2014-12-01-http-long-polling/

https://www.pubnub.com/blog/2014-12-01-http-long-polling/

BIBLIOGRAFIE

38. Stream Updates with Server-Sent Events [online]. Eric Bidelman, 2010[cit. 2018-05-10]. Dostupné z: https://www.html5rocks.com/en/tutorials/eventsource/basics/.

39. WebRTC Gateway [online]. Bbutscher [cit. 2018-05-10]. Dostupné z:https://en.wikipedia.org/wiki/WebRTC_Gateway.

40. Why was SCTP Selected for WebRTC’s Data Channel? [online]. TsahiLevent-Levi, 2014 [cit. 2018-05-10]. Dostupné z: https://bloggeek.me/sctp-data-channel/.

41. Stream Control Transmission Protocol (SCTP) Partial Reliability Extension[online]. R. Stewart, 2004 [cit. 2018-05-10]. Dostupné z: https://tools.ietf.org/html/rfc3758.

42. The Secure Real-time Transport Protocol (SRTP). M. Baugher, 2004. Do-stupné také z: https://tools.ietf.org/html/rfc3711.

43. Same Origin Policy [online]. Victor Pascual, 2015 [cit. 2015-26-02]. Do-stupné z: https://tools.ietf.org/html/draft-ietf-rtcweb-security-08#section-3.2.

82

https://www.html5rocks.com/en/tutorials/eventsource/basics/

https://www.html5rocks.com/en/tutorials/eventsource/basics/

https://en.wikipedia.org/wiki/WebRTC_Gateway

https://bloggeek.me/sctp-data-channel/

https://bloggeek.me/sctp-data-channel/




https://tools.ietf.org/html/draft-ietf-rtcweb-security-08#section-3.2

https://tools.ietf.org/html/draft-ietf-rtcweb-security-08#section-3.2

VoIP telefon pro webové prostředí - IS MUNI

Documents