ICE Candidate: vad är det, typer av kandidater och hur det fungerar

Vad är ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — är en grundläggande enhet i processen att upprätta en P2P-anslutning via WebRTC-protokollet. Den representerar ett par av IP-adress + port som kan användas för dataöverföring mellan två peers. Varje kandidat innehåller information om transportprotokoll (UDP, TCP), anslutningstyp och prioritet.

ICE Candidate bildas på varje enhet separat. Enheten samlar in alla tillgängliga nätverksgränssnitt, begär den externa adressen via en STUN-server och lägger till en reläadress från TURN-servern. Den resulterande listan över kandidater skickas till den fjärranslutna peern via signaleringskanalen i SDP-format (Session Description Protocol).

Enligt specifikationen RFC 8445 (IETF, 2018) använder ICE mekanismen nominated pairs: efter insamling av alla kandidater genomförs parvis testning via STUN-förfrågningar. Det första paret som klarar testet förklaras nominated (utsedd) och används för multimediaöverföring. De återstående paren finns kvar i reserv ifall anslutningen bryts.

ICE:s roll i WebRTC-stacken

WebRTC — är en öppen standard för P2P-kommunikation, men direkt anslutning mellan enheter är ofta omöjlig på grund av NAT (Network Address Translation) och brandväggar. ICE Candidate löser detta problem genom att erbjuda flera alternativa anslutningsvägar. ICE-protokollet (Interactive Connectivity Establishment) är en obligatorisk komponent i WebRTC och beskrivs i W3C WebRTC-specifikationen (2025).

Många mobilapputvecklare använder WebRTC-bibliotek som Google WebRTC (för Android) och nativeskal för iOS. I var och en av dem hanteras ICE-processen automatiskt, men förståelse av kandidattyper gör det möjligt för utvecklaren att konfigurera serverinfrastrukturen och optimera anslutningskvaliteten.

SDP-format med ICE-kandidater

ICE Candidate överförs inom SDP-meddelandet som attribut a=candidate. Varje rad innehåller foundation, component ID, transportprotokoll, prioritet, IP-adress, port och kandidattyp. Nedan ges ett exempel på ett SDP-fragment med tre kandidater av olika typer:

// Exempel på SDP med ICE-kandidater
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

Fältet priority bestämmer ordningen för testning av kandidater. Ju högre prioritet, desto tidigare kommer kandidaten att kontrolleras. Host-kandidater har alltid högst prioritet och relay lägst.

Typer av ICE-kandidater

Specifikationen RFC 8445 definierar fyra typer av ICE-kandidater, som var och en motsvarar ett specifikt sätt att nå den fjärranslutna peern. Kandidattypen påverkar dess prioritet, tid för att upprätta anslutning och krav på serverinfrastruktur.

Host-kandidater

Host-kandidat bildas från IP-adressen för enhetens lokala nätverksgränssnitt. Om enheten befinner sig i samma lokala nätverk som peern, ger host-kandidaten en direkt anslutning med minimal fördröjning. För mobila enheter genereras host-kandidater för WiFi-gränssnittet, mobil LTE/5G-anslutning och vid behov för VPN-tunnlar.

Host-kandidater har högst prioritet (2130706431 för UDP) och testas först. Om båda peers befinner sig bakom NAT kommer deras host-kandidater att vara privata adresser (192.168.x.x, 10.x.x.x) och direkt anslutning via dem är omöjlig. ICE går över till att testa srflx- och relay-kandidater.

SRFLX- och PRFLX-kandidater

SRFLX (Server Reflexive) — är den externa IP-adressen och porten som erhålls från STUN-servern. När enheten skickar en STUN-förfrågan ser servern dess publika adress efter NAT och returnerar den. Denna kandidat möjliggör direkt anslutning mellan peers bakom olika NAT:er, om deras NAT-enheter stöder Hairpinning.

PRFLX (Peer Reflexive) upptäcks dynamiskt när en STUN-förfrågan från en peer anländer till en oväntad adress. Denna typ uppstår när båda peers skickar förfrågningar samtidigt och NAT skapar en tillfällig bindning. PRFLX-kandidaten har högre prioritet än srflx men lägre än host.

