10. Keepalives (Keepalives)

Alle Endpunkte MUST für jede Mediensitzung Keepalives senden. Diese Keepalives dienen dem Zweck, NAT-Bindungen für die Mediensitzung am Leben zu erhalten. Diese Keepalives MUST gesendet werden, unabhängig davon, ob der Medienstrom derzeit inactive, sendonly, recvonly oder sendrecv ist, und unabhängig vom Vorhandensein oder Wert des Bandbreitenattributs. Diese Keepalives MUST gesendet werden, auch wenn ICE für die Sitzung überhaupt nicht verwendet wird. Das Keepalive SHOULD in einem Format gesendet werden, das von seinem Peer unterstützt wird. ICE-Endpunkte erlauben STUN-basierte Keepalives für UDP-Ströme, und als solche MUST STUN-Keepalives verwendet werden, wenn ein Agent eine vollständige ICE-Implementierung ist und mit einem Peer kommuniziert, der ICE (Lite oder vollständig) unterstützt. Ein Agent kann feststellen, dass sein Peer ICE unterstützt, durch das Vorhandensein von a=candidate-Attributen für jede Mediensitzung. Wenn der Peer ICE nicht unterstützt, ist die Wahl eines Paketformats für Keepalives eine Frage der lokalen Implementierung. Ein Format, das es ermöglicht, Pakete einfach in Abwesenheit von tatsächlichem Medieninhalt zu senden, wird RECOMMENDED. Beispiele für Formate, die dieses Ziel leicht erreichen, sind RTP No-Op [NO-OP-RTP] und in Fällen, in denen beide Seiten es unterstützen, RTP Comfort Noise [RFC3389]. Wenn der Peer keine Formate unterstützt, die besonders gut für Keepalives geeignet sind, SHOULD ein Agent RTP-Pakete mit einer falschen Versionsnummer oder einer anderen Form von Fehler senden, die dazu führen würde, dass sie vom Peer verworfen werden.

Wenn für Tr Sekunden kein Paket auf dem Kandidatenpaar gesendet wurde, das ICE für eine Medienkomponente verwendet (wobei Pakete diejenigen einschließen, die für die Komponente definiert sind (RTP oder RTCP) und vorherige Keepalives), MUST ein Agent ein Keepalive auf diesem Paar generieren. Tr SHOULD konfigurierbar sein und SHOULD einen Standardwert von 15 Sekunden haben. Tr MUST NOT auf weniger als 15 Sekunden konfiguriert werden. Alternativ, wenn ein Agent einen dynamischen Weg hat, die Bindungslebensdauern der dazwischenliegenden NATs zu entdecken, kann er diesen Wert verwenden, um Tr zu bestimmen. Administratoren, die ICE in kontrollierteren Netzwerkumgebungen einsetzen, SHOULD Tr auf die längstmögliche Dauer in ihrer Umgebung setzen.

Wenn STUN für Keepalives verwendet wird, wird eine STUN Binding Indication verwendet [RFC5389]. Die Indication MUST NOT irgendeinen Authentifizierungsmechanismus verwenden. Sie SHOULD das FINGERPRINT-Attribut enthalten, um beim Demultiplexen zu helfen, aber SHOULD KEINE anderen Attribute enthalten. Sie wird ausschließlich verwendet, um die NAT-Bindungen am Leben zu erhalten. Die Binding Indication wird unter Verwendung derselben lokalen und entfernten Kandidaten gesendet, die für Medien verwendet werden. Obwohl Binding Indications für Keepalives verwendet werden, MUST ein Agent bereit sein, auch eine Konnektivitätsprüfung zu empfangen. Wenn eine Konnektivitätsprüfung empfangen wird, wird eine Antwort generiert, wie in [RFC5389] diskutiert, aber es gibt ansonsten keine Auswirkungen auf die ICE-Verarbeitung.

Ein Agent MUST die Keepalive-Verarbeitung beginnen, sobald ICE Kandidaten für die Verwendung mit Medien ausgewählt hat oder Medien zu fließen beginnen, je nachdem, was zuerst eintritt. Keepalives enden, sobald die Sitzung beendet wird oder der Medienstrom entfernt wird.