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

WebRTC

Ievads

WebRTC ir uz pārlūkprogrammu balstīta tehnoloģija, kas ļauj savienot divus klientus video datu pārraidei. Galvenās funkcijas ir iekšējais pārlūkprogrammas atbalsts (nav nepieciešamas trešās puses iegultās 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, t.i., adreses internetā. Nelielā daudzuma dēļ IPv4 adresēm (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. publiski IP Adreses internetā ir unikālas, bet privātās adreses nav. Tātad 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 privātais, otrs publiski) (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āts, viens 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, kuriem ir līdzīgi mezglu numuri. Šeit parādās maršrutētāji (maršrutētāji), kuriem ir divas tīkla saskarnes - 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 ar palīdzību 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 mezgls p1 tur ir interjers IP = 192.168.0.200 un ārējā IP = 10.50.200.5 , kura pēdējā adrese ir arī ārēja visiem citiem saimniekiem viņa tīklā. Situācija ir līdzīga mezglam p2. Tāpēc viņu savienojums nav iespējams, ja tikai viņu iekšējais (savējais) IP adreses. Varat izmantot ārējās adreses, tas ir, maršrutētāju 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. Šo problēmu atrisina mehānisms NAT

Kas notiks, ja mēs tomēr 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). Tas viss zemāk.

Divas WebRTC fāzes

Lai savienotu divus mezglus, izmantojot protokolu WebRTC(vai vienkārši RTC ja ir savienoti divi 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.

Uzreiz jāsaka, ka, lai gan tehnoloģija WebRTC savā darbā izmanto dažādas komunikācijas metodes ( TCP un UDP), un tai ir elastīga pārslēgšanās starp tām, šī tehnoloģija nav protokola savienojuma datu nodošanai. 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ārsūtīšanas metode, kas nav saistīta ar WebRTC. Tas var būt ligzdas pārsūtīšana, protokols http, tas var būt pat protokols SMTP vai Krievijas pasts. Šis transmisijas mehānisms primārs dati tiek saukti signāls. Nav nepieciešams pārsūtīt daudz informācijas. Visi dati tiek pārsūtīti kā teksts 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 vēlāk, bet šobrīd 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š atsevišķi, tiks izmantots tikai savienojuma gadījumā, un tas netiks izmantots, pārsūtot video datus.

Tātad, aplūkosim pirmo fāzi, savienojuma iestatīšanas fāzi. Tas sastāv no vairākiem priekšmetiem. Vispirms apsveriet šo posmu mezglam, kas uzsāk savienojumu, un pēc tam gaidošajam.

• Iniciators (zvanītājs - zvanītājs):
  1. Piedāvājums sākt video datu pārraidi (createOffer)
  2. Iegūt savu SDP SDP)
  3. Iegūt savu Ledus kandidāts Ledus kandidāts)
• Zvana gaidīšana ( callee):
  1. Vietējās (savas) multivides straumes iegūšana un iestatīšana pārraidei (getUserMediaStream)
  2. Saņemt piedāvājumu sākt video datu pārsūtīšanu un izveidot atbildi (createAnswer)
  3. Iegūt savu SDP objektu un izlaižot to caur signalizācijas mehānismu ( SDP)
  4. Iegūt savu 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ā rindkopā.

Neskatoties uz šķietamo soļu sarežģītību, patiesībā tās ir trīs: savas multivides straumes nosūtīšana (1. lpp.), savienojuma parametru iestatīšana (2.-4. lpp.), kāda cita multivides straumes saņemšana (5. lpp.). 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 jāiet paketēm, lai nokļūtu no viena tīkla mezgla uz otru. Otrais norāda video/audio parametri- kādu kvalitāti izmantot, kādus kodekus izmantot.

Garīgā stadijā izveidot Piedāvājumu vai izveidotAtbildi jābūt savienotam ar pārsūtīšanas posmiem SDP un Ledus kandidāts objektus.

Pamatvienības

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 – lokālās un attālās. Lokālais saņem datus no ievades ierīcēm (kamera, mikrofons), bet attālā – tīklā. Tādējādi katram mezglam ir gan vietējais, gan attālais pavediens. AT WebRTC ir saskarne pavedieniem mediju plūsma un ir arī apakšinterfeiss LocalMediaStreamīpaši vietējam pavedienam. AT JavaScript jūs varat saskarties tikai ar pirmo, un, ja jūs izmantojat lib džinksts, tad var sastapt arī otro.

AT WebRTC pavedienā ir diezgan mulsinoša hierarhija. Katra straume var sastāvēt no vairākiem multivides celiņiem ( mediju celiņš), 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 (mēs + tabula) un viens audio (mēs). Ir skaidrs, ka mēs un tabulu vajadzētu sadalīt dažādos pavedienos, jo šie dati, iespējams, ir vāji atkarīgi viens no otra. Tāpēc mums būs divi mediju plūsma‘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 mediju straumē vismaz jāiekļauj iespēja saturēt dažāda veida datus – video un audio. Tas tiek ņemts vērā tehnoloģijā, un tāpēc katrs datu veids tiek ieviests, izmantojot multivides celiņu. mediju celiņš. Mediju celiņam ir īpašs īpašums laipns, kas nosaka, kas ir mūsu priekšā - video vai audio (5. attēls)

5. attēls. Multivides straumes veido multivides celiņi

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 ierakstam pateiksim, 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ā 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 pirmajā mirklī šķiet, ka video no skaņas var atšķirt arī citādi.

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

Tātad, ja multivides ierakstus var identificēt, izmantojot etiķeti, 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 un tajā izmantot dažādus ierakstus. Mēs esam nonākuši pie svarīgas mediju straumju īpašības - 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 vienlaikus.

Tādējādi, ja mēs vēlamies, lai mūsu vārdi, emocijas uz sejas un mūsu papīra lapa tiktu atskaņota vienlaikus, 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ā celiņš ir jāatspējo, varat izmantot īpašumu iespējots multivides ieraksti.

Galu galā jums vajadzētu padomāt par stereo skaņu. Kā jūs zināt, stereo skaņa ir divas dažādas skaņas. Un tie arī jāsūta atsevišķi. Šim nolūkam tiek izmantoti kanāli. MediaChannel. Audio multivides celiņam var būt daudz kanālu (piemēram, 6, ja nepieciešams 5+1 audio). Mediju celiņā, protams, arī kanāli sinhronizēts. Video parasti tiek izmantots tikai viens kanāls, bet var tikt izmantoti vairāki, piemēram, reklāmas pārklājumiem.

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 vairāk, ja nepieciešams pārsūtīt vairākus dažādus videoklipus (sarunu biedra un viņa tabulas). 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ā mediju 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 mediju datu pārsūtīšanai starp diviem tīkla mezgliem. WebRTC izdara to automātiski un izveido īpašu objektu – sesijas rokturi SDP. Nododiet šo objektu citam mezglam, un jūs varat nosūtīt multivides datus. Tikai vēl nav savienojuma ar citu mezglu.

Šim nolūkam tiek izmantots jebkurš signalizācijas mehānisms. SDP var pārraidīt pat pa rozetēm, pat cilvēks (pastāsti citam mezglam pa telefonu), kaut vai Krievijas pasts. Viss ir ļoti vienkārši - jums iedos gatavu SDP un ir jānosūta. Un pēc saņemšanas otrā pusē - pārskaitījums uz nodaļu WebRTC. Sesijas rokturis tiek saglabāts kā teksts, un jūs varat to mainīt savās lietojumprogrammās, taču parasti tas nav nepieciešams. Piemēram, pievienojot galddatoru↔tālruni, dažreiz jums ir jāpiespiež vēlamā audio kodeka atlase.

Parasti, izveidojot savienojumu, ir jānorāda, piemēram, kāda adrese URL. Šeit tas nav nepieciešams, jo jūs pats nosūtīsit datus uz galamērķi, izmantojot signalizācijas mehānismu. 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 objektu un nodots tam pašam 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 otrā galā dati nonāks 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 tiks nodots lokālās sesijas deskriptors, un tas būs jānodod 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. Neizsauciet arī createAnswer un createOffer, kamēr nav saņemta vietējā multivides straume - 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 iegūšanas tas ir jāiestata. Var šķist mazliet dīvaini paiet garām WebRTC ko viņa pati mums iedeva, bet tāds ir protokols. Saņemot tālvadības rokturi, tas arī jāiestata. Tāpēc vienā mezglā ir jāinstalē divi deskriptori - savs un kāda cita (tas ir, lokālais un attālais).

