Astăzi, WebRTC este o tehnologie fierbinte pentru streaming audio și video în browsere. Tehnologiile conservatoare, cum ar fi streaming-ul HTTP și blițul, sunt mai potrivite pentru distribuirea conținutului înregistrat (video la cerere) și semnificativ inferior WebRTC în termeni de emisiuni în timp real și online, adică. În cazul în care este necesară întârzierea minimă a videoclipului, permițând publicului să vadă ce se întâmplă "Live".

Posibilitatea de comunicare de înaltă calitate în timp real este derivată din arhitectura WebRTC în sine, unde protocolul UDP este utilizat pentru a transporta fluxuri video, care este baza standard pentru transmiterea video cu întârzieri minime și utilizate pe scară largă în sistemele de comunicații în timp real.

Întârzierea comunicării este importantă în sistemele de radiodifuziune online, Webinars și alte aplicații în care este necesară o comunicare interactivă cu sursa video, utilizatorii finali și necesită o soluție.

Un alt motiv greu pentru a încerca webrtc este cu siguranță o tendință. Astăzi, fiecare browser Android Chrome acceptă această tehnologie, care garantează milioane de dispozitive gata pentru vizualizarea difuzării fără a instala software și configurații suplimentare.

Pentru a verifica tehnologia WebRTC în caz și pentru a rula o difuzare on-line simplă, am folosit serverul pe serverul FlashPhoner WebRTC Media & Broadcasting. În caracteristici, abilitatea de a difuza fluxurile WebRTC într-un mod la mai multe "(un-la-mamei), precum și suport pentru camerele IP și sistemele de supraveghere video prin protocolul RTSP; În această recenzie, ne concentrăm pe emisiunile web Web și pe caracteristicile acestora.

Instalarea serverului WebRTC Media & Broadcasting

Deoarece sistemul versiunii serverului nu a fost pentru Windows, nu a vrut să instaleze un tip VMware + Linux Tip virtual, emisiunile online de testare pe computerul Windows nu a funcționat. Pentru a economisi timp, a decis să ia instanțe pe un nor care găzduiește astfel:

A fost CentOS X86_64 versiunea 6.5 fără software preinstalat în centrul de date din Amsterdam. Astfel, tot ceea ce am primit este disponibil este serverul și accesul ssh la acesta. Pentru cei care sunt familiarizați cu comenzile consolei Linux, instalarea serverului WebRTC promite să meargă ușor și fără durere. Deci, ceea ce am făcut:

1. Descărcați arhiva:

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

2. Despacheta

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

3. Instalare:

$ Cd flashfonerwebcallServer.

În timpul instalării de introducere a adresei IP a serverului: xxx.xxx.xxx.xxx

4. Activați licența:

$ CD / usr / locale / flashfonerwebcallServer / bin

$. / Activare.sh

5. Rulați serverul WCS:

$ Service WebcallServer Start

6. Verificați jurnalul:

$ coada - f /usr/local/flashphonerwebcallServer/logs/flashphoner_manager.log

7. Verificați dacă două procese în vigoare:

$ Ps aux | Grep flashfoner.

Procesul de instalare este finalizat.

Testarea emisiunilor Online WebRTC

Transmiterea emisiunilor s-au dovedit a fi nerealizate. În plus față de server, există un client web care constă dintr-o duzină de fișiere JavaScript, HTML și CSS și a fost implementat în folderul / var / www / html din faza de instalare. Singurul lucru care trebuia făcut este să introducă adresa IP a serverului la configurarea flashfoner.xml astfel încât clientul web să se poată conecta la serverul Websockets HTML5. Descriem procesul de testare.

1. Deschideți pagina client Index.html din browser Chrome:

2. Pentru a porni emisiunea, trebuie să faceți clic pe butonul "Start" din mijlocul ecranului.
Înainte de a face, trebuie să vă asigurați că camera web este conectată și gata de lucru. Nu există cerințe speciale pentru camera web, de exemplu, am folosit camera standard încorporată în laptop cu o rezoluție de 1280 × 800.

Browserul Chrome va cere cu siguranță accesul la aparatul foto și microfon pentru ca utilizatorul să înțeleagă că videoclipul său va fi trimis la serverul de Internet și la permis să facă acest lucru.

3. Interfața este o emisiune de succes a fluxului video de pe aparatul foto de pe serverul WebRTC. În colțul din dreapta sus, indicatorul indică faptul că fluxul se duce la server, în colțul de jos butonul Stop pentru a opri trimiterea video.

Fiți atenți la link-ul din câmpul de jos. Acesta conține identificatorul unic al acestui fir, astfel încât oricine se poate alătura vizionării. Este suficient să deschideți această legătură în browser. Pentru ao copia în clipboard, trebuie să faceți clic pe butonul "Copiere".

În aplicațiile reale, cum ar fi webinarii, prelegeri, emisiuni online sau dezvoltatori de televiziune interactivă vor trebui să pună în aplicare distribuția acestui identificator anumitor grupuri de telespectatori pentru ca acestea să se conecteze la fluxurile dorite, dar aceasta este logica aplicației. Serverul WebRTC Media & Broadcasting nu afectează, ci doar distribuirea video.

5. Conexiunea este stabilită și vizualizatorul vede fluxul de pe ecran. Acum, el poate trimite un link către altcineva, nu mai reproduceți fluxul sau porniți modul ecran complet utilizând comenzile din colțul din dreapta jos.

Rezultatele testelor WebRTC Server de traducere online

În timpul testelor, întârzierea părea perfectă. Ping la centrul de date sa ridicat la aproximativ 100 de milisecunde, iar întârzierea nu a fost distinsă de ochi. De aici, se poate presupune că întârzierea reală este aceeași 100 plus minus câteva zeci de milisecunde pentru timpul de tamponare. Dacă comparați cu Flash Video: În astfel de teste, Flash nu se comportă la fel de bun ca WebRTC. Deci, dacă într-o rețea similară pentru a vă deplasa mâna, atunci mișcarea de pe ecran poate fi văzută numai prin una / două secunde.

În ceea ce privește calitatea, observăm că pe mișcările uneori puteți distinge cuburile. Aceasta corespunde naturii codecului VP8 și a sarcinii sale principale - pentru a oferi o conexiune video în timp real cu o calitate acceptabilă și fără întârzieri în comunicare.

Serverul este suficient de ușor pentru a instala și configura, nu necesită abilități grave în plus față de cunoștințele Linux la nivelul unui utilizator avansat care poate executa comenzi de la consola prin SSH și utilizează editorul de text. Ca rezultat, am reușit să stabilim radiodifuziunea online între browsere. Conectarea spectatorilor suplimentari la flux, de asemenea, nu a provocat probleme.

Calitatea difuzată sa dovedit a fi destul de acceptabilă pentru webinarii și emisiunile online. Singurul lucru care a provocat câteva întrebări este rezoluția video. Camera acceptă 1280 × 800, dar rezoluția din imaginea de testare este foarte asemănătoare cu 640 × 480. Aparent, această întrebare trebuie clarificată de dezvoltatori.

Testarea video difuzată de la camera web
prin serverul WebRTC.

WebRTC (comunicații în timp real) este un standard care descrie transmiterea datelor audio streaming, a datelor video și a conținutului din browser și a browserului în timp real fără a instala plug-in-uri sau alte extensii. Standardul vă permite să transformați browserul în terminalul terminal al videoconferințelor, să deschideți pagina web pentru a începe comunicarea.

