Vienādranga video tērzēšana, kuras pamatā ir WebRTC. P2P video tērzēšana, kuras pamatā ir WebRTC Webrtc instalēšana

Eiropas interneta lietotāji ir sadalīti divās daļās: saskaņā ar Alenbahas (Vācijā) Sabiedriskās domas analīzes institūta aptauju Skype, tērzēšanas un tūlītējās ziņojumapmaiņas sistēmas ir kļuvušas par neatņemamu sastāvdaļu. Ikdiena No 16,5 miljoniem pieaugušo un bērnu 9 miljoni izmanto šos pakalpojumus neregulāri, un 28 miljoni tos nepieskaras.

Tas var mainīties, tagad integrējoties Firefox reāllaika komunikācijas tehnoloģija (WebRTC), kā arī pats klients. Audio un video tērzēšanas sākšana tagad nav grūtāka par vietnes atvēršanu. Savukārt tādi pakalpojumi kā Facebook un Skype paļaujas uz risinājumiem, izmantojot atsevišķu klientu un konta izveidi.

WebRTC izceļas ne tikai ar lietošanas vienkāršību. Šī metode ļauj pat instalēt tiešs savienojums starp divām pārlūkprogrammām. Tādā veidā audio un video dati nenonāk caur serveri, kur varētu būt pārslodze vai kur administrators nav īpaši jutīgs pret privātumu vai datu aizsardzību. Pateicoties tiešajam savienojumam, WebRTC nav nepieciešama ne reģistrācija, ne Konts jebkurā servisā.

Lai sāktu sarunu, jums tikai jāievēro saite. Komunikācija paliek privāta, jo datu straume ir šifrēta. Google sāka aktīvi iesaistīties reāllaika saziņā, izmantojot pārlūkprogrammu, jau 2011. gadā, kad publicēja WebRTC ieviešanas pirmkodu.

Drīz pēc tam pārlūks Chrome un Firefox saņēma savus WebRTC dzinējus. Šobrīd viņu mobilās versijas ir aprīkotas gan ar šo tehnoloģiju, gan WebView 3.6 dzinēju, kas instalēts ar Android 5.0, ko izmanto aplikācijas.

Reāllaika saziņai tīmekļa skatītājā ir jāievieš atbilstošas ​​JavaScript saskarnes. Izmantojot GetUserMedia programmatūra aktivizē uztveršanu no audio un video avotiem, tas ir, no tīmekļa kameras un mikrofona. RTCPeerConnection ir atbildīgs par savienojuma izveidi, kā arī par pašu saziņu.

Paralēli integrācijai pārlūkprogrammā Konsorcija darba grupa Globālais tīmeklis(W3C) ir paātrinājis WebRTC standartizācijas procesu. Tas jāpabeidz 2015. gadā.

WebRTC ir apmierināts ar maz

WebRTC pakalpojuma izmantošana neprasa daudz resursu, jo serveris savieno tikai sarunu biedrus. Arī savienojuma izveide nav īpaši sarežģīta. Pirmkārt, pārlūkprogramma signalizē WebRTC serverim, ka tas plāno sākt zvanu. Viņš saņem HTTPS saiti no servera - sakari ir šifrēti. Lietotājs nosūta šo saiti savam sarunu biedram. Pēc tam pārlūkprogramma pieprasa lietotājam atļauju piekļūt tīmekļa kamerai un mikrofonam.

Lai izveidotu tiešu straumēšanas savienojumu ar sarunu partneri, pārlūkprogramma saņem savu IP adresi un konfigurācijas datus no WebRTC pakalpojuma. Citas personas tīmekļa skatītājs dara to pašu.

Lai straumēšanas savienojums darbotos nevainojami un labā kvalitātē, pārlūkprogrammā darbojas trīs dzinēji. Divi no tiem optimizē un saspiež audio un video datus, trešais ir atbildīgs par to transportēšanu. Tas sūta datus, izmantojot SRTP protokols(Secure Real-time Transport Protocol), kas nodrošina šifrētu reāllaika straumēšanu.

Ja nevar izveidot tiešu savienojumu, WebRTC meklē citu ceļu. Piemēram, tas notiek, kad tīkla iestatījumi neļautu STUN serverim ziņot par IP adresi. WebRTC standarts nosaka, ka šajā gadījumā saruna notiks, bet ar TURN servera starpposma aktivizēšanu (Traversal Using Relays around NAT). Tātad, vietnē netscan.co varat pārbaudīt, vai WebRTC ir ieviests jūsu datorā un ar jūsu piekļuvi tīklam.

Kā tiek izveidots savienojums

Vispirms jums ir jāreģistrē saruna (1). WebRTC pakalpojums nodrošina saiti, kas jānosūta sarunu biedram. Pārlūks, izmantojot STUN serveri, uzzina savu IP adresi (2), nosūta to pakalpojumam un saņem partnera IP, lai izveidotu tiešu savienojumu (3). Ja STUN neizdodas, saruna tiek novirzīta, izmantojot TURN serveri (4).

Saziņa, izmantojot WebRTC tehnoloģiju pārlūkprogrammā, tiek palaista, izmantojot JavaScript kodu. Pēc tam par saziņu ir atbildīgi trīs dzinēji: balss un video dzinēji savāc multivides datus no tīmekļa kameras un mikrofona, un transporta dzinējs apvieno informāciju un nosūta straumi šifrētā veidā, izmantojot SRTP (Secure Real-time Protocol).

Kuras pārlūkprogrammas darbojas ar WebRTC

Chrome un Firefox ir WebRTC dzinējs, kas izmanto tādus pakalpojumus kā talky.io. Mozilla pārlūkprogramma var strādāt tieši ar savu klientu.

Google un Mozilla turpina attīstīt reāllaika saziņas ideju: Chrome var uzņemt WebRTC konferences ar vairākiem dalībniekiem, un Firefox jaunais Hello klients tika izstrādāts sadarbībā ar telekomunikāciju giganta Telefonica meitasuzņēmumu. Apple pagaidām paliek malā, jums vēl nevajadzētu sagaidīt WebRTC programmā Safari. Tomēr ir daudz alternatīvas lietojumprogrammas operētājsistēmai iOS un spraudņiem pārlūkprogrammai Safari.

Microsoft izvēlas nedaudz citu kursu. Kā konkursa īpašnieks Skype pakalpojumsšis uzņēmums netaisās tik viegli kapitulēt WebRTC priekšā. Tā vietā Microsoft izstrādā tehnoloģiju, ko sauc par ORTC (Object Real-Time Communications). Internet Explorer.

Atšķirības no WebRTC, piemēram, dažādi kodeki un protokoli kontakta izveidei ar serveri, ir nelielas un laika gaitā, visticamāk, kļūs par WebRTC standarta papildinājumu, kas ietver šīs atšķirības. Tādējādi aiz muguras paliek tikai Apple - kā parasti.

Foto: ražošanas uzņēmumi; goodluz/Fotolia.com

Lielākā daļa materiālu uz WebRTC koncentrējas uz kodēšanas pielietojuma līmeni un neveicina tehnoloģijas izpratni. Mēģināsim iedziļināties un noskaidrot, kā notiek savienojums, kas ir sesijas deskriptors un kandidāti, kam tie nepieciešami Apdullināt Un GRIEZIES serveris.

WebRTC

Ievads

WebRTC ir uz pārlūkprogrammu orientēta tehnoloģija, kas ļauj savienot divus klientus video datu pārsūtīšanai. Galvenās funkcijas: iekšējais pārlūkprogrammas atbalsts (nav nepieciešamas trešās puses ieviestas tehnoloģijas, piemēram Adobe Flash ) un iespēja savienot klientus, neizmantojot papildu serverus - savienojums vienādranga(Tālāk, p2p).

Izveidojiet savienojumu p2p- diezgan sarežģīts uzdevums, jo datoriem ne vienmēr ir publiska IP adreses, tas ir, adreses internetā. Nelielā daudzuma dēļ IPv4 adreses (un drošības nolūkos), tika izstrādāts mehānisms NAT, kas ļauj izveidot privātus tīklus, piemēram, lietošanai mājās. Daudzi mājas maršrutētāji tagad atbalsta NAT un pateicoties tam, visām mājas ierīcēm ir piekļuve internetam, lai gan interneta pakalpojumu sniedzēji parasti to nodrošina IP adrese. Publisks IP adreses ir unikālas internetā, bet privātās adreses nav. Tāpēc savienojiet p2p- grūti.

Lai to labāk izprastu, apsveriet trīs situācijas: abi mezgli atrodas vienā tīklā (1. attēls), abi mezgli atrodas dažādos tīklos (viens ir privāts, otrs ir publisks) (2. attēls) un abi mezgli atrodas dažādos privātajos tīklos ar vienu un to pašu IP adreses (3. attēls).

1. attēls. Abi mezgli vienā tīklā

