From 39f2114f9797eb51994966c6bb8ff1814c9a4da8 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:36:08 +0100 Subject: unslug fr: move --- files/fr/web/guide/api/gamepad/index.html | 281 ---------------- files/fr/web/guide/api/webrtc/index.html | 52 --- .../index.html | 97 ++++++ .../api/webrtc/webrtc_architecture/index.html | 54 ---- .../web/guide/api/webrtc/webrtc_basics/index.html | 360 --------------------- 5 files changed, 97 insertions(+), 747 deletions(-) delete mode 100644 files/fr/web/guide/api/gamepad/index.html delete mode 100644 files/fr/web/guide/api/webrtc/index.html create mode 100644 files/fr/web/guide/api/webrtc/peer-to-peer_communications_with_webrtc/index.html delete mode 100644 files/fr/web/guide/api/webrtc/webrtc_architecture/index.html delete mode 100644 files/fr/web/guide/api/webrtc/webrtc_basics/index.html (limited to 'files/fr/web/guide/api') diff --git a/files/fr/web/guide/api/gamepad/index.html b/files/fr/web/guide/api/gamepad/index.html deleted file mode 100644 index 1cfa50fc2c..0000000000 --- a/files/fr/web/guide/api/gamepad/index.html +++ /dev/null @@ -1,281 +0,0 @@ ---- -title: Utiliser l'API Gamepad -slug: Web/Guide/API/Gamepad -translation_of: Web/API/Gamepad_API/Using_the_Gamepad_API ---- -

{{ SeeCompatTable() }}

-
-

HTML5 a introduit plusieurs des composants nécessaires pour le développement de jeux vidéos riches et interactifs. Des technologies comme <canvas>, WebGL, <audio>, et <video>, ainsi que les implémentations JavaScript, ont mûri au point de supporter plusieurs fonctions autrefois réservées aux applications natives. L'API Gamepad est une manière pour les développeurs et designers d'accéder aux contrôleurs de jeux.

-
-
-

Note: Dans Firefox 29 et plus, l'API Gamepad est activée par défaut, tout comme pour les versions Nightly et Aurora. Depuis Firefox 24, l'API Gamepad était déjà disponible derrière une option dans les préférences. Il est possible de l'activer dans ces versions en ouvrant about:config et en activant dom.gamepad.enabled.

-
-

L'API Gamepad introduit de nouveaux évènements à l'objet {{ domxref("Window") }} pour lire l'état des contrôleurs. En plus de ces événements, l'API ajoute aussi un objet {{ domxref("Gamepad") }} que vous pouvez utiliser pour récupérer l'état d'un contrôleur connecté, et une méthode {{ domxref("navigator.getGamepads") }} que vous pouvez utiliser pour obtenir la liste des contrôleurs connus par la page.

-

Connexion au contrôleur

-

Lorsqu'un nouveau contrôleur est connecté à l'ordinateur, la page active reçoit tout d'abord un événement {{ domxref("Window.gamepadconnected") }}. Si un contrôleur est déjà connecté lorsque la page termine de charger, l'événement {{ domxref("Window.gamepadconnected") }} est envoyé à la page active lorsque l'utilisateur appuie sur un bouton ou bouge un axe.

-
-

Dans Firefox, les contrôleurs ne sont rendus visibles à une page que lorsque l'utilisateur s'en sert alors que cette page est active. Cela permet d'éviter que les contrôleurs soient utilisés pour identifier l'utilisateur. Dès lors qu'un contrôleur a été utilisé, les autres contrôleurs connectés seront rendus visibles automatiquement.

-
-

Vous pouvez utiliser {{ domxref("Window.gamepadconnected") }} ainsi :

-
window.addEventListener("gamepadconnected", function(e) {
-  console.log("Contrôleur n°%d connecté : %s. %d boutons, %d axes.",
-  e.gamepad.index, e.gamepad.id,
-  e.gamepad.buttons.length, e.gamepad.axes.length);
-});
-
-

Chaque contrôleur est associé à un identifiant unique, qui est disponible dans la propriété gamepad de l'événement.

