Google se compromete a avanzar en la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Primeros pasos con conexiones entre pares

conexiones entre pares es parte de las especificaciones de WebRTC que se ocupa de la conexión de dos aplicaciones en distintos ordenadores para comunicarse utilizando un protocolo peer-to-peer. La comunicación entre pares puede ser de vídeo, datos binarios de audio o arbitraria (para los clientes que apoyan la RTCDataChannel API). Con el fin de descubrir cómo dos pares pueden conectar, tanto a los clientes necesitan para proporcionar una configuración de servidor de ICE. Este puede ser un efecto de aturdimiento o un servidor TURN, y su función es proporcionar candidatos ICE para cada cliente que luego se transfiere a la par remoto. Esta transferencia de candidatos ICE se llama comúnmente de señalización.

Señalización

La especificación WebRTC incluye API para la comunicación con un ICE (Internet Conectividad Establecimiento) Server, pero el componente de señalización no es parte de ella. La señalización es necesaria para que dos compañeros que compartan cómo deben conectarse. Por lo general, esto se soluciona a través de un API Web basado en HTTP normal (es decir, un servicio REST u otro mecanismo RPC) se inicia cuando las aplicaciones web pueden transmitir la información necesaria antes de la conexión entre pares.

El código de seguimiento fragmento de código muestra cómo este servicio de señalización ficticia se puede utilizar para enviar y recibir mensajes de forma asíncrona. Esto será utilizado en los ejemplos restantes de esta guía donde sea necesario.

 // 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 señalización se puede implementar de muchas maneras diferentes, y la especificación WebRTC no prefiere una solución concreta.

El inicio de las conexiones entre pares

Cada conexión entre pares es manejado por un RTCPeerConnection objeto. El constructor de esta clase toma un único RTCConfiguration objeto como su parámetro. Este objeto define la forma en la conexión entre pares está configurado y debe contener información sobre los servidores de hielo para su uso.

Una vez que el RTCPeerConnection se crea que necesitamos para crear una oferta SDP o respuesta, dependiendo de si estamos llamando el par o la recepción de pares. Una vez creada la oferta SDP o respuesta, debe ser enviada a la distancia entre pares a través de un canal diferente. SDP pasar objetos a interlocutores remotos se llama de señalización y no está cubierto por la especificación WebRTC.

Para iniciar el establecimiento de la comunicación entre pares desde el lado llamante, creamos un RTCPeerConnection objeto y luego llamamos createOffer() para crear un RTCSessionDescription objeto. Esta descripción de la sesión se establece como la descripción local utilizando setLocalDescription() y después se envía a través de nuestro canal de señalización al lado de recepción. Hemos creado también un oyente a nuestro canal de señalización para cuando se recibe una respuesta a nuestra descripción de la sesión que se ofrecen desde el lado de recepción.

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

En el lado receptor, esperamos a que una oferta entrante antes de que creamos nuestra RTCPeerConnection ejemplo. Una vez hecho esto nos propusimos la oferta recibida utilizando setRemoteDescription() . A continuación, se llama createAnswer() para crear una respuesta a la oferta recibida. Esta respuesta está configurado como la descripción local utilizando setLocalDescription() y luego se envían a un lado llamar a través de nuestro servidor de señalización.

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

Una vez que los dos compañeros han establecido tanto las descripciones de la sesión locales y remotos que conocen las capacidades del par remoto. Esto no significa que la conexión entre los pares está listo. Para que esto funcione tenemos que recoger los candidatos hielo en cada extremo de comunicación y la transferencia (a través del canal de señalización) al otro por pares.

candidatos ICE

Antes de dos pares pueden communitcate usando WebRTC, es necesario que la información de conectividad de cambio. Dado que las condiciones de la red puede variar dependning en un número de factores, un servicio externo se utiliza generalmente para descubrir los posibles candidatos para la conexión a un compañero. Este servicio se llama ICE y está utilizando o bien un efecto de aturdimiento o un servidor TURN. STUN significa Sesión Transversales Utilidades para NAT, y por lo general se utiliza indirectamente en la mayoría de aplicaciones de WebRTC.

TURN (Transversal usando Relay NAT) es la solución más avanzada que incorpora los protocolos de aturdir y la mayoría de los servicios basados ​​en WebRTC comerciales utilizan un servidor TURN para establecer conexiones entre pares. La API de WebRTC es compatible tanto con STUN y gire directamente, y se reunió con el término más completo de Internet Conectividad Establecimiento. Al crear una conexión WebRTC, por lo general proporcionar una o varios servidores de ICE en la configuración para el RTCPeerConnection objeto.

Trickle ICE

Una vez que un RTCPeerConnection se crea objeto, el marco subyacente utiliza los servidores ICE previstos para reunir los candidatos para el establecimiento de conectividad (ICE) candidatos. El evento icegatheringstatechange en RTCPeerConnection señales en qué estado se encuentra la reunión ICE es ( new , gathering o complete ).

Si bien es posible que un compañero que esperar hasta la reunión del ICE se ha completado, por lo general es mucho más eficaz utilizar una técnica de "goteo de hielo" y transmitir cada candidato ICE a la distancia entre pares, ya que se descubrió. Esto reducirá significativamente el tiempo de preparación para la conectividad entre pares y permitir que una llamada de vídeo para empezar con menos retrasos.

Para reunir los candidatos ICE, basta con añadir un detector para el icecandidate evento. El RTCPeerConnectionIceEvent emite en ese oyente contendrá candidate propiedad que representa un nuevo candidato que debe ser enviado a la distancia entre pares (Ver 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);
        }
    }
});
 

Conexión establecida

Una vez que se reciben los candidatos ICE, deberíamos esperar que el estado de nuestra conexión de pares con el tiempo va a cambiar a un estado conectado. Para detectar esto, añadimos un oyente de nuestro RTCPeerConnection donde se escucha para connectionstatechange eventos.

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

Documentación de la API RTCPeerConnection