Mulai menggunakan WebRTC

Sam Dutton

WebRTC adalah cikal bakal baru dalam perjuangan 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 saja mudahnya menambahkan video chat dan berbagi data secara peer-to-peer ke aplikasi web Anda. 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. Klik Gabung untuk bergabung ke ruang chat dan mengizinkan aplikasi menggunakan webcam.
  3. Buka URL yang ditampilkan di akhir halaman di tab baru atau, lebih baik lagi, di komputer lain.

Mulai cepat

Tidak 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 lengkap, termasuk server pemberi sinyal sederhana.

Histori WebRTC yang sangat singkat

Salah satu tantangan besar terakhir bagi web adalah memungkinkan komunikasi manusia melalui suara dan video: disingkat RTC atau komunikasi real-time. RTC harus natural di aplikasi web seperti memasukkan teks dalam input teks. Tanpanya, Anda tidak akan dapat berinovasi dan mengembangkan cara baru bagi orang untuk berinteraksi.

Selama ini, RTC sudah menjadi perusahaan dan kompleks, sehingga membutuhkan teknologi audio dan video yang mahal untuk dilisensikan atau dikembangkan secara internal. Mengintegrasikan teknologi RTC dengan konten, data, dan layanan yang ada sulit dan menghabiskan waktu, terutama di web.

Chat video Gmail menjadi populer pada tahun 2008 dan, pada tahun 2011, Google memperkenalkan Hangouts, yang menggunakan Talk (seperti halnya Gmail). Google membeli GIPS, perusahaan yang mengembangkan banyak komponen yang diperlukan untuk RTC, seperti codec dan teknik pengurangan gema. Google menjadikan teknologi yang dikembangkan oleh GIPS sebagai open source dan terlibat dengan badan standar terkait 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 real-time tanpa plugin. Kebutuhan itu nyata:

  • Banyak layanan web menggunakan RTC, tetapi memerlukan download, aplikasi native, atau plugin. Ini termasuk Skype, Facebook, dan Hangouts.
  • Mendownload, menginstal, dan mengupdate plugin merupakan hal yang rumit, rentan terhadap error, dan menjengkelkan.
  • Plugin sulit di-deploy, di-debug, dipecahkan masalah, diuji, dan dikelola - serta mungkin memerlukan lisensi dan integrasi dengan teknologi yang rumit dan mahal. Sering kali sulit untuk membujuk orang agar menginstal plugin sejak awal!

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

Di mana kita sekarang?

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

WebRTC mengimplementasikan 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 Chris Wilson yang menggunakan getUserMedia sebagai input untuk audio web.

RTCPeerConnection: Untuk demo sederhana dan aplikasi video chat yang berfungsi penuh, lihat Contoh koneksi Peer 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 untuk membangun aplikasi sederhana untuk video chat dan berbagi file.

WebRTC pertama Anda

Aplikasi WebRTC perlu melakukan beberapa hal:

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

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

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

(Pembahasan terperinci tentang aspek jaringan dan sinyal WebRTC akan dilakukan nanti.)

MediaStream API (juga dikenal sebagai getUserMedia API)

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

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

  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 dibuat 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() menampilkan array satu MediaStreamTrack yang merepresentasikan 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 tidak ada audio, tetapi mudah untuk membayangkan kasus penggunaan jika ada lebih banyak lagi, seperti aplikasi chat yang melakukan streaming dari kamera depan, kamera belakang, mikrofon, dan aplikasi yang membagikan layarnya.

MediaStream dapat disertakan ke elemen video dengan menyetel atribut srcObject. Sebelumnya, hal ini dilakukan dengan menetapkan atribut src ke URL objek yang dibuat dengan URL.createObjectURL(), tetapi hal ini sudah 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 menggabungkan getUserMedia. Menambahkan izin audioCapture dan/atau videoCapture ke manifes memungkinkan izin diminta dan diberikan hanya sekali setelah penginstalan. Setelah itu, pengguna tidak akan dimintai izin untuk mengakses kamera atau mikrofon.

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

Intent tersebut 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 saat digunakan bersama dengan 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 menghasilkan gambar ASCII.
Gambar ASCII yang dihasilkan oleh idevelop.ro/ascii-camera
gUM ASCII art!

Batasan

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

Sebagai contoh, lihat Contoh WebRTC getUserMedia: pilih resolusi.

