WebRTC. Videokonferencie v prehliadači. Rozhovor s viacerými používateľmi pomocou hlasového rozhovoru WebRTC Webrtc

Preambula. P2P videorozhovor je zapnutý Základňa WebRTC je alternatívou k Skype a iným komunikačným prostriedkom. Hlavnými prvkami videorozhovoru p2p založeného na WebRTC sú prehliadač a kontaktný server. Videorozhovory P2P sú videorozhovory typu peer-to-peer, v ktorých sa server nezúčastňuje na prenose informačných tokov. Informácie sa prenášajú priamo medzi prehliadačmi používateľov (rovesníkmi) bez akýchkoľvek doplnkové programy. Okrem prehliadačov využívajú videorozhovory p2p kontaktné servery, ktoré sú určené na registráciu používateľov, ukladanie údajov o nich a zabezpečenie prepínania medzi používateľmi. Prehliadače, ktoré podporujú najnovšie technológie WebRTC a HTML5, poskytujú okamžité textové správy a prenos súborov, ako aj hlasovú a video komunikáciu cez IP siete.

Takže chaty, webové chaty, hlasové a video chaty vo webovom rozhraní, IMS, VoIP sú služby, ktoré poskytujú online komunikáciu prostredníctvom kompozitných sietí s prepínaním paketov. Komunikačné služby spravidla vyžadujú buď inštaláciu klientskych aplikácií na používateľské zariadenia (PC, smartfóny atď.), alebo inštaláciu pluginov a rozšírení do prehliadačov. Služby majú svoje vlastné komunikačné siete, z ktorých väčšina je postavená na architektúre klient-server.

Komunikačné služby sú aplikácie iné ako IMS, v ktorých nie sú integrované hlasové, video, dátové a textové kanály. V sieťach každej služby, . Treba si uvedomiť, že tieto aplikácie nemôžu súčasne pracovať vo viacerých komunikačných sieťach, t.j. Aplikácie zvyčajne nemôžu navzájom komunikovať, čo si vyžaduje inštaláciu samostatnej aplikácie pre každú komunikačnú sieť.

Problém integrácie komunikačných služieb v reálnom čase (chat, telefonovanie, videokonferencie), t.j. integráciu hlasových, video, dátových kanálov a prístup k nim pomocou jednej aplikácie (prehliadača) je možné riešiť v peer-to-peer alebo p2p video chatoch (peer-to-peer, point-to-point) na základe protokolu WebRTC. Prehliadač, ktorý podporuje WebRTC, sa v podstate stáva jediným rozhraním pre všetky používateľské zariadenia (PC, smartfóny, iPady, IP telefóny, mobilné telefóny atď.), ktoré pracujú s komunikačnými službami.

Práve WebRTC zabezpečuje implementáciu v prehliadači všetkých technológií, ktoré zabezpečujú komunikáciu v reálnom čase. Podstatou videorozhovorov p2p je, že multimediálne a textové údaje sa prenášajú priamo medzi prehliadačmi používateľov (vzdialený peering) bez účasti servera alebo ďalších programov. Prehliadače teda poskytujú nielen prístup takmer ku všetkým informačné zdroje internetu, ktoré sú uložené na serveroch, ale stávajú sa aj prostriedkom prístupu ku všetkým komunikačným službám v reálnom čase a poštovým službám (hlasová schránka, e-mail, SMS a pod.)

Servery (kontaktné servery) p2p video chatov sú určené len na registráciu používateľov, ukladanie údajov o používateľoch a vytváranie spojenia (prepínania) medzi prehliadačmi používateľov. Prvé videorozhovory p2p boli implementované pomocou flash technológií. Flash p2p videorozhovory sa používajú napr v sociálnych sieťach. Flash videorozhovory p2p neposkytujú vysoká kvalita prenos multimediálnych dát. Okrem toho, na výstup hlasového a video streamu z mikrofónu a videokamery v p2p flash video chatoch je potrebné nainštalovať flash plugin do webového prehliadača.

Nová generácia telekomunikačných služieb však zahŕňa webovú komunikáciu, ktorá na komunikáciu cez internet používa iba prehliadače a kontaktné servery, ktoré podporujú protokoly WebRTC a špecifikáciu HTML5. Akékoľvek používateľské zariadenie (PC, iPad, smartfóny atď.) vybavené takýmto prehliadačom môže poskytovať vysokokvalitné hlasové a videohovory, ako aj prenos okamžitých textových správ a súborov.

Takže novou technológiou webovej komunikácie (p2p chat, video chat) je protokol WebRTC. WebRTC spolu s HTML5, CSS3 a JavaScriptom umožňujú vytvárať rôzne webové aplikácie. WebRT je navrhnutý tak, aby organizoval webovú komunikáciu (siete peer-to-peer) v reálnom čase pomocou architektúry peer-to-peer. P2P chaty založené na WebRTC poskytujú prenos súborov, ako aj textovú, hlasovú a video komunikáciu medzi používateľmi cez internet iba pomocou webových prehliadačov bez použitia externých doplnkov a zásuvných modulov v prehliadači.

V p2p chatoch sa server používa iba na vytvorenie p2p spojenia medzi dvoma prehliadačmi. Na vytvorenie klientskej časti p2p chatu založeného na protokole WebRTC sa používajú HTML5, CSS3 a JavaScript. Klientska aplikácia komunikuje s prehliadačmi cez WebRTC API.

WebRTC implementujú tri JavaScript API:

• RTCPeerConnection;
• MediaStream(getUserMedia);
• RTCDataChannel.

Prehliadače prenášajú mediálne dáta pomocou protokolu SRTP, ktorý beží nad UDP. Keďže NAT spôsobuje problémy prehliadačom (klientom) za smerovačmi NAT, ktoré používajú pripojenie p2p cez internet, STUN sa používa na obídenie prekladačov NAT. STUN je protokol klient-server, ktorý beží nad prenosovým protokolom UDP. V p2p chatoch sa spravidla používa verejný STUN server a informácie z neho prijaté sa používajú na UDP spojenie medzi dvoma prehliadačmi, ak sú za NAT.

Príklady implementácie WebRTC aplikácií (p2p chaty, hlasové a video webové chaty):
1. P2P videochat Bistri (videorozhovor jedným kliknutím, p2p chat), založený na WebRTC, je možné otvoriť na Bistri. Bistri funguje v prehliadači bez inštalácie ďalších programov a doplnkov. Podstata práce je nasledovná: otvorte p2p videorozhovor pomocou zadaného odkazu, po registrácii v rozhraní, ktoré sa otvorí, pozvite partnerov, potom zo zoznamu peer klientov vyberte partnera, ktorý je online, a kliknite na „videohovor tlačidlo “.

Výsledkom je, že MediaStream (getUserMedia) zachytí mikrofón + webovú kameru a server si vymieňa signalizačné správy s vybraným partnerom. Po výmene signalizačných správ vytvára rozhranie API PeerConnection kanály na prenos hlasových a video streamov. Okrem toho Bistri prenáša okamžité textové správy a súbory. Na obr. 1 zobrazuje snímku obrazovky rozhrania videorozhovoru Bistri p2p.

Ryža. 1. P2P videochat Bistri

2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) - táto klientska aplikácia je postavená na báze HTML5 a WebRTC, ktorá umožňuje uskutočňovať hlasové a video hovory, ako aj posielať okamžité textové správy, t.j. Twelephone obsahuje testovací p2p chat, video chat a SIP Twelephone. Je potrebné poznamenať, že Twelephone podporuje protokol SIP a teraz môžete uskutočňovať a prijímať hlasové hovory a videohovory z telefónov SIP pomocou svojho účtu Twitter ako telefónneho čísla. okrem toho textové správy môžete zadať hlasom cez mikrofón a program na rozpoznávanie hlasu zadá text do riadku „Odoslať správu“.

Twelephone je webová telefónia založená na prehliadači Google Chrome, od verzie 25, bez prídavných softvér. Twelephone vyvinul Chris Matthieu. Backend Twelephone je postavený na Node.js. Server (kontaktný server) sa používa iba na vytvorenie spojenia p2p medzi dvoma prehliadačmi alebo klientmi WebRTC. Aplikácia Twelephone nemá vlastné autorizačné nástroje, ale je zameraná na pripojenie k účtu ( účtu) na Twitteri.

Na obr. 2 ukazuje snímku obrazovky rozhrania videorozhovoru Twelephone p2p.

Ryža. 2. P2P telefón

3. Skupinový p2p video chat Conversat.io je postavený na najnovších technológiách WebRTC a HTML5. Videorozhovor Conversat je vyvinutý na základe knižnice SimpleWebRTC a je určený na komunikáciu až 6 peer klientov v jednej miestnosti (pre komunikáciu uveďte názov spoločenskej miestnosti pre peer klientov do riadku "Pomenujte konverzáciu"). P2P videochat Conversat poskytuje komunikačné služby používateľom bez registrácie na kontaktnom serveri. Na obr. Obrázok 3 zobrazuje snímku obrazovky rozhrania videorozhovoru Conversat p2p.

Ryža. 3. Skupinový P2P videorozhovor Conversat.io

Aby sa používatelia mohli zúčastniť videorozhovorov P2P založených na WebRTC, musia mať nainštalovaný prehliadač, ktorý podporuje protokol WebRTC a špecifikáciu HTML5. V súčasnosti prehliadače Google Chrome počnúc verziou 25 a Mozilla Firefox Nightly podporuje protokol WebRTC a špecifikáciu HTML5. Aplikácie WebRTC sú lepšie ako aplikácie Flash z hľadiska kvality prenosu obrazu a zvuku.

Väčšina materiálov o WebRTC je zameraná na aplikačnú úroveň kódovania a neprispieva k pochopeniu technológie. Pokúsme sa ísť hlbšie a zistiť, ako k pripojeniu dochádza, aký je deskriptor relácie a kandidáti, prečo sú potrebné servery STUN a TURN.

Úvod do WebRTC

WebRTC je technológia orientovaná na prehliadač, ktorá umožňuje prepojiť dvoch klientov na prenos video dát. Hlavnými funkciami sú interná podpora prehliadača (nie sú potrebné technológie implementované tretími stranami, ako je adobe flash) a možnosť pripojenia klientov bez použitia ďalších serverov - pripojenie peer-to-peer (ďalej len p2p).

