1. Introduction (Einführung)

RFC 3264 [RFC3264] definiert einen zweiphasigen Austausch von Session Description Protocol (SDP)-Nachrichten [RFC4566] zum Zwecke des Aufbaus von Multimedia-Sitzungen. Dieser Offer/Answer-Mechanismus wird von Protokollen wie dem Session Initiation Protocol (SIP) [RFC3261] verwendet.

Protokolle, die Offer/Answer verwenden, sind schwer über Network Address Translators (NATs) zu betreiben. Da ihr Zweck darin besteht, einen Fluss von Medienpaketen aufzubauen, neigen sie dazu, die IP-Adressen und Ports von Medienquellen und -senken in ihren Nachrichten zu übertragen, was bekanntermaßen bei NAT problematisch ist [RFC3235]. Die Protokolle versuchen auch, einen Medienfluss direkt zwischen den Teilnehmern zu erstellen, so dass es keinen Vermittler auf Anwendungsebene zwischen ihnen gibt. Dies geschieht, um die Medienlatenz zu verringern, Paketverluste zu reduzieren und die Betriebskosten für die Bereitstellung der Anwendung zu senken. Dies ist jedoch über NAT schwer zu erreichen. Eine vollständige Behandlung der Gründe hierfür sprengt den Rahmen dieser Spezifikation.

Es wurden zahlreiche Lösungen definiert, um den Betrieb dieser Protokolle über NAT zu ermöglichen. Dazu gehören Application Layer Gateways (ALGs), das Middlebox Control Protocol [RFC3303], die ursprüngliche Spezifikation Simple Traversal of UDP Through NAT (STUN) [RFC3489] und Realm Specific IP [RFC3102] [RFC3103] sowie Session Description-Erweiterungen, die erforderlich sind, damit sie funktionieren, wie z. B. das Session Description Protocol (SDP) [RFC4566]-Attribut für das Real Time Control Protocol (RTCP) [RFC3605]. Leider haben alle diese Techniken Vor- und Nachteile, die jede einzelne in einigen Netzwerktopologien optimal machen, in anderen jedoch eine schlechte Wahl darstellen. Das Ergebnis ist, dass Administratoren und Implementierer Annahmen über die Topologien der Netzwerke treffen, in denen ihre Lösungen bereitgestellt werden. Dies führt zu Komplexität und Sprödigkeit im System. Was benötigt wird, ist eine einzige Lösung, die flexibel genug ist, um in allen Situationen gut zu funktionieren.

Diese Spezifikation definiert Interactive Connectivity Establishment (ICE) als Technik zur NAT-Überquerung für UDP-basierte Medienströme (obwohl ICE erweitert werden kann, um andere Transportprotokolle wie TCP [ICE-TCP] zu handhaben), die durch das Offer/Answer-Modell aufgebaut wurden. ICE ist eine Erweiterung des Offer/Answer-Modells und funktioniert durch Einbeziehung einer Vielzahl von IP-Adressen und Ports in SDP-Angebote und -Antworten, die dann durch Peer-to-Peer-Konnektivitätsprüfungen auf Konnektivität getestet werden. Die in das SDP aufgenommenen IP-Adressen und Ports sowie die Konnektivitätsprüfungen werden unter Verwendung der überarbeiteten STUN-Spezifikation [RFC5389] durchgeführt, die nun in Session Traversal Utilities for NAT umbenannt wurde. Der neue Name und die neue Spezifikation spiegeln ihre neue Rolle als Werkzeug wider, das mit anderen NAT-Überquerungstechniken (nämlich ICE) verwendet wird, anstatt eine eigenständige NAT-Überquerungslösung zu sein, wie es die ursprüngliche STUN-Spezifikation war. ICE nutzt auch Traversal Using Relays around NAT (TURN) [RFC5766], eine Erweiterung von STUN. Da ICE für jeden Medienstream eine Vielzahl von IP-Adressen und Ports austauscht, ermöglicht es auch die Adressauswahl für Multihomed- und Dual-Stack-Hosts, weshalb es RFC 4091 [RFC4091] und [RFC4092] ablöst.