12. Usage with SIP (Verwendung mit SIP)
12.1. Latency Guidelines (Latenzrichtlinien)
ICE erfordert, dass eine Reihe von STUN-basierten Konnektivitätsprüfungen zwischen Endpunkten stattfindet. Diese Prüfungen beginnen beim Antwortenden bei der Erstellung seiner Antwort und beim Anbietenden, wenn er die Antwort erhält. Diese Prüfungen können Zeit in Anspruch nehmen, und daher kann die Auswahl der Nachrichten, die mit Angeboten und Antworten verwendet werden, die wahrgenommene Benutzerlatenz beeinflussen. Zwei Latenzzahlen sind von besonderem Interesse. Dies sind die Verzögerung nach dem Abheben (post-pickup delay) und die Verzögerung nach dem Wählen (post-dial delay). Die Verzögerung nach dem Abheben bezieht sich auf die Zeit zwischen dem Moment, in dem ein Benutzer „das Telefon abhebt“, und dem Moment, in dem jede von ihm geäußerte Sprache an den Anrufer übermittelt werden kann. Die Verzögerung nach dem Wählen bezieht sich auf die Zeit zwischen dem Moment, in dem ein Benutzer die Zieladresse für den Benutzer eingibt, und dem Beginn des Rückrufs als Folge des erfolgreichen Beginns des Klingelns des Telefons des angerufenen Teilnehmers.
Es können zwei Fälle betrachtet werden – einer, bei dem das Angebot im anfänglichen INVITE vorhanden ist, und einer, bei dem es sich in einer Antwort befindet.
12.1.1. Offer in INVITE (Angebot im INVITE)
Um Verzögerungen nach dem Wählen zu reduzieren, ist es RECOMMENDED, dass der Anrufer mit dem Sammeln von Kandidaten beginnt, bevor er sein anfängliches INVITE tatsächlich sendet. Dies kann bei Hinweisen der Benutzeroberfläche gestartet werden, dass ein Anruf ansteht, wie z. B. Aktivität auf einer Tastatur oder das Abheben des Telefons.
Wenn ein Angebot in einer INVITE-Anfrage empfangen wird, SHOULD der Antwortende bei Erhalt des Angebots mit dem Sammeln seiner Kandidaten beginnen und dann eine Antwort in einer vorläufigen Antwort generieren, sobald er diesen Prozess abgeschlossen hat. ICE erfordert, dass eine vorläufige Antwort mit einem SDP zuverlässig übertragen wird. Dies kann durch den bestehenden Mechanismus der Bestätigung vorläufiger Antworten (PRACK) [RFC3262] oder durch eine für ICE spezifische Optimierung erfolgen. Mit dieser Optimierung können vorläufige Antworten, die eine SDP-Antwort enthalten, die die ICE-Verarbeitung für einen oder mehrere Medienströme beginnt, zuverlässig ohne RFC 3262 gesendet werden. Dazu sendet der Agent die vorläufige Antwort mit den in RFC 3262 beschriebenen exponentiellen Backoff-Timern erneut. Die erneute Übertragung MUST bei Erhalt einer STUN Binding-Anfrage für einen der in diesem SDP signalisierten Medienströme (da der Erhalt einer Binding-Anfrage anzeigt, dass der Anbietende die Antwort erhalten hat) oder bei Übertragung der Antwort in einer 2xx-Antwort eingestellt werden. Wenn der Peer-Agent lite ist, wird es niemals eine STUN Binding-Anfrage geben. In einem solchen Fall MUST der Agent das erneute Senden der 18x einstellen, nachdem er sie viermal gesendet hat (ICE funktioniert tatsächlich auch dann, wenn der Peer die 18x nie erhält; die Erfahrung hat jedoch gezeigt, dass das Senden für Middleboxes und Firewall-Traversal wichtig ist). Wenn vor der letzten erneuten Übertragung keine Binding-Anfrage empfangen wird, betrachtet der Agent die Sitzung nicht als beendet. Trotz der Tatsache, dass die vorläufige Antwort zuverlässig zugestellt wird, ändern sich die Regeln, wann ein Agent ein aktualisiertes Angebot oder eine aktualisierte Antwort senden kann, nicht gegenüber den in RFC 3262 angegebenen. Insbesondere wenn das INVITE ein Angebot enthielt, erscheint dieselbe Antwort in allen 1xx und in der 2xx-Antwort auf das INVITE. Erst nachdem diese 2xx gesendet wurde, kann ein aktualisierter Angebots-/Antwortaustausch stattfinden. Diese Optimierung SHOULD NOT verwendet werden, wenn beide Agenten PRACK unterstützen. Beachten Sie, dass die Optimierung sehr spezifisch für vorläufige Antworten ist, die Antworten enthalten, die die ICE-Verarbeitung starten; es ist keine allgemeine Technik für 1xx-Zuverlässigkeit.
Alternativ MAY ein Agent das Senden einer Antwort bis zum 200 OK verzögern; dies führt jedoch zu einer schlechten Benutzererfahrung und ist NOT RECOMMENDED.
Sobald die Antwort gesendet wurde, SHOULD der Agent seine Konnektivitätsprüfungen beginnen. Sobald Kandidatenpaare für jede Komponente eines Medienstroms in die gültige Liste aufgenommen wurden, kann der Antwortende mit dem Senden von Medien auf diesem Medienstrom beginnen.
Vor diesem Zeitpunkt dürfen jedoch keine Medien, die an den Anrufer gesendet werden müssen (wie SIP Early Media [RFC3960]), übertragen werden (MUST NOT). Aus diesem Grund SHOULD Implementierungen die Benachrichtigung des angerufenen Teilnehmers verzögern, bis Kandidaten für jede Komponente jedes Medienstroms in die gültige Liste aufgenommen wurden. Im Falle eines PSTN-Gateways würde dies bedeuten, dass die Setup-Nachricht in das PSTN bis zu diesem Zeitpunkt verzögert wird. Dies erhöht die Verzögerung nach dem Wählen, hat aber den Effekt, dass „Geisterklingeln“ eliminiert wird. Geisterklingeln sind Fälle, in denen der angerufene Teilnehmer das Telefon klingeln hört, abhebt, aber nichts hört und nicht gehört werden kann. Diese Technik funktioniert, ohne Unterstützung für oder Verwendung von Vorbedingungen [RFC3312] zu erfordern, da es sich um eine lokalisierte Entscheidung handelt. Es hat auch den Vorteil, dass garantiert wird, dass kein einziges Medienpaket abgeschnitten wird, sodass die Verzögerung nach dem Abheben null ist. Wenn ein Agent beschließt, die lokale Benachrichtigung auf diese Weise zu verzögern, SHOULD er eine 180-Antwort generieren, sobald die Benachrichtigung beginnt.
12.1.2. Offer in Response (Angebot in Antwort)
Zusätzlich zu Verwendungen, bei denen das Angebot in einem INVITE und die Antwort in der vorläufigen und/oder 200 OK-Antwort enthalten ist, funktioniert ICE in Fällen, in denen das Angebot in der Antwort erscheint. In solchen Fällen, die bei der Anrufsteuerung durch Dritte [RFC3725] üblich sind, SHOULD ICE-Agenten ihre Angebote in einer zuverlässigen vorläufigen Antwort generieren (die RFC 3262 verwenden MUST) und den Benutzer bei Erhalt des INVITE nicht benachrichtigen. Die Antwort kommt in einem PRACK an. Dies ermöglicht, dass die ICE-Verarbeitung vor der Benachrichtigung stattfindet, sodass keine Verzögerung nach dem Abheben auftritt, auf Kosten erhöhter Anrufaufbauverzögerungen. Sobald ICE abgeschlossen ist, kann der Angerufene den Benutzer benachrichtigen und dann ein 200 OK generieren, wenn er antwortet. Das 200 OK würde kein SDP enthalten, da der Angebots-/Antwortaustausch abgeschlossen ist.
Alternativ MAY Agenten das Angebot stattdessen in ein 2xx platzieren (in diesem Fall kommt die Antwort im ACK). Wenn dies geschieht, benachrichtigt der Angerufene den Benutzer bei Erhalt des INVITE, und der ICE-Austausch findet erst statt, nachdem der Benutzer geantwortet hat. Dies hat den Effekt, die Anrufaufbauverzögerung zu verringern, kann jedoch zu erheblichen Verzögerungen nach dem Abheben und zum Abschneiden von Medien führen.
12.2. SIP Option Tags and Media Feature Tags (SIP-Options-Tags und Medienfunktions-Tags)
[RFC5768] spezifiziert ein SIP-Options-Tag und ein Medienfunktions-Tag zur Verwendung mit ICE. ICE-Implementierungen, die SIP verwenden, SHOULD diese Spezifikation unterstützen, die ein Funktions-Tag bei Registrierungen verwendet, um die Interoperabilität durch Signalisierungsvermittler zu erleichtern.
12.3. Interactions with Forking (Interaktionen mit Forking)
ICE interagiert sehr gut mit Forking. Tatsächlich behebt ICE einige der mit Forking verbundenen Probleme. Ohne ICE kann der Anrufer, wenn ein Anruf gegabelt wird und er mehrere eingehende Medienströme empfängt, nicht bestimmen, welcher Medienstrom welchem Angerufenen entspricht.
Mit ICE ist dieses Problem gelöst. Die Konnektivitätsprüfungen, die vor der Übertragung von Medien stattfinden, tragen Benutzernamenfragmente, die wiederum mit einem bestimmten Angerufenen korreliert sind. Nachfolgende Medienpakete, die auf demselben Kandidatenpaar wie die Konnektivitätsprüfung ankommen, werden demselben Angerufenen zugeordnet. Somit kann der Anrufer diese Korrelation durchführen, solange er eine Antwort erhalten hat.
12.4. Interactions with Preconditions (Interaktionen mit Vorbedingungen)
Quality of Service (QoS)-Vorbedingungen, die in RFC 3312 [RFC3312] und RFC 4032 [RFC4032] definiert sind, gelten nur für die Transportadressen, die als Standardziele für Medien in einem Angebot/einer Antwort aufgeführt sind.
Wenn ICE die Transportadresse ändert, an der Medien empfangen werden, spiegelt sich diese Änderung in einem aktualisierten Angebot wider, das das Standardziel für Medien ändert, um der Auswahl von ICE zu entsprechen. Als solches erscheint es wie jedes andere Re-INVITE und wird in den RFCs 3312 und 4032 vollständig behandelt, die ohne Rücksicht auf die Tatsache gelten, dass sich das Ziel für Medien aufgrund von ICE-Verhandlungen, die „im Hintergrund“ stattfinden, ändert.
Tatsächlich SHOULD ein Agent NICHT anzeigen, dass QoS-Vorbedingungen erfüllt wurden, bis die Prüfungen abgeschlossen sind und die für Medien zu verwendenden Kandidatenpaare ausgewählt haben.
ICE hat auch (gezielte) Interaktionen mit Konnektivitätsvorbedingungen [SDP-PRECON]. Diese Interaktionen werden dort beschrieben. Beachten Sie, dass die in Abschnitt 12.1 beschriebenen Verfahren ihre eigene Art von „Vorbedingungen“ beschreiben, wenn auch mit weniger Funktionalität als die durch die expliziten Vorbedingungen in [SDP-PRECON] bereitgestellten.
12.5. Interactions with Third Party Call Control (Interaktionen mit Anrufsteuerung durch Dritte)
ICE funktioniert mit den Flüssen I, III und IV, wie in [RFC3725] beschrieben. Fluss I funktioniert, ohne dass der Controller ICE unterstützt oder kennt. Fluss IV funktioniert, solange der Controller die ICE-Attribute unverändert weitergibt. Fluss II ist grundsätzlich nicht mit ICE kompatibel; jeder Agent glaubt, der Antwortende zu sein, und generiert daher niemals ein Re-INVITE.
Die Flüsse für den fortgesetzten Betrieb, wie in Abschnitt 7 von RFC 3725 beschrieben, erfordern zusätzliches Verhalten von ICE-Implementierungen zur Unterstützung. Insbesondere wenn ein Agent ein Mid-Dialog-Re-INVITE empfängt, das kein Angebot enthält, MUST er ICE für jeden Medienstrom neu starten und den Prozess des Sammelns neuer Kandidaten durchlaufen. Darüber hinaus SHOULD diese Kandidatenliste diejenigen enthalten, die derzeit für Medien verwendet werden.