2. attēls: mezgli dažādos tīklos (viens privātais, otrs publiski)

3. attēls: mezgli dažādos privātajos tīklos, bet ar skaitliski vienādām adresēm

Iepriekš esošajos attēlos pirmais burts divu rakstzīmju apzīmējumā norāda mezgla veidu (p = līdzinieks, r = maršrutētājs). Pirmajā attēlā situācija ir labvēlīga: mezgli viņu tīklā ir pilnībā identificēti pēc tīkla IP adreses un tāpēc var tieši savienoties savā starpā. Otrajā attēlā mums ir divi dažādi tīkli ar līdzīgiem mezglu numuriem. Šeit parādās maršrutētāji (maršrutētāji), kuriem ir divi tīkla interfeiss- jūsu tīklā un ārpus tīkla. Tāpēc viņiem ir divi IP adreses. Parastajiem mezgliem ir tikai viens interfeiss, caur kuru tie var sazināties tikai savā tīklā. Ja viņi pārsūta datus kādam ārpus sava tīkla, tad tikai izmantojot NAT maršrutētāja (maršrutētāja) iekšpusē un tāpēc redzams citiem zem IP maršrutētāja adrese ir viņu ārējā IP adrese. Tādējādi mezglā p1 Tur ir interjers IP = 192.168.0.200 Un ārējā IP = 10.50.200.5 , un pēdējā adrese būs arī ārēja visiem citiem tā tīkla mezgliem. Līdzīga situācija mezglam p2. Tāpēc to savienojums nav iespējams, ja izmantojat tikai viņu iekšējos (savējos) IP adreses. Varat izmantot ārējās adreses, tas ir, maršrutētāja adreses, taču, tā kā visiem viena privātā tīkla mezgliem ir viena un tā pati ārējā adrese, tas ir diezgan grūti. Šī problēma tiek atrisināta, izmantojot mehānismu NAT

Kas notiks, ja mēs nolemsim savienot mezglus, izmantojot to iekšējās adreses? Dati netiks atstāti no tīkla. Lai uzlabotu efektu, varat iedomāties situāciju, kas parādīta pēdējā attēlā - abiem mezgliem ir vienādas iekšējās adreses. Ja viņi tos izmanto saziņai, tad katrs mezgls sazināsies ar sevi.

WebRTC veiksmīgi tiek galā ar šādām problēmām, izmantojot protokolu ICE, kas tomēr prasa izmantot papildu serverus ( Apdullināt, GRIEZIES). Vairāk par to visu zemāk.

Divas WebRTC fāzes

Lai savienotu divus mezglus, izmantojot protokolu WebRTC(vai vienkārši RTC, ja divi sazinās iPhone“a) ir jāveic dažas iepriekšējas darbības, lai izveidotu savienojumu. Šī ir pirmā fāze – savienojuma izveide. Otrais posms ir video datu pārraide.

Ir vērts uzreiz pateikt, ka, lai gan tehnoloģija WebRTC savā darbā izmanto daudzus dažādi veidi sakari ( TCP Un UDP), un tai ir elastīga pārslēgšanās starp tām, šī tehnoloģija nav savienojuma datu pārsūtīšanas protokola. Nav pārsteidzoši, jo savienojiet divus mezglus p2p nav tik viegli. Tāpēc ir nepieciešams, lai būtu daži papildu datu pārraides metode, kas nekādā veidā nav saistīta ar WebRTC. Tas varētu būt ligzdas pārsūtīšana, protokols HTTP, tas varētu būt pat protokols SMTP vai Krievijas pasts. Šis transmisijas mehānisms sākotnējā dati tiek saukti signāls. Nav daudz informācijas jāsniedz. Visi dati tiek pārsūtīti teksta veidā un ir sadalīti divos veidos - SDP Un Ledus kandidāts. Pirmais veids tiek izmantots loģiska savienojuma izveidošanai, bet otrais - fiziskajam savienojumam. Vairāk par to visu vēlāk, bet pagaidām ir svarīgi to atcerēties WebRTC sniegs mums kādu informāciju, kas būs jāpārsūta uz citu mezglu. Tiklīdz mēs pārsūtīsim visu nepieciešamo informāciju, mezgli varēs savienoties un mūsu palīdzība vairs nebūs nepieciešama. Tātad signalizācijas mehānisms, kas mums jāievieš, ir atsevišķi, tiks izmantots tikai savienojuma gadījumā, bet netiks izmantots, pārsūtot video datus.

Tātad, aplūkosim pirmo posmu - savienojuma izveides fāzi. Tas sastāv no vairākiem punktiem. Vispirms apskatīsim šo fāzi mezglam, kas uzsāk savienojumu, un pēc tam tam, kas gaida.

• Iniciators (zvanītājs - zvanītājs):
  1. Piedāvājums sākt video datu pārsūtīšanu (createOffer)
  2. Jūsu iegūšana SDP SDP)
  3. Jūsu iegūšana Ledus kandidāts Ledus kandidāts)
• Zvana gaidīšana ( callee):
  1. Vietējās (savas) multivides straumes saņemšana un iestatīšana pārraidei (getUserMediaStream)
  2. Piedāvājuma saņemšana sākt video datu pārsūtīšanu un atbildes izveide (createAnswer)
  3. Jūsu iegūšana SDP objektu un pārraidot to, izmantojot signalizācijas mehānismu ( SDP)
  4. Jūsu iegūšana Ledus kandidāts objekti un to pārraide caur signalizācijas mehānismu ( Ledus kandidāts)
  5. Attālās (ārvalstu) multivides straumes saņemšana un parādīšana ekrānā (onAddStream)

Vienīgā atšķirība ir otrajā punktā.

Neskatoties uz darbību šķietamo sarežģītību, patiesībā tās ir trīs: savas multivides straumes nosūtīšana (1. vienums), savienojuma parametru iestatīšana (2.–4. vienums), kāda cita multivides straumes saņemšana (5. vienums). Visgrūtākais ir otrais solis, jo tas sastāv no divām daļām: izveidošanas fiziskais Un loģiski savienojumiem. Pirmais norāda ceļš, pa kuru paketēm jāpārvietojas, lai nokļūtu no viena tīkla mezgla uz otru. Otrais norāda video/audio parametri– kādu kvalitāti lietot, kādus kodekus lietot.

Garīgā stadija izveidot Piedāvājumu vai izveidotAtbildi jābūt savienotam ar pārraides posmiem SDP Un Ledus kandidāts objektus.

Pamatelementi

Multivides straumes (MediaStream)

Galvenā vienība ir multivides straume, tas ir, video un audio datu, attēla un skaņas straume. Ir divu veidu multivides straumes – vietējās un attālās. Lokālais saņem datus no ievades ierīcēm (kamera, mikrofons), bet attālā – caur tīklu. Tādējādi katram mezglam ir gan vietējais, gan attālais pavediens. IN WebRTC ir saskarne pavedieniem MediaStream un ir arī apakšinterfeiss LocalMediaStreamīpaši vietējam pavedienam. IN JavaScript jūs varat saskarties tikai ar pirmo, un, ja jūs izmantojat libjingle, tad jūs varat saskarties ar otro.

IN WebRTC Pavedienā ir diezgan mulsinoša hierarhija. Katra straume var sastāvēt no vairākiem multivides celiņiem ( MediaTrack), kas savukārt var sastāvēt no vairākiem mediju kanāliem ( MediaChannel). Un var būt arī vairākas pašas mediju straumes.

Apskatīsim visu kārtībā. Lai to izdarītu, paturēsim prātā dažus piemērus. Teiksim, mēs vēlamies pārraidīt ne tikai video par sevi, bet arī video no mūsu galda, uz kura guļ papīrs, uz kura mēs gatavojamies kaut ko rakstīt. Mums būs nepieciešami divi video (mums + tabula) un viens audio (mums). Ir skaidrs, ka mēs un tabula ir jāsadala dažādos pavedienos, jo šie dati, iespējams, ir vāji atkarīgi viens no otra. Tāpēc mums būs divi MediaStream‘a – viens mums un viens galdam. Pirmajā būs gan video, gan audio dati, bet otrajā būs tikai video (4. attēls).

4. attēls. Divas dažādas multivides straumes. Viens mums, viens mūsu galdam

Tūlīt ir skaidrs, ka multivides straumē vismaz ir jāietver iespēja saturēt datus dažādi veidi- video un audio. Tas tiek ņemts vērā tehnoloģijā, un tāpēc katrs datu veids tiek ieviests, izmantojot multivides celiņu MediaTrack. Mediju celiņam ir īpašs īpašums laipns, kas nosaka, kas mums ir priekšā – video vai audio (5. attēls)

5. attēls. Multivides straumes sastāv no multivides celiņiem

