Le but de cet article est de vous familiariser avec sa structure et son principe de fonctionnement à l'aide d'un exemple de démonstration de chat vidéo peer-to-peer (chat vidéo p2p). À cette fin, nous utiliserons la démo de chat vidéo multi-utilisateur webrtc.io-demo. Il peut être téléchargé à partir du lien : https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Il est à noter que GitHub est un site ou un service web de développement collaboratif de projets web. Sur celui-ci, les développeurs peuvent poster les codes de leurs développements, en discuter et communiquer entre eux. De plus, certaines grandes sociétés informatiques hébergent leurs référentiels officiels sur ce site. Le service est gratuit pour les projets open source. GitHub est un référentiel de bibliothèques open source.

Ainsi, nous placerons l'échantillon de démonstration de chat vidéo peer-to-peer téléchargé depuis GitHub sur le lecteur C d'un ordinateur personnel dans le répertoire créé pour notre application "webrtc_demo".

Riz. 1

Comme il ressort de la structure (Fig. 1), le chat vidéo peer-to-peer se compose de scripts client script.js et server.js implémentés dans le langage de programmation JavaScript. Le script (bibliothèque) webrtc.io.js (CLIENT) - fournit l'organisation de la communication en temps réel entre les navigateurs sur un schéma peer-to-peer : "client-client", et webrtc.io.js (CLIENT) et webrtc .io.js (SERVER), utilisant le protocole WebSocket, ils assurent la communication full-duplex entre le navigateur et le serveur web selon l'architecture « client-serveur ».

Le script webrtc.io.js (SERVER) est inclus dans la bibliothèque webrtc.io et se trouve dans le répertoire node_modules\webrtc.io\lib. L'interface de chat vidéo index.html est implémentée en HTML5 et CSS3. Le contenu des fichiers de l'application webrtc_demo peut être visualisé avec l'un des éditeurs html, par exemple "Notepad ++".

Nous allons vérifier le fonctionnement du chat vidéo dans le système de fichiers du PC. Pour exécuter le serveur (server.js) sur un PC, vous devez installer le runtime node.js. Node.js permet au code JavaScript de s'exécuter en dehors du navigateur. Vous pouvez télécharger node.js depuis le lien : http://nodejs.org/ (version v0.10.13 le 15/07/13). Sur la page principale du site node.org, cliquez sur le bouton de téléchargement et accédez à http://nodejs.org/download/. Pour les utilisateurs de Windows, téléchargez d'abord win.installer (.msi), puis exécutez win.installer (.msi) sur le PC et installez nodejs et "npm package manager" dans le répertoire Program Files.

Riz. 2

Ainsi, node.js se compose d'un environnement de développement et d'exécution de code JavaScript, ainsi que d'un ensemble de modules internes pouvant être installés à l'aide du gestionnaire ou du gestionnaire de packages npm.

Pour installer des modules, vous devez exécuter la commande en ligne de commande à partir du répertoire de l'application (par exemple, "webrtc_demo") : npm install nom_module... Lors de l'installation des modules, le gestionnaire npm crée un dossier node_modules dans le répertoire à partir duquel l'installation a été effectuée. Dans le processus, nodejs connecte automatiquement les modules du répertoire node_modules.

Ainsi, après avoir installé node.js, ouvrez une ligne de commande et mettez à jour le module express dans le dossier node_modules du répertoire webrtc_demo à l'aide du gestionnaire de packages npm :

C:\webrtc_demo> npm install express

Le module express est un framework web pour node.js ou un framework web pour développer des applications. Pour avoir un accès global à express, vous pouvez l'installer comme ceci : npm install -g express.

Ensuite, nous mettons à jour le module webrtc.io :

C:\webrtc_demo> npm installer webrtc.io

Puis, en ligne de commande, démarrez le serveur : server.js :

C:\webrtc_demo> node server.js

Riz. 3

Tout, le serveur fonctionne avec succès (Figure 3). Désormais, à l'aide d'un navigateur Web, vous pouvez accéder au serveur par adresse IP et télécharger la page Web index.html, à partir de laquelle le navigateur Web extraira le code de script client - script.js et le code de script webrtc.io.js, et les exécuter. Pour que le chat vidéo peer-to-peer fonctionne (pour établir une connexion entre deux navigateurs), il est nécessaire à partir de deux navigateurs prenant en charge webrtc de contacter le serveur de signalisation fonctionnant sur node.js par l'adresse IP.

En conséquence, l'interface de la partie cliente de l'application de communication (chat vidéo) s'ouvrira avec une demande d'autorisation d'accès à la caméra et au microphone (Fig. 4).

Riz. 4

Après avoir cliqué sur le bouton "Autoriser", la caméra et le microphone sont connectés pour la communication multimédia. De plus, des données textuelles peuvent être communiquées via l'interface de chat vidéo (Fig. 5).

Riz. 5

Il faut le noter. Le serveur est de signalisation, et est principalement destiné à établir une connexion entre les navigateurs des utilisateurs. Node.js est utilisé pour exécuter le script server.js qui fournit la signalisation WebRTC.

Les internautes européens se divisent en deux parties : selon une enquête de l'Institut d'analyse de l'opinion publique d'Allenbach (Allemagne), les systèmes de Skype, de chat et de messagerie instantanée sont devenus partie intégrante de la vie quotidienne de 16,5 millions d'adultes et d'enfants, 9 des millions utilisent ces services au cas par cas, et 28 millions n'y touchent pas.

Cela peut changer car Firefox intègre maintenant technologie de communication en temps réel (WebRTC), ainsi que le client lui-même. Démarrer un chat audio et vidéo n'est désormais pas plus difficile que d'ouvrir un site Web. En revanche, des services tels que Facebook et Skype misent sur des solutions autonomes de création de clients et de comptes.

WebRTC n'est pas seulement facile à utiliser. Cette méthode vous permet même de définir connexion directe entre deux navigateurs... Ainsi, les données audio et vidéo ne transitent pas par le serveur, où une surcharge peut survenir ou dont l'administrateur n'est pas particulièrement sensible à la confidentialité ou à la protection des données. Grâce à la connexion directe, WebRTC ne nécessite pas d'inscription ni de compte auprès d'un service.

Pour démarrer une conversation, il vous suffit de suivre le lien. La communication reste privée car le flux de données est crypté. Google a commencé à s'engager activement dans la communication en temps réel via un navigateur en 2011, lorsqu'il a publié le code source de son implémentation de WebRTC.

Peu de temps après, Chrome et Firefox ont obtenu leurs propres moteurs WebRTC. Actuellement, leurs variantes mobiles sont équipées à la fois de cette technologie et du moteur WebView 3.6 installé avec Android 5.0, qui est utilisé par les applications.

Pour une communication en temps réel, les interfaces JavaScript appropriées doivent être implémentées dans le visualiseur Web. Avec GetUserMedia, le logiciel active la capture à partir de sources audio et vidéo, c'est-à-dire à partir d'une webcam et d'un microphone. RTCPeerConnection est responsable de l'établissement d'une connexion, ainsi que de la communication elle-même.

