WebRTC, comunicação ponto a ponto com RTCPeerConnection

Em meu artigo anterior, discuti sobre o uso da função getUserMedia do WebRTC e como você pode solicitar permissão do usuário e acessar o vídeo e o microfone do usuário. Recomendo a leitura desse artigo antes de ler este.

Portanto, esse exemplo funcionou muito bem apenas para exibir o conteúdo no navegador, mas seria mais útil enviar esses dados pela rede e poder bater um papo com seus amigos e podemos usar RTCPeerConnection.

RTCPeerConnection

Esta é outra extensão de API para WebRTC que lida com a conexão ponto a ponto para getUserMedia. RTCPeerConnection permite que dois usuários se comuniquem diretamente de um navegador para outro. Pegamos streams de mídia que recebemos de getUserMedia e os conectamos à conexão de mesmo nível e os enviamos para o outro lado. Quando o outro lado os recebe, eles aparecem como um novo fluxo de mídia em sua conexão de mesmo nível e podem conectá-los a um elemento de vídeo para exibi-lo na página. Portanto, ambos os lados têm uma conexão de mesmo nível, ambos obtêm streams de getUserMedia, eles os conectam e ambos os streams saem magicamente codificados e decodificados do outro lado. Cada RTCPeerConnection tem um agente ICE e é assim que RTCPeerConnection conecta dois pares.

GELO

ICE (Interactive Connectivity Establishment) é usado para fazer a conexão ponto a ponto para nós através da rede. O ICE primeiro tenta conectar os pares diretamente usando a latência mais baixa possível, via UDP. Em nossa rede, usamos um firewall NAT em nosso navegador que nos impede de saber nosso endereço IP público. Quando estamos atrás de um firewall, não sabemos qual é nosso endereço IP público, então enviamos uma solicitação a um servidor STUN para obter nosso endereço IP público e, então, podemos criar uma conexão ponto a ponto. Às vezes, o STUN nem sempre funciona, o ICE usa outro método chamado TURN como fallback. O TURN nos permite enviar os dados através de um servidor proxy e é garantido que nossos dados chegarão ao outro ponto, mas ao custo de latência e largura de banda. Estudos mostram que STUN funciona na maioria das vezes.

HTML5 Rocks tem um ótimo artigo sobre isso e WebRTC, você pode lê-lo aqui. http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-real