Kā viss notiks programmā? Mēs izveidosim divas multivides straumes. Tad mēs izveidosim divus video celiņus un vienu audio celiņu. Piekļūstam kamerām un mikrofonam. Katram celiņam pastāstīsim, kuru ierīci izmantot. Pievienosim video un audio celiņu pirmajai multivides straumei un video celiņu no citas kameras otrajai multivides straumei.

Bet kā mēs varam atšķirt multivides straumes savienojuma otrā galā? Lai to izdarītu, katrai multivides straumei ir īpašums etiķete– straumes etiķete, tās nosaukums (6. attēls). Multivides ierakstiem ir tāds pats īpašums. Lai gan no pirmā acu uzmetiena šķiet, ka video var atšķirt no skaņas citos veidos.

6. attēls. Multivides straumes un ieraksti ir identificēti ar etiķetēm

Tātad, ja multivides ierakstus var identificēt, izmantojot tagu, tad kāpēc mūsu piemērā ir jāizmanto divas multivides straumes, nevis viena? Galu galā jūs varat pārsūtīt vienu multivides straumi, bet tajā izmantot dažādus ierakstus. Esam sasnieguši svarīgu mediju straumju īpašību – tās sinhronizēt multivides ieraksti. Dažādas multivides straumes netiek sinhronizētas viena ar otru, bet katrā multivides straumē tiek sinhronizēti visi ieraksti tiek atskaņoti vienlaicīgi.

Tādējādi, ja vēlamies, lai mūsu vārdi, sejas emocijas un papīra lapa tiktu atskaņota vienlaicīgi, tad ir vērts izmantot vienu mediju straumi. Ja tas nav tik svarīgi, tad izdevīgāk ir izmantot dažādas plūsmas - attēls būs vienmērīgāks.

Ja pārraides laikā kāds ieraksts ir jāizslēdz, varat izmantot īpašumu iespējots multivides ieraksti.

Visbeidzot, ir vērts padomāt par stereo skaņu. Kā jūs zināt, stereo skaņa ir divas dažādas skaņas. Un tie arī ir jānodod atsevišķi. Šim nolūkam tiek izmantoti kanāli MediaChannel. Multivides audio celiņam var būt daudz kanālu (piemēram, 6, ja nepieciešams 5+1 audio). Protams, mediju ierakstos ir arī kanāli. sinhronizēts. Video parasti tiek izmantots tikai viens kanāls, bet var izmantot vairākus, piemēram, pārklājošajai reklāmai.

Apkopot: Mēs izmantojam multivides straumi, lai pārsūtītu video un audio datus. Katrā multivides straumē dati tiek sinhronizēti. Mēs varam izmantot vairākas multivides straumes, ja mums nav nepieciešama sinhronizācija. Katrā multivides straumē ir divu veidu multivides celiņi - video un audio. Parasti ir ne vairāk kā divi ieraksti, taču to var būt arī vairāk, ja nepieciešams pārsūtīt vairākus dažādus video (par sarunu biedru un viņa tabulu). Katrs celiņš var sastāvēt no vairākiem kanāliem, ko parasti izmanto tikai stereo skaņai.

Vienkāršākajā video tērzēšanas situācijā mums būs viena lokālā medija straume, kas sastāvēs no diviem celiņiem – video celiņa un audio celiņa, no kuriem katrs sastāvēs no viena galvenā kanāla. Video celiņš ir atbildīgs par kameru, audio celiņš ir par mikrofonu, un multivides straume ir abu konteiners.

Sesijas deskriptors (SDP)

Dažādiem datoriem vienmēr būs dažādas kameras, mikrofoni, videokartes un cita tehnika. Viņiem ir daudz iespēju. Tas viss ir jāsaskaņo datu nesēju pārsūtīšanai starp diviem tīkla mezgliem. WebRTC dara to automātiski un rada īpašs objekts– sesijas deskriptors SDP. Nododiet šo objektu citam mezglam, un multivides datus var pārsūtīt. Tikai vēl nav savienojuma ar citu mezglu.

Šim nolūkam tiek izmantots jebkurš signalizācijas mehānisms. SDP var pārraidīt vai nu caur rozetēm, vai personiski (pastāstiet citam mezglam pa tālruni), vai ar Krievijas pastu. Tas ir ļoti vienkārši - viņi jums iedos gatavu SDP un tas ir jānosūta. Un pēc saņemšanas otrā pusē - pārskaitījums uz nodaļu WebRTC. Sesijas deskriptors tiek saglabāts kā teksts, un to var mainīt jūsu lietojumprogrammās, taču tas parasti nav nepieciešams. Piemēram, pieslēdzot galddatoru ↔ tālruni, dažreiz jums ir jāpiespiež vēlamā audio kodeka izvēle.

Parasti, izveidojot savienojumu, jums ir jānorāda, piemēram, kāda veida adrese URL. Šeit tas nav nepieciešams, jo, izmantojot signalizācijas mehānismu, jūs pats nosūtīsit datus uz galamērķi. Lai norādītu WebRTC ko mēs vēlamies instalēt p2p savienojumu, jums ir jāizsauc funkcija createOffer. Pēc šīs funkcijas izsaukšanas un īpašas piešķiršanas atzvani'Tiks izveidots SDP objekts un pārsūtīts uz to pašu atzvani. Viss, kas no jums tiek prasīts, ir pārsūtīt šo objektu pa tīklu uz citu mezglu (sarunu partneri). Pēc tam dati nonāks otrā galā caur signalizācijas mehānismu, proti, šo SDP objekts. Šis sesijas deskriptors šim mezglam ir svešs un tāpēc satur noderīgu informāciju. Šī objekta saņemšana ir signāls savienojuma sākšanai. Tāpēc jums ir jāpiekrīt tam un jāizsauc funkcija createAnswer. Tas ir pilnīgs createOffer analogs. Atpakaļ pie jūsu atzvani pārsūtīs vietējās sesijas deskriptoru, un tas būs jāpārsūta atpakaļ, izmantojot signalizācijas mehānismu.

Ir vērts atzīmēt, ka funkciju createAnswer varat izsaukt tikai pēc kāda cita saņemšanas SDP objektu. Kāpēc? Jo vietējais SDP objektam, kas tiks ģenerēts, izsaucot createAnswer, ir jāpaļaujas uz tālvadības pulti SDP objekts. Tikai šajā gadījumā ir iespējams saskaņot savus video iestatījumus ar sarunu biedra iestatījumiem. Tāpat nevajadzētu izsaukt createAnswer un createOffer pirms vietējās multivides straumes saņemšanas — viņiem nebūs uz ko rakstīt. SDP objekts.

Kopš gada WebRTC ir iespējams rediģēt SDP objektu, tad pēc lokālā roktura saņemšanas tas jāuzstāda. Tas var šķist nedaudz dīvaini WebRTC ko viņa pati mums iedeva, bet tāds ir protokols. Kad tiek saņemts tālvadības rokturis, tas arī ir jāuzstāda. Tāpēc vienā mezglā ir jāinstalē divi deskriptori - jūsu un kāda cita (tas ir, lokālais un attālais).

Pēc tam rokasspiedieni mezgli zina viens par otra vēlmēm. Piemēram, ja mezgls 1 atbalsta kodekus A Un B, un mezgls 2 atbalsta kodekus B Un C, tad, tā kā katrs mezgls zina savus un citu deskriptorus, abi mezgli izvēlēsies kodeku B(7. attēls). Tagad ir izveidota savienojuma loģika un var pārraidīt multivides straumes, taču ir vēl viena problēma - mezgli joprojām ir savienoti tikai ar signalizācijas mehānismu.

7. attēls. Kodeka pārrunas

Ledus kandidāts

Tehnoloģija WebRTC mēģinot mūs sajaukt ar savu jauno metodiku. Veidojot savienojumu, nav norādīta tā mezgla adrese, ar kuru vēlaties izveidot savienojumu. Vispirms instalēts loģiski savienojums, nē fiziskais, lai gan vienmēr tika darīts pretējais. Bet tas nešķitīs dīvaini, ja neaizmirsīsim, ka izmantojam trešās puses signalizācijas mehānismu.

Tātad savienojums jau ir izveidots (loģiskais savienojums), taču joprojām nav ceļa, pa kuru tīkla mezgli varētu pārsūtīt datus. Tas nav tik vienkārši, bet sāksim vienkārši. Ļaujiet mezgliem atrasties tajā pašā privātajā tīklā. Kā mēs jau zinām, viņi var viegli savienoties viens ar otru saskaņā ar savu iekšējo IP adreses (vai varbūt uz kādu citu, ja netiek izmantots TCP/IP).

