WebRTC. Videokonference pārlūkprogrammā. Vairāku lietotāju tērzēšana, izmantojot WebRTC Webrtc balss tērzēšanu

Preambula. P2P video tērzēšana ieslēgta WebRTC bāze ir alternatīva Skype un citiem saziņas līdzekļiem. Uz WebRTC balstītas p2p video tērzēšanas galvenie elementi ir pārlūkprogramma un kontaktu serveris. P2P video tērzēšana ir vienādranga video tērzēšana, kurā serveris nepiedalās informācijas plūsmu pārraidē. Informācija tiek pārsūtīta tieši starp lietotāju pārlūkprogrammām (vienaudžiem) bez jebkādas papildu programmas. Papildus pārlūkprogrammām p2p video tērzēšanā tiek izmantoti kontaktu serveri, kas paredzēti lietotāju reģistrēšanai, datu glabāšanai par tiem un lietotāju pārslēgšanās nodrošināšanai. Pārlūkprogrammas, kas atbalsta jaunākās WebRTC un HTML5 tehnoloģijas, nodrošina tūlītēju īsziņu un failu pārsūtīšanu, kā arī balss un video saziņu, izmantojot IP tīklus.

Tātad tērzēšana, tīmekļa tērzēšana, balss un video tērzēšana tīmekļa saskarnē, IMS, VoIP ir pakalpojumi, kas nodrošina tiešsaistes saziņu, izmantojot saliktos pakešu komutācijas tīklus. Parasti sakaru pakalpojumiem lietotāja ierīcēs (personālajos datoros, viedtālruņos utt.) ir jāinstalē klienta lietojumprogrammas vai pārlūkprogrammās jāinstalē spraudņi un paplašinājumi. Pakalpojumiem ir savi sakaru tīkli, no kuriem lielākā daļa ir veidota uz klienta-servera arhitektūras.

Sakaru pakalpojumi ir lietojumprogrammas, kas nav IMS un kurās nav integrēti balss, video, datu un teksta kanāli. Katra pakalpojuma tīklos . Jāpiebilst, ka šīs aplikācijas nevar vienlaicīgi darboties vairākos sakaru tīklos, t.i. Lietojumprogrammas parasti nevar sazināties viena ar otru, tāpēc katram sakaru tīklam ir jāinstalē atsevišķa lietojumprogramma.

Reāllaika sakaru pakalpojumu (čata, telefonijas, videokonferences) integrēšanas problēma, t.i. balss, video, datu kanālu integrāciju un piekļuvi tiem, izmantojot vienu aplikāciju (pārlūku), var atrisināt peer-to-peer vai p2p video čatos (peer-to-peer, point-to-point), pamatojoties uz WebRTC protokolu. Būtībā pārlūkprogramma, kas atbalsta WebRTC, kļūst par vienotu interfeisu visām lietotāja ierīcēm (personālajiem datoriem, viedtālruņiem, iPad, IP tālruņiem, Mobilie tālruņi utt.), kas darbojas ar sakaru pakalpojumiem.

Tas ir WebRTC, kas nodrošina visu to tehnoloģiju ieviešanu pārlūkprogrammā, kas nodrošina reāllaika saziņu. P2p video tērzēšanas būtība ir tāda, ka multivides un teksta dati tiek pārsūtīti tieši starp lietotāju pārlūkprogrammām (attālā peering) bez servera vai papildu programmu līdzdalības. Tādējādi pārlūkprogrammas ne tikai nodrošina piekļuvi gandrīz visiem informācijas resursi Internets, kas tiek glabāts serveros, bet arī kļūst par piekļuves līdzekli visiem reāllaika sakaru pakalpojumiem un pasta pakalpojumiem (balss pasts, e-pasts, SMS utt.)

P2p video tērzēšanas serveri (kontaktu serveri) ir paredzēti tikai lietotāju reģistrēšanai, datu glabāšanai par lietotājiem un savienojuma izveidei (pārslēgšanai) starp lietotāju pārlūkprogrammām. Pirmie p2p video tērzēšana tika ieviesta, izmantojot zibatmiņas tehnoloģijas. Flash p2p video tērzēšana tiek izmantota, piemēram, iekšā sociālajos tīklos. Flash p2p video tērzēšana nenodrošina augstas kvalitātes multivides datu pārraide. Turklāt, lai p2p zibatmiņas video tērzēšanā izvadītu balss un video straumi no mikrofona un videokameras, ir jāinstalē flash spraudnis tīmekļa pārlūkprogrammā.

Taču jaunās paaudzes telekomunikāciju pakalpojumi ietver tīmekļa saziņu, kas izmanto tikai pārlūkprogrammas un kontaktu serverus, kas atbalsta WebRTC protokolus un HTML5 specifikāciju, lai sazinātos internetā. Jebkura lietotāja ierīce (personālais dators, iPad, viedtālruņi u.c.), kas aprīkota ar šādu pārlūkprogrammu, var nodrošināt augstas kvalitātes balss un video zvanus, kā arī tūlītēju īsziņu un failu pārsūtīšanu.

Tātad, jaunā tīmekļa saziņas tehnoloģija (p2p tērzēšana, video tērzēšana) ir WebRTC protokols. WebRTC kopā ar HTML5, CSS3 un JavaScript ļauj izveidot dažādas tīmekļa lietojumprogrammas. WebRT ir paredzēts, lai organizētu tīmekļa saziņu (vienādranga tīklus) reāllaikā, izmantojot vienādranga arhitektūru. P2P tērzēšana, kuras pamatā ir WebRTC, nodrošina failu pārsūtīšanu, kā arī teksta, balss un video saziņu starp lietotājiem internetā, izmantojot tikai tīmekļa pārlūkprogrammas, pārlūkprogrammā neizmantojot ārējus papildinājumus un spraudņus.

P2p tērzēšanā serveris tiek izmantots tikai, lai izveidotu p2p savienojumu starp divām pārlūkprogrammām. Lai izveidotu p2p tērzēšanas klienta daļu, pamatojoties uz WebRTC protokolu, tiek izmantots HTML5, CSS3 un JavaScript. Klienta lietojumprogramma mijiedarbojas ar pārlūkprogrammām, izmantojot WebRTC API.

WebRTC ievieš trīs JavaScript API:

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

Pārlūkprogrammas pārsūta multivides datus, izmantojot SRTP protokolu, kas darbojas virs UDP. Tā kā NAT rada problēmas pārlūkprogrammām (klientiem) aiz NAT maršrutētājiem, kas izmanto p2p savienojumus internetā, STUN izmanto, lai apietu NAT tulkotājus. STUN ir klienta-servera protokols, kas darbojas papildus UDP transporta protokolam. P2p tērzēšanā parasti tiek izmantots publisks STUN serveris, un no tā saņemtā informācija tiek izmantota UDP savienojumam starp divām pārlūkprogrammām, ja tās atrodas aiz NAT.

