web-dev-qa-db-fra.com

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

WebRTC est un protocole qui définit la méthode de transport des données multimédias entre homologues. Compris. Il fonctionne également au-dessus de RTP/UDP. Cela a également compris.

Lors de la discussion sur le serveur de signalisation, il est mentionné qu'il est nécessaire de vérifier la compatibilité/l'initiation du canal ... et ainsi de suite.

Ma question est: après avoir dit ci-dessus,

1) Cela signifie-t-il qu'un serveur de signalisation est obligatoire?

2) WebRTC n'a-t-il pas l'intelligence de parler directement à l'autre homologue sans serveur de signalisation?

3) Chaque article lié à WebRTC commence par la déclaration "C'est entre la communication de navigateur à navigateur?.

4) En outre, quel est le gain si WebRTC est utilisé par rapport à la manière traditionnelle de diffuser dans le navigateur? [Honnêtement, je ne connais pas la voie héritée].

Je sais que c'est une question théorique. Cependant, je vois ce genre de question probablement dans un contexte différent flotte sur Internet. J'espère que cette question donne des réponses au niveau de l'architecture. Merci.

webrtc
31
Whoami

WebRTC ne résout pas la découverte (et ne devrait pas non plus).

WebRTC sait comment parler directement à un autre homologue sans serveur de signalisation, mais il ne sait pas comment découvrir un autre homologue. 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 entrer en contact avec moi et pas avec un milliard d'autres personnes? Par coordonnées GPS? adresse e-mail? I.P statique? irc? message instantané? Facebook? numéro de téléphone?

Aussi, comment saurai-je quand vous appelez? Est-ce que mon ordinateur "sonnera"? Il existe des centaines de façons de résoudre ce problème avec la technologie Web standard, donc WebRTC vous rendrait un mauvais service s'il dictait une manière spécifique. Le contexte de votre candidature informera probablement les meilleurs moyens de contact. Peut-être que je vous rencontre dans un forum en ligne ou une salle virtuelle dans un jeu en ligne?

Techniquement parlant, vous n'avez pas strictement besoin un serveur de signalisation avec WebRTC, tant que vous avez d'autres moyens pour obtenir une offre SDP (un morceau de texte) à votre homologue et recevoir la réciproque SDP répond en retour, que ce soit par SMS, IM, irc, e-mail ou pigeon voyageur. Essayez ceci dans Chrome ou Firefox: https://jsfiddle.net/nnc13tw2 - cliquez sur "Offrir" (attendez jusqu'à 20 secondes), envoyez la sortie à votre ami qui la colle dans le même champ de son côté et appuie sur Entrée, et lui fait renvoyer la réponse, que vous collez dans le champ de réponse et appuyez sur Entrée. Vous devez maintenant être connecté, et aucun serveur de connexion n'a jamais été impliqué.

Pourquoi jsfiddle fonctionne: il regroupe 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.

Certaines fonctionnalités avancées, telles que la modification du nombre de sources vidéo en cours d'appel, etc. nécessitent également une signalisation, mais une fois l'appel établi, une application peut utiliser ses propres canaux de données pour tout autre besoin de signalisation entre les pairs.

Stackoverflow exige maintenant que j'inclue du code pour lier à jsfiddle, donc je pourrais aussi bien l'inclure ici (bien que si vous êtes sur Chrome utilisez le violon ci-dessus, car l'accès à la caméra ne le fait pas semblent fonctionner dans des extraits):

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>
43
jib
  1. Oui, la signalisation est obligatoire pour que les candidats ICE et similaires soient échangés afin que la connexion homologue sache qui est son homologue
  2. Non, comment connaîtrait-il son homologue 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 diffuse de la vidéo sur une page de navigateur via une connexion homologue WebRTC.
  4. Qu'est-ce que tu racontes? Vous voulez dire le gain d'utiliser WebRTC vs Flash et un serveur central? WebRTC est pair à pair et si vous le couplez 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 multimédias.
8
Benjamin Trent

Vous avez besoin d'un serveur de signalisation pour pouvoir établir une connexion entre deux homologues arbitraires; c'est une simple réalité de l'architecture Internet utilisée 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 savoir quelle est l'adresse IP de votre homologue. Comment allez-vous obtenir ces informations du pair A au pair B sans que les personnes assises à ces ordinateurs se téléphonent et dictent les destinataires IP? Pour ce faire, chaque homologue découvre d'abord sa propre adresse, puis l'envoie à l'autre homologue. Cela ouvre deux autres problèmes: comment un homologue découvre-t-il quelle est son adresse IP orientée vers l'extérieur (qui peut être considérablement différente de sa propre IP), et comment le communique-t-il à l'autre homologue dont l'adresse n'est pas encore connue?

C'est là qu'intervient un serveur de signalisation. Les deux pairs ont une connexion au serveur de signalisation, avant de se connecter. Ils utilisent donc le serveur de signalisation pour relayer les messages en leur nom jusqu'à ce qu'ils aient négocié un moyen direct 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 pour que je ne sois même pas sûr que la spécification le traite.

Quant à 3): WebRTC peut être implémenté sur n'importe quel appareil, c'est juste un protocole; ce n'est pas lié exclusivement aux navigateurs.

Quant à 4): la façon "héritée" de diffuser n'importe quoi d'un navigateur à un autre impliquait toujours un serveur relais au milieu. Ce serveur a de gros besoins en CPU et en 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. De plus, il n'y avait pas vraiment de standard ouvert avant; la plupart du temps, vous paieriez de l'argent à Adobe d'une manière ou d'une autre.

6
deceze

La plupart de la réponse a été couverte, je pensais juste ajouter un petit quelque chose. Lorsque Google a créé webRTC pour la première fois et qu'il l'a généré il y a 4 ans, il l'a fait strictement seul sans aucune capacité de signalisation.

Cependant, Google a récemment acheté Firebase, donc je parierais que bientôt ils ouvriront une solution complète de bout en bout pour WebRTC afin que nous puissions tous avoir encore plus de facilité à l'implémenter.

En parlant de Firebase, je l'ai essayé et ce n'est pas mal, j'ai fait le travail de base: http://antonvolt.com/prototype2/

0
AntonV