ICE Candidate: definizione, tipi di candidati e funzionamento

Cos’è un ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) è un’unità fondamentale nel processo di stabilimento della connessione P2P tramite il protocollo WebRTC. Rappresenta una coppia indirizzo IP + porta che può essere utilizzata per trasmettere dati tra due peer. Ogni candidato contiene informazioni sul protocollo di trasporto (UDP, TCP), sul tipo di connessione e sulla priorità.

ICE Candidate viene formato separatamente su ciascun dispositivo. Il dispositivo raccoglie tutte le interfacce di rete disponibili, richiede l’indirizzo esterno tramite un server STUN e aggiunge l’indirizzo relay dal server TURN. L’elenco dei candidati ottenuto viene inviato al peer remoto attraverso il canale di segnalazione in formato SDP (Session Description Protocol).

Secondo la specifica RFC 8445 (IETF, 2018), ICE utilizza il meccanismo delle coppie nominate (nominated pairs): dopo la raccolta di tutti i candidati, viene eseguito un test per coppia tramite richieste STUN. La coppia che supera la verifica per prima viene dichiarata nominata (nominated) e utilizzata per la trasmissione multimediale. Le altre coppie rimangono in riserva in caso di interruzione della connessione.

Ruolo di ICE nello stack WebRTC

WebRTC è uno standard aperto per le comunicazioni P2P, ma la connessione diretta tra dispositivi è spesso impossibile a causa del NAT (Network Address Translation) e dei firewall. ICE Candidate risolve questo problema offrendo diversi percorsi di connessione alternativi. Il protocollo ICE (Interactive Connectivity Establishment) è un componente obbligatorio di WebRTC ed è descritto nella specifica W3C WebRTC (2025).

Molti sviluppatori di applicazioni mobili utilizzano librerie WebRTC come Google WebRTC (per Android) e wrapper nativi per iOS. In ciascuna di esse, il processo ICE viene gestito automaticamente, ma la comprensione dei tipi di candidati consente allo sviluppatore di configurare l’infrastruttura del server e ottimizzare la qualità della connessione.

Formato SDP con candidati ICE

ICE Candidate viene trasmesso in un messaggio SDP sotto forma di attributi a=candidate. Ogni riga contiene foundation, component ID, protocollo di trasporto, priorità, indirizzo IP, porta e tipo di candidato. Di seguito è riportato un esempio di frammento SDP con tre candidati di diversi tipi:

// Campione SDP con candidati 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

Il campo priority determina l’ordine di test dei candidati. Più alta è la priorità, prima il candidato verrà verificato. I candidati host hanno sempre la priorità più alta, relay la più bassa.

Tipi di candidati ICE

La specifica RFC 8445 definisce quattro tipi di candidati ICE, ciascuno corrispondente a un modo specifico di raggiungere il peer remoto. Il tipo di candidato influenza la sua priorità, il tempo di stabilimento della connessione e i requisiti dell’infrastruttura server.

Candidati host

Un candidato host viene formato dall’indirizzo IP dell’interfaccia di rete locale del dispositivo. Se il dispositivo si trova nella stessa rete locale del peer, il candidato host fornisce una connessione diretta con latenza minima. Per i dispositivi mobili, i candidati host vengono generati per l’interfaccia WiFi, la connessione cellulare LTE/5G e, se necessario, per i tunnel VPN.

I candidati host hanno la priorità più alta (2130706431 per UDP) e vengono testati per primi. Se entrambi i peer si trovano dietro NAT, i loro candidati host saranno indirizzi privati (192.168.x.x, 10.x.x.x) e la connessione diretta tramite essi è impossibile. ICE passa al test dei candidati srflx e relay.

Candidati SRFLX e PRFLX

Un candidato SRFLX (Server Reflexive) è un indirizzo IP esterno e una porta ottenuti dal server STUN. Quando il dispositivo invia una richiesta STUN, il server vede il suo indirizzo pubblico dopo il NAT e lo restituisce. Questo candidato consente di stabilire una connessione diretta tra peer dietro NAT diversi se i loro dispositivi NAT supportano Hairpinning.

Un candidato PRFLX (Peer Reflexive) viene rilevato dinamicamente quando una richiesta STUN da un peer arriva a un indirizzo imprevisto. Questo tipo si verifica quando entrambi i peer inviano richieste contemporaneamente e il NAT crea un’associazione temporanea. Il candidato PRFLX ha una priorità più alta di srflx ma inferiore a host.

