Améliorer l’accès aux visioconférences Jitsi

Jitsi Meet est une solution libre de visioconférence construite autour du protocole WebRTC. L’éditeur en met à disposition une instance publique, mais qui est difficilement utilisable dans un contexte professionnel où la confidentialité est un enjeu important.

Il est donc recommandé en entreprise d’installer un service dédié, que l’on pourra sécuriser en fonction des besoins (mise en place d’une authentification par exemple).

On se rend compte cependant qu’il n’est pas toujours facile pour les participants de se connecter à un serveur, essentiellement pour des problèmes de compatibilité réseau.

Il est vrai que les protocoles utilisés sont nombreux et complexes. De plus la documentation est obscure, quand elle existe.

On ne traite dans cet article que les problèmes de connectivité. D’autres facteurs peuvent en effet rendre les échanges difficiles : la consommation importante de bande passante et l’utilisation excessive de CPU sur les postes de travail. Ces problèmes sont souvent contournés en coupant ou en limitant l’usage de la vidéo.

Cet article est une synthèse de notre livre blanc que vous pouvez télécharger ici: https://bit.ly/3gMnky8

La solution de visioconférence libre Jitsi meet

Depuis le confinement causé par la covid-19, tout le monde connaît Zoom et ses concurrents Teams, Webex, Google Meet, etc. Jitsi Meet est une solution équivalente, qui certes ne peut se prévaloir de toutes les fonctionnalités des offres commerciales, mais qui a l’avantage d’être entièrement libre et gratuite.

Elle s’est imposée comme référence dans l’open source et est intégrée dans la plupart des offres libres de type digital workplace.

Un autre avantage par rapport à Zoom, c’est qu’il suffit d’avoir un navigateur web (récent) pour se connecter à une salle de visioconférence, sans installation de quoi que ce soit sur le poste client (caractéristique d’ailleurs partagée avec Google Meet).

Pour cela, Jitsi exploite la norme WebRTC, qui est implémentée dans les navigateurs modernes.

Cette norme a été imaginée au départ pour des communications entre deux personnes, de poste à poste. Le nom complet de la norme est d’ailleurs « communication en temps réel entre navigateurs ».

Jitsi étend ce concept à la visioconférence, c’est-à-dire aux échanges entre plusieurs participants. Dans une architecture en étoile, les différents participants se connectent – toujours en WebRTC – à un serveur central qui se charge du routage des flux entre les navigateurs.

En termes réseau, on est face à deux difficultés. La première, c’est qu’un protocole prévu pour le poste à poste est dévoyé en client / serveur.

La seconde, c’est que les flux média sont atypiques dans notre monde actuel essentiellement web, où les pages sont un assemblage d’objets récupérés par des connexions atomiques courtes (protocole HTTP). A l’opposé, l’audio et la video requièrent des connexions longues et continues, où la qualité de la communication n’est pas essentielle (la perte de paquets est acceptée).

Web RTC avec Jitsi

Jitsi utilise WebRTC pour établir des connexions entre un serveur et chaque participant à une visioconférence. Chaque participant entre dans une communication de type poste à poste avec le serveur, qui se comporte comme un navigateur.

Le serveur reçoit les images et la voix de chaque participant, puis les redistribue aux autres participants, dans une architecture en étoile. Un participant envoie donc son flux au serveur et en retour reçoit un flux pour chaque autre participant, soit (n-1) flux au total en réception.

Une visioconférence est donc bien plus complexe à gérer qu’une simple conversation entre deux parties, puisqu’il faut contrôler autant de sessions point à point que de participants.

Dans cette architecture, WebRTC reste techniquement en point à point, entre un navigateur et un serveur. Mais avec une coloration asymétrique : une des deux extrémités de la connexion est bien connue, puisqu’il s’agit du serveur. On est donc dans du WebRTC utilisé en client / serveur.

Une conférence commence par des échanges de type web normal, pour mettre en place ce qu’on appelle la signalisation, c’est-à-dire la manière de réaliser les échanges de son et d’image en WebRTC. Ceux-ci ne peuvent emprunter les mêmes canaux que le web, d’une part parce que les protocoles web (HTTP) ne sont pas adaptés à des flux temps réel, et d’autre part du fait que le protocole WebRTC implique que le serveur Jitsi se connecte directement aux participants, ce que HTTP ne prévoit pas.

