Mulai menggunakan WebRTC

Sam Dutton

WebRTC adalah bidang baru dalam perang panjang untuk web yang terbuka dan tidak terbebani.

Brendan Eich, penemu JavaScript

Komunikasi real-time tanpa plugin

Bayangkan sebuah dunia di mana ponsel, TV, dan komputer Anda dapat berkomunikasi di platform yang sama. Bayangkan Anda dapat menambahkan video chat dan berbagi data peer-to-peer ke aplikasi web Anda dengan mudah. Itulah visi WebRTC.

Ingin mencobanya? WebRTC tersedia di desktop dan perangkat seluler di Google Chrome, Safari, Firefox, dan Opera. Sebaiknya mulai adalah aplikasi video chat sederhana di appr.tc:

  1. Buka appr.tc di browser Anda.
  2. Mengklik Gabung untuk bergabung ke ruang chat dan mengizinkan aplikasi menggunakan webcam.
  3. Buka URL yang ditampilkan di akhir halaman dalam tab baru atau, lebih baik lagi, di komputer lain.

Mulai cepat

Tak sempat membaca artikel ini atau hanya ingin menulis kode?

Atau, langsung buka codelab WebRTC, panduan langkah demi langkah yang menjelaskan cara membangun aplikasi video chat yang lengkap, termasuk server pemberi sinyal sederhana.

Sejarah WebRTC yang sangat singkat

Salah satu tantangan besar terakhir bagi web adalah memungkinkan komunikasi manusia melalui suara dan video: komunikasi real-time atau disingkat RTC. RTC seharusnya sama alaminya di aplikasi web seperti memasukkan teks dalam input teks. Tanpa AI, kemampuan Anda untuk berinovasi dan mengembangkan cara baru bagi orang-orang untuk berinteraksi akan menjadi terbatas.

Secara historis, RTC bersifat perusahaan dan kompleks, sehingga memerlukan teknologi audio dan video yang mahal untuk dilisensikan atau dikembangkan secara internal. Integrasi teknologi RTC dengan konten, data, dan layanan yang ada saat ini sulit dan memakan waktu, terutama di web.

Video chat Gmail menjadi populer pada tahun 2008 dan, pada tahun 2011, Google memperkenalkan Hangouts, yang menggunakan Talk (seperti halnya Gmail). Google membeli GIPS, sebuah perusahaan yang mengembangkan banyak komponen yang diperlukan untuk RTC, seperti codec dan teknik pembatalan gema. Google menjadikan teknologi yang dikembangkan oleh GIPS sebagai open source dan terlibat dengan badan standar relevan di Internet Engineering Task Force (IETF) dan World Wide Web Consortium (W3C) untuk memastikan konsensus industri. Pada Mei 2011, Ericsson membuat implementasi pertama WebRTC.

WebRTC menerapkan standar terbuka untuk komunikasi data, audio, dan video secara real-time dan bebas plugin. Kebutuhan itu nyata:

  • Banyak layanan web menggunakan RTC, tetapi membutuhkan download, aplikasi bawaan, atau plugin. Termasuk Skype, Facebook, dan Hangouts.
  • Mendownload, menginstal, dan mengupdate plugin sangat rumit, rentan error, dan mengganggu.
  • Plugin sulit di-deploy, di-debug, memecahkan masalah, diuji, dan dikelola - serta mungkin memerlukan pemberian lisensi dan integrasi dengan teknologi yang kompleks dan mahal. Sering kali sulit untuk membujuk orang untuk menginstal plugin sejak awal!

Prinsip panduan project WebRTC adalah bahwa API-nya harus bersifat open source, gratis, terstandardisasi, terintegrasi dalam browser web, dan lebih efisien daripada teknologi yang sudah ada.

Di mana kita sekarang?

WebRTC digunakan dalam berbagai aplikasi, seperti Google Meet. WebRTC juga telah terintegrasi dengan aplikasi asli WebKitGTK+ dan Qt.

WebRTC menerapkan ketiga API ini: - MediaStream (juga dikenal sebagai getUserMedia) - RTCPeerConnection - RTCDataChannel

