ICE Candidate: mi ez, a jelöltek típusai és hogyan működik

Mi az ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — egy alapvető egység a P2P kapcsolat létrehozásának folyamatában a WebRTC protokollon keresztül. Egy IP-cím + port párost képvisel, amely két társ közötti adatátvitelre használható. Minden jelölt tartalmaz információt a szállítási protokollról (UDP, TCP), a kapcsolat típusáról és a prioritásról.

Az ICE Candidate minden eszközön külön-külön jön létre. Az eszköz összegyűjti az összes elérhető hálózati interfészt, lekéri a külső címet egy STUN szerveren keresztül, és hozzáadja a közvetítő címet a TURN szervertől. Az így kapott jelöltlista SDP (Session Description Protocol) formátumban kerül elküldésre a távoli társnak a jelzőcsatornán keresztül.

Az RFC 8445 (IETF, 2018) specifikáció szerint az ICE a nominated pairs mechanizmust használja: az összes jelölt összegyűjtése után páronkénti tesztelés történik STUN kérésekkel. Az első sikeresen tesztelt pár nominated (kijelölt) lesz, és a multimédia továbbítására használják. A többi pár tartalékban marad a kapcsolat megszakadása esetére.

Az ICE szerepe a WebRTC veremben

A WebRTC — egy nyílt szabvány a P2P kommunikációhoz, de a közvetlen kapcsolat az eszközök között gyakran lehetetlen a NAT (Network Address Translation) és a tűzfalak miatt. Az ICE Candidate több alternatív kapcsolódási útvonalat kínálva oldja meg ezt a problémát. Az ICE (Interactive Connectivity Establishment) protokoll a WebRTC kötelező összetevője, és a W3C WebRTC (2025) specifikáció írja le.

Sok mobilalkalmazás-fejlesztő használ WebRTC könyvtárakat, mint a Google WebRTC (Androidhoz) és natív burkolók iOS-hez. Mindegyikben az ICE folyamat automatikusan zajlik, de a jelölttípusok megértése lehetővé teszi a fejlesztő számára a szerver-infrastruktúra konfigurálását és a kapcsolat minőségének optimalizálását.

SDP formátum ICE jelöltekkel

Az ICE Candidate SDP üzenet részeként kerül továbbításra a=candidate attribútumok formájában. Minden sor tartalmaz foundation, component ID, szállítási protokoll, prioritás, IP-cím, port és jelölt típust. Az alábbiakban egy SDP részlet látható három különböző típusú jelölttel:

// Példa SDP ICE jelöltekkel
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

A priority mező határozza meg a jelöltek tesztelésének sorrendjét. Minél magasabb a prioritás, annál korábban kerül ellenőrzésre a jelölt. A host jelöltek mindig a legmagasabb, a relay pedig a legalacsonyabb prioritással rendelkeznek.

Az ICE jelöltek típusai

Az RFC 8445 specifikáció négy típust határoz meg az ICE jelöltek számára, amelyek mindegyike a távoli társ elérésének egy meghatározott módjának felel meg. A jelölt típusa befolyásolja a prioritását, a kapcsolat létrehozásának idejét és a szerver-infrastruktúrával szembeni követelményeket.

Host jelöltek

Host jelölt az eszköz helyi hálózati interfészének IP-címéből jön létre. Ha az eszköz ugyanabban a helyi hálózatban van, mint a társ, a host jelölt közvetlen kapcsolatot biztosít minimális késleltetéssel. Mobileszközök esetén a host jelöltek a WiFi interfészhez, a mobil LTE/5G kapcsolathoz és szükség esetén a VPN alagutakhoz jönnek létre.

A host jelöltek rendelkeznek a legmagasabb prioritással (2130706431 UDP esetén), és elsőként kerülnek tesztelésre. Ha mindkét társ NAT mögött van, a host jelöltjeik privát címek lesznek (192.168.x.x, 10.x.x.x), és a közvetlen kapcsolat rajtuk keresztül lehetetlen. Az ICE áttér az srflx és relay jelöltek tesztelésére.

SRFLX és PRFLX jelöltek

SRFLX (Server Reflexive) — a STUN szervertől kapott külső IP-cím és port. Amikor az eszköz STUN kérést küld, a szerver látja a NAT utáni nyilvános címét, és visszaküldi azt. Ez a jelölt lehetővé teszi a közvetlen kapcsolat létrehozását különböző NAT mögötti társak között, ha a NAT eszközeik támogatják a Hairpinninget.

PRFLX (Peer Reflexive) dinamikusan észlelhető, amikor egy társ STUN kérése váratlan címre érkezik. Ez a típus akkor jön létre, amikor mindkét társ egyszerre küld kéréseket, és a NAT ideiglenes kötést hoz létre. A PRFLX jelölt magasabb prioritással rendelkezik, mint az srflx, de alacsonyabbal, mint a host.

