Chat video peer-to-peer bazat pe WebRTC. Chat video P2P bazat pe instalarea WebRTC Webrtc

Utilizatorii de internet europeni sunt împărțiți în două părți: conform unui sondaj al Institutului de Analiză a Opiniei Publice din Allenbach (Germania), Skype, sistemele de chat și de mesagerie instant au devenit parte integrantă a Viata de zi cu zi pentru 16,5 milioane de adulți și copii, 9 milioane folosesc aceste servicii ocazional, iar 28 de milioane nu le ating.

Acest lucru se poate schimba pe măsură ce Firefox se integrează acum tehnologie de comunicare în timp real (WebRTC), precum și clientul însuși. Pornirea unui chat audio și video nu este acum mai dificilă decât deschiderea unui site web. Servicii precum Facebook și Skype, pe de altă parte, se bazează pe soluții care folosesc un client separat și creează un cont.

WebRTC se distinge nu numai prin ușurința sa de utilizare. Această metodă vă permite chiar să instalați conexiune directă între două browsere. În acest fel, datele audio și video nu trec printr-un server unde ar putea exista o supraîncărcare sau unde administratorul nu este deosebit de sensibil la confidențialitate sau protecția datelor. Datorită conexiunii directe, WebRTC nu necesită nici înregistrare, nici Contîn orice serviciu.

Pentru a începe o conversație, trebuie doar să urmați linkul. Comunicarea rămâne privată, deoarece fluxul de date este criptat. Google a început să se angajeze activ în comunicare în timp real prin browser încă din 2011, când a publicat codul sursă al implementării sale WebRTC.

La scurt timp după aceasta, Chrome și Firefox și-au primit propriile motoare WebRTC. În prezent, versiunile lor mobile sunt echipate atât cu această tehnologie, cât și cu motorul WebView 3.6 instalat cu Android 5.0, care este folosit de aplicații.

Pentru comunicarea în timp real, interfețele JavaScript adecvate trebuie implementate în vizualizatorul web. Folosind GetUserMedia software activează captura din surse audio și video, adică de pe camera web și microfon. RTCPeerConnection este responsabil pentru stabilirea conexiunii, precum și a comunicației în sine.

În paralel cu integrarea în browser, grupul de lucru Consorțiu World wide web(W3C) a accelerat procesul de standardizare WebRTC. Ar trebui finalizat în 2015.

WebRTC se mulțumește cu puțin

Utilizarea serviciului WebRTC nu necesită multe resurse, deoarece serverul conectează doar interlocutorii. Stabilirea unei conexiuni nu este, de asemenea, deosebit de dificilă. În primul rând, browserul semnalează serverului WebRTC că intenționează să inițieze un apel. Primește o legătură HTTPS de la server - comunicarea este criptată. Utilizatorul trimite acest link interlocutorului său. Browserul cere apoi utilizatorului permisiunea de a accesa camera web și microfon.

Pentru a stabili o conexiune directă de streaming cu interlocutorul, browserul primește adresa sa IP și datele de configurare de la serviciul WebRTC. Vizualizatorul web al celeilalte persoane face același lucru.

Pentru ca conexiunea de streaming să funcționeze fără probleme și de bună calitate, trei motoare funcționează în browser. Două dintre ele optimizează și comprimă datele audio și video, al treilea este responsabil de transportul lor. Trimite date prin Protocolul SRTP(Secure Real-time Transport Protocol), care permite streaming criptat în timp real.

Dacă nu poate fi stabilită o conexiune directă, WebRTC caută o altă cale. De exemplu, asta se întâmplă când setari de reteaîmpiedică serverul STUN să raporteze adresa IP. Standardul WebRTC prevede că în acest caz conversația va avea loc, dar cu activarea intermediară a serverului TURN (Traversal Using Relays around NAT). Deci, pe site-ul netscan.co puteți verifica dacă WebRTC este implementat pe computerul dvs. și cu accesul dvs. la Rețea.

Cum se face legătura

Mai întâi trebuie să înregistrați conversația (1). Serviciul WebRTC oferă un link care trebuie trimis către interlocutor. Browserul, folosind serverul STUN, află propria sa adresă IP (2), o trimite către serviciu și primește IP-ul partenerului pentru a stabili o conexiune directă (3). Dacă STUN eșuează, conversația este redirecționată folosind serverul TURN (4).

Comunicarea folosind tehnologia WebRTC în browser este lansată folosind codul JavaScript. După aceea, trei motoare sunt responsabile de comunicare: motoarele de voce și video colectează date multimedia de la camera web și microfon, iar motorul de transport combină informațiile și trimite fluxul în formă criptată folosind SRTP (Secure Real-time Protocol).

Ce browsere funcționează cu WebRTC

Chrome și Firefox au un motor WebRTC care utilizează servicii precum talky.io. Browserul Mozilla poate funcționa direct cu propriul client.

Google și Mozilla continuă să promoveze ideea comunicării în timp real: Chrome poate găzdui conferințe WebRTC cu mai mulți participanți, iar noul client Hello al Firefox a fost dezvoltat în colaborare cu o subsidiară a gigantului telecomunicații Telefonica. Apple rămâne deocamdată pe margine; nu ar trebui să vă așteptați încă la WebRTC în Safari. Cu toate acestea, sunt multe aplicații alternative pentru iOS și pluginuri pentru Safari.

Microsoft urmează un curs ușor diferit. Ca proprietar al unui competitor serviciu Skype această companie nu va capitula atât de ușor față de WebRTC. În schimb, Microsoft dezvoltă o tehnologie numită ORTC (Object Real-Time Communications) pentru Internet Explorer.

Diferențele față de WebRTC, cum ar fi diferite codecuri și protocoale pentru stabilirea contactului cu serverul, sunt minore și, în timp, cel mai probabil se vor dezvolta într-o adăugare la standardul WebRTC care include aceste diferențe. Astfel, doar Apple rămâne în urmă - ca de obicei.

Fotografie: Companii de productie; goodluz/Fotolia.com

Majoritatea materialului pe WebRTC se concentrează pe nivelul aplicației de codificare și nu contribuie la înțelegerea tehnologiei. Să încercăm să mergem mai adânc și să aflăm cum are loc conexiunea, ce sunt descriptorul de sesiune și candidații, pentru ce sunt necesari aceștia STUNȘi ÎNTOARCE Server.

WebRTC

Introducere

WebRTC este o tehnologie orientată spre browser care vă permite să conectați doi clienți pentru transferul de date video. Caracteristici principale: suport intern pentru browser (nu este nevoie de tehnologii implementate de terți, cum ar fi adobe flash ) și capacitatea de a conecta clienți fără a utiliza servere suplimentare - conexiune de la persoană la persoană(Mai departe, p2p).

Stabiliți o conexiune p2p- o sarcină destul de dificilă, deoarece computerele nu au întotdeauna public IP adrese, adică adrese de pe Internet. Datorită cantității mici IPv4 adrese (și din motive de securitate), a fost dezvoltat un mecanism NAT, care vă permite să creați rețele private, de exemplu, pentru uz casnic. Multe routere de acasă acceptă acum NATși datorită acestui fapt, toate dispozitivele de acasă au acces la Internet, deși furnizorii de internet oferă de obicei unul IP abordare. Public IP adresele sunt unice pe Internet, dar cele private nu. Prin urmare conectează-te p2p- dificil.

Pentru a înțelege mai bine acest lucru, luați în considerare trei situații: ambele noduri sunt în aceeași rețea (Imaginea 1), ambele noduri sunt pe rețele diferite (unul este privat, celălalt este public) (Figura 2)și ambele noduri sunt pe rețele private diferite cu același IP adrese (Figura 3).

Figura 1: Ambele noduri din aceeași rețea

