WebRTC. Videokonference v brskalniku. Večuporabniški klepet z uporabo glasovnega klepeta WebRTC Webrtc

Preambula. Video klepet P2P je vklopljen Osnova WebRTC je alternativa Skypu in drugim komunikacijskim sredstvom. Glavna elementa p2p video klepeta, ki temelji na WebRTC, sta brskalnik in kontaktni strežnik. Video klepeti P2P so video klepeti enakovrednih, pri katerih strežnik ne sodeluje pri prenosu informacijskih tokov. Informacije se prenašajo neposredno med uporabnikovimi brskalniki (vrstniki) brez kakršnih koli dodatne programe. Video klepeti p2p poleg brskalnikov uporabljajo kontaktne strežnike, ki so namenjeni registraciji uporabnikov, shranjevanju podatkov o njih in zagotavljanju preklapljanja med uporabniki. Brskalniki, ki podpirajo najnovejši tehnologiji WebRTC in HTML5, zagotavljajo takojšnje besedilno sporočanje in prenos datotek ter glasovno in video komunikacijo prek omrežij IP.

Torej so klepeti, spletni klepeti, glasovni in video klepeti v spletnem vmesniku, IMS, VoIP storitve, ki zagotavljajo spletno komunikacijo prek sestavljenih paketno komutiranih omrežij. Komunikacijske storitve praviloma zahtevajo namestitev odjemalskih aplikacij na uporabniške naprave (osebne računalnike, pametne telefone itd.) ali namestitev vtičnikov in razširitev v brskalnikih. Storitve imajo lastna komunikacijska omrežja, ki so večinoma zgrajena na arhitekturi odjemalec-strežnik.

Komunikacijske storitve so aplikacije, razen IMS, v katere glasovni, video, podatkovni in besedilni kanali niso integrirani. V omrežjih vsake storitve, . Upoštevati je treba, da te aplikacije ne morejo hkrati delovati v več komunikacijskih omrežjih, tj. Aplikacije običajno ne morejo komunicirati med seboj, zato je treba za vsako komunikacijsko omrežje namestiti ločeno aplikacijo.

Problem integracije komunikacijskih storitev v realnem času (klepet, telefonija, videokonference), t.j. integracijo govornih, video, podatkovnih kanalov in dostop do njih z uporabo ene aplikacije (brskalnika) lahko rešimo v peer-to-peer ali p2p video klepetih (peer-to-peer, point-to-point) na osnovi protokola WebRTC. V bistvu brskalnik, ki podpira WebRTC, postane enoten vmesnik za vse uporabniške naprave (osebne računalnike, pametne telefone, iPade, IP telefone, Mobilni telefoni itd.), ki delujejo s komunikacijskimi storitvami.

WebRTC je tisti, ki zagotavlja implementacijo v brskalnik vseh tehnologij, ki omogočajo komunikacijo v realnem času. Bistvo p2p video klepetov je, da se večpredstavnostni in tekstovni podatki prenašajo neposredno med brskalniki uporabnikov (remote peering) brez sodelovanja strežnika ali dodatnih programov. Tako brskalniki ne zagotavljajo le dostopa do skoraj vseh informacijskih virov Internet, ki so shranjeni na strežnikih, ampak postanejo tudi sredstvo za dostop do vseh komunikacijskih storitev v realnem času in poštnih storitev (glasovna pošta, E-naslov, SMS itd.)

Strežniki (kontaktni strežniki) p2p video klepetov so namenjeni zgolj registraciji uporabnikov, shranjevanju podatkov o uporabnikih in vzpostavljanju povezave (preklapljanju) med brskalniki uporabnikov. Prvi p2p video klepeti so bili izvedeni s tehnologijo flash. Video klepeti Flash p2p se uporabljajo na primer v v socialnih omrežjih. Video klepeti Flash p2p ne zagotavljajo visoka kvaliteta prenos multimedijskih podatkov. Poleg tega morate za predvajanje glasovnega in video toka iz mikrofona in video kamere v video klepetih p2p flash namestiti vtičnik flash v spletni brskalnik.

Toda nova generacija telekomunikacijskih storitev vključuje spletne komunikacije, ki za komunikacijo prek interneta uporabljajo samo brskalnike in kontaktne strežnike, ki podpirajo protokole WebRTC in specifikacijo HTML5. Vsaka uporabniška naprava (PC, iPad, pametni telefoni itd.), ki je opremljena s takšnim brskalnikom, lahko zagotavlja kakovostne glasovne in video klice ter prenos takojšnjih besedilnih sporočil in datotek.

Torej, nova tehnologija za spletno komunikacijo (p2p klepeti, video klepeti) je protokol WebRTC. WebRTC skupaj s HTML5, CSS3 in JavaScript omogoča ustvarjanje različnih spletnih aplikacij. WebRT je zasnovan za organiziranje spletnih komunikacij (omrežij enakovrednih) v realnem času z uporabo arhitekture enakovrednih. P2P klepeti, ki temeljijo na WebRTC, omogočajo prenos datotek ter besedilno, glasovno in video komunikacijo med uporabniki prek interneta z uporabo samo spletnih brskalnikov brez uporabe zunanjih dodatkov in vtičnikov v brskalniku.

Pri p2p klepetih se strežnik uporablja samo za vzpostavitev povezave p2p med dvema brskalnikoma. Za ustvarjanje odjemalskega dela p2p klepeta, ki temelji na protokolu WebRTC, se uporabljajo HTML5, CSS3 in JavaScript. Odjemalska aplikacija komunicira z brskalniki prek API-ja WebRTC.

WebRTC izvajajo trije JavaScript API-ji:

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

Brskalniki prenašajo medijske podatke s protokolom SRTP, ki deluje poleg UDP. Ker NAT povzroča težave brskalnikom (odjemalcem) za usmerjevalniki NAT, ki uporabljajo povezave p2p prek interneta, se STUN uporablja za obhod prevajalnikov NAT. STUN je protokol odjemalec-strežnik, ki deluje na vrhu transportnega protokola UDP. Pri p2p klepetih se praviloma uporablja javni strežnik STUN, informacije, prejete z njega, pa se uporabljajo za povezavo UDP med dvema brskalnikoma, če sta za NAT.

Primeri implementacije aplikacij WebRTC (p2p klepeti, glasovni in video spletni klepeti):
1. P2P video klepet Bistri (video klepet z enim klikom, p2p klepet), ki temelji na WebRTC, lahko odprete na Bistri. Bistri deluje v brskalniku brez namestitve dodatnih programov in vtičnikov. Bistvo dela je naslednje: odprite video klepet p2p z navedeno povezavo, po registraciji v vmesniku, ki se odpre, povabite partnerje, nato s seznama enakovrednih strank izberite partnerja, ki je na spletu, in kliknite »video klic ”.

Posledično bo MediaStream (getUserMedia) zajel mikrofon + spletno kamero, strežnik pa bo izmenjal signalna sporočila z izbranim partnerjem. Po izmenjavi signalnih sporočil API PeerConnection ustvari kanale za prenos glasovnih in video tokov. Poleg tega Bistri prenaša takojšnja besedilna sporočila in datoteke. Na sl. 1 prikazuje posnetek zaslona vmesnika za video klepet Bistri p2p.

riž. 1. P2P video klepet Bistri

2. Twelephone (p2p video klepet, p2p klepet, SIP Twelephone) - ta odjemalska aplikacija je zgrajena na osnovi HTML5 in WebRTC, ki omogoča glasovne in video klice ter pošiljanje neposrednih besedilnih sporočil, tj. Twelephone vključuje testni p2p klepet, video klepet in SIP Twelephone. Opozoriti je treba, da Twelephone podpira protokol SIP in zdaj lahko opravljate in sprejemate glasovne in video klice iz telefonov SIP z uporabo vašega Twitter računa kot telefonske številke. Poleg tega tekstovna sporočila lahko vnesete z glasom prek mikrofona, program za prepoznavanje glasu pa vnese besedilo v vrstico »Pošlji sporočilo«.

Twelephone je spletna telefonija, ki temelji na brskalniku Google Chrome, od različice 25, brez dodatnih programsko opremo. Twelephone je razvil Chris Matthieu. Zaledje Twelephone je zgrajeno na Node.js. Strežnik (kontaktni strežnik) se uporablja samo za vzpostavitev p2p povezave med dvema brskalnikoma ali odjemalcema WebRTC. Aplikacija Twelephone nima lastnih avtorizacijskih orodij, ampak je osredotočena na povezovanje z računom ( račun) na Twitterju.

Na sl. 2 prikazuje posnetek zaslona vmesnika za video klepet Twelephone p2p.

riž. 2. P2P Twelephone

3. Skupinski p2p video klepet Conversat.io je zgrajen na najnovejših tehnologijah WebRTC in HTML5. Video klepet Conversat je razvit na podlagi knjižnice SimpleWebRTC in je namenjen komunikaciji med do 6 enakovrednimi odjemalci v eni sobi (za komunikacijo navedite ime skupne sobe za enakovredne odjemalce v vrstici »Poimenuj pogovor«). P2P video klepet Conversat zagotavlja komunikacijske storitve uporabnikom brez registracije na kontaktnem strežniku. Na sl. Slika 3 prikazuje posnetek zaslona vmesnika za video klepet Conversat p2p.

riž. 3. Skupinski P2P video klepet Conversat.io

Za sodelovanje v P2P video klepetih, ki temeljijo na WebRTC, morajo imeti uporabniki nameščen brskalnik, ki podpira protokol WebRTC in specifikacijo HTML5. Trenutno brskalniki Google Chrome, začenši z različico 25, in Mozilla Firefox Nightly podpira protokol WebRTC in specifikacijo HTML5. Aplikacije WebRTC so boljše od aplikacij Flash glede kakovosti prenosa slike in zvoka.

Večina gradiva o WebRTC je osredotočena na aplikativno raven kodiranja in ne prispeva k razumevanju tehnologije. Poskusimo iti globlje in ugotoviti, kako pride do povezave, kaj so deskriptor seje in kandidati, zakaj sta potrebna strežnika STUN in TURN.

Predstavitev WebRTC

