Membangun layanan backend yang diperlukan untuk aplikasi WebRTC

Sam Dutton

Apa itu pensinyalan?

Pensinyalan adalah proses mengoordinasikan komunikasi. Agar aplikasi WebRTC dapat menyiapkan panggilan, kliennya perlu bertukar informasi berikut:

• Pesan kontrol sesi yang digunakan untuk membuka atau menutup komunikasi
• Pesan error
• Metadata media, seperti codec, setelan codec, bandwidth, dan jenis media
• Data utama yang digunakan untuk membuat koneksi aman
• Data jaringan, seperti alamat IP dan port host yang terlihat oleh dunia luar

Proses pemberian sinyal ini memerlukan cara bagi klien untuk mengirim dan menerima pesan. Mekanisme tersebut tidak diimplementasikan oleh WebRTC API. Anda harus membuatnya sendiri. Nanti dalam artikel ini, Anda akan mempelajari cara membuat layanan sinyal. Namun, pertama-tama, Anda memerlukan sedikit konteks.

Mengapa pensinyalan tidak ditentukan oleh WebRTC?

Untuk menghindari redundansi dan memaksimalkan kompatibilitas dengan teknologi yang sudah ada, metode dan protokol pensinyalan tidak ditentukan oleh standar WebRTC. Pendekatan ini diuraikan oleh JavaScript Session Establishment Protocol (JSEP):

Arsitektur JSEP juga menghindari browser harus menyimpan status, yaitu berfungsi sebagai mesin status pensinyalan. Hal ini akan menjadi masalah jika, misalnya, data sinyal hilang setiap kali halaman dimuat ulang. Sebagai gantinya, status sinyal dapat disimpan di server.

JSEP memerlukan pertukaran penawaran dan jawaban antar-peer, metadata media yang disebutkan di atas. Penawaran dan jawaban dikomunikasikan dalam format Session Description Protocol (SDP), yang terlihat seperti ini:

v=0
o=- 7614219274584779017 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS
m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:W2TGCZw2NZHuwlnf
a=ice-pwd:xdQEccP40E+P0L5qTyzDgfmW
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9c1AHz27dZ9xPI91YNfSlI67/EMkjHHIHORiClQe
a=rtpmap:111 opus/48000/2
…

Ingin tahu apa arti sebenarnya dari semua istilah SDP ini? Lihat contoh Internet Engineering Task Force (IETF).

Perlu diingat bahwa WebRTC didesain agar penawaran atau jawaban dapat disesuaikan sebelum ditetapkan sebagai deskripsi lokal atau jarak jauh dengan mengedit nilai dalam teks SDP. Misalnya, fungsi preferAudioCodec() di appr.tc dapat digunakan untuk menyetel codec dan bitrate default. SDP agak sulit dimanipulasi dengan JavaScript dan ada diskusi tentang apakah versi WebRTC mendatang harus menggunakan JSON, tetapi ada beberapa keuntungan jika tetap menggunakan SDP.

API dan pensinyalan RTCPeerConnection: Penawaran, jawaban, dan kandidat

RTCPeerConnection adalah API yang digunakan oleh aplikasi WebRTC untuk membuat koneksi antar-peer, dan mengomunikasikan audio dan video.

Untuk memulai proses ini, RTCPeerConnection memiliki dua tugas:

• Pastikan kondisi media lokal, seperti kemampuan codec dan resolusi. Ini adalah metadata yang digunakan untuk mekanisme penawaran dan jawaban.
• Mendapatkan potensi alamat jaringan untuk host aplikasi, yang dikenal sebagai kandidat.

Setelah data lokal ini dipastikan, data tersebut harus dipertukarkan melalui mekanisme sinyal dengan peer jarak jauh.

Bayangkan Alice mencoba menelepon Eve. Berikut mekanisme penawaran/jawaban lengkap dengan semua detailnya:

