Pourquoi un serveur de signalisation est-il nécessaire pour WebRTC?

WebRTC ne résout pas la découverte (ni ne devrait-elle le faire).

WebRTC sait comment parler directement à un autre pair sans serveur de signalisation, mais il ne sait pas comment découvrir un autre pair. La découverte est un problème inhérent, donc je suis un peu perplexe que les gens s'attendent à ce que WebRTC le résolve pour eux.

Pensez-y: Comment allez-vous m'appeler? Comment allez-vous diriger votre ordinateur pour initier le contact avec moi et pas un milliard d'autres des gens? Par coordonnées GPS? adresse e-mail? IP statique? irc? un message instantané? facebook? numéro de téléphone?

et comment je saurai quand vous appellerez? Mon ordinateur "ring"? Il y a des centaines de façons de résoudre ce problème avec la technologie Web habituelle, donc WebRTC vous rendrait un mauvais service si elle dictait une façon spécifique. Le contexte de votre demande éclairera probablement le meilleur moyen de communiquer avec vous. Peut-être que je vous rencontre dans un forum en ligne ou une salle virtuelle dans un de jeu?

Techniquement parlant, vous n'avez pas strictement besoin un serveur de signalisation avec WebRTC, aussi longtemps que vous avez d'autres moyens d'obtenir une offre SDP (un morceau de texte) à votre Pair, et de recevoir la réponse SDP réciproque en retour, que ce soit par le texte de téléphone, IM, irc, email, ou pigeon porteur. Essayez ceci dans Chrome ou Firefox: https://jsfiddle.net/nnc13tw2 - cliquez sur "Offrir" (attendre jusqu'à 20 secondes), envoyer la sortie à votre ami qui colle dans le même champ, à leur fin et touche Entrer, et de renvoyer la réponse, que vous collez dans le champ de réponse et appuyez sur Entrée. Vous devriez maintenant être connecté, et aucun serveur de connexion n'a jamais été impliqué.

pourquoi le jsfiddle fonctionne: il empaquette tous les candidats ICE dans le SDP, ce qui peut prendre quelques secondes, pour vous donner tout ce dont vous avez besoin en une seule fois.

quelques fonctionnalités avancées, comme modifier le nombre de sources vidéo en cours d'appel, etc. aussi exiger de signalisation, mais une fois qu'un appel a été mise en place, une application pourrait utiliser ses propres canaux de données pour tout besoin de signalisation supplémentaire entre les pairs.

Stackoverflow exige maintenant que j'inclue du code pour le relier à jsfiddle, donc Je pourrais tout aussi bien l'inclure ici (bien que si vous êtes sur Chrome utiliser le violon, ci-dessus, comme accéder à la caméra ne semble pas fonctionner dans des extraits de code):

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>

1. Oui, la signalisation est obligatoire pour que les candidats de L'ICE et autres soient échangés pour que la connexion par les pairs sache qui est son pair
2. Non, comment connaîtrait-il son pair sans une sorte d'échange?
3. Non, ça ne veut pas dire ça. J'ai fait de nombreuses expériences en travaillant avec raspis, et d'autres appareils natifs que je streamais vidéo à une page de navigateur par une connexion de pair WebRTC.
4. de Quoi tu parles? Vous voulez dire le gain d'utiliser WebRTC vs Flash et un serveur Central? WebRTC est pair à pair et si vous jumelez cela avec GetUserMedia et Html5, vous vous débarrassez du besoin de flash et d'un serveur multimédia central pour gérer tous les échanges de médias.

vous avez besoin d'un serveur de signalisation pour pouvoir établir une connexion entre deux pairs arbitraires; c'est une simple réalité de l'architecture internet en usage aujourd'hui.

pour contacter un autre pair sur le web, vous devez d'abord connaître son adresse IP. Il y a déjà le premier problème. Vous devez connaître l'adresse IP de votre hôte. Comment allez-vous obtenir cette information de pair a à pair B sans que les gens assis à ces ordinateurs s'appellent les uns les autres? par téléphone et en dictant les adresses IP? Pour ce faire, chaque pair découvre d'abord sa propre adresse, puis l'envoie à l'autre Pair. Cela pose deux autres problèmes: comment un pair découvre - t-il son adresse IP vers l'extérieur (qui peut être très différente de sa propre adresse IP), et comment le communique-t-il à l'Autre pair d'une adresse encore inconnue?

c'est ici qu'un serveur de signalisation entre en jeu. Les deux pairs ont une connexion au serveur de signalisation, avant d'avoir une connexion les uns aux autres. Ils utilisent donc le serveur de signalisation pour relayer des messages en leur nom jusqu'à ce qu'ils aient négocié une façon directe de parler. Il serait possible de négocier une connexion sans l'aide d'une tierce partie sur les sous-réseaux locaux; mais ce scénario est probablement assez rare que je ne suis même pas sûr que le spec s'en occupe.

comme pour 3): WebRTC peut être implémenté sur n'importe quel périphérique, c'est juste un protocole; il n'est pas exclusivement lié aux navigateurs.

comme pour 4): la façon "d'héritage" la diffusion en continu d'un navigateur à un autre impliquait toujours un serveur relais au milieu. Ce serveur a de gros besoins de CPU et de bande passante et est un goulot d'étranglement coûteux. WebRTC permet des connexions P2P directes sans intermédiaire, à l'exception d'un serveur de signalisation léger. Aussi, il n'y avait pas vraiment un standard ouvert avant; la plupart du temps, vous versez de l'argent à Adobe d'une façon ou d'une autre.

la plus grande partie de la réponse a été couverte, juste pensé que je voudrais ajouter un petit quelque chose. Lorsque Google a créé webRTC et open source Il ya 4 ans, il l'a fait strictement sur son propre sans aucune capacité de signalisation.

cependant, récemment, Google a acheté Firebase, donc je parierais que bientôt ils seront open sourcing une solution complète de bout en bout pour WebRTC afin que chacun d'entre nous peut avoir un temps encore plus facile la mise en œuvre.

en Parlant de Firebase, je l'ai essayé et il n'est pas mauvais, a obtenu le travail de base effectué: http://antonvolt.com/prototype2/