Comment fonctionne le protocole WebRTC ICE ? Guide clair et complet

WebRTC permet à deux navigateurs ou applications d’échanger de l’audio, de la vidéo ou des données en temps réel. Mais connaître l’adresse IP d’un correspondant ne suffit pas : les réseaux domestiques, mobiles et d’entreprise utilisent des NAT et des pare-feu. ICE (Interactive Connectivity Establishment) est le mécanisme qui découvre les chemins possibles, les teste, puis retient celui qui fonctionne. Normalisé notamment par la RFC 8445, il privilégie généralement UDP, adapté à la faible latence des communications interactives.

ICE dans WebRTC : résoudre la connexion entre deux pairs malgré les NAT

Un NAT traduit une adresse privée, telle que 192.168.x.x, en adresse publique. Il crée souvent une association temporaire lorsqu’un appareil émet un paquet, mais bloque une connexion entrante non sollicitée. Un pare-feu stateful applique une logique comparable : il autorise habituellement les réponses à un trafic sortant, sans ouvrir librement les ports. ICE ne contourne pas arbitrairement ces protections. Il coordonne les deux extrémités pour que chacune tente des chemins compatibles avec les règles réseau en vigueur. Son objectif est de sélectionner une paire d’adresses réellement joignable dans les deux sens, plutôt que de supposer qu’une adresse annoncée est accessible. Les médias WebRTC transitent le plus souvent sur UDP. Ce choix évite les retards induits par les retransmissions de TCP pour une conversation en direct. UDP n’est toutefois pas systématiquement disponible : certains environnements imposent TCP ou TLS. La différence entre ces transports est utile à replacer dans le fonctionnement de l’utilisation conjointe d’UDP et de TCP par DNS.

Les candidats ICE : adresses host, server-reflexive et relay

Un candidat ICE est une adresse de transport candidate : type, adresse IP, port, protocole et priorité. L’agent WebRTC rassemble plusieurs candidats, car un même appareil peut posséder des interfaces Wi-Fi, Ethernet, VPN ou IPv6. Les candidats sont ensuite associés en paires avec ceux du correspondant.

Type	Origine	Usage principal
host	Interface locale	Réseau local ou adressage directement atteignable
srflx	Serveur STUN	Adresse publique découverte à travers un NAT
relay	Serveur TURN	Relais lorsque les chemins directs échouent

Candidats host : la connexion directe sur le réseau local

Un candidat host correspond à l’adresse liée à une interface de l’équipement. Il est particulièrement efficace lorsque les deux pairs appartiennent au même LAN : la liaison peut rester locale, avec peu de latence et sans serveur de relais. Il peut aussi fonctionner avec une adresse publiquement routable, situation aujourd’hui moins fréquente côté client. Dans les anciens modèles de transport, ICE distinguait des composants pour RTP et RTCP. En WebRTC moderne, rtcp-mux fait circuler RTP et RTCP sur le même port, et BUNDLE regroupe plusieurs flux média dans une même association de transport. Cela réduit le nombre de candidats et de vérifications nécessaires.

Candidats srflx et relay : adresses publiques via STUN et TURN

Un candidat server-reflexive, ou srflx, est l’adresse et le port publics qu’un serveur STUN observe pour le client. Il peut permettre une connexion directe entre deux NAT compatibles. Cette adresse reste néanmoins dépendante du comportement du NAT ; elle n’est pas une ouverture permanente. Un candidat relay provient d’une allocation TURN. Le client réserve temporairement une adresse sur le relais, avec des autorisations pour transmettre les paquets au pair. Le trafic média passe alors par ce serveur. C’est moins direct, mais souvent indispensable derrière des pare-feu restrictifs ou des NAT symétriques.

Le déroulement d’une négociation ICE dans WebRTC

Collecter et échanger les candidats via le canal de signalisation

WebRTC ne définit pas le canal de signalisation. L’application échange donc l’offre et la réponse SDP par WebSocket, HTTP ou tout autre mécanisme. Le SDP porte notamment les paramètres média, les identifiants ICE ufrag et pwd, utilisés pour l’authentification à court terme des échanges STUN. Avec Trickle ICE, les candidats sont transmis au fil de leur découverte plutôt qu’après la collecte complète. La connexion peut ainsi commencer plus vite. Si la signalisation passe par une API depuis un navigateur, les règles de CORS dans les navigateurs doivent autoriser explicitement cette origine.

Tester les paires de candidats avec les contrôles de connectivité

Chaque candidat local est combiné avec les candidats distants compatibles : ce sont les paires de candidats. Elles composent une checklist ordonnée. ICE envoie des requêtes STUN Binding afin de vérifier que les paquets franchissent effectivement les NAT et pare-feu. La foundation regroupe des candidats issus de propriétés de collecte similaires ; elle aide à éviter des tests redondants. Une adresse découverte n’est donc jamais considérée comme valide avant un contrôle de connectivité réussi.

Sélectionner le meilleur chemin et maintenir la connexion

Lorsque plusieurs paires répondent, l’agent controlling nomme celle retenue ; l’agent controlled accepte cette nomination. Les flux audio, vidéo et données empruntent alors cette paire. Des contrôles périodiques contribuent à maintenir les traductions NAT et à détecter une perte de chemin.

Le rôle complémentaire des serveurs STUN et TURN

STUN : découvrir l’adresse visible depuis Internet