1. Alice membuat objek RTCPeerConnection.
2. Alice membuat penawaran (deskripsi sesi SDP) dengan metode RTCPeerConnection createOffer().
3. Alice menelepon setLocalDescription() untuk menawarkan penawarannya.
4. Alice membuat string penawaran dan menggunakan mekanisme pensinyalan untuk mengirimkannya ke Eve.
5. Eve memanggil setRemoteDescription() dengan penawaran Alice, sehingga RTCPeerConnection-nya mengetahui penyiapan Alice.
6. Eve memanggil createAnswer() dan callback keberhasilan untuk ini meneruskan deskripsi sesi lokal - jawaban Eve.
7. Eve menetapkan jawabannya sebagai deskripsi lokal dengan memanggil setLocalDescription().
8. Kemudian, Eve menggunakan mekanisme sinyal untuk mengirimkan jawaban string-nya kepada Alice.
9. Alice menetapkan jawaban Eve sebagai deskripsi sesi jarak jauh menggunakan setRemoteDescription().

Alice dan Eve juga perlu bertukar informasi jaringan. Ekspresi "menemukan kandidat" mengacu pada proses menemukan antarmuka dan port jaringan menggunakan framework ICE.

1. Alice membuat objek RTCPeerConnection dengan handler onicecandidate.
2. Handler dipanggil saat kandidat jaringan tersedia.
3. Di handler, Alice mengirim data kandidat yang diubah menjadi string ke Eve melalui channel sinyal mereka.
4. Saat Eve menerima pesan kandidat dari Alice, dia akan memanggil addIceCandidate() untuk menambahkan kandidat ke deskripsi peer jarak jauh.

JSEP mendukung ICE Candidate Trickling, yang memungkinkan pemanggil memberikan kandidat secara bertahap kepada penerima panggilan setelah penawaran awal, dan penerima panggilan dapat mulai bertindak atas panggilan dan menyiapkan koneksi tanpa menunggu semua kandidat tiba.

Mengodekan WebRTC untuk pensinyalan

Cuplikan kode berikut adalah contoh kode W3C yang merangkum proses pemberian sinyal lengkap. Kode mengasumsikan keberadaan beberapa mekanisme pensinyalan, SignalingChannel. Pensinyalan akan dibahas lebih mendetail nanti.

// 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);
  }
};

// After 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);
  }
};

Untuk melihat proses penawaran/jawaban dan pertukaran kandidat dalam tindakan, lihat simpl.info RTCPeerConnection dan lihat log konsol untuk contoh chat video satu halaman. Jika Anda ingin lebih banyak, download dump lengkap sinyal dan statistik WebRTC dari halaman about://webrtc-internals di Google Chrome atau halaman opera://webrtc-internals di Opera.

Penemuan peer

Ini adalah cara elegan untuk bertanya, "Bagaimana cara menemukan seseorang untuk diajak bicara?"

Untuk panggilan telepon, Anda memiliki nomor telepon dan direktori. Untuk chat dan pesan video online, Anda memerlukan sistem pengelolaan identitas dan kehadiran, serta cara bagi pengguna untuk memulai sesi. Aplikasi WebRTC memerlukan cara bagi klien untuk memberi sinyal satu sama lain bahwa mereka ingin memulai atau bergabung ke panggilan.

Mekanisme penemuan peer tidak ditentukan oleh WebRTC dan Anda tidak akan melihat opsi di sini. Prosesnya bisa sesederhana mengirim email atau pesan berisi URL. Untuk aplikasi chat video, seperti Talky, tawk.to, dan Browser Meeting, Anda mengundang orang ke panggilan dengan membagikan link kustom. Developer Chris Ball membuat eksperimen serverless-webrtc yang menarik dan memungkinkan peserta panggilan WebRTC bertukar metadata melalui layanan pesan apa pun yang mereka sukai, seperti IM, email, atau merpati pos.

Bagaimana cara membangun layanan pensinyalan?

Untuk mengulanginya, protokol dan mekanisme pensinyalan tidak ditentukan oleh standar WebRTC. Apa pun pilihan Anda, Anda memerlukan server perantara untuk bertukar pesan sinyal dan data aplikasi antar-klien. Sayangnya, aplikasi web tidak dapat begitu saja berteriak ke internet, "Hubungkan saya dengan teman saya!"

Untungnya, pesan sinyal berukuran kecil dan sebagian besar dipertukarkan di awal panggilan. Dalam pengujian dengan appr.tc untuk sesi video chat, total sekitar 30-45 pesan ditangani oleh layanan pensinyalan dengan total ukuran untuk semua pesan sekitar 10 KB.

