20. Operational Considerations (Betriebliche Überlegungen)

Dieser Abschnitt erörtert Probleme, die für Netzbetreiber relevant sind, die ICE einsetzen möchten.

20.1. NAT and Firewall Types (NAT- und Firewall-Typen)

ICE wurde entwickelt, um mit vorhandenen NAT- und Firewall-Geräten zu funktionieren. Folglich ist es nicht notwendig, vorhandene Firewall- und NAT-Geräte zu ersetzen oder neu zu konfigurieren, um den Einsatz von ICE zu erleichtern. Tatsächlich wurde ICE entwickelt, um in Umgebungen eingesetzt zu werden, in denen der Voice over IP (VoIP)-Betreiber keine Kontrolle über die IP-Netzwerkinfrastruktur hat, einschließlich Firewalls und NAT.

Dennoch funktioniert ICE am besten in Umgebungen, in denen die NAT-Geräte "behave"-konform sind und die in [RFC4787] und [RFC5766] definierten Empfehlungen erfüllen. In Netzwerken mit behave-konformem NAT funktioniert ICE ohne die Notwendigkeit eines TURN-Servers, wodurch die Sprachqualität verbessert, die Anrufaufbauzeiten verkürzt und die Bandbreitenanforderungen an den Netzbetreiber reduziert werden.

20.2. Bandwidth Requirements (Bandbreitenanforderungen)

Der Einsatz von ICE kann mehrere Wechselwirkungen mit der verfügbaren Netzwerkkapazität haben, die Betreiber berücksichtigen sollten.

20.2.1. STUN and TURN Server Capacity Planning (STUN- und TURN-Server-Kapazitätsplanung)

In erster Linie nutzt ICE TURN- und STUN-Server, die sich typischerweise in den Rechenzentren des Netzbetreibers befinden würden. Die STUN-Server benötigen relativ wenig Bandbreite. Für jede Komponente jedes Medienstroms gibt es eine oder mehrere STUN-Transaktionen von jedem Client zum STUN-Server. In einer grundlegenden reinen Sprach-IPv4-VoIP-Bereitstellung gibt es vier Transaktionen pro Anruf (eine für RTP und eine für RTCP, sowohl für den Anrufer als auch für den Angerufenen). Jede Transaktion ist eine einzelne Anforderung und eine einzelne Antwort, wobei erstere 20 Byte lang ist und letztere 28. Wenn ein System also N Benutzer hat und jeder in einer Hauptverkehrsstunde vier Anrufe tätigt, würde dies N*1,7 bps erfordern. Für eine Million Benutzer sind dies 1,7 Mbit/s, eine sehr kleine Zahl (relativ gesehen).

Der TURN-Verkehr ist umfangreicher. Der TURN-Server sieht ein Verkehrsvolumen, das dem STUN-Volumen entspricht (tatsächlich ist, wenn TURN-Server eingesetzt werden, kein separater STUN-Server erforderlich), zusätzlich zum Verkehr für den eigentlichen Medienverkehr. Die Menge der Anrufe, die TURN für das Medien-Relay erfordern, hängt stark von den Netzwerktopologien ab und kann und wird im Laufe der Zeit variieren. In einem Netzwerk mit 100 % behave-konformem NAT ist sie genau null. Zum Zeitpunkt des Schreibens sahen groß angelegte Verbraucherbereitstellungen zwischen 5 und 10 Prozent der Anrufe, die TURN-Server erforderten. In Anbetracht einer reinen Sprachbereitstellung mit G.711 (also 80 kbit/s in jeder Richtung) mit 0,2 Erlang während der Hauptverkehrsstunde sind dies N*3,2 kbit/s. Für eine Bevölkerung von einer Million Benutzern sind dies 3,2 Gbit/s, unter der Annahme einer 10-prozentigen Nutzung von TURN-Servern.

20.2.2. Gathering and Connectivity Checks (Sammeln und Konnektivitätsprüfungen)

Der Prozess des Sammelns von Kandidaten und der Durchführung von Konnektivitätsprüfungen kann bandbreitenintensiv sein. ICE wurde entwickelt, um beide Prozesse zu takten. Die Sammelphase und die Konnektivitätsprüfphase sollen Verkehr mit ungefähr derselben Bandbreite wie der Medienverkehr selbst erzeugen. Dies wurde getan, um sicherzustellen, dass, wenn ein Netzwerk so konzipiert ist, dass es Multimediaverkehr eines bestimmten Typs (Sprache, Video oder nur Text) unterstützt, es über ausreichende Kapazität verfügt, um die ICE-Prüfungen für diese Medien zu unterstützen. Natürlich verursachen die ICE-Prüfungen einen geringfügigen Anstieg der Gesamtauslastung; dies wird jedoch typischerweise ein extrem kleiner Anstieg sein.

