WebRTC. Videoneuvottelut selaimessa. Usean käyttäjän chat WebRTC Webrtc -äänikeskustelun avulla

Johdanto. P2P-videokeskustelu päällä WebRTC-pohja on vaihtoehto Skypelle ja muille viestintävälineille. WebRTC-pohjaisen p2p-videokeskustelun pääelementit ovat selain ja yhteyspalvelin. P2P-videokeskustelut ovat peer-to-peer-videokeskusteluja, joissa palvelin ei osallistu tietovirtojen välittämiseen. Tietoa siirretään suoraan käyttäjien selainten välillä ilman mitään lisäohjelmia. Selainten lisäksi p2p-videokeskusteluissa käytetään yhteyspalvelimia, jotka on suunniteltu rekisteröimään käyttäjiä, tallentamaan tietoja heistä ja varmistamaan käyttäjien välinen vaihto. Selaimet, jotka tukevat uusimpia WebRTC- ja HTML5-tekniikoita, tarjoavat välitöntä tekstiviestien ja tiedostojen siirtoa sekä ääni- ja videoviestintää IP-verkkojen kautta.

Joten chatit, verkkokeskustelut, ääni- ja videokeskustelut verkkoliittymässä, IMS, VoIP ovat palveluita, jotka tarjoavat online-viestintää komposiittipakettikytkentäisten verkkojen kautta. Viestintäpalvelut edellyttävät pääsääntöisesti joko asiakassovellusten asentamista käyttäjän laitteisiin (PC:t, älypuhelimet jne.) tai lisäosien ja laajennusten asentamista selaimiin. Palveluilla on omat viestintäverkot, joista suurin osa on rakennettu asiakas-palvelin-arkkitehtuurille.

Viestintäpalvelut ovat muita sovelluksia kuin IMS, joihin ääni-, video-, data- ja tekstikanavia ei ole integroitu. Kunkin palvelun verkoissa . On huomattava, että nämä sovellukset eivät voi toimia samanaikaisesti useissa tietoliikenneverkoissa, ts. Sovellukset eivät yleensä pysty kommunikoimaan toistensa kanssa, joten kullekin tietoliikenneverkolle on asennettava erillinen sovellus.

Ongelmana on reaaliaikaisten viestintäpalvelujen (chat, puhelin, videoneuvottelu) integrointi, ts. äänen, videon, datakanavien integrointi ja pääsy niihin yhdellä sovelluksella (selaimella) voidaan ratkaista WebRTC-protokollan pohjalta peer-to-peer- tai p2p-videokeskusteluissa (peer-to-peer, point-to-point). Pohjimmiltaan WebRTC:tä tukevasta selaimesta tulee yksi käyttöliittymä kaikille käyttäjän laitteille (PC:t, älypuhelimet, iPadit, IP-puhelimet, matkapuhelimet jne.), jotka toimivat viestintäpalvelujen kanssa.

Se on WebRTC, joka varmistaa kaikkien reaaliaikaista viestintää tarjoavien teknologioiden käyttöönoton selaimessa. P2p-videokeskustelujen ydin on, että multimedia- ja tekstidata siirretään suoraan käyttäjien selainten välillä (etäyhteys) ilman palvelimen tai lisäohjelmien osallistumista. Näin ollen selaimet eivät vain tarjoa pääsyä lähes kaikkiin tietolähteitä Internet, jotka tallennetaan palvelimille, mutta niistä tulee myös keino päästä kaikkiin reaaliaikaisiin viestintäpalveluihin ja sähköpostipalveluihin (vastaaja, sähköposti, tekstiviesti jne.)

P2p-videokeskustelujen palvelimet (yhteyspalvelimet) on tarkoitettu vain käyttäjien rekisteröintiin, käyttäjätietojen tallentamiseen ja yhteyden muodostamiseen (vaihtoon) käyttäjien selainten välillä. Ensimmäiset p2p-videokeskustelut toteutettiin flash-tekniikoilla. Flash p2p -videokeskusteluja käytetään mm sosiaalisissa verkostoissa. Flash p2p -videokeskustelut eivät tarjoa korkealaatuinen multimediatietojen siirto. Lisäksi, jos haluat lähettää ääni- ja videovirtaa mikrofonista ja videokamerasta p2p-flash-videokeskusteluissa, sinun on asennettava flash-laajennus verkkoselaimeen.

Mutta uuden sukupolven tietoliikennepalvelut sisältävät verkkoviestinnän, joka käyttää vain WebRTC-protokollia ja HTML5-spesifikaatiota tukevia selaimia ja yhteyspalvelimia kommunikoidakseen Internetissä. Mikä tahansa sellaisella selaimella varustettu käyttäjälaite (PC, iPad, älypuhelimet jne.) voi tarjota korkealaatuisia ääni- ja videopuheluita sekä pikaviestien ja tiedostojen siirtoa.

Joten uusi verkkoviestintätekniikka (p2p-keskustelut, videokeskustelut) on WebRTC-protokolla. WebRTC yhdessä HTML5:n, CSS3:n ja JavaScriptin kanssa mahdollistavat erilaisten verkkosovellusten luomisen. WebRT on suunniteltu järjestämään verkkoviestintää (vertaisverkot) reaaliajassa käyttämällä vertaisarkkitehtuuria. WebRTC:hen perustuvat P2P-chatit tarjoavat tiedostonsiirron sekä teksti-, ääni- ja videoviestinnän käyttäjien välillä Internetin kautta käyttämällä vain verkkoselaimia ilman selaimen ulkoisia lisäosia ja laajennuksia.

P2p-keskusteluissa palvelinta käytetään vain p2p-yhteyden muodostamiseen kahden selaimen välille. WebRTC-protokollaan perustuvan p2p-chatin asiakasosan luomiseen käytetään HTML5:tä, CSS3:a ja JavaScriptiä. Asiakassovellus on vuorovaikutuksessa selaimien kanssa WebRTC API:n kautta.

WebRTC on toteutettu kolmella JavaScript-sovellusliittymällä:

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

Selaimet siirtävät mediatietoja SRTP-protokollalla, joka toimii UDP:n päällä. Koska NAT aiheuttaa ongelmia NAT-reitittimien takana oleville selaimille (asiakkaille), jotka käyttävät p2p-yhteyksiä Internetissä, STUNia käytetään NAT-kääntäjien ohittamiseen. STUN on asiakas-palvelin-protokolla, joka toimii UDP-siirtoprotokollan päällä. P2p-chateissa käytetään pääsääntöisesti julkista STUN-palvelinta, josta saatua tietoa käytetään UDP-yhteyteen kahden selaimen välillä, jos ne ovat NAT:n takana.

Esimerkkejä WebRTC-sovellusten toteutuksesta (p2p-chatit, ääni- ja videoverkkochatit):
1. P2P-videochat Bistri (yhden napsautuksen videochat, p2p-chat), joka perustuu WebRTC:hen, voidaan avata Bistrissä. Bistri toimii selaimessa ilman lisäohjelmien ja lisäosien asentamista. Työn ydin on seuraava: avaa p2p-videokeskustelu määritetyn linkin avulla, rekisteröidyttyäsi avautuvassa käyttöliittymässä, kutsu kumppaneita, valitse sitten vertaisasiakkaiden luettelosta verkossa oleva kumppani ja napsauta "videopuhelua" ”-painiketta.

Tämän seurauksena MediaStream (getUserMedia) kaappaa mikrofonin + verkkokameran, ja palvelin vaihtaa signalointiviestejä valitun kumppanin kanssa. Signalointiviestien vaihdon jälkeen PeerConnection API luo kanavat ääni- ja videovirtojen lähettämiseen. Lisäksi Bistri välittää pikaviestejä ja tiedostoja. Kuvassa Kuva 1 näyttää kuvakaappauksen Bistri p2p -videokeskusteluliittymästä.

Riisi. 1. P2P-videokeskustelu Bistri

2. Twelephone (p2p videochat, p2p chat, SIP Twelephone) - tämä asiakassovellus on rakennettu HTML5:n ja WebRTC:n pohjalta, jonka avulla voit soittaa ääni- ja videopuheluita sekä lähettää pikaviestejä, ts. Twelephone sisältää testi-p2p-chatin, videochatin ja SIP Twelephonen. On huomattava, että Twelephone tukee SIP-protokollaa ja nyt voit soittaa ja vastaanottaa ääni- ja videopuheluita SIP-puhelimista käyttämällä Twitter-tiliäsi puhelinnumerona. Sitä paitsi, tekstiviestit voit syöttää äänellä mikrofonin kautta, ja äänentunnistusohjelma syöttää tekstin "Lähetä viesti" -riville.

Twelephone on selainpohjainen verkkopuhelinpalvelu Google Chrome, alkaen versiosta 25, ilman lisäosia ohjelmisto. Twelephonen on kehittänyt Chris Matthieu. Twelephone-taustaosa on rakennettu Node.js:lle. Palvelinta (yhteyspalvelinta) käytetään vain p2p-yhteyden muodostamiseen kahden selaimen tai WebRTC-asiakkaan välille. Twelephone-sovelluksella ei ole omia valtuutustyökaluja, mutta se on keskittynyt tiliin yhdistämiseen ( tili) Twitterissä.

Kuvassa Kuva 2 näyttää kuvakaappauksen Twelephone p2p -videokeskusteluliittymästä.

Riisi. 2. P2P Twelephone

3. Ryhmä-p2p-videokeskustelu Conversat.io on rakennettu uusimmille WebRTC- ja HTML5-tekniikoille. Conversat-videokeskustelu on kehitetty SimpleWebRTC-kirjaston pohjalta ja se on tarkoitettu kommunikointiin jopa kuuden vertaisasiakkaan välillä yhdessä huoneessa (ilmoita kommunikaatiota varten vertaisasiakkaiden yhteisen huoneen nimi "Nimeä keskustelu" -riville). P2P-videochat Conversat tarjoaa viestintäpalveluita käyttäjille ilman rekisteröitymistä yhteyspalvelimelle. Kuvassa Kuvassa 3 on kuvakaappaus Conversat p2p -videokeskusteluliittymästä.

Riisi. 3. Ryhmä-P2P-videokeskustelu Conversat.io

WebRTC-pohjaisiin P2P-videokeskusteluihin osallistuminen edellyttää, että käyttäjillä on asennettuna selain, joka tukee WebRTC-protokollaa ja HTML5-spesifikaatiota. Tällä hetkellä Google Chrome -selaimet alkaen versiosta 25 ja Mozilla Firefox Nightly tukee WebRTC-protokollaa ja HTML5-spesifikaatiota. WebRTC-sovellukset ovat parempia kuin Flash-sovellukset kuvan- ja äänensiirron laadun suhteen.

Suurin osa WebRTC:n materiaalista keskittyy koodauksen sovellustasoon, eikä se auta ymmärtämään tekniikkaa. Yritetään mennä syvemmälle ja selvittää miten yhteys syntyy, mikä on istunnon kuvaaja ja ehdokkaat, miksi STUN- ja TURN-palvelimia tarvitaan.

WebRTC Johdanto