Selain tidak terlalu menuntut dalam hal bandwidth, layanan pensinyalan WebRTC tidak menggunakan banyak pemrosesan atau memori karena hanya perlu meneruskan pesan dan mempertahankan sedikit data status sesi, seperti klien mana yang terhubung.

Mendorong pesan dari server ke klien

Layanan pesan untuk pensinyalan harus bersifat dua arah: klien ke server dan server ke klien. Komunikasi dua arah bertentangan dengan model permintaan/respons klien/server HTTP, tetapi berbagai solusi seperti polling panjang telah dikembangkan selama bertahun-tahun untuk mengirim data dari layanan yang berjalan di server web ke aplikasi web yang berjalan di browser.

Baru-baru ini, EventSource API telah diterapkan secara luas. Hal ini memungkinkan peristiwa yang dikirim server - data yang dikirim dari server web ke klien browser melalui HTTP. EventSource dirancang untuk pengiriman pesan satu arah, tetapi dapat digunakan bersama dengan XHR untuk membangun layanan pertukaran pesan sinyal. Layanan sinyal meneruskan pesan dari pemanggil, yang dikirimkan oleh permintaan XHR, dengan mengirimkannya melalui EventSource ke penerima panggilan.

WebSocket adalah solusi yang lebih alami, yang dirancang untuk komunikasi klien–server full duplex - pesan yang dapat mengalir dalam kedua arah secara bersamaan. Salah satu keunggulan layanan sinyal yang dibangun dengan WebSocket murni atau peristiwa yang dikirim server (EventSource) adalah bahwa backend untuk API ini dapat diimplementasikan pada berbagai framework web yang umum untuk sebagian besar paket hosting web untuk bahasa seperti PHP, Python, dan Ruby.

Semua browser modern kecuali Opera Mini mendukung WebSocket dan, yang lebih penting, semua browser yang mendukung WebRTC juga mendukung WebSocket, baik di desktop maupun seluler. TLS harus digunakan untuk semua koneksi guna memastikan pesan tidak dapat dicegat tanpa dienkripsi dan juga untuk mengurangi masalah dengan traversal proxy. (Untuk mengetahui informasi selengkapnya tentang WebSocket dan proxy traversal, lihat bab WebRTC di High Performance Browser Networking karya Ilya Grigorik.)

Sinyal juga dapat ditangani dengan membuat klien WebRTC melakukan polling server pesan berulang kali melalui Ajax, tetapi hal ini menyebabkan banyak permintaan jaringan yang berlebihan, yang terutama bermasalah bagi perangkat seluler. Bahkan setelah sesi dibuat, perangkat peer perlu melakukan polling untuk pesan sinyal jika ada perubahan atau penghentian sesi oleh perangkat peer lain. Contoh aplikasi WebRTC Book menggunakan opsi ini dengan beberapa pengoptimalan untuk frekuensi polling.

Menskalakan pemberian sinyal

Meskipun layanan pensinyalan menggunakan bandwidth dan CPU yang relatif kecil per klien, server pensinyalan untuk aplikasi populer mungkin harus menangani banyak pesan dari berbagai lokasi dengan tingkat serentak yang tinggi. Aplikasi WebRTC yang mendapatkan banyak traffic memerlukan server pensinyalan yang dapat menangani beban yang cukup besar. Anda tidak menjelaskan secara mendetail di sini, tetapi ada sejumlah opsi untuk pengiriman pesan bervolume tinggi dan berperforma tinggi, termasuk yang berikut:

• eXtensible Messaging and Presence Protocol (XMPP), yang awalnya dikenal sebagai Jabber, adalah protokol yang dikembangkan untuk pesan instan yang dapat digunakan untuk pensinyalan (Implementasi server mencakup ejabberd dan Openfire. Klien JavaScript, seperti Strophe.js, menggunakan BOSH untuk meniru streaming dua arah, tetapi karena berbagai alasan, BOSH mungkin tidak seefisien WebSocket dan, karena alasan yang sama, mungkin tidak dapat diskalakan dengan baik.) (Sebagai informasi tambahan, Jingle adalah ekstensi XMPP untuk mengaktifkan suara dan video. Project WebRTC menggunakan komponen jaringan dan transpor dari library libjingle - implementasi Jingle C++.)