Pēc tādiem 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). Savienojuma loģika tagad ir izveidota 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

Kandidāti (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 ir darīts pretējais. Bet tas nešķitīs dīvaini, ja neaizmirstam, ka izmantojam trešās puses signalizācijas mehānismu.

Tātad savienojums jau ir izveidots (loģiskais savienojums), bet tīkla mezgliem vēl nav iespējas 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, izmantojot savu iekšējo IP adreses (vai varbūt kādas citas, ja netiek izmantotas TCP/IP).

Caur dažiem atzvani'un WebRTC stāsta mums Ledus kandidāts objektus. Tie ir arī teksta formā, un tāpat kā ar sesiju deskriptoriem 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 viņš varēs fiziski izveidot savienojumu ar mums, un, tā kā viņam jau ir sesijas deskriptors, viņš var loģiski izveidot savienojumu un dati "plūs". Ja viņš neaizmirsīs mums nosūtīt savu kandidāta objektu, tas ir, informāciju par to, kur viņš atrodas tīklā, tad mēs varēsim ar viņu sazināties. Šeit mēs atzīmējam 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 adrese, kas norādīta pieprasījuma pakotnē. AT WebRTC jāzina divas adreses un savienojiet tos abās pusēs.

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

Un kāpēc bija tikai viens sesijas deskriptors, bet var 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 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 ir ietverta kandidātobjektā - IP, PORTA, TRANSPORTS un daži citi. Ļaujiet, piemēram, izmantot UDP transports un 531 osta.

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

Tad, ja mēs atrodamies mezglā p1, tad WebRTC dos mums tādu kandidāta objektu - . Tas nav precīzs formāts, bet 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ņa IP un PORTA). 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 viegli - 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 būs vienā tīklā ar šo maršrutētāju (piemēram, internetā) (9. attēls).

9. attēls. Viens saimniekdators aiz NAT, otrs ne

Šajā gadījumā ir īpašs problēmas risinājums, ko mēs tagad apsveram. Mājas maršrutētājā parasti ir tabula 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 . Pirmkārt, 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 savu ( p1 → r1). Turklāt saskaņā ar ā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 mainīja adresi uz savu). Maršrutētājs saņem datus, apskata tabulu NAT un nosūta datus uz mezglu p1. Maršrutētājs šeit darbojas kā starpnieks.

Bet 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 ar 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 dažādi. Pēc tam, kad pakete no tīmekļa servera nonāk atpakaļ maršrutētājā, maršrutētājs sapratīs pēc porta, kuram šī pakete ir piešķirta. Piemērs ir zemāk.

Atgriezties pie tehnoloģijām WebRTC, vai drīzāk, tās 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 resursdatoru - tas var būt un var nebūt tajā pašā tīklā. Otrais kandidāts noderēs, un, kā jau zinām, ostai būs liela nozīme (lai tiktu cauri NAT).

Tabulas ieraksts NAT tiek ģenerēti tikai tad, kad dati tiek izvadīti 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 nokļūt mezglā p1.

Par praksi abi mezgli būs aiz muguras NAT. Lai izveidotu tabulas ierakstu NAT katrs maršrutētājs, 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 datu sūtīšana uz iekšējām adresēm ir bezjēdzīga.

Tomēr, ja ārējās adreses ir zināmas, savienojums būs viegli nodibināts. Ja pirmais mezgls nosūta datus otrā mezgla maršrutētājam, maršrutētājs tos ignorēs, jo tā tabula NAT kamēr tukšs. Tomēr tabulas pirmā mezgla maršrutētājā NAT bija vajadzīgs ieraksts. 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šamie dati.

Problēma ir tā, ka, lai uzzinātu savu ārējo IP adrese, jums ir nepieciešams mezgls, kas atrodas kopējā tīklā. 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īgie ieraksti tabulā. NAT.

STUN un TURN serveri

Inicializācijas laikā WebRTC pieejams Apdullināt un GRIEZIES serveri, kurus mēs sauksim kā ICE serveriem. Ja serveri nav norādīti, tad tikai mezgli tajā pašā tīklā (savienots ar to bez NAT). Uzreiz jāatzīmē, 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 resursdatora adresi. Piekļūst mezgls aiz maršrutētāja Apdullināt serveris, kuram jāiziet cauri NAT. Paciņa, kas atnāca 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 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 maršrutētājam nosūtītās paketes vajadzīgajā portā nodod mūsu mezglam.

Apskatīsim šo procesu ar piemēru.

Piemērs (darba STUN serveris)

Apdullināt serveris tiks apzīmēts 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ā, dažādos apakštīklos var izmantot dažādas tehnoloģijas). Maršrutētājam ir jāaizstāj avota adrese src IP, jo paketē norādītā adrese acīmredzami nav piemērota ārējam apakštīklam, turklāt adreses no šī diapazona tiek rezervētas, un nevienai adresei internetā nav šādas adreses. Maršrutētājs veic aizstāšanu paketē un izveido jaunu ierakstu savā tabulā r1_nat. Lai to izdarītu, viņam ir jāizdomā porta numurs. Atgādiniet to, jo vairāki mezgli apakštīklā var piekļūt ārējam tīklam, tad tabulā NAT ir jāsaglabā papildu informācija, lai maršrutētājs varētu noteikt, kuram no šiem vairākiem saimniekiem ir paredzēta atgriešanas pakete no servera. Ļaujiet maršrutētājam nākt klajā ar portu 888 .

Mainīta pakotnes galvene:

4. tabula: NAT tabula 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. Patiešām, pēc atpakaļsūtīšanas 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 mainīja avota adresi un portu pakešu galvenē 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	MĒLĒTĀ OSTA
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 apskatīt to, ko tikko apsvērām. Iepriekš esošās tabulas ir daļa no galvene iepakojums, nevis no viņa 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 arī 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, parasti protokoliem nerūp informācija par mezglu adresēm, svarīgi tikai, lai paketes tiktu nogādātas galamērķī. Šeit mēs aplūkojam protokolu, kas nosaka ceļu starp diviem mezgliem.

Tātad tagad mums ir otrā partija, 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. Rūteris saprot, ka pakete nav paredzēta viņam. Kā viņš to saprot? To var atrast tikai osta. Osta 888 viņš neizmanto saviem personīgajiem mērķiem, bet izmanto mehānismu NAT. Tāpēc maršrutētājs aplūko šo tabulu. Skatās uz kolonnu Ārējais PORTS un meklē atbilstošu virkni MĒLĒTĀ OSTA no ienākošās pakas, tas ir 888 .

iekšējais 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, ka šāda līnija pastāv. Ja nepaveicas, tad paciņa vienkārši tiktu izmesta. Tagad jums ir jāsaprot, kuram no apakštīkla mezgliem ir jānosūta šī pakete. Nesteigsimies, atkārtosim 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āja uztvērēja adreses viltošana

src IP	Src PORT	Galamērķa IP	MĒLĒTĀ OSTA
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ā. Tas 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ūtīs uz rūteri r1 ostas pakotne 888 , maršrutētājs pārsūtīs šo paketi resursdatoram 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 serveru mērķis ir tikai pārvarēt ierobežojumus NAT.

Starp mezglu un serveri var būt vairāk nekā viens maršrutētājs, bet vairāki. Šajā gadījumā mezgls saņems tā maršrutētāja adresi, kas pirmais ievadīs tajā pašā tīklā, kur 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 faktu, ka katrā maršrutētājā tabulai tiks pievienota mums nepieciešamā līnija NAT. Tātad atpakaļceļš atkal būs tikpat gluds.

GRIEZIES serveris ir uzlabots Apdullināt serveris. No tā uzreiz izriet, 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 (kā norādīts 3g tīkli), serveris pārslēdzas uz atkārtotāja režīmu ( relejs), tas ir, tas darbojas kā starpnieks. Protams, par jebkuru p2p tad tas nav jautājums, bet gan ā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āki veidi NAT. Tie aizstāj to pašu IP adrese un ports, bet dažiem 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ā saimniekdatora 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 serveris neizdodas - tabula NAT saglabā adresi un portu Apdullināt serveris un kad maršrutētājs saņem paketi no WebRTC sarunu biedrs, viņš viņu izmet, jo viņš ir “falsificēts”. Viņš nenāca no Apdullināt serveris.

Pa šo ceļu GRIEZIES serveris ir vajadzīgs, kad abi sarunu biedri ir aiz muguras simetrisks NAT(katram par savu).

Ī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, atkārtoti izlasiet atbilstošos punktus.

