Videokõned ja reaalajas voogedastus WebRTC ja SDK-dega

Kui sa ehitad JavaScripti kõrvalprojekt Ja kui vajate videokõnesid, on normaalne, et teil on kahtlusi: kas peaksin kasutama puhast WebRTC-d, SDK-d nagu Agora, Twilio, Mux või Zegocloud või otsustama React Native'is RN-WebRTC kasuks? Halb uudis on see, et ühest lahendust pole. Hea uudis on see, et te mõistate reaalajas JavaScripti, mis annab teile ideaalse positsiooni teadliku otsuse tegemiseks ja arhitektuuri sassi ajamise vältimiseks.

Järgmistes ridades näete samm-sammult, kuidas see toimib WebRTC seesMilline roll on Agoral (ja teistel sarnastel pakkujatel)? Mida tähendab oma infrastruktuuri loomine (STUN/TURN, signaalimine, SFU, meediaserverid...)? Ja millised on tegelikud kompromissid videokõnede ja reaalajas voogesituse kulude, keerukuse ja skaleeritavuse vahel?

Mis on WebRTC ja miks see on kõige alus?

WebRTC (veebi reaalajas suhtlus) See on avatud lähtekoodiga standardite, API-de ja protokollide kogum, mis võimaldab reaalajas heli, video ja andmete voogesitust otse brauserist või natiivrakendusest ilma pistikprogrammide või väliste rakendusteta. See on standardiseeritud W3C ja IETF-i poolt ning seda toetavad kõik tänapäevased brauserid: Chrome, Firefox, Safari, Edge, Opera ja paljud mobiilibrauserid.

Nende filosoofia on selge: võimaldada suhtlust peer-to-peer (P2P) kasutajate vahel väga madala latentsusega, lahendades kõik ebamugavad võrguprobleemid – koodekid, värin, kaja, pakettide kadu, krüptimine jne – kulisside taga. See hõlmab kõike alates kahest videokõnest kuni süsteemini interaktiivne voogesitus sadade või tuhandete pealtvaatajatega, kui see ühendada õige infrastruktuuriga.

Seotud artikkel:

Kuidas Androidis helistamisrakendust kasutada ja luua: ülim juhend kasutajatele ja arendajatele

Peamised WebRTC API-d: getUserMedia, RTCPeerConnection ja RTCDataChannel

WebRTC tugineb kolmele peamisele brauseripoolsele API-le, mida te kindlasti kasutate, olenemata sellest, kas loote oma lahenduse või kasutate SDK-d nagu Agora:

• Meediavoog / getUserMedia: video ja heli jäädvustamiseks (kaamera, mikrofon ja isegi ekraan või vahekaardid).
• RTCPeerConnection: audio- ja videovoogude omavaheliseks läbirääkimiseks ja edastamiseks.
• RTCDataChannel: suvaliste andmete (teksti, binaarfailide, failide) saatmiseks klientide vahel madala latentsusega.

koos getUserMedia Saate taotleda brauseri juurdepääsu kaamerale ja mikrofonile ning saada vastuse. MediaStream mille seejärel seostate elemendiga <video> koos video.srcObject = stream. Saate kandideerida piiranguid (eraldusvõime, kaadrisagedus, esi-/tagakaamera jne) ja kui need tingimused ei ole täidetud, saate selliseid vigu nagu OverconstrainedErrormille puhul peate suutma pakkuda alternatiive (näiteks vähendamine 1080p-lt 720p-le ja kohanduste rakendamine vastavalt parandage mikrofoni heli).

API rakendus RTCPeerConnection See on kõnede süda: see tegeleb SDP (pakkumine/vastus) läbirääkimistega, ICE (uimastamine/pööramine) kandidaatide kogumisega, ühenduse loomisega ja turvalise edastusega SRTP kaudu. Oma koodist saate lihtsalt ühenduse luua, meediarajad lisada ja sündmustele reageerida, näiteks onicecandidate u ontrack ja sina hoolitsed siltide eest.

Lõpuks RTCDataChannel See võimaldab teil seadistada andmekanaleid sarnaselt WebSocketiga, kuid punkt-punktina ning täpsusega kontrollides usaldusväärsust ja järjekorda. See on kasulik videovestluseks, failide jagamiseks, mängu oleku sünkroonimiseks või reaalajas koostööks. Süntaks on tuttav: dataChannel.send() y onmessage vastuvõtjas.

Signaalimine: „liim”, mida WebRTC ei defineeri

