WebRTC tehnoloogia: heli- ja videovestlus brauseris. P2P-videovestlus, mis põhineb veebiarendaja WebRTC-l WebRTC

Suurem osa materjalist peal WebRTC keskendub koodi kirjutamise rakendustasemele ega aita kaasa tehnoloogia mõistmisele. Proovime minna sügavamale ja uurida, kuidas seos tekib, mis on seansi kirjeldus ja kandidaadid, mis on URMASTUS ja PÖÖRE server.

WebRTC

Sissejuhatus

WebRTC on brauseripõhine tehnoloogia, mis võimaldab ühendada kaks klienti videoandmete edastamiseks. Peamised funktsioonid on sisemine brauseri tugi (pole vaja kolmanda osapoole manustatud tehnoloogiaid, nagu Adobe flash) ja võimalus ühendada kliente ilma täiendavaid servereid kasutamata – ühendus peer-to-peer(Lisaks p2p).

Looge ühendus p2p- üsna keeruline ülesanne, kuna arvutitel pole alati avalikkust IP aadressid, st aadressid Internetis. Väikese koguse tõttu IPv4(ja turvalisuse huvides) töötati välja mehhanism NAT, mis võimaldab luua privaatvõrke näiteks koduseks kasutamiseks. Nüüd toetavad paljud koduruuterid NAT ja tänu sellele on kõigil koduseadmetel juurdepääs Internetile, kuigi Interneti-pakkujad seda tavaliselt pakuvad IP aadress. avalik IP Aadressid on Internetis ainulaadsed, kuid privaatsed aadressid mitte. Nii et ühendage p2p- raske.

Selle paremaks mõistmiseks kaaluge kolme olukorda: mõlemad sõlmed on samas võrgus (Pilt 1), on mõlemad sõlmed erinevates võrkudes (üks privaatne, teine avalik) (Pilt 2) ja mõlemad sõlmed on erinevates privaatvõrkudes samaga IP aadressid (Joonis 3).

Joonis 1: mõlemad sõlmed samas võrgus

Joonis 2: Sõlmed erinevates võrkudes (üks privaatne, üks avalik)

Joonis 3: Sõlmed erinevates privaatvõrkudes, kuid numbriliselt võrdsete aadressidega

Ülaltoodud joonistel näitab kahekohalise tähise esimene täht sõlme tüüpi (p = eakaaslane, r = ruuter). Esimesel joonisel on olukord soodne: nende võrgu sõlmed on võrgu järgi täielikult tuvastatud IP aadressid ja saavad seetõttu üksteisega otse ühenduse luua. Teisel joonisel on meil kaks erinevat võrku, millel on sarnased sõlmenumbrid. Siin ilmuvad ruuterid (ruuterid), millel on kaks võrguliidest - nende võrgu sees ja väljaspool võrku. Seetõttu on neil kaks IP aadressid. Tavalistel sõlmedel on ainult üks liides, mille kaudu nad saavad suhelda ainult oma võrgus. Kui nad edastavad andmeid kellelegi väljaspool oma võrku, siis ainult abiga NAT ruuteri (ruuteri) sees ja seetõttu teistele selle all nähtav IP ruuteri aadress on nende välised IP aadress. Seega sõlm p1 seal on interjöör IP = 192.168.0.200 ja välised IP = 10.50.200.5 , kusjuures viimane aadress on ka kõigi teiste tema võrgu hostide jaoks väline. Sõlme puhul on olukord sarnane p2. Seetõttu on nende ühendus võimatu, kui ainult nende sisemine (oma) IP aadressid. Võite kasutada väliseid aadresse, see tähendab ruuterite aadresse, kuid kuna kõigil sama privaatvõrgu sõlmedel on sama välisaadress, on see üsna keeruline. See probleem lahendatakse mehhanismi abil NAT

Mis juhtub, kui otsustame ikkagi ühendada sõlmed nende sisemiste aadresside kaudu? Andmed ei lahku võrgust. Efekti suurendamiseks võite ette kujutada viimasel joonisel näidatud olukorda - mõlemal sõlmel on samad sisemised aadressid. Kui nad kasutavad neid suhtlemiseks, suhtleb iga sõlm iseendaga.

WebRTC saab selliste probleemidega protokolli kasutades edukalt toime JÄÄ, mis aga nõuab täiendavate serverite kasutamist ( URMASTUS, PÖÖRE). Kõik see allpool.

WebRTC kaks etappi

Kahe sõlme ühendamiseks protokolli kaudu WebRTC(või lihtsalt RTC kui kaks on ühendatud iPhone„a) ühenduse loomiseks tuleb astuda mõned eeltoimingud. See on esimene faas – ühenduse loomine. Teine etapp on videoandmete edastamine.

Peaks kohe ütlema, et kuigi tehnoloogia WebRTC kasutab oma töös erinevaid suhtlusviise ( TCP ja UDP) ja neil on paindlik nende vahel vahetamine, see tehnoloogia puudub ühendusandmete edastamise protokoll. Pole üllatav, sest ühendage kaks sõlme p2p mitte nii lihtne. Seetõttu on vaja mõnda lisaks andmete edastamise meetod, mis ei ole seotud WebRTC. See võib olla pistikupesa ülekanne, protokoll HTTP, võib see olla isegi protokoll SMTP või Vene Post. See ülekandemehhanism esmane andmeid kutsutakse signaal. Pole vaja palju teavet edastada. Kõik andmed edastatakse tekstina ja jagunevad kahte tüüpi – SDP ja Jääkandidaat. Esimest tüüpi kasutatakse loogilise ühenduse loomiseks ja teist füüsilise ühenduse loomiseks. Rohkem sellest hiljem, kuid praegu on oluline seda meeles pidada WebRTC annab meile teavet, mis tuleb teisele sõlmele edastada. Kui oleme kogu vajaliku teabe edastanud, saavad sõlmed ühenduse luua ja meie abi pole enam vaja. Nii et signaalimismehhanism, mida peame rakendama eraldi, kasutatakse ära ainult ühendatuna, ja seda ei kasutata videoandmete edastamisel.

Nii et vaatame esimest etappi, ühenduse seadistamise etappi. See koosneb mitmest elemendist. Mõelge sellele faasile esmalt ühenduse käivitava sõlme ja seejärel ootava sõlme jaoks.

Algataja (helistaja - helistaja):
1. Video andmeedastuse alustamise pakkumine (createOffer)
2. Saab oma SDP SDP)
3. Saab oma Jääkandidaat Jääkandidaat)
Koputus ( callee):
1. Kohaliku (oma) meediumivoo hankimine ja edastamiseks seadistamine (getUserMediaStream)
2. Saate pakkumise alustada video andmeedastust ja luua vastus (createAnswer)
3. Saab oma SDP objekt ja selle läbimine signalisatsioonimehhanismist ( SDP)
4. Saab oma Jääkandidaat objektid ja nende edastamine signaalimismehhanismi kaudu ( Jääkandidaat)
5. Kaugmeediumivoo (välismaise) vastuvõtmine ja selle kuvamine ekraanil (onAddStream)

Ainus erinevus on teises lõigus.

Vaatamata sammude näilisele keerukusele on neid tegelikult kolm: oma meediavoo saatmine (lk 1), ühenduse parameetrite seadistamine (lk 2-4), kellegi teise meediavoo vastuvõtmine (lk 5). Kõige keerulisem on teine samm, sest see koosneb kahest osast: kehtestamine füüsiline ja loogilineühendused. Esimene näitab tee, mida mööda peavad paketid minema, et ühest võrgusõlmest teise jõuda. Teine näitab video/heli parameetrid- millist kvaliteeti kasutada, milliseid koodekeid kasutada.

Vaimne staadium looPakkumine või looVastus tuleks ühendada ülekandeetappidega SDP ja Jääkandidaat objektid.

Põhiüksused

Meedia vood (MediaStream)

Peamine üksus on meediumivoog, see tähendab video- ja heliandmete, pildi ja heli voog. Meediumivooge on kahte tüüpi – kohalik ja kaug. Lokaalne saab andmeid sisendseadmetelt (kaamera, mikrofon) ja kaugjuhtimine võrgu kaudu. Seega on igal sõlmel nii kohalik kui ka kauglõng. AT WebRTC voogude jaoks on liides meediavoog ja seal on ka alamliides LocalMediaStream spetsiaalselt kohaliku lõime jaoks. AT JavaScript võite kohata ainult esimest ja kui kasutate lib kõlin, siis võib kohata ka teist.

AT WebRTC lõimes on üsna segane hierarhia. Iga voog võib koosneda mitmest meediarajast ( meediarada), mis omakorda võib koosneda mitmest meediakanalist ( MediaChannel). Ja seal võib olla ka mitu meediavoogu ise.

Vaatleme kõike järjekorras. Selleks pidagem meeles mõnda näidet. Oletame, et tahame edastada mitte ainult videot endast, vaid ka videot oma lauast, millel lebab paberitükk, millele hakkame midagi kirjutama. Vajame kahte videot (meie + tabel) ja ühte heli (meie). On selge, et meie ja tabel tuleks jagada erinevatesse lõimedesse, sest need andmed on tõenäoliselt üksteisest nõrgalt sõltuvad. Seetõttu on meil kaks meediavoog‘a – üks meile ja teine lauale. Esimene sisaldab nii video- kui ka heliandmeid ja teine ainult videot (joonis 4).

Joonis 4: Kaks erinevat meediavoogu. Üks meile, teine meie lauale

Kohe on selge, et meediavoog peaks sisaldama vähemalt võimalust sisaldada erinevat tüüpi andmeid - videot ja heli. Seda võetakse tehnoloogias arvesse ja seetõttu rakendatakse igat tüüpi andmeid meediaraja kaudu. meediarada. Meediarajal on eriline omadus lahke, mis määrab, mis on meie ees – video või heli (joonis 5)

Joonis 5: Meediumivood koosnevad meediumilugudest

Kuidas kõik programmis läheb? Loome kaks meediavoogu. Seejärel loome kaks videorada ja ühe heliriba. Saame ligipääsu kaameratele ja mikrofonile. Ütleme igale rajale, millist seadet kasutada. Lisame esimesse meediumivoogu video- ja heliriba ning teise meediumivoogu videoraja teisest kaamerast.

Kuidas aga eristada meediumivooge ühenduse teises otsas? Selleks on igal meediavool atribuut silt– voo silt, selle nimi (joonis 6). Meediumilugudel on sama omadus. Kuigi esmapilgul tundub, et videot saab helist eristada ka muul viisil.

Joonis 6: Meediumivood ja rajad on identifitseeritud siltide abil

Niisiis, kui meediumiradasid saab sildi kaudu tuvastada, siis miks peame oma näites kasutama ühe asemel kahte meediumivoogu? Lõppude lõpuks saate edastada ühe meediumivoo ja kasutada selles erinevaid lugusid. Oleme jõudnud meediavoogude olulise omaduseni – nendeni sünkroonida meediarajad. Erinevaid meediumivooge ei sünkroonita omavahel, vaid iga meediavoo sees kõiki lugusid mängis samal ajal.

Seega, kui tahame, et meie sõnad, emotsioonid näol ja paberitükk mängitaks korraga, siis tasub kasutada ühte meediavoogu. Kui see pole nii oluline, siis on tulusam kasutada erinevaid vooge - pilt on sujuvam.