-
-

Note: À l'écriture de ces lignes, Chrome n'implémente pas les événements {{ domxref("Window.gamepadconnected") }} et {{ domxref("Window.gamepaddisconnected") }}. Vous devez utiliser {{ domxref("navigator.getGamepads") }} pour récupérer la liste des contrôleurs disponibles.

-
-

Déconnexion du contrôleur

-

Lorsqu'un contrôleur est déconnecté, et si la page avait déjà reçu des données de ce contrôleur auparavant (par exemple par l'événement {{ domxref("Window.gamepadconnected") }}), un second événement est envoyé à la fenêtre active :  {{ domxref("Window.gamepaddisconnected") }}.

-
window.addEventListener("gamepaddisconnected", function(e) {
-  console.log("Contrôleur n°%d déconnecté : %s",
-  e.gamepad.index, e.gamepad.id);
-});
-

La propriété index sera unique à chaque périphérique connecté au système, même si plusieurs contrôleurs du même type sont utilisés. La propriété correspond également à l'indice du tableau retourné par {{ domxref("navigator.getGamepads") }}.

-
var gamepads = {};
-
-function gamepadHandler(event, connecting) {
-  var gamepad = event.gamepad;
-  // Note :
-  // gamepad === navigator.getGamepads()[gamepad.index]
-
-  if (connecting) {
-    gamepads[gamepad.index] = gamepad;
-  } else {
-    delete gamepads[gamepad.index];
-  }
-}
-
-window.addEventListener("gamepadconnected", function(e) { gamepadHandler(e, true); }, false);
-window.addEventListener("gamepaddisconnected", function(e) { gamepadHandler(e, false); }, false);
-
-

Cet exemple montre également comment la propriété gamepad peut être conservée après que l'événement se soit terminé. Cette technique sera utilisée plus tard pour obtenir l'état du périphérique.

-
- [PAGE NON TRADUITE DEPUIS ICI...]
-
-  
-

Querying the Gamepad object

-

As you can see, the gamepad events discussed above include a gamepad property on the event object, which returns a {{ domxref("Gamepad") }} object. We can use this in order to determine which gamepad (i.e., its ID) had caused the event, since multiple gamepads might be connected at once. We can do much more with the {{ domxref("Gamepad") }} object, including holding a reference to it and querying it to find out which buttons and axes are being pressed at any one time. Doing so is often desirable for games or other interactive web pages that need to know the state of a gamepad now vs. the next time an event fires.

-

Performing such checks tends to involve using the {{ domxref("Gamepad") }} object in conjunction with an animation loop (e.g., {{ domxref("requestAnimationFrame") }}), where developers want to make decisions for the current frame based on the state of the gamepad or gamepads.

-
-

Note: The Gamepad API also provides a function -- {{ domxref("Navigator.getGamepads") }}-- that returns a list of all devices currently visible to the webpage, an array of {{ domxref("Gamepad") }} objects. This can then be used to get the same information. For example, the first code example above you be rewritten as shown below:

-
-
window.addEventListener("gamepadconnected", function(e) {
-  var gp = navigator.getGamepads()[e.gamepad.index];
-  console.log("Gamepad connected at index %d: %s. %d buttons, %d axes.",
-  gp.index, gp.id,
-  gp.buttons.length, gp.axes.length);
-});
-

The {{ domxref("Gamepad") }} object's properties are as follows:

- -
-

Note: The Gamepad object is available on the {{ domxref("Window.gamepadconnected") }} event rather than the {{ domxref("Window") }} object itself, for security reasons. Once we have a reference to it, we can query its properties for information about the current state of the gamepad. Behind the scenes, this object will be updated every time the gamepad's state changes.

-
-

Using button information

-

Let's look at a simple example that displays connection information for one gamepad (it ignores subsequent gamepad connections) and allows you to move a ball around the screen using the four gamepad buttons on the right hand side of the gamepad. You can view the demo live, and find the source code on Github.

-

