Skambinimo iš naršyklės technologijos egzistuoja jau daug metų: Java, ActiveX, Adobe Flash... Per pastaruosius kelerius metus tapo aišku, kad įskiepiai ir kairiarankės virtualios mašinos neblizga patogumu (kodėl turėčiau išvis ką nors įdiegti?) ir, svarbiausia, saugumas . Ką daryti? Yra išėjimas!
Dar visai neseniai IP tinklai IP telefonijai ar vaizdo įrašams naudojo kelis protokolus: SIP, labiausiai paplitęs protokolas, H.323 ir MGCP, atsirandantis vietoje, Jabber/Jingle (naudojamas Gtalk), pusiau atviras Adobe RTMP* ir, žinoma, , uždarė Skype. „Google“ inicijuotas WebRTC projektas bando pakeisti IP ir žiniatinklio telefonijos pasaulį, padarydamas nereikalingus visus programinius telefonus, įskaitant „Skype“. WebRTC ne tik diegia visas komunikacijos galimybes tiesiai naršyklės viduje, kuri dabar įdiegta beveik kiekviename įrenginyje, bet ir vienu metu bando išspręsti bendresnę naršyklės vartotojų komunikacijos problemą (keitimasis įvairiais duomenimis, ekrano transliavimas, bendradarbiavimas su dokumentais ir daug daugiau).
WebRTC žiniatinklio kūrėjo požiūriuŽiniatinklio kūrėjo požiūriu, WebRTC susideda iš dviejų pagrindinių dalių:
- medijos srautų valdymas iš vietinių išteklių (kameros, mikrofono ar vietinio kompiuterio ekrano) įgyvendinamas navigator.getUserMedia metodu, kuris grąžina MediaStream objektą;
- lygiavertis ryšys tarp įrenginių, generuojančių medijos srautus, įskaitant ryšio metodų apibrėžimą ir tiesioginį jų perdavimą – RTCPeerConnection objektai (skirti garso ir vaizdo srautams siųsti ir priimti) ir RTCDataChannel (skirti duomenims siųsti ir gauti iš naršyklės).
Išsiaiškinsime, kaip organizuoti paprastą kelių vartotojų vaizdo pokalbį tarp naršyklių, pagrįstų WebRTC, naudojant žiniatinklio lizdus. Pradėsime eksperimentuoti su „Chrome“ / „Chromium“, kaip pažangiausiomis WebRTC naršyklėmis, nors „Firefox 22“, išleista birželio 24 d., jas beveik pasivijo. Reikia pasakyti, kad standartas dar nepriimtas, o API gali keistis nuo versijos iki versijos. Visi pavyzdžiai buvo išbandyti naudojant „Chromium 28“. Paprastumo dėlei neprižiūrėsime kodo švarumo ir kelių naršyklių suderinamumo.
MediaStreamPirmasis ir paprasčiausias WebRTC komponentas yra „MediaStream“. Tai suteikia naršyklei prieigą prie medijos srautų iš vietinio kompiuterio kameros ir mikrofono. „Chrome“ tam reikia iškviesti funkciją navigator.webkitGetUserMedia() (kadangi standartas dar nėra baigtas, visos funkcijos yra su priešdėliu, o „Firefox“ ta pati funkcija vadinama navigator.mozGetUserMedia()). Kai paskambinsite, vartotojo bus paprašyta leisti pasiekti kamerą ir mikrofoną. Tęsti pokalbį bus galima tik vartotojui davus sutikimą. Šiai funkcijai kaip parametrai perduodami reikiamo medijos srauto ir dviejų atgalinio skambučio funkcijų parametrai: pirmasis bus iškviestas, jei bus sėkmingai gauta prieiga prie kameros/mikrofono, antrasis – įvykus klaidai. Pirmiausia sukurkime HTML failą rtctest1.html su mygtuku ir elementu:
WebRTC – pirmasis pristatymo vaizdo įrašas (aukštis: 240 piks.; plotis: 320 piks.; kraštinė: 1 piks. vientisai pilka; ) getUserMedia
„Microsoft“ nebūtų „Microsoft“, jei ji nedelsdama nereaguotų į „Google“ iniciatyvą išleisdama savo nesuderinamą nestandartinę parinktį, pavadintą CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Nors ir taip nedidelė IE dalis ir toliau mažėja, „Skype“ vartotojų skaičius suteikia „Microsoft“ vilčių išstumti „Google“ ir galima daryti prielaidą, kad šis standartas bus naudojamas „Skype“ naršyklės versijoje. Google standartas visų pirma orientuotas į ryšį tarp naršyklių; tuo pačiu metu didžioji balso srauto dalis vis dar išlieka įprastame telefono tinkle, o vartai tarp jo ir IP tinklų reikalingi ne tik dėl naudojimosi patogumo ar greitesnio paskirstymo, bet ir kaip pinigų gavimo priemonė, kuri leis daugiau žaidėjų juos plėtoti. Atsiradęs dar vienas standartas gali ne tik sukelti nemalonų kūrėjų poreikį palaikyti dvi nesuderinamas technologijas vienu metu, bet ir ateityje suteikti vartotojui platesnį galimo funkcionalumo ir turimų techninių sprendimų pasirinkimą. Palauk ir pamatysi.
Įgalinamas vietinis srautasHTML failo žymose nurodykime visuotinį medijos srauto kintamąjį:
Var localStream = null;
Pirmasis „getUserMedia“ metodo parametras turi nurodyti prašomo medijos srauto parametrus – pavyzdžiui, tiesiog įgalinkite garsą arba vaizdo įrašą:
Var streamConstraints = ("garsas": tiesa, "vaizdo įrašas": tiesa); // Prašyti prieigos prie garso ir vaizdo
Arba nurodykite papildomus parametrus:
Var streamConstraints = ( "garsas": tiesa, "vaizdo įrašas": ( "privalomas": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "pasirenkamas": ) );
Antrasis getUserMedia metodo parametras turi būti perduotas atgalinio skambinimo funkcijai, kuri bus iškviesta, jei ji bus sėkminga:
Funkcija getUserMedia_success(stream) ( console.log("getUserMedia_success():", srautas); localVideo1.src = URL.createObjectURL(stream); // Prijunkite medijos srautą prie HTML elemento localStream = stream; // ir išsaugokite globaliame kintamajame tolesniam naudojimui )
Trečiasis parametras yra atgalinio skambinimo funkcija, klaidų tvarkytuvas, kuris bus iškviestas įvykus klaidai
Funkcija getUserMedia_error(error) ( console.log("getUserMedia_error():", klaida); )
Tikrasis getUserMedia metodo iškvietimas yra prašymas pasiekti mikrofoną ir kamerą, kai paspaudžiamas pirmasis mygtukas
Funkcija getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )
Neįmanoma pasiekti medijos srauto iš vietoje atidaryto failo. Jei bandysime tai padaryti, gausime klaidą:
NavigatorUserMediaError (kodas: 1, PERMISSION_DENIED: 1)"
Įkelkime gautą failą į serverį, atidarykime jį naršyklėje ir, atsakydami į pasirodžiusį užklausą, leisime prieiti prie kameros ir mikrofono.
Galite pasirinkti įrenginius, prie kurių „Chrome“ turės prieigą, skiltyje „Nustatymai“, „Rodyti išplėstinių nustatymų nuorodą“, „Privatumo“ skiltis, „Turinio“ mygtukas. „Firefox“ ir „Opera“ naršyklėse įrenginiai parenkami iš išskleidžiamojo sąrašo tiesiogiai, kai prieiga leidžiama.
Naudojant HTTP protokolą, leidimo bus prašoma kiekvieną kartą, kai bus pasiekiamas medijos srautas, kai puslapis bus įkeltas. Perjungus į HTTPS, užklausa bus rodoma vieną kartą, tik pirmą kartą prisijungus prie medijos srauto.
Atkreipkite dėmesį į pulsuojantį apskritimą žymės piktogramoje ir fotoaparato piktogramą dešinėje adreso juostos pusėje:
RTCMediaConnectionRTCMediaConnection yra objektas, skirtas sukurti ir perduoti žiniasklaidos srautus tinkle tarp dalyvių. Be to, šis objektas yra atsakingas už medijos seanso aprašo (SDP) generavimą, informacijos apie ICE kandidatus, skirtus NAT arba ugniasienių (vietinių ir naudojant STUN) perėjimą, gavimą ir sąveiką su TURN serveriu. Kiekvienas dalyvis turi turėti vieną RTCMediaConnection vienam ryšiui. Medijos srautai perduodami naudojant šifruotą SRTP protokolą.
TURN serveriaiYra trijų tipų ICE kandidatai: pagrindinis, srflx ir relay. Host yra informacija, gauta vietoje, srflx - kaip mazgas atrodo išoriniam serveriui (STUN), o relay - informacija, skirta srautui perduoti per TURN serverį. Jei mūsų mazgas yra už NAT, tada kandidatai prie pagrindinio kompiuterio turės vietinius adresus ir bus nenaudingi, srflx kandidatai padės tik su tam tikro tipo NAT, o perdavimas bus paskutinė viltis perduoti srautą per tarpinį serverį.
ICE kandidato į pagrindinio kompiuterio tipą pavyzdys su adresu 192.168.1.37 ir prievadu udp/34022:
A=kandidatas:337499441 2 udp 2113937151 192.168.1.37 34022 tipo prieglobos karta 0
Bendras formatas STUN/TURN serveriams nurodyti:
Var serveriai = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "slaptažodis") ]);
Internete yra daug viešųjų STUN serverių. Pavyzdžiui, yra didelis sąrašas. Deja, jie išsprendžia per mažai problemų. Viešųjų TURN serverių, skirtingai nei STUN, praktiškai nėra. Taip yra dėl to, kad TURN serveris eina per medijos srautus, kurie gali žymiai apkrauti tiek tinklo kanalą, tiek patį serverį. Todėl lengviausias būdas prisijungti prie TURN serverių yra jį įsidiegti patiems (aišku, reikės viešo IP). Iš visų serverių, mano nuomone, geriausias yra rfc5766-turn-server. Yra net paruoštas „Amazon EC2“ vaizdas.
Su TURN ne viskas yra taip gerai, kaip norėtume, tačiau vyksta aktyvus vystymasis, ir norisi tikėtis, kad po kurio laiko WebRTC, jei neprilygs Skype adresų vertimo (NAT) ir ugniasienių kokybe. , yra bent jau pastebimas ateis arčiau.
RTCMediaConnection reikalingas papildomas valdymo informacijos apsikeitimo mechanizmas ryšiui užmegzti – nors ir generuoja šiuos duomenis, tačiau jų neperduoda, o perdavimas kitiems dalyviams turi būti įgyvendintas atskirai.
Perkėlimo metodo pasirinkimas priklauso kūrėjui – bent jau rankiniu būdu. Kai tik įvyks apsikeitimas reikalingais duomenimis, RTCMediaConnection automatiškai įdiegs medijos srautus (jei įmanoma, žinoma).
pasiūlymo-atsakymo modelisNorint nustatyti ir pakeisti medijos srautus, naudojamas pasiūlymo/atsakymo modelis (aprašytas RFC3264) ir SDP (seanso aprašo protokolas). Juos taip pat naudoja SIP protokolas. Šiame modelyje yra du agentai: Siūlytojas – tas, kuris sugeneruoja seanso SDP aprašą, kad sukurtų naują arba pakeistų esamą (Offer SDP), ir atsakiklis – tas, kuris gauna seanso SDP aprašą iš kitą agentą ir atsako pateikdamas savo seanso aprašymą (Answer SDP). Tuo pačiu metu specifikacijai reikalingas aukštesnio lygio protokolas (pavyzdžiui, SIP arba nuosavas žiniatinklio lizdas, kaip mūsų atveju), kuris yra atsakingas už SDP perdavimą tarp agentų.
Kokius duomenis reikia perduoti tarp dviejų RTCMediaConnections, kad jie galėtų sėkmingai sukurti medijos srautus:
- Pirmasis prisijungimą inicijuojantis dalyvis sudaro Pasiūlymą, kuriame perduoda SDP duomenų struktūrą (tas pats protokolas tam pačiam tikslui naudojamas SIP), apibūdinančią galimas medijos srauto, kurį jis ruošiasi perduoti, charakteristikas. Šis duomenų blokas turi būti perduotas antrajam dalyviui. Antrasis dalyvis suformuoja atsakymą su savo SDP ir išsiunčia jį pirmajam.
- Tiek pirmasis, tiek antrasis dalyviai atlieka galimų ICE kandidatų nustatymo procedūrą, kurios pagalba antrasis dalyvis gali perduoti jiems medijos srautą. Kai kandidatai nustatomi, informacija apie juos turėtų būti perduota kitam dalyviui.
Formavimo pasiūlymas Norėdami sukurti pasiūlymą, mums reikia dviejų funkcijų. Pirmasis bus iškviestas, jei jis bus sėkmingai suformuotas. Antrasis createOffer() metodo parametras yra atgalinio skambinimo funkcija, iškviečiama ją vykdant įvykus klaidai (jei vietinė gija jau yra).
Be to, reikalingos dvi įvykių tvarkyklės: onicecandidate apibrėžiant naują ICE kandidatą ir onaddstream, kai jungiamas medijos srautas iš tolimosios pusės. Grįžkime prie savo bylos. Pridėkime dar vieną prie HTML po eilučių su elementais:
sukurti Pasiūlymą
Ir po eilutės su elementu (ateičiai):
Taip pat JavaScript kodo pradžioje paskelbsime visuotinį RTCPeerConnection kintamąjį:
Var pc1;
Iškviesdami RTCPeerConnection konstruktorių, turite nurodyti STUN/TURN serverius. Daugiau informacijos apie juos rasite šoninėje juostoje; kol visi dalyviai yra tame pačiame tinkle, jie nėra būtini.
Var serveriai = null;
Pasiūlymo SDP rengimo parametrai
Var offerConstraints = ();
Pirmasis CreateOffer() metodo parametras yra atgalinio skambinimo funkcija, iškviečiama sėkmingai suformavus pasiūlymą
Funkcija pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Nustatyti SDP, generuoja OffConnection naudojant setLocalDescription metodą // Kai tolimoji pusė siunčia savo Answer SDP, ją reikės nustatyti naudojant setRemoteDescription metodą // Kol nebus įdiegta antroji pusė, nieko nedarome // pc2_receivedOffer(desc);
Antrasis parametras yra atgalinio ryšio funkcija, kuri bus iškviesta įvykus klaidai
Funkcija pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )
Ir paskelbkime atgalinio ryšio funkciją, kuriai bus perduoti ICE kandidatai, kai jie bus nustatyti:
Funkcija pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Kol neįdiegta antroji pusė, nieko nedarome // pc2.addIceCandidate(new RTCIceCandidate(event.candidate) ) )
Taip pat atgalinio skambučio funkcija, skirta pridėti medijos srautą iš tolimos pusės (ateičiai, nes kol kas turime tik vieną RTCPeerConnection):
Funkcija pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )
Kai spustelėsite mygtuką „sukurti pasiūlymą“, sukursime RTCPeerConnection, nustatysime onicecandidate ir onaddstream metodus ir paprašysime sudaryti pasiūlymo SDP, iškviesdami CreateOffer() metodą:
Funkcija createOffer_click() ( console.log("createOffer_click()"); pc1 = naujas webkitRTCPeerConnection(servers); // Sukurti RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Atšaukimo funkcija, skirta ICE kandidatams apdoroti pc1.onaddonad =dstream; Atšaukimo funkcija iškviečiama, kai pasirodo medijos srautas iš toli. prašyti sudaryti Offer pc1_createOffer_success , pc1_createOffer_error, offerConstraints)
Išsaugokime failą kaip rtctest2.html, įkelkime į serverį, atidarykime naršyklėje ir pažiūrėkime konsolėje kokie duomenys generuojami jos veikimo metu. Antrasis vaizdo įrašas dar nepasirodys, nes yra tik vienas dalyvis. Prisiminkime, kad SDP yra medijos seanso parametrų aprašymas, galimi kodekai, medijos srautai ir ICE kandidatai yra galimi prisijungimo prie konkretaus dalyvio variantai.
Atsakymo SDP formavimas ir ICE kandidatų mainaiTiek Offer SDP, tiek kiekvienas iš ICE kandidatų turi būti perkeltas į kitą pusę ir ten, juos gavęs, RTCPeerConnection iškviečia metodus setRemoteDescription pasiūlymo SDP ir addIceCandidate kiekvienam ICE kandidatui, gautam iš tolimosios pusės; panašiai priešinga kryptimi atsakymo SDP ir nuotolinio ICE kandidatams. Pats Atsakymas SDP formuojamas panašiai kaip ir Pasiūlymas; skirtumas tas, kad iškviečiamas ne createOffer, o createAnswer metodas, o prieš tai RTCPeerConnection metodas setRemoteDescription perduodamas iš skambinančiojo gautam Offer SDP.
Pridėkite dar vieną vaizdo elementą prie HTML:
Ir pasaulinis antrojo RTCPeerConnection kintamasis pagal pirmojo deklaraciją:
Var pc2;
Apdorojamas pasiūlymas ir atsakymas SDPAtsakymo SDP formavimas labai panašus į pasiūlymą. Atšaukimo funkcijoje, iškviestoje sėkmingai suformavus atsakymą, panašiai kaip pasiūlymas, pateiksime vietinį aprašymą ir gautą atsakymo SDP perduosime pirmajam dalyviui:
Funkcija pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )
Atgalinio skambinimo funkcija, iškviečiama generuojant atsakymą įvykus klaidai, yra visiškai panaši į pasiūlymą:
Funkcija pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", error); )
Atsakymo SDP formavimo parametrai:
Var answerConstraints = ( "privalomas": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );
Kai antrasis dalyvis gaus Pasiūlymą, mes sukursime RTCPeerConnection ir suformuosime atsakymą taip pat, kaip ir pasiūlyme:
Funkcija pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Sukurkite RTCPeerConnection objektą antrajam dalyviui taip pat kaip ir pirmajam pc2 = naujas webkitRTCPeerConnection(servers); pc2.onicecandidate = candidate = pc2 // Nustatyti įvykių tvarkyklę, kai ji pasirodo pc2.onaddstream = pc_onaddstream // Kai pasirodo srautas, prijunkite jį prie HTML pc2.addStream (localStream) // Perkelkite vietinės medijos srautą (mūsų pavyzdyje – antrąjį); dalyvis turi tą patį kaip ir pirmasis) // Dabar, kai bus paruoštas antrasis RTCPeerConnection, perduosime jam gautą Offer SDP (vietinį srautą perdavėme pirmajam) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Prašyti antrojo ryšio sugeneruoti duomenis atsakymo pranešimui pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints )
Norėdami perkelti pasiūlymo SDP iš pirmojo dalyvio į antrąjį mūsų pavyzdyje, panaikinkime jo komentarą pc1 funkcijoje sukurti Pasiūlymą sėkmės() skambučio linija:
Pc2_gautasPasiūlymas(desc);
Norėdami įgyvendinti ICE kandidatų apdorojimą, pirmojo dalyvio ICE kandidato parengties įvykių tvarkyklėje pc1_onicecandidate() panaikinkime jo perkėlimą į antrąjį:
Pc2.addIceCandidate(naujas RTCIceCandidate(įvykis.kandidatas));
Antrojo dalyvio ICE kandidato parengties įvykių tvarkytuvas yra panašus į pirmąjį:
Funkcija pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )
Atgalinio skambinimo funkcija, skirta pridėti medijos srautą iš pirmojo dalyvio:
Funkcija pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )
Ryšio nutraukimasPrie HTML pridėkime dar vieną mygtuką
Pakabinti
Ir ryšio nutraukimo funkcija
Funkcija btnHangupClick() ( // Atjunkite vietinį vaizdo įrašą nuo HTML elementų, sustabdykite vietinės medijos srautą, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Kiekvienam dalyviui išjunkite vaizdo įrašą iš HTML elementus, uždarykite ryšį, nustatykite rodyklę = null remoteVideo1.src = "" pc1 = null;
Išsaugokime kaip rtctest3.html, įkelkime į serverį ir atidarykime naršyklėje. Šis pavyzdys įgyvendina dvipusį medijos srautų perdavimą tarp dviejų RTCPeerConnections tame pačiame naršyklės skirtuke. Norint organizuoti Pasiūlymo ir atsakymo SDP, ICE kandidatų ir kitos informacijos apsikeitimą tarp dalyvių ir kita informacija per tinklą, o ne tiesioginio skambinimo procedūromis, reikės įgyvendinti apsikeitimą tarp dalyvių, naudojant tam tikrą transportą, mūsų atveju - internetinius lizdus.
Ekrano transliacijaFunkcija getUserMedia taip pat gali užfiksuoti ekraną ir transliuoti kaip MediaStream, nurodydama šiuos parametrus:
Var mediaStreamConstraints = ( garsas: klaidingas, vaizdo įrašas: ( privalomas: ( chromeMediaSource: "screen"), pasirenkamas: ) );
Norint sėkmingai pasiekti ekraną, turi būti įvykdytos kelios sąlygos:
- įgalinti ekrano kopijos vėliavėlę getUserMedia() chrome://flags/,chrome://flags/;
- šaltinio failas turi būti atsiųstas per HTTPS (SSL kilmė);
- garso srauto nereikėtų prašyti;
- Viename naršyklės skirtuke negalima vykdyti kelių užklausų.
Nors WebRTC dar nebaigtas, jau atsirado kelios juo pagrįstos bibliotekos. JsSIP skirtas sukurti naršyklės pagrindu veikiančius programinius telefonus, veikiančius su SIP jungikliais, tokiais kaip Asterisk ir Camalio. „PeerJS“ leis lengviau kurti P2P tinklus duomenų mainams, o „Holla“ sumažins P2P ryšiui iš naršyklių reikalingą plėtrą.
Node.js ir socket.ioNorėdami organizuoti SDP ir ICE kandidatų apsikeitimą tarp dviejų RTCPeerConnections per tinklą, naudojame Node.js su socket.io moduliu.
Aprašytas naujausios stabilios Node.js versijos (skirtos Debian/Ubuntu) diegimas
$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs
Aprašytas kitų operacinių sistemų diegimas
Patikrinkime:
$ echo "sys=require("util"); sys.puts("Test pranešimas");" > nodetest1.js $ nodejs nodetest1.js
Naudodami npm (Node Package Manager) įdiegsime socket.io ir papildomą greitąjį modulį:
$ npm įdiekite socket.io express
Išbandykime tai sukurdami nodetest2.js failą serverio pusei:
$ nano nodetest2.js var app = reikalauti("express")() , serveris = reikalauti("http").createServer(app) , io = reikalauti("socket.io").klausite(serveris); serveris.klausytis(80); // Jei 80 prievadas nemokamas app.get("/", funkcija (req, res) ( // Kai pasiekiate šakninį puslapį res.sendfile(__dirname + "/nodetest2.html"); // išsiųskite HTML failą ) ) ; io.sockets.on("ryšys", funkcija (socket) ( // Jungiantis socket.emit("serverio įvykis", ( labas: "world" )); // siųsti žinutę socket.on("kliento įvykis" , funkcija (duomenys) ( // ir paskelbti įvykių tvarkyklę, kai gaunamas pranešimas iš kliento konsolės.log(data); ));
Ir nodetest2.html kliento pusei:
$ nano nodetest2.html var socket = io.connect("/"); // Websocket serverio URL (šakninis serverio puslapis, iš kurio buvo įkeltas puslapis) socket.on("serverio įvykis", funkcija (duomenys) ( console.log(data); socket.emit("kliento įvykis", () "vardas": "vertė" ));
Pradėkime serverį:
$ sudo nodejs nodetest2.js
ir naršyklėje atidarykite puslapį http://localhost:80 (jei veikia vietoje per 80 prievadą). Jei viskas pavyks, naršyklės JavaScript pulte matysime įvykių apsikeitimą tarp naršyklės ir serverio prisijungus.
Keitimasis informacija tarp RTCPeerConnection per žiniatinklio lizdus Kliento dalisIšsaugokime pagrindinį pavyzdį (rtcdemo3.html) nauju pavadinimu rtcdemo4.html. Į elementą įtraukkime socket.io biblioteką:
Ir „JavaScript“ scenarijaus pradžioje - prisijungimas prie interneto lizdų:
Var socket = io.connect("http://localhost");
Tiesioginį skambutį pakeiskime kito dalyvio funkcijomis, išsiųsdami jam žinutę per žiniatinklio lizdus:
Funkcija createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("pasiūlymas", desc); ... ) funkcija pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("atsakymas", desc); funkcija pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. ) funkcija pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )
Funkcijoje hangup() užuot tiesiogiai iškvietę antrojo dalyvio funkcijas, mes perduosime pranešimą per žiniatinklio lizdus:
Funkcija btnHangupClick() (... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("pakabinti", ()); )
Ir pridėkite pranešimų gavimo tvarkytojus:
Socket.on("pasiūlymas", funkcija (duomenys) ( console.log("socket.on("pasiūlymas"):", data); pc2_receivedOffer(data); )); socket.on("atsakymas", funkcija (duomenys) (е console.log("socket.on("atsakymas"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", funkcija (duomenys) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", funkcija (duomenys) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("pakabinti", funkcija (duomenys) ( console.log("socket.on("pakabinti"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );
Serverio dalisServerio pusėje išsaugokite failą nodetest2 nauju pavadinimu rtctest4.js, o funkcijos io.sockets.on("ryšys", funkcija (socket) (... ) viduje pridėsime kliento pranešimų priėmimą ir siuntimą:
Socket.on("pasiūlymas", funkcija (duomenys) ( // Kai gauname "pasiūlymo" pranešimą, // kadangi šiame pavyzdyje yra tik vienas kliento ryšys, // mes išsiųsime pranešimą atgal per tą patį lizdą .emit("pasiūlymas" , data ), // Jei reikėtų persiųsti pranešimą per visus ryšius // išskyrus siuntėją: // soket.broadcast.emit("pasiūlymas", duomenys )); socket.on("atsakymas", funkcija (duomenys) ( socket.emit("atsakymas, duomenys); )); socket.on("ice1", funkcija (duomenys) ( socket.emit("ice1", data); )); socket.on("ice2", funkcija (duomenys) ( socket.emit("ice2", data); )); socket.on("pakabinti", funkcija (duomenys) ( socket.emit("pakabinti", duomenys); ));
Be to, pakeiskime HTML failo pavadinimą:
// res.sendfile(__dirname + "/nodetest2.html"); // Siųsti HTML failą res.sendfile(__dirname + "/rtctest4.html");
Serverio paleidimas:
$ sudo nodejs nodetest2.js
Nepaisant to, kad abiejų klientų kodas vykdomas tame pačiame naršyklės skirtuke, visa sąveika tarp dalyvių mūsų pavyzdyje yra visiškai vykdoma tinkle ir dalyvių „atskyrimas“ nereikalauja jokių ypatingų sunkumų. Tačiau tai, ką padarėme, taip pat buvo labai paprasta – šios technologijos yra geros, nes jas paprasta naudoti. Net jei kartais ir apgaulinga. Ypač nepamirškime, kad be STUN/TURN serverių mūsų pavyzdys neveiks esant adresų vertimui ir ugniasienėms.
IšvadaGautas pavyzdys yra labai įprastas, tačiau jei šiek tiek universalizuojate įvykių tvarkykles, kad jos nesiskirtų tarp skambinančiojo ir skambinančiojo šalies, vietoj dviejų objektų pc1 ir pc2 sukurkite RTCPeerConnection masyvą ir įgyvendinkite dinaminį elementų kūrimą ir pašalinimą. , tada gausite visiškai tinkamą vaizdo pokalbį. Su WebRTC nėra susijusios specialios specifikos, o paprasto vaizdo pokalbio keliems dalyviams pavyzdys (taip pat visų straipsnyje pateiktų pavyzdžių tekstai) yra diske, kuris pateikiamas kartu su žurnalu. Tačiau internete jau galima rasti daug gerų pavyzdžių. Visų pirma, rengiant straipsnį buvo panaudota: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.
Galima daryti prielaidą, kad labai greitai WebRTC dėka įvyks revoliucija ne tik mūsų supratimu apie balso ir vaizdo ryšius, bet ir tai, kaip mes suvokiame internetą kaip visumą. „WebRTC“ yra ne tik kaip skambučių iš naršyklės į naršyklę technologija, bet ir kaip realaus laiko komunikacijos technologija. Vaizdo komunikacija, kurią aptarėme, yra tik maža dalis galimų jo naudojimo variantų. Jau yra ekrano transliavimo ir bendradarbiavimo pavyzdžių ir net naršyklės pagrindu sukurtas P2P turinio pristatymo tinklas, naudojant RTCDataChannel.
Šiandien WebRTC yra „karšta“ garso ir vaizdo transliavimo naršyklėse technologija. Konservatyvios technologijos, tokios kaip HTTP Streaming ir Flash, labiau tinka platinti įrašytą turinį (vaizdo įrašą pagal pareikalavimą) ir realiu laiku bei internetinėmis transliacijomis gerokai nusileidžia WebRTC, t.y. kur reikalingas minimalus vaizdo įrašo delsos laikas, kad žiūrovai matytų, kas vyksta „gyvai“.
Kokybiško ryšio realiuoju laiku galimybė kyla iš pačios WebRTC architektūros, kur vaizdo srautams transportuoti naudojamas UDP protokolas, kuris yra standartinis vaizdo perdavimo su minimaliais vėlavimais pagrindas ir plačiai naudojamas realaus laiko ryšio sistemose.
Ryšio delsa yra svarbi internetinio transliavimo sistemose, internetiniuose seminaruose ir kitose programose, kurioms reikalingas interaktyvus bendravimas su vaizdo šaltiniu, galutiniais vartotojais ir reikalingas sprendimas.
Kita gera priežastis išbandyti WebRTC yra ta, kad tai tikrai tendencija. Šiandien kiekviena Android Chrome naršyklė palaiko šią technologiją, kuri garantuoja milijonus įrenginių, paruoštų žiūrėti transliaciją neįdiegiant jokios papildomos programinės įrangos ar konfigūracijų.
Norėdami išbandyti WebRTC technologiją ir pradėti joje paprastą internetinę transliaciją, panaudojome „Flashphoner WebRTC Media & Broadcasting Server“ serverio programinę įrangą. Funkcijose nurodoma galimybė transliuoti WebRTC srautus „vienas su daugeliu“ režimu, taip pat IP kamerų ir vaizdo stebėjimo sistemų palaikymas per RTSP protokolą; Šioje apžvalgoje mes sutelksime dėmesį į žiniatinklio žiniatinklio transliacijas ir jų funkcijas.
„WebRTC Media & Broadcasting Server“ diegimasKadangi nebuvo serverio versijos Windows sistemai ir nenorėjau diegti virtualios mašinos, tokios kaip VMWare+Linux, negalėjau išbandyti internetinių transliacijų savo namų Windows kompiuteryje. Norėdami sutaupyti laiko, nusprendėme pavyzdį naudoti debesyje prieglobą:
Tai buvo Centos x86_64 6.5 versija be jokios iš anksto įdiegtos programinės įrangos Amsterdamo duomenų centre. Taigi viskas, ką turime, yra serveris ir ssh prieiga prie jo. Tiems, kurie yra susipažinę su Linux konsolės komandomis, WebRTC serverio įdiegimas žada būti paprastas ir neskausmingas. Taigi, ką mes padarėme:
1. Atsisiųskite archyvą:
$wget https://site/download-wcs5-server.tar.gz
2. Išpakuokite:
$tar -xzf download-wcs5-server.tar.gz
3. Įdiekite:
$cd FlashphonerWebCallServer
Diegimo metu įveskite serverio IP adresą: XXX.XXX.XXX.XXX
4. Suaktyvinkite licenciją:
$cd /usr/local/FlashphonerWebCallServer/bin
$./activation.sh
5. Paleiskite WCS serverį:
$service žiniatinklio skambučių serverio paleidimas
6. Patikrinkite žurnalą:
$uodega – f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log
7. Patikrinkite, ar atlikti du procesai:
$ps aux | grep Flashphoner
Diegimo procesas baigtas.
WebRTC internetinių transliacijų testavimasIšbandyti transliacijas pasirodė paprastas dalykas. Be serverio, yra žiniatinklio klientas, kurį sudaro keliolika „Javascript“, HTML ir CSS failų ir kurį diegimo etape mes įdiegėme į /var/www/html aplanką. Vienintelis dalykas, kurį reikėjo padaryti, buvo įvesti serverio IP adresą į flashphoner.xml konfigūraciją, kad žiniatinklio klientas galėtų užmegzti ryšį su serveriu per HTML5 Websockets. Apibūdinkime testavimo procesą.
1. „Chrome“ naršyklėje atidarykite index.html bandomojo kliento puslapį:
2. Norėdami pradėti transliaciją, turite spustelėti mygtuką „Pradėti“ ekrano viduryje.
Prieš tai darydami, turite įsitikinti, kad internetinė kamera prijungta ir paruošta naudoti. Interneto kamerai nėra jokių specialių reikalavimų, pavyzdžiui, naudojome standartinę nešiojamajame kompiuteryje įmontuotą kamerą, kurios skiriamoji geba yra 1280x800.
„Chrome“ naršyklė tikrai paprašys prieigos prie kameros ir mikrofono, kad vartotojas suprastų, jog jo vaizdo įrašas bus išsiųstas į interneto serverį ir leis.
3. Sąsaja rodo sėkmingą vaizdo srauto transliaciją iš kameros į WebRTC serverį. Viršutiniame dešiniajame kampe indikatorius rodo, kad srautas eina į serverį, apatiniame kampe yra mygtukas „Stop“, kad sustabdytų vaizdo įrašo siuntimą.
Atkreipkite dėmesį į nuorodą žemiau esančiame laukelyje. Jame yra unikalus šio srauto identifikatorius, todėl visi gali prisijungti prie peržiūros. Tiesiog atidarykite šią nuorodą savo naršyklėje. Norėdami nukopijuoti jį į mainų sritį, spustelėkite mygtuką „Kopijuoti“.
Realiose programose, tokiose kaip internetiniai seminarai, paskaitos, vaizdo transliacijos internetu ar interaktyvioji televizija, kūrėjai turės platinti šį identifikatorių tam tikroms žiūrovų grupėms, kad jie galėtų prisijungti prie norimų srautų, tačiau tokia yra programos logika. „WebRTC Media & Broadcasting Server“ tam įtakos neturi, o tik platina vaizdo įrašą.
5. Ryšys užmezgamas ir žiūrovas ekrane mato srautą. Dabar jis gali nusiųsti nuorodą kam nors kitam, sustabdyti srauto grojimą arba įjungti viso ekrano režimą naudodamas apatiniame dešiniajame kampe esančius valdiklius.
Bandymų metu delsa atrodė tobula. Ping į duomenų centrą buvo apie 100 milisekundžių, o delsa buvo nematoma. Iš čia galime daryti prielaidą, kad tikrasis vėlavimas yra tas pats 100 plius ar minus kelios dešimtys milisekundžių buferio trukmei. Palyginti su „Flash“ vaizdo įrašu: tokiuose testuose „Flash“ elgiasi ne taip gerai, kaip „WebRTC“. Taigi, pajudinus ranką panašiame tinkle, judesį ekrane galima pamatyti tik po vienos ar dviejų sekundžių.
Kalbant apie kokybę, pastebime, kad kubus kartais galima atskirti pagal judesius. Tai atitinka VP8 kodeko prigimtį ir pagrindinį jo tikslą – užtikrinti priimtinos kokybės vaizdo ryšį realiuoju laiku ir be ryšio vėlavimų.
Serveris yra gana lengvas įdiegti ir konfigūruoti, kad jis nereikalauja jokių rimtų įgūdžių, išskyrus pažengusio vartotojo, kuris gali vykdyti komandas iš konsolės per ssh ir naudoti teksto rengyklę, žinių. Dėl to mums pavyko sukurti internetinę transliaciją „vienas su daugeliu“ tarp naršyklių. Papildomų žiūrovų prijungimas prie srauto taip pat nesukėlė problemų.
Transliacijos kokybė pasirodė gana priimtina internetiniams seminarams ir internetinėms transliacijoms. Vienintelis dalykas, dėl kurio kilo klausimų, buvo vaizdo raiška. Kamera palaiko 1280x800, tačiau bandomojo vaizdo raiška labai panaši į 640x480. Matyt, šį klausimą reikia išsiaiškinti su kūrėjais.
Vaizdo įrašas apie bandymo transliaciją iš internetinės kamerosper WebRTC serverį
Šio straipsnio tikslas – naudoti demonstracinį lygiaverčio vaizdo pokalbio (p2p vaizdo pokalbio) pavyzdį, kad susipažintumėte su jo struktūra ir veikimo principu. Šiuo tikslu naudosime kelių vartotojų lygiaverčių vaizdo pokalbių demonstracinę versiją webrtc.io-demo. Jį galima atsisiųsti iš nuorodos: https://github.com/webRTC/webrtc.io-demo/tree/master/site.
Reikėtų pažymėti, kad „GitHub“ yra svetainė arba žiniatinklio paslauga, skirta bendrai kurti žiniatinklio projektus. Jame kūrėjai gali skelbti savo kūrimo kodus, juos aptarti ir bendrauti tarpusavyje. Be to, kai kurios didelės IT įmonės skelbia savo oficialias saugyklas šioje svetainėje. Paslauga nemokama atvirojo kodo projektams. „GitHub“ yra atvirų, nemokamų šaltinio kodų bibliotekų saugykla.
Taigi, mes patalpinsime demonstracinį lygiaverčio vaizdo pokalbio pavyzdį, atsisiųstą iš GitHub, asmeninio kompiuterio C diske į sukurtą mūsų programos „webrtc_demo“ katalogą.
Ryžiai. 1
Kaip matyti iš struktūros (1 pav.), peer-to-peer vaizdo pokalbį sudaro kliento script.js ir serverio serverio.js scenarijai, įdiegti JavaScript programavimo kalba. Scenarijus (biblioteka) webrtc.io.js (KLIENTAS) – suteikia galimybę organizuoti ryšį realiuoju laiku tarp naršyklių naudojant lygiavertę schemą: "klientas-klientas" ir webrtc.io.js (KLIENTAS) ir webrtc. io.js (SERVERIS), Naudodami WebSocket protokolą, jie užtikrina dvipusį ryšį tarp naršyklės ir žiniatinklio serverio, naudojant kliento-serverio architektūrą.
Webrtc.io.js (SERVER) scenarijus yra įtrauktas į webrtc.io biblioteką ir yra node_modules\webrtc.io\lib kataloge. Vaizdo pokalbių sąsaja index.html yra įdiegta HTML5 ir CSS3. Webrtc_demo programos failų turinį galima peržiūrėti naudojant vieną iš html redaktorių, pavyzdžiui, „Notepad++“.
Patikrinsime vaizdo pokalbio veikimo principą kompiuterio failų sistemoje. Norėdami paleisti serverį (server.js) kompiuteryje, turite įdiegti node.js vykdymo aplinką. Node.js leidžia paleisti JavaScript kodą už naršyklės ribų. Galite atsisiųsti node.js iš nuorodos: http://nodejs.org/ (versija v0.10.13 nuo 07/15/13). Pagrindiniame node.org svetainės puslapyje spustelėkite atsisiuntimo mygtuką ir eikite į http://nodejs.org/download/. „Windows“ naudotojams pirmiausia atsisiųskite win.installer (.msi), tada kompiuteryje paleiskite win.installer (.msi) ir kataloge Program Files įdiekite nodejs ir „npm paketų tvarkyklę“.
Ryžiai. 2
Taigi, node.js susideda iš aplinkos, skirtos kurti ir paleisti JavaScript kodą, taip pat vidinių modulių rinkinį, kurį galima įdiegti naudojant tvarkyklę arba npm paketų tvarkyklę.
Norėdami įdiegti modulius, komandų eilutėje turite paleisti komandą iš programų katalogo (pavyzdžiui, "webrtc_demo"): npm install module_name. Modulių diegimo metu npm tvarkyklė sukuria aplanką node_modules kataloge, iš kurio buvo atliktas diegimas. Veikimo metu nodejs automatiškai sujungia modulius iš katalogo node_modules.
Taigi, įdiegę node.js, atidarykite komandų eilutę ir atnaujinkite greitąjį modulį webrtc_demo katalogo aplanke node_modules naudodami npm paketų tvarkyklę:
C:\webrtc_demo>npm install express
Greitasis modulis yra žiniatinklio struktūra, skirta node.js arba žiniatinklio platforma, skirta programų kūrimui. Norėdami turėti visuotinę prieigą prie Express, galite ją įdiegti tokiu būdu: npm install -g express .
Tada atnaujinkite webrtc.io modulį:
C:\webrtc_demo>npm įdiegti webrtc.io
Tada komandinėje eilutėje paleidžiame serverį: server.js:
C:\webrtc_demo>mazgo serveris.js
Ryžiai. 3
Viskas, serveris veikia sėkmingai (3 pav.). Dabar naudodamiesi žiniatinklio naršykle galite susisiekti su serveriu pagal IP adresą ir įkelti tinklalapį index.html, iš kurio žiniatinklio naršyklė ištrauks kliento scenarijaus kodą - script.js ir webrtc.io.js scenarijaus kodą, ir juos vykdyti. Norėdami valdyti lygiavertį vaizdo pokalbį (kad užmegztumėte ryšį tarp dviejų naršyklių), turite susisiekti su signalo serveriu, veikiančiu adresu node.js iš dviejų naršyklių, palaikančių webrtc.
Dėl to atsidarys komunikacijos programos (vaizdo pokalbio) kliento dalies sąsaja su prašymu leisti pasiekti kamerą ir mikrofoną (4 pav.).
Ryžiai. 4
Paspaudus mygtuką „Leisti“, kamera ir mikrofonas sujungiami daugialypės terpės ryšiui. Be to, per vaizdo pokalbių sąsają galite bendrauti tekstiniais duomenimis (5 pav.).
Ryžiai. 5
Reikėtų pažymėti, kad. Serveris yra signalizacijos serveris ir daugiausia skirtas ryšiams tarp vartotojų naršyklių užmegzti. Node.js naudojamas server.js serverio scenarijui, teikiančiam WebRTC signalizaciją, valdyti.
Preambulė. P2P vaizdo pokalbis, pagrįstas WebRTC, yra alternatyva Skype ir kitoms ryšio priemonėms. Pagrindiniai p2p vaizdo pokalbių elementai, pagrįsti WebRTC, yra naršyklė ir kontaktų serveris. P2P vaizdo pokalbiai yra lygiaverčiai vaizdo pokalbiai, kuriuose serveris nedalyvauja perduodant informacijos srautus. Informacija perduodama tiesiogiai tarp vartotojų naršyklių (bendradarbių) be jokių papildomų programų. Be naršyklių, p2p vaizdo pokalbiuose naudojami kontaktiniai serveriai, skirti registruoti vartotojus, saugoti duomenis apie juos ir užtikrinti perjungimą tarp vartotojų. Naršyklės, palaikančios naujausias WebRTC ir HTML5 technologijas, teikia momentinius tekstinius pranešimus ir failų perdavimą, taip pat balso ir vaizdo ryšį IP tinklais.
Taigi, pokalbiai, interneto pokalbiai, balso ir vaizdo pokalbiai žiniatinklio sąsajoje, IMS, VoIP yra paslaugos, teikiančios ryšį internetu per sudėtinius paketų perjungimo tinklus. Paprastai komunikacijos paslaugoms reikia įdiegti kliento programas vartotojo įrenginiuose (asmeniniuose kompiuteriuose, išmaniuosiuose telefonuose ir kt.), arba įdiegti papildinius ir plėtinius naršyklėse. Paslaugos turi savo ryšių tinklus, kurių dauguma yra sukurti pagal kliento-serverio architektūrą.
Ryšių paslaugos yra programos, išskyrus IMS, kuriose balso, vaizdo, duomenų ir teksto kanalai nėra integruoti. Kiekvienos paslaugos tinkluose . Pažymėtina, kad šios programos negali vienu metu dirbti keliuose ryšio tinkluose, t.y. Programos paprastai negali susisiekti viena su kita, todėl kiekvienam ryšio tinklui reikia įdiegti atskirą programą.
Realaus laiko komunikacijos paslaugų (pokalbių, telefonijos, vaizdo konferencijų) integravimo problema, t.y. balso, vaizdo, duomenų kanalų integravimas ir prieiga prie jų naudojant vieną programą (naršyklę) gali būti išspręsta lygiarangiuose arba p2p vaizdo pokalbiuose (peer-to-peer, point-to-point) remiantis WebRTC protokolu. Iš esmės WebRTC palaikanti naršyklė tampa viena sąsaja visiems vartotojo įrenginiams (kompiuteriams, išmaniesiems telefonams, iPad, IP telefonams, mobiliesiems telefonams ir kt.), kurie veikia su ryšio paslaugomis.
Būtent WebRTC užtikrina visų technologijų, užtikrinančių ryšį realiuoju laiku, įdiegimą naršyklėje. P2p vaizdo pokalbių esmė yra ta, kad daugialypės terpės ir teksto duomenys perduodami tiesiai tarp vartotojų naršyklių (nuotolinis peering), nedalyvaujant serveriui ar papildomoms programoms. Taigi, naršyklės ne tik suteikia prieigą prie beveik visų interneto informacijos išteklių, kurie saugomi serveriuose, bet ir tampa priemone pasiekti visas realaus laiko ryšio paslaugas bei pašto paslaugas (balso paštas, el. paštas, SMS ir kt.)
P2p vaizdo pokalbių serveriai (kontaktiniai serveriai) skirti tik vartotojams registruoti, duomenims apie vartotojus saugoti ir ryšiui tarp vartotojų naršyklių užmegzti (persijungti). Pirmieji p2p vaizdo pokalbiai buvo įgyvendinti naudojant „flash“ technologijas. „Flash p2p“ vaizdo pokalbiai naudojami, pavyzdžiui, socialiniuose tinkluose. Flash p2p vaizdo pokalbiai neužtikrina aukštos kokybės daugialypės terpės duomenų perdavimo. Be to, norėdami išvesti balso ir vaizdo srautus iš mikrofono ir vaizdo kameros p2p „flash“ vaizdo pokalbiuose, savo žiniatinklio naršyklėje turite įdiegti „Flash“ papildinį.
Tačiau naujos kartos telekomunikacijų paslaugos apima žiniatinklio ryšį, kuris naudoja tik naršykles ir kontaktinius serverius, palaikančius WebRTC protokolus ir HTML5 specifikaciją, kad galėtų bendrauti internetu. Bet kuris vartotojo įrenginys (kompiuteris, iPad, išmanieji telefonai ir kt.), turintis tokią naršyklę, gali užtikrinti aukštos kokybės balso ir vaizdo skambučius, taip pat momentinių tekstinių žinučių ir failų perdavimą.
Taigi, nauja žiniatinklio komunikacijos technologija (p2p pokalbiai, vaizdo pokalbiai) yra WebRTC protokolas. WebRTC kartu su HTML5, CSS3 ir JavaScript leidžia kurti įvairias žiniatinklio programas. WebRT skirtas organizuoti žiniatinklio ryšius (peer-to-peer tinklus) realiuoju laiku, naudojant peer-to-peer architektūrą. P2P pokalbiai, pagrįsti WebRTC, užtikrina failų perdavimą, taip pat teksto, balso ir vaizdo ryšį tarp vartotojų internetu, naudojant tik žiniatinklio naršykles, nenaudojant išorinių naršyklės priedų ir papildinių.
P2p pokalbiuose serveris naudojamas tik p2p ryšiui tarp dviejų naršyklių užmegzti. Norėdami sukurti p2p pokalbio kliento dalį, pagrįstą WebRTC protokolu, naudojami HTML5, CSS3 ir JavaScript. Kliento programa sąveikauja su naršyklėmis per WebRTC API.
„WebRTC“ įgyvendina trys „JavaScript“ API:
- RTCPeerConnection;
- MediaStream(getUserMedia);
- RTCDataChannel.
Naršyklės perduoda medijos duomenis naudodamos SRTP protokolą, kuris veikia virš UDP. Kadangi NAT sukuria problemų naršyklėms (klientams) už NAT maršrutizatorių, naudojančių p2p ryšį internetu, STUN naudojamas apeiti NAT vertėjus. STUN yra kliento ir serverio protokolas, kuris veikia virš UDP perdavimo protokolo. P2p pokalbiuose paprastai naudojamas viešasis STUN serveris, o iš jo gauta informacija naudojama UDP ryšiui tarp dviejų naršyklių, jei jos yra už NAT.
WebRTC programų (p2p pokalbių, balso ir vaizdo žiniatinklio pokalbių) diegimo pavyzdžiai:
1. P2P vaizdo pokalbis Bistri (vieno paspaudimo vaizdo pokalbis, p2p pokalbis), pagrįstas WebRTC, gali būti atidarytas Bistri. „Bistri“ veikia naršyklėje neįdiegdamas papildomų programų ir priedų. Darbo esmė tokia: atidarykite p2p vaizdo pokalbį naudodami nurodytą nuorodą, užsiregistravę atsidariusioje sąsajoje, pakvieskite partnerius, tada iš bendraamžių klientų sąrašo pasirinkite partnerį, kuris yra prisijungęs ir spustelėkite „vaizdo skambutis“. “ mygtuką.
Dėl to MediaStream (getUserMedia) užfiksuos mikrofoną + internetinę kamerą, o serveris keisis signaliniais pranešimais su pasirinktu partneriu. Pasikeitus signaliniais pranešimais, PeerConnection API sukuria kanalus balso ir vaizdo srautams perduoti. Be to, Bistri perduoda momentinius tekstinius pranešimus ir failus. Fig. 1 rodoma Bistri p2p vaizdo pokalbių sąsajos ekrano kopija.
Ryžiai. 1. P2P vaizdo pokalbis Bistri
2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) – ši kliento aplikacija sukurta HTML5 ir WebRTC pagrindu, kuri leidžia atlikti balso ir vaizdo skambučius, taip pat siųsti momentines tekstines žinutes, t.y. Twelephone apima bandomąjį p2p pokalbį, vaizdo pokalbį ir SIP Twelephone. Reikėtų pažymėti, kad „Twelephone“ palaiko SIP protokolą, todėl dabar galite skambinti ir priimti balso ir vaizdo skambučius iš SIP telefonų naudodami „Twitter“ paskyrą kaip telefono numerį. Be to, tekstinius pranešimus galima įvesti balsu per mikrofoną, o balso atpažinimo programa įveda tekstą eilutėje „Siųsti žinutę“.
„Twelephone“ yra žiniatinklio telefonija, veikianti „Google Chrome“ naršyklės pagrindu, pradedant nuo 25 versijos, be papildomos programinės įrangos. „Twelephone“ sukūrė Chrisas Matthieu. „Twelephone“ užpakalinė programa sukurta naudojant Node.js. Serveris (kontaktų serveris) naudojamas tik p2p ryšiui tarp dviejų naršyklių arba WebRTC klientų užmegzti. „Twelephone“ programa neturi savo autorizacijos įrankių, bet yra skirta prisijungti prie paskyros „Twitter“.
Fig. 2 parodyta Twelephone p2p vaizdo pokalbių sąsajos ekrano kopija.
Ryžiai. 2. P2P Twelephone
3. Grupinis p2p vaizdo pokalbis Conversat.io sukurtas naudojant naujausias WebRTC ir HTML5 technologijas. „Conversat“ vaizdo pokalbis sukurtas remiantis SimpleWebRTC biblioteka ir skirtas bendrauti iki 6 lygiaverčių klientų vienoje patalpoje (bendraudami eilutėje „Pavadinkite pokalbį“ nurodykite bendros patalpos, skirtos lygiaverčiams klientams, pavadinimą). P2P vaizdo pokalbis „Conversat“ teikia ryšio paslaugas vartotojams neprisiregistravęs kontaktų serveryje. Fig. 3 paveiksle parodyta Conversat p2p vaizdo pokalbių sąsajos ekrano kopija.
Ryžiai. 3. Grupinis P2P vaizdo pokalbis Conversat.io
Norėdami dalyvauti P2P vaizdo pokalbiuose, pagrįstuose WebRTC, vartotojai turi turėti įdiegtą naršyklę, kuri palaiko WebRTC protokolą ir HTML5 specifikaciją. Šiuo metu „Google Chrome“ naršyklės, pradedant nuo 25 versijos ir „Mozilla Firefox Nightly“, palaiko WebRTC protokolą ir HTML5 specifikaciją. „WebRTC“ programos yra pranašesnės už „Flash“ programas vaizdo ir garso perdavimo kokybe.
WebRTC (Web Real-Time Communications) yra technologija, leidžianti žiniatinklio programoms ir svetainėms užfiksuoti ir pasirinktinai perduoti garso ir (arba) vaizdo medijos srautus, taip pat keistis savavališkais duomenimis tarp naršyklių, nebūtinai naudojant tarpininkus. Standartų rinkinys, kurį apima WebRTC technologija, leidžia keistis duomenimis ir rengti lygiavertes telekonferencijas, vartotojui neįdiegiant papildinių ar bet kokios kitos trečiosios šalies programinės įrangos.
WebRTC sudaro kelios tarpusavyje sujungtos taikomųjų programų sąsajos (API) ir protokolai, kurie veikia kartu. Dokumentacija, kurią rasite čia, padės suprasti WebRTC pagrindus, kaip nustatyti ir naudoti ryšį duomenims ir medijai perduoti ir daug daugiau.
SuderinamumasKadangi WebRTC diegimas dar tik pradedamas kurti, o kiekviena naršyklė turi WebRTC funkciją, prieš pradedant dirbti su kodu primygtinai rekomenduojame naudoti Google Adapter.js polifilų biblioteką.
Adapter.js naudoja pleištus ir daugialypius užpildus, kad sklandžiai panaikintų WebRTC diegimo skirtumus tarp jį palaikančių kontekstų. Adapter.js taip pat tvarko tiekėjo priešdėlius ir kitus ypatybių pavadinimų skirtumus, todėl WebRTC lengviau kurti ir gauti labiausiai suderinamus rezultatus. Biblioteką taip pat galima įsigyti kaip NPM paketą.
Norėdami toliau tyrinėti Adapter.js biblioteką, pažiūrėkite.
WebRTC sąvokos ir naudojimas„WebRTC“ yra daugiafunkcinis ir, kartu su , teikia galingas žiniatinklio daugialypės terpės galimybes, įskaitant garso ir vaizdo konferencijų palaikymą, failų dalijimąsi, ekrano fiksavimą, tapatybės valdymą ir sąveiką su senomis telefono sistemomis, įskaitant DTMF toninio rinkimo palaikymą. Ryšiai tarp mazgų gali būti sukurti nenaudojant specialių tvarkyklių ar įskiepių, o dažnai ir be tarpinių paslaugų.
Ryšys tarp dviejų mazgų vaizduojamas kaip RTCPeerConnection sąsajos objektas. Užmezgus ir atidarius ryšį, naudojant RTCPeerConnection objektą, prie ryšio galima pridėti medijos srautus („MediaStream“) ir (arba) duomenų kanalus (RTCDataChannel).
Medijos srautus gali sudaryti bet koks medijos informacijos takelių (takų) skaičius. Šiuos takelius vaizduoja „MediaStreamTrack“ sąsajos objektai, juose gali būti vieno ar daugiau tipų medijos duomenų, įskaitant garsą, vaizdo įrašą, tekstą (pvz., subtitrus ar skyrių pavadinimus). Daugumą srautų sudaro bent vienas garso takelis (vienas garso takelis) arba vaizdo takelis, juos galima siųsti ir gauti kaip srautus (realiojo laiko laikmena) arba išsaugoti faile.
Taip pat galite naudoti ryšį tarp dviejų mazgų, kad keistumėte savavališkus duomenis naudodami RTCDataChannel sąsajos objektą, kuris gali būti naudojamas paslaugų informacijai, vertybinių popierių rinkos duomenims, žaidimo būsenos paketams perduoti, failų perdavimui ar privačiais duomenų kanalais.
reikia daugiau informacijos ir nuorodų į atitinkamus vadovus ir mokymo programas
WebRTC sąsajosKadangi WebRTC teikia sąsajas, kurios kartu atlieka įvairias užduotis, jas suskirstėme į kategorijas. Norėdami greitai naršyti, žr. šoninės juostos rodyklę.
Ryšio nustatymas ir valdymasŠios sąsajos naudojamos WebRTC ryšiams konfigūruoti, atidaryti ir valdyti. Jie yra vieno sluoksnio medijos ryšiai, duomenų kanalai ir sąsajos, kurios naudojamos keistis informacija apie kiekvieno mazgo galimybes, siekiant pasirinkti geriausią konfigūraciją dvipusiam daugialypės terpės ryšiui sukurti.
RTCPeerConnection reiškia WebRTC ryšį tarp vietinio kompiuterio ir nuotolinio mazgo. Naudojamas sėkmingai perduoti duomenis tarp dviejų mazgų. RTCSessionDescription Nurodo seanso parametrus. Kiekviename RTCSessionDescription yra tipo aprašymai, nurodantys, kurią derybų proceso dalį (pasiūlymą/atsakymą) jis aprašo, ir seanso SDP aprašą. RTCIceCandidate reiškia interneto ryšio sukūrimo (ICE) serverio kandidatą RTCPeerConnection ryšiui užmegzti. RTCIceTransport yra interneto ryšio priemonės (ICE) informacija. RTCPeerConnectionIceEvent Nurodo įvykius, vykstančius ICE kandidatuose, paprastai RTCPeerConnection . Šiam įvykio objektui perduodamas vienas tipas: icecandidate. RTCRtpSender Valdo duomenų srautinį perdavimą ir perdavimą per MediaStreamTrack tipo objektą RTCPeerConnection tipo objektui. RTCRtpReceiver Valdo duomenų priėmimą ir dekodavimą per MediaStreamTrack tipo objektą RTCPeerConnection tipo objektui. RTCTrackEvent Nurodo, kad buvo sukurtas naujas gaunamas MediaStreamTrack objektas ir RTCRtpReceiver objektas buvo pridėtas prie RTCPeerConnection objekto. RTCCertificate Rodo sertifikatą, kuris naudoja RTCPeerConnection objektą. RTCDataChannel reiškia dvikryptį duomenų kanalą tarp dviejų ryšio mazgų. RTCDataChannelEvent Nurodo įvykius, kurie iškeliami, kai RTCDataChannel tipo objektas yra prijungtas prie RTCPeerConnection tipo objekto. RTCDTMFSender Valdo dviejų tonų daugiadažnių (DTMF) signalų kodavimą ir perdavimą RTCPeerConnection tipo objektui. RTCDTMFToneChangeEvent Nurodo gaunamą dviejų tonų kelių dažnių (DTMF) tonų keitimo įvykį. Šis įvykis nėra burbulas (jei nenurodyta kitaip) ir nėra atšaukiamas (jei nenurodyta kitaip). RTCStatsReport asinchroniškai praneša apie perduodamo MediaStreamTrack tipo objekto būseną. RTCIdentityProviderRegistrar Registruoja tapatybės teikėją (idP). RTCIdentityProvider Įgalina naršyklės galimybę prašyti sukurti arba patikrinti tapatybės deklaraciją. RTCIdentityAssertion Nurodo esamo ryšio nuotolinio mazgo identifikatorių. Jei mazgas dar neįdiegtas ir nepatvirtintas, sąsajos nuoroda grįš null . Po įdiegimo nesikeičia. RTCIdentityEvent Nurodo tapatybės teikėjo (idP) deklaracijos įvykio objektą. RTCPeerConnection tipo objekto įvykis. Vienas tipas perduodamas šiam tapatybės rezultato įvykiui. RTCIdentityErrorEvent Nurodo klaidos įvykio objektą, susietą su tapatybės teikėju (idP). RTCPeerConnection tipo objekto įvykis. Šiam įvykiui perduodamos dviejų tipų klaidos: idpassertionerror ir idpvalidationerror. Vadovai WebRTC architektūros apžvalga Po API, kurią kūrėjai naudoja kurdami ir naudodami WebRTC, slypi tinklo protokolų ir ryšio standartų rinkinys. Ši apžvalga yra šių standartų demonstracija. WebRTC leidžia organizuoti ryšį tarp mazgų režimu, kad naršyklėje būtų perkelti savavališki duomenys, garso, vaizdo srautai arba bet koks jų derinys. Šiame straipsnyje apžvelgsime WebRTC seanso gyvenimą, pradedant nuo ryšio užmezgimo ir tęsiant iki galo, kol jis nutrūksta, kai jo nebereikia. WebRTC API apžvalga WebRTC susideda iš kelių tarpusavyje susijusių taikomųjų programų sąsajų (API) ir protokolų, kurie veikia kartu, kad palaikytų keitimąsi duomenimis ir medijos srautais tarp dviejų ar daugiau mazgų. Šiame straipsnyje pateikiama trumpa kiekvienos iš šių API apžvalga ir jų paskirtis. WebRTC pagrindai Šis straipsnis padės jums sukurti kelių naršyklių RTC programą. Šio straipsnio pabaigoje turėtumėte turėti veikiantį tiesioginių duomenų ir medijos kanalą. WebRTC protokolai Šiame straipsnyje pristatomi protokolai, kurie papildo WebRTC API. Šiame vadove aprašoma, kaip galite naudoti mazgų ir mazgų ryšį ir susieti