WebRTC on selainsuuntautunut tekniikka, jonka avulla voit yhdistää kaksi asiakasta videotiedonsiirtoa varten. Tärkeimmät ominaisuudet ovat selainten sisäinen tuki (ei tarvita kolmannen osapuolen toteuttamia teknologioita, kuten Adobe Flash) ja kyky yhdistää asiakkaita ilman lisäpalvelimia - vertaisyhteys (jäljempänä p2p).

P2p-yhteyden muodostaminen on melko vaikea tehtävä, koska tietokoneilla ei aina ole julkisia IP-osoitteita eli osoitteita Internetissä. IPv4-osoitteiden pienen määrän vuoksi (ja turvallisuussyistä) kehitettiin NAT-mekanismi, jonka avulla voit luoda yksityisiä verkkoja esimerkiksi kotikäyttöön. Monet kodin reitittimet tukevat nyt NAT:ia ja tämän ansiosta kaikilla kodin laitteilla on pääsy Internetiin, vaikka Internet-palveluntarjoajat tarjoavat yleensä yhden IP-osoitteen. Julkiset IP-osoitteet ovat ainutlaatuisia Internetissä, mutta yksityiset eivät. Siksi p2p:n yhdistäminen on vaikeaa.

Ymmärtääksesi tämän paremmin, harkitse kolmea tilannetta: molemmat solmut ovat samassa verkossa (kuva 1), molemmat solmut ovat eri verkoissa (toinen yksityisessä, toinen julkisessa) (kuva 2) ja molemmat solmut ovat eri yksityisissä verkoissa samat IP-osoitteet (kuva 3).

Kuva 1: Molemmat solmut samassa verkossa

Kuva 2: Solmut eri verkoissa (yksi yksityinen, yksi julkinen)

Kuva 3: Solmut eri yksityisissä verkoissa, mutta numeerisesti samat osoitteet

Yllä olevissa kuvissa kaksimerkkisen merkinnän ensimmäinen kirjain osoittaa solmutyypin (p = vertaisverkko, r = reititin). Ensimmäisessä kuvassa tilanne on suotuisa: niiden verkon solmut tunnistetaan täysin verkon IP-osoitteista ja voivat siten muodostaa yhteyden suoraan toisiinsa. Toisessa kuvassa meillä on kaksi eri verkkoa, joilla on samanlaiset solmunumerot. Tässä näkyvät reitittimet (reitittimet), joita on kaksi verkkoliitäntä– verkon sisällä ja verkon ulkopuolella. Siksi heillä on kaksi IP-osoitetta. Tavallisilla solmuilla on vain yksi rajapinta, jonka kautta ne voivat kommunikoida vain verkon sisällä. Jos he lähettävät dataa jollekin verkon ulkopuolelle, niin vain NAT:n avulla reitittimen (reitittimen) sisällä ja siten muiden nähtävissä reitittimen IP-osoitteen alla - se on heidän ulkoinen IP-osoite. Joten solmulla p1 on sisätilat IP = 192.168.0.200 Ja ulkoinen IP = 10.50.200.5 , ja viimeinen osoite on myös sen verkon kaikkien muiden solmujen ulkopuolella. Tilanne on samanlainen solmun p2 kohdalla. Siksi heidän kommunikointinsa on mahdotonta, jos käytetään vain heidän sisäisiä (omia) IP-osoitteita. Voit käyttää ulkoisia osoitteita eli reitittimen osoitteita, mutta koska kaikilla saman yksityisen verkon solmuilla on sama ulkoinen osoite, tämä on melko vaikeaa. Tämä ongelma voidaan ratkaista käyttämällä NAT-mekanismia

Mitä tapahtuu, jos päätämme yhdistää solmut niiden sisäisten osoitteiden kautta? Tiedot eivät poistu verkosta. Vaikutuksen parantamiseksi voit kuvitella viimeisessä kuvassa näkyvän tilanteen - molemmilla solmuilla on samat sisäiset osoitteet. Jos he käyttävät niitä viestintään, jokainen solmu kommunikoi itsensä kanssa.

WebRTC selviää onnistuneesti tällaisista ongelmista käyttämällä ICE-protokollaa, joka kuitenkin vaatii lisäpalvelimien käyttöä (STUN, TURN). Tästä kaikesta lisää alla.

WebRTC:n kaksi vaihetta

Jos haluat yhdistää kaksi solmua WebRTC-protokollan (tai yksinkertaisesti RTC:n, jos kaksi iPhonea kommunikoivat) kautta, sinun on suoritettava joitain alustavia vaiheita yhteyden muodostamiseksi. Tämä on ensimmäinen vaihe - yhteyden muodostaminen. Toinen vaihe on videodatan siirto.

On syytä sanoa heti, että vaikka WebRTC-tekniikka käyttää monia eri tavoin tietoliikennettä (TCP ja UDP) ja siinä on joustava vaihto niiden välillä, tämä tekniikka sillä ei ole protokollaa yhteystietojen lähettämiseen. Ei yllättävää, koska kahden p2p-solmun yhdistäminen ei ole niin helppoa. Siksi niitä on oltava jonkin verran lisää tiedonsiirtomenetelmä, joka ei liity millään tavalla WebRTC:hen. Se voi olla socket-siirto, HTTP-protokolla, se voi jopa olla SMTP-protokolla tai Venäjän posti. Tämä siirtomekanismi alkukirjain dataa kutsutaan signaali. Tietoa ei tarvitse välittää paljon. Kaikki tiedot välitetään tekstimuodossa ja jaetaan kahteen tyyppiin - SDP ja Ice Candidate. Ensimmäistä tyyppiä käytetään loogisen yhteyden muodostamiseen ja toista fyysiseen yhteyteen. Tästä kaikesta lisää myöhemmin, mutta nyt on vain tärkeää muistaa, että WebRTC antaa meille tietoja, jotka on lähetettävä toiseen solmuun. Heti kun lähetämme kaikki tarvittavat tiedot, solmut voivat muodostaa yhteyden, eikä apuamme enää tarvita. Joten signalointimekanismi, joka meidän on toteutettava, on erikseen, käytetään vain yhdistettynä, mutta sitä ei käytetä videodatan lähettämiseen.

Tarkastellaan siis ensimmäistä vaihetta - yhteyden muodostusvaihetta. Se koostuu useista kohdista. Tarkastellaan tätä vaihetta ensin solmulle, joka aloittaa yhteyden, ja sitten sitä, joka odottaa.

• Aloittaja (soittaja):
• Tarjoa videotiedonsiirron aloittamista (createOffer)
• SDP SDP:n hankkiminen)
• Jääehdokkaan vastaanottaminen Ice ehdokas )
• Koputuspalvelu (puhelun vastaanottaja):
• Paikallisen (oma) mediavirran vastaanottaminen ja sen asettaminen lähetettäväksi (getUserMediaStream)
• Tarjouksen vastaanottaminen videotiedonsiirron aloittamisesta ja vastauksen luominen (createAnswer)
• SDP-objektin vastaanottaminen ja sen välittäminen signalointimekanismin (SDP) läpi
• Jääkandidaattiesineiden vastaanottaminen ja niiden välittäminen merkinantomekanismin läpi (Ice ehdokas)
• Etä (ulkomaisen) mediavirran vastaanottaminen ja sen näyttäminen näytöllä (onAddStream)

Ainoa ero on toisessa kohdassa.

Vaiheiden ilmeisestä monimutkaisuudesta huolimatta niitä on itse asiassa kolme: oman mediavirran lähettäminen (kohta 1), yhteysparametrien asettaminen (kohdat 2-4), jonkun muun mediavirran vastaanottaminen (kohta 5). Vaikein vaihe on toinen vaihe, koska se koostuu kahdesta osasta: perustamisesta fyysistä Ja looginen yhteyksiä. Ensimmäinen osoittaa polku, jota pitkin pakettien täytyy kulkea päästäkseen verkkosolmusta toiseen. Toinen osoittaa video/audioparametrit– mitä laatua käyttää, mitä koodekkeja käyttää.

Henkisesti createOffer- tai createAnswer-vaiheen tulisi olla yhteydessä SDP- ja Ice-ehdokasobjektien läpivientivaiheisiin.

Peruskokonaisuudet Mediastreamit (MediaStream)

Pääolemus on mediavirta, eli video- ja äänidatan, kuvan ja äänen virta. Mediavirtoja on kahden tyyppisiä - paikallisia ja etätiedostoja. Paikallinen vastaanottaa dataa syöttölaitteilta (kamera, mikrofoni) ja etälaite verkon kautta. Siten jokaisella solmulla on sekä paikallinen että etäsäike. WebRTC:ssä on MediaStream-liitäntä suoratoistoa varten, ja siellä on myös LocalMediaStream-aliliittymä erityisesti paikallista streamia varten. JavaScriptissä voit kohdata vain ensimmäisen, mutta jos käytät libjingleä, voit kohdata myös toisen.

WebRTC:llä on melko hämmentävä hierarkia säikeessä. Jokainen stream voi koostua useista mediaraidoista (MediaTrack), jotka puolestaan ​​voivat koostua useista mediakanavista (MediaChannel). Ja itse mediavirtoja voi myös olla useita.

Katsotaan kaikki järjestyksessä. Pidetäänpä tämä esimerkki mielessä. Oletetaan, että haluamme lähettää paitsi videon itsestämme, myös videon pöydästämme, jolla on paperi, jolle aiomme kirjoittaa jotain. Tarvitsemme kaksi videota (me + pöytä) ja yhden äänen (me). On selvää, että me ja taulukko tulisi jakaa eri säikeisiin, koska nämä tiedot ovat todennäköisesti heikosti riippuvaisia ​​toisistaan. Siksi meillä on kaksi MediaStreamia - yksi meille ja toinen pöytään. Ensimmäinen sisältää sekä video- että äänidataa ja toinen vain videota (kuva 4).

Kuva 4: Kaksi erilaista mediavirtaa. Yksi meille, yksi meidän pöytään

On heti selvää, että vähintään mediavirran tulee sisältää kyky sisältää dataa eri tyyppejä- video ja ääni. Tämä on otettu huomioon tekniikassa ja siksi jokainen tietotyyppi toteutetaan MediaTrack-mediaraidan kautta. Mediaraidalla on erityinen ominaisuuslaji , joka määrittää, onko kyseessä video vai ääni (kuva 5)

Kuva 5: Mediavirrat koostuvat mediakappaleista

Miten kaikki tapahtuu ohjelmassa? Luomme kaksi mediavirtaa. Sitten luomme kaksi videoraitaa ja yhden ääniraidan. Päästään käsiksi kameroihin ja mikrofoniin. Kerrotaan jokaiselle raidalle, mitä laitetta käytetään. Lisätään video- ja ääniraita ensimmäiseen mediavirtaan ja videoraita toisesta kamerasta toiseen mediavirtaan.

Mutta miten erotamme mediavirrat yhteyden toisessa päässä? Tätä varten jokaisella mediavirralla on otsikkoominaisuus - virran nimi, sen nimi (kuva 6). Mediakappaleilla on sama ominaisuus. Vaikka ensi silmäyksellä näyttää siltä, ​​​​että video voidaan erottaa äänestä muulla tavalla.

Kuva 6: Mediavirrat ja raidat tunnistetaan nimiöillä

