ICE Candidate: was es ist, Kandidatentypen und wie es funktioniert

Was ist ein ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) ist eine grundlegende Einheit im Prozess des Aufbaus einer P2P-Verbindung über das WebRTC-Protokoll. Es stellt ein Paar aus IP-Adresse + Port dar, das für die Datenübertragung zwischen zwei Peers verwendet werden kann. Jeder Kandidat enthält Informationen über das Transportprotokoll (UDP, TCP), den Verbindungstyp und die Priorität.

Ein ICE Candidate wird auf jedem Gerät separat generiert. Das Gerät sammelt alle verfügbaren Netzwerkschnittstellen, fordert eine externe Adresse über einen STUN-Server an und fügt eine Relay-Adresse von einem TURN-Server hinzu. Die resultierende Kandidatenliste wird über einen Signalisierungskanal im SDP-Format (Session Description Protocol) an den entfernten Peer gesendet.

Gemäß der Spezifikation RFC 8445 (IETF, 2018) verwendet ICE einen Mechanismus nominierter Paare: Nach dem Sammeln aller Kandidaten werden diese paarweise durch STUN-Anfragen getestet. Das Paar, das die Prüfung zuerst besteht, wird als nominiert erklärt und für die Multimedia-Übertragung verwendet. Die übrigen Paare bleiben für den Fall einer Verbindungsunterbrechung in Reserve.

Die Rolle von ICE im WebRTC-Stack

WebRTC ist ein offener Standard für P2P-Kommunikation, aber eine direkte Verbindung zwischen Geräten ist aufgrund von NAT (Network Address Translation) und Firewalls oft nicht möglich. ICE Candidate löst dieses Problem, indem es mehrere alternative Verbindungspfade anbietet. Das ICE-Protokoll (Interactive Connectivity Establishment) ist ein obligatorischer Bestandteil von WebRTC und in der W3C WebRTC-Spezifikation (2025) beschrieben.

Viele Entwickler mobiler Anwendungen verwenden WebRTC-Bibliotheken wie Google WebRTC (für Android) und native Wrapper für iOS. In jeder von ihnen wird der ICE-Prozess automatisch verwaltet, aber das Verständnis der Kandidatentypen ermöglicht es dem Entwickler, die Serverinfrastruktur zu konfigurieren und die Verbindungsqualität zu optimieren.

SDP-Format mit ICE Kandidaten

Ein ICE Candidate wird innerhalb einer SDP-Nachricht als a=candidate-Attribute übertragen. Jede Zeile enthält Foundation, Component ID, Transportprotokoll, Priorität, IP-Adresse, Port und Kandidatentyp. Nachfolgend ein Beispiel eines SDP-Fragments mit drei Kandidaten verschiedener Typen:

// Beispiel SDP mit ICE-Kandidaten
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

Das Feld priority bestimmt die Reihenfolge der Kandidatentests. Je höher die Priorität, desto früher wird der Kandidat überprüft. Host-Kandidaten haben immer die höchste Priorität, Relay-Kandidaten die niedrigste.

Arten von ICE Kandidaten

Die Spezifikation RFC 8445 definiert vier Typen von ICE-Kandidaten, die jeweils einer bestimmten Art des Erreichens eines entfernten Peers entsprechen. Der Kandidatentyp beeinflusst seine Priorität, die Verbindungsaufbauzeit und die Anforderungen an die Serverinfrastruktur.

Host-Kandidaten

Ein Host-Kandidat wird aus der IP-Adresse der lokalen Netzwerkschnittstelle des Geräts gebildet. Befindet sich das Gerät im selben lokalen Netzwerk wie ein Peer, bietet der Host-Kandidat eine direkte Verbindung mit minimaler Latenz. Für mobile Geräte werden Host-Kandidaten für die WiFi-Schnittstelle, die Mobilfunkverbindung LTE/5G und bei Bedarf für VPN-Tunnel generiert.