Figura 2: Noduri în diferite rețele (unul în privat, unul în public)

Figura 3: Noduri din rețele private diferite, dar cu adrese egale numeric

În figurile de mai sus, prima literă din notația cu două caractere indică tipul de nod (p = egal, r = router). În prima figură, situația este favorabilă: nodurile din rețeaua lor sunt complet identificate de rețea IP adrese și, prin urmare, se pot conecta direct între ele. În a doua figură avem două rețele diferite cu numere de noduri similare. Aici apar routerele (routere), care au două interfata retea– în interiorul rețelei și în afara rețelei. De aceea au două IP adrese. Nodurile obișnuite au o singură interfață prin care pot comunica doar în cadrul rețelei lor. Dacă transmit date către cineva din afara rețelei lor, atunci numai folosind NATîn interiorul routerului (routerului) și, prin urmare, vizibil celorlalți sub IP adresa routerului - aceasta este a lor extern IP abordare. Astfel, la nod p1 Există interior IP = 192.168.0.200 Și extern IP = 10.50.200.5 , iar ultima adresă va fi, de asemenea, externă tuturor celorlalte noduri din rețeaua sa. O situație similară pentru nod p2. Prin urmare, conexiunea lor este imposibilă dacă sunt folosite doar cele interne. IP adrese. Puteți utiliza adrese externe, adică adrese de router, dar deoarece toate nodurile din aceeași rețea privată au aceeași adresă externă, acest lucru este destul de dificil. Această problemă este rezolvată folosind mecanismul NAT

Ce se va întâmpla dacă decidem să conectăm nodurile prin adresele lor interne? Datele nu vor părăsi rețeaua. Pentru a spori efectul, vă puteți imagina situația prezentată în ultima figură - ambele noduri au aceleași adrese interne. Dacă le folosesc pentru a comunica, atunci fiecare nod va comunica cu el însuși.

WebRTC face față cu succes unor astfel de probleme folosind protocolul GHEAŢĂ, care, totuși, necesită utilizarea de servere suplimentare ( STUN, ÎNTOARCE). Mai multe despre toate acestea mai jos.

Două faze ale WebRTC

Pentru a conecta două noduri printr-un protocol WebRTC(sau pur și simplu RTC, dacă doi comunică iPhone„a) trebuie luate niște pași preliminari pentru a stabili o conexiune. Aceasta este prima fază - stabilirea unei conexiuni. A doua fază este transmisia de date video.

Merită spus imediat că, deși tehnologie WebRTC folosește multe în munca sa în diverse moduri comunicatii ( TCPȘi UDP) și are comutare flexibilă între ele, această tehnologie nu are un protocol pentru transmiterea datelor de conexiune. Nu este surprinzător, deoarece conectați două noduri p2p nu asa de usor. Prin urmare, este necesar să aveți câteva adiţional o metodă de transmitere a datelor care nu are nicio legătură cu WebRTC. Ar putea fi un transfer de socket, un protocol HTTP, ar putea fi chiar un protocol SMTP sau Poșta Rusă. Acest mecanism de transmisie iniţială se numesc date semnal. Nu trebuie transmise prea multe informații. Toate datele sunt transmise sub formă de text și sunt împărțite în două tipuri - SDPȘi Candidat de gheață. Primul tip este folosit pentru a stabili o conexiune logică, iar al doilea pentru o conexiune fizică. Mai multe despre toate acestea mai târziu, dar deocamdată este doar important să ne amintim asta WebRTC ne va oferi câteva informații care vor trebui transmise la un alt nod. Imediat ce vom transmite toate informațiile necesare, nodurile se vor putea conecta și ajutorul nostru nu va mai fi nevoie. Deci mecanismul de semnalizare pe care trebuie să-l implementăm este separat, va fi folosit numai atunci când este conectat, dar nu va fi folosit la transmiterea datelor video.

Deci, să luăm în considerare prima fază - faza de stabilire a conexiunii. Este format din mai multe puncte. Să ne uităm la această fază mai întâi pentru nodul care inițiază conexiunea și apoi pentru cel care așteaptă.

• Inițiator (apelant - apelant):
  1. Oferiți să începeți transferul de date video (createOffer)
  2. Primindu-l pe al tău SDP SDP)
  3. Primindu-l pe al tău Candidat de gheață Candidat de gheață)
• Apel în așteptare ( apelat):
  1. Primirea unui flux media local (dvs.) și setarea acestuia pentru transmisie (getUserMediaStream)
  2. Primirea unei oferte pentru a începe transferul de date video și crearea unui răspuns (createAnswer)
  3. Primindu-l pe al tău SDP obiect și transmiterea acestuia printr-un mecanism de semnalizare ( SDP)
  4. Primindu-l pe al tău Candidat de gheață obiecte și transmiterea lor printr-un mecanism de semnalizare ( Candidat de gheață)
  5. Primirea unui flux media de la distanță (străin) și afișarea lui pe ecran (onAddStream)

Singura diferență este în al doilea punct.

În ciuda complexității aparente a pașilor, există de fapt trei dintre ei: trimiterea propriului flux media (articolul 1), setarea parametrilor de conexiune (articolele 2-4), primirea fluxului media altcuiva (articolul 5). Pasul cel mai dificil este cel de-al doilea pas, deoarece constă din două părți: stabilirea fizicȘi logic conexiuni. Primul indică cale, de-a lungul căruia pachetele trebuie să călătorească pentru a ajunge de la un nod de rețea la altul. Al doilea indică parametrii video/audio– ce calitate să folosești, ce codecuri să folosești.

Stadiul mental createOffer sau createRăspuns trebuie conectat la etapele de transmisie SDPȘi Candidat de gheață obiecte.

Entități de bază

Fluxuri media (MediaStream)

Entitatea principală este fluxul media, adică fluxul de date video și audio, imagine și sunet. Există două tipuri de fluxuri media - locale și la distanță. Cel local primește date de la dispozitivele de intrare (cameră, microfon), iar cel la distanță prin rețea. Astfel, fiecare nod are atât un fir local, cât și unul la distanță. ÎN WebRTC există o interfață pentru fire MediaStreamși există și o subinterfață LocalMediaStream special pentru thread-ul local. ÎN JavaScriptîl poți întâlni doar pe primul și dacă îl folosești libjingle, atunci s-ar putea să îl întâlnești pe al doilea.

ÎN WebRTC Există o ierarhie destul de confuză în cadrul firului. Fiecare flux poate consta din mai multe piese media ( MediaTrack), care la rândul său poate consta din mai multe canale media ( MediaChannel). Și pot exista, de asemenea, mai multe fluxuri media în sine.

Să privim totul în ordine. Pentru a face acest lucru, să ținem cont de un exemplu. Să spunem că vrem să transmitem nu doar un videoclip cu noi înșine, ci și un videoclip al mesei noastre, pe care se află o bucată de hârtie pe care urmează să scriem ceva. Vom avea nevoie de două videoclipuri (noi + tabel) și unul audio (noi). Este clar că noi și tabelul ar trebui să fim împărțiți în fire diferite, deoarece aceste date sunt probabil puțin dependente unele de altele. Prin urmare, vom avea două MediaStream‘a – unul pentru noi și unul pentru masă. Primul va conține atât date video, cât și audio, iar al doilea va conține doar video (Figura 4).

Figura 4: Două fluxuri media diferite. Unul pentru noi, unul pentru masa noastră

Este imediat clar că un flux media trebuie să includă cel puțin capacitatea de a conține date tipuri diferite- video și audio. Acest lucru este luat în considerare în tehnologie și, prin urmare, fiecare tip de date este implementat printr-o pistă media MediaTrack. Piesa media are o proprietate specială drăguț, care determină ce avem în fața noastră – video sau audio (Figura 5)

