Beaucoup de projets WebRTC fonctionnent parfaitement en démonstration, sur le réseau local du développeur, puis échouent mystérieusement en production : l’appel se connecte, mais aucun son ne passe entre deux utilisateurs situés sur des réseaux différents. La cause est presque toujours la même : l’absence de serveur TURN. Ce composant relaie le média quand une connexion directe est impossible, et il est tout simplement indispensable dès que vos utilisateurs ne sont pas sur le même réseau. Ce tutoriel déploie coturn, le serveur TURN open source de référence, de l’installation jusqu’au test, puis le branche sur vos clients WebRTC.
Prérequis
- Un serveur Ubuntu ou Debian avec une adresse IP publique fixe.
- Un nom de domaine pointant vers ce serveur (recommandé pour le TLS).
- Un certificat TLS valide si vous voulez du TURN chiffré (TURNS).
- Un accès root ou sudo en SSH.
- Niveau : avancé. Temps estimé : 45 minutes.
STUN, TURN : rappel de leur rôle
Deux serveurs auxiliaires aident WebRTC à franchir les réseaux. Un serveur STUN répond à une question simple : « quelle est mon adresse publique vue d’Internet ? ». Cette information permet souvent aux deux participants d’établir une connexion média directe, sans intermédiaire. STUN est léger : il ne fait que renseigner, il ne transporte aucune voix.
Mais quand les réseaux sont trop restrictifs — un pare-feu d’entreprise sévère, un NAT dit symétrique, un opérateur mobile contraignant — aucune connexion directe n’est possible. C’est là qu’intervient le serveur TURN, qui relaie tout le flux média entre les deux parties. Contrairement à STUN, TURN voit passer toute la voix, ce qui consomme de la bande passante sur le serveur et ajoute un peu de latence. C’est pourquoi il n’est utilisé qu’en dernier recours, quand le chemin direct échoue. La bonne nouvelle : coturn fait office à la fois de serveur STUN et de serveur TURN, un seul logiciel couvre les deux besoins.
Étape 1 — Installer coturn
coturn est packagé dans les dépôts officiels d’Ubuntu et Debian, l’installation est donc directe. On met à jour la liste des paquets puis on installe le serveur.
apt update
apt -y install coturn
Le paquet installe le démon turnserver ainsi que des utilitaires de test que nous emploierons plus loin. À ce stade, le service est installé mais désactivé par défaut : il faut explicitement l’autoriser à démarrer, ce qui est l’objet de l’étape suivante. Cette désactivation par défaut est volontaire, pour éviter qu’un serveur mal configuré ne s’expose accidentellement.
Étape 2 — Autoriser le démarrage du service
coturn ne démarre pas tant qu’on ne l’a pas explicitement activé dans son fichier d’options système. Éditez /etc/default/coturn et décommentez (ou ajoutez) la ligne qui active le démon.
TURNSERVER_ENABLED=1
Cette unique ligne indique au système que le service coturn doit être lancé. Sans elle, le démon refuse de démarrer même si tout le reste est correctement configuré — c’est une cause classique de « ça ne marche pas » chez les débutants. Une fois la ligne en place et le fichier sauvegardé, le service pourra être démarré après configuration.
Étape 3 — Configurer turnserver.conf
Le cœur de la configuration réside dans /etc/turnserver.conf. Voici une configuration de référence pour un usage WebRTC, que nous commenterons ensuite ligne par ligne.
listening-port=3478
tls-listening-port=5349
fingerprint
lt-cred-mech
realm=votre-domaine.com
server-name=votre-domaine.com
external-ip=VOTRE_IP_PUBLIQUE
min-port=49152
max-port=65535
user=turnuser:un_mot_de_passe_robuste
cert=/etc/coturn/cert.pem
pkey=/etc/coturn/privkey.pem
log-file=/var/log/turnserver.log
Détaillons. listening-port=3478 est le port standard du TURN non chiffré, et tls-listening-port=5349 celui du TURN chiffré (TURNS). L’option fingerprint ajoute une empreinte aux messages, attendue par WebRTC. lt-cred-mech active le mécanisme d’authentification à long terme, celui qu’exige WebRTC. Le realm est votre domaine, utilisé dans l’authentification. external-ip est crucial sur un serveur derrière un NAT ou chez un hébergeur : il indique l’adresse publique que coturn doit annoncer.
Les options min-port et max-port bornent la plage de ports que coturn utilisera pour relayer le média ; cette plage devra être ouverte dans le pare-feu. La ligne user définit un compte avec mot de passe pour l’authentification statique. Enfin, cert et pkey pointent vers votre certificat TLS et sa clé, nécessaires au TURN chiffré. Adaptez chaque valeur à votre environnement, en particulier l’IP publique et le domaine.
Étape 4 — Choisir le mode d’authentification
L’authentification mérite réflexion, car elle protège votre serveur d’un usage abusif : un TURN ouvert à tous serait exploité pour relayer du trafic tiers à vos frais. Deux approches existent. La première, l’authentification statique, utilise un couple identifiant/mot de passe fixe, déclaré par la ligne user ci-dessus. Simple, mais le secret est partagé et figé.
La seconde, recommandée en production, repose sur des identifiants temporaires : on remplace la ligne user par use-auth-secret et static-auth-secret=UN_SECRET. Le serveur applicatif génère alors, pour chaque session, des identifiants valables quelques minutes seulement, dérivés de ce secret partagé. Même interceptés, ils expirent vite et ne permettent pas un abus durable. C’est l’approche à privilégier dès que le service est exposé publiquement, car elle limite drastiquement la fenêtre d’exploitation en cas de fuite.
Étape 5 — Ouvrir les ports du pare-feu
coturn a besoin que plusieurs ports soient joignables depuis l’extérieur, sans quoi le relais ne fonctionne pas. Il faut autoriser les ports de signalisation TURN (3478 et 5349, en TCP et UDP) ainsi que toute la plage de relais média définie par min-port et max-port.
ufw allow 3478
ufw allow 5349
ufw allow 49152:65535/udp
Ces règles ouvrent les ports de contrôle et la plage de relais média en UDP. Si vous utilisez le pare-feu de votre hébergeur plutôt qu’ufw, appliquez la même logique dans son panneau. Oublier d’ouvrir la plage de ports média est l’erreur la plus fréquente : le serveur répond aux requêtes initiales mais ne peut pas relayer la voix, ce qui reproduit exactement le symptôme « appel connecté, pas de son » que TURN est censé résoudre.
Étape 6 — Démarrer et vérifier
Tout est en place : on active et on démarre le service, puis on confirme qu’il tourne.
systemctl enable coturn
systemctl restart coturn
systemctl status coturn
La première commande inscrit coturn au démarrage du système, la deuxième le lance avec la configuration, la troisième affiche son état. Vous devez voir le service « active (running) ». En cas d’échec, le journal défini par log-file ou la commande journalctl -u coturn révèle la cause — souvent une erreur de syntaxe dans la configuration ou un certificat introuvable.
Étape 7 — Tester le serveur TURN
Comment savoir si le TURN fonctionne réellement, sans monter toute une application ? L’outil de référence est la page de test « Trickle ICE » fournie par le projet WebRTC. On y saisit l’adresse de son serveur et ses identifiants, et la page indique si elle obtient des candidats de type « relay » — la preuve que le relais TURN répond.
Renseignez l’URL turn:votre-domaine.com:3478 avec l’identifiant et le mot de passe configurés, puis lancez la collecte de candidats. Si vous voyez apparaître des candidats marqués « relay », votre serveur TURN relaie correctement le média. Si seuls des candidats « host » ou « srflx » apparaissent, c’est que le TURN ne répond pas : revenez sur l’authentification ou l’ouverture des ports. coturn fournit aussi des utilitaires en ligne de commande, comme turnutils_uclient, pour un test plus technique depuis le serveur lui-même.
Étape 8 — Déclarer le TURN côté client WebRTC
Le serveur fonctionne, reste à indiquer à vos softphones WebRTC qu’ils doivent l’utiliser. Cela se fait via la liste des iceServers passée à la connexion WebRTC. On y déclare à la fois le serveur STUN et le serveur TURN avec ses identifiants.
const iceServers = [
{ urls: "stun:votre-domaine.com:3478" },
{
urls: "turn:votre-domaine.com:3478",
username: "turnuser",
credential: "un_mot_de_passe_robuste"
}
];
Cette liste est transmise à la configuration de la connexion WebRTC de votre client — que vous utilisiez JsSIP, SIP.js ou une autre bibliothèque, chacune offre un moyen de fournir ces iceServers. Une fois déclarés, les appels qui ne peuvent pas s’établir en direct basculeront automatiquement par le relais TURN, et le son passera enfin entre des utilisateurs situés sur des réseaux différents. C’est le chaînon qui fait la différence entre une démonstration locale et un service réellement utilisable partout.
Le certificat TLS et le TURN chiffré
Pourquoi se donner la peine de configurer le TURN chiffré (TURNS) sur le port 5349, alors que le TURN simple sur 3478 fonctionne déjà ? Pour deux raisons concrètes. D’abord, certains réseaux d’entreprise bloquent tout sauf le trafic chiffré sur les ports web : un TURN écoutant en TLS sur un port standard passe là où le TURN en clair serait filtré. Ensuite, le chiffrement protège la confidentialité de la signalisation de relais. Pour ces raisons, exposer le TURNS en plus du TURN classique élargit le nombre d’utilisateurs effectivement joignables.
Le certificat à utiliser est le même type que pour un site web : un certificat reconnu, idéalement émis gratuitement par une autorité comme Let’s Encrypt pour votre domaine. Une fois le certificat obtenu, les lignes cert et pkey de la configuration pointent vers les fichiers correspondants. Pensez au renouvellement : un certificat Let’s Encrypt expire tous les trois mois, et un certificat périmé fait silencieusement tomber le TURNS. Automatisez le renouvellement et prévoyez de recharger coturn après chaque renouvellement, faute de quoi le serveur continuera de présenter l’ancien certificat jusqu’à son redémarrage.
Dimensionner et surveiller le relais
Un serveur TURN se dimensionne d’abord sur la bande passante, pas sur le processeur. Chaque appel relayé consomme la bande passante de la voix dans les deux sens, multipliée par le nombre d’appels simultanés qui passent par le relais. Comme tous les appels n’empruntent pas le TURN — seuls ceux qui échouent en direct le font — la charge réelle est souvent inférieure au pire cas, mais il faut prévoir une marge confortable pour les heures de pointe.
Surveillez deux indicateurs. Le premier est le débit réseau du serveur : un relais saturé hache la voix de tous les appels qui transitent par lui. Le second est le journal de coturn, qui consigne les sessions de relais et révèle un usage anormal — un pic soudain de sessions peut trahir une exploitation par des tiers si l’authentification est trop permissive. Sur un déploiement qui grandit, envisagez de dédier le TURN à son propre serveur, distinct du PBX, afin que la charge de relais média n’empiète jamais sur le traitement des appels lui-même. Cette séparation des rôles est une bonne pratique d’architecture qui prend tout son sens à mesure que le trafic augmente.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| coturn ne démarre pas | TURNSERVER_ENABLED=1 absent |
Activer le service dans /etc/default/coturn |
| Pas de candidat « relay » | Authentification ou ports média fermés | Vérifier identifiants et ouvrir la plage min-port:max-port |
| Relais sans audio | Plage de ports UDP non ouverte au pare-feu | Autoriser 49152:65535/udp |
| TURN chiffré (TURNS) inopérant | Certificat ou clé introuvable | Corriger les chemins cert et pkey |
| Serveur exploité par des tiers | Authentification statique trop exposée | Passer aux identifiants temporaires (use-auth-secret) |
Tutoriels associés
- Côté serveur SIP : activer WebRTC sur Asterisk.
- Côté client : softphone JsSIP et client SIP.js.
Pour aller plus loin
- Retour au guide : Téléphonie IP avancée : 3CX, Issabel et softphones WebRTC.
- Documentation officielle : wiki coturn (turnserver) et guide TURN de WebRTC.org.
Questions fréquentes
STUN ne suffit-il pas ?
Non, pas dans tous les cas. STUN aide à établir une connexion directe, mais derrière certains réseaux restrictifs aucun chemin direct n’existe. Sans TURN pour relayer, ces appels échouent. En production, TURN est indispensable.
Le TURN consomme-t-il beaucoup de bande passante ?
Oui, car il relaie tout le média des appels qui passent par lui. Dimensionnez la bande passante du serveur en conséquence, mais rassurez-vous : seuls les appels qui ne trouvent pas de chemin direct l’utilisent réellement.
Faut-il un serveur dédié pour coturn ?
Pas obligatoirement, mais c’est recommandé en production pour isoler la charge réseau du relais. Pour un petit déploiement, coturn peut cohabiter avec d’autres services sur un serveur correctement dimensionné.
Authentification statique ou temporaire ?
Statique pour un test rapide ou un usage interne contrôlé ; temporaire (use-auth-secret) dès que le serveur est exposé publiquement, car les identifiants éphémères limitent fortement le risque d’exploitation par des tiers.