ICE Candidate: co to je, typy kandidátů a jak funguje

Co je ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — je základní jednotka v procesu navazování P2P spojení prostřednictvím protokolu WebRTC. Představuje pár IP adresa + port, který lze použít pro přenos dat mezi dvěma peery. Každý kandidát obsahuje informace o transportním protokolu (UDP, TCP), typu spojení a prioritě.

ICE Candidate se vytváří na každém zařízení zvlášť. Zařízení shromáždí všechny dostupné síťové rozhraní, vyžádá externí adresu prostřednictvím STAN serveru a přidá reléovou adresu z TURN serveru. Výsledný seznam kandidátů je odeslán vzdálenému peerovi prostřednictvím signalizačního kanálu ve formátu SDP (Session Description Protocol).

Podle specifikace RFC 8445 (IETF, 2018) ICE používá mechanismus nominated pairs: po shromáždění všech kandidátů se provádí jejich párové testování prostřednictvím STUN požadavků. První pár, který testem projde, je prohlášen za nominated (jmenovaný) a používá se pro přenos multimédií. Ostatní páry zůstávají v záloze pro případ přerušení spojení.

Role ICE v zásobníku WebRTC

WebRTC — je otevřený standard pro P2P komunikaci, ale přímé spojení mezi zařízeními je často nemožné kvůli NAT (Network Address Translation) a firewallům. ICE Candidate řeší tento problém nabídkou několika alternativních cest spojení. Protokol ICE (Interactive Connectivity Establishment) je povinnou součástí WebRTC a je popsán ve specifikaci W3C WebRTC (2025).

Mnoho vývojářů mobilních aplikací používá knihovny WebRTC, jako je Google WebRTC (pro Android) a nativní obaly pro iOS. V každé z nich je proces ICE řízen automaticky, ale porozumění typům kandidátů umožňuje vývojáři konfigurovat serverovou infrastrukturu a optimalizovat kvalitu spojení.

Formát SDP s ICE kandidáty

ICE Candidate se přenáší v rámci SDP zprávy jako atributy a=candidate. Každý řádek obsahuje foundation, component ID, transportní protokol, prioritu, IP adresu, port a typ kandidáta. Níže je uveden příklad SDP fragmentu se třemi kandidáty různých typů:

// Příklad SDP s ICE kandidáty
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

Pole priority určuje pořadí testování kandidátů. Čím vyšší priorita, tím dříve bude kandidát zkontrolován. Host kandidáti mají vždy nejvyšší prioritu, relay nejnižší.

Typy ICE kandidátů

Specifikace RFC 8445 definuje čtyři typy ICE kandidátů, z nichž každý odpovídá určitému způsobu dosažení vzdáleného peer. Typ kandidáta ovlivňuje jeho prioritu, dobu navázání spojení a požadavky na serverovou infrastrukturu.

Host kandidáti

Host kandidát se vytváří z IP adresy lokálního síťového rozhraní zařízení. Pokud je zařízení ve stejné lokální síti jako peer, host kandidát poskytuje přímé spojení s minimálním zpožděním. Pro mobilní zařízení se host kandidáti generují pro rozhraní WiFi, mobilní LTE/5G připojení a v případě potřeby pro VPN tunely.

Host kandidáti mají nejvyšší prioritu (2130706431 pro UDP) a testují se jako první. Pokud jsou oba peeři za NATem, jejich host kandidáti budou soukromé adresy (192.168.x.x, 10.x.x.x) a přímé spojení přes ně není možné. ICE přechází k testování srflx a relay kandidátů.

SRFLX a PRFLX kandidáti

SRFLX (Server Reflexive) — je externí IP adresa a port získané od STUN serveru. Když zařízení odešle STUN požadavek, server vidí jeho veřejnou adresu za NATem a vrátí ji. Tento kandidát umožňuje navázání přímého spojení mezi peery za různými NATy, pokud jejich NAT zařízení podporují Hairpinning.

PRFLX (Peer Reflexive) je detekován dynamicky, když STUN požadavek od jednoho peer přijde na neočekávanou adresu. Tento typ vzniká, když oba peeři odešlou požadavky současně a NAT vytvoří dočasné propojení. PRFLX kandidát má vyšší prioritu než srflx, ale nižší než host.

