ICE Candidate : définition, types de candidats et fonctionnement

Qu’est-ce qu’un ICE Candidate ?

ICE Candidate (Interactive Connectivity Establishment Candidate) est une unité fondamentale dans le processus d’établissement de connexion P2P via le protocole WebRTC. Il représente une paire adresse IP + port qui peut être utilisée pour transmettre des données entre deux pairs. Chaque candidat contient des informations sur le protocole de transport (UDP, TCP), le type de connexion et la priorité.

L’ICE Candidate est formé sur chaque périphérique séparément. Le périphérique collecte toutes les interfaces réseau disponibles, demande l’adresse externe via un serveur STUN et ajoute l’adresse relais du serveur TURN. La liste de candidats obtenue est envoyée au pair distant via le canal de signalisation au format SDP (Session Description Protocol).

Selon la spécification RFC 8445 (IETF, 2018), ICE utilise le mécanisme des paires nommées (nominated pairs) : après la collecte de tous les candidats, un test par paire est effectué via des requêtes STUN. La paire qui réussit la vérification en premier est déclarée nommée (nominated) et utilisée pour la transmission multimédia. Les autres paires restent en réserve en cas de rupture de connexion.

Rôle d’ICE dans la pile WebRTC

WebRTC est un standard ouvert pour les communications P2P, mais la connexion directe entre périphériques est souvent impossible en raison du NAT (Network Address Translation) et des pare-feu. ICE Candidate résout ce problème en proposant plusieurs chemins de connexion alternatifs. Le protocole ICE (Interactive Connectivity Establishment) est un composant obligatoire de WebRTC et est décrit dans la spécification W3C WebRTC (2025).

De nombreux développeurs d’applications mobiles utilisent des bibliothèques WebRTC telles que Google WebRTC (pour Android) et les wrappers natifs pour iOS. Dans chacune d’elles, le processus ICE est géré automatiquement, mais la compréhension des types de candidats permet au développeur de configurer l’infrastructure serveur et d’optimiser la qualité de la connexion.

Format SDP avec candidats ICE

L’ICE Candidate est transmis dans un message SDP sous forme d’attributs a=candidate. Chaque ligne contient le fondement (foundation), l’ID de composant, le protocole de transport, la priorité, l’adresse IP, le port et le type de candidat. Voici un exemple de fragment SDP avec trois candidats de types différents :

// Échantillon SDP avec candidats ICE
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

Le champ priority détermine l’ordre de test des candidats. Plus la priorité est élevée, plus le candidat sera vérifié tôt. Les candidats host ont toujours la priorité la plus élevée, relay la plus faible.

Types de candidats ICE

La spécification RFC 8445 définit quatre types de candidats ICE, chacun correspondant à une manière spécifique d’atteindre le pair distant. Le type de candidat influence sa priorité, le temps d’établissement de la connexion et les exigences d’infrastructure serveur.

Candidats host

Un candidat host est formé à partir de l’adresse IP de l’interface réseau locale du périphérique. Si le périphérique se trouve dans le même réseau local que le pair, le candidat host assure une connexion directe avec une latence minimale. Pour les périphériques mobiles, les candidats host sont générés pour l’interface WiFi, la connexion cellulaire LTE/5G et, si nécessaire, pour les tunnels VPN.

Les candidats host ont la priorité la plus élevée (2130706431 pour UDP) et sont testés en premier. Si les deux pairs sont derrière un NAT, leurs candidats host seront des adresses privées (192.168.x.x, 10.x.x.x) et la connexion directe via celles-ci est impossible. ICE passe alors au test des candidats srflx et relay.

Candidats SRFLX et PRFLX

Un candidat SRFLX (Server Reflexive) est une adresse IP externe et un port obtenus du serveur STUN. Lorsque le périphérique envoie une requête STUN, le serveur voit son adresse publique après le NAT et la retourne. Ce candidat permet d’établir une connexion directe entre des pairs derrière différents NAT si leurs dispositifs NAT prennent en charge le Hairpinning.

Un candidat PRFLX (Peer Reflexive) est détecté dynamiquement lorsqu’une requête STUN d’un pair arrive sur une adresse inattendue. Ce type apparaît lorsque les deux pairs envoient des requêtes simultanément et que le NAT crée une liaison temporaire. Le candidat PRFLX a une priorité plus élevée que srflx mais plus faible que host.

