ICE Candidate: ce este, tipuri de candidați și cum funcționează

Ce este ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — este o unitate fundamentală în procesul de stabilire a conexiunii P2P prin protocolul WebRTC. Reprezintă o pereche adresă IP + port care poate fi utilizată pentru transmiterea datelor între doi peeri. Fiecare candidat conține informații despre protocolul de transport (UDP, TCP), tipul conexiunii și prioritatea.

ICE Candidate se formează pe fiecare dispozitiv separat. Dispozitivul colectează toate interfețele de rețea disponibile, solicită adresa externă printr-un server STUN și adaugă adresa de releu de la serverul TURN. Lista de candidați rezultată este trimisă peerului la distanță prin canalul de semnalizare în format SDP (Session Description Protocol).

Conform specificației RFC 8445 (IETF, 2018), ICE utilizează mecanismul nominated pairs: după colectarea tuturor candidaților, se efectuează testarea lor în perechi prin cereri STUN. Prima pereche care trece testul este declarată nominated (desemnată) și utilizată pentru transmisia multimedia. Celelalte perechi rămân în rezervă în caz de întrerupere a conexiunii.

Rolul ICE în stiva WebRTC

WebRTC — este un standard deschis pentru comunicații P2P, dar conexiunea directă între dispozitive este adesea imposibilă din cauza NAT (Network Address Translation) și a firewall-urilor. ICE Candidate rezolvă această problemă oferind mai multe căi alternative de conexiune. Protocolul ICE (Interactive Connectivity Establishment) este o componentă obligatorie a WebRTC și este descris în specificația W3C WebRTC (2025).

Mulți dezvoltatori de aplicații mobile utilizează biblioteci WebRTC precum Google WebRTC (pentru Android) și învelișuri native pentru iOS. În fiecare dintre ele, procesul ICE este gestionat automat, dar înțelegerea tipurilor de candidați permite dezvoltatorului să configureze infrastructura serverului și să optimizeze calitatea conexiunii.

Format SDP cu candidați ICE

ICE Candidate este transmis în cadrul mesajului SDP ca atribute a=candidate. Fiecare linie conține foundation, component ID, protocolul de transport, prioritatea, adresa IP, portul și tipul candidatului. Mai jos este dat un exemplu de fragment SDP cu trei candidați de tipuri diferite:

// Exemplu SDP cu candidați 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

Câmpul priority determină ordinea de testare a candidaților. Cu cât prioritatea este mai mare, cu atât candidatul va fi verificat mai devreme. Candidații host au întotdeauna cea mai mare prioritate, iar relay — cea mai mică.

Tipuri de candidați ICE

Specificația RFC 8445 definește patru tipuri de candidați ICE, fiecare corespunzând unui anumit mod de a ajunge la peerul la distanță. Tipul candidatului influențează prioritatea sa, timpul de stabilire a conexiunii și cerințele față de infrastructura serverului.

Candidați host

Candidatul host se formează din adresa IP a interfeței de rețea locale a dispozitivului. Dacă dispozitivul se află în aceeași rețea locală cu peerul, candidatul host asigură o conexiune directă cu întârziere minimă. Pentru dispozitivele mobile, candidații host sunt generați pentru interfața WiFi, conexiunea celulară LTE/5G și, la nevoie, pentru tunelurile VPN.

Candidații host au cea mai mare prioritate (2130706431 pentru UDP) și sunt testați primii. Dacă ambii peeri se află în spatele NAT, candidații lor host vor fi adrese private (192.168.x.x, 10.x.x.x) și conexiunea directă prin ei este imposibilă. ICE trece la testarea candidaților srflx și relay.

Candidați SRFLX și PRFLX

SRFLX (Server Reflexive) — este adresa IP externă și portul obținute de la serverul STUN. Când dispozitivul trimite o cerere STUN, serverul vede adresa sa publică după NAT și o returnează. Acest candidat permite stabilirea unei conexiuni directe între peeri aflați în spatele unor NAT diferite, dacă dispozitivele lor NAT acceptă Hairpinning.

PRFLX (Peer Reflexive) este detectat dinamic atunci când o cerere STUN de la un peer sosește la o adresă neașteptată. Acest tip apare atunci când ambii peeri trimit cereri simultan și NAT creează o legătură temporară. Candidatul PRFLX are prioritate mai mare decât srflx, dar mai mică decât host.