Pēc dažiem atzvani'Un WebRTC stāsta mums Ledus kandidāts objektus. Tie ir arī teksta formā, un, tāpat kā sesijas deskriptori, tie vienkārši ir jānosūta, izmantojot signalizācijas mehānismu. Ja sesijas deskriptors saturēja informāciju par mūsu iestatījumiem kameras un mikrofona līmenī, tad kandidāti satur informāciju par mūsu atrašanās vietu tīklā. Nododiet tos citam mezglam, un tas varēs fiziski izveidot savienojumu ar mums, un, tā kā tam jau ir sesijas deskriptors, tas loģiski varēs izveidot savienojumu un dati "plūst". Ja viņš atcerēsies mums nosūtīt savu kandidāta objektu, tas ir, informāciju par to, kur viņš pats atrodas tīklā, tad mēs varēsim ar viņu sazināties. Šeit atzīmēsim vēl vienu atšķirību no klasiskās klienta un servera mijiedarbības. Saziņa ar HTTP serveri notiek saskaņā ar pieprasījuma-atbildes shēmu, klients nosūta datus serverim, kas tos apstrādā un nosūta pa pieprasījuma paketē norādītā adrese. IN WebRTC jāzina divas adreses un savienojiet tos abās pusēs.

Atšķirība no sesijas deskriptoriem ir tāda, ka ir jāinstalē tikai attāli kandidāti. Rediģēšana šeit ir aizliegta un nevar dot nekādu labumu. Dažās implementācijās WebRTC kandidāti ir jāinstalē tikai pēc tam, kad ir iestatīti sesijas deskriptori.

Kāpēc bija tikai viens sesijas deskriptors, bet varēja būt daudz kandidātu? Jo atrašanās vietu tīklā var noteikt ne tikai pēc tā iekšējās IP adrese, bet arī maršrutētāja ārējā adrese, un ne vienmēr tikai viena, kā arī adreses GRIEZIES serveriem. Pārējā rindkopas daļa tiks veltīta detalizētai diskusijai par kandidātiem un to, kā savienot mezglus no dažādiem privātiem tīkliem.

Tātad divi mezgli atrodas vienā tīklā (8. attēls). Kā tos identificēt? Izmantojot IP adreses. Citādi nav. Tiesa, jūs joprojām varat izmantot dažādus transportus ( TCP Un UDP) un dažādas ostas. Šī ir informācija, kas ietverta kandidāta objektā - IP, OSTA, TRANSPORTS un vēl kādu. Ļaujiet, piemēram, izmantot UDP transports un 531 osta.

8. attēls. Divi mezgli atrodas vienā tīklā

Tad, ja esam mezglā p1, Tas WebRTC nodos mums tādu kandidātu objektu - . Tas nav precīzs formāts, tikai diagramma. Ja mēs esam mezglā p2, tad kandidāts ir - . Caur signalizācijas mehānismu p1 saņems kandidātu p2(t.i., mezgla atrašanās vieta p2, proti, viņš IP Un OSTA). Tad p1 var savienoties ar p2 tieši. Pareizāk, p1 nosūtīs datus uz adresi 10.50.150.3:531 cerībā, ka viņi sasniegs p2. Nav svarīgi, vai adrese pieder mezglam p2 vai kāds starpnieks. Svarīgi ir tikai tas, ka dati tiks nosūtīti caur šo adresi un var sasniegt p2.

Kamēr mezgli atrodas vienā tīklā, viss ir vienkārši un vienkārši - katram mezglam ir tikai viens kandidātobjekts (vienmēr ar to saprot savu, tas ir, tā atrašanās vietu tīklā). Bet, kad mezgli būs iekšā, būs daudz vairāk kandidātu savādāk tīkliem.

Pāriesim pie sarežģītāka gadījuma. Viens mezgls atradīsies aiz maršrutētāja (precīzāk, aiz NAT), bet otrs mezgls atradīsies vienā tīklā ar šo maršrutētāju (piemēram, internetā) (9. attēls).

9. attēls. Viens mezgls atrodas aiz NAT, otrs nav

Šajā gadījumā ir īpašs problēmas risinājums, ko mēs tagad apsvērsim. Mājas maršrutētājs parasti satur tabulu NAT. Šis ir īpašs mehānisms, kas paredzēts, lai maršrutētāja privātā tīkla mezgli varētu piekļūt, piemēram, vietnēm.

Pieņemsim, ka tīmekļa serveris ir tieši savienots ar internetu, tas ir, tam ir publiska IP* adrese. Lai tas būtu mezgls p2. Mezgls p1(tīmekļa klients) nosūta pieprasījumu uz adresi 10.50.200.10 . Vispirms dati tiek pārsūtīti uz maršrutētāju r1, vai drīzāk uz viņa interjers saskarne 192.168.0.1 . Pēc tam maršrutētājs atceras avota adresi (adresi p1) un ievada to īpašā tabulā NAT, pēc tam maina avota adresi uz jūsu ( p1 → r1). Tālāk, savā veidā ārējā interfeisu, maršrutētājs nosūta datus tieši uz tīmekļa serveri p2. Tīmekļa serveris apstrādā datus, ģenerē atbildi un nosūta to atpakaļ. Nosūta uz maršrutētāju r1, jo tieši viņš atrodas atgriešanas adresē (maršrutētājs aizstāja adresi ar savu). Maršrutētājs saņem datus un apskata tabulu NAT un pārsūta datus uz mezglu p1. Maršrutētājs šeit darbojas kā starpnieks.

Ko darīt, ja vairāki mezgli no iekšējā tīkla vienlaikus piekļūst ārējam tīklam? Kā maršrutētājs sapratīs, kam nosūtīt atbildi? Šī problēma tiek atrisināta, izmantojot ostas. Kad maršrutētājs aizstāj resursdatora adresi ar savu, tas aizstāj arī portu. Ja divi mezgli piekļūst internetam, maršrutētājs aizstāj to avota portus ar savādāk. Pēc tam, kad pakete no tīmekļa servera nonāk atpakaļ maršrutētājā, maršrutētājs pēc porta sapratīs, kam pakete ir piešķirta. Piemērs zemāk.

Atgriezīsimies pie tehnoloģijām WebRTC, vai drīzāk, tai daļai, kas izmanto ICE protokols (tātad Ledus kandidāti). Mezgls p2 ir viens kandidāts (tā atrašanās vieta tīklā – 10.50.200.10 ), un mezglu p1, kas atrodas aiz maršrutētāja ar NAT, būs divi kandidāti - vietējais ( 192.168.0.200 ) un maršrutētāja kandidāts ( 10.50.200.5 ). Pirmais nav noderīgs, bet tas tomēr tiek ģenerēts, jo WebRTC vēl neko nezina par attālo mezglu - tas var būt un var nebūt tajā pašā tīklā. Otrais kandidāts noderēs, un, kā jau zināms, ostai būs liela nozīme (izbraukt cauri NAT).

Tabulas ieraksts NAT tiek ģenerēti tikai tad, kad dati iziet no iekšējā tīkla. Tāpēc mezgls p1 vispirms jāpārsūta dati un tikai pēc tam mezgla dati p2 varēs sasniegt mezglu p1.

Par praksi abi mezgli būs aiz muguras NAT. Lai izveidotu ierakstu tabulā NAT no katra maršrutētāja mezgliem kaut kas jānosūta uz attālo mezglu, bet šoreiz ne pirmais nevar sasniegt otro, ne otrādi. Tas ir saistīts ar faktu, ka mezgli nezina savu ārējo IP adreses, un sūtīt datus uz iekšējām adresēm ir bezjēdzīgi.

Tomēr, ja ir zināmas ārējās adreses, savienojums būs viegli izveidojams. Ja pirmais mezgls nosūta datus otrā mezgla maršrutētājam, maršrutētājs tos ignorēs, jo tā tabula NAT pagaidām tukšs. Tomēr tabulas pirmā mezgla maršrutētājā NAT Man vajag ierakstu. Ja tagad otrais mezgls nosūta datus uz pirmā mezgla maršrutētāju, tad maršrutētājs tos veiksmīgi pārsūtīs uz pirmo mezglu. Tagad galds NAT otrajam maršrutētājam ir nepieciešami dati.

Problēma ir tā, ka, lai atpazītu savu ārējo IP adrese, jums ir nepieciešams mezgls, kas atrodas koplietots tīkls. Lai atrisinātu šo problēmu, tiek izmantoti papildu serveri, kas ir tieši savienoti ar internetu. Ar viņu palīdzību tiek izveidoti arī vērtīgi ieraksti tabulā NAT.

STUN un TURN serveri

Par inicializāciju WebRTC jānorāda pieejamais Apdullināt Un GRIEZIES serveriem, kurus mēs turpmāk izsauksim ICE serveriem. Ja serveri nav norādīti, tad tikai mezgli tajā pašā tīklā (savienots ar to bez NAT). Tūlīt ir vērts atzīmēt, ka par 3g-ir jāizmanto tīkli GRIEZIES serveriem.