WebRTC lietojumprogrammu ieviešanas piemēri (p2p tērzēšana, balss un video tīmekļa tērzēšana):
1. P2P video tērzēšana Bistri (viena klikšķa video tērzēšana, p2p tērzēšana), pamatojoties uz WebRTC, var atvērt Bistri. Bistri darbojas pārlūkprogrammā, neinstalējot papildu programmas un spraudņus. Darba būtība ir šāda: atveriet p2p video tērzēšanu, izmantojot norādīto saiti, pēc reģistrēšanās saskarnē, kas atveras, uzaiciniet partnerus, pēc tam no vienaudžu klientu saraksta atlasiet partneri, kurš ir tiešsaistē un noklikšķiniet uz “videozvans ” pogu.

Rezultātā MediaStream (getUserMedia) uzņems mikrofonu + tīmekļa kameru, un serveris apmainīsies ar signalizācijas ziņojumiem ar izvēlēto partneri. Pēc signalizācijas ziņojumu apmaiņas PeerConnection API izveido kanālus balss un video straumju pārsūtīšanai. Turklāt Bistri pārsūta tūlītējās īsziņas un failus. Attēlā 1 parāda Bistri p2p video tērzēšanas saskarnes ekrānuzņēmumu.

Rīsi. 1. P2P video tērzēšana Bistri

2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) - šī klienta aplikācija ir veidota uz HTML5 un WebRTC bāzes, kas ļauj veikt balss un video zvanus, kā arī nosūtīt tūlītējas īsziņas, t.i. Twelephone ietver testa p2p tērzēšanu, video tērzēšanu un SIP Twelephone. Jāatzīmē, ka Twelephone atbalsta SIP protokolu, un tagad jūs varat veikt un saņemt balss un video zvanus no SIP tālruņiem, izmantojot savu Twitter kontu kā tālruņa numuru. Turklāt, isziņas var ievadīt ar balsi caur mikrofonu, un balss atpazīšanas programma ievada tekstu rindā “Sūtīt ziņu”.

Twelephone ir uz pārlūkprogrammu balstīta tīmekļa telefonija Google Chrome, sākot no versijas 25, bez papildu programmatūra. Twelephone izstrādāja Kriss Matjē. Twelephone aizmugursistēma ir veidota uz Node.js. Serveris (kontaktu serveris) tiek izmantots tikai, lai izveidotu p2p savienojumu starp divām pārlūkprogrammām vai WebRTC klientiem. Lietojumprogrammai Twelephone nav savu autorizācijas rīku, bet tā ir vērsta uz savienojuma izveidi ar kontu ( konts) vietnē Twitter.

Attēlā 2 ir parādīts Twelephone p2p video tērzēšanas interfeisa ekrānuzņēmums.

Rīsi. 2. P2P Twelephone

3. Grupas p2p video tērzēšana Conversat.io ir veidota, izmantojot jaunākās WebRTC un HTML5 tehnoloģijas. Conversat video tērzēšana ir izstrādāta, pamatojoties uz SimpleWebRTC bibliotēku, un ir paredzēta saziņai starp līdz 6 vienādranga klientiem vienā telpā (saziņai rindā "Nosaukt sarunu" norādiet kopīgās telpas nosaukumu vienādranga klientiem). P2P video tērzēšana Conversat nodrošina saziņas pakalpojumus lietotājiem, nereģistrējoties kontaktu serverī. Attēlā 3. attēlā parādīts Conversat p2p video tērzēšanas interfeisa ekrānuzņēmums.

Rīsi. 3. Grupas P2P video tērzēšana Conversat.io

Lai piedalītos P2P video tērzēšanā, kuras pamatā ir WebRTC, lietotājiem ir jābūt instalētai pārlūkprogrammai, kas atbalsta WebRTC protokolu un HTML5 specifikāciju. Pašlaik Google Chrome pārlūkprogrammas, sākot ar versiju 25 un Mozilla Firefox Nightly atbalsta WebRTC protokolu un HTML5 specifikāciju. WebRTC lietojumprogrammas attēla un skaņas pārraides kvalitātes ziņā ir pārākas par Flash lietojumprogrammām.

Lielākā daļa WebRTC materiālu ir vērsta uz kodēšanas lietojumprogrammas līmeni un neveicina izpratni par tehnoloģiju. Mēģināsim iedziļināties un noskaidrot, kā notiek savienojums, kas ir sesijas deskriptors un kandidāti, kāpēc nepieciešami STUN un TURN serveri.

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 ir pārlūkprogrammu iekšējais atbalsts (nav nepieciešamas trešo pušu ieviestās tehnoloģijas, piemēram, Adobe Flash) un iespēja savienot klientus, neizmantojot papildu serverus - peer-to-peer savienojums (turpmāk, p2p).

P2p savienojuma izveide ir diezgan sarežģīts uzdevums, jo datoriem ne vienmēr ir publiskas IP adreses, tas ir, adreses internetā. Nelielā IPv4 adrešu skaita dēļ (un drošības nolūkos) tika izstrādāts NAT mehānisms, kas ļauj izveidot privātus tīklus, piemēram, mājas lietošanai. 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 nodrošina vienu IP adresi. Publiskās IP adreses internetā ir unikālas, bet privātās ne. Tāpēc p2p savienošana ir sarežģīta.

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ātajā, otrs publiski) (2. attēls) un abi mezgli atrodas dažādos privātos tīklos ar tās pašas 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 = vienādranga, 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 adresēm, un tāpēc tie var tieši savienoties viens ar otru. 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 divas 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šienē un tāpēc ir redzami citiem zem maršrutētāja IP adreses - tas ir viņu ārējā IP adrese. Tātad mezglam p1 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. Situācija ir līdzīga mezglam p2. Tāpēc viņu komunikācija nav iespējama, ja tiek izmantotas tikai viņu iekšējās (pašu) 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. Šo problēmu var atrisināt, izmantojot NAT mehānismu

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 ICE protokolu, kas tomēr prasa papildu serveru izmantošanu (STUN, TURN). Vairāk par to visu zemāk.

Divas WebRTC fāzes