În aplicațiile mobile, candidații srflx sunt deosebit de importanți la comutarea între WiFi și rețeaua celulară. Când dispozitivul schimbă rețeaua, adresa IP se modifică și ICE trebuie să recolteze candidații. Acest proces se numește ICE restart și necesită retrimiterea unui nou SDP.

Candidați relay prin TURN

Candidatul relay — este o adresă pe serverul TURN prin care traficul este retransmis de la un peer la altul. Acest tip este utilizat ca opțiune de rezervă atunci când conexiunea directă P2P este imposibilă (NAT simetric, firewall corporativ). Canalul de releu adaugă întârziere și crește încărcarea serverului, de aceea în setări optime serverul TURN este utilizat doar pentru 10–15% din toate sesiunile.

Implementări populare de servere TURN: coturn (cod sursă deschis), Twilio Network Traversal, Metered TURN. Alegerea furnizorului TURN influențează calitatea conexiunii media în aplicațiile mobile — serverul trebuie să fie amplasat geografic aproape de utilizatori pentru a minimiza întârzierea suplimentară.

Cum funcționează procesul ICE

Procesul ICE — este un protocol în mai multe etape care garantează stabilirea unei conexiuni P2P fiabile în condiții de incertitudine a topologiei de rețea. Algoritmul este descris în RFC 8445 și include patru faze obligatorii: colectarea candidaților, sortarea lor, testarea și nominalizarea.

Faza 1: colectarea candidaților

Fiecare dispozitiv colectează toate adresele de rețea disponibile. Pentru aceasta, motorul WebRTC enumeră interfețele locale (host), trimite o cerere către serverul STUN (srflx) și solicită adresa de releu de la serverul TURN (relay). Simultane, dispozitivul poate detecta un candidat prflx dacă primește o cerere STUN de intrare de la peer.

În dezvoltarea mobilă, această etapă este critică pentru timpul de stabilire a conexiunii. Pe iOS și Android, colectarea candidaților poate dura între 200 ms și 2 secunde, în funcție de viteza rețelei, disponibilitatea serverelor STUN/TURN și numărul de interfețe de rețea active.

Faza 2: formarea perechilor și sortarea

După primirea listei de candidați de la peerul la distanță prin canalul de semnalizare, motorul ICE local formează toate perechile de candidați posibile (local + la distanță). Fiecare pereche primește o prioritate conform formulei din RFC 8445, care ia în considerare prioritățile ambilor candidați și direcția (incoming/outgoing).

Perechile se sortează în ordine descrescătoare a priorității. Cele mai bune perechi sunt testate primele. Algoritmul garantează că perechea host-host va fi verificată înaintea host-srflx, host-relay sau relay-relay, minimizând întârzierea conexiunii în configurații simple de rețea.

Faza 3: testarea și nominalizarea

ICE trimite cereri STUN-binding pentru fiecare pereche de candidați. Dacă se primește un răspuns STUN — perechea este validă. Prima pereche validă este nominalizată (nominated) ca principală. Motorul WebRTC începe transmiterea media prin această pereche, iar celelalte perechi continuă să fie verificate în caz de defectare a celei principale.

Procesul de testare poate dura până la câteva secunde la un număr mare de candidați. WebRTC utilizează temporizatoare: pentru perechile host un temporizator agresiv (20 ms), pentru relay — unul mai conservator (200 ms). Dezvoltatorii de aplicații mobile pot accelera conexiunea limitând numărul de servere ICE sau configurând iceTransportPolicy.

ICE Restart

ICE restart — este repornirea procesului ICE fără recrearea întregului RTCPeerConnection. Este necesar la schimbarea rețelei, pierderea conexiunii sau comutarea între WiFi și rețeaua mobilă. La restart, toți candidații actuali sunt resetați, iar procesul începe din nou cu generarea unui nou ufrag și pwd.

În dezvoltarea iOS, ICE restart se apelează prin metoda restartIce() pe RTCPeerConnection. Pe Android se utilizează o metodă similară în clasa PeerConnection din Google WebRTC. Gestionarea corectă a ICE restart — cerință critică pentru aplicațiile care rulează pe dispozitive mobile cu conexiune de rețea instabilă.

Servere STUN și TURN în ICE

STUN (Session Traversal Utilities for NAT) și TURN (Traversal Using Relays around NAT) — sunt componente server cheie fără de care ICE Candidate nu poate garanta o conexiune reușită în condiții de internet real. Configurarea lor corectă influențează direct calitatea apelului în aplicațiile mobile.