• Library open source, seperti ZeroMQ (seperti yang digunakan oleh TokBox untuk layanan Rumour mereka) dan OpenMQ (NullMQ menerapkan konsep ZeroMQ ke platform web menggunakan protokol STOMP melalui WebSocket.)

• Platform pesan cloud komersial yang menggunakan WebSocket (meskipun dapat melakukan penggantian ke polling panjang), seperti Pusher, Kaazing, dan PubNub (PubNub juga memiliki API untuk WebRTC).

• Platform WebRTC komersial, seperti vLine

(Panduan Teknologi Web Real-Time dari Developer Phil Leggetter menyediakan daftar lengkap layanan dan library pesan.)

Membangun layanan pemberian sinyal dengan Socket.io di Node

Berikut adalah kode untuk aplikasi web sederhana yang menggunakan layanan sinyal yang dibuat dengan Socket.io di Node. Desain Socket.io memudahkan pembuatan layanan untuk bertukar pesan dan Socket.io sangat cocok untuk pensinyalan WebRTC karena konsep ruang bawaannya. Contoh ini tidak dirancang untuk menskalakan sebagai layanan sinyal tingkat produksi, tetapi mudah dipahami oleh sejumlah kecil pengguna.

Socket.io menggunakan WebSocket dengan penggantian: polling panjang AJAX, streaming multipart AJAX, Iframe Selamanya, dan polling JSONP. Library ini telah di-porting ke berbagai backend, tetapi mungkin paling dikenal karena versi Node-nya yang digunakan dalam contoh ini.

Tidak ada WebRTC dalam contoh ini. Aplikasi ini hanya dirancang untuk menunjukkan cara membangun sinyal ke dalam aplikasi web. Lihat log konsol untuk melihat apa yang terjadi saat klien bergabung ke ruang dan bertukar pesan. Codelab WebRTC ini memberikan petunjuk langkah demi langkah tentang cara mengintegrasikannya ke dalam aplikasi chat video WebRTC yang lengkap.

Berikut adalah index.html klien:

<!DOCTYPE html>
<html>
  <head>
    <title>WebRTC client</title>
  </head>
  <body>
    <script src='/https/web.dev/socket.io/socket.io.js'></script>
    <script src='js/main.js'></script>
  </body>
</html>

Berikut adalah file JavaScript main.js yang dirujuk di klien:

const isInitiator;

room = prompt('Enter room name:');

const socket = io.connect();

if (room !== '') {
  console.log('Joining room ' + room);
  socket.emit('create or join', room);
}

socket.on('full', (room) => {
  console.log('Room ' + room + ' is full');
});

socket.on('empty', (room) => {
  isInitiator = true;
  console.log('Room ' + room + ' is empty');
});

socket.on('join', (room) => {
  console.log('Making request to join room ' + room);
  console.log('You are the initiator!');
});

socket.on('log', (array) => {
  console.log.apply(console, array);
});

Berikut aplikasi server lengkapnya:

const static = require('node-static');
const http = require('http');
const file = new(static.Server)();
const app = http.createServer(function (req, res) {
  file.serve(req, res);
}).listen(2013);

const io = require('socket.io').listen(app);

io.sockets.on('connection', (socket) => {

  // Convenience function to log server messages to the client
  function log(){
    const array = ['>>> Message from server: '];
    for (const i = 0; i < arguments.length; i++) {
      array.push(arguments[i]);
    }
      socket.emit('log', array);
  }

  socket.on('message', (message) => {
    log('Got message:', message);
    // For a real app, would be room only (not broadcast)
    socket.broadcast.emit('message', message);
  });

  socket.on('create or join', (room) => {
    const numClients = io.sockets.clients(room).length;

    log('Room ' + room + ' has ' + numClients + ' client(s)');
    log('Request to create or join room ' + room);

    if (numClients === 0){
      socket.join(room);
      socket.emit('created', room);
    } else if (numClients === 1) {
      io.sockets.in(room).emit('join', room);
      socket.join(room);
      socket.emit('joined', room);
    } else { // max two clients
      socket.emit('full', room);
    }
    socket.emit('emit(): client ' + socket.id +
      ' joined room ' + room);
    socket.broadcast.emit('broadcast(): client ' + socket.id +
      ' joined room ' + room);

  });

});

