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), Skype, le chat et les systèmes de messagerie instantanée font désormais partie intégrante de la vie quotidienne de 16,5 millions d'adultes et d'enfants, 9 millions utilisent ces services au cas par cas, et 28 millions n'y touchent pas.

La situation peut changer, puisque maintenant Firefox est intégré 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. Des services tels que Facebook et Skype, quant à eux, s'appuient sur des solutions utilisant un client distinct et créant un compte.

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 un serveur où une surcharge peut survenir ou dont l'administrateur n'est pas particulièrement sensible à la vie privée ou à la protection des données. Grâce à la connexion directe, WebRTC ne nécessite aucune inscription ni Compte dans n'importe quel 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é. Communication en temps réel via le navigateur, Google a commencé à s'engager activement en 2011, lorsqu'il a publié le code source de son implémentation WebRTC.

Peu de temps après, Chrome et Firefox ont reçu leurs propres moteurs WebRTC. Ils sont actuellement options mobileséquipé à la fois de cette technologie et du moteur WebView 3.6 installé avec Android 5.0, qui est utilisé par les applications.

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

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

WebRTC se contente de peu

L'utilisation du service WebRTC ne nécessite pas beaucoup de ressources, puisque le serveur ne fait que connecter les copains. L'établissement d'une connexion n'est pas non plus particulièrement difficile. Tout d'abord, le navigateur signale au serveur WebRTC qu'il prévoit d'initier un appel. Il reçoit un lien HTTPS du serveur - la connexion 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 de streaming directe avec l'autre partie, le navigateur reçoit son adresse IP et ses données de configuration du service WebRTC. Le navigateur Web du copain fait de même.

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

Si une connexion directe échoue, WebRTC recherche un autre chemin. Par exemple, cela se produit lorsque paramètres réseau empêcher le serveur STUN de pouvoir rapporter 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

Vous devez d'abord enregistrer une conversation (1). Le service WebRTC fournit un lien qui doit être envoyé à l'interlocuteur. Le navigateur, à l'aide du 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).

Communication par Technologies WebRTC dans le navigateur est lancé à l'aide de code JavaScript. Après cela, trois moteurs sont responsables de la communication : les moteurs voix et vidéo collectent les données multimédias 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 tels que talky.io. Le navigateur 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 Hello de Firefox est développé avec l'aide d'une filiale du géant des télécommunications Telefonica. Apple reste sur la touche pour l'instant, 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 Skype compétitif, cette société ne va pas capituler si facilement face au 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 au WebRTC, telles que les différents codecs et protocoles pour établir le contact avec le serveur, sont mineures et au fil du temps sont susceptibles de s'ajouter à la norme WebRTC, qui inclura ces différences. Ainsi, seul Apple reste derrière - comme d'habitude.

Une photo: entreprises de fabrication; goodluz/Photolia.com

Bonjour les amis, comme vous le savez déjà, nous vous informons régulièrement des nouvelles technologies, aujourd'hui je vais vous présenter WebRTC, une technologie développée par Google, qui permet aux utilisateurs de parler directement dans le navigateur vidéo et audio sans nécessiter que l'utilisation d'un plugin- Sites Web ou applications. La connexion directe vidéo et audio entre les utilisateurs s'effectue directement dans le navigateur.
Technologie WebRTC prise en charge par Mozilla Navigateurs Firefox Google Chrome et pour tout système opérateur, Opera rejoindra bientôt.
Qu'est-ce que le WebRTC et quoi ?
WebRTC est l'abréviation de Web Real Time Communication, cette technologie vous permet d'ouvrir des chats audio et vidéo directement dans le navigateur sans avoir besoin d'autres plug-ins, applications ou services sur Internet pour cela. La connexion s'effectue directement du navigateur au navigateur.
Là où les services connus (Skype, Yahoo Messenger, Apple FaceTime, Google Hago, etc.) nécessitent un serveur qui connecte les utilisateurs afin d'initier et de gérer le trafic. En utilisant ces services, nous devons nous inscrire et établir une liste de clients et de contacts.
Avec WebRTC, nous n'avons pas besoin de serveurs, d'applications ou de serveurs qui se connectent pour intercéder.
Avantages du WebRTC :
1. Plus d'applications consommant des ressources et de la batterie.
2. Les discussions sont plus privées (relativement).
3. Comment contacter peut être fait localement, pas les serveurs Flos US pour les connexions locales.
4. Simplicité, facilité d'utilisation.
5. Opportunité la poursuite du développement, et dans d'autres directions.
6. La communication est stable et indépendante de connexions externes qui sont parfois extrêmement instables.
Dans le tutoriel, j'ai utilisé une démo que les gens de Google ont développée, cette démo est assez simple, des fonctionnalités plus avancées et des connexions plus rapides peuvent utiliser l'une des applications qui supportent WebRTC, elles sont plus faciles à utiliser. Bientôt, nous réaliserons également un didacticiel sur les applications WebRTC.
Comment utiliser la démo WebRTC ?
Cliquez très simplement sur le lien ci-dessous, il génère automatiquement un chat. pour lier cette salle, vous devez envoyer une amie/copine avec qui vous souhaitez entrer en contact.
Ami / petite amie et le vôtre, mais vous ne devez utiliser que le plus dernières versions MozillaFirefox ou GoogleChrome.