Apdullināt serveris ir vienkārši serveris internetā, kas atgriež atgriešanas adresi, tas ir, sūtītāja mezgla adresi. Piekļūst mezgls, kas atrodas aiz maršrutētāja Apdullināt serveris, kuram jāiziet cauri NAT. Paciņa ieradās plkst Apdullināt serveris, satur avota adresi - maršrutētāja adresi, tas ir, mūsu mezgla ārējo adresi. Šī adrese Apdullināt serveri un nosūta to atpakaļ. Tādējādi mezgls saņem savu ārējo IP adrese un ports, caur kuru tam var piekļūt no tīkla. Tālāk, WebRTC izmantojot šo adresi, tiek izveidots papildu kandidāts (ārējā maršrutētāja adrese un ports). Tagad tabulā NAT Maršrutētājam ir ieraksts, kas ļauj maršrutētājam nosūtītajām paketēm vajadzīgajā portā nokļūt mūsu mezglā.

Apskatīsim šo procesu ar piemēru.

Piemērs (STUN servera darbība)

Apdullināt mēs apzīmēsim serveri ar s1. Maršrutētājs, tāpat kā iepriekš, cauri r1, un mezgls – cauri p1. Jums būs arī jāievēro tabula NAT– apzīmēsim to kā r1_nat. Turklāt šajā tabulā parasti ir daudz ierakstu no dažādiem apakštīkla mezgliem - tie netiks norādīti.

Tātad, sākumā mums ir tukšs galds r1_nat.

2. tabula. Pakešu galvene

Mezgls p1 nosūta šo paketi maršrutētājam r1(neatkarīgi no tā, kā tos var izmantot dažādos apakštīklos dažādas tehnoloģijas). Maršrutētājam ir jāmaina avota adrese Src IP, jo paketē norādītā adrese acīmredzami nav piemērota ārējam apakštīklam, turklāt adreses no šāda diapazona ir rezervētas, un nevienai adresei internetā nav šādas adreses. Maršrutētājs veic aizstāšanu paketē un izveido jauns ieraksts tavā tabulā r1_nat. Lai to izdarītu, viņam ir jāizdomā porta numurs. Atgādināsim, ka, tā kā vairāki mezgli apakštīklā var piekļūt ārējam tīklam, tad tabulā NAT ir jāsaglabā Papildus informācija, lai maršrutētājs varētu noteikt, kurš no šiem vairākiem mezgliem ir paredzēts atgriešanas paketei no servera. Ļaujiet maršrutētājam nākt klajā ar portu 888 .

Mainīta pakotnes galvene:

4. tabula: NAT tabula ir atjaunināta ar jaunu ierakstu

Šeit IP apakštīkla adrese un ports ir tieši tādi paši kā oriģinālajai paketei. Faktiski, veicot postbacking, mums ir jābūt iespējai tos pilnībā atjaunot. IPārējā tīkla adrese ir maršrutētāja adrese, un ports ir mainīts uz maršrutētāja izgudroto.

Reālā osta, uz kuru mezgls p1 pieņem savienojumu - tas, protams, 35777 , bet serveris sūta datus uz fiktīvs osta 888 , kuru maršrutētājs nomainīs uz īsto 35777 .

Tātad maršrutētājs pakešu galvenē aizstāja avota adresi un portu un pievienoja ierakstu tabulai NAT. Tagad pakete tiek nosūtīta pa tīklu serverim, tas ir, mezglam s1. Pie ieejas, s1 ir šī pakete:

Src IP	Src PORT	Galamērķa IP	Gala OST
10.50.200.5	888	12.62.100.200	6000

5. tabula: STUN serveris saņēma paketi

Kopā Apdullināt serveris zina, ka saņēmis paketi no adreses 10.50.200.5:888 . Tagad serveris nosūta šo adresi atpakaļ. Šeit ir vērts apstāties un vēlreiz paskatīties uz to, ko tikko apskatījām. Iepriekš esošās tabulas ir fragments no galvene iepakojums, nepavisam ne no tā saturu. Mēs nerunājām par saturu, jo tas nav tik svarīgi - tas kaut kā ir aprakstīts protokolā Apdullināt. Tagad papildus nosaukumam mēs apsvērsim saturu. Tas būs vienkāršs un satur maršrutētāja adresi - 10.50.200.5:888 , lai gan mēs to ņēmām no galvene iepakojums. Tas netiek darīts bieži; protokoliem nav svarīga informācija par mezglu adresēm; Šeit mēs aplūkojam protokolu, kas nosaka ceļu starp diviem mezgliem.

Tātad tagad mums ir otrā pakete, kas iet pretējā virzienā:

7. tabula. STUN serveris nosūta paketi ar šo saturu

Pēc tam pakete pārvietojas pa tīklu, līdz tā sasniedz maršrutētāja ārējo saskarni r1. Maršrutētājs saprot, ka pakete tam nav paredzēta. Kā viņš to saprot? To var noteikt tikai osta. Osta 888 viņš to neizmanto saviem personīgajiem mērķiem, bet izmanto to mehānismam NAT. Tāpēc maršrutētājs aplūko šo tabulu. Skatās uz kolonnu Ārējais PORTS un meklē atbilstošu virkni Gala OST no ienākošās pakas, tas ir 888 .

Iekšējā IP	Iekšējais PORTS	Ārējais IP	Ārējais PORTS
192.168.0.200	35777	10.50.200.5	888

8. tabula: NAT tabula

Mums ir paveicies, šāda līnija pastāv. Ja mums nepaveicas, paciņa vienkārši tiktu izmesta. Tagad jums ir jāsaprot, kuram apakštīkla mezglam ir jānosūta šī pakete. Nav jāsteidzas, vēlreiz atcerēsimies ostu nozīmi šajā mehānismā. Tajā pašā laikā divi apakštīkla mezgli varētu nosūtīt pieprasījumus ārējam tīklam. Tad, ja pirmajam mezglam maršrutētājs nāca klajā ar portu 888 , tad uz otro viņš izdomātu ostu 889 . Pieņemsim, ka tas notika, tas ir, tabula r1_nat izskatās šādi:

10. tabula. Maršrutētājs aizstāj uztvērēja adresi

Src IP	Src PORT	Galamērķa IP	Gala OST
12.62.100.200	6000	192.168.0.200	35777

11. tabula: maršrutētājs mainīja uztvērēja adresi

Pakete veiksmīgi nonāk mezglā p1 un, aplūkojot paketes saturu, mezgls uzzina par tās ārējo IP adrese, tas ir, maršrutētāja adrese ārējā tīklā. Viņš arī zina portu, caur kuru maršrutētājs iet NAT.

Ko tālāk? Kāds no tā visa labums? Ieguvums ir ieraksts tabulā r1_nat. Ja tagad kāds sūta uz rūteri r1 iepakojums ar portu 888 , tad maršrutētājs pārsūtīs šo paketi uz mezglu p1. Tādējādi tika izveidota neliela šaura eja uz slēpto mezglu p1.

No iepriekš minētā piemēra varat iegūt priekšstatu par to, kā tas darbojas NAT un būtība Apdullināt serveris. Kopumā mehānisms ICE Un Apdullināt/pagriezties serveri ir precīzi paredzēti ierobežojumu pārvarēšanai NAT.

Starp mezglu un serveri var būt nevis viens maršrutētājs, bet vairāki. Šajā gadījumā mezgls saņems tā maršrutētāja adresi, kas pirmais piekļūst tam pašam tīklam kā serveris. Citiem vārdiem sakot, mēs iegūstam savienotā maršrutētāja adresi Apdullināt serveris. Priekš p2p komunikācija ir tieši tas, kas mums nepieciešams, ja neaizmirstam to, ka katrs maršrutētājs tabulai pievienos mums vajadzīgo rindu NAT. Tāpēc arī atpakaļceļš atkal būs tikpat gluds.

GRIEZIES serveris ir uzlabots Apdullināt serveris. No šejienes uzreiz vajadzētu uzzināt, ka jebkura GRIEZIES serveris var strādāt un kā Apdullināt serveris. Tomēr ir arī priekšrocības. Ja p2p komunikācija nav iespējama (piemēram, 3g tīkli), serveris pārslēdzas uz atkārtotāja režīmu ( relejs), tas ir, tas darbojas kā starpnieks. Protams, par neko p2p tad jautājumu nav, bet ārpus mehānisma rāmjiem ICE mezgli domā, ka sazinās tieši.

Kādos gadījumos tas ir nepieciešams GRIEZIES serveris? Kāpēc nepietiek Apdullināt serveri? Fakts ir tāds, ka ir vairākas šķirnes NAT. Viņi aizvieto vienādi IP adrese un ports, taču dažos no tiem ir iebūvēta papildu aizsardzība pret “viltošanu”. Piemēram, iekšā simetrisks tabula NAT Ir saglabāti vēl 2 parametri - IP un attālā mezgla ports. Pakete no ārējā tīkla iet cauri NAT uz iekšējo tīklu tikai tad, ja avota adrese un ports atbilst tabulā ierakstītajiem. Tāpēc fokuss Apdullināt servera kļūme - tabula NAT saglabā adresi un portu Apdullināt serveris un kad maršrutētājs saņem paketi no WebRTC sarunu biedrs, viņš to izmet, jo tas ir “falsificēts”. Viņš nenāca no Apdullināt serveris.

