L’essentiel du WebRTC

Les informations ci-dessous proviennent de RTCPeerConnection; elles pourraient rester ici, comme aller ailleurs. Mais elles ne font pas partie de cette page. Alors pendant que je trie cette page, elles seront ici, jusqu'à ce que je sache où elles appartiennent pour de vrai.

l'utilisation de RTCPeerConnection implique la négociation d'une connexion entre votre machine et une machine distante,et ce, au format SDP entre les deux. L'appelant commence le processus en envoyant une offre à l'appareil distant, qui répond par l'acceptation ou le rejet de la demande de connexion.

Les deux parties (l'appelant et l'appelé) doivent mettre en place leurs propres instances de RTCPeerConnection pour représenter leurs extrémités de la connexion peer-to-peer:

var pc = new RTCPeerConnection();
pc.onaddstream = function (obj) {
  var vid = document.createElement("video");
  document.appendChild(vid);
  vid.srcObject = obj.stream;
};

// Helper functions
function endCall() {
  var videos = document.getElementsByTagName("video");
  for (var i = 0; i < videos.length; i++) {
    videos[i].pause();
  }

  pc.close();
}

function error(err) {
  endCall();
}

l'appelant doit utiliser navigator.getUserMedia() pour obtenir un flux vidéo, puis ajouter ce flux à l'instance de RTCPeerConnection. Une fois que cela a été fait, il doit appeler RTCPeerConnection.createOffer() (en-US) pour créer une offre,puis la configurer et l'envoyer a un serveur faisant office d'intermediaire.

// recuperer la liste des "amis" a partir du serveur
// l'utilisateur selectionne un amis avec qui lancer la connection
navigator.getUserMedia({ video: true }, function (stream) {
  // l'ajout d'un stream locale ne declanche pas onaddstream,
  // donc il faut l'appeler manuellement.
  pc.onaddstream = (e) => (video.src = URL.createObjectURL(e.stream));
  pc.addStream(stream);

  pc.createOffer(function (offer) {
    pc.setLocalDescription(
      offer,
      function () {
        // envoi de l'offre au serveur qui se charge de la transmettre a "l'ami" choisit precedemment.
      },
      error,
    );
  }, error);
});

sur l'autre machine, l'ami recevra l'offre à partir du serveur en utilisant le protocole approprié (définit par le serveur). Une fois que l'offre arrive,navigator.getUserMedia() est une fois de plus appelée pour créer le second flux, qui est ajouté à la RTCPeerConnection. Un objet RTCSessionDescription (en-US) est créé, et mis en place comme la description du distant en appelant RTCPeerConnection.setRemoteDescription() (en-US).

Ensuite, une réponse est créée en utilisant RTCPeerConnection.createAnswer() (en-US) et renvoyé au serveur, qui la transmet à l'appelant.

var offer = getOfferFromFriend();
navigator.getUserMedia({ video: true }, function (stream) {
  pc.onaddstream = (e) => (video.src = URL.createObjectURL(e.stream));
  pc.addStream(stream);

  pc.setRemoteDescription(
    new RTCSessionDescription(offer),
    function () {
      pc.createAnswer(function (answer) {
        pc.setLocalDescription(
          answer,
          function () {
            // envoi de la réponse au serveur qui la transmettra a l'appelant
          },
          error,
        );
      }, error);
    },
    error,
  );
});

retour a la première machine, qui recois la reponse. une fois cette dernière arrivée,l'appelant utilise RTCPeerConnection.setRemoteDescription() (en-US) pour définir la réponse comme la description de l'autre l'extrémité de la connexion.

// pc a été déclaré précédemment, lors de l'envoi de l'offre.
var offer = getResponseFromFriend();
pc.setRemoteDescription(
  new RTCSessionDescription(offer),
  function () {},
  error,
);

Tout ce qui est en dessous de ce point est potentiellement obsolète. Il est toujours là en attente d'examen et d'intégration possible dans d'autres parties de la documentation où il serait encore valides.

Cette page contient des informations périmées selon http://stackoverflow.com/a/25065359/3760500