Vytvorenie pripojenia p2p je pomerne náročná úloha, pretože počítače nemajú vždy verejné adresy IP, teda adresy na internete. Kvôli malému počtu IPv4 adries (a z bezpečnostných dôvodov) bol vyvinutý mechanizmus NAT, ktorý umožňuje vytvárať privátne siete napríklad pre domáce použitie. Mnoho domácich smerovačov teraz podporuje NAT a vďaka tomu majú všetky domáce zariadenia prístup na internet, hoci poskytovatelia internetu zvyčajne poskytujú jednu IP adresu. Verejné IP adresy sú na internete jedinečné, ale súkromné ​​nie. Preto je pripojenie p2p ťažké.

Aby ste to lepšie pochopili, zvážte tri situácie: oba uzly sú v rovnakej sieti (obrázok 1), oba uzly sú v rôznych sieťach (jeden v súkromnej, druhý vo verejnej) (obrázok 2) a oba uzly sú v rôznych súkromných sieťach s rovnaké IP adresy (obrázok 3).

Obrázok 1: Oba uzly v rovnakej sieti

Obrázok 2: Uzly v rôznych sieťach (jeden v súkromnej, jeden vo verejnej)

Obrázok 3: Uzly v rôznych súkromných sieťach, ale s číselne rovnakými adresami

Na obrázkoch vyššie prvé písmeno v dvojznakovom zápise označuje typ uzla (p = peer, r = router). Na prvom obrázku je situácia priaznivá: uzly v ich sieti sú plne identifikované sieťovými IP adresami, a preto sa môžu navzájom priamo spájať. Na druhom obrázku máme dve rôzne siete s podobnými číslami uzlov. Tu sa objavujú smerovače (smerovače), ktoré majú dva sieťové rozhranie– vo vašej sieti a mimo vašej siete. Preto majú dve IP adresy. Bežné uzly majú len jedno rozhranie, cez ktoré môžu komunikovať len v rámci svojej siete. Ak prenášajú dáta niekomu mimo svojej siete, tak iba pomocou NAT vo vnútri smerovača (smerovača) a teda viditeľné pre ostatných pod IP adresou smerovača - je to ich externé IP adresa. Takže uzol p1 má interiéru IP = 192.168.0.200 A externé IP = 10.50.200.5 a posledná adresa bude tiež externá pre všetky ostatné uzly v jej sieti. Situácia je podobná pre uzol p2. Preto je ich komunikácia nemožná, ak sa používajú iba ich interné (vlastné) IP adresy. Môžete použiť externé adresy, teda adresy smerovačov, ale keďže všetky uzly v tej istej súkromnej sieti majú rovnakú externú adresu, je to dosť ťažké. Tento problém je možné vyriešiť pomocou mechanizmu NAT

Čo sa stane, ak sa rozhodneme prepojiť uzly cez ich interné adresy? Dáta neopustia sieť. Pre zvýšenie efektu si môžete predstaviť situáciu znázornenú na poslednom obrázku – oba uzly majú rovnaké interné adresy. Ak ich použijú na komunikáciu, potom každý uzol bude komunikovať sám so sebou.

WebRTC sa s takýmito problémami úspešne vyrovnáva pomocou protokolu ICE, ktorý však vyžaduje použitie ďalších serverov (STUN, TURN). Viac o tom všetkom nižšie.

Dve fázy WebRTC

Ak chcete pripojiť dva uzly prostredníctvom protokolu WebRTC (alebo jednoducho RTC, ak komunikujú dva telefóny iPhone), musíte na vytvorenie spojenia vykonať niekoľko predbežných krokov. Toto je prvá fáza - nadviazanie spojenia. Druhou fázou je prenos video dát.

Okamžite stojí za to povedať, že hoci technológia WebRTC používa veľa rôznymi spôsobmi komunikácie (TCP a UDP) a má medzi nimi flexibilné prepínanie, túto technológiu nemá protokol na prenos údajov o pripojení. Nie je prekvapujúce, pretože prepojenie dvoch uzlov p2p nie je také jednoduché. Preto je potrebné mať nejaké dodatočné spôsob prenosu údajov, ktorý nijako nesúvisí s WebRTC. Môže to byť soketový prenos, HTTP protokol, dokonca to môže byť protokol SMTP alebo ruskej pošty. Tento prevodový mechanizmus počiatočné dáta sa nazývajú signál. Nie je potrebné poskytovať veľa informácií. Všetky údaje sa prenášajú v textovej podobe a delia sa na dva typy – SDP a Ice Candidate. Prvý typ sa používa na vytvorenie logického pripojenia a druhý na fyzické pripojenie. Viac o tom všetkom neskôr, ale zatiaľ je dôležité si uvedomiť, že WebRTC nám poskytne nejaké informácie, ktoré bude potrebné preniesť do iného uzla. Hneď ako prenesieme všetky potrebné informácie, uzly sa budú môcť spojiť a naša pomoc už nebude potrebná. Takže signálny mechanizmus, ktorý musíme implementovať, je oddelene, bude použitý iba pri pripojení, ale nepoužije sa pri prenose obrazových údajov.

Pozrime sa teda na prvú fázu – fázu nadviazania spojenia. Pozostáva z niekoľkých bodov. Pozrime sa na túto fázu najprv pre uzol, ktorý iniciuje spojenie, a potom pre ten, ktorý čaká.

• Iniciátor (volajúci):
• Ponúknuť spustenie prenosu údajov videa (createOffer)
• Získanie vášho SDP SDP)
• Prijatie kandidáta na ľadový kandidát na ľad)
• Čakajúci hovor (volaný):
• Príjem miestneho (vášho) mediálneho streamu a jeho nastavenie na prenos (getUserMediaStream)
• Prijatie ponuky na spustenie prenosu video dát a vytvorenie odpovede (createAnswer)
• Prijímanie svojho objektu SDP a jeho prechod cez signalizačný mechanizmus (SDP)
• Prijímanie vašich objektov ľadových kandidátov a ich prechod cez signalizačný mechanizmus (ľadový kandidát)
• Príjem vzdialeného (cudzieho) mediálneho streamu a jeho zobrazenie na obrazovke (onAddStream)

Rozdiel je len v druhom bode.

Napriek zjavnej zložitosti krokov sú v skutočnosti tri: odoslanie vlastného mediálneho toku (položka 1), nastavenie parametrov pripojenia (položky 2-4), príjem mediálneho toku niekoho iného (položka 5). Najťažším krokom je druhý krok, pretože pozostáva z dvoch častí: založenie fyzické A logické spojenia. Prvý naznačuje cesta, po ktorej musia pakety cestovať, aby sa dostali z jedného sieťového uzla do druhého. Druhý naznačuje video/audio parametre– akú kvalitu použiť, aké kodeky použiť.

Mentálne by fáza createOffer alebo createAnswer mala byť prepojená s fázami odovzdávania objektov SDP a kandidátov na ľad.

Základné entity Mediálne toky (MediaStream)

Hlavnou podstatou je mediálny prúd, teda prúd obrazových a zvukových dát, obrazu a zvuku. Existujú dva typy mediálnych tokov – lokálne a vzdialené. Lokálny prijíma dáta zo vstupných zariadení (kamera, mikrofón) a vzdialený cez sieť. Každý uzol má teda lokálne aj vzdialené vlákno. Vo WebRTC existuje rozhranie MediaStream pre streamy a existuje aj podrozhranie LocalMediaStream špeciálne pre lokálny stream. V JavaScripte sa môžete stretnúť len s prvým, ale ak používate libjingle, môžete sa stretnúť aj s druhým.

WebRTC má v rámci vlákna dosť mätúcu hierarchiu. Každý stream môže pozostávať z niekoľkých mediálnych stôp (MediaTrack), ktoré môžu pozostávať z niekoľkých mediálnych kanálov (MediaChannel). A môže existovať aj niekoľko samotných mediálnych prúdov.

Pozrime sa na všetko v poriadku. Aby sme to dosiahli, zapamätajme si niekoľko príkladov. Povedzme, že chceme preniesť nielen video seba, ale aj video nášho stola, na ktorom leží papier, na ktorý ideme niečo písať. Budeme potrebovať dve videá (my + tabuľka) a jedno audio (my). Je jasné, že my a tabuľku by sme mali rozdeliť do rôznych vlákien, pretože tieto údaje sú na sebe pravdepodobne slabo závislé. Preto budeme mať dva MediaStreamy – jeden pre nás a jeden pre stôl. Prvý bude obsahovať obrazové aj zvukové údaje a druhý bude obsahovať iba obraz (obrázok 4).

Obrázok 4: Dva rôzne mediálne toky. Jeden pre nás, jeden pre náš stôl

Okamžite je jasné, že tok médií musí minimálne obsahovať schopnosť obsahovať dáta odlišné typy- video a audio. Toto je v technológii zohľadnené a preto je každý typ dát implementovaný prostredníctvom mediálnej stopy MediaTrack. Mediálna stopa má špeciálnu vlastnosť druh , ktorá určuje, či ide o video alebo zvuk (obrázok 5)

Obrázok 5: Mediálne toky pozostávajú z mediálnych stôp

Ako sa všetko bude diať v programe? Vytvoríme dva mediálne prúdy. Potom vytvoríme dve video stopy a jednu zvukovú stopu. Poďme získať prístup ku kamerám a mikrofónu. Povedzme každej skladbe, ktoré zariadenie použiť. Pridajme video a audio stopu do prvého mediálneho prúdu a video stopu z inej kamery do druhého mediálneho prúdu.

Ako však rozlíšime mediálne toky na druhom konci spojenia? Na tento účel má každý mediálny prúd vlastnosť label – označenie prúdu, jeho názov (obrázok 6). Mediálne stopy majú rovnakú vlastnosť. Aj keď sa na prvý pohľad zdá, že video sa dá od zvuku odlíšiť aj inak.

Obrázok 6: Toky médií a stopy sú označené štítkami

Takže, ak je možné mediálne stopy identifikovať pomocou značky, prečo potom musíme v našom príklade použiť dva mediálne prúdy namiesto jedného? Koniec koncov, môžete prenášať jeden mediálny prúd, ale používať v ňom rôzne stopy. Dosiahli sme dôležitú vlastnosť mediálnych tokov – oni synchronizovať mediálne stopy. Rôzne mediálne toky nie sú synchronizované navzájom, ale v rámci každého mediálneho toku sú všetky stopy sa prehrávajú súčasne.

