Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Memulai dengan koneksi peer

Koneksi rekan adalah bagian dari spesifikasi WebRTC yang berhubungan dengan menghubungkan dua aplikasi pada komputer yang berbeda untuk berkomunikasi menggunakan protokol peer-to-peer. Komunikasi antara rekan dapat berupa video, audio, atau data biner sewenang-wenang (untuk klien yang mendukung API RTCDataChannel ). Untuk mengetahui bagaimana dua rekan dapat terhubung, kedua klien perlu menyediakan konfigurasi Server ICE. Ini adalah STUN atau TURN-server, dan peran mereka adalah menyediakan kandidat ICE untuk setiap klien yang kemudian ditransfer ke peer jarak jauh. Pemindahan kandidat ICE ini biasa disebut pensinyalan.

Pemberian sinyal

Spesifikasi WebRTC termasuk API untuk berkomunikasi dengan ICE (Internet Connectivity Establishment) Server, tetapi komponen pensinyalan bukan bagian darinya. Sinyal diperlukan agar dua rekan untuk berbagi bagaimana mereka harus terhubung. Biasanya ini diselesaikan melalui Web API berbasis HTTP biasa (yaitu, layanan REST atau mekanisme RPC lainnya) di mana aplikasi web dapat menyampaikan informasi yang diperlukan sebelum koneksi rekan dimulai.

Cuplikan kode tindak menunjukkan bagaimana layanan pensinyalan fiktif ini dapat digunakan untuk mengirim dan menerima pesan secara tidak sinkron. Ini akan digunakan dalam sisa contoh dalam panduan ini jika perlu.

 // Set up an asynchronous communication channel that will be
// used during the peer connection setup
const signalingChannel = new SignalingChannel(remoteClientId);
signalingChannel.addEventListener('message', message => {
    // New message from remote client received
});

// Send an asynchronous message to the remote client
signalingChannel.send('Hello!');
 

Pensinyalan dapat diimplementasikan dengan berbagai cara, dan spesifikasi WebRTC tidak memilih solusi spesifik.

Memulai koneksi peer

Setiap koneksi peer ditangani oleh objek RTCPeerConnection . Konstruktor untuk kelas ini mengambil objek RTCConfiguration tunggal sebagai parameternya. Objek ini menentukan bagaimana koneksi peer diatur dan harus berisi informasi tentang server ICE untuk digunakan.

Setelah RTCPeerConnection dibuat, kita perlu membuat penawaran atau jawaban SDP, tergantung pada apakah kita rekan panggilan atau rekan penerima. Setelah penawaran atau jawaban SDP dibuat, itu harus dikirim ke rekan jauh melalui saluran yang berbeda. Melewati objek SDP ke rekan-rekan jauh disebut pensinyalan dan tidak dicakup oleh spesifikasi WebRTC.

Untuk memulai pengaturan koneksi rekan dari sisi panggilan, kami membuat objek RTCPeerConnection dan kemudian memanggil createOffer() untuk membuat objek RTCSessionDescription . Deskripsi sesi ini ditetapkan sebagai deskripsi lokal menggunakan setLocalDescription() dan kemudian dikirim melalui saluran pensinyalan kami ke sisi penerima. Kami juga mengatur pendengar ke saluran pensinyalan kami ketika jawaban untuk deskripsi sesi yang kami tawarkan diterima dari sisi penerima.

 async function makeCall() {
    const configuration = {'iceServers': [{'urls': 'stun:stun.l.google.com:19302'}]}
    const peerConnection = new RTCPeerConnection(configuration);
    signalingChannel.addEventListener('message', async message => {
        if (message.answer) {
            const remoteDesc = new RTCSessionDescription(message.answer);
            await peerConnection.setRemoteDescription(remoteDesc);
        }
    });
    const offer = await peerConnection.createOffer();
    await peerConnection.setLocalDescription(offer);
    signalingChannel.send({'offer': offer});
}
 

Di sisi penerima, kami menunggu penawaran yang masuk sebelum kami membuat instance RTCPeerConnection kami. Setelah selesai, kami mengatur penawaran yang diterima menggunakan setRemoteDescription() . Selanjutnya, kami memanggil createAnswer() untuk membuat jawaban atas tawaran yang diterima. Jawaban ini ditetapkan sebagai deskripsi lokal menggunakan setLocalDescription() dan kemudian dikirim ke sisi panggilan melalui server pensinyalan kami.

 const peerConnection = new RTCPeerConnection(configuration);