Kui rada tuleb edastamise ajal keelata, saate seda atribuuti kasutada lubatud meediarajad.

Lõpuks peaksite mõtlema stereohelile. Nagu teate, on stereoheli kaks erinevat heli. Ja need tuleb ka eraldi saata. Selleks kasutatakse kanaleid. MediaChannel. Heli meediumirajal võib olla palju kanaleid (näiteks 6, kui vajate 5+1 heli). Meediaraja sees, kanalid muidugi ka sünkroniseeritud. Video jaoks kasutatakse tavaliselt ainult ühte kanalit, kuid näiteks reklaamiülekatete jaoks saab kasutada mitut.

Kokku võtma: kasutame video- ja heliandmete edastamiseks meediavoogu. Igas meediumivoos sünkroonitakse andmed. Kui me sünkroonimist ei vaja, saame kasutada mitut meediumivoogu. Igas meediumivoos on kahte tüüpi meediumiradasid – video ja heli jaoks. Tavaliselt ei ole rohkem kui kaks lugu, kuid neid võib olla rohkem, kui peate edastama mitu erinevat videot (vestluskaaslasest ja tema tabelist). Iga lugu võib koosneda mitmest kanalist, mida tavaliselt kasutatakse ainult stereoheli jaoks.

Lihtsaimas videovestluse olukorras on meil üks kohalik meediavoog, mis koosneb kahest rajast - videorajast ja heliribast, millest igaüks koosneb ühest põhikanalist. Videorada vastutab kaamera eest, heliriba mikrofoni eest ja meediavoog on mõlema konteiner.

Seansi kirjeldus (SDP)

Erinevatel arvutitel on alati erinevad kaamerad, mikrofonid, videokaardid ja muu varustus. Neil on palju võimalusi. Kõik see peab olema kooskõlastatud meediumiandmete edastamiseks kahe võrgusõlme vahel. WebRTC teeb seda automaatselt ja loob spetsiaalse objekti – seansi käepideme SDP. Edastage see objekt teisele sõlmele ja saate meediumiandmeid saata. Ainult teise sõlmega pole veel ühendust.

Selleks kasutatakse mis tahes signaalimismehhanismi. SDP saab edastada kasvõi läbi pistikupesade, kasvõi inimese poolt (rääkige telefoni teel teisele sõlmele), kasvõi Vene Postiga. Kõik on väga lihtne - teile antakse valmis SDP ja see tuleb saata. Ja teiselt poolt kättesaamisel - ülekandmine osakonda WebRTC. Seansi käepide salvestatakse tekstina ja saate seda oma rakendustes muuta, kuid tavaliselt pole seda vaja. Näiteks lauaarvuti↔telefoni ühendamisel peate mõnikord sundima soovitud helikodeki valima.

Tavaliselt tuleb ühenduse loomisel määrata näiteks mõni aadress URL. Siin pole seda vaja, kuna saadate ise andmed signaalimismehhanismi kaudu sihtkohta. Et näidata WebRTC mida tahame installida p2pühenduse loomiseks peate helistama funktsiooni CreateOffer. Pärast selle funktsiooni kutsumist ja sellele erilise andmist helista tagasi‘a luuakse SDP objekti ja edastati samale helista tagasi. Kõik, mida teilt nõutakse, on see objekt võrgu kaudu teisele sõlmele (vestluspartnerile) üle kanda. Pärast seda teises otsas tulevad andmed läbi signalisatsioonimehhanismi, nimelt selle SDP objekt. See seansi deskriptor on sellele sõlmele võõras ja sisaldab seetõttu kasulikku teavet. Selle objekti kättesaamine on signaal ühenduse alustamiseks. Seetõttu peate sellega nõustuma ja kutsuma funktsiooni createAnswer. See on CreateOfferi täielik analoog. Tagasi oma juurde helista tagasi edastab kohaliku seansi deskriptori ja see tuleb signaalimehhanismi kaudu tagasi saata.

Väärib märkimist, et funktsiooni createAnswer saate kutsuda alles pärast kellegi teise vastuse saamist SDP objektiks. Miks? Sest kohalik SDP CreateAnsweri kutsumisel genereeritav objekt peab tuginema kaugjuhtimispuldile SDP objekt. Ainult sel juhul on võimalik oma videoseadeid vestluspartneri seadetega kooskõlastada. Samuti ärge helistage createAnswer ja createOffer enne, kui kohalik meediavoog on vastu võetud – neil pole enam millelegi kirjutada SDP objekt.

Alates aastast WebRTC on võimalik redigeerida SDP objekt, siis pärast kohaliku käepideme saamist tuleb see seadistada. Möödumine võib tunduda veidi imelik WebRTC mida ta ise meile andis, aga see on protokoll. Kui saate kaugjuhtimispuldi, peate selle ka seadistama. Seetõttu peate ühele sõlmele installima kaks deskriptorit - enda ja kellegi teise (st kohaliku ja kaugseadme).

Pärast selliseid käepigistused sõlmed teavad üksteise soovidest. Näiteks kui sõlm 1 toetab koodekeid A ja B ja sõlm 2 toetab koodekeid B ja C, siis kuna iga sõlm teab oma ja teise deskriptoreid, valivad mõlemad sõlmed koodeki B(Joonis 7). Ühendusloogika on nüüd loodud ja meediumivooge saab edastada, kuid on veel üks probleem - sõlmed on endiselt ühendatud ainult signaalimismehhanismi abil.

Joonis 7: Codec läbirääkimised

Kandidaadid (jääkandidaat)

Tehnoloogia WebRTC püüab meid oma uue metoodikaga segadusse ajada. Ühenduse loomisel ei määrata selle sõlme aadressi, millega soovite ühendust luua. Esmalt installitud loogilineühendus, mitte füüsiline, kuigi alati on tehtud vastupidist. Kuid see ei tundu imelik, kui me ei unusta, et kasutame kolmanda osapoole signaalimismehhanismi.

Seega on ühendus juba loodud (loogiline ühendus), kuid võrgusõlmedel pole veel võimalust andmeid edastada. Kõik pole nii lihtne, aga alustame lihtsast. Olgu sõlmed samas privaatvõrgus. Nagu me juba teame, saavad nad oma sisemise kaudu hõlpsasti üksteisega ühenduse luua IP aadressid (või võib-olla mõni muu, kui seda ei kasutata TCP/IP).

Mõne kaudu helista tagasi'ja WebRTCütleb meile Jääkandidaat objektid. Need on ka tekstilisel kujul ja nagu seansi kirjeldused, tuleb need lihtsalt saata signaalimismehhanismi kaudu. Kui seansi deskriptor sisaldas teavet meie seadete kohta kaamera ja mikrofoni tasemel, siis kandidaadid sisaldavad teavet meie asukoha kohta võrgus. Edastage need teisele sõlmele ja ta saab meiega füüsiliselt ühenduse luua ja kuna tal on juba seansi kirjeldus, saab ta loogiliselt ühendada ja andmed "vooguvad". Kui ta ei unusta meile saatmast oma kandidaatobjekti ehk teavet selle kohta, kus ta võrgus asub, siis saame temaga ühenduse luua. Märgime siin veel ühe erinevuse klassikalisest kliendi-serveri suhtlusest. Side HTTP-serveriga toimub päringu-vastuse skeemi järgi, klient saadab andmed serverisse, mis töötleb neid ja saadab päringupaketis määratud aadress. AT WebRTC vaja teada kaks aadressi ja ühendage need mõlemalt poolt.

Erinevus seansikäepidemetest seisneb selles, et seadistada tuleb ainult kaugkandidaadid. Redigeerimine on siin keelatud ega too mingit kasu. Mõnes teostuses WebRTC kandidaadid tuleb määrata alles pärast seansipidemete seadistamist.

Ja miks oli ainult üks seansi kirjeldus, aga kandidaate võib olla palju? Kuna asukohta võrgus saab määrata mitte ainult selle sisemise järgi IP aadress, aga ka ruuteri välisaadress ja mitte tingimata üks, samuti aadressid PÖÖRE serverid. Ülejäänud lõik on pühendatud üksikasjalikule arutelule kandidaatide ja erinevate privaatvõrkude sõlmede ühendamise kohta.

Seega on kaks sõlme samas võrgus (joonis 8). Kuidas neid tuvastada? Kasutades IP aadressid. Ei muud moodi. Tõsi, ikka saab kasutada erinevaid transporte ( TCP ja UDP) ja erinevad sadamad. See on teave, mis sisaldub kandidaatobjektis - IP, PORT, TRANSPORT ja mõned teised. Lase näiteks kasutada UDP transport ja 531 sadamasse.

Joonis 8: Kaks sõlme on samas võrgus

Siis kui oleme sõlmes p1, siis WebRTC annab meile sellise kandidaatobjekti - . See ei ole täpne vorming, vaid ainult diagramm. Kui oleme sõlmes p2, siis on kandidaat . Signaalmehhanismi kaudu p1 saab kandidaadi p2(st sõlme asukoht p2, nimelt tema IP ja PORT). Siis p1 saab ühendada p2 otse. Õigem, p1 saadab andmed aadressile 10.50.150.3:531 lootuses, et nad jõuavad p2. Pole tähtis, kas see aadress kuulub sõlmele p2 või mõni vahendaja. Ainus oluline asi on see, et andmed saadetakse selle aadressi kaudu ja need jõuavad p2.

Kuni sõlmed on samas võrgus - kõik on lihtne ja lihtne - on igal sõlmel ainult üks kandidaatobjekt (mis tähendab alati oma, see tähendab selle asukohta võrgus). Aga kui sõlmed on sees, on kandidaate palju rohkem erinev võrgud.

Liigume edasi keerulisema juhtumi juurde. Üks sõlm asub ruuteri taga (täpsemalt NAT-i taga) ja teine sõlm on selle ruuteriga samas võrgus (näiteks Internetis) (joonis 9).

Joonis 9: Üks host on NAT-i taga, teine mitte

Sellel juhtumil on probleemile konkreetne lahendus, mida me nüüd kaalume. Koduruuter sisaldab tavaliselt tabelit NAT. See on spetsiaalne mehhanism, mis on loodud selleks, et võimaldada ruuteri privaatvõrgu sõlmedel pääseda juurde näiteks veebisaitidele.

Oletame, et veebiserver on otse Internetiga ühendatud, see tähendab, et sellel on avalik IP* aadress. Las see olla sõlm p2. Sõlm p1(veebiklient) saadab päringu aadressile 10.50.200.10 . Esiteks lähevad andmed ruuterisse r1, õigemini tema peal interjöör liides 192.168.0.1 . Pärast seda jätab ruuter meelde lähteaadressi (aadress p1) ja sisestab selle spetsiaalsesse tabelisse NAT, seejärel muudab lähteaadressi enda aadressiks ( p1 → r1). Lisaks vastavalt välised liides, saadab ruuter andmed otse veebiserverisse p2. Veebiserver töötleb andmeid, genereerib vastuse ja saadab need tagasi. Saadab ruuterile r1, kuna just tema on tagastusaadressis (ruuter muutis aadressi enda omaks). Ruuter saab andmeid, vaatab tabelit NAT ja saadab andmed sõlme p1. Ruuter toimib siin vahendajana.