Démo WebRTC(Chat d'introduction audio - vidéo)

Attention:
La démo n'est pas très stable, elle est faite à des fins de démonstration uniquement. Il peut être utilisé pendant une durée limitée pendant laquelle de petites erreurs de connexion peuvent se produire.
Si vous rencontrez des problèmes de connectivité, essayez de créer un autre chat.

Aujourd'hui, WebRTC est la technologie "à la mode" pour le streaming audio et vidéo dans les navigateurs. technologies conservatrices telles que Streaming HTTP et Flash sont plus adaptés à la diffusion de contenus enregistrés (vidéo à la demande) et sont nettement inférieurs au WebRTC en termes de diffusions en temps réel et en ligne, c'est-à-dire où une latence vidéo minimale est requise, permettant aux téléspectateurs de voir ce qui se passe "en direct".

La possibilité d'une communication en temps réel de haute qualité provient de l'architecture WebRTC elle-même, où le protocole UDP est utilisé pour transporter les flux vidéo, qui est la base standard pour la transmission vidéo avec des retards minimaux 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 direct, les webinaires et d'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 définitivement une tendance. Chaque Android aujourd'hui Navigateur Chrome prend en charge cette technologie, qui garantit que des millions d'appareils sont prêts à regarder la diffusion sans installer de logiciel ni de configuration supplémentaire.

Afin de tester la technologie WebRTC en action et de lancer une simple diffusion en ligne dessus, nous avons utilisé le logiciel serveur 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 cette revue, nous nous concentrerons sur les diffusions web-web et leurs fonctionnalités.

Installation du serveur multimédia et de diffusion WebRTC

Parce que pour Systèmes Windows il n'y avait pas de version serveur, et je ne voulais pas installer une machine virtuelle comme VMWare + Linux, tester les diffusions en ligne sur la maison Ordinateur Windows N'a pas fonctionné. Pour gagner du temps, nous avons décidé de prendre une instance sur l'hébergement cloud comme celle-ci :

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

1. Télécharger l'archive :

$wget https://website/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 Flashphone

Le processus d'installation est terminé.

Tester les flux en direct WebRTC

Tester les émissions s'est avéré être une affaire simple. En plus du serveur, il existe un client Web, qui se compose d'une douzaine 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 HTML5 Websockets. Décrivons le processus de test.

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

2. Pour commencer la diffusion, vous devez cliquer 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 à fonctionner. Il n'y a pas d'exigences particulières pour une webcam, par exemple, nous avons utilisé une caméra d'ordinateur portable intégrée standard 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 autorisée à le faire.

3. L'interface représente 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.

Regardez le lien ci-dessous. Il contient un identifiant unique pour ce flux, afin que n'importe qui puisse rejoindre la vue. Ouvrez simplement ce lien dans un navigateur. Pour le copier dans le presse-papiers, vous devez cliquer sur le bouton "Copier".

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

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

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

Lors des tests, la latence semblait parfaite. Le ping vers le centre de données était d'environ 100 millisecondes et le retard n'était pas visible à l'œil nu. À partir de là, 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. Comparé à la vidéo Flash, Flash n'est pas aussi performant que WebRTC dans ces tests. 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 distingue les cubes sur les mouvements. Ceci est conforme à la nature du codec VP8 et son objectif principal est de fournir une communication vidéo en temps réel avec une qualité acceptable et sans retards de communication.

Le serveur est assez facile à installer et à configurer, il ne nécessite aucune compétence sérieuse pour le faire fonctionner, à l'exception d'une connaissance de Linux au niveau d'un utilisateur avancé qui peut exécuter des commandes depuis la console via ssh et utiliser éditeur de texte. En conséquence, nous avons réussi à mettre en place 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 causé quelques questions était la résolution de la vidéo. La caméra prend en charge 1280x800, mais la résolution sur l'image de test est très similaire à 640x480. Apparemment, ce problème doit être clarifié avec les développeurs.

Vidéo sur les tests diffusée depuis une webcam
via le serveur WebRTC

La plupart du matériel sur WebRTC se concentre sur le niveau d'application de l'écriture de code et ne contribue pas à la compréhension de la technologie. Essayons d'approfondir et de découvrir comment la connexion se produit, quel est le descripteur de session et les candidats, quels sont ÉTOURDIR et TOUR serveur.

WebRTC

Introduction

WebRTC est une technologie basée sur un navigateur qui vous permet de connecter deux clients pour la transmission de données vidéo. Les principales fonctionnalités sont la prise en charge du navigateur interne (pas besoin de technologies embarquées tierces telles que Adobe Flash ) et la possibilité de connecter des clients sans utiliser de serveurs supplémentaires - connexion d'égal à égal(Plus loin, p2p).

Établir une connexion p2p- une tâche assez difficile, car les ordinateurs n'ont pas toujours de fonction publique IP adresses, c'est-à-dire les adresses sur Internet. En raison de la petite quantité IPv4 adresses (et pour des raisons de sécurité) un mécanisme a été développé NAT, qui vous permet de créer des réseaux privés, par exemple, pour un usage domestique. De nombreux routeurs domestiques prennent désormais en charge NAT et grâce à cela, tous les appareils domestiques ont accès à Internet, bien que les fournisseurs d'accès Internet en fournissent généralement un IP adresse. Publique IP Les adresses sont uniques sur Internet, mais les adresses privées ne le sont pas. Alors connectez-vous p2p- difficile.

Afin de mieux comprendre cela, considérons trois situations : les deux nœuds sont sur le même réseau (Image 1), les deux nœuds sont dans des réseaux différents (l'un en privé, l'autre en public) (Photo 2) et les deux nœuds sont dans des réseaux privés différents avec le même IP adresses (Figure 3).

Figure 1 : Les deux nœuds sur le même réseau

Figure 2 : Nœuds sur différents réseaux (un en privé, un en public)

Figure 3 : Nœuds dans différents réseaux privés, mais avec des adresses numériquement égales

Dans les figures ci-dessus, la première lettre de la notation à deux caractères indique le type de nœud (p = pair, r = routeur). Dans la première figure, la situation est favorable : les nœuds de leur réseau sont complètement identifiés par réseau IP adresses et peuvent donc se connecter directement les uns aux autres. Dans la deuxième figure, nous avons deux réseaux différents qui ont des numéros de nœuds similaires. Les routeurs (routeurs) apparaissent ici, qui ont deux interface réseau- à l'intérieur de votre réseau et à l'extérieur de votre réseau. Ils ont donc deux IP adresses. Les nœuds réguliers n'ont qu'une seule interface à travers laquelle ils ne peuvent communiquer que sur leur propre réseau. S'ils transmettent des données à quelqu'un en dehors de leur réseau, alors seulement avec l'aide de NATà l'intérieur du routeur (routeur) et donc visible pour les autres sous IP l'adresse du routeur est leur externe IP adresse. Ainsi, le nœud p1 il y a intérieur IP = 192.168.0.200 et externe IP = 10.50.200.5 , la dernière adresse étant également externe à tous les autres hôtes de son réseau. La situation est similaire pour le nœud p2. Par conséquent, leur connexion est impossible si seulement leur interne (propre) IP adresses. Vous pouvez utiliser des adresses externes, c'est-à-dire les adresses des routeurs, mais comme tous les nœuds d'un même réseau privé ont la même adresse externe, c'est assez difficile. Ce problème est résolu par le mécanisme NAT

Que se passera-t-il si nous décidons toujours de connecter les nœuds via leurs adresses internes ? Les données ne quitteront pas le réseau. Pour améliorer l'effet, vous pouvez imaginer la situation illustrée dans la dernière figure - les deux nœuds ont les mêmes adresses internes. S'ils les utilisent pour communiquer, alors chaque nœud communiquera avec lui-même.

WebRTC fait face avec succès à de tels problèmes en utilisant le protocole LA GLACE, qui nécessite cependant l'utilisation de serveurs supplémentaires ( ÉTOURDIR, TOUR). Tout cela ci-dessous.

WebRTC en deux phases

Pour connecter deux nœuds via un protocole WebRTC(ou simplement RTC si deux sont connectés iPhone«a) il est nécessaire d'effectuer certaines actions préliminaires pour établir une connexion. C'est la première phase - établir une connexion. La deuxième phase est la transmission des données vidéo.

Il faut dire tout de suite que, bien que la technologie WebRTC dans son travail utilise de nombreux différentes façons communication ( TCP et UDP) et dispose d'une commutation flexible entre eux, cette technologie n'a pas de protocole pour transmettre les données de connexion. Pas surprenant, car connectez deux nœuds p2p pas si facile. Il est donc nécessaire d'avoir quelques Additionnel méthode de transfert de données, non liée à WebRTC. Il peut s'agir d'un transfert de socket, d'un protocole http, il peut même s'agir d'un protocole SMTP ou la poste russe. Ce mécanisme de transmission primaire les données sont appelées signal. Peu d'informations doivent être transférées. Toutes les données sont transmises sous forme de texte et sont divisées en deux types - SDP et Candidat de glace. Le premier type est utilisé pour établir une connexion logique, et le second pour une connexion physique. Plus d'informations à ce sujet plus tard, mais pour l'instant, il est important de se rappeler que WebRTC nous donnera des informations qui devront être transmises à un autre nœud. Dès que nous aurons transféré toutes les informations nécessaires, les nœuds pourront se connecter et notre aide ne sera plus nécessaire. Ainsi, le mécanisme de signalisation que nous devons mettre en œuvre séparément, sera utilisé uniquement lorsqu'il est connecté, et ne sera pas utilisé lors de la transmission de données vidéo.

Examinons donc la première phase, la phase de configuration de la connexion. Il se compose de plusieurs éléments. Considérez cette phase d'abord pour le nœud qui initie la connexion, puis pour celui en attente.

• Initiateur (appelant - votre interlocuteur):
  1. Offre de début de transmission de données vidéo (createOffer)
  2. Obtenir votre SDP SDP)
  3. Obtenir votre Candidat glace Candidat glace)
