Panggilan video dan penstriman masa nyata dengan WebRTC dan SDK

Jika anda sedang membina sebuah Projek sampingan JavaScript Dan jika anda memerlukan panggilan video, adalah perkara biasa untuk mempunyai keraguan: Patutkah saya menggunakan WebRTC tulen, SDK seperti Agora, Twilio, Mux atau Zegocloud, atau menggunakan RN-WebRTC sepenuhnya dalam React Native? Berita buruknya ialah tiada penyelesaian tunggal. Berita baiknya ialah anda memahami JavaScript masa nyata, yang meletakkan anda dalam kedudukan yang ideal untuk membuat keputusan termaklum dan mengelakkan daripada merosakkan seni bina.

Dalam baris berikut, anda akan melihat, langkah demi langkah, bagaimana ia berfungsi WebRTC Di DalamApakah peranan yang dimainkan oleh Agora (dan penyedia lain yang serupa)? Apakah maksudnya untuk menyediakan infrastruktur anda sendiri (STUN/TURN, signaling, SFU, pelayan media…)? Dan apakah pertukaran sebenar antara kos, kerumitan dan kebolehskalaan untuk panggilan video dan penstriman masa nyata?

Apakah WebRTC dan mengapa ia menjadi asas kepada segala-galanya?

WebRTC (Komunikasi Masa Nyata Web) Ia merupakan satu set piawaian, API dan protokol sumber terbuka yang membolehkan penstriman audio, video dan data masa nyata terus daripada pelayar atau aplikasi natif, tanpa pemalam atau aplikasi luaran. Ia diseragamkan oleh W3C dan IETF dan disokong oleh semua pelayar moden: Chrome, Firefox, Safari, Edge, Opera dan banyak pelayar mudah alih.

Falsafah mereka jelas: untuk membolehkan komunikasi rakan sebaya (P2P) antara pengguna dengan kependaman yang sangat rendah, mengendalikan semua isu rangkaian yang menyusahkan—codec, jitter, gema, kehilangan paket, penyulitan, dsb.—di sebalik tabir. Ini termasuk segala-galanya daripada panggilan video satu sama satu kepada sistem penstriman interaktif dengan ratusan atau ribuan penonton jika anda menggabungkannya dengan infrastruktur yang betul.

artikel berkaitan:

Cara Menggunakan dan Membuat Apl Panggilan pada Android: Panduan Terbaik untuk Pengguna dan Pembangun

API WebRTC Utama: getUserMedia, RTCPeerConnection dan RTCDataChannel

WebRTC bergantung pada tiga API sisi pelayar utama yang pasti akan anda gunakan, sama ada anda membina penyelesaian anda sendiri atau menggunakan SDK seperti Agora:

• MediaStream / dapatkanPenggunaMedia: untuk merakam video dan audio (kamera, mikrofon dan juga skrin atau tab).
• RTCPeerConnection: untuk berunding dan mengangkut strim audio dan video antara rakan sebaya.
• RTCDataChannel: untuk menghantar data sewenang-wenangnya (teks, binari, fail) dengan kependaman rendah antara klien.

dengan getUserMedia Anda boleh meminta akses pelayar ke kamera dan mikrofon dan menerima MediaStream yang kemudiannya anda kaitkan dengan elemen <video> dengan video.srcObject = stream. Anda boleh memohon sekatan (resolusi, kadar bingkai, kamera hadapan/belakang, dll.) dan, jika ini tidak dipenuhi, anda akan mendapat ralat seperti OverconstrainedErroryang mana anda mesti uruskan untuk menawarkan alternatif (contohnya, mengecilkan saiz daripada 1080p kepada 720p dan menggunakan pelarasan untuk tingkatkan audio mikrofon).

API dari RTCPeerConnection Ia merupakan inti pati panggilan: ia mengendalikan rundingan SDP (tawaran/respons), pengumpulan calon ICE (pengecutan/pusingan), penubuhan sambungan dan penghantaran selamat melalui SRTP. Daripada kod anda, anda hanya perlu mencipta sambungan, menambah trek media dan bertindak balas terhadap peristiwa seperti onicecandidate u ontrack dan awak uruskan papan tanda tu.

Akhirnya, RTCDataChannel Ia membolehkan anda menyediakan saluran data yang serupa dengan WebSocket, tetapi dari titik ke titik dan dengan kawalan yang ditala dengan baik ke atas kebolehpercayaan dan susunan. Ia berguna untuk sembang dalam video, perkongsian fail, penyegerakan keadaan permainan atau kerjasama masa nyata. Sintaksnya biasa: dataChannel.send() y onmessage dalam penerima.