To start with, we declare some variables: The gamepadInfo paragraph that the connection info is written into, the ball that we want to move, the start variable that acts as the ID for requestAnimation Frame, the a and b variables that act as position modifiers for moving the ball, and the shorthand variables that will be used for the {{ domxref("requestAnimationFrame") }} and {{ domxref("cancelRequestAnimationFrame") }} cross browser forks.

-
var gamepadInfo = document.getElementById("gamepad-info");
-var ball = document.getElementById("ball");
-var start;
-var a = 0;
-var b = 0;
-
-var rAF = window.mozRequestAnimationFrame ||
-  window.webkitRequestAnimationFrame ||
-  window.requestAnimationFrame;
-
-var rAFStop = window.mozCancelRequestAnimationFrame ||
-  window.webkitCancelRequestAnimationFrame ||
-  window.cancelRequestAnimationFrame;
-

Next we use the {{ domxref("Window.gamepadconnected") }} event to check for a gamepad being connected. When one is connected, we grab the gamepad using {{ domxref("Navigator.getGamepads") }}[0], print information about the gamepad into our gamepad info div, and fire the gameLoop() function that starts the whole ball movement process up.

-
window.addEventListener("gamepadconnected", function(e) {
-  var gp = navigator.getGamepads()[e.gamepad.index];
-  gamepadInfo.innerHTML = "Gamepad connected at index " + gp.index + ": " + gp.id + ". It has " + gp.buttons.length + " buttons and " + gp.axes.length + " axes.";
-
-  gameLoop();
-});
-

Now we use the {{ domxref("Window.gamepaddisconnected") }} event to check if the gamepad is disconnected again. If so, we stop the {{ domxref("requestAnimationFrame") }} loop (see below) and revert the gamepad information back to what it was originally.

-
window.addEventListener("gamepaddisconnected", function(e) {
-  gamepadInfo.innerHTML = "Waiting for gamepad.";
-
-  rAFStop(start);
-});
-

Chrome does things differently here. Instead of constantly storing the gamepad's latest state in a variable it only stores a snapshot, so to do the same thing in Chrome you have to keep polling it and then only use the {{ domxref("Gamepad") }} object in code when it is available. We have done this below using {{ domxref("Window.setInterval") }}; once the object is available the gamepad info is outputted, the game loop is started, and the interval is cleared using {{ domxref("Window.clearInterval") }}. Note that in older versions of Chrome {{ domxref("Navigator.getGamepads") }} is implemented with a webkit prefix. We attempt to detect and handle both the prefixed version and the standard version of the function for backwards-compatibility.

-
if(!('GamepadEvent' in window)) {
-  // No gamepad events available, poll instead.
-  var interval = setInterval(pollGamepads, 500);
-}
-
-function pollGamepads() {
-  var gamepads = navigator.getGamepads ? navigator.getGamepads() : (navigator.webkitGetGamepads ? navigator.webkitGetGamepads : []);
-  for (var i = 0; i < gamepads.length; i++) {
-    var gp = gamepads[i];
-    if(gp) {
-      gamepadInfo.innerHTML = "Gamepad connected at index " + gp.index + ": " + gp.id + ". It has " + gp.buttons.length + " buttons and " + gp.axes.length + " axes.";
-      gameLoop();
-      clearInterval(interval);
-    }
-  }
-}
-

Now on to the main game loop. In each execution of the loop we check if one of four buttons is being pressed; if so, we update the values of the a and b movement variables appropriately, then update the {{ cssxref("left") }} and {{ cssxref("top") }} properties, changing their values to the current values of a and b respectively. This has the effect of moving the ball around the screen.  In current versions of Chrome (version 34 as of this writing) the button values are stored as an array of double values, instead of {{ domxref("GamepadButton") }} objects. This is fixed in development versions.

-

After all this is done, we use our rAF variable to request the next animation frame, running gameLoop() again.