Peu importe ce que la page de MDN indique, RTPDataChannels est très désuet (faites connaître l'URL). Firefox et Chrome supportent les spec DataChannels maintenant. Idem pour DTLSSRTPKeyAgreement je pense.

Comme vous pouvez l'imaginer, avec une API aussi jeune, vous devez utiliser les préfixes de navigateur et les positionner dans des variables communes.

var PeerConnection =
  window.mozRTCPeerConnection || window.webkitRTCPeerConnection;
var IceCandidate = window.mozRTCIceCandidate || window.RTCIceCandidate;
var SessionDescription =
  window.mozRTCSessionDescription || window.RTCSessionDescription;
navigator.getUserMedia =
  navigator.getUserMedia ||
  navigator.mozGetUserMedia ||
  navigator.webkitGetUserMedia;

C'est le point de départ pour créer une connexion avec un pair. Il accepte des options de configuration sur les serveurs ICE à utiliser pour établir une connexion.

var pc = new PeerConnection(configuration, options);

L'objet RTCConfiguration (en-US) contient l'information sur les serveurs TURN et/ou STUN à utiliser pour ICE. Ceci est requis pour s'assurer que la plupart des utilisateurs peuvent en fait créer une connexion en évitant les restrictions du NAT et du pare-feu.

var configuration = {
  iceServers: [
    { url: "stun:23.21.150.121" },
    { url: "stun:stun.l.google.com:19302" },
    {
      url: "turn:numb.viagenie.ca",
      credential: "webrtcdemo",
      username: "louis%40mozilla.com",
    },
  ],
};

Google met à disposition un serveur STUN public que nous pouvons utiliser. J'ai également créé un compte chez http://numb.viagenie.ca/ pour un accès gratuit à un serveur TURN. Vous pouvez faire la même chose et les remplacer par vos propres informations d'identification.

Selon le type de connexion, vous devez passer des options.

var options = {
  optional: [{ DtlsSrtpKeyAgreement: true }, { RtpDataChannels: true }],
};

DtlsSrtpKeyAgreement est exigé pour Chrome et Firefox pour interagir.

RtpDataChannels est nécessaire si nous voulons utiliser l'API DataChannels sur Firefox.

Après avoir créé la connexion et en passant par les serveurs STUN et TURN disponibles, un événement sera déclenché une fois que le framework ICE aura trouvé certains « candidats » qui permettront de vous connecter avec un pair. Ceci est reconnu comme étant un candidat ICE et exécute une fonction de rappel sur PeerConnection#onicecandidate.

pc.onicecandidate = function (e) {
  // candidate exists in e.candidate
  if (e.candidate == null) {
    return;
  }
  send("icecandidate", JSON.stringify(e.candidate));
  pc.onicecandidate = null;
};

Lorsque le rappel est exécuté, nous devons utiliser le canal de signal pour envoyer le Candidat au pair. Sur Chrome, on trouve habituellement plusieurs candidats ICE, nous n'en avons besoin que d'un seul donc j'en envoie généralement une puis supprimer le descripteur. Firefox inclut le Candidat dans l'Offre SDP.

Maintenant que nous avons un candidat ICE, nous devons l'envoyer à nos pairs afin qu'ils sachent comment se connecter avec nous. Toutefois, cela nous laisse face à une problématique de l'œuf et de la poule; Nous voulons que PeerConnection envoie des données à un pair, mais avant cela, nous devons lui envoyer des métadonnées…

C'est là qu'intervient le canal de signal. C'est n'importe quel mode de transport de données qui permet aux deux pairs d'échanger des informations. Dans cet article, nous allons utiliser FireBase parce que c'est incroyablement facile à installer et ne nécessite aucun hébergement ou code serveur.

Pour l'instant imaginez seulement que deux méthodes existent: send() va prendre une clé et lui affecter des données et recv() appelle un descripteur lorsqu'une clé a une valeur.

La structure de la base de données ressemble à ceci :

{
    "": {
        "candidate:": …
        "offer": …
        "answer": …
    }
}

Les connexions sont divisées par un roomId et stockeront 4 éléments d'information, le candidat ICE de l'auteur de l'offre, le candidat ICE du répondeur, l'offre SDP et la réponse SDP.

Une offre SDP (Session Description Protocol) et le méta données qui décrit aux autres pairs le format attendu(video, formats, codecs, cryptage, résolution, taille, etc etc).

Un échange nécessite une offre d'un pair, alors l'autre pair doit recevoir l'offre et offrir en retour une réponse.

pc.createOffer(
  function (offer) {
    pc.setLocalDescription(offer);

    send("offer", JSON.stringify(offer));
  },
  errorHandler,
  constraints,
);

S'il y avait un problème lors de la génération d'une offre, cette méthode sera exécutée avec les détails de l'erreur comme premier argument.

var errorHandler = function (err) {
  console.error(err);
};

Options pour l'offre SDP.

var constraints = {
  mandatory: {
    OfferToReceiveAudio: true,
    OfferToReceiveVideo: true,
  },
};

OfferToReceiveAudio/Video Dit aux autres pair que vous désirez recevoir de la vidéo ou de l'audio de leur part. Ce n'est pas nécessaire pour DataChannels.

Une fois que l'offre a été générée nous devons définir le SDP local à la nouvelle offre et l'envoyer par le canal de signal aux autres pairs et attendre leur réponse SDP.

Une réponse SDP est comme une offre, mais est une réponse ; un peu comme répondre au téléphone. Nous pouvons seulement émettre une réponse qu'après avoir reçu une offre.

recv("offer", function (offer) {
  offer = new SessionDescription(JSON.parse(offer));
  pc.setRemoteDescription(offer);

  pc.createAnswer(
    function (answer) {
      pc.setLocalDescription(answer);

      send("answer", JSON.stringify(answer));
    },
    errorHandler,
    constraints,
  );
});

J'expliquerai d'abord comment utiliser PeerConnection pour l'API DataChannels et le transfert de données arbitraires entre des pairs.

Note: Au moment de l'écriture de cet article, l'interopérabilité entre Chrome et Firefox n'est pas possible avec DataChannels. Chrome prend en charge un protocole similaire mais privé et soutiendra le protocole standard bientôt.

var channel = pc.createDataChannel(channelName, channelOptions);

L'auteur de l'offre doit être le pair qui crée le canal. Le répondeur recevra le canal dans le rappel (callback) ondatachannel dans le PeerConnection. Vous devez appeler createDataChannel() une fois avant de créer l'offre.

Il s'agit d'une chaîne qui agit comme une étiquette pour le nom de votre canal. AVERTISSEMENT : Assurez-vous que votre nom de canal n'a pas d'espaces ou Chrome va échouer sur createAnswer().

var channelOptions = {};

Ces options ne sont pas bien supportées sur Chrome donc vous pouvez laisser ça vide pour l'instant. Vérifiez le RFC pour plus d'informations sur les options.

onopen

Exécuté lorsque la connexion est établie.

onerror

Exécuté s'il y a une erreur de création de la connexion. Le premier argument est un objet d'erreur.

channel.onerror = function (err) {
  console.error("Channel Error:", err);
};

nmessage

channel.onmessage = function (e) {
  console.log("Got message:", e.data);
};

Le cœur de la connexion. Lorsque vous recevez un message, cette méthode s'exécute. Le premier argument est un objet d'événement qui contient les données, heure de réception et autres informations.

onclose

Exécuté si l'autre pair ferme la connexion.

Si vous êtes le créateur du canal(l'auteur de l'offre), vous pouvez lier des événements directement à la DataChannel que vous avez créé avec createChannel. Si vous êtes l'auteur de la réponse, vous devez utiliser le callback ondatachannel dans le PeerConnection afin d'accéder au même canal.

pc.ondatachannel = function (e) {
    e.channel.onmessage = function () { … };
};

Le canal est disponible dans l'objet événement passé dans le descripteur en tant que e.channel.

send()

channel.send("Hi Peer!");

Cette méthode vous permet d'envoyer des données directement au pair! Incroyable. Vous devez envoyer un String, Blob, ArrayBuffer ou ArrayBufferView, alors assurez-vous de "stringifier" les objets.

close()

Ferme le canal une fois que la connexion doit se terminer. Il est recommandé de le faire sur l' unload de la page.

Maintenant nous allons couvrir la transmission de médias tels que l'audio ou la vidéo. Pour afficher la vidéo et l'audio, vous devez inclure un tag <video> dans le document avec l'attribut autoplay.

<video id="preview" autoplay></video>;

var video = document.getElementById("preview");
navigator.getUserMedia(
  mediaOptions,
  function (stream) {
    video.src = URL.createObjectURL(stream);
  },
  errorHandler,
);

mediaOptions

Les contraintes sur les types de médias que vous souhaitez renvoyer de l'utilisateur.

var mediaOptions = {
  video: true,
  audio: true,
};

Si vous voulez juste une conversation audio, supprimez la clé video.

errorHandler

Exécuté s'il y a une erreur retournée par le support demandé.

addStream

Ajoute le flux de getUserMedia au PeerConnection.

pc.addStream(stream);

onaddstream

<video id="otherPeer" autoplay></video>;

var otherPeer = document.getElementById("otherPeer");
pc.onaddstream = function (e) {
  otherPeer.src = URL.createObjectURL(e.stream);
};

Exécuté lorsque la connexion a été mise en place et que l'autre pair a ajouté le flux de données pour la connexion avec addStream. Vous avez besoin d'un autre tag <video> pour afficher les médias de l'autre pair.

Le premier argument est un objet d'événement avec les flux de média de l'autre pair.

Vous pouvez voir la source développée à partir de tous les extraits de code de cet article à mon repo WebRTC.

• Exemple de DataChannels : code, demo
• Exemple de média : code, demo