WebRTC je tehnologija, usmerjena v brskalnik, ki omogoča povezavo dveh odjemalcev za prenos video podatkov. Glavne značilnosti so notranja podpora brskalniku (ni potrebe po implementiranih tehnologijah tretjih oseb, kot je adobe flash) in možnost povezovanja odjemalcev brez uporabe dodatnih strežnikov - povezava enakovrednih (v nadaljevanju p2p).

Vzpostavitev povezave p2p je precej težka naloga, saj računalniki nimajo vedno javnih IP naslovov, torej naslovov v internetu. Zaradi majhnega števila naslovov IPv4 (in zaradi varnosti) je bil razvit mehanizem NAT, ki omogoča ustvarjanje zasebnih omrežij, na primer za domačo uporabo. Mnogi domači usmerjevalniki zdaj podpirajo NAT in zahvaljujoč temu imajo vse domače naprave dostop do interneta, čeprav internetni ponudniki običajno zagotavljajo en naslov IP. Javni naslovi IP so edinstveni v internetu, zasebni pa ne. Zato je povezovanje p2p težko.

Da bi to bolje razumeli, razmislite o treh situacijah: obe vozlišči sta v istem omrežju (slika 1), obe vozlišči sta v različnih omrežjih (eno zasebno, drugo javno) (slika 2) in obe vozlišči sta v različnih zasebnih omrežjih z iste naslove IP (slika 3).

Slika 1: Obe vozlišči v istem omrežju

Slika 2: Vozlišča v različnih omrežjih (eno zasebno, eno javno)

Slika 3: Vozlišča v različnih zasebnih omrežjih, vendar s številčno enakimi naslovi

Na zgornjih slikah prva črka v zapisu z dvema znakoma označuje vrsto vozlišča (p = vrstnik, r = usmerjevalnik). Na prvi sliki je situacija ugodna: vozlišča v svojem omrežju so popolnoma identificirana z omrežnimi naslovi IP in se zato lahko med seboj neposredno povezujejo. Na drugi sliki imamo dve različni omrežji s podobnimi številkami vozlišč. Tu se pojavijo usmerjevalniki (routerji), ki imajo dva omrežni vmesnik– znotraj in zunaj vašega omrežja. Zato imajo dva IP naslova. Običajna vozlišča imajo samo en vmesnik, prek katerega lahko komunicirajo samo znotraj svojega omrežja. Če prenašajo podatke nekomu zunaj svojega omrežja, potem samo z uporabo NAT znotraj usmerjevalnika (routerja) in so zato vidni drugim pod naslovom IP usmerjevalnika - je njihov zunanji IP naslov. Torej ima vozlišče p1 notranjost IP = 192.168.0.200 in zunanji IP = 10.50.200.5 , zadnji naslov pa bo tudi zunanji za vsa druga vozlišča v njegovem omrežju. Situacija je podobna za vozlišče p2. Zato je njihova komunikacija nemogoča, če se uporabljajo samo njihovi interni (lastni) naslovi IP. Uporabite lahko zunanje naslove, torej naslove usmerjevalnika, a ker imajo vsa vozlišča v istem zasebnem omrežju enak zunanji naslov, je to precej težko. To težavo je mogoče rešiti z uporabo mehanizma NAT

Kaj se bo zgodilo, če se odločimo za povezavo vozlišč prek njihovih notranjih naslovov? Podatki ne bodo zapustili omrežja. Za povečanje učinka si lahko predstavljate situacijo, prikazano na zadnji sliki - obe vozlišči imata enake notranje naslove. Če jih uporabljajo za komunikacijo, bo vsako vozlišče komuniciralo samo s seboj.

WebRTC se s tovrstnimi težavami uspešno spopada s pomočjo protokola ICE, ki pa zahteva uporabo dodatnih strežnikov (STUN, TURN). Več o vsem tem spodaj.

Dve fazi WebRTC

Če želite povezati dve vozlišči prek protokola WebRTC (ali preprosto RTC, če komunicirata dva iPhona), morate opraviti nekaj predhodnih korakov za vzpostavitev povezave. To je prva faza – vzpostavitev povezave. Druga faza je prenos video podatkov.

Takoj je vredno povedati, da čeprav tehnologija WebRTC uporablja veliko na različne načine komunikacije (TCP in UDP) in ima prilagodljivo preklapljanje med njimi, ta tehnologija nima protokola za prenos podatkov o povezavi. Ni presenetljivo, saj povezovanje dveh p2p vozlišč ni tako enostavno. Zato jih je treba imeti nekaj dodatno način prenosa podatkov, ki ni v nobeni povezavi z WebRTC. Lahko bi bil prenos vtičnice, protokol HTTP, lahko celo protokol SMTP ali Ruska pošta. Ta prenosni mehanizem začetnica podatki se imenujejo signal. Ni treba posredovati veliko informacij. Vsi podatki se prenašajo v besedilni obliki in so razdeljeni na dve vrsti - SDP in Ice Candidate. Prvi tip se uporablja za vzpostavitev logične povezave, drugi pa za fizično povezavo. Več o vsem tem kasneje, za zdaj pa je pomembno le vedeti, da nam bo WebRTC dal nekaj informacij, ki jih bo treba prenesti na drugo vozlišče. Takoj, ko posredujemo vse potrebne informacije, se bodo vozlišča lahko povezala in naša pomoč ne bo več potrebna. Signalni mehanizem, ki ga moramo uvesti, je torej ločeno, bodo uporabljeni samo ko je povezan, vendar ne bo uporabljen pri prenosu video podatkov.

Torej, razmislimo o prvi fazi - fazi vzpostavitve povezave. Sestavljen je iz več točk. Oglejmo si to fazo najprej za vozlišče, ki vzpostavi povezavo, in nato za tisto, ki čaka.

• Pobudnik (kličoči):
• Ponudba za začetek prenosa video podatkov (createOffer)
• Pridobivanje vašega SDP SDP)
• Prejemanje vašega kandidata za led Ice kandidata )
• Čakajoči klic (klicani):
• Prejemanje lokalnega (vašega) medijskega toka in nastavitev za prenos (getUserMediaStream)
• Prejem ponudbe za začetek prenosa video podatkov in ustvarjanje odgovora (createAnswer)
• Prejemanje njegovega predmeta SDP in njegovo posredovanje skozi signalizacijski mehanizem (SDP)
• Sprejemanje vaših predmetov kandidata za led in njihovo posredovanje skozi signalni mehanizem (kandidat za led)
• Sprejem oddaljenega (tujega) medijskega toka in njegov prikaz na zaslonu (onAddStream)

Edina razlika je v drugi točki.

Kljub navidezni zapletenosti korakov so dejansko trije: pošiljanje lastnega medijskega toka (točka 1), nastavitev parametrov povezave (točke 2-4), sprejem medijskega toka nekoga drugega (točka 5). Najtežji korak je drugi korak, saj je sestavljen iz dveh delov: vzpostavitev fizično in logično povezave. Prvi nakazuje pot, vzdolž katerega morajo potovati paketi, da pridejo od enega omrežnega vozlišča do drugega. Drugi nakazuje video/avdio parametre– kakšno kakovost uporabiti, katere kodeke uporabiti.

Miselno je treba fazo createOffer ali createAnswer povezati s stopnjami podajanja kandidatnih objektov SDP in Ice.

Osnovne entitete Medijski tokovi (MediaStream)

Glavno bistvo je medijski tok, to je tok video in avdio podatkov, slike in zvoka. Obstajata dve vrsti medijskih tokov - lokalni in oddaljeni. Lokalni sprejema podatke iz vhodnih naprav (kamera, mikrofon), oddaljeni pa prek omrežja. Tako ima vsako vozlišče lokalno in oddaljeno nit. V WebRTC obstaja vmesnik MediaStream za tokove in obstaja tudi podvmesnik LocalMediaStream posebej za lokalni tok. V JavaScriptu lahko naletite samo na prvo, če pa uporabljate libjingle, lahko naletite tudi na drugo.

WebRTC ima precej zmedeno hierarhijo znotraj niti. Vsak tok je lahko sestavljen iz več medijskih skladb (MediaTrack), te pa iz več medijskih kanalov (MediaChannel). Lahko pa je tudi več samih medijskih tokov.

Poglejmo vse po vrsti. Da bi to naredili, imejmo v mislih nekaj primerov. Recimo, da ne želimo posredovati le posnetka sebe, ampak tudi posnetek naše mize, na kateri leži kos papirja, na katerega bomo nekaj napisali. Potrebovali bomo dva videa (mi + miza) in en avdio (mi). Jasno je, da bi morali biti mi in tabela razdeljeni na različne niti, ker so ti podatki verjetno slabo odvisni drug od drugega. Zato bomo imeli dva MediaStreama - enega za nas in enega za mizo. Prvi bo vseboval tako video kot zvočne podatke, drugi pa samo video (slika 4).

Slika 4: Dva različna medijska toka. Eno za nas, eno za našo mizo

Takoj je jasno, da mora medijski tok vključevati vsaj možnost vsebovanja podatkov različni tipi- video in avdio. To je upoštevano v tehnologiji, zato je vsaka vrsta podatkov implementirana prek medijske sledi MediaTrack. Medijska sled ima posebno vrsto lastnosti, ki določa, ali je video ali zvok (slika 5).

Slika 5: Medijski tokovi so sestavljeni iz medijskih sledi

Kako se bo vse dogajalo v programu? Ustvarili bomo dva medijska toka. Nato bomo ustvarili dva video posnetka in en zvočni posnetek. Omogočimo dostop do kamer in mikrofona. Vsaki skladbi povejmo, katero napravo naj uporabi. Dodajmo video in zvočni posnetek v prvi medijski tok in video posnetek iz druge kamere v drugi medijski tok.

Toda kako ločimo medijske tokove na drugem koncu povezave? Za to ima vsak medijski tok lastnost oznake - oznako toka, njegovo ime (slika 6). Medijske sledi imajo enako lastnost. Čeprav se na prvi pogled zdi, da je video od zvoka mogoče ločiti še kako drugače.

Slika 6: Medijski tokovi in ​​sledi so označeni z oznakami