Ak teda chceme, aby sa naše slová, emócie tváre a náš kus papiera prehrávali súčasne, potom sa oplatí použiť jeden mediálny prúd. Ak to nie je také dôležité, potom je výhodnejšie použiť rôzne prúdy - obraz bude hladší.

Ak je potrebné počas prenosu vypnúť niektorú stopu, môžete použiť vlastnosť enabled mediálnej stopy.

Nakoniec sa oplatí porozmýšľať nad stereo zvukom. Ako viete, stereo zvuk sú dva rôzne zvuky. A musia sa prenášať aj samostatne. Na to slúžia MediaChannels. Mediálna zvuková stopa môže mať veľa kanálov (napríklad 6, ak potrebujete zvuk 5+1). Vo vnútri mediálnych stôp sú, samozrejme, aj kanály. synchronizované. Pre video sa zvyčajne používa iba jeden kanál, ale niekoľko sa dá použiť napríklad na prekrývanie reklamy.

Zhrnúť: Na prenos obrazových a zvukových údajov používame mediálny tok. V rámci každého mediálneho toku sa údaje synchronizujú. Ak nepotrebujeme synchronizáciu, môžeme použiť viacero mediálnych streamov. Vo vnútri každého mediálneho toku sú dva typy mediálnych stôp – pre video a pre zvuk. Zvyčajne nie sú viac ako dve stopy, ale môže ich byť viac, ak potrebujete preniesť niekoľko rôznych videí (hovoriaceho a jeho stola). Každá stopa môže pozostávať z niekoľkých kanálov, čo sa zvyčajne používa iba pre stereo zvuk.

V najjednoduchšej situácii videorozhovoru budeme mať jeden lokálny mediálny stream, ktorý bude pozostávať z dvoch stôp - video stopy a zvukovej stopy, z ktorých každá bude pozostávať z jedného hlavného kanála. Video stopa je zodpovedná za kameru, zvuková stopa je za mikrofón a mediálny tok je kontajnerom oboch.

Deskriptor relácie (SDP)

Rôzne počítače budú mať vždy rôzne kamery, mikrofóny, grafické karty a ďalšie vybavenie. Existuje veľa možností, ktoré majú. Toto všetko musí byť koordinované pre mediálny prenos dát medzi dvoma sieťovými uzlami. WebRTC to robí automaticky a vytvára špeciálny objekt– deskriptor relácie SDP. Odovzdajte tento objekt inému uzlu a údaje o médiách sa môžu preniesť. Len ešte nie je spojenie s iným uzlom.

Používa sa na to akýkoľvek signalizačný mechanizmus. SDP môže byť prenášaný buď cez zásuvky, alebo osobou (povedzte to inému uzlu telefonicky), alebo ruskou poštou. Všetko je veľmi jednoduché - dostanete hotový SDP a musíte ho odoslať. A keď ho dostanete na druhej strane, preneste ho na oddelenie WebRTC. Deskriptor relácie je uložený ako text a možno ho zmeniť vo vašich aplikáciách, ale vo všeobecnosti to nie je potrebné. Napríklad pri pripájaní stolného ↔ telefónu niekedy musíte vynútiť výber požadovaného zvukového kodeku.

Pri vytváraní pripojenia musíte zvyčajne zadať nejaký druh adresy, napríklad URL. Tu to nie je potrebné, pretože prostredníctvom signalizačného mechanizmu sami odošlete údaje na miesto určenia. Aby sme WebRTC oznámili, že chceme vytvoriť pripojenie p2p, musíme zavolať funkciu createOffer. Po zavolaní tejto funkcie a zadaní špeciálneho spätného volania 'a sa vytvorí objekt SDP a odovzdá sa rovnakému spätnému volaniu. Všetko, čo sa od vás vyžaduje, je preniesť tento objekt cez sieť do iného uzla (partnera). Potom sa dáta dostanú na druhý koniec cez signalizačný mechanizmus, konkrétne tento SDP objekt. Tento deskriptor relácie je pre tento uzol cudzí, a preto nesie užitočné informácie. Prijatie tohto objektu je signálom na spustenie spojenia. Preto s tým musíte súhlasiť a zavolať funkciu createAnswer. Je to úplná analógia createOffer. Opäť platí, že deskriptor lokálnej relácie bude odovzdaný vášmu spätnému volaniu a bude potrebné ho odovzdať späť cez signalizačný mechanizmus.

Stojí za zmienku, že funkciu createAnswer môžete zavolať až po prijatí objektu SDP niekoho iného. prečo? Pretože lokálny objekt SDP, ktorý sa vygeneruje pri volaní createAnswer, sa musí spoliehať na vzdialený objekt SDP. Iba v tomto prípade je možné koordinovať vaše nastavenia videa s nastaveniami vášho partnera. Tiež by ste nemali volať createAnswer a createOffer pred prijatím lokálneho mediálneho toku – nebudú mať čo zapisovať do objektu SDP.

Keďže WebRTC má schopnosť upravovať objekt SDP, po prijatí lokálneho deskriptora je potrebné ho nainštalovať. Môže sa zdať trochu zvláštne, že musíme do WebRTC preniesť to, čo nám sám dal, ale taký je protokol. Keď je prijatá diaľková rukoväť, musí byť tiež nainštalovaná. Preto musíte na jeden uzol nainštalovať dva deskriptory – váš a cudzí (teda lokálny a vzdialený).

Po tomto podania rúk uzly vedia o svojich prianiach. Napríklad, ak uzol 1 podporuje kodeky A a B a uzol 2 podporuje kodeky B a C, potom, keďže každý uzol pozná svoje vlastné deskriptory a deskriptory toho druhého, oba uzly si vyberú kodek B (obrázok 7). Logika spojenia je teraz vytvorená a mediálne streamy môžu byť prenášané, ale je tu ďalší problém - uzly sú stále spojené iba signalizačným mechanizmom.

Obrázok 7: Vyjednávanie kodeku

Ľadový kandidát

Technológia WebRTC sa nás snaží zmiasť svojou novou metodikou. Pri vytváraní spojenia nie je zadaná adresa uzla, ku ktorému sa chcete pripojiť. Nainštalované ako prvé logické spojenie, nie fyzické, hoci sa vždy robilo naopak. To sa však nebude zdať zvláštne, ak nezabudneme, že používame signalizačný mechanizmus tretej strany.

Takže spojenie už bolo vytvorené (logické spojenie), ale stále neexistuje cesta, po ktorej môžu sieťové uzly prenášať dáta. Nie je to všetko také jednoduché, ale začnime jednoducho. Nech sú uzly v rovnakej súkromnej sieti. Ako už vieme, môžu sa navzájom jednoducho spojiť pomocou svojich interných IP adries (alebo možno nejakých iných, ak sa nepoužíva TCP/IP).

Prostredníctvom spätného volania a WebRTC nás informuje o objektoch kandidátov na ľad. Prichádzajú tiež v textovej forme a podobne ako deskriptory relácie ich jednoducho treba odoslať prostredníctvom signalizačného mechanizmu. Ak deskriptor relácie obsahoval informácie o našich nastaveniach na úrovni kamery a mikrofónu, potom kandidáti obsahujú informácie o našej polohe v sieti. Odovzdajte ich inému uzlu a ten sa k nám bude môcť fyzicky pripojiť, a keďže už má deskriptor relácie, logicky sa bude môcť pripojiť a údaje budú „plynúť“. Ak nám nezabudne poslať svoj kandidátsky objekt, teda informáciu o tom, kde sa v sieti nachádza, tak sa s ním budeme môcť spojiť. Všimnime si tu ešte jeden rozdiel oproti klasickej interakcii klient-server. Komunikácia s HTTP serverom prebieha podľa schémy požiadavka-odpoveď, klient posiela dáta na server, ktorý ich spracuje a odošle cez adresu uvedenú v balíku požiadavky. Vo WebRTC musíte vedieť dve adresy a spojte ich na oboch stranách.

Rozdiel od deskriptorov relácie je v tom, že je potrebné nainštalovať iba vzdialených kandidátov. Úpravy tu sú zakázané a neprinášajú žiadne výhody. V niektorých implementáciách WebRTC je potrebné nainštalovať kandidátov až po nastavení deskriptorov relácie.

Prečo bol iba jeden deskriptor relácie, ale mohlo byť veľa kandidátov? Pretože umiestnenie v sieti môže byť určené nielen jeho internou IP adresou, ale aj externou adresou smerovača, a nie nevyhnutne len jednou, ako aj adresami serverov TURN. Zvyšok odseku bude venovaný podrobnej diskusii o kandidátoch a spôsobe pripojenia uzlov z rôznych súkromných sietí.

Takže dva uzly sú v rovnakej sieti (obrázok 8). Ako ich identifikovať? Pomocou IP adries. Žiadna iná cesta. Je pravda, že stále môžete používať rôzne prenosy (TCP a UDP) a rôzne porty. Toto sú informácie, ktoré obsahuje kandidátsky objekt - IP, PORT, TRANSPORT a niektoré ďalšie. Využime napríklad prenos UDP a port 531.

Obrázok 8: Dva uzly sú v rovnakej sieti

Potom, ak sme v uzle p1, WebRTC nám dá takýto kandidátsky objekt - . Toto nie je presný formát, len schéma. Ak sme v uzle p2, kandidát je . Prostredníctvom signalizačného mechanizmu p1 prijme kandidáta p2 (to znamená umiestnenie uzla p2, konkrétne jeho IP a PORT). Potom sa p1 môže pripojiť priamo k p2. Správnejšie, p1 pošle dáta na 10.50.150.3:531 v nádeji, že dosiahne p2. Nezáleží na tom, či táto adresa patrí uzlu p2 alebo nejakému sprostredkovateľovi. Dôležité je len to, že cez túto adresu sa budú odosielať dáta a môžu sa dostať na p2.

Pokiaľ sú uzly v jednej sieti, všetko je jednoduché a ľahké – každý uzol má len jeden kandidátsky objekt (vždy to znamená jeho vlastný, teda jeho umiestnenie v sieti). Ale keď budú uzly, bude oveľa viac kandidátov rôzne siete.