Menetapkan nilai batasan yang tidak diizinkan akan memberikan DOMException atau OverconstrainedError jika, misalnya, resolusi yang diminta tidak tersedia. Untuk melihat cara kerjanya, lihat Contoh WebRTC getUserMedia: pilih resolusi untuk demo.

Screenshot dan screenshot

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 lainnya, lihat Berbagi Layar dengan WebRTC. Artikel ini sudah ada beberapa tahun yang lalu, 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 flag command line seperti yang dijelaskan dalam postingan ini.

Sinyal: Kontrol sesi, jaringan, dan informasi 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, sebuah proses yang dikenal sebagai pemberian sinyal. Metode dan protokol sinyal tidak ditentukan oleh WebRTC. Pemberian sinyal bukan bagian dari RTCPeerConnection API.

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

Sinyal 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 diajak 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 merupakan 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 menemukan kandidat mengacu pada proses pencarian antarmuka dan port jaringan menggunakan framework ICE.)

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

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

  1. Anita menjalankan metode RTCPeerConnection createOffer(). RTCSessionDescription - deskripsi sesi lokal Alice akan diteruskan sebagai pengembalian dari traffic ini.
  2. Dalam callback, Anita menetapkan deskripsi lokal menggunakan setLocalDescription(), lalu mengirimkan deskripsi sesi ini kepada Bobi melalui saluran sinyalnya. Perlu diketahui bahwa RTCPeerConnection tidak akan mulai mengumpulkan kandidat hingga setLocalDescription() dipanggil. ID ini dikodifikasi dalam draf JSEP IETF.
  3. Bobi menetapkan deskripsi yang dikirimkan Anisa sebagai deskripsi jarak jauh menggunakan setRemoteDescription().
  4. Bobi menjalankan metode RTCPeerConnection createAnswer(), dengan meneruskan deskripsi jarak jauh yang dia dapatkan dari Anita sehingga sesi lokal yang kompatibel dengan miliknya dapat dibuat. Callback createAnswer() diberi RTCSessionDescription. Bob menetapkannya sebagai deskripsi lokal dan mengirimkannya ke Alia.
  5. Saat Anita mendapatkan deskripsi sesi Bobi, dia menetapkannya sebagai deskripsi jarak jauh dengan setRemoteDescription.
  6. {i>Ping!<i}

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 serta media dapat dilakukan secara bersamaan, tetapi kedua proses tersebut harus telah selesai sebelum streaming audio dan video antar-pembanding dapat dimulai.

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

Diagram arsitektur JSEP
Arsitektur JSEP

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

RTCPeerConnection

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

Berikut adalah diagram arsitektur WebRTC yang menampilkan peran RTCPeerConnection. Seperti yang akan Anda perhatikan, bagian hijau yang rumit itu cukup 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 tersembunyi di baliknya. Codec dan protokol yang digunakan oleh WebRTC melakukan banyak tugas untuk memungkinkan komunikasi real-time dapat dilakukan, bahkan melalui jaringan yang tidak dapat diandalkan:

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

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

RTCPeerConnection tanpa server

Kode berikut diambil dari Contoh koneksi peering WebRTC, yang memiliki RTCPeerConnection lokal dan jarak jauh (serta video lokal dan jarak jauh) di satu halaman web. Ini bukanlah sesuatu yang sangat 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 peer lokal (pemanggil) dan pc2 mewakili peer jarak jauh (callee).