Tādējādi GRIEZIES serveris ir nepieciešams, kad atrodas abi sarunu biedri simetrisks NAT(katram savs).

Īss kopsavilkums

Šeit ir daži apgalvojumi par entītijām WebRTC kas vienmēr jāpatur prātā. Tie ir detalizēti aprakstīti iepriekš. Ja kāds no apgalvojumiem jums nešķiet pilnīgi skaidrs, vēlreiz izlasiet atbilstošos punktus.

• Multivides straume
  • Video un audio dati tiek iesaiņoti multivides straumēs
  • Multivides straumes sinhronizē veidojošos multivides ierakstus
  • Dažādas multivides straumes netiek sinhronizētas viena ar otru
  • Multivides straumes var būt lokālas un attālinātas, lokālā parasti ir savienota ar kameru un mikrofonu, attālās datus no tīkla saņem šifrētā veidā
  • Ir divu veidu multivides celiņi – video un audio.
  • Multivides ierakstiem ir iespēja ieslēgt/izslēgt
  • Multivides ieraksti sastāv no multivides kanāliem
  • Multivides ieraksti sinhronizē veidojošos multivides kanālus
  • Multivides straumēm un multivides ierakstiem ir etiķetes, pēc kurām tās var atšķirt
• Sesijas rokturis
  • Sesijas deskriptors tiek izmantots, lai loģiski savienotu divus tīkla mezglus
  • Sesijas deskriptors saglabā informāciju par pieejamie veidi video un audio datu kodēšana
  • WebRTC izmanto ārēju signalizācijas mehānismu - sesijas deskriptoru pārsūtīšanas uzdevumu ( sdp) attiecas uz pieteikumu
  • Loģiskā savienojuma mehānisms sastāv no diviem posmiem - teikumiem ( piedāvājums) un atbildi ( atbildi)
  • Sesijas deskriptora ģenerēšana nav iespējama, neizmantojot vietējo mediju straumi priekšlikuma gadījumā ( piedāvājums) un nav iespējams, neizmantojot attālās sesijas rokturi atbildes gadījumā ( atbildi)
  • Iegūtais deskriptors ir jāpiešķir ieviešanai WebRTC, un nav nozīmes tam, vai šis deskriptors ir iegūts attālināti vai lokāli no tās pašas ieviešanas WebRTC
  • Ir iespējams nedaudz rediģēt sesijas deskriptoru
• Kandidāti
  • Kandidāts ( Ledus kandidāts) ir tīkla mezgla adrese
  • Mezgla adrese var būt jūsu vai maršrutētāja adrese vai GRIEZIES serveriem
  • Kandidātu vienmēr ir daudz
  • Kandidāts sastāv no IP adrese, osta un transporta veids ( TCP vai UDP)
  • Kandidātus izmanto, lai izveidotu fizisku savienojumu starp diviem tīkla mezgliem
  • Kandidāti arī jānosūta, izmantojot signalizācijas mehānismu
  • Kandidāti arī jāpārceļ uz implementācijām WebRTC, tomēr tikai attālināti
  • Dažās implementācijās WebRTC kandidātus var pārsūtīt tikai pēc tam, kad ir iestatīts sesijas deskriptors
• Apdullināt/pagriezt/LEDUS/NAT
  • NAT– mehānisms piekļuves nodrošināšanai ārējam tīklam
  • Mājas maršrutētāji atbalsta īpašu tabulu NAT
  • Maršrutētājs aizstāj adreses paketēs - avota adresi ar savu, ja pakete nonāk ārējā tīklā, un saņēmēja adresi ar resursdatora adresi iekšējā tīklā, ja pakete nāk no ārēja tīkla.
  • Lai nodrošinātu vairāku kanālu piekļuvi ārējam tīklam NAT izmanto portus
  • ICE– apvedceļa mehānisms NAT
  • Apdullināt Un GRIEZIES serveri – palīgserveri apiešanai NAT
  • Apdullināt serveris ļauj izveidot nepieciešamos ierakstus tabulā NAT, kā arī atgriež mezgla ārējo adresi
  • GRIEZIES serveris vispārina Apdullināt mehānisms un liek tam vienmēr darboties
  • Sliktākajos gadījumos GRIEZIES serveris tiek izmantots kā starpnieks ( relejs), tas ir p2p pārvēršas klients-serveris-klients komunikācijā.

WebRTC (Web Real Time Communications) ir standarts, kas apraksta audio datu, video datu un satura straumēšanu no un uz pārlūkprogrammu reāllaikā, neinstalējot spraudņus vai citus paplašinājumus. Standarts ļauj pārvērst pārlūkprogrammu par videokonferenču termināli, lai sāktu sazināties, jums vienkārši jāatver tīmekļa lapa.

Kas ir WebRTC?

Šajā rakstā mēs apskatīsim visu, kas jums jāzina par WebRTC tehnoloģiju parasts lietotājs. Apskatīsim projekta priekšrocības un trūkumus, atklāsim dažus noslēpumus, pastāstīsim, kā tas darbojas, kur un kam tiek izmantots WebRTC.

Kas jums jāzina par WebRTC?

Video komunikācijas standartu un tehnoloģiju evolūcija

Sergejs Jutsaitis, Cisco, Video+konference 2016

Kā darbojas WebRTC

Klienta puse

• Lietotājs atver lapu, kurā ir HTML5 tags
• Pārlūkprogramma pieprasa piekļuvi lietotāja tīmekļa kamerai un mikrofonam.
• JavaScript kods lietotāja lapā kontrolē savienojuma parametrus (WebRTC servera vai citu WebRTC klientu IP adreses un portus), lai apietu NAT un ugunsmūri.
• Saņemot informāciju par sarunu partneri vai par straumi no konferences, kas sajaukta serverī, pārlūkprogramma sāk pārrunāt izmantotos audio un video kodekus.
• Sākas kodēšanas process un straumēšanas datu pārsūtīšana starp WebRTC klientiem (mūsu gadījumā starp pārlūkprogrammu un serveri).

WebRTC servera pusē

Video serveris nav nepieciešams, lai apmainītos ar datiem starp diviem dalībniekiem, bet, ja nepieciešams apvienot vairākus dalībniekus vienā konferencē, ir nepieciešams serveris.

Video serveris saņems multivides trafiku no dažādiem avotiem, konvertēs to un nosūtīs lietotājiem, kuri izmanto WebRTC kā termināli.

Turklāt WebRTC serveris saņems multivides trafiku no WebRTC vienaudžiem un pārsūtīs to konferences dalībniekiem, kuri izmanto lietojumprogrammas galddatori vai mobilās ierīces, ja kāds.

Standarta priekšrocības

• Nav nepieciešama programmatūras instalēšana.
• Ļoti augsta komunikācijas kvalitāte, pateicoties:
  • Mūsdienu video (VP8, H.264) un audio kodeku (Opus) izmantošana.
  • Automātiska straumes kvalitātes pielāgošana savienojuma apstākļiem.
  • Iebūvēta atbalss un trokšņu samazināšanas sistēma.
  • Automātiska dalībnieku mikrofonu (AGC) jutības līmeņa regulēšana.
• Augsts drošības līmenis: visi savienojumi ir aizsargāti un šifrēti, izmantojot TLS un SRTP protokolus.
• Ir iebūvēts mehānisms satura, piemēram, darbvirsmas, tveršanai.
• Iespēja ieviest jebkuru pārvaldības saskarni, kuras pamatā ir HTML5 un JavaScript.
• Iespēja integrēt saskarni ar jebkuru aizmugursistēmu, izmantojot WebSockets.
• Projekts ar atvērtu avota kods— var tikt ieviests jūsu produktā vai pakalpojumā.
• Patiesa starpplatforma: tā pati WebRTC lietojumprogramma darbosies vienlīdz labi jebkurā operētājsistēma, galddatorā vai mobilajā ierīcē, ja pārlūkprogramma atbalsta WebRTC. Tas ievērojami ietaupa resursus programmatūras izstrādei.

Standarta trūkumi

