STUN et TURN : traverser NAT et pare-feu en WebRTC
Réponse courte
STUN (Session Traversal Utilities for NAT) permet à un client WebRTC de découvrir son adresse publique et de tenter une connexion directe. TURN (Traversal Using Relays around NAT) relaye les flux média quand le direct est impossible : cas fréquent derrière un pare-feu d'entreprise ou un NAT symétrique. Ensemble, ils alimentent le protocole ICE (Interactive Connectivity Establishment), qui choisit automatiquement le chemin réseau le plus performant.
Pourquoi NAT et pare-feu posent problème en WebRTC ?
WebRTC vise une connexion directe entre navigateurs ou vers un SFU. Or, la plupart des postes d'entreprise et des box domestiques se trouvent derrière un NAT (Network Address Translation) ou un pare-feu qui filtre les connexions entrantes.
Sans mécanisme de traversée, deux participants ne peuvent pas s'établir mutuellement : d'où l'échec fréquent des démos « ça marche chez moi, pas chez le client ». STUN et TURN résolvent ce problème à des niveaux différents : découverte d'adresse pour l'un, relais de secours pour l'autre.
Qu'est-ce que STUN ?
STUN est un serveur léger qui répond à une requête client : « quelle est mon adresse IP publique et mon port ? ». Le client WebRTC utilise cette information pour négocier une connexion directe avec l'autre participant ou avec le SFU.
- Charge serveur : minimale (requêtes courtes, pas de flux média) ;
- Ne transporte pas la vidéo ni l'audio ;
- Suffisant quand les deux parties ont des NAT « permissifs » ;
- Insuffisant seul en environnement corporate ou avec NAT symétrique.
STUN est une brique nécessaire, rarement suffisante en production B2B.
Qu'est-ce que TURN ?
TURN est un relais média : quand la connexion directe échoue (pare-feu strict, NAT symétrique, UDP bloqué), les flux audio et vidéo passent par le serveur TURN.
- Consomme de la bande passante serveur (upstream + downstream par participant) ;
- Indispensable en B2B pour les invités externes, télétravailleurs et réseaux corporate ;
- Doit supporter UDP et TCP/TLS (certains réseaux bloquent l'UDP) ;
- Composant sensible pour la souveraineté : les flux transitent par le relais.
→ Contexte architecture : architecture vidéo.
STUN vs TURN : comparaison
| STUN | TURN | |
|---|---|---|
| Rôle | Découverte d'adresse publique | Relais de flux média |
| Transporte la vidéo | Non | Oui |
| Bande passante serveur | Négligeable | Élevée en mode relais |
| Latence ajoutée | Aucune | 1 hop serveur (variable) |
| Obligatoire en prod B2B | Recommandé | Quasi obligatoire |
| Localisation critique | Non | Oui (résidence des flux) |
| Impact sur le DPA | Faible | Élevé |
Comment ICE utilise STUN et TURN ?
Le protocole ICE teste plusieurs « candidats » réseau, dans un ordre de priorité :
- Host : adresse locale du poste (LAN) ;
- Server reflexive (via STUN) : adresse publique découverte ;
- Relay (via TURN) : relais serveur quand le direct échoue.
ICE sélectionne le couple avec la connectivité confirmée et la latence la plus faible. L'utilisateur ne choisit rien : le navigateur bascule automatiquement. Pour la DSI, l'enjeu est de s'assurer que tous les candidats nécessaires sont disponibles et documentés.
Déroulé typique d'une connexion WebRTC
- Signalisation (HTTPS/WSS) : échange SDP, création de session ;
- Collecte ICE : le client interroge STUN, obtient des credentials TURN ;
- Tests de connectivité : ICE vérifie chaque candidat (host, reflexive, relay) ;
- Sélection : le meilleur chemin est retenu (direct si possible, TURN sinon) ;
- Transport chiffré : les flux média passent en DTLS-SRTP, quel que soit le chemin.
Un échec à l'étape 3–4 se traduit par un appel qui ne démarre pas, ou une session dégradée (audio seul, vidéo figée).
NAT symétrique et pare-feu corporate : cas fréquents
| Situation réseau | Comportement | Solution |
|---|---|---|
| NAT permissif (box domestique) | Connexion directe souvent possible | STUN suffit parfois |
| NAT symétrique (box 4G, certains FAI) | Le port public change à chaque connexion | TURN obligatoire |
| Pare-feu bloquant UDP | ICE direct échoue | TURN en TCP/TLS |
| Proxy HTTP strict | Signalisation OK, média bloqué | TURN documenté + ports autorisés |
| VPN corporate | Routes modifiées, latence variable | Tester en conditions réelles |
Sans TURN correctement déployé et documenté, le taux d'échec de connexion en environnement corporate peut dépasser 30 %. Un pilote sur poste pare-feu + 4G reste indispensable avant un déploiement généralisé.
Exigences réseau pour la DSI
Un éditeur infrastructure doit fournir un guide pare-feu complet :
- FQDN et plages IP des serveurs STUN et TURN ;
- Ports UDP (3478, plages RTP dynamiques) et TCP fallback (443, 5349) ;
- Procédure de test connectivité (poste corporate, 4G, VPN) ;
- Localisation des relais TURN (France, on-premise, zones géographiques) ;
- Durée de vie des credentials TURN et mécanisme de renouvellement ;
- Capacité TURN dimensionnée pour le volume de sessions en relais.
Ne pas se contenter d'autoriser le domaine du portail web : les flux média passent par des hôtes distincts.
Ce que la DSI doit exiger de l'éditeur
Avant de valider une architecture réseau WebRTC, demandez :
- Schéma d'architecture : signalisation, STUN, TURN, SFU, monitoring ;
- Guide pare-feu testable par votre équipe réseau ;
- Pourcentage de sessions en relais TURN attendu pour votre profil d'usage ;
- Redondance : plusieurs nœuds TURN, bascule automatique ;
- Localisation contractuelle des relais (DPA, sous-traitants) ;
- Métriques ops : taux d'échec ICE, latence par type de candidat, bande passante TURN.
Sans guide pare-feu, la responsabilité des échecs de connexion reste floue entre l'éditeur et la DSI.
TURN et souveraineté
Les flux TURN transitent par le serveur relais : composant critique pour la résidence des données et le cadrage RGPD.
| Modèle | Cas d'usage | Point d'attention |
|---|---|---|
| Cloud France / UE | Déploiement standard B2B | Vérifier la localisation réelle des relais, pas seulement du portail |
| On-premise | Secteurs réglementés, politiques IT strictes | Dimensionner bande passante et redondance |
| Hybride | Internes + invités externes | Relais TURN proche des participants concernés |
Points de vigilance :
- Cadrer contractuellement les relais TURN dans le DPA ;
- Ne pas confondre « page web hébergée en France » et « relais média en France » ;
- Documenter la chaîne de sous-traitants pour le DPO.
Voir hébergement France et cloud souverain vidéo.
Dimensionner le TURN
Le TURN consomme de la bande passante indépendamment du SFU :
- En relais, le serveur reçoit et renvoie chaque flux (double transit) ;
- Le volume dépend du nombre de sessions en mode relay, pas du nombre total de sessions ;
- Prévoir du TCP fallback si l'UDP est bloqué (latence plus élevée) ;
- Redondance multi-zones pour la résilience.
Les ordres de grandeur et stratégies de cluster sont détaillés sur scalabilité WebRTC.
Symptômes d'un TURN mal configuré
| Symptôme | Diagnostic probable |
|---|---|
| OK en 4G, échec en Wi-Fi bureau | TURN absent ou pare-feu bloquant |
| Un seul sens audio/vidéo | ICE partiel, candidats incomplets |
| Connexion puis coupure après quelques minutes | Credentials TURN expirés, timeout |
| OK en pilote, échec en production | TURN non déployé ou non dimensionné en prod |
| Qualité dégradée pour certains invités uniquement | Relais TURN éloigné géographiquement |
| Latence élevée pour tous | Tout passe en relais TURN TCP (UDP bloqué) |
→ Impact latence : latence vidéo.
STUN/TURN et SFU : rôles distincts
Ne pas confondre connectivité et distribution :
- STUN/TURN = couche ICE : établir le chemin réseau (NAT, pare-feu) ;
- SFU = couche média : distribuer les flux en réunion multi-participants.
Un participant rejoint le SFU via une connexion directe ou un relais TURN. Les deux composants doivent être dimensionnés et documentés séparément. Avec la signalisation, ils forment l'infrastructure collaborative WebRTC complète.
Chiffrement et sécurité
- STUN : requêtes légères, pas de flux média ;
- TURN : supporte TURN over TLS pour le canal de contrôle ;
- Flux média WebRTC : chiffrés en DTLS-SRTP, quel que soit le chemin (direct ou relais).
Le relais TURN ne déchiffre pas le contenu média dans une architecture standard : il route des paquets chiffrés. Vérifier ce point avec l'éditeur si la sécurité l'exige.
Comment Leagora documente STUN/TURN ?
Leagora fournit schéma d'architecture, guide pare-feu et localisation des relais pour les déploiements France ou on-premise. La plateforme vidéo combine STUN, TURN, SFU et API vidéo sur des composants open source auditable.
Les produits métier s'appuient sur cette infrastructure : assistance-video.fr, meeting.leagora.io, mes-rdv.fr, assistance.leagora.io.
FAQ
STUN suffit-il en entreprise ?
Rarement seul. En B2B, TURN est quasi obligatoire pour les invités derrière pare-feu, NAT symétrique et réseaux filtrés.
TURN consomme-t-il beaucoup de bande passante ?
Oui, quand les flux passent en relais : le serveur reçoit et renvoie chaque paquet. Dimensionner TURN fait partie intégrante du contrat infrastructure, distinct du dimensionnement SFU.
Faut-il autoriser l'UDP ?
Idéalement oui pour la latence optimale. Si l'UDP est bloqué, le TURN doit supporter TCP/TLS : vérifier avec l'éditeur et tester en conditions réelles.
Où héberger les serveurs TURN ?
Même politique que le SFU : France, on-premise ou cloud souverain selon votre DPA. La localisation des relais TURN est plus critique que celle du STUN.
STUN et TURN sont-ils chiffrés ?
Le contrôle TURN peut passer en TLS. Les flux média WebRTC restent chiffrés en DTLS-SRTP sur tous les chemins ICE.
Comment tester la connectivité avant un déploiement ?
Exiger une procédure de test documentée : poste corporate derrière pare-feu, connexion 4G, VPN, partage d'écran. Mesurer le taux de sessions en relais TURN et la latence associée.
TURN et RGPD : quelles données transitent ?
Les flux média chiffrés transitent par le relais. Les métadonnées de session (adresses IP, timestamps) peuvent être journalisées : cadrer la rétention dans le DPA.
À retenir
- STUN = découverte d'adresse ; TURN = relais de secours indispensable en B2B.
- ICE combine les deux automatiquement : l'utilisateur ne choisit pas le chemin.
- NAT symétrique et pare-feu corporate = TURN quasi systématique.
- Exiger un guide pare-feu, une localisation documentée et des tests réseau réels en pilote.
- TURN ≠ SFU : connectivité réseau vs distribution média ; dimensionner les deux séparément.
Aller plus loin
- WebRTC : socle technique de l'infrastructure vidéo temps réel
- SFU WebRTC : distribution média multi-participants
- Scalabilité WebRTC : dimensionner TURN et SFU ensemble
- Architecture vidéo : signalisation, ICE, API et authentification
Demander un devis
Pour un cadrage pare-feu, TURN, SFU et architecture réseau : demander un devis.