Torej, če je medijske skladbe mogoče prepoznati prek oznake, zakaj potem moramo za naš primer uporabiti dva medijska toka namesto enega? Navsezadnje lahko prenašate en medijski tok, vendar v njem uporabite različne skladbe. Dosegli smo pomembno lastnost medijskih tokov – oni sinhronizirati medijske skladbe. Različni medijski tokovi niso sinhronizirani med seboj, vendar znotraj vsakega medijskega toka vse skladbe se predvajajo hkrati.

Torej, če želimo, da se naše besede, naša obrazna čustva in naš kos papirja predvajajo hkrati, potem je vredno uporabiti en medijski tok. Če to ni tako pomembno, je bolj donosno uporabiti različne tokove - slika bo bolj gladka.

Če je treba med prenosom nekatere skladbe onemogočiti, lahko uporabite lastnost enabled medijske skladbe.

Nazadnje je vredno razmisliti o stereo zvoku. Kot veste, sta stereo zvok dva različna zvoka. In jih je treba tudi ločeno prenesti. Za to se uporabljajo MediaChannels. Medijski zvočni posnetek ima lahko veliko kanalov (na primer 6, če potrebujete zvok 5+1). Seveda obstajajo tudi kanali znotraj medijskih tirov. sinhronizirano. Za video se običajno uporablja samo en kanal, lahko pa jih je več, na primer za prekrivno oglaševanje.

Povzeti: Za prenos video in avdio podatkov uporabljamo medijski tok. Znotraj vsakega medijskega toka se podatki sinhronizirajo. Če ne potrebujemo sinhronizacije, lahko uporabimo več medijskih tokov. Znotraj vsakega medijskega toka sta dve vrsti medijskih posnetkov - za video in za zvok. Običajno nista več kot dve skladbi, vendar jih je lahko več, če morate prenesti več različnih video posnetkov (sogovornika in njegove mize). Vsaka skladba je lahko sestavljena iz več kanalov, kar se običajno uporablja samo za stereo zvok.

V najpreprostejši situaciji video klepeta bomo imeli en lokalni medijski tok, ki bo sestavljen iz dveh skladb - video posnetka in zvočnega posnetka, od katerih bo vsak sestavljen iz enega glavnega kanala. Video posnetek je odgovoren za kamero, zvočni posnetek je odgovoren za mikrofon, medijski tok pa je vsebnik za oba.

Deskriptor seje (SDP)

Različni računalniki bodo vedno imeli različne kamere, mikrofone, video kartice in drugo opremo. Imajo veliko možnosti. Vse to mora biti usklajeno za medijski prenos podatkov med dvema omrežnima vozliščema. WebRTC to naredi samodejno in ustvari poseben predmet– Deskriptor seje SDP. Predajte ta objekt drugemu vozlišču in medijski podatki se lahko prenesejo. Le povezave z drugim vozliščem še ni.

Za to se uporablja kateri koli signalni mehanizem. SDP se lahko prenaša bodisi prek vtičnic bodisi prek osebe (povejte ga drugemu vozlišču po telefonu) bodisi preko ruske pošte. Vse je zelo preprosto - dobili boste pripravljen SDP in ga morate poslati. In ko ga prejmete na drugi strani, ga prenesite v oddelek WebRTC. Deskriptor seje je shranjen kot besedilo in ga lahko spremenite v svojih aplikacijah, vendar to na splošno ni potrebno. Na primer, ko povezujete namizje ↔ telefon, morate včasih prisilno izbrati želeni zvočni kodek.

Običajno morate pri vzpostavljanju povezave podati nekakšen naslov, na primer URL. To tukaj ni potrebno, saj boste preko signalnega mehanizma sami poslali podatke na cilj. Če želimo WebRTC nakazati, da želimo vzpostaviti povezavo p2p, moramo poklicati funkcijo createOffer. Po klicu te funkcije in podajanju posebnega povratnega klica 'a, bo ustvarjen objekt SDP in posredovan istemu povratnemu klicu. Vse kar se od vas zahteva je, da ta objekt preko omrežja prenesete na drugo vozlišče (sogovornika). Po tem bodo podatki prispeli na drugo stran preko signalnega mehanizma, in sicer tega SDP objekta. Ta deskriptor seje je temu vozlišču tuj in zato nosi koristne informacije. Prejem tega predmeta je signal za začetek povezave. Zato se morate s tem strinjati in poklicati funkcijo createAnswer. Je popoln analog createOffer. Spet bo lokalni deskriptor seje posredovan vašemu povratnemu klicu in ga bo treba posredovati nazaj prek signalizacijskega mehanizma.

Omeniti velja, da lahko funkcijo createAnswer pokličete šele po prejemu predmeta SDP nekoga drugega. Zakaj? Ker se mora lokalni objekt SDP, ki bo ustvarjen ob klicu createAnswer, zanašati na oddaljeni objekt SDP. Samo v tem primeru je možno uskladiti svoje video nastavitve z nastavitvami sogovornika. Prav tako ne smete klicati createAnswer in createOffer, preden prejmete lokalni medijski tok - ne bosta imela ničesar za napisati v objekt SDP.

Ker ima WebRTC možnost urejanja predmeta SDP, ga je treba po prejemu lokalnega deskriptorja namestiti. Morda se zdi malo nenavadno, da moramo na WebRTC prenesti tisto, kar nam je sam dal, vendar je to protokol. Ko prejmete daljinski ročaj, ga morate tudi namestiti. Zato morate na eno vozlišče namestiti dva deskriptorja - svojega in nekoga drugega (torej lokalnega in oddaljenega).

Po tem stiski rok vozlišča poznajo želje drug drugega. Na primer, če vozlišče 1 podpira kodeka A in B, vozlišče 2 pa podpira kodeka B in C, potem, ker vsako vozlišče pozna svoj in deskriptor drugega, bosta obe vozlišči izbrali kodek B (slika 7). Logika povezave je zdaj vzpostavljena in medijski tokovi se lahko prenašajo, vendar obstaja še en problem - vozlišča so še vedno povezana samo s signalnim mehanizmom.

Slika 7: Pogajanje kodekov

Kandidat za led

Tehnologija WebRTC nas poskuša zmesti s svojo novo metodologijo. Pri vzpostavljanju povezave naslov vozlišča, na katerega se želite povezati, ni določen. Nameščen prvi logično povezava, ne fizično, čeprav se je vedno delalo nasprotno. Toda to se ne bo zdelo čudno, če ne pozabimo, da uporabljamo signalni mehanizem tretjih oseb.

Povezava je torej že vzpostavljena (logična povezava), vendar še vedno ni poti, po kateri bi omrežna vozlišča lahko prenašala podatke. Ni vse tako preprosto, a začnimo preprosto. Naj bodo vozlišča v istem zasebnem omrežju. Kot že vemo, se med seboj zlahka povežejo s svojimi internimi naslovi IP (ali morda kakšnimi drugimi, če se ne uporablja TCP/IP).

Preko nekaterih povratnih klicev 'in WebRTC nas obvešča o predmetih kandidatov za Ice. Na voljo so tudi v besedilni obliki in jih je, tako kot deskriptorje sej, preprosto treba poslati prek signalizacijskega mehanizma. Če je deskriptor seje vseboval informacije o naših nastavitvah na ravni kamere in mikrofona, potem kandidati vsebujejo informacije o naši lokaciji v omrežju. Prenesite jih na drugo vozlišče in se bo lahko fizično povezalo z nami, in ker že ima deskriptor seje, se bo logično lahko povezalo in podatki bodo "tekli." Če se spomni, da nam pošlje svoj kandidatni objekt, to je informacijo o tem, kje je sam v omrežju, potem se bomo lahko povezali z njim. Naj omenimo še eno razliko od klasične interakcije odjemalec-strežnik. Komunikacija s strežnikom HTTP poteka po shemi zahteva-odgovor, odjemalec pošlje podatke strežniku, ki jih obdela in pošlje preko naslov, naveden v paketu zahteve. V WebRTC morate vedeti dva naslova in jih povežite na obeh straneh.

Razlika od deskriptorjev sej je v tem, da je treba namestiti samo oddaljene kandidate. Urejanje tukaj je prepovedano in ne more prinesti nobene koristi. V nekaterih implementacijah WebRTC je treba kandidate namestiti šele, ko so nastavljeni deskriptorji seje.

Zakaj je bil samo en deskriptor seje, kandidatov pa je lahko veliko? Kajti lokacijo v omrežju lahko določimo ne samo z njegovim internim naslovom IP, ampak tudi z zunanjim naslovom usmerjevalnika, in ne nujno samo enega, pa tudi z naslovi strežnikov TURN. Preostanek odstavka bo namenjen podrobni razpravi o kandidatih in o tem, kako povezati vozlišča iz različnih zasebnih omrežij.

Torej sta dve vozlišči v istem omrežju (slika 8). Kako jih prepoznati? Uporaba naslovov IP. Ne gre drugače. Res je, še vedno lahko uporabljate različne transporte (TCP in UDP) in različna vrata. To so informacije, ki jih vsebuje objekt kandidata - IP, PORT, TRANSPORT in nekateri drugi. Uporabimo na primer transport UDP in vrata 531.

Slika 8: Dve vozlišči sta v istem omrežju

Potem, če smo v vozlišču p1, nam bo WebRTC dal tak kandidatni objekt - . To ni natančna oblika, le diagram. Če smo na vozlišču p2, potem je kandidat . Preko signalizacijskega mehanizma bo p1 prejel kandidata p2 (to je lokacijo vozlišča p2, in sicer njegov IP in PORT). Potem se lahko p1 neposredno poveže s p2. Natančneje, p1 bo poslal podatke na 10.50.150.3:531 v upanju, da bodo dosegli p2. Ni pomembno, ali ta naslov pripada vozlišču p2 ali kakšnemu posredniku. Edina pomembna stvar je, da bodo podatki poslani prek tega naslova in lahko dosežejo p2.

Dokler so vozlišča v istem omrežju, je vse preprosto in enostavno - vsako vozlišče ima le en kandidatni objekt (vedno pomeni svojega, to je svojo lokacijo v omrežju). Toda ko bodo vozlišča notri, bo veliko več kandidatov drugačen omrežja.

