Membangun layanan backend aplikasi WebRTC

Sam Dutton

Dipublikasikan: 4 November 2013

WebRTC memungkinkan komunikasi peer-to-peer. WebRTC memerlukan server agar klien dapat bertukar metadata dan mengoordinasikan komunikasi melalui proses yang disebut sinyal. Server juga membantu klien menangani penafsir alamat jaringan (NAT) dan firewall.

Di sini, Anda akan mempelajari cara membangun layanan pensinyalan dan menangani keunikan konektivitas dunia nyata dengan server STUN dan TURN. Anda juga akan memahami cara aplikasi WebRTC dapat menangani panggilan banyak pihak dan berinteraksi dengan layanan, seperti VoIP dan PSTN (juga dikenal sebagai telepon).

Apa yang dimaksud dengan 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 kunci yang digunakan untuk membuat koneksi aman
• Data jaringan, seperti alamat IP dan port host seperti yang terlihat oleh dunia luar

Proses pensinyalan ini memerlukan cara bagi klien untuk meneruskan pesan bolak-balik. Mekanisme tersebut tidak diterapkan oleh WebRTC API. Sebagai gantinya, Anda harus membuatnya sendiri.

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):

Catatan: Penyiapan panggilan WebRTC ini sepenuhnya menentukan dan mengontrol bidang media, tetapi menyerahkan bidang sinyal kepada aplikasi sebanyak mungkin. Alasannya adalah bahwa aplikasi yang berbeda mungkin lebih memilih untuk menggunakan protokol yang berbeda, seperti protokol sinyal panggilan SIP atau Jingle yang ada, atau sesuatu yang kustom untuk aplikasi tertentu. Dalam pendekatan ini, informasi penting yang akan dipertukarkan adalah deskripsi sesi multimedia, yang menentukan informasi konfigurasi media dan transpor yang diperlukan untuk membuat bidang media.

Arsitektur JSEP juga mencegah 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.

Diagram arsitektur JSEP

JSEP memerlukan pertukaran antara peer penawaran dan jawaban, metadata media. 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 arti sebenarnya dari semua istilah SDP yang rumit ini? Lihat contoh Internet Engineering Task Force (IETF).

Perlu diingat bahwa WebRTC dirancang agar penawaran atau jawaban dapat diubah sebelum ditetapkan sebagai deskripsi lokal atau jarak jauh dengan mengedit nilai dalam teks SDP. Misalnya, fungsi preferAudioCodec() di appr.tc dapat digunakan untuk menetapkan codec dan kecepatan bit 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 RTCPeerConnection dan pensinyalan: Penawaran, jawaban, dan kandidat

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

Untuk menginisialisasi proses ini, RTCPeerConnection memiliki dua tugas:

• Pastikan kondisi media lokal, seperti kemampuan resolusi dan codec. Ini adalah metadata yang digunakan untuk mekanisme penawaran dan jawaban.
• Mendapatkan alamat jaringan potensial 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 adalah mekanisme jawaban lengkap dengan semua detailnya:

1. Alice membuat objek RTCPeerConnection.
2. Alice membuat penawaran (deskripsi sesi SDP) dengan metode RTCPeerConnection createOffer().
3. Alice memanggil setLocalDescription() dengan penawarannya.
4. Alice mengubah penawaran menjadi string 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 yang berhasil untuk ini akan meneruskan deskripsi sesi lokal - jawaban Eve.
7. Eve menetapkan jawabannya sebagai deskripsi lokal dengan memanggil setLocalDescription().
8. Eve kemudian menggunakan mekanisme pensinyalan untuk mengirimkan jawaban stringified-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 jaringan dan port menggunakan framework ICE.

1. Alice membuat objek RTCPeerConnection dengan pengendali onicecandidate.
2. Pengendali dipanggil saat kandidat jaringan tersedia.
3. Di pengendali, Alice mengirimkan data kandidat yang diubah menjadi string kepada Eve melalui saluran pensinyalan mereka.
4. Saat Eve mendapatkan pesan kandidat dari Alice, dia memanggil addIceCandidate() untuk menambahkan kandidat ke deskripsi peer jarak jauh.

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