• Appel en attente ( appelé):
  1. Obtenir un flux multimédia local (propre) et le configurer pour la transmission (getUserMediaStream)
  2. Recevoir une offre pour démarrer un transfert de données vidéo et créer une réponse (createAnswer)
  3. Obtenir votre SDP objet et en le faisant passer par le mécanisme de signalisation ( SDP)
  4. Obtenir votre Candidat glace objets et leur transmission par le mécanisme de signalisation ( Candidat glace)
  5. Recevoir un flux multimédia distant (étranger) et l'afficher à l'écran (onAddStream)

La seule différence est dans le deuxième paragraphe.

Malgré l'apparente complexité des étapes, il y en a en fait trois : envoyer votre propre flux multimédia (p. 1), définir les paramètres de connexion (p. 2-4), recevoir le flux multimédia de quelqu'un d'autre (p. 5). Le plus difficile est la deuxième étape, car elle se compose de deux parties : établir physique et logique Connexions. Le premier indique chemin, le long duquel les paquets doivent passer pour passer d'un nœud de réseau à un autre. La seconde indique paramètres vidéo/audio- quelle qualité utiliser, quels codecs utiliser.

Stade mental créer une offre ou créerRéponse doit être connecté aux étages de transfert SDP et Candidat glace objets.

Entités de base

Flux multimédias (MediaStream)

L'entité principale est le flux multimédia, c'est-à-dire le flux de données vidéo et audio, d'image et de son. Il existe deux types de flux multimédias - locaux et distants. Le local reçoit les données des périphériques d'entrée (caméra, microphone) et le distant via le réseau. Ainsi, chaque nœud a à la fois un thread local et un thread distant. À WebRTC il y a une interface pour les flux flux multimédia et il y a aussi une sous-interface LocalMediaStream spécialement pour fil local. À Javascript vous ne pouvez rencontrer que le premier, et si vous utilisez lib jingle, alors le second peut également être rencontré.

À WebRTC il y a une hiérarchie plutôt déroutante dans le fil. Chaque flux peut être composé de plusieurs pistes multimédia ( piste multimédia), qui à son tour peut consister en plusieurs canaux média ( MédiaChannel). Et il peut également y avoir plusieurs flux multimédias eux-mêmes.