Isyarat: "gam" yang tidak ditakrifkan oleh WebRTC

Satu salah faham biasa: WebRTC tidak termasuk papan tandaRTCPeerConnection perlu bertukar maklumat, tetapi ia tidak menentukan caranya. Anda perlu mentakrifkannya sendiri, atau SDK pihak ketiga boleh mengabstrakkannya untuk anda.

Pasangan dihantar melalui isyarat:

• Mesej kawalan sesi: mulakan panggilan, tutup panggilan, ralat.
• Maklumat rangkaian: Calon ICE (alamat/port IP yang ditemui).
• Metadata media: Tawaran dan respons SDP dengan codec, resolusi, dsb.

Papan tanda ini biasanya dilaksanakan dengan Soket WebSocket.IO, HTTP (polling/long-polling), MQTT atau mekanisme dwiarah yang lain. Corak yang sangat tipikal ialah pelayan Node.js dengan Soket.IO yang mengurus "bilik" dan menghantar mesej jenis teks/JSON antara pelanggan:

Server: menerima create or joinIa mewujudkan bilik jika tiada, menyokong sehingga dua klien (untuk panggilan video asas) dan menghantar mesej. message ke soket lain di dalam bilik. Anda bertanggungjawab untuk tidak melebihi bilangan pengguna maksimum atau mereka bentuk logik bilik anda sendiri.

PelangganApabila memuatkan halaman, ia meminta nama bilik (atau menyimpulkannya daripada URL), ia memancarkan create or joinDengar acara seperti created, joined, full, ready dan bersetuju dengan pihak yang satu lagi untuk memulakan atau menolak panggilan tersebut.

Corak ini sesuai untuk prototaip atau projek sampinganIa memberi anda pelayan isyarat ringan yang boleh anda skalakan dengan kluster dan pengimbang beban jika perlu.

STUN, PUTAR, AIS: Melepasi NAT dan tembok api tanpa menjadi gila

Dalam dunia yang ideal, dua pengguna akan sentiasa berada di rangkaian yang boleh diakses dan berhubung secara langsung. Dalam dunia sebenar, terdapat NAT, tembok api, CGNAT daripada ISP dan rangkaian korporat paranoid. Di sinilah ICE memainkan peranan, menggabungkan STUN dan TURN.

• MENYEBABKAN PENGSAN (Utiliti Sesi Traversal untuk NAT) membolehkan klien mengetahui IP dan port awamPelayan STUN hanya akan bertindak balas dengan maklumat tersebut.
• TUKAR (Traversal Menggunakan Relay di sekitar NAT) bertindak sebagai pelayan geganti media apabila tiada cara untuk membuka saluran P2P secara langsung. Trafik audio/video melaluinya, jadi ia menggunakan lebar jalur pelayan dan memerlukan wang.
• ICE (Penubuhan Ketersambungan Interaktif) bertanggungjawab untuk menguji semua calon yang mungkin (alamat setempat, yang dicerminkan oleh STUN, geganti TURN) sehingga laluan yang berdaya maju ditemui.

Dalam praktiknya, dalam objek konfigurasi RTCPeerConnection anda, anda menambah tatasusunan Pelayan ais Dengan URI STUN/TURN, pelayar akan melakukan selebihnya. Jika anda menyediakan infrastruktur anda sendiri, anda perlu menggunakan dan menyelenggara pelayan STUN/TURN anda; jika anda menggunakan SDK seperti Agora, Twilio atau Zegocloud, mereka telah pun menyelesaikannya dan sedia untuk pengeluaran.

Penstriman masa nyata latensi rendah: WebRTC vs HLS/DASH

Apabila kita bercakap tentang siaran langsung Terdapat dua dunia yang berbeza: protokol berasaskan HTTP (HLS, DASH) dan WebRTC. HLS/DASH berfungsi dengan memuat turun dan memainkan segmen video daripada klien; ini sesuai untuk kebolehskalaan melalui CDN, tetapi ia memperkenalkan latensi beberapa saat (5-30 saat dengan mudah).

WebRTC, sebaliknya, menggunakan UDP + RTP dan menghantar video dalam mod "tolak" dari sumber kepada pemain, dengan masa permulaan yang sangat singkat dan latensi biasa di bawah ms 500 (selalunya ~250 ms) jika rangkaiannya bagus. Ia mencapai matlamat ini hasil daripada:

