webrtc - example - stun turn server

¿Por qué se necesita el servidor de señalización para WebRTC?

Question

WebRTC es un protocolo que define el método de transporte para los datos de medios entre pares. Entendido. También funciona sobre RTP / UDP. Esto también entendido.

Al obtener la discusión sobre el servidor de señalización, se menciona que es necesario realizar una verificación de compatibilidad / inicio del canal ... y así sucesivamente.

Mi pregunta es: habiendo dicho anteriormente,

1) ¿Significa que el servidor de señalización es obligatorio?

2) ¿No tiene el WebRTC inteligencia para hablar directamente con el otro par sin señalar el servidor?

3) Todos los artículos relacionados con webRTC comienzan con el estado "¿Está entre la comunicación entre navegador y navegador?", ¿Significa que webRTC no se puede usar entre a) Dispositivo integrado con cámara [Sin navegador], b) navegador en otro lugar.

4) Además, ¿cuál es la ganancia si se usa webRTC en comparación con la forma heredada de transmisión al navegador? [Sinceramente, no conozco el legado].

Sé que es una pregunta teórica. Sin embargo, veo este tipo de preguntas probablemente en diferentes contextos flotando en Internet. Espero que esta pregunta dé algunas respuestas a nivel de Arquitectura. Gracias.

Answer 1

1. Sí, la señalización es obligatoria para que los candidatos de ICE y similares se intercambien para que la conexión entre pares sepa quién es
2. No, ¿cómo conocería a sus pares sin algún tipo de intercambio?
3. No, eso no significa eso. He realizado numerosos experimentos trabajando con raspis y otros dispositivos nativos para transmitir videos a una página del navegador a través de una conexión de pares WebRTC.
4. ¿De qué estás hablando? ¿Te refieres a la ganancia de usar WebRTC vs Flash y un servidor central? WebRTC es de igual a igual y si combina eso con GetUserMedia y Html5, se deshace de la necesidad de flash y un servidor de medios central para manejar todos los intercambios de medios.

Answer 2

La mayor parte de la respuesta se ha cubierto, solo pensé que agregaría algo. Cuando Google creó por primera vez webRTC y lo abrió hace 4 años, lo hizo estrictamente por sí solo sin ninguna capacidad de señalización.

Sin embargo, recientemente Google compró Firebase, por lo que apostaría a que pronto estarán disponibles para obtener una solución completa de extremo a extremo para WebRTC para que todos podamos tener un tiempo aún más fácil para implementarlo.

Hablando de Firebase, lo probé y no está mal, hice el trabajo básico: http://antonvolt.com/prototype2/

Answer 3

Necesita un servidor de señalización para poder establecer una conexión entre dos pares arbitrarios; Es una realidad simple de la arquitectura de Internet en uso hoy en día.

Para contactar a otro compañero en la web, primero debe conocer su dirección IP. Ahí está el primer problema. Necesita saber cuál es la dirección IP de su par. ¿Cómo va a obtener esta información del par A al par B sin que las personas sentadas en estas computadoras se llamen por teléfono y dicten a los destinatarios de IP? Para hacer esto, cada par descubre primero su propia dirección y luego la envía al otro par. Esto abre dos problemas más: ¿cómo descubre un par cuál es su dirección IP externa (que puede ser significativamente diferente de su propia IP), y cómo se comunica esto al otro par de dirección aún desconocida?

Aquí es donde entra un servidor de señalización. Ambos pares tienen una conexión con el servidor de señalización, antes de conectarse entre sí. Entonces usan el servidor de señalización para retransmitir mensajes en su nombre hasta que hayan negociado una forma directa de hablar. Sería posible negociar una conexión sin ayuda de terceros en subredes locales; pero este escenario es probablemente lo suficientemente raro como para que ni siquiera estoy seguro de que la especificación lo aborde.

En cuanto a 3): WebRTC se puede implementar en cualquier dispositivo, es solo un protocolo; No está vinculado exclusivamente a los navegadores.

En cuanto a 4): la forma "heredada" de transmitir cualquier cosa de un navegador a otro siempre involucraba un servidor de retransmisión en el medio. Este servidor tiene grandes requisitos de CPU y ancho de banda y es un cuello de botella costoso. WebRTC permite conexiones P2P directas sin intermediarios, excepto para un servidor de señalización liviano. Además, no había realmente un estándar abierto antes; la mayoría de las veces estarías pagando algo de dinero a Adobe de una forma u otra.

Answer 4

WebRTC no resuelve el descubrimiento (ni debería hacerlo).

WebRTC sabe cómo hablar directamente con otro par sin un servidor de señalización, pero no sabe cómo descubrir a otro par. El descubrimiento es un problema inherente, así que estoy un poco desconcertado porque la gente espera que WebRTC lo resuelva por ellos.

Piénsalo: ¿cómo me vas a llamar? ¿Cómo va a dirigir su computadora para iniciar contacto conmigo y no con un billón de otras personas? ¿Por coordenadas GPS? ¿dirección de correo electrónico? ¿IP estática? irc? ¿mensaje instantáneo? ¿Facebook? ¿número de teléfono?

Además, ¿cómo sabré cuando llames? ¿Mi computadora "sonará"? Hay cientos de formas de resolver esto con la tecnología web normal, por lo que WebRTC le perjudicaría si dictara una forma específica. El contexto de su solicitud probablemente informará los mejores medios de contacto. ¿Tal vez te encuentro en algún foro en línea o sala virtual en un juego en línea?

Técnicamente hablando, no necesita estrictamente un servidor de señalización con WebRTC, siempre que tenga otros medios para obtener una oferta de SDP (un texto) para su compañero y recibir la respuesta recíproca de SDP a cambio, ya sea por teléfono mensaje de texto, mensajería instantánea, irc, correo electrónico o paloma mensajera. Pruebe esto en Chrome o Firefox: https://jsfiddle.net/nnc13tw2 - haga clic en "Ofrecer" (espere hasta 20 segundos), envíe el resultado a su amigo que lo pega en el mismo campo en su extremo y presiona Enter, y pídales que envíen la respuesta, que pegue en el campo de respuesta y presione Enter. Ahora debería estar conectado, y ningún servidor de conexión estuvo involucrado.

Por qué funciona jsfiddle: Empaqueta a todos los candidatos de ICE en el SDP, lo que puede tomar unos segundos, para darle todo lo que necesita de una vez.

Algunas funciones avanzadas, como alterar la cantidad de fuentes de video a mitad de la llamada, etc., también requieren señalización, pero una vez que se ha establecido una llamada, una aplicación podría usar sus propios canales de datos para cualquier necesidad de señalización adicional entre los pares.

ahora exige que incluya código para vincular a jsfiddle, por lo que también podría incluirlo aquí (aunque si está en Chrome use el violín anterior, ya que el acceso a la cámara no parece funcionar en fragmentos):

var config = { iceServers: [{ urls: "stun:stun.l.google.com:19302" }]};

var dc, pc = new RTCPeerConnection(config);
pc.onaddstream = e => v2.srcObject = e.stream;
pc.ondatachannel = e => dcInit(dc = e.channel);
v2.onloadedmetadata = e => log("Connected!");

var haveGum = navigator.mediaDevices.getUserMedia({video:true, audio:true})
  .then(stream => pc.addStream(v1.srcObject = stream))
  .catch(failed);

function dcInit() {
  dc.onopen = () => log("Chat!");
  dc.onmessage = e => log(e.data);
}

function createOffer() {
  button.disabled = true;
  dcInit(dc = pc.createDataChannel("chat"));
  haveGum.then(() => pc.createOffer()).then(d => pc.setLocalDescription(d)).catch(failed);
  pc.onicecandidate = e => {
    if (e.candidate) return;
    offer.value = pc.localDescription.sdp;
    offer.select();
    answer.placeholder = "Paste answer here";
  };
};

offer.onkeypress = e => {
  if (!enterPressed(e) || pc.signalingState != "stable") return;
  button.disabled = offer.disabled = true;
  var desc = new RTCSessionDescription({ type:"offer", sdp:offer.value });
  pc.setRemoteDescription(desc)
    .then(() => pc.createAnswer()).then(d => pc.setLocalDescription(d))
    .catch(failed);
  pc.onicecandidate = e => {
    if (e.candidate) return;
    answer.focus();
    answer.value = pc.localDescription.sdp;
    answer.select();
  };
};

answer.onkeypress = e => {
  if (!enterPressed(e) || pc.signalingState != "have-local-offer") return;
  answer.disabled = true;
  var desc = new RTCSessionDescription({ type:"answer", sdp:answer.value });
  pc.setRemoteDescription(desc).catch(failed);
};

chat.onkeypress = e => {
  if (!enterPressed(e)) return;
  dc.send(chat.value);
  log(chat.value);
  chat.value = "";
};

var enterPressed = e => e.keyCode == 13;
var log = msg => div.innerHTML += "<p>" + msg + "</p>";
var failed = e => log(e);

<video id="v1" height="120" width="160" autoplay muted></video>
<video id="v2" height="120" width="160" autoplay></video><br>
<button id="button" onclick="createOffer()">Offer:</button>
<textarea id="offer" placeholder="Paste offer here"></textarea><br>
Answer: <textarea id="answer"></textarea><br><div id="div"></div>
Chat: <input id="chat"></input><br>
<script src="https://webrtc.github.io/adapter/adapter-latest.js"></script>