Ce este webrtc?

În acest articol, vom lua în considerare tot ce trebuie să știți despre tehnologia WebRTC pentru un utilizator obișnuit. Luați în considerare avantajele și dezavantajele proiectului, dezvăluiți unele secrete, vă vom spune cum funcționează, unde și ce este aplicat WebRTC.

Ce trebuie să știți despre WebRTC?

Evoluția standardelor și tehnologiilor Communicatii video

Sergey Yutzaytis, Cisco, Video + Conferința 2016

Cum funcționează WebRTC.

Pe partea clientului

• Utilizatorul deschide o pagină care conține etichetă HTML5
• Browserul solicită accesul la un webcam și un microfon utilizator.
• Codul JavaScript de pe pagina de utilizator controlează parametrii conexiunii (adresele IP și serverul WebRTC sau alți clienți WebRTC) pentru a ocoli NAT și firewall.
• Când primiți informații despre interlocutor sau un flux cu conferința, browserul începe să se potrivească cu codecurile audio și video utilizate.
• Procesul de codificare și transmitere a datelor de streaming între clienții WebRTC (în cazul nostru, între browser și server) începe.

Pe partea laterală a serverului WebRTC

Pentru schimbul de date între cei doi participanți, serverul video nu este necesar, dar dacă trebuie să combinați mai mulți participanți la o conferință, serverul este necesar.

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

De asemenea, Serverul WebRTC va primi traficul media de la WebRTC Peters și va transfera la participanții la conferințe care utilizează aplicații pentru computere desktop sau dispozitive mobile, dacă există.

Avantajele standardului

• Nu este necesară instalarea.
• Comunicare foarte de înaltă calitate din cauza:
  • Utilizarea codecurilor video (VP8, H.264) și audio (OPUS).
  • Ajustarea automată a calității fluxului sub starea conexiunii.
  • ECHO încorporat și sistem de reducere a zgomotului.
  • Ajustarea automată a sensibilității microfoanelor participanților (ARU).
• Securitate înaltă: Toate conexiunile sunt protejate și criptate în conformitate cu protocoalele TLS și SRTP.
• Există un mecanism de captare a conținutului încorporat, cum ar fi desktopul.
• Abilitatea de a implementa orice interfață de management HTML5 și JavaScript.
• Abilitatea de a integra o interfață cu orice sisteme de back-end utilizând WebSockets.
• Un proiect open source - poate fi implementat în produsul sau serviciul dvs.
• Real Cross-Platform: aceeași aplicație WebRTC va funcționa la fel de bine pe orice sistem de operare, desktop sau mobil, cu condiția ca browserul să accepte webrtc. Acest lucru economisește semnificativ resurse pentru dezvoltarea software-ului.

Dezavantaje ale standardului

• Pentru organizarea conferințelor audio și video de grup, este necesar serverul VKS, care ar amesteca videoclipul și sunetul de la participanți, deoarece Browserul nu știe cum să sincronizeze câteva fluxuri de intrare între ele.
• Toate soluțiile WebRTC sunt incompatibile, deoarece Standardul descrie doar metode de transmisie video și de sunet, lăsând implementarea metodelor de abordare a abonaților, urmărirea disponibilității, mesageriei și a fișierelor, planificarea și alți furnizori.
• Cu alte cuvinte, nu veți putea apela de la aplicația WebRTC a unui dezvoltator în aplicația WebRTC a unui alt dezvoltator.
• Amestecarea conferințelor de grup necesită resurse mari de calcul, astfel încât acest tip de apel video necesită achiziționarea unui abonament plătit sau investiții în infrastructura sa, unde este necesar un nucleu fizic al procesorului modern pentru fiecare conferință.

Secretele WebRTC: Cum furnizorii beneficiază de tehnologia web descoperită

Tsakhi LeVi, Bloggeek.me, Video + Conferința 2015

Webrtc pentru piața VKS

Creșterea numărului de terminale VKS

Tehnologia WebRTC a avut un impact puternic asupra dezvoltării pieței VKS. După părăsirea primelor browsere cu suportul WebRTC în 2013, numărul potențial de terminale de conferințe video din întreaga lume a crescut imediat cu 1 miliard de dispozitive. În esență, fiecare browser a devenit un terminal CSM, nu inferior analogilor sa hardware din punctul de vedere al licitării.

Utilizați în soluții specializate

Utilizarea diferitelor biblioteci JavaScript și WebRTC Cloud Service API vă permite să adăugați cu ușurință suport de legătură video la orice proiecte web. Anterior, să transmită date în timpul dezvoltatorilor în timp real, era necesar să se studieze principiile protocoalelor și să utilizeze evoluțiile altor companii care au cerut cel mai adesea licențierea suplimentară, ceea ce a crescut costurile. Deja, WebRTC este utilizat în mod activ în "Site-ul de apel", "Suport de chat online" etc.

Ex-utilizatorii Skype pentru Linux

În 2014, Microsoft a anunțat încetarea suportului de proiect Skype pentru Linux, care a provocat o mare iritare din partea specialiștilor IT. Tehnologia WebRTC nu este legată de sistemul de operare și implementată la nivelul browserului, adică Utilizatorii Linux vor putea vedea produsele și serviciile bazate pe înlocuirea Skype Fulld WebRTC.

Competiția cu bliț.

WebRTC și HTML5 au devenit o lovitură fatală pentru tehnologia Flash, care și atât de îngrijorată de departe de cei mai buni ani. Din 2017, browserele de frunte au încetat oficial pentru a sprijini Flash și Tehnologia au dispărut în cele din urmă de pe piață. Dar trebuie să oferiți flash datorită, după tot ce a fost cel care a creat piața conferinței web și a propus oportunități tehnice pentru comunicațiile live în browsere.

Prezentare video WebRTC.

Dmitry Odintsov, TrueConf, Video + Conference Octombrie 2017

Codecs în WebRTC.

Codecuri audio

Pentru a comprima traficul audio în codecurile WebRTC, Opus și G.711 sunt utilizate.

G.711. - Cel mai vechi codec vocal cu o rată mare de biți (64 kbps), care este cel mai adesea folosit în sistemele de telefonie tradițională. Principalul avantaj este sarcina computațională minimă datorită utilizării algoritmilor de compresie a luminii. Codecul este caracterizat printr-un nivel scăzut de compresie a semnalului vocal și nu face o întârziere audio suplimentară în timpul comunicării dintre utilizatori.

G.711 este susținută de un număr mare de dispozitive. Sistemele în care acest CODEC este utilizat este mai ușor de utilizat decât cele bazate pe alte coduri audio (G.723, G.726, G.728 etc.). În ceea ce privește calitatea G.711, sa estimat 4.2 în testul MOS (o estimare în intervalul 4-5 este cea mai mare și înseamnă o calitate bună, similară cu calitatea transmisiei de trafic vocal în ISDN și chiar mai mare).