Figura 5: Fluxurile media constau din piese media

Cum se va întâmpla totul în program? Vom crea două fluxuri media. Apoi vom crea două piese video și o pistă audio. Să obținem acces la camere și microfon. Să spunem fiecărei piese ce dispozitiv să folosească. Să adăugăm o pistă video și audio la primul flux media și o pistă video de la o altă cameră la al doilea flux media.

Dar cum distingem fluxurile media la celălalt capăt al conexiunii? Pentru a face acest lucru, fiecare flux media are proprietatea eticheta– eticheta fluxului, numele acestuia (Figura 6). Piesele media au aceeași proprietate. Deși la prima vedere pare că videoclipul poate fi distins de sunet în alte moduri.

Figura 6: Fluxurile și melodiile media sunt identificate prin etichete

Deci, dacă melodiile media pot fi identificate printr-o etichetă, atunci de ce trebuie să folosim două fluxuri media pentru exemplul nostru, în loc de unul? La urma urmei, puteți transmite un flux media, dar utilizați diferite piese în el. Am ajuns la o proprietate importantă a fluxurilor media - ei sincroniza piese media. Diferitele fluxuri media nu sunt sincronizate între ele, dar în cadrul fiecărui flux media toate piesele sunt redate simultan.

Astfel, dacă vrem ca cuvintele noastre, emoțiile noastre faciale și bucata noastră de hârtie să fie redate simultan, atunci merită să folosiți un flux media. Dacă acest lucru nu este atât de important, atunci este mai profitabil să folosiți diferite fluxuri - imaginea va fi mai netedă.

Dacă o pistă trebuie oprită în timpul transmisiei, puteți folosi proprietatea activat piese media.

În cele din urmă, merită să ne gândim la sunetul stereo. După cum știți, sunetul stereo este doi sunete diferite. Și trebuie să fie transferate și separat. Canalele sunt folosite pentru aceasta MediaChannel. O pistă audio media poate avea mai multe canale (de exemplu, 6 dacă aveți nevoie de 5+1 audio). Există și canale în interiorul pieselor media, desigur. sincronizate. Pentru video, de obicei este utilizat un singur canal, dar mai multe pot fi folosite, de exemplu, pentru suprapunerea publicității.

A rezuma: Folosim un flux media pentru a transmite date video și audio. În cadrul fiecărui flux media, datele sunt sincronizate. Putem folosi mai multe fluxuri media dacă nu avem nevoie de sincronizare. În interiorul fiecărui flux media există două tipuri de piese media - pentru video și pentru audio. De obicei, nu există mai mult de două piese, dar pot fi mai multe dacă trebuie să transmiteți mai multe videoclipuri diferite (ale interlocutorului și a mesei sale). Fiecare piesă poate consta din mai multe canale, care este de obicei folosit doar pentru sunet stereo.

În cea mai simplă situație de chat video, vom avea un flux media local, care va consta din două piese - o pistă video și o pistă audio, fiecare dintre acestea fiind compusă dintr-un canal principal. Piesa video este responsabilă pentru cameră, pista audio este pentru microfon, iar fluxul media este containerul pentru ambele.

Descriptor de sesiune (SDP)

Calculatoarele diferite vor avea întotdeauna camere, microfoane, plăci video și alte echipamente diferite. Există multe opțiuni pe care le au. Toate acestea trebuie coordonate pentru transferul media de date între două noduri de rețea. WebRTC o face automat și creează obiect special– descriptor de sesiune SDP. Treceți acest obiect către alt nod și datele media pot fi transferate. Numai că nu există încă nicio legătură cu un alt nod.

Pentru aceasta este folosit orice mecanism de semnalizare. SDP poate fi transmis fie prin prize, fie de persoană (spuneți-l unui alt nod prin telefon), fie prin Russian Post. Este foarte simplu - vă vor oferi un gata făcut SDPși trebuie trimis. Și la primire pe cealaltă parte - transfer la departament WebRTC. Descriptorul de sesiune este stocat ca text și poate fi modificat în aplicațiile dvs., dar acest lucru nu este în general necesar. De exemplu, atunci când conectați desktop ↔ telefon, uneori trebuie să forțați selectarea codecului audio dorit.

De obicei, atunci când stabiliți o conexiune, trebuie să specificați un fel de adresă, de exemplu URL. Acest lucru nu este necesar aici, deoarece prin mecanismul de semnalizare tu însuți vei trimite datele la destinație. A indica WebRTC ce vrem să instalăm p2p conexiune trebuie să apelați funcția createOffer. După ce a apelat această funcție și i-ai dat un special sună din nou‘a va fi creat SDP obiect şi transferat la acelaşi sună din nou. Tot ceea ce vă este necesar este să transferați acest obiect prin rețea către un alt nod (interlocutor). După aceasta, datele vor ajunge la celălalt capăt prin mecanismul de semnalizare și anume acesta SDP un obiect. Acest descriptor de sesiune este străin acestui nod și, prin urmare, conține informații utile. Primirea acestui obiect este un semnal de pornire a conexiunii. Prin urmare, trebuie să fiți de acord cu acest lucru și să apelați funcția createAnswer. Este un analog complet pentru createOffer. Înapoi la a ta sună din nou va transmite descriptorul de sesiune local și va trebui să fie transmis înapoi prin mecanismul de semnalizare.

Este de remarcat faptul că puteți apela funcția createAnswer numai după ce ați primit-o pe a altcuiva SDP obiect. De ce? Pentru că local SDP obiectul care va fi generat atunci când createAnswer este apelat trebuie să se bazeze pe telecomandă SDP un obiect. Numai în acest caz este posibil să vă coordonați setările video cu setările interlocutorului dvs. De asemenea, nu ar trebui să apelați createAnswer și createOffer înainte de a primi fluxul media local - nu vor avea nimic la care să scrie SDP un obiect .

Din moment ce în WebRTC se poate edita SDP obiect, apoi după primirea mânerului local acesta trebuie instalat. Acest lucru poate părea puțin ciudat de transmis WebRTC ceea ce ea însăși ne-a dat, dar acesta este protocolul. Când se primește un mâner de la distanță, acesta trebuie de asemenea instalat. Prin urmare, trebuie să instalați doi descriptori pe un nod - al dvs. și al altcuiva (adică, local și la distanță).

Dupa asta strângeri de mână nodurile știu unul despre dorințele celuilalt. De exemplu, dacă nodul 1 acceptă codecuri AȘi B, și nodul 2 acceptă codecuri BȘi C, atunci, deoarece fiecare nod își cunoaște descriptorii proprii și ai altora, ambele noduri vor alege codecul B(Figura 7). Logica de conectare este acum stabilită și fluxurile media pot fi transmise, dar există o altă problemă - nodurile sunt încă conectate doar printr-un mecanism de semnalizare.

Figura 7: Negocierea codecului

Candidat de gheață

Tehnologie WebRTCîncercând să ne confunde cu noua lui metodologie. La stabilirea unei conexiuni, adresa nodului la care doriți să vă conectați nu este specificată. Instalat mai întâi logic conexiune, nu fizic, deși întotdeauna s-a făcut invers. Dar acest lucru nu va părea ciudat dacă ne amintim că folosim un mecanism de semnalizare terță parte.

Deci, conexiunea a fost deja stabilită (conexiune logică), dar încă nu există o cale pe care nodurile rețelei să poată transmite date. Nu este chiar atât de simplu, dar să începem simplu. Lăsați nodurile să fie în aceeași rețea privată. După cum știm deja, ei se pot conecta cu ușurință unul cu celălalt în funcție de interiorul lor IP adrese (sau poate către alte persoane, dacă nu sunt utilizate TCP/IP).