Parallèlement à l'intégration du navigateur, un groupe de travail du World Wide Web Consortium (W3C) a accéléré le processus de normalisation WebRTC. Il devrait être achevé en 2015.

WebRTC se contente de peu

Utiliser le service WebRTC ne nécessite pas beaucoup de ressources, puisque le serveur ne connecte que les interlocuteurs. L'établissement d'une connexion n'est pas non plus particulièrement difficile. Tout d'abord, le navigateur signale au serveur WebRTC qu'il envisage de démarrer un appel. Il reçoit un lien HTTPS du serveur - la communication est cryptée. L'utilisateur transmet ce lien à son interlocuteur. Le navigateur demande alors à l'utilisateur l'autorisation d'accéder à la webcam et au microphone.

Pour établir une connexion directe en streaming avec l'interlocuteur, le navigateur reçoit son adresse IP et les données de configuration du service WebRTC. Le Web Viewer de l'interlocuteur fait de même.

Pour que la connexion de streaming fonctionne correctement et de bonne qualité, trois moteurs fonctionnent dans le navigateur. Deux d'entre eux optimisent et compressent les données audio et vidéo, le troisième se charge de leur transport. Il envoie des données via SRTP(Secure Real-time Transport Protocol) qui permet une diffusion cryptée en temps réel.

Si une connexion directe échoue, WebRTC recherche un autre chemin. Par exemple, cela se produit lorsque les paramètres réseau empêchent le serveur STUN de signaler l'adresse IP. La norme WebRTC stipule que dans ce cas la conversation aura lieu, mais avec l'inclusion intermédiaire du serveur TURN (Traversal Using Relays around NAT). Ainsi, sur le site netscan.co, vous pouvez vérifier si WebRTC est implémenté sur votre ordinateur et avec votre accès au Web.

Comment se fait la connexion

Tout d'abord, vous devez enregistrer la conversation (1). Le service WebRTC fournit un lien qui doit être envoyé à l'interlocuteur. Le navigateur, utilisant le serveur STUN, trouve sa propre adresse IP (2), l'envoie au service et reçoit l'IP du partenaire pour établir une connexion directe (3). Si STUN échoue, la conversation est redirigée à l'aide du serveur TURN (4).

La communication utilisant la technologie WebRTC dans un navigateur est lancée à l'aide du code JavaScript. Après cela, trois moteurs sont responsables de la communication : les moteurs voix et vidéo collectent les données multimédia de la webcam et du microphone, et le moteur de transport combine les informations et envoie le flux sous forme cryptée à l'aide du protocole SRTP (Secure Real-time Protocol).

Quels navigateurs fonctionnent avec WebRTC

Chrome et Firefox sont équipés d'un moteur WebRTC qui utilise des services comme talky.io. Le navigateur de Mozilla peut fonctionner directement avec son propre client.

Google et Mozilla continuent de développer l'idée de communication en temps réel : Chrome peut héberger une conférence WebRTC avec plusieurs participants, et le nouveau client Firefox Hello est développé en collaboration avec la filiale du géant des télécoms Telefonica. Apple reste pour l'instant sur la touche, il ne faut pas encore s'attendre à WebRTC dans Safari. Cependant, il existe de nombreuses applications et plugins iOS alternatifs pour Safari.

Microsoft prend un cours légèrement différent. En tant que propriétaire du service concurrentiel Skype, cette entreprise ne va pas capituler si facilement devant WebRTC. Au lieu de cela, Microsoft développe une technologie appelée ORTC (Object Real-Time Communications) pour Internet Explorer.

Les différences par rapport à WebRTC, telles que d'autres codecs et protocoles pour établir le contact avec le serveur, sont insignifiantes et sont susceptibles d'évoluer au fil du temps en plus de la norme WebRTC, qui inclura ces divergences. Ainsi, seul Apple est laissé pour compte - comme d'habitude.

Photo: entreprises de fabrication; goodluz / Fotolia.com

Les technologies pour les appels depuis le navigateur existent depuis de nombreuses années : Java, ActiveX, Adobe Flash... Au cours des dernières années, il est devenu clair que les plugins et les machines virtuelles de gauche ne brillent pas par leur commodité (pourquoi devrais-je installer quoi que ce soit pas du tout ?) Et, surtout, la sécurité... Que faire? Il y a une sortie !

