Cet article offre une lecture linéaire de quelques minutes. Il porte sur un aspect technique réseau sur lequel nos clients et prospects nous posent souvent des questions. Nous y répondons donc ici, dans le but de partager les savoirs et la réflexion.

Passons donc en revue quelques éléments qui composent un réseau, sous l’angle de la visioconférence, tout en ayant une vision de haut niveau.

Le Web et la voix/vidéo de WebRTC avec TCP et UDP

Sur Internet, vous le savez sans doute, les ordinateurs communiquent entre eux en envoyant des petits paquets de données. Le protocole de communication s’appelle IP pour Internet Protocol.

Il existe deux autre protocoles qui se reposent sur IP : TCP et UDP.

TCP assure l’ordre des paquets et la fiabilité de transmission. C’est donc très bien adapté au web, au mail, au chat, à la transmission de fichiers dont les images, par exemple.

UDP va beaucoup plus vite en n’assurant ni ordre ni fiabilité, donc il peut perdre des paquets. C’est très bien adapté à la voix et à la vidéo, car l’être humain ne perçoit pas la perte d’un petit nombre de paquets de données audio ou vidéo.

Le point commun entre TCP et UDP, c’est qu’il faut pour transmettre des données, l’adresse IP et le port.

TCP pour les données fiables, et UDP pour la voix et la vidéo. Donc le web sur TCP et la voix et vidéo de WebRTC sur UDP.

Le pair-à-pair, ou « peer-to-peer » (mesh)

Les applications de visioconférence WebRTC tentent généralement de communiquer de pair-à-pair, c’est-à-dire de navigateur à navigateur.

En effet, il est parfois préférable de ne pas passer par un serveur, dans le but de ne pas consommer trop de données sur ce dernier. Une application WebRTC de voix et vidéo consommera beaucoup plus de volume de données qu’une simple application Web : dans le premier cas, les flux sont continus et volumineux, dans le second cas petits et intermittents (à la demande).

Dans ce mode, les deux navigateurs échangent en direct leur adresse IP et les ports voix et vidéo sur lequel ils vont communiquer.

Traverser les réseaux avec ICE, STUN et TURN

Le pair-à-pair fonctionne correctement dans un réseau local. Sur Internet, ce sont plusieurs réseaux locaux qui sont généralement séparés par des « passages » réseau qu’on appelle des NAT (Network Address Translation).

On n’a donc pas l’adresse IP du navigateur dans le réseau local, mais l’adresse IP externe du NAT sur Internet.

On a alors besoin d’un serveur STUN sur Internet public et visible de tous, pour échanger les adresses IP externes et ports de ces NAT.

Parfois, cette aide ne suffit pas, il y a besoin d’un relai TURN. Le navigateur est en communication pair-à-pair avec le serveur TURN et relaie donc les flux audio et vidéo.

Et ICE est le protocole qui décrit comment se servir de STUN puis TURN, en cas de besoin.

STUN aide à mieux traverser les NAT, TURN permet de relayer les flux audio et vidéo, ICE décrit l’usage de STUN et TURN.

Architectures serveur SFU et MCU

Lorsqu’on monte à l’échelle, le pair-à-pair trouve ses limites très tôt, puisqu’à partir de 3 à 5 participants, les navigateurs sont énormément sollicités.

On insère donc un serveur sur internet public qui va centraliser, relayer et/ou mixer les flux.

Lisez notre article sur les architectures, et comprenez bien les avantages et inconvénients de chacune.

Un SFU relaie tous les flux, un MCU mixe tous les flux.

Les pare-feux et UDP

Le web sur TCP passe généralement les pare-feux, mais la voix et la vidéo de WebRTC sur UDP se retrouve parfois bloqués par ces derniers.

Il est donc nécessaire d’ouvrir les ports sur le protocole UDP vers les serveurs de visioconférence.

Parfois il n’est pas possible ou pas souhaitable d’ouvrir des ports pour UDP. Il est alors possible d’utiliser un contournement : on fait passer le flux UDP sur des ports généralement dédiés à du TCP, comme HTTPS, à savoir le port 443.

Le changement de port est une adaptation tout à fait acceptable.

La DPI et TURN

Il existe en outre des outils réseau un peu plus exigeants en terme de sécurité : la DPI, pour Deep Packet Inspection. Ces outils fouillent dans les paquets alors que le pare-feux se contentent de les « regarder passer ».

TURN est alors employé pour encapsuler les flux audio/vidéo UDP dans TCP, c’est une astuce.

Du côté de la DPI, il est nécessaire de procéder aux ajustements de configuration afin de laisser passer ce trafic légitime.

Ainsi le trafic entre le navigateur et le serveur TURN est en TCP, donc le pare-feu et la DPI laissent passer, puis du serveur TURN public au serveur WebRTC public le trafic est en UDP.

Un serveur TURN permet de passer la DPI si celle-ci est configurée pour être tolérante.

BigBlueButton, Jitsi Meet, Nextcloud Talk

Les trois logiciels phares de la visioconférence opensource BigBlueButton, Jitsi Meet et Nextcloud Talk utiliseront ces techniques ou astuces pour les réseaux les plus restrictifs.

Consultez notre comparatif fonctionnel pour vous faire une idée précise des besoin couverts par chacune des solutions.

Demandez l’expertise Arawa

Arawa fournit des produits opensource de visioconférence et les services associés.

N’hésitez pas à nous formuler votre demande.

Bibliographie : pour aller plus loin

Wikipédia nous semble comme d’habitude une documentation qui représente un excellent point de départ pour mieux comprendre l’univers WebRTC et celui de la VoIP.