Host-Kandidaten haben die höchste Priorität (2130706431 für UDP) und werden zuerst getestet. Befinden sich beide Peers hinter NAT, sind ihre Host-Kandidaten private Adressen (192.168.x.x, 10.x.x.x) und eine direkte Verbindung über sie ist nicht möglich. ICE fährt dann mit dem Testen von srflx- und relay-Kandidaten fort.

SRFLX- und PRFLX-Kandidaten

Ein SRFLX (Server Reflexive)-Kandidat ist eine externe IP-Adresse und ein Port, die von einem STUN-Server bezogen wurden. Wenn ein Gerät eine STUN-Anfrage sendet, sieht der Server seine öffentliche Adresse hinter NAT und gibt sie zurück. Dieser Kandidat ermöglicht eine direkte Verbindung zwischen Peers hinter verschiedenen NATs, wenn deren NAT-Geräte Hairpinning unterstützen.

Ein PRFLX (Peer Reflexive)-Kandidat wird dynamisch erkannt, wenn eine STUN-Anfrage eines Peers an einer unerwarteten Adresse eintrifft. Dieser Typ tritt auf, wenn beide Peers gleichzeitig Anfragen senden und NAT eine temporäre Bindung erstellt. Ein PRFLX-Kandidat hat eine höhere Priorität als srflx, aber eine niedrigere als host.

In mobilen Anwendungen sind srflx-Kandidaten besonders wichtig beim Wechsel zwischen WiFi- und Mobilfunknetz. Wenn ein Gerät das Netzwerk wechselt, ändert sich die IP-Adresse und ICE muss die Kandidaten neu sammeln. Dieser Prozess wird als ICE-Neustart bezeichnet und erfordert das Senden eines neuen SDP.

Relay-Kandidaten über TURN

Ein Relay-Kandidat ist eine Adresse auf einem TURN-Server, über den Datenverkehr von einem Peer zum anderen weitergeleitet wird. Dieser Typ wird als Fallback verwendet, wenn eine direkte P2P-Verbindung nicht möglich ist (symmetrisches NAT, Unternehmensfirewall). Ein Relay-Kanal erhöht die Latenz und die Serverlast, daher wird der TURN-Server in optimalen Konfigurationen nur für 10–15% aller Sitzungen genutzt.

Beliebte TURN-Server-Implementierungen: coturn (Open Source), Twilio Network Traversal, Metered TURN. Die Wahl des TURN-Anbieters beeinflusst die Medienverbindungsqualität in mobilen Anwendungen — der Server sollte geografisch nahe an den Benutzern liegen, um zusätzliche Latenz zu minimieren.

Wie der ICE-Prozess funktioniert

Der ICE-Prozess ist ein mehrstufiges Protokoll, das den Aufbau einer zuverlässigen P2P-Verbindung unter Bedingungen der Netzwerktopologie-Unsicherheit garantiert. Der Algorithmus ist in RFC 8445 beschrieben und umfasst vier obligatorische Phasen: Kandidatensammlung, Sortierung, Test und Nominierung.

Phase 1: Kandidatensammlung

Jedes Gerät sammelt alle verfügbaren Netzwerkadressen. Dazu zählt die WebRTC-Engine lokale Schnittstellen auf (host), sendet eine Anfrage an einen STUN-Server (srflx) und fordert eine Relay-Adresse von einem TURN-Server an. Gleichzeitig kann das Gerät einen prflx-Kandidaten entdecken, wenn es eine eingehende STUN-Anfrage von einem Peer erhält.

In der mobilen Entwicklung ist diese Phase entscheidend für die Verbindungsaufbauzeit. Auf iOS und Android kann die Kandidatensammlung je nach Netzwerkgeschwindigkeit, Verfügbarkeit von STUN/TURN-Servern und Anzahl aktiver Netzwerkschnittstellen 200 ms bis 2 Sekunden dauern.

Phase 2: Paarbildung und Sortierung