-
function buttonPressed(b) {
-  if (typeof(b) == "object") {
-    return b.pressed;
-  }
-  return b == 1.0;
-}
-
-function gameLoop() {
-  var gamepads = navigator.getGamepads ? navigator.getGamepads() : (navigator.webkitGetGamepads ? navigator.webkitGetGamepads : []);
-  if (!gamepads)
-    return;
-
-  var gp = gamepads[0];
-  if (buttonPressed(gp.buttons[0])) {
-    b--;
-  } else if (buttonPressed(gp.buttons[2])) {
-    b++;
-  }
-  if(buttonPressed(gp.buttons[1])) {
-    a++;
-  } else if(buttonPressed(gp.buttons[3])) {
-    a--;
-  }
-
-  ball.style.left = a*2 + "px";
-  ball.style.top = b*2 + "px";
-
-  var start = rAF(gameLoop);
-};
-

Using axes information

-

TBD (basically the same, except using axes[i] rather than button[i].value for both Firefox and Chrome.)

-

Complete example: Displaying gamepad state

-

This example shows how to use the {{ domxref("Gamepad") }} object, as well as the {{ domxref("Window.gamepadconnected") }} and {{ domxref("Window.gamepaddisconnected") }} events in order to display the state of all gamepads connected to the system. You can find a working demo and look at the full source code on Github.

-
var haveEvents = 'GamepadEvent' in window;
-var controllers = {};
-var rAF = window.mozRequestAnimationFrame ||
-  window.webkitRequestAnimationFrame ||
-  window.requestAnimationFrame;
-
-function connecthandler(e) {
-  addgamepad(e.gamepad);
-}
-function addgamepad(gamepad) {
-  controllers[gamepad.index] = gamepad; var d = document.createElement("div");
-  d.setAttribute("id", "controller" + gamepad.index);
-  var t = document.createElement("h1");
-  t.appendChild(document.createTextNode("gamepad: " + gamepad.id));
-  d.appendChild(t);
-  var b = document.createElement("div");
-  b.className = "buttons";
-  for (var i=0; i<gamepad.buttons.length; i++) {
-    var e = document.createElement("span");
-    e.className = "button";
-    //e.id = "b" + i;
-    e.innerHTML = i;
-    b.appendChild(e);
-  }
-  d.appendChild(b);
-  var a = document.createElement("div");
-  a.className = "axes";
-  for (var i=0; i<gamepad.axes.length; i++) {
-    var e = document.createElement("progress");
-    e.className = "axis";
-    //e.id = "a" + i;
-    e.setAttribute("max", "2");
-    e.setAttribute("value", "1");
-    e.innerHTML = i;
-    a.appendChild(e);
-  }
-  d.appendChild(a);
-  document.getElementById("start").style.display = "none";
-  document.body.appendChild(d);
-  rAF(updateStatus);
-}
-
-function disconnecthandler(e) {
-  removegamepad(e.gamepad);
-}
-
-function removegamepad(gamepad) {
-  var d = document.getElementById("controller" + gamepad.index);
-  document.body.removeChild(d);
-  delete controllers[gamepad.index];
-}
-
-function updateStatus() {
-  if (!haveEvents) {
-    scangamepads();
-  }
-  for (j in controllers) {
-    var controller = controllers[j];
-    var d = document.getElementById("controller" + j);
-    var buttons = d.getElementsByClassName("button");
-    for (var i=0; i<controller.buttons.length; i++) {
-      var b = buttons[i];
-      var val = controller.buttons[i];
-      var pressed = val == 1.0;
-      if (typeof(val) == "object") {
-        pressed = val.pressed;
-        val = val.value;
-      }
-      var pct = Math.round(val * 100) + "%"
-      b.style.backgroundSize = pct + " " + pct;
-      if (pressed) {
-        b.className = "button pressed";
-      } else {
-        b.className = "button";
-      }
-    }
-
-    var axes = d.getElementsByClassName("axis");
-    for (var i=0; i<controller.axes.length; i++) {
-      var a = axes[i];
-      a.innerHTML = i + ": " + controller.axes[i].toFixed(4);
-      a.setAttribute("value", controller.axes[i] + 1);
-    }
-  }
-  rAF(updateStatus);
-}
-
-function scangamepads() {
-  var gamepads = navigator.getGamepads ? navigator.getGamepads() : (navigator.webkitGetGamepads ? navigator.webkitGetGamepads() : []);
-  for (var i = 0; i < gamepads.length; i++) {
-    if (gamepads[i]) {
-      if (!(gamepads[i].index in controllers)) {
-        addgamepad(gamepads[i]);
-      } else {
-        controllers[gamepads[i].index] = gamepads[i];
-      }
-    }
-  }
-}
-
-window.addEventListener("gamepadconnected", connecthandler);
-window.addEventListener("gamepaddisconnected", disconnecthandler);
-if (!haveEvents) {
-  setInterval(scangamepads, 500);
-}
-