Pojdimo k bolj zapletenemu primeru. Eno vozlišče bo za usmerjevalnikom (natančneje za NAT), drugo vozlišče pa bo v istem omrežju s tem usmerjevalnikom (na primer na internetu) (slika 9).

Slika 9: Eno vozlišče je za NAT, drugo ne

Ta primer ima posebno rešitev problema, ki jo bomo zdaj obravnavali. Domači usmerjevalnik običajno vsebuje tabelo NAT. To je poseben mehanizem, ki omogoča vozliščem v zasebnem omrežju usmerjevalnika dostop na primer do spletnih mest.

Predpostavimo, da je spletni strežnik neposredno povezan z internetom, to pomeni, da ima javni naslov IP *. Naj bo to vozlišče p2. Vozlišče p1 (spletni odjemalec) pošlje zahtevo na naslov 10.50.200.10. Najprej gredo podatki na usmerjevalnik r1, oziroma na njegov notranjost vmesnik 192.168.0.1. Nato si usmerjevalnik zapomni izvorni naslov (naslov p1) in ga vnese v posebno tabelo NAT, nato pa izvorni naslov spremeni v svojega (p1 → r1). Nadalje, na svoj način zunanji vmesnika usmerjevalnik pošilja podatke neposredno na spletni strežnik p2. Spletni strežnik obdela podatke, ustvari odgovor in jih pošlje nazaj. Pošlje r1 usmerjevalniku, ker je v povratnem naslovu (usmerjevalnik je zamenjal naslov s svojim). Usmerjevalnik prejme podatke, pogleda tabelo NAT in jih posreduje vozlišču p1. Usmerjevalnik tukaj deluje kot posrednik.

Kaj pa, če več vozlišč iz notranjega omrežja hkrati dostopa do zunanjega omrežja? Kako bo usmerjevalnik razumel, komu poslati odgovor? Ta problem je rešen z uporabo pristanišča. Ko usmerjevalnik zamenja naslov gostitelja s svojim, zamenja tudi vrata. Če dve vozlišči dostopata do interneta, potem usmerjevalnik zamenja njihova izvorna vrata z drugačen. Potem, ko se paket s spletnega strežnika vrne v usmerjevalnik, bo ta po vratih razumel, komu je paket dodeljen. Primer spodaj.

Vrnimo se k tehnologiji WebRTC oziroma natančneje k njenemu delu, ki uporablja protokol ICE (torej kandidati za Ice). Vozlišče p2 ima enega kandidata (njegova lokacija v omrežju je 10.50.200.10), vozlišče p1, ki se nahaja za usmerjevalnikom z NAT, pa bo imelo dva kandidata - lokalnega (192.168.0.200) in kandidata za usmerjevalnik (10.50.200.5). Prvi ni uporaben, vendar se kljub temu generira, saj WebRTC še ne ve ničesar o oddaljenem vozlišču – lahko je ali pa tudi ne v istem omrežju. Drugi kandidat bo prišel prav, in kot že vemo, bo pomembno vlogo igralo pristanišče (za prehod skozi NAT).

Vnos v tabelo NAT se ustvari šele, ko podatki zapustijo notranje omrežje. Zato mora vozlišče p1 najprej posredovati podatke in šele nato lahko podatki iz vozlišča p2 dosežejo vozlišče p1.

Na praksi obe vozlišči bo za NAT. Če želite ustvariti vnos v tabeli NAT vsakega usmerjevalnika, morajo gostitelji nekaj poslati oddaljenemu gostitelju, vendar tokrat niti prvi ne more doseči drugega niti obratno. To je posledica dejstva, da vozlišča ne poznajo svojih zunanjih naslovov IP in je pošiljanje podatkov na notranje naslove nesmiselno.

Če pa so zunanji naslovi znani, bo povezava zlahka vzpostavljena. Če prvo vozlišče pošlje podatke usmerjevalniku drugega vozlišča, jih bo ta prezrl, saj je njegova tabela NAT še prazna. Vendar se je v usmerjevalniku prvega vozlišča v tabeli NAT pojavil potreben vnos. Če zdaj drugo vozlišče pošlje podatke usmerjevalniku prvega vozlišča, jih bo usmerjevalnik uspešno prenesel na prvo vozlišče. Zdaj ima tabela NAT drugega usmerjevalnika tudi potrebne podatke.

Težava je v tem, da za iskanje zunanjega naslova IP potrebujete vozlišče, ki se nahaja v skupno omrežje. Za rešitev te težave se uporabljajo dodatni strežniki, ki so neposredno povezani z internetom. Z njihovo pomočjo se ustvarijo tudi dragoceni vnosi v tabeli NAT.

Strežnika STUN in TURN

Pri inicializaciji WebRTC morate določiti razpoložljiva strežnika STUN in TURN, ki ju bomo odslej imenovali strežnika ICE. Če strežniki niso določeni, se bodo lahko povezala samo vozlišča v istem omrežju (z njim povezana brez NAT). Takoj velja omeniti, da je za omrežja 3g obvezna uporaba strežnikov TURN.

OMAMLJENJE strežnik je preprosto strežnik na internetu, ki vrne povratni naslov, to je naslov vozlišča pošiljatelja. Gostitelj za usmerjevalnikom vzpostavi stik s strežnikom STUN, da prečka NAT. Paket, ki je prišel na strežnik STUN, vsebuje izvorni naslov - naslov usmerjevalnika, to je zunanji naslov našega vozlišča. To je naslov STUN, ki ga strežnik pošlje nazaj. Tako vozlišče prejme svoj zunanji naslov IP in vrata, prek katerih je dostopno iz omrežja. Nato WebRTC uporabi ta naslov za ustvarjanje dodatnega kandidata (naslov zunanjega usmerjevalnika in vrata). Zdaj je v tabeli NAT usmerjevalnika vnos, ki omogoča, da paketi, poslani usmerjevalniku na zahtevanih vratih, dosežejo naše vozlišče.

Oglejmo si ta postopek na primeru.

Primer (delovanje strežnika STUN)

Strežnik STUN bo označen s s1. Usmerjevalnik je kot prej skozi r1, vozlišče pa skozi p1. Prav tako boste morali spremljati tabelo NAT - označili jo bomo kot r1_nat. Poleg tega ta tabela običajno vsebuje veliko zapisov iz različnih vozlišč podomrežja - ne bodo podani.

Torej, na začetku imamo prazno tabelo r1_nat.

Tabela 2: Glava paketa

Vozlišče p1 pošlje ta paket usmerjevalniku r1 (ne glede na to, kako lahko različna podomrežja uporabljajo različne tehnologije). Usmerjevalnik mora zamenjati izvorni naslov Src IP, saj naslov, naveden v paketu, očitno ni primeren za zunanje podomrežje, poleg tega so naslovi iz takega obsega rezervirani in niti en naslov na internetu nima takega naslova. Usmerjevalnik naredi zamenjavo v paketu in ustvari nov vnos v vaši tabeli r1_nat. Za to mora najti številko vrat. Spomnimo se, da ker lahko več gostiteljev znotraj podomrežja dostopa do zunanjega omrežja, mora tabela NAT shraniti Dodatne informacije, tako da lahko usmerjevalnik določi, katero od teh več vozlišč je namenjenih za povratni paket s strežnika. Naj usmerjevalnik pripravi vrata 888.

Spremenjena glava paketa:

Tabela 4: Tabela NAT je bila posodobljena z novim vnosom

Tu sta naslov IP in vrata za podomrežje popolnoma enaka izvirnemu paketu. Pravzaprav moramo pri postbackingu imeti način, da jih popolnoma obnovimo. Naslov IP za zunanje omrežje je naslov usmerjevalnika, vrata pa so se spremenila v tista, ki si jih je izmislil usmerjevalnik.

Prava vrata, na katerih vozlišče p1 sprejme povezavo, so seveda 35777, vendar strežnik pošilja podatke na izmišljena vrata 888, ki jih bo usmerjevalnik spremenil v pravih 35777.

Tako je usmerjevalnik zamenjal izvorni naslov in vrata v glavi paketa ter dodal vnos v tabelo NAT. Zdaj je paket poslan preko omrežja na strežnik, to je vozlišče s1. Na vhodu ima s1 naslednji paket:

Src IP Src PORT Ciljni IP Ciljni PORT

10.50.200.5	888	12.62.100.200	6000

Tabela 5: Strežnik STUN je prejel paket

V celoti strežnik STUN ve, da je prejel paket z naslova 10.50.200.5:888. Zdaj strežnik pošlje ta naslov nazaj. Tu se je vredno ustaviti in si še enkrat ogledati, kar smo pravkar pogledali. Zgornje tabele so delček iz glava paket, sploh ne iz njega vsebino. O vsebini nismo govorili, saj ni tako pomembna - nekako je opisana v protokolu STUN. Zdaj bomo poleg naslova upoštevali tudi vsebino. Preprost bo in bo vseboval naslov usmerjevalnika - 10.50.200.5:888, čeprav smo ga vzeli iz glava paket. To se ne zgodi pogosto; protokoli običajno ne skrbijo za informacije o naslovih vozlišč; pomembno je le, da so paketi dostavljeni na predvideno destinacijo. Tukaj gledamo protokol, ki vzpostavi pot med dvema vozliščema.

Zdaj imamo drugi paket, ki gre v nasprotno smer:

Tabela 7: Strežnik STUN pošlje paket s to vsebino

Nato paket potuje po omrežju, dokler ne doseže zunanjega vmesnika usmerjevalnika r1. Usmerjevalnik razume, da paket ni namenjen njemu. Kako on to razume? To lahko določi le pristanišče. Port 888 ne uporablja za svoje osebne namene, ampak ga uporablja za mehanizem NAT. Zato usmerjevalnik pogleda to tabelo. Pogleda stolpec External PORT in poišče vrstico, ki se ujema s ciljnim PORTom iz dohodnega paketa, to je 888.

Notranji IP Notranja PORT Zunanji IP Zunanja PORT

192.168.0.200	35777	10.50.200.5	888

Tabela 8: Tabela NAT

