STUN vs TURN vs ICE : faire fonctionner WebRTC derrière des firewalls d’entreprise
Le rôle exact de STUN, TURN et ICE dans WebRTC, et pourquoi la capacité TURN devient critique dans les réseaux enterprise.
WebRTC promet de l’audio et de la vidéo peer-to-peer directement dans le navigateur, mais l’internet réel est rempli de NATs, de routeurs restrictifs et de firewalls d’entreprise. Deux peers ne peuvent pas simplement échanger leurs adresses IP et espérer que le média circule.
ICE, ou Interactive Connectivity Establishment, est le framework de négociation chargé de trouver le meilleur chemin possible entre deux peers. Il orchestre la collecte des candidats et les tests de connexion afin que WebRTC s’adapte à des environnements réseau complexes.
STUN est l’aide légère dans ce processus. Un client demande à un serveur STUN de révéler son IP publique et son port public, puis partage cette information avec le peer distant. Lorsque le NAT est suffisamment permissif, cela suffit pour établir une connexion directe.
TURN existe pour les cas plus difficiles. Dans des réseaux d’entreprise stricts ou derrière des NATs symétriques, une connexion directe peut ne jamais aboutir même si chaque peer connaît son identité publique. Dans ce cas, ICE bascule vers un relais TURN qui reçoit le flux d’un côté et le retransmet à l’autre.
Ce fallback est ce qui rend WebRTC viable en environnement enterprise, mais il modifie aussi complètement le modèle de coût. STUN est léger, tandis que TURN consomme réellement de la bande passante et de l’infrastructure puisqu’il relaie le média.
La leçon pratique consiste à optimiser d’abord les connexions peer-to-peer, tout en dimensionnant la production comme si une part significative des appels allait nécessiter TURN. Sans une infrastructure TURN solide, WebRTC fonctionne très bien en démo et échoue précisément là où les clients enterprise en ont le plus besoin.