Dans les applications mobiles, les candidats srflx sont particulièrement importants lors du basculement entre WiFi et réseau cellulaire. Lorsque le périphérique change de réseau, l’adresse IP change et ICE doit recollecter les candidats. Ce processus s’appelle ICE restart et nécessite le renvoi d’un nouveau SDP.

Candidats relay via TURN

Un candidat relay est une adresse sur le serveur TURN par laquelle le trafic est relayé d’un pair à l’autre. Ce type est utilisé comme option de secours lorsque la connexion P2P directe est impossible (NAT symétrique, pare-feu d’entreprise). Le canal relay ajoute une latence et augmente la charge du serveur, donc dans une configuration optimale, le serveur TURN n’est utilisé que pour 10 à 15 % de toutes les sessions.

Implémentations populaires de serveurs TURN : coturn (open source), Twilio Network Traversal, Metered TURN. Le choix du fournisseur TURN influence la qualité de la connexion média dans les applications mobiles : le serveur doit être géographiquement proche des utilisateurs pour minimiser la latence supplémentaire.

Comment fonctionne le processus ICE

Le processus ICE est un protocole en plusieurs étapes qui garantit l’établissement d’une connexion P2P fiable dans des conditions d’incertitude de la topologie réseau. L’algorithme est décrit dans la RFC 8445 et comprend quatre phases obligatoires : collecte des candidats, leur tri, leur test et leur nomination.

Phase 1 : collecte des candidats

Chaque périphérique collecte toutes les adresses réseau disponibles. Pour ce faire, le moteur WebRTC énumère les interfaces locales (host), envoie une requête au serveur STUN (srflx) et demande une adresse relay au serveur TURN. Simultanément, le périphérique peut détecter un candidat prflx s’il reçoit une requête STUN entrante du pair.

Dans le développement mobile, cette étape est cruciale pour le temps d’établissement de la connexion. Sur iOS et Android, la collecte des candidats peut prendre de 200 ms à 2 secondes selon la vitesse du réseau, la disponibilité des serveurs STUN/TURN et le nombre d’interfaces réseau actives.

Phase 2 : formation des paires et tri

Après réception de la liste de candidats du pair distant via le canal de signalisation, le moteur ICE local forme toutes les paires de candidats possibles (local + distant). Chaque paire reçoit une priorité selon la formule de la RFC 8445, tenant compte des priorités des deux candidats et de la direction (entrante/sortante).

Les paires sont triées par ordre décroissant de priorité. Les meilleures paires sont testées en premier. L’algorithme garantit que la paire host-host sera vérifiée avant host-srflx, host-relay ou relay-relay, minimisant ainsi la latence de connexion dans les configurations réseau simples.

Phase 3 : test et nomination

ICE envoie des requêtes STUN-binding pour chaque paire de candidats. Si une réponse STUN est reçue, la paire est valide. La première paire valide est nommée (nominated) comme principale. Le moteur WebRTC commence à transmettre les médias via cette paire, tandis que les autres paires continuent d’être vérifiées en cas de défaillance de la principale.

Le processus de test peut prendre plusieurs secondes avec un grand nombre de candidats. WebRTC utilise des minuteurs : pour les paires host, le minuteur est agressif (20 ms), pour relay, plus conservateur (200 ms). Les développeurs d’applications mobiles peuvent accélérer la connexion en limitant le nombre de serveurs ICE ou en configurant iceTransportPolicy.

ICE Restart

ICE restart est le redémarrage du processus ICE sans recréer l’intégralité du RTCPeerConnection. Il est nécessaire en cas de changement de réseau, de perte de connexion ou de basculement entre WiFi et réseau mobile. Lors du restart, tous les candidats actuels sont réinitialisés et le processus recommence avec la génération d’un nouvel ufrag et pwd.

Dans le développement iOS, ICE restart est déclenché par la méthode restartIce() sur RTCPeerConnection. Sur Android, une méthode similaire est utilisée dans la classe PeerConnection de Google WebRTC. La gestion correcte d’ICE restart est une exigence critique pour les applications fonctionnant sur des périphériques mobiles avec une connexion réseau instable.

Serveurs STUN et TURN dans ICE

