Tentokráte jsem se pustil do zpracování školního projektu na téma zprovoznění komunikace mezi pobočkovou ústřednou Asterisk a klientem založeným na WebRTC technologii. Ačkoliv se předmět samotný zabývá spíše klasickým VoIP, zvolil jsem si zajímavý úkol zprovoznění Asterisku se SIPml5 klientem.
Nejprve seznámení se s pojmy: Asterisk je zástupcem digitálních telefonních pobočkových ústředen (neboli protikus k drátu od kancelářského telefonu) pracujících na protokolu SIP, H.323 a dalších, což je opět evoluce dříve známých principů klasických telefonů, tak jak je známe posledních 140 let.
Naproti tomu je Web Real-Time Communication teprve 4 roky stará novinka postavená na Javascriptu do webových prohlížečů. Funguje jako peer-to-peer komunikace klientů na aplikační úrovni a portu 80 a proto nevyžaduje speciální podporu ze síťové strany.
Umí přenášet hlas, video, zprávy, hry či soubory v reálném čase. Dále se budu zabývat uplatněním WebRTC jako přenosového média pro hovory, co se s WebRTC dá dělat naleznete i s demonstaracemi na webu.
Klasické řešení VoIP telefonů se SIPem a RTP je dostatečně robustní v intranetu či kdekoliv, kde máte ve správě infrastrukturu. Můžete například ovlivňovat firewallová pravidla nebo specifikovat druh nasazeného klienta na počítačích a tím zajišťovat kvalitní telefonní služby.
Výborné video popisující ve 30 minutách, proč je WebRTC docela fajn:
Kde nebude tento přístup vyhovovat je současný trend v mobilitě uživatelů, různorodosti zařízení a módnosti mít všechnu funkcionalitu ve webovém prohlížeči. WebRTC je v tomto směru úžasný, protože nenutí k instalaci pluginů, což je jedna z největších výhod pro uživatele i programátory. A když to jednou umí prohlížeč, tak to pravděpodobně funguje nativně přes celý internet. Hurá!
Teď jak to využít? Můj projekt se zaměřuje na použití SIPml5 klienta, který využívá WebRTC pro přenos médií. Samotný klient se přihlásí k PBX pomocí běžných SIP zpráv přenášených přes protokol websocket.
Největší komplikace je zde s přenášenými médii. WebRTC správně vyžaduje šifrování "hlasu" mezi koncovými stanicemi za použití DTLS/SRTP. které se musí dohodnout v rámci vyjednávání o kodecích v rámci protokolu SDP a to bohužel klasičtí B2BUA a VoIP klienti neumí.
Schéma zapojení:
- PC1: phonerlite-portable <111>
- PC1: simpl5 <888> Mozilla
- PC2: phonerlite-portable <222>
- PC2 simpl5 <999> Chrome
Jak se tedy klienti chovají při hovoru?
- 111 na 222: standardně včetně médií
- 222 na 111: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio
- 111 na 888: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio
- 888 na 111: Remote host can't match request ACK to call
- 111 na 999: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio
- 999 na 111: Spojeno bez médií
- 222 na 888: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio
- 888 na 222: Spojeno bez médií
- 222 na 999: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio
- 999 na 222: Spojeno bez médií
Co na to konzole Asterisku? (klienti při prvotní registraci)
- Registered SIP '222' at 192.168.124.1:5075
- Saved useragent "SIPPER for PhonerLitePortable" for peer 222
- Registered SIP '111' at 192.168.124.137:5080
- Saved useragent "SIPPER for PhonerLitePortable" for peer 111
- Registered SIP '888' at 192.168.124.137:49478
- WebSocket connection from '192.168.124.137:49478' for protocol 'sip' accepted using version '13'
- Saved useragent "IM-client/OMA1.0 sipML5-v1.2015.03.18" for peer 888
- Registered SIP '999' at 192.168.124.1:22470
- WebSocket connection from '192.168.124.1:22470' for protocol 'sip' accepted using version '13'
- Saved useragent "IM-client/OMA1.0 sipML5-v1.2015.03.18" for peer 999
Všechny analýzy nám vlastně říkají to, co už víme, nedaří se navázat zabezpečené spojení a proto je komunikace odmítnuta. V screenshotech nějak chybí volání 888 na 111 a zároveň je mi podezřelé, proč klient 111 odmítá komunikovat, protože mi již v minulosti telefonovat a konfiguraci má stále stejnou a dokonce identickou s klientem 222. Podrobím tento nesoulad dalšímu zkoumání...
Použité konfigurační soubory
Čím si nejsem jistý je chování Asterisku při tomto patchi. Nevysledoval jsem žádnou změnu. Ta by měla dle dokumentace pouze potlačit nevhodné chování Chrome a ICE, jenže vzhledem ke stáří zmíněného patche bych vše považoval za již vyřešené.
Závěr
Závěr
Tento projekt mě seznámil s docela zajímavými technologiemi, trochu to kazí to, že mi vlastně nefungují, ale docela bych věřil, že to bude chybou mezi klávesnicí a židlí. V principu se mi také líbí fakt, že minimální implementace vyžaduje šifrování, což je pro tyto technologie dobře. Nadruhou stranu mi to způsobilo asi 3 týdenní zpoždění s odevzdáním a i tak jsem si hraním s Asteriskem a SIPm5 strávil asi 2 celé víkendy, čímž notně utrpěly jiné projekty, které jsem v průběhu semestru povinen odevzdávat. Doufám, že se mi podaří nějakou konzultací zmíněné nedostatky odstranit a článek tak aktualizovat na funkční tutoriál.
Dotazy, tipy a nápady přijímám jako vždy do komentářů.
Žádné komentáře :
Okomentovat
Dotaz, připomínka, oprava?
(pokud máte problém s vložením příspěvku, vyzkoušejte to v prohlížeči Chrome)