Quand nous créons une application web, nous avons parfois besoin d'installer un système de communication sur cette application, que ce soit sous la forme d'un chat en ligne ou d'un streaming vidéo. Et quand cela arrive, on pourrait avoir tendance à se demander ce qu'il va falloir installer pour cela. Mais il existe une solution permettant de se passer de toute installation de logiciels, plugins ou autre sur votre application : WebRTC. 

WebRTC, pour Web Real-Time Communication, est un standard open-source de communication en temps réel entre navigateurs. Grâce à lui (et aux talents de nos/vos développeurs), il est possible de créer un module de communication entre plusieurs navigateurs web tels que Google Chrome, FireFox, etc. Mais le plus intéressant est que cette communication est directe, elle ne passe pas par un serveur tiers contrairement aux méthodes plus traditionnelles. 

Il faut déjà commencer à nuancer légèrement le fait qu'il n'y ait pas de serveur utilisé pour communiquer. Le standard WebRTC utilise bel et bien un serveur dans le processus de communication, mais ce dernier n'est pas utilisé pour les échanges de données en tant que tel, il sert uniquement à la signalisation, autrement dit, il est là uniquement pour permettre aux navigateurs de s'identifier entre eux et les met en relation. La suite se passe entre eux via des échanges peer-to-peer. 

La partie signalisation se fait via le protocole SDP, pour Session Description Protocol. Il s’agit basiquement d’un fichier texte contenant plusieurs paires de clés / valeurs. Ce fichier va contenir toutes les données qui seront utiles à la connexion entre les navigateurs comme les adresses IPs, les ports utilisés, les codecs audio et vidéo, etc. Ces fichiers SDP seront envoyés par exemple via WebSocket mais d’autres moyens peuvent être utilisés selon les besoins et les capacités de votre application / navigateur. 

Maintenant que la signalisation est faite, les deux navigateurs vont à présent tenter de se connecter entre eux. Pour cela, WebRTC utilise le protocole ICE, pour Interactive Connectivity Establishment. Ce protocole a été conçu pour permettre l’établissement d’une connexion entre deux agents. 

Selon les restrictions et/ou la sécurité du réseau où se trouve l’un ou tous les navigateurs souhaitant communiquer, WebRTC aura potentiellement besoin d’utiliser des serveurs STUN (Session Traversal Utilities for NAT) dans le cas de réseaux utilisant une NAT, voire d’un serveur TURN (Traversal Using Relays around NAT) pour les réseaux les plus sécurisés. Toutefois, l’utilisation d’un TURN est à éviter si cela est possible car cela ralentit le flux de données lors de la communication. 

Niveau sécurité, WebRTC va utiliser deux protocoles : DTLS (Datagram Transport Layer Security) pour sécuriser les communications et SRTP (Secure Real-Time Transport Protocol) pour sécuriser les paquets de données RTP. 

Le RTP justement (Real-Time Transport Protocol) est l’un des derniers protocoles utilisés par WebRTC qui permet de gérer le streaming en temps réel. Enfin, nous avons SCTP (Stream Control Transmission Protocol) permettant la transmission de messages. 

En ayant tout cela en tête, on se rend finalement compte d’une chose. WebRTC utilise beaucoup de protocoles différents : SDP, ICE, STUN, TURN, DTLS, SRTP, RTP ou encore SCTP. Tous ces protocoles sont antérieurs à WebRTC (voire très antérieur vu que SDP date de 1998). 

Finalement, la force de WebRTC est d’être une sorte de chef de projet ayant sélectionné les éléments les plus adaptés et déjà éprouvés pour chaque partie de son processus. Cela peut permettre notamment d’étudier chaque morceau individuellement afin d’ajuster votre application à vos besoins. 

Contrairement à ce que cette liste de protocoles laisse penser, la mise en œuvre s'avère quant à elle relativement facile. D'ailleurs, les langages nécessaires sont classiques : JavaScript et HTML. Cela peut être combiné avec d'autres frameworks comme Angular évidemment, mais ils ne sont pas indispensables. WebRTC fonctionne avec des éléments simples d'accès. 

Prenons un exemple concret. Nous mettons en place un appel audio / vidéo entre deux utilisateurs. WebRTC va utiliser la méthode getUserMedia() (https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia) afin d'obtenir l'autorisation de l'utilisateur d'accéder au micro et à la webcam. Ensuite, tout passera par RTCPeerConnection qui se chargera, avec les bonnes configurations, d'établir la connexion et de démarrer l'appel vidéo (sachant que la partie HTML au plus basique se limitera à des balises vidéos et quelques boutons pour démarrer / arrêter l'appel). 

Le premier avantage de WebRTC est qu'il est open-source, et donc gratuit. Ensuite, comme évoqué, pas besoin de serveur pour gérer la communication. Si vous devez utiliser du STUN, vous pouvez utiliser des serveurs publics comme ceux de Google par exemple (vous trouverez une liste non exhaustive ici : https://wiki.freepbx.org/display/FPG/STUN+Servers, n'hésitez pas à tester leur disponibilité avec l'outil Trickle ICE https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ ). Le seul cas pouvant poser un problème est si vous avez besoin d'un serveur TURN qu'il faudra créer vous-même. 

Le (très) gros avantage de WebRTC est surtout son niveau de sécurité, offrant aux utilisateurs des communications hautement sécurisée grâce à ses flux nativement cryptés grâce aux protocoles précédemment mentionnés comme DTLS ou SRTP. 

WebRTC est également très flexible pour les développeurs afin qu'ils puissent répondre aux besoins de leurs clients. Enfin, WebRTC est compatible avec la plupart des navigateurs et systèmes d'exploitation. 

WebRTC peut être utilisé pour beaucoup de projets différents afin de faire de la communication audio / vidéo, du service client, du streaming, etc.