Opus. - Acesta este un codec cu o întârziere scăzută de codificare (2,5 ms la 60 ms), suport pentru un biți variabil și un nivel ridicat de compresie, care este ideal pentru transmiterea unui semnal audio streaming în rețele cu lățime de bandă variabilă. Opus este o soluție hibridă care combină cele mai bune caracteristici ale codecilor de mătase (comprimarea vocii, rezolvarea distorsiunii de vorbire umană) și CELT (codificarea datelor audio). Codecul este în acces liber, dezvoltatorii care îl folosesc, nu trebuie să plătească deducerile pentru deținătorii de drepturi de autor. În comparație cu alte coduri audio, Opus, fără îndoială câștigă în mulți indicatori. El a eclipsat codecuri destul de populare cu un bitrate scăzut, cum ar fi MP3, Vorbis, AAC LC. Opus restaurează cel mai aproape de "imaginea" originală a sunetului decât AMR-WB și Speex. În spatele acestui CODEC - viitorul, motiv pentru care tehnologiile WebRTC l-au inclus într-o gamă obligatorie de audiostandați susținuți.

Codec video.

Selecția unui codec video pentru WebRTC a durat câțiva ani de la dezvoltatori, ca rezultat, am decis să folosim H.264 și VP8. Aproape toate browserele moderne suportă ambele codecuri. Servere de conferințe video pentru lucrul cu WebRTC suport suficient doar unul.

VP8. - Video gratuit codificat cu o licență deschisă se distinge printr-o viteză mare de decodificare a fluxului video și o rezistență sporită la pierderea cadrelor. Codecul este universal, este ușor de introdus în platforme hardware, deci foarte des dezvoltatorii sistemelor de videoconferință îl utilizează în produsele lor.

CODEC VIDEO CODECUT H.264. El a devenit cunoscut mult mai devreme decât colegul său. Acesta este un codec cu un grad ridicat de compresie a fluxului video, menținând în același timp video de înaltă calitate. Prevalența ridicată a acestui CODEC printre sistemele hardware de conferințe video implică utilizarea sa în standardul WebRTC.

Google și Mozilla promovează în mod activ codecul VP8 și Microsoft, Apple și Cisco - H.264 (pentru a asigura compatibilitatea cu sistemele tradiționale de conferințe video). Și aici este o problemă foarte mare pentru dezvoltatorii de soluții Cloud WebRTC, deoarece, în cadrul conferinței, toți participanții folosesc un browser, conferința este suficientă pentru a se amesteca o dată cu un codec și dacă există browsere diferite și există Safari / Edge Browsere, apoi conferința va trebui să fie codificată de două ori diferite, ceea ce va dubla cerințele sistemului pentru serverul media și, ca rezultat, costul abonamentelor către serviciile WebRTC.

Webrtc api.

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

• (Responsabil pentru acceptarea unui semnal audio și video de browser web de la aparatul de fotografiat sau de pe desktopul utilizatorului).
• Rtcpeerconnection. (Responsabil pentru legătura dintre browsere pentru "schimbul" primite de la aparatul foto, microfon și desktop, mediadanții. De asemenea, în "Drepturile" acestui API intră în procesul de procesare a semnalului (curățându-l din afară, reglarea volumului microfonului) și controlul codurile audio și video utilizate).
• Canalul RTCDATA. (Oferă transmisia de date bilaterală prin conexiunea stabilită).

Înainte de a accesa microfonul și camera de utilizator, browserul solicită permisiunea. În Google Chrome, vă puteți regla în avans în secțiunea "Setări", în Opera și Firefox, selectarea dispozitivelor este efectuată direct în momentul accesului, din lista derulantă. Cererea de rezoluție va apărea întotdeauna la utilizarea protocolului HTTP și o dată dacă utilizați HTTPS:

Rtcpeerconnection.. Fiecare browser care participă la conferința WebRTC trebuie să aibă acces la acest obiect. Datorită utilizării RTCPEERCONNECTY, mediadentul dintr-un browser poate fi utilizat chiar și prin ecrane NAT și de rețea. Pentru a transfera cu succes porțiunile media, participanții ar trebui să schimbe următoarele date utilizând transportul, cum ar fi prizele web:

• participantul inițiator trimite cel de-al doilea participant la ofertă-SDP (structura datelor, cu caracteristicile fluxului media, pe care le va transmite);
• cel de-al doilea participant formează "răspunsul" - răspuns-SDP și îl transmite inițiatorului;
• apoi, schimbul de candidați la gheață este organizat între participanți, dacă este cazul (dacă participanții sunt în spatele ecranelor NAT sau de rețea).

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

Canalul RTCDATA.. Suportul protocolului canalelor de date a apărut în browsere relativ recent, prin urmare, acest API poate fi vizualizat exclusiv în cazurile de utilizare a browserelor WebRTC în Mozilla Firefox 22+ și Google Chrome 26+. Cu aceasta, participanții pot partaja mesaje text în browser.

Conexiune de către webrtc.

Browserele desktop acceptate

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

Browsere mobile acceptate pentru Android

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

Webrtc, Microsoft și Internet Explorer

Pentru o lungă perioadă de timp Microsoft a păstrat tăcerea cu privire la suportul WebRTC în Internet Explorer și în noul său browser Edge. Băieții de la Redmond nu doresc cu adevărat să dea tehnologiilor utilizatorilor că nu controlează, aceasta este o astfel de politică. Dar, treptat, cazul a fost mutat din punctul mort, pentru că WebRTC a mai fost imposibil de ignorat, iar proiectul ORTC derivat din standardul WebRTC a fost anunțat.

Potrivit dezvoltatorilor, ORTC este o extensie a standardului webRTC cu un set îmbunătățit de API și HTML5 bazat pe JavaScript, care tradus într-o limbă normală înseamnă că totul va fi același, doar pentru a controla standardul, iar dezvoltarea sa va fi Microsoft , și nu Google. Setul de codecuri este extins de suportul pentru H.264 și unele coduri audio ale seriei G.7xx utilizate în sistemele de telefonie și hardware VKS. Poate apărea suport încorporat pentru PDR (pentru transmiterea conținutului) și mesageria. Apropo, utilizatorii de Internet Explorer nu sunt norocoși, suportul ORTC va fi doar la margine. Ei bine, în mod natural, un astfel de set de protocoale și codecuri cu sânge scăzut este introdus cu Skype for Business, care deschide și mai multe aplicații de afaceri pentru WebRTC.

Webrtc este un API furnizat de un browser și vă permite să organizați conexiunea P2P și transferul de date direct între browsere. Pe Internet există destul de multe manuale pentru scrierea propriei chat-uri video utilizând WebRTC. De exemplu, aici este un articol despre Habré. Cu toate acestea, toate acestea se limitează la conectarea a doi clienți. În acest articol, voi încerca să spun despre cum să organizați conexiune și mesaje între trei și mai mulți utilizatori care utilizează WebRTC.

Interfața RTCPeerConnection este o conexiune peer-to-peer între două browsere. Pentru a conecta trei și mai mulți utilizatori, va trebui să organizăm o rețea de plasă (o rețea în care fiecare nod este conectat la toate celelalte noduri).
Vom folosi următoarea schemă:

1. La deschiderea unei pagini, verificați prezența ID-ului camerei în locație.
2. Dacă ID-ul camerei nu este specificat, generăm un nou
3. Trimitem serverul de semnalizare "mesajul despre ceea ce vrem să ne alăturăm camerei specificate
4. Serverul de semnalizare formează restul clienților din această cameră o nouă alertă de utilizatori
5. Clienții care sunt deja în cameră trimit o ofertă SDP nou-venită
6. Newbie răspunde la ofertă