Aga mis siis, kui mitu sisevõrgu sõlme pääsevad välisvõrku korraga? Kuidas saab ruuter aru, kellele vastus tagasi saata? See probleem lahendatakse koos sadamad. Kui ruuter asendab hostiaadressi enda aadressiga, asendab see ka pordi. Kui kaks sõlme pääsevad Internetti, asendab ruuter nende lähtepordid mitmesugused. Seejärel, kui veebiserveri pakett ruuterisse tagasi jõuab, saab ruuter aru pordi järgi, kellele see pakett on määratud. Näide on allpool.

Tagasi Tehnoloogia juurde WebRTC või õigemini selle osale, mis kasutab JÄÄ protokoll (seega Jää kandidaadid). Sõlm p2 on üks kandidaat (selle asukoht võrgus - 10.50.200.10 ) ja sõlm p1, mis asub NAT-iga ruuteri taga, on kaks kandidaati - kohalik ( 192.168.0.200 ) ja ruuterikandidaat ( 10.50.200.5 ). Esimene ei ole kasulik, kuid sellest hoolimata genereeritakse see WebRTC ei tea kaughostist veel midagi – see võib olla samas võrgus, aga ei pruugi olla. Teine kandidaat tuleb kasuks ja nagu me juba teame, on sadamal oluline roll (läbi saada NAT).

Tabeli sissekanne NAT luuakse ainult siis, kui andmed sisevõrgust väljuvad. Seetõttu sõlm p1 peab esmalt edastama andmed ja alles pärast seda sõlme andmed p2 pääseb sõlme p1.

Praktikas mõlemad sõlmed jääb maha NAT. Tabelisse kirje loomiseks NAT iga ruuteri puhul peavad sõlmed saatma midagi kaugsõlmele, kuid seekord ei jõua esimene teiseni ega ka vastupidi. See on tingitud asjaolust, et sõlmed ei tea oma välist IP aadressid ja andmete saatmine siseaadressidele on mõttetu.

Kui aga välisaadressid on teada, on ühendus hõlpsasti loodud. Kui esimene sõlm saadab andmed teise sõlme ruuterile, siis ruuter ignoreerib neid, kuna selle tabel NAT tühja ajal. Küll aga tabeli esimese sõlme ruuteris NAT oli vaja rekordit. Kui nüüd saadab teine sõlm andmed esimese sõlme ruuterile, siis ruuter edastab need edukalt esimesse sõlme. Nüüd laud NAT teisel ruuteril on vajalikud andmed.

Probleem on selles, et teada oma välist IP aadressi, vajate ühises võrgus asuvat sõlme. Selle probleemi lahendamiseks kasutatakse täiendavaid servereid, mis on otse Internetiga ühendatud. Nende abiga valmivad ka tabelis olevad väärtuslikud kirjed. NAT.

STUN ja TURN serverid

Initsialiseerimisel WebRTC saadaval URMASTUS ja PÖÖRE serverid, mida me nimetame JÄÄ serverid. Kui servereid pole määratud, siis ainult sama võrgu sõlmed (sellega ühendatud ilma NAT). Tuleb kohe märkida, et selleks 3g- tuleb kasutada võrke PÖÖRE serverid.

URMASTUS server on lihtsalt server Internetis, mis tagastab tagastusaadressi, st saatja hosti aadressi. Juurdepääsuks on ruuteri taga asuv sõlm URMASTUS server läbimiseks NAT. Pakk, mis tuli URMASTUS server, sisaldab lähteaadressi - ruuteri aadressi, see tähendab meie sõlme välist aadressi. See aadress URMASTUS server ja saadab tagasi. Seega saab sõlm oma välise IP aadress ja port, mille kaudu see on võrgust juurdepääsetav. Edasi, WebRTC selle aadressi kasutamine loob täiendava kandidaadi (välise ruuteri aadressi ja pordi). Nüüd tabelis NAT ruuteril on kirje, mis edastab ruuterile saadetud paketid vajalikul pordil meie sõlme.

Vaatame seda protsessi näitega.

Näide (STUN-serveri töö)

URMASTUS serverit tähistatakse s1. Ruuter, nagu varemgi, läbi r1, ja sõlm läbi p1. Samuti peate järgima tabelit NAT- tähistame seda kui r1_nat. Lisaks sisaldab see tabel tavaliselt palju kirjeid erinevatest alamvõrgu sõlmedest - neid ei anta.

Nii et alguses on meil tühi laud r1_nat.

Tabel 2: Paketi päis

Sõlm p1 saadab selle paketi ruuterile r1(ükskõik kuidas, erinevates alamvõrkudes saab kasutada erinevaid tehnoloogiaid). Ruuter peab lähteaadressi asendama src IP, kuna paketis määratud aadress ilmselgelt välise alamvõrgu jaoks ei sobi, pealegi on selle vahemiku aadressid reserveeritud ja ühelgi Interneti-aadressil pole sellist aadressi. Ruuter teeb paketis asenduse ja loob oma tabelisse uue kirje r1_nat. Selleks peab ta välja mõtlema pordi numbri. Tuletage meelde, et kuna alamvõrgu mitu sõlme pääsevad välisvõrku, siis tabelis NAT tuleb salvestada lisateavet, et ruuter saaks kindlaks teha, millisele neist mitmest hostist on serveri tagastatav pakett mõeldud. Laske ruuteril port välja pakkuda 888 .

Muudetud paketi päis:

Tabel 4: NAT-tabelit värskendati uue kirjega

Siin IP alamvõrgu aadress ja port on täpselt samad, mis originaalpaketil. Tõepoolest, tagasipostitamisel peab meil olema võimalus need täielikult taastada. IP välisvõrgu aadress on ruuteri aadress ja port on muutunud ruuteri leiutatud portiks.

Tõeline port, kuhu sõlm p1 nõustub ühendusega - see muidugi 35777 , kuid server saadab andmed aadressile fiktiivne sadamasse 888 , mille ruuter muudab päriseks 35777 .

Seega muutis ruuter paketi päises lähteaadressi ja porti ning lisas tabelisse kirje NAT. Nüüd saadetakse pakett üle võrgu serverisse ehk sõlme s1. sissepääsu juures, s1 on selline pakett:

src IP	Src PORT	Sihtkoha IP	KOHTA SADAM
10.50.200.5	888	12.62.100.200	6000

Tabel 5: STUN-server sai paketi

Kokku URMASTUS server teab, et sai aadressilt paketi 10.50.200.5:888 . Nüüd saadab server selle aadressi tagasi. Siin tasub peatuda ja äsja kaalutu uuesti üle vaadata. Ülaltoodud tabelid on osa päis pakendist, üldse mitte sellest sisu. Sisust me ei rääkinud, kuna see pole nii oluline – see on kuidagi protokollis kirjeldatud URMASTUS. Nüüd käsitleme lisaks pealkirjale ka sisu. See on lihtne ja sisaldab ruuteri aadressi - 10.50.200.5:888 kuigi me võtsime selle päis pakett. Seda ei tehta sageli, tavaliselt protokollid sõlmede aadresside infost ei hooli, oluline on vaid, et paketid jõuaksid sihtkohta. Siin käsitleme protokolli, mis loob tee kahe sõlme vahel.

Nüüd on meil teine partii vastupidises suunas:

Tabel 7: STUN-server saadab selle sisuga paketi

Järgmisena liigub pakett läbi võrgu, kuni see jõuab ruuteri välisliideseni r1. Ruuter saab aru, et pakett pole talle mõeldud. Kuidas ta sellest aru saab? Selle leiab ainult sadam. Port 888 ta ei kasuta oma isiklikel eesmärkidel, vaid kasutab mehhanismi jaoks NAT. Seetõttu vaatab ruuter seda tabelit. Vaatab veergu Väline PORT ja otsib stringi, mis sobib KOHTA SADAM sissetulevast pakist, st 888 .

sisemine IP	Sisemine PORT	väline IP	Väline PORT
192.168.0.200	35777	10.50.200.5	888

Tabel 8: NAT-tabel

Meil on vedanud, et selline liin on olemas. Kui ei veaks, visatakse pakk lihtsalt ära. Nüüd peate mõistma, milline alamvõrgu sõlmedest peaks selle paketi saatma. Ärgem kiirustagem, vaid korrakem sadamate tähtsust selles mehhanismis. Samal ajal võivad kaks alamvõrgu sõlme saata päringuid välisvõrku. Siis, kui ruuteril tuli esimese sõlme jaoks välja port 888 , siis teiseks mõtleks ta portsu välja 889 . Oletame, et see juhtus, see tähendab laud r1_nat näeb välja selline:

Tabel 10: ruuteri vastuvõtja aadressi võltsimine

src IP	Src PORT	Sihtkoha IP	KOHTA SADAM
12.62.100.200	6000	192.168.0.200	35777

Tabel 11: ruuter muutis vastuvõtja aadressi

Pakett jõuab edukalt sõlme p1 ja paketi sisu vaadates saab sõlm teada selle välisest IP aadress, st ruuteri aadress välisvõrgus. Samuti teab see porti, mida ruuter läbib NAT.

Mis järgmiseks? Mis sellest kõigest kasu on? Kasu on kanne tabelis r1_nat. Kui nüüd keegi ruuterile saadab r1 sadama pakett 888 , siis edastab ruuter selle paketi hostile p1. Nii tekkis väike kitsas käik peidetud sõlme p1.

Ülaltoodud näite põhjal saate selle toimimisest aimu. NAT ja olemus URMASTUS server. Üldiselt mehhanism JÄÄ ja Uimastamist/pööret serverite eesmärk on lihtsalt piirangutest üle saada NAT.

Sõlme ja serveri vahel võib olla rohkem kui üks ruuter, kuid mitu. Sel juhul saab sõlm selle ruuteri aadressi, mis siseneb esimesena serveriga samasse võrku. Teisisõnu saame ühendatud ruuteri aadressi URMASTUS server. Sest p2p side on just see, mida vajame, kui me ei unusta tõsiasja, et igas ruuteris lisatakse tabelisse vajalik rida NAT. Nii et tagasitee on jälle sama sujuv.

PÖÖRE server on täiustatud URMASTUS server. Sellest järeldub kohe, et mis tahes PÖÖRE server saab töötada ja kuidas URMASTUS server. Siiski on ka eeliseid. Kui a p2p suhtlemine pole võimalik (nagu 3g võrgud), siis lülitub server repiiteri režiimi ( relee), see tähendab, et see töötab vahendajana. Muidugi, ükskõik millise kohta p2p siis pole see küsimus, vaid väljaspool mehhanismi raamistikku JÄÄ sõlmed arvavad, et nad suhtlevad otse.

Millistel juhtudel on see vajalik PÖÖRE server? Miks ei piisa URMASTUS serverid? Fakt on see, et neid on mitut tüüpi NAT. Need asendavad sama IP aadress ja port, kuid mõnel neist on sisseehitatud lisakaitse võltsimise vastu. Näiteks sisse sümmeetriline laud NAT Veel 2 parameetrit on salvestatud - IP ja kaughosti port. Läbi käib välisvõrgu pakett NAT sisevõrku ainult siis, kui lähteaadress ja port ühtivad tabelis registreeritutega. Seetõttu keskendutakse URMASTUS server ebaõnnestub – tabel NAT salvestab aadressi ja pordi URMASTUS server ja kui ruuter saab paketi WebRTC vestluskaaslane, heidab ta temast kõrvale, kuna ta on "võltsitud". Ta ei tulnud URMASTUS server.

