Vaizdo skambučiai ir transliacijos realiuoju laiku naudojant „WebRTC“ ir SDK

Jei statote JavaScript šalutinis projektas O jei jums reikia vaizdo skambučių, normalu abejoti: ar turėčiau naudoti gryną „WebRTC“, SDK, pvz., „Agora“, „Twilio“, „Mux“ ar „Zegocloud“, ar visiškai pereiti prie „RN-WebRTC“ „React Native“? Bloga žinia ta, kad nėra vieno sprendimo. Gera žinia ta, kad jūs suprantate realaus laiko „JavaScript“, todėl galite priimti pagrįstą sprendimą ir išvengti architektūros klaidų.

Šiose eilutėse žingsnis po žingsnio pamatysite, kaip tai veikia WebRTC vidujeKokį vaidmenį atlieka „Agora“ (ir kiti panašūs tiekėjai)? Ką reiškia susikurti savo infrastruktūrą (STUN/TURN, signalizacija, SFU, medijos serveriai...)? Ir kokie yra realūs kompromisai tarp kainos, sudėtingumo ir mastelio keitimo vaizdo skambučiams ir transliacijoms realiuoju laiku?

Kas yra WebRTC ir kodėl tai yra visko pagrindas?

„WebRTC“ (žiniatinklio realaus laiko komunikacija) Tai atvirojo kodo standartų, API ir protokolų rinkinys, leidžiantis transliuoti garsą, vaizdą ir duomenis realiuoju laiku tiesiai iš naršyklės ar vietinės programėlės be papildinių ar išorinių programų. Jį standartizuoja W3C ir IETF, jį palaiko visos šiuolaikinės naršyklės: „Chrome“, „Firefox“, „Safari“, „Edge“, „Opera“ ir daugelis mobiliųjų naršyklių.

Jų filosofija aiški: sudaryti sąlygas bendravimui. tarpusavio ryšys (P2P) tarp vartotojų su labai mažu delsos laiku, užkulisiuose sprendžiant visas nepatogias tinklo problemas – kodekus, virpesius, aidą, paketų praradimą, šifravimą ir kt. Tai apima viską – nuo ​​​​vienas su vienu vaizdo skambučio iki sistemos, interaktyvus transliavimas su šimtais ar tūkstančiais žiūrovų, jei derinsite tai su tinkama infrastruktūra.

Susijęs straipsnis:

Kaip naudoti ir sukurti skambinimo programėlę „Android“ sistemoje: išsamus vadovas vartotojams ir kūrėjams

Pagrindinės „WebRTC“ API: „getUserMedia“, „RTCPeerConnection“ ir „RTCDataChannel“

„WebRTC“ remiasi trimis pagrindinėmis naršyklės API, kurias tikrai naudosite, nesvarbu, ar kursite savo sprendimą, ar naudosite SDK, pvz., „Agora“:

• MediaStream / getUserMedia: vaizdo įrašams ir garsui užfiksuoti (kamera, mikrofonas ir net ekranas ar skirtukai).
• RTCPeerConnection: derėtis ir perduoti garso ir vaizdo srautus tarp bendraamžių.
• RTCDataChannel: siųsti savavališkus duomenis (tekstinius, dvejetainius, failus) su maža delsa tarp klientų.

su „getUserMedia“ Galite paprašyti naršyklės prieigos prie kameros ir mikrofono ir gauti MediaStream kurį vėliau susiejate su elementu <video> su video.srcObject = stream. Galite kreiptis apribojimai (skiriamoji geba, kadrų dažnis, priekinė / galinė kamera ir kt.) ir jei šie reikalavimai nebus įvykdyti, gausite tokias klaidas kaip OverconstrainedErrorkuriam turite pasiūlyti alternatyvų (pavyzdžiui, sumažinti raišką nuo 1080p iki 720p ir pritaikyti koregavimus pagerinti mikrofono garsą).