0. Server de semnalizare

După cum știți, cel puțin WebRTC și oferă posibilitatea conexiunilor P2P între browsere, aceasta necesită încă transport suplimentar pentru a schimba mesajele de servicii. În acest exemplu, serverul WebSocket scris pe NODE.JS utilizând socket.io acționează ca un astfel de transport.

Var socket_io \u003d necesită ("socket.io"); MODULE.EXPORTS \u003d (Server) (Var Utilizatori \u003d (); Var Io \u003d Socket_io (server); IO.ON ("conexiune", funcția (// Desire de un utilizator nou Alăturați-vă în camera socket.on (" Cameră ", funcția (mesajul) (mesajul JSON \u003d json.parse (mesaj); // Adăugați o priză la lista utilizatorilor utilizatori \u003d priză; dacă (socket.room! \u003d\u003d nedefinit) (// dacă soclul este deja În unele camere, ieșiți din socket.Leave (socket.room);) // Introduceți camera solicitată Socket.room \u003d Json.room, Socket.Join (socket.roid); socket.user_id \u003d json.id; / / trimiteți la restul clienților din această cameră, un mesaj despre aderarea la un nou membru socket.broadcast.to (socket.room) .emit ("nou", json.id); // mesaj legat de webrtc ( Oferta SDP, răspunsul SDP sau candidatul la gheață) socket.on ("webrtc", funcție (mesaj) (mesaj); dacă (JSON.TO! \u003d\u003d Utilizatori Undefined && Utilizatori! \u003d\u003d Undefined) (// Dacă mesajul este specificat de destinatarul și acest destinatar cunoscut serverului, trimit un mesaj numai pentru el ... utilizatori.emit ("webrtc", mesaj); ) Altfel (// ... altfel luăm în considerare mesajul prin radiodifuziune socket.broadcast.to (socket.room) .Emmit ("webrtc", mesaj);))); . ștergeți utilizatorii;)); ); );

1. index.html.

Codul sursă al paginii în sine este destul de simplu. În mod conștient, nu am acordat atenție layout-ului și altor frumos, deoarece acest articol nu este despre asta. Dacă cineva vrea, faceți-o frumos, nu va funcționa multă dificultate.

2. Main.js.

2.0. Primiți linkuri către articolele de pagină și interfețele WebRTC

var chatlog \u003d document.getelementbyid ("chatlog"); Var Message \u003d document.getelementbyid ("mesaj"); var conexiune_num \u003d document.getelementbyid ("conexiune_num"); var_link \u003d document.getelementbyid ("cameră_link");

Încă mai trebuie să folosim prefixele browserului pentru a accesa interfețele WebRTC.

VAR Peerconnection \u003d fereastră.mozrtcpeerconection || Fereastră.Webkitrtcpeerconnection; Var Sessiondescription \u003d fereastră.moztcsesiondescription || Fereastră.rtcsesiondescription; VAR OPECANDADA \u003d fereastră.MoztCiceCandad || Fereastră.RCICECADANIDE;

2.1. Definirea ID-ului camerei

Aici vom avea nevoie de o funcție pentru a genera un identificator unic al camerei și a utilizatorului. Vom folosi UUID în aceste scopuri.

Funcția UUID () (retur matemath.floor () (matemath.random () * 0x10000).]; Returnează S4 () + S4 () + "-" + S4 () + "-" + S4 () + "-" + S4 () + "-" + S4 () + S4 () + S4 ();)

Acum, să încercăm să tragem identificatorul camerei de la adresa. Dacă acest lucru nu este specificat, vom genera unul nou. Să aducem legătura cu camera curentă la pagină și, pentru unul, va genera identificatorul actual de utilizator.

Var cameră \u003d locație.hash.substr (1); dacă (! cameră) (cameră \u003d uuid ();) room_link.innerhtml \u003d "link în cameră"; var me \u003d uuid ();

2.2. Websocket.

Imediat Când deschideți pagina, vă veți conecta la serverul nostru de semnalizare "Y, veți trimite o solicitare de a intra în cameră și de a specifica managerii de mesaje.

// specificăm că atunci când închideți mesajul, trebuie să trimiteți serverul la Socket VAR \u003d io.connect ("", ("Sincronizați deconectarea la descărcare": TRUE)); socket.on ("webrtc", socketreceived); socket.on ("nou", socketwpeer); // trimite imediat o cerere de a intra în camera socket.emit ("cameră", json.Stringfy ((id: eu, camera: cameră))); . )););)

2.3. Setări Peererconctionare

Majoritatea furnizorilor oferă conexiune la internet prin NAT. Din acest motiv, conexiunea directă nu devine afacere atât de trivială. Când creați o conexiune, trebuie să specificăm lista de servere de asistență și să transformăm că browserul va încerca să se utilizeze pentru a ocoli NAT. De asemenea, specificăm o pereche de opțiuni suplimentare pentru conectare.

Var Server \u003d (IceServers: [URL: "STUN: 23.21.150.121"), (URL: stun: stun.l.google.com: 19302 "), (URL:" Turn: numb.viagenie.ca ", acreditare : "Parola dvs. merge aici", nume de utilizator: " [E-mail protejat]')

2.4. Conectarea unui utilizator nou

Când se adaugă o nouă sărbătoare în cameră, serverul ne trimite un mesaj. nou. Conform manipulatoarelor de mesaje specificate mai sus, o funcție va apela. socketNewPeer..

Var peers \u003d (); Funcție SocketNewPeer (date); // Creați o nouă conexiune Var PC \u003d New PeererConnection (server, Opțiuni); // Inițializarea inițialității IT (PC, Date, "Ofertă"); // Păstrați Pir Peers.Connection \u003d PC; / / Creați Dachachannel pentru care Var Channel \u003d PC.CreatedataHannel ("mychannel", ()); canal.owner \u003d date; peers.channel \u003d canal; // Instalarea stivuitorilor Evenimentului Canal Bindevents (canal); // Creați oferta de ofertă SDP. CreateOffer (Funcție (ofertă));) Funcție InitConnection (PC, ID, SDPTYPE) (PC.OniceCandad \u003d Funcție (eveniment) (dacă (Event.Candidat) (// Când este detectată noua gheață a candidatului, adăugați-o în listă trimiterea în continuare peers.Candidecache.push (Event.Candidat);) altceva (// Când detectarea candidatului este finalizată, manipulatorul va fi numit din nou, dar fără candidat // În acest caz, trimitem o frică de prima ofertă SDP sau Răspuns SDP (în funcție de parametrul funcției) ... SendviaSocket (SDPTYPE, PC.LocalDescrieri, ID); // ... și apoi toate candidații de gheață găsită anterior pentru (var i \u003d 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. Oferta SDP, răspunsul SDP, candidatul la gheață

La primirea unuia dintre aceste mesaje, apelați manipulatorul mesajului corespunzător.

Funcția SocketReceived (date); comutator (json.type) (candidat) (json.id, json.data); pauză; caz "ofertă": RemoteofferReceived (JSON. ID, JSON.DATA); Break; caz " Răspuns ": RemotenswerreCEived (JSON.ID, JSON.DATA); Break;))

2.5.0 ofertă SDP.

Funcție RemotefferReception (ID, Date) (CreareConnection (ID); VAP PC \u003d colegii.connection; PC.SETRemotedescription (date); PC.CreateAnswer (funcția (răspunsul) (răspuns))));) Funcție CreareConnection (ID) (dacă (Colegii \u003d\u003d\u003d nedefinit) (colegii \u003d (CandidatCache :); VAP PC \u003d New PeerConection (server, Opțiuni); InitConnection (PC, ID, "Răspuns"); colee.connection \u003d PC; PC.ONDATACHANNALION \u003d FUNCTION (E ) (peers.channel \u003d e.channel; coles.channel.owner \u003d id; bindrovens (colective);)))))