Sellel viisil PÖÖRE serverit on vaja siis, kui mõlemad vestluskaaslased on taga sümmeetriline NAT(igaüks oma).

Lühikokkuvõte

Siin on mõned väited üksuste kohta WebRTC mida tuleb alati meeles pidada. Neid on üksikasjalikult kirjeldatud eespool. Kui mõni väide ei tundu teile täiesti selge, lugege asjakohased lõigud uuesti läbi.

meediavoog
- Video- ja heliandmed pakitakse meediumivoogudesse
- Meediumivood sünkroonivad moodustavaid meediumilugusid
- Erinevad meediumivood on sünkroonist väljas
- Meediumivood võivad olla lokaalsed ja kaugjuhtimisega, kaamera ja mikrofon on tavaliselt ühendatud lokaalsega, kaugvood saavad võrgust andmeid krüpteeritult
- Meediumiradu on kahte tüüpi – video ja heli jaoks.
- Meediumiradadel on võimalus sisse/välja lülitada
- Meediarajad koosnevad meediakanalitest
- Meediarajad sünkroonivad moodustavaid meediumikanaleid
- Meediumivoogudel ja -lugudel on sildid, mille järgi neid saab eristada
Seansi käepide
- Seansi deskriptorit kasutatakse kahe võrgusõlme loogiliseks ühendamiseks
- Seansi deskriptor salvestab teavet video- ja heliandmete saadaolevate kodeerimismeetodite kohta.
- WebRTC kasutab välist signaalimismehhanismi - seansi kirjelduste edastamise ülesannet ( sdp) langeb rakendusele
- Loogiline ühendusmehhanism koosneb kahest etapist - ettepanekust ( pakkuma) ja vastus ( vastama)
- Seansi deskriptori genereerimine ei ole võimalik ilma pakkumise korral kohalikku meediavoogu kasutamata ( pakkuma) ja see pole võimalik ilma kaugseansi kirjeldust kasutamata vastuse korral ( vastama)
- Saadud deskriptor tuleb anda rakendamisele WebRTC, ja pole vahet, kas see käepide saadakse samast rakendusest eemalt või kohapeal WebRTC
- Seansi kirjeldust on võimalik veidi muuta
Kandidaadid
- kandidaat ( Jääkandidaat) on võrgu sõlme aadress
- Sõlme aadress võib olla teie enda aadress või ruuteri aadress või PÖÖRE serverid
- Kandidaate on alati palju
- Kandidaat koosneb IP aadress, sadam ja transpordiliik ( TCP või UDP)
- Kandidaate kasutatakse füüsilise ühenduse loomiseks võrgu kahe sõlme vahel
- Kandidaadid tuleb saata ka signaalimismehhanismi kaudu
- Kandidaadid peavad läbima ka teostused WebRTC, kuid ainult kaug
- Mõnes teostuses WebRTC Kandidaate saab läbida alles pärast seansi kirjelduse määramist
SUN/TURN/ICE/NAT
- NAT– välisvõrgule juurdepääsu võimaldamise mehhanism
- Koduruuterid toetavad spetsiaalset tabelit NAT
- Ruuter asendab pakettides olevad aadressid - lähteaadressi enda aadressiga, juhul kui pakett läheb välisvõrku, ja vastuvõtja aadressi sisevõrgu hosti aadressiga, kui pakett tuli välisvõrgust.
- Mitme kanaliga juurdepääsu pakkumiseks välisele võrgule NAT kasutab porte
- JÄÄ- möödaviigumehhanism NAT
- URMASTUS ja PÖÖRE serverid - abiserverid möödasõiduks NAT
- URMASTUS server võimaldab luua tabelisse vajalikud kirjed NAT ja tagastab ka sõlme välisaadressi
- PÖÖRE server üldistab URMASTUS mehhanism ja paneb selle alati tööle
- Halvematel juhtudel PÖÖRE serverit kasutatakse vahendajana ( relee), see on p2p muutub kliendi-serveri-kliendi ühenduseks.

Euroopa internetikasutajad jagunevad kahte ossa: Allenbachis (Saksamaa) asuva Avaliku Arvamuse Analüüsi Instituudi küsitluse kohaselt on Skype, vestlus- ja kiirsuhtlussüsteemid muutunud igapäevaelu lahutamatuks osaks 16,5 miljoni täiskasvanu ja lapse jaoks, 9 miljonit inimest. kasutavad neid teenuseid iga juhtumi puhul eraldi ja 28 miljonit ei puuduta neid.

Olukord võib muutuda, kuna nüüd on Firefox integreeritud reaalajas kommunikatsioonitehnoloogia (WebRTC), aga ka klient ise. Heli- ja videovestluse alustamine pole nüüd keerulisem kui veebisaidi avamine. Teenused nagu Facebook ja Skype aga tuginevad lahendustele, mis kasutavad eraldi klienti ja loovad konto.

WebRTC-d pole mitte ainult lihtne kasutada. See meetod võimaldab teil isegi määrata otseühendus kahe brauseri vahel. Seega ei liigu heli- ja videoandmed läbi serveri, kus võib tekkida ülekoormus või kus administraator ei ole privaatsuse või andmekaitse suhtes eriti tundlik. Otseühenduse korral ei nõua WebRTC registreerimist ega kontot ühegi teenusega.

Vestluse alustamiseks peate järgima ainult linki. Suhtlemine jääb privaatseks kuna andmevoog on krüpteeritud. Google hakkas brauseri kaudu reaalajas suhtlemisega aktiivselt tegelema juba 2011. aastal, kui avaldas oma WebRTC juurutuse lähtekoodi.

Varsti pärast seda said Chrome ja Firefox oma WebRTC mootorid. Praegu on nende mobiiliversioonid varustatud nii selle tehnoloogiaga kui ka WebView 3.6 mootoriga, millele on installitud Android 5.0, mida rakendused kasutavad.

Reaalajas suhtlemiseks tuleb veebivaaturis realiseerida vastavad JavaScripti liidesed. GetUserMedia abil võimaldab tarkvara jäädvustada heli- ja videoallikatest, st veebikaamerast ja mikrofonist. RTCPeerConnection vastutab nii ühenduse loomise kui ka suhtluse enda eest.

Paralleelselt brauseri integreerimisega on World Wide Web Consortium (W3C) töörühm edendanud WebRTC standardimisprotsessi. See peaks valmima 2015. aastal.

WebRTC on rahul vähesega

WebRTC teenuse kasutamine ei nõua palju ressursse, kuna server ühendab ainult sõpru. Ühenduse loomine pole samuti eriti keeruline. Esiteks annab brauser WebRTC-serverile märku, et ta kavatseb kõne algatada. See saab serverist HTTPS-lingi – ühendus on krüptitud. Kasutaja saadab selle lingi oma vestluskaaslasele. Seejärel küsib brauser kasutajalt luba veebikaamerale ja mikrofonile juurdepääsuks.

Otsese voogedastusühenduse loomiseks teise osapoolega saab brauser oma IP-aadressi ja konfiguratsiooniandmed WebRTC teenuselt. Sõbra veebibrauser teeb sama.

Voogedastusühenduse sujuvaks ja kvaliteetseks toimimiseks töötab brauseris kolm mootorit. Kaks neist optimeerivad ja tihendavad heli- ja videoandmeid, kolmas vastutab nende transpordi eest. See saadab andmeid kaudu SRTP protokoll(Secure Real-time Transport Protocol), mis võimaldab reaalajas krüptitud voogesitust.

Kui otseühendus ebaõnnestub, otsib WebRTC teist teed. Näiteks juhtub see siis, kui võrguseaded takistavad STUN-serveril IP-aadressi teatamist. WebRTC standard näeb ette, et sel juhul vestlus toimub, kuid vahepealse TURN-serveri kaasamisega (Traversal Using Relays around NAT). Seega saate veebisaidil netscan.co kontrollida, kas WebRTC on teie arvutis ja teie juurdepääsuga veebile rakendatud.

Kuidas ühendus luuakse

Esmalt peate vestluse registreerima (1). WebRTC teenus pakub linki, mis tuleb vestluspartnerile saata. Brauser otsib STUNserveri abil välja oma IP-aadressi (2), saadab selle teenusele ja saab otseühenduse loomiseks partneri IP-aadressi (3). Kui STUN ebaõnnestub, suunatakse vestlus TURN-serveri (4) abil ümber.

Brauseris WebRTC-tehnoloogiat kasutav suhtlus käivitatakse JavaScripti koodi abil. Pärast seda vastutavad suhtluse eest kolm mootorit: kõne- ja videomootorid koguvad veebikaamerast ja mikrofonist multimeediumiandmeid ning transpordimootor ühendab teabe ja saadab voo krüpteeritud kujul, kasutades turvalist reaalajaprotokolli (SRTP).

Millised brauserid WebRTC-ga töötavad?

Chrome ja Firefox on varustatud WebRTC mootoriga, mis kasutab selliseid teenuseid nagu talky.io. Mozilla brauser saab töötada otse oma kliendiga.

Google ja Mozilla jätkavad reaalajas suhtlemise idee arendamist: Chrome saab korraldada WebRTC konverentsi mitme osalejaga ning Firefoxi uus Hello klient töötatakse välja telekommunikatsioonihiiglase Telefonica tütarettevõtte abiga. Apple jääb praegu kõrvale, te ei tohiks WebRTC-d Safaris veel oodata. Siiski on Safari jaoks palju alternatiivseid iOS-i rakendusi ja pistikprogramme.

Microsoft võtab veidi teistsuguse kursi. Konkurentsivõimelise Skype'i teenuse omanikuna ei kavatse see ettevõte WebRTC-le nii lihtsalt alla anda. Selle asemel arendab Microsoft Internet Exploreri jaoks tehnoloogiat nimega ORTC (Object Real-Time Communications).

Erinevused WebRTC-st, nagu erinevad koodekid ja protokollid serveriga kontakti loomiseks, on väikesed ja aja jooksul lisanduvad tõenäoliselt WebRTC standardile, mis hõlmab ka neid erinevusi. Seega jääb maha vaid Apple – nagu ikka.

Foto: tootmisettevõtted; goodluz/Photolia.com

Brauserist helistamise tehnoloogiad on aastaid vanad: Java, ActiveX, Adobe Flash... Viimastel aastatel on selgunud, et pistikprogrammid ja vasakpoolsed virtuaalmasinad ei hiilga mugavusest (miks ma peaksin midagi installima kõik?) ja, mis kõige tähtsam, turvalisus . Mida teha? Väljapääs on olemas!

Kuni viimase ajani kasutati IP-võrkudes IP-telefoni või -video jaoks mitut protokolli: SIP, kõige levinum sündmuskohalt väljuv protokoll, H.323 ja MGCP, Jabber/Jingle (kasutatakse Gtalkis), poolavatud Adobe RTMP* ja muidugi Skype suletud. Google'i algatatud WebRTC projekt püüab IP- ja veebitelefonimaailma ümber pöörata, muutes kõik tarkvaratelefonid, sealhulgas Skype, aegunuks. WebRTC ei rakenda mitte ainult kõiki suhtlusvõimalusi otse brauseris, mis on nüüd installitud peaaegu igasse seadmesse, vaid püüab samaaegselt lahendada ka üldisemat brauseri kasutajate vahelise suhtluse ülesannet (erinevate andmete vahetamine, ekraani tõlkimine, koostöö dokumentidega ja palju rohkem).