Imamo srečo, taka linija obstaja. Če ne bi imeli sreče, bi paket preprosto zavrgli. Zdaj morate razumeti, katero vozlišče v podomrežju naj pošlje ta paket. Ni treba hiteti, spet se spomnimo pomena vrat v tem mehanizmu. Istočasno lahko dve vozlišči v podomrežju pošiljata zahteve zunanjemu omrežju. Potem, če bi usmerjevalnik za prvo vozlišče dobil vrata 888, bi za drugo dobil vrata 889. Predpostavimo, da se je to zgodilo, to pomeni, da je tabela r1_nat videti takole:

Tabela 10: Usmerjevalnik zamenja naslov prejemnika

Src IP Src PORT Ciljni IP Ciljni PORT

12.62.100.200	6000	192.168.0.200	35777

Tabela 11: Usmerjevalnik je spremenil naslov prejemnika

Paket uspešno prispe do vozlišča p1 in ob vpogledu v vsebino paketa vozlišče izve svoj zunanji IP naslov, to je naslov usmerjevalnika v zunanjem omrežju. Pozna tudi vrata, ki jih usmerjevalnik vodi skozi NAT.

Kaj je naslednje? Kakšna je korist od vsega tega? Ugodnost je vnos v tabeli r1_nat. Če zdaj kdorkoli pošlje paket z vrati 888 usmerjevalniku r1, bo usmerjevalnik ta paket posredoval vozlišču p1. To je ustvarilo majhen ozek prehod do skritega vozlišča p1.

Iz zgornjega primera lahko dobite nekaj predstave o tem, kako deluje NAT in o bistvu strežnika STUN. Na splošno so mehanizem ICE in strežniki STUN/TURN natančno usmerjeni v premagovanje omejitev NAT.

Med vozliščem in strežnikom ne more biti en usmerjevalnik, ampak več. V tem primeru bo vozlišče prejelo naslov usmerjevalnika, ki prvi dostopa do istega omrežja kot strežnik. Z drugimi besedami, dobili bomo naslov usmerjevalnika, ki je povezan s strežnikom STUN. Za p2p komunikacijo je to točno tisto, kar potrebujemo, če ne pozabimo, da bo vsak usmerjevalnik v NAT tabelo dodal vrstico, ki jo potrebujemo. Zato bo pot nazaj spet enako gladka.

Strežnik TURN je izboljšan strežnik STUN. Od tu morate takoj ugotoviti, da lahko vsak strežnik TURN deluje tudi kot strežnik STUN. Vendar pa obstajajo tudi prednosti. Če komunikacija p2p ni mogoča (kot na primer v omrežjih 3g), potem strežnik preklopi v relejni način, torej deluje kot posrednik. Seveda ne govorimo o nobenem p2p, vendar zunaj mehanizma ICE vozlišča mislijo, da komunicirajo neposredno.

V katerih primerih je potreben strežnik TURN? Zakaj ni dovolj strežnika STUN? Dejstvo je, da obstaja več vrst NAT. Na enak način nadomestijo naslov IP in vrata, le da imajo nekateri vgrajeno dodatno zaščito pred »ponarejanjem«. Na primer, v simetrično V tabeli NAT sta shranjena še 2 parametra - IP in vrata oddaljenega gostitelja. Paket iz zunanjega omrežja gre skozi NAT v notranje omrežje le, če se izvorni naslov in vrata ujemajo s tistima, zapisanima v tabeli. Zato trik s strežnikom STUN ne uspe - tabela NAT shrani naslov in vrata strežnika STUN in ko usmerjevalnik prejme paket od sogovornika WebRTC, ga zavrže, ker je "ponarejen". Ni prišel s strežnika STUN.

Tako je TURN strežnik potreben v primeru, ko sta oba sogovornika zadaj simetrično NAT (vsak po svoje).

Kratek povzetek

Tukaj je nekaj izjav o entitetah WebRTC, ki jih morate vedno imeti v mislih. Podrobno so opisani zgoraj. Če se vam katera od trditev ne zdi povsem jasna, ponovno preberite ustrezne odstavke.

• Medijski tok
  • Video in zvočni podatki so pakirani v medijske tokove
  • Medijski tokovi sinhronizirajo predstavnostne skladbe, ki sestavljajo
  • Različni medijski tokovi niso sinhronizirani med seboj
  • Medijski tokovi so lahko lokalni in oddaljeni, lokalni je običajno povezan s kamero in mikrofonom, oddaljeni prejemajo podatke iz omrežja v šifrirani obliki
  • Obstajata dve vrsti medijskih posnetkov - za video in za zvok.
  • Medijske skladbe imajo možnost vklopa/izklopa
  • Medijske skladbe sestavljajo medijski kanali
  • Medijske skladbe sinhronizirajo medijske kanale, ki sestavljajo
  • Medijski tokovi in ​​medijske sledi imajo oznake, po katerih jih je mogoče razlikovati
• Ročaj seje
  • Deskriptor seje se uporablja za logično povezovanje dveh omrežnih vozlišč
  • Deskriptor seje hrani informacije o razpoložljive načine kodiranje video in avdio podatkov
  • WebRTC uporablja zunanji mehanizem signalizacije - naloga posredovanja deskriptorjev seje (sdp) je v rokah aplikacije
  • Mehanizem logične povezave je sestavljen iz dveh stopenj - ponudbe (ponudba) in odgovora (odgovor).
  • Generiranje deskriptorja seje je nemogoče brez uporabe lokalnega medijskega toka v primeru ponudbe in brez uporabe deskriptorja oddaljene seje v primeru odgovora.
  • Nastali deskriptor je treba dati implementaciji WebRTC in ni pomembno, ali je ta deskriptor prejet na daljavo ali lokalno iz iste implementacije WebRTC
  • Deskriptor seje je mogoče nekoliko urediti
• Kandidati
  • Ice kandidat je naslov vozlišča v omrežju
  • Naslov vozlišča je lahko vaš ali pa je lahko naslov usmerjevalnika ali strežnika TURN
  • Kandidatov je vedno veliko
  • Kandidat je sestavljen iz naslova IP, vrat in vrste transporta (TCP ali UDP)
  • Kandidati se uporabljajo za vzpostavitev fizične povezave med dvema vozliščema v omrežju
  • Kandidate je treba poslati tudi prek signalnega mehanizma
  • Kandidate je treba prenesti tudi na implementacije WebRTC, a le na oddaljene
  • V nekaterih izvedbah WebRTC je mogoče kandidate prenesti šele, ko je nastavljen deskriptor seje
• OMAMLJENJE/OBRAT/LED/NAT
  • NAT je mehanizem za zagotavljanje dostopa do zunanjega omrežja
  • Domači usmerjevalniki podpirajo posebno tabelo NAT
  • Usmerjevalnik zamenja naslove v paketih - izvorni naslov s svojim, če gre paket v zunanje omrežje, naslov prejemnika pa z naslovom gostitelja v notranjem omrežju, če je paket prišel iz zunanjega omrežja.
  • Za zagotavljanje večkanalnega dostopa do zunanjega omrežja NAT uporablja vrata
  • ICE - NAT Traversal Engine
  • Strežnika STUN in TURN – pomočnika za prečkanje NAT
  • Strežnik STUN omogoča ustvarjanje potrebnih vnosov v tabeli NAT in vrne tudi zunanji naslov gostitelja
  • Strežnik TURN posplošuje mehanizem STUN in poskrbi, da vedno deluje
  • V najslabšem primeru se strežnik TURN uporabi kot posrednik (rele), to pomeni, da se p2p spremeni v povezavo odjemalec-strežnik-odjemalec.

Danes je WebRTC »vroča« tehnologija za pretakanje zvoka in videa v brskalnikih. Konzervativne tehnologije, kot sta HTTP Streaming in Flash, so bolj primerne za distribucijo posnetih vsebin (video na zahtevo) in so bistveno slabše od WebRTC glede realnega časa in spletnih oddaj, tj. kjer je potrebna minimalna zakasnitev videa, da lahko gledalci vidijo, kaj se dogaja "v živo".

Možnost kakovostne komunikacije v realnem času izhaja iz same arhitekture WebRTC, kjer se za prenos video tokov uporablja protokol UDP, ki je standardna osnova za prenos videa z minimalnimi zakasnitvami in se pogosto uporablja v komunikacijskih sistemih v realnem času.

Komunikacijska zakasnitev je pomembna v sistemih spletnega oddajanja, spletnih seminarjih in drugih aplikacijah, ki zahtevajo interaktivno komunikacijo z video virom, končnimi uporabniki in zahtevajo rešitev.

Še en dober razlog za preizkus WebRTC je ta, da je vsekakor trend. Danes vsak Android Brskalnik Chrome podpira to tehnologijo, ki zagotavlja na milijone naprav pripravljenih za gledanje oddajanja brez namestitve dodatne programske opreme ali konfiguracij.

Da bi preizkusili tehnologijo WebRTC v akciji in zagnali preprosto spletno oddajanje, smo uporabili strežniško programsko opremo Flashphoner WebRTC Media & Broadcasting Server. Funkcije navajajo zmožnost oddajanja tokov WebRTC v načinu enega proti več, kot tudi podporo za kamere IP in sisteme video nadzora prek protokola RTSP; V tem pregledu se bomo osredotočili na spletne oddaje in njihove značilnosti.

Namestitev strežnika WebRTC Media & Broadcasting Server

Ker za Windows sistemi ni bilo nobene različice strežnika in nisem želel namestiti virtualnega stroja, kot je VMWare+Linux, zato sem lahko preizkusil spletne oddaje doma Windows računalnik Ni uspelo. Da bi prihranili čas, smo se odločili vzeti primerek gostovanja v oblaku, kot je ta:

Šlo je za Centos x86_64 različice 6.5 brez prednameščene programske opreme v amsterdamskem podatkovnem centru. Tako imamo na razpolago samo strežnik in ssh dostop do njega. Za tiste, ki poznajo ukazi konzole Linux, namestitev strežnika WebRTC obljublja, da bo preprosta in neboleča. Torej, kaj smo naredili:

1. Prenesite arhiv:

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

2. Razpakirajte:

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

3. Namestite:

$cd FlashphonerWebCallServer

Med namestitvijo vnesite naslov IP strežnika: XXX.XXX.XXX.XXX