După unii sună din nou'Și WebRTC spune-ne Candidat de gheață obiecte. Ele vin, de asemenea, sub formă de text și, ca și descriptorii de sesiune, pur și simplu trebuie să fie trimise printr-un mecanism de semnalizare. Dacă descriptorul de sesiune conținea informații despre setările noastre la nivel de cameră și microfon, atunci candidații conțin informații despre locația noastră în rețea. Transmite-le la un alt nod și se va putea conecta fizic la noi și, deoarece are deja un descriptor de sesiune, se va putea conecta în mod logic și datele vor „fluge”. Dacă își amintește să ne trimită obiectul său candidat, adică informații despre locul în care se află el însuși în rețea, atunci vom putea să ne conectăm cu el. Să remarcăm aici încă o diferență față de interacțiunea clasică client-server. Comunicarea cu serverul HTTP are loc conform schemei cerere-răspuns, clientul trimite date către server, care le prelucrează și le trimite prin adresa specificată în pachetul de solicitare. ÎN WebRTC Trebuie să știu două adreseși conectați-le pe ambele părți.

Diferența față de descriptorii de sesiune este că doar candidații la distanță trebuie să fie instalați. Editarea aici este interzisă și nu poate aduce niciun beneficiu. În unele implementări WebRTC candidații trebuie să fie instalați numai după ce au fost setați descriptori de sesiune.

De ce a existat un singur descriptor de sesiune, dar ar putea fi mulți candidați? Deoarece locația în rețea poate fi determinată nu numai de interiorul acesteia IP adresa, dar și adresa externă a routerului, și nu neapărat doar una, precum și adresele ÎNTOARCE servere. Restul paragrafului va fi dedicat unei discuții detaliate despre candidați și despre modul de conectare a nodurilor din diferite rețele private.

Deci, două noduri sunt în aceeași rețea (Figura 8). Cum să le identificăm? Prin utilizarea IP adrese. Nici o alta cale. Adevărat, puteți folosi în continuare mijloace de transport diferite ( TCPȘi UDP) și diferite porturi. Acestea sunt informațiile conținute în obiectul candidat - IP, PORT, TRANSPORT si inca una. Să folosim, de exemplu UDP transport si 531 port.

Figura 8: Două noduri sunt în aceeași rețea

Atunci dacă suntem la nod p1, Acea WebRTC ne va transmite un astfel de obiect candidat - . Acesta nu este un format exact, doar o diagramă. Dacă suntem într-un nod p2, atunci candidatul este - . Printr-un mecanism de semnalizare p1 va primi un candidat p2(adică locația nodului p2, anume a lui IPȘi PORT). Apoi p1 se poate conecta cu p2 direct. Mai corect, p1 va trimite datele la adresa 10.50.150.3:531 în speranţa că vor ajunge p2. Nu contează dacă adresa aparține nodului p2 sau vreun intermediar. Singurul lucru important este că datele vor fi trimise prin această adresă și pot ajunge p2.

Atâta timp cât nodurile sunt în aceeași rețea, totul este simplu și ușor - fiecare nod are un singur obiect candidat (însemnând întotdeauna propriul său, adică locația sa în rețea). Dar vor fi mult mai mulți candidați atunci când nodurile vor fi introduse diferit retelelor.

Să trecem la un caz mai complex. Un nod va fi situat în spatele routerului (mai precis, în spatele NAT), iar al doilea nod va fi situat în aceeași rețea cu acest router (de exemplu, pe Internet) (Figura 9).

Figura 9: Un nod este în spatele NAT, celălalt nu

Acest caz are o soluție specială la problemă, pe care acum o vom lua în considerare. Router de acasă de obicei conține un tabel NAT. Acesta este un mecanism special conceput pentru a permite nodurilor din rețeaua privată a routerului să acceseze, de exemplu, site-uri web.

Să presupunem că serverul web este conectat direct la Internet, adică are un public IP* abordare. Să fie acesta un nod p2. Nod p1(client web) trimite o solicitare la adresa 10.50.200.10 . Mai întâi datele merg la router r1, sau mai bine zis pe a lui interior interfata 192.168.0.1 . După care, routerul își amintește adresa sursă (adresa p1) și îl introduce într-un tabel special NAT, apoi schimbă adresa sursă cu a ta( p1 → r1). Mai departe, în felul meu extern interfață, routerul trimite date direct către serverul web p2. Serverul web prelucrează datele, generează un răspuns și îl trimite înapoi. Se trimite la router r1, deoarece el este cel care se află în adresa de retur (routerul a înlocuit adresa cu propria sa). Routerul primește date și se uită la tabel NATși transmite datele către nod p1. Routerul acţionează ca un intermediar aici.

Ce se întâmplă dacă mai multe noduri din rețeaua internă accesează simultan rețeaua externă? Cum va înțelege routerul cui să trimită răspunsul înapoi? Această problemă este rezolvată folosind porturi. Când un router înlocuiește adresa gazdă cu propria sa, acesta înlocuiește și portul. Dacă două noduri accesează Internetul, atunci routerul își înlocuiește porturile sursă cu diferit. Apoi, când pachetul de la serverul web revine la router, routerul va înțelege după port cui este alocat pachetul. Exemplu de mai jos.

Să revenim la tehnologie WebRTC, sau mai degrabă, la partea din acesta care folosește GHEAŢĂ protocol (deci Gheaţă candidați). Nod p2 are un singur candidat (locația sa în rețea – 10.50.200.10 ), și nodul p1, care se află în spatele unui router cu NAT, va avea doi candidați - local ( 192.168.0.200 ) și router candidat ( 10.50.200.5 ). Primul nu este util, dar este totuși generat, din moment ce WebRTC nu știe încă nimic despre nodul la distanță - poate fi sau nu în aceeași rețea. Al doilea candidat va veni la îndemână și, după cum știm deja, portul va juca un rol important (de a trece prin NAT).

Intrare la tabel NAT generate numai atunci când datele părăsesc rețeaua internă. Prin urmare nodul p1 trebuie să transmită mai întâi datele și numai după aceea datele nodului p2 va putea ajunge la nod p1.

La practică ambele noduri va fi în urmă NAT. Pentru a crea o înregistrare într-un tabel NAT ale fiecărui router, nodurile trebuie să trimită ceva către nodul de la distanță, dar de data aceasta nici primul nu poate ajunge la cel de-al doilea și nici invers. Acest lucru se datorează faptului că nodurile nu își cunosc exteriorul IP adrese, iar trimiterea datelor către adrese interne este inutilă.

Cu toate acestea, dacă adresele externe sunt cunoscute, conexiunea se va stabili cu ușurință. Dacă primul nod trimite date către routerul celui de-al doilea nod, routerul le va ignora, deoarece tabelul său NAT gol deocamdată. Cu toate acestea, în routerul primului nod din tabel NAT Am nevoie de o înregistrare. Dacă acum al doilea nod trimite date către routerul primului nod, atunci routerul le va transfera cu succes la primul nod. Acum masa NAT al doilea router are nevoie de date.

Problema este că pentru a-ți recunoaște exteriorul IP adresa, aveți nevoie de un nod situat în rețea partajată. Pentru a rezolva această problemă, sunt folosite servere suplimentare care sunt conectate direct la Internet. Cu ajutorul lor, sunt create și înregistrări apreciate în tabel NAT.

Servere STUN și TURN

La inițializare WebRTC trebuie să indicați cele disponibile STUNȘi ÎNTOARCE servere, pe care le vom numi în continuare GHEAŢĂ servere. Dacă serverele nu sunt specificate, atunci numai nodurile din aceeași rețea (conectate la aceasta fără NAT). Este imediat de remarcat faptul că pt 3g-trebuie folosite rețele ÎNTOARCE servere.