Détermination du moyen de connexion le plus approprié

Dans un mode IP, le moyen le plus approprié pour transporter des flux média en temps réel est le protocole UDP qui envoie les données au fil de l’eau, sans vérifier qu’elles soient correctement reçues. Le protocole TCP, le plus utilisé, assure au contraire l’intégrité des échanges, en envoyant de nouveau les informations qui n’ont pas correctement été reçues. Dans un flux temps réel, cette caractéristique est au contraire pénalisante.

De ce fait, en visioconférence, l’idéal est que le navigateur envoie les flux média vers le serveur sous forme de paquets UDP, le serveur en faisant exactement de même dans le sens inverse.

Ce schéma fonctionne correctement lorsque les deux extrémités se trouvent sur le même réseau, ou du moins peuvent communiquer sans contraintes avec leurs adresses locales.

Or dès lors que les connexions transitent par internet, divers équipements de sécurité entrent en jeu : proxy, firewall, translation d’adresse, qui empêchent ou restreignent les échanges UDP

Les équipements réseau sont en effet optimisés pour les flux TCP qui constituent l’essentiel des échanges web.

Pour que les visioconférences se déroulent dans les meilleures conditions, on va passer ici en revue les différents cas d’usage rencontrés et détailler pour chacun les mécanismes à mettre en place.

Cas simple en réseau local 

Le cas d’usage le plus simple est la visioconférence interne où le serveur Jitsi et les participants sont sur le même réseau local. C’est la situation rencontrée en interne à une entreprise.

Les échanges se font dans le cadre idéal, par des connexions UDP. Lors de la phase initiale de signalisation, le participant et le serveur s’échangent leurs adresses respectives pour que l’autre partie puisse s’y connecter.

Serveur Jitsi publié sur internet 

Lorsque le serveur Jitsi est publié sur internet, il est visible de deux manières différentes : avec son adresse locale pour les accès locaux et avec une adresse publique pour les accès depuis internet.

Un mécanisme de translation d’adresse auprès du firewall protégeant le serveur Jitsi donne la visibilité sur internet. Il est nécessaire que cette translation soit de type statique, c’est-à-dire que les paquets venant à l’initiative d’internet soient acceptés et dirigés vers le serveur Jitsi (Full Cone NAT).

Dans notre illustration, le serveur Jitsi est vu avec l’adresse 192.168.10.4 en local et avec l’adresse 176.45.3.7 depuis internet.

Les méthodes de connexion se déclinent en fonction de la localisation du poste du participant. On étudie ci-dessous les cas d’usage les plus courants.

Serveur sur internet, accès des participants en direct sur internet 

On se place pour commencer dans le cas le plus simple, celui d’un poste directement sur internet. C’est par exemple le cas des téléphones mobiles en 4G. Ils disposent en effet d’une adresse IP publique fournie par l’opérateur.

Pour la connexion du serveur vers le participant, le schéma est simple. Le participant annonce au serveur Jitsi son adresse locale. Celle-ci est une adresse publique et le serveur Jitsi pourra donc simplement lui envoyer les flux média.

Pour le flux inverse, du participant vers le serveur Jitsi, il faut que le navigateur connaisse l’adresse du serveur pour pouvoir s’y connecter. Or par défaut, le serveur Jitsi annonce son adresse IP locale.

Mais ici, cette adresse locale (192.168.10.4) est privée et n’est donc pas visible sur internet. Le participant ne pourra pas y accéder.

Pour annoncer la bonne adresse, il suffit simplement de paramétrer le serveur Jitsi pour qu’il transmette non seulement son adresse locale, mais aussi son adresse translatée (176.45.3.7).

Avec les dernières versions de Jitsi Meet (depuis avril 2020), un mécanisme automatique a été même intégré : l’adresse publique est déterminée automatiquement, au travers d’un dispositif à base de STUN.