Specifications

-

{{page("/en-US/docs/Gamepad","Specifications")}}

-

Browser compatibility

-

{{page("/en-US/docs/Gamepad","Browser_compatibility")}}

-

 

-

 

-

 

diff --git a/files/fr/web/guide/api/webrtc/index.html b/files/fr/web/guide/api/webrtc/index.html deleted file mode 100644 index 2d516d62d5..0000000000 --- a/files/fr/web/guide/api/webrtc/index.html +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: WebRTC -slug: Web/Guide/API/WebRTC -tags: - - Intro - - WebRTC -translation_of: Web/API/WebRTC_API -translation_of_original: Web/Guide/API/WebRTC ---- -

WebRTC (où RTC signifie Real-Time Communications -Communications en temps réel-) est une technologie qui permet la transmission en continue (streaming) de l'audio/vidéo et le partage de données entre les navigateurs clients (peers). Comme un ensemble de normes (standards), le WebRTC fournit à n'importe quel navigateur la capacité de partager des données d'application et d'effectuer des téléconférences d’égal à égal, sans avoir à installer quelques plug-ins ou logiciels tiers.

-

Les composants WebRTC sont accessibles grâce aux APIs JavaScript : l'API de flux réseau (Network Stream), qui représente un flux de données audio ou vidéo ; l'API de Connexion (PeerConnection), qui permet à plusieurs utilisateurs de communiquer via leurs navigateurs ; et l'API DataChannel qui permet la communication d'autres types de données pour le jeu en temps réel, dialogue en ligne, transfert de fichiers, etc.

-
-

Note: Cette documentation n'est pas à jour et est un travail en cours. Vous voulez aider? Nous avons besoin de personnes pour parcourir ces docs et les mettre à jour, tout autant que de documenter les APIs dans notre référence d’API! Consultez notre guide à la page Débuter sur MDN si vous voulez aider.

-
-

Guide

-
-
- Introduction au WebRTC
-
- Guide d'introduction à ce qu’est WebRTC et comment ça marche.
-
- Communications Peer-to-peer avec WebRTC
-
- Comment faire pour effectuer des communications peer-to-peer en utilisant les APIs WebRTC.
-
- Prendre des photos avec la webcam
-
- Un guide d'introduction à ce qu’est WebRTC et à comment ça marche.
-
- Introduction à l'architecture WebRTC
-
- (AKA "WebRTC et l'océan des acronymes") WebRTC a beaucoup de parties différentes et cela peut être accablant et source de confusion pour les nouveaux venus. Cet article a pour but d'expliquer qu’elles sont toutes les pièces, et comment elles s'imbriquent.
-
- L’essentiel du WebRTC
-
- Maintenant que vous comprenez l'architecture WebRTC, vous pouvez passer à cet article, qui vous emmène à travers la création d'une application multi-navigateur RTC simple.
-
-

Référence