STUN Server este pur și simplu un server de pe Internet care returnează o adresă de retur, adică adresa nodului expeditorului. Nodul situat în spatele routerului accesează STUN serverul pe care să îl parcurgeți NAT. Pachetul la care a ajuns STUN server, conține adresa sursă - adresa routerului, adică adresa externă a nodului nostru. Această adresă STUN server și îl trimite înapoi. Astfel, nodul își primește exteriorul IP adresa și portul prin care este accesibil din rețea. Mai departe, WebRTC folosind această adresă se creează un candidat suplimentar (adresa ruterului extern și port). Acum în tabel NAT Routerul are o intrare care permite pachetelor trimise către router pe portul necesar să treacă la nodul nostru.

Să ne uităm la acest proces cu un exemplu.

Exemplu (operare server STUN)

STUN vom nota serverul prin s1. Routerul, ca înainte, prin r1, iar nodul – prin p1. De asemenea, va trebui să urmați tabelul NAT– să o notăm ca r1_nat. Mai mult, acest tabel conține de obicei multe înregistrări de la diferite noduri ale subrețelei - acestea nu vor fi date.

Deci, la început avem o masă goală r1_nat.

Tabelul 2: Antet pachet

Nod p1 trimite acest pachet către router r1(indiferent cum, acestea pot fi utilizate în diferite subrețele tehnologii diferite). Routerul trebuie să schimbe adresa sursei Src IP, deoarece adresa specificată în pachet nu este în mod evident potrivită pentru o subrețea externă, mai mult, adresele dintr-un astfel de interval sunt rezervate și nici o singură adresă de pe Internet nu are o astfel de adresă; Routerul face o înlocuire în pachet și creează intrare nouăîn masa ta r1_nat. Pentru a face acest lucru, el trebuie să vină cu un număr de port. Să ne amintim că, deoarece mai multe noduri dintr-o subrețea pot accesa rețeaua externă, atunci în tabel NAT trebuie păstrat Informații suplimentare, astfel încât routerul să poată determina care dintre aceste câteva noduri este destinat pachetului de returnare de la server. Lasă routerul să vină cu un port 888 .

Antetul pachetului modificat:

Tabelul 4: Tabelul NAT a fost actualizat cu o nouă intrare

Aici IP adresa și portul pentru subrețea sunt exact aceleași cu pachetul original. De fapt, la postback, trebuie să avem o modalitate de a le restaura complet. IP adresa pentru reteaua externa este adresa routerului, iar portul s-a schimbat in cel inventat de router.

Portul real către care nodul p1 acceptă conexiunea - aceasta, desigur, 35777 , dar serverul trimite date către fictiv port 888 , care va fi schimbat de router cu cel real 35777 .

Deci, routerul a înlocuit adresa sursă și portul în antetul pachetului și a adăugat o intrare în tabel NAT. Acum pachetul este trimis prin rețea către server, adică către nod s1. La intrare, s1 are acest pachet:

Src IP	Src PORT	Dest IP	Dest PORT
10.50.200.5	888	12.62.100.200	6000

Tabelul 5: Pachetul primit de serverul STUN

Total STUN serverul stie ca a primit un pachet de la adresa 10.50.200.5:888 . Acum serverul trimite această adresă înapoi. Merită să ne oprim aici și să aruncăm o altă privire la ceea ce tocmai ne-am uitat. Tabelele de mai sus sunt un fragment din antet pachet, deloc din el conţinut. Nu am vorbit despre conținut, deoarece nu este atât de important - este cumva descris în protocol STUN. Acum vom lua în considerare, pe lângă titlu, și conținutul. Va fi simplu și va conține adresa routerului - 10.50.200.5:888 , desi am luat-o din antet pachet. Acest lucru nu se face des, de obicei, nu le pasă de informații despre adresele nodurilor; Aici ne uităm la un protocol care stabilește o cale între două noduri.

Deci acum avem un al doilea pachet care merge în direcția opusă:

Tabelul 7: Serverul STUN trimite un pachet cu acest conținut

Apoi, pachetul călătorește prin rețea până ajunge la interfața externă a routerului r1. Routerul înțelege că pachetul nu este destinat acestuia. Cum înțelege el asta? Acest lucru poate fi determinat doar de port. Port 888 nu o folosește în scopuri personale, ci o folosește pentru mecanism NAT. Prin urmare, routerul se uită la acest tabel. Uită-te la coloană PORT externși caută un șir care se potrivește Dest PORT din pachetul primit, adică 888 .

IP intern	PORT intern	IP extern	PORT extern
192.168.0.200	35777	10.50.200.5	888

Tabelul 8: Tabelul NAT

Suntem norocoși, o astfel de linie există. Dacă am avea ghinion, pachetul ar fi pur și simplu aruncat. Acum trebuie să înțelegeți ce nod din subrețea ar trebui să trimită acest pachet. Nu trebuie să ne grăbim, să ne amintim din nou importanța porturilor în acest mecanism. În același timp, două noduri de pe subrețea ar putea trimite cereri către rețeaua externă. Apoi, dacă pentru primul nod routerul a venit cu un port 888 , apoi pentru al doilea ar veni cu un port 889 . Să presupunem că s-a întâmplat asta, adică tabelul r1_nat arata asa:

Tabelul 10: Routerul înlocuiește adresa receptorului

Src IP	Src PORT	Dest IP	Dest PORT
12.62.100.200	6000	192.168.0.200	35777

Tabelul 11: Routerul a schimbat adresa receptorului

Pachetul ajunge cu succes la nod p1și uitându-se la conținutul pachetului, nodul învață despre exteriorul acestuia IP adresa, adică adresa routerului din rețeaua externă. Știe și portul prin care trece routerul NAT.

Ce urmeaza? La ce folosesc toate astea? Beneficiul este o intrare în tabel r1_nat. Dacă acum cineva trimite la router r1 pachet cu port 888 , atunci routerul va redirecționa acest pachet către nod p1. Astfel, a fost creat un mic pasaj îngust către nodul ascuns p1.

Din exemplul de mai sus vă puteți face o idee despre cum funcționează NATși esență STUN Server. În general, mecanismul GHEAŢĂȘi STUN/TURN serverele au ca scop tocmai depășirea limitărilor NAT.

Între nod și server nu pot exista un singur router, ci mai multe. În acest caz, nodul va primi adresa routerului care este primul care accesează aceeași rețea ca și serverul. Cu alte cuvinte, obținem adresa routerului la care este conectat STUN Server. Pentru p2p comunicarea este exact ceea ce avem nevoie, dacă nu uităm faptul că fiecare router va adăuga rândul de care avem nevoie la tabel NAT. Prin urmare, drumul înapoi va fi din nou la fel de lin.

ÎNTOARCE serverul este îmbunătățit STUN Server. De aici ar trebui să se învețe imediat că orice ÎNTOARCE serverul poate funcționa și cum STUN Server. Cu toate acestea, există și avantaje. Dacă p2p comunicarea este imposibilă (cum ar fi în 3g rețele), apoi serverul trece în modul repetitor ( releu), adică funcționează ca intermediar. Desigur, despre nimic p2p atunci nu se pune problema, ci în afara cadrului mecanismului GHEAŢĂ nodurile cred că comunică direct.

În ce cazuri este necesar ÎNTOARCE Server? De ce nu este suficient STUN servere? Faptul este că există mai multe soiuri NAT. Se înlocuiesc în mod egal IP adresa și portul, dar unele dintre ele au protecție suplimentară împotriva „falsificării” încorporate în ele. De exemplu, în simetric masa NATÎncă 2 parametri sunt salvați - IPși portul nodului la distanță. Un pachet din rețeaua externă trece prin NAT către rețeaua internă numai dacă adresa sursă și portul se potrivesc cu cele înregistrate în tabel. Prin urmare, focalizarea STUN serverul eșuează - tabel NAT stochează adresa și portul STUN server și când routerul primește un pachet de la WebRTC interlocutor, îl renunță pentru că este „falsificat”. El nu a venit din STUN Server.