Considérons tout dans l'ordre. Pour ce faire, gardons à l'esprit quelques exemples. Disons que nous voulons transmettre non seulement une vidéo de nous-mêmes, mais aussi une vidéo de notre table, sur laquelle se trouve un morceau de papier sur lequel nous allons écrire quelque chose. Nous aurons besoin de deux vidéos (we + tableau) et d'un audio (we). Il est clair que nous et le tableau devrions être divisés en différents fils, car ces données sont probablement faiblement dépendantes les unes des autres. Nous aurons donc deux flux multimédia‘a – un pour nous et un pour la table. Le premier contiendra à la fois des données vidéo et audio, et le second ne contiendra que de la vidéo (Figure 4).

Figure 4 : Deux flux multimédias différents. Un pour nous, un pour notre table

Il est immédiatement clair que le flux multimédia doit au moins inclure la capacité de contenir des données différents types- vidéo et audio. Ceci est pris en compte dans la technologie et donc chaque type de données est implémenté via une piste média. piste multimédia. La piste média a une propriété spéciale gentil, qui détermine ce qui est devant nous - vidéo ou audio (Figure 5)

Figure 5 : Les flux multimédias sont constitués de pistes multimédias

Comment tout se passera-t-il dans le programme ? Nous allons créer deux flux multimédias. Ensuite, nous créerons deux pistes vidéo et une piste audio. Donnons accès aux caméras et au microphone. Disons à chaque piste quel appareil utiliser. Ajoutons une piste vidéo et audio au premier flux multimédia et une piste vidéo d'une autre caméra au deuxième flux multimédia.

Mais comment distinguer les flux multimédias à l'autre bout de la connexion ? Pour ce faire, chaque flux multimédia a une propriété étiquette– étiquette de flux, son nom (Figure 6). Les pistes multimédia ont la même propriété. Bien qu'à première vue, il semble que la vidéo puisse être distinguée du son par d'autres moyens.

Figure 6 : Les flux multimédias et les pistes sont identifiés par des étiquettes

Donc, si les pistes multimédias peuvent être identifiées via une étiquette, pourquoi devons-nous utiliser deux flux multimédias pour notre exemple, au lieu d'un ? Après tout, vous pouvez transférer un flux multimédia et y utiliser différentes pistes. Nous avons atteint propriété importante flux multimédias - ils synchroniser pistes médiatiques. Différents flux multimédias ne sont pas synchronisés les uns avec les autres, mais dans chaque flux multimédia, toutes les pistes sont joués en même temps.

Ainsi, si nous voulons que nos mots, nos émotions sur le visage et notre morceau de papier soient joués en même temps, cela vaut la peine d'utiliser un seul flux multimédia. Si ce n'est pas si important, il est plus rentable d'utiliser différents flux - l'image sera plus fluide.

Si une piste doit être désactivée pendant la transmission, vous pouvez utiliser la propriété activé pistes médiatiques.

En fin de compte, vous devriez penser au son stéréo. Comme vous le savez, le son stéréo est composé de deux son différent. Et ils doivent également être envoyés séparément. Les canaux sont utilisés pour cela. MédiaChannel. Une piste multimédia audio peut avoir plusieurs canaux (par exemple, 6 si vous avez besoin d'un son 5+1). À l'intérieur de la piste multimédia, les chaînes, bien sûr aussi synchronisé. Pour la vidéo, un seul canal est généralement utilisé, mais plusieurs peuvent être utilisés, par exemple pour les superpositions publicitaires.

Résumer: nous utilisons un flux multimédia pour transmettre des données vidéo et audio. Au sein de chaque flux multimédia, les données sont synchronisées. Nous pouvons utiliser plusieurs flux multimédias si nous n'avons pas besoin de synchronisation. Dans chaque flux multimédia, il existe deux types de pistes multimédia - pour la vidéo et pour l'audio. Il n'y a généralement pas plus de deux pistes, mais il peut y en avoir plus si vous avez besoin de transférer plusieurs vidéos différentes (de l'interlocuteur et de sa table). Chaque piste peut être composée de plusieurs canaux, qui ne sont généralement utilisés que pour le son stéréo.

Dans la situation de chat vidéo la plus simple, nous aurons un flux multimédia local, composé de deux pistes - une piste vidéo et une piste audio, chacune composée d'un canal principal. La piste vidéo est responsable de la caméra, la piste audio est pour le microphone et le flux multimédia est le conteneur des deux.

Descripteur de session (SDP)

À différents ordinateurs il y aura toujours différentes caméras, microphones, cartes vidéo et autres équipements. Il existe de nombreuses options qu'ils ont. Tout cela doit être coordonné pour le transfert de données multimédias entre deux nœuds de réseau. WebRTC le fait automatiquement et crée un objet spécial - le descripteur de session SDP. Transmettez cet objet à un autre nœud et vous pourrez envoyer des données multimédias. Seulement il n'y a pas encore de connexion avec un autre nœud.

Pour cela, tout mécanisme de signalisation est utilisé. SDP peut être transmis même via des prises, même par une personne (dites-le à un autre nœud par téléphone), même par la poste russe. Tout est très simple - vous recevrez un prêt à l'emploi SDP et doit être envoyé. Et dès réception de l'autre côté - transfert au département WebRTC. Le descripteur de session est stocké sous forme de texte et vous pouvez le modifier dans vos applications, mais vous n'en avez généralement pas besoin. Par exemple, lors de la connexion d'un ordinateur de bureau↔téléphone, vous devez parfois forcer la sélection du codec audio souhaité.