Jusqu'à récemment, plusieurs protocoles étaient utilisés dans les réseaux IP pour la téléphonie IP ou la vidéo : SIP, le protocole le plus répandu, qui sort de la scène H.323 et MGCP, Jabber/Jingle (utilisé dans Gtalk), Adobe RTMP* semi-ouvert et , bien sûr, Skype propriétaire. Le projet WebRTC, initié par Google, tente de révolutionner le monde de la téléphonie IP et Web en rendant inutiles tous les softphones, y compris Skype. WebRTC implémente non seulement toutes les capacités de communication directement à l'intérieur du navigateur, qui est désormais installé sur presque tous les appareils, mais tente simultanément de résoudre le problème plus général de la communication entre les utilisateurs du navigateur (échange de données diverses, diffusion d'écrans, collaboration avec des documents, etc. Suite).

WebRTC du côté du développeur Web

Du point de vue d'un développeur Web, WebRTC se compose de deux parties principales :

• le contrôle des flux multimédias à partir de ressources locales (caméra, microphone ou écran d'ordinateur local) est implémenté par la méthode navigator.getUserMedia, qui renvoie un objet MediaStream ;
• communication peer-to-peer entre les appareils qui génèrent des flux multimédias, y compris la définition des méthodes de communication et leur transfert direct - objets RTCPeerConnection (pour envoyer et recevoir des flux audio et vidéo) et RTCDataChannel (pour envoyer et recevoir des données du navigateur).

Qu'est-ce qu'on fait?

Nous allons découvrir comment organiser le chat vidéo multi-utilisateurs le plus simple entre navigateurs basés sur WebRTC à l'aide de sockets Web. Commençons par expérimenter Chrome/Chromium, comme les navigateurs les plus avancés en termes de WebRTC, même si Firefox 22, sorti le 24 juin, les a presque rattrapés. Il faut dire que la norme n'a pas encore été adoptée, et l'API peut changer de version en version. Tous les exemples ont été testés dans Chromium 28. Par souci de simplicité, nous ne surveillerons pas la propreté du code et la compatibilité entre navigateurs.

MediaStream

Le premier et le plus simple des composants WebRTC est MediaStream. Il permet au navigateur d'accéder aux flux multimédias de la caméra et du microphone de l'ordinateur local. Dans Chrome, pour cela, vous devez appeler la fonction navigator.webkitGetUserMedia () (puisque la norme n'est pas encore complète, toutes les fonctions viennent avec un préfixe, et dans Firefox cette même fonction s'appelle navigator.mozGetUserMedia ()). Lorsque vous l'appelez, l'utilisateur sera invité à autoriser l'accès à la caméra et au microphone. Il ne sera possible de poursuivre l'appel qu'une fois que l'utilisateur aura donné son accord. Les paramètres du flux média requis et deux fonctions de rappel sont passés en paramètres de cette fonction : la première sera appelée en cas d'accès réussi à la caméra/microphone, la seconde en cas d'erreur. Tout d'abord, créons un fichier HTML rtctest1.html avec un bouton et un élément

getUserMedia

Microsoft CU-RTC-Web

Microsoft ne serait pas Microsoft si, en réponse à l'initiative de Google, il ne publiait pas immédiatement sa propre version non standard incompatible appelée CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Bien que la part d'IE, qui est déjà faible, continue de baisser, le nombre d'utilisateurs de Skype donne à Microsoft l'espoir de presser Google, et on peut supposer que cette norme sera utilisée dans la version navigateur de Skype. La norme Google se concentre principalement sur la communication entre les navigateurs ; dans le même temps, l'essentiel du trafic vocal reste dans le réseau téléphonique ordinaire, et des passerelles entre celui-ci et les réseaux IP sont nécessaires non seulement pour faciliter l'utilisation ou une distribution plus rapide, mais aussi comme moyen de monétisation, ce qui permettra à plus d'acteurs pour les développer... L'émergence d'une autre norme peut non seulement conduire à un besoin désagréable pour les développeurs de prendre en charge deux technologies incompatibles à la fois, mais aussi à long terme donner à l'utilisateur un choix plus large de fonctionnalités possibles et de solutions techniques disponibles. Attend et regarde.

Activer le flux local

Étiquettes intérieures de notre fichier HTML, déclarons une variable globale pour le flux média :

Var localStream = null ;

Le premier paramètre de la méthode getUserMedia doit spécifier les paramètres du flux multimédia demandé - par exemple, activez simplement l'audio ou la vidéo :

Var streamConstraints = ("audio": true, "video": true); // Demande d'accès à la fois à l'audio et à la vidéo

Ou spécifiez des paramètres supplémentaires :

Var streamConstraints = ("audio": true, "video": ("obligatoire": ("maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "facultatif":) );

Le deuxième paramètre de la méthode getUserMedia doit recevoir une fonction de rappel qui sera appelée si elle est exécutée avec succès :

Fonction getUserMedia_success (stream) (console.log ("getUserMedia_success ():", stream); localVideo1.src = URL.createObjectURL (stream); // Connecter le flux multimédia à l'élément HTML

Le troisième paramètre est la fonction de rappel, un gestionnaire d'erreurs qui sera appelé en cas d'erreur

Fonction getUserMedia_error (erreur) (console.log ("getUserMedia_error ():", erreur);)

Appel en fait la méthode getUserMedia - demande d'accès au microphone et à la caméra lorsque le premier bouton est enfoncé

Fonction getUserMedia_click () (console.log ("getUserMedia_click ()"); navigator.webkitGetUserMedia (streamConstraints, getUserMedia_success, getUserMedia_error);)

Il n'est pas possible d'accéder au flux multimédia à partir d'un fichier ouvert localement. Si nous essayons de faire cela, nous obtenons une erreur :

NavigatorUserMediaError (code : 1, PERMISSION_DENIED : 1)"

Téléchargeons le fichier résultant sur le serveur, ouvrons-le dans un navigateur et, en réponse à la demande qui apparaît, permettons l'accès à la caméra et au microphone.

Vous pouvez sélectionner les appareils auxquels Chrome accédera dans Paramètres, Afficher le lien des paramètres avancés, section Confidentialité, bouton Contenu. Dans les navigateurs Firefox et Opera, les appareils sont sélectionnés dans la liste déroulante directement lorsque l'accès est autorisé.

Avec HTTP, l'autorisation sera demandée à chaque accès au flux multimédia après le chargement de la page. Le passage en HTTPS vous permettra d'afficher la requête une seule fois, uniquement lors du tout premier accès au flux média.

Faites attention au cercle clignotant dans l'icône du signet et à l'icône de l'appareil photo sur le côté droit de la barre d'adresse :

RTCMediaConnection

RTCMediaConnection est un objet conçu pour établir et transmettre des flux multimédias sur le réseau entre les participants. De plus, cet objet est chargé de générer la description de la session média (SDP), d'obtenir des informations sur les candidats ICE pour traverser le NAT ou les pare-feux (locaux et utilisant STUN) et d'interagir avec le serveur TURN. Chaque participant doit avoir une RTCMediaConnection par connexion. Les flux multimédias sont transmis à l'aide du protocole SRTP crypté.

TOURNER les serveurs

Les candidats ICE sont de trois types : hôte, srflx et relais. L'hôte contient des informations reçues localement, srflx - comment le nœud ressemble à un serveur externe (STUN) et relay - des informations pour le trafic proxy via le serveur TURN. Si notre nœud est derrière NAT, alors les candidats hôtes contiendront des adresses locales et seront inutiles, les candidats srflx n'aideront qu'avec certains types de NAT et le relais sera le dernier espoir de faire passer le trafic via un serveur intermédiaire.

Un exemple de candidat ICE de type host, avec l'adresse 192.168.1.37 et le port udp/34022 :

A = candidat : ​​337499441 2 udp 2113937151 192.168.1.37 34022 typ génération hôte 0

Format général de spécification des serveurs STUN / TURN :

Var serveurs = ("iceServers": [("url": "stun: stun.stunprotocol.org: 3478"), ("url": "turn: [email protégé]: port "," identifiant ":" mot de passe ")]);

Il existe de nombreux serveurs STUN publics sur Internet. Par exemple, il y a une grande liste. Malheureusement, ils résolvent trop peu de problèmes. Il n'y a pratiquement pas de serveurs TURN publics, contrairement à STUN. Cela est dû au fait que le serveur TURN passe par lui-même les flux multimédias, ce qui peut considérablement charger à la fois le canal réseau et le serveur lui-même. Par conséquent, le moyen le plus simple de se connecter aux serveurs TURN est de l'installer vous-même (il est clair qu'une IP publique est requise). De tous les serveurs, rfc5766-turn-server est le meilleur à mon avis. Il existe même une image prête à l'emploi pour Amazon EC2.

Avec TURN, tout n'est pas aussi bon que nous le souhaiterions, mais un développement actif est en cours, et j'espère qu'après un certain temps WebRTC, sinon égal à Skype dans la qualité de passage à travers la traduction d'adresses (NAT) et les pare-feu, alors au moins se rapprochera sensiblement.

RTCMediaConnection nécessite un mécanisme supplémentaire d'échange d'informations de contrôle pour établir une connexion - bien qu'il génère ces données, il ne les transmet pas et le transfert vers d'autres participants doit être mis en œuvre séparément.

Le choix de la méthode de transfert est de la responsabilité du développeur - même manuellement. Dès que l'échange des données nécessaires aura lieu, le RTCMediaConnection mettra en place les flux média automatiquement (si possible, bien sûr).

Modèle offre-réponse

Pour établir et modifier les flux multimédias, le modèle offre/réponse (décrit dans la RFC3264) et le protocole de description de session (SDP) sont utilisés. Ils sont également utilisés par le protocole SIP. Dans ce modèle, deux agents sont distingués : l'Offreur - celui qui génère une description de session SDP pour en créer une nouvelle ou modifier une existante (Offre SDP), et le Répondeur - celui qui reçoit une description de session SDP d'un autre agent et répond à avec sa propre description de session (Réponse SDP). Dans le même temps, la spécification requiert la présence d'un protocole de niveau supérieur (par exemple, SIP ou le vôtre sur des sockets Web, comme dans notre cas), qui est responsable du transfert du SDP entre les agents.

Quelles données doivent être transférées entre deux RTCMediaConnections pour qu'elles réussissent à établir des flux multimédias :

• Le premier participant initiant la connexion forme une Offre, dans laquelle il transmet une structure de données SDP (le même protocole est utilisé dans le même but dans SIP) décrivant les caractéristiques possibles du flux média qu'il va commencer à transmettre. Ce bloc de données doit être transféré au deuxième participant. Le deuxième participant forme une Réponse avec son SDP et l'envoie au premier.
• Le premier et le deuxième participants exécutent tous deux la procédure pour déterminer les candidats ICE possibles, à l'aide de laquelle le deuxième participant peut leur transmettre le flux multimédia. Au fur et à mesure que les candidats sont identifiés, les informations les concernant doivent être transmises à un autre participant.

Formation de l'offre

Pour former une offre, nous avons besoin de deux fonctions. Le premier sera appelé s'il est formé avec succès. Le deuxième paramètre de la méthode createOffer() est une fonction de rappel qui est appelée en cas d'erreur lors de son exécution (à condition que le flux local soit déjà disponible).

De plus, vous avez besoin de deux gestionnaires d'événements : onicecandidate lors de la définition d'un nouveau candidat ICE et onaddstream lors de la connexion d'un flux multimédia de l'autre côté. Revenons à notre dossier. Ajouter au HTML après les lignes avec des éléments un de plus:

créer une offre

Et après la ligne avec l'élément

Aussi, au début du code JavaScript, nous déclarons une variable globale pour RTCPeerConnection :

Var pc1;

Lors de l'appel du constructeur RTCPeerConnection, vous devez spécifier les serveurs STUN / TURN. Voir la barre latérale pour plus de détails ; tant que tous les participants sont sur le même réseau, ils ne sont pas obligatoires.

Var serveurs = null ;

Paramètres de préparation de l'offre SDP

Var offreContraintes = ();

Le premier paramètre de la méthode createOffer() est une fonction de rappel qui est appelée lorsqu'une offre est générée avec succès.

Fonction pc1_createOffer_success (desc) (console.log ("pc1_createOffer_success ():\ndesc.sdp:\n" + desc.sdp + "desc:", desc); pc1.setLocalDescription (desc); // Définir RTCPeerConnection généré par Offer SDP à l'aide de la méthode setLocalDescription. // Lorsque le côté distant envoie sa réponse SDP, il devra être défini à l'aide de la méthode setRemoteDescription // Jusqu'à ce que le deuxième côté soit implémenté, ne rien faire // pc2_receivedOffer (desc);)

Le deuxième paramètre est une fonction de rappel qui sera appelée en cas d'erreur

Fonction pc1_createOffer_error (error) (console.log ("pc1_createOffer_success_error (): error:", error);)

Et nous allons déclarer une fonction de rappel à laquelle les candidats ICE seront transmis tels qu'ils sont définis :

Fonction pc1_onicecandidate (événement) (if (event.candidate) (console.log ("pc1_onicecandidate (): \ n" + event.candidate.candidate.replace ("\ r \ n", ""), event.candidate); // Jusqu'à ce que le deuxième côté soit implémenté, ne rien faire // pc2.addIceCandidate (nouveau RTCIceCandidate (event.candidate) );))

Et aussi une fonction de rappel pour ajouter un flux multimédia de l'autre côté (pour l'avenir, puisque nous n'avons pour l'instant qu'une seule RTCPeerConnection) :

Fonction pc1_onaddstream (événement) (console.log ("pc_onaddstream ()"); remoteVideo1.src = URL.createObjectURL (event.stream);)

Lorsque vous cliquez sur le bouton "createOffer", créez une RTCPeerConnection, définissez les méthodes onicecandidate et onaddstream et demandez la formation de l'Offre SDP en appelant la méthode createOffer() :

Fonction createOffer_click () (console.log ("createOffer_click ()"); pc1 = nouveau webkitRTCPeerConnection (serveurs); // Créer RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Fonction de rappel pour traiter les candidats ICE pc1._onaddstream = pc1 // Rappel -fonction appelée lorsqu'un flux multimédia apparaît de l'autre côté. Il n'est pas encore disponible pc1.addStream (localStream); // Transférons le flux multimédia local (nous supposons qu'il a déjà été reçu) pc1.createOffer (// Et nous demandons en fait la formation de Offer pc1_createOffer_success , pc1_createOffer_error, offerConstraints );)

Enregistrons le fichier sous rtctest2.html, mettons-le sur le serveur, ouvrons-le dans un navigateur et voyons dans la console quelles données sont générées lors de son fonctionnement. La deuxième vidéo n'apparaîtra pas encore, car il n'y a qu'un seul participant. Rappelez-vous que SDP est une description des paramètres de session multimédia, les codecs disponibles, les flux multimédias et les candidats ICE sont des options possibles pour se connecter à un participant donné.

Réponse SDP Formation et ICE Candidate Exchange

L'offre SDP et chacun des candidats ICE doivent être transmis de l'autre côté et là, après les avoir reçus de RTCPeerConnection, appeler les méthodes setRemoteDescription pour l'offre SDP et addIceCandidate pour chaque candidat ICE reçu de l'autre côté ; De même pour les candidats Answer SDP et ICE distants. Réponse SDP lui-même est formé de la même manière que l'offre ; la différence est que ce n'est pas la méthode createOffer qui est appelée, mais la méthode createAnswer et avant cette RTCPeerConnection, l'offre SDP reçue de l'appelant est transmise par la méthode setRemoteDescription.

Ajoutons un autre élément vidéo au HTML :

Et une variable globale pour le deuxième RTCPeerConnection sous le premier :

Var pc2;

Offre et réponse SDP Traitement

Réponse La génération SDP est très similaire à l'offre. Dans la fonction de rappel, appelée lors de la formation réussie de la réponse, de manière similaire à l'offre, nous donnons la description locale et transmettons la réponse SDP reçue au premier participant :

Fonction pc2_createAnswer_success (desc) (pc2.setLocalDescription (desc); console.log ("pc2_createAnswer_success ()", desc.sdp); pc1.setRemoteDescription (desc);)

La fonction de rappel, appelée en cas d'erreur lors de la formation d'une Réponse, est totalement similaire à Offre :

Fonction pc2_createAnswer_error (erreur) (console.log ("pc2_createAnswer_error ():", erreur);)

Paramètres de génération de Answer SDP :

Var answerConstraints = ("obligatoire": ("OfferToReceiveAudio": true, "OfferToReceiveVideo": true));

Lorsqu'une offre est reçue par le deuxième participant, créez une connexion RTCPeer et formez une réponse de la même manière que l'offre :

Fonction pc2_receivedOffer (desc) (console.log ("pc2_receiveOffer()", desc); // Créer un objet RTCPeerConnection pour le deuxième participant de la même manière que le premier pc2 = new webkitRTCPeerConnection (servers); pc2.onicecandidate = pc2_onicecandidate; // Définir un gestionnaire d'événement candidat ICE pc2.onaddstream = pc_onaddstream; // Lorsque le flux apparaît, connectez-le à HTML

Afin de passer l'Offre SDP du premier participant au second dans le cadre de notre exemple, on décommente dans la fonction pc1 créer une offre chaîne d'appel success() :

Pc2_receivedOffer (desc);

Pour implémenter le traitement des candidats ICE, décommentons le gestionnaire de l'événement ICE candidate readiness du premier participant pc1_onicecandidate() pour le passer au second :

Pc2.addIceCandidate (nouveau RTCIceCandidate (event.candidate));

Le deuxième gestionnaire d'événements de préparation des participants pour les candidats ICE est reproduit comme le premier :

Fonction pc2_onicecandidate (événement) (if (event.candidate) (console.log ("pc2_onicecandidate ():", event.candidate.candidate); pc1.addIceCandidate (nouveau RTCIceCandidate (event.candidate));))

Fonction de rappel pour ajouter un flux multimédia du premier participant :

Fonction pc2_onaddstream (événement) (console.log ("pc_onaddstream ()"); remoteVideo2.src = URL.createObjectURL (event.stream);)

Mettre fin à la connexion

Ajoutons un autre bouton au HTML

Raccrocher

Et une fonction pour terminer la connexion

Fonction btnHangupClick () (// Déconnecter la vidéo locale des éléments HTML

Enregistrons-le sous le nom rtctest3.html, mettons-le sur le serveur et ouvrons-le dans un navigateur. Cet exemple implémente la diffusion multimédia bidirectionnelle entre deux RTCPeerConnections dans le même signet de navigateur. Pour organiser l'échange d'offre et de réponse SDP, candidats ICE entre les participants et d'autres informations via le réseau, au lieu d'un appel direct de procédures, il sera nécessaire de mettre en œuvre l'échange entre les participants en utilisant un moyen de transport, dans notre cas, sockets web.

Diffusion à l'écran

La fonction getUserMedia peut également capturer un écran et le diffuser en tant que MediaStream en spécifiant les paramètres suivants :

Var mediaStreamConstraints = (audio : false, vidéo : (obligatoire : (chromeMediaSource : "screen"), facultatif :));

Pour réussir l'accès à l'écran, plusieurs conditions doivent être remplies :

• activez l'indicateur de capture d'écran dans getUserMedia () dans chrome : // flags /, chrome : // flags /;
• le fichier source doit être téléchargé via HTTPS (origine SSL) ;
• le flux audio ne doit pas être demandé ;
• plusieurs demandes ne doivent pas être exécutées dans un seul onglet de navigateur.

Bibliothèques pour WebRTC

Bien que WebRTC ne soit pas encore terminé, il existe déjà plusieurs bibliothèques basées sur celui-ci. JsSIP est conçu pour créer des téléphones logiciels basés sur un navigateur qui fonctionnent avec des commutateurs SIP tels que Asterisk et Camalio. PeerJS simplifiera la création de réseaux P2P pour l'échange de données, et Holla réduira la quantité de développement requise pour la communication P2P à partir des navigateurs.

Node.js et socket.io

Afin d'organiser l'échange de candidats SDP et ICE entre deux RTCPeerConnections sur le réseau, nous utilisons Node.js avec le module socket.io.

L'installation de la dernière version stable de Node.js (pour Debian / Ubuntu) est décrite

$ sudo apt-get install python-software-properties python g ++ make $ sudo add-apt-repository ppa: chris-lea / node.js $ sudo apt-get update $ sudo apt-get install nodejs

L'installation pour d'autres systèmes d'exploitation est décrite

Allons vérifier:

$ echo "sys = require (" util "); sys.puts (" Test message ");" > nodetest1.js $ nodejs nodetest1.js

Installez socket.io et le module complémentaire express à l'aide de npm (Node Package Manager) :

$ npm installer socket.io express

Vérifions en créant un fichier nodetest2.js côté serveur :

$ nano nodetest2.js var app = require ("express") (), server = require ("http"). createServer (app), io = require ("socket.io"). listen (server); server.listen (80); // Si le port 80 est gratuit app.get ("/", fonction (req, res) (// Lors de l'accès à la page racine res.sendfile (__ dirname + "/nodetest2.html"); // envoie le fichier HTML )) ; io.sockets.on ("connexion", fonction (socket) (// Lors de la connexion socket.emit ("événement serveur", (bonjour : "monde")); // envoyer un message socket.on ("événement client", function (data) (// et déclarer un gestionnaire d'événement lorsqu'un message arrive du client console.log (data);));));

Et nodetest2.html pour le côté client :

$ nano nodetest2.html

Commençons le serveur :

$ sudo nodejs nodetest2.js

et ouvrez la page http:// localhost: 80 (si exécuté localement sur le port 80) dans un navigateur. Si tout se passe bien, dans la console JavaScript du navigateur, nous verrons l'échange d'événements entre le navigateur et le serveur lors de la connexion.

Échange d'informations entre RTCPeerConnection via des websockets

Partie cliente

Enregistrons notre exemple principal (rtcdemo3.html) sous le nouveau nom rtcdemo4.html. Connectons la bibliothèque socket.io dans l'élément :

Et au début du script JavaScript - connexion aux websockets :

Var socket = io.connect ("http: // localhost");

Remplaçons l'appel direct de fonctions d'un autre participant en lui envoyant un message via des web sockets :

Fonction createOffer_success (desc) (... // pc2_receivedOffer (desc); socket.emit ("offre", desc); ...) fonction pc2_createAnswer_success (desc) (... // pc1.setRemoteDescription (desc); socket .emit ("answer", desc);) fonction pc1_onicecandidate (événement) (... // pc2.addIceCandidate (nouveau RTCIceCandidate (event.candidate)); socket.emit ("ice1", event.candidate); .. .) fonction pc2_onicecandidate (événement) (... // pc1.addIceCandidate (nouveau RTCIceCandidate (événement.candidate)); socket.emit ("ice2", event.candidate); ...)

Dans la fonction raccrocher(), au lieu d'appeler directement les fonctions du second participant, faites passer le message via les web sockets :

Fonction btnHangupClick () (... // remoteVideo2.src = ""; pc2.close (); pc2 = null; socket.emit ("raccrocher", ());)

Et ajoutez des gestionnaires pour recevoir le message :

Socket.on ("offre", fonction (données) (console.log ("socket.on ("offre "):", données); pc2_receivedOffer (données);)); socket.on ("réponse", fonction (données) (e console.log ("socket.on ("réponse "):", données); pc1.setRemoteDescription (nouveau RTCSessionDescription (données));)); socket.on ("ice1", fonction (données) (console.log ("socket.on (" ice1 "):", données); pc2.addIceCandidate (nouveau RTCIceCandidate (données));)); socket.on ("ice2", fonction (données) (console.log ("socket.on (" ice2 "):", données); pc1.addIceCandidate (nouveau RTCIceCandidate (données));)); socket.on ("raccrocher", fonction (données) (console.log ("socket.on ("raccrocher "):", données); remoteVideo2.src = ""; pc2.close (); pc2 = null;) );

Partie serveur

Côté serveur, enregistrez le fichier nodetest2 sous un nouveau nom rtctest4.js et ajoutez la réception et l'envoi de messages client à l'intérieur de la fonction io.sockets.on ("connexion", fonction (socket) (...) :

Socket.on ("offre", fonction (données) (// Lorsque le message "offre" est reçu, // puisqu'il n'y a qu'une seule connexion client dans cet exemple, // renvoie le message via la même socket socket.emit ("offre" , données); // S'il était nécessaire d'envoyer un message sur toutes les connexions, // à l'exception de l'expéditeur : // soket.broadcast.emit ("offre", données);)); socket.on ("réponse", fonction (données) (socket.emit ("réponse", données);)); socket.on ("ice1", fonction (données) (socket.emit ("ice1", données);)); socket.on ("ice2", fonction (données) (socket.emit ("ice2", données);)); socket.on ("raccrocher", fonction (données) (socket.emit ("raccrocher", données);));

De plus, nous allons changer le nom du fichier HTML :

// res.sendfile (__ dirname + "/nodetest2.html"); // Envoie le fichier HTML res.sendfile (__ dirname + "/rtctest4.html");

Démarrage du serveur :

$ sudo nodejs nodetest2.js

Malgré le fait que le code des deux clients est exécuté dans le même signet de navigateur, toutes les interactions entre les participants dans notre exemple sont entièrement effectuées via le réseau et il ne nécessite aucune complication particulière pour "séparer" les participants. Cependant, ce que nous avons fait était également très simple - ces technologies sont bonnes pour leur facilité d'utilisation. Même si parfois décevant. En particulier, n'oublions pas que sans serveurs STUN/TURN, notre exemple ne peut pas fonctionner en présence de translation d'adresses et de firewalls.

Conclusion

L'exemple résultant est très conditionnel, mais si nous universalisons légèrement les gestionnaires d'événements afin qu'ils ne diffèrent pas sur l'appelant et l'appelé, au lieu de deux objets pc1 et pc2, créez un tableau RTCPeerConnection et implémentez la création et la suppression dynamiques d'éléments

On peut supposer que très bientôt, grâce au WebRTC, il y aura une révolution non seulement dans notre compréhension des communications vocales et vidéo, mais aussi dans la façon dont nous percevons Internet en général. WebRTC se positionne non seulement comme une technologie d'appels d'un navigateur à un navigateur, mais aussi comme une technologie de communication en temps réel. La communication vidéo que nous avons analysée n'est qu'une petite partie des options possibles pour son utilisation. Il existe déjà des exemples de screencasting et de collaboration, et même un réseau de diffusion de contenu P2P basé sur un navigateur utilisant RTCDataChannel.

Aujourd'hui, WebRTC est la technologie la plus avancée pour le streaming audio et vidéo dans les navigateurs. Les technologies conservatrices telles que HTTP Streaming et Flash sont plus adaptées à la distribution de contenu enregistré (vidéo à la demande) et sont nettement inférieures au WebRTC en termes de diffusion en temps réel et en ligne, c'est-à-dire où une latence vidéo minimale est requise pour permettre aux téléspectateurs de voir ce qui se passe « en direct ».

La possibilité d'une communication en temps réel de haute qualité vient de l'architecture WebRTC elle-même, où le protocole UDP est utilisé pour transporter des flux vidéo, qui est la base standard pour la transmission vidéo avec des délais minimes et est largement utilisé dans les systèmes de communication en temps réel.

La latence de communication est importante dans les systèmes de diffusion en ligne, les webinaires et autres applications où une communication interactive avec la source vidéo, les utilisateurs finaux et la solution est requise.

Une autre bonne raison d'essayer WebRTC est certainement une tendance. Aujourd'hui, chaque navigateur Android Chrome prend en charge cette technologie, qui garantit des millions d'appareils prêts à regarder la diffusion sans installer de logiciel ou de configuration supplémentaire.

Afin de tester la technologie WebRTC en action et d'y exécuter une simple diffusion en ligne, nous avons utilisé le logiciel Flashphoner WebRTC Media & Broadcasting Server. Les fonctionnalités déclarent la possibilité de diffuser des flux WebRTC en mode un-à-plusieurs, ainsi que la prise en charge des caméras IP et des systèmes de vidéosurveillance via le protocole RTSP ; dans cet aperçu, nous nous concentrerons sur la diffusion sur le Web et ses fonctionnalités.

Installation du serveur WebRTC Media & Broadcasting

Comme il n'y avait pas de version serveur pour Windows et que je ne voulais pas installer une machine virtuelle comme VMWare + Linux, je ne pouvais pas tester les diffusions en ligne sur mon ordinateur Windows domestique. Pour gagner du temps, nous avons décidé de prendre une instance sur un hébergement cloud comme celui-ci :

Il s'agissait de Centos x86_64 version 6.5 sans aucun logiciel pré-installé dans le centre de données d'Amsterdam. Ainsi, tout ce que nous avons à notre disposition est le serveur et l'accès ssh à celui-ci. Pour ceux qui connaissent les commandes de la console Linux, l'installation du serveur WebRTC promet d'être simple et indolore. Alors ce que nous avons fait :

1. Télécharger l'archive :

$ wget https : //site/download-wcs5-server.tar.gz

2. Déballer:

$ tar -xzf download-wcs5-server.tar.gz

3. Installer:

$ cd FlashphonerWebCallServer

Lors de l'installation, saisissez l'adresse IP du serveur : XXX.XXX.XXX.XXX

4. Activer la licence :

$ cd / usr / local / FlashphonerWebCallServer / bin

$. / activation.sh

5. Démarrez le serveur WCS :

$ service webcallserver start

6. Vérifier le journal :

$ tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Vérifiez que deux processus sont en place :

$ ps aux | grep Flashphoner

Le processus d'installation est terminé.

Test des diffusions en ligne WebRTC

Tester les diffusions s'est avéré être une affaire simple. En plus du serveur, il existe un client web, qui se compose d'une dizaine de fichiers Javascript, HTML et CSS et a été déployé par nos soins dans le dossier /var/www/html lors de la phase d'installation. La seule chose à faire était d'entrer l'adresse IP du serveur dans la configuration flashphoner.xml afin que le client Web puisse établir une connexion au serveur via des Websockets HTML5. Décrivons le processus de test.

1. Ouvrez la page client de test index.html dans le navigateur Chrome :

2. Pour commencer à diffuser, vous devez appuyer sur le bouton "Démarrer" au milieu de l'écran.
Avant de faire cela, vous devez vous assurer que la webcam est connectée et prête à être utilisée. Il n'y a pas d'exigences particulières pour une webcam, par exemple, nous avons utilisé une caméra standard intégrée dans un ordinateur portable avec une résolution de 1280 × 800.

Le navigateur Chrome demandera certainement l'accès à la caméra et au microphone afin que l'utilisateur comprenne que sa vidéo sera envoyée au serveur Internet et lui permet de le faire.

3. L'interface est une diffusion réussie du flux vidéo de la caméra vers le serveur WebRTC. Dans le coin supérieur droit, l'indicateur indique que le flux va vers le serveur, dans le coin inférieur il y a un bouton Stop pour arrêter l'envoi de la vidéo.

Notez le lien dans la case ci-dessous. Il contient un identifiant unique pour ce flux, afin que tout le monde puisse rejoindre la vue. Il suffit d'ouvrir ce lien dans un navigateur. Pour le copier dans le presse-papiers, cliquez sur le bouton "Copier".

Dans les applications réelles comme les webinaires, les conférences, les diffusions vidéo en ligne ou la télévision interactive, les développeurs devront mettre en œuvre la distribution de cet identifiant à certains groupes de téléspectateurs afin qu'ils puissent se connecter aux flux nécessaires, mais c'est la logique de l'application. Serveur multimédia et de diffusion WebRTC cela ne l'affecte pas, mais ne traite que de la distribution de la vidéo.

5. La connexion est établie et le spectateur voit le flux sur l'écran. Maintenant, il peut envoyer le lien à quelqu'un d'autre, arrêter la lecture du flux ou activer le mode plein écran à l'aide des commandes dans le coin inférieur droit.

Résultats des tests du serveur WebRTC des diffusions en ligne

Lors des tests, la latence semblait parfaite. Le ping vers le centre de données était d'environ 100 millisecondes et la latence était invisible à l'œil. Par conséquent, nous pouvons supposer que le délai réel est le même 100 plus ou moins quelques dizaines de millisecondes pour le temps de mise en mémoire tampon. Par rapport à la vidéo Flash : dans de tels tests, Flash ne se comporte pas aussi bien que WebRTC. Ainsi, si vous déplacez votre main sur un réseau similaire, le mouvement à l'écran ne peut être vu qu'après une / deux secondes.

Concernant la qualité, on note que parfois on peut distinguer des cubes sur des mouvements. Ceci est conforme à la nature du codec VP8 et à son objectif principal - fournir une communication vidéo en temps réel avec une qualité acceptable et sans retards de communication.

Le serveur est assez simple à installer et à configurer ; pour le démarrer, vous n'avez besoin d'aucune compétence sérieuse autre que la connaissance de Linux au niveau d'un utilisateur avancé, qui peut exécuter des commandes depuis la console via ssh et utiliser un éditeur de texte. En conséquence, nous avons réussi à établir une diffusion en ligne un-à-plusieurs entre les navigateurs. La connexion de téléspectateurs supplémentaires au flux n'a pas non plus posé de problèmes.

La qualité de diffusion s'est avérée tout à fait acceptable pour les webinaires et les diffusions en ligne. La seule chose qui a soulevé des questions était la résolution vidéo. La caméra prend en charge 1280x800, mais la résolution de l'image de test est très similaire à 640x480. Apparemment, cette question doit être clarifiée avec les développeurs.

Vidéo pour tester la diffusion depuis une webcam
via le serveur WebRTC

WebRTC est une API fournie par un navigateur qui vous permet d'organiser une connexion P2P et de transférer des données directement entre les navigateurs. Il existe de nombreux tutoriels sur Internet pour écrire votre propre chat vidéo en utilisant WebRTC. Par exemple, voici un article sur Habré. Cependant, ils sont tous limités à la connexion de deux clients. Dans cet article, je vais essayer de parler de la façon d'organiser la connexion et l'échange de messages entre trois utilisateurs ou plus à l'aide de WebRTC.

L'interface RTCPeerConnection est une connexion peer-to-peer entre deux navigateurs. Pour connecter trois utilisateurs ou plus, nous devrons organiser un réseau maillé (un réseau dans lequel chaque nœud est connecté à tous les autres nœuds).
Nous utiliserons le schéma suivant :

1. Lors de l'ouverture de la page, nous vérifions la présence d'un identifiant de salle dans emplacement.hash
2. Si l'identifiant de la salle n'est pas spécifié, nous en générons un nouveau
3. Nous envoyons un serveur de signalisation "y un message que nous voulons rejoindre la salle spécifiée
4. Le serveur de signalisation envoie une nouvelle notification d'utilisateur au reste des clients de cette salle.
5. Les clients qui sont déjà dans la salle envoient une offre SDP au nouvel arrivant
6. Le débutant répond à l'offre

0. Serveur de signalisation

Comme vous le savez, bien que WebRTC fournisse une connexion P2P entre les navigateurs, il nécessite toujours un transport supplémentaire pour échanger des messages de service. Dans cet exemple, un tel transport est un serveur WebSocket écrit en Node.JS à l'aide de socket.io :

Var socket_io = require ("socket.io"); module.exports = fonction (serveur) (var utilisateurs = (); var io = socket_io (serveur); io.on ("connexion", fonction (socket) (// Le nouvel utilisateur veut rejoindre la salle socket.on (" room", fonction (message) (var json = JSON.parse (message); // Ajoute le socket à la liste des utilisateurs users = socket; if (socket.room! == undefined) (// Si le socket est déjà dans une pièce, quittez-le socket.leave (socket.room);) // Entrez dans la pièce demandée socket.room = json.room; socket.join (socket.room); socket.user_id = json.id; // Envoyer aux autres clients de cette salle un message concernant un nouveau participant rejoignant socket.broadcast.to (socket.room) .emit ("new", json.id);)); // Message lié à WebRTC (offre SDP, réponse SDP ou candidat ICE) socket.on ("webrtc", fonction (message) (var json = JSON.parse (message); if (json.to! == undefined && users! == undefined) (// Si le message contient un destinataire et ce destinataire connu du serveur, nous envoyons un message seulement à lui ... users.emit ("webrtc", message); ) else (// ... sinon, considérez le message comme une diffusion socket.broadcast.to (socket.room) .emit ("webrtc", message);))); // Quelqu'un a déconnecté socket.on ("déconnecter", fonction () (// Lorsqu'un client se déconnecte, en informer les autres socket.broadcast.to (socket.room) .emit ("quitter", socket.user_id); supprimer utilisateurs;)); )); );

1.index.html

Le code source de la page elle-même est assez simple. Je n'ai délibérément pas fait attention à la mise en page et aux autres beautés, puisque cet article ne parle pas de cela. Si quelqu'un veut la rendre belle, ce ne sera pas difficile.

2.main.js

2.0. Obtenir des liens vers des éléments de page et des interfaces WebRTC

var chatlog = document.getElementById ("chatlog"); var message = document.getElementById ("message"); var connection_num = document.getElementById ("connection_num"); var room_link = document.getElementById ("room_link");

Nous devons encore utiliser des préfixes de navigateur pour faire référence aux interfaces WebRTC.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || window.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || window.RTCIceCandidate;

2.1. Détermination de l'identifiant de la salle

Ici, nous avons besoin d'une fonction pour générer une pièce unique et un ID utilisateur. Nous utiliserons l'UUID à ces fins.

Fonction uuid () (var s4 = function () (retourne Math.floor (Math.random () * 0x10000) .toString (16) ;); retourne s4 () + s4 () + "-" + s4 () + "-" + s4 () + "-" + s4 () + "-" + s4 () + s4 () + s4 ();)

Essayons maintenant d'extraire l'ID de la salle de l'adresse. Si aucun n'est spécifié, nous en générerons un nouveau. Affichez le lien vers la salle actuelle sur la page et, en une étape, générons l'ID utilisateur actuel.

Var ROOM = location.hash.substr (1) ; if (! ROOM) (ROOM = uuid ();) room_link.innerHTML = "Lien vers la pièce"; var ME = uuid ();

2.2. Websocket

Dès l'ouverture de la page, nous nous connecterons à notre serveur de signalisation, enverrons une demande d'entrée dans la salle et spécifierons les gestionnaires de messages.

// Nous indiquons que lorsque le message est fermé, une notification à ce sujet doit être envoyée au serveur var socket = io.connect ("", ("sync Disconnect on unload": true)); socket.on ("webrtc", socketReceived); socket.on ("nouveau", socketNewPeer); // Envoie immédiatement une requête pour entrer dans la salle socket.emit ("room", JSON.stringify ((id: ME, room: ROOM))); // Fonction d'assistance pour l'envoi de messages d'adresse liés à WebRTC fonction sendViaSocket (type, message, to) (socket.emit ("webrtc", JSON.stringify ((id: ME, to: to, type: type, data: message ) ));)

2.3. Paramètres de connexion par les pairs

La plupart des FAI fournissent le NAT via la connectivité Internet. Cela rend la connexion directe moins triviale. Lors de la création d'une connexion, nous devons spécifier une liste de serveurs STUN et TURN que le navigateur essaiera d'utiliser pour traverser NAT. Nous indiquerons également quelques options supplémentaires pour la connexion.

Var server = (iceServers: [(url: "stun: 23.21.150.121"), (url: "stun: stun.l.google.com: 19302"), (url: "turn: numb.viagenie.ca", identification : "votre mot de passe va ici", nom d'utilisateur : " [email protégé]")]); var options = (facultatif : [(DtlsSrtpKeyAgreement : true), // requis pour se connecter entre Chrome et Firefox (RtpDataChannels : true) // requis dans Firefox pour utiliser l'API DataChannels])

2.4. Connecter un nouvel utilisateur

Lorsqu'un nouveau pair est ajouté à la salle, le serveur nous envoie un message Nouveau... Selon les gestionnaires de messages ci-dessus, la fonction sera appelée socketNouveauPeer.

Var pairs = (); function socketNewPeer (data) (peers = (candidateCache:); // Créer une nouvelle connexion var pc = new PeerConnection (server, options); // Initialiser la initConnection (pc, data, "offer"); // Enregistrer le pair dans la liste peers peers.connection = pc; // Créer un DataChannel à travers lequel les messages seront échangés var channel = pc.createDataChannel ("mychannel", ()); channel.owner = data; peers.channel = channel; // Installer les gestionnaires d'événements channel bindEvents (channel); // Créer une offre SDP pc.createOffer (function (offer) (pc.setLocalDescription (offer);));) function initConnection (pc, id, sdpType) (pc.onicecandidate = function ( event) ( if (event.candidate) (// Lorsqu'un nouveau candidat ICE est trouvé, ajoutez-le à la liste pour l'envoi ultérieur de peers.candidateCache.push (event.candidate);) else (// Lorsque la détection du candidat est terminée, le gestionnaire sera à nouveau appelé, mais sans candidat // Dans ce cas, on enverra d'abord l'offre SDP au pair, ou Réponse SDP (selon le paramètre de fonction) ... sendViaSocket (sdpType, pc.localDescription, id); // ... puis tous les candidats ICE trouvés précédemment pour (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. Offre SDP, réponse SDP, candidat ICE

Lorsqu'un de ces messages est reçu, nous appelons le gestionnaire de messages correspondant.

Fonction socketReceived (données) (var json = JSON.parse (données); switch (json.type) (case "candidate": remoteCandidateReceived (json.id, json.data); break; case "offer": remoteOfferReceived (json. id, json.data); break; case "answer": remoteAnswerReceived (json.id, json.data); break;))

2.5.0 Offre SDP

fonction remoteOfferReceived (id, data) (createConnection (id); var pc = peers.connection; pc.setRemoteDescription (nouvelle SessionDescription (data)); pc.createAnswer (function (answer) (pc.setLocalDescription (answer);)); ) fonction createConnection (id) (if (peers === undefined) (peers = (candidateCache:); var pc = new PeerConnection (serveur, options); initConnection (pc, id, "answer"); peers.connection = pc ; pc.ondatachannel = fonction (e) (peers.channel = e.channel ; peers.channel.owner = id ; bindEvents (peers.channel ;)))

2.5.1 Réponse SDP

fonction remoteAnswerReceived (id, data) (var pc = peers.connection; pc.setRemoteDescription (new SessionDescription (data));)

2.5.2 Candidat ICE

fonction remoteCandidateReceived (id, data) (createConnection (id); var pc = peers.connection; pc.addIceCandidate (new IceCandidate (data));)

2.6. Envoi d'un message

En appuyant sur le bouton Envoyer la fonction est appelée envoyer le message... Tout ce qu'il fait, c'est parcourir la liste des pairs et essayer d'envoyer à tout le monde le message spécifié.