Membuat kode WebRTC untuk pensinyalan

Cuplikan kode berikut adalah contoh kode W3C yang merangkum proses pensinyalan lengkap. Kode ini mengasumsikan adanya beberapa mekanisme sinyal, SignalingChannel. Sinyal akan dibahas secara 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, buka simpl.info RTCPeerConnection dan lihat log konsol untuk contoh video chat satu halaman. Anda dapat mendownload 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 yang lebih formal untuk bertanya, "Bagaimana cara menemukan seseorang untuk diajak bicara?"

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

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

Bagaimana cara membangun layanan sinyal?

Sekali lagi, protokol dan mekanisme pensinyalan tidak ditentukan oleh standar WebRTC. Apa pun yang Anda pilih, Anda memerlukan server perantara untuk bertukar pesan sinyal dan data aplikasi antar-klien. Sayangnya, aplikasi web tidak dapat berteriak ke internet, "Hubungkan saya ke 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 sinyal dengan total ukuran untuk semua pesan sekitar 10 KB.

Selain relatif tidak memerlukan banyak bandwidth, layanan pensinyalan WebRTC tidak menggunakan banyak pemrosesan atau memori karena hanya perlu menyampaikan pesan dan menyimpan sedikit data status sesi, seperti klien mana yang terhubung.

Catatan: Mekanisme sinyal yang digunakan untuk bertukar metadata sesi juga dapat digunakan untuk mengomunikasikan data aplikasi.

Mengirim pesan dari server ke klien

Browser Support

• 6
• 79
• 6
• 5

Source

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 peretasan seperti long polling telah dikembangkan selama bertahun-tahun untuk mengirim data dari layanan yang berjalan di server web ke aplikasi web yang berjalan di browser.

EventSource API memungkinkan peristiwa yang dikirim server, data yang dikirim dari server web ke klien browser melalui HTTP. EventSource dirancang untuk pesan satu arah, tetapi dapat digunakan bersama dengan XHR untuk membangun layanan guna bertukar pesan sinyal. Layanan sinyal meneruskan pesan dari pemanggil, yang dikirim oleh permintaan XHR, dengan mengirimkannya melalui EventSource ke penerima panggilan.

Browser Support

• 5
• 12
• 11
• 5

Source

WebSocket dirancang untuk komunikasi klien-server full duplex, yang berarti pesan dapat mengalir ke kedua arah secara bersamaan. Salah satu keuntungan layanan pensinyalan yang dibangun dengan WebSocket murni atau peristiwa yang dikirim server (EventSource) adalah 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 yang mendukung WebRTC juga mendukung WebSocket. TLS harus digunakan untuk semua koneksi guna memastikan pesan tidak dapat disadap tanpa dienkripsi dan juga untuk mengurangi masalah dengan traversal proxy. Untuk mengetahui informasi selengkapnya tentang WebSocket dan traversal proxy, baca bab WebRTC dalam High Performance Browser Networking karya Ilya Grigorik.

Anda dapat menangani pensinyalan dengan meminta klien WebRTC melakukan polling ke server pesan berulang kali melalui Ajax, tetapi hal ini menyebabkan banyak permintaan jaringan yang redundan, yang sangat bermasalah untuk perangkat seluler. Bahkan setelah sesi dibuat, peer perlu melakukan polling untuk pesan sinyal jika terjadi perubahan atau penghentian sesi oleh peer lain. Contoh aplikasi WebRTC Book mengambil opsi ini dengan beberapa pengoptimalan untuk frekuensi polling.

Pensinyalan skala

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

• eXtensible Messaging and Presence Protocol (XMPP) adalah protokol yang dikembangkan untuk pesan instan yang dapat digunakan untuk memberi sinyal. Implementasi server mencakup ejabberd dan Openfire. Klien JavaScript, seperti Strophe.js, menggunakan BOSH untuk mengemulasi streaming dua arah, tetapi BOSH mungkin tidak efisien dan skalanya buruk, dibandingkan dengan WebSocket.