• Grupu audio un video konferenču organizēšanai nepieciešams videokonferenču serveris, kas miksētu video un skaņu no dalībniekiem, jo Pārlūkprogramma nezina, kā sinhronizēt vairākas ienākošās straumes savā starpā.
• Visi WebRTC risinājumi ir nesavietojami viens ar otru, jo... standarts apraksta tikai metodes video un audio pārsūtīšanai, atstājot pārdevēja ziņā metožu ieviešanu abonentu uzrunāšanai, viņu pieejamības izsekošanai, ziņojumu un failu apmaiņai, plānošanai un citām lietām.
• Citiem vārdiem sakot, jūs nevarēsit piezvanīt no viena izstrādātāja WebRTC lietojumprogrammas uz cita izstrādātāja WebRTC lietojumprogrammu.
• Grupu konferenču miksēšana prasa lielus skaitļošanas resursus, tāpēc šāda veida video komunikācijai ir jāiegādājas maksas abonements vai jāiegulda savā infrastruktūrā, kur katrai konferencei nepieciešams 1 moderna procesora fiziskais kodols.

WebRTC noslēpumi: kā pārdevēji gūst labumu no izrāviena tīmekļa tehnoloģijas

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

WebRTC videokonferenču tirgum

Videokonferenču termināļu skaita palielināšanās

WebRTC tehnoloģijai ir bijusi spēcīga ietekme uz videokonferenču tirgus attīstību. Pēc pirmo pārlūkprogrammu ar WebRTC atbalstu izlaišanas 2013. gadā potenciālais videokonferenču termināļu skaits visā pasaulē nekavējoties palielinājās par 1 miljardu ierīču. Faktiski katra pārlūkprogramma ir kļuvusi par videokonferenču termināli, kas komunikācijas kvalitātes ziņā nav zemāka par aparatūras kolēģiem.

Izmanto specializētos risinājumos

Izmantojot dažādas JavaScript bibliotēkas un mākoņpakalpojumu API ar WebRTC atbalstu, ir viegli pievienot video komunikācijas atbalstu jebkuram tīmekļa projektam. Iepriekš, lai pārraidītu datus reāllaikā, izstrādātājiem bija jāizpēta protokolu darbības principi un jāizmanto citu uzņēmumu izstrādes, kas visbiežāk prasīja papildu licencēšanu, kas sadārdzināja izmaksas. WebRTC jau tiek aktīvi izmantots tādos pakalpojumos kā “Zvans no vietnes”, “Tiešsaistes tērzēšanas atbalsts” utt.

Bijušie Skype operētājsistēmai Linux lietotāji

2014. gadā Microsoft paziņoja par Skype for Linux projekta atbalsta pārtraukšanu, kas izraisīja lielu IT speciālistu sašutumu. WebRTC tehnoloģija nav piesaistīta operētājsistēmai, bet tiek ieviesta pārlūkprogrammas līmenī, t.i. Linux lietotāji varēs redzēt uz WebRTC balstītus produktus un pakalpojumus kā pilnvērtīgu Skype aizstājēju.

Sacensības ar Flash

WebRTC un HTML5 bija nāves trieciens Flash tehnoloģijai, kas jau piedzīvoja savus sliktākos gadus. Kopš 2017. gada vadošās pārlūkprogrammas ir oficiāli pārtraukušas atbalstīt Flash, un tehnoloģija ir pilnībā pazudusi no tirgus. Bet mums ir jāpiešķir Flash, jo tas bija tas, kurš izveidoja tīmekļa konferenču tirgu un piedāvāja tehniskās iespējas tiešai saziņai pārlūkprogrammās.

WebRTC video prezentācijas

Dmitrijs Odincovs, TrueConf, video+konference, 2017. gada oktobris

Kodeki pakalpojumā WebRTC

Audio kodeki

WebRTC izmanto Opus un G.711 kodekus, lai saspiestu audio trafiku.

G.711- vecākais balss kodeks ar augstu bitu pārraides ātrumu (64 kbps), ko visbiežāk izmanto tradicionālajās telefonijas sistēmās. Galvenā priekšrocība ir minimālā skaitļošanas slodze, ko rada vieglu saspiešanas algoritmu izmantošana. Kodekam ir zems balss signālu saspiešanas līmenis, un tas neievieš papildu audio aizkavi komunikācijas laikā starp lietotājiem.

G.711 atbalsta liels skaits ierīču. Sistēmas, kas izmanto šo kodeku, ir vieglāk lietojamas nekā tās, kuru pamatā ir citi audio kodeki (G.723, G.726, G.728 utt.). Kvalitātes ziņā G.711 MOS testēšanā saņēma punktu 4,2 (rezultāts no 4 līdz 5 ir visaugstākais un nozīmē laba kvalitāte, līdzīgi kā balss trafika pārraides kvalitāte ISDN un pat augstāka).

Opus ir kodekss ar zemu kodēšanas latentumu (no 2,5 ms līdz 60 ms), mainīga bitu pārraides ātruma un augsta kompresijas līmeņa atbalstu, kas ir ideāli piemērots straumēšanas audio signālu pārraidīšanai tīklos ar mainīgu caurlaidspēja. Opus ir hibrīds risinājums, kas apvieno SILK (balss saspiešana, cilvēka runas traucējumu novēršana) un CELT (audio datu kodēšana) kodeku labākās īpašības. Kodeks ir brīvi pieejams izstrādātājiem, kuri to izmanto, nav jāmaksā autortiesību īpašniekiem. Salīdzinot ar citiem audio kodekiem, Opus neapšaubāmi uzvar daudzos aspektos. Tas ir aizēnojis diezgan populārus zema bitu pārraides ātruma kodekus, piemēram, MP3, Vorbis, AAC LC. Opus atjauno skaņas “attēlu” tuvāk oriģinālam nekā AMR-WB un Speex. Šis kodeks ir nākotne, tāpēc WebRTC tehnoloģijas veidotāji to iekļāva obligātajā atbalstīto audio standartu diapazonā.

Video kodeki

WebRTC video kodeka izvēles problēmas izstrādātājiem prasīja vairākus gadus, un galu galā viņi nolēma izmantot H.264 un VP8. Gandrīz visas mūsdienu pārlūkprogrammas atbalsta abus kodekus. Videokonferenču serveriem ir jāatbalsta tikai viens, lai strādātu ar WebRTC.

VP8- bezmaksas video kodeku ar atvērtu licenci, ko raksturo liels video straumes dekodēšanas ātrums un paaugstināta izturība pret kadru zudumu. Kodeks ir universāls un viegli iestrādājams aparatūras platformās, tāpēc video konferenču sistēmu izstrādātāji to ļoti bieži izmanto savos produktos.

Maksas video kodeks H.264 kļuva slavens daudz agrāk nekā viņa brālis. Šis ir kodeks ar augstu video straumes saspiešanas pakāpi saglabāšanas laikā Augstas kvalitātes video. Šī kodeka lielā izplatība starp aparatūras videokonferenču sistēmām liecina par tā izmantošanu WebRTC standartā.

Google un Mozilla aktīvi reklamē VP8 kodeku, un Microsoft, Apple un Cisco aktīvi reklamē H.264 (lai nodrošinātu saderību ar tradicionālajām videokonferenču sistēmām). Un te rodas ļoti liela problēma mākoņu WebRTC risinājumu izstrādātājiem, jo, ja visi konferences dalībnieki izmanto vienu pārlūkprogrammu, tad pietiek vienreiz sajaukt konferenci ar vienu kodeku un, ja pārlūkprogrammas ir dažādas un Safari / Edge ir starp tiem, tad konferencei būs jākodē divreiz dažādi kodeki, kas dubultos Sistēmas prasības multivides serverim un līdz ar to WebRTC pakalpojumu abonēšanas izmaksas.

WebRTC API

WebRTC tehnoloģija ir balstīta uz trim galvenajām API:

• (atbildīgs par tīmekļa pārlūkprogrammas audio un video signālu saņemšanu no kamerām vai lietotāja darbvirsmas).
• RTCPeerConnection(atbild par savienojumu starp pārlūkprogrammām, lai “apmainītos” multivides dati, kas saņemti no kameras, mikrofona un darbvirsmas. Tāpat šīs API “pienākumos” ietilpst signāla apstrāde (tā attīrīšana no svešiem trokšņiem, mikrofona skaļuma regulēšana) un kontrole pār izmantotie audio un video kodeki).
• RTCData kanāls(nodrošina divvirzienu datu pārsūtīšanu, izmantojot izveidoto savienojumu).

Pirms piekļūstat lietotāja mikrofonam un kamerai, pārlūkprogramma pieprasa atļauju to darīt. IN Google Chrome Piekļuvi var konfigurēt iepriekš sadaļā “Iestatījumi” operētājsistēmās Opera un Firefox, ierīces tiek atlasītas tieši piekļuves brīdī no nolaižamā saraksta. Atļaujas pieprasījums vienmēr tiks parādīts, izmantojot HTTP protokolu, un tikai vienu reizi, ja tiek izmantots HTTPS:

RTCPeerConnection. Katrai pārlūkprogrammai, kas piedalās WebRTC konferencē, ir jābūt piekļuvei šo objektu. Pateicoties RTCPeerConnection izmantošanai, multivides dati no vienas pārlūkprogrammas uz otru var pat tikt cauri NAT un ugunsmūri. Lai veiksmīgi pārsūtītu multivides straumes, dalībniekiem ir jāapmainās ar šādiem datiem, izmantojot transportu, piemēram, tīmekļa ligzdas:

• iniciējošais dalībnieks nosūta otrajam dalībniekam Offer-SDP (datu struktūra ar multivides straumes īpašībām, ko tas pārraidīs);
• otrais dalībnieks ģenerē “atbildi” - Answer-SDP un nosūta to iniciatoram;
• tad tiek organizēta ICE kandidātu apmaiņa starp dalībniekiem, ja tādi tiek konstatēti (ja dalībnieki atrodas aiz NAT vai ugunsmūriem).

Pēc veiksmīgas šīs apmaiņas pabeigšanas tiek organizēta tieša multivides straumju (audio un video) pārsūtīšana starp dalībniekiem.

RTCData kanāls. Datu kanāla protokola atbalsts pārlūkprogrammās parādījās salīdzinoši nesen, tāpēc šo API var uzskatīt tikai WebRTC izmantošanas gadījumos pārlūkprogrammās. Mozilla Firefox 22+ un Google Chrome 26+. Ar tās palīdzību dalībnieki var apmainīties isziņas pārlūkprogrammā.

Savienojums caur WebRTC

Atbalstītās darbvirsmas pārlūkprogrammas

• Google Chrome (17+) un visas pārlūkprogrammas, kuru pamatā ir Chromium dzinējs;
• Mozilla FireFox (18+);
• Opera (12+);
• Safari (11+);

Atbalstītās mobilās pārlūkprogrammas operētājsistēmai Android

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

WebRTC, Microsoft un Internet Explorer

Ļoti ilgu laiku Microsoft klusēja par WebRTC atbalstu pārlūkprogrammā Internet Explorer un tās jaunajā Edge pārlūkprogrammā. Redmondas puišiem īsti nepatīk nodot lietotāju rokās tehnoloģijas, kuras viņi nekontrolē, tāda ir politika. Taču pamazām lieta izkustējās no nāves punkta, jo... WebRTC vairs nebija iespējams ignorēt, un tika paziņots par ORTC projektu, kas ir WebRTC standarta atvasinājums.

Pēc izstrādātāju domām, ORTC ir WebRTC standarta paplašinājums ar uzlabotu API komplektu, kas balstīts uz JavaScript un HTML5, kas, tulkojot parastā valodā, nozīmē, ka viss būs pa vecam, tikai Microsoft, nevis Google kontrolēs standartu. un tās attīstību. Kodeku komplekts ir papildināts ar atbalstu H.264 un dažiem G.7ХХ sērijas audio kodekiem, ko izmanto telefonijas un aparatūras videokonferenču sistēmās. Var būt iebūvēts atbalsts RDP (satura pārsūtīšanai) un ziņojumapmaiņai. Starp citu, Internet Explorer lietotājiem nav paveicies, ORTC atbalsts būs pieejams tikai Edge. Un, protams, šis protokolu un kodeku komplekts viegli saskaras ar Skype for Business, kas atver vēl vairāk biznesa lietojumprogrammu WebRTC.

Šī raksta mērķis ir izmantot vienādranga video tērzēšanas (p2p video tērzēšanas) demonstrācijas paraugu, lai iepazītos ar tās struktūru un darbības principu. Šim nolūkam mēs izmantosim vairāku lietotāju vienādranga video tērzēšanas demonstrāciju webrtc.io-demo. To var lejupielādēt no saites: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Jāatzīmē, ka GitHub ir vietne vai tīmekļa pakalpojums, kas paredzēts tīmekļa projektu kopīgai izstrādei. Tajā izstrādātāji var ievietot savu izstrādes kodus, apspriest tos un sazināties savā starpā. Turklāt daži lielie IT uzņēmumi šajā vietnē ievieto savus oficiālos repozitorijus. Pakalpojums ir bezmaksas atvērtā pirmkoda projektiem. GitHub ir atvērtu, bezmaksas pirmkoda bibliotēku repozitorijs.

Tātad vienādranga video tērzēšanas demonstrācijas paraugs, kas lejupielādēts no GitHub diskā C personālais dators izveidotajā direktorijā mūsu lietojumprogrammai "webrtc_demo".

Rīsi. 1

Kā izriet no struktūras (1. att.), peer-to-peer video tērzēšana sastāv no klienta script.js un servera server.js skriptiem, kas ieviesti JavaScript programmēšanas valodā. Skripts (bibliotēka) webrtc.io.js (KLIENTS) - nodrošina reāllaika saziņas organizēšanu starp pārlūkprogrammām, izmantojot vienādranga shēmu: "klients-klients" un webrtc.io.js (CLIENT) un webrtc. io.js (SERVER), izmantojot WebSocket protokolu, tie nodrošina duplekso saziņu starp pārlūkprogrammu un tīmekļa serveri, izmantojot klienta-servera arhitektūru.

Webrtc.io.js (SERVER) skripts ir iekļauts webrtc.io bibliotēkā un atrodas node_modules\webrtc.io\lib direktorijā. Video tērzēšanas saskarne index.html ir ieviesta HTML5 un CSS3. Webrtc_demo lietojumprogrammas failu saturu var apskatīt, izmantojot kādu no html redaktoriem, piemēram, "Notepad++".

Mēs pārbaudīsim video tērzēšanas darbības principu failu sistēma PC. Lai darbinātu serveri (server.js) datorā, jāinstalē izpildlaika vide node.js. Node.js ļauj palaist JavaScript kodu ārpus pārlūkprogrammas. Varat lejupielādēt node.js no saites: http://nodejs.org/ (versija v0.10.13 no 15.07.13.). Vietnes node.org galvenajā lapā noklikšķiniet uz lejupielādes pogas un dodieties uz http://nodejs.org/download/. Windows lietotājiem vispirms lejupielādējiet win.installer (.msi), pēc tam palaidiet win.installer (.msi) datorā un instalējiet nodejs un "npm pakotņu pārvaldnieku" direktorijā Programmas faili.

Rīsi. 2

Tādējādi node.js sastāv no vides JavaScript koda izstrādei un palaišanai, kā arī iekšējo moduļu kopas, ko var instalēt, izmantojot pārvaldnieku vai npm pakotņu pārvaldnieku.

Lai instalētu moduļus, jums ir nepieciešams komandrinda Lietojumprogrammu direktorijā (piemēram, "webrtc_demo") palaidiet komandu: npm instalēšanas moduļa_nosaukums. Moduļu instalēšanas laikā npm pārvaldnieks direktorijā, no kura tika veikta instalēšana, izveido mapi node_modules. Darbības laikā nodejs automātiski savieno moduļus no direktorija node_modules.

Tātad pēc node.js instalēšanas atveriet komandrindu un atjauniniet ekspresmoduli webrtc_demo direktorija mapē node_modules, izmantojot npm pakotņu pārvaldnieku:

C:\webrtc_demo>npm install express

Ātrais modulis ir tīmekļa ietvars node.js vai tīmekļa platforma lietojumprogrammu izstrādei. Lai iegūtu globālu piekļuvi Express, varat to instalēt šādi: npm install -g express.

Pēc tam atjauniniet moduli webrtc.io:

C:\webrtc_demo>npm instalējiet webrtc.io

Pēc tam komandrindā mēs palaižam serveri: server.js:

C:\webrtc_demo>node server.js

Rīsi. 3

Tas arī viss, serveris darbojas veiksmīgi (3. attēls). Tagad, izmantojot tīmekļa pārlūkprogrammu, varat sazināties ar serveri pēc IP adreses un ielādēt index.html tīmekļa lapu, no kuras tīmekļa pārlūkprogramma izvilks klienta skripta kodu - script.js un webrtc.io.js skripta kodu, un izpildīt tos. Lai darbotos vienādranga video tērzēšana (lai izveidotu savienojumu starp divām pārlūkprogrammām), jums jāsazinās ar signāla serveri, kas darbojas vietnē node.js no divām pārlūkprogrammām, kas atbalsta webrtc.

Rezultātā atvērsies komunikācijas aplikācijas (video tērzēšanas) klienta daļas saskarne ar pieprasījumu pēc atļaujas piekļūt kamerai un mikrofonam (4. att.).

Rīsi. 4

Pēc noklikšķināšanas uz pogas "Atļaut", kamera un mikrofons ir savienoti multivides saziņai. Turklāt jūs varat sazināties, izmantojot teksta datus, izmantojot video tērzēšanas saskarni (5. att.).

Rīsi. 5

Jāpiebilst, ka. Serveris ir signalizācijas serveris, un tas galvenokārt ir paredzēts, lai izveidotu savienojumus starp lietotāju pārlūkprogrammām. Node.js tiek izmantots, lai darbinātu server.js skriptu, kas nodrošina WebRTC signālu.