Joten jos mediakappaleet voidaan tunnistaa tunnisteen avulla, miksi meidän on käytettävä esimerkissämme kahta mediavirtaa yhden sijasta? Loppujen lopuksi voit lähettää yhden mediavirran, mutta käyttää siinä erilaisia ​​raitoja. Olemme saavuttaneet mediavirtojen tärkeän ominaisuuden - ne synkronoida mediakappaleita. Eri mediavirtoja ei synkronoida keskenään, mutta jokaisen mediavirran sisällä kaikki raidat pelataan samanaikaisesti.

Jos siis haluamme, että sanamme, kasvojen tunteemme ja paperimme toistetaan samanaikaisesti, kannattaa käyttää yhtä mediavirtaa. Jos tämä ei ole niin tärkeää, on kannattavampaa käyttää erilaisia ​​​​virtoja - kuva on tasaisempi.

Jos jokin raita on poistettava käytöstä lähetyksen aikana, voit käyttää mediaraidan sallittua ominaisuutta.

Lopuksi kannattaa miettiä stereoääntä. Kuten tiedät, stereoääni on kaksi eri ääntä. Ja ne on myös siirrettävä erikseen. Mediakanavia käytetään tähän. Mediaääniraidalla voi olla useita kanavia (esimerkiksi 6, jos tarvitset 5+1 ääntä). Mediaraitojen sisällä on tietysti myös kanavia. synkronoitu. Videossa käytetään yleensä vain yhtä kanavaa, mutta useita voidaan käyttää esimerkiksi peittomainontaan.

Yhteenvetona: Käytämme mediavirtaa video- ja äänidatan välittämiseen. Jokaisen mediavirran tiedot synkronoidaan. Voimme käyttää useita mediavirtoja, jos emme tarvitse synkronointia. Jokaisen mediavirran sisällä on kahden tyyppisiä mediaraitoja - videota ja ääntä varten. Raitoja ei yleensä ole enempää kuin kaksi, mutta niitä voi olla enemmän, jos joudut lähettämään useita eri videoita (keskustelijasta ja hänen pöydästään). Jokainen raita voi koostua useista kanavista, joita käytetään yleensä vain stereoääneen.

Yksinkertaisimmassa videokeskustelutilanteessa meillä on yksi paikallinen mediavirta, joka koostuu kahdesta raidasta - videoraidasta ja ääniraidasta, joista kukin koostuu yhdestä pääkanavasta. Videoraita vastaa kamerasta, ääniraita mikrofonista ja mediavirta on molempien kontti.

Istuntokuvaus (SDP)

Eri tietokoneissa on aina erilaiset kamerat, mikrofonit, näytönohjaimet ja muut laitteet. Heillä on monia vaihtoehtoja. Kaikki tämä on koordinoitava mediatietojen siirtämiseksi kahden verkkosolmun välillä. WebRTC tekee tämän automaattisesti ja luo erityinen kohde– SDP-istunnon kuvaaja. Siirrä tämä objekti toiselle solmulle, ja mediatiedot voidaan siirtää. Vain yhteyttä toiseen solmuun ei vielä ole.

Tähän käytetään mitä tahansa signaalimekanismia. SDP voidaan välittää joko pistorasioiden kautta tai henkilön toimesta (kerro se toiselle solmulle puhelimitse) tai Venäjän postin kautta. Kaikki on hyvin yksinkertaista - sinulle annetaan valmis SDP ja sinun on lähetettävä se. Ja kun vastaanotat toiselta puolelta, siirrä se WebRTC-osastolle. Istuntokuvaaja tallennetaan tekstinä ja sitä voidaan muuttaa sovelluksissasi, mutta tämä ei yleensä ole välttämätöntä. Esimerkiksi, kun kytket pöytätietokoneen ↔-puhelimen, joskus joudut pakottamaan halutun äänikoodekin valinnan.

Yleensä yhteyttä muodostettaessa on määritettävä jonkinlainen osoite, kuten URL-osoite. Tämä ei ole tässä välttämätöntä, koska lähetät itse tiedot määränpäähän signalointimekanismin kautta. Osoittaaksemme WebRTC:lle, että haluamme muodostaa p2p-yhteyden, meidän on kutsuttava createOffer-toiminto. Kun tämä toiminto on kutsuttu ja erityinen takaisinsoitto on määritetty, SDP-objekti luodaan ja välitetään samalle takaisinkutsulle. Ainoa mitä sinulta vaaditaan, on siirtää tämä objekti verkon kautta toiseen solmuun (keskustelukumppaniin). Tämän jälkeen data saapuu toiseen päähän signalointimekanismin kautta, nimittäin tämän SDP-objektin kautta. Tämä istuntokuvaaja on vieras tälle solmulle ja sisältää siksi hyödyllistä tietoa. Tämän kohteen vastaanottaminen on signaali yhteyden aloittamisesta. Siksi sinun on hyväksyttävä tämä ja kutsuttava createAnswer-funktio. Se on createOfferin täydellinen analogi. Jälleen paikallinen istunnon kuvaaja välitetään takaisinsoittoosi, ja se on välitettävä takaisin signalointimekanismin kautta.

On syytä huomata, että voit kutsua createAnswer-funktiota vasta saatuasi jonkun muun SDP-objektin. Miksi? Koska paikallisen SDP-objektin, joka luodaan kutsuttaessa createAnswer, on perustuttava etä-SDP-objektiin. Vain tässä tapauksessa on mahdollista sovittaa videoasetukset keskustelukumppanisi asetuksiin. Älä myöskään saa kutsua createAnsweria ja createOfferia ennen paikallisen mediavirran vastaanottamista - niillä ei ole mitään kirjoitettavaa SDP-objektiin.

Koska WebRTC pystyy muokkaamaan SDP-objektia, se on asennettava paikallisen kuvaajan vastaanottamisen jälkeen. Saattaa tuntua hieman oudolta, että meidän on siirrettävä WebRTC:lle sen, mitä se itse antoi meille, mutta se on protokolla. Kun etäkahva vastaanotetaan, se on myös asennettava. Siksi sinun on asennettava kaksi kuvaajaa yhteen solmuun - omasi ja jonkun muun (eli paikallinen ja etä).

Tämän jälkeen kädenpuristus solmut tietävät toistensa toiveista. Esimerkiksi, jos solmu 1 tukee koodekkeja A ja B ja solmu 2 tukee koodekkeja B ja C, niin koska kukin solmu tuntee omat ja toisensa kuvaajat, molemmat solmut valitsevat koodekin B (kuva 7). Yhteyslogiikka on nyt muodostettu ja mediavirtoja voidaan lähettää, mutta on toinen ongelma - solmut on edelleen kytketty vain signalointimekanismilla.

Kuva 7: Codec-neuvottelu

Jääehdokas

WebRTC-tekniikka yrittää hämmentää meitä uudella menetelmällään. Yhteyttä muodostettaessa ei määritetä sen solmun osoitetta, johon haluat muodostaa yhteyden. Asennettu ensin looginen yhteys, ei fyysistä, vaikka aina tehtiin päinvastoin. Mutta tämä ei vaikuta oudolta, jos emme unohda, että käytämme kolmannen osapuolen signalointimekanismia.

Yhteys on siis jo muodostettu (looginen yhteys), mutta silti ei ole polkua, jota pitkin verkkosolmut voivat lähettää dataa. Kaikki ei ole niin yksinkertaista, mutta aloitetaan yksinkertaisesta. Olkoon solmut samassa yksityisessä verkossa. Kuten jo tiedämme, ne voivat helposti muodostaa yhteyden toisiinsa käyttämällä sisäisiä IP-osoitteita (tai ehkä joitain muita, jos TCP/IP:tä ei käytetä).

Joidenkin takaisinsoittojen kautta ja WebRTC ilmoittaa meille jääehdokasobjekteista. Ne tulevat myös tekstimuodossa, ja kuten istuntokuvaajat, ne on yksinkertaisesti lähetettävä signalointimekanismin kautta. Jos istuntokuvaaja sisälsi tietoja asetuksistamme kameran ja mikrofonin tasolla, niin ehdokkaat sisältävät tietoa sijainnistamme verkossa. Välitä ne toiselle solmulle, jolloin se voi muodostaa fyysisen yhteyden meihin, ja koska sillä on jo istunnon kuvaaja, se voi loogisesti muodostaa yhteyden ja tiedot "virtaavat". Jos hän muistaa lähettää meille ehdokasobjektinsa eli tiedon missä hän itse on verkossa, voimme ottaa yhteyttä häneen. Huomaa tässä vielä yksi ero perinteiseen asiakas-palvelin-vuorovaikutukseen verrattuna. Kommunikointi HTTP-palvelimen kanssa tapahtuu pyyntö-vastausmallin mukaisesti, asiakas lähettää tiedot palvelimelle, joka käsittelee sen ja lähettää sen pyyntöpaketissa määritetty osoite. WebRTC:ssä sinun on tiedettävä kaksi osoitetta ja yhdistä ne molemmilta puolilta.

Ero istunnon kuvauksiin on se, että vain etäehdokkaat täytyy asentaa. Muokkaus täällä on kiellettyä eikä siitä voi olla mitään hyötyä. Joissakin WebRTC-toteutuksissa ehdokkaat on asennettava vasta sen jälkeen, kun istuntokuvaajat on asetettu.

Miksi istunnon kuvaus oli vain yksi, mutta ehdokkaita saattoi olla useita? Koska verkon sijainti voidaan määrittää paitsi sen sisäisen IP-osoitteen perusteella, myös reitittimen ulkoisen osoitteen perusteella, eikä välttämättä vain yhden, sekä TURN-palvelimien osoitteiden perusteella. Kappaleen loppuosa on omistettu yksityiskohtaiselle keskustelulle ehdokkaista ja kuinka yhdistää solmut eri yksityisistä verkoista.

Joten kaksi solmua on samassa verkossa (kuva 8). Kuinka tunnistaa ne? IP-osoitteiden käyttäminen. Ei toista reittiä. Voit silti käyttää erilaisia ​​siirtoja (TCP ja UDP) ja erilaisia ​​portteja. Nämä tiedot sisältyvät ehdokasobjektiin - IP, PORT, TRANSPORT ja jotkut muut. Käytetään esimerkiksi UDP-kuljetusta ja porttia 531.

Kuva 8: Kaksi solmua on samassa verkossa

Sitten, jos olemme solmussa p1, WebRTC antaa meille sellaisen ehdokasobjektin - . Tämä ei ole tarkka muoto, vain kaavio. Jos olemme solmussa p2, niin ehdokas on . Signalointimekanismin kautta p1 vastaanottaa p2:n ehdokkaan (eli solmun p2 sijainnin, nimittäin sen IP:n ja PORTin). Sitten p1 voi muodostaa yhteyden p2:een suoraan. Oikeammin p1 lähettää tiedot numeroon 10.50.150.3:531 siinä toivossa, että se saavuttaa p2:n. Ei ole väliä kuuluuko tämä osoite solmulle p2 vai jollekin välittäjälle. Ainoa tärkeä asia on, että tiedot lähetetään tämän osoitteen kautta ja voivat saavuttaa p2:n.

