ICE (Interactive Connectivity Establishment) ist ein Framework, das automatisch den besten Weg für eine Verbindung zwischen zwei Geräten findet — auch wenn beide hinter NAT-Routern und Firewalls liegen. Es koordiniert dabei die Verfahren STUN und TURN und ist das Herzstück des Verbindungsaufbaus bei WebRTC. Die aktuelle Spezifikation ist RFC 8445 (2018).
Kandidaten sammeln
Jedes Gerät stellt zunächst alle erreichbaren eigenen Adressen zusammen, die ICE-Kandidaten:
- Host-Kandidat: die lokale IP-Adresse im eigenen Netz (zum Beispiel 192.168.1.20).
- Server-Reflexiv-Kandidat (srflx): die öffentliche Adresse, die ein STUN-Server zurückspiegelt.
- Relay-Kandidat: die Adresse, die ein TURN-Server als Relay vergibt.
Verbindung prüfen und wählen
Beide Seiten tauschen ihre Kandidatenlisten über den Signalisierungskanal aus (zum Beispiel WebSocket oder SIP). Danach testet ICE alle sinnvollen Paare parallel mit STUN-Binding-Requests — die Connectivity Checks. Das erste erfolgreich getestete Paar wird genommen (Nomination), wobei direkte Wege Vorrang haben: Host vor Server-Reflexiv vor Relay, weil der Umweg über TURN Latenz und Bandbreite kostet. Während der Checks entdeckte zusätzliche Adressen heißen Peer-Reflexiv-Kandidaten.
Praxis
ICE läuft in WebRTC automatisch ab, sobald eine RTCPeerConnection erzeugt wird. Moderne Implementierungen nutzen Trickle ICE (RFC 8838): Kandidaten werden nicht erst gesammelt und dann geschlossen übertragen, sondern nach und nach verschickt, sobald sie gefunden werden — das verkürzt den Verbindungsaufbau spürbar. Auch SIP-Softphones setzen ICE ein, um Medienströme über UDP zuverlässig durch NAT zu bringen.