API RTCPeerConnection Tai yra skambučių esmė: ji tvarko SDP (pasiūlymo/atsakymo) derybas, ICE (apsvaiginimo/pasukimo) kandidatų surinkimą, ryšio užmezgimą ir saugų perdavimą per SRTP. Savo kode tiesiog sukuriate ryšį, pridedate medijos takelius ir reaguojate į tokius įvykius kaip onicecandidate u ontrack ir jūs pasirūpinate ženklais.

Galiausiai, RTCDataChannel Tai leidžia nustatyti duomenų kanalus, panašius į „WebSocket“, bet tiesioginio ryšio kanalus ir tiksliai kontroliuojant patikimumą bei tvarką. Tai naudinga vaizdo pokalbiams, failų bendrinimui, žaidimo būsenos sinchronizavimui arba bendradarbiavimui realiuoju laiku. Sintaksė pažįstama: dataChannel.send() y onmessage imtuve.

Signalizavimas: „klijai“, kurių WebRTC neapibrėžia

Tipiškas nesusipratimas: WebRTC neapima ženklų„RTCPeerConnection“ turi keistis informacija, tačiau nenurodo, kaip tai daryti. Tai turite apibrėžti patys arba trečiosios šalies SDK gali tai jums apibendrinti.

Poros siunčiamos signalizacijos būdu:

• Sesijos valdymo pranešimai: pradėti skambutį, baigti ragelį, klaidos.
• Tinklo informacijaICE kandidatai (aptikti IP adresai / prievadai).
• Medijos metaduomenysSDP pasiūlymai ir atsakymai su kodekais, skiriamosiomis gebomis ir kt.

Šis ženklas paprastai įgyvendinamas su WebSockets„Socket.IO“, HTTP (apklausa / ilga apklausa), MQTT arba kiti dvikrypčiai mechanizmai. Labai tipiškas modelis yra „Node.js“ serveris su Lizdas.IO kuris tvarko „kambarius“ ir persiunčia žinutes teksto / JSON tipas tarp klientų:

Serveris: gauna create or joinJis sukuria kambarį, jei jo nėra, palaiko iki dviejų klientų (pagrindiniam vaizdo skambučiui) ir persiunčia pranešimus. message prie kitų kambaryje esančių lizdų. Jūs esate atsakingi už tai, kad neviršytumėte maksimalaus vartotojų skaičiaus arba sukurtumėte savo kambario logiką.

KlientasĮkeliant puslapį, jis prašo kambario pavadinimo (arba jį nustato iš URL), jis išmeta create or joinKlausykitės tokių renginių kaip created, joined, full, ready ir susitaria su kita šalimi dėl skambučio inicijavimo arba atmetimo.

Šis modelis puikiai tinka prototipas arba šalutinis projektasTai suteikia jums lengvą signalizacijos serverį, kurį galite pritaikyti klasteriams ir apkrovos balansavimo įrenginiams, jei reikia.

STUN, TURN, ICE: NAT ir užkardų apėjimas neišprotėjus

Idealiame pasaulyje du vartotojai visada būtų pasiekiamuose tinkluose ir jungtųsi tiesiogiai. Realiame pasaulyje yra NAT, ugniasienės, CGNAT iš interneto paslaugų teikėjų ir paranojiškų įmonių tinklų. Čia praverčia ICE, apjungianti STUN ir TURN.

• STUDINIS (Session Traversal Utilities for NAT) leidžia klientui sužinoti savo Viešas IP ir prievadasSTUN serveris atsako tik šia informacija.
• SUKTI (Traversal Using Relays around NAT) veikia kaip relės serveris medijos, kai nėra galimybės atidaryti tiesioginio P2P kanalo. Per jį praeina garso / vaizdo srautas, todėl jis naudoja serverio pralaidumą ir kainuoja pinigus.
• P (Interactive Connectivity Establishment) yra atsakingas už visų galimų kandidatų (vietinių adresų, atspindimų STUN, TURN relių) testavimą, kol randamas tinkamas maršrutas.