Ce protocole a été conçu spécifiquement pour la découverte automatique des adresses IP publiques. On place un serveur STUN sur internet. Le serveur Jitsi s’y connecte, ce qui donne l’occasion au serveur STUN de regarder l’adresse IP publique dans les paquets IP qu’il reçoit. L’information est alors retournée à Jitsi qui connaît ainsi en temps réelle son adresse de sortie sur internet.

Le projet Jitsi a déployé un serveur STUN à cet effet dans le domaine jitsi.org et il en a renseigné le nom en dur dans le code de Jitsi Meet.

On remarquera que ce mécanisme n’est pas propre au serveur Jitsi. Il a été imaginé à l’origine pour que les participants à des appels WebRTC puissent découvrir automatiquement leur propre adresse publique lorsqu’ils se trouvent sur un réseau privé.

On verra d’ailleurs plus bas qu’un service STUN participe aussi à l’amélioration de la connexion des participants à une réunion Jitsi.

Accès du participant depuis son domicile 

Le premier niveau de complexité est rencontré lorsque les personnes font une visioconférence depuis leur domicile. Elles sont derrière une box internet qui fait de la translation d’adresse.

 

Cette translation suit un modèle différent de celui du serveur Jitsi. Pour ce dernier, tous les paquets venant d’internet sont nécessairement routés vers le serveur. Dans une installation à domicile, une seule adresse IP publique est partagée par de nombreux équipements. C’est normal puisqu’on est dans un schéma où les habitants font essentiellement appel à des ressources extérieures (consultation web, réception de flux de télévision ou de VoD). Lorsqu’un équipement se connecte sur internet, le routeur trace l’origine de la connexion pour lui transmettre par la suite les paquets retour venant d’internet.

Il n’existe cependant pas de standard pour mettre en œuvre la translation d’adresse. Chaque routeur invente son propre système, en fonction de sa perception de l’ergonomie et de la sécurité. Ça rend les choses plus compliquées.

Le principal obstacle, c’est l’adresse IP publique unique. Avec ce dispositif, même en connaissant l’adresse publique du participant, le serveur Jitsi ne peut se connecter directement au navigateur car la connexion est bloquée par la box internet qui ne sait vers quel équipement de la maison l’orienter. Ceux qui jouent sur internet connaissent le mécanisme UPnP pour contourner cette difficulté, mais il n’est pas utilisé par les navigateurs.

Il exploite le comportement habituel des box internet qui autorise les flux UDP entrant à condition qu’un flux correspondant sortant ait été envoyé auparavant, et tire avantage de la nature asymétrique des connexions à un serveur visible sur internet.

Dans la cinématique imaginée, le serveur Jitsi envoie au navigateur son adresse publique. De son côté, le navigateur ne connaît que son adresse locale, qui n’est pas routable sur internet et qui est donc théoriquement inutilisable. Mais il ne le sait pas et il va quand même tenter une connexion avec le serveur Jitsi.

Cette tentative va réussir : les paquets UDP sont envoyés à la box, qui va réaliser une translation d’adresse et transmettre le flux au serveur Jitsi. Au passage la box ouvre un canal UDP entre le navigateur et le serveur Jitsi.

La réponse UDP du serveur Jitsi va naturellement être envoyée à l’adresse source des paquets reçus, qui est l’adresse publique de la box. Cette dernière réceptionne les paquets et les reconnaît comme faisant partie du canal ouvert à l’aller. Elle les transmet au navigateur en faisant une translation inverse.

Il s’agit ici d’un comportement habituel en NAT UDP, le même que celui qui est en jeu pour les requêtes DNS.

Le problème, c’est que si des échanges se sont déroulés correctement, ils ne correspondent pas au test réalisé. On rappelle que le test du départ se faisait entre l’adresse locale du navigateur (192.168.1.32) et l’adresse du serveur Jitsi. Si ce dernier tente d’envoyer un flux, ce sera vers l’adresse locale 192.168.1.32, ce qui n’est pas possible.

C’est ici qu’ICE ruse en faisant en sorte de retrouver les conditions de départ qui correspondent aux échanges réalisés. Il suffit pour cela de considérer que le test n’a pas porté sur l’adresse locale du navigateur, mais sur son adresse publique translatée.