• mediju straume
  • Video un audio dati tiek iesaiņoti multivides straumēs
  • Multivides straumes sinhronizē veidojošos multivides ierakstus
  • Dažādas multivides straumes nav sinhronizētas
  • Multivides straumes var būt lokālas un attālinātas, kamera un mikrofons parasti ir savienoti ar lokālo, attālās saņem datus no tīkla šifrētā veidā.
  • Ir divu veidu multivides celiņi – video un audio.
  • Multivides ierakstiem ir iespēja ieslēgt/izslēgt
  • Multivides ierakstus veido multivides kanāli
  • 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 pieejamajām video un audio datu kodēšanas metodēm.
  • 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 - priekšlikuma ( piedāvājums) un atbilde ( atbildi)
  • Sesijas deskriptora ģenerēšana nav iespējama, neizmantojot vietējo mediju straumi piedāvājuma gadījumā ( piedāvājums), un tas nav iespējams, neizmantojot attālās sesijas deskriptoru atbildes gadījumā ( atbildi)
  • Iegūtais deskriptors ir jāpiešķir ieviešanai WebRTC, un nav svarīgi, vai šis rokturis ir iegūts attālināti vai lokāli no tās pašas ieviešanas WebRTC
  • Sesijas deskriptoru ir iespējams nedaudz rediģēt
• 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ātiem ir jānokārto arī īstenošana WebRTC, bet tikai attālināti
  • Dažās implementācijās WebRTC Kandidātus var nokārtot tikai pēc sesijas deskriptora iestatīšanas
• STUN/TURN/LEDU/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 uztvērēja adresi ar resursdatora adresi iekšējā tīklā, ja pakete nāk no ārējā 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 par savienojumu klients-serveris-klients.

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

Situācija var mainīties, jo tagad Firefox ir integrēts 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 ir ne tikai viegli lietojams. Šī metode pat ļauj iestatīt tiešs savienojums starp divām pārlūkprogrammām. Tādējādi audio un video dati netiek cauri serverim, kurā var rasties pārslodze vai kura administrators nav īpaši jutīgs pret privātumu vai datu aizsardzību. Izmantojot tiešu savienojumu, WebRTC nav nepieciešama reģistrācija vai konts nevienā pakalpojumā.

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

Drīz pēc tam 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 nodrošina tveršanu no audio un video avotiem, t.i., tīmekļa kameras un mikrofona. RTCPeerConnection ir atbildīgs par savienojuma izveidi, kā arī par pašu komunikāciju.

Paralēli pārlūkprogrammas integrācijai World Wide Web Consortium (W3C) darba grupa ir virzījusi 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 draugus. Arī savienojuma izveide nav īpaši sarežģīta. Pirmkārt, pārlūkprogramma signalizē WebRTC serverim, ka tas plāno sākt zvanu. Tas saņem HTTPS saiti no servera - savienojums ir šifrēts. 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 otru pusi, pārlūkprogramma saņem savu IP adresi un konfigurācijas datus no WebRTC pakalpojuma. Drauga tīmekļa pārlūkprogramma 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(Drošs reāllaika transporta protokols), kas nodrošina reāllaika šifrētu straumēšanu.

Ja neizdodas izveidot tiešo savienojumu, WebRTC meklē citu ceļu. Piemēram, tas notiek, ja tīkla iestatījumi neļauj STUN serverim ziņot par IP adresi. WebRTC standarts nosaka, ka šajā gadījumā saruna notiks, bet ar starpposma TURN servera iekļauš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īmeklim.

Kā tiek izveidots savienojums

Vispirms ir jāreģistrē saruna (1). WebRTC pakalpojums nodrošina saiti, kas jānosūta sarunu biedram. Pārlūks, izmantojot STUNserveri, 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 drošo reāllaika protokolu (SRTP).

Kuras pārlūkprogrammas darbojas ar WebRTC

Chrome un Firefox ir aprīkoti ar WebRTC dzinēju, kas izmanto tādus pakalpojumus kā talky.io. Pārlūkprogramma Mozilla 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 konferenci ar vairākiem dalībniekiem, un jaunais Hello klients pārlūkprogrammā Firefox tiek izstrādāts ar telekomunikāciju giganta Telefonica meitasuzņēmuma palīdzību. Apple pagaidām paliek malā, pagaidām nevajadzētu gaidīt WebRTC pārlūkprogrammā Safari. Tomēr pārlūkprogrammai Safari ir daudz alternatīvu iOS lietotņu un spraudņu.

Microsoft izvēlas nedaudz citu kursu. Būdams konkurētspējīga Skype pakalpojuma īpašnieks, šis uzņēmums negatavojas tik viegli kapitulēt WebRTC priekšā. Tā vietā Microsoft izstrādā tehnoloģiju, ko sauc par ORTC (Object Real-Time Communications) pārlūkprogrammai Internet Explorer.

Atšķirības no WebRTC, piemēram, dažādi kodeki un protokoli kontakta nodibināšanai ar serveri, ir nelielas un laika gaitā, visticamāk, papildinās WebRTC standartu, kurā būs iekļautas šīs atšķirības. Tādējādi atpaliek tikai Apple - kā parasti.

Fotogrāfija: ražošanas uzņēmumi; goodluz/Photolia.com

Tehnoloģijas zvanīšanai no pārlūkprogrammas ir daudzus gadus vecas: Java, ActiveX, Adobe Flash... Pēdējos gados ir kļuvis skaidrs, ka spraudņi un atstātās virtuālās mašīnas nespīd ar ērtībām (kāpēc man vajadzētu kaut ko instalēt viss?) un, pats galvenais, drošība . Ko darīt? Ir izeja!

Vēl nesen IP tīklos IP telefonijai vai video tika izmantoti vairāki protokoli: SIP, visizplatītākais protokols, kas nāk ārpus skatuves, H.323 un MGCP, Jabber/Jingle (izmanto Gtalk), daļēji atvērtais Adobe RTMP* un , protams, slēgtais Skype. Google iniciētais WebRTC projekts mēģina mainīt IP un tīmekļa telefonijas pasauli, padarot visus softphones, tostarp Skype, novecojušus. WebRTC ne tikai ievieš visas komunikācijas iespējas tieši pārlūkprogrammā, kas tagad ir instalēta gandrīz visās ierīcēs, bet vienlaikus mēģina atrisināt arī vispārīgāku saziņas uzdevumu starp pārlūkprogrammas lietotājiem (dažādu datu apmaiņa, ekrāna tulkošana, sadarbība ar dokumentiem un daudz vairāk).

WebRTC, ko izveidojis tīmekļa izstrādātājs

No tīmekļa izstrādātāja viedokļa WebRTC sastāv no divām galvenajām daļām:

• multivides straumju pārvaldība no vietējiem resursiem (kamera, mikrofons vai lokālais datora ekrāns) tiek īstenota ar metodi navigator.getUserMedia, kas atgriež MediaStream objektu;
• peer-to-peer sakari starp ierīcēm, kas ģenerē multivides straumes, tostarp komunikācijas metožu definīcija un to tiešā pārraide - RTCPeerConnection objekti (audio un video straumju nosūtīšanai un saņemšanai) un RTCDataChannel (datu nosūtīšanai un saņemšanai no pārlūkprogrammas).

Ko mēs darām?

Mēs izdomāsim, kā organizēt vienkāršāko vairāku spēlētāju video tērzēšanu starp pārlūkprogrammām, pamatojoties uz WebRTC, izmantojot tīmekļa ligzdas. Sāksim eksperimentēt ar Chrome/Chromium, kas ir vismodernākās pārlūkprogrammas WebRTC ziņā, lai gan Firefox 22, kas tika izlaista 24. jūnijā, tos gandrīz panāca. Jāsaka, ka standarts vēl nav pieņemts, un API var mainīties no versijas uz versiju. Visi piemēri tika pārbaudīti pārlūkprogrammā Chromium 28. Vienkāršības labad mēs nepārraudzīsim koda tīrību un vairāku pārlūkprogrammu saderību.

mediju plūsma

Pirmais un vienkāršākais WebRTC komponents ir MediaStream. Tas nodrošina pārlūkprogrammai piekļuvi multivides straumēm no lokālā datora kameras un mikrofona. Pārlūkā Chrome tas prasa izsaukt funkciju navigator.webkitGetUserMedia() (tā kā standarts vēl nav pabeigts, visām funkcijām ir prefikss, un pārlūkprogrammā Firefox šī pati funkcija tiek saukta par navigator.mozGetUserMedia()). Kad tas tiek izsaukts, lietotājam tiks piedāvāts atļaut piekļuvi kamerai un mikrofonam. Sarunu varēs turpināt tikai pēc lietotāja piekrišanas. Nepieciešamās multivides straumes un divu atzvanīšanas funkciju parametri tiek nodoti kā parametri šai funkcijai: pirmais tiks izsaukts veiksmīgas piekļuves kamerai/mikrofonam gadījumā, otrais - kļūdas gadījumā. Vispirms izveidosim HTML failu rtctest1.html ar pogu un elementu