Lai savienotu divus mezglus, izmantojot WebRTC protokolu (vai vienkārši RTC, ja sazinās divi iPhone), 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 WebRTC tehnoloģija izmanto daudzus dažādos veidos komunikācijas (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 divu p2p mezglu savienošana nav tik vienkārša. 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, HTTP protokols, tas pat varētu būt SMTP protokols 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 formā un ir sadalīti divos veidos - SDP un Ice Candidate. Pirmais veids tiek izmantots loģiska savienojuma izveidošanai, bet otrais - fiziskajam savienojumam. Vairāk par to visu vēlāk, taču pagaidām ir svarīgi atcerēties, ka WebRTC sniegs mums 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):
• Piedāvājums sākt video datu pārsūtīšanu (createOffer)
• SDP SDP iegūšana)
• Ledus kandidāta saņemšana Ledus kandidāts)
• Zvanu gaidīšana (zvanīts):
• Vietējās (jūsu) multivides straumes saņemšana un iestatīšana pārraidei (getUserMediaStream)
• Piedāvājuma saņemšana sākt video datu pārsūtīšanu un atbildes izveide (createAnswer)
• Saņem tā SDP objektu un nodod to caur signalizācijas mehānismu (SDP)
• Jūsu Ledus kandidātu objektu saņemšana un izvadīšana caur signalizācijas mehānismu (Ice kandidāt)
• 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 šķietamo darbību 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.

Mentāli posmam createOffer vai createAnswer jābūt savienotam ar SDP un Ice kandidātobjektu nodošanas posmiem.

Pamatentītijas Multivides straumes (MediaStream)

Galvenā būtī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. Vietnē WebRTC ir MediaStream interfeiss straumēm, un ir arī LocalMediaStream apakšinterfeiss, kas īpaši paredzēts vietējai straumei. JavaScript jūs varat saskarties tikai ar pirmo, bet, ja izmantojat libjingle, varat saskarties arī ar otro.

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 multivides 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 - viens mums un otrs 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 ir ņemts vērā tehnoloģijā, un tāpēc katrs datu veids tiek ieviests, izmantojot MediaTrack multivides celiņu. Multivides ierakstam ir īpašs rekvizītu veids , kas nosaka, vai tas ir 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 etiķetes rekvizīts - 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āatspējo, varat izmantot multivides celiņa iespējoto rekvizītu.

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 MediaChannels. 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 to dara automātiski un izveido īpašs objekts– SDP sesijas deskriptors. 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 ligzdām, vai persona (pastāstiet citam mezglam pa tālruni), vai arī Krievijas pasts. Viss ir ļoti vienkārši - jums iedos gatavu SDP un jums tas ir jānosūta. Un, kad tas ir saņemts otrā pusē, pārsūtiet to uz WebRTC nodaļu. 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, veidojot savienojumu, ir jānorāda kāda veida adrese, piemēram, 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, ka vēlamies izveidot p2p savienojumu, mums ir jāizsauc funkcija createOffer. Pēc šīs funkcijas izsaukšanas un īpašas atzvanīšanas 'a' norādīšanas tiks izveidots SDP objekts un nosūtīts uz to pašu atzvanīšanu. 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 objektu. Š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. Arī vietējās sesijas deskriptors tiks nosūtīts jūsu atzvanīšanai, un tas būs jānosūta atpakaļ, izmantojot signalizācijas mehānismu.

Ir vērts atzīmēt, ka funkciju createAnswer var izsaukt tikai pēc kāda cita SDP objekta saņemšanas. Kāpēc? Tā kā vietējam SDP objektam, kas tiks ģenerēts, izsaucot createAnswer, ir jāpaļaujas uz attālo SDP objektu. 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 lokālās multivides straumes saņemšanas – tiem nebūs ko rakstīt SDP objektam.