• 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 mungkin beralih ke polling panjang), seperti Pusher dan Kaazing.

• Platform WebRTC komersial, seperti vLine

Membangun layanan sinyal dengan Socket.io di Node

Berikut adalah kode untuk aplikasi web 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 dirancang untuk jumlah pengguna yang relatif kecil, bukan untuk penggunaan produksi.

Socket.io menggunakan WebSocket dengan penggantian: polling panjang AJAX, streaming multibagian AJAX, Forever Iframe, 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 dirancang untuk menunjukkan cara membangun pensinyalan 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 video chat WebRTC yang lengkap.

Berikut adalah index.html klien:

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

Berikut adalah file JavaScript main.js yang direferensikan 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 adalah aplikasi server lengkap:

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

  });

});

Untuk menjalankan aplikasi ini di localhost, Anda harus memiliki Node.js, Socket.IO, dan node-static. Untuk menginstal Socket.IO dan node-static, jalankan npm 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, 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 pensinyalan, backend dan aplikasi klien Anda harus menyediakan layanan yang mirip dengan contoh ini.

Gotcha sinyal

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

Server sinyal siap pakai

Jika Anda tidak ingin membuatnya sendiri, ada beberapa server pensinyalan 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 pensinyalan yang dibuat untuk digunakan dengan library klien JavaScript SimpleWebRTC.

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

Sebagai catatan, Ericsson membangun server pensinyalan menggunakan PHP di Apache pada masa-masa awal WebRTC. Meskipun sekarang agak usang, Anda sebaiknya melihat kodenya jika mempertimbangkan sesuatu yang serupa.

Keamanan sinyal

Enkripsi wajib untuk semua komponen WebRTC.

Namun, mekanisme pensinyalan tidak ditentukan oleh standar WebRTC, jadi terserah Anda untuk membuat pensinyalan aman. Jika penyerang berhasil membajak sinyal, mereka dapat menghentikan sesi, mengalihkan koneksi, dan merekam, mengubah, atau memasukkan konten.

Faktor terpenting dalam mengamankan sinyal adalah menggunakan protokol yang aman: HTTPS dan WSS, seperti TLS. Hal ini memastikan bahwa pesan tidak dapat disadap tanpa dienkripsi. Selain itu, berhati-hatilah agar tidak menyiarkan pesan sinyal dengan cara yang memungkinkannya diakses oleh penelepon lain yang menggunakan server sinyal yang sama.

Catatan: Untuk mengamankan aplikasi WebRTC, pensinyalan harus selalu menggunakan TLS.

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 dipertukarkan dengan peer lain untuk berkomunikasi secara langsung.

Dunia tanpa NAT dan firewall

Pada kenyataannya, sebagian besar perangkat berada di balik satu atau beberapa lapisan NAT, beberapa memiliki software antivirus yang memblokir port dan protokol tertentu, dan banyak yang berada di balik proxy dan firewall perusahaan. Firewall dan NAT mungkin sebenarnya diimplementasikan oleh perangkat yang sama, seperti router Wi-Fi rumah.

Dunia nyata

Aplikasi WebRTC dapat menggunakan framework ICE untuk mengatasi kompleksitas jaringan di dunia nyata. Untuk mengaktifkannya, aplikasi Anda harus meneruskan URL server ICE ke RTCPeerConnection.

ICE mencoba menemukan jalur terbaik untuk menghubungkan peer. Fungsi 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 untuk 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 fungsi relai 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 TURN (secara opsional) ditentukan oleh aplikasi WebRTC di objek konfigurasi iceServers yang merupakan argumen pertama untuk konstruktor RTCPeerConnection. Untuk appr.tc, nilai tersebut 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'
    }
  ]
}

Catatan: Contoh kredensial TURN memiliki batas waktu dan habis masa berlakunya pada September 2013.

Setelah RTCPeerConnection memiliki informasi tersebut, keajaiban ICE akan terjadi secara otomatis. RTCPeerConnection menggunakan framework ICE untuk menentukan jalur terbaik antara peer, yang berfungsi dengan 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, peer WebRTC tidak dapat berkomunikasi. Untuk mengatasi masalah ini, WebRTC menggunakan STUN.