API ditentukan dalam dua spesifikasi berikut:

Ketiga API tersebut didukung di perangkat seluler dan desktop oleh Chrome, Safari, Firefox, Edge, dan Opera.

getUserMedia: Untuk demo dan kode, lihat contoh WebRTC atau coba contoh luar biasa dari Chris Wilson yang menggunakan getUserMedia sebagai input untuk audio web.

RTCPeerConnection: Untuk demo sederhana dan aplikasi video chat yang berfungsi penuh, lihat Contoh koneksi Peering WebRTC dan appr.tc. Aplikasi ini menggunakan adapter.js, shim JavaScript yang dikelola oleh Google dengan bantuan dari komunitas WebRTC, untuk memisahkan perbedaan browser dan perubahan spesifikasi.

RTCDataChannel: Untuk melihat penerapannya, lihat contoh WebRTC untuk melihat salah satu demo saluran data.

Codelab WebRTC menunjukkan cara menggunakan ketiga API guna membangun aplikasi sederhana untuk obrolan video dan berbagi file.

WebRTC pertama Anda

Aplikasi WebRTC perlu melakukan beberapa hal:

  • Dapatkan audio streaming, video, atau data lainnya.
  • Dapatkan informasi jaringan, seperti alamat IP dan port, lalu tukarkan dengan klien WebRTC lain (dikenal sebagai peer) untuk mengaktifkan koneksi, bahkan melalui NAT dan firewall.
  • Mengoordinasikan komunikasi pemberian sinyal untuk melaporkan kesalahan dan memulai atau menutup sesi.
  • Bertukar informasi tentang media dan kemampuan klien, seperti resolusi dan codec.
  • Berkomunikasi dengan audio streaming, video, atau data.

Untuk memperoleh dan mengomunikasikan data streaming, WebRTC menerapkan API berikut:

  • MediaStream mendapatkan akses ke aliran data, seperti dari kamera dan mikrofon pengguna.
  • RTCPeerConnection mengaktifkan panggilan audio atau video dengan fasilitas untuk enkripsi dan pengelolaan bandwidth.
  • RTCDataChannel memungkinkan komunikasi peer-to-peer untuk data generik.

(Ada diskusi mendetail tentang aspek jaringan dan aspek sinyal WebRTC nanti.)

MediaStream API (juga dikenal sebagai getUserMedia API)

MediaStream API mewakili aliran media yang disinkronkan. Misalnya, streaming yang diambil dari input kamera dan mikrofon telah menyinkronkan trek video dan audio. (Jangan salah membedakan MediaStreamTrack dengan elemen <track>, yang merupakan sesuatu yang sangat berbeda.)

Mungkin cara termudah untuk memahami MediaStream API adalah dengan melihatnya secara alami:

  1. Di browser Anda, buka Contoh WebRTC getUserMedia.
  2. Buka konsol.
  3. Periksa variabel stream yang berada dalam cakupan global.

Setiap MediaStream memiliki input, yang mungkin berupa MediaStream yang dihasilkan oleh getUserMedia(), dan output, yang mungkin diteruskan ke elemen video atau RTCPeerConnection.

Metode getUserMedia() mengambil parameter objek MediaStreamConstraints dan menampilkan Promise yang di-resolve ke objek MediaStream.

Setiap MediaStream memiliki label, seperti 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'. Array MediaStreamTrack ditampilkan oleh metode getAudioTracks() dan getVideoTracks().

Untuk contoh getUserMedia, stream.getAudioTracks() menampilkan array kosong (karena tidak ada audio), dan, dengan asumsi webcam yang berfungsi terhubung, stream.getVideoTracks() akan menampilkan array satu MediaStreamTrack yang mewakili streaming dari webcam. Setiap MediaStreamTrack memiliki jenis ('video' atau 'audio'), label (seperti 'FaceTime HD Camera (Built-in)'), dan mewakili satu atau beberapa saluran audio atau video. Dalam hal ini, hanya ada satu trek video dan tanpa audio, tetapi mudah untuk membayangkan kasus penggunaan yang lebih banyak dari itu, seperti aplikasi chat yang mendapatkan streaming dari kamera depan, kamera belakang, mikrofon, dan aplikasi yang berbagi layarnya.