Penelepon

  1. Buat RTCPeerConnection baru dan tambahkan aliran data dari getUserMedia(): ```js // Server adalah file konfigurasi opsional. (Lihat diskusi TURN dan STUN nanti.) pc1 = new RTCPeerConnection(servers); // ... localStream.getTracks().forEvery((track) => { pc1.addTrack(track, localStream); });
  1. Buat penawaran dan tetapkan sebagai deskripsi lokal untuk pc1 dan sebagai deskripsi jarak jauh untuk pc2. Hal ini dapat dilakukan langsung di 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 );

Tujuan 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

Pada kenyataannya, WebRTC memerlukan server, seberapa sederhananya, sehingga hal berikut dapat terjadi:

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

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

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

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

ICE adalah kerangka kerja untuk menghubungkan rekan, 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 balik NAT untuk mengetahui alamat dan porta publiknya. (Untuk informasi lebih lanjut tentang STUN dan TURN, lihat Membangun layanan backend yang diperlukan untuk aplikasi WebRTC.)

Menemukan kandidat koneksi
Menemukan kandidat koneksi

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

Jalur data WebRTC
Jalur data WebRTC

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

Klien {i>video-chat<i} sederhana

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

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

Topologi jaringan

WebRTC, seperti yang saat ini diterapkan, hanya mendukung komunikasi one-to-one, tetapi dapat digunakan dalam skenario jaringan yang lebih kompleks, seperti dengan beberapa peer 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 selektif, serta mencampur atau merekam audio dan video.

Diagram topologi Multipoint Control Unit
Contoh topologi Multipoint Control Unit

Banyak aplikasi WebRTC yang ada hanya mendemonstrasikan 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 SIP sipml5 sebagai open source yang dibuat dengan WebRTC dan WebSocket, yang (di antara potensi penggunaan lainnya) 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 bencana dalam koper

API RTCDataChannel<

Selain 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 membangun aplikasi transfer file sederhana, lihat contoh WebRTC dan codelab WebRTC.

Ada banyak potensi kasus penggunaan untuk API, antara lain:

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

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

  • Memanfaatkan penyiapan RTCPeerConnection sesi
  • Beberapa saluran simultan dengan prioritas
  • Semantik pengiriman yang andal dan tidak dapat diandalkan
  • Keamanan bawaan (DTLS) dan kontrol kemacetan
  • Kemampuan untuk menggunakan 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 mengomunikasikan status game. Mainkan teman atau jadi beruang! Platform inovatif Sharefest memungkinkan berbagi file melalui RTCDataChannel dan peerCDN memberikan gambaran sekilas tentang cara WebRTC dapat mengaktifkan distribusi konten peer-to-peer.

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

Keamanan

Ada beberapa cara yang dapat digunakan aplikasi atau plugin komunikasi real-time untuk membahayakan keamanan. Contoh:

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

WebRTC memiliki beberapa fitur untuk menghindari masalah ini:

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

Diskusi lengkap tentang keamanan untuk media streaming berada di luar cakupan artikel ini. Untuk informasi selengkapnya, lihat Arsitektur Keamanan WebRTC yang Diusulkan yang diusulkan oleh IETF.

Kesimpulan

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

Teknologi tidak akan jauh lebih mengganggu daripada ini.

Seperti yang dikemukakan oleh blogger Phil Edholm, "Kemungkinan besar, WebRTC dan HTML5 dapat mengaktifkan transformasi yang sama untuk komunikasi real-time seperti yang dilakukan browser asli untuk mendapatkan informasi".

Developer tools

  • Statistik WebRTC untuk sesi yang sedang berlangsung dapat ditemukan di:
    • tentang://webrtc-internals di Chrome
    • opera://webrtc-internals di Opera
    • about:webrtc di Firefox
      Halaman chrome://webrtc-internals
      screenshot chrome://webrtc-internals
  • Catatan interop lintas browser
  • adapter.js adalah shim JavaScript untuk WebRTC yang dikelola oleh Google dengan bantuan dari komunitas WebRTC yang memisahkan awalan vendor, perbedaan browser, dan perubahan spesifikasi.
  • Untuk mempelajari proses sinyal WebRTC lebih lanjut, periksa output log appr.tc ke konsol.
  • Jika terlalu banyak, Anda dapat memilih untuk menggunakan framework WebRTC atau bahkan layanan WebRTC yang lengkap.
  • Laporan bug dan permintaan fitur selalu dihargai:

Pelajari lebih lanjut

Standar dan protokol

Ringkasan dukungan WebRTC

MediaStream dan getUserMedia API

  • Chrome desktop 18.0.1008 dan yang lebih tinggi; Chrome untuk Android 29 dan yang lebih tinggi
  • Opera 18 dan yang lebih tinggi; Opera untuk Android 20 dan yang lebih tinggi
  • 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 tinggi

RTCPeerConnection API

  • Chrome desktop 20 dan yang lebih tinggi; Chrome untuk Android 29 dan yang lebih tinggi (tanpa flag)
  • Opera 18 dan yang lebih tinggi (aktif secara default); Opera untuk Android 20 dan yang lebih tinggi (aktif secara default)
  • Firefox 22 dan yang lebih tinggi (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 tinggi

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 lebih tinggi; Opera untuk Android 20 dan yang lebih tinggi
  • Firefox 22 dan yang lebih tinggi (aktif secara default)

Untuk informasi yang lebih mendetail mengenai 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.