Las conexiones entre pares son la parte de las especificaciones de WebRTC que se ocupa de conectar dos aplicaciones en diferentes computadoras para comunicarse mediante un protocolo de igual a igual. La comunicación entre pares puede ser de video, audio o datos binarios arbitrarios (para clientes que soportan la API RTCDataChannel ). Para descubrir cómo se pueden conectar dos pares, ambos clientes deben proporcionar una configuración de servidor ICE. Este es un servidor STUN o TURN, y su función es proporcionar candidatos ICE a cada cliente que luego se transfieren al par remoto. Esta transferencia de candidatos ICE se denomina comúnmente señalización.
Señalización
La especificación WebRTC incluye API para comunicarse con un servidor ICE (establecimiento de conectividad a Internet), pero el componente de señalización no forma parte de él. La señalización es necesaria para que dos pares compartan cómo deben conectarse. Por lo general, esto se resuelve a través de una API web normal basada en HTTP (es decir, un servicio REST u otro mecanismo RPC) donde las aplicaciones web pueden transmitir la información necesaria antes de que se inicie la conexión entre pares.
El siguiente fragmento de código muestra cómo este servicio de señalización ficticio se puede utilizar para enviar y recibir mensajes de forma asincrónica. Esto se utilizará en los ejemplos restantes de esta guía cuando 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 formas diferentes y la especificación WebRTC no prefiere ninguna solución específica.
Iniciar conexiones entre pares
Cada conexión de pares es manejada por un objeto RTCPeerConnection . El constructor de esta clase toma un único objeto RTCConfiguration como parámetro. Este objeto define cómo se configura la conexión entre pares y debe contener información sobre los servidores ICE que se utilizarán.
Una vez que se crea la RTCPeerConnection , necesitamos crear una oferta o respuesta SDP, dependiendo de si somos el par que llama o el par receptor. Una vez que se crea la oferta o respuesta SDP, se debe enviar al par remoto a través de un canal diferente. Pasar objetos SDP a pares remotos se denomina señalización y no está cubierto por la especificación WebRTC.
Para iniciar la configuración de la conexión entre pares desde el lado de la llamada, creamos un objeto RTCPeerConnection y luego llamamos a createOffer() para crear un objeto RTCSessionDescription . Esta descripción de sesión se establece como la descripción local usando setLocalDescription() y luego se envía a través de nuestro canal de señalización al lado receptor. También configuramos un oyente para nuestro canal de señalización para cuando se reciba una respuesta a la descripción de nuestra sesión ofrecida desde el lado receptor.
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 una oferta entrante antes de crear nuestra instancia RTCPeerConnection . Una vez hecho esto, configuramos la oferta recibida usando setRemoteDescription() . A continuación, llamamos a createAnswer() para crear una respuesta a la oferta recibida. Esta respuesta se establece como la descripción local usando setLocalDescription() y luego se envía al lado que llama 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 pares han establecido las descripciones de sesión local y remota, conocen las capacidades del par remoto. Esto no significa que la conexión entre los pares esté lista. Para que esto funcione, necesitamos recopilar los candidatos ICE en cada par y transferirlos (a través del canal de señalización) al otro par.
Candidatos ICE
Antes de que dos pares puedan comunicarse usando WebRTC, necesitan intercambiar información de conectividad. Dado que las condiciones de la red pueden variar dependiendo de una serie de factores, generalmente se utiliza un servicio externo para descubrir los posibles candidatos para conectarse a un par. Este servicio se llama ICE y utiliza un servidor STUN o TURN. STUN son las siglas de Session Traversal Utilities para NAT, y generalmente se usa indirectamente en la mayoría de las aplicaciones WebRTC.
TURN (Traversal Using Relay NAT) es la solución más avanzada que incorpora los protocolos STUN y la mayoría de los servicios comerciales basados en WebRTC utilizan un servidor TURN para establecer conexiones entre pares. La API de WebRTC admite STUN y TURN directamente, y se recopila bajo el término más completo Establecimiento de conectividad a Internet. Al crear una conexión WebRTC, normalmente proporcionamos uno o varios servidores ICE en la configuración del objeto RTCPeerConnection .
Goteo de hielo
Una vez que se crea un objeto RTCPeerConnection , el marco subyacente utiliza los servidores ICE proporcionados para reunir candidatos para el establecimiento de conectividad (candidatos ICE). El evento icegatheringstatechange en RTCPeerConnection señala en qué estado se encuentra la reunión de ICE ( new , gathering o complete ).
Si bien es posible que un par espere hasta que se complete la recopilación de ICE, generalmente es mucho más eficiente usar una técnica de "goteo de hielo" y transmitir cada candidato ICE al par remoto a medida que se descubre. Esto reducirá significativamente el tiempo de configuración para la conectividad entre pares y permitirá que una videollamada comience con menos demoras.
Para reunir candidatos de ICE, simplemente agregue un oyente para el evento icecandidate . El RTCPeerConnectionIceEvent emitido en ese oyente contendrá la propiedad de candidate que representa un nuevo candidato que debe enviarse al par remoto (ver Señalización).
// 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 de ICE, debemos esperar que el estado de nuestra conexión entre pares cambie eventualmente a un estado conectado. Para detectar esto, agregamos un oyente a nuestro RTCPeerConnection donde escuchamos eventos de cambio de estado de connectionstatechange .
// Listen for connectionstatechange on the local RTCPeerConnection
peerConnection.addEventListener('connectionstatechange', event => {
if (peerConnection.connectionState === 'connected') {
// Peers connected!
}
});