2.5.1 Răspuns SDP.

Funcție RemoteSweReReceived (ID, Date) (VAP PC \u003d colegii.Connection; PC.Setremotededeption (New Sessiondescription (date));)

2.5.2 Candidat la gheață.

Funcția RemoteCandidat (ID, Date) (CreațiConnection (ID); VAP PC \u003d colegii.Connection; PC.AddicAndided (Noua IceCandatul (date);

2.6. Trimiterea unui mesaj

Apăsând butonul Trimite. Funcția este numită trimite mesaj.. Tot ceea ce face ea este transmis pe lista colegilor și încearcă să trimită mesajul specificat tuturor.

Timp de mulți ani pentru apelurile de la browser de mai mulți ani: Java, ActiveX, Adobe Flash ... În ultimii ani a devenit clar că plugin-urile și mașinile virtuale stângi nu strălucesc (de ce ar trebui să instalez ceva?) Și, Cel mai important, securitatea. Ce să fac? Există o ieșire!

Până de curând, mai multe protocoale pentru telefonia IP sau video au fost utilizate în rețele IP: SIP, cel mai frecvent protocol care vine de la scena H.323 și MGCP, Jabber / Jingle (utilizată în Gtalk), Adobe RTMP semi-deschisă * și, de Curs, skype închis. Proiectul WebRTC, inițiat de Google, încearcă să transforme starea de lucruri în lume și pe telefonul web, făcând inutil toate telefoanele software, inclusiv Skype. WebRTC nu implementează doar toate capabilitățile de comunicare direct în interiorul browserului instalat acum pe fiecare dispozitiv, dar încercând să rezolve simultan sarcina mai generală a comunicațiilor între utilizatorii browserelor (schimbul de date, ecrane, colaborarea cu documente și multe altele).

WebRtc web dezvoltator

Din punctul de vedere al dezvoltatorului web WebRTC este alcătuit din două părți principale:

• gestionarea porțiunilor media din resursele locale (camera, microfonul sau ecranul local al computerului) este implementată de metoda Navigator.GetUserMedia care returnează obiectul MediaSTream;
• comunicarea peer-to-peer între dispozitive care generează trafic media, inclusiv definiția metodelor de comunicare și le transmite direct obiecte de protecție (pentru a trimite și a primi fluxuri audio și video) și RTCDatachannel (pentru trimiterea și primirea datelor din browser).

Ce facem?

Vom aborda cum să organizăm cel mai simplu chat video multiplayer între browserele bazate pe WEBRTC utilizând prize web. Experimentul va începe în Chrome / Chromiu, ca fiind cel mai avansat în ceea ce privește browserele WebRTC, deși lansate pe 24 iunie, Firefox 22 aproape le-a prins. Trebuie spus că standardul nu a fost încă acceptat și de la versiunea la versiunea API se poate schimba. Toate exemplele au fost verificate în crom 28. Pentru simplitate, nu vom urmări curățenia codului și a browserului încrucișat.

MediaSTream.

Prima componentă simplă a WebRTC - MediaSTream. Acesta oferă acces la browser la circulația media din cameră și microfonul local de calculator. În Chrome, este necesar să se apeleze la funcția navigator.webkitgetusermedia () (deoarece standardul nu este încă finalizat, toate funcțiile merg cu prefixul și în Firefox aceeași funcție se numește navigator.mozgetusermedia ()). Când o sună, utilizatorul va fi afișat o cerere de acces la cameră și microfon. Puteți continua apelul numai după ce utilizatorul își dă consimțământul. Parametrii acestei funcții transmit parametrii comutatorului media necesar și două funcții de apelare: Primul va fi cauzat în cazul unui acces cu succes la aparatul foto / microfon, al doilea - în cazul unei erori. Pentru a începe, creați un fișier HTML RTCTEST1.HTML cu un buton și un element

getusermedia.

Microsoft Cu-RTC-Web

Microsoft nu ar fi Microsoft dacă este ca răspuns la inițiativa Google nu a eliberat imediat opțiunea sa non-standard incompatibilă numită CU-RTC-Web (HTML5Labs.interoperabilitybridges.com/cu-rtc-wareb/cu-rtc-web.htm ). Deși cota de IE și atât de mică, continuă să se micșoreze, numărul de utilizatori Skype oferă Microsoft speră să preseze Google și se poate presupune că acest standard special va fi utilizat în versiunea browserului Skype. Standardul Google este orientat în principal pe comunicațiile dintre browsere; În același timp, partea principală a traficului de voce rămâne în continuare în rețeaua de telefonie obișnuită, iar gateway-urile dintre rețelele IT și IP sunt necesare nu numai pentru ușurința utilizării sau distribuției mai rapide, ci și ca mijloc de monetizare, care va Permiteți un număr mare de jucători să-i dezvolte. Apariția unui alt standard poate duce numai la nevoia neplăcută de a sprijini o dată două tehnologii incompatibile, dar în viitor pentru a oferi utilizatorului o selecție mai largă de posibilă funcționalitate și soluții tehnice accesibile. Așteptați și vedeți.

Pornirea fluxului local

Inside Tag-uri Fișierul nostru HTML va declara variabila globală pentru comutatorul media:

Var localstream \u003d null;

Primul parametru al metodei GetUtubermedia trebuie să specifice parametrii comutatorului media solicitat - de exemplu, includ pur și simplu audio sau video:

Var Streamconstracs \u003d ("Audio": Adevărat, "Video": TRUE); // solicitați accesul și audio și video

Fie specificați parametrii suplimentari:

Var Streamconstrains \u003d ("Audio": Adevărat, "Video": ("Obligatoriu": ("Maxwidth": "320", "MaxHeight": "240", "Maxframerat": "5"), "Opțional" :) );

Cel de-al doilea parametru al metodei GetUtubermedia trebuie transferat într-o funcție de apel invers, care va fi cauzată dacă este executată cu succes:

Funcție getusermedia_success ("getusermedia_suxcess ():", flux); localVideo1.src \u003d url.createObjecturl (flux); // Conectați comutatorul media la elementul HTML

A treia parametru - Handler de eroare de funcționare a funcției Callback, care va fi apelat în caz de eroare

Funcție getusermedia_error (eroare) (consola.log ("getusermedia_error ():", eroare);)

Apelând de fapt metoda GEUUSERMEDIA - Cerere de acces la microfon și cameră când faceți clic pe primul buton

Funcție getusermedia_click () (consola.log ("getusermedia_click ()"); navigator.webkitgetusermedia (Streamconstras, getusermedia_success, getusermedia_error);)

Obțineți acces la fișierul media din fișier deschis local, este imposibil. Dacă încercați să faceți acest lucru, obțineți o greșeală:

NavigatorUserMediaError (cod: 1, permision_denizat: 1) "

Postăm fișierul rezultat pe server, deschis în browser și ca răspuns la solicitarea care a apărut permițând accesul la cameră și microfonul.

Selectați dispozitivele la care vor primi Chrome, puteți setări ("Setări"), afișați setări avansate ("Afișați setările avansate"), confidențialitatea secțiunii ("Date personale"), butonul de conținut ("Setări de conținut"). În browserele Firefox și Opera, selecția dispozitivelor este realizată din lista derulantă direct atunci când accesul este rezolvat.

Când utilizați protocolul HTTP, permisiunea va fi solicitată de fiecare dată când primiți accesul la călătoria media după încărcarea paginii. Tranziția la HTTPS vă va permite să afișați o interogare o dată, numai cu primul acces la comutatorul media.

Fiți atenți la cercul pulsatoriu din pictograma de pe fila și pictograma camerei din partea dreaptă a barei de adrese:

RTCMediaConnection.

RTCMediaConnection este un obiect conceput pentru a stabili și transmite medii între participanți. În plus, acest obiect este responsabil pentru formarea unei descrieri a Mediassiei (SDP), obținând informații despre candidații de gheață pentru trecerea prin intermediul ecranelor NAT sau de rețea (locale și folosind stun) și interacționează cu serverul de întoarcere. Fiecare participant trebuie să aibă o singură conexiune RTCMediaConnection. Fotografiile media sunt transmise peste protocolul SRTP criptat.

Turn servere

Candidații de gheață sunt trei tipuri: gazdă, srflx și releu. Gazdă conține informații obținute la nivel local, SRFLX - modul în care nodul caută un server extern (stun) și releu - informații pentru traficul de proxing prin serverul de întoarcere. Dacă nodul nostru este în spatele NAT, atunci candidații gazdă vor conține adrese locale și vor fi inutile, candidații SRFLX vor ajuta numai cu anumite tipuri de NAT și releu va fi ultima speranță de a sări traficul prin intermediul serverului intermediar.

Exemplu de candidat la gheață a tipului de gazdă, cu adresa 192.168.1.37 și portul UDP / 34022:

A \u003d Candidatul: 337499441 2 UDP 2113937151 192.168.1.37 34022 Generarea tipului gazdă 0

Format general pentru setarea serverelor de sto / turn:

Var servere \u003d ("Iceservers": [("URL": "URL: stun.stunprotocol.org: 3478"), ("URL": "Turn: [E-mail protejat]: port "," Credential ":" Parola ")]);

Publicul servere de la Internet foarte mult. O listă mare, de exemplu, este. Din păcate, ei rezolvă prea multe probleme. Serverele de întoarcere publice, spre deosebire de stun, este practic nu. Acest lucru se datorează faptului că serverul de întoarcere trece prin fotografii media care pot descărca semnificativ și canalul de rețea și serverul însuși. Prin urmare, cea mai ușoară cale de a vă conecta la serverele de întoarcere este de a seta singur (este clar că va fi solicitată IP-ul public). De la toate serverele, în opinia mea, cel mai bun server RFC5766-Turn. Sub ea există chiar o imagine gata făcută pentru Amazon EC2.

Cu întoarcerea până când totul este atât de bun, dar există o dezvoltare activă și vreau să sper, după un timp WebRTC, dacă nu se compară cu Skype cu privire la calitatea trecerii prin difuzarea adreselor (NAT) și ecrane de rețea, apoi cel puțin o abordare vizibilă.

Pentru RTCMediaConnection, este necesar un mecanism suplimentar pentru schimbul de informații de control pentru a stabili o conexiune - deși formează aceste date, dar nu le transmite și transferul către alți participanți trebuie implementat separat.

Alegerea unei metode de transmisie este atribuită dezvoltatorului - deși manual. De îndată ce va avea loc schimbul de date necesare, RTCMediaConnection va stabili automat performanțele media (dacă se dovedește, bineînțeles).

Modelul ofertei-răspuns

Pentru a stabili și schimba vizualizările media, se utilizează modelul de ofertă / răspuns. Descris în RFC3264) și protocolul SDP (protocolul de descriere a sesiunii). Acestea sunt utilizate și protocolul SIP. Acest model distinge doi agenți: Ofrar - unul care generează o descriere SDP a sesiunii pentru a crea o nouă sau modificare a existenței (ofertei SDP), iar răspunsul este cel care primește o descriere a SDP a sesiunii de la un alt agent și îl întâlnește descrierea proprie a sesiunii (răspunsul SDP). În același timp, specificația necesită un protocol de nivel superior (de exemplu, SIP sau propriul său deasupra prizelor web, ca în cazul nostru) responsabil cu transmiterea PSD între agenți.

Ce date trebuie transferate între două RTCMediaConnection, astfel încât acestea să poată instala cu succes traficul media:

• Primul participant care inițiază conexiunea generează o ofertă în care transmite structura de date SDP (același protocol pentru același scop este utilizat în SIP), care descrie caracteristicile posibile ale comutatorului media, pe care o va începe să transmită. Acest bloc de date trebuie transferat la al doilea participant. Cel de-al doilea participant formează răspunsul, cu SDP și îl transmite primii.
• Iar primul și al doilea participant efectuează procedura de determinare a posibilelor candidați la gheață, cu ajutorul căruia al doilea participant va putea să se transfere la ei. După cum sunt definite candidații, informațiile despre ele ar trebui transmise unui alt participant.

Oferta de formare.

Pentru formarea ofertei, vom avea nevoie de două funcții. Primul va fi chemat în cazul formării sale de succes. Al doilea parametru al metodei CreateOffer () este o funcție de apel invers, numită dacă apare o eroare (cu condiția ca fluxul local să fie deja disponibil).

De asemenea, veți avea nevoie de două manipulatori de evenimente: OniceCandatul la determinarea noului candidat la gheață și OnAdstream atunci când conectați comutatorul media din partea îndepărtată. Să revenim la dosarul nostru. Adăugați la HTML după rânduri cu elemente încă una:

createOffer.

Și după un șir cu un element

De asemenea, la începutul codului JavaScript va declara variabila globală pentru RTCPEERCONNECTY:

Var PC1;

Când sunați la designerul RTCPEERCONNEction, trebuie să specificați serverele de stom / rândul său. Citiți mai multe despre ele, consultați inserția; În timp ce toți participanții se află în aceeași rețea, nu sunt obligați.

Var servere \u003d null;

Opțiuni pentru pregătirea ofertei SDP

VAR OFFERTCONSIRANDS \u003d ();

Primul parametru al metodei CreateOffer () este o funcție de apel invers la succes

Funcție PC1_CREATEOFFER_SUCCESS ("PC1_CREATEOFFER_SUCCESS ():" + desc.SDP + "Desc:", desc); PC1.SETLOCALDERICTIRE (DESC); // Setați RTCPEERCONNECTING, formată prin ofertă SDP utilizând metoda SetLocalDecription . // Când partea lungă rotundă este trimisă la răspunsul său SDP, va trebui să fie stabilit de Settremotedescription // până când a doua parte nu este implementată, nu face nimic // pc2_receivedoffer (desc);)

Al doilea parametru este o funcție de apel invers care va fi numită în caz de eroare

Funcția PC1_CREATEOFFER_ERROR (Eroare) (Console.log ("PC1_CREATEOFFER_SUCCESS_ERROR (): Eroare:", eroare);)

Și declară o funcție de apel inversă pe care candidații de gheață vor fi transmise așa cum sunt determinați:

Funcția PC1_ORICECANDADE (Evenimentul) (Console.log ("PC1_OniceCandade (): \\ n" + eveniment.candidat.Candid.replace ("\\ r \\ n", ""), eveniment.Candidat); // În timp ce a doua parte este nu implementate, nu face nimic // pc2.addicandatul (noul RTCICECADADIDE (Event.Candidat);))

Pe lângă o funcție de apel invers pentru a adăuga un comutator media din partea îndepărtată (pentru viitor, deoarece avem doar o singură RTCPEERCONNECTY):

FUNCȚIA PC1_ONADDSTREAM (console.log ( "PC_ONADDSTREAM ()"); remotevideo1.src \u003d url.createObjectURL (EVENT.Stream);)

Când faceți clic pe butonul CREATEOFFER, veți crea RTCPeerConnection, setați metodele OniceCandidate și onadstream și să solicite formarea ofertei PSD prin apelarea metodei CreateOFfer ():

Funcția createOffer_click () (console.log ( "createOffer_click ()"); PC1 \u003d new webkitRTCPeerConnection (servere); // Creare RTCPeerConnection pc1.onicecandidate \u003d pc1_onicecandidate; // Callback-funcție de procesare pentru ICE-candidați pc1.onaddstream \u003d pc1_onaddstream; // funcția de callback cauzată de apariția unui comutator media din partea îndepărtată. Până în prezent, nu are PC1.addstream (localstream); // Să dăm porțiuni media locale (presupunem că este deja primit) PC1.CreateOffer (// și care solicită de fapt formarea de PC1_CREATEOFFER_SUCCESS Oferta, PC1_CREATEOFFER_ERROR, OFFERCONSTRAINTS);)

Salvați fișierul ca RTCTEST2.HTML, post-l pe server, deschideți-l în browser-ul și aspectul în consolă, ce date sunt formate în timpul activității sale. Al doilea videoclip nu va apărea încă, ca participantul este doar unul. Reamintim, SDP - o descriere a parametrilor Mediassiei, codec-urile disponibile, performanțele media și candidații de gheață sunt opțiuni posibile pentru conectarea la acest participant.

Formarea răspunsului SDP și a ICE-Candidați

Iar PSD Oferta, și fiecare dintre candidații ICE trebuie să fie transferate către cealaltă parte și de acolo după primirea RTCPeerConnection pentru a apela metodele setremotedescription pentru PDS Oferta și Addicecandidate pentru fiecare ICE-candidat derivată din partea îndepărtată; În mod similar, în direcția opusă pentru răspunsul SDP și candidații la distanță de gheață. Răspunsul SDP în sine se formează în mod similar de oferit; Diferența este că metoda CreateOffer este numită, dar metoda CreateAnswer și înainte de această metodă RTCPEERCONNECTS este transmisă de SETremotedescription Ofertă SDP primită de la apelantul.

Adăugați un alt element video în HTML:

Și variabila globală pentru cea de-a doua RTCPEERCONNEction sub anunțul primului:

Var PC2;

Procesarea ofertei și răspundeți la SDP

Răspuns Formarea SDP este foarte asemănătoare ofertei. În funcție de reapelare cauzată de formarea cu succes a răspunsului, similar cu oferta, da o descriere locală și să dea primul participant a primit de PSD Răspuns:

Funcția PC2_CreateAnswer_Succesrtion (desc); console.log ("PC2_Createanswer_success ()", desc.sdp); PC1.Setreremotedscix (desc);)

-Numita funcție de apel invers, în cazul unei erori în formarea Răspunsul este complet similar cu oferta:

Funcția PC2_CreateAnswer_error (Eroare) (Console.log ("PC2_CreateAnswer_error ():", eroare);)

Răspundeți opțiunile de formare SDP:

Var Answerconstrains \u003d ("Obligatoriu": ("OfferToreceevedio": TRUE ", OffertoreVideo": TRUE));

La primirea ofertei, vom crea RTCPEERCONNECONNEREA ȘI FORMULARĂMĂ RĂSPUNS SAMILĂ LA OFERTA:

Funcție PC2_ReceiveDOFFFER (DESC) (Consoleofer (), DESC); // Creați un obiect RTCPEERCONNEction pentru cel de-al doilea participant în același mod ca primul PC2 \u003d New WebkitrtCpeerconnection (servere); PC2.oniceCandidat \u003d PC2_OniceCandidat; // Setați handlerul evenimentului Când evenimentul apare candidat la gheață PC2.onaddstream \u003d PC_ONADDSTEAM; // Când un flux pare să-l conecteze la HTML

Pentru ca în exemplul nostru, transmiteți oferta SDP de la primul participant la al doilea, ne dezabonăm în funcția PC1 createOffer.succes () șir de apel:

PC2_ReceiveDOffer (DESC);

Pentru a implementa prelucrarea candidaților cu gheață, noi inconsecventăm evenimentele de pregătire a candidaților de gheață a primului participant PC1_OniceCandidat () la transferul său la al doilea:

PC2.AddiceCandidatul (noul RTCecceCandidat (Event.Candidat));

Manipulatorul evenimentului de pregătire a celui de-al doilea candidat de gheață participant este primul oglindă:

Funcția PC2_OniceCandid (eveniment) (console.log ("PC2_ORICADECANDAD ():", Event.Candidat.Candidat); PC1.addiceCandatul (noul RTCICECADADIDE));)))