V mobilních aplikacích jsou srflx kandidáti obzvláště důležití při přepínání mezi WiFi a mobilní sítí. Když zařízení změní síť, IP adresa se změní a ICE musí znovu shromáždit kandidáty. Tento proces se nazývá ICE restart a vyžaduje opětovné odeslání nového SDP.

Relay kandidáti přes TURN

Relay kandidát — je adresa na TURN serveru, přes kterou je provoz přenášen z jednoho peer na druhý. Tento typ se používá jako záložní možnost, když přímé P2P spojení není možné (symetrický NAT, firemní firewall). Reléový kanál přidává zpoždění a zvyšuje zatížení serveru, proto se v optimálních nastaveních TURN server používá pouze pro 10–15% všech relací.

Populární implementace TURN serverů: coturn (otevřený zdrojový kód), Twilio Network Traversal, Metered TURN. Výběr poskytovatele TURN ovlivňuje kvalitu mediálního spojení v mobilních aplikacích — server by měl být geograficky blízko uživatelům, aby se minimalizovalo dodatečné zpoždění.

Jak funguje proces ICE

Proces ICE — je vícefázový protokol, který zaručuje navázání spolehlivého P2P spojení v podmínkách nejistoty síťové topologie. Algoritmus je popsán v RFC 8445 a zahrnuje čtyři povinné fáze: shromažďování kandidátů, jejich řazení, testování a nominaci.

Fáze 1: shromažďování kandidátů

Každé zařízení shromáždí všechny dostupné síťové adresy. K tomu WebRTC engine vyjmenuje lokální rozhraní (host), odešle požadavek na STUN server (srflx) a vyžádá reléovou adresu od TURN serveru (relay). Současně může zařízení detekovat prflx kandidáta, pokud obdrží příchozí STUN požadavek od peer.

V mobilním vývoji je tato fáze kritická pro dobu navázání spojení. Na iOS a Androidu může shromažďování kandidátů trvat od 200 ms do 2 sekund v závislosti na rychlosti sítě, dostupnosti STUN/TURN serverů a počtu aktivních síťových rozhraní.

Fáze 2: tvorba párů a řazení

Po obdržení seznamu kandidátů od vzdáleného peer prostřednictvím signalizačního kanálu vytvoří lokální ICE engine všechny možné páry kandidátů (lokální + vzdálený). Každý pár obdrží prioritu podle vzorce z RFC 8445, který zohledňuje priority obou kandidátů a směr (incoming/outgoing).

Páry se řadí sestupně podle priority. Nejlepší páry se testují jako první. Algoritmus zaručuje, že pár host-host bude zkontrolován dříve než host-srflx, host-relay nebo relay-relay, čímž minimalizuje zpoždění spojení v jednoduchých síťových konfiguracích.

Fáze 3: testování a nominace

ICE odesílá STUN-binding požadavky pro každý pár kandidátů. Pokud je obdržena STUN odpověď — pár je platný. První platný pár je nominován (nominated) jako hlavní. WebRTC engine začne přenášet média přes tento pár, zatímco ostatní páry jsou nadále kontrolovány pro případ selhání hlavního.

Proces testování může trvat až několik sekund při velkém počtu kandidátů. WebRTC používá časovače: pro host páry agresivní časovač (20 ms), pro relay — konzervativnější (200 ms). Vývojáři mobilních aplikací mohou spojení urychlit omezením počtu ICE serverů nebo konfigurací iceTransportPolicy.

ICE Restart

ICE restart — je restartování procesu ICE bez opětovného vytvoření celého RTCPeerConnection. Je nezbytný při změně sítě, ztrátě spojení nebo přepínání mezi WiFi a mobilní sítí. Při restartu jsou všichni aktuální kandidáti resetováni a proces začíná znovu s generováním nového ufrag a pwd.

V iOS vývoji se ICE restart volá metodou restartIce() na RTCPeerConnection. Na Androidu se používá analogická metoda ve třídě PeerConnection z Google WebRTC. Správné zpracování ICE restart — kritický požadavek pro aplikace běžící na mobilních zařízeních s nestabilním síťovým připojením.

STUN a TURN servery v ICE