getUserMedia

Microsoft CU-RTC-Web

Microsoft nebūtu Microsoft, ja tā nekavējoties neizlaidītu savu nesaderīgo pielāgoto variantu CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm), reaģējot uz Google iniciatīvu. . Lai gan IE daļa, jau tā neliela, turpina samazināties, Skype lietotāju skaits dod Microsoft cerību uzspiest Google, un var pieņemt, ka šis standarts tiks izmantots Skype pārlūkprogrammas versijā. Google standarts galvenokārt koncentrējas uz saziņu starp pārlūkprogrammām; tajā pašā laikā lielākā daļa balss trafika joprojām paliek parastajā telefonu tīklā, un vārtejas starp to un IP tīkliem ir nepieciešamas ne tikai izmantošanas ērtībai vai ātrākai izplatīšanai, bet arī kā monetizācijas līdzeklis, kas ļaus lielākam skaitam spēlētāju attīstīt tos. Cita standarta parādīšanās var radīt ne tikai nepatīkamu vajadzību izstrādātājiem atbalstīt uzreiz divas nesaderīgas tehnoloģijas, bet arī nākotnē sniegt lietotājam plašāku iespējamās funkcionalitātes un pieejamo tehnisko risinājumu izvēli. Gaidi un redzēsi.

Iespējot vietējo pavedienu

Iekšējās atzīmes Mūsu HTML failā deklarēsim globālo mainīgo multivides straumei:

VarlocalStream = null;

Pirmais getUserMedia metodes parametrs ir norādīt pieprasītās multivides straumes parametrus, piemēram, vienkārši iespējojiet audio vai video:

Var streamConstraints = ( "audio": patiess, "video": patiess ); // Pieprasīt piekļuvi gan audio, gan video

Vai arī norādiet papildu opcijas:

Var streamConstraints = ( "audio": patiess, "video": ( "obligāts": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "neobligāts": ) );

Otrais getUserMedia metodes parametrs ir nodot atzvanīšanas funkciju, kas tiks izsaukta, ja tā būs veiksmīga:

Funkcija getUserMedia_success(stream) ( console.log("getUserMedia_success():", straume); localVideo1.src = URL.createObjectURL(stream); // Pievienojiet multivides straumi HTML elementam

Trešais parametrs ir atzvanīšanas funkcija, kļūdu apstrādātājs, kas tiks izsaukts kļūdas gadījumā.

Funkcija getUserMedia_error(error) ( console.log("getUserMedia_error():", kļūda); )

Faktiskais getUserMedia metodes izsaukums — piekļuves pieprasīšana mikrofonam un kamerai, kad tiek nospiesta pirmā poga

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

Nav iespējams piekļūt multivides straumei no lokāli atvērta faila. Ja mēģinām to izdarīt, tiek parādīta kļūda:

NavigatorUserMediaError (kods: 1, PERMISSION_DENIED: 1)"

Augšupielādēsim iegūto failu serverī, atveram to pārlūkprogrammā un, atbildot uz parādīto pieprasījumu, ļausim piekļūt kamerai un mikrofonam.

Varat atlasīt, kurām ierīcēm pārlūks Chrome piekļūs, atverot sadaļu Iestatījumi, Rādīt papildu iestatījumu saiti, sadaļu Privātums, Satura pogu. Pārlūkprogrammās Firefox un Opera ierīces tiek atlasītas nolaižamajā sarakstā tieši pēc piekļuves piešķiršanas.

Izmantojot HTTP protokolu, atļauja tiks pieprasīta katru reizi, kad pēc lapas ielādes piekļūst multivides straumei. Pārslēgšanās uz HTTPS ļaus jums parādīt pieprasījumu vienreiz, tikai pašā pirmajā piekļūšanas reizē multivides straumei.

Pievērsiet uzmanību pulsējošajam aplim cilnes ikonā un kameras ikonai adreses joslas labajā pusē:

RTCMediaConnection

RTCMediaConnection - objekts, kas paredzēts multivides straumju izveidei un pārsūtīšanai tīklā starp dalībniekiem. Turklāt šis objekts ir atbildīgs par multivides sesijas apraksta (SDP) ģenerēšanu, informācijas iegūšanu par ICE kandidātiem NAT vai ugunsmūriem (vietējiem un izmantojot STUN) un mijiedarbību ar TURN serveri. Katram dalībniekam ir jābūt vienam RTCMediaConnection vienam savienojumam. Multivides straumes tiek pārsūtītas, izmantojot šifrētu SRTP protokolu.

TURN serveri

Ir trīs veidu ICE kandidāti: saimniekdators, srflx un relejs. Host satur informāciju, kas iegūta lokāli, srflx ir tas, kā saimniekdators izskatās ārējam serverim (STUN), un relejs ir informācija trafika starpniekserverēšanai caur TURN serveri. Ja mūsu mezgls atrodas aiz NAT, tad resursdatora kandidāti saturēs vietējās adreses un būs bezjēdzīgi, srflx kandidāti palīdzēs tikai ar noteiktiem NAT veidiem un relejs būs pēdējā cerība nodot trafiku caur starpposma serveri.

ICE resursdatora tipa kandidāta piemērs ar adresi 192.168.1.37 un portu udp/34022:

A=kandidāts:337499441 2 udp 2113937151 192.168.1.37 34022 tips resursdatora paaudze 0

Vispārīgs formāts STUN/TURN serveru norādīšanai:

Var serveri = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [aizsargāts ar e-pastu]:port", "credential": "password" ) ]);

Internetā ir daudz publisko STUN serveru. Piemēram, liels saraksts ir . Diemžēl tie atrisina pārāk maz problēmu. Publisku TURN serveru, atšķirībā no STUN, praktiski nav. Tas ir saistīts ar faktu, ka TURN serveris caur sevi izlaiž multivides straumes, kas var ievērojami noslogot gan tīkla kanālu, gan pašu serveri. Tāpēc vienkāršākais veids, kā izveidot savienojumu ar TURN serveriem, ir to instalēt pašam (acīmredzot, jums būs nepieciešams publisks IP). No visiem serveriem, manuprāt, labākais ir rfc5766-turn-server . Zem tā ir pat gatavs Amazon EC2 attēls.

Pagaidām ar TURN ne viss ir tik labi kā gribētos, taču notiek aktīva attīstība, un gribētos cerēt, ka pēc kāda laika WebRTC, ja nepanāks Skype adrešu caurlaides kvalitātes ziņā tulkojums (NAT) un ugunsmūri, tad vismaz manāmi tuvojas.

RTCMediaConnection ir nepieciešams papildu mehānisms kontroles informācijas apmaiņai, lai izveidotu savienojumu - lai gan tas ģenerē šos datus, tas tos nepārraida, un citu dalībnieku pārraide ir jārealizē atsevišķi.

Par pārraides metodes izvēli ir atbildīgs izstrādātājs - vismaz manuāli. Tiklīdz ir veikta nepieciešamo datu apmaiņa, RTCMediaConnection automātiski iestatīs multivides straumes (protams, ja iespējams).

piedāvājuma-atbildes modelis

Lai izveidotu un modificētu multivides straumes, tiek izmantots piedāvājuma / atbildes modelis (piedāvājums / atbilde; aprakstīts RFC3264) un SDP protokols (sesijas apraksta protokols). Tos izmanto arī SIP protokols. Šajā modelī tiek izdalīti divi aģenti: Piedāvātājs - tas, kurš ģenerē SDP sesijas aprakstu, lai izveidotu jaunu vai pārveidotu esošo (Piedāvājums SDP), un Atbildētājs - tas, kurš saņem SDP sesijas aprakstu no cita aģenta un atbild. uz to ar savu sesijas aprakstu (Atbilde SDP). Tajā pašā laikā specifikācijai ir nepieciešams augstāka līmeņa protokols (piemēram, SIP vai savs, izmantojot tīmekļa ligzdas, kā tas ir mūsu gadījumā), kas ir atbildīgs par SDP pārsūtīšanu starp aģentiem.

Kādi dati ir jāpārsūta starp diviem RTCMediaConnections, lai tie varētu veiksmīgi izveidot multivides straumes:

• Pirmā puse, kas uzsāk savienojumu, veido Piedāvājumu, kurā tā nosūta SDP datu struktūru (tas pats protokols tiek izmantots vienam un tam pašam mērķim SIP), aprakstot iespējamās multivides straumes īpašības, kuru tā gatavojas sākt pārraidīt. Šis datu bloks ir jāpārsūta otrajam dalībniekam. Otrais dalībnieks ģenerē Atbildi ar savu SDP un nosūta to pirmajam.
• Gan pirmais, gan otrais dalībnieks veic iespējamo ICE kandidātu noteikšanas procedūru, ar kuras palīdzību otrais dalībnieks var pārsūtīt viņiem mediju straumi. Kad kandidāti ir identificēti, informācija par viņiem ir jānodod citam dalībniekam.

Piedāvājuma veidošana

Lai izveidotu piedāvājumu, mums ir nepieciešamas divas funkcijas. Pirmais tiks izsaukts tā veiksmīgas izveidošanas gadījumā. Otrs metodes createOffer() parametrs ir atzvanīšanas funkcija, kas tiek izsaukta, ja tās izpildes laikā rodas kļūda (ja vietējā straume jau ir pieejama).

Turklāt ir nepieciešami divi notikumu apstrādātāji: onecandidate, kad tiek definēts jauns ICE kandidāts, un onaddstream, kad multivides straume ir pievienota no tālākās puses. Atgriezīsimies pie mūsu lietas. Pievienojiet HTML pēc rindiņām ar elementiem vēl vienu:

izveidot Piedāvājumu

Un pēc līnijas ar elementu

Turklāt JavaScript koda sākumā mēs deklarēsim globālo mainīgo RTCPeerConnection:

varpc1;

Izsaucot RTCPeerConnection konstruktoru, jānorāda STUN/TURN serveri. Plašāku informāciju skatiet sānjoslā; kamēr visi dalībnieki atrodas vienā tīklā, tie nav nepieciešami.

var serveri = null;

SDP nodrošināšanas piedāvājuma iespējas

var offerConstraints = ();

Pirmais metodes createOffer() parametrs ir atzvanīšanas funkcija, kas tiek izsaukta pēc veiksmīgas piedāvājuma izveides

Funkcija pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Iestatiet theConne ģenerēto RTCPeer Piedāvājiet SDP metodi setLocalDescription. // Kad tālākā puse nosūta atbildes SDP, tā būs jāiestata, izmantojot metodi setRemoteDescription // Kamēr otrā puse nav ieviesta, neko nedariet // pc2_receivedOffer(desc); )

Otrais parametrs ir atzvanīšanas funkcija, kas tiks izsaukta kļūdas gadījumā

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

Un mēs paziņosim par atzvanīšanas funkciju, kas tiks nodota ICE kandidātiem, kā tie ir definēti:

Funkcija pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Nedariet neko, kamēr nav ieviesta otrā puse // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Kā arī atzvanīšanas funkcija multivides straumes pievienošanai no tālākās puses (nākotnei, jo līdz šim mums ir tikai viens RTCPeerConnection):

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

Noklikšķinot uz pogas “createOffer”, izveidojiet RTCPeerConnection, iestatiet onicecandidate un onaddstream metodes un pieprasiet Offer SDP izveidi, izsaucot metodi createOffer():

Funkcija createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Izveidojiet RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Atzvanīšanas funkcija ICE kandidātu apstrādei pc1.onaddonad =d straum / Atzvanīšanas funkcija tiek izsaukta, ja ir multivides straume no tālākās puses, tā vēl neeksistē pc1.addStream(localStream); // Nododiet lokālo multivides straumi (pieņemot, ka tā jau ir saņemta) pc1.createOffer(// Un patiesībā pieprasīt Piedāvājuma izveidi pc1_createOffer_success , pc1_createOffer_error, offerConstraints);)

Saglabāsim failu kā rtctest2.html, ievietosim serverī, atveram pārlūkprogrammā un skatīsimies konsolē, kādi dati tiek ģenerēti tā darbības laikā. Otrais video vēl neparādīsies, jo ir tikai viens dalībnieks. Atcerieties, ka SDP ir multivides sesijas parametru apraksts, pieejamie kodeki, multivides straumes un ICE kandidāti ir iespējamās opcijas, lai izveidotu savienojumu ar šo dalībnieku.

Atbildes SDP veidošana un ICE kandidātu apmaiņa

Gan Offer SDP, gan katrs no ICE kandidātiem ir jānodod uz otru pusi, un tur pēc to saņemšanas no RTCPeerConnection izsauc setRemoteDescription metodes Piedāvājuma SDP un addIceCandidate katram no tālākās puses saņemtajam ICE kandidātam; līdzīgi apgrieztā veidā Answer SDP un attāliem ICE kandidātiem. Pats Atbilde SDP tiek veidots līdzīgi kā Piedāvājums; atšķirība ir tāda, ka tiek izsaukta nevis metode createOffer, bet gan createAnswer metode, un pirms šī RTCPeerConnection metodei setRemoteDescription tiek nodots no zvanītāja saņemtais Offer SDP.

Pievienosim HTML vēl vienu video elementu:

Un globālais mainīgais otrajam RTCPeerConnection saskaņā ar pirmā deklarāciju:

Varpc2;

Piedāvājuma un atbildes apstrāde SDP

Atbildes veidošana SDP ir ļoti līdzīga piedāvājumam. Atzvanīšanas funkcijā, kas izsaukta pēc veiksmīgas atbildes veidošanas, līdzīgi kā piedāvājums, mēs sniegsim lokālu aprakstu un nodosim saņemto Atbildes SDP pirmajam dalībniekam:

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

Atzvanīšanas funkcija, kas tiek izsaukta kļūdas gadījumā atbildes ģenerēšanas laikā, ir pilnībā līdzīga Piedāvājumam:

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

Parametri atbildes SDP ģenerēšanai:

Var answerConstraints = ( "obligāti": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

Kad otrais dalībnieks saņem Piedāvājumu, izveido RTCPeerConnection un veido Atbildi tāpat kā Piedāvājums:

Funkcija pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Izveidojiet RTCPeerConnection objektu otrajam dalībniekam, līdzīgi kā pirmajam ICE kandidātam pc2.onaddstream = pc_onaddstream; // Kad parādās straume, pievienojiet to HTML

Lai pārsūtītu Piedāvājuma SDP no pirmā dalībnieka uz otro, kā daļu no mūsu piemēra, atņemiet komentāru funkcijā pc1 izveidot Piedāvājumu veiksme() izsaukuma virkne:

Pc2_receivedOffer(desc);

Lai īstenotu ICE kandidātu apstrādi, pirmā dalībnieka pc1_onicecandidate() ICE kandidātu gatavības notikumu apdarinātājā noņemiet komentārus tā pārsūtīšanai uz otro:

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

Otrā dalībnieka ICE kandidāta gatavības notikumu apstrādātājs ir līdzīgs pirmajam:

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

Atzvanīšanas funkcija multivides straumes pievienošanai no pirmā dalībnieka:

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

Savienojuma pārtraukšana

Pievienosim vēl vienu pogu HTML

piekārt

Un funkcija savienojuma pārtraukšanai

Funkcija btnHangupClick() ( // Atspējot vietējo video no HTML elementiem

Saglabāsim kā rtctest3.html, ievietosim serverī un atveram pārlūkprogrammā. Šajā piemērā tiek īstenota divvirzienu multivides straumēšana starp diviem RTCPeerConnections vienā pārlūkprogrammas cilnē. Lai organizētu Piedāvājuma un atbildes SDP, ICE kandidātu un citas informācijas apmaiņu starp dalībniekiem un citas informācijas apmaiņu caur tīklu, būs nepieciešams īstenot apmaiņu starp dalībniekiem, izmantojot kādu transportu, mūsu gadījumā tīmekļa ligzdas, nevis tiešu zvanu uz procedūras.

Ekrāna apraide

Izmantojot funkciju getUserMedia, varat arī uzņemt ekrānu un straumēt kā MediaStream, norādot šādus parametrus:

Var mediaStreamConstraints = ( audio: false, video: ( obligāti: ( chromeMediaSource: "screen" ), neobligāti: ) );

Lai veiksmīgi piekļūtu ekrānam, ir jāievēro vairāki nosacījumi:

• iespējot ekrānuzņēmuma karogu getUserMedia() chrome://flags/,chrome://flags/;
• avota fails ir jālejupielādē, izmantojot HTTPS (SSL izcelsme);
• audio straumi nedrīkst pieprasīt;
• vienā pārlūkprogrammas cilnē nevajadzētu veikt vairākus pieprasījumus.

WebRTC bibliotēkas

Lai gan WebRTC vēl nav pabeigts, jau ir parādījušās vairākas uz tā balstītas bibliotēkas. JsSIP ir paredzēts, lai izveidotu uz pārlūkprogrammu balstītus programmatūras tālruņus, kas darbojas ar SIP slēdžiem, piemēram, Asterisk un Camalio. PeerJS vienkāršos P2P tīklu izveidi datu apmaiņai, un Holla samazinās izstrādes apjomu, kas nepieciešams P2P saziņai no pārlūkprogrammām.

Node.js un socket.io

Lai organizētu SDP un ICE kandidātu apmaiņu starp diviem RTCPeerConnections tīklā, mēs izmantojam Node.js ar moduli socket.io.

Ir aprakstīta jaunākās stabilās Node.js versijas (Debian/Ubuntu) instalēšana

$ 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

Ir aprakstīta instalēšana citām operētājsistēmām

Pārbaudīsim:

$ echo "sys=require("util"); sys.puts("Pārbaudes ziņojums");" > nodetest1.js $ nodejs nodetest1.js

Izmantojot npm (Node Package Manager), instalējiet socket.io un papildu ekspresmoduli:

$ npm instalējiet socket.io express

Pārbaudīsim to, izveidojot nodetest2.js failu servera pusei:

$ nano nodetest2.js var app = prasīt("express")() , serveris = prasīt("http").createServer(app) , io = prasīt("ligzda.io").klausīt(serveris); serveris.klausies(80); // Ja ports 80 ir bezmaksas app.get("/", funkcija (req, res) ( // Piekļūstot saknes lapai res.sendfile(__dirname + "/nodetest2.html"); // norādiet HTML failu ) ) ; io.sockets.on("savienojums", funkcija (socket) ( // Savienojumā socket.emit("servera notikums", ( sveiki: "world" )); // nosūtīt ziņojumu socket.on("klienta notikums", funkcija (dati) ( // un deklarēt notikumu apdarinātāju, kad pienāk ziņojums no klienta konsoles.log(data); )); ));

Un nodetest2.html klienta pusei:

$nano nodetest2.html

Sāksim serveri:

$ sudo nodejs nodetest2.js

un pārlūkprogrammā atveriet lapu http://localhost:80 (ja lokāli darbojas 80. portā). Ja viss būs veiksmīgs, pārlūkprogrammas JavaScript konsolē mēs redzēsim notikumu apmaiņu starp pārlūkprogrammu un serveri savienojuma laikā.

Informācijas apmaiņa starp RTCPeerConnection, izmantojot tīmekļa ligzdas

Klienta puse

Saglabāsim mūsu galveno piemēru (rtcdemo3.html) ar jauno nosaukumu rtcdemo4.html. Elementā iekļaujiet socket.io bibliotēku:

Un JavaScript skripta sākumā - tīmekļa ligzdas savienojums:

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

Aizstāsim tiešo zvanu uz cita dalībnieka funkcijām, nosūtot viņam ziņojumu caur tīmekļa ligzdām:

Funkcija createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("piedāvājums", desc); ... ) funkcija pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("atbilde", desc); ) funkcija pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) funkcija pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