STUN est un service léger : il répond à une requête en indiquant l’adresse source observée. Il facilite la création de candidats srflx, mais ne relaie pas les médias et ne garantit pas qu’un pair pourra joindre cette adresse. Il faut des serveurs STUN accessibles, fiables et proches des utilisateurs, sans les confondre avec le canal de signalisation.

TURN : relayer les médias lorsqu’une liaison directe échoue

TURN fournit une solution de repli robuste. Il transporte les paquets entre les deux clients via son allocation, y compris lorsque les tests directs échouent. Comme les flux peuvent être volumineux, le relais augmente la consommation de bande passante et la latence ; son dimensionnement est donc critique. Les accès TURN doivent être protégés par des identifiants temporaires et par TLS lorsque le contexte l’exige. Ce chiffrement s’inscrit dans les principes du protocole TLS lors d’une connexion HTTPS, même si les usages et transports diffèrent.

Priorités, nomination et modes de fonctionnement d’ICE

Comment ICE privilégie les chemins directs et performants

Une priorité est attribuée aux candidats, puis aux paires. Elle favorise généralement les chemins directs et adaptés au transport choisi, sans empêcher TURN de servir de secours. ICE teste selon cet ordre, tout en tenant compte des réponses reçues. Le chemin gagnant est celui qui combine joignabilité vérifiée et priorité, non celui qui paraît le plus proche sur le papier.

ICE full, ICE lite et le redémarrage ICE en cas de changement réseau

Un agent ICE full collecte les candidats et exécute les vérifications complètes, comme un navigateur. ICE lite, fréquent sur certains serveurs, répond aux vérifications mais n’initie pas toute la procédure. En cas de bascule Wi-Fi vers mobile ou de changement d’adresse, un redémarrage ICE renouvelle ufrag, pwd et candidats pour établir une nouvelle connectivité.

Limites d’ICE et bonnes pratiques de déploiement WebRTC

ICE n’élimine ni les politiques réseau strictes ni le coût d’un relais. Une infrastructure fiable prévoit TURN, des identifiants éphémères, une supervision des échecs et des serveurs répartis géographiquement. Les éléments essentiels à vérifier sont :

• STUN et TURN redondants, avec UDP et, si nécessaire, des transports de secours ;
• des journaux séparant échec de signalisation, collecte de candidats et échec de connectivité ;
• la mesure de l’usage TURN, indicateur d’environnements où le pair à pair ne passe pas ;
• un redémarrage ICE déclenché lors d’un changement réseau détecté.

Une connexion de secours sur TCP peut nécessiter de comprendre le handshake TCP en trois étapes. Enfin, DNS peut participer à la découverte de services dans certaines architectures ; les enregistrements DNS SRV constituent alors un mécanisme de localisation, distinct d’ICE lui-même.

Questions fréquentes

ICE chiffre-t-il les flux audio et vidéo ?

ICE ne chiffre pas les médias : il choisit leur chemin réseau. Dans WebRTC, le chiffrement des flux repose sur DTLS-SRTP, tandis qu’ICE sécurise les vérifications de connectivité avec des identifiants temporaires. Un chemin direct ou relayé ne modifie donc pas l’exigence de chiffrement des communications.

Pourquoi une session peut-elle rester bloquée sur « connecting » ?

Un blocage indique souvent qu’aucune paire de candidats n’a validé les tests de connectivité. Les causes possibles incluent des candidats non échangés par la signalisation, un serveur TURN indisponible, des identifiants expirés ou un filtrage réseau. Les événements ICE du navigateur permettent d’isoler l’étape précise en échec.

Les adresses IP locales sont-elles exposées à l’autre participant ?

Les navigateurs limitent cette exposition en utilisant fréquemment des adresses mDNS pour les candidats host. L’adresse locale réelle n’est alors pas directement communiquée dans la signalisation. Ce comportement dépend toutefois du navigateur, des permissions et du contexte réseau ; il ne remplace pas les protections de confidentialité globales de l’application.

Un serveur TURN est-il obligatoire pour une application WebRTC ?

Il n’est pas obligatoire pour établir toutes les communications, car STUN et les candidats directs suffisent dans certains réseaux. Il est néanmoins fortement recommandé en production : sans relais, les utilisateurs placés derrière des NAT ou pare-feu incompatibles ne pourront pas se joindre. TURN assure la continuité de service lorsque le pair à pair échoue.

Comment savoir si une communication passe par TURN ?

Les statistiques WebRTC et les outils de diagnostic du navigateur indiquent généralement le type de paire sélectionnée. Une paire marquée « relay » signifie que les médias transitent par TURN. Cette information aide à surveiller les coûts réseau et à détecter des environnements où les connexions directes sont fréquemment bloquées.

Le point à retenir pour des appels fiables

La mise en relation temps réel ne dépend pas seulement des navigateurs : elle doit s’adapter aux adresses privées, aux traductions NAT et aux règles de filtrage rencontrées par chaque participant. ICE apporte cette capacité d’adaptation en comparant plusieurs chemins plutôt qu’en imposant une route unique. La liaison directe reste préférable lorsqu’elle est validée, mais un relais TURN garantit la continuité lorsque le réseau l’exige. Pour une application robuste, il faut donc traiter la signalisation, STUN et TURN comme des composants complémentaires, surveiller les échecs de connectivité et prévoir le renouvellement du chemin après un changement de réseau. La fiabilité perçue par l’utilisateur repose surtout sur cette préparation invisible.