Google est engagé à faire progresser l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Mise en route avec des connexions par les pairs

connexions par les pairs est la partie du cahier des charges WebRTC qui traite de la connexion de deux applications sur des ordinateurs différents de communiquer en utilisant un protocole peer-to-peer. La communication entre pairs peut être vidéo, données binaires audio ou arbitraires (pour les clients supportant la RTCDataChannel API). Pour découvrir comment deux pairs peuvent se connecter, les clients doivent fournir une configuration ICE Server. C'est soit un STUN ou un serveur TURN, et leur rôle est de fournir aux candidats ICE à chaque client qui est ensuite transféré à l'homologue distant. Ce transfert des candidats ICE est communément appelé la signalisation.

Signalisation

La spécification API WebRTC comprend pour communiquer avec un ICE (connectivité Internet Etablissement) Server, mais le composant de signalisation ne fait pas partie de celui-ci. La signalisation est nécessaire pour que deux pairs de partager la façon dont ils doivent se connecter. Habituellement, cela est résolu grâce à une API Web HTTP régulière (par exemple, un service REST ou un autre mécanisme RPC) où les applications Web peuvent relayer les informations nécessaires avant que la connexion par les pairs est initiée.

Le code de suivi snippet montre comment ce service de signalisation peut être utilisé fictif pour envoyer et recevoir des messages de manière asynchrone. Il sera utilisé dans les exemples de ce guide le cas échéant.

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

La signalisation peut être mis en œuvre de différentes façons, et la spécification de WebRTC ne préfère aucune solution spécifique.

Établir des connexions par les pairs

Chaque connexion homologue est assurée par un RTCPeerConnection objet. Le constructeur de cette classe prend un seul RTCConfiguration objet comme paramètre. Cet objet définit la façon dont la connexion par les pairs est mis en place et doit contenir des informations sur les serveurs ICE à utiliser.

Une fois que le RTCPeerConnection est créé , nous devons créer une offre SDP ou réponse, selon que nous l'appel par les pairs ou la réception par les pairs. Une fois l'offre SDP ou réponse est créé, il doit être envoyé à l'homologue distant par un autre canal. En passant des objets SDP à leurs pairs à distance est appelée signalisation et ne sont pas couverts par la spécification WebRTC.

Pour lancer la configuration de connexion homologue du côté appelant, nous créons un RTCPeerConnection objet puis appelez createOffer() pour créer un RTCSessionDescription objet. Cette description de session est définie comme la description locale à l' aide setLocalDescription() et est ensuite envoyé sur notre canal de signalisation sur le côté de réception. Nous avons également mis en place un écouteur à notre canal de signalisation quand une réponse à notre description de session est reçue du Offertes du côté réception.

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

Sur le nous attendons une offre d' entrée côté réception, avant de créer notre RTCPeerConnection exemple. Une fois cela fait , nous fixons l'offre reçue à l' aide setRemoteDescription() . Ensuite, nous appelons createAnswer() pour créer une réponse à l'offre reçue. Cette réponse est définie comme la description locale à l' aide setLocalDescription() , puis envoyé au côté appelant sur notre serveur de signalisation.

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

Une fois que les deux pairs ont mis les deux descriptions de session locaux et distants, ils connaissent les capacités de l'homologue distant. Cela ne signifie pas que la connexion entre les pairs est prêt. Pour que cela fonctionne, nous devons recueillir les candidats ICE à chaque poste et transfert (sur le canal de signalisation) à l'autre par les pairs.

candidats ICE

Avant deux pairs peuvent communitcate en utilisant WebRTC, ils ont besoin d'échanger des informations de connectivité. , Est généralement utilisé un service externe Etant donné que les conditions du réseau peuvent varier dependning sur un certain nombre de facteurs pour découvrir les candidats possibles pour la connexion à un pair. Ce service est appelé ICE et utilise soit un STUN ou un serveur TURN. STUN signifie session Traversal Utilities pour NAT, et est généralement utilisé indirectement dans la plupart des applications de WebRTC.

TURN (Traversal L'utilisation de relais NAT) est la solution la plus avancée qui intègre les protocoles STUN et la plupart des services à base de WebRTC commerciaux utilisent un serveur TURN pour établir des connexions entre pairs. L'API WebRTC prend en charge les STUN et TURN directement, et il est rassemblé sous le terme plus complet de connectivité Internet Création. Lors de la création d' une connexion WebRTC, nous fournissons généralement un ou plusieurs serveurs ICE dans la configuration de l' RTCPeerConnection objet.

Trickle ICE

Une fois qu'un RTCPeerConnection objet est créé, le cadre sous - jacent utilise les serveurs fournis ICE pour recueillir les candidats pour l' établissement de la connectivité (candidats ICE). L'événement icegatheringstatechange sur RTCPeerConnection signaux dans quel état la collecte ICE est ( new , gathering ou complete ).

Bien qu'il soit possible pour un pair d'attendre jusqu'à ce que la collecte ICE est terminée, il est généralement beaucoup plus efficace d'utiliser une technique de « glace filet » et transmettre chaque candidat ICE à l'homologue distant comme il se découvre. Cela permettra de réduire considérablement le temps d'installation pour la connectivité par les pairs et de permettre un appel vidéo pour commencer avec moins de retards.

Pour recueillir les candidats ICE, il suffit d' ajouter un écouteur pour l' icecandidate événement. Le RTCPeerConnectionIceEvent émis sur cet auditeur contiendra candidate propriété qui représente un nouveau candidat qui devrait être envoyé à l'homologue distant (Voir 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);
        }
    }
});
 

Connection établie

Une fois que les candidats ICE sont reçus, nous devrions attendre de l'Etat pour notre connexion homologue finira par passer à un état connecté. Pour détecter cela, nous ajoutons un auditeur à notre RTCPeerConnection où nous écoutons connectionstatechange événements.

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

RTCPeerConnection documentation de l' API