Server STUN berada di internet publik dan memiliki satu tugas: memeriksa alamat IP:port permintaan masuk (dari aplikasi yang berjalan di balik 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 sinyal untuk menyiapkan link langsung.

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

Sebagian besar panggilan WebRTC berhasil membuat koneksi menggunakan STUN, meskipun mungkin lebih sedikit untuk panggilan antara peer di balik firewall dan konfigurasi NAT yang kompleks.

Menggunakan server STUN untuk mendapatkan alamat IP:port publik

TURN

RTCPeerConnection mencoba menyiapkan komunikasi langsung antara peer melalui UDP. Jika gagal, RTCPeerConnection akan menggunakan TCP. Jika gagal, server TURN dapat digunakan sebagai pengganti, yang merelai data di antara endpoint.

Sekali lagi, TURN digunakan untuk menyampaikan 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 satu tugas: untuk merelai streaming. Tidak seperti server STUN, server TURN pada dasarnya menggunakan banyak bandwidth.

The full Monty: STUN, TURN, dan pensinyalan

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. Anda dapat menyiapkan restund di Compute :

1. Buka firewall seperlunya 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 ANY dari ANY).
4. Instal 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 ekstrak.
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) dan 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 eksternal.
12. Menjalankan restund
13. Uji menggunakan klien stund dari mesin jarak jauh: ./client IP:port

WebRTC multi-pihak

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

Ada banyak kasus penggunaan untuk streaming media yang lebih dari sekadar panggilan one-to-one. 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. Ini adalah pendekatan yang diambil oleh aplikasi, seperti talky.io, dan berfungsi dengan sangat baik untuk sejumlah kecil peer. Selain itu, konsumsi pemrosesan dan bandwidth menjadi berlebihan, terutama untuk klien seluler.

Topologi mesh penuh: Semua orang terhubung ke semua orang

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).

MediaStream dari satu RTCPeerConnection dapat digunakan sebagai input untuk lainnya. Hal ini dapat memungkinkan arsitektur yang lebih fleksibel karena memungkinkan aplikasi web menangani pemilihan rute panggilan dengan memilih peer lain yang akan dihubungkan. Untuk melihat penerapannya, lihat Relay koneksi peer contoh WebRTC dan Beberapa koneksi peer contoh WebRTC.

Unit kontrol multipoint

Opsi yang lebih baik untuk endpoint dalam jumlah besar adalah menggunakan unit kontrol multipoint (MCU). Ini adalah server yang berfungsi sebagai jembatan untuk mendistribusikan media di antara banyak peserta. MCU dapat menangani berbagai resolusi, codec, dan kecepatan frame dalam konferensi video; menangani transcoding; melakukan penerusan streaming selektif; serta menggabungkan atau merekam audio dan video. Untuk panggilan banyak pihak, ada sejumlah masalah yang perlu dipertimbangkan, terutama cara menampilkan beberapa input video dan menggabungkan audio dari beberapa sumber. Platform cloud, seperti vLine, juga berupaya mengoptimalkan pemilihan rute traffic.

Anda dapat membeli paket hardware MCU lengkap atau membuatnya sendiri.

Bagian belakang Cisco MCU

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

Selain browser: VoIP, telepon, dan pesan

Sifat WebRTC yang terstandardisasi 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 sinyal. Pensinyalan harus mengalir melalui gateway, tetapi setelah komunikasi dibuat, traffic SRTP (video dan audio) dapat mengalir secara peer-to-peer.

Public Switched Telephone Network (PSTN) adalah jaringan circuit-switched dari semua telepon analog "lama". 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++, yaitu implementasi Jingle yang awalnya dikembangkan untuk Talk.

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

• jsSIP: Library SIP JavaScript
• Phono: API telepon JavaScript open source yang dibuat sebagai plugin
• Twilio: suara dan pesan

Cari tahu lebih lanjut

• Baca dokumentasi WebRTC API.
• 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 SFHTML5 Chris Wilson: Pengantar Aplikasi WebRTC

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.