Memulai koneksi pembanding

Koneksi peer adalah bagian dari spesifikasi WebRTC yang menangani menghubungkan dua aplikasi di komputer yang berbeda untuk berkomunikasi menggunakan protokol peer-to-peer. Komunikasi antar rekan dapat berupa video, audio atau data biner arbitrer (untuk klien yang mendukung RTCDataChannel API). Di beberapa untuk menemukan bagaimana dua rekan dapat terhubung, kedua klien perlu memberikan ICE Konfigurasi server. Ini bisa berupa STUN atau server TURN, dan perannya adalah untuk memberikan kandidat ICE ke setiap klien yang kemudian ditransfer ke remote rekan sejawat. Pentransferan kandidat ICE ini biasa disebut pensinyalan.

Pemberian sinyal

Spesifikasi WebRTC mencakup API untuk berkomunikasi dengan ICE (Internet Server Konektivitas), tetapi komponen sinyal bukan bagian dari anotasi. Sinyal diperlukan agar dua rekan dapat berbagi bagaimana mereka harus terhubung. Biasanya ini diselesaikan melalui API Web berbasis HTTP reguler (yaitu, REST atau mekanisme RPC lainnya) tempat aplikasi web dapat menyampaikan informasi sebelum koneksi peer dimulai.

Cuplikan kode berikut menunjukkan bagaimana layanan pensinyalan fiktif ini dapat digunakan untuk mengirim dan menerima pesan secara asinkron. Ini akan digunakan di sisa contoh dalam panduan ini jika diperlukan.

// 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!');

Sinyal dapat diterapkan dengan berbagai cara, dan WebRTC spesifikasi tidak lebih menyukai solusi spesifik apa pun.

Memulai koneksi pembanding

Setiap koneksi peer ditangani oleh objek RTCPeerConnection. Konstruktor untuk class ini menggunakan satu objek RTCConfiguration sebagai parameternya. Ini mendefinisikan cara koneksi peer disiapkan dan harus berisi informasi tentang server ICE untuk digunakan.

Setelah RTCPeerConnection dibuat, kita perlu membuat penawaran SDP atau jawaban, tergantung pada apakah kita adalah rekan yang menelepon atau menerima. Setelah SDP dibuat, maka harus dikirim ke peer jarak jauh melalui saluran yang berbeda. Meneruskan objek SDP ke rekan jarak jauh disebut sinyal dan tidak tercakup dalam spesifikasi WebRTC.

Untuk memulai pengaturan koneksi peer dari sisi panggilan, kita membuat Objek RTCPeerConnection, lalu panggil createOffer() untuk membuat Objek RTCSessionDescription. Deskripsi sesi ini ditetapkan sebagai deskripsi menggunakan setLocalDescription() dan kemudian dikirim melalui sinyal kami ke sisi penerima. Kita juga menyiapkan pemroses untuk sinyal kita channel Anda ketika jawaban atas deskripsi sesi yang kami tawarkan di 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, kita menunggu penawaran masuk sebelum membuat Instance RTCPeerConnection. Setelah selesai, kita menetapkan penawaran yang diterima menggunakan setRemoteDescription(). Selanjutnya, kita memanggil createAnswer() untuk membuat jawaban atas penawaran yang diterima. Jawaban ini ditetapkan sebagai deskripsi lokal menggunakan setLocalDescription() lalu dikirim ke sisi pemanggil melalui sinyal kita server tertentu.

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 {i>peer remote<i}. Ini tidak berarti bahwa koneksi antar-rekan sudah siap. Agar hal ini berjalan, kita harus mengumpulkan ICE di setiap peer dan ditransfer (melalui saluran sinyal) ke kandidat lainnya rekan sejawat.

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 memungkinkan untuk terhubung ke peer. Layanan ini disebut ICE dan menggunakan server STUN atau TURN. STUN adalah singkatan dari Session Traversal Utilitas untuk NAT, dan biasanya digunakan secara tidak langsung di sebagian besar aplikasi WebRTC.

TURN (Traversal Menggunakan Relay NAT) adalah solusi yang lebih canggih yang menggabungkan protokol STUN dan sebagian besar layanan berbasis WebRTC komersial menggunakan server TURN untuk membangun koneksi di antara rekan. WebRTC API mendukung STUN dan TURN secara langsung, dan ini dihimpun dari istilah Internet yang lebih lengkap. Pengembangan Konektivitas. Saat membuat koneksi WebRTC, kami biasanya menyediakan satu atau beberapa server ICE dalam konfigurasi untuk Objek RTCPeerConnection.

Trickle ICE

Setelah objek RTCPeerConnection dibuat, framework yang mendasarinya akan menggunakan menyediakan server ICE untuk mengumpulkan kandidat untuk pembentukan konektivitas (ICE kandidat). Peristiwa icegatheringstatechange pada sinyal RTCPeerConnection di negara bagian tempat pertemuan ICE (new, gathering, atau complete).

Meskipun ada kemungkinan rekan untuk menunggu hingga pengumpulan ICE selesai, biasanya jauh lebih efisien menggunakan "trickle ice" dan mentransmisikan setiap kandidat ICE ke rekan jarak jauh saat ditemukan. Hal ini akan mengurangi waktu penyiapan secara signifikan untuk konektivitas peer dan memungkinkan video untuk memulai dengan lebih sedikit penundaan.

Untuk mengumpulkan kandidat ICE, cukup tambahkan pemroses untuk peristiwa icecandidate. RTCPeerConnectionIceEvent yang dimunculkan pada pemroses tersebut akan berisi Properti candidate yang mewakili kandidat baru yang harus dikirim ke peer jarak jauh (Lihat Sinyal).

// 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 mengharapkan negara bagian untuk koneksi akhirnya akan berubah ke status terhubung. Untuk mendeteksi hal ini, kita menambahkan pemroses RTCPeerConnection tempat kita memproses connectionstatechange peristiwa.

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

RTCPeerConnection API dokumentasi