Funkcijā hangup() tā vietā, lai tieši izsauktu otrā dalībnieka funkcijas, mēs nosūtīsim ziņojumu, izmantojot tīmekļa ligzdas:

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

Un pievienojiet ziņojumu saņemšanas apstrādātājus:

Socket.on("piedāvājums", funkcija (dati) ( console.log("socket.on("piedāvājums"):", dati); pc2_receivedOffer(data); )); socket.on("atbilde", funkcija (dati) (e console.log("socket.on("atbilde"):", dati); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", funkcija (dati) ( console.log("socket.on("ice1"):", dati); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", funkcija (dati) ( console.log("socket.on("ice2"):", dati); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("uzkārt", funkcija (dati) ( console.log("socket.on("hangup")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Servera daļa

Servera pusē saglabājiet failu nodetest2 ar jauno nosaukumu rtctest4.js un io.sockets.on("savienojums", funkcija (socket) (... ) iekšpusē pievienojiet klienta ziņojumu saņemšanu un sūtīšanu:

Socket.on("piedāvājums", funkcija (dati) ( // Saņemot "piedāvājuma" ziņojumu, // tā kā šajā piemērā ir tikai viens klienta savienojums, // nosūtīt ziņojumu atpakaļ caur to pašu ligzdu socket.emit( "piedāvājums" , dati); // Ja būtu nepieciešams pārsūtīt ziņojumu uz visiem savienojumiem // izņemot sūtītāju: // socket.broadcast.emit("piedāvājums", dati); )); socket.on("atbilde", funkcija (dati) ( socket.emit("atbilde", dati); )); socket.on("ice1", funkcija (dati) ( socket.emit("ice1", dati); )); socket.on("ice2", funkcija (dati) ( socket.emit("ice2", dati); )); socket.on("uzkārt", funkcija (dati) ( socket.emit("uzkārt", dati); ));

Turklāt mainiet HTML faila nosaukumu:

// res.sendfile(__dirname + "/nodetest2.html"); // Norādiet HTML failu res.sendfile(__dirname + "/rtctest4.html");

Servera starts:

$ sudo nodejs nodetest2.js

Neskatoties uz to, ka abu klientu kods tiek izpildīts vienā pārlūkprogrammas cilnē, visa mijiedarbība starp dalībniekiem mūsu piemērā tiek pilnībā veikta caur tīklu un vairs nav grūti “izkliedēt” dalībniekus. Tomēr tas, ko mēs darījām, bija arī ļoti vienkārši – šīs tehnoloģijas ir labas to lietošanas vienkāršībai. Lai arī dažreiz maldinoši. Jo īpaši neaizmirsīsim, ka bez STUN/TURN serveriem mūsu piemērs nevarēs darboties adrešu tulkošanas un ugunsmūru klātbūtnē.

Secinājums

Iegūtais piemērs ir ļoti nosacīts, bet, ja mēs nedaudz universalizējam notikumu apdarinātājus, lai tie neatšķirtos starp izsaucošajām un izsauktajām pusēm, divu objektu pc1 un pc2 vietā izveidojiet RTCPeerConnection masīvu un ieviešam dinamisku elementu izveidi un dzēšanu.

Var pieņemt, ka pavisam drīz, pateicoties WebRTC, notiks revolūcija ne tikai mūsu izpratnē par balss un video sakariem, bet arī tajā, kā mēs uztveram internetu kopumā. WebRTC ir pozicionēts ne tikai kā zvana tehnoloģija no pārlūka uz pārlūkprogrammu, bet arī kā reāllaika komunikācijas tehnoloģija. Video komunikācija, kuru mēs analizējām, ir tikai neliela daļa no iespējamām tās izmantošanas iespējām. Jau ir ekrāna koplietošanas (ekrāna koplietošanas) un sadarbības piemēri un pat uz pārlūkprogrammu balstīts P2P satura piegādes tīkls, izmantojot RTCDataChannel.

WebRTC (Web Real Time Communications) ir standarts, kas apraksta straumētu audio datu, video datu un satura pārsūtīšanu no pārlūkprogrammas 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, vienkārši atveriet tīmekļa lapu, lai sāktu saziņu.

Kas ir WebRTC?

Šajā rakstā mēs apskatīsim visu, kas ir jāzina par WebRTC tehnoloģiju vidusmēra lietotājam. Apsvērsim 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 standartu un tehnoloģiju attīstība

Sergejs Jutsaitis, Cisco, Video+konference 2016

Kā darbojas WebRTC

Klienta pusē

• 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 biedru vai par straumi ar konferenci, kas sajaukta serverī, pārlūkprogramma sāk sarunas par izmantotajiem audio un video kodekiem.
• Sākas datu kodēšanas un straumēšanas process starp WebRTC klientiem (mūsu gadījumā starp pārlūkprogrammu un serveri).

WebRTC servera pusē

Video serveris nav nepieciešams datu apmaiņai starp diviem dalībniekiem, bet, ja vēlaties 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.

WebRTC serveris arī saņems multivides trafiku no WebRTC vienaudžiem un nosūtīs to konferences dalībniekiem, izmantojot galddatoru vai mobilās lietojumprogrammas, ja tādas ir.

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 slāpēšana.
  • Automātiska dalībnieku mikrofonu līmeņa kontrole (AGC).
• Augsts drošības līmenis: visi savienojumi ir droši un šifrēti saskaņā ar TLS un SRTP protokoliem.
• Ir iebūvēts mehānisms satura, piemēram, darbvirsmas, tveršanai.
• Spēja ieviest jebkuru vadības interfeisu, kura pamatā ir HTML5 un JavaScript.
• Iespēja integrēt saskarni ar jebkuru aizmugursistēmu, izmantojot WebSockets.
• Atvērtā koda projekts — varat to iegult savā produktā vai pakalpojumā.
• Patiesa starpplatforma: viena un tā pati WebRTC lietojumprogramma darbosies vienlīdz labi jebkurā operētājsistēmā, gan galddatorā, gan mobilajā ierīcē, ja pārlūkprogramma atbalsta WebRTC. Tas ietaupa daudz resursu 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 audio 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 skaņas pārsūtīšanai, atstājot pārdevējam 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.
• Grupas 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 tā infrastruktūrā, kur katrai konferencei nepieciešams 1 moderna procesora fiziskais kodols.

WebRTC noslēpumi: kā pārdevēji gūst labumu no traucējošām tīmekļa tehnoloģijām

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

WebRTC video konferenč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 sakaru kvalitātes ziņā nav zemāks par aparatūras kolēģiem.

Izmanto specializētos risinājumos

Dažādu JavaScript bibliotēku un mākoņpakalpojumu API izmantošana ar WebRTC atbalstu ļauj viegli pievienot video atbalstu jebkuram tīmekļa projektam. Agrāk reāllaika datu pārraidei izstrādātājiem vajadzēja apgūt protokolu darbību un izmantot citu uzņēmumu darbu, kas visbiežāk prasīja papildu licencēšanu, kas palielināja izmaksas. WebRTC jau tiek aktīvi izmantots tādos pakalpojumos kā “Zvans no vietnes”, “Tiešsaistes atbalsta tērzēšana” 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 radīja lielu IT speciālistu satraukumu. WebRTC tehnoloģija nav piesaistīta operētājsistēmai, bet tiek ieviesta pārlūkprogrammas līmenī, t.i. Linux lietotāji uz WebRTC balstītus produktus un pakalpojumus varēs redzēt 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 tālu no labākajiem gadiem. Kopš 2017. gada vadošās pārlūkprogrammas ir oficiāli pārtraukušas atbalstīt Flash, un tehnoloģija beidzot ir pazudusi no tirgus. Bet jums ir jāpiešķir Flash kredīts, jo tieši viņš izveidoja tīmekļa konferenču tirgu un piedāvāja tehniskās iespējas tiešsaistes saziņai pārlūkprogrammās.

WebRTC video prezentācijas

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

Kodeki pakalpojumā WebRTC

Audio kodeki

Lai saspiestu audio trafiku WebRTC, tiek izmantoti Opus un G.711 kodeki.

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 4,2 punktus (no 4 līdz 5 ir visaugstākais un nozīmē labu kvalitāti, kas ir līdzīga balss trafika kvalitātei ISDN un pat augstāka).

Opus ir kodekss ar zemu kodēšanas latentumu (no 2,5 ms līdz 60 ms), mainīga bitu ātruma atbalstu un augstu kompresiju, kas ir ideāli piemērots audio straumēšanai mainīga joslas platuma tīklos. Opus ir hibrīds risinājums, kas apvieno labākās SILK (balss saspiešanas, cilvēka runas traucējumu novēršana) un CELT (audio datu kodēšanas) kodeku īpašības. Kodeks ir brīvi pieejams, izstrādātājiem, kuri to izmanto, nav jāmaksā autortiesību īpašniekiem honorāri. Salīdzinot ar citiem audio kodekiem, Opus noteikti uzvar daudzos veidos. Tas ir aptumšojis 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, 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 tie darbotos ar WebRTC.

VP8 ir bezmaksas video kodeks ar atvērtu licenci, kas nodrošina lielu video straumes dekodēšanas ātrumu un lielāku izturību pret kadru zudumu. Kodeks ir universāls, to ir viegli ieviest aparatūras platformās, tāpēc video konferenču sistēmu izstrādātāji to bieži izmanto savos produktos.

Maksas video kodeks H.264 kļuva pazīstams daudz agrāk nekā viņa brālis. Šis ir kodeks ar augstu video straumes saspiešanas pakāpi, vienlaikus saglabājot augstu video kvalitāti. Šī 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, savukārt 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ņos balstītu WebRTC risinājumu izstrādātājiem, jo, ja visi konferences dalībnieki izmanto vienu pārlūkprogrammu, tad pietiek vienu reizi sajaukt konferenci ar vienu kodeku, un, ja pārlūkprogrammas ir dažādas un starp tām ir ir Safari / Edge, tad konferencei būs jākodē divreiz dažādi kodeki, kas dubultos sistēmas prasības multivides serverim un līdz ar to arī 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 multivides datu “apmaiņai”, 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 izmantotajiem audio un video kodekiem).
• RTC datu 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 šo atļauju. Pārlūkā Google Chrome jūs varat iepriekš konfigurēt piekļuvi sadaļā "Iestatījumi", operētājsistēmā Opera un Firefox ierīču izvēle tiek veikta tieši piekļuves brīdī no nolaižamā saraksta. Atļaujas pieprasījums vienmēr tiks parādīts, kad tiek izmantots HTTP protokols, un vienu reizi, ja izmantojat HTTPS:

RTCPeerConnection. Katrai pārlūkprogrammai, kas piedalās WebRTC konferencē, ir jābūt piekļuvei šim objektam. Pateicoties RTCPeerConnection izmantošanai, multivides dati no vienas pārlūkprogrammas uz otru var pat tikt cauri NAT un ugunsmūriem. 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 mediju straumes īpašībām, ko tas pārraidīs);
• otrais dalībnieks ģenerē “atbildi” - Answer-SDP un nosūta to iniciatoram;
• pēc tam tiek organizēta ICE kandidātu apmaiņa starp dalībniekiem, ja tādi tiek atrasti (ja dalībnieki atrodas aiz NAT vai ugunsmūriem).

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

RTC datu 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 apsvērt tikai gadījumos, kad WebRTC tiek izmantots pārlūkprogrammās Mozilla Firefox 22+ un Google Chrome 26+. Ar to dalībnieki pārlūkprogrammā var apmainīties ar īsziņām.

WebRTC savienojums

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 savā jaunajā Edge pārlūkprogrammā. Puišiem no Redmondas īsti nepatīk nodot tehnoloģijas lietotāju rokās, kuras viņi nekontrolē, tāda ir politika. Bet pamazām lietas nokāpa no zemes, jo. WebRTC vairs nebija iespējams ignorēt, un tika paziņots par ORTC projektu, kas atvasināts no WebRTC standarta.

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 paplašināts ar atbalstu H.264 un dažiem G.7XX sērijas audio kodekiem, ko izmanto telefonijas un aparatūras videokonferenču sistēmās. Varbūt būs iebūvēts atbalsts LAP (satura pārsūtīšanai) un ziņojumapmaiņai. Starp citu, Internet Explorer lietotājiem nav paveicies, ORTC atbalsts būs tikai Edge. Un, protams, šāds protokolu un kodeku komplekts ar mazu asiņu iederas Skype for Business, kas WebRTC atver vēl vairāk biznesa lietojumprogrammu.

WebRTC ir pārlūkprogrammas nodrošināta API, kas ļauj organizēt P2P savienojumu un tieši pārsūtīt datus starp pārlūkprogrammām. Internetā ir diezgan daudz pamācību par to, kā izveidot savu video tērzēšanu, izmantojot WebRTC. Piemēram, šeit ir raksts par Habrē. Tomēr tie visi aprobežojas ar divu klientu savienošanu. Šajā rakstā es mēģināšu runāt par to, kā organizēt savienojumu un ziņojumu apmaiņu starp trim vai vairākiem lietotājiem, izmantojot WebRTC.

RTCPeerConnection saskarne ir vienādranga savienojums starp divām pārlūkprogrammām. Lai savienotu trīs vai vairāk lietotājus, mums būs jāorganizē tīkla tīkls (tīkls, kurā katrs mezgls ir savienots ar visiem pārējiem mezgliem).
Mēs izmantosim šādu shēmu:

1. Atverot lapu, mēs pārbaudām telpas ID klātbūtni atrašanās vieta.hash
2. Ja telpas ID nav norādīts, ģenerējiet jaunu
3. Mēs nosūtām signalizācijas serverim "ziņu, ka vēlamies pievienoties norādītajai telpai
4. Signalizācijas serveris nosūta paziņojumu par jaunu lietotāju citiem klientiem šajā telpā
5. Klienti, kuri jau atrodas istabā, nosūta jaunpienācējam SDP piedāvājumu
6. Jaunpienācējs atsaucas uz piedāvājumu "s

0. Signalizācijas serveris

Kā zināms, lai gan WebRTC nodrošina P2P savienojuma iespēju starp pārlūkprogrammām, tas tomēr prasa papildu transportu pakalpojumu ziņojumu apmaiņai. Šajā piemērā transports ir WebSocket serveris, kas rakstīts Node.JS, izmantojot socket.io:

var socket_io = prasīt("ligzda.io"); module.exports = funkcija (serveris) ( var lietotāji = (); var io = socket_io(serveris); io.on("savienojums", funkcija(ligzda) ( // Vēlaties, lai telpai socket.on() pievienotos jauns lietotājs "room ", function(message) ( var json = JSON. parse(message); // Pievienojiet ligzdu lietotāju sarakstam lietotāji = ligzda; if (socket.room !== undefined) ( // Ja ligzda ir jau kādā telpā atstājiet to socket.leave(socket.room); ) // Ievadiet pieprasīto telpu socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Sūtīt citiem klientiem šajā telpā ir ziņojums par pievienošanos jaunam dalībniekam socket.broadcast.to(socket.room).emit("new", json.id; )); // ar WebRTC saistīts ziņojums (SDP piedāvājums, SDP atbilde vai ICE kandidāts) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined) ( // Ja ziņojumā ir adresāts un šis serverim zināms adresāts, nosūtiet ziņojumu tikai viņam... users.emit("webrtc", ziņa); ) else ( // ...citādi uzskatīt ziņojumu par apraides socket.broadcast.to(socket.room).emit("webrtc", ziņojums); ) ); // Kāds atvienojis socket.on("disconnect", function() ( // Kad klients atvienojas, paziņojiet citiem socket.broadcast.to(socket.room).emit("leave", socket.user_id); dzēst lietotājus; )); )); );

1. index.html

Pašas lapas avota kods ir diezgan vienkāršs. Es apzināti nepievērsu uzmanību izkārtojumam un citām skaistām lietām, jo ​​šis raksts nav par to. Ja kāds vēlas viņu padarīt skaistu, tas nebūs grūti.

2.main.js

2.0. Saišu iegūšana uz lapas elementiem un WebRTC saskarnēm

var chatlog = document.getElementById("čatlog"); var ziņojums = document.getElementById("ziņa"); var savienojuma_numurs = document.getElementById("savienojuma_numurs"); var room_link = document.getElementById("istabas_saite");

Mums joprojām ir jāizmanto pārlūkprogrammas prefiksi, lai piekļūtu WebRTC saskarnēm.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || logs.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || logs.RTCIceCandidate;

2.1. Telpas ID noteikšana

Šeit mums ir nepieciešama funkcija, lai ģenerētu unikālu telpu un lietotāja ID. Šim nolūkam mēs izmantosim UUID.

Funkcija uuid () ( var s4 = funkcija() (atgriezt Math.floor(Math.random() * 0x10000).toString(16); ); return s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Tagad mēģināsim izvilkt telpas ID no adreses. Ja tas nav iestatīts, mēs ģenerēsim jaunu. Mēs lapā parādīsim saiti uz pašreizējo telpu un tajā pašā laikā ģenerēsim pašreizējā lietotāja identifikatoru.

VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Saite uz telpu"; var ME = uuid();

2.2. tīmekļa ligzda

Tūlīt pēc lapas atvēršanas mēs pieslēgsimies mūsu signalizācijas serverim, nosūtīsim pieprasījumu iekļūt telpā un norādīsim ziņojumu apstrādātājus.

// Mēs norādām, ka, kad ziņojums ir aizvērts, mums ir jānosūta paziņojums serverim par šo var socket = io.connect("", ("sync disconnect on unload": true)); socket.on("webrtc", socketReceived); socket.on("jauns", socketNewPeer); // Nekavējoties nosūtiet pieprasījumu iekļūt telpā socket.emit("istaba", JSON.stringify((id: ME, room: ROOM))); // Palīdzības funkcija adreses ziņojumu nosūtīšanai saistībā ar WebRTC funkciju sendViaSocket(tips, ziņojums, uz) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message )) ));)

2.3. Vienādranga savienojuma iestatījumi

Lielākā daļa interneta pakalpojumu sniedzēju nodrošina interneta savienojumu, izmantojot NAT. Šī iemesla dēļ tieša saikne kļūst ne tik triviāla. Veidojot savienojumu, mums ir jānorāda STUN un TURN serveru saraksts, kurus pārlūkprogramma mēģinās izmantot, lai apietu NAT. Mēs arī norādīsim pāris papildu savienojuma iespējas.

Var serveris = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", akreditācijas dati: "jūsu parole nonāk šeit", lietotājvārds: " [aizsargāts ar e-pastu]") ] ); var opcijas = ( pēc izvēles: [ (DtlsSrtpKeyAgreement: true), // nepieciešams savienojumam starp Chrome un Firefox (RtpDataChannels: true) // nepieciešams pārlūkprogrammā Firefox, lai izmantotu DataChannels API ] )

2.4. Jauna lietotāja pievienošana

Kad telpai tiek pievienots jauns līdzinieks, serveris nosūta mums ziņojumu jauns. Saskaņā ar iepriekš minētajiem ziņojumu apstrādātājiem funkcija tiks izsaukta ligzdaNewPeer.

var peers = (); funkcija socketNewPeer(data) ( peers = (candidateCache: ); // Izveidojiet jaunu savienojumu var pc = new PeerConnection(serveris, opcijas); // Inicializējiet to initConnection(pc, data, "offer"); // Saglabājiet vienādrangu sarakstā peers peers.connection = pc; // Izveidojiet DataChannel, caur kuru tiks apmaiņa ar ziņojumiem var channel = pc.createDataChannel("mans kanāls", ()); channel.owner = dati; peers.channel = kanāls; // Iestatīt notikumu apdarinātājus bindEvents(channel); // Izveidot SDP piedāvājumu pc.createOffer(function(offer) ( pc.setLocalDescription(offer); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = function ( notikums) ( if (event.candidate) ( // Kad tiek atrasts jauns ICE kandidāts, pievienojiet to sarakstam tālākai sūtīšanai peers.candidateCache.push(event.candidate); ) else ( // Kad kandidātu atklāšana ir pabeigts, apstrādātājs tiks izsaukts vēlreiz, bet bez kandidāta // Šajā gadījumā mēs vispirms nosūtām līdziniekam SDP piedāvājumu vai SDP atbilde (atkarībā no funkcijas parametra)... sendViaSocket(sdpType, pc.localDescription, id); // ...un pēc tam visi iepriekš atrastie ICE kandidāti (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. SDP piedāvājums, SDP atbilde, ICE kandidāts

Kad tiek saņemts kāds no šiem ziņojumiem, mēs izsaucam attiecīgo ziņojumu apstrādātāju.

Funkcija socketReceived(data) ( var json = JSON.parse(data); slēdzis (json.type) ( case "candidate": remoteCandidateReceived(json.id, json.data); break; case "offer": remoteOfferReceived(json. id, json.data); pārtraukums; reģistrs "atbilde": remoteAnswerReceived(json.id, json.data); pārtraukums; ) )

2.5.0 SDP piedāvājums

funkcija remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(atbilde) ( pc.setLocalDescription(atbilde); )); ) funkcija createConnection(id) ( if (peers === undefined) ( peers = (candidateCache: ); var pc = new PeerConnection(serveris, opcijas); initConnection(pc, id, "atbilde"); peers.connection = pc ; pc.ondatachannel = funkcija(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) )

2.5.1 SDP atbilde

funkcija remoteAnswerReceived(id, dati) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); )

2.5.2. ICE kandidāts

funkcija remoteCandidateReceived(id, dati) ( CreateConnection(id); var pc = peers.connection; pc.addIceCandidate(new IceCandidate(data)); )

2.6. Nosūtot ziņojumu

Nospiežot pogu nosūtīt tiek izsaukta funkcija sūtīt ziņu. Viss, ko tas dara, ir iziet cauri vienaudžu sarakstam un mēģināt nosūtīt norādīto ziņojumu visiem.