Überlastung aufgrund der Sammel- und Prüfphasen hat sich in Bereitstellungen, die keine Taktung verwendeten, als Problem erwiesen. Typischerweise wurden Zugangsleitungen überlastet, da die Endpunkte das Netzwerk so schnell mit Prüfungen überfluteten, wie sie sie senden konnten. Folglich sollten Netzbetreiber sicherstellen, dass ihre ICE-Implementierungen die Taktungsfunktion unterstützen. Obwohl diese Taktung die Anrufaufbauzeiten erhöht, macht sie ICE netzwerkfreundlich und einfacher bereitzustellen.

20.2.3. Keepalives (Keepalives)

STUN-Keepalives (in Form von STUN Binding Indications) werden in der Mitte einer Mediensitzung gesendet. Sie werden jedoch nur gesendet, wenn kein tatsächlicher Medienverkehr vorhanden ist. In Bereitstellungen, die keine Sprachaktivitätserkennung (VAD) verwenden, werden die Keepalives nie verwendet, und es gibt keinen Anstieg der Bandbreitennutzung. Wenn VAD verwendet wird, werden Keepalives während Stilleperioden gesendet. Dies beinhaltet ein einzelnes Paket alle 15-20 Sekunden, weit weniger als das Paket alle 20-30 ms, das gesendet wird, wenn Sprache vorhanden ist. Daher haben Keepalives keine wirklichen Auswirkungen auf die Kapazitätsplanung.

20.3. ICE and ICE-lite (ICE und ICE-lite)

Bereitstellungen, die eine Mischung aus ICE und ICE-lite verwenden, arbeiten perfekt zusammen. Sie wurden explizit so konzipiert, dass sie dies ohne Funktionsverlust tun.

ICE-lite kann jedoch nur in begrenzten Anwendungsfällen eingesetzt werden. Diese Fälle und die damit verbundenen Vorbehalte sind in Anhang A dokumentiert.

20.4. Troubleshooting and Performance Management (Fehlerbehebung und Leistungsmanagement)

ICE nutzt End-to-End-Konnektivitätsprüfungen und verlagert einen Großteil der Verarbeitung in die Endpunkte. Dies stellt eine Herausforderung für den Netzbetreiber dar – wie können sie ICE-Bereitstellungen Fehler beheben? Wie können sie wissen, wie ICE funktioniert?

ICE verfügt über integrierte Funktionen, um bei der Bewältigung dieser Probleme zu helfen. SIP-Server auf dem Signalisierungspfad, die typischerweise in den Rechenzentren des Netzbetreibers eingesetzt werden, sehen den Inhalt des Angebots-/Antwortaustauschs, der die ICE-Parameter übermittelt. Diese Parameter umfassen den Typ jedes Kandidaten (Host, Server-Reflexiv oder Relay) zusammen mit seinen zugehörigen Adressen. Sobald die ICE-Verarbeitung abgeschlossen ist, findet ein aktualisierter Angebots-/Antwortaustausch statt, der die ausgewählte Adresse (und ihren Typ) signalisiert. Dieses aktualisierte re-INVITE wird genau zu dem Zweck durchgeführt, Netzwerkausrüstung (wie ein an einen SIP-Server angeschlossenes Diagnosetool) über die Ergebnisse der ICE-Verarbeitung zu informieren.

Infolgedessen kann ein Netzbetreiber anhand der vom SIP-Server generierten Protokolle beobachten, welche Arten von Kandidaten für jeden Anruf verwendet werden und welche Adresse von ICE ausgewählt wurde. Dies ist die primäre Information, die hilft, zu bewerten, wie ICE funktioniert.

20.5. Endpoint Configuration (Endpunktkonfiguration)

ICE ist darauf angewiesen, dass mehrere Daten in den Endpunkten konfiguriert sind. Diese Konfigurationsdaten umfassen Timer, Anmeldeinformationen für TURN-Server und Hostnamen für STUN- und TURN-Server. ICE selbst bietet keinen Mechanismus für diese Konfiguration. Stattdessen wird angenommen, dass diese Informationen an jeden Mechanismus angehängt sind, der verwendet wird, um alle anderen Parameter im Endpunkt zu konfigurieren. Für SIP-Telefone wurden Standardlösungen wie das Konfigurationsframework [SIP-UA-FRMWK] definiert.