Habituellement, lors de l'établissement d'une connexion, vous devez spécifier une adresse, par exemple URL. Ce n'est pas nécessaire ici, puisque vous enverrez vous-même les données à la destination via le mécanisme de signalisation. Indiquer WebRTC ce que nous voulons installer p2p connexion, vous devez appeler la fonction createOffer. Après avoir appelé cette fonction et lui avoir donné un spécial rappeler'a sera créé SDP objet et transmis au même rappeler. Tout ce qui vous est demandé est de transférer cet objet sur le réseau vers un autre nœud (interlocuteur). Après cela, à l'autre extrémité, les données passeront par le mécanisme de signalisation, à savoir ce SDP un objet. Ce descripteur de session pour ce nœud est étranger et porte donc informations utiles. La réception de cet objet est un signal pour démarrer la connexion. Par conséquent, vous devez accepter cela et appeler la fonction createAnswer. C'est un analogue complet de createOffer . Retour à votre rappeler transmettra un descripteur de session local et devra être retransmis via le mécanisme de signalisation.

Il convient de noter que vous ne pouvez appeler la fonction createAnswer qu'après avoir reçu la réponse de quelqu'un d'autre. SDP objet. Pourquoi? Parce que locale SDP l'objet qui sera généré lors de l'appel de createAnswer doit s'appuyer sur la télécommande SDP un objet. Ce n'est que dans ce cas qu'il est possible de coordonner vos paramètres vidéo avec les paramètres de l'interlocuteur. De plus, n'appelez pas createAnswer et createOffer tant que le flux multimédia local n'est pas reçu - ils n'auront rien sur quoi écrire SDP un objet .