Prin urmare ÎNTOARCE este nevoie de un server când sunt localizați ambii interlocutori simetric NAT(fiecare la el).

Rezumat scurt

Iată câteva afirmații despre entități WebRTC care trebuie ținut mereu în minte. Ele sunt descrise în detaliu mai sus. Dacă vreuna dintre afirmații nu vi se pare complet clară, recitiți paragrafele relevante.

• Flux media
  • Datele video și audio sunt împachetate în fluxuri media
  • Fluxurile media sincronizează melodiile media care alcătuiesc
  • Fluxurile media diferite nu sunt sincronizate între ele
  • Fluxurile media pot fi locale și la distanță, cel local este de obicei conectat la o cameră și un microfon, cei la distanță primesc date din rețea în formă criptată
  • Există două tipuri de piese media - pentru video și pentru audio.
  • Piesele media au capacitatea de a activa/dezactiva
  • Piesele media constau din canale media
  • Piesele media sincronizează canalele media care alcătuiesc
  • Fluxurile media și melodiile media au etichete prin care pot fi distinse
• Mânerul de sesiune
  • Descriptorul de sesiune este folosit pentru a conecta logic două noduri de rețea
  • Descriptorul de sesiune stochează informații despre modalități disponibile codificarea datelor video și audio
  • WebRTC folosește un mecanism de semnalizare extern - sarcina de a transmite descriptori de sesiune ( sdp) cade pe cerere
  • Mecanismul de conectare logică constă din două etape - propoziții ( oferi) si raspunsul ( Răspuns)
  • Generarea unui descriptor de sesiune nu este posibilă fără utilizarea unui flux media local în cazul unei propuneri ( oferi) și nu este posibil fără utilizarea unui handle de sesiune la distanță în cazul unui răspuns ( Răspuns)
  • Descriptorul rezultat trebuie dat implementării WebRTC, și nu contează dacă acest descriptor este obținut de la distanță sau local din aceeași implementare WebRTC
  • Este posibil să editați ușor descriptorul de sesiune
• Candidați
  • Candidatul ( Candidat de gheață) este adresa nodului din rețea
  • Adresa nodului poate fi propria dvs. sau poate fi adresa unui router sau ÎNTOARCE servere
  • Întotdeauna sunt mulți candidați
  • Candidatul este format din IP adresa, portul si tipul de transport ( TCP sau UDP)
  • Candidații sunt folosiți pentru a stabili o conexiune fizică între două noduri dintr-o rețea
  • De asemenea, candidații trebuie să fie trimiși printr-un mecanism de semnalizare
  • Candidații trebuie, de asemenea, să fie transferați la implementări WebRTC, însă doar la distanță
  • În unele implementări WebRTC candidații pot fi transmise numai după ce a fost setat descriptorul de sesiune
• STUN/TURN/ICE/NAT
  • NAT– mecanism de asigurare a accesului la rețeaua externă
  • Routerele de acasă suportă o masă specială NAT
  • Routerul înlocuiește adresele din pachete - adresa sursă cu propria sa, dacă pachetul merge la o rețea externă, iar adresa receptorului cu adresa gazdă în rețeaua internă, dacă pachetul a venit dintr-o rețea externă
  • Pentru a oferi acces multicanal la rețeaua externă NAT folosește porturi
  • GHEAŢĂ– mecanism de bypass NAT
  • STUNȘi ÎNTOARCE servere – servere de ajutor pentru ocolire NAT
  • STUN serverul vă permite să creați înregistrările necesare în tabel NATși returnează, de asemenea, adresa externă a nodului
  • ÎNTOARCE serverul generalizează STUN mecanism și îl face să funcționeze mereu
  • În cele mai rele cazuri ÎNTOARCE serverul este folosit ca intermediar ( releu), acesta este p2p se transformă într-o comunicare client-server-client.

WebRTC (Web Real Time Communications) este un standard care descrie transmiterea în flux de date audio, date video și conținut din și către browser în timp real, fără a instala plugin-uri sau alte extensii. Standardul vă permite să vă transformați browserul într-un terminal de videoconferință, trebuie doar să deschideți o pagină web pentru a începe să comunicați.

Ce este WebRTC?

În acest articol vom analiza tot ce trebuie să știți despre tehnologia WebRTC utilizator obișnuit. Să ne uităm la avantajele și dezavantajele proiectului, să dezvăluim câteva secrete, să vă spunem cum funcționează, unde și pentru ce este folosit WebRTC.

Ce trebuie să știți despre WebRTC?

Evoluția standardelor și tehnologiilor de comunicare video

Sergey Yutsaitis, Cisco, Video+Conference 2016

Cum funcționează WebRTC

Partea clientului

• Utilizatorul deschide o pagină care conține o etichetă HTML5
• Browserul solicită acces la camera web și la microfonul utilizatorului.
• Codul JavaScript de pe pagina de utilizator controlează parametrii de conectare (adresele IP și porturile serverului WebRTC sau alți clienți WebRTC) pentru a ocoli NAT și Firewall.
• La primirea de informații despre interlocutor sau despre fluxul de la conferință mixat pe server, browserul începe să negocieze codecurile audio și video folosite.
• Începe procesul de codificare și transferul datelor de streaming între clienții WebRTC (în cazul nostru, între browser și server).

Pe partea de server WebRTC

Nu este necesar un server video pentru a face schimb de date între doi participanți, dar dacă trebuie să combinați mai mulți participanți într-o conferință, este necesar un server.

Serverul video va primi trafic media din diverse surse, îl va converti și îl va trimite utilizatorilor care folosesc WebRTC ca terminal.

De asemenea, serverul WebRTC va primi trafic media de la colegii WebRTC și îl va transmite participanților la conferință care folosesc aplicații pentru computere desktop sau dispozitive mobile, dacă este cazul.

Avantajele standardului

• Nu este necesară instalarea de software.
• Calitate foarte înaltă a comunicării, datorită:
  • Utilizarea de codecuri video moderne (VP8, H.264) și audio (Opus).
  • Reglarea automată a calității fluxului la condițiile de conectare.
  • Sistem de reducere a ecouului și a zgomotului încorporat.
  • Reglarea automată a nivelului de sensibilitate al microfoanelor participante (AGC).
• Nivel ridicat de securitate: toate conexiunile sunt protejate și criptate folosind protocoale TLS și SRTP.
• Există un mecanism încorporat pentru captarea conținutului, de exemplu, desktopul.
• Posibilitatea implementării oricărei interfețe de management bazate pe HTML5 și JavaScript.
• Abilitatea de a integra interfața cu orice sistem back-end folosind WebSockets.
• Proiect cu deschis cod sursa— poate fi implementat în produsul sau serviciul dumneavoastră.
• Adevărat multiplatformă: aceeași aplicație WebRTC va funcționa la fel de bine pe oricare sistem de operare, desktop sau mobil, cu condiția ca browserul să accepte WebRTC. Acest lucru economisește semnificativ resursele pentru dezvoltarea de software.

Dezavantajele standardului