Nach Erhalt der Kandidatenliste vom entfernten Peer über den Signalisierungskanal bildet die lokale ICE-Engine alle möglichen Kandidatenpaare (lokal + entfernt). Jedes Paar erhält eine Priorität gemäß der Formel aus RFC 8445, die die Prioritäten beider Kandidaten und die Richtung (eingehend/ausgehend) berücksichtigt.

Paare werden in absteigender Prioritätsreihenfolge sortiert. Die besten Paare werden zuerst getestet. Der Algorithmus garantiert, dass ein host-host-Paar vor host-srflx, host-relay oder relay-relay geprüft wird, wodurch Verbindungsverzögerungen in einfachen Netzwerkkonfigurationen minimiert werden.

Phase 3: Test und Nominierung

ICE sendet STUN-Bindungsanfragen für jedes Kandidatenpaar. Wenn eine STUN-Antwort empfangen wird, ist das Paar gültig. Das erste gültige Paar wird als primär nominiert. Die WebRTC-Engine beginnt mit der Medienübertragung über dieses Paar, während die übrigen Paare für den Fall des Primärausfalls weiter geprüft werden.

Der Testprozess kann bei einer großen Anzahl von Kandidaten bis zu mehreren Sekunden dauern. WebRTC verwendet Timer: für host-Paare ist der Timer aggressiv (20 ms), für relay-Paare konservativer (200 ms). Entwickler mobiler Anwendungen können die Verbindung beschleunigen, indem sie die Anzahl der ICE-Server begrenzen oder iceTransportPolicy konfigurieren.

ICE-Neustart

ICE-Neustart ist ein Neustart des ICE-Prozesses, ohne die gesamte RTCPeerConnection neu zu erstellen. Er ist beim Netzwerkwechsel, Verbindungsverlust oder Wechsel zwischen WiFi- und Mobilfunknetz erforderlich. Während eines Neustarts werden alle aktuellen Kandidaten verworfen und der Prozess beginnt mit der Generierung neuer ufrag und pwd von neuem.

In der iOS-Entwicklung wird der ICE-Neustart über die Methode restartIce() auf RTCPeerConnection aufgerufen. Auf Android wird eine ähnliche Methode in der Klasse PeerConnection von Google WebRTC verwendet. Die korrekte Behandlung des ICE-Neustarts ist eine kritische Anforderung für Anwendungen auf mobilen Geräten mit instabilen Netzwerkverbindungen.

STUN- und TURN-Server in ICE

STUN (Session Traversal Utilities for NAT) und TURN (Traversal Using Relays around NAT) sind wichtige Serverkomponenten, ohne die ICE Candidate unter realen Internetbedingungen keine erfolgreiche Konnektivität garantieren kann. Ihre richtige Konfiguration wirkt sich direkt auf die Anrufqualität in mobilen Anwendungen aus.

STUN: Erkennung der externen Adresse

Ein STUN-Server ermöglicht es einem Gerät, seine öffentliche IP-Adresse und den Port zu ermitteln, den NAT für die ausgehende Verbindung zugewiesen hat. Das STUN-Protokoll ist in RFC 8489 definiert und arbeitet über UDP auf Port 3478, unterstützt aber auch TCP. Google stellt öffentliche STUN-Server (stun.l.google.com:19302) zur Verfügung, die kostenlos genutzt werden können.

In der mobilen Entwicklung ist eine STUN-Anfrage eine leichte Operation, die 50–200 ms dauert. Einige Unternehmens- und Mobilfunknetze blockieren jedoch UDP-Datenverkehr, sodass ICE für die STUN-Kommunikation TCP verwenden oder direkt auf TURN zurückgreifen muss.

TURN: Datenverkehrsweiterleitung

Ein TURN-Server ist ein Medienverkehrs-Relay. Wenn eine direkte P2P-Verbindung nicht möglich ist (symmetrisches NAT, Firewall), sendet das Gerät Daten an TURN, der sie an den anderen Peer weiterleitet. TURN ist ein zuverlässiger, aber teurer Mechanismus: Er erhöht die Latenz (30–100 ms) und erfordert Serverbandbreite in Höhe der Summe aller Mediensitzungen.