Depuis en WebRTC il est possible de modifier SDP object, puis après avoir obtenu un handle local, il doit être défini. Cela peut sembler un peu étrange de passer WebRTC ce qu'elle-même nous a donné, mais c'est le protocole. Lorsque vous recevez une poignée à distance, vous devez également la définir. Par conséquent, vous devez installer deux descripteurs sur un nœud - le vôtre et celui de quelqu'un d'autre (c'est-à-dire local et distant).

Après un tel poignées de main les nœuds connaissent les souhaits des uns et des autres. Par exemple, si le nœud 1 prend en charge les codecs UN et B, et le nœud 2 prend en charge les codecs B et C, alors, puisque chaque nœud connaît son propre descripteur et celui d'un autre, les deux nœuds choisiront un codec B(Figure 7). La logique de connexion est maintenant établie et les flux multimédias peuvent être transmis, mais il y a un autre problème - les nœuds ne sont toujours connectés que par un mécanisme de signalisation.

Figure 7 : Négociation de codec

Candidats (candidat glace)

Technologie WebRTC essayer de nous confondre avec sa nouvelle méthodologie. Lors de l'établissement d'une connexion, l'adresse du nœud avec lequel vous souhaitez vous connecter n'est pas spécifiée. Installé en premier logique connexion, non physique, bien que le contraire ait toujours été fait. Mais cela ne semblera pas étrange, si nous n'oublions pas que nous utilisons un mécanisme de signalisation tiers.

Ainsi, la connexion a déjà été établie (connexion logique), mais il n'y a pas encore de moyen pour les nœuds du réseau de transmettre des données. Tout n'est pas si simple, mais commençons simplement. Laissez les nœuds être dans le même réseau privé. Comme nous le savons déjà, ils peuvent facilement se connecter les uns aux autres via leur connexion interne. IP adresses (ou peut-être d'autres, si elles ne sont pas utilisées TCP/IP).

A travers certains rappeler'et WebRTC nous dit Candidat glace objets. Ils se présentent également sous forme textuelle et, tout comme les descripteurs de session, ils doivent simplement être envoyés via le mécanisme de signalisation. Si le descripteur de session contenait des informations sur nos paramètres au niveau de la caméra et du microphone, les candidats contiennent des informations sur notre emplacement sur le réseau. Passez-les à un autre nœud, et il pourra se connecter physiquement à nous, et puisqu'il a déjà un descripteur de session, il peut logiquement se connecter et les données « circuleront ». S'il n'oublie pas de nous envoyer son objet candidat, c'est-à-dire des informations sur l'endroit où il se trouve dans le réseau, nous pourrons alors nous connecter avec lui. Nous notons ici une différence de plus par rapport à l'interaction client-serveur classique. Communication avec Serveur HTTP se produit selon le schéma requête-réponse, le client envoie des données au serveur, qui les traite et les envoie via adresse indiquée dans le dossier de demande. À WebRTC dois savoir deux adresses et connectez-les des deux côtés.

La différence avec les descripteurs de session est que seuls les candidats distants doivent être définis. L'édition est interdite ici et ne peut apporter aucun avantage. Dans certaines implémentations WebRTC les candidats n'ont besoin d'être définis qu'après la définition des descripteurs de session.

Et pourquoi n'y avait-il qu'un seul descripteur de session, alors qu'il peut y avoir plusieurs candidats ? Parce que l'emplacement dans le réseau peut être déterminé non seulement par son IP adresse, mais aussi l'adresse externe du routeur, et pas forcément une, ainsi que les adresses TOUR les serveurs. Le reste du paragraphe sera consacré à une discussion détaillée des candidats et à la manière de connecter des nœuds de différents réseaux privés.

Ainsi, deux nœuds sont dans le même réseau (Figure 8). Comment les identifier ? En utilisant IP adresses. Pas d'autre chemin. Certes, vous pouvez toujours utiliser différents transports ( TCP et UDP) et différents ports. Il s'agit des informations contenues dans l'objet candidat - IP, PORT, LE TRANSPORT et quelques autres. Utilisons par exemple UDP transports et 531 Port.

Figure 8 : Deux nœuds sont sur le même réseau

Alors si nous sommes dans un noeud p1, alors WebRTC nous donnera un tel objet candidat - . Ce n'est pas un format exact, mais seulement un schéma. Si nous sommes dans un nœud p2, alors le candidat est . Grâce au mécanisme de signalisation p1 recevra un candidat p2(c'est-à-dire l'emplacement du nœud p2, à savoir son IP et PORT). Alors p1 peut se connecter avec p2 directement. Plus juste, p1 enverra des données à l'adresse 10.50.150.3:531 dans l'espoir qu'ils atteindront p2. Peu importe si cette adresse appartient à un nœud p2 ou un intermédiaire. La seule chose importante est que les données seront envoyées via cette adresse et pourront atteindre p2.

Tant que les nœuds sont dans le même réseau - tout est simple et facile - chaque nœud n'a qu'un seul objet candidat (signifiant toujours le sien, c'est-à-dire son emplacement dans le réseau). Mais il y aura beaucoup plus de candidats lorsque les nœuds seront en différent réseaux.

Passons à un cas plus compliqué. Un nœud sera derrière le routeur (plus précisément, derrière NAT), et le deuxième nœud sera dans le même réseau avec ce routeur (par exemple, sur Internet) (Figure 9).

Figure 9 : Un hôte derrière NAT, un autre pas

Ce cas a une solution particulière au problème, que nous considérons maintenant. Un routeur domestique contient généralement une table NAT. Il s'agit d'un mécanisme spécial conçu pour permettre aux nœuds du réseau privé du routeur d'accéder, par exemple, à des sites Web.

Supposons que le serveur Web soit directement connecté à Internet, c'est-à-dire qu'il dispose d'un accès public IP* adresse. Que ce soit un nœud p2. Nouer p1(client web) envoie une requête à l'adresse 10.50.200.10 . Tout d'abord, les données vont au routeur r1, ou plutôt sur son intérieur interface 192.168.0.1 . Après cela, le routeur se souvient de l'adresse source (adresse p1) et l'inscrit dans une table spéciale NAT, puis remplace l'adresse source par la sienne ( p1 → r1). De plus, selon externe interface, le routeur envoie les données directement au serveur web p2. Le serveur Web traite les données, génère une réponse et la renvoie. Envoie au routeur r1, puisque c'est lui qui est dans l'adresse de retour (le routeur a changé l'adresse pour la sienne). Le routeur reçoit des données, regarde la table NAT et envoie les données au nœud p1. Le routeur agit ici comme intermédiaire.

Mais que se passe-t-il si plusieurs nœuds du réseau interne accèdent au réseau externe en même temps ? Comment le routeur comprendra-t-il à qui renvoyer la réponse ? Ce problème est résolu avec ports. Lorsque le routeur remplace l'adresse de l'hôte par la sienne, il remplace également le port. Si deux nœuds accèdent à Internet, le routeur remplace leurs ports source par divers. Ensuite, lorsque le paquet du serveur Web reviendra au routeur, le routeur comprendra par le port à qui ce paquet est attribué. Un exemple est ci-dessous.

Retour à la technologie WebRTC, ou plutôt, à sa partie qui utilise LA GLACE protocole (donc Glace candidats). Nouer p2 a un candidat (sa localisation dans le réseau - 10.50.200.10 ), et le nœud p1, qui se trouve derrière un routeur avec NAT, aura deux candidats - local ( 192.168.0.200 ) et routeur candidat ( 10.50.200.5 ). Le premier n'est pas utile, mais il est quand même généré, puisque WebRTC ne sait encore rien de l'hôte distant - il peut se trouver ou non sur le même réseau. Le deuxième candidat sera utile, et comme nous le savons déjà, le port jouera un rôle important (pour passer NAT).

Entrée de tableau NAT généré uniquement lorsque les données sortent du réseau interne. Par conséquent, le nœud p1 doit d'abord transmettre les données et ensuite seulement les données du nœud p2 peut accéder au nœud p1.

En pratique les deux nœuds sera derrière NAT. Pour créer une entrée dans une table NAT chaque routeur, les nœuds doivent envoyer quelque chose au nœud distant, mais cette fois ni le premier ne peut atteindre le second, ni l'inverse. Cela est dû au fait que les nœuds ne connaissent pas leurs IP adresses, et l'envoi de données à des adresses internes n'a aucun sens.

Cependant, si les adresses externes sont connues, la connexion sera facilement établie. Si le premier nœud envoie des données au routeur du deuxième nœud, alors le routeur les ignorera, puisque sa table NATà vide. Cependant, dans le routeur du premier nœud de la table NAT il fallait un dossier. Si maintenant le deuxième nœud envoie des données au routeur du premier nœud, le routeur les transmettra avec succès au premier nœud. maintenant le tableau NAT le deuxième routeur a les données dont vous avez besoin.

Le problème est que pour connaître votre externe IP adresse, vous avez besoin d'un nœud situé dans réseau commun. Pour résoudre ce problème, des serveurs supplémentaires sont utilisés qui sont directement connectés à Internet. Avec leur aide, les précieux enregistrements du tableau sont également créés. NAT.

Serveurs STUN et TURN

A l'initialisation WebRTC disponible ÉTOURDIR et TOUR serveurs, que nous appellerons LA GLACE les serveurs. Si les serveurs ne sont pas spécifiés, seuls les nœuds du même réseau (qui y sont connectés sans NAT). Il convient de noter immédiatement que pour 3g-les réseaux doivent être utilisés TOUR les serveurs.

ÉTOURDIR serveur n'est qu'un serveur sur Internet qui renvoie adresse de retour, qui est l'adresse de l'hôte expéditeur. Le nœud derrière le routeur accède ÉTOURDIR serveur à traverser NAT. Le colis qui est arrivé ÉTOURDIR serveur, contient l'adresse source - l'adresse du routeur, c'est-à-dire l'adresse externe de notre nœud. Cette adresse ÉTOURDIR serveur et renvoie. Ainsi, le nœud obtient son externe IP l'adresse et le port par lequel il est accessible depuis le réseau. Plus loin, WebRTC l'utilisation de cette adresse crée un candidat supplémentaire (adresse et port de routeur externe). Maintenant dans le tableau NAT le routeur a une entrée qui transmet les paquets envoyés au routeur sur le port requis à notre nœud.

Regardons ce processus avec un exemple.

Exemple (fonctionnement du serveur STUN)

ÉTOURDIR le serveur sera désigné par s1. Routeur, comme avant, à travers r1, et le nœud passant par p1. Vous devrez également suivre le tableau NAT- notons-le comme r1_nat. De plus, cette table contient généralement de nombreuses entrées provenant de différents nœuds de sous-réseau - elles ne seront pas données.

Donc, au début, nous avons une table vide r1_nat.

Tableau 2 : En-tête de paquet

Nouer p1 envoie ce paquet au routeur r1(peu importe comment, différentes technologies peuvent être utilisées dans différents sous-réseaux). Le routeur doit effectuer une substitution de l'adresse source IP src, puisque l'adresse spécifiée dans le paquet n'est évidemment pas adaptée au sous-réseau externe, de plus, les adresses de cette plage sont réservées, et pas une seule adresse sur Internet n'a une telle adresse. Le routeur effectue une substitution dans le paquet et crée nouvel enregistrement dans votre tableau r1_nat. Pour ce faire, il doit trouver un numéro de port. Rappelez-vous que, puisque plusieurs nœuds d'un sous-réseau peuvent accéder à un réseau externe, alors dans le tableau NAT Devrait être gardé Informations Complémentaires afin que le routeur puisse déterminer auquel de ces plusieurs hôtes le paquet de retour du serveur est destiné. Laissez le routeur proposer un port 888 .

En-tête de paquet modifié :

Tableau 4 : Tableau NAT mis à jour avec une nouvelle entrée

Ici IP l'adresse et le port du sous-réseau sont exactement les mêmes que ceux du paquet d'origine. En effet, lors de la publication, nous devons avoir un moyen de les restaurer complètement. IP l'adresse du réseau externe est l'adresse du routeur et le port a été remplacé par celui inventé par le routeur.

Le port réel auquel le nœud p1 accepte une connexion - ceci, bien sûr, 35777 , mais le serveur envoie des données à fictif Port 888 , qui sera remplacé par le routeur par le vrai 35777 .

Ainsi, le routeur a changé l'adresse source et le port dans l'en-tête du paquet et a ajouté une entrée à la table NAT. Maintenant, le paquet est envoyé sur le réseau au serveur, c'est-à-dire au nœud s1. à l'entrée, s1 a ce paquet:

IP src	PORT SRC	IP cible	PORT DEST
10.50.200.5	888	12.62.100.200	6000

Tableau 5 : Le serveur STUN a reçu un paquet

Total ÉTOURDIR le serveur sait qu'il a reçu un paquet de l'adresse 10.50.200.5:888 . Maintenant, le serveur renvoie cette adresse. Cela vaut la peine de s'arrêter ici et de revenir sur ce que nous venons de considérer. Les tableaux ci-dessus font partie de entête paquet, pas du tout contenu. Nous n'avons pas parlé du contenu, car ce n'est pas si important - il est en quelque sorte décrit dans le protocole ÉTOURDIR. Maintenant, nous allons considérer en plus du titre aussi le contenu. Il sera simple et contiendra l'adresse du routeur - 10.50.200.5:888 même si nous l'avons pris de entête forfait. Cela n'est pas souvent fait, généralement les protocoles ne se soucient pas des informations sur les adresses des nœuds, il est seulement important que les paquets soient livrés à leur destination. Ici, nous considérons un protocole qui établit un chemin entre deux nœuds.

Nous avons donc maintenant un deuxième lot allant dans la direction opposée :

Tableau 7 : Le serveur STUN envoie un paquet avec ce contenu

Ensuite, le paquet voyage à travers le réseau jusqu'à ce qu'il atteigne l'interface externe du routeur r1. Le routeur comprend que le colis ne lui est pas destiné. Comment le comprend-il ? Cela ne peut être trouvé que par le port. Port 888 il n'utilise pas à ses fins personnelles, mais utilise pour le mécanisme NAT. Par conséquent, le routeur examine également cette table. Regarde la colonne PORT externe et à la recherche d'une chaîne qui correspond PORT DEST du colis entrant, c'est-à-dire 888 .

IP interne	Port interne	IP externe	PORT externe
192.168.0.200	35777	10.50.200.5	888

Tableau 8 : Tableau NAT

Nous avons de la chance qu'une telle ligne existe. S'il n'y avait pas de chance, le paquet serait simplement jeté. Vous devez maintenant comprendre lequel des nœuds de sous-réseau doit envoyer ce paquet. Ne nous précipitons pas, récapitulons l'importance des ports dans ce mécanisme. Dans le même temps, deux nœuds du sous-réseau peuvent envoyer des requêtes au réseau externe. Ensuite, si pour le premier nœud, le routeur propose un port 888 , puis pour la seconde il proposerait un port 889 . Supposons que cela se produise, c'est-à-dire que la table r1_nat Ressemble à ça:

Tableau 10 : adresse de récepteur d'usurpation de routeur

IP src	PORT SRC	IP cible	PORT DEST
12.62.100.200	6000	192.168.0.200	35777

Tableau 11 : Le routeur a modifié l'adresse du récepteur

Le paquet arrive avec succès au nœud p1 et en examinant le contenu du paquet, le nœud se renseigne sur son externe IP adresse, c'est-à-dire l'adresse du routeur dans le réseau externe. Il connaît également le port par lequel le routeur passe NAT.

Et après? A quoi ça sert tout ça ? L'avantage est une entrée dans le tableau r1_nat. Si maintenant quelqu'un enverra au routeur r1 port paquet 888 , le routeur transmettra ce paquet à l'hôte p1. Ainsi, un petit passage étroit a été créé vers le nœud caché p1.

À partir de l'exemple ci-dessus, vous pouvez avoir une idée de la façon dont cela fonctionne. NAT et essence ÉTOURDIR serveur. En général, le mécanisme LA GLACE et Étourdir/tourner les serveurs visent juste à surmonter les restrictions NAT.

Il peut y avoir plus d'un routeur entre le nœud et le serveur, mais plusieurs. Dans ce cas, le nœud recevra l'adresse du routeur qui est le premier à entrer dans le même réseau que le serveur. En d'autres termes, nous obtenons l'adresse du routeur connecté à ÉTOURDIR serveur. Pour p2p la communication est exactement ce dont nous avons besoin, si nous n'oublions pas le fait que dans chaque routeur, la ligne dont nous avons besoin sera ajoutée à la table NAT. Ainsi, le retour sera à nouveau tout aussi fluide.

TOUR le serveur est amélioré ÉTOURDIR serveur. Il en résulte immédiatement que tout TOUR le serveur peut fonctionner et comment ÉTOURDIR serveur. Cependant, il y a aussi des avantages. Si un p2p la communication n'est pas possible (comme dans 3g réseaux), puis le serveur passe en mode répéteur ( relais), c'est-à-dire qu'il fonctionne comme un intermédiaire. Bien sûr, à propos de n'importe quel p2p alors ce n'est pas une question, mais hors du cadre du mécanisme LA GLACE les nœuds pensent qu'ils communiquent directement.

Dans quels cas faut-il TOUR serveur? Pourquoi n'est pas assez ÉTOURDIR les serveurs? Le fait est qu'il existe plusieurs types NAT. Ils remplacent le même IP adresse et port, mais certains d'entre eux ont intégré protection supplémentaire de « falsification ». Par exemple, dans symétrique table NAT 2 autres paramètres sont enregistrés - IP et le port de l'hôte distant. Un paquet du réseau externe passe par NAT au réseau interne uniquement si l'adresse source et le port correspondent à ceux enregistrés dans la table. Par conséquent, la mise au point ÉTOURDIR panne du serveur - tableau NAT adresse et port des magasins ÉTOURDIR serveur et lorsque le routeur reçoit un paquet de WebRTC interlocuteur, il l'écarte, car il est « falsifié ». Il ne vient pas de ÉTOURDIR serveur.

De cette façon TOUR un serveur est nécessaire lorsque les deux interlocuteurs sont derrière symétrique NAT(chacun pour le sien).

Bref résumé

Voici quelques déclarations sur les entités WebRTC qu'il faut toujours garder à l'esprit. Ils sont décrits en détail ci-dessus. Si l'un des énoncés ne vous semble pas tout à fait clair, relisez les paragraphes concernés.

• flux multimédia
  • Les données vidéo et audio sont regroupées dans des flux multimédias
  • Les flux multimédias synchronisent les pistes multimédias qui composent
  • Différents flux multimédias ne sont pas synchronisés
  • Les flux multimédias peuvent être locaux et distants, une caméra et un microphone sont généralement connectés au local, les distants reçoivent les données du réseau sous forme cryptée
  • Il existe deux types de pistes multimédia - pour la vidéo et pour l'audio.
  • Les pistes multimédias ont la possibilité d'activer / désactiver
  • Les pistes multimédias sont composées de canaux multimédias
  • Les pistes multimédias synchronisent les canaux multimédias qui composent
  • Les flux multimédias et les pistes multimédias ont des étiquettes par lesquelles ils peuvent être distingués
• Descripteur de session
  • Le descripteur de session est utilisé pour connecter logiquement deux nœuds de réseau
  • Le descripteur de session stocke des informations sur moyens disponibles encodage de données vidéo et audio
  • WebRTC utilise un mécanisme de signalisation externe - la tâche de transmettre les descripteurs de session ( sdp) tombe sur l'application
  • Le mécanisme de connexion logique se compose de deux étapes - une proposition ( offrir) et réponse ( réponse)
  • La génération de descripteur de session n'est pas possible sans utiliser un flux multimédia local en cas d'offre ( offrir) et n'est pas possible sans utiliser un descripteur de session distante en cas de réponse ( réponse)
  • Le descripteur résultant doit être donné à l'implémentation WebRTC, et peu importe si ce handle est obtenu à distance ou localement à partir de la même implémentation WebRTC
  • Il est possible de modifier légèrement le descripteur de session
• Candidats
  • Candidat ( Candidat glace) est l'adresse du nœud dans le réseau
  • L'adresse du nœud peut être la vôtre, ou il peut s'agir de l'adresse d'un routeur ou TOUR les serveurs
  • Il y a toujours beaucoup de candidats
  • Le candidat est composé de IP adresse, port et type de transport ( TCP ou UDP)
  • Les candidats sont utilisés pour établir une connexion physique entre deux nœuds dans un réseau
  • Les candidats doivent également être envoyés via le mécanisme de signalisation
  • Les candidats doivent également réussir les implémentations WebRTC, mais seulement à distance
  • Dans certaines implémentations WebRTC Les candidats ne peuvent être acceptés qu'une fois le descripteur de session défini
• STUN/TURN/ICE/NAT
  • NAT– un mécanisme de fourniture d'accès à un réseau externe
  • Les routeurs domestiques prennent en charge une table spéciale NAT
  • Le routeur remplace les adresses dans les paquets - l'adresse source par la sienne, si le paquet va au réseau externe, et l'adresse du récepteur par l'adresse hôte dans le réseau interne, si le paquet provient du réseau externe
  • Pour fournir un accès multicanal à un réseau externe NAT utilise des ports
  • LA GLACE- mécanisme de dérivation NAT
  • ÉTOURDIR et TOUR serveurs - serveurs auxiliaires pour contourner NAT
  • ÉTOURDIR le serveur vous permet de créer les entrées nécessaires dans la table NAT, et renvoie également l'adresse externe du nœud
  • TOUR le serveur généralise ÉTOURDIR mécanisme et le fait toujours fonctionner
  • Dans les pires cas TOUR le serveur sert d'intermédiaire ( relais), C'est p2p se transforme en une connexion client-serveur-client.