I mobilapplikationer är srflx-kandidater särskilt viktiga vid växling mellan WiFi och mobilnät. När enheten byter nätverk ändras IP-adressen och ICE måste samla in kandidaterna på nytt. Denna process kallas ICE restart och kräver att ett nytt SDP skickas på nytt.

Relay-kandidater via TURN

Relay-kandidat — är en adress på TURN-servern genom vilken trafik vidarebefordras från en peer till en annan. Denna typ används som en reservoption när direkt P2P-anslutning är omöjlig (symmetrisk NAT, företagsbrandvägg). Reläkanalen tillför fördröjning och ökar serverbelastningen, därför används TURN-servern i optimala inställningar endast för 10–15% av alla sessioner.

Populära implementationer av TURN-servrar: coturn (öppen källkod), Twilio Network Traversal, Metered TURN. Valet av TURN-leverantör påverkar kvaliteten på mediaanslutningen i mobilapplikationer — servern bör vara geografiskt nära användarna för att minimera ytterligare fördröjning.

Hur ICE-processen fungerar

ICE-processen — är ett flerstegsprotokoll som garanterar upprättandet av en pålitlig P2P-anslutning under förhållanden med osäker nätverkstopologi. Algoritmen beskrivs i RFC 8445 och omfattar fyra obligatoriska faser: insamling av kandidater, sortering, testning och nominering.

Fas 1: insamling av kandidater

Varje enhet samlar in alla tillgängliga nätverksadresser. För detta räknar WebRTC-motorn upp lokala gränssnitt (host), skickar en förfrågan till STUN-servern (srflx) och begär en reläadress från TURN-servern (relay). Samtidigt kan enheten upptäcka en prflx-kandidat om den tar emot en inkommande STUN-förfrågan från peern.

I mobil utveckling är denna fas kritisk för tiden att upprätta anslutning. På iOS och Android kan insamling av kandidater ta från 200 ms till 2 sekunder, beroende på nätverkshastighet, tillgänglighet av STUN/TURN-servrar och antalet aktiva nätverksgränssnitt.

Fas 2: bildande av par och sortering

Efter att ha tagit emot listan över kandidater från den fjärranslutna peern via signaleringskanalen, bildar den lokala ICE-motorn alla möjliga par av kandidater (lokal + fjärr). Varje par får en prioritet enligt formeln från RFC 8445, som tar hänsyn till båda kandidaternas prioriteter och riktning (inkommande/utgående).

Paren sorteras i fallande prioritetsordning. De bästa paren testas först. Algoritmen garanterar att host-host-paret kontrolleras före host-srflx, host-relay eller relay-relay, vilket minimerar anslutningsfördröjningen i enkla nätverkskonfigurationer.

Fas 3: testning och nominering

ICE skickar STUN-binding-förfrågningar för varje par av kandidater. Om ett STUN-svar tas emot är paret giltigt. Det första giltiga paret nomineras (nominated) som primärt. WebRTC-motorn börjar överföra media via detta par, medan de återstående paren fortsätter att kontrolleras ifall det primära skulle misslyckas.

Testningsprocessen kan ta upp till flera sekunder vid ett stort antal kandidater. WebRTC använder timer: för host-par en aggressiv timer (20 ms), för relay — en mer konservativ (200 ms). Mobilapputvecklare kan påskynda anslutningen genom att begränsa antalet ICE-servrar eller konfigurera iceTransportPolicy.

ICE Restart

ICE restart — är en omstart av ICE-processen utan att återskapa hela RTCPeerConnection. Den är nödvändig vid nätverksförändring, förlust av anslutning eller växling mellan WiFi och mobilnät. Vid omstart återställs alla nuvarande kandidater och processen börjar om med generering av ny ufrag och pwd.

I iOS-utveckling anropas ICE restart med metoden restartIce() på RTCPeerConnection. På Android används en liknande metod i klassen PeerConnection från Google WebRTC. Korrekt hantering av ICE restart — ett kritiskt krav för applikationer som körs på mobila enheter med instabil nätverksanslutning.

STUN och TURN-servrar i ICE

STUN (Session Traversal Utilities for NAT) och TURN (Traversal Using Relays around NAT) — är viktiga serverkomponenter utan vilka ICE Candidate inte kan garantera en framgångsrik anslutning under verkliga internetförhållanden. Deras korrekta konfiguration påverkar direkt samtalskvaliteten i mobilapplikationer.