4. Aktivirajte licenco:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Zaženite strežnik WCS:

$service webcallserver start

6. Preverite dnevnik:

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

7. Preverite, ali sta oba postopka vzpostavljena:

$ps aux | grep Flashphoner

Postopek namestitve je končan.

Testiranje spletnih oddaj WebRTC

Testiranje oddaj se je izkazalo za preprosto zadevo. Poleg strežnika obstaja spletni odjemalec, ki je sestavljen iz ducata datotek Javascript, HTML in CSS in smo ga med namestitvijo namestili v mapo /var/www/html. Edina stvar, ki jo je bilo treba storiti, je vnesti naslov IP strežnika v konfiguracijo flashphoner.xml, da lahko spletni odjemalec vzpostavi povezavo s strežnikom prek HTML5 Websockets. Opišimo postopek testiranja.

1. Odprite stran testnega odjemalca index.html v brskalniku Chrome:

2. Če želite začeti oddajanje, morate klikniti gumb »Začni« na sredini zaslona.
Preden to storite, se morate prepričati, da je spletna kamera povezana in pripravljena za uporabo. Za spletno kamero ni posebnih zahtev, uporabili smo na primer standardno kamero, vgrajeno v prenosnik z ločljivostjo 1280x800.

Brskalnik Chrome bo zagotovo zahteval dostop do kamere in mikrofona, da bo uporabnik razumel, da bo njegov videoposnetek poslan na internetni strežnik in to dovolil.

3. Vmesnik predstavlja uspešno oddajanje video toka iz kamere na strežnik WebRTC. V zgornjem desnem kotu indikator označuje, da gre tok na strežnik; v spodnjem kotu je gumb »Ustavi« za ustavitev pošiljanja videa.

Upoštevajte povezavo v spodnjem polju. Vsebuje edinstven identifikator za ta tok, tako da se lahko kdorkoli pridruži ogledu. Samo odprite to povezavo v brskalniku. Če ga želite kopirati v odložišče, kliknite gumb »Kopiraj«.

V resničnih aplikacijah, kot so spletni seminarji, predavanja, spletni video prenosi ali interaktivna TV, bodo morali razvijalci implementirati distribucijo tega identifikatorja določenim skupinam gledalcev, da se bodo lahko povezali z želenimi tokovi, a to je že logika aplikacije . WebRTC Media & Broadcasting Server nanj ne vpliva, ampak samo distribuira video.

5. Povezava je vzpostavljena in gledalec vidi tok na zaslonu. Zdaj lahko pošlje povezavo nekomu drugemu, ustavi predvajanje toka ali omogoči celozaslonski način s kontrolniki v spodnjem desnem kotu.

Rezultati testiranja spletnega oddajnega strežnika WebRTC

Med preizkusi se je zakasnitev zdela popolna. Ping do podatkovnega centra je bil približno 100 milisekund in zakasnitev je bila očesu nevidna. Od tu lahko domnevamo, da je dejanska zakasnitev istih 100 plus ali minus nekaj deset milisekund za čas medpomnjenja. V primerjavi z videoposnetki Flash: v takih testih se Flash ne obnaša tako dobro kot WebRTC. Torej, če premaknete roko na podobnem omrežju, je gibanje na zaslonu vidno šele po eni ali dveh sekundah.

Glede kakovosti ugotavljamo, da se kocke včasih razlikujejo po premikih. To je skladno z naravo kodeka VP8 in njegovim glavnim namenom - zagotoviti video komunikacijo v realnem času s sprejemljivo kakovostjo in brez komunikacijskih zamud.

Strežnik je dokaj enostaven za namestitev in konfiguracijo, njegovo poganjanje ne zahteva nobenih resnih veščin razen poznavanja Linuxa na ravni naprednega uporabnika, ki zna izvajati ukaze iz konzole preko ssh in uporabljati urejevalnik besedil. Posledično nam je uspelo vzpostaviti spletno oddajanje ena proti več med brskalniki. Tudi priklop dodatnih gledalcev na tok ni predstavljal težav.

Kakovost oddajanja se je izkazala za povsem sprejemljivo za spletne seminarje in spletne oddaje. Edina stvar, ki je sprožila nekaj vprašanj, je bila ločljivost videa. Kamera podpira ločljivost 1280x800, vendar je ločljivost na testni sliki zelo podobna 640x480. Očitno je treba to vprašanje razjasniti z razvijalci.

Videoposnetek o testiranju, predvajan s spletne kamere
prek strežnika WebRTC

Tehnologije za klicanje iz brskalnika obstajajo že vrsto let: Java, ActiveX, Adobe Flash...V zadnjih nekaj letih je postalo jasno, da so vtičniki ostali virtualni stroji Ne blestijo s priročnostjo (zakaj bi sploh kaj namestil?) in, kar je najpomembneje, z varnostjo. Kaj storiti? Obstaja izhod!

Do nedavnega so omrežja IP uporabljala več protokolov za IP telefonijo ali video: SIP, najpogostejši protokol, H.323 in MGCP, ki prihajata na sceno, Jabber/Jingle (uporablja se v Gtalku), polodprti Adobe RTMP* in seveda , zaprt Skype. Projekt WebRTC, ki ga je sprožil Google, poskuša spremeniti stanje v svetu IP in spletne telefonije ter programski telefoni, vključno s Skypeom. WebRTC ne izvaja le vseh komunikacijskih zmožnosti neposredno v brskalniku, ki je danes nameščen na skoraj vsaki napravi, temveč skuša hkrati rešiti tudi splošnejši problem komunikacije med uporabniki brskalnika (izmenjava različnih podatkov, oddajanje zaslona, ​​sodelovanje z dokumenti itd.). veliko več).

WebRTC z vidika spletnega razvijalca

Z vidika spletnega razvijalca je WebRTC sestavljen iz dveh glavnih delov:

• nadzor medijskih tokov iz lokalnih virov (kamera, mikrofon ali zaslon lokalni računalnik) izvaja metoda navigator.getUserMedia, ki vrne objekt MediaStream;
• komunikacija enakovrednih med napravami, ki generirajo medijske tokove, vključno z definiranjem komunikacijskih metod in njihovim neposrednim prenosom - objekti RTCPeerConnection (za pošiljanje in sprejemanje avdio in video tokov) in RTCDataChannel (za pošiljanje in prejemanje podatkov iz brskalnika).

Kaj počnemo?

Ugotovili bomo, kako organizirati preprost večuporabniški video klepet med brskalniki, ki temeljijo na WebRTC z uporabo spletnih vtičnic. Eksperimentirati bomo začeli v Chromu/Chromiumu, kot najnaprednejših brskalnikih glede WebRTC, čeprav ju je Firefox 22, ki je izšel 24. junija, že skoraj dohitel. Povedati je treba, da standard še ni bil sprejet, API pa se lahko spreminja od različice do različice. Vsi primeri so bili testirani v Chromiumu 28. Zaradi poenostavitve ne bomo spremljali čistosti kode in združljivosti med brskalniki.

MediaStream

Prva in najpreprostejša komponenta WebRTC je MediaStream. Brskalniku omogoča dostop do medijskih tokov iz kamere in mikrofona lokalnega računalnika. V Chromu morate za to poklicati funkcijo navigator.webkitGetUserMedia() (ker standard še ni dokončan, imajo vse funkcije predpono, v Firefoxu pa se ista funkcija imenuje navigator.mozGetUserMedia()). Ko ga pokličete, bo uporabnik pozvan, da dovoli dostop do kamere in mikrofona. Nadaljevanje klica bo možno šele, ko uporabnik poda soglasje. Parametri zahtevanega medijskega toka in dve funkciji za povratni klic se posredujejo kot parametri tej funkciji: prva bo poklicana, če je uspešno pridobljen dostop do kamere/mikrofona, druga pa v primeru napake. Najprej ustvarimo datoteko HTML rtctest1.html z gumbom in elementom:

WebRTC – prvi predstavitveni video (višina: 240 slikovnih pik; širina: 320 slikovnih pik; obroba: 1 slikovna pika polno siva; ) getUserMedia

Microsoft CU-RTC-Web

Microsoft ne bi bil Microsoft, če se ne bi takoj odzval na Googlovo pobudo z izdajo lastne nezdružljive nestandardne možnosti, imenovane CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Čeprav delež IE, ki je že tako majhen, še naprej upada, število uporabnikov Skypa daje Microsoftu upanje, da bo izpodrinil Google, in lahko domnevamo, da bo ta standard uporabljen v brskalniku Skype različice. Googlov standard je osredotočen predvsem na komunikacijo med brskalniki; hkrati pa večina govornega prometa še vedno ostaja v navadnem telefonskem omrežju, prehodi med njim in IP omrežji pa so potrebni ne le zaradi lažje uporabe ali hitrejše distribucije, temveč tudi kot sredstvo monetizacije, ki bo več igralcem omogočila jih razvijati. Pojav drugega standarda morda ne bo povzročil le neprijetne potrebe razvijalcev, da podpirajo dve nezdružljivi tehnologiji hkrati, temveč bo v prihodnosti uporabniku omogočil večjo izbiro možnih funkcionalnosti in razpoložljivih tehničnih rešitev. Počakaj in boš videl.

Omogočanje lokalnega toka

Znotraj oznak naše datoteke HTML deklarirajmo globalno spremenljivko za medijski tok:

Var localStream = null;

Prvi parameter metode getUserMedia mora podati parametre zahtevanega medijskega toka - na primer, preprosto omogočite zvok ali video:

Var streamConstraints = ("avdio": resnično, "video": resnično); // Zahtevajte dostop do zvoka in videa

Ali pa določite dodatne parametre:

Var streamConstraints = ( "audio": true, "video": ( "obvezno": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "izbirno": ) );

Drugi parameter metode getUserMedia je treba posredovati funkciji povratnega klica, ki bo poklicana, če bo uspešna:

Funkcija getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Povežite predstavnostni tok z elementom HTML localStream = stream; // in ga shranite v globalni spremenljivki za nadaljnjo uporabo)

Tretji parameter je funkcija povratnega klica, obravnavalec napak, ki bo poklican v primeru napake