Prejdime k zložitejšiemu prípadu. Jeden uzol bude umiestnený za smerovačom (presnejšie za NAT) a druhý uzol bude umiestnený v rovnakej sieti s týmto smerovačom (napríklad na internete) (obrázok 9).

Obrázok 9: Jeden uzol je za NAT, druhý nie

Tento prípad má konkrétne riešenie problému, ktoré teraz zvážime. Domáci router zvyčajne obsahuje tabuľku NAT. Ide o špeciálny mechanizmus navrhnutý tak, aby umožnil uzlom v súkromnej sieti smerovača pristupovať napríklad k webovým stránkam.

Predpokladajme, že webový server je pripojený k internetu priamo, to znamená, že má verejnú IP * adresu. Nech je to uzol p2. Uzol p1 (webový klient) odošle požiadavku na adresu 10.50.200.10. Po prvé, údaje idú do smerovača r1, alebo skôr do jeho interiéru rozhranie 192.168.0.1. Potom si router zapamätá zdrojovú adresu (adresa p1) a zadá ju do špeciálnej tabuľky NAT, potom zmení zdrojovú adresu na svoju vlastnú (p1 → r1). Ďalej vlastným spôsobom externé router posiela dáta priamo na webový server p2. Webový server spracuje údaje, vygeneruje odpoveď a odošle ju späť. Pošle r1 do smerovača, pretože je v návratovej adrese (smerovač nahradil adresu svojou vlastnou). Router prijme dáta, pozrie sa na tabuľku NAT a odošle dáta do uzla p1. Smerovač tu funguje ako sprostredkovateľ.

Čo ak niekoľko uzlov z internej siete súčasne pristupuje k externej sieti? Ako router pochopí, komu má poslať odpoveď späť? Tento problém je vyriešený pomocou prístavov. Keď smerovač nahradí adresu hostiteľa svojou vlastnou, nahradí aj port. Ak dva uzly pristupujú na internet, router nahradí ich zdrojové porty rôzne. Potom, keď sa paket z webového servera vráti späť do smerovača, smerovač podľa portu pochopí, komu je paket priradený. Príklad nižšie.

Vráťme sa k technológii WebRTC, presnejšie k jej časti, ktorá využíva protokol ICE (preto kandidáti na ľad). Uzol p2 má jedného kandidáta (jeho umiestnenie v sieti je 10.50.200.10) a uzol p1, ktorý sa nachádza za smerovačom s NAT, bude mať dvoch kandidátov – lokálny (192.168.0.200) a kandidát na smerovač (10.50.200.5). Prvý z nich nie je užitočný, ale napriek tomu sa generuje, pretože WebRTC ešte nevie nič o vzdialenom uzle - môže alebo nemusí byť v rovnakej sieti. Druhý kandidát príde vhod a ako už vieme, dôležitú úlohu bude zohrávať port (na prechod cez NAT).

Záznam v tabuľke NAT sa vygeneruje iba vtedy, keď údaje opustia internú sieť. Preto musí uzol p1 prenášať dáta ako prvý a až potom môžu dáta z uzla p2 dosiahnuť uzol p1.

Na praxi oba uzly bude za NAT. Na vytvorenie záznamu v tabuľke NAT každého smerovača musia hostitelia poslať niečo vzdialenému hostiteľovi, ale tentoraz ani jeden nemôže dosiahnuť druhého a ani naopak. Je to spôsobené tým, že uzly nepoznajú svoje externé IP adresy a odosielanie údajov na interné adresy je zbytočné.

Ak sú však známe externé adresy, spojenie sa ľahko vytvorí. Ak prvý uzol odošle dáta do smerovača druhého uzla, smerovač ich bude ignorovať, pretože jeho tabuľka NAT je stále prázdna. V smerovači prvého uzla sa však v tabuľke NAT objavil potrebný záznam. Ak teraz druhý uzol posiela údaje do smerovača prvého uzla, smerovač ich úspešne prenesie do prvého uzla. Teraz má potrebné údaje aj tabuľka NAT druhého smerovača.

Problém je v tom, že na zistenie vašej externej IP adresy potrebujete uzol umiestnený v zdieľaná sieť. Na vyriešenie tohto problému sa používajú ďalšie servery, ktoré sú priamo pripojené k internetu. S ich pomocou sa tiež vytvárajú cenné položky v tabuľke NAT.

Servery STUN a TURN

Pri inicializácii WebRTC musíte špecifikovať dostupné servery STUN a TURN, ktoré budeme odteraz nazývať servery ICE. Ak nie sú špecifikované servery, budú sa môcť pripojiť iba uzly v rovnakej sieti (k nej pripojené bez NAT). Okamžite stojí za zmienku, že pre siete 3g je použitie serverov TURN povinné.

STUN server je jednoducho server na internete, ktorý vracia spiatočnú adresu, teda adresu uzla odosielateľa. Hostiteľ za smerovačom kontaktuje server STUN, aby prešiel NAT. Paket, ktorý prišiel na server STUN, obsahuje zdrojovú adresu – adresu smerovača, teda externú adresu nášho uzla. Toto je adresa STUN, ktorú server pošle späť. Uzol teda dostane svoju externú IP adresu a port, cez ktorý je prístupný zo siete. Ďalej WebRTC použije túto adresu na vytvorenie ďalšieho kandidáta (externá adresa smerovača a port). Teraz je v tabuľke NAT smerovača položka, ktorá umožňuje paketom odoslaným smerovaču na požadovanom porte dosiahnuť náš uzol.

Pozrime sa na tento proces na príklade.

Príklad (prevádzka servera STUN)

Server STUN bude označený s1. Smerovač, ako predtým, je cez r1 a uzol je cez p1. Budete tiež musieť sledovať tabuľku NAT - označíme ju ako r1_nat. Okrem toho táto tabuľka zvyčajne obsahuje veľa záznamov z rôznych uzlov podsiete - nebudú uvedené.

Takže na začiatku máme prázdnu tabuľku r1_nat.

Tabuľka 2: Hlavička paketu

Uzol p1 odošle tento paket do smerovača r1 (bez ohľadu na to, ako môžu použiť rôzne podsiete rôzne technológie). Router potrebuje nahradiť zdrojovú adresu Src IP, keďže adresa uvedená v pakete zjavne nie je vhodná pre externú podsieť, navyše adresy z takéhoto rozsahu sú rezervované a takúto adresu nemá ani jedna adresa na internete. Smerovač vykoná náhradu v pakete a vytvorí nový vstup vo vašej tabuľke r1_nat. Aby to urobil, musí prísť s číslom portu. Pripomeňme, že keďže niekoľko hostiteľov v rámci podsiete môže pristupovať k externej sieti, tabuľka NAT sa musí uložiť Ďalšie informácie, takže router môže určiť, ktorý z týchto niekoľkých uzlov je určený pre návratový paket zo servera. Nechajte smerovač prísť s portom 888.

Zmenená hlavička balíka:

Tabuľka 4: Tabuľka NAT bola aktualizovaná o novú položku

Tu sú IP adresa a port pre podsieť úplne rovnaké ako pôvodný paket. V skutočnosti pri postbackingu musíme mať spôsob, ako ich úplne obnoviť. Adresa IP pre externú sieť je adresa smerovača a port sa zmenil na port, ktorý vymyslel smerovač.

Skutočný port, na ktorom uzol p1 akceptuje pripojenie, je samozrejme 35777, ale server odosiela údaje do fiktívne port 888, ktorý router zmení na skutočný 35777.

Router teda nahradil zdrojovú adresu a port v hlavičke paketu a pridal položku do tabuľky NAT. Teraz je paket odoslaný cez sieť na server, to znamená do uzla s1. Na vstupe má s1 nasledujúci paket:

Src IP Src PORT Cieľový IP Cieľový PORT

10.50.200.5	888	12.62.100.200	6000

Tabuľka 5: Server STUN prijatý paket

Celkovo server STUN vie, že prijal paket z adresy 10.50.200.5:888. Teraz server pošle túto adresu späť. Oplatí sa tu zastaviť a ešte raz sa pozrieť na to, na čo sme sa práve pozreli. Vyššie uvedené tabuľky sú úryvkom z hlavička balík, vôbec nie z neho obsahu. O obsahu sme sa nebavili, keďže nie je až taký dôležitý – je nejako popísaný v protokole STUN. Teraz zvážime okrem názvu aj obsah. Bude jednoduchý a bude obsahovať adresu smerovača - 10.50.200.5:888, hoci sme ju prevzali z hlavička balík. Nerobí sa to často, protokoly sa zvyčajne nestarajú o informácie o adresách uzlov, dôležité je len to, aby boli pakety doručené na zamýšľané miesto určenia. Tu sa pozeráme na protokol, ktorý vytvára cestu medzi dvoma uzlami.

Takže teraz máme druhý paket, ktorý ide opačným smerom:

Tabuľka 7: Server STUN odošle paket s týmto obsahom

Potom paket putuje cez sieť, kým nedosiahne externé rozhranie smerovača r1. Smerovač chápe, že paket nie je preň určený. Ako tomu rozumie? To môže určiť iba prístav. Port 888 nepoužíva na svoje osobné účely, ale používa ho na mechanizmus NAT. Preto sa router pozerá na túto tabuľku. Pozrie sa na stĺpec Externý PORT a hľadá riadok, ktorý sa zhoduje s cieľovým PORTom z prichádzajúceho paketu, to znamená 888.

Interná IP Interná PORT Externá IP Externá PORT

192.168.0.200	35777	10.50.200.5	888

Tabuľka 8: Tabuľka NAT

Máme šťastie, takáto linka existuje. Ak by sme nemali šťastie, paket by bol jednoducho zahodený. Teraz musíte pochopiť, ktorý uzol v podsieti by mal poslať tento paket. Netreba sa ponáhľať, opäť si pripomeňme dôležitosť portov v tomto mechanizme. Súčasne dva uzly v podsieti mohli odosielať požiadavky do externej siete. Potom, ak router prišiel s portom 888 pre prvý uzol, potom pre druhý by prišiel s portom 889. Predpokladajme, že sa to stalo, to znamená, že tabuľka r1_nat vyzerá takto:

Tabuľka 10: Smerovač nahrádza adresu prijímača

Src IP Src PORT Cieľový IP Cieľový PORT

12.62.100.200	6000	192.168.0.200	35777

Tabuľka 11: Smerovač zmenil adresu prijímača

Paket úspešne dorazí do uzla p1 a pri pohľade na obsah paketu sa uzol dozvie o svojej externej IP adrese, teda o adrese smerovača na externej sieti. Pozná aj port, ktorým router prechádza cez NAT.

Čo bude ďalej? Načo je toto všetko? Výhoda je záznam v tabuľke r1_nat. Ak teraz niekto pošle paket s portom 888 smerovaču r1, smerovač prepošle tento paket uzlu p1. Vznikol tak malý úzky priechod do skrytého uzla p1.

Z vyššie uvedeného príkladu môžete získať určitú predstavu o tom, ako funguje NAT a o podstate servera STUN. Vo všeobecnosti sú mechanizmus ICE a servery STUN/TURN presne zamerané na prekonanie obmedzení NAT.

Medzi uzlom a serverom nemôže byť jeden smerovač, ale niekoľko. V tomto prípade uzol dostane adresu smerovača, ktorý ako prvý pristupuje k rovnakej sieti ako server. Inými slovami, získame adresu smerovača pripojeného k serveru STUN. Pre p2p komunikáciu je to presne to, čo potrebujeme, ak nezabudneme na fakt, že každý router si do tabuľky NAT pridá linku, ktorú potrebujeme. Preto bude cesta späť opäť rovnako hladká.

Server TURN je vylepšený server STUN. Odtiaľto by ste si mali okamžite uvedomiť, že každý server TURN môže fungovať aj ako server STUN. Existujú však aj výhody. Ak nie je možná komunikácia p2p (ako napríklad v sieťach 3g), server sa prepne do režimu relé, to znamená, že funguje ako sprostredkovateľ. Samozrejme, nehovoríme o žiadnom p2p, ale mimo mechanizmu ICE si uzly myslia, že komunikujú priamo.

V akých prípadoch je potrebný server TURN? Prečo nie je dostatok servera STUN? Faktom je, že existuje niekoľko typov NAT. Nahrádzajú IP adresu a port rovnakým spôsobom, ale niektoré z nich majú zabudovanú dodatočnú ochranu proti „falšovaniu“. Napríklad v symetrické V tabuľke NAT sú uložené ďalšie 2 parametre - IP a port vzdialeného hostiteľa. Paket z externej siete prechádza cez NAT do internej siete iba vtedy, ak sa zdrojová adresa a port zhodujú s tými, ktoré sú zaznamenané v tabuľke. Preto trik so serverom STUN zlyhá - v tabuľke NAT je uložená adresa a port servera STUN a keď smerovač prijme paket od partnera WebRTC, zahodí ho, pretože je „sfalšovaný“. Nepochádza zo servera STUN.

Server TURN je teda potrebný v prípade, keď sú obaja partneri pozadu symetrické NAT (každý po svojom).

Krátke zhrnutie

Tu je niekoľko vyhlásení o entitách WebRTC, ktoré by ste mali mať vždy na pamäti. Sú podrobne opísané vyššie. Ak sa vám niektorý z výrokov nezdá úplne jasný, prečítajte si znova príslušné odseky.

• Mediálny prúd
  • Obrazové a zvukové údaje sú zabalené do mediálnych tokov
  • Toky médií synchronizujú mediálne stopy, ktoré tvoria
  • Rôzne mediálne toky nie sú navzájom synchronizované
  • Mediálne streamy môžu byť lokálne a vzdialené, lokálne sú väčšinou pripojené ku kamere a mikrofónu, vzdialené prijímajú dáta zo siete v zašifrovanej podobe
  • Existujú dva typy mediálnych stôp – pre video a pre zvuk.
  • Mediálne stopy majú možnosť zapnúť/vypnúť
  • Mediálne stopy pozostávajú z mediálnych kanálov
  • Mediálne stopy synchronizujú mediálne kanály, ktoré tvoria
  • Mediálne toky a mediálne stopy majú štítky, podľa ktorých ich možno rozlíšiť
• Rukoväť relácie
  • Deskriptor relácie sa používa na logické prepojenie dvoch sieťových uzlov
  • Deskriptor relácie ukladá informácie o dostupné spôsoby kódovanie obrazových a zvukových údajov
  • WebRTC využíva externý signalizačný mechanizmus – úloha preposielania deskriptorov relácie (sdp) pripadá na aplikáciu
  • Mechanizmus logického spojenia pozostáva z dvoch fáz - ponuka (ponuka) a odpoveď (odpoveď)
  • Generovanie deskriptora relácie nie je možné bez použitia lokálneho mediálneho toku v prípade ponuky a nie je možné bez použitia deskriptora vzdialenej relácie v prípade odpovede.
  • Výsledný deskriptor musí byť daný implementácii WebRTC a nezáleží na tom, či je tento deskriptor prijatý vzdialene alebo lokálne z rovnakej implementácie WebRTC.
  • Je možné mierne upraviť deskriptor relácie
• Kandidáti
  • Kandidát na ľad je adresa uzla v sieti
  • Adresa uzla môže byť vaša vlastná alebo to môže byť adresa smerovača alebo servera TURN
  • Kandidátov je vždy veľa
  • Kandidát sa skladá z IP adresy, portu a typu transportu (TCP alebo UDP)
  • Kandidáti sa používajú na vytvorenie fyzického spojenia medzi dvoma uzlami v sieti
  • Kandidátov je tiež potrebné poslať prostredníctvom signalizačného mechanizmu
  • Kandidátov je tiež potrebné odovzdať implementáciám WebRTC, ale iba vzdialeným
  • V niektorých implementáciách WebRTC môžu byť kandidáti prenášaní až po nastavení deskriptora relácie
• STUN/TURN/ICE/NAT
  • NAT je mechanizmus na poskytovanie prístupu k externej sieti
  • Domáce smerovače podporujú špeciálnu tabuľku NAT
  • Router nahrádza adresy v paketoch – zdrojovú adresu svojou vlastnou, ak paket ide do externej siete, a adresu prijímača adresou hostiteľa vo vnútornej sieti, ak paket prišiel z externej siete
  • Na poskytnutie viackanálového prístupu k externej sieti používa NAT porty
  • ICE - NAT Traversal Engine
  • Servery STUN a TURN – asistenčné servery pre prechod NAT
  • Server STUN vám umožňuje vytvárať potrebné položky v tabuľke NAT a tiež vracia externú adresu hostiteľa
  • Server TURN zovšeobecňuje mechanizmus STUN a umožňuje mu vždy fungovať
  • V najhorších prípadoch sa TURN server používa ako sprostredkovateľ (relé), to znamená, že p2p sa zmení na spojenie klient-server-klient.

Dnes je WebRTC „horúcou“ technológiou na streamovanie zvuku a videa v prehliadačoch. Konzervatívne technológie, ako HTTP Streaming a Flash, sú vhodnejšie na distribúciu nahratého obsahu (video na požiadanie) a sú výrazne horšie ako WebRTC v reálnom čase a online vysielaní, t.j. kde je potrebná minimálna latencia videa, aby diváci mohli vidieť, čo sa deje „naživo“.

Možnosť kvalitnej komunikácie v reálnom čase pochádza zo samotnej architektúry WebRTC, kde sa na prenos video streamov používa protokol UDP, ktorý je štandardným základom pre prenos videa s minimálnym oneskorením a je široko používaný v systémoch komunikácie v reálnom čase.

Komunikačná latencia je dôležitá v online vysielacích systémoch, webinároch a iných aplikáciách, ktoré vyžadujú interaktívnu komunikáciu so zdrojom videa, koncovými používateľmi a vyžadujú riešenie.

Ďalším dobrým dôvodom na vyskúšanie WebRTC je, že je to určite trend. Dnes každý Android Prehliadač Chrome podporuje túto technológiu, ktorá zaručuje, že milióny zariadení sú pripravené na sledovanie vysielania bez inštalácie akéhokoľvek dodatočného softvéru alebo konfigurácií.

S cieľom otestovať technológiu WebRTC v akcii a spustiť jednoduchý online vysielanie, použili sme serverový softvér Flashphoner WebRTC Media & Broadcasting Server. Funkcie uvádzajú schopnosť vysielať WebRTC streamy v režime one-to-many, ako aj podporu IP kamier a video monitorovacích systémov prostredníctvom protokolu RTSP; V tejto recenzii sa zameriame na web-webové vysielania a ich funkcie.

Inštalácia WebRTC Media & Broadcasting Server

Pretože pre systémy Windows neexistovala žiadna serverová verzia a nechcel som inštalovať virtuálny stroj ako VMWare+Linux, aby som mohol testovať online vysielanie doma Počítač so systémom Windows Nevyšlo to. Aby sme ušetrili čas, rozhodli sme sa použiť príklad cloudového hostingu, ako je tento:

Bol to Centos x86_64 verzie 6.5 bez akéhokoľvek predinštalovaného softvéru v amsterdamskom dátovom centre. Takže všetko, čo máme k dispozícii, je server a ssh prístup k nemu. Pre tých, ktorí sú oboznámení s príkazy konzoly Linux, inštalácia servera WebRTC sľubuje, že bude jednoduchá a bezbolestná. Čo sme teda urobili:

1. Stiahnite si archív:

$wget https://site/download-wcs5-server.tar.gz

2. Rozbaľte:

$tar -xzf download-wcs5-server.tar.gz

3. Nainštalujte:

$cd FlashphonerWebCallServer

Počas inštalácie zadajte IP adresu servera: XXX.XXX.XXX.XXX

4. Aktivujte licenciu:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Spustite server WCS:

$service webcallserver štart

6. Skontrolujte denník:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Skontrolujte, či sú zavedené dva procesy:

$ps aux | grep Flashphoner

Proces inštalácie je dokončený.

Testovanie online vysielania WebRTC

Testovanie vysielaní sa ukázalo ako jednoduchá záležitosť. Okrem servera existuje webový klient, ktorý pozostáva z tucta súborov Javascript, HTML a CSS a bol nami nasadený do priečinka /var/www/html počas fázy inštalácie. Jediné, čo som musel urobiť, bolo zadať IP adresu servera do konfigurácie flashphoner.xml, aby webový klient mohol nadviazať spojenie so serverom cez HTML5 Websockets. Poďme si popísať proces testovania.