(Anda tidak perlu mempelajari node-static untuk ini. (Kebetulan digunakan dalam contoh ini.)

Untuk menjalankan aplikasi ini di localhost, Anda harus menginstal Node, Socket.IO, dan node-static. Node dapat didownload dari Node.js (penginstalannya mudah dan cepat). Untuk menginstal Socket.IO dan node-static, jalankan Node Package Manager dari terminal di direktori aplikasi Anda:

npm install socket.io
npm install node-static

Untuk memulai server, jalankan perintah berikut dari terminal di direktori aplikasi Anda:

node server.js

Dari browser Anda, buka localhost:2013. Buka tab atau jendela baru di browser apa pun, lalu buka localhost:2013 lagi. Untuk melihat apa yang terjadi, periksa konsol. Di Chrome dan Opera, Anda dapat mengakses konsol melalui Google Chrome Developer Tools dengan Ctrl+Shift+J (atau Command+Option+J di Mac).

Apa pun pendekatan yang Anda pilih untuk memberi sinyal, backend dan aplikasi klien Anda - setidaknya - harus menyediakan layanan yang serupa dengan contoh ini.

Masalah pemberian sinyal

• RTCPeerConnection tidak akan mulai mengumpulkan kandidat hingga setLocalDescription() dipanggil. Hal ini diwajibkan dalam draf IETF JSEP.
• Manfaatkan Trickle ICE. Panggil addIceCandidate() segera setelah kandidat tiba.

Server sinyal siap pakai

Jika Anda tidak ingin membuat sendiri, ada beberapa server sinyal WebRTC yang tersedia, yang menggunakan Socket.IO seperti contoh sebelumnya dan terintegrasi dengan library JavaScript klien WebRTC:

• webRTC.io adalah salah satu library abstraksi pertama untuk WebRTC.
• Signalmaster adalah server sinyal yang dibuat untuk digunakan dengan library klien JavaScript SimpleWebRTC.

Jika Anda tidak ingin menulis kode sama sekali, platform WebRTC komersial yang lengkap tersedia dari perusahaan seperti vLine, OpenTok, dan Asterisk.

Sebagai catatan, Ericsson membangun server pensinyalan menggunakan PHP di Apache pada awal kemunculan WebRTC. Sekarang sudah agak usang, tetapi ada baiknya melihat kode jika Anda mempertimbangkan sesuatu yang serupa.

Keamanan pensinyalan

"Keamanan adalah seni membuat tidak ada yang terjadi."

Salman Rushdie

Enkripsi bersifat wajib untuk semua komponen WebRTC.

Namun, mekanisme pensinyalan tidak ditentukan oleh standar WebRTC, jadi Anda yang harus mengamankan pensinyalan. Jika penyerang berhasil membajak sinyal, mereka dapat menghentikan sesi, mengalihkan koneksi, serta merekam, mengubah, atau menyisipkan konten.

Faktor terpenting dalam mengamankan pensinyalan adalah menggunakan protokol yang aman - HTTPS dan WSS (misalnya, TLS) - yang memastikan bahwa pesan tidak dapat dicegat tanpa dienkripsi. Selain itu, berhati-hatilah agar tidak menyiarkan pesan sinyal dengan cara yang dapat diakses oleh pemanggil lain menggunakan server sinyal yang sama.

Setelah memberi sinyal: Menggunakan ICE untuk mengatasi NAT dan firewall

Untuk pensinyalan metadata, aplikasi WebRTC menggunakan server perantara, tetapi untuk streaming media dan data yang sebenarnya setelah sesi dibuat, RTCPeerConnection mencoba menghubungkan klien secara langsung atau peer-to-peer.

Dalam dunia yang lebih sederhana, setiap endpoint WebRTC akan memiliki alamat unik yang dapat ditukar dengan peer lain untuk berkomunikasi secara langsung.

Pada kenyataannya, sebagian besar perangkat berada di belakang satu atau beberapa lapisan NAT, beberapa memiliki software antivirus yang memblokir port dan protokol tertentu, dan banyak yang berada di belakang proxy dan firewall perusahaan. Firewall dan NAT sebenarnya dapat diterapkan oleh perangkat yang sama, seperti router WIFI rumah.

Aplikasi WebRTC dapat menggunakan framework ICE untuk mengatasi kompleksitas jaringan dunia nyata. Agar hal ini dapat terjadi, aplikasi Anda harus meneruskan URL server ICE ke RTCPeerConnection, seperti yang dijelaskan dalam artikel ini.

ICE mencoba menemukan jalur terbaik untuk menghubungkan peer. Fitur ini mencoba semua kemungkinan secara paralel dan memilih opsi paling efisien yang berfungsi. ICE pertama-tama mencoba membuat koneksi menggunakan alamat host yang diperoleh dari sistem operasi dan kartu jaringan perangkat. Jika gagal (yang akan terjadi pada perangkat di belakang NAT), ICE akan mendapatkan alamat eksternal menggunakan server STUN dan, jika gagal, traffic akan dirutekan melalui server relai TURN.

Dengan kata lain, server STUN digunakan untuk mendapatkan alamat jaringan eksternal dan server TURN digunakan untuk merelai traffic jika koneksi langsung (peer-to-peer) gagal.

Setiap server TURN mendukung STUN. Server TURN adalah server STUN dengan fungsionalitas penerusan bawaan tambahan. ICE juga mengatasi kompleksitas penyiapan NAT. Pada kenyataannya, NAT hole-punching mungkin memerlukan lebih dari sekadar alamat IP:port publik.

URL untuk server STUN dan/atau TURN (opsional) ditentukan oleh aplikasi WebRTC dalam objek konfigurasi iceServers yang merupakan argumen pertama untuk konstruktor RTCPeerConnection. Untuk appr.tc, nilai tersebut akan terlihat seperti ini:

{
  'iceServers': [
    {
      'urls': 'stun:stun.l.google.com:19302'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=udp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    },
    {
      'urls': 'turn:192.158.29.39:3478?transport=tcp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    }
  ]
}

Setelah RTCPeerConnection memiliki informasi tersebut, keajaiban ICE akan terjadi secara otomatis. RTCPeerConnection menggunakan framework ICE untuk menentukan jalur terbaik antar-peer, dengan menggunakan server STUN dan TURN sesuai kebutuhan.

STUN

NAT menyediakan alamat IP untuk perangkat yang akan digunakan dalam jaringan lokal pribadi, tetapi alamat ini tidak dapat digunakan secara eksternal. Tanpa alamat publik, tidak ada cara bagi peer WebRTC untuk berkomunikasi. Untuk mengatasi masalah ini, WebRTC menggunakan STUN.

Server STUN berada di internet publik dan memiliki satu tugas sederhana - memeriksa alamat IP:port permintaan yang masuk (dari aplikasi yang berjalan di belakang NAT) dan mengirim alamat tersebut kembali sebagai respons. Dengan kata lain, aplikasi menggunakan server STUN untuk menemukan IP:port-nya dari perspektif publik. Proses ini memungkinkan peer WebRTC mendapatkan alamat yang dapat diakses secara publik untuk dirinya sendiri, lalu meneruskannya ke peer lain melalui mekanisme pensinyalan untuk menyiapkan link langsung. (Dalam praktiknya, NAT yang berbeda bekerja dengan cara yang berbeda dan mungkin ada beberapa lapisan NAT, tetapi prinsipnya tetap sama.)

Server STUN tidak perlu melakukan banyak hal atau mengingat banyak hal, sehingga server STUN dengan spesifikasi yang relatif rendah dapat menangani sejumlah besar permintaan.

Sebagian besar panggilan WebRTC berhasil membuat koneksi menggunakan STUN - 86% menurut Webrtcstats.com, meskipun persentasenya bisa lebih rendah untuk panggilan antara peer di balik firewall dan konfigurasi NAT yang kompleks.

TURN

RTCPeerConnection mencoba menyiapkan komunikasi langsung antar-peer melalui UDP. Jika gagal, RTCPeerConnection akan menggunakan TCP. Jika gagal, server TURN dapat digunakan sebagai penggantian, yang meneruskan data antara endpoint.

Sekadar mengulangi, TURN digunakan untuk meneruskan streaming audio, video, dan data antar-peer, bukan data sinyal.

Server TURN memiliki alamat publik, sehingga dapat dihubungi oleh peer meskipun peer berada di balik firewall atau proxy. Server TURN memiliki tugas yang secara konseptual sederhana - untuk merelay streaming. Namun, tidak seperti server STUN, server ini secara inheren menggunakan banyak bandwidth. Dengan kata lain, server TURN harus lebih kuat.

Diagram ini menunjukkan cara kerja TURN. STUN murni tidak berhasil, sehingga setiap peer menggunakan server TURN.

Men-deploy server STUN dan TURN

Untuk pengujian, Google menjalankan server STUN publik, stun.l.google.com:19302, seperti yang digunakan oleh appr.tc. Untuk layanan STUN/TURN produksi, gunakan rfc5766-turn-server. Kode sumber untuk server STUN dan TURN tersedia di GitHub, tempat Anda juga dapat menemukan link ke beberapa sumber informasi tentang penginstalan server. Image VM untuk Amazon Web Services juga tersedia.

Server TURN alternatif adalah restund, yang tersedia sebagai kode sumber dan juga untuk AWS. Berikut petunjuk cara menyiapkan restund di Compute Engine.

1. Buka firewall sesuai kebutuhan untuk tcp=443, udp/tcp=3478.
2. Buat empat instance, satu untuk setiap IP publik, image Ubuntu 12.06 Standar.
3. Siapkan konfigurasi firewall lokal (izinkan APA PUN dari MANA PUN).
4. Menginstal alat: shell sudo apt-get install make sudo apt-get install gcc
5. Instal libre dari creytiv.com/re.html.
6. Ambil restund dari creytiv.com/restund.html dan buka paketnya.
7. wget hancke.name/restund-auth.patch dan terapkan dengan patch -p1 < restund-auth.patch.
8. Jalankan make, sudo make install untuk libre dan restund.
9. Sesuaikan restund.conf dengan kebutuhan Anda (ganti alamat IP dan pastikan alamat IP tersebut berisi rahasia bersama yang sama) lalu salin ke /etc.
10. Salin restund/etc/restund ke /etc/init.d/.
11. Konfigurasi restund:
    1. Setel LD_LIBRARY_PATH.
    2. Salin restund.conf ke /etc/restund.conf.
    3. Tetapkan restund.conf untuk menggunakan 10 yang tepat. Alamat IP.
12. Jalankan restund
13. Uji menggunakan klien stund dari komputer jarak jauh: ./client IP:port

Di luar komunikasi tatap muka: WebRTC multipihak

Anda juga dapat melihat standar IETF yang diusulkan Justin Uberti untuk REST API untuk akses ke Layanan TURN.

Mudah untuk membayangkan kasus penggunaan streaming media yang melampaui panggilan empat mata sederhana. Misalnya, konferensi video antara sekelompok rekan kerja atau acara publik dengan satu pembicara dan ratusan atau jutaan penonton.

Aplikasi WebRTC dapat menggunakan beberapa RTCPeerConnection sehingga setiap endpoint terhubung ke setiap endpoint lainnya dalam konfigurasi mesh. Pendekatan ini digunakan oleh aplikasi, seperti talky.io, dan berfungsi dengan sangat baik untuk sejumlah kecil rekan. Selain itu, pemrosesan dan konsumsi bandwidth menjadi berlebihan, terutama untuk klien seluler.

Atau, aplikasi WebRTC dapat memilih satu endpoint untuk mendistribusikan streaming ke semua endpoint lainnya dalam konfigurasi bintang. Anda juga dapat menjalankan endpoint WebRTC di server dan membuat mekanisme redistribusi Anda sendiri (aplikasi klien contoh disediakan oleh webrtc.org).

Sejak Chrome 31 dan Opera 18, MediaStream dari satu RTCPeerConnection dapat digunakan sebagai input untuk MediaStream lainnya. Hal ini dapat memungkinkan arsitektur yang lebih fleksibel karena memungkinkan aplikasi web menangani pemilihan rute panggilan dengan memilih rekan lain yang akan dihubungkan. Untuk melihat cara kerjanya, lihat WebRTC samples Peer connection relay dan WebRTC samples Multiple peer connections.

Multipoint Control Unit

Opsi yang lebih baik untuk sejumlah besar endpoint adalah menggunakan Multipoint Control Unit (MCU). Server ini berfungsi sebagai jembatan untuk mendistribusikan media di antara sejumlah besar peserta. MCU dapat menangani berbagai resolusi, codec, dan kecepatan frame dalam konferensi video; menangani transkode; melakukan penerusan streaming selektif; serta mencampur atau merekam audio dan video. Untuk panggilan multipihak, ada sejumlah masalah yang perlu dipertimbangkan, terutama cara menampilkan beberapa input video dan mencampur audio dari beberapa sumber. Platform cloud, seperti vLine, juga berupaya mengoptimalkan perutean traffic.

Anda dapat membeli paket hardware MCU lengkap atau membuatnya sendiri.

Beberapa opsi software MCU open source tersedia. Misalnya, Licode (sebelumnya dikenal sebagai Lynckia) menghasilkan MCU open source untuk WebRTC. OpenTok memiliki Mantis.

Selain browser: VoIP, telepon, dan pesan

Sifat WebRTC yang standar memungkinkan komunikasi antara aplikasi WebRTC yang berjalan di browser dan perangkat atau platform yang berjalan di platform komunikasi lain, seperti telepon atau sistem konferensi video.

SIP adalah protokol pensinyalan yang digunakan oleh sistem VoIP dan konferensi video. Untuk mengaktifkan komunikasi antara aplikasi web WebRTC dan klien SIP, seperti sistem konferensi video, WebRTC memerlukan server proxy untuk memediasi pensinyalan. Pensinyalan harus mengalir melalui gateway, tetapi setelah komunikasi dibuat, traffic SRTP (video dan audio) dapat mengalir langsung peer-to-peer.

Public Switched Telephone Network (PSTN) adalah jaringan circuit-switched dari semua telepon analog "biasa". Untuk panggilan antara aplikasi web WebRTC dan telepon, traffic harus melalui gateway PSTN. Demikian pula, aplikasi web WebRTC memerlukan server XMPP perantara untuk berkomunikasi dengan endpoint Jingle seperti klien IM. Jingle dikembangkan oleh Google sebagai ekstensi untuk XMPP guna mengaktifkan suara dan video untuk layanan pesan. Implementasi WebRTC saat ini didasarkan pada library libjingle C++, implementasi Jingle yang awalnya dikembangkan untuk Talk.

Sejumlah aplikasi, library, dan platform memanfaatkan kemampuan WebRTC untuk berkomunikasi dengan dunia luar:

• sipML5: klien SIP JavaScript open source
• jsSIP: Library SIP JavaScript
• Phono: API telepon JavaScript open source yang dibuat sebagai plugin
• Zingaya: widget telepon yang dapat disematkan
• Twilio: suara dan pesan
• Uberconference: konferensi

Developer sipML5 juga telah membuat gateway webrtc2sip. Tethr dan Tropo telah mendemonstrasikan framework untuk komunikasi saat bencana "dalam koper" menggunakan sel OpenBTS untuk memungkinkan komunikasi antara ponsel menengah dan komputer melalui WebRTC. Itu adalah komunikasi telepon tanpa operator.

Cari tahu lebih lanjut

Codelab WebRTC memberikan petunjuk langkah demi langkah tentang cara membuat aplikasi chat video dan teks menggunakan layanan sinyal Socket.io yang berjalan di Node.

Presentasi WebRTC Google I/O tahun 2013 dengan pemimpin teknologi WebRTC, Justin Uberti

Presentasi Chris Wilson di SFHTML5 - Introduction to WebRTC Apps

Buku setebal 350 halaman WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web memberikan banyak detail tentang jalur data dan sinyal, serta menyertakan sejumlah diagram topologi jaringan yang mendetail.

WebRTC and Signaling: What Two Years Has Taught Us - Postingan blog TokBox tentang alasan tidak memasukkan pensinyalan dalam spesifikasi adalah ide yang bagus

A Practical Guide to Building WebRTC Apps karya Ben Strong memberikan banyak informasi tentang topologi dan infrastruktur WebRTC.

Bab WebRTC dalam High Performance Browser Networking Ilya Grigorik membahas secara mendalam arsitektur, kasus penggunaan, dan performa WebRTC.