Funkcija getUserMedia_error(error) ( console.log("getUserMedia_error():", napaka); )

Dejanski klic metode getUserMedia je zahteva za dostop do mikrofona in kamere, ko pritisnete prvi gumb

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

Do medijskega toka ni mogoče dostopati iz datoteke, ki je odprta lokalno. Če poskusimo to narediti, bomo dobili napako:

NavigatorUserMediaError (koda: 1, PERMISSION_DENIED: 1)"

Naložimo nastalo datoteko na strežnik, jo odpremo v brskalniku in kot odgovor na prikazano zahtevo dovolimo dostop do kamere in mikrofona.

Naprave, do katerih bo Chrome imel dostop, lahko izberete v nastavitvah, Prikaži povezavo naprednih nastavitev, razdelek Zasebnost, gumb Vsebina. V brskalnikih Firefox in Opera se naprave izberejo s spustnega seznama neposredno, ko je dostop dovoljen.

Pri uporabi protokola HTTP bo dovoljenje zahtevano ob vsakem dostopu do medijskega toka po nalaganju strani. Preklop na HTTPS vam bo omogočil, da zahtevo prikažete enkrat, le ob prvem dostopu do medijskega toka.

Opazite utripajoč krog v ikoni zaznamka in ikono kamere na desni strani naslovne vrstice:

RTCMediaConnection

RTCMediaConnection je objekt, zasnovan za vzpostavitev in prenos medijskih tokov po omrežju med udeleženci. Poleg tega je ta objekt odgovoren za generiranje opisa medijske seje (SDP), pridobivanje informacij o ICE kandidatih za prečkanje NAT oz. požarni zidovi(lokalno in z uporabo STUN) in interakcijo s strežnikom TURN. Vsak udeleženec mora imeti eno RTCMediaConnection na povezavo. Medijski tokovi se prenašajo z uporabo šifriranega protokola SRTP.

TURN strežniki

Obstajajo tri vrste kandidatov ICE: gostitelj, srflx in rele. Host vsebuje informacije, prejete lokalno, srflx - kako je vozlišče videti zunanjemu strežniku (STUN) in rele - informacije za proxy promet prek strežnika TURN. Če je naše vozlišče za NAT, bodo kandidati za gostitelje vsebovali lokalne naslove in bodo neuporabni, kandidati za srflx bodo pomagali samo pri določenih vrstah NAT, rele pa bo zadnje upanje za prenos prometa skozi vmesni strežnik.

Primer kandidata ICE tipa host z naslovom 192.168.1.37 in vrati udp/34022:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 tip generacija gostitelja 0

Splošni format za določanje strežnikov STUN/TURN:

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

Na internetu je veliko javnih strežnikov STUN. Obstaja velik seznam, npr. Žal rešujejo premalo problemov. Za razliko od STUN-a javnih strežnikov TURN praktično ni. To je posledica dejstva, da strežnik TURN prehaja skozi medijske tokove, kar lahko znatno obremeni tako omrežni kanal kot sam strežnik. Zato je najlažji način za povezavo s strežniki TURN ta, da ga namestite sami (očitno boste potrebovali javni IP). Od vseh strežnikov je po mojem mnenju najboljši rfc5766-turn-server. Obstaja celo že pripravljena slika za Amazon EC2.

S TURN ni vse tako dobro, kot bi si želeli, vendar je aktiven razvoj v teku in upam, da bo čez nekaj časa WebRTC, če ne enak Skypeu v smislu kakovosti prehoda skozi prevajanje naslovov (NAT) in požarne zidove , se bo vsaj opazno približal.

RTCMediaConnection zahteva dodaten mehanizem za izmenjavo nadzornih informacij za vzpostavitev povezave - čeprav te podatke generira, jih ne posreduje, prenos drugim udeležencem pa mora biti izveden ločeno.

Izbira načina prenosa je prepuščena razvijalcu - vsaj ročno. Takoj, ko pride do izmenjave potrebnih podatkov, bo RTCMediaConnection samodejno namestil medijske tokove (seveda, če je to mogoče).

model ponudba-odgovor

Za vzpostavitev in spreminjanje medijskih tokov se uporabljata model ponudbe/odgovora (opisan v RFC3264) in SDP (Session Description Protocol). Uporablja jih tudi protokol SIP. V tem modelu sta dva agenta: Ponudnik - tisti, ki generira opis SDP seje, da ustvari novega ali spremeni obstoječega (Ponudba SDP), in Answerer - tisti, ki prejme opis SDP seje od drugega agenta in se odzove s svojim opisom seje (Odgovor SDP). Hkrati specifikacija zahteva protokol višje ravni (na primer SIP ali lasten over web sockets, kot v našem primeru), ki je odgovoren za prenos SDP med agenti.

Katere podatke je treba posredovati med dvema RTCMediaConnections, da lahko uspešno vzpostavita medijske tokove:

• Prvi udeleženec, ki vzpostavi povezavo, oblikuje ponudbo, v kateri posreduje podatkovno strukturo SDP (isti protokol se uporablja za isti namen v SIP), ki opisuje možne značilnosti medijskega toka, ki ga bo začel prenašati. Ta blok podatkov je treba prenesti na drugega udeleženca. Drugi udeleženec oblikuje odgovor s svojim SDP in ga pošlje prvemu.
• Tako prvi kot drugi udeleženec izvajata postopek določanja možnih ICE kandidatov, s pomočjo katerega jima lahko drugi udeleženec posreduje medijski tok. Ko so kandidati identificirani, je treba informacije o njih posredovati drugemu udeležencu.

Ponudba za oblikovanje

Za ustvarjanje ponudbe potrebujemo dve funkciji. Prvi bo poklican, če bo uspešno oblikovan. Drugi parameter metode createOffer() je funkcija povratnega klica, ki se kliče v primeru napake med njenim izvajanjem (pod pogojem, da je lokalna nit že na voljo).

Poleg tega sta potrebna dva obdelovalca dogodkov: onicecandidate pri definiranju novega kandidata ICE in onaddstream pri povezovanju medijskega toka z oddaljene strani. Vrnimo se k naši datoteki. Dodajmo še eno v HTML za vrsticami z elementi:

createOffer

In za vrstico z elementom (za prihodnost):

Tudi na začetku kode JavaScript bomo deklarirali globalno spremenljivko za RTCPeerConnection:

Var pc1;

Pri klicu konstruktorja RTCPeerConnection morate podati strežnike STUN/TURN. Za več informacij o njih glejte stransko vrstico; dokler so vsi udeleženci v istem omrežju, niso potrebni.

Var strežniki = nič;

Parametri za pripravo SDP ponudbe

Var offerConstraints = ();

Prvi parameter metode createOffer() je funkcija povratnega klica, ki se prikliče po uspešnem oblikovanju ponudbe

Funkcija pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Nastavi povezavo RTCPeerConnection, ki jo ustvari Offer SDP z uporabo metode setLocalDescription. // Ko oddaljena stran pošlje svoj odgovor SDP, ga bo treba nastaviti z metodo setRemoteDescription // Dokler druga stran ni implementirana, ne naredimo ničesar // pc2_receivedOffer(desc); )

Drugi parameter je funkcija povratnega klica, ki bo poklicana v primeru napake

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

In deklarirajmo funkcijo povratnega klica, ki ji bodo kandidati ICE posredovani, ko bodo določeni:

Funkcija pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Dokler ni implementirana druga stran, ne naredimo ničesar // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

In tudi funkcija povratnega klica za dodajanje medijskega toka z oddaljene strani (za prihodnost, saj imamo trenutno samo eno RTCPeerConnection):

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

Ko kliknete na gumb “createOffer”, bomo ustvarili RTCPeerConnection, nastavili metodi onicecandidate in onaddstream ter zahtevali oblikovanje ponudbe SDP s klicem metode createOffer():

Funkcija createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Ustvari RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Funkcija povratnega klica za obdelavo kandidatov ICE pc1.onaddstream = pc1_onaddstream; // Funkcija povratnega klica, ki se prikliče, ko se medijski tok pojavi na oddaljeni strani. Ni še nobenega pc1.addStream(localStream); // Prenesimo lokalni medijski tok (ob predpostavki, da je že prejet) pc1.createOffer(// In dejansko zahtevamo oblikovanje ponudbe pc1_createOffer_success, pc1_createOffer_error, offerConstraints); )

Datoteko shranimo kot rtctest2.html, jo naložimo na strežnik, odpremo v brskalniku in v konzoli poglejmo, kateri podatki nastanejo med njenim delovanjem. Drugi video še ne bo prikazan, ker je samo en udeleženec. Spomnimo se, da je SDP opis parametrov medijske seje, razpoložljivi kodeki, medijski tokovi in ​​kandidati ICE so možne možnosti za povezavo z določenim udeležencem.

Oblikovanje Answer SDP in izmenjava kandidatov ICE

Oba SDP ponudbe in vsakega od kandidatov ICE je treba prenesti na drugo stran in tam, potem ko jih prejme, RTCPeerConnection pokliče metode setRemoteDescription za SDP ponudbe in addIceCandidate za vsakega kandidata ICE, prejetega z oddaljene strani; podobno v hrbtna stran za Answer SDP in oddaljene kandidate ICE. Sam Odgovor SDP je oblikovan podobno kot Ponudba; razlika je v tem, da se ne kliče metoda createOffer, ampak metoda createAnswer, pred tem pa se metoda RTCPeerConnection setRemoteDescription posreduje ponudbi SDP, prejeti od klicatelja.

Dodajmo še en video element v HTML:

In globalna spremenljivka za drugo RTCPeerConnection pod deklaracijo prve:

Var pc2;

Obdelava ponudbe in odgovora SDP

Oblikovanje Answer SDP je zelo podobno Ponudbi. V funkciji povratnega klica, ki se prikliče ob uspešnem oblikovanju odgovora, bomo podobno kot pri ponudbi podali lokalni opis in posredovali prejeti SDP odgovora prvemu udeležencu:

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

Funkcija povratnega klica, ki jo prikličemo v primeru napake pri generiranju odgovora, je popolnoma podobna ponudbi:

Funkcija pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", napaka); )

Parametri za oblikovanje SDP odgovora:

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