Tā kā WebRTC ir iespēja rediģēt SDP objektu, pēc vietējā deskriptora saņemšanas tas ir jāinstalē. Var šķist nedaudz dīvaini, ka mums ir jāpārsūta WebRTC tas, ko tas mums deva, taču 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, bet mezgls 2 atbalsta kodekus B un C, tad, tā kā katrs mezgls zina savus un otra deskriptorus, abi mezgli izvēlēsies B kodeku (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

WebRTC tehnoloģija mēģina mūs sajaukt ar savu jauno metodoloģiju. 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 izveidot savienojumu ar otru, izmantojot savas iekšējās IP adreses (vai varbūt dažas citas, ja netiek izmantots TCP/IP).

Izmantojot dažus atzvanīšanas pakalpojumus, WebRTC informē mūs par ledus kandidātu objektiem. 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. WebRTC jums 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 WebRTC implementācijās 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 adreses, bet arī pēc maršrutētāja ārējās adreses un ne vienmēr tikai vienas, kā arī pēc TURN serveru adresēm. 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žādus portus. Šī ir informācija, kas ir ietverta kandidātobjektā - IP, PORT, TRANSPORT un daži citi. Ļaujiet, piemēram, izmantot UDP transportu un portu 531.

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

Tad, ja esam mezglā p1, tad WebRTC mums iedos šādu kandidātobjektu - . Tas nav precīzs formāts, tikai diagramma. Ja mēs atrodamies mezglā p2, tad kandidāts ir . Izmantojot signalizācijas mehānismu, p1 saņems p2 kandidātu (tas ir, mezgla p2 atrašanās vietu, proti, tā IP un PORT). Tad p1 var tieši savienoties ar p2. Pareizāk, p1 nosūtīs datus uz 10.50.150.3:531, cerot, ka tie sasniegs p2. Nav svarīgi, vai šī adrese pieder mezglam p2 vai kādam starpniekam. Vienīgais svarīgais ir 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 NAT tabulu. Š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 ir mezgls p2. Node p1 (tīmekļa klients) nosūta pieprasījumu uz adresi 10.50.200.10. Pirmkārt, dati tiek novirzīti uz maršrutētāju r1 vai drīzāk uz to interjers saskarne 192.168.0.1. Pēc tam maršrutētājs atceras avota adresi (adresi p1) un ievada to īpašā NAT tabulā, pēc tam maina avota adresi uz savu (p1 → r1). Tālāk, savā veidā ārējā interfeisu, maršrutētājs nosūta datus tieši uz p2 tīmekļa serveri. Tīmekļa serveris apstrādā datus, ģenerē atbildi un nosūta to atpakaļ. Nosūta r1 maršrutētājam, jo ​​tas atrodas atgriešanas adresē (maršrutētājs aizstāja adresi ar savu). Maršrutētājs saņem datus, apskata NAT tabulu un pārsūta datus uz mezglu p1. Šeit maršrutētājs 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 WebRTC tehnoloģijas, precīzāk, pie tās daļas, kas izmanto ICE protokolu (tātad Ice kandidāti). Mezglam p2 ir viens kandidāts (tā atrašanās vieta tīklā ir 10.50.200.10), un mezglam 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, taču tas tiek ģenerēts, jo WebRTC vēl neko nezina par attālo mezglu - tas var būt vai nebūt vienā tīklā. Otrais kandidāts noderēs, un kā jau zinām, ostai (lai tiktu cauri NAT) būs liela nozīme.

Ieraksts NAT tabulā tiek ģenerēts tikai tad, kad dati iziet no iekšējā tīkla. Tāpēc mezglam p1 vispirms ir jāpārraida dati un tikai pēc tam dati no mezgla p2 var sasniegt mezglu p1.

Par praksi abi mezgli būs aiz NAT. Lai izveidotu ierakstu katra maršrutētāja NAT tabulā, saimniekiem kaut kas ir jānosūta attālajam saimniekdatoram, taču šoreiz ne pirmais nevar sasniegt otro, ne otrādi. Tas ir saistīts ar faktu, ka mezgli nezina savas ārējās IP adreses, un datu sūtīšana uz iekšējām adresēm ir bezjēdzīga.

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ā NAT tabula joprojām ir tukša. Tomēr pirmā mezgla maršrutētājā NAT tabulā parādījās nepieciešamais 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 arī otrā maršrutētāja NAT tabulā ir nepieciešamie dati.

Problēma ir tāda, ka, lai uzzinātu savu ārējo IP adresi, 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 NAT tabulā tiek izveidoti arī vērtīgi ieraksti.

STUN un TURN serveri

Inicializējot WebRTC, jānorāda pieejamie STUN un TURN serveri, kurus turpmāk sauksim par ICE serveriem. Ja serveri nav norādīti, tad izveidot savienojumu varēs tikai mezgli tajā pašā tīklā (pieslēgti tam bez NAT). Tūlīt ir vērts atzīmēt, ka 3G tīkliem TURN serveru izmantošana ir obligāta.

Apdullināt serveris ir vienkārši serveris internetā, kas atgriež atgriešanas adresi, tas ir, sūtītāja mezgla adresi. Resursdators aiz maršrutētāja sazinās ar STUN serveri, lai šķērsotu NAT. Paketē, kas nonāca STUN serverī, ir avota adrese - maršrutētāja adrese, tas ir, mūsu mezgla ārējā adrese. Šī ir adrese STUN, ko serveris nosūta atpakaļ. Tādējādi mezgls saņem savu ārējo IP adresi un portu, caur kuru tam var piekļūt no tīkla. Tālāk WebRTC izmanto šo adresi, lai izveidotu papildu kandidātu (ārējā maršrutētāja adrese un ports). Tagad maršrutētāja NAT tabulā ir ieraksts, kas ļauj paketēm, kas nosūtītas maršrutētājam vajadzīgajā portā, sasniegt mūsu mezglu.

Apskatīsim šo procesu ar piemēru.

Piemērs (STUN servera darbība)

STUN serveris tiks apzīmēts ar s1. Maršrutētājs, tāpat kā iepriekš, ir caur r1, un mezgls ir caur p1. Jums būs arī jāuzrauga NAT tabula — mēs to apzīmēsim 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ša tabula r1_nat.

2. tabula. Pakešu galvene

Mezgls p1 nosūta šo paketi maršrutētājam r1 (neatkarīgi no tā, kā to var izmantot dažādi apakštīkli 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 šāda diapazona tiek rezervētas, un nevienai adresei internetā nav šādas adreses. Maršrutētājs veic aizstāšanu paketē un izveido jauns ieraksts savā tabulā r1_nat. Lai to izdarītu, viņam ir jāizdomā porta numurs. Atgādiniet, ka, tā kā vairāki resursdatori apakštīklā var piekļūt ārējam tīklam, NAT tabula 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 apakštīkla IP 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. Ārējā tīkla IP adrese ir maršrutētāja adrese, un ports ir mainīts uz maršrutētāja izgudroto.

Patiesais ports, kurā mezgls p1 pieņem savienojumu, protams, ir 35777, bet serveris sūta datus uz fiktīvs ports 888, kuru maršrutētājs nomainīs uz īsto 35777.

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

Src IP Src PORT Dest IP Dest PORT

10.50.200.5	888	12.62.100.200	6000

5. tabula. STUN serveris saņēma paketi

Kopumā STUN 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 ir kaut kā aprakstīts STUN protokolā. Tagad papildus nosaukumam mēs apsvērsim saturu. Tas būs vienkāršs un saturēs 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 parasti nerūp informācija par mezglu adresēm, ir svarīgi tikai, lai paketes tiktu piegādātas paredzētajam mērķim. Š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 r1 ārējo interfeisu. Maršrutētājs saprot, ka pakete tam nav paredzēta. Kā viņš to saprot? To var noteikt tikai osta. Viņš neizmanto portu 888 saviem personiskajiem mērķiem, bet izmanto to NAT mehānismam. Tāpēc maršrutētājs aplūko šo tabulu. Apskata kolonnu Ārējais PORT un meklē rindu, kas atbilst ienākošās paketes galamērķim, 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, šā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 maršrutētājs pirmajam mezglam izdomāja 888. portu, tad otrajam tas izdomāja 889. portu. Pieņemsim, ka tas notika, tas ir, r1_nat tabula izskatās šādi:

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

Src IP Src PORT Dest IP Dest PORT

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 savu ārējo IP adresi, tas ir, maršrutētāja adresi ārējā tīklā. Viņš arī zina portu, kuru maršrutētājs iet caur NAT.

Ko tālāk? Kāds no tā visa labums? Ieguvums ir ieraksts r1_nat tabulā. Ja tagad kāds sūta paketi ar portu 888 uz router r1, tad maršrutētājs šo paketi pārsūtīs uz mezglu p1. Tas izveidoja nelielu šauru eju uz slēpto mezglu p1.

No iepriekš minētā piemēra varat iegūt priekšstatu par NAT darbību un STUN servera būtību. Kopumā ICE mehānisms un STUN/TURN serveri ir precīzi vērsti uz NAT ierobežojumu pārvarēšanu.

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ūsim ar STUN serveri savienotā maršrutētāja adresi. P2p komunikācijai tas ir tieši tas, kas mums vajadzīgs, ja neaizmirstam faktu, ka katrs maršrutētājs pievienos mums nepieciešamo rindiņu NAT tabulai. Tāpēc arī atpakaļceļš atkal būs tikpat gluds.

TURN serveris ir uzlabots STUN serveris. No šejienes uzreiz jāatņem, ka jebkurš TURN serveris var darboties arī kā STUN serveris. Tomēr ir arī priekšrocības. Ja p2p komunikācija nav iespējama (kā, piemēram, 3g tīklos), tad serveris pārslēdzas uz releja režīmu, tas ir, darbojas kā starpnieks. Protams, mēs nerunājam par kaut kādu p2p, bet ārpus ICE mehānisma mezgli domā, ka viņi sazinās tieši.

Kādos gadījumos ir nepieciešams TURN serveris? Kāpēc nav pietiekami daudz STUN servera? Fakts ir tāds, ka ir vairāki NAT veidi. Tie aizstāj IP adresi un portu tādā pašā veidā, taču dažos no tiem ir iebūvēta papildu aizsardzība pret “viltošanu”. Piemēram, iekšā simetrisks NAT tabulā tiek saglabāti vēl 2 parametri - IP un attālā mezgla ports. Pakete no ārējā tīkla caur NAT tiek pārsūtīta uz iekšējo tīklu tikai tad, ja avota adrese un ports atbilst tabulā ierakstītajiem. Tāpēc triks ar STUN serveri neizdodas - NAT tabula saglabā STUN servera adresi un portu un, kad maršrutētājs saņem paketi no WebRTC sarunu biedra, tas to izmet, jo tā ir “falsificēta”. Tas nenāca no STUN servera.

Tādējādi TURN serveris ir nepieciešams gadījumā, ja abi sarunu biedri ir aiz muguras simetrisks NAT (katram savs).

Īss kopsavilkums

Šeit ir daži paziņojumi par WebRTC entītijām, kas jums 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 (sdp) pārsūtīšanas uzdevums ir lietojumprogrammai.
  • Loģiskā savienojuma mehānisms sastāv no diviem posmiem - piedāvājums (piedāvājums) un atbildes (atbilde)
  • Sesijas deskriptora ģenerēšana nav iespējama, neizmantojot lokālo mediju straumi piedāvājuma gadījumā un nav iespējama bez attālās sesijas deskriptora izmantošanas atbildes gadījumā.
  • Iegūtais deskriptors ir jāpiešķir WebRTC ieviešanai, un nav nozīmes tam, vai šis deskriptors tiek saņemts attālināti vai lokāli no tās pašas WebRTC ieviešanas.
  • Ir iespējams nedaudz rediģēt sesijas deskriptoru
• Kandidāti
  • Ledus kandidāts ir tīkla mezgla adrese
  • Mezgla adrese var būt jūsu vai maršrutētāja vai TURN servera adrese
  • Kandidātu vienmēr ir daudz
  • Kandidāts sastāv no IP adreses, porta un transporta veida (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ānodod WebRTC implementācijām, taču tikai attālajām
  • Dažās WebRTC implementācijās kandidātus var pārsūtīt tikai pēc tam, kad ir iestatīts sesijas deskriptors
• Apdullināt/pagriezt/LEDUS/NAT
  • NAT ir mehānisms, kas nodrošina piekļuvi ārējam tīklam
  • Mājas maršrutētāji atbalsta īpašu NAT tabulu
  • 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 daudzkanālu piekļuvi ārējam tīklam, NAT izmanto portus
  • ICE — NAT šķērsošanas dzinējs
  • STUN un TURN serveri – palīgserveri NAT šķērsošanai
  • STUN serveris ļauj izveidot nepieciešamos ierakstus NAT tabulā, kā arī atgriež resursdatora ārējo adresi
  • TURN serveris vispārina STUN mehānismu un liek tam vienmēr darboties
  • Sliktākajos gadījumos TURN serveris tiek izmantots kā starpnieks (relejs), tas ir, p2p pārvēršas par savienojumu klients-serveris-klients.

Mūsdienās WebRTC ir “karstākā” tehnoloģija audio un video straumēšanai pārlūkprogrammās. Konservatīvās tehnoloģijas, piemēram, HTTP Streaming un Flash, ir piemērotākas ierakstītā satura (video pēc pieprasījuma) izplatīšanai un ir ievērojami zemākas par WebRTC reāllaika un tiešsaistes apraides ziņā, t.i. kur ir nepieciešams minimāls video latentums, lai skatītāji varētu redzēt notiekošo “tiešraidē”.

Kvalitatīvas reāllaika komunikācijas iespēja nāk no pašas WebRTC arhitektūras, kur video straumju transportēšanai tiek izmantots UDP protokols, kas ir standarta pamats video pārraidīšanai ar minimālu aizkavi un tiek plaši izmantots reāllaika sakaru sistēmās.

Saziņas latentums ir svarīgs tiešsaistes apraides sistēmās, tīmekļsemināros un citās lietojumprogrammās, kurām nepieciešama interaktīva saziņa ar video avotu, gala lietotājiem un kurām ir nepieciešams risinājums.

Vēl viens labs iemesls izmēģināt WebRTC ir tas, ka tā noteikti ir tendence. Šodien katrs Android Chrome pārlūks atbalsta šo tehnoloģiju, kas garantē miljoniem ierīču, kas ir gatavas skatīties pārraidi, neinstalējot papildu programmatūru vai konfigurācijas.

Lai pārbaudītu WebRTC tehnoloģiju darbībā un palaistu vienkāršu tiešsaistes pārraide, mēs izmantojām Flashphoner WebRTC Media & Broadcasting Server servera programmatūru. Funkcijās ir norādīta iespēja pārraidīt WebRTC straumes režīmā viens pret daudziem, kā arī atbalsts IP kamerām un videonovērošanas sistēmām, izmantojot RTSP protokolu; Šajā pārskatā mēs koncentrēsimies uz tīmekļa tīmekļa pārraidēm un to funkcijām.

WebRTC multivides un apraides servera instalēšana

Jo priekš Windows sistēmas nebija servera versijas, un es negribēju instalēt virtuālo mašīnu, piemēram, VMWare+Linux, lai es varētu pārbaudīt tiešsaistes pārraides mājās. Windows dators Neizdevās. Lai ietaupītu laiku, mēs nolēmām izmantot mākoņa mitināšanas piemēru:

Tā bija Centos x86_64 versija 6.5 bez iepriekš instalētas programmatūras Amsterdamas datu centrā. Tādējādi viss, kas mūsu rīcībā ir, ir serveris un ssh piekļuve tam. Tiem, kas ir pazīstami ar konsoles komandas Linux, WebRTC servera instalēšana solās būt vienkārša un nesāpīga. Tātad, ko mēs izdarījām:

1. Lejupielādējiet arhīvu:

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

2. Izsaiņojiet:

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

3. Instalējiet:

$cd FlashphonerWebCallServer

Instalēšanas laikā ievadiet servera IP adresi: XXX.XXX.XXX.XXX

4. Aktivizējiet licenci:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Startējiet WCS serveri:

$service webcallserver startēšana

6. Pārbaudiet žurnālu:

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

7. Pārbaudiet, vai ir ieviesti divi procesi:

$ps aux | grep Flashphoner

Instalēšanas process ir pabeigts.

WebRTC tiešsaistes apraides pārbaude

Pārraižu pārbaude izrādījās vienkārša lieta. Papildus serverim ir arī tīmekļa klients, kas sastāv no dučiem Javascript, HTML un CSS failiem un kuru mēs instalēšanas posmā izvietojām mapē /var/www/html. Vienīgais, kas man bija jādara, bija ievadīt servera IP adresi flashphoner.xml konfigurācijā, lai tīmekļa klients varētu izveidot savienojumu ar serveri, izmantojot HTML5 Websockets. Aprakstīsim testēšanas procesu.

1. Pārlūkprogrammā Chrome atveriet index.html testa klienta lapu:

2. Lai sāktu apraidi, ekrāna vidū ir jānoklikšķina uz pogas "Sākt".
Pirms to darāt, jums jāpārliecinās, vai tīmekļa kamera ir pievienota un gatava lietošanai. Tīmekļa kamerai nav īpašu prasību, piemēram, mēs izmantojām standarta kameru, kas iebūvēta klēpjdatorā ar izšķirtspēju 1280x800.

Pārlūks Chrome noteikti prasīs piekļuvi kamerai un mikrofonam, lai lietotājs saprastu, ka viņa video tiks nosūtīts uz interneta serveri un to atļauj.

3. Interfeiss atspoguļo veiksmīgu video straumes pārraidi no kameras uz WebRTC serveri. Augšējā labajā stūrī indikators norāda, ka straume iet uz serveri; apakšējā stūrī ir poga “Apturēt”, lai apturētu video sūtīšanu.

Lūdzu, ņemiet vērā saiti zemāk esošajā lodziņā. Tajā ir unikāls šīs straumes identifikators, tāpēc ikviens var pievienoties skatīšanai. Vienkārši atveriet šo saiti savā pārlūkprogrammā. Lai kopētu to starpliktuvē, noklikšķiniet uz pogas "Kopēt".

Reālās lietojumprogrammās, piemēram, vebināros, lekcijās, tiešsaistes video pārraidēs vai interaktīvajā TV, izstrādātājiem būs jāīsteno šī identifikatora izplatīšana noteiktām skatītāju grupām, lai tās varētu pieslēgties vēlamajām straumēm, taču tāda jau ir aplikācijas loģika. . WebRTC Media & Broadcasting Server to neietekmē, bet tikai izplata video.

5. Savienojums ir izveidots, un skatītājs ekrānā redz straumi. Tagad viņš var nosūtīt saiti kādam citam, apturēt straumes atskaņošanu vai iespējot pilnekrāna režīmu, izmantojot vadīklas apakšējā labajā stūrī.

WebRTC tiešsaistes apraides servera testēšanas rezultāti

Pārbaužu laikā latentums šķita ideāls. ping uz datu centru bija aptuveni 100 milisekundes, un aizkave bija acīm neredzama. No šejienes mēs varam pieņemt, ka reālā aizkave ir tāda pati 100 plus vai mīnus daži desmiti milisekundes buferizācijas laikam. Salīdzinot ar Flash video: šādos testos Flash nedarbojas tik labi kā WebRTC. Tātad, ja pārvietojat roku līdzīgā tīklā, kustību ekrānā var redzēt tikai pēc vienas vai divām sekundēm.

Runājot par kvalitāti, mēs atzīmējam, ka kubus dažreiz var atšķirt pēc kustībām. Tas atbilst VP8 kodeka būtībai un tā galvenajam mērķim - nodrošināt reāllaika video saziņu ar pieņemamu kvalitāti un bez sakaru kavēšanās.

Serveri ir diezgan viegli uzstādīt un konfigurēt; tā darbināšanai nav nepieciešamas nekādas nopietnas prasmes, izņemot zināšanas par Linux pieredzējuša lietotāja līmenī, kurš var izpildīt komandas no konsoles, izmantojot ssh un lietot teksta redaktors. Rezultātā mums izdevās izveidot tiešsaistes apraidi viens pret daudziem starp pārlūkprogrammām. Papildu skatītāju pievienošana straumei arī nesagādāja nekādas problēmas.

Pārraides kvalitāte izrādījās diezgan pieņemama vebināriem un tiešsaistes pārraidēm. Vienīgais, kas radīja dažus jautājumus, bija video izšķirtspēja. Kamera atbalsta 1280x800, bet izšķirtspēja testa attēlā ir ļoti līdzīga 640x480. Acīmredzot šis jautājums ir jāprecizē ar izstrādātājiem.

Video par testēšanas pārraidi no tīmekļa kameras
izmantojot WebRTC serveri

Tehnoloģijas zvanu veikšanai no pārlūkprogrammas pastāv jau daudzus gadus: Java, ActiveX, Adobe Flash...Pēdējos gados ir kļuvis skaidrs, ka spraudņi un pa kreisi virtuālās mašīnas Tie nespīd ar ērtībām (kāpēc man vispār kaut kas jāinstalē?) un, pats galvenais, ar drošību. 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, H.323 un MGCP, kas nāk no skatuves, Jabber/Jingle (izmanto Gtalk), daļēji atvērts Adobe RTMP* un, protams, , aizvēra Skype. Google iniciētais WebRTC projekts mēģina mainīt situāciju IP un tīmekļa telefonijas pasaulē, padarot visu softphones, tostarp Skype. WebRTC ne tikai ievieš visas saziņas iespējas tieši pārlūkprogrammā, kas tagad ir instalēta gandrīz katrā ierīcē, bet arī mēģina vienlaikus atrisināt vispārīgāku saziņas problēmu starp pārlūkprogrammas lietotājiem (dažādu datu apmaiņa, ekrāna apraide, sadarbība ar dokumentiem un daudz vairāk).

WebRTC no tīmekļa izstrādātāja viedokļa

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

• multivides straumju kontrole no vietējiem resursiem (kamera, mikrofons vai ekrāns). lokālais dators) tiek realizēta ar metodi navigator.getUserMedia, kas atgriež MediaStream objektu;
• peer-to-peer saziņa starp ierīcēm, kas ģenerē multivides straumes, tostarp saziņas metožu definēšana un tieša to 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šu vairāku lietotāju video tērzēšanu starp pārlūkprogrammām, pamatojoties uz WebRTC, izmantojot tīmekļa ligzdas. Mēs sāksim eksperimentēt pārlūkprogrammā Chrome/Chromium, kas ir vismodernākās pārlūkprogrammas WebRTC ziņā, lai gan Firefox 22, kas tika izlaista 24. jūnijā, ir gandrīz panākusi tos. 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.

MediaStream

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. Lai to izdarītu, pārlūkprogrammā Chrome ir jāizsauc funkcija 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()). Zvanot, lietotājam tiks lūgts 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, ja tiks veiksmīgi iegūta pieeja kamerai/mikrofonam, otra - kļūdas gadījumā. Vispirms izveidosim HTML failu rtctest1.html ar pogu un elementu:

WebRTC — pirmais ievada video (augstums: 240 pikseļi; platums: 320 pikseļi; apmale: 1 px cieti pelēka; ) getUserMedia

Microsoft CU-RTC-Web

Microsoft nebūtu Microsoft, ja tā nekavējoties nereaģētu uz Google iniciatīvu, izlaižot savu nesaderīgo nestandarta opciju ar nosaukumu CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Lai gan IE īpatsvars, jau tā neliels, turpina samazināties, Skype lietotāju skaits dod Microsoft cerību izspiest Google, un var pieņemt, ka šis konkrētais standarts tiks izmantots pārlūkprogrammā. Skype versijas. Google standarts galvenokārt ir vērsts 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 rašanās var radīt ne tikai nepatīkamu vajadzību izstrādātājiem atbalstīt divas nesavietojamas tehnoloģijas vienlaikus, bet arī nākotnē sniegt lietotājam plašāku iespējamo funkcionalitātes un pieejamo tehnisko risinājumu izvēli. Gaidi un redzēsi.

Vietējās straumes iespējošana

Mūsu HTML faila tagos deklarēsim globālo mainīgo multivides straumei:

Var localStream = null;

Pirmajam getUserMedia metodes parametram ir jānorāda pieprasītās multivides straumes parametri, 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 parametrus:

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

Otrais parametrs getUserMedia metodei ir jānodod atzvanīšanas funkcijai, kas tiks izsaukta, ja tā būs veiksmīga:

Funkcija getUserMedia_success(stream) ( console.log("getUserMedia_success():", straume); localVideo1.src = URL.createObjectURL(stream); // Savienojiet multivides straumi ar HTML elementu localStream = straume; // un saglabājiet to globālajā mainīgajā turpmākai lietošanai)

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 ir pieprasījums piekļūt 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āsim to izdarīt, mēs saņemsim kļūdu:

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.

Ierīces, kurām Chrome varēs piekļūt, varat atlasīt sadaļā Iestatījumi, Rādīt papildu iestatījumu saiti, sadaļā Konfidencialitāte, pogā Saturs. Pārlūkprogrammās Firefox un Opera ierīces tiek atlasītas no nolaižamā saraksta tieši, kad piekļuve ir atļauta.

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 pirmajā reizē, kad piekļūstat multivides straumei.

Ievērojiet pulsējošo apli grāmatzīmes ikonā un kameras ikonu adreses joslas labajā pusē:

RTCMediaConnection

RTCMediaConnection ir 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 šķērsošanai vai ugunsmūri(lokāli 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 saņemta lokāli, srflx — kā mezgls izskatās ārējam serverim (STUN), un relejs — informācija trafika starpniekserverēšanai caur TURN serveri. Ja mūsu mezgls atrodas aiz NAT, 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 starpserveri.

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:user@host:port", "credential": "password") ]);

Internetā ir daudz publisko STUN serveru. Piemēram, ir liels saraksts. 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 iet caur multivides straumēm, 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. Ir pat gatavs Amazon EC2 attēls.

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 ne līdzvērtīgs Skype adrešu tulkošanas (NAT) un ugunsmūru kvalitātes ziņā. , ir vismaz manāms nāks tuvāk.

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 pārraide citiem dalībniekiem ir jārealizē atsevišķi.

Pārsūtīšanas metodes izvēle ir izstrādātāja ziņā - vismaz manuāli. Tiklīdz notiek nepieciešamo datu apmaiņa, RTCMediaConnection automātiski instalēs multivides straumes (protams, ja iespējams).

piedāvājuma-atbildes modelis

Lai izveidotu un mainītu multivides straumes, tiek izmantots piedāvājuma/atbilžu modelis (aprakstīts RFC3264) un SDP (sesijas apraksta protokols). Tos izmanto arī SIP protokols. Šajā modelī ir divi aģenti: Piedāvātājs - tas, kurš ģenerē sesijas SDP aprakstu, lai izveidotu jaunu vai pārveidotu esošo (Piedāvājums SDP), un atbildētājs - tas, kurš saņem sesijas SDP aprakstu no cits aģents un atbild ar savu sesijas aprakstu (Answer 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:

• Pirmais dalībnieks, kurš uzsāk savienojumu, veido Piedāvājumu, kurā tas nosūta SDP datu struktūru (tas pats protokols tiek izmantots tam pašam mērķim SIP), aprakstot iespējamās multivides straumes īpašības, kuras tas drīzumā sāks pārraidīt. Šis datu bloks ir jāpārsūta otrajam dalībniekam. Otrais dalībnieks veido 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ārraidīt viņiem mediju straumi. Kad kandidāti ir identificēti, informācija par viņiem ir jānodod citam dalībniekam.

Veidošanas piedāvājums

Lai izveidotu piedāvājumu, mums ir nepieciešamas divas funkcijas. Pirmais tiks izsaukts, ja tas būs veiksmīgi izveidots. Otrs metodes createOffer() parametrs ir atzvanīšanas funkcija, kas tiek izsaukta kļūdas gadījumā tās izpildes laikā (ja vietējais pavediens jau ir pieejams).

Turklāt ir nepieciešami divi notikumu apdarinātāji: onecandidate, definējot jaunu ICE kandidātu, un onaddstream, kad savieno multivides straumi no tālākās puses. Atgriezīsimies pie mūsu lietas. Pievienosim vēl vienu HTML pēc rindiņām ar elementiem:

izveidot Piedāvājumu

Un pēc rindas ar elementu (nākotnei):

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

Var pc1;

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

Var serveri = null;

Piedāvājuma SDP sagatavošanas parametri

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); // Iestatīt RTCPeerConnection radīto SDP izmantojot metodi setLocalDescription. // Kad tālākā puse nosūta savu Atbildes SDP, tā būs jāiestata, izmantojot metodi setRemoteDescription // Kamēr otrā puse nav ieviesta, mēs neko nedarām // 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 deklarēsim atzvanīšanas funkciju, kurai tiks nodoti ICE kandidāti, kad tie tiks noteikti:

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

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

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

Noklikšķinot uz pogas “izveidot piedāvājumu”, mēs izveidosim RTCPeerConnection, iestatīsim onicecandidate un onaddstream metodes un pieprasīsim Offer SDP izveidi, izsaucot metodi createOffer():

Funkcija createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Izveidot RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Atzvanīšanas funkcija ICE kandidātu apstrādei pc1.onaddonad =dpc1.onaddonad =dpc1.onaddonad Atzvanīšanas funkcija tiek izsaukta, kad multivides straume parādās no tālākās puses. Vēl nevienas nav pc1.addStream(localStream); // Pārraidīsim lokālo multivides straumi (pieņemot, ka tā jau ir saņemta) pc1.createOffer(// Un faktiski pieprasīsim Piedāvājuma izveidošana pc1_createOffer_success , pc1_createOffer_error, offerConstraints);)

Saglabāsim failu kā rtctest2.html, augšupielādēsim 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. Atcerēsimies, ka SDP ir multivides sesijas parametru apraksts, pieejamie kodeki, multivides straumes un ICE kandidāti ir iespējamās opcijas, lai izveidotu savienojumu ar konkrēto dalībnieku.

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

Gan Offer SDP, gan katrs no ICE kandidātiem ir jāpārnes uz otru pusi un tur pēc to saņemšanas RTCPeerConnection izsauc Piedāvājuma SDP metodes setRemoteDescription un addIceCandidate katram no tālākās puses saņemtajam ICE kandidātam; līdzīgi iekšā otrā puse 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 tam RTCPeerConnection metode setRemoteDescription tiek nodota no zvanītāja saņemtajam Offer SDP.

Pievienosim HTML vēl vienu video elementu:

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

Var pc2;

Piedāvājuma un atbildes apstrāde SDP

Atbildes SDP veidošana ir ļoti līdzīga piedāvājumam. Atzvanīšanas funkcijā, kas tiek 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ā, ģenerējot atbildi, ir pilnībā līdzīga piedāvājumam:

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

Parametri atbildes SDP veidošanai:

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

Kad otrs dalībnieks saņems Piedāvājumu, mēs izveidosim RTCPeerConnection un veidosim Atbildi tādā pašā veidā kā Piedāvājums:

Funkcija pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Izveidojiet RTCPeerConnection objektu otrajam dalībniekam tāpat kā pirmajam pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = candidate = pc2 ; // Iestatiet notikumu apdarinātāju, kad tas parādās ICE kandidāts pc2.onaddstream = pc_onaddstream; // Kad parādās straume, savienojiet to ar HTML pc2.addStream(localStream); // Pārsūtiet vietējās multivides straumi (mūsu piemērā otro dalībniekam ir tāds pats kā pirmajam) // Tagad, kad būs gatavs otrais RTCPeerConnection, mēs tam nodosim saņemto Offer SDP (nodevām lokālo straumi pirmajam) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Pieprasīt otro savienojumu, lai ģenerētu datus atbildes ziņojumam pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Lai pārsūtītu piedāvājuma SDP no pirmā dalībnieka uz otro mūsu piemērā, atcelsim to funkcijā pc1. izveidot Piedāvājumu veiksme() zvana līnija:

Pc2_receivedOffer(desc);

Lai īstenotu ICE kandidātu apstrādi, pirmā dalībnieka pc1_onicecandidate() ICE kandidātu gatavības notikumu apstrādātājā komentēsim tā pārsūtīšanu 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

Beigt sarunu

Un savienojuma pārtraukšanas funkcija

Funkcija btnHangupClick() ( // Atvienojiet vietējo video no HTML elementiem, apturiet vietējās multivides straumi, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Katram dalībniekam atspējojiet video no HTML elementiem, aizveriet savienojumu, iestatiet rādītāju = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Saglabāsim to kā rtctest3.html, augšupielādēsim serverī un atveram pārlūkprogrammā. Šajā piemērā ir īstenota divvirzienu multivides straumju pārraide starp divām 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 caur tīklu, nevis tiešās izsaukšanas procedūras, būs nepieciešams īstenot apmaiņu starp dalībniekiem, izmantojot kādu transportu, mūsu gadījumā - web ligzdas.

Ekrāna pārraide

Funkcija getUserMedia var arī tvert 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 nav jāpieprasa;
• Vienā pārlūkprogrammas cilnē nevajadzētu izpildīt vairākus pieprasījumus.

Bibliotēkas WebRTC

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 atvieglos P2P tīklu izveidi datu apmaiņai, un Holla samazinās nepieciešamo izstrādes apjomu 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 caur tīklu, 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

Uzstādīšana citiem OS aprakstīts

Pārbaudīsim:

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

Izmantojot npm (Node Package Manager), mēs instalēsim 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"); // nosūtīt HTML failu ) ) ; io.sockets.on("savienojums", funkcija (socket) ( // Savienojot socket.emit("servera notikums", ( sveiki: "world" )); // nosūtīt ziņojumu socket.on("klienta notikums" , funkcija (dati) ( // un deklarēt notikumu apstrādātāju, kad tiek saņemts ziņojums no klienta konsoles.log(dati); )); ));

Un nodetest2.html klienta pusei:

$ nano nodetest2.html var socket = io.connect("/"); // Websocket servera URL (tā servera saknes lapa, no kuras lapa tika ielādēta) socket.on("servera notikums", funkcija (data) ( console.log(data); socket.emit("klienta notikums", () "nosaukums": "vērtība" )); ));

Sāksim serveri:

$ sudo nodejs nodetest2.js

un pārlūkprogrammā atveriet lapu http://localhost:80 (ja darbojas lokāli 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 daļa

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

Un JavaScript skripta sākumā - savienojuma izveide ar tīmekļa ligzdām:

Var ligzda = 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 pārsū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) (е 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("hangup", funkcija (data) ( console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Servera daļa

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

Socket.on("piedāvājums", funkcija (dati) ( // Kad saņemam "piedāvājuma" ziņojumu, // jo šajā piemērā ir tikai viens klienta savienojums, // mēs nosūtīsim ziņojumu atpakaļ caur to pašu ligzdas ligzdu .emit("piedāvājums" , dati); // Ja būtu nepieciešams pārsūtīt ziņojumu pa visiem savienojumiem, // izņemot sūtītāju: // soket.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 mainīsim HTML faila nosaukumu:

// res.sendfile(__dirname + "/nodetest2.html"); // Nosūtīt HTML failu res.sendfile(__dirname + "/rtctest4.html");

Servera palaišana:

$ 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 tīklā, un dalībnieku “atdalīšana” neprasa īpašas grūtības. Taču arī tas, ko darījām, bija ļoti vienkārši – šīs tehnoloģijas ir labas, jo tās ir viegli lietojamas. Pat ja reizēm mānīgi. 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

Rezultātā iegūtais piemērs ir ļoti parasts, taču, ja mēs nedaudz universalizējam notikumu apdarinātājus, lai tie neatšķirtos starp zvanītāju un izsaukto pusi, divu objektu pc1 un pc2 vietā izveidojiet RTCPeerConnection masīvu un ieviešam dinamiska radīšana un noņemot elementus, jūs iegūsit pilnībā lietojamu video tērzēšanu. Ar WebRTC nav saistīta īpaša specifika, un vienkārša video tērzēšanas piemērs vairākiem dalībniekiem (kā arī visu rakstā minēto piemēru teksti) ir diskā, kas tiek piegādāts kopā ar žurnālu. Tomēr internetā jau var atrast diezgan daudz. labi piemēri. Īpaši, sagatavojot rakstu, tika izmantots: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.

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ā tehnoloģija zvaniem no pārlūka uz pārlūkprogrammu, bet arī kā reāllaika komunikācijas tehnoloģija. Video komunikācija, par kuru mēs runājām, ir tikai neliela daļa iespējamie varianti tā izmantošanu. Jau ir ekrāna pārraides un sadarbības piemēri un pat uz pārlūkprogrammu balstīts P2P satura piegādes tīkls, kas izmanto RTCDataChannel.