1. V prehliadači Chrome otvorte stránku testovacieho klienta index.html:

2. Ak chcete spustiť vysielanie, musíte kliknúť na tlačidlo „Štart“ v strede obrazovky.
Predtým, ako to urobíte, sa musíte uistiť, že je webová kamera pripojená a pripravená na použitie. Na webkameru nie sú kladené žiadne špeciálne požiadavky, napríklad sme použili štandardnú kameru zabudovanú v notebooku s rozlíšením 1280x800.

Prehliadač Chrome určite požiada o prístup ku kamere a mikrofónu, aby používateľ pochopil, že jeho video bude odoslané na internetový server a povolil to.

3. Rozhranie predstavuje úspešné vysielanie toku videa z kamery na server WebRTC. V pravom hornom rohu indikátor indikuje, že stream smeruje na server, v dolnom rohu je tlačidlo „Stop“ na zastavenie odosielania videa.

Všimnite si prosím odkaz v poli nižšie. Obsahuje jedinečný identifikátor pre tento stream, takže ktokoľvek sa môže pripojiť k sledovaniu. Stačí otvoriť tento odkaz v prehliadači. Ak ho chcete skopírovať do schránky, kliknite na tlačidlo „Kopírovať“.

V reálnych aplikáciách, ako sú webináre, prednášky, online video vysielania alebo interaktívna televízia, budú musieť vývojári implementovať distribúciu tohto identifikátora určitým skupinám divákov, aby sa mohli pripojiť k požadovaným streamom, ale to je už logika aplikácie. . WebRTC Media & Broadcasting Server to neovplyvňuje, ale iba distribuuje video.

5. Spojenie sa vytvorí a divák vidí stream na obrazovke. Teraz môže poslať odkaz niekomu inému, zastaviť prehrávanie streamu alebo povoliť režim celej obrazovky pomocou ovládacích prvkov v pravom dolnom rohu.

Výsledky testovania online vysielacieho servera WebRTC

Počas testov sa latencia zdala dokonalá. Ping do dátového centra bol asi 100 milisekúnd a oneskorenie bolo pre oko neviditeľné. Odtiaľ môžeme predpokladať, že skutočné oneskorenie je rovnakých 100 plus alebo mínus niekoľko desiatok milisekúnd pre čas ukladania do vyrovnávacej pamäte. V porovnaní s Flash videom: pri takýchto testoch sa Flash nespráva tak dobre ako WebRTC. Ak teda pohnete rukou na podobnej sieti, pohyb na obrazovke je vidieť až po jednej alebo dvoch sekundách.

Pokiaľ ide o kvalitu, poznamenávame, že kocky sa niekedy dajú rozlíšiť podľa pohybov. To je v súlade s povahou kodeku VP8 a jeho hlavným účelom – poskytovať video komunikáciu v reálnom čase s prijateľnou kvalitou a bez komunikačných oneskorení.

Server sa inštaluje a konfiguruje pomerne jednoducho, jeho prevádzka si nevyžaduje žiadne vážne zručnosti okrem znalosti Linuxu na úrovni pokročilého používateľa, ktorý vie spúšťať príkazy z konzoly cez ssh a používať textový editor. Výsledkom bolo, že sa nám podarilo nastaviť online vysielanie typu one-to-many medzi prehliadačmi. Pripojenie ďalších divákov k streamu tiež nerobilo problémy.

Kvalita vysielania sa ukázala byť celkom prijateľná pre webináre a online prenosy. Jediné, čo vyvolalo nejaké otázky, bolo rozlíšenie videa. Kamera podporuje rozlíšenie 1280x800, no rozlíšenie na testovacej snímke je veľmi podobné 640x480. Zdá sa, že tento problém je potrebné objasniť s vývojármi.

Video o testovaní vysielania z webovej kamery
cez WebRTC server

Technológie na uskutočňovanie hovorov z prehliadača existujú už mnoho rokov: Java, ActiveX, Adobe Flash...V posledných rokoch sa ukázalo, že pluginy a odišiel virtuálne stroje Nežiaria pohodlím (prečo by som mal vôbec niečo inštalovať?) a hlavne bezpečnosťou. Čo robiť? Existuje východ!

Až donedávna IP siete používali niekoľko protokolov pre IP telefóniu alebo video: SIP, najbežnejší protokol, H.323 a MGCP prichádzajúce zo scény, Jabber/Jingle (používaný v Gtalku), polootvorený Adobe RTMP* a samozrejme , zatvoril Skype. Projekt WebRTC, ktorý iniciovala spoločnosť Google, sa snaží zmeniť stav vecí vo svete IP a webovej telefónie. softvérové ​​telefóny vrátane Skype. WebRTC nielenže implementuje všetky komunikačné možnosti priamo vo vnútri prehliadača, ktorý je dnes nainštalovaný takmer na každom zariadení, ale snaží sa súčasne riešiť aj všeobecnejší problém komunikácie medzi používateľmi prehliadača (výmena rôznych údajov, vysielanie obrazoviek, spolupráca s dokumentmi, oveľa viac).

WebRTC z pohľadu webového vývojára

Z pohľadu webového vývojára sa WebRTC skladá z dvoch hlavných častí:

• ovládanie mediálnych tokov z miestnych zdrojov (kamera, mikrofón alebo obrazovka lokálny počítač) je implementovaná metódou navigator.getUserMedia, ktorá vracia objekt MediaStream;
• peer-to-peer komunikácia medzi zariadeniami generujúcimi mediálne toky, vrátane definovania komunikačných metód a ich priameho prenosu – objektov RTCPeerConnection (na odosielanie a prijímanie audio a video streamov) a RTCDataChannel (na odosielanie a prijímanie dát z prehliadača).

Čo urobíme?

Zistíme, ako zorganizovať jednoduchý videorozhovor pre viacerých používateľov medzi prehliadačmi založenými na WebRTC pomocou webových soketov. Začneme experimentovať v prehliadači Chrome/Chromium ako najpokročilejších prehliadačoch z hľadiska WebRTC, hoci Firefox 22, vydaný 24. júna, ich takmer dobehol. Treba povedať, že štandard ešte nebol prijatý a API sa môže meniť od verzie k verzii. Všetky príklady boli testované v prehliadači Chromium 28. Pre jednoduchosť nebudeme sledovať čistotu kódu a kompatibilitu medzi prehliadačmi.

MediaStream

Prvým a najjednoduchším komponentom WebRTC je MediaStream. Umožňuje prehliadaču prístup k mediálnym tokom z kamery a mikrofónu miestneho počítača. V prehliadači Chrome na to musíte zavolať funkciu navigator.webkitGetUserMedia() (keďže štandard ešte nie je dokončený, všetky funkcie majú predponu a vo Firefoxe sa rovnaká funkcia nazýva navigator.mozGetUserMedia()). Keď ho zavoláte, používateľ bude požiadaný o povolenie prístupu ku kamere a mikrofónu. V hovore bude možné pokračovať až po udelení súhlasu užívateľa. Parametre požadovaného mediálneho toku a dve funkcie spätného volania sa odovzdávajú ako parametre tejto funkcii: prvá bude volaná, ak sa úspešne získa prístup ku kamere/mikrofónu, druhá - v prípade chyby. Najprv vytvorte súbor HTML rtctest1.html s tlačidlom a prvkom:

WebRTC – prvé úvodné video ( výška: 240px; šírka: 320px; orámovanie: 1px plná sivá; ) getUserMedia

Microsoft CU-RTC-Web

Microsoft by nebol Microsoft, keby okamžite nezareagoval na iniciatívu Google uvoľnením vlastnej nekompatibilnej neštandardnej možnosti s názvom CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Aj keď podiel IE, už aj tak malý, naďalej klesá, počet používateľov Skype dáva Microsoftu nádej vytlačiť Google a dá sa predpokladať, že práve tento štandard bude v prehliadači použitý Verzie Skype. Štandard Google je zameraný predovšetkým na komunikáciu medzi prehliadačmi; zároveň veľká časť hlasovej prevádzky stále zostáva v bežnej telefónnej sieti a brány medzi ňou a IP sieťami sú potrebné nielen kvôli jednoduchosti používania alebo rýchlejšej distribúcii, ale aj ako prostriedok monetizácie, ktorý umožní viacerým hráčom rozvíjať ich. Vznik ďalšieho štandardu môže viesť nielen k nepríjemnej potrebe vývojárov podporovať dve nekompatibilné technológie naraz, ale aj v budúcnosti poskytnúť používateľovi širší výber možnej funkcionality a dostupných technických riešení. Počkaj a uvidíš.

Povolenie miestneho streamu

Vo vnútri značiek nášho súboru HTML deklarujme globálnu premennú pre stream médií:

Var localStream = null;

Prvý parameter metódy getUserMedia musí špecifikovať parametre požadovaného mediálneho toku – napríklad jednoducho povoliť zvuk alebo video:

Var streamConstraints = ("audio": true, "video": true); // Požiadajte o prístup k zvuku aj videu

Alebo zadajte ďalšie parametre:

Var streamConstraints = ( "audio": true, "video": ( "povinné": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "voliteľné": ) );

Druhý parameter metódy getUserMedia musí byť odovzdaný funkcii spätného volania, ktorá sa zavolá, ak bude úspešná:

Funkcia getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Pripojte stream médií k prvku HTML localStream = stream; // a uložte ho v globálnej premennej pre ďalšie použitie)

Tretím parametrom je funkcia spätného volania, obsluha chýb, ktorá sa zavolá v prípade chyby

Funkcia getUserMedia_error(error) ( console.log("getUserMedia_error():", chyba); )

Skutočným volaním metódy getUserMedia je požiadavka na prístup k mikrofónu a kamere po stlačení prvého tlačidla

Funkcia getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Nie je možné získať prístup k mediálnemu prúdu zo súboru otvoreného lokálne. Ak sa to pokúsime urobiť, dostaneme chybu:

NavigatorUserMediaError (kód: 1, PERMISSION_DENIED: 1)"

Nahrajte výsledný súbor na server, otvorte ho v prehliadači a ako odpoveď na zobrazenú požiadavku povoľte prístup ku kamere a mikrofónu.