Niin kauan kuin solmut ovat samassa verkossa, kaikki on yksinkertaista ja helppoa - jokaisella solmulla on vain yksi ehdokasobjekti (tarkoittaa aina omaa eli sen sijaintia verkossa). Mutta ehdokkaita tulee olemaan paljon enemmän, kun solmut ovat mukana eri verkkoja.

Jatketaan monimutkaisempaan tapaukseen. Yksi solmu sijaitsee reitittimen takana (tarkemmin NAT:n takana), ja toinen solmu sijaitsee samassa verkossa tämän reitittimen kanssa (esimerkiksi Internetissä) (Kuva 9).

Kuva 9: ​​Yksi solmu on NAT:n takana, toinen ei

Tässä tapauksessa on erityinen ratkaisu ongelmaan, jota tarkastelemme nyt. Kotireititin sisältää yleensä NAT-taulukon. Tämä on erityinen mekanismi, joka on suunniteltu mahdollistamaan reitittimen yksityisen verkon solmujen pääsy esimerkiksi verkkosivustoille.

Oletetaan, että verkkopalvelin on yhteydessä Internetiin suoraan, eli sillä on julkinen IP *-osoite. Olkoon tämä solmu p2. Solmu p1 (verkkoasiakas) lähettää pyynnön osoitteeseen 10.50.200.10. Ensinnäkin tiedot menevät reitittimeen r1, tai pikemminkin sen sisätilat käyttöliittymä 192.168.0.1. Tämän jälkeen reititin muistaa lähdeosoitteen (osoite p1) ja syöttää sen erityiseen NAT-taulukkoon ja muuttaa sitten lähdeosoitteen omaksi (p1 → r1). Lisäksi omalla tavallani ulkoinen käyttöliittymä, reititin lähettää tiedot suoraan p2-verkkopalvelimelle. Web-palvelin käsittelee tiedot, luo vastauksen ja lähettää sen takaisin. Lähettää r1:n reitittimelle, koska se on paluuosoitteessa (reititin korvasi osoitteen omalla). Reititin vastaanottaa tiedot, katsoo NAT-taulukkoa ja välittää tiedot solmuun p1. Reititin toimii tässä välittäjänä.

Entä jos useat sisäisen verkon solmut käyttävät samanaikaisesti ulkoista verkkoa? Kuinka reititin ymmärtää, kenelle vastaus lähetetään? Tämä ongelma ratkaistaan ​​käyttämällä portit. Kun reititin korvaa isäntäosoitteen omalla osoitteellaan, se korvaa myös portin. Jos kaksi solmua käyttää Internetiä, reititin korvaa niiden lähdeportit eri. Sitten, kun paketti Web-palvelimelta tulee takaisin reitittimeen, reititin ymmärtää portin perusteella, kenelle paketti on osoitettu. Esimerkki alla.

Palataanpa WebRTC-tekniikkaan, tai tarkemmin sanottuna siihen osaan, joka käyttää ICE-protokollaa (siis Ice-ehdokkaat). Solmulla p2 on yksi ehdokas (sen sijainti verkossa on 10.50.200.10), ja solmulla p1, joka sijaitsee NAT-reitittimen takana, on kaksi ehdokasta - paikallinen (192.168.0.200) ja reititinehdokas (10.50.200.5). Ensimmäinen ei ole hyödyllinen, mutta se syntyy siitä huolimatta, koska WebRTC ei tiedä vielä mitään etäsolmusta - se voi olla tai ei ole samassa verkossa. Toinen ehdokas on hyödyllinen, ja kuten jo tiedämme, portilla (NAT:n läpi pääsemiseksi) on tärkeä rooli.

Merkintä NAT-taulukkoon luodaan vain, kun tiedot poistuvat sisäisestä verkosta. Siksi solmun p1 on lähetettävä tiedot ensin ja vasta sen jälkeen solmun p2 data pääsee solmuun p1.

Käytännössä molemmat solmut on NAT:n takana. Luodakseen merkinnän kunkin reitittimen NAT-taulukkoon isäntien on lähetettävä jotain etäisännälle, mutta tällä kertaa edellinen ei voi tavoittaa jälkimmäistä eikä päinvastoin. Tämä johtuu siitä, että solmut eivät tiedä ulkoisia IP-osoitteitaan ja tietojen lähettäminen sisäisiin osoitteisiin on turhaa.

Jos ulkoiset osoitteet ovat kuitenkin tiedossa, yhteys on helppo muodostaa. Jos ensimmäinen solmu lähettää dataa toisen solmun reitittimelle, reititin jättää sen huomioimatta, koska sen NAT-taulukko on edelleen tyhjä. Ensimmäisen solmun reitittimessä NAT-taulukkoon ilmestyi kuitenkin tarvittava merkintä. Jos nyt toinen solmu lähettää dataa ensimmäisen solmun reitittimelle, reititin siirtää sen onnistuneesti ensimmäiseen solmuun. Nyt myös toisen reitittimen NAT-taulukossa on tarvittavat tiedot.

Ongelmana on, että ulkoisen IP-osoitteesi selvittämiseksi tarvitset solmun, joka sijaitsee jaettu verkko. Tämän ongelman ratkaisemiseksi käytetään lisäpalvelimia, jotka ovat suoraan yhteydessä Internetiin. Niiden avulla NAT-taulukkoon luodaan myös arvokkaita merkintöjä.

STUN- ja TURN-palvelimet

Kun aloitat WebRTC:n, sinun on määritettävä käytettävissä olevat STUN- ja TURN-palvelimet, joita kutsumme vastedes ICE-palvelimiksi. Jos palvelimia ei ole määritetty, vain saman verkon solmut (joihin on yhdistetty ilman NAT:ta) voivat muodostaa yhteyden. On heti syytä huomata, että 3G-verkoissa TURN-palvelimien käyttö on pakollista.

TAINNUTTAA palvelin on yksinkertaisesti Internetissä oleva palvelin, joka palauttaa palautusosoitteen, eli lähettäjän solmun osoitteen. Reitittimen takana oleva isäntä ottaa yhteyttä STUN-palvelimeen NAT:n läpi kulkemiseksi. STUN-palvelimelle saapunut paketti sisältää lähdeosoitteen - reitittimen osoitteen, eli solmumme ulkoisen osoitteen. Tämä on STUN-osoite, jonka palvelin lähettää takaisin. Siten solmu saa ulkoisen IP-osoitteensa ja portin, jonka kautta siihen pääsee verkosta. Seuraavaksi WebRTC käyttää tätä osoitetta lisäehdokkaan (ulkoisen reitittimen osoitteen ja portin) luomiseen. Nyt reitittimen NAT-taulukossa on merkintä, jonka avulla reitittimelle vaaditussa portissa lähetetyt paketit pääsevät solmuun.

Tarkastellaan tätä prosessia esimerkin avulla.

Esimerkki (STUN-palvelimen toiminta)

STUN-palvelin merkitään s1:llä. Reititin, kuten ennenkin, kulkee r1:n kautta ja solmu p1:n kautta. Sinun on myös seurattava NAT-taulukkoa - merkitsemme sitä nimellä r1_nat. Lisäksi tämä taulukko sisältää yleensä monia tietueita aliverkon eri solmuista - niitä ei anneta.

Joten alussa meillä on tyhjä taulukko r1_nat.

Taulukko 2: Paketin otsikko

Solmu p1 lähettää tämän paketin reitittimelle r1 (riippumatta siitä, kuinka eri aliverkot voivat käyttää erilaisia ​​teknologioita). Reitittimen on vaihdettava lähdeosoite Src IP, koska paketissa määritetty osoite ei ilmeisesti sovi ulkoiseen aliverkkoon; lisäksi osoitteet sellaiselta alueelta on varattu, eikä missään Internet-osoitteessa ole tällaista osoitetta. Reititin tekee korvauksen paketissa ja luo uusi merkintä taulukossasi r1_nat. Tätä varten hänen on keksittävä portin numero. Muista, että koska useat aliverkon isännät voivat käyttää ulkoista verkkoa, NAT-taulukko on tallennettava lisäinformaatio, jotta reititin voi määrittää, mikä näistä useista solmuista on tarkoitettu paluupaketille palvelimelta. Anna reitittimen keksiä portti 888.

Paketin otsikko muutettu:

Taulukko 4: NAT-taulukko on päivitetty uudella merkinnällä

Tässä aliverkon IP-osoite ja portti ovat täsmälleen samat kuin alkuperäisessä paketissa. Itse asiassa, kun postbacking, meillä on oltava tapa palauttaa ne kokonaan. Ulkoisen verkon IP-osoite on reitittimen osoite, ja portti on vaihtunut reitittimen keksimään.

Todellinen portti, jolla solmu p1 hyväksyy yhteyden, on tietysti 35777, mutta palvelin lähettää tietoja fiktiivinen portti 888, jonka reititin muuttaa todelliseksi 35777:ksi.

Joten reititin korvasi lähdeosoitteen ja portin paketin otsikossa ja lisäsi merkinnän NAT-taulukkoon. Nyt paketti lähetetään verkon kautta palvelimelle eli solmulle s1. S1:llä on sisääntulossa seuraava paketti:

Src IP Src PORT Dest IP Dest PORT

10.50.200.5	888	12.62.100.200	6000

Taulukko 5: STUN-palvelin vastaanotti paketin

Kaiken kaikkiaan STUN-palvelin tietää vastaanottaneensa paketin osoitteesta 10.50.200.5:888. Nyt palvelin lähettää tämän osoitteen takaisin. Kannattaa pysähtyä tähän ja katsoa uudelleen, mitä juuri katsoimme. Yllä olevat taulukot ovat katkelmia otsikko paketti, ei ollenkaan siitä sisältö. Emme puhuneet sisällöstä, koska se ei ole niin tärkeä - se on jotenkin kuvattu STUN-protokollassa. Nyt tarkastelemme otsikon lisäksi sisältöä. Se on yksinkertainen ja sisältää reitittimen osoitteen - 10.50.200.5:888, vaikka otimme sen osoitteesta otsikko paketti. Tätä ei tehdä usein, protokollat ​​eivät yleensä välitä tiedoista solmuosoitteista, on vain tärkeää, että paketit toimitetaan niille tarkoitettuun määränpäähän. Tässä tarkastelemme protokollaa, joka muodostaa polun kahden solmun välille.

Joten nyt meillä on toinen paketti, joka menee päinvastaiseen suuntaan:

Taulukko 7: STUN-palvelin lähettää tämän sisällön sisältävän paketin

Seuraavaksi paketti kulkee verkon poikki, kunnes se saavuttaa reitittimen r1 ulkoisen liitännän. Reititin ymmärtää, että pakettia ei ole tarkoitettu sille. Kuinka hän ymmärtää tämän? Tämän voi määrittää vain portti. Hän ei käytä porttia 888 henkilökohtaisiin tarkoituksiinsa, mutta käyttää sitä NAT-mekanismiin. Siksi reititin katsoo tätä taulukkoa. Katsoo External PORT -saraketta ja etsii riviä, joka vastaa saapuvan paketin kohdeporttia, eli 888.

Sisäinen IP Sisäinen PORT Ulkoinen IP Ulkoinen PORT

192.168.0.200	35777	10.50.200.5	888

Taulukko 8: NAT-taulukko