-
-
- Navigator.getUserMedia
-
- L'API pour capturer des médias (audio/video).
-
- RTCPeerConnection
-
- L'interface traitant en continu des données entre deux pairs.
-
- RTCDataChannel
-
- L'interface pour l'envoi des données arbitraires à travers la connexion de pair (peer connection).
-
diff --git a/files/fr/web/guide/api/webrtc/peer-to-peer_communications_with_webrtc/index.html b/files/fr/web/guide/api/webrtc/peer-to-peer_communications_with_webrtc/index.html new file mode 100644 index 0000000000..72bd60d899 --- /dev/null +++ b/files/fr/web/guide/api/webrtc/peer-to-peer_communications_with_webrtc/index.html @@ -0,0 +1,97 @@ +--- +title: Communication de pair-à-pair avec WebRTC +slug: WebRTC/communication-de-pair-a-pair-avec-WebRTC +translation_of: Web/Guide/API/WebRTC/Peer-to-peer_communications_with_WebRTC +--- +

{{SeeCompatTable}}

+

Les APIs WebRTC sont conçues pour permettre aux applications JavaScript de créer des connexions en temps-réel, avec des canaux audio, vidéo et/ou de données, entre utilisateurs à travers leurs navigateurs ou avec des serveurs supportant le protocole WebRTC. Il autorise aussi navigator.mozGetUserMedia() à accéder au microphone et à la webcam (getUserMedia() est en cours de standardisation par le groupe Media Capture Task, avec les APIs Recording).

+

La principale source des évolutions des spécifications de WebRTC sont les spécifications du W3C WebRTC et getUserMedia, ainsi que différents brouillons de IETF, principalement du groupe de travail rtcweb, mais aussi mmusic, rmcat et quelques autres. Une grande partie de l'implémentation dans Chrome et Firefox est basée sur le code libéré par Google à webrtc.org.

+

NOTE:  Les versions courantes de FlashBlock peuvent bloquer le tag HTML5 <video> par défaut; si c'est le cas, il faut lui dire d'autoriser le contenu de la page, ou désactiver cette option via Tools/Add-ons.

+

Un bon tutoriel sur les fonctionnalités de base de WebRTC peut-être trouvé sur HTML5 Rocks. On pourra trouver sur le site webrtc-landing une série de page de test basique.

+

Il est possible de faire un appel simple de personne à personne  (y compris à ceux utilisant Chrome) à apprtc.appspot.com.

+

Un article de Hacks décrit avec précision ce qu'il se passe dans une connexion RTCPeerConnecion (lien) :

+

Basics of RTCPeerConnection call setup

+

Spécifications

+ + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
WebRTC APIEn cours de définition 
getUserMedia APIEn cours definitionhttp://dev.w3.org/2011/webrtc/editor/getusermedia.html
+

Compatibilité des navigateurs

+
+ {{CompatibilityTable}}
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
FonctionnalitéChromeFirefox (Gecko)Internet ExplorerOperaSafari (WebKit)
Support de baseOui{{property_prefix("webkit")}}Firefox 22{{CompatNo}}{{CompatNo}}{{CompatNo}}
DataChannelsA partir de Chrome 29Firefox 22{{CompatNo}}{{CompatNo}}{{CompatNo}}
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
FontionnalitéAndroidFirefox Mobile (Gecko)IE PhoneOpera MobileSafari Mobile
Support préliminaireVia Chrome (behind flag)Activé sur versions Nightly et Aurora{{CompatNo}}{{CompatNo}}{{CompatNo}}
DataChannels{{CompatUnknown}}Activé sur versions Nightly et Aurora{{CompatNo}}{{CompatNo}}{{CompatNo}}
+
+

 

diff --git a/files/fr/web/guide/api/webrtc/webrtc_architecture/index.html b/files/fr/web/guide/api/webrtc/webrtc_architecture/index.html deleted file mode 100644 index 8b512d7127..0000000000 --- a/files/fr/web/guide/api/webrtc/webrtc_architecture/index.html +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Introduction à l'architecture WebRTC -slug: Web/Guide/API/WebRTC/WebRTC_architecture -tags: - - WebRTC -translation_of: Web/API/WebRTC_API/Connectivity ---- -

(AKA "WebRTC et l'océan des acronymes") WebRTC comporte de nombreuses parties distinctes et cela peut être accablant et source de confusion pour les nouveaux venus. Cet article a pour but d'expliquer quelles sont toutes ses parties, et comment elles s'imbriquent.