• Pentru a organiza conferințe audio și video de grup, este necesar un server de videoconferință care să amestece video și sunet de la participanți, deoarece Browserul nu știe cum să sincronizeze mai multe fluxuri de intrare între ele.
• Toate soluțiile WebRTC sunt incompatibile între ele, deoarece... standardul descrie numai metode de transmitere video și audio, lăsând implementarea metodelor de adresare a abonaților, urmărirea disponibilității acestora, schimbul de mesaje și fișiere, programare și alte lucruri către furnizor.
• Cu alte cuvinte, nu veți putea apela de la o aplicație WebRTC a unui dezvoltator la o aplicație WebRTC a altui dezvoltator.
• Mixarea conferințelor de grup necesită resurse de calcul mari, așa că acest tip de comunicare video necesită achiziționarea unui abonament plătit sau investiția în infrastructura dvs., unde fiecare conferință necesită 1 nucleu fizic al unui procesor modern.

Secretele WebRTC: Cum beneficiază furnizorii de tehnologia web inovatoare

Tzachi Levent-Levi, Bloggeek.me, Video+Conference 2015

WebRTC pentru piața videoconferințelor

Creșterea numărului de terminale de videoconferință

Tehnologia WebRTC a avut o influență puternică asupra dezvoltării pieței videoconferințelor. După lansarea primelor browsere cu suport WebRTC în 2013, numărul potențial de terminale de videoconferință din întreaga lume a crescut imediat cu 1 miliard de dispozitive. De fapt, fiecare browser a devenit un terminal de videoconferință, nu inferior omologilor săi hardware în ceea ce privește calitatea comunicației.

Utilizare în soluții specializate

Utilizarea diferitelor biblioteci JavaScript și API-uri pentru servicii cloud cu suport WebRTC facilitează adăugarea de suport pentru comunicații video la orice proiecte web. Anterior, pentru a transmite date în timp real, dezvoltatorii trebuiau să studieze principiile de funcționare a protocolului și să folosească evoluțiile altor companii, care de cele mai multe ori necesitau licențiere suplimentară, ceea ce crește costurile. WebRTC este deja utilizat în mod activ în servicii precum „Apel de pe site”, „Asistență prin chat online”, etc.

Foști utilizatori Skype pentru Linux

În 2014, Microsoft a anunțat încetarea suportului pentru proiectul Skype pentru Linux, ceea ce a provocat o mare iritare în rândul specialiștilor IT. Tehnologia WebRTC nu este legată de sistemul de operare, ci este implementată la nivel de browser, de exemplu. utilizatorii Linux va putea vedea produse și servicii bazate pe WebRTC ca un înlocuitor cu drepturi depline pentru Skype.

Concurență cu Flash

WebRTC și HTML5 au fost o lovitură de moarte pentru tehnologia Flash, care trecea deja prin cei mai grei ani. Din 2017, browserele de top au încetat oficial să mai accepte Flash, iar tehnologia a dispărut complet de pe piață. Dar trebuie să dăm Flash-ului cuvenitul, pentru că el a fost cel care a creat piața de conferințe web și a oferit capabilități tehnice pentru comunicare live în browsere.

Prezentări video WebRTC

Dmitri Odintsov, TrueConf, Video+Conference octombrie 2017

Codecuri în WebRTC

Codecuri audio

WebRTC folosește codecuri Opus și G.711 pentru a comprima traficul audio.

G.711- cel mai vechi codec de voce cu un bitrate mare (64 kbps), care este cel mai des folosit în sistemele tradiționale de telefonie. Principalul avantaj este sarcina de calcul minimă datorită utilizării algoritmilor de compresie ușoare. Codecul are un nivel scăzut de compresie a semnalelor vocale și nu introduce întârziere audio suplimentară în timpul comunicării între utilizatori.

G.711 este acceptat de un număr mare de dispozitive. Sistemele care folosesc acest codec sunt mai ușor de utilizat decât cele bazate pe alte codecuri audio (G.723, G.726, G.728 etc.). În ceea ce privește calitatea, G.711 a primit un scor de 4,2 la testarea MOS (un scor între 4-5 este cel mai mare și înseamnă calitate bună, similar cu calitatea transmisiei traficului vocal în ISDN și chiar mai mare).

Opus este un codec cu latență scăzută de codare (de la 2,5 ms la 60 ms), suport pentru rate de biți variabile și niveluri ridicate de compresie, care este ideal pentru transmiterea semnalelor audio în flux în rețele cu variabile. debitului. Opus este o soluție hibridă care combină cele mai bune caracteristici ale codec-urilor SILK (comprimarea vocii, eliminarea distorsiunii vorbirii umane) și CELT (codarea datelor audio). Codecul este disponibil gratuit, dezvoltatorii care îl folosesc nu trebuie să plătească drepturi de autor deținătorilor de drepturi de autor. În comparație cu alte codecuri audio, Opus câștigă fără îndoială în multe privințe. A eclipsat codecuri destul de populare cu rate de biți scăzute, cum ar fi MP3, Vorbis, AAC LC. Opus restabilește „imaginea” sunetului mai aproape de original decât AMR-WB și Speex. Acest codec este viitorul, motiv pentru care creatorii tehnologiei WebRTC l-au inclus în gama obligatorie de standarde audio acceptate.

Codecuri video

Problemele de alegere a unui codec video pentru WebRTC au luat dezvoltatorilor câțiva ani, iar în cele din urmă au decis să folosească H.264 și VP8. Aproape toate browserele moderne acceptă ambele codecuri. Serverele de videoconferință trebuie să accepte doar unul pentru a funcționa cu WebRTC.

VP8 este un codec video gratuit cu licență deschisă, caracterizat prin viteză mare de decodare a fluxului video și rezistență crescută la pierderea cadrelor. Codecul este universal și ușor de implementat în platformele hardware, motiv pentru care dezvoltatorii de sisteme de videoconferință îl folosesc foarte des în produsele lor.

Codec video plătit H.264 a devenit celebru mult mai devreme decât fratele său. Acesta este un codec cu un grad ridicat de compresie a fluxului video la salvare Calitate superioară video. Prevalența ridicată a acestui codec printre sistemele hardware de videoconferință sugerează utilizarea sa în standardul WebRTC.

Google și Mozilla promovează în mod activ codecul VP8, iar Microsoft, Apple și Cisco promovează activ H.264 (pentru a asigura compatibilitatea cu sistemele tradiționale de videoconferință). Și aici apare o problemă foarte mare pentru dezvoltatorii de soluții cloud WebRTC, deoarece dacă toți participanții la o conferință folosesc același browser, atunci este suficient să amestecați conferința o dată cu un singur codec, iar dacă browserele sunt diferite și Safari / Edge sunt printre ele, atunci conferința va trebui să fie codificată de două ori codecuri diferite, care vor dubla Cerințe de sistem către serverul media și, ca urmare, costul abonamentelor la serviciile WebRTC.

API-ul WebRTC

Tehnologia WebRTC se bazează pe trei API-uri principale:

• (responsabil ca browserul web să primească semnale audio și video de la camere sau desktopul utilizatorului).
• RTCPeerConnection(responsabil pentru conexiunea dintre browsere pentru „schimbul” de date media primite de la cameră, microfon și desktop. De asemenea, „responsabilitățile” acestui API includ procesarea semnalului (curățarea acestuia de zgomote străine, reglarea volumului microfonului) și controlul asupra codecuri audio și video utilizate) .
• Canalul RTCData(oferă transfer bidirecțional de date printr-o conexiune stabilită).

Înainte de a accesa microfonul și camera utilizatorului, browserul solicită permisiunea pentru a face acest lucru. ÎN Google Chrome Puteți configura accesul în prealabil în secțiunea „Setări” din Opera și Firefox, dispozitivele sunt selectate direct în momentul obținerii accesului, dintr-o listă derulantă; Solicitarea de permisiune va apărea întotdeauna când se utilizează protocolul HTTP și o singură dată dacă se utilizează HTTPS:

RTCPeerConnection. Fiecare browser care participă la o conferință WebRTC trebuie să aibă acces la acest obiect. Datorită utilizării RTCPeerConnection, datele media de la un browser la altul pot chiar să treacă prin NAT și firewall-uri. Pentru a transmite cu succes fluxuri media, participanții trebuie să facă schimb de următoarele date folosind un transport, cum ar fi socket-urile web:

• participantul inițiator trimite celui de-al doilea participant o Oferta-SDP (structură de date cu caracteristicile fluxului media pe care îl va transmite);
• al doilea participant generează un „răspuns” - Answer-SDP și îl trimite inițiatorului;
• atunci se organizează un schimb de candidați ICE între participanți, dacă sunt detectați (dacă participanții sunt în spatele NAT sau firewall-uri).

După finalizarea cu succes a acestui schimb, transferul direct al fluxurilor media (audio și video) este organizat între participanți.

Canalul RTCData. Suportul pentru protocolul Data Channel a apărut în browsere relativ recent, astfel încât acest API poate fi luat în considerare exclusiv în cazurile de utilizare a WebRTC în browsere Mozilla Firefox 22+ și Google Chrome 26+. Cu ajutorul acestuia, participanții pot face schimb mesaje textîn browser.

Conexiune prin WebRTC

Browsere desktop acceptate

• Google Chrome (17+) și toate browserele bazate pe motorul Chromium;
• Mozilla FireFox (18+);
• Opera (12+);
• Safari (11+);

Browsere mobile acceptate pentru Android

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Safari (11+).

WebRTC, Microsoft și Internet Explorer

Pentru o perioadă foarte lungă de timp, Microsoft a rămas tăcut cu privire la suportul WebRTC în Internet Explorer și noul său browser Edge. Băieților de la Redmond nu prea le place să pună tehnologii pe care nu le controlează în mâinile utilizatorilor, asta e politica lor. Dar treptat problema s-a mutat dintr-un punct mort, pentru că... Nu a mai fost posibil să se ignore WebRTC, iar proiectul ORTC, un derivat al standardului WebRTC, a fost anunțat.

Potrivit dezvoltatorilor, ORTC este o extensie a standardului WebRTC cu un set îmbunătățit de API-uri bazate pe JavaScript și HTML5, ceea ce, tradus în limbaj obișnuit, înseamnă că totul va fi la fel, doar Microsoft, nu Google, va controla standardul. si dezvoltarea acesteia. Setul de codecuri a fost extins cu suport pentru H.264 și unele codecuri audio din seria G.7ХХ, utilizate în sistemele de telefonie și videoconferință hardware. Poate exista suport încorporat pentru RDP (pentru transfer de conținut) și mesagerie. Apropo, utilizatorii de Internet Explorer nu au noroc că suportul ORTC va fi disponibil doar în Edge. Și, desigur, acest set de protocoale și codecuri se interfață ușor cu Skype for Business, care deschide și mai multe aplicații de afaceri pentru WebRTC.

Scopul acestui articol este de a utiliza un eșantion demonstrativ de chat video peer-to-peer (chat video p2p) pentru a vă familiariza cu structura și principiul său de funcționare. În acest scop, vom folosi demonstrația de chat video peer-to-peer multi-utilizator webrtc.io-demo. Poate fi descărcat de pe link-ul: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

De menționat că GitHub este un site sau serviciu web pentru dezvoltarea colaborativă a proiectelor Web. Pe acesta, dezvoltatorii pot posta codurile dezvoltărilor lor, le pot discuta și pot comunica între ei. În plus, unele mari companii IT își postează depozitele oficiale pe acest site. Serviciul este gratuit pentru proiecte open source. GitHub este un depozit pentru biblioteci de cod sursă deschise și gratuite.

Deci, vom plasa eșantionul demonstrativ de chat video peer-to-peer descărcat de pe GitHub pe unitatea C calculator personalîn directorul creat pentru aplicația noastră „webrtc_demo”.

Orez. 1

După cum reiese din structură (Fig. 1), chat-ul video peer-to-peer este format din script-uri client script.js și server server.js, implementate în limbajul de programare JavaScript. Script (biblioteca) webrtc.io.js (CLIENT) - oferă organizarea comunicațiilor în timp real între browsere folosind o schemă peer-to-peer: „client-client”, și webrtc.io.js (CLIENT) și webrtc. io.js (SERVER), Folosind protocolul WebSocket, oferă comunicații duplex între browser și serverul web folosind o arhitectură client-server.

Scriptul webrtc.io.js (SERVER) este inclus în biblioteca webrtc.io și se află în directorul node_modules\webrtc.io\lib. Interfața de chat video index.html este implementată în HTML5 și CSS3. Conținutul fișierelor aplicației webrtc_demo poate fi vizualizat folosind unul dintre editorii html, de exemplu „Notepad++”.

Vom verifica principiul de funcționare al chat-ului video în Sistemul de fișiere PC. Pentru a rula serverul (server.js) pe un PC, trebuie să instalați mediul de rulare node.js. Node.js vă permite să rulați cod JavaScript în afara browserului. Puteți descărca node.js de pe link-ul: http://nodejs.org/ (versiunea v0.10.13 din 15/07/13). Pe pagina principală a site-ului web node.org, faceți clic pe butonul de descărcare și accesați http://nodejs.org/download/. Pentru utilizatorii de Windows, mai întâi descărcați win.installer (.msi), apoi rulați win.installer (.msi) pe computer și instalați nodejs și „npm package manager” în directorul Program Files.

Orez. 2

Astfel, node.js constă dintr-un mediu pentru dezvoltarea și rularea codului JavaScript, precum și un set de module interne care pot fi instalate folosind managerul sau managerul de pachete npm.

Pentru a instala module trebuie Linie de comanda Din directorul aplicației (de exemplu, „webrtc_demo”) rulați comanda: npm install module_name. În timpul procesului de instalare a modulelor, managerul npm creează un folder node_modules în directorul din care a fost efectuată instalarea. În timpul funcționării, nodejs conectează automat modulele din directorul node_modules.

Deci, după instalarea node.js, deschideți linia de comandă și actualizați modulul expres din folderul node_modules din directorul webrtc_demo folosind managerul de pachete npm:

C:\webrtc_demo>npm install express

Modulul expres este un cadru web pentru node.js sau o platformă web pentru dezvoltarea aplicațiilor. Pentru a avea acces global la Express, îl puteți instala astfel: npm install -g express.

Apoi actualizați modulul webrtc.io:

C:\webrtc_demo>npm instalează webrtc.io

Apoi, pe linia de comandă lansăm serverul: server.js:

C:\webrtc_demo>node server.js

Orez. 3

Asta este, serverul rulează cu succes (Figura 3). Acum, folosind un browser web, puteți contacta serverul după adresa IP și puteți încărca pagina web index.html, din care browserul web va extrage codul de script client - script.js și codul de script webrtc.io.js și executa-le. Pentru a opera chat video peer-to-peer (pentru a stabili o conexiune între două browsere), trebuie să contactați serverul de semnal care rulează pe node.js din două browsere care acceptă webrtc.

Ca urmare, interfața părții client a aplicației de comunicare (video chat) se va deschide cu o solicitare de permisiunea de a accesa camera și microfonul (Fig. 4).

Orez. 4

După ce faceți clic pe butonul „Permite”, camera și microfonul sunt conectate pentru comunicare multimedia. În plus, puteți comunica prin date text prin interfața de chat video (Fig. 5).

Orez. 5

Trebuie remarcat faptul că. Serverul este un server de semnalizare și este conceput în principal pentru a stabili conexiuni între browserele utilizatorilor. Node.js este utilizat pentru a opera scriptul serverului server.js care oferă semnalizare WebRTC.