Tüüpiline arusaamatus: WebRTC ei sisalda silteRTCPeerConnection peab vahetama teavet, kuid ei dikteeri, kuidas seda teha. Selle peate ise defineerima või saab selle teie eest abstraktselt esitada kolmanda osapoole SDK.

Paarid saadetakse signaalimise teel:

• Seansi juhtimise sõnumid: kõne alustamine, kõne katkestamine, vead.
• Teave võrgu kohtaICE kandidaadid (avastatud IP-aadressid/pordid).
• Meedia metaandmedSDP pakub ja vastab koos koodekite, resolutsioonide jms-ga.

See märgistus rakendatakse tavaliselt koos WebSocketsSocket.IO, HTTP (küsitlus/pikk küsitlus), MQTT või muud kahesuunalised mehhanismid. Väga tüüpiline muster on Node.js server, millel on Socket.IO mis haldab "ruume" ja edastab sõnumeid teksti/JSON-tüüp klientide vahel:

Serversaab create or joinSee loob toa, kui seda pole olemas, toetab kuni kahte klienti (tavalise videokõne jaoks) ja edastab sõnumeid. message ruumi teiste pistikupesadega. Teie vastutate selle eest, et te ei ületaks maksimaalset kasutajate arvu või kujundaksite oma ruumi loogika.

KlientLehe laadimisel küsib see toa nime (või tuletab selle URL-ist) ja väljastab create or joinKuula selliseid sündmusi nagu created, joined, full, ready ja lepib teise osapoolega kokku kõne algatamise või tagasilükkamise.

See muster sobib ideaalselt prototüüp või kõrvalprojektSee annab sulle kerge signaaliserveri, mida saad vajadusel klastrite ja koormuse tasakaalustajatega skaleerida.

STUN, TURN, ICE: NAT-idest ja tulemüüridest läbi saamine ilma hulluks minemata

Ideaalmaailmas oleks kaks kasutajat alati ligipääsetavates võrkudes ja ühenduksid otse. Tegelikkuses on NAT-id, tulemüürid, CGNAT internetiteenuse pakkujatelt ja paranoilistelt ettevõtete võrkudelt. Siin tulebki mängu ICE, mis ühendab STUN-i ja TURN-i.

• URMASTUS (Session Traversal Utilities for NAT) võimaldab kliendil teada saada oma Avalik IP ja portSTUN-server vastab ainult selle teabega.
• Pöörake (Traversal Using Relays around NAT) toimib järgmiselt edastusserver meediast, kui otsest P2P-kanalit pole võimalik avada. Heli/video liiklus läbib seda, seega tarbib see serveri ribalaiust ja on kulukas.
• ICE (Interactive Connectivity Establishment) vastutab kõigi võimalike kandidaatide (kohalikud aadressid, mida kajastavad STUN ja TURN releed) testimise eest, kuni leitakse sobiv marsruut.

Praktikas lisate oma RTCPeerConnectioni konfiguratsiooniobjekti massiivi jääServerid STUN/TURN URI-de abil teeb brauser ülejäänu. Kui seadistate oma infrastruktuuri, peate oma STUN/TURN serverid juurutama ja haldama; kui kasutate SDK-d nagu Agora, Twilio või Zegocloud, on see neil juba lahendatud ja tootmiskeskkonnaks valmis.

Madala latentsusega reaalajas voogesitus: WebRTC vs HLS/DASH

Kui me räägime otseülekanne On kaks erinevat maailma: HTTP-põhised protokollid (HLS, DASH) ja WebRTC. HLS/DASH toimivad kliendilt videosegmentide allalaadimise ja esitamise teel; see sobib ideaalselt CDN-i kaudu skaleeritavaks toimimiseks, kuid see toob kaasa ka mitme sekundi pikkused latentsusajad (kergesti 5–30 sekundit).

WebRTC seevastu kasutab UDP + RTP ja edastab video allikast pleierile "push" režiimis, väga lühikese käivitusaja ja tüüpiliste latentsusaegadega allpool 500 ms (sageli ~250 ms), kui võrk on hea. See saavutatakse tänu:

• Ummikute kontroll integreeritud, mis reguleerib bitikiirust ja eraldusvõimet reaalajas vastavalt pakettide kadumisele, värinale või RTT-le.
• Tõhusate koodekite (VP8, VP9, ​​​​H.264; üha enam AV1) kasutamine koos riistvaraline kiirendus kui see on saadaval.
• Võimalus kasutada SVC-d (skaleeritavat videokodeerimist), nii et vastuvõtja võtab vastu ainult neid kihte, mida tema võrk/seade toetab.