Olemme onnekkaita, tällainen linja on olemassa. Jos olisimme epäonnisia, paketti yksinkertaisesti hylättiin. Nyt sinun on ymmärrettävä, minkä aliverkon solmun tulee lähettää tämä paketti. Ei tarvitse kiirehtiä, muistetaan jälleen porttien merkitys tässä mekanismissa. Samanaikaisesti kaksi aliverkon solmua voisi lähettää pyyntöjä ulkoiseen verkkoon. Sitten, jos reititin keksi portin 888 ensimmäiselle solmulle, niin toiselle se saisi portin 889. Oletetaan, että näin tapahtui, eli r1_nat-taulukko näyttää tältä:

Taulukko 10: Reititin korvaa vastaanottimen osoitteen

Src IP Src PORT Dest IP Dest PORT

12.62.100.200	6000	192.168.0.200	35777

Taulukko 11: Reititin muutti vastaanottimen osoitetta

Paketti saapuu onnistuneesti solmuun p1 ja paketin sisältöä katsomalla solmu saa tietää ulkoisen IP-osoitteensa eli ulkoisen verkon reitittimen osoitteen. Hän tietää myös portin, jonka reititin kulkee NAT:n kautta.

Mitä seuraavaksi? Mitä hyötyä tästä kaikesta on? Etu on merkintä r1_nat-taulukkoon. Jos nyt joku lähettää paketin portilla 888 reitittimelle r1, niin reititin välittää tämän paketin solmuun p1. Tämä loi pienen kapean käytävän piilotettuun solmuun p1.

Yllä olevasta esimerkistä saat jonkinlaisen käsityksen NAT:n toiminnasta ja STUN-palvelimen olemuksesta. Yleisesti ottaen ICE-mekanismi ja STUN/TURN-palvelimet on tarkoitettu täsmälleen NAT-rajoitusten voittamiseksi.

Solmun ja palvelimen välillä ei voi olla yksi reititin, vaan useita. Tässä tapauksessa solmu saa sen reitittimen osoitteen, joka ensimmäisenä pääsee samaan verkkoon kuin palvelin. Toisin sanoen saamme STUN-palvelimeen yhdistetyn reitittimen osoitteen. P2p-viestintää varten tämä on juuri se, mitä tarvitsemme, jos emme unohda sitä tosiasiaa, että jokainen reititin lisää tarvitsemamme rivin NAT-taulukkoon. Siksi paluumatka on jälleen yhtä sujuvaa.

TURN-palvelin on parannettu STUN-palvelin. Tästä kannattaa heti poistaa se, että mikä tahansa TURN-palvelin voi toimia myös STUN-palvelimena. On kuitenkin myös etuja. Jos p2p-viestintä on mahdotonta (kuten esimerkiksi 3g-verkoissa), palvelin siirtyy välitystilaan, eli se toimii välittäjänä. Emme tietenkään puhu mistään p2p:stä, mutta ICE-mekanismin ulkopuolella solmut luulevat kommunikoivansa suoraan.

Missä tapauksissa TURN-palvelin tarvitaan? Miksi STUN-palvelinta ei ole tarpeeksi? Tosiasia on, että NAT-tyyppejä on useita. Ne korvaavat IP-osoitteen ja portin samalla tavalla, mutta joihinkin niistä on sisäänrakennettu lisäsuojaus "väärennöksiä" vastaan. Esimerkiksi sisään symmetrinen NAT-taulukko tallentaa 2 muuta parametria - IP ja etäsolmun portti. Paketti ulkoisesta verkosta kulkee NAT:n kautta sisäiseen verkkoon vain, jos lähdeosoite ja portti vastaavat taulukkoon tallennettuja. Siksi temppu STUN-palvelimen kanssa epäonnistuu - NAT-taulukko tallentaa STUN-palvelimen osoitteen ja portin, ja kun reititin vastaanottaa paketin WebRTC-keskustelukumppanilta, se hylkää sen, koska se on "väärennetty". Se ei tullut STUN-palvelimelta.

Siten TURN-palvelinta tarvitaan siinä tapauksessa, että molemmat keskustelukumppanit ovat takana symmetrinen NAT (jokainen omansa).

Lyhyt yhteenveto

Tässä on joitain WebRTC-kokonaisuuksia koskevia lausuntoja, jotka sinun tulee aina pitää mielessä. Ne on kuvattu yksityiskohtaisesti edellä. Jos jokin lauseista ei näytä täysin selvältä, lue asiaankuuluvat kohdat uudelleen.

• Mediavirta
  • Video- ja äänidata pakataan mediavirtoihin
  • Mediavirrat synkronoivat muodostavat mediakappaleet
  • Eri mediavirtoja ei synkronoida keskenään
  • Mediavirrat voivat olla paikallisia ja etälähetyksiä, paikallinen on yleensä kytketty kameraan ja mikrofoniin, etävirrat vastaanottavat tietoa verkosta salatussa muodossa
  • Mediaraitoja on kahta tyyppiä - videolle ja äänelle.
  • Mediaraitoja voi kytkeä päälle/pois
  • Mediaraidat koostuvat mediakanavista
  • Mediaraidat synkronoivat muodostavat mediakanavat
  • Mediavirroissa ja mediaraioissa on tunnisteet, joiden avulla ne voidaan erottaa
• Istunnon kahva
  • Istuntokuvaajaa käytetään yhdistämään loogisesti kaksi verkkosolmua
  • Istuntokuvaaja tallentaa tietoja käytettävissä olevia tapoja video- ja äänidatan koodaus
  • WebRTC käyttää ulkoista signalointimekanismia - istunnon kuvaimien (sdp) edelleenlähetys kuuluu sovellukselle
  • Looginen yhteysmekanismi koostuu kahdesta vaiheesta - tarjous (tarjous) ja vastaus (vastaus)
  • Istuntokuvaajan luominen on mahdotonta ilman paikallista mediavirtaa tarjouksen yhteydessä, ja se on mahdotonta ilman etäistunnon kuvaajaa vastauksen tapauksessa.
  • Tuloksena oleva kuvaaja on annettava WebRTC-toteutukselle, eikä sillä ole väliä, vastaanotetaanko tämä kuvaaja etänä vai paikallisesti samasta WebRTC-toteutuksesta
  • Istuntokuvausta on mahdollista muokata hieman
• Ehdokkaat
  • Jääehdokas on verkon solmun osoite
  • Solmun osoite voi olla omasi tai se voi olla reitittimen tai TURN-palvelimen osoite
  • Ehdokkaita on aina paljon
  • Ehdokas koostuu IP-osoitteesta, portista ja siirtotyypistä (TCP tai UDP)
  • Ehdokkaita käytetään luomaan fyysinen yhteys verkon kahden solmun välille
  • Ehdokkaat on myös lähetettävä merkinantomekanismin kautta
  • Ehdokkaat on myös siirrettävä WebRTC-toteutuksiin, mutta vain etäkäyttöön
  • Joissakin WebRTC-toteutuksissa ehdokkaat voidaan lähettää vasta sen jälkeen, kun istunnon kuvaaja on asetettu
• STUN/TURN/ICE/NAT
  • NAT on mekanismi, jolla tarjotaan pääsy ulkoiseen verkkoon
  • Kotireitittimet tukevat erityistä NAT-taulukkoa
  • Reititin korvaa paketeissa olevat osoitteet - lähdeosoitteen omalla, jos paketti menee ulkoiseen verkkoon, ja vastaanottimen osoitteen sisäisen verkon isäntäosoitteella, jos paketti tuli ulkoisesta verkosta.
  • Monikanavaisen pääsyn tarjoamiseksi ulkoiseen verkkoon NAT käyttää portteja
  • ICE - NAT Traversal Engine
  • STUN- ja TURN-palvelimet – apupalvelimet NAT-läpikulkuun
  • STUN-palvelimen avulla voit luoda tarvittavat merkinnät NAT-taulukkoon ja palauttaa myös isännän ulkoisen osoitteen
  • TURN-palvelin yleistää STUN-mekanismin ja saa sen aina toimimaan
  • Pahimmassa tapauksessa TURN-palvelinta käytetään välittäjänä (välittäjänä), eli p2p muuttuu asiakas-palvelin-asiakas -yhteydeksi.

Nykyään WebRTC on "kuuma" tekniikka äänen ja videon suoratoistoon selaimissa. Konservatiiviset tekniikat, kuten HTTP Streaming ja Flash, sopivat paremmin tallennetun sisällön (video on demand) jakeluun ja ovat huomattavasti WebRTC:tä huonompia reaaliajassa ja online-lähetyksissä, ts. jossa vaaditaan minimaalista videon latenssia, jotta katsojat näkevät mitä tapahtuu "suorana".

Laadukkaan reaaliaikaisen viestinnän mahdollisuus tulee itse WebRTC-arkkitehtuurista, jossa UDP-protokollaa käytetään videovirtojen siirtämiseen, mikä on vakioperusta videon lähettämiselle minimaalisilla viiveillä ja jota käytetään laajalti reaaliaikaisissa viestintäjärjestelmissä.

Viestinnän latenssi on tärkeä online-lähetysjärjestelmissä, webinaareissa ja muissa sovelluksissa, jotka vaativat interaktiivista viestintää videolähteen, loppukäyttäjien kanssa ja vaativat ratkaisun.

Toinen hyvä syy kokeilla WebRTC:tä on se, että se on ehdottomasti trendi. Nykyään jokainen Android Chrome-selain tukee tätä tekniikkaa, joka takaa, että miljoonat laitteet ovat valmiina katsomaan lähetystä ilman lisäohjelmistojen tai -kokoonpanojen asentamista.

WebRTC-tekniikan testaamiseksi toiminnassa ja yksinkertaisen suorituksen suorittamiseksi verkkolähetys, käytimme Flashphoner WebRTC Media & Broadcasting Server -palvelinohjelmistoa. Ominaisuudet kertovat kyvystä lähettää WebRTC-virtoja yksi-moneen-tilassa sekä tuen IP-kameroita ja videovalvontajärjestelmiä RTSP-protokollan kautta; Tässä katsauksessa keskitymme web-web-lähetyksiin ja niiden ominaisuuksiin.

WebRTC Media & Broadcasting Serverin asentaminen

Koska varten Windows-järjestelmät palvelinversiota ei ollut, enkä halunnut asentaa virtuaalikoneita, kuten VMWare+Linux, jotta voisin testata online-lähetyksiä kotona Windows-tietokone Ei toiminut. Ajan säästämiseksi päätimme ottaa esimerkin pilvipalvelusta seuraavasti:

Se oli Centos x86_64 -versio 6.5 ilman esiasennettua ohjelmistoa Amsterdamin palvelinkeskuksessa. Näin ollen meillä on käytettävissämme vain palvelin ja ssh-pääsy siihen. Niille, jotka ovat tuttuja konsolin komennot Linux, WebRTC-palvelimen asentaminen lupaa olla yksinkertaista ja kivutonta. Joten mitä teimme:

1. Lataa arkisto:

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

2. Pura pakkauksesta:

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

3. Asenna:

$cd FlashphonerWebCallServer

Syötä asennuksen aikana palvelimen IP-osoite: XXX.XXX.XXX.XXX

4. Aktivoi lisenssi:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Käynnistä WCS-palvelin:

$service webcallserver käynnistyy

6. Tarkista loki:

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

7. Tarkista, että kaksi prosessia ovat paikoillaan:

$ps aux | grep Flashphoner

Asennusprosessi on valmis.

WebRTC-verkkolähetysten testaus

Lähetysten testaus osoittautui yksinkertaiseksi. Palvelimen lisäksi käytössä on web-asiakasohjelma, joka koostuu kymmenestä Javascript-, HTML- ja CSS-tiedostosta ja jonka otettiin käyttöön /var/www/html-kansioon asennusvaiheessa. Ainoa asia, mitä minun piti tehdä, oli syöttää palvelimen IP-osoite flashphoner.xml-konfiguraatioon, jotta web-asiakas voisi muodostaa yhteyden palvelimeen HTML5 Websocketsin kautta. Kuvataan testausprosessi.

1. Avaa index.html-testiasiakassivu Chrome-selaimessa:

2. Aloita lähetys napsauttamalla näytön keskellä olevaa "Aloita"-painiketta.
Ennen kuin teet tämän, sinun on varmistettava, että verkkokamera on kytketty ja käyttövalmis. Web-kameralle ei ole erityisiä vaatimuksia, esimerkiksi käytimme kannettavaan tietokoneeseen sisäänrakennettua tavallista kameraa, jonka resoluutio on 1280x800.

Chrome-selain pyytää ehdottomasti pääsyä kameraan ja mikrofoniin, jotta käyttäjä ymmärtää, että hänen videonsa lähetetään Internet-palvelimelle ja sallii sen.

3. Käyttöliittymä edustaa videovirran onnistunutta lähetystä kamerasta WebRTC-palvelimelle. Oikeassa yläkulmassa ilmaisin osoittaa, että stream on menossa palvelimelle; alanurkassa on "Stop"-painike videon lähettämisen lopettamiseksi.

Huomioi linkki alla olevaan laatikkoon. Se sisältää tämän streamin yksilöllisen tunnisteen, joten kuka tahansa voi liittyä katseluun. Avaa tämä linkki selaimessasi. Kopioi se leikepöydälle napsauttamalla "Kopioi" -painiketta.

Todellisissa sovelluksissa, kuten webinaareissa, luennoissa, online-videolähetyksissä tai interaktiivisessa televisiossa, kehittäjien on toteutettava tämän tunnisteen jakaminen tietyille katsojaryhmille, jotta he voivat muodostaa yhteyden haluttuihin streameihin, mutta tämä on jo sovelluksen logiikka. . WebRTC Media & Broadcasting Server ei vaikuta siihen, vaan vain jakaa videota.

5. Yhteys muodostetaan ja katsoja näkee virran näytöllä. Nyt hän voi lähettää linkin jollekulle toiselle, pysäyttää suoratoiston tai ottaa koko näytön tilan käyttöön oikeassa alakulmassa olevilla säätimillä.

WebRTC-verkkolähetyspalvelimen testauksen tulokset

Testien aikana latenssi vaikutti täydelliseltä. Ping datakeskukseen oli noin 100 millisekuntia ja viive oli näkymätön. Tästä voidaan olettaa, että todellinen viive on sama 100 plus tai miinus muutama kymmenkunta millisekuntia puskurointiajalla. Flash-videoon verrattuna: tällaisissa testeissä Flash ei toimi yhtä hyvin kuin WebRTC. Joten jos liikutat kättäsi samanlaisessa verkossa, liike näytöllä näkyy vasta yhden tai kahden sekunnin kuluttua.

Laadun osalta huomaamme, että kuutiot voidaan joskus erottaa liikkeistä. Tämä on yhdenmukainen VP8-koodekin luonteen ja sen päätarkoituksen kanssa - tarjota reaaliaikainen videoviestintä hyväksyttävällä laadulla ja ilman viestintäviiveitä.

Palvelin on melko helppo asentaa ja konfiguroida, sen käyttäminen ei vaadi muita vakavia taitoja kuin Linuxin tuntemus kokeneen käyttäjän tasolla, joka osaa suorittaa komentoja konsolista ssh:n kautta ja käyttää tekstieditori. Tuloksena onnistuimme luomaan yksi-moneen verkkolähetyksen selaimien välillä. Lisäkatsojien yhdistäminen streamiin ei myöskään aiheuttanut ongelmia.

Lähetyksen laatu osoittautui melko hyväksyttäväksi webinaareihin ja verkkolähetyksiin. Ainoa asia, joka herätti kysymyksiä, oli videon resoluutio. Kamera tukee 1280x800, mutta testikuvan resoluutio on hyvin samanlainen kuin 640x480. Ilmeisesti tämä ongelma on selvitettävä kehittäjien kanssa.

Video testauslähetyksestä web-kamerasta
WebRTC-palvelimen kautta

Tekniikat puheluiden soittamiseen selaimesta ovat olleet olemassa useita vuosia: Java, ActiveX, Adobe Flash...Viime vuosien aikana on käynyt selväksi, että laajennukset ja vasemmalle virtuaalikoneita Ne eivät loista mukavuudesta (miksi minun pitäisi asentaa mitään?) ja mikä tärkeintä, turvallisuudella. Mitä tehdä? Siellä on uloskäynti!

Viime aikoihin asti IP-verkot käyttivät useita IP-puheluita tai -videoita varten: SIP, yleisin protokolla, H.323 ja MGCP, jotka tulevat esiin, Jabber/Jingle (käytetään Gtalkissa), puoliavoin Adobe RTMP* ja tietysti , sulki Skypen. Googlen käynnistämä WebRTC-projekti yrittää muuttaa IP- ja verkkopuhelinmaailman asioiden tilaa. softphones, mukaan lukien Skype. WebRTC ei ainoastaan ​​toteuta kaikkia viestintäominaisuuksia suoraan selaimen sisällä, joka on nyt asennettu melkein jokaiselle laitteelle, vaan myös yrittää samanaikaisesti ratkaista yleisemmän selaimen käyttäjien välisen viestinnän ongelman (erilaisten tietojen vaihto, näytön lähetys, yhteistyö asiakirjojen kanssa ja paljon enemmän).

WebRTC verkkokehittäjän näkökulmasta

Web-kehittäjän näkökulmasta WebRTC koostuu kahdesta pääosasta:

• mediavirran hallinta paikallisista resursseista (kamera, mikrofoni tai näyttö paikallinen tietokone) on toteutettu menetelmällä navigator.getUserMedia, joka palauttaa MediaStream-objektin;
• mediavirtoja tuottavien laitteiden välinen vertaisviestintä, mukaan lukien viestintämenetelmien määrittely ja niiden suora lähettäminen - RTCPeerConnection-objektit (ääni- ja videovirtojen lähettämiseen ja vastaanottamiseen) ja RTCDataChannel (tietojen lähettämiseen ja vastaanottamiseen selaimesta).

Mitä me teemme?

Selvitämme kuinka järjestää yksinkertainen usean käyttäjän videokeskustelu selaimien välillä WebRTC:n perusteella käyttämällä verkkopistorasiaa. Aloitamme Chromen/Chromiumin kokeilun, sillä se on WebRTC:n kehittyneimmät selaimet, vaikka Firefox 22, joka julkaistiin 24. kesäkuuta, on melkein saavuttanut ne. On sanottava, että standardia ei ole vielä hyväksytty, ja API voi muuttua versiosta toiseen. Kaikki esimerkit testattiin Chromium 28:ssa. Yksinkertaisuuden vuoksi emme valvo koodin puhtautta ja selainten välistä yhteensopivuutta.

MediaStream

Ensimmäinen ja yksinkertaisin WebRTC-komponentti on MediaStream. Se antaa selaimelle pääsyn mediavirtoihin paikallisen tietokoneen kamerasta ja mikrofonista. Chromessa tätä varten sinun on kutsuttava funktio navigator.webkitGetUserMedia() (koska standardia ei ole vielä viimeistelty, kaikilla funktioilla on etuliite, ja Firefoxissa sama toiminto on nimeltään navigator.mozGetUserMedia()). Kun soitat sille, käyttäjää pyydetään sallimaan pääsy kameraan ja mikrofoniin. Puhelua voidaan jatkaa vasta, kun käyttäjä on antanut suostumuksensa. Vaaditun mediavirran parametrit ja kaksi takaisinsoittotoimintoa välitetään parametreina tälle toiminnolle: ensimmäinen kutsutaan, jos pääsy kameraan/mikrofoniin saadaan onnistuneesti, toinen - virheen sattuessa. Luodaan ensin HTML-tiedosto rtctest1.html painikkeella ja elementillä:

WebRTC - ensimmäinen esittelyvideo (korkeus: 240px; leveys: 320px; reunus: 1px tasainen harmaa; ) getUserMedia

Microsoft CU-RTC-Web

Microsoft ei olisi Microsoft, jos se ei heti vastaisi Googlen aloitteeseen julkaisemalla omaa yhteensopimatonta ei-standardivaihtoehtoaan nimeltä CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Vaikka jo ennestään pienen IE:n osuus jatkaa laskuaan, Skypen käyttäjien määrä antaa Microsoftille toivoa syrjäyttää Googlen, ja voidaan olettaa, että juuri tätä standardia tullaan käyttämään selaimessa. Skype versiot. Google-standardi keskittyy ensisijaisesti selainten väliseen viestintään. samaan aikaan suurin osa puheliikenteestä jää edelleen tavalliseen puhelinverkkoon, ja sen ja IP-verkkojen välisiä yhdyskäytäviä tarvitaan paitsi käytön helpottamiseksi tai nopeamman jakelun vuoksi, myös rahallistamiskeinona, jonka avulla useammat pelaajat voivat kehittää niitä. Toisen standardin ilmaantuminen voi paitsi johtaa kehittäjien epämiellyttävään tarpeeseen tukea kahta yhteensopimatonta teknologiaa samanaikaisesti, vaan myös tulevaisuudessa antaa käyttäjälle laajemman valikoiman mahdollisia toimintoja ja käytettävissä olevia teknisiä ratkaisuja. Odota niin näet.

Paikallisen streamin käyttöönotto

Määritetään HTML-tiedostomme tagien sisällä mediavirran globaali muuttuja:

Var localStream = null;

GetUserMedia-menetelmän ensimmäisen parametrin on määritettävä pyydetyn mediavirran parametrit - esimerkiksi ota ääni tai video käyttöön:

Var streamConstraints = ("ääni": tosi, "video": tosi); // Pyydä sekä äänen että videon käyttöoikeutta

Tai määritä lisäparametreja:

Var streamConstraints = ( "ääni": tosi, "video": ( "pakollinen": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "valinnainen": ) );

Toinen getUserMedia-menetelmän parametri on välitettävä takaisinsoittofunktiolle, joka kutsutaan, jos se onnistuu:

Funktio getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Yhdistä mediavirta HTML-elementtiin localStream = stream; // ja tallenna se globaalissa muuttujassa myöhempää käyttöä varten)

Kolmas parametri on takaisinsoittotoiminto, virheenkäsittelijä, joka kutsutaan virheen sattuessa

Funktio getUserMedia_error(error) ( console.log("getUserMedia_error():", virhe); )