• Kawalan kesesakan bersepadu, yang melaraskan kadar bit dan resolusi dalam masa nyata mengikut kehilangan paket, jitter atau RTT.
• Penggunaan codec yang cekap (VP8, VP9, ​​​​H.264; semakin AV1) dengan pecutan perkakasan apabila tersedia.
• Kemungkinan menggunakan SVC (Pengekodan Video Berskala) supaya penerima hanya menerima lapisan yang boleh disokong oleh rangkaian/perantinya.

Itulah sebabnya WebRTC merupakan pilihan semula jadi untuk lelongan masa nyata, pertaruhan sukan langsung, perdagangan, permainan interaktif, sokongan jarak jauh, teleperubatan, bilik darjah maya penyertaan atau papan pemuka kewangan yang tidak mampu menanggung kelewatan beberapa saat.

Masalahnya ialah WebRTC P2P tulen tidak berskala baik kepada beribu-ribu penonton; untuk itu anda perlukan SFU, pelayan media atau platform hibriddi sinilah penyelesaian seperti Flussonic, Agora atau yang serupa digunakan.

Penskalaan melangkaui P2P: SFU, pelayan media dan seni bina hibrid

Dalam panggilan video satu lawan satu, WebRTC berfungsi dengan sempurna. Tetapi jika anda mula menambah 10, 20 atau 100 pengguna, keadaan akan berubah: setiap klien perlu menghantar/menerima berbilang strim, CPUnya menjadi terlalu panas dan rangkaian akan ranap. Tiga corak klasik muncul di sini:

• MCU (Unit Kawalan Berbilang Titik)Pelayan menerima semua strim, mencampurkannya, dan menghantar satu strim kepada setiap klien. Kelebihan: penggunaan sumber yang rendah pada klien. Kelemahan: beban pelayan yang berat, kawalan kualiti individu yang kurang.
• SFU (Unit Penghantaran Selektif)Pelayan menerima strim dan menghantarnya secara selektif tanpa mencampurkannya. Setiap penonton menerima strim yang mereka perlukan, mungkin dalam kualiti yang berbeza. Ini adalah corak yang paling biasa digunakan hari ini untuk persidangan video berbilang pengguna dan penstriman interaktif yang boleh diskala.
• Seni bina hibrid WebRTC + HLS/DASHWebRTC digunakan untuk pengingesan dan interaksi, manakala HLS/DASH diedarkan kepada khalayak ramai yang tidak memerlukan interaksi masa nyata. Ia merupakan keseimbangan antara kependaman ultra rendah untuk "pelakon" dan skalabiliti besar-besaran untuk "penonton".

Pelayan media seperti Flussonik Yang lain menyediakan bahagian belakang yang diperlukan: mereka menerima strim WebRTC, mentranskodkannya jika perlu, menghantarnya melalui WebRTC kepada klien lain atau menukarnya kepada protokol jenis HLS untuk pengedaran besar-besaran. Infrastruktur jenis ini, dalam praktiknya, menjadikannya berdaya maju untuk melangkaui panggilan satu sama lain tanpa perlu mencipta semula roda.

Kes penggunaan biasa: panggilan video, penstriman, IoT dan banyak lagi

WebRTC telah menjadi kebiasaan, dan anda mungkin menggunakannya setiap hari tanpa menyedarinya. Beberapa contoh di mana ia sangat sesuai ialah... panggilan video dan persidangan video:

• Panggilan video dan persidangan videoGoogle Meet, Jitsi, Slack, Microsoft Teams dan banyak lagi alatan lain bergantung pada WebRTC (sebahagian atau sepenuhnya) untuk perkongsian video, audio dan skrin.
• Perkhidmatan penstriman masa nyataPlatform seperti Twitch, Meta Live, Vimeo Livestream atau alatan seperti Streamyard menggabungkan WebRTC untuk ingest dan teknologi lain untuk pengedaran besar-besaran.
• Sembang dan pesanan dengan perkongsian failTerima kasih kepada RTCDataChannel, anda boleh melakukan sembang masa nyata, perkongsian fail, penyegerakan status, dsb., tanpa pelayan media pusat.
• Permainan awan dan berbilang pemainPerkhidmatan seperti GeForce NOW atau Xbox Cloud Gaming memanfaatkan teknologi serupa untuk video interaktif; banyak permainan P2P menggunakan WebRTC untuk menyegerakkan permainan.
• IoT dan pengawasanKamera pintar, monitor bayi, loceng pintu video atau dron boleh menghantar video masa nyata ke peranti mudah alih dan pelayar web yang menggunakan WebRTC.
• Pendidikan dan teleperubatan: bilik darjah maya dengan papan putih, kuiz dan video dua hala, atau konsultasi perubatan dalam talian yang mana kependaman dan keselamatan adalah penting.