Seetõttu on WebRTC loomulik valik reaalajas oksjonid, otseülekandega spordiennustused, kauplemine, interaktiivsed mängud, kaugtugi, telemeditsiin, osaluspõhised virtuaalsed klassiruumid või finantsarmatuurlauad, mis ei saa endale lubada mitmesekundilist viivitust.

Probleem on selles, et puhas P2P WebRTC ei skaleeru hästi tuhandete vaatajateni; selleks on vaja SFU-d, meediaserverid või hübriidplatvormidja just siin tulevadki mängu sellised lahendused nagu Flussonic, Agora või sarnased.

P2P-st kaugemale ulatuv skaleerimine: SFU-d, meediaserverid ja hübriidarhitektuurid

Üks-ühele videokõnes töötab WebRTC laitmatult. Aga kui hakkate lisama 10, 20 või 100 kasutajat, siis asjad muutuvad: iga klient peab saatma/vastu võtma mitu voogu, selle protsessor kuumeneb üle ja võrk jookseb kokku. Siin ilmneb kolm klassikalist mustrit:

• MCU (mitmepunktiline juhtseade)Server võtab vastu kõik voogedastused, miksib need ja saadab igale kliendile ühe voo. Eelis: kliendi väike ressursitarbimine. Puudused: suur serverikoormus, vähem individuaalset kvaliteedikontrolli.
• SFU (selektiivne edasisuunamisüksus)Server võtab vastu vooge ja edastab need valikuliselt, neid segamata. Iga vaataja saab vajalikud voogedastused, võimalik, et erineva kvaliteediga. See on tänapäeval kõige sagedamini kasutatav muster mitme kasutajaga videokonverents ja skaleeritav interaktiivne voogedastus.
• Hübriidsed arhitektuurid WebRTC + HLS/DASHWebRTC-d kasutatakse vastuvõtmiseks ja interaktsiooniks, samas kui HLS/DASH levitab seda suurele publikule, kes ei vaja reaalajas interaktsiooni. See on tasakaal järgmise vahel: ülimadal latentsusaeg „näitlejatele“ ja tohutu skaleeritavus „pealtvaatajatele“.

Meediaserverid, näiteks Flusooniline Teised pakuvad vajalikku taustasüsteemi: nad võtavad vastu WebRTC voo, vajadusel transkodeerivad selle, edastavad selle WebRTC kaudu teistele klientidele või teisendavad selle massiliseks levitamiseks HLS-tüüpi protokollideks. Selline infrastruktuur muudab praktikas teostatavaks üks-ühele kõnedest kaugemale minemise ilma jalgratast leiutamata.

Tüüpilised kasutusjuhud: videokõned, voogedastus, asjade internet ja palju muud

WebRTC on muutunud kõikjalolevaks ja te kasutate seda tõenäoliselt iga päev, seda ise teadvustamata. Mõned näited, kus see eriti hästi sobib, on... videokõned ja videokonverentsid:

• Videokõned ja videokonverentsidGoogle Meet, Jitsi, Slack, Microsoft Teams ja paljud teised tööriistad toetuvad video, heli ja ekraani jagamiseks WebRTC-le (osaliselt või täielikult).
• Reaalajas voogedastusteenusedPlatvormid nagu Twitch, Meta Live, Vimeo Livestream või tööriistad nagu Streamyard kombineerivad WebRTC-d ingesti jaoks ja teisi tehnoloogiaid massiliseks levitamiseks.
• Vestlus ja sõnumid failide jagamisegaTänu RTCDataChannelile saate reaalajas vestelda, faile jagada, olekut sünkroonida jne ilma kesksete meediaserveriteta.
• Pilvemängud ja mitmikmängTeenused nagu GeForce NOW või Xbox Cloud Gaming kasutavad interaktiivse video jaoks sarnaseid tehnoloogiaid; paljud P2P-mängud kasutavad mängu sünkroonimiseks WebRTC-d.
• Asjade internet ja seireNutikaamerad, beebimonitorid, video uksekellad või droonid saavad saata reaalajas video mobiilseadmetesse ja brauseritesse, mis kasutavad WebRTC-d.
• Haridus ja telemeditsiinvirtuaalsed klassiruumid tahvlite, viktoriinide ja kahesuunalise videoga või veebipõhised meditsiinikonsultatsioonid, kus latentsus ja turvalisus on üliolulised.