signalingChannel.addEventListener('message', async message => {
    if (message.offer) {
        peerConnection.setRemoteDescription(new RTCSessionDescription(message.offer));
        const answer = await peerConnection.createAnswer();
        await peerConnection.setLocalDescription(answer);
        signalingChannel.send({'answer': answer});
    }
});
 

Setelah kedua rekan tersebut menetapkan deskripsi sesi lokal dan jarak jauh, mereka mengetahui kemampuan rekan jauh. Ini tidak berarti bahwa koneksi antar peer sudah siap. Agar ini berfungsi, kita perlu mengumpulkan kandidat ICE di setiap peer dan mentransfer (melalui saluran pensinyalan) ke peer lainnya.

Kandidat ICE

Sebelum dua rekan dapat berkomunikasi menggunakan WebRTC, mereka perlu bertukar informasi konektivitas. Karena kondisi jaringan dapat bervariasi tergantung pada sejumlah faktor, layanan eksternal biasanya digunakan untuk menemukan kandidat yang mungkin untuk terhubung ke peer. Layanan ini disebut ICE dan menggunakan STUN atau server TURN. STUN adalah singkatan dari Session Traversal Utilities untuk NAT, dan biasanya digunakan secara tidak langsung di sebagian besar aplikasi WebRTC.

TURN (Traversal Using Relay NAT) adalah solusi yang lebih canggih yang menggabungkan protokol STUN dan sebagian besar layanan berbasis WebRTC komersial menggunakan server TURN untuk membuat koneksi antar rekan. WebRTC API mendukung STUN dan MENGHIDUPKAN secara langsung, dan dikumpulkan di bawah Internet Connectivity Establishment yang lebih lengkap. Saat membuat koneksi WebRTC, kami biasanya menyediakan satu atau beberapa server ICE dalam konfigurasi untuk objek RTCPeerConnection .

Trickle ICE

Setelah objek RTCPeerConnection dibuat, kerangka kerja yang mendasarinya menggunakan server ICE yang disediakan untuk mengumpulkan kandidat untuk pembentukan konektivitas (kandidat ICE). Acara icegatheringstatechange pada RTCPeerConnection sinyal dalam keadaan apa pertemuan ICE ( new , gathering atau complete ).

Meskipun dimungkinkan bagi seorang rekan untuk menunggu sampai pertemuan ICE selesai, biasanya jauh lebih efisien untuk menggunakan teknik "trickle ice" dan mengirimkan setiap kandidat ICE ke rekan yang jauh ketika ditemukan. Ini secara signifikan akan mengurangi waktu setup untuk konektivitas peer dan memungkinkan panggilan video untuk memulai dengan sedikit penundaan.

Untuk mengumpulkan kandidat ICE, cukup tambahkan pendengar untuk acara icecandidate . RTCPeerConnectionIceEvent dipancarkan pada pendengar itu akan berisi properti candidate yang mewakili kandidat baru yang harus dikirim ke rekan jauh (Lihat Signaling).

 // Listen for local ICE candidates on the local RTCPeerConnection
peerConnection.addEventListener('icecandidate', event => {
    if (event.candidate) {
        signalingChannel.send({'new-ice-candidate': event.candidate});
    }
});

// Listen for remote ICE candidates and add them to the local RTCPeerConnection
signalingChannel.addEventListener('message', async message => {
    if (message.iceCandidate) {
        try {
            await peerConnection.addIceCandidate(message.iceCandidate);
        } catch (e) {
            console.error('Error adding received ice candidate', e);
        }
    }
});
 

Koneksi terjalin

Setelah kandidat ICE diterima, kita harus berharap negara untuk koneksi rekan kita akhirnya akan berubah menjadi negara terhubung. Untuk mendeteksi ini, kami menambahkan pendengar ke RTCPeerConnection kami di mana kami mendengarkan untuk connectionstatechange RTCPeerConnection acara.

 // Listen for connectionstatechange on the local RTCPeerConnection
peerConnection.addEventListener('connectionstatechange', event => {
    if (peerConnection.connectionState === 'connected') {
        // Peers connected!
    }
});
 

Dokumentasi RTCPeerConnection API