WebRTC veebiarendaja poolt

Veebiarendaja seisukohast koosneb WebRTC kahest põhiosast:

kohalikest ressurssidest (kaamerast, mikrofonist või kohalikust arvutiekraanist) pärinevate meediumivoogude haldamine on realiseeritud meetodi navigator.getUserMedia abil, mis tagastab MediaStreami objekti;
peer-to-peer side meediavooge genereerivate seadmete vahel, sealhulgas sidemeetodite määratlemine ja nende otseedastus - RTCPeerConnectioni objektid (heli- ja videovoogude saatmiseks ja vastuvõtmiseks) ning RTCDataChannel (brauserist andmete saatmiseks ja vastuvõtmiseks).

Mida me siis teeme?

Selgitame välja, kuidas korraldada veebipistikupesade abil WebRTC-l põhinevat lihtsaimat mitme mängijaga videovestlust brauserite vahel. Alustame katsetamist Chrome/Chromiumiga, mis on WebRTC mõttes kõige arenenum brauser, kuigi 24. juunil välja antud Firefox 22 jõudis neile peaaegu järele. Peab ütlema, et standardit pole veel vastu võetud ja API võib versiooniti muutuda. Kõiki näiteid testiti Chromium 28-s. Lihtsuse huvides me ei jälgi koodi puhtust ja brauseritevahelist ühilduvust.

meediavoog

Esimene ja lihtsaim WebRTC komponent on MediaStream. See annab brauserile juurdepääsu meediumivoogudele kohaliku arvuti kaamerast ja mikrofonist. Chrome'is nõuab see funktsiooni navigator.webkitGetUserMedia() väljakutsumist (kuna standard pole veel lõplikult vormistatud, on kõigil funktsioonidel eesliide ja Firefoxis kannab sama funktsioon nime navigator.mozGetUserMedia()). Kui see helistatakse, palutakse kasutajal lubada juurdepääs kaamerale ja mikrofonile. Kõnet on võimalik jätkata alles pärast kasutaja nõusoleku andmist. Sellele funktsioonile edastatakse parameetritena vajaliku meediavoo parameetrid ja kaks tagasihelistamisfunktsiooni: esimene helistatakse kaamera/mikrofoni eduka juurdepääsu korral, teine - vea korral. Kõigepealt loome nupu ja elemendiga HTML-faili rtctest1.html

WebRTC – esimene tutvus

Microsoft CU-RTC-Web

Microsoft poleks Microsoft, kui ta ei anna vastuseks Google'i algatusele kohe välja oma ühildumatut kohandatud varianti nimega CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm). . Kuigi niigi väikese IE osakaal jätkab langust, annab Skype’i kasutajate arv Microsoftile lootust Google’i peale suruda ning võib oletada, et seda standardit hakatakse kasutama ka Skype’i brauseriversioonis. Google'i standard keskendub peamiselt brauseritevahelisele suhtlusele; samal ajal jääb suurem osa kõneliiklusest endiselt tavapärasesse telefonivõrku ning selle ja IP-võrkude vahelisi lüüsi on vaja mitte ainult kasutamise hõlbustamiseks või kiiremaks levitamiseks, vaid ka raha teenimise vahendina, mis võimaldab rohkematel mängijatel neid arendada. Teise standardi ilmumine võib mitte ainult tekitada arendajates ebameeldiva vajaduse toetada korraga kahte omavahel mitteühilduvat tehnoloogiat, vaid anda ka tulevikus kasutajale suurema valiku võimalike funktsionaalsuste ja olemasolevate tehniliste lahenduste osas. Oota ja vaata.

Luba kohalik lõim

Sildid sees Deklareerime oma HTML-failis meediumivoo jaoks globaalse muutuja:

VarlocalStream = null;

GetUserMedia meetodi esimene parameeter on soovitud meediumivoo parameetrite määramine – näiteks lihtsalt heli või video lubamine:

Var streamConstraints = ( "heli": tõsi, "video": tõsi ); // Taotlege juurdepääsu nii helile kui ka videole

Või määrake lisavalikud:

Var streamConstraints = ( "heli": tõsi, "video": ( "kohustuslik": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "valikuline": ) );

GetUserMedia meetodi teine parameeter on tagasihelistamisfunktsiooni edastamine, mis kutsutakse välja, kui see õnnestub:

Funktsioon getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Meediumivoo lisamine HTML-elemendile

Kolmas parameeter on tagasihelistamise funktsioon, veakäsitleja, mis kutsutakse välja vea korral.

Funktsioon getUserMedia_error(error) ( console.log("getUserMedia_error():", viga); )

Tegelik väljakutse getUserMedia meetodile – juurdepääsu taotlemine mikrofonile ja kaamerale esimese nupu vajutamisel

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

Lokaalselt avatud failist pole meediumivoogu võimalik juurde pääseda. Kui proovime seda teha, saame veateate:

NavigatorUserMediaError (kood: 1, PERMISSION_DENIED: 1)"

Laadime saadud faili serverisse, avame selle brauseris ja lubame vastuseks ilmuvale päringule juurdepääsu kaamerale ja mikrofonile.

Saate valida, millistele seadmetele Chrome juurde pääseb. Selleks avage jaotis Seaded, Kuva täpsemate seadete link, jaotis Privaatsus ja nupp Sisu. Firefoxi ja Opera brauserites valitakse seadmed ripploendist otse juurdepääsu andmisel.

HTTP-protokolli kasutamisel küsitakse luba iga kord, kui pärast lehe laadimist meediumivoogu avatakse. HTTPS-ile lülitumine võimaldab teil taotlust kuvada üks kord, ainult meediumivoo esimesel juurdepääsul.

Pöörake tähelepanu pulseerivale ringile vahekaardi ikoonil ja kaameraikoonile aadressiriba paremal küljel:

RTCMediaConnection

RTCMediaConnection - objekt, mis on loodud meediumivoogude loomiseks ja edastamiseks võrgu kaudu osalejate vahel. Lisaks vastutab see objekt meediumiseansi kirjelduse (SDP) genereerimise, ICE-kandidaatide kohta teabe hankimise eest NAT-i või tulemüüride (kohalikud ja STUN-i kasutavad) läbimiseks ning TURN-serveriga suhtlemise eest. Igal osalejal peab ühenduse kohta olema üks RTCMediaConnection. Meediumivood edastatakse krüptitud SRTP-protokolli kaudu.

TURN serverid

ICE kandidaate on kolme tüüpi: host, srflx ja relay. Host sisaldab kohapeal saadud teavet, srflx on see, kuidas host näeb välja välise serveri jaoks (STUN) ja relee on teave liikluse puhverserveriks läbi TURN-serveri. Kui meie sõlm on NAT-i taga, siis hostikandidaadid sisaldavad kohalikke aadresse ja on kasutud, srflx-kandidaadid aitavad ainult teatud tüüpi NAT-i puhul ja relee on viimane lootus liiklust läbi vaheserveri edastada.

Näide ICE kandidaadist hostitüübist aadressiga 192.168.1.37 ja pordiga udp/34022:

A=kandidaat:337499441 2 udp 2113937151 192.168.1.37 34022 tüüp hosti põlvkond 0

STUN/TURN serverite määramise üldine vorming:

Var serverid = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [e-postiga kaitstud]:port", "mandaat": "parool" ) ]);

Internetis on palju avalikke STUN-servereid. Suur nimekiri on näiteks . Kahjuks lahendavad need liiga vähe probleeme. Erinevalt STUNist avalikke TURN-servereid praktiliselt pole. Selle põhjuseks on asjaolu, et TURN-server laseb ise läbi meediavooge, mis võib oluliselt koormata nii võrgukanalit kui ka serverit ennast. Seetõttu on kõige lihtsam viis TURN-i serveritega ühenduse loomiseks see ise installida (ilmselgelt vajate avalikku IP-d). Kõigist serveritest on minu arvates parim rfc5766-turn-server . Selle all on isegi Amazon EC2 jaoks valmis pilt.

TURNiga pole kõik nii hästi, kui tahaksime, kuid aktiivne areng on käimas ja tahaks loota, et mõne aja pärast WebRTC, kui mitte võrdne Skype'iga aadressi tõlkimise (NAT) läbimise kvaliteedilt ja tulemüürid, siis vähemalt märgatavalt lähemale.

RTCMediaConnection vajab ühenduse loomiseks täiendavat juhtimisinfo vahetamise mehhanismi – kuigi ta genereerib need andmed, ei edasta neid ning edastamine teiste osalejate poolt tuleb eraldi realiseerida.

Edastusmeetodi valiku eest vastutab arendaja – vähemalt käsitsi. Niipea, kui vajalikud andmed on vahetatud, seadistab RTCMediaConnection automaatselt meediavoogusid (loomulikult võimalusel).

pakkumine-vastus mudel

Meediumivoogude loomiseks ja muutmiseks kasutatakse pakkumise / vastuse mudelit (pakkumine / vastus; kirjeldatud RFC3264-s) ja SDP-protokolli (Session Description Protocol). Neid kasutab ka SIP-protokoll. Selles mudelis eristatakse kahte agenti: Pakkuja – see, kes genereerib SDP seansi kirjelduse, et luua uus või muuta olemasolevat (Offer SDP) ja vastaja – see, kes saab SDP seansi kirjelduse teiselt agendilt ja vastab. sellele oma seansi kirjeldusega (Vastus SDP). Samal ajal nõuab spetsifikatsioon kõrgema taseme protokolli (näiteks SIP või oma veebipistikupesade kaudu, nagu meie puhul), mis vastutab SDP edastamise eest agentide vahel.

Milliseid andmeid tuleb kahe RTCMediaConnectioni vahel edastada, et nad saaksid edukalt luua meediumivooge:

Esimene ühenduse algataja moodustab Pakkumise, milles saadab SDP andmestruktuuri (sama protokolli kasutatakse samal eesmärgil SIP-is), mis kirjeldab edastamist alustava meediumivoo võimalikke omadusi. See andmeplokk tuleb teisele osalejale üle kanda. Teine osaleja genereerib oma SDP-ga vastuse ja saadab selle esimesele.
Nii esimene kui ka teine osaleja viivad läbi võimalike ICE kandidaatide väljaselgitamise protseduuri, mille abil saab teine osaleja neile meediavoo üle kanda. Kandidaatide tuvastamisel tuleks teave nende kohta edastada teisele osalejale.

Pakkumise moodustamine

Pakkumise moodustamiseks vajame kahte funktsiooni. Esimene kutsutakse selle eduka moodustamise korral. Meetodi createOffer() teine parameeter on tagasihelistamise funktsioon, mida kutsutakse selle täitmisel ilmneva vea korral (eeldusel, et kohalik voog on juba saadaval).

Lisaks on vaja kahte sündmuste töötlejat: onicecandidate uue ICE kandidaadi määratlemisel ja onaddstream meediumivoo ühendamisel kaugemast küljest. Läheme tagasi oma faili juurde. Lisage HTML-i elementidega ridade järel

Ja pärast rida elemendiga

Samuti deklareerime JavaScripti koodi alguses RTCPeerConnectioni globaalse muutuja:

varpc1;