WebRTC turvalisus: krüptimine, õigused ja parimad tavad

WebRTC turvalisus ei ole lisafunktsioon: see on sisse ehitatud. disainist alates integreeritudKõik meediakomponendid on krüpteeritud ja API-d töötavad ainult turvalistest allikatest (HTTPS või localhost), kuigi soovitatav on olla valvas. pettused videokõnede kaudu.

• DTLS (Datagrammi transpordikihi turvalisus) krüpteerib edastatavaid andmeid.
• SRTP (Secure Real-time Transport Protocol) kaitseb heli ja videot nii, et neid ei oleks lihtne manipuleerida ega pealt kuulata.
• Juurdepääs kaamera ja mikrofon See nõuab selgesõnalist kasutajaluba koos nähtavate visuaalsete indikaatoritega (ikoonid, värvilised punktid jne).
• Kuna pole vaja pluginaid installida, on oht, et pahatahtlikku tarkvara varjatud kolmandate osapoolte laiendustesse või binaarfailidesse.

Sellegipoolest peate oma kihi eest ise hoolitsema: kasutage HTTPS kogu ulatusesVaadake üle taotletud õigused, hoidke brauserid ja teegid ajakohasena ning ärge unustage oma signaaliserveri või REST API-de turvalisust.

WebRTC vs muud tehnoloogiad: VoIP, WebSockets ja patenteeritud platvormid

Kui tuled traditsioonilise VoIP-i maailmast, siis oled tuttav SIP-i, PBX-i, tarkvaratelefonide ja kallite serveritega. WebRTC muudab paradigmat: sa ei pea kasutajalt mingit teavet nõudma. lauaarvuti klient Spetsiifilist riistvara pole vaja; piisab brauserist ja suhteliselt lihtsast signaaliserverist.

Versus Traditsiooniline VoIPWebRTC vähendab põhiinfrastruktuuri koormust ja avab ukse otse veebi integreeritud rakendustele. Paljudel juhtudel saate oma SIP-taustaserverit taaskasutada lüüside kaudu, mis teisendavad signaalimise WebRTC-ks.

Seoses WebSocketsNeid tuleks vaadelda pigem teineteist täiendavatena: need sobivad ideaalselt teavituste, kerge vestluse või olekuvärskenduste jaoks, kuid mitte intensiivse meedia jaoks. WebRTC on optimeeritud reaalajas heli/videoummikute kontrolli, koodekite, jitter-puhvri jms abil. Praktikas kasutavad paljud projektid signaalimiseks WebSocketsi ja meedia edastamiseks WebRTC-d.

Kui võrrelda neid platvormidega nagu Zoom, GoToMeeting või WebExErinevus seisneb mudelis: need tööriistad on suletud lahendused, sageli kohustuslike töölauarakenduste ja patenteeritud taustsüsteemiga. WebRTC seevastu on baastehnoloogia; saate selle peale luua oma "mini-Meeti" või integreerida teenustega, mis seda juba kasutavad (nt Google Meet või Microsoft Teams).

WebRTC-ga arendamine: tegelik keerukus ja levinud lõksud

Kuigi API-d tunduvad paberil lihtsad, on WebRTC nullist rakendamine keerulisem. Peate tegelema järgmisega:

Seotud artikkel:

Tor-brauser Androidile: täpsemad seaded ja turvaline kasutamine

• Kohandatud sildid: sõnumite ja ruumide kujundamine, taasühendumiste haldamine, uuestikatsed, vead.
• JÄÄ/UIMASTAMISE/PÖÖRDUMISE haldamineJuurutage servereid, jälgige TURN-i kasutust (mis tarbib ribalaiust), reguleerige ajalõpusid.
• Teenuse kvaliteet (QoS): bitikiiruste kohandamine, ebastabiilsete võrkudega toimetulek, koodekite üle läbirääkimiste pidamine, ühenduse halvenemise tuvastamine ja reageerimine.
• Skaleerimine: liikuda lihtsalt P2P-lt gruppidele, seejärel sadadele kasutajatele, tutvustada SFU-sid või meediaservereid ilma algset disaini rikkumata.
• Ühilduv entre navegadoresKuigi olukord on hea, leiate ikkagi nüansse. Kasutage adapter.js See on endiselt väga soovitatav.