A mobilalkalmazásokban az srflx jelöltek különösen fontosak a WiFi és a mobil hálózat közötti váltáskor. Amikor az eszköz hálózatot vált, az IP-cím megváltozik, és az ICE-nek újra kell gyűjtenie a jelölteket. Ezt a folyamatot ICE restart-nak hívják, és új SDP újraküldését igényli.

Relay jelöltek TURN-on keresztül

Relay jelölt — egy cím a TURN szerveren, amelyen keresztül a forgalom az egyik társról a másikra közvetítődik. Ez a típus tartalék lehetőségként szolgál, amikor a közvetlen P2P kapcsolat lehetetlen (szimmetrikus NAT, vállalati tűzfal). A közvetítő csatorna késleltetést ad hozzá és növeli a szerver terhelését, ezért optimális beállításoknál a TURN szerver csak az összes munkamenet 10–15%-ában kerül használatra.

Népszerű TURN szerver implementációk: coturn (nyílt forráskódú), Twilio Network Traversal, Metered TURN. A TURN szolgáltató kiválasztása befolyásolja a média kapcsolat minőségét a mobilalkalmazásokban — a szervernek földrajzilag közel kell lennie a felhasználókhoz a további késleltetés minimalizálása érdekében.

Hogyan működik az ICE folyamat

Az ICE folyamat — egy többlépcsős protokoll, amely garantálja a megbízható P2P kapcsolat létrejöttét a hálózati topológia bizonytalanságának körülményei között. Az algoritmust az RFC 8445 írja le, és négy kötelező fázist foglal magában: jelöltek gyűjtése, rendezés, tesztelés és kijelölés.

1. fázis: jelöltek gyűjtése

Minden eszköz összegyűjti az összes elérhető hálózati címet. Ehhez a WebRTC motor felsorolja a helyi interfészeket (host), kérést küld a STUN szerverre (srflx), és közvetítő címet kér a TURN szervertől (relay). Ezzel egyidejűleg az eszköz észlelhet egy prflx jelöltet, ha bejövő STUN kérést kap a társról.

A mobilfejlesztésben ez a fázis kritikus a kapcsolat létrehozásának ideje szempontjából. iOS-en és Androidon a jelöltek gyűjtése a hálózati sebességtől, a STUN/TURN szerverek elérhetőségétől és az aktív hálózati interfészek számától függően 200 ms-tól 2 másodpercig tarthat.

2. fázis: párok képzése és rendezés

Miután a távoli társ jelöltlistája megérkezett a jelzőcsatornán keresztül, a helyi ICE motor létrehozza az összes lehetséges jelöltpárt (helyi + távoli). Minden pár prioritást kap az RFC 8445 képlete szerint, amely figyelembe veszi mindkét jelölt prioritását és az irányt (incoming/outgoing).

A párok prioritás szerint csökkenő sorrendbe rendeződnek. A legjobb párok kerülnek először tesztelésre. Az algoritmus garantálja, hogy a host-host pár előbb kerül ellenőrzésre, mint a host-srflx, host-relay vagy relay-relay, minimalizálva a kapcsolat késleltetését egyszerű hálózati konfigurációkban.

3. fázis: tesztelés és kijelölés

Az ICE STUN-kötési kéréseket küld minden jelöltpárnak. Ha STUN válasz érkezik — a pár érvényes. Az első érvényes pár kijelölésre (nominated) kerül elsődlegesként. A WebRTC motor megkezdi a média továbbítását ezen a páron keresztül, a többi pár továbbra is ellenőrzés alatt marad az elsődleges meghibásodása esetére.

A tesztelési folyamat akár több másodpercig is eltarthat nagyszámú jelölt esetén. A WebRTC időzítőket használ: a host párokhoz agresszív időzítőt (20 ms), a relay-hez konzervatívabbat (200 ms). A mobilalkalmazás-fejlesztők az ICE szerverek számának korlátozásával vagy az iceTransportPolicy konfigurálásával gyorsíthatják a kapcsolatot.

ICE Restart

ICE restart — az ICE folyamat újraindítása a teljes RTCPeerConnection újbóli létrehozása nélkül. Hálózatváltáskor, kapcsolat megszakadásakor vagy WiFi és mobilhálózat közötti váltáskor szükséges. A restart során az összes aktuális jelölt nullázódik, és a folyamat új ufrag és pwd generálásával kezdődik elölről.

Az iOS fejlesztésben az ICE restart a restartIce() metódussal hívható meg a RTCPeerConnection-ön. Androidon a Google WebRTC PeerConnection osztályának hasonló metódusa használható. Az ICE restart helyes kezelése — kritikus követelmény az instabil hálózati kapcsolattal rendelkező mobileszközökön futó alkalmazások számára.

STUN és TURN szerverek az ICE-ben

STUN (Session Traversal Utilities for NAT) és TURN (Traversal Using Relays around NAT) — kulcsfontosságú szerver-összetevők, amelyek nélkül az ICE Candidate nem tudja garantálni a sikeres kapcsolatot valós internetes körülmények között. Helyes konfigurálásuk közvetlenül befolyásolja a hívás minőségét a mobilalkalmazásokban.