Praktiškai, savo RTCPeerConnection konfigūracijos objekte pridedate masyvą iceServers Naudodama STUN/TURN URI, naršyklė atlieka visą likusį darbą. Jei kuriate savo infrastruktūrą, turėsite diegti ir prižiūrėti savo STUN/TURN serverius; jei naudojate SDK, pvz., „Agora“, „Twilio“ ar „Zegocloud“, jie jau yra sutvarkę šią užduotį ir yra paruošti gamybai.

Mažo delsos transliacijos realiuoju laiku: WebRTC ir HLS/DASH

Kai mes kalbame apie tiesioginis transliavimas Yra du skirtingi pasauliai: HTTP pagrįsti protokolai (HLS, DASH) ir WebRTC. HLS/DASH veikia atsisiųsdami ir paleisdami vaizdo įrašų segmentus iš kliento; tai puikiai tinka mastelio keitimui per CDN, tačiau atsiranda kelių sekundžių latencijos (lengvai 5–30 sekundžių).

Kita vertus, „WebRTC“ naudoja UDP + RTP ir perduoda vaizdo įrašą iš šaltinio į grotuvą „push“ režimu, labai trumpu paleidimo laiku ir tipiškomis delsomis, nurodytomis žemiau 500 ms (dažnai ~250 ms), jei tinklas geras. Tai pasiekiama dėl:

• Spūsčių kontrolė integruotas, kuris realiuoju laiku reguliuoja bitų spartą ir skiriamąją gebą pagal paketų praradimą, virpėjimą arba RTT.
• Efektyvių kodekų (VP8, VP9, ​​​​H.264; vis dažniau AV1) naudojimas su aparatinės įrangos spartinimas kai yra prieinama.
• Galimybė naudoti SVC (mastelinio vaizdo kodavimą), kad imtuvas priimtų tik tuos sluoksnius, kuriuos palaiko jo tinklas / įrenginys.

Štai kodėl „WebRTC“ yra natūralus pasirinkimas realaus laiko aukcionai, tiesioginių sporto lažybų, prekybos, interaktyvių žaidimų, nuotolinės pagalbos, telemedicinos, dalyvaujamųjų virtualių klasių ar finansinių ataskaitų suvestinių, kurios negali sau leisti kelių sekundžių vėlavimo.

Problema ta, kad grynas P2P WebRTC nėra gerai pritaikomas tūkstančiams žiūrovų; tam jums reikia SFU, medijos serveriai arba hibridinės platformosbūtent čia ir praverčia tokie sprendimai kaip „Flussonic“, „Agora“ ar panašūs.

P2P ribų peržengimas: SFU, medijos serveriai ir hibridinės architektūros

Vaizdo skambučio metu „WebRTC“ veikia nepriekaištingai. Tačiau jei pradedate pridėti 10, 20 ar 100 vartotojų, viskas pasikeičia: kiekvienas klientas turi siųsti / gauti kelis srautus, jo procesorius perkaista ir tinklas sugenda. Čia išryškėja trys klasikiniai modeliai:

• MCU (daugiataškis valdymo blokas)Serveris gauna visus srautus, juos sumaišo ir siunčia po vieną srautą kiekvienam klientui. Privalumas: mažas kliento išteklių suvartojimas. Trūkumai: didelė serverio apkrova, mažiau individualios kokybės kontrolės.
• SFU (selektyvusis persiuntimo blokas)Serveris gauna srautus ir juos pasirinktinai persiunčia jų nemaišydamas. Kiekvienas žiūrovas gauna jam reikalingus srautus, galbūt skirtingos kokybės. Tai šiandien dažniausiai naudojamas modelis kelių vartotojų vaizdo konferencijos ir keičiamo mastelio interaktyvi transliacija.
• Hibridinės architektūros WebRTC + HLS/DASH„WebRTC“ naudojamas įterpimui ir sąveikai, o HLS/DASH platina didelėms auditorijoms, kurioms nereikia sąveikos realiuoju laiku. Tai pusiausvyra tarp itin mažas delsimas „aktoriams“ ir didžiulis mastelio keitimas „žiūrovams“.

