Google está empenhada em fazer avançar a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Começando com conexões de pares

Conexões ponto é a parte das especificações WebRTC que lida com a ligação entre dois aplicativos em computadores diferentes para se comunicar usando um protocolo peer-to-peer. A comunicação entre os pares podem ser de vídeo, dados binários de áudio ou arbitrária (para clientes que apoiam o RTCDataChannel API). A fim de descobrir como dois pares podem se conectar, ambos os clientes precisam para fornecer uma configuração ICE Server. Isto é, quer um STUN ou um servidor turno, e seu papel é fornecer aos candidatos ICE para cada cliente que é então transferido para o peer remoto. Esta transferência de candidatos ICE é comumente chamado de sinalização.

Sinalização

A especificação inclui WebRTC APIs para comunicar com um ICE (Internet Estabelecimento de Conectividade) servidor, mas o componente de sinalização não é parte do mesmo. A sinalização é necessária para que dois pares para compartilhar como eles devem se conectar. Normalmente, isso é resolvido através de uma baseada em HTTP normal Web API (ou seja, um serviço REST ou outro mecanismo RPC), onde aplicações web podem retransmitir as informações necessárias antes da conexão ponto é iniciada.

O código de acompanhamento snippet mostra como este serviço de sinalização fictious podem ser usados ​​para enviar e receber mensagens de forma assíncrona. Esta será usada nos exemplos restantes neste guia, quando necessário.

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

Sinalização pode ser implementada em muitas maneiras diferentes, ea especificação WebRTC não preferem qualquer solução específica.

Iniciar ligações pares

Cada conexão ponto é tratado por um RTCPeerConnection objeto. O construtor para esta classe tem um único RTCConfiguration objeto como parâmetro. Este objeto define como a conexão ponto está configurado e deve conter informações sobre os servidores de gelo para uso.

Uma vez que o RTCPeerConnection é criado precisamos criar uma oferta SDP ou resposta, dependendo se estamos a ponto de chamada ou recepção de pares. Uma vez que a oferta SDP ou resposta é criado, ele deve ser enviado para o ponto remoto através de um canal diferente. Passando SDP objetos aos pares remotos é chamada sinalização e não é coberto pela especificação WebRTC.

Para iniciar a configuração da conexão de pares do lado chamando, criamos um RTCPeerConnection objeto e, em seguida, chamar createOffer() para criar uma RTCSessionDescription objeto. Esta sessão descrição é definida como a descrição local usando setLocalDescription() e é então enviado através de nosso canal de sinalização para o lado de recebimento. Nós também configurar um ouvinte para o nosso canal de sinalização para quando uma resposta à nossa sessão descrição oferecida é recebida do lado de recepção.

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

No lado receptor, esperamos por uma oferta recebida antes de criar o nosso RTCPeerConnection instância. Uma vez feito isto vamos definir a oferta recebida usando setRemoteDescription() . Em seguida, chamamos createAnswer() para criar uma resposta para a proposta recebida. Essa resposta é definido como a descrição local usando setLocalDescription() e, em seguida, enviado para o lado chamando sobre o nosso servidor de sinalização.

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

Uma vez que os dois colegas criaram ambas as descrições de sessão locais e remotos eles sabem as capacidades do ponto remoto. Isso não significa que a conexão entre os pares está pronto. Para que isso funcione, precisamos recolher os candidatos gelo em cada peer e transferência (sobre o canal de sinalização) para os outros pares.

candidatos ICE

Antes de dois pares pode communitcate usando WebRTC, eles precisam informações de conectividade de câmbio. Desde que as condições da rede pode variar dependning em uma série de fatores, um serviço externo é normalmente usado para descobrir as possíveis candidatos para se conectar a uma rede peer. Este serviço é chamado ICE e está usando um STUN ou um servidor de volta. STUN significa sessão Traversal Utilities para NAT, e normalmente é usado indiretamente na maioria das aplicações WebRTC.

VOLTA (Traversal Usando Relé NAT) é a solução mais avançada que incorpora os protocolos Stun e a maioria dos serviços baseados WebRTC comercial usar um servidor de volta para o estabelecimento de conexões entre pares. A API WebRTC suporta tanto STUN e vire diretamente, e ele é recolhida sob o termo mais completo Internet Estabelecimento de Conectividade. Ao criar uma conexão WebRTC, que geralmente oferecem um ou vários servidores ICE na configuração para o RTCPeerConnection objeto.

trickle ICE

Uma vez que um RTCPeerConnection objeto é criado, a estrutura subjacente usa os servidores ICE previstos para reunir candidatos para o estabelecimento de conectividade (candidatos ICE). O evento icegatheringstatechange em RTCPeerConnection sinais em que estado o encontro ICE é ( new , gathering ou complete ).

Embora seja possível para um par de esperar até a reunião ICE está completo, é geralmente muito mais eficiente usar uma técnica de "ice trickle" e transmitir cada candidato ICE para o peer remoto como ele é descoberto. Isto irá reduzir significativamente o tempo de configuração para a conectividade ponto e permitir que uma chamada de vídeo para começar com menos atrasos.

Para reunir candidatos ICE, basta adicionar um ouvinte para o icecandidate evento. O RTCPeerConnectionIceEvent emitida em que ouvinte irá conter candidate propriedade que representa um novo candidato que deve ser enviado para o ponto remoto (consulte 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);
        }
    }
});
 

Conexão estabelecida

Uma vez que os candidatos ICE estão sendo recebidos, devemos esperar o estado de nossa conexão de pares acabará por mudar para um estado conectado. Para detectar isso, adicionar um ouvinte para o nosso RTCPeerConnection onde nós ouvir connectionstatechange eventos.

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

Documentação da API RTCPeerConnection