Serveurs STUN et TURN : ce qu’il faut à un appel vidéo pour se connecter

Un appel vidéo dans le navigateur semble devoir être simple. WebRTC envoie l’audio et la vidéo directement d’un appareil à l’autre, sans serveur au milieu. Puis vous le testez en dehors de votre propre réseau, et certains appels sonnent, sont décrochés, puis restent muets, l’écran noir. La plupart du temps, le code est correct. Ce qui manque, c’est un serveur STUN, un serveur TURN, ou les deux.

Cet article explique ce que fait chacun d’eux, pourquoi un appel en a besoin, ce qu’il faut pour faire tourner votre propre serveur TURN, et que faire des appels que même un relais ne parvient pas à connecter.

Pourquoi deux appareils ne peuvent pas simplement se connecter

Presque aucun appareil sur Internet n’a sa propre adresse publique. Un ordinateur portable à la maison se trouve derrière un routeur, un téléphone derrière son opérateur, et un ordinateur au bureau derrière un pare-feu. Chacun ne connaît que son adresse privée, comme 192.168.1.23, qui ne veut rien dire à l’autre bout de l’appel.

Avant qu’un appel puisse commencer, chaque appareil doit découvrir comment joindre l’autre, et les deux doivent essayer ces chemins jusqu’à ce que l’un fonctionne. WebRTC s’en charge avec ICE, qui rassemble des adresses candidates pour chaque appareil et les teste par paires. Une partie de ces candidates vient de STUN et de TURN.

Ce que fait un serveur STUN

Un serveur STUN répond à une seule question : « quelle est mon adresse, telle que vous la voyez ? » Un appareil lui envoie une petite requête, et le serveur répond avec l’adresse publique et le port d’où vient cette requête. L’appareil ajoute cette adresse à ses candidates, l’autre appareil l’essaie, et sur la plupart des réseaux domestiques l’appel se connecte directement.

STUN est peu coûteux. Il voit passer quelques petits paquets au début d’un appel et plus rien ensuite, si bien qu’un seul serveur STUN peut servir un très grand nombre d’appels, et il existe des serveurs publics que chacun peut utiliser. Quand un chemin direct existe, STUN suffit à un appel.

Ce que fait un serveur TURN

Parfois, aucun chemin direct n’existe. Un pare-feu strict ne laisse rien entrer, un opérateur mobile donne à un téléphone un port public différent pour chaque nouvelle destination, ou un réseau d’entreprise n’autorise que le trafic web. L’adresse renvoyée par STUN ne fonctionne pas pour l’autre appareil, et l’appel échoue.

Un serveur TURN est un relais pour ces appels. Les deux appareils ouvrent une connexion sortante vers lui, et il fait passer leur audio et leur vidéo de l’un à l’autre. Comme les appareils n’ouvrent que des connexions sortantes, ce que presque tous les réseaux autorisent, l’appel passe là où un appel direct ne passe pas.

Le relais a un coût que STUN n’a pas : chaque seconde d’audio et de vidéo le traverse, dans les deux sens, pendant toute la durée de l’appel. Un appel vidéo en tête-à-tête peut y faire passer plusieurs mégabits par seconde. C’est pourquoi il existe des serveurs STUN publics, mais aucun serveur TURN gratuit sur lequel compter : un relais ouvert à tous se retrouve vite à transporter du trafic que son propriétaire n’a jamais voulu transporter, puis il est fermé ou placé derrière des identifiants.

Faire tourner votre propre serveur TURN

Il existe des serveurs TURN open source qui fonctionnent bien, et beaucoup d’équipes commencent par là. Ce qu’il faut :

• Un serveur avec une adresse publique et beaucoup de bande passante, proche de vos utilisateurs. Un relais sur un autre continent ajoute un décalage qui s’entend.
• Les bons ports. Le port habituel est le 3478, en UDP et en TCP. Pour les réseaux qui n’autorisent que le trafic web, le relais doit aussi répondre sur le port 443 avec TLS, ce qui veut dire un certificat pour son nom, renouvelé à temps.
• Des identifiants qui expirent. Un serveur TURN ne devrait jamais accepter un nom d’utilisateur et un mot de passe fixes, visibles dans votre page, que n’importe qui peut copier. La méthode habituelle est un secret partagé entre votre application et le relais : votre serveur crée pour chaque appel un nom d’utilisateur et un mot de passe qui cessent de fonctionner au bout d’un moment.
• Plusieurs relais, à mesure que vous grandissez. Avec un seul relais, tous les appels peuvent échouer au même endroit. Les utilisateurs d’autres régions en veulent un près de chez eux, et chacun demande de la surveillance, des mises à jour et de la marge pour grandir.
• Des tests depuis de vrais réseaux. Un relais qui fonctionne depuis votre bureau peut échouer depuis un téléphone sur le réseau d’un opérateur mobile ou depuis un ordinateur portable sur le Wi-Fi d’un hôtel. Testez depuis les réseaux qu’utilisent vos utilisateurs.

Rien de tout cela n’est difficile, mais c’est un service à faire tourner tant que votre application propose des appels.

Quand même TURN ne peut pas connecter un appel

Un relais règle la plupart des appels qui échouent, mais pas tous. Certains réseaux bloquent l’UDP que le relais préfère, et certains perturbent les longues connexions, même sur le port 443. Pour ceux-là, un appel peut aller un cran plus loin, dans une salle sur un serveur multimédia, le genre de serveur sur lequel tournent les appels de groupe. Les deux personnes envoient alors leur flux au serveur multimédia et reçoivent de lui celui de l’autre, un chemin qui tient bon sur des réseaux où tout média en pair-à-pair, quel qu’il soit, a du mal à passer.

Un appel qui ne peut basculer là qu’après avoir échoué raccrocherait d’abord. Le mieux est de garder l’appel en cours pendant qu’il change de chemin, pour que les personnes qui y participent ne remarquent qu’un court instant figé, et non un appel coupé.

Comment WordPlus Cloud connecte les appels

WordPlus Cloud fait tourner les trois chemins, et un appel entre deux personnes se connecte donc toujours, quel que soit le réseau :

1. Directement, entre les deux appareils, sur la plupart des réseaux. Le chemin le plus rapide.
2. Via nos relais, quand un pare-feu bloque le chemin direct. Ils répondent sur les ports du web, 443 et 80, ainsi que sur le 3478, et un appel passe ainsi partout où passent les sites web. Chaque personne de chaque appel reçoit ses propres identifiants de relais, qui expirent au bout de quelques heures, pour que personne ne puisse utiliser les relais en dehors de vos appels.
3. Via nos serveurs multimédias, quand même les relais ne peuvent pas transporter l’appel. Il y bascule et continue, sans raccrocher.

Les appels sont chiffrés de bout en bout sur chaque chemin, avec une clé que seul votre serveur distribue, si bien que les relais et les serveurs multimédias transportent ce qu’ils ne peuvent pas lire. Les appels entre deux personnes sont inclus dans chaque formule, relayés ou non. C’est toujours votre serveur qui décide qui peut appeler qui, et le cloud applique sa décision.

Cela fonctionne de la même façon dans Better Messages sur WordPress et dans vos propres applications, depuis Next.js, Laravel, Django et d’autres piles, avec nos SDK. La page Appels vidéo et appels de groupe pour votre application montre ce que vous apportent les SDK, et la page Comment fonctionnent les appels de notre documentation montre le code.