Ko drugi udeleženec prejme ponudbo, bomo ustvarili RTCPeerConnection in oblikovali odgovor na enak način kot ponudbo:

Funkcija pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Ustvarite objekt RTCPeerConnection za drugega udeleženca na enak način kot prvega pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate ; // Nastavi obdelovalnik dogodkov, ko se pojavi kandidat ICE pc2.onaddstream = pc_onaddstream; // Ko se pojavi tok, ga poveži s HTML pc2.addStream(localStream); // Prenesi lokalni medijski tok (v našem primeru drugi udeleženec ima enako kot prvi) // Zdaj, ko je druga RTCPeerConnection pripravljena, ji bomo posredovali prejeto ponudbo SDP (prvemu smo posredovali lokalni tok) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Zahtevaj drugo povezavo za ustvarjanje podatkov za sporočilo odgovora pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Da bi prenesli SDP ponudbe od prvega udeleženca do drugega v našem primeru, jo odkomentirajmo v funkciji pc1 createOffer klicna vrstica success():

Pc2_receivedOffer(desc);

Za izvedbo obdelave kandidatov ICE odkomentirajmo v obdelovalcu dogodka pripravljenosti kandidata ICE prvega udeleženca pc1_onicecandidate() njegov prenos na drugega:

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

Obravnavalec dogodka pripravljenosti kandidata ICE drugega udeleženca je zrcalno podoben prvemu:

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

Funkcija povratnega klica za dodajanje medijskega toka od prvega udeleženca:

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

Prekinitev povezave

Dodajmo še en gumb v HTML

Prekiniti

In funkcija za prekinitev povezave

Funkcija btnHangupClick() ( // Prekini povezavo lokalnega videa z elementi HTML, ustavi lokalni medijski tok, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Za vsakega udeleženca onemogoči video iz HTML elementi, zaprite povezavo, nastavite kazalec = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Shranimo ga kot rtctest3.html, naložimo na strežnik in odpremo v brskalniku. Ta primer izvaja dvosmerni prenos medijskih tokov med dvema povezavama RTCPeerConnection znotraj istega zavihka brskalnika. Za organizacijo izmenjave ponudb in odgovorov SDP, kandidatov ICE med udeleženci in drugih informacij prek omrežja bo namesto neposrednih klicnih postopkov potrebno izvesti izmenjavo med udeleženci z uporabo neke vrste transporta, v našem primeru - spletnih vtičnic.

Oddaja zaslona

Funkcija getUserMedia lahko tudi zajame zaslon in pretaka kot MediaStream, tako da poda naslednje parametre:

Var mediaStreamConstraints = ( zvok: false, video: ( obvezno: ( chromeMediaSource: "zaslon"), izbirno: ) );

Za uspešen dostop do zaslona mora biti izpolnjenih več pogojev:

• omogoči zastavico posnetka zaslona v getUserMedia() v chrome://flags/,chrome://flags/;
• izvorno datoteko je treba prenesti prek HTTPS (izvor SSL);
• zvočni tok se ne sme zahtevati;
• Na enem zavihku brskalnika se ne sme izvajati več zahtev.

Knjižnice za WebRTC

Čeprav WebRTC še ni končan, se je že pojavilo več knjižnic, ki temeljijo na njem. JsSIP je zasnovan za ustvarjanje programskih telefonov, ki temeljijo na brskalniku in delujejo s stikali SIP, kot sta Asterisk in Camalio. PeerJS bo olajšal ustvarjanje omrežij P2P za izmenjavo podatkov, Holla pa bo zmanjšala obseg razvoja, ki je potreben za komunikacije P2P iz brskalnikov.

Node.js in socket.io

Za organizacijo izmenjave SDP in ICE kandidatov med dvema RTCPeerConnection preko omrežja uporabljamo Node.js z modulom socket.io.

Opisana je namestitev najnovejše stabilne različice Node.js (za Debian/Ubuntu).

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

Namestitev za druge OS opisano

Preverimo:

$ echo "sys=require("util"); sys.puts("Testno sporočilo");" > nodetest1.js $ nodejs nodetest1.js

Z uporabo npm (Node Package Manager) bomo namestili socket.io in dodatni modul express:

$ npm namestite socket.io express

Preizkusimo ga tako, da ustvarimo datoteko nodetest2.js za strežniško stran:

$ nano nodetest2.js var app = require("express")(), server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Če so vrata 80 prosta app.get("/", function (req, res) ( // Ko dostopate do korenske strani res.sendfile(__dirname + "/nodetest2.html"); // pošljite datoteko HTML) ) ; io.sockets.on("povezava", funkcija (socket) ( // Pri povezovanju socket.emit("server event", ( hello: "world" )); // pošlji sporočilo socket.on("client event" , funkcija (podatki) ( // in deklarira obravnavo dogodkov, ko sporočilo prispe iz odjemalske konzole.log(data); )); ));

In nodetest2.html za stran odjemalca:

$ nano nodetest2.html var socket = io.connect("/"); // URL strežnika Websocket (korenska stran strežnika, s katerega je bila stran naložena) socket.on("strežniški dogodek", funkcija (podatki) ( console.log(data); socket.emit("odjemalski dogodek", ( "ime": "vrednost" )); ));

Zaženemo strežnik:

$ sudo nodejs nodetest2.js

in odprite stran http://localhost:80 (če deluje lokalno na vratih 80) v brskalniku. Če je vse uspešno, bomo v JavaScript konzoli brskalnika videli izmenjavo dogodkov med brskalnikom in strežnikom ob povezavi.

Izmenjava informacij med RTCPeerConnection preko spletnih vtičnic Odjemalski del

Shranimo naš glavni primer (rtcdemo3.html) pod novim imenom rtcdemo4.html. Vključimo knjižnico socket.io v element:

In na začetku skripta JavaScript - povezovanje s spletnimi vtičnicami:

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

Nadomestimo neposredni klic funkcij drugega udeleženca tako, da mu pošljemo sporočilo prek spletnih vtičnic:

Funkcija createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("offer", desc); ... ) funkcija pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("odgovor", 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); ... )

V funkciji hangup() bomo namesto neposrednega klicanja funkcij drugega udeleženca posredovali sporočilo prek spletnih vtičnic:

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

In dodajte upravljavce za prejemanje sporočil:

Socket.on("ponudba", funkcija (podatki) ( console.log("socket.on("ponudba")):", podatki); pc2_receivedOffer(podatki); )); socket.on("odgovor", funkcija (podatki) (е console.log("socket.on("odgovor"):", podatki); pc1.setRemoteDescription(novo RTCSessionDescription(podatki)); )); socket.on("ice1", funkcija (podatki) ( console.log("socket.on("ice1"):", podatki); pc2.addIceCandidate(novo RTCIceCandidate(podatki)); )); socket.on("ice2", funkcija (podatki) ( console.log("socket.on("ice2"):", podatki); pc1.addIceCandidate(novo RTCIceCandidate(podatki)); )); socket.on("hangup", funkcija (podatki) ( console.log("socket.on("hangup")):", podatki); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Strežniški del

Na strani strežnika shranite datoteko nodetest2 pod novim imenom rtctest4.js in znotraj funkcije io.sockets.on("connection", function (socket) ( ... ) bomo dodali prejemanje in pošiljanje sporočil odjemalca:

Socket.on("ponudba", funkcija (podatki) ( // Ko prejmemo sporočilo "ponudba", // ker je v tem primeru samo ena odjemalska povezava, // bomo poslali sporočilo nazaj prek iste vtičnice vtičnice .emit("offer" , data); // Če bi bilo potrebno sporočilo posredovati preko vseh povezav, // razen pošiljatelja: // soket.broadcast.emit("offer", data); )); socket.on("odgovor", funkcija (podatki) ( socket.emit("odgovor", podatki); )); socket.on("ice1", funkcija (podatki) ( socket.emit("ice1", podatki); )); socket.on("ice2", funkcija (podatki) ( socket.emit("ice2", podatki); )); socket.on("hangup", funkcija (podatki) ( socket.emit("hangup", podatki); ));

Poleg tega spremenimo ime datoteke HTML:

// res.sendfile(__dirname + "/nodetest2.html"); // Pošlji datoteko HTML res.sendfile(__dirname + "/rtctest4.html");

Zagon strežnika:

$ sudo nodejs nodetest2.js

Kljub temu, da se koda obeh odjemalcev izvaja znotraj istega zavihka brskalnika, se vsa interakcija med udeleženci v našem primeru v celoti izvaja preko omrežja in »ločevanje« udeležencev ne zahteva posebnih težav. Vendar pa je bilo tudi to, kar smo naredili, zelo preprosto – te tehnologije so dobre, ker so preproste za uporabo. Tudi če včasih varljivo. Še posebej ne pozabimo, da brez strežnikov STUN/TURN naš primer ne bo mogel delovati ob prisotnosti prevajanja naslovov in požarnih zidov.

Zaključek

Nastali primer je zelo običajen, a če nekoliko univerzaliziramo obdelovalce dogodkov, tako da se ne razlikujejo med kličočim in klicanim, namesto dveh objektov pc1 in pc2 naredimo polje RTCPeerConnection in implementiramo dinamično ustvarjanje in odstranitev elementov, boste dobili popolnoma uporaben video klepet. Z WebRTC ni posebnih posebnosti, primer preprostega videoklepeta za več udeležencev (ter besedila vseh primerov v članku) pa je na disku, ki je priložen reviji. Se pa na internetu že da marsikaj najti. dobri primeri. Pri pripravi članka so bili uporabljeni zlasti: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.

Predvidevamo lahko, da bo zelo kmalu po zaslugi WebRTC prišlo do revolucije ne le v našem razumevanju glasovnih in video komunikacij, ampak tudi v načinu, kako dojemamo internet kot celoto. WebRTC ni postavljen le kot tehnologija za klice med brskalniki, temveč tudi kot komunikacijska tehnologija v realnem času. Video komunikacija, o kateri smo razpravljali, je le majhen del možne možnosti njegovo uporabo. Obstajajo že primeri predvajanja zaslona in sodelovanja ter celo omrežje za dostavo vsebine P2P v brskalniku, ki uporablja RTCDataChannel.