Keselamatan WebRTC: penyulitan, kebenaran dan amalan terbaik

Keselamatan dalam WebRTC bukanlah satu tambahan: ia terbina dalam. bersepadu daripada reka bentukSemua komponen media disulitkan dan API hanya berfungsi daripada sumber selamat (HTTPS atau localhost), walaupun adalah dinasihatkan untuk sentiasa berwaspada. penipuan melalui panggilan video.

• DTLS (Keselamatan Lapisan Pengangkutan Datagram) menyulitkan data semasa transit.
• SRTP (Protokol Pengangkutan Masa Nyata Selamat) melindungi audio dan video supaya ia tidak mudah dimanipulasi atau dipintas.
• Akses kepada kamera dan mikrofon Ia memerlukan kebenaran pengguna yang jelas, dengan penunjuk visual yang boleh dilihat (ikon, titik berwarna, dll.).
• Oleh kerana tiada plugin untuk dipasang, risiko perisian berniat jahat disamarkan dalam sambungan atau binari pihak ketiga.

Walaupun begitu, anda perlu menjaga lapisan anda sendiri: gunakan HTTPS di seluruhSemak kebenaran yang anda minta, pastikan pelayar dan pustaka dikemas kini dan jangan abaikan keselamatan pelayan isyarat atau API REST anda.

WebRTC vs teknologi lain: VoIP, WebSockets dan platform proprietari

Jika anda datang dari dunia VoIP tradisional, anda pasti biasa dengan SIP, PBX, telefon bimbit dan pelayan yang mahal. WebRTC mengubah paradigma: anda tidak perlu meminta pengguna memberikan sebarang maklumat. pelanggan desktop Tiada perkakasan khusus diperlukan; pelayar dan pelayan isyarat yang agak mudah sudah memadai.

Lawan VoIP TradisionalWebRTC mengurangkan beban infrastruktur teras dan membuka pintu kepada aplikasi yang disepadukan secara langsung ke dalam web. Dalam banyak kes, anda boleh menggunakan semula bahagian belakang SIP anda melalui gerbang yang menterjemahkan isyarat kepada WebRTC.

Mengenai Soket WebIa harus dilihat lebih sebagai pelengkap: ia sesuai untuk pemberitahuan, sembang ringan atau kemas kini status, tetapi bukan untuk media intensif. WebRTC dioptimumkan untuk audio/video masa nyatadengan kawalan kesesakan, codec, penimbal jitter, dsb. Dalam praktiknya, banyak projek menggunakan WebSockets untuk pengisyaratan dan WebRTC untuk pengangkutan media.

Jika anda membandingkannya dengan platform seperti Zoom, GoToMeeting atau WebExPerbezaannya terletak pada modelnya: alat tersebut merupakan penyelesaian tertutup, selalunya dengan aplikasi desktop wajib dan backend proprietari. Sebaliknya, WebRTC ialah teknologi asas; anda boleh membina "mini-Meet" anda sendiri di atasnya atau berintegrasi dengan perkhidmatan yang sudah menggunakannya (seperti Google Meet atau Microsoft Teams).

Membangun dengan WebRTC: kerumitan sebenar dan perangkap biasa

Walaupun API kelihatan mudah di atas kertas, melaksanakan WebRTC dari awal adalah lebih kompleks. Anda perlu berurusan dengan:

artikel berkaitan:

Pelayar Tor untuk Android: Tetapan lanjutan dan penggunaan selamat

• Papan tanda tersuai: mereka bentuk mesej, bilik, mengurus penyambungan semula, percubaan semula, ralat.
• Pengurusan AIS/KEJUTAN/PUTARPasang pelayan, pantau penggunaan TURN (yang menggunakan lebar jalur), laraskan tamat masa.
• Kualiti perkhidmatan (QoS): menyesuaikan kadar bit, mengendalikan rangkaian yang tidak stabil, merundingkan codec, mengesan apabila sambungan merosot dan bertindak balas.
• meningkat: beralih daripada P2P mudah kepada kumpulan, kemudian kepada ratusan pengguna, memperkenalkan SFU atau pelayan media tanpa melanggar reka bentuk asal.
• Keserasian entre navegadoresWalaupun keadaannya baik, anda masih akan menemui nuansa yang berbeza. Gunakan penyesuai.js Ia masih sangat disyorkan.