STUN: detectarea adresei externe

Serverul STUN permite dispozitivului să își cunoască adresa IP publică și portul pe care NAT l-a alocat pentru conexiunea de ieșire. Protocolul STUN este definit în RFC 8489 și funcționează pe UDP pe portul 3478, suportând și TCP. Google oferă servere STUN publice (stun.l.google.com:19302) care pot fi utilizate gratuit.

În dezvoltarea mobilă, cererea STUN — o operațiune ușoară care durează 50–200 ms. Cu toate acestea, unele rețele corporative și mobile blochează traficul UDP, forțând ICE să utilizeze TCP pentru comunicarea STUN sau să treacă direct la TURN.

TURN: retransmisia traficului

Serverul TURN — este un retransmițător de trafic media. Când conexiunea directă P2P este imposibilă (NAT simetric, firewall), dispozitivul trimite datele către TURN, care le transmite celuilalt peer. TURN — un mecanism fiabil, dar costisitor: adaugă întârziere (30–100 ms) și necesită lățime de bandă a serverului egală cu suma tuturor sesiunilor media.

Potrivit WebRTC Stats Report (2025), aproximativ 8–15% din sesiunile WebRTC în rețelele mobile necesită TURN. Pentru optimizarea costurilor traficului TURN, dezvoltatorii utilizează testarea preliminară a conexiunii și doar la eșecul P2P activează canalul TURN.

Alegerea STUN/TURN pentru aplicația mobilă

La alegerea infrastructurii pentru ICE într-un proiect mobil se iau în considerare: amplasarea geografică a serverelor pentru minimizarea întârzierii, suportul UDP și TCP, costul traficului TURN și SLA. Soluții populare: coturn pentru instalare independentă, Twilio, Agora și LiveKit pentru utilizare în cloud.

ICE Candidate în dezvoltarea mobilă

Pentru dezvoltatorii mobili, înțelegerea ICE Candidate depășește cadrul teoretic — este o necesitate practică la crearea aplicațiilor cu apeluri vocale și video. Platformele iOS și Android oferă API-uri native pentru WebRTC care automatizează lucrul cu ICE, dar dezvoltatorul răspunde de configurarea serverelor ICE și gestionarea evenimentelor de schimbare a rețelei.

Configurarea ICE pe iOS

Pe iOS, WebRTC este disponibil prin framework-ul WebRTC.framework sau biblioteca GoogleWebRTC prin CocoaPods. Servere ICE se configurează prin tabloul RTCIceServer în 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)

După crearea RTCPeerConnection și apelarea offer() sau answer(), motorul colectează automat candidații ICE. Evenimentul iceGatheringStateChange notifică despre schimbarea stării de colectare, iar iceConnectionState — despre starea conexiunii.

Configurarea ICE pe Android

Android utilizează aceeași bibliotecă Google WebRTC. Servere ICE se setează prin PeerConnection.RTCConfiguration. Dezvoltatorul poate gestiona politica ICE prin iceTransportsType — modul relay forțează utilizarea exclusivă a TURN, ceea ce crește fiabilitatea, dar și întârzierea:

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

Parametrul bundlePolicy influențează numărul de candidați ICE — modul MAXBUNDLE unifică toate fluxurile media într-un singur transport, reducând numărul total de candidați și accelerând conexiunea.

Gestionarea evenimentelor ICE în aplicația mobilă

Evenimentele ICE cheie pe care dezvoltatorul trebuie să le gestioneze: starea conexiunii ICE (ICE connection state), schimbarea stării de colectare (ICE gathering state) și detectarea unui nou candidat. După ce ICE finalizează colectarea și testarea, starea sa trece în connected sau completed.

În rețelele mobile apar frecvent comutări între WiFi și rețeaua celulară. La schimbarea rețelei, ICE trebuie să execute restart, altfel fluxul media se întrerupe. Dezvoltatorii implementează monitorizarea NetworkManager (iOS) sau ConnectivityManager (Android) pentru apelarea automată a restartIce().

Implementarea reușită a ICE într-o aplicație mobilă include: alegerea serverelor STUN/TURN fiabile, gestionarea corectă a ICE restart la schimbarea rețelei, configurarea iceConnectionState pentru afișarea stării conexiunii în UI și monitorizarea statisticilor prin RTCStatsReport.