STUN: külső cím észlelése

A STUN szerver lehetővé teszi az eszköz számára, hogy megtudja nyilvános IP-címét és azt a portot, amelyet a NAT a kimenő kapcsolathoz kiosztott. A STUN protokollt az RFC 8489 határozza meg, és UDP-n keresztül működik a 3478-as porton, valamint támogatja a TCP-t is. A Google nyilvános STUN szervereket biztosít (stun.l.google.com:19302), amelyek ingyenesen használhatók.

A mobilfejlesztésben a STUN kérés — könnyű művelet, amely 50–200 ms-ig tart. Egyes vállalati és mobil hálózatok azonban blokkolják az UDP forgalmat, kényszerítve az ICE-t, hogy TCP-t használjon a STUN kommunikációhoz, vagy közvetlenül a TURN-ra váltson.

TURN: forgalom továbbítása

A TURN szerver — a médiaforgalom továbbítója. Amikor a közvetlen P2P kapcsolat lehetetlen (szimmetrikus NAT, tűzfal), az eszköz adatokat küld a TURN-nak, amely továbbítja azokat a másik társnak. A TURN megbízható, de költséges mechanizmus: késleltetést ad hozzá (30–100 ms), és a szerver sávszélességét igényli, amely megegyezik az összes média munkamenet összegével.

A WebRTC Stats Report (2025) szerint a mobilhálózatokban a WebRTC-munkamenetek körülbelül 8–15%-a igényel TURN-t. A TURN forgalom költségeinek optimalizálása érdekében a fejlesztők előzetes kapcsolattesztelést alkalmaznak, és csak P2P sikertelenség esetén aktiválják a TURN csatornát.

STUN/TURN kiválasztása mobilalkalmazáshoz

A mobilprojekt ICE infrastruktúrájának kiválasztásakor figyelembe veszik: a szerverek földrajzi elhelyezkedését a késleltetés minimalizálása érdekében, az UDP és TCP támogatását, a TURN forgalom költségét és az SLA-t. Népszerű megoldások: coturn önálló telepítéshez, Twilio, Agora és LiveKit felhőalapú használathoz.

ICE Candidate a mobilfejlesztésben

A mobilfejlesztők számára az ICE Candidate megértése túlmutat az elméleten — gyakorlati szükségszerűség a hang- és videohívásokat tartalmazó alkalmazások létrehozásakor. Az iOS és Android platformok natív API-kat biztosítanak a WebRTC-hez, amelyek automatizálják az ICE-vel való munkát, de a fejlesztő felelős az ICE szerverek konfigurálásáért és a hálózatváltozási események kezeléséért.

ICE konfigurálása iOS-en

iOS-en a WebRTC a WebRTC.framework keretrendszeren vagy a GoogleWebRTC könyvtáron keresztül érhető el CocoaPods segítségével. Az ICE szerverek a RTCIceServer tömbben konfigurálhatók a RTCConfiguration-ban:

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)

A RTCPeerConnection létrehozása és az offer() vagy answer() meghívása után a motor automatikusan összegyűjti az ICE jelölteket. Az iceGatheringStateChange esemény a gyűjtés állapotának változásáról, az iceConnectionState pedig a kapcsolat állapotáról tájékoztat.

ICE konfigurálása Androidon

Az Android ugyanazt a Google WebRTC könyvtárat használja. Az ICE szerverek a PeerConnection.RTCConfiguration-on keresztül állíthatók be. A fejlesztő az ICE irányelveket az iceTransportsType segítségével kezelheti — a relay mód kizárólag a TURN használatát kényszeríti ki, ami növeli a megbízhatóságot, de a késleltetést is:

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

A bundlePolicy paraméter befolyásolja az ICE jelöltek számát — a MAXBUNDLE mód egyetlen szállításba egyesíti az összes médiafolyamot, csökkentve a jelöltek teljes számát és gyorsítva a kapcsolatot.

ICE események kezelése mobilalkalmazásban

A legfontosabb ICE események, amelyeket a fejlesztőnek kezelnie kell: ICE kapcsolat állapota (ICE connection state), a gyűjtési állapot változása (ICE gathering state) és új jelölt észlelése. Miután az ICE befejezte a gyűjtést és a tesztelést, az állapota connected vagy completed értékre vált.

A mobilhálózatokban gyakran történnek váltások a WiFi és a mobil kapcsolat között. Hálózatváltáskor az ICE-nek restartot kell végrehajtania, különben a médiafolyam megszakad. A fejlesztők NetworkManager (iOS) vagy ConnectivityManager (Android) figyelést implementálnak a restartIce() automatikus meghívásához.

Az ICE sikeres implementációja egy mobilalkalmazásban magában foglalja: megbízható STUN/TURN szerverek kiválasztását, az ICE restart helyes kezelését hálózatváltáskor, az iceConnectionState konfigurálását a kapcsolat állapotának UI-ban történő megjelenítéséhez és a statisztikák figyelését az RTCStatsReport segítségével.