RTCPeerConnection konstruktori kutsumisel peate määrama STUN/TURN serverid. Lisateabe saamiseks vaadake külgriba; seni, kuni kõik osalejad on samas võrgus, pole neid vaja.

var serverid = null;

Pakkumise SDP valikud

var offerConstraints = ();

Meetodi createOffer() esimene parameeter on tagasihelistamisfunktsioon, mida kutsutakse pakkumise edukal moodustamisel

Funktsioon pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Määrake theConne'i loodud RTCPeer Paku SDP meetodit setLocalDescription. // Kui kaugem pool saadab oma Answer SDP, tuleb see määrata kasutades setRemoteDescription meetodit // Kuni teise külje juurutamiseni ärge tehke midagi // pc2_receivedOffer(desc); )

Teine parameeter on tagasihelistamise funktsioon, mis kutsutakse välja vea korral

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

Ja me deklareerime tagasihelistamisfunktsiooni, mis edastatakse ICE kandidaatidele, nagu need on määratletud:

Funktsioon pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Ärge tehke midagi enne, kui teine pool on rakendatud // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Lisaks tagasihelistamisfunktsioonile meediavoo lisamiseks kaugemalt (tuleviku jaoks, kuna meil on seni ainult üks RTCPeerConnection):

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

Kui klõpsate nupul "loo pakkumine", looge RTCPeerConnection, määrake onicecandidate ja onaddstream meetodid ning taotlege Offer SDP moodustamist, kutsudes välja meetodi createOffer():

Funktsioon createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // RTCPeerConnectioni loomine pc1.onicecandidate = pc1_onicecandidate; // Tagasihelistamise funktsioon ICE kandidaatide töötlemiseks pc1.onaddonad =dstream / Tagasihelistamise funktsioon kutsutakse välja, kui kaugemalt on meediumivoog, seda pole veel olemas pc1.addStream(localStream); // Kohaliku meediavoo edastamine (eeldusel, et see on juba vastu võetud) pc1.createOffer(// Ja tegelikult taotleda pakkumise moodustamist pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Salvestame faili nimega rtctest2.html, paneme serverisse, avame brauseris ja vaatame konsoolis, millised andmed selle töö käigus tekivad. Teist videot veel ei ilmu, kuna osalejaid on vaid üks. Tuletame meelde, et SDP on meediumiseansi parameetrite kirjeldus, saadaolevad koodekid, meediumivood ja ICE-kandidaadid on võimalikud valikud selle osalejaga ühenduse loomiseks.

Vastuse SDP moodustamine ja ICE kandidaatide vahetus

Nii Offer SDP kui ka iga ICE kandidaat tuleb edastada teisele poole ja seal, pärast nende saamist RTCPeerConnectionist, kutsuda välja meetodid setRemoteDescription Offer SDP jaoks ja addIceCandidate iga kaugemalt saadud ICE kandidaadi jaoks; samamoodi vastupidiselt Answer SDP ja kaug-ICE kandidaatide puhul. Vastuse SDP ise moodustatakse sarnaselt Pakkumisega; erinevus seisneb selles, et kutsutakse mitte meetodit createOffer, vaid meetodit createAnswer ja enne seda antakse RTCPeerConnection meetodile setRemoteDescription edasi helistajalt saadud Offer SDP.

Lisame HTML-ile veel ühe videoelemendi:

Ja teise RTCPeerConnectioni globaalne muutuja esimese deklaratsiooni all:

Varpc2;

SDP pakkumise ja vastuse töötlemine

Vastuse vormistamine SDP on väga sarnane pakkumisega. Tagasihelistamise funktsioonis, mida kutsutakse vastuse edukal moodustamisel, anname sarnaselt Pakkumisele kohaliku kirjelduse ja edastame saadud vastuse SDP esimesele osalejale:

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

Tagasihelistamise funktsioon, mida kutsutakse vastuse genereerimisel ilmneva vea korral, on täiesti sarnane Pakkumisega:

Funktsioon pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", error); )

Vastuse SDP genereerimise parameetrid:

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

Kui teine osaleja saab pakkumise, looge RTCPeerConnection ja vormistage vastus samamoodi nagu pakkumine:

Funktsioon pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Looge teise osaleja jaoks RTCPeerConnectioni objekt, mis sarnaneb esimesele pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onice //candidate Määrake sündmuste töötleja, kui ICE kandidaat pc2.onaddstream = pc_onaddstream; // Kui kuvatakse voog, ühendage see HTML-iga

Pakkumise SDP ülekandmiseks esimeselt osalejalt teisele, eemaldage meie näite osana funktsioonis pc1 kommentaar looPakkumine success() kõnestring:

Pc2_receivedOffer(desc);

ICE kandidaatide töötlemise rakendamiseks tühjendage esimese osaleja pc1_onicecandidate() ICE kandidaadi valmisoleku sündmuste töötlejas selle edastamine teisele:

Pc2.addIceCandidate(uus RTCIceCandidate(sündmus.kandidaat));

Teise osaleja ICE kandidaadi valmisoleku sündmuste käsitleja sarnaneb esimesele:

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

Tagasihelistamise funktsioon meediumivoo lisamiseks esimeselt osalejalt:

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

Ühenduse katkestamine

Lisame HTML-i veel ühe nupu

Ja funktsioon ühenduse lõpetamiseks

Funktsioon btnHangupClick() ( // Keela kohalik video HTML-elementidest

Salvestame selle nimega rtctest3.html, paneme serverisse ja avame brauseris. See näide rakendab kahesuunalist meedia voogesitust kahe RTCPeerConnectioni vahel samal brauseri vahekaardil. Pakkumise ja vastuse SDP, ICE kandidaatide osalejate ja muu teabe vahetamise korraldamiseks võrgu kaudu on vaja otsekõne asemel rakendada osalejate vahelist vahetust, kasutades mingit transporti, meie puhul veebipistikupesasid. protseduurid.

Ekraanisaade

Funktsiooni getUserMedia abil saate ka jäädvustada ekraani ja voogesitada MediaStream'ina, määrates järgmised parameetrid:

Var mediaStreamConstraints = ( heli: false, video: ( kohustuslik: ( chromeMediaSource: "screen" ), valikuline: ) );

Edukaks ekraanile juurdepääsuks peavad olema täidetud mitmed tingimused:

lubage ekraanipildi lipp rakenduses getUserMedia() asukohas chrome://flags/,chrome://flags/;
lähtefail tuleb alla laadida HTTPS-i (SSL-i päritolu) kaudu;
helivoogu ei tohi taotleda;
mitu päringut ei tohiks teha samal brauseri vahekaardil.

WebRTC raamatukogud

Kuigi WebRTC pole veel valmis, on sellel põhinevaid teeke juba ilmunud. JsSIP on loodud brauseripõhiste tarkvaratelefonide loomiseks, mis töötavad SIP-lülititega, nagu Asterisk ja Camalio. PeerJS lihtsustab andmevahetuseks P2P võrkude loomist ning Holla vähendab brauserite P2P suhtluseks vajalikku arendusmahtu.

Node.js ja socket.io

SDP ja ICE kandidaatide vahetamise korraldamiseks kahe RTCPeerConnectioni vahel üle võrgu kasutame koos mooduliga socket.io Node.js.

Kirjeldatakse Node.js-i uusima stabiilse versiooni (Debiani/Ubuntu jaoks) installimist

$ 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

Teiste operatsioonisüsteemide installimist kirjeldatakse

Kontrollime:

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

Installige npm (Node Package Manager) abil socket.io ja täiendav kiirmoodul:

$ npm installige socket.io express

Kontrollime seda, luues serveri poole jaoks faili nodetest2.js:

$ nano nodetest2.js var app = nõuda("ekspress")() , server = nõua("http").createServer(app) , io = nõuda("socket.io").kuula(server); server.kuula(80); // Kui port 80 on vaba app.get("/", funktsioon (req, res) ( // Juurlehele juurdepääsul res.sendfile(__dirname + "/nodetest2.html"); // andke HTML-fail ) ) ; io.sockets.on("ühendus", funktsioon (socket) ( // Ühenduses socket.emit("serveri sündmus", ( tere: "maailm" )); // sõnumi saatmine socket.on("kliendi sündmus", funktsioon (andmed) ( // ja kliendikonsoolist sõnumi saabumisel deklareerida sündmuste käitleja.log(data); )); ));

Ja nodetest2.html kliendi poole jaoks:

$nano nodetest2.html

Käivitame serveri:

$ sudo nodejs nodetest2.js

ja avage brauseris leht http://localhost:80 (kui see töötab kohapeal pordis 80). Kui kõik õnnestub, näeme brauseri JavaScripti konsoolis ühenduse loomisel sündmuste vahetust brauseri ja serveri vahel.

Teabevahetus RTCPeerConnectioni vahel veebipesade kaudu

Kliendi pool

Salvestame oma põhinäite (rtcdemo3.html) uue nimega rtcdemo4.html. Lisage elementi socket.io teek:

Ja JavaScripti skripti alguses - veebipesa ühendus:

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

Asendame otsekõne mõne teise osaleja funktsioonidele, saates talle veebipesade kaudu sõnumi:

Funktsioon createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("pakkumine", desc); ... ) funktsioon pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("vastus", desc); ) funktsioon pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) funktsioon pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

Funktsioonis hangup() saadame teise osaleja funktsioonide otse väljakutsumise asemel sõnumi veebipesade kaudu:

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

Ja lisage sõnumite vastuvõtmise töötlejad:

Socket.on("pakkumine", funktsioon (andmed) ( console.log("socket.on("off"):", data); pc2_receivedOffer(data); )); socket.on("vastus", funktsioon (andmed) (e console.log("socket.on("vastus"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", funktsioon (andmed) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", funktsioon (andmed) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", funktsioon (andmed) ( console.log("socket.on("hangup")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Serveri osa

Serveri poolel salvestage fail nodetest2 uue nimega rtctest4.js ja lisage funktsiooni io.sockets.on("connection", function (socket) ( ... ) sisse kliendi sõnumite vastuvõtmine ja saatmine:

Socket.on("pakkumine", funktsioon (data) ( // Teate "pakkumine" saamisel // kuna antud näites on ainult üks kliendiühendus, siis // saada sõnum tagasi läbi sama socket.emit( "pakkumine" , andmed); // Kui oleks vaja sõnum edastada kõikidel ühendustel // peale saatja: // socket.broadcast.emit("pakkumine", andmed); )); socket.on("vastus", funktsioon (andmed) ( socket.emit("vastus", andmed); )); socket.on("ice1", funktsioon (andmed) ( socket.emit("ice1", data); )); socket.on("ice2", funktsioon (andmed) ( socket.emit("ice2", data); )); socket.on("hangup", funktsioon (andmed) ( socket.emit("hangup", data); ));

Lisaks muutke HTML-faili nime:

// res.sendfile(__dirname + "/nodetest2.html"); // Saada HTML-fail res.sendfile(__dirname + "/rtctest4.html");

Serveri käivitamine:

$ sudo nodejs nodetest2.js

Hoolimata asjaolust, et mõlema kliendi kood käivitatakse samal brauseri vahekaardil, toimub kogu meie näites osalejate vaheline suhtlus täielikult võrgu kaudu ja osalejate "levitamine" pole enam keeruline. Kuid see, mida me tegime, oli ka väga lihtne – need tehnoloogiad on nende kasutusmugavuse poolest head. Kuigi mõnikord petlik. Eelkõige ärgem unustagem, et ilma STUN/TURN serveriteta ei tööta meie näide aadressi tõlkimise ja tulemüüride olemasolul.

Järeldus

Saadud näide on väga tinglik, kuid kui me sündmuste käitlejad veidi universaliseerida, et need kutsuva ja kutsutava osapoole vahel ei erineks, siis kahe objekti pc1 ja pc2 asemel tee RTCPeerConnectioni massiiv ning rakenda elementide dünaamilist loomist ja kustutamist.

Võib oletada, et väga varsti toimub tänu WebRTC-le revolutsioon mitte ainult meie arusaamises kõne- ja videosuhtlusest, vaid ka selles, kuidas me Internetti tervikuna tajume. WebRTC ei ole mitte ainult brauserist brauserile kõnetehnoloogia, vaid ka reaalajas sidetehnoloogia. Videosuhtlus, mida oleme analüüsinud, on vaid väike osa selle kasutusvõimalustest. Juba on näiteid ekraani jagamisest (ekraani jagamisest) ja koostööst ning isegi brauseripõhisest P2P-sisu edastamise võrgust, mis kasutab RTCDataChanneli.

WebRTC (Web Real Time Communications) on standard, mis kirjeldab voogesituse heliandmete, videoandmete ja sisu edastamist brauserist ja brauserisse reaalajas ilma pluginaid või muid laiendusi installimata. Standard võimaldab teil muuta brauseri videokonverentsi terminaliks, avades lihtsalt suhtluse alustamiseks veebilehe.

Mis on WebRTC?

Selles artiklis käsitleme kõike, mida tavakasutaja jaoks WebRTC-tehnoloogia kohta teada on vaja. Vaatleme projekti eeliseid ja puudusi, paljastame mõned saladused, räägime teile, kuidas see töötab, kus ja milleks WebRTC-d kasutatakse.

Mida peate WebRTC kohta teadma?

Videostandardite ja -tehnoloogiate areng

Sergey Yutsaitis, Cisco, video+konverents 2016

Kuidas WebRTC töötab

Kliendi poolel

Kasutaja avab lehe, mis sisaldab HTML5 märgendit
Brauser taotleb juurdepääsu kasutaja veebikaamerale ja mikrofonile.
Kasutajalehel olev JavaScripti kood juhib ühenduse parameetreid (WebRTC-serveri või muude WebRTC-klientide IP-aadressid ja pordid), et NAT-ist ja tulemüürist mööda minna.
Kui saate teavet vestluspartneri või serveris segatud konverentsiga voo kohta, alustab brauser kasutatavate heli- ja videokoodekite üle läbirääkimisi.
Algab andmete kodeerimise ja voogesituse protsess WebRTC klientide vahel (meie puhul brauseri ja serveri vahel).

WebRTC serveri poolel

Kahe osaleja vaheliseks andmevahetuseks pole videoserverit vaja, kuid kui soovitakse ühte konverentsi mitut osalejat ühendada, on vaja serverit.

Videoserver võtab vastu meediumiliiklust erinevatest allikatest, teisendab selle ja saadab kasutajatele, kes kasutavad WebRTC-d terminalina.

WebRTC server võtab vastu ka meedialiiklust WebRTC kaaslastelt ja edastab selle konverentsil osalejatele, kasutades töölaua- või mobiilirakendusi, kui neid on.

Standardi eelised

Tarkvara installimine pole vajalik.
Väga kõrge suhtluskvaliteet tänu:
- Kaasaegsete video- (VP8, H.264) ja helikoodekite (Opus) kasutamine.
- Voo kvaliteedi automaatne kohandamine vastavalt ühenduse tingimustele.
- Sisseehitatud kaja- ja mürasummutus.
- Osalejate mikrofonide automaatne tasemekontroll (AGC).
Kõrge turvalisuse tase: kõik ühendused on turvalised ja krüpteeritud vastavalt TLS ja SRTP protokollidele.
Sisu, näiteks töölaua, jäädvustamiseks on sisseehitatud mehhanism.
Võimalus rakendada mis tahes juhtimisliidest, mis põhineb HTML5-l ja JavaScriptil.
Võimalus integreerida liidest mis tahes taustasüsteemidega, kasutades WebSocketsi.
Avatud lähtekoodiga projekt – saate selle oma tootesse või teenusesse manustada.
Tõeline platvormideülene: sama WebRTC rakendus töötab võrdselt hästi igas operatsioonisüsteemis, nii lauaarvutis kui ka mobiilis, eeldusel, et brauser toetab WebRTC-d. See säästab palju ressursse tarkvara arendamiseks.

Standardi puudused

Grupi heli- ja videokonverentside korraldamiseks on vaja videokonverentsi serverit, mis segaks osalejate video ja heli, sest brauser ei tea, kuidas mitut sissetulevat voogu üksteisega sünkroonida.
Kõik WebRTC lahendused ei ühildu omavahel, kuna standard kirjeldab ainult video ja heli edastamise meetodeid, jättes tellijate poole pöördumise, nende saadavuse jälgimise, sõnumite ja failide vahetamise, ajastamise ja muu teenuste rakendamise müüjale.
Teisisõnu, te ei saa helistada ühe arendaja WebRTC-rakendusest teise arendaja WebRTC-rakendusse.
Grupikonverentsi miksimine nõuab palju arvutusressursse, seega nõuab seda tüüpi videosuhtlus tasulise tellimuse ostmist või investeeringut selle infrastruktuuri, kus iga konverentsi jaoks on vaja 1 kaasaegse protsessori füüsilist tuuma.

WebRTC saladused: kuidas müüjad häirivast veebitehnoloogiast kasu saavad

Tzachi Levent-Levi, Bloggeek.me, video+konverents 2015

WebRTC videokonverentside turule

Videokonverentsi terminalide arvu suurenemine

WebRTC tehnoloogial on olnud tugev mõju videokonverentsi turu arengule. Pärast esimeste WebRTC toega brauserite väljaandmist 2013. aastal kasvas potentsiaalne videokonverentsi terminalide arv üle maailma kohe 1 miljardi seadme võrra. Tegelikult on igast brauserist saanud videokonverentsi terminal, mis ei jää suhtluskvaliteedi poolest alla oma riistvaralistele kolleegidele.

Kasutada spetsiaalsetes lahendustes

Erinevate JavaScripti teekide ja pilveteenuste API-de kasutamine koos WebRTC toega muudab videotoe lisamise mis tahes veebiprojektidele lihtsaks. Varem pidi reaalajas andmeedastus arendajatel õppima protokollide toimimist ja kasutama teiste ettevõtete tööd, mis kõige sagedamini nõudis täiendavat litsentsimist, mis suurendas kulusid. WebRTC-d kasutatakse juba aktiivselt sellistes teenustes nagu "Helista saidilt", "Võrgutoe vestlus" jne.

Skype'i Linuxi jaoks endised kasutajad

2014. aastal teatas Microsoft Skype for Linuxi projekti toetamise lõpetamisest, mis tekitas IT-spetsialistides suurt pahameelt. WebRTC tehnoloogia ei ole seotud operatsioonisüsteemiga, vaid on realiseeritud brauseri tasemel, s.t. Linuxi kasutajad näevad WebRTC-põhiseid tooteid ja teenuseid Skype'i täieõigusliku asendusena.

Võistlus Flashiga

WebRTC ja HTML5 olid surmahoop Flash-tehnoloogiale, mis elas juba kaugeltki parimaid aastaid. Alates 2017. aastast on juhtivad brauserid ametlikult Flashi toetamise lõpetanud ja tehnoloogia on lõpuks turult kadunud. Kuid peate Flashile krediiti andma, sest just tema lõi veebikonverentside turu ja pakkus tehnilisi võimalusi otsesuhtluseks brauserites.

WebRTC videoesitlused

Dmitri Odintsov, TrueConf, video+konverents, oktoober 2017

Koodekid WebRTC-s

Heli kodekid

Heliliikluse tihendamiseks WebRTC-s kasutatakse Opuse ja G.711 koodekeid.

G.711- vanim kõrge bitikiirusega (64 kbps) kõnekoodek, mida kasutatakse kõige sagedamini traditsioonilistes telefonisüsteemides. Peamine eelis on kergete tihendusalgoritmide kasutamisest tulenev minimaalne arvutuskoormus. Kodekil on madal häälsignaalide tihendamise tase ja see ei tekita kasutajatevahelise suhtluse ajal täiendavat heliviivitust.

G.711 toetab suur hulk seadmeid. Seda koodekit kasutavaid süsteeme on lihtsam kasutada kui teistel helikoodekitel põhinevaid süsteeme (G.723, G.726, G.728 jne). Kvaliteedi osas sai G.711 MOS-i testimisel hindeks 4,2 (skoor 4-5 on kõrgeim ja tähendab head kvaliteeti, mis on sarnane kõneliikluse kvaliteedile ISDN-is ja isegi kõrgem).

Opus on madala kodeeringu latentsusajaga (2,5 ms kuni 60 ms), muutuva bitikiiruse toe ja kõrge tihedusega koodek, mis sobib ideaalselt heli voogedastuseks muutuva ribalaiusega võrkudes. Opus on hübriidlahendus, mis ühendab endas SILK (Voice Compression, Human Speech Distortion Elimination) ja CELT (Audio Data Encoding) koodekite parimad omadused. Kodek on vabalt saadaval, seda kasutavad arendajad ei pea autoriõiguste omanikele litsentsitasusid maksma. Võrreldes teiste helikoodekidega võidab Opus kindlasti mitmel viisil. See on varjutanud üsna populaarsed madala bitikiirusega koodekid, nagu MP3, Vorbis, AAC LC. Opus taastab heli "pildi" originaalile lähemal kui AMR-WB ja Speex. See koodek on tulevik, mistõttu lisasid WebRTC tehnoloogia loojad selle toetatud helistandardite kohustuslikku hulka.

Videokoodekid

WebRTC jaoks videokodeki valimise küsimused võtsid arendajatel mitu aastat, lõpuks otsustasid nad kasutada H.264 ja VP8. Peaaegu kõik kaasaegsed brauserid toetavad mõlemat koodekit. WebRTC-ga töötamiseks peavad videokonverentsiserverid toetama ainult ühte.

VP8 on avatud litsentsiga tasuta videokodek, millel on suur videovoo dekodeerimise kiirus ja suurem vastupidavus kaadrite kadumisele. Kodek on universaalne, seda on lihtne riistvaraplatvormidele juurutada, nii et videokonverentsisüsteemide arendajad kasutavad seda sageli oma toodetes.

Tasuline videokoodek H.264 sai tuntuks palju varem kui tema vend. See on koodek, mille videovoo tihendusaste on kõrge, säilitades samal ajal kõrge videokvaliteedi. Selle koodeki kõrge levimus riistvaraliste videokonverentsisüsteemide seas viitab selle kasutamisele WebRTC standardis.

Google ja Mozilla reklaamivad aktiivselt VP8 koodekit, Microsoft, Apple ja Cisco aga H.264 (tagamaks ühilduvust traditsiooniliste videokonverentsisüsteemidega). Ja siin tekib väga suur probleem pilvepõhiste WebRTC lahenduste arendajatel, sest kui kõik konverentsil osalejad kasutavad sama brauserit, siis piisab sellest, kui konverents segatakse üks kord ühe koodekiga ja kui brauserid on erinevad ja nende hulgas Kui on olemas Safari / Edge, siis tuleb konverents kodeerida kaks korda erinevat kodekit, mis kahekordistab meediumiserveri süsteeminõudeid ja selle tulemusena WebRTC teenuste tellimuste maksumust.

WebRTC API

WebRTC tehnoloogia põhineb kolmel peamisel API-l:

(vastutab selle eest, et veebibrauser võtaks vastu heli- ja videosignaale kaameratest või kasutaja töölaualt).
RTCPeerConnection(vastutab brauseritevahelise ühenduse eest kaamerast, mikrofonist ja töölaualt vastuvõetud meediumiandmete "vahetuseks". Samuti kuuluvad selle API "ülesannete hulka" signaalitöötlus (puhastamine kõrvalisest mürast, mikrofoni helitugevuse reguleerimine) ja juhtimine kasutatavate heli- ja videokoodekite kaudu).
RTC andmekanal(pakkub kahesuunalist andmeedastust loodud ühenduse kaudu).

Enne kasutaja mikrofoni ja kaamera juurde pääsemist küsib brauser seda luba. Google Chrome'is saate juurdepääsu eelkonfigureerida jaotises "Seaded", Opera ja Firefoxi puhul tehakse seadmete valik otse juurdepääsu ajal ripploendist. Loataotlus kuvatakse alati HTTP-protokolli kasutamisel ja üks kord HTTPS-i kasutamisel:

RTCPeerConnection. Igal WebRTC konverentsil osaleval brauseril peab olema juurdepääs sellele objektile. Tänu RTCPeerConnectioni kasutamisele võivad meediumiandmed ühest brauserist teise liikuda isegi läbi NAT-i ja tulemüüride. Meediumivoogude edukaks edastamiseks peavad osalejad vahetama järgmisi andmeid, kasutades transporti, näiteks veebipesasid.

algatav osaleja saadab teisele osalejale Offer-SDP (andmestruktuur koos edastatava meediavoo omadustega);
teine osaleja genereerib "vastuse" - Answer-SDP ja saadab selle algatajale;
seejärel korraldatakse osalejate vahel ICE kandidaatide vahetus, kui neid leitakse (kui osalejad on NAT või tulemüüride taga).

Pärast selle vahetuse edukat lõpetamist osalejate vahel korraldatakse otse meediavoogude (heli ja video) edastamine.

RTC andmekanal. Andmekanali protokolli tugi ilmus brauserites suhteliselt hiljuti, seega saab seda API-t arvesse võtta ainult juhtudel, kui WebRTC-d kasutatakse brauserites Mozilla Firefox 22+ ja Google Chrome 26+. Sellega saavad osalejad brauseris tekstisõnumeid vahetada.

WebRTC ühendus

Toetatud lauaarvuti brauserid

Google Chrome (17+) ja kõik Chromiumi mootoril põhinevad brauserid;
Mozilla Firefox (18+);
Ooper (12+);
Safari (11+);

Androidi toetatud mobiilibrauserid

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

WebRTC, Microsoft ja Internet Explorer

Microsoft vaikis väga pikka aega WebRTC toest Internet Exploreris ja oma uues Edge'i brauseris. Redmondi kuttidele ei meeldi väga anda tehnoloogiat kasutajate kätte, mida nad ei kontrolli, selline poliitika on selline. Kuid tasapisi said asjad maast lahti, sest. WebRTC-d ei saanud enam eirata ja kuulutati välja WebRTC standardist tuletatud ORTC projekt.

Arendajate sõnul on ORTC WebRTC standardi laiendus JavaScriptil ja HTML5-l põhinevate täiustatud API-de komplektiga, mis tavakeelde tõlgituna tähendab, et kõik jääb samaks, standardit kontrollib ainult Microsoft, mitte Google. ja selle areng. Kodekite komplekti on laiendatud H.264 ja mõne G.7XX-seeria helikoodeki toega, mida kasutatakse telefoni- ja riistvaralistes videokonverentsisüsteemides. Võib-olla on sisseehitatud tugi RDP-le (sisu edastamiseks) ja sõnumitele. Muide, Internet Exploreri kasutajatel ei vea, ORTC tugi jääb alles Edge'i. Ja loomulikult sobib selline protokollide ja koodekite komplekt vähese verega Skype for Businessiga kokku, mis avab WebRTC jaoks veelgi rohkem ärirakendusi.

WebRTC on brauseris pakutav API, mis võimaldab korraldada P2P-ühendust ja edastada andmeid otse brauserite vahel. Internetis on üsna palju õpetusi selle kohta, kuidas WebRTC abil oma videovestlust kirjutada. Näiteks siin on artikkel Habré kohta. Kuid need kõik piirduvad kahe kliendi ühendamisega. Selles artiklis püüan rääkida sellest, kuidas korraldada WebRTC abil ühendust ja sõnumite vahetamist kolme või enama kasutaja vahel.

RTCPeerConnectioni liides on peer-to-peer ühendus kahe brauseri vahel. Kolme või enama kasutaja ühendamiseks peame korraldama võrguvõrgu (võrk, milles iga sõlm on ühendatud kõigi teiste sõlmedega).
Kasutame järgmist skeemi:

Lehe avamisel kontrollime ruumi ID olemasolu asukoht.räsi
Kui ruumi ID-d pole määratud, genereerige uus
Saadame signaalimisserverile "teate, et soovime liituda määratud ruumiga
Signaaliserver saadab teistele selles ruumis viibivatele klientidele uue kasutaja teatise
Kliendid, kes on juba ruumis, saadavad uuele tulijale SDP pakkumise
Uustulnuk vastab pakkumisele "s

0. Signaaliserver

Teatavasti pakub WebRTC küll P2P-ühenduse võimalust brauserite vahel, kuid see nõuab siiski lisatransporti teenuseteadete vahetamiseks. Selles näites on transpordiks WebSocketi server, mis on kirjutatud failis Node.JS, kasutades socket.io:

var sokkel_io = nõuavad("socket.io"); module.exports = funktsioon (server) ( var users = (); var io = socket_io(server); io.on("ühendus", funktsioon(socket) ( // Soovin ruumiga liituda uut kasutajat socket.on( "ruum ", function(message) ( var json = JSON. parse(message); // Lisa pesa kasutajate loendisse kasutajad = socket; if (socket.room !== undefined) ( // Kui pesa on juba mõnes ruumis jätke see socket.leave(socket.room); ) // Sisestage soovitud ruum socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Saada teistele klientidele selles ruumis on sõnum uue osalejaga liitumise kohta socket.broadcast.to(socket.room).emit("new", json.id; )); // WebRTC-ga seotud sõnum (SDP pakkumine, SDP vastus või ICE kandidaat) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined) ( // Kui kirjas on adressaat ja see adressaat on serverile teada, saatke sõnum ainult talle... users.emit("webrtc", sõnum); ) else ( // ...muidu käsitage sõnumit leviedastusena socket.broadcast.to(socket.room).emit("webrtc", sõnum); ) ); // Keegi katkestas ühenduse socket.on("disconnect", function() ( // Kui klient katkestab ühenduse, teavitage teisi socket.broadcast.to(socket.room).emit("leave", socket.user_id); kasutajate kustutamine; )); )); );

1. index.html

Lehe enda lähtekood on üsna lihtne. Ma ei pööranud meelega tähelepanu paigutusele ja muudele ilusatele asjadele, kuna see artikkel sellest ei räägi. Kui keegi tahab teda ilusaks teha, pole see raske.

WebRTC vestluse demo

ühendatud 0 eakaaslased

2.main.js

2.0. Leheelementide ja WebRTC liideste linkide hankimine

var chatlog = document.getElementById("vestluslogi"); var sõnum = document.getElementById("sõnum"); var ühenduse_arv = document.getElementById("ühenduse_arv"); var room_link = document.getElementById("ruumi_link");

WebRTC liidestele juurdepääsuks peame endiselt kasutama brauseri eesliiteid.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || aken.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || aken.RTCIceCndidate;

2.1. Ruumi ID määramine

Siin vajame funktsiooni ainulaadse ruumi ja kasutaja ID genereerimiseks. Kasutame selleks UUID-d.

Funktsioon uuid () ( var s4 = function() ( tagastab Math.floor(Math.random() * 0x10000).toString(16); ); tagastab s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Proovime nüüd aadressist ruumi ID välja võtta. Kui see pole määratud, loome uue. Kuvame lehel lingi praegusele ruumile ja samal ajal genereerime praegusele kasutajale identifikaatori.

VarRUUM = asukoht.hash.substr(1); if (!ROOM) ( RUUM = uuid(); ) room_link.innerHTML = "Link ruumiga"; varME = uuid();

2.2. veebipistikupesa

Kohe lehe avamisel loome ühenduse oma signalisatsiooniserveriga, saadame päringu ruumi sisenemiseks ja täpsustame sõnumite töötlejad.

// Täpsustame, et kui sõnum on suletud, peame saatma serverile teate selle kohta var socket = io.connect("", ("sünkroonimise katkestamine mahalaadimisel": true)); socket.on("webrtc", socketReceived); socket.on("uus", socketNewPeer); // Saada koheselt ruumi sisenemise taotlus socket.emit("room", JSON.stringify((id: ME, room: ROOM))); // Abifunktsioon WebRTC funktsiooniga seotud aadressisõnumite saatmiseks sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message )) ));)

2.3. Peer-ühenduse seaded

Enamik Interneti-teenuse pakkujaid pakub Interneti-ühendust NAT-i kaudu. Seetõttu ei muutu otsene seos nii triviaalseks. Ühenduse loomisel peame määrama STUN- ja TURN-serverite loendi, mida brauser proovib kasutada NAT-ist mööda hiilimiseks. Toome välja ka paar lisavõimalust ühendamiseks.

Var server = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", mandaat: "teie parool läheb siia", kasutajanimi: " [e-postiga kaitstud]") ] ); var options = ( valikuline: [ (DtlsSrtpKeyAgreement: true), // vajalik Chrome'i ja Firefoxi vahelise ühenduse loomiseks (RtpDataChannels: true) // Firefoxis nõutav DataChannelsi API kasutamiseks ] )

2.4. Uue kasutaja ühendamine

Kui ruumi lisatakse uus partner, saadab server meile sõnumi uus. Vastavalt ülaltoodud sõnumitöötlejatele kutsutakse funktsioon välja pesaNewPeer.

Peer ütleb: " + e.data + "

"; }; }

2.5. SDP pakkumine, SDP vastus, ICE kandidaat

Kui üks neist sõnumitest saabub, helistame vastavale sõnumitöötlejale.

Funktsioon socketReceived(data) ( var json = JSON.parse(data); lüliti (json.type) ( tõuke "kandidaat": remoteCandidateReceived(json.id, json.data); break; tõuke "pakkumine": remoteOfferReceived(json. id, json.data); break; suur- ja suurtäht "vastus": remoteAnswerReceived(json.id, json.data); break; ) )

2.5.0 SDP pakkumine

function remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(vastus) ( pc.setLocalDescription(vastus); )); ) funktsioon createConnection(id) ( if (peers === undefined) ( peers = (candidateCache: ); var pc = new PeerConnection(server, options); initConnection(pc, id, "answer"); peers.connection = pc ; pc.ondatachannel = funktsioon(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) )