Väikeses kõrvalprojektis võib Socket.IO ja avaliku STUN-iga sõlmeserveri seadistamine olla piisav 1:1 kõnede või väga väikeste gruppide jaoks. Aga kui teie idee kasvab ja vajate suur rahvahulkOlgu tegemist peene kvaliteedikontrolli, salvestiste, analüüsi, transkriptsioonide või raha teenimisega, peate peagi kaaluma või kaasama oma meediaservervõi pöörduda spetsialiseeritud teenusepakkuja poole.

Reaalajas CDN SDK-dega: Agora, Twilio, Mux, ZEGOCLOUD…

Teenused nagu Agora, Twilio, Mux, ZEGOCLOUD või sarnased tehnoloogiad loovad WebRTC peale väärtuskihi, mis säästab teie tööd kuude kaupa ja lugematuid peavalusid:

• nad pakuvad teile a globaalne meediavõrgustik SFU-dega, mis on jaotatud üle maailma ja optimeeritud madala latentsuse saavutamiseks.
• Abstraktne UIMASTAMINE/PÖÖRAMINE, signaalimine, uuesti proovimine, taasühendamised ja keerukas võrguhaldus.
• Nende hulka kuuluvad hästi hooldatud SDK-d järgmistele rakendustele: veeb, iOS, Android, React Native ja muud raamistikud.
• Nad pakuvad lisateenuseid, näiteks salvestamine, edastamine RTMP/HLS-i, modereerimine, reaalajas statistika, kvaliteedikontroll, kasutajarollid (võõrustaja, publik, esineja) jne.

Nagu te ilmselt kahtlustate, on peamine probleem hind: kui teil on isegi natuke raha mitu minutit videot Või kui samaaegseid kasutajaid on palju, siis arve tõuseb hüppeliselt. Lisaks muutute sõltuvaks nende platvormist ja selle hinnast või API muutustest.

Teie konkreetses olukorras, omades tugevaid kogemusi Reaalajas JavaScriptMõistlik variant on alustada SDK-ga, et kiirendada arendust, valideerida toodet ning õppida tundma selle ruumimudelit, rolle, voo elutsüklit ja olekuhaldust. Hiljem, kui projekt hoo sisse saab ja maksumusest saab probleem, saab lahenduse osi järk-järgult migreerida vastupidavamale platvormile. patenteeritud WebRTC infrastruktuur või tugineda jaotuskihi juhtimiseks Flussonic-tüüpi meediaserverile.

WebRTC silumise parimad tavad ja tööriistad

WebRTC musta kasti sattumise vältimiseks on soovitatav toetuda brauserites ja ökosüsteemis juba olemasolevatele tööriistadele:

• kroom: // webrtc-sisemine (o about:webrtc (Firefoxis): paneel ühenduste, bitikiiruste, pakettide kadumise, aktiivsete koodekite jms üksikasjaliku statistikaga.
• adapter.js: kogukonna hallatav shim, mis silub brauserite ja versioonide vahelisi erinevusi.
• test.webrtc.org: kaamera, mikrofoni, võrgu ja üldise ühilduvuse kontrollimiseks masinas.
• Ametlikud proovid aadressil webrtc.github.io/samples: näited piirangutest, partnerühendustest, andmekanalitest, ekraani jagamisest… väga kasulikud mustrite kopeerimiseks.

Samuti on hea mõte kood struktureerida, eraldades selgelt signaalikiht kihi (pistikupesad, ruumid, sõnumid) Puhas WebRTC (ühenduse loomine, voogesituse haldamine, sündmuste käitlejad). See võimaldab teil signaalimise taustsüsteemi või meediaserveri asendada ilma kogu kliendiloogikat ümber kirjutamata.

Seotud artikkel:

Android ja Linux: KDE Connecti parimad alternatiivid

Kui kõik eelnev on olemas, siis kõrvalprojekti jaoks, mis alles algab ja kus sa hindad seda nii kõrgelt arendusaeg kui keskpika perioodi kuluKõige tasakaalustatum strateegia on tavaliselt alustada WebRTC-l põhineva reaalajas SDK-ga, mis võimaldab teil React/React Native'is kiiresti itereerida, sisestada, kuidas nad rolle, seansse, voogedastuse elutsüklit ja reaalajas olekuid käsitlevad, ning paralleelselt süveneda WebRTC-sse "naha kaupa" (getUserMedia, RTCPeerConnection, RTCDataChannel, signaalimine Node+Socket.IO, STUN/TURN, SFU abil), et mitte olla igaveseks seotud ühe platvormiga ja oleks võimalik hüpata kohandatud lahendusele, kui toode seda õigustab.