Nelle applicazioni mobili, i candidati srflx sono particolarmente importanti durante il passaggio tra WiFi e rete cellulare. Quando il dispositivo cambia rete, l’indirizzo IP cambia e ICE deve raccogliere nuovamente i candidati. Questo processo si chiama ICE restart e richiede l’invio di un nuovo SDP.

Candidati relay tramite TURN

Un candidato relay è un indirizzo sul server TURN attraverso il quale il traffico viene relay da un peer all’altro. Questo tipo viene utilizzato come opzione di riserva quando la connessione P2P diretta è impossibile (NAT simmetrico, firewall aziendale). Il canale relay aggiunge latenza e aumenta il carico del server, pertanto in una configurazione ottimale, il server TURN viene utilizzato solo per il 10–15% di tutte le sessioni.

Implementazioni popolari di server TURN: coturn (open source), Twilio Network Traversal, Metered TURN. La scelta del provider TURN influenza la qualità della connessione multimediale nelle applicazioni mobili — il server deve essere geograficamente vicino agli utenti per minimizzare la latenza aggiuntiva.

Come funziona il processo ICE

Il processo ICE è un protocollo in più fasi che garantisce lo stabilimento di una connessione P2P affidabile in condizioni di incertezza della topologia di rete. L’algoritmo è descritto nella RFC 8445 e comprende quattro fasi obbligatorie: raccolta dei candidati, loro ordinamento, test e nomina.

Fase 1: raccolta dei candidati

Ogni dispositivo raccoglie tutti gli indirizzi di rete disponibili. Per fare ciò, il motore WebRTC enumera le interfacce locali (host), invia una richiesta al server STUN (srflx) e richiede un indirizzo relay al server TURN. Contemporaneamente, il dispositivo può rilevare un candidato prflx se riceve una richiesta STUN in entrata dal peer.

Nello sviluppo mobile, questa fase è cruciale per il tempo di stabilimento della connessione. Su iOS e Android, la raccolta dei candidati può richiedere da 200 ms a 2 secondi a seconda della velocità della rete, della disponibilità dei server STUN/TURN e del numero di interfacce di rete attive.

Fase 2: formazione delle coppie e ordinamento

Dopo aver ricevuto l’elenco dei candidati dal peer remoto attraverso il canale di segnalazione, il motore ICE locale forma tutte le coppie di candidati possibili (locale + remoto). Ogni coppia riceve una priorità secondo la formula della RFC 8445, tenendo conto delle priorità di entrambi i candidati e della direzione (entrante/uscente).

Le coppie vengono ordinate in ordine decrescente di priorità. Le coppie migliori vengono testate per prime. L’algoritmo garantisce che la coppia host-host venga verificata prima di host-srflx, host-relay o relay-relay, minimizzando la latenza di connessione nelle configurazioni di rete semplici.

Fase 3: test e nomina

ICE invia richieste STUN-binding per ogni coppia di candidati. Se viene ricevuta una risposta STUN, la coppia è valida. La prima coppia valida viene nominata (nominated) come principale. Il motore WebRTC inizia a trasmettere i media attraverso questa coppia, mentre le altre coppie continuano a essere verificate in caso di guasto della principale.

Il processo di test può richiedere diversi secondi con un gran numero di candidati. WebRTC utilizza timer: per le coppie host, il timer è aggressivo (20 ms), per relay più conservativo (200 ms). Gli sviluppatori di applicazioni mobili possono accelerare la connessione limitando il numero di server ICE o configurando iceTransportPolicy.

ICE Restart

ICE restart è il riavvio del processo ICE senza ricreare l’intero RTCPeerConnection. È necessario in caso di cambio di rete, perdita di connessione o passaggio tra WiFi e rete mobile. Al riavvio, tutti i candidati correnti vengono reimpostati e il processo ricomincia con la generazione di nuovi ufrag e pwd.

Nello sviluppo iOS, ICE restart viene attivato dal metodo restartIce() su RTCPeerConnection. Su Android, un metodo simile viene utilizzato nella classe PeerConnection di Google WebRTC. La gestione corretta di ICE restart è un requisito critico per le applicazioni che funzionano su dispositivi mobili con connessione di rete instabile.

Server STUN e TURN in ICE

STUN (Session Traversal Utilities for NAT) e TURN (Traversal Using Relays around NAT) sono componenti server chiave senza i quali ICE Candidate non può garantire una connessione riuscita in condizioni Internet reali. La loro corretta configurazione influenza direttamente la qualità della chiamata nelle applicazioni mobili.