Or pour l’instant le navigateur ne connaît pas cette adresse. ICE profite du test pour la récupérer, en indiquant que le test de connectivité se fasse par une requête STUN. De ce fait, au retour du test, le navigateur récupère de la réponse STUN son adresse publique.

Il reste au navigateur à transmettre cette adresse publique au serveur Jitsi pour que tous les éléments entrent dans le cadre du test validé. Les échanges peuvent alors se faire correctement.

On n’a abordé ici que le cas IPv4. Le cas IPv6 est encore plus simple puisqu’il n’y a pas de translation en jeu. Le test de base entre adresses locales du navigateur et du serveur Jitsi fonctionne directement lorsqu’il est réalisé par le navigateur.

Serveur sur internet, accès en entreprise derrière un proxy

Lorsque les employés d’une entreprise participent à une conférence Jitsi hébergée sur internet, ils doivent souvent passer par un proxy web, qui assure essentiellement des fonctions de sécurité : authentification, interdiction des sites suspects, analyse de contenu.

Ce proxy est un nouvel obstacle aux connexions WebRTC, car il ne fait pas passer les flux UDP.
Le navigateur doit alors basculer en TCP, malgré les inconvénients que cela occasionne (souvent des retards rendant les conversations difficiles). Cette possibilité est prévue par WebRTC, sous la forme du protocole ICE TCP. Le serveur Jitsi se met en état passif, c’est-à-dire en attente d’une connexion TCP venant du navigateur.
Ce dernier initie une connexion active, qui se traduit par l’ouverture d’une connexion TCP. Comme cette connexion ne véhicule pas de HTTP, le navigateur lance une requête CONNECT auprès du proxy.

Pourtant dans la réalité, on se rend compte que la connexion ne passe pas toujours. On a par exemple relevé des reconnexions fréquentes (toutes les 30 secondes) rendant impossible la tenue d’une réunion.

L’expérience montre que l’utilisation d’un serveur TURN améliore la situation. Au départ la norme TURN avait été imaginée pour faciliter les communications WebRTC en poste à poste (P2P), en plaçant un serveur relais sur internet et passer d’une logique poste à poste à une logique client/serveur. Le serveur TURN agit comme un relais WebRTC auquel il est plus facile de se connecter. Il sait travailler en UDP, mais aussi en TCP et même en TCP chiffré par TLS. Il peut donc passer les proxy.

Comme le protocole ICE TCP est apparu après TURN et qu’il s’en inspire et l’améliore, on pensait au début que TURN serait inutile pour des conférences Jitsi.

Mais finalement il reste un élement important pour assurer une bonne connectivité. En observant le comportement réel des navigateurs, on s’est rendu compte qu’ICE TCP n’était que très peu utilisé. Pire, derrière un proxy, si le serveur TURN est arrêté, les connexions ne se font plus du tout et on ne voit pas de tentatives ICE TCP.

L’accès derrière un proxy présente sans conteste des défis majeurs pour Jitsi. On arrive cependant à assurer des conférences correctes, avec l’aide d’un serveur TURN complémentaire qui ne devrait pourtant théoriquement ne servir à rien.

Mettre toutes les chances de son côté 

Les protocoles en jeu dans WebRTC sont atypiques dans un internet résolument orienté HTTP. Il n’est donc pas surprenant de rencontrer des difficultés à les faire véhiculer.

Par rapport aux communications de poste à poste, l’utilisation de Jitsi présente un premier avantage en reproduisant un schéma client/serveur mieux toléré que le poste à poste.

L’expérience montre toutefois que cela ne résout pas tous les problèmes, car chaque équipement réseau (firewall, routeur, proxy) présente un nouveau défi.

On constate par expérience que les relais TURN, précieux en poste à poste mais théoriquement inutiles avec Jitsi, améliorent sensiblement la connectivité.

On aura donc intérêt à déployer toute la panoplie des méthodes pour rendre possible les connexions, et en particulier un serveur TURN qui aide les échanges UDP mais aussi TCP.

Auteur : Marc (Directeur technique)