Zariadenia, ku ktorým bude mať Chrome prístup, si môžete vybrať v časti Nastavenia, Zobraziť odkaz na rozšírené nastavenia, v sekcii Ochrana osobných údajov, tlačidlo Obsah. V prehliadačoch Firefox a Opera sa zariadenia vyberajú z rozbaľovacieho zoznamu priamo pri povolení prístupu.

Pri použití protokolu HTTP sa povolenie bude vyžadovať pri každom prístupe k mediálnemu toku po načítaní stránky. Prechod na HTTPS vám umožní zobraziť požiadavku raz, len pri prvom prístupe k mediálnemu streamu.

Všimnite si pulzujúci kruh v ikone záložky a ikonu fotoaparátu na pravej strane panela s adresou:

RTCMediaConnection

RTCMediaConnection je objekt určený na vytvorenie a prenos mediálnych tokov cez sieť medzi účastníkmi. Okrem toho je tento objekt zodpovedný za generovanie popisu mediálnej relácie (SDP), získavanie informácií o kandidátoch ICE na prechádzanie NAT resp. firewally(lokálne a pomocou STUN) a interakcia so serverom TURN. Každý účastník musí mať jedno pripojenie RTCMediaConnection na pripojenie. Toky médií sa prenášajú pomocou šifrovaného protokolu SRTP.

TURN servery

Existujú tri typy kandidátov ICE: hostiteľ, srflx a relé. Hostiteľ obsahuje informácie prijaté lokálne, srflx - ako uzol vyzerá na externom serveri (STUN) a relay - informácie pre proxy prevádzku cez server TURN. Ak je náš uzol za NAT, kandidáti na hostiteľa budú obsahovať miestne adresy a bude to zbytočné, kandidáti srflx pomôžu len s určitými typmi NAT a relay bude poslednou nádejou na prenos prevádzky cez medziľahlý server.

Príklad kandidáta ICE typu hostiteľ s adresou 192.168.1.37 a portom udp/34022:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 typ generácie hostiteľa 0

Všeobecný formát pre špecifikáciu serverov STUN/TURN:

Var servers = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "password" ) ]);

Na internete je veľa verejných serverov STUN. Veľký zoznam je napr. Žiaľ, riešia príliš málo problémov. Na rozdiel od STUN prakticky neexistujú žiadne verejné TURN servery. Je to spôsobené tým, že server TURN prechádza mediálnymi tokmi, ktoré môžu výrazne zaťažiť sieťový kanál aj samotný server. Najjednoduchší spôsob, ako sa pripojiť k serverom TURN, je nainštalovať si ich sami (samozrejme, že budete potrebovať verejnú IP). Zo všetkých serverov je podľa mňa najlepší rfc5766-turn-server. Existuje dokonca hotový obrázok pre Amazon EC2.

S TURN nie je všetko tak dobré, ako by sme chceli, ale prebieha aktívny vývoj a rád by som dúfal, že po nejakom čase WebRTC, ak sa nebude rovnať Skype, pokiaľ ide o kvalitu prechodu cez preklad adries (NAT) a firewally , je prinajmenšom badateľné priblížiť sa.

RTCMediaConnection vyžaduje dodatočný mechanizmus na výmenu riadiacich informácií na nadviazanie spojenia – tieto dáta síce generuje, ale neprenáša ich a prenos k ostatným účastníkom musí byť realizovaný samostatne.

Výber spôsobu prenosu je na vývojárovi - aspoň manuálne. Hneď ako dôjde k výmene potrebných údajov, RTCMediaConnection automaticky nainštaluje mediálne streamy (samozrejme, ak je to možné).

model ponuka-odpoveď

Na vytvorenie a zmenu mediálnych tokov sa používa model ponuka/odpoveď (opísaný v RFC3264) a protokol SDP (Session Description Protocol). Používa ich aj protokol SIP. V tomto modeli sú dvaja agenti: Offerer – ten, kto generuje popis SDP relácie na vytvorenie nového alebo úpravu existujúceho (Offer SDP), a Answerer – ten, ktorý dostane popis SDP relácie od iného agenta a odpovie vlastným popisom relácie (Odpoveď SDP). Špecifikácia zároveň vyžaduje protokol vyššej úrovne (napríklad SIP alebo vlastný cez webové zásuvky, ako v našom prípade), ktorý je zodpovedný za prenos SDP medzi agentmi.

Aké údaje je potrebné odovzdať medzi dvoma pripojeniami RTCMediaConnection, aby mohli úspešne vytvoriť toky médií:

• Prvý účastník, ktorý iniciuje spojenie, vytvorí ponuku, v ktorej odošle dátovú štruktúru SDP (rovnaký protokol sa používa na rovnaký účel v SIP) s popisom možných charakteristík mediálneho toku, ktorý sa má začať vysielať. Tento blok údajov sa musí preniesť na druhého účastníka. Druhý účastník vytvorí odpoveď so svojím SDP a pošle ju prvému.
• Prvý aj druhý účastník vykonávajú postup určenia možných kandidátov na ICE, pomocou ktorého im druhý účastník môže prenášať mediálny tok. Po identifikácii kandidátov by sa informácie o nich mali postúpiť ďalšiemu účastníkovi.

Ponuka formácie

Na vygenerovanie Ponuky potrebujeme dve funkcie. Prvý sa zavolá, ak sa úspešne vytvorí. Druhým parametrom metódy createOffer() je funkcia spätného volania volaná v prípade chyby pri jej vykonávaní (za predpokladu, že lokálne vlákno je už dostupné).

Okrem toho sú potrebné dve obsluhy udalostí: onicecandidate pri definovaní nového kandidáta ICE a onaddstream pri pripájaní mediálneho toku zo vzdialenej strany. Vráťme sa k nášmu súboru. Pridajme ďalší do HTML za riadky s prvkami:

vytvoriťPonuku

A za riadkom s prvkom (pre budúcnosť):

Na začiatku kódu JavaScript tiež deklarujeme globálnu premennú pre RTCPeerConnection:

Var pc1;

Pri volaní konštruktora RTCPeerConnection musíte zadať servery STUN/TURN. Viac informácií o nich nájdete na bočnom paneli; pokiaľ sú všetci účastníci v rovnakej sieti, nevyžadujú sa.

Var servery = null;

Parametre na prípravu SDP ponuky

Var offerConstraints = ();

Prvým parametrom metódy createOffer() je funkcia spätného volania volaná po úspešnom vytvorení ponuky

Funkcia pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Nastavenie RTCPeerConnection vygenerovaného ponukou SDP pomocou metódy setLocalDescription. // Keď druhá strana odošle svoju odpoveď SDP, bude potrebné ju nastaviť pomocou metódy setRemoteDescription // Kým nebude implementovaná druhá strana, nerobíme nič // pc2_receivedOffer(desc); )

Druhým parametrom je funkcia spätného volania, ktorá sa zavolá v prípade chyby

Funkcia pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )

A deklarujme funkciu spätného volania, do ktorej budú kandidáti ICE odovzdaní, keď budú určení:

Funkcia pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Kým nebude implementovaná druhá strana, nerobíme nič // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

A tiež funkcia spätného volania na pridanie mediálneho streamu zo vzdialenej strany (pre budúcnosť, keďže zatiaľ máme len jedno RTCPeerConnection):

Funkcia pc1_onaddstream(udalosť) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

Keď kliknete na tlačidlo „createOffer“, vytvoríme RTCPeerConnection, nastavíme metódy onicecandidate a onaddstream a požiadame o vytvorenie ponuky SDP volaním metódy createOffer():

Funkcia createOffer_click() ( console.log("createOffer_click()"); pc1 = nový webkitRTCPeerConnection(servers); // Vytvorenie RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Funkcia spätného volania na spracovanie kandidátov ICE pc1.onadonaddstream = pc1 Funkcia spätného volania volaná, keď sa mediálny tok objaví zo vzdialenej strany. Zatiaľ neexistuje pc1.addStream(localStream); // Prenesme lokálny mediálny tok (za predpokladu, že už bol prijatý) pc1.createOffer(// A skutočne požiadame vytvorenie Ponuky pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Uložíme súbor ako rtctest2.html, nahráme ho na server, otvoríme v prehliadači a v konzole uvidíme, aké dáta sa pri jeho prevádzke generujú. Druhé video sa zatiaľ nezobrazí, keďže je len jeden účastník. Pripomeňme, že SDP je popis parametrov mediálnej relácie, dostupné kodeky, mediálne toky a kandidáti ICE sú možnými možnosťami pripojenia k danému účastníkovi.

Vytvorenie odpovede SDP a výmena kandidátov ICE

Ponuka SDP aj každý z kandidátov ICE musia byť prenesené na druhú stranu a tam, po ich prijatí, RTCPeerConnection zavolá metódy setRemoteDescription pre ponuku SDP a addIceCandidate pre každého kandidáta ICE prijatého z opačnej strany; podobne v opačná strana pre odpoveď SDP a vzdialených ICE kandidátov. Samotný Answer SDP sa tvorí podobne ako Ponuka; rozdiel je v tom, že sa nevolá metóda createOffer, ale metóda createAnswer a predtým sa metóda RTCPeerConnection setRemoteDescription odovzdá Offer SDP prijatej od volajúceho.

Pridajme do HTML ďalší prvok videa:

A globálna premenná pre druhú RTCPeerConnection podľa deklarácie prvej:

Var pc2;

Spracovanie ponuky a odpovede SDP

Vytvorenie Answer SDP je veľmi podobné ako Offer. Vo funkcii spätného volania, ktorá sa volá po úspešnom vytvorení odpovede, podobne ako v ponuke Ponuka, poskytneme miestny popis a prijatú SDP odpovede postúpime prvému účastníkovi:

Funkcia pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

Funkcia spätného volania, ktorá sa volá v prípade chyby pri generovaní odpovede, je úplne podobná funkcii Ponuka:

Funkcia pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", chyba); )

Parametre na vytvorenie odpovede SDP:

Var answerConstraints = ( "povinné": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true) );

Keď druhý účastník dostane Ponuku, vytvoríme RTCPeerConnection a vytvoríme odpoveď rovnakým spôsobom ako Ponuka:

Funkcia pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Vytvorenie objektu RTCPeerConnection pre druhého účastníka rovnakým spôsobom ako pre prvého pc2 = nový webkitRTCPeerConnection(servers); pc2.onicecandidate = pcdidate2_onicecan ; // Nastavte obsluhu udalosti, keď sa objaví ICE kandidát pc2.onaddstream = pc_onaddstream; // Keď sa objaví stream, pripojte ho k HTML pc2.addStream(localStream); // Preneste lokálny mediálny stream (v našom príklade druhý účastník má rovnaký ako prvý) // Teraz, keď je pripravené druhé pripojenie RTCPeerConnection, odošleme mu prijatú ponuku SDP (prvému sme odovzdali lokálny stream) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Požiadajte druhé pripojenie o vygenerovanie údajov pre správu s odpoveďou pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Aby sme v našom príklade preniesli Offer SDP od prvého účastníka k druhému, odkomentujme ho vo funkcii pc1 vytvoriťPonuku telefonická linka success():

Pc2_receivedOffer(desc);

Ak chcete implementovať spracovanie kandidátov ICE, zrušte komentár v obslužnom programe udalosti pripravenosti kandidátov ICE prvého účastníka pc1_onicecandidate() jeho prenos na druhého:

Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));

Obsluha udalosti pripravenosti kandidáta na ICE druhého účastníka je zrkadlovo podobná prvému:

Funkcia pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Funkcia spätného volania na pridanie mediálneho streamu od prvého účastníka:

Funkcia pc2_onaddstream(udalosť) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Ukončenie spojenia

Pridajme do HTML ďalšie tlačidlo

Zložiť

A funkcia na ukončenie spojenia

Funkcia btnHangupClick() ( // Odpojenie lokálneho videa od prvkov HTML, zastavenie lokálneho mediálneho streamu, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Pre každého účastníka zakáže video z HTML prvkov, zatvorte spojenie, nastavte ukazovateľ = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Uložme to ako rtctest3.html, nahrajme na server a otvorme v prehliadači. Tento príklad implementuje obojsmerný prenos mediálnych tokov medzi dvoma RTCPeerConnections v rámci rovnakej karty prehliadača. Na organizovanie výmeny Offer and Answer SDP, ICE kandidátov medzi účastníkmi a iných informácií cez sieť, namiesto priameho volania procedúr, bude potrebné realizovať výmenu medzi účastníkmi pomocou nejakého druhu dopravy, v našom prípade - webových zásuviek.

Vysielanie obrazovky

Funkcia getUserMedia môže tiež zachytiť obrazovku a streamovať ako MediaStream zadaním nasledujúcich parametrov:

Var mediaStreamConstraints = ( audio: false, video: ( povinné: ( chromeMediaSource: "screen"), voliteľné: ) );

Pre úspešný prístup na obrazovku je potrebné splniť niekoľko podmienok:

• povoliť príznak snímky obrazovky v getUserMedia() v chrome://flags/,chrome://flags/;
• zdrojový súbor je potrebné stiahnuť cez HTTPS (originál SSL);
• audio stream by sa nemal požadovať;
• Na jednej karte prehliadača by sa nemali vykonávať viaceré požiadavky.

Knižnice pre WebRTC

Hoci WebRTC ešte nie je dokončený, objavilo sa už niekoľko knižníc, ktoré sú na ňom založené. JsSIP je navrhnutý na vytváranie softvérových telefónov založených na prehliadači, ktoré pracujú s prepínačmi SIP, ako sú Asterisk a Camalio. PeerJS uľahčí vytváranie P2P sietí na výmenu dát a Holla zníži množstvo vývoja potrebného na P2P komunikáciu z prehliadačov.

Node.js a socket.io

Na organizovanie výmeny SDP a ICE kandidátov medzi dvoma RTCPeerConnections cez sieť používame Node.js s modulom socket.io.

Je popísaná inštalácia najnovšej stabilnej verzie Node.js (pre Debian/Ubuntu).

$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs

Inštalácia pre ostatných OS popísané

Skontrolujme to:

$ echo "sys=require("util"); sys.puts("Testovacia správa");" > nodetest1.js $ nodejs nodetest1.js

Pomocou npm (Node Package Manager) nainštalujeme socket.io a dodatočný expresný modul:

$ npm nainštalovať socket.io express

Poďme to otestovať vytvorením súboru nodetest2.js na strane servera:

$ nano nodetest2.js var app = require("express")() , server = required("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Ak je port 80 bezplatný app.get("/", funkcia (req, res) ( // Pri prístupe na koreňovú stránku res.sendfile(__dirname + "/nodetest2.html"); // odošlite súbor HTML ) ); io.sockets.on("pripojenie", funkcia (socket) ( // Pri pripájaní socket.emit("udalosť servera", ( ahoj: "svet" )); // odoslanie správy socket.on("udalosť klienta" , funkcia (údaje) ( // a deklarácia obsluhy udalosti, keď správa príde z klienta console.log(data); )); ));

A nodetest2.html pre stranu klienta:

$ nano nodetest2.html var socket = io.connect("/"); // URL servera Websocket (koreňová stránka servera, z ktorej bola stránka načítaná) socket.on("udalosť servera", funkcia (údaje) ( console.log(data); socket.emit("udalosť klienta", ( "meno": "hodnota" )); ));

Spustíme server:

$ sudo nodejs nodetest2.js

a otvorte v prehliadači stránku http://localhost:80 (ak beží lokálne na porte 80). Ak je všetko úspešné, v konzole JavaScript prehliadača uvidíme výmenu udalostí medzi prehliadačom a serverom pri pripojení.

Výmena informácií medzi RTCPeerConnection cez webové zásuvky Klientska časť

Uložme náš hlavný príklad (rtcdemo3.html) pod novým názvom rtcdemo4.html. Zahrňme knižnicu socket.io do prvku:

A na začiatku skriptu JavaScript – pripojenie k websockets:

Var socket = io.connect("http://localhost");

Nahraďte priame volanie funkcií iného účastníka zaslaním správy cez webové zásuvky:

Funkcia createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("offer", desc); ... ) funkcia pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("odpoveď", desc); ) funkcia pc1_onicecandidate(udalosť) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) funkcia pc2_onicecandidate(udalosť) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

Vo funkcii hangup() namiesto priameho volania funkcií druhého účastníka odošleme správu cez webové zásuvky:

Funkcia btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

A pridajte obslužné nástroje prijímania správ:

Socket.on("ponuka", funkcia (údaje) ( console.log("socket.on("ponuka"):", údaje); pc2_receivedOffer(údaje); )); socket.on("odpoveď", funkcia (údaje) (е console.log("socket.on("odpoveď"):", údaje); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", funkcia (údaje) ( console.log("socket.on("ice1"):", údaje); pc2.addIceCandidate(new RTCIceCandidate(údaje)); )); socket.on("ice2", funkcia (údaje) ( console.log("socket.on("ice2"):", údaje); pc1.addIceCandidate(new RTCIceCandidate(údaje)); )); socket.on("zavesenie", funkcia (údaje) ( console.log("socket.on("zavesenie"):", údaje); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Serverová časť

Na strane servera uložíme súbor nodetest2 pod novým názvom rtctest4.js a do funkcie io.sockets.on("connection", function (socket) ( ... ) pridáme prijímanie a odosielanie klientských správ:

Socket.on("ponuka", funkcia (údaje) ( // Keď dostaneme správu "ponuka", // keďže v tomto príklade existuje iba jedno pripojenie klienta, // pošleme správu späť cez ten istý soket .emit("ponuka" , data); // Ak by bolo potrebné preposlať správu cez všetky spojenia, // okrem odosielateľa: // soket.broadcast.emit("ponuka", data); )); socket.on("odpoveď", funkcia (údaje) ( socket.emit("odpoveď", údaje); )); socket.on("ice1", funkcia (data) ( socket.emit("ice1", data); )); socket.on("ice2", funkcia (data) ( socket.emit("ice2", data); )); socket.on("zavesenie", funkcia (údaje) ( socket.emit("zavesenie", údaje); ));

Okrem toho zmeňme názov súboru HTML:

// res.sendfile(__dirname + "/nodetest2.html"); // Odoslať súbor HTML res.sendfile(__dirname + "/rtctest4.html");

Spustenie servera:

$ sudo nodejs nodetest2.js

Napriek tomu, že kód oboch klientov sa vykonáva na tej istej karte prehliadača, všetka interakcia medzi účastníkmi v našom príklade prebieha úplne cez sieť a „oddelenie“ účastníkov nevyžaduje žiadne zvláštne ťažkosti. To, čo sme však urobili, bolo tiež veľmi jednoduché – tieto technológie sú dobré, pretože sa ľahko používajú. Aj keď niekedy klamlivé. Najmä nezabúdajme, že bez serverov STUN/TURN nebude náš príklad fungovať v prítomnosti prekladu adries a firewallov.

Záver

Výsledný príklad je veľmi konvenčný, ale ak trochu zovšeobecníme obsluhu udalostí tak, aby sa medzi volajúcim a volaným nelíšili, namiesto dvoch objektov pc1 a pc2 vytvorte pole RTCPeerConnection a implementujte dynamická tvorba a odstránením prvkov získate úplne použiteľný videorozhovor. S WebRTC nie sú spojené žiadne špeciálne špecifiká a ukážka jednoduchého videorozhovoru pre viacerých účastníkov (ako aj texty všetkých príkladov v článku) je na disku, ktorý je súčasťou magazínu. Na internete toho však už nájdete pomerne veľa. dobré príklady. Pri príprave článku boli použité najmä: simpl.info getUserMedia, simpl.info RTCPeerConnection, referenčná aplikácia WebRTC.

Dá sa predpokladať, že veľmi skoro vďaka WebRTC dôjde k revolúcii nielen v našom chápaní hlasovej a video komunikácie, ale aj v tom, ako vnímame internet ako celok. WebRTC je umiestnený nielen ako technológia pre hovory medzi prehliadačmi, ale aj ako komunikačná technológia v reálnom čase. Videokomunikácia, o ktorej sme diskutovali, je len malá časť možné možnosti jeho použitie. Už existujú príklady screencastingu a spolupráce a dokonca aj sieť na doručovanie obsahu P2P založená na prehliadači pomocou RTCDataChannel.