STUN: rilevamento dell’indirizzo esterno

Il server STUN consente al dispositivo di conoscere il proprio indirizzo IP pubblico e la porta che il NAT ha allocato per la connessione in uscita. Il protocollo STUN è definito nella RFC 8489 e funziona su UDP sulla porta 3478, e supporta anche TCP. Google fornisce server STUN pubblici (stun.l.google.com:19302) utilizzabili gratuitamente.

Nello sviluppo mobile, una richiesta STUN è un’operazione leggera che richiede 50–200 ms. Tuttavia, alcune reti aziendali e mobili bloccano il traffico UDP, costringendo ICE a utilizzare TCP per la comunicazione STUN o a passare direttamente a TURN.

TURN: relay del traffico

Un server TURN è un relay del traffico multimediale. Quando la connessione P2P diretta è impossibile (NAT simmetrico, firewall), il dispositivo invia i dati a TURN che li inoltra all’altro peer. TURN è un meccanismo affidabile ma costoso: aggiunge latenza (30–100 ms) e richiede una larghezza di banda del server pari alla somma di tutte le sessioni multimediali.

Secondo il WebRTC Stats Report (2025), circa l’8–15% delle sessioni WebRTC nelle reti mobili richiede TURN. Per ottimizzare i costi del traffico TURN, gli sviluppatori utilizzano un test di connessione preliminare e attivano il canale TURN solo in caso di fallimento del P2P.

Scelta di STUN/TURN per l’applicazione mobile

Nella scelta dell’infrastruttura per ICE in un progetto mobile, si considera: la posizione geografica dei server per minimizzare la latenza, il supporto UDP e TCP, il costo del traffico TURN e lo SLA. Soluzioni popolari: coturn per installazione autonoma, Twilio, Agora e LiveKit per uso cloud.

ICE Candidate nello sviluppo mobile

Per gli sviluppatori mobili, la comprensione di ICE Candidate va oltre la teoria — è una necessità pratica nella creazione di applicazioni con chiamate vocali e video. Le piattaforme iOS e Android forniscono API native per WebRTC che automatizzano il lavoro con ICE, ma lo sviluppatore è responsabile della configurazione dei server ICE e della gestione degli eventi di cambio rete.

Configurazione ICE su iOS

Su iOS, WebRTC è disponibile tramite il framework WebRTC.framework o la libreria GoogleWebRTC tramite CocoaPods. I server ICE vengono configurati tramite l’array RTCIceServer in 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)

Dopo la creazione del RTCPeerConnection e la chiamata a offer() o answer(), il motore raccoglie automaticamente i candidati ICE. L’evento iceGatheringStateChange notifica il cambiamento dello stato di raccolta, mentre iceConnectionState informa sullo stato della connessione.

Configurazione ICE su Android

Android utilizza la stessa libreria Google WebRTC. I server ICE vengono impostati tramite PeerConnection.RTCConfiguration. Lo sviluppatore può gestire la politica ICE tramite iceTransportsType — la modalità relay utilizza forzatamente solo TURN, aumentando l’affidabilità ma incrementando la latenza:

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

Il parametro bundlePolicy influenza il numero di candidati ICE — la modalità MAXBUNDLE combina tutti i flussi multimediali in un unico trasporto, riducendo il numero totale di candidati e accelerando la connessione.

Gestione degli eventi ICE nell’applicazione mobile

I principali eventi ICE che lo sviluppatore deve gestire: stato della connessione ICE (ICE connection state), cambiamento dello stato di raccolta (ICE gathering state) e rilevamento di un nuovo candidato. Dopo che ICE completa la raccolta e i test, il suo stato passa a connected o completed.

Nelle reti mobili, i passaggi tra WiFi e rete cellulare sono frequenti. Al cambio di rete, ICE deve eseguire un restart, altrimenti il flusso multimediale viene interrotto. Gli sviluppatori implementano il monitoraggio di NetworkManager (iOS) o ConnectivityManager (Android) per chiamare automaticamente restartIce().

Un’implementazione di successo di ICE in un’applicazione mobile include: la scelta di server STUN/TURN affidabili, la corretta gestione di ICE restart al cambio di rete, la configurazione di iceConnectionState per visualizzare lo stato UI della connessione e il monitoraggio delle statistiche tramite RTCStatsReport.