Varsinainen kutsu getUserMedia-menetelmälle on pyyntö saada pääsy mikrofoniin ja kameraan, kun ensimmäistä painiketta painetaan

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

Mediavirtaa ei voi käyttää paikallisesti avatusta tiedostosta. Jos yritämme tehdä tämän, saamme virheilmoituksen:

NavigatorUserMediaError (koodi: 1, PERMISSION_DENIED: 1)"

Ladataan tuloksena oleva tiedosto palvelimelle, avataan se selaimessa ja sallitaan vastauksena näkyviin tulevaan pyyntöön pääsy kameraan ja mikrofoniin.

Voit valita laitteet, joita Chrome voi käyttää kohdassa Asetukset, Näytä lisäasetukset -linkki, Tietosuoja-osiossa ja Sisältö-painikkeessa. Firefox- ja Opera-selaimissa laitteet valitaan avattavasta luettelosta suoraan, kun käyttö on sallittu.

HTTP-protokollaa käytettäessä lupaa pyydetään aina, kun mediavirtaa käytetään sivun latautumisen jälkeen. HTTPS:ään vaihtamalla voit näyttää pyynnön kerran, vain ensimmäisen kerran, kun käytät mediavirtaa.

Huomaa sykkivä ympyrä kirjanmerkkikuvakkeessa ja kamerakuvake osoitepalkin oikealla puolella:

RTCMediaConnection

RTCMediaConnection on objekti, joka on suunniteltu muodostamaan ja välittämään mediavirtoja verkon yli osallistujien välillä. Lisäksi tämä objekti vastaa mediaistunnon kuvauksen (SDP) luomisesta, tietojen hankkimisesta ICE-ehdokkaista NAT:n läpikulkua varten tai palomuurit(paikallinen ja STUN-käyttö) ja vuorovaikutus TURN-palvelimen kanssa. Jokaisella osallistujalla on oltava yksi RTCMediaConnection yhteyttä kohti. Mediavirrat lähetetään käyttämällä salattua SRTP-protokollaa.

TURN palvelimet

ICE-ehdokkaita on kolmenlaisia: isäntä, srflx ja relay. Isäntä sisältää paikallisesti vastaanotettuja tietoja, srflx - miltä solmu näyttää ulkoiselle palvelimelle (STUN) ja välitys - tiedot liikenteen välityspalvelimelle TURN-palvelimen kautta. Jos solmumme on NAT:n takana, isäntäehdokkaat sisältävät paikalliset osoitteet ja se on hyödytöntä, srflx-ehdokkaat auttavat vain tietyntyyppisten NAT:ien kanssa ja välitys on viimeinen toivo siirtää liikennettä välipalvelimen kautta.

Esimerkki isäntätyypin ICE-ehdokkaasta, jonka osoite on 192.168.1.37 ja portti udp/34022:

A=ehdokas:337499441 2 udp 2113937151 192.168.1.37 34022 tyyppi isäntäsukupolvi 0

Yleinen muoto STUN/TURN-palvelimien määrittämiseen:

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

Internetissä on monia julkisia STUN-palvelimia. Siellä on esimerkiksi iso lista. Valitettavasti ne ratkaisevat liian vähän ongelmia. Julkisia TURN-palvelimia ei käytännössä ole, toisin kuin STUN. Tämä johtuu siitä, että TURN-palvelin kulkee mediavirtojen läpi, mikä voi merkittävästi kuormittaa sekä verkkokanavaa että itse palvelinta. Siksi helpoin tapa muodostaa yhteys TURN-palvelimiin on asentaa se itse (ilmeisesti tarvitset julkisen IP-osoitteen). Kaikista palvelimista mielestäni paras on rfc5766-turn-server. Amazon EC2:lle on jopa valmis kuva.

TURN:n kanssa kaikki ei ole niin hyvin kuin haluaisimme, mutta aktiivista kehitystä on käynnissä, ja haluaisin toivoa, että jonkin ajan kuluttua WebRTC, ellei Skypen kanssa sama kuin osoitteenkäännösten (NAT) ja palomuurien laadussa. , on ainakin havaittavissa, tulee lähemmäksi.

RTCMediaConnection vaatii lisämekanismin ohjaustietojen vaihtamiseen yhteyden muodostamiseksi - vaikka se luo nämä tiedot, se ei välitä sitä, vaan siirto muille osallistujille on toteutettava erikseen.

Siirtotavan valinta on kehittäjällä - ainakin manuaalisesti. Heti kun tarvittavat tiedot on vaihdettu, RTCMediaConnection asentaa mediavirrat automaattisesti (jos mahdollista).

tarjous-vastaus malli

Mediavirtojen muodostamiseen ja muuttamiseen käytetään tarjous/vastaus-mallia (kuvattu RFC3264:ssä) ja SDP:tä (Session Description Protocol). Niitä käyttää myös SIP-protokolla. Tässä mallissa on kaksi agenttia: Tarjoaja - se, joka luo istunnon SDP-kuvauksen luodakseen uuden tai muokatakseen olemassa olevaa (Offer SDP) ja vastaaja - se, joka vastaanottaa istunnon SDP-kuvauksen toinen agentti ja vastaa omalla istuntokuvauksellaan (Answer SDP). Samanaikaisesti määrittely edellyttää korkeamman tason protokollaa (esim. SIP tai oma over web sockets, kuten meidän tapauksessamme), joka vastaa SDP:n välittämisestä agenttien välillä.

Mitä tietoja on siirrettävä kahden RTCMediaConnectionin välillä, jotta ne voivat luoda mediavirtoja:

• Ensimmäinen yhteyden aloittava osallistuja muodostaa Tarjouksen, jossa se lähettää SDP-tietorakenteen (sama protokolla käytetään samaan tarkoitukseen SIP:ssä), joka kuvaa sen mediavirran mahdollisia ominaisuuksia, joita se on alkamassa lähettää. Tämä tietolohko on siirrettävä toiselle osallistujalle. Toinen osallistuja muodostaa vastauksen SDP:llään ja lähettää sen ensimmäiselle.
• Sekä ensimmäinen että toinen osallistuja suorittavat proseduurin mahdollisten ICE-ehdokkaiden määrittämiseksi, joiden avulla toinen osallistuja voi lähettää heille mediavirran. Kun ehdokkaat tunnistetaan, tiedot heistä tulee välittää toiselle osallistujalle.

Perustamistarjous

Tarjouksen luomiseksi tarvitsemme kaksi toimintoa. Ensimmäinen kutsutaan, jos se on muodostettu onnistuneesti. CreateOffer()-menetelmän toinen parametri on takaisinsoittotoiminto, joka kutsutaan, jos sen suorituksen aikana tapahtuu virhe (edellyttäen, että paikallinen säie on jo saatavilla).

Lisäksi tarvitaan kaksi tapahtumakäsittelijää: onicecandidate, kun määritetään uutta ICE-kandidaattia, ja onaddstream, kun kytketään mediavirta kaukaa. Palataan tiedostoomme. Lisätään toinen HTML-koodiin elementtirivien jälkeen:

luoda Tarjous

Ja elementin rivin jälkeen (tulevaisuutta varten):

Myös JavaScript-koodin alussa ilmoitamme globaalin muuttujan RTCPeerConnectionille:

Var pc1;

Kun kutsut RTCPeerConnection-konstruktoria, sinun on määritettävä STUN/TURN-palvelimet. Lisätietoja niistä on sivupalkissa; niin kauan kuin kaikki osallistujat ovat samassa verkossa, niitä ei vaadita.

Muut palvelimet = null;

Parametrit Tarjouksen SDP:n laatimiseen

Var offerConstraints = ();

CreateOffer()-menetelmän ensimmäinen parametri on takaisinsoittotoiminto, jota kutsutaan tarjouksen onnistuneen muodostamisen yhteydessä

Funktio pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Aseta RTCPeerConnection generoima SDP käyttäen setLocalDescription-menetelmää. // Kun etäpuoli lähettää Answer SDP:n, se on asetettava käyttämällä setRemoteDescription-menetelmää // Ennen kuin toinen puoli on otettu käyttöön, emme tee mitään // pc2_receivedOffer(desc); )

Toinen parametri on takaisinsoittotoiminto, joka kutsutaan virheen sattuessa

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

Ja julistetaan takaisinsoittotoiminto, johon ICE-ehdokkaat siirretään, kun ne on määritetty:

Funktio pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Ennen kuin toinen puoli on otettu käyttöön, emme tee mitään // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Ja myös takaisinsoittotoiminto mediavirran lisäämiseksi kaukaa (tulevaisuutta varten, koska meillä on toistaiseksi vain yksi RTCPeerConnection):

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

Kun napsautat "luoTarjous" -painiketta, luomme RTCPeerConnectionin, asetamme onicecandidate- ja onaddstream-menetelmät ja pyydämme Offer SDP:n muodostamista kutsumalla createOffer()-metodia:

Funktio createOffer_click() ( console.log("createOffer_click()"); pc1 = uusi webkitRTCPeerConnection(servers); // Luo RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Takaisinsoittotoiminto ICE-ehdokkaiden käsittelyyn pc1.onaddonad =dstream; Takaisinsoittotoiminto kutsutaan kun mediavirta ilmestyy kaukaa. Ei ole vielä yhtään pc1.addStream(localStream); // Lähetetään paikallinen mediavirta (olettaen, että se on jo vastaanotettu) pc1.createOffer(// Ja itse asiassa pyytää tarjouksen muodostaminen pc1_createOffer_success , pc1_createOffer_error, offerConstraints);)

Tallennetaan tiedosto nimellä rtctest2.html, ladataan se palvelimelle, avataan selaimessa ja katsotaan konsolista mitä dataa sen toiminnan aikana syntyy. Toinen video ei näy vielä, koska osallistujia on vain yksi. Muistakaamme, että SDP on mediaistunnon parametrien kuvaus, käytettävissä olevat koodekit, mediavirrat ja ICE-ehdokkaat ovat mahdollisia vaihtoehtoja yhteyden muodostamiseksi tiettyyn osallistujaan.

Answer SDP:n muodostaminen ja ICE-ehdokkaiden vaihto

Sekä Tarjous-SDP että jokainen ICE-ehdokas on siirrettävä toiselle puolelle, ja siellä niiden vastaanottamisen jälkeen RTCPeerConnection kutsuu tarjous-SDP:n setRemoteDescription-menetelmiä ja addIceCandidate-menetelmiä jokaiselle kaukaa vastaanotetulle ICE-ehdokkaalle; samalla tavalla sisään kääntöpuoli Answer SDP- ja etä-ICE-ehdokkaille. Vastaus SDP itsessään on muodostettu samalla tavalla kuin Tarjous; ero on siinä, että ei kutsuta createOffer-metodia vaan createAnswer-metodia, ja ennen sitä RTCPeerConnection-metodi setRemoteDescription välitetään soittajalta vastaanotettuun Offer SDP:hen.

Lisätään toinen videoelementti HTML-koodiin:

Ja globaali muuttuja toiselle RTCPeerConnectionille ensimmäisen määrityksen mukaisesti:

Var pc2;

Käsitellään tarjousta ja vastausta SDP

Answer SDP:n muodostus on hyvin samanlainen kuin Offer. Takaisinsoittotoiminnossa, jota pyydetään onnistuneen vastauksen muodostamisen yhteydessä, tarjouksen tapaan, annamme paikallisen kuvauksen ja välitämme vastaanotetun vastauksen SDP:n ensimmäiselle osallistujalle:

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

Takaisinsoittotoiminto, jota kutsutaan, jos vastausta luotaessa tapahtuu virhe, on täysin samanlainen kuin Tarjous:

Funktio pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", virhe); )

Parametrit Answer SDP:n muodostamiseksi:

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

Kun toinen osallistuja saa Tarjouksen, luomme RTCPeerConnectionin ja muodostamme vastauksen samalla tavalla kuin Tarjous:

Funktio pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Luo RTCPeerConnection-objekti toiselle osallistujalle samalla tavalla kuin ensimmäiselle pc2 = uusi webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2 ; // Aseta tapahtumakäsittelijä, kun se tulee näkyviin ICE-ehdokas pc2.onaddstream = pc_onaddstream; // Kun stream tulee näkyviin, yhdistä se HTML:ään pc2.addStream(localStream); // Siirrä paikallinen mediavirta (esimerkissämme toinen osallistujalla on sama kuin ensimmäisellä) // Nyt kun toinen RTCPeerConnection on valmis, välitämme sille vastaanotetun Offer SDP:n (välitimme paikallisen streamin ensimmäiselle) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Pyydä toista yhteyttä luomaan tiedot vastausviestille pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Siirtääksemme Offer SDP:n ensimmäiseltä osallistujalta toiselle esimerkissämme, poistetaan sen kommentti pc1-funktiossa luoda Tarjous menestys() puhelulinja:

Pc2_receivedOffer(desc);

ICE-ehdokkaiden käsittelyn toteuttamiseksi poistetaan kommentit ensimmäisen osallistujan pc1_onicecandidate() ICE-ehdokkaiden valmiustapahtuman käsittelijässä sen siirtoa toiselle:

Pc2.addIceCandidate(uusi RTCIceCandidate(tapahtuma.ehdokas));

Toisen osallistujan ICE-ehdokasvalmiuden tapahtumakäsittelijä on peilimäinen ensimmäiseen verrattuna:

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

Takaisinsoittotoiminto mediavirran lisäämiseksi ensimmäiseltä osallistujalta:

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

Yhteyden lopettaminen

Lisätään toinen painike HTML-koodiin

Lopettaa puhelu

Ja toiminto yhteyden katkaisemiseen

Funktio btnHangupClick() ( // Katkaise paikallinen video HTML-elementeistä, pysäytä paikallinen mediavirta, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Poista video käytöstä HTML-koodista jokaiselle osallistujalle elementit, sulje yhteys, aseta osoitin = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Tallennetaan se nimellä rtctest3.html, ladataan palvelimelle ja avataan selaimessa. Tämä esimerkki toteuttaa mediavirran kaksisuuntaisen siirron kahden RTCPeerConnectionin välillä samalla selainvälilehdellä. Tarjouksen ja vastauksen SDP:n, ICE-ehdokkaiden ja muun tiedon vaihdon järjestämiseksi verkon kautta, suoran soittomenettelyn sijaan, on tarpeen toteuttaa osallistujien välinen vaihto käyttämällä jonkinlaista liikennettä, tässä tapauksessa - verkkopistorasiaa.

Näytön lähetys

getUserMedia-toiminto voi myös kaapata näytön ja suoratoistaa MediaStream-muodossa määrittämällä seuraavat parametrit:

Var mediaStreamConstraints = ( ääni: false, video: ( pakollinen: ( chromeMediaSource: "näyttö"), valinnainen: ) );

Jotta näyttöön pääsee onnistuneesti, useiden ehtojen on täytyttävä:

• ota kuvakaappauslippu käyttöön getUserMediassa() kohdassa chrome://flags/,chrome://flags/;
• lähdetiedosto on ladattava HTTPS:n kautta (SSL-alkuperä);
• äänivirtaa ei pitäisi pyytää;
• Useita pyyntöjä ei tule suorittaa yhdellä selaimen välilehdellä.

WebRTC:n kirjastot

Vaikka WebRTC ei ole vielä valmis, useita siihen perustuvia kirjastoja on jo ilmestynyt. JsSIP on suunniteltu luomaan selainpohjaisia ​​ohjelmistopuhelimia, jotka toimivat SIP-kytkimien, kuten Asterisk ja Camalio, kanssa. PeerJS helpottaa P2P-verkkojen luomista tiedonvaihtoa varten, ja Holla vähentää P2P-viestinnän edellyttämää kehitystyötä selaimista.

Node.js ja socket.io

SDP- ja ICE-ehdokkaiden vaihdon järjestämiseksi kahden RTCPeerConnectionin välillä verkon kautta käytämme Node.js:ää socket.io-moduulin kanssa.

Node.js:n uusimman vakaan version asentaminen (Debian/Ubuntu) on kuvattu

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

Asennus muille OS kuvattu

Tarkistetaan:

$ echo "sys=require("util"); sys.puts("Testiviesti");" > nodetest1.js $ nodejs nodetest1.js

Asennamme npm:n (Node Package Manager) avulla socket.io ja lisäpikamoduulin:

$ npm asenna socket.io express

Testataan sitä luomalla nodetest2.js-tiedosto palvelinpuolelle:

$ nano nodetest2.js var app = vaatia("express")() , palvelin = vaatia("http").createServer(app) , io = vaatia("socket.io").kuuntele(palvelin); server.listen(80); // Jos portti 80 on ilmainen app.get("/", funktio (req, res) ( // Pääsivua käytettäessä res.sendfile(__dirname + "/nodetest2.html"); // lähetä HTML-tiedosto ) ) ; io.sockets.on("yhteys", funktio (socket) ( // Yhdistettäessä socket.emit("server event", ( hello: "world" )); // lähetä viesti socket.on("asiakastapahtuma" , function (data) ( // ja määritä tapahtumakäsittelijä, kun asiakaskonsolista saapuu viesti.log(data); )); ));

Ja nodetest2.html asiakaspuolelle:

$ nano nodetest2.html var socket = io.connect("/"); // Websocket-palvelimen URL-osoite (palvelimen juurisivu, josta sivu on ladattu) socket.on("palvelintapahtuma", funktio (data) ( console.log(data); socket.emit("asiakastapahtuma", () "nimi": "arvo" )); ));

Aloitetaan palvelin:

$ sudo nodejs nodetest2.js

ja avaa selaimessa sivu http://localhost:80 (jos se toimii paikallisesti portissa 80). Jos kaikki onnistuu, selaimen JavaScript-konsolissa näemme tapahtumien vaihdon selaimen ja palvelimen välillä yhteyden muodostuessa.

Tietojen vaihto RTCPeerConnectionin välillä web-sockettien kautta Asiakasosa

Tallennetaan pääesimerkkimme (rtcdemo3.html) uudella nimellä rtcdemo4.html. Sisällytetään socket.io-kirjasto elementtiin:

Ja JavaScript-skriptin alussa - yhteyden muodostaminen verkkopistorasioihin:

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

Korvataan suora puhelu toisen osallistujan toimintoihin lähettämällä hänelle viesti verkkoliitäntöjen kautta:

Funktio createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("tarjous", desc); ... ) funktio pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("answer", desc); ) function pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) function pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

Hangup()-funktiossa sen sijaan, että kutsuisimme suoraan toisen osallistujan funktioita, lähetämme viestin web-pistokkeiden kautta:

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

Ja lisää viestien vastaanottajat:

Socket.on("tarjous", funktio (data) ( console.log("socket.on("tarjous"):", data); pc2_receivedOffer(data); )); socket.on("vastaus", funktio (data) (е console.log("socket.on("vastaus"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", funktio (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", funktio (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", funktio (data) ( console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Palvelimen osa

Tallenna palvelinpuolella nodetest2-tiedosto uudella nimellä rtctest4.js ja io.sockets.on("connection", function (socket) ( ... ) -funktion sisään lisäämme asiakasviestien vastaanottamisen ja lähettämisen:

Socket.on("tarjous", funktio (data) ( // Kun saamme "tarjous"-viestin, // koska tässä esimerkissä on vain yksi asiakasyhteys, // lähetämme viestin takaisin saman socket-pistorasian kautta .emit("tarjous" , data); // Jos viesti olisi välitettävä edelleen kaikkien yhteyksien kautta, // paitsi lähettäjä: // soket.broadcast.emit("tarjous", data); )); socket.on("vastaus", funktio (data) ( socket.emit("vastaus", data); )); socket.on("ice1", funktio (data) ( socket.emit("ice1", data); )); socket.on("ice2", funktio (data) ( socket.emit("ice2", data); )); socket.on("hangup", funktio (data) ( socket.emit("hangup", data); ));

Muutetaan lisäksi HTML-tiedoston nimi:

// res.sendfile(__dirname + "/nodetest2.html"); // Lähetä HTML-tiedosto res.sendfile(__dirname + "/rtctest4.html");

Palvelimen käynnistäminen:

$ sudo nodejs nodetest2.js

Huolimatta siitä, että molempien asiakkaiden koodi suoritetaan samalla selainvälilehdellä, kaikki esimerkissämme osallistujien välinen vuorovaikutus tapahtuu täysin verkon kautta, eikä osallistujien "erotteleminen" vaadi erityisiä vaikeuksia. Teimme kuitenkin myös hyvin yksinkertaista - nämä tekniikat ovat hyviä, koska niitä on helppo käyttää. Vaikka joskus petollinenkin. Älkäämme erityisesti unohtako, että ilman STUN/TURN-palvelimia esimerkkimme ei toimi osoitteenkäännösten ja palomuurien kanssa.

Johtopäätös

Tuloksena oleva esimerkki on hyvin tavanomainen, mutta jos yleistämme hieman tapahtumakäsittelijät, jotta ne eivät eroa soittajan ja soitetun osapuolen välillä, kahden objektin pc1 ja pc2 sijasta tee RTCPeerConnection-taulukko ja toteuta dynaaminen luominen ja poistamalla elementtejä, saat täysin käyttökelpoisen videokeskustelun. WebRTC:hen ei liity erityisiä yksityiskohtia, ja esimerkki yksinkertaisesta videokeskustelusta useille osallistujille (sekä kaikkien artikkelin esimerkkien tekstit) on lehden mukana tulevalla levyllä. Internetistä löytyy kuitenkin jo aika paljon. hyviä esimerkkejä. Artikkelin valmistelussa käytettiin erityisesti seuraavia: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.

Voidaan olettaa, että WebRTC:n ansiosta hyvin pian tapahtuu vallankumous ei vain puhe- ja videoviestinnän ymmärtämisessä, vaan myös siinä, miten koemme Internetin kokonaisuutena. WebRTC ei ole vain tekniikka selainpuheluille, vaan myös reaaliaikainen viestintätekniikka. Keskustelemamme videoviestintä on vain pieni osa mahdollisia vaihtoehtoja sen käyttöä. Esimerkkejä näytön lähetyksestä ja yhteistyöstä on jo olemassa, ja jopa selainpohjainen P2P-sisällönjakeluverkko, joka käyttää RTCDataChannelia.