Žiniasklaidos serveriai, pvz. Flussoninis Kiti teikia reikiamą vidinę sistemą: jie gauna „WebRTC“ srautą, prireikus jį perkoduoja, persiunčia per „WebRTC“ kitiems klientams arba konvertuoja į HLS tipo protokolus masiniam platinimui. Būtent tokio tipo infrastruktūra praktiškai leidžia peržengti individualių skambučių ribas, nereikalaujant išradinėti dviračio.

Tipiniai naudojimo atvejai: vaizdo skambučiai, transliacijos, daiktų internetas ir daug daugiau

„WebRTC“ tapo visur paplitęs, ir jūs tikriausiai jį naudojate kiekvieną dieną to nesuvokdami. Keletas pavyzdžių, kur jis ypač gerai tinka... vaizdo skambučiai ir vaizdo konferencijos:

• Vaizdo skambučiai ir vaizdo konferencijos„Google Meet“, „Jitsi“, „Slack“, „Microsoft Teams“ ir daugelis kitų įrankių vaizdo, garso ir ekrano bendrinimui naudoja „WebRTC“ (visiškai arba iš dalies).
• Srautinio perdavimo realiuoju laiku paslaugosTokios platformos kaip „Twitch“, „Meta Live“, „Vimeo Livestream“ arba tokie įrankiai kaip „Streamyard“ sujungia „WebRTC“ įterpimui ir kitas technologijas masiniam platinimui.
• Pokalbiai ir susirašinėjimas su failų bendrinimu„RTCDataChannel“ dėka galite bendrauti realiuoju laiku, dalytis failais, sinchronizuoti būseną ir pan. be centrinių medijos serverių.
• Žaidimai debesyje ir kelių žaidėjų režimasTokios paslaugos kaip „GeForce NOW“ ar „Xbox Cloud Gaming“ naudoja panašias technologijas interaktyviam vaizdo įrašui kurti; daugelis P2P žaidimų naudoja „WebRTC“ žaidimo sinchronizavimui.
• Daiktų internetas ir stebėjimasIšmaniosios kameros, kūdikių monitoriai, vaizdo durų skambučiai arba dronai gali siųsti realaus laiko vaizdo įrašas į mobiliuosius įrenginius ir naršykles, naudojant „WebRTC“.
• Švietimas ir telemedicinavirtualios klasės su baltomis lentomis, viktorinomis ir dvipusiu vaizdo ryšiu arba internetinės medicininės konsultacijos, kur delsa ir saugumas yra labai svarbūs.

„WebRTC“ saugumas: šifravimas, leidimai ir geriausia praktika

„WebRTC“ saugumas nėra priedas: jis yra integruotas. integruota nuo pat dizaino pradžiosVisi medijos komponentai yra užšifruoti, o API veikia tik iš saugių šaltinių (HTTPS arba „localhost“), nors patartina būti budriems. sukčiavimas vaizdo skambučiais.

• DTLS (Datagramų transportavimo sluoksnio saugumas) šifruoja perduodamus duomenis.
• SRTP (Saugus realaus laiko perdavimo protokolas) apsaugo garsą ir vaizdą, kad jų nebūtų lengva manipuliuoti ar perimti.
• Prieiga prie kamera ir mikrofonas Tam reikalingas aiškus vartotojo leidimas su matomais vaizdiniais indikatoriais (piktogramomis, spalvotais taškais ir kt.).
• Kadangi nėra jokių įskiepių, kuriuos reikėtų įdiegti, kyla rizika, kad kenkėjiška programinė įranga paslėpta trečiųjų šalių plėtiniuose arba dvejetainiuose failuose.

Net ir tokiu atveju, jūs turite pasirūpinti savo sluoksniu: naudokite HTTPS visame pasaulyjePeržiūrėkite prašomus leidimus, nuolat atnaujinkite naršykles ir bibliotekas ir nepamirškite signalizacijos serverio ar REST API saugumo.

„WebRTC“ ir kitos technologijos: VoIP, „WebSockets“ ir patentuotos platformos