Caracteristică de apel inversă pentru adăugarea comutatorilor media de la primul participant:

Funcția PC2_Onaddstream (consola.log ("pc_onaddstream ()"); RemoteVideo2.src \u003d URL.CreateObjecturl (Event.Stream);)

Finalizarea conexiunii

Adăugați un alt buton la HTML

Închide.

Și funcția pentru a finaliza conexiunea

Funcție btnhanguplick () (// opriți videoclipul local de la elementele HTML

Salvați ca RTCTEST 3.HTML, stați pe server și deschideți în browser. Acest exemplu implementează un transfer bilateral al performanțelor media între două RTCPeerConection într-un marcaj de browser. Pentru a organiza schimbul de ofertă și a răspunde la SDP prin intermediul rețelei, vor fi necesare candidate de gheață între participanți și alte informații în locul unei proceduri directe de provocare pentru a pune în aplicare schimbul între participanții cu orice transport, în cazul nostru - Prize web.

Ecranul de difuzare

GetUtilizermedia Caracteristică De asemenea, puteți captura ecranul și difuzarea ca MediaSTream, specificând următorii parametri:

Var MediaSTReamconstrans \u003d (Audio: False, Video: (obligatoriu: (ChromeMediaSource: "Ecran"), opțional :));

Pentru a accesa cu succes ecranul, trebuie efectuate mai multe condiții:

• activați steagul screenshot în getUturmedia () în Chrome: // Steaguri /, Chrome: // Steaguri /;
• fișierul sursă trebuie să fie descărcat de HTTPS (Originea SSL);
• fluxul audio nu trebuie solicitat;
• nu ar trebui să existe mai multe solicitări într-o filă de browser.

Biblioteci pentru WebRTC.

Deși WebRTC nu este de asemenea finalizat, există deja mai multe biblioteci bazate pe aceasta. JSSIP este conceput pentru a crea splo-uri moi de browser care lucrează cu switch-uri SIP, cum ar fi asteriscul și Camalio. Peerjs va simplifica crearea rețelelor P2P pentru schimbul de date, iar Holla va reduce domeniul de aplicare necesar pentru comunicarea P2P de la browsere.

Node.js și socket.io.

Pentru a organiza schimbul de candidați SDP și gheață între cele două RTCpeerconnection prin rețea, utilizați node.js cu modulul socket.io.

Instalarea celei mai recente versiuni stabile a NODE.JS (pentru Debian / Ubuntu) descrisă

$ sudo apt-get-get instalare Python-software-proprietăți Python g ++ face $ sudo add-apt-repository PPA: chris-lea / node.js $ sudo apt-get update $ sudo apt-get instalare nodejs

Instalarea pentru alte sisteme de operare este descrisă

Verifica:

$ Eco "sys \u003d necesită" sys.puts ("mesaj de testare"); " \u003e NODETEST1.JS $ NODEJS NODETEST1.JS

Folosind NPM (Manager de pachete NODE), instalați socket.io și un modul expres suplimentar:

$ Npm install socket.io exprima

Verificați prin crearea unui fișier NODETEST2.JS pentru partea serverului:

$ Nano Nodetest2.js Var App \u003d necesită ("Express") (), server \u003d necesită ("http"). CreateServer (aplicație), io \u003d necesită ("socket.io"). Ascultați (server); Server.lusten (80); // Dacă portul 80 este GRATUIT la App.Get ("/", funcția (REQ, RES) (// atunci când accesează pagina Res.SendFile Root (__ Dirname + "/nodest2.html"); // renunță la un Fișier html)); io.sockets.on ("conexiune", funcție (soclu) (// când conectați socket.emit ("eveniment server" (salut: "lume")); // trimite mesajul socket.on ("eveniment client" , Funcție (date) (// declară un handler de evenimente la primirea unui mesaj de la consola clientului (date);));));

Și nodest2.html pentru partea clientului:

$ nano nodestest2.html.

Porniți serverul:

$ sudo nodejs nodetest2.js

Și deschideți http: // localhost: 80 pagină (dacă rulează local pe portul 80) din browser. Dacă totul are succes, în consola JavaScript din browser, vom vedea schimbul de evenimente între browser și server când este conectat.

Schimbul de informații între RTCPEERCONNECTY prin prize web

Partea clientului

Salvați exemplul nostru principal (RTCDemO3.HTML) sub noul nume RTCDemo4.html. Conectați biblioteca socket.io din element:

Și la începutul scriptului JavaScript - Conectați-vă la prizele web:

Var socly \u003d io.connect ("http: // localhost");

Voi înlocui apelul direct al funcțiilor unui alt participant la trimiterea acestuia prin prize web:

Funcție creayOffer_Success (desc); socket.emit ("oferta", desc), ...) Funcție PC2_CreateAnswer_success (Desc) (... // PC1.SetreRremotededesction (desc); priză ("Răspuns", Desc);) funcția PC1_oniceCacandad (eveniment) (... // pc2.addicandatul (noul RTCecceCandidat (Event.Candidat); Socket.Emit ("ICE1", Event.Candidat); ..) ... // PC1.addicandatul (noul RTCICECADADIDE (Event.Candidat); Socket.Emit ("ICE2", Eveniment.Candidat); ...)

În funcția Hangup (), în loc de un apel direct pentru funcțiile celui de-al doilea participant, permiteți-ne să dau un mesaj prin prize web:

Funcția BTnhangupClick () (... // Remotevideo2.src \u003d ""; PC2.C2.CLOSE (); PC2 \u003d null; socket.emit ("Hangup", ());)

Și adăugați manageri de primire a mesajelor:

Socket.on ("ofertă", funcție (date) ("socket.on (" ofertă "):", date); PC2_ReceiveDOffer (date);)); Socket.on ("Răspuns", funcție (date) (e console.log ("socket.on": ", date); pc1.setremotedescription (date);)); Socket.on ("ICE1", funcția ("socket.on" ("ICE1"): ", date); PC2.addicandad (noul RTCICECADADIDE (date));)); Socket.on ("ICE2", funcția ("socket.on" ("ICE2"): ", date); PC1.addicandad (noul RTCiceCandidat (date));)); Socket.on ("Hangup", funcția ("consola.log" ("socket.on (" hangup "):", date); la distanțăvideo2.src \u003d "; PC2.Close (); PC2 \u003d null;)) ;

Partea serverului

Pe partea serverului, salvați fișierul NODETEST2 sub noul nume rtcest4.js și în interiorul funcției io.sockets.on ("conexiune", funcție (soclu) (...) Adăugați recepție și trimiterea mesajelor clienților:

Socket.on ("Ofertă", funcție (date) (// la primirea mesajului "Ofertă", // Deoarece conexiunea clientului în acest exemplu este doar una, // trimite un mesaj înapoi prin același soclu socket.emit ("Ofertă", date); // dacă ar fi necesar să trimiteți un mesaj pe toate conexiunile, // în plus față de expeditor: // soke.broadcast.emit ("ofertă", date);)); socket.on ("răspuns", funcție (date) (socket.emit ("răspuns", date);));); socket.on ("ICE1", funcție (date) (socket.emit ("ICE1", date);)); socket.on ("ICE2", funcția (date) (socket.emit ("ICE2", date);)); socket.on ("Hangup", funcție (date) (socket.emit ("Hangup", date);));

În plus, veți schimba numele fișierului HTML:

// res.sendfile (__ dirname + "/nodetest2.html"); // dați fișierul html res.sendfile (__ dirname + "/rtctcest4.html");

Server de pornire:

$ sudo nodejs nodetest2.js

În ciuda faptului că codul celor doi clienți se efectuează în același marcaj al browserului, toată interacțiunea dintre participanții din exemplul nostru este pe deplin efectuată prin rețea și participanții "diseminează" nu mai necesită dificultăți speciale. Cu toate acestea, ceea ce am făcut a fost, de asemenea, foarte simplu - aceste tehnologii și sunt bune pentru simplitatea lor de utilizare. Lăsați uneori înșelătorii. În special, nu vom uita că, fără servere de asistență, exemplul nostru nu va putea să lucreze în prezența traducerilor și ecranelor de rețea.

Concluzie

Exemplul rezultat este foarte condiționat, dar dacă aveți un pic de manipulatoare de eveniment universal, astfel încât acestea să nu difere de la apelarea și numitul partidului, în loc de două obiecte PC1 și PC2 pentru a face ca array RTCPEERCONNECONS să se dezvolte dinamică și să îndepărteze elementele

Se poate presupune că este foarte curând mulțumită WebRTC, va fi o lovitură de stat nu numai în prezentarea legăturilor vocale și video, ci și în modul în care percepem Internetul în ansamblu. WebRTC este poziționat nu numai ca o tehnologie pentru apelurile din browser către browser, ci și ca o tehnologie de comunicații în timp real. Apel video, pe care l-am dezasamblat, doar o mică parte a opțiunilor posibile de utilizare. Deja există exemple de difuzare a ecranului (screensering) și colaborare și chiar rețelei P2P de livrare a conținutului bazat pe browsere folosind RTCDatachannel.