Dalam projek sampingan yang kecil, menyediakan pelayan Node dengan Socket.IO dan STUN awam mungkin mencukupi untuk panggilan 1:1 atau kumpulan yang sangat kecil. Tetapi jika idea anda berkembang dan anda memerlukannya orang ramai yang ramaiSama ada kawalan kualiti yang baik, rakaman, analisis, transkripsi atau pengewangan, anda tidak lama lagi perlu mempertimbangkan atau menggabungkan pelayan media sendiriatau bertukar kepada pembekal pakar.

CDN masa nyata dengan SDK: Agora, Twilio, Mux, ZEGOCLOUD…

Perkhidmatan seperti Agora, Twilio, Mux, ZEGOCLOUD atau teknologi serupa membina lapisan nilai di atas WebRTC yang menjimatkan masa kerja berbulan-bulan dan sakit kepala yang tidak terkira banyaknya:

• mereka menawarkan anda a rangkaian media global dengan SFU yang diedarkan di seluruh dunia, dioptimumkan untuk kependaman rendah.
• Abstrak SUN/PUTAR, memberi isyarat, cuba semula, penyambungan semula dan pengurusan rangkaian yang kompleks.
• Ia merangkumi SDK yang diselenggara dengan baik untuk web, iOS, Android, React Native dan kerangka kerja lain.
• Mereka menyediakan tambahan seperti rakaman, penyiaran ke RTMP/HLS, moderasi, statistik masa nyata, kawalan kualiti, peranan pengguna (hos, khalayak, penceramah), dsb.

Kosnya, seperti yang mungkin anda syak, adalah masalah utama: jika anda mempunyai sedikit wang sekalipun banyak minit video Atau, dengan bilangan pengguna serentak yang ramai, bilnya akan melonjak naik. Tambahan pula, anda menjadi bergantung pada platform mereka dan harga atau APInya berubah.

Dalam situasi khusus anda, dengan pengalaman yang kukuh dalam JavaScript masa nyataPilihan yang bijak adalah bermula dengan SDK untuk mempercepatkan pembangunan, mengesahkan produk dan mempelajari tentang model bilik, peranan, kitaran hayat strim dan pengurusan keadaannya. Kemudian, jika projek itu bermula dan kos menjadi isu, anda boleh memindahkan sebahagian penyelesaian secara beransur-ansur ke platform yang lebih mantap. infrastruktur WebRTC proprietari atau bergantung pada pelayan media jenis Flussonic untuk mengawal lapisan pengedaran.

Amalan dan alatan terbaik untuk penyahpepijatan WebRTC

Untuk mengelakkan diri daripada tersesat dalam kotak hitam WebRTC, adalah dinasihatkan untuk bergantung pada alat yang sedia ada dalam pelayar dan ekosistem:

• chrome: // webrtc-dalaman (o tentang:webrtc (dalam Firefox): panel dengan statistik terperinci sambungan, kadar bit, kehilangan paket, codec aktif, dsb.
• penyesuai.js: shim yang diselenggara oleh komuniti yang melicinkan perbezaan antara pelayar dan versi.
• test.webrtc.org: untuk menyemak kamera, mikrofon, rangkaian dan keserasian umum pada mesin.
• Sampel Rasmi di webrtc.github.io/samples: contoh kekangan, sambungan rakan sebaya, saluran data, perkongsian skrin… sangat berguna untuk menyalin corak.

Ia juga merupakan idea yang baik untuk menstrukturkan kod dengan memisahkannya dengan jelas lapisan isyarat (soket, bilik, mesej) bagi lapisan WebRTC Tulen (penciptaan sambungan, pengurusan strim, pengendali peristiwa). Ini membolehkan anda menggantikan bahagian belakang pengisyaratan atau pelayan media tanpa menulis semula semua logik klien.

artikel berkaitan:

Android dan Linux: Alternatif Terbaik untuk KDE Connect

Dengan semua perkara di atas, untuk projek sampingan yang baru bermula dan di mana anda sangat menghargainya masa pembangunan sebagai kos jangka sederhanaStrategi yang paling seimbang biasanya bermula dengan SDK masa nyata berdasarkan WebRTC yang membolehkan anda melakukan iterasi dengan cepat dalam React/React Native, menginternalisasikan cara mereka mengendalikan peranan, sesi, kitaran hayat strim dan keadaan langsung, dan secara selari menyelidiki WebRTC dengan lebih mendalam "mengikut kulit" (getUserMedia, RTCPeerConnection, RTCDataChannel, isyarat dengan Node+Socket.IO, STUN/TURN, SFU) agar tidak terikat selama-lamanya pada satu platform dan dapat membuat lompatan kepada penyelesaian yang lebih tersuai apabila produk tersebut mewajarkannya.