STUN: upptäckt av extern adress

STUN-servern gör det möjligt för enheten att få reda på sin publika IP-adress och den port som NAT har tilldelat för den utgående anslutningen. STUN-protokollet definieras i RFC 8489 och fungerar över UDP på port 3478 och stöder även TCP. Google tillhandahåller publika STUN-servrar (stun.l.google.com:19302) som kan användas gratis.

I mobil utveckling är en STUN-förfrågan — en lätt operation som tar 50–200 ms. Vissa företags- och mobila nätverk blockerar dock UDP-trafik, vilket tvingar ICE att använda TCP för STUN-kommunikation eller gå direkt till TURN.

TURN: vidarebefordring av trafik

TURN-servern — är en vidarebefordrare av medietrafik. När direkt P2P-anslutning är omöjlig (symmetrisk NAT, brandvägg) skickar enheten data till TURN, som vidarebefordrar dem till den andra peern. TURN är en pålitlig men kostsam mekanism: den tillför fördröjning (30–100 ms) och kräver bandbredd på servern som är lika med summan av alla mediasessioner.

Enligt WebRTC Stats Report (2025) kräver cirka 8–15% av WebRTC-sessioner i mobila nätverk TURN. För att optimera kostnaderna för TURN-trafik använder utvecklare preliminär testning av anslutningen och aktiverar endast TURN-kanalen vid P2P-misslyckande.

Val av STUN/TURN för mobilapplikation

Vid val av infrastruktur för ICE i ett mobilprojekt beaktas: geografisk placering av servrar för att minimera fördröjning, stöd för UDP och TCP, kostnad för TURN-trafik och SLA. Populära lösningar: coturn för självinstallation, Twilio, Agora och LiveKit för molnanvändning.

ICE Candidate i mobil utveckling

För mobila utvecklare går förståelsen av ICE Candidate bortom teorin — det är en praktisk nödvändighet när man skapar applikationer med röst- och videosamtal. Plattformarna iOS och Android tillhandahåller inbyggda API:er för WebRTC som automatiserar arbetet med ICE, men utvecklaren ansvarar för konfigurationen av ICE-servrar och hantering av nätverksförändringshändelser.

Konfiguration av ICE på iOS

På iOS är WebRTC tillgängligt via ramverket WebRTC.framework eller biblioteket GoogleWebRTC via CocoaPods. ICE-servrar konfigureras via arrayen RTCIceServer i 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)

Efter att ha skapat RTCPeerConnection och anropat offer() eller answer() samlar motorn automatiskt in ICE-kandidater. Händelsen iceGatheringStateChange meddelar om förändring av insamlingsstatus och iceConnectionState om anslutningsstatus.

Konfiguration av ICE på Android

Android använder samma Google WebRTC-bibliotek. ICE-servrar ställs in via PeerConnection.RTCConfiguration. Utvecklaren kan hantera ICE-policy via iceTransportsType — relay-läge tvingar användning av endast TURN, vilket ökar tillförlitligheten men också fördröjningen:

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

Parametern bundlePolicy påverkar antalet ICE-kandidater — MAXBUNDLE-läget slår samman alla mediaströmmar till en transport, vilket minskar det totala antalet kandidater och påskyndar anslutningen.

Hantering av ICE-händelser i mobilapplikationen

De viktigaste ICE-händelserna som utvecklaren bör hantera: ICE-anslutningsstatus (ICE connection state), förändring av insamlingsstatus (ICE gathering state) och upptäckt av ny kandidat. När ICE har slutfört insamling och testning övergår dess status till connected eller completed.

I mobila nätverk förekommer ofta växlingar mellan WiFi och mobil anslutning. Vid nätverksförändring måste ICE utföra en omstart, annars avbryts mediaströmmen. Utvecklare implementerar övervakning av NetworkManager (iOS) eller ConnectivityManager (Android) för automatisk anropning av restartIce().

Framgångsrik implementering av ICE i en mobilapplikation omfattar: val av pålitliga STUN/TURN-servrar, korrekt hantering av ICE restart vid nätverksförändring, konfiguration av iceConnectionState för visning av anslutningsstatus i användargränssnittet och övervakning av statistik via RTCStatsReport.