Laut dem WebRTC Stats Report (2025) benötigen etwa 8–15% der WebRTC-Sitzungen in Mobilfunknetzen TURN. Zur Optimierung der TURN-Verkehrskosten verwenden Entwickler vorläufige Verbindungstests und aktivieren den TURN-Kanal nur bei P2P-Fehlschlag.

Auswahl von STUN/TURN für eine mobile Anwendung

Bei der Auswahl der Infrastruktur für ICE in einem Mobilprojekt werden berücksichtigt: geografische Lage der Server zur Minimierung der Latenz, UDP- und TCP-Unterstützung, Kosten des TURN-Verkehrs und SLA. Beliebte Lösungen umfassen: coturn für Selbsthosting, Twilio, Agora und LiveKit für Cloud-Nutzung.

ICE Candidate in der mobilen Entwicklung

Für mobile Entwickler geht das Verständnis von ICE Candidate über die Theorie hinaus — es ist eine praktische Notwendigkeit bei der Erstellung von Anwendungen mit Sprach- und Videoanrufen. Die Plattformen iOS und Android bieten native WebRTC-APIs, die die ICE-Verwaltung automatisieren, aber der Entwickler ist für die Konfiguration der ICE-Server und die Behandlung von Netzwerkwechselereignissen verantwortlich.

ICE-Konfiguration auf iOS

Auf iOS ist WebRTC über das Framework WebRTC.framework oder die Bibliothek GoogleWebRTC über CocoaPods verfügbar. ICE-Server werden über ein Array von RTCIceServer in RTCConfiguration konfiguriert:

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)

Nach dem Erstellen einer RTCPeerConnection und dem Aufruf von offer() oder answer() sammelt die Engine automatisch ICE-Kandidaten. Das Ereignis iceGatheringStateChange informiert über Änderungen des Sammelstatus, während iceConnectionState den Verbindungsstatus meldet.

ICE-Konfiguration auf Android

Android verwendet dieselbe Google WebRTC-Bibliothek. ICE-Server werden über PeerConnection.RTCConfiguration festgelegt. Der Entwickler kann die ICE-Richtlinie über iceTransportsType verwalten — der Relay-Modus verwendet erzwingend nur TURN, was die Zuverlässigkeit erhöht, aber die Latenz erhöht:

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

Der Parameter bundlePolicy beeinflusst die Anzahl der ICE-Kandidaten — der MAXBUNDLE-Modus kombiniert alle Medienströme in einem Transport, reduziert die Gesamtzahl der Kandidaten und beschleunigt die Verbindung.

Behandlung von ICE-Ereignissen in mobilen Anwendungen

Zu den wichtigsten ICE-Ereignissen, die ein Entwickler behandeln sollte, gehören: ICE-Verbindungsstatus, ICE-Sammelstatus und Erkennung neuer Kandidaten. Nachdem ICE die Sammlung und Tests abgeschlossen hat, wechselt sein Status zu connected oder completed.

In Mobilfunknetzen kommt es häufig zu Wechseln zwischen WiFi- und Mobilfunkverbindung. Wenn sich das Netzwerk ändert, muss ICE einen Neustart durchführen, andernfalls wird der Medienstrom unterbrochen. Entwickler implementieren die Überwachung von NetworkManager (iOS) oder ConnectivityManager (Android), um restartIce() automatisch aufzurufen.

Eine erfolgreiche ICE-Implementierung in einer mobilen Anwendung umfasst: Auswahl zuverlässiger STUN/TURN-Server, korrekte ICE-Neustart-Behandlung bei Netzwerkwechsel, Konfiguration von iceConnectionState für die UI-Statusanzeige und Überwachung von Statistiken über RTCStatsReport.