STUN (Session Traversal Utilities for NAT) et TURN (Traversal Using Relays around NAT) sont des composants serveur clés sans lesquels ICE Candidate ne peut garantir une connexion réussie dans des conditions Internet réelles. Leur configuration correcte influence directement la qualité des appels dans les applications mobiles.

STUN : détection de l’adresse externe

Le serveur STUN permet au périphérique de connaître son adresse IP publique et le port que le NAT a alloué pour la connexion sortante. Le protocole STUN est défini dans la RFC 8489 et fonctionne sur UDP au port 3478, et prend également en charge TCP. Google fournit des serveurs STUN publics (stun.l.google.com:19302) utilisables gratuitement.

Dans le développement mobile, une requête STUN est une opération légère prenant 50 à 200 ms. Cependant, certains réseaux d’entreprise et mobiles bloquent le trafic UDP, forçant ICE à utiliser TCP pour la communication STUN ou à passer directement à TURN.

TURN : relais de trafic

Un serveur TURN est un relais de trafic média. Lorsque la connexion P2P directe est impossible (NAT symétrique, pare-feu), le périphérique envoie les données à TURN qui les transfère à l’autre pair. TURN est un mécanisme fiable mais coûteux : il ajoute une latence (30 à 100 ms) et nécessite une bande passante serveur égale à la somme de toutes les sessions média.

Selon le WebRTC Stats Report (2025), environ 8 à 15 % des sessions WebRTC dans les réseaux mobiles nécessitent TURN. Pour optimiser les coûts du trafic TURN, les développeurs utilisent un test de connexion préalable et n’activent le canal TURN qu’en cas d’échec du P2P.

Choix de STUN/TURN pour une application mobile

Lors du choix de l’infrastructure pour ICE dans un projet mobile, on tient compte de la localisation géographique des serveurs pour minimiser la latence, du support UDP et TCP, du coût du trafic TURN et du SLA. Solutions populaires : coturn pour une installation autonome, Twilio, Agora et LiveKit pour une utilisation cloud.

ICE Candidate dans le développement mobile

Pour les développeurs mobiles, la compréhension d’ICE Candidate va au-delà de la théorie : c’est une nécessité pratique lors de la création d’applications avec appels vocaux et vidéo. Les plateformes iOS et Android fournissent des API natives pour WebRTC qui automatisent le travail avec ICE, mais le développeur est responsable de la configuration des serveurs ICE et du traitement des événements de changement de réseau.

Configuration ICE sur iOS

Sur iOS, WebRTC est disponible via le framework WebRTC.framework ou la bibliothèque GoogleWebRTC via CocoaPods. Les serveurs ICE sont configurés via le tableau RTCIceServer dans RTCConfiguration :

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

Après la création du RTCPeerConnection et l’appel de offer() ou answer(), le moteur collecte automatiquement les candidats ICE. L’événement iceGatheringStateChange notifie le changement d’état de collecte, et iceConnectionState informe de l’état de la connexion.

Configuration ICE sur Android

Android utilise la même bibliothèque Google WebRTC. Les serveurs ICE sont définis via PeerConnection.RTCConfiguration. Le développeur peut gérer la politique ICE via iceTransportsType : le mode relay utilise uniquement TURN, ce qui améliore la fiabilité mais augmente la latence :

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

Le paramètre bundlePolicy influence le nombre de candidats ICE : le mode MAXBUNDLE combine tous les flux média dans un seul transport, réduisant le nombre total de candidats et accélérant la connexion.

Gestion des événements ICE dans l’application mobile

Les principaux événements ICE que le développeur doit gérer : l’état de connexion ICE (ICE connection state), le changement d’état de collecte (ICE gathering state) et la détection d’un nouveau candidat. Une fois qu’ICE termine la collecte et les tests, son état passe à connected ou completed.

Dans les réseaux mobiles, les basculements entre WiFi et réseau cellulaire sont fréquents. Lors du changement de réseau, ICE doit effectuer un restart, sinon le flux média est interrompu. Les développeurs implémentent la surveillance de NetworkManager (iOS) ou ConnectivityManager (Android) pour appeler automatiquement restartIce().

Une implémentation réussie d’ICE dans une application mobile comprend : le choix de serveurs STUN/TURN fiables, la gestion correcte d’ICE restart lors du changement de réseau, la configuration d’iceConnectionState pour afficher le statut UI de la connexion et la surveillance des statistiques via RTCStatsReport.