MediaStream dapat disertakan ke elemen video dengan menyetel atribut srcObject. Sebelumnya, hal ini dilakukan dengan menyetel atribut src ke URL objek yang dibuat dengan URL.createObjectURL(), tetapi tindakan ini tidak digunakan lagi.

getUserMedia juga dapat digunakan sebagai node input untuk Web Audio API:

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {
  audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {
  audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {
  console.log('Sorry! Web Audio not supported.');
}

// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;

// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;

navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {
  // Create an AudioNode from the stream.
  const mediaStreamSource =
    audioContext.createMediaStreamSource(stream);
  mediaStreamSource.connect(filterNode);
  filterNode.connect(gainNode);
  // Connect the gain node to the destination. For example, play the sound.
  gainNode.connect(audioContext.destination);
});

Aplikasi dan ekstensi berbasis Chromium juga dapat menyertakan getUserMedia. Menambahkan izin audioCapture dan/atau videoCapture ke manifes memungkinkan izin untuk diminta dan diberikan hanya sekali setelah penginstalan. Setelah itu, pengguna tidak akan dimintai izin untuk mengakses kamera atau mikrofon.

Izin hanya perlu diberikan satu kali untuk getUserMedia(). Pertama kali, tombol Izinkan ditampilkan di infobar browser. Akses HTTP untuk getUserMedia() tidak digunakan lagi oleh Chrome pada akhir tahun 2015 karena diklasifikasikan sebagai Fitur canggih.

Tujuannya berpotensi mengaktifkan MediaStream untuk sumber data streaming apa pun, bukan hanya kamera atau mikrofon. Hal ini akan memungkinkan streaming dari data yang disimpan atau sumber data arbitrer, seperti sensor atau input lainnya.

getUserMedia() benar-benar berfungsi bersama API dan library JavaScript lainnya:

  • Webcam Toy adalah aplikasi photobooth yang menggunakan WebGL untuk menambahkan efek aneh dan indah ke foto yang dapat dibagikan atau disimpan secara lokal.
  • FaceKat adalah game pelacakan wajah yang dibuat dengan headtrackr.js.
  • ASCII Camera menggunakan Canvas API untuk membuat gambar ASCII.
Gambar ASCII yang dibuat oleh idevelop.ro/ascii-camera
seni ASCII gUM!

Batasan

Batasan dapat digunakan untuk menetapkan nilai resolusi video untuk getUserMedia(). Hal ini juga memungkinkan dukungan untuk batasan lainnya, seperti rasio aspek; mode menghadap ke kamera (kamera depan atau belakang); kecepatan frame, tinggi, dan lebar; dan metode applyConstraints().

Sebagai contoh, lihat Contoh WebRTC getUserMedia: pilih resolusi.

Menyetel nilai batasan yang tidak diizinkan akan menghasilkan DOMException atau OverconstrainedError jika, misalnya, resolusi yang diminta tidak tersedia. Untuk melihat penerapannya, lihat Contoh WebRTC getUserMedia: pilih resolusi untuk demo.

Tangkapan layar dan tab

Aplikasi Chrome juga memungkinkan untuk membagikan video live dari satu tab browser atau seluruh desktop melalui chrome.tabCapture dan chrome.desktopCapture API. (Untuk demo dan informasi selengkapnya, lihat Berbagi layar dengan WebRTC. Artikel ini berusia beberapa tahun, tetapi masih menarik.)

Anda juga dapat menggunakan screenshot sebagai sumber MediaStream di Chrome menggunakan batasan chromeMediaSource eksperimental. Perhatikan bahwa screenshot memerlukan HTTPS dan hanya boleh digunakan untuk pengembangan karena diaktifkan melalui tanda command line seperti yang dijelaskan dalam postingan ini.

Sinyal: Informasi kontrol sesi, jaringan, dan media

WebRTC menggunakan RTCPeerConnection untuk mengomunikasikan data streaming antar-browser (juga dikenal sebagai pembanding), tetapi juga memerlukan mekanisme untuk mengoordinasikan komunikasi dan mengirim pesan kontrol, proses yang dikenal sebagai pensinyalan. Metode dan protokol sinyal tidak ditentukan oleh WebRTC. Sinyal bukan bagian dari RTCPeerConnection API.

Sebagai gantinya, developer aplikasi WebRTC dapat memilih protokol pesan apa pun yang mereka sukai, seperti SIP atau XMPP, dan saluran komunikasi dupleks (dua arah) yang sesuai. Contoh appr.tc menggunakan XHR dan Channel API sebagai mekanisme pensinyalan. Codelab menggunakan Socket.io yang berjalan di server Node.

{i>Signaling<i} digunakan untuk bertukar tiga jenis informasi:

  • Pesan kontrol sesi: untuk melakukan inisialisasi atau menutup komunikasi dan melaporkan error.
  • Konfigurasi jaringan: ke dunia luar, apa alamat IP dan porta komputer Anda?
  • Kemampuan media: codec dan resolusi apa yang dapat ditangani oleh browser dan browser yang ingin digunakan untuk berkomunikasi?

Pertukaran informasi melalui pemberian sinyal harus berhasil diselesaikan sebelum streaming peer-to-peer dapat dimulai.

Misalnya, bayangkan Alice ingin berkomunikasi dengan Bob. Berikut ini contoh kode dari spesifikasi WebRTC W3C, yang menunjukkan cara kerja proses sinyal. Kode ini mengasumsikan keberadaan beberapa mekanisme sinyal yang dibuat dalam metode createSignalingChannel(). Perhatikan juga bahwa di Chrome dan Opera, RTCPeerConnection saat ini diberi awalan.

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    // Send the offer to the other peer.
    signaling.send({desc: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};

// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {
  // Don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

// Call start() to initiate.
async function start() {
  try {
    // Get local stream, show it in self-view, and add it to be sent.
    const stream =
      await navigator.mediaDevices.getUserMedia(constraints);
    stream.getTracks().forEach((track) =>
      pc.addTrack(track, stream));
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({desc, candidate}) => {
  try {
    if (desc) {
      // If you get an offer, you need to reply with an answer.
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream =
          await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) =>
          pc.addTrack(track, stream));
        await pc.setLocalDescription(await pc.createAnswer());
        signaling.send({desc: pc.localDescription});
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc);
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

Pertama, Alice dan Bob bertukar informasi jaringan. (Ekspresi finding kandidat mengacu pada proses menemukan antarmuka dan port jaringan menggunakan framework ICE.)

  1. Anita membuat objek RTCPeerConnection dengan pengendali onicecandidate, yang berjalan saat kandidat jaringan tersedia.
  2. Alice mengirimkan data kandidat yang diserialisasi kepada Bob melalui saluran sinyal apa pun yang mereka gunakan, seperti WebSocket atau mekanisme lainnya.
  3. Saat Bobi mendapatkan pesan kandidat dari Alia, dia memanggil addIceCandidate untuk menambahkan kandidat tersebut ke deskripsi pembanding jarak jauh.

Klien WebRTC (juga dikenal sebagai rekan, atau Alice dan Bob dalam contoh ini) juga perlu memastikan dan bertukar informasi media audio dan video lokal dan jarak jauh, seperti kemampuan resolusi dan codec. Memberi sinyal untuk bertukar informasi konfigurasi media dilakukan dengan bertukar penawaran dan jawaban menggunakan Protokol Deskripsi Sesi (SDP):

  1. Anita menjalankan metode RTCPeerConnection createOffer(). Hasil dari hal ini diteruskan RTCSessionDescription - deskripsi sesi lokal Alice.
  2. Dalam callback, Alice menetapkan deskripsi lokal menggunakan setLocalDescription(), lalu mengirim deskripsi sesi ini ke Bob melalui saluran sinyalnya. Perhatikan bahwa RTCPeerConnection tidak akan mulai mengumpulkan kandidat hingga setLocalDescription() dipanggil. Hal ini dikodifikasi dalam draf JSEP IETF.
  3. Bobi menetapkan deskripsi yang dikirim Alia sebagai deskripsi jarak jauh menggunakan setRemoteDescription().
  4. Bob menjalankan metode RTCPeerConnection createAnswer(), dengan meneruskan deskripsi jarak jauh yang ia dapatkan dari Alice sehingga sesi lokal yang kompatibel dengan miliknya dapat dibuat. Callback createAnswer() diberi RTCSessionDescription. Bob menetapkannya sebagai deskripsi lokal dan mengirimkannya kepada Alice.
  5. Saat Alice mendapatkan deskripsi sesi Bobi, dia menyetelnya sebagai deskripsi jarak jauh dengan setRemoteDescription.
  6. Ping!

Objek RTCSessionDescription adalah blob yang sesuai dengan Session Description Protocol, SDP. Diserialisasi, objek SDP akan terlihat seperti ini:

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

Akuisisi dan pertukaran informasi jaringan dan media dapat dilakukan secara bersamaan, tetapi kedua proses ini harus sudah selesai sebelum streaming audio dan video di antara pembanding dapat dimulai.

Arsitektur penawaran/jawaban yang sebelumnya dijelaskan disebut JavaScript Session Menetapkan Protocol, atau JSEP. (Terdapat animasi luar biasa yang menjelaskan proses pemberian sinyal dan streaming dalam video demo Ericsson untuk penerapan WebRTC pertamanya.)

Diagram arsitektur JSEP
Arsitektur JSEP

Setelah proses pensinyalan berhasil diselesaikan, data dapat di-streaming secara langsung secara peer-to-peer, antara pemanggil dan tujuan panggilan - atau, jika gagal, melalui server relai perantara (info selengkapnya akan dijelaskan nanti). Streaming adalah tugas RTCPeerConnection.

RTCPeerConnection

RTCPeerConnection adalah komponen WebRTC yang menangani komunikasi streaming data yang stabil dan efisien antar-peer.

Berikut adalah diagram arsitektur WebRTC yang menampilkan peran RTCPeerConnection. Seperti yang akan Anda perhatikan, bagian hijau itu rumit!

Diagram arsitektur WebRTC
Arsitektur WebRTC (dari webrtc.org)

Dari perspektif JavaScript, hal utama yang harus dipahami dari diagram ini adalah RTCPeerConnection melindungi developer web dari berbagai kerumitan yang mengintai di bawahnya. Codec dan protokol yang digunakan oleh WebRTC melakukan banyak pekerjaan untuk membuat komunikasi secara real-time dapat dilakukan, bahkan melalui jaringan yang tidak dapat diandalkan:

  • Penyembunyian paket yang hilang
  • Peredam gema
  • Adaptabilitas bandwidth
  • Buffering jitter dinamis
  • Kontrol penguatan otomatis
  • Pengurangan dan peredam bising
  • Pembersihan gambar

Kode W3C sebelumnya menunjukkan contoh WebRTC yang disederhanakan dari perspektif pemberian sinyal. Berikut adalah panduan dua aplikasi WebRTC yang berfungsi. Yang pertama adalah contoh sederhana untuk mendemonstrasikan RTCPeerConnection dan yang kedua adalah klien video chat yang beroperasi penuh.

RTCPeerConnection tanpa server

Kode berikut diambil dari koneksi Peer sampel WebRTC, yang memiliki RTCPeerConnection lokal dan jarak jauh (serta video lokal dan jarak jauh) di satu halaman web. Ini tidak terlalu berguna - pemanggil dan tujuan panggilan berada di halaman yang sama - tetapi membuat cara kerja RTCPeerConnection API sedikit lebih jelas karena objek RTCPeerConnection di halaman dapat bertukar data dan pesan secara langsung tanpa harus menggunakan mekanisme sinyal perantara.

Dalam contoh ini, pc1 mewakili pembanding lokal (pemanggil) dan pc2 mewakili pembanding jarak jauh (tujuan panggilan).

Penelepon

  1. Buat RTCPeerConnection baru dan tambahkan aliran data dari getUserMedia(): ```js // Server adalah file konfigurasi opsional. (Lihat diskusi TURN dan STUN nanti.) pc1 = baru RTCPeerConnection(server); // ... localStream.getTracks().forEach((track) =&gt; { pc1.addTrack(track, localStream); });
  1. Buat penawaran dan tetapkan sebagai deskripsi lokal untuk pc1 dan sebagai deskripsi jarak jauh untuk pc2. Tindakan ini dapat dilakukan langsung dalam kode tanpa menggunakan sinyal karena pemanggil dan tujuan panggilan berada di halaman yang sama: js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

Penerima panggilan

  1. Buat pc2 dan, saat streaming dari pc1 ditambahkan, tampilkan dalam elemen video: js pc2 = new RTCPeerConnection(servers); pc2.ontrack = gotRemoteStream; //... function gotRemoteStream(e){ vid2.srcObject = e.stream; }

RTCPeerConnection API plus server

Di dunia nyata, WebRTC memerlukan server, meskipun sederhana, sehingga hal berikut dapat terjadi:

  • Pengguna dapat saling menemukan dan bertukar informasi di dunia nyata, seperti nama.
  • Aplikasi klien WebRTC (peer) bertukar informasi jaringan.
  • Pembanding bertukar data tentang media, seperti format dan resolusi video.
  • Aplikasi klien WebRTC melintasi gateway NAT dan firewall.

Dengan kata lain, WebRTC memerlukan empat jenis fungsi sisi server:

  • Penemuan dan komunikasi pengguna
  • Pemberian sinyal
  • Traversal NAT/firewall
  • Server relai jika komunikasi peer-to-peer gagal

NAT traversal, jaringan peer-to-peer, dan persyaratan untuk membangun aplikasi server agar dapat menemukan dan memberikan sinyal pengguna berada di luar cakupan artikel ini. Dapat dikatakan bahwa protokol STUN dan ekstensinya, TURN, digunakan oleh framework ICE untuk memungkinkan RTCPeerConnection menangani traversal NAT dan variasi jaringan lainnya.

ICE adalah framework untuk menghubungkan pembanding, seperti dua klien video chat. Awalnya, ICE mencoba menghubungkan pembanding secara langsung dengan latensi serendah mungkin melalui UDP. Dalam proses ini, server STUN memiliki satu tugas: memungkinkan peer di belakang NAT untuk mengetahui alamat publik dan port-nya. (Untuk informasi selengkapnya tentang STUN dan TURN, lihat Membangun layanan backend yang diperlukan untuk aplikasi WebRTC.)

Menemukan kandidat koneksi
Menemukan kandidat untuk terhubung

Jika UDP gagal, ICE akan mencoba TCP. Jika koneksi langsung gagal - khususnya karena traversal dan firewall NAT perusahaan - ICE menggunakan server TURN perantara (relay). Dengan kata lain, ICE pertama-tama menggunakan STUN dengan UDP untuk menghubungkan peer secara langsung dan, jika gagal, akan kembali ke server relai TURN. Ekspresi finding kandidat mengacu pada proses menemukan antarmuka dan port jaringan.

Jalur data WebRTC
Jalur data WebRTC

Engineer WebRTC Justin Uberti memberikan informasi lebih lanjut tentang ICE, STUN, dan TURN dalam presentasi WebRTC Google I/O 2013. (Slide presentasi memberikan contoh implementasi server TURN dan STUN.)

Aplikasi video chat sederhana

Tempat yang baik untuk mencoba WebRTC, lengkap dengan sinyal dan traversal NAT/firewall menggunakan server STUN, adalah demo chat video di appr.tc. Aplikasi ini menggunakan adapter.js, shim untuk melindungi aplikasi dari perubahan spesifikasi dan perbedaan awalan.

Kode sengaja dibuat panjang dalam logging-nya. Periksa konsol untuk memahami urutan peristiwa. Berikut adalah panduan kode yang mendetail.

Topologi jaringan

WebRTC, seperti yang diterapkan saat ini, hanya mendukung komunikasi one-to-one, tetapi dapat digunakan dalam skenario jaringan yang lebih kompleks, seperti dengan beberapa pembanding yang masing-masing berkomunikasi satu sama lain secara langsung atau melalui Multipoint Control Unit (MCU), server yang dapat menangani peserta dalam jumlah besar dan melakukan penerusan streaming tertentu, serta menggabungkan atau merekam audio dan video.

Diagram topologi Multipoint Control Unit
Contoh topologi Unit Kontrol Multipoint

Banyak aplikasi WebRTC yang ada hanya menunjukkan komunikasi antar-browser web, tetapi server gateway dapat mengaktifkan aplikasi WebRTC yang berjalan di browser untuk berinteraksi dengan perangkat, seperti telepon (juga dikenal sebagai PSTN) dan dengan sistem VOIP. Pada bulan Mei 2012, Doubango Telecom menjadikan klien sipml5 SIP sebagai open source yang dibuat dengan WebRTC dan WebSocket, yang (di antara potensi penggunaan lainnya) yang memungkinkan panggilan video antara browser dan aplikasi yang berjalan di iOS dan Android. Di Google I/O, Tethr dan Tropo mendemonstrasikan framework untuk komunikasi bencana dalam koper menggunakan sel OpenBTS untuk memungkinkan komunikasi antara ponsel menengah dan komputer melalui WebRTC. Komunikasi telepon tanpa operator!

Demo Tethr/Tropo di Google I/O 2012
Tethr/Tropo: Komunikasi penanganan bencana dalam koper

API RTCDataChannel<

Seperti halnya audio dan video, WebRTC mendukung komunikasi real-time untuk jenis data lainnya.

RTCDataChannel API memungkinkan pertukaran data arbitrer secara peer-to-peer dengan latensi rendah dan throughput tinggi. Untuk demo satu halaman dan mempelajari cara membuat aplikasi transfer file sederhana, lihat contoh WebRTC dan codelab WebRTC.

Ada banyak potensi kasus penggunaan untuk API, termasuk:

  • Game
  • Aplikasi desktop jarak jauh
  • Chat teks secara real-time
  • Transfer file
  • Jaringan terdesentralisasi

API ini memiliki beberapa fitur untuk memaksimalkan RTCPeerConnection dan memungkinkan komunikasi peer-to-peer yang canggih dan fleksibel:

  • Memanfaatkan penyiapan sesi RTCPeerConnection
  • Beberapa saluran simultan dengan prioritas
  • Semantik pengiriman yang andal dan tidak andal
  • Kontrol kemacetan dan keamanan bawaan (DTLS)
  • Kemampuan untuk digunakan dengan atau tanpa audio atau video

Sintaksis sengaja mirip dengan WebSocket dengan metode send() dan peristiwa message:

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel =
  localConnection.createDataChannel('sendDataChannel');

// ...

remoteConnection.ondatachannel = (event) => {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessage;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
};

function onReceiveMessage(event) {
  document.querySelector("textarea#send").value = event.data;
}

document.querySelector("button#send").onclick = () => {
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

Komunikasi terjadi langsung antar-browser, sehingga RTCDataChannel bisa jauh lebih cepat daripada WebSocket meskipun server relai (TURN) diperlukan saat melakukan hole-punching untuk mengatasi firewall dan NAT gagal.

RTCDataChannel tersedia di Chrome, Safari, Firefox, Opera, dan Samsung Internet. Game Cube Slam menggunakan API untuk menyampaikan status game. Mainkan teman atau mainkan beruang! Platform inovatif Sharefest memungkinkan aktivitas berbagi file melalui RTCDataChannel dan peerCDN memberikan gambaran sekilas tentang bagaimana WebRTC dapat memungkinkan distribusi konten peer-to-peer.

Untuk informasi selengkapnya tentang RTCDataChannel, lihat spesifikasi protokol draf IETF.

Keamanan

Ada beberapa kemungkinan aplikasi atau plugin komunikasi real-time dapat membahayakan keamanan. Contoh:

  • Media atau data yang tidak dienkripsi mungkin disadap antara browser, atau antara browser dan server.
  • Aplikasi mungkin merekam dan mendistribusikan video atau audio tanpa diketahui pengguna.
  • Malware atau virus dapat diinstal bersama plugin atau aplikasi yang tampaknya tidak berbahaya.

WebRTC memiliki beberapa fitur untuk menghindari masalah tersebut:

  • Implementasi WebRTC menggunakan protokol aman, seperti DTLS dan SRTP.
  • Enkripsi bersifat wajib untuk semua komponen WebRTC, termasuk mekanisme pensinyalan.
  • WebRTC bukan plugin. Komponennya berjalan di sandbox browser dan bukan dalam proses terpisah. Komponen tidak memerlukan penginstalan terpisah dan akan diperbarui setiap kali browser diupdate.
  • Akses kamera dan mikrofon harus diberikan secara eksplisit dan, saat kamera atau mikrofon berjalan, akses ini akan ditunjukkan dengan jelas oleh antarmuka pengguna.

Pembahasan lengkap tentang keamanan untuk media streaming tidak termasuk dalam cakupan artikel ini. Untuk informasi selengkapnya, lihat Arsitektur Keamanan WebRTC yang Diusulkan yang diajukan oleh IETF.

Kesimpulan

API dan standar WebRTC dapat mendemokrasikan dan mendesentralisasi alat untuk pembuatan konten dan komunikasi, termasuk telepon, game, produksi video, pembuatan musik, dan pengumpulan berita.

Teknologi tidak akan jauh mengganggu daripada ini.

Seperti yang disebutkan oleh blogger Phil Edholm, "Mungkin, WebRTC dan HTML5 dapat memungkinkan transformasi yang sama untuk komunikasi waktu nyata seperti yang dilakukan browser asli untuk informasi".

Developer tools

Pelajari lebih lanjut

Standar dan protokol

Ringkasan dukungan WebRTC

MediaStream API dan getUserMedia API

  • Desktop Chrome 18.0.1008 dan yang lebih baru; Chrome untuk Android 29 dan yang lebih baru
  • Opera 18 dan yang lebih baru; Opera untuk Android 20 dan yang lebih baru
  • Opera 12, Opera Mobile 12 (berdasarkan mesin Presto)
  • Firefox 17 dan yang lebih baru
  • Microsoft Edge 16 dan yang lebih baru
  • Safari 11.2 dan yang lebih tinggi di iOS, dan 11.1 dan yang lebih tinggi di MacOS
  • UC 11.8 dan yang lebih tinggi di Android
  • Samsung Internet 4 dan yang lebih baru

RTCPeerConnection API

  • Chrome desktop 20 dan yang lebih baru; Chrome untuk Android 29 dan yang lebih tinggi (tanpa flag)
  • Opera 18 dan yang lebih baru (aktif secara default); Opera untuk Android 20 dan yang lebih baru (aktif secara default)
  • Firefox 22 dan yang lebih baru (aktif secara default)
  • Microsoft Edge 16 dan yang lebih baru
  • Safari 11.2 dan yang lebih tinggi di iOS, dan 11.1 dan yang lebih tinggi di MacOS
  • Samsung Internet 4 dan yang lebih baru

RTCDataChannel API

  • Versi eksperimental di Chrome 25, tetapi lebih stabil (dan dengan interoperabilitas Firefox) di Chrome 26 dan yang lebih baru; Chrome untuk Android 29 dan yang lebih baru
  • Versi stabil (dan dengan interoperabilitas Firefox) di Opera 18 dan yang lebih baru; Opera untuk Android 20 dan yang lebih baru
  • Firefox 22 dan yang lebih baru (aktif secara default)

Untuk informasi lebih mendetail tentang dukungan lintas platform untuk API, seperti getUserMedia dan RTCPeerConnection, lihat caniuse.com dan Status Platform Chrome.

API native untuk RTCPeerConnection juga tersedia di dokumentasi di webrtc.org.