STUN (Session Traversal Utilities for NAT) a TURN (Traversal Using Relays around NAT) — jsou klíčové serverové komponenty, bez kterých ICE Candidate nemůže zaručit úspěšné spojení v podmínkách reálného internetu. Jejich správná konfigurace přímo ovlivňuje kvalitu hovoru v mobilních aplikacích.

STUN: detekce externí adresy

STUN server umožňuje zařízení zjistit svou veřejnou IP adresu a port, který NAT přidělil pro odchozí spojení. Protokol STUN je definován v RFC 8489 a pracuje přes UDP na portu 3478 a také podporuje TCP. Google poskytuje veřejné STUN servery (stun.l.google.com:19302), které lze zdarma používat.

V mobilním vývoji je STUN požadavek — lehká operace trvající 50–200 ms. Některé firemní a mobilní sítě však blokují UDP provoz, čímž nutí ICE používat TCP pro STUN komunikaci nebo přejít rovnou na TURN.

TURN: retransmise provozu

TURN server — je retransmiter mediálního provozu. Když přímé P2P spojení není možné (symetrický NAT, firewall), zařízení odešle data na TURN, který je předá druhému peerovi. TURN je spolehlivý, ale nákladný mechanismus: přidává zpoždění (30–100 ms) a vyžaduje šířku pásma serveru rovnou součtu všech mediálních relací.

Podle WebRTC Stats Report (2025) přibližně 8–15% WebRTC relací v mobilních sítích vyžaduje TURN. Pro optimalizaci nákladů na TURN provoz vývojáři používají předběžné testování spojení a pouze při selhání P2P aktivují TURN kanál.

Výběr STUN/TURN pro mobilní aplikaci

Při výběru infrastruktury pro ICE v mobilním projektu se zohledňuje: geografické umístění serverů pro minimalizaci zpoždění, podpora UDP a TCP, cena TURN provozu a SLA. Populární řešení: coturn pro samostatnou instalaci, Twilio, Agora a LiveKit pro cloudové použití.

ICE Candidate v mobilním vývoji

Pro mobilní vývojáře přesahuje porozumění ICE Candidate rámec teorie — je to praktická nutnost při vytváření aplikací s hlasovými a videohovory. Platformy iOS a Android poskytují nativní API pro WebRTC, která automatizují práci s ICE, ale vývojář odpovídá za konfiguraci ICE serverů a zpracování událostí změny sítě.

Konfigurace ICE na iOS

Na iOS je WebRTC dostupný přes framework WebRTC.framework nebo knihovnu GoogleWebRTC přes CocoaPods. ICE servery se konfigurují přes pole RTCIceServer v 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)

Po vytvoření RTCPeerConnection a volání offer() nebo answer() engine automaticky shromažďuje ICE kandidáty. Událost iceGatheringStateChange informuje o změně stavu shromažďování a iceConnectionState o stavu spojení.

Konfigurace ICE na Androidu

Android používá stejnou knihovnu Google WebRTC. ICE servery se nastavují přes PeerConnection.RTCConfiguration. Vývojář může spravovat politiku ICE přes iceTransportsType — režim relay vynucuje použití pouze TURN, což zvyšuje spolehlivost, ale také zpoždění:

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

Parametr bundlePolicy ovlivňuje počet ICE kandidátů — režim MAXBUNDLE slučuje všechny mediální toky do jednoho transportu, snižuje celkový počet kandidátů a urychluje spojení.

Zpracování ICE událostí v mobilní aplikaci

Klíčové ICE události, které by měl vývojář zpracovávat: stav ICE spojení (ICE connection state), změna stavu shromažďování (ICE gathering state) a detekce nového kandidáta. Poté, co ICE dokončí shromažďování a testování, přejde jeho stav do connected nebo completed.

V mobilních sítích často dochází k přepínání mezi WiFi a mobilním připojením. Při změně sítě musí ICE provést restart, jinak je mediální tok přerušen. Vývojáři implementují monitorování NetworkManager (iOS) nebo ConnectivityManager (Android) pro automatické volání restartIce().

Úspěšná implementace ICE v mobilní aplikaci zahrnuje: výběr spolehlivých STUN/TURN serverů, správné zpracování ICE restart při změně sítě, konfiguraci iceConnectionState pro zobrazení stavu spojení v UI a monitorování statistik přes RTCStatsReport.