7. Connection Management (Verbindungsmanagement)

Die Methoden, Mechanismen und Anforderungen zum Aufbau, zur Verhandlung und zum Abbau von Verbindungen sind ein umfangreiches Thema und auch ein Bereich, in dem sowohl Interoperabilität als auch Innovationsfreiheit erforderlich sind.

Die folgenden Prinzipien gelten:

Die WebRTC-Medienverhandlung wird in der Lage sein, die gleiche SDP-Angebot/Antwort-Semantik auszudrücken, die in SIP [RFC3264] verwendet wird, so dass es möglich ist, Signalisierungs-Gateways zwischen SIP und WebRTC-Medienverhandlung zu bauen.
Gateways zu traditionellen SIP-Geräten, die ICE und die entsprechenden RTP/SDP-Mechanismen, Codecs und Sicherheitsmechanismen unterstützen, sind ohne die Verwendung eines Medien-Gateways möglich. Ein Signalisierungs-Gateway kann erforderlich sein, um zwischen Web-seitiger Signalisierung und SIP-Signalisierung zu übersetzen.
Wenn SDP für neue Codecs spezifiziert wird, sollte es nicht erforderlich sein, eine andere Standardisierung zu haben, um diesen Codec in einem Webbrowser zu verwenden. Das Hinzufügen neuer Codecs, die neue SDP-Parameter haben können, sollte die API zwischen dem Browser und der JavaScript-Anwendung nicht ändern. Sobald ein Browser einen neuen Codec unterstützt, sollten alte Anwendungen, die vor der Spezifikation des Codecs geschrieben wurden, in der Lage sein, den neuen Codec gegebenenfalls automatisch zu verwenden, ohne Änderungen an der JavaScript-Anwendung.

Die spezifischen Entscheidungen, die für WebRTC getroffen wurden, und ihre Auswirkungen auf die API, die Browsern zur Verfügung gestellt wird, die WebRTC implementieren, werden in [RFC8829] beschrieben.

WebRTC-Browser müssen (MUST) [RFC8829] implementieren.

WebRTC-Endpunkte müssen (MUST) die in [RFC8829] beschriebenen Funktionen implementieren, die sich auf die Netzwerkschicht beziehen (z. B. BUNDLE [RFC8843], "rtcp-mux" [RFC5761] und Trickle ICE [RFC8838]), aber diese Endpunkte müssen die in [RFC8829] beschriebenen API-Funktionen nicht unterstützen.