Jei esate iš tradicinio VoIP pasaulio, jums bus pažįstami SIP, PBX, programiniai telefonai ir brangūs serveriai. „WebRTC“ keičia paradigmą: jums nereikia reikalauti, kad vartotojas pateiktų kokią nors informaciją. darbastalio klientas Nereikia jokios specialios įrangos; pakanka naršyklės ir gana paprasto signalizacijos serverio.

Prieš Tradicinis VoIP„WebRTC“ sumažina pagrindinės infrastruktūros apkrovą ir atveria duris programoms, tiesiogiai integruotoms į žiniatinklį. Daugeliu atvejų galite pakartotinai panaudoti savo SIP serverio sistemą per šliuzus, kurie signalus verčia į „WebRTC“.

Kalbant apie WebSocketsJuos reikėtų vertinti labiau kaip vienas kitą papildančius elementus: jie idealiai tinka pranešimams, lengvam pokalbiui ar būsenos atnaujinimams, bet ne intensyviai medijai. „WebRTC“ yra optimizuotas realaus laiko garsas / vaizdassu perkrovos valdymu, kodekais, trūkčiojimo buferiu ir kt. Praktiškai daugelyje projektų signalizacijai naudojami „WebSockets“, o medijos perdavimui – „WebRTC“.

Jei palyginsite juos su tokiomis platformomis kaip „Zoom“, „GoToMeeting“ arba „WebEx“Skirtumas slypi modelyje: šie įrankiai yra uždari sprendimai, dažnai su privalomomis darbalaukio programėlėmis ir patentuota posisteme. Kita vertus, „WebRTC“ yra pamatinė technologija; galite sukurti savo „mini-Meet“ ant jos arba integruoti su paslaugomis, kurios ją jau naudoja (pvz., „Google Meet“ ar „Microsoft Teams“).

Kūrimas naudojant „WebRTC“: tikrasis sudėtingumas ir dažni trūkumai

Nors API teoriškai atrodo paprastos, „WebRTC“ įdiegimas nuo nulio yra sudėtingesnis. Turėsite susidurti su:

Susijęs straipsnis:

„Tor“ naršyklė, skirta „Android“: išplėstiniai nustatymai ir saugus naudojimas

• Individualūs ženklai: pranešimų, kambarių kūrimas, pakartotinių prisijungimų, pakartotinių bandymų, klaidų valdymas.
• LEDŲ/APSVAIGINIMO/APSIJUNGIMO valdymasDislokuoti serverius, stebėti TURN naudojimą (kuris naudoja pralaidumą), koreguoti skirtojo laiko limitus.
• Paslaugos kokybė (QoS): pritaikyti bitų spartą, valdyti nestabilius tinklus, derinti kodekus, aptikti ryšio pablogėjimą ir reaguoti.
• mastelį: pereiti nuo paprasto P2P prie grupių, o vėliau prie šimtų vartotojų, įdiegti SFU arba medijos serverius nepažeidžiant originalaus dizaino.
• Suderinamumas entre navegadoresNors situacija gera, vis tiek rasite niuansų. adapteris.js Vis dar labai rekomenduojama.

Mažame šalutiniame projekte „Node“ serverio nustatymas su „Socket.IO“ ir viešu STUN gali pakakti individualiems skambučiams arba labai mažoms grupėms. Tačiau jei jūsų idėja auga ir jums reikia didelė miniaNesvarbu, ar tai būtų puiki kokybės kontrolė, įrašai, analizė, transkripcijos ar monetizavimas, netrukus turėsite apsvarstyti arba įtraukti nuosavas medijos serverisarba pereiti prie specializuoto tiekėjo.

Realaus laiko CDN su SDK: „Agora“, „Twilio“, „Mux“, „ZEGOCLOUD“…

Paslaugos kaip Agora, Twilio, Mux, ZEGOCLOUD arba panašios technologijos sukuria vertės sluoksnį ant „WebRTC“, kuris sutaupo jums mėnesių darbo ir daugybę galvos skausmų:

• jie jums siūlo a pasaulinis žiniasklaidos tinklas su visame pasaulyje paskirstytais SFU, optimizuotais mažam delsos laikui.
• Santrauka STUN/APSUKIMAS, signalizavimas, pakartotiniai bandymai, pakartotiniai prijungimai ir sudėtingas tinklo valdymas.
• Jie apima gerai prižiūrimus SDK, skirtus žiniatinklis, „iOS“, „Android“, „React Native“ ir kiti karkasai.
• Jie teikia papildomas paslaugas, pvz. įrašymas, transliavimas į RTMP/HLS, moderavimas, statistika realiuoju laiku, kokybės kontrolė, vartotojų vaidmenys (vedėjas, auditorija, pranešėjas) ir kt.

Kaina, kaip tikriausiai įtariate, yra pagrindinė problema: jei turite bent šiek tiek pinigų daug minučių vaizdo įrašo Arba, esant dideliam skaičiui vienu metu naudojamų vartotojų, sąskaita staiga išauga. Be to, jūs tampate priklausomi nuo jų platformos ir jos kainos ar API pokyčių.

Jūsų konkrečioje situacijoje, turėdami didelę patirtį Realaus laiko „JavaScript“Protingas pasirinkimas yra pradėti nuo SDK, kad paspartintumėte kūrimą, patvirtintumėte produktą ir sužinotumėte apie jo patalpų modelį, vaidmenis, srauto gyvavimo ciklą ir būsenos valdymą. Vėliau, jei projektas įsibėgės ir kaina taps problema, galėsite palaipsniui perkelti sprendimo dalis į patikimesnę platformą. patentuota WebRTC infrastruktūra arba pasikliauti „Flussonic“ tipo medijos serveriu, kad valdytų platinimo sluoksnį.

Geriausia WebRTC derinimo praktika ir įrankiai

Kad nepasiklystumėte „WebRTC“ juodojoje dėžėje, patartina pasikliauti naršyklėse ir ekosistemoje jau esančiais įrankiais:

• chromas: // webrtc-vidiniai (o apie:webrtc (naršyklėje „Firefox“): skydelis su išsamia jungčių, bitų spartos, paketų praradimo, aktyvių kodekų ir kt. statistika.
• adapteris.js: bendruomenės prižiūrimas tarpinis elementas, kuris išlygina skirtumus tarp naršyklių ir versijų.
• test.webrtc.org: norint patikrinti kameros, mikrofono, tinklo ir bendrą suderinamumą įrenginyje.
• Oficialūs pavyzdžiai webrtc.github.io/samples: apribojimų, tarpusavio ryšių, duomenų kanalų, ekrano bendrinimo pavyzdžiai... labai naudingi kopijuojant šablonus.

Taip pat gera idėja kodą struktūrizuoti aiškiai atskiriant signalizacijos sluoksnis (lizdai, kambariai, pranešimai) sluoksnio Grynas WebRTC (ryšio kūrimas, srauto valdymas, įvykių tvarkyklės). Tai leidžia pakeisti signalizacijos serverį arba medijos serverį neperrašant visos kliento logikos.

Susijęs straipsnis:

„Android“ ir „Linux“: geriausios „KDE Connect“ alternatyvos

Turint visa tai, kas išdėstyta aukščiau, šalutiniam projektui, kuris tik prasideda ir kuriame jūs taip vertinate vystymosi laikas kaip vidutinės trukmės išlaidosLabiausiai subalansuota strategija paprastai yra pradėti nuo realaus laiko SDK, pagrįsto „WebRTC“, kuris leidžia greitai iteruoti „React“ / „React Native“, internalizuoti, kaip jie tvarko vaidmenis, sesijas, srauto gyvavimo ciklą ir tiesiogines būsenas, ir lygiagrečiai gilintis į „WebRTC“ „iš esmės“ (getUserMedia, RTCPeerConnection, RTCDataChannel, signalizacija naudojant Node+Socket.IO, STUN/TURN, SFU), kad nebūtumėte amžinai pririšti prie vienos platformos ir galėtumėte pereiti prie labiau pritaikyto sprendimo, kai produktas tai pateisina.