- -

Qu’est-ce que ICE?

- -

Interactive Connectivity Establishment (ICE) est un cadre qui permet à votre navigateur web de se connecter avec des pairs. Il y a plusieurs raisons pour qu’une connexion directe entre un pair A et un pair B ne fonctionne pas. Il a besoin de contourner les pare-feux qui pourraient empêcher la connexion de s’ouvrir, il doit vous attribuer une adresse unique si votre appareil n'a pas une adresse IP publique comme la plupart du temps et transmettre des données via un serveur si votre routeur ne permet pas de vous connecter directement avec des pairs. ICE utilise certaines des techniques suivantes décrites ci-dessous pour y parvenir :

- -

Qu’est-ce que STUN?

- -

Session Traversal Utilities for NAT (STUN) (acronyme dans un acronyme) est un protocole qui permet de découvrir votre adresse publique et de déterminer toute restriction dans votre routeur qui empêcherait une connexion directe avec un pair.

- -

Le client enverra une demande à un serveur STUN sur internet qui répondra avec l'adresse du client public et informera si le client est accessible derrière un routeur NAT.

- -

An interaction between two users of a WebRTC application involving a STUN server.

- -

Qu’est-ce que NAT?

- -

Network Address Translation (NAT) est utilisé pour donner à votre appareil une adresse IP publique. Un routeur aura une adresse IP publique et chaque périphérique connecté au routeur aura une adresse IP privée. Les demandes seront traduites de l'adresse IP privée de l'appareil vers l'IP publique du routeur avec un port unique. De cette façon, vous n'avez pas besoin d’avoir une adresse IP publique unique pour chaque périphérique, mais pouvez encore être découvert sur internet.

- -

Certains routeurs auront des restrictions sur ceux qui peuvent se connecter aux dispositifs sur le réseau. Cela peut signifier que, même si nous avons l'adresse IP publique, trouvée par le serveur STUN, tout le monde ne peut pas créer une connexion. Dans ce cas, il faut se tourner vers le TURN.

- -

Qu’est-ce que TURN?

- -

Certains routeurs utilisant NAT emploient une restriction appelée ‘Symmetric NAT’. Cela signifie que le routeur n'accepte que les connexions de pairs auxquelles vous vous êtes déjà connecté.

- -

Traversal Using Relays around NAT (TURN) Doit contourner la restriction de NAT Symétrique en ouvrant une connexion avec un serveur TURN et retransmettre toutes les informations par le biais de ce serveur. Vous devrez créer une connexion avec un serveur TURN et dire à tous les pairs d'envoyer des paquets au serveur qui vous seront alors expédiés. Cela vient évidemment avec une certaine surcharge et n'est donc utilisé que s'il n'y a pas d'autres alternatives.

- -

Une interaction entre deux utilisateurs d'une application WebRTC impliquant des serveurs STUN et TURN.

- -

Qu’est-ce que SDP?

- -

Session Description Protocol (SDP) est une norme décrivant le contenu multimédia de la connexion comprenant la résolution, les formats, les codecs, le cryptage, etc., afin que les deux pairs puissent se comprendre une fois le transfert des données en cours. Ce n'est pas le média lui-même, mais plus les métadonnées.

- -

Qu’est-ce qu'une Offre/Réponse et un Canal de Signal?

- -

Malheureusement WebRTC ne peut pas créer de connexions sans une sorte de serveur au milieu. Nous appelons cela le Canal de Signal (Signal Channel). C'est une sorte de canal de communication pour échanger des informations avant de configurer une connexion, que ce soit par e-mail, carte postale ou pigeon voyageur... C’est comme bon vous semble.

- -

L’information que nous avons besoin d'échanger est l'Offre et la Réponse qui contient juste le SDP mentionné ci-dessus.

- -

Le pair A, qui sera l'initiateur de la connexion, va créer une offre. Il enverra ensuite cette offre au pair B en utilisant le Canal de Signal choisi. Le pair B recevra l’offre du Canal de Signal et créera la Réponse. Il renverra ensuite tout ceci au pair A via le Canal de Signal.

- -

Qu’est-ce qu’un candidat ICE?

- -

Autant que d'échanger des informations sur les médias (cf. Offre/Réponse et SDP), les pairs doivent échanger des informations sur la connexion réseau. Ceci est connu comme étant un candidat ICE et détaille les méthodes disponibles que le pair est en mesure de communiquer (directement ou via un serveur TURN).

- -

L'échange entier dans un diagramme compliqué

- -

Un schéma architectural complet montrant l'ensemble du processus WebRTC.

diff --git a/files/fr/web/guide/api/webrtc/webrtc_basics/index.html b/files/fr/web/guide/api/webrtc/webrtc_basics/index.html deleted file mode 100644 index e550e4adbb..0000000000 --- a/files/fr/web/guide/api/webrtc/webrtc_basics/index.html +++ /dev/null @@ -1,360 +0,0 @@ ---- -title: L’essentiel du WebRTC -slug: Web/Guide/API/WebRTC/WebRTC_basics -tags: - - WebRTC -translation_of: Web/API/WebRTC_API/Signaling_and_video_calling -translation_of_original: Web/API/WebRTC_API/WebRTC_basics ---- -
-

Maintenant que vous comprenez l'architecture WebRTC, vous pouvez passer à cet article, qui vous emmène à travers la création d'une application RTC multi-navigateurs.A la fin de cet article vous devriez pouvoir créer un canal de données et de médias  pair à pair qui fonctionne

-
- -

Contenu semi-ancien, à partir de RTCPeerConnection

- -

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.

- -

Usage basique

- -

l'utilisation de RTCPeerConnection implique la négociation d'une connexion entre votre machine  et une machine distante,et ce, en générant {{interwiki("wikipedia", "Session Description Protocol")}} a échanger 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();
-}
- -

Initialiser un appel

- -

l'appelant doit utiliser {{domxref("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 {{domxref("RTCPeerConnection.createOffer()")}} 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);
-});
- -

Répondre à un appel

- -

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,{{domxref("navigator.getUserMedia()")}} est une fois de plus appelée pour créer le second flux, qui est ajouté à la RTCPeerConnection. Un  objet {{domxref("RTCSessionDescription")}} est créé, et mis en place comme la description du distant en appelant {{domxref("RTCPeerConnection.setRemoteDescription()")}}.

- -

Ensuite, une réponse est créée en utilisant {{domxref("RTCPeerConnection.createAnswer()")}} 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);
-});
- -

Gestion de la réponse

- -

retour a la première machine, qui recois la reponse. une fois cette dernière arrivée,l'appelant utilise {{domxref("RTCPeerConnection.setRemoteDescription()")}} 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);
- -

Ancien contenu en approche!

- -

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.

- -
-

Ne pas utiliser les examples de cette page. Voir l'article signalisation et appel vidéo ,pour des example mis a jour sur l'utilisation des medias WebRTC.

-
- -

Note

- -

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.

-
- -

Shims (Bibliothèque d’interception d’API)

- -

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;
- -

PeerConnection

- -

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);
- -

RTCConfiguration

- -

L'objet {{domxref("RTCConfiguration")}} 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.

- -

options (Cf. "Note" avant)

- -

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.

- -

ICECandidate

- -

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.

- -

Canal de Signal

- -

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.

- -

Offre

- -

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);
- -

errorHandler

- -

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);
-};
- -

constraints

- -

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.

- -

Réponse

- -

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);
-});
- -

DataChannel

- -

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.

- -

channelName

- -

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().

- -

channelOptions

- -
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.

- -

Méthodes et événements de canal

- -

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);
-};
- -

onmessage

- -
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.

- -

Lier les événements

- -

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.

- -

Media

- -

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.

- -

Obtenir les médias de l'utilisateur

- -
<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é.

- -

Événements Médias et Méthodes

- -

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.

- -

Afficher la Source

- -

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

- - -- cgit v1.2.3-54-g00ecf