Zum Hauptinhalt springen

3. Transport and Middlebox Specification (Transport- und Middlebox-Spezifikation)

Dieser Abschnitt definiert die Transportprotokolle und Middlebox-Verarbeitungsfunktionen, die WebRTC-Endpunkte unterstützen müssen.

3.1. System-Provided Interfaces (Vom System bereitgestellte Schnittstellen)​

Die hier verwendeten Protokollspezifikationen setzen voraus, dass die folgenden Protokolle für die Implementierungen der WebRTC-Protokolle verfügbar sind:

UDP [RFC0768]: Dies ist das Protokoll, das von den meisten beschriebenen Protokollelementen angenommen wird.

TCP [RFC0793]: Dies wird für HTTP/WebSockets sowie für TURN/TLS und ICE-TCP verwendet.

Für beide Protokolle wird IPv4- und IPv6-Unterstützung vorausgesetzt.

Für UDP setzt diese Spezifikation die Fähigkeit voraus, den Differentiated Services Code Point (DSCP) der geöffneten Sockets auf Paketbasis festzulegen, um die in [RFC8837] beschriebenen Priorisierungen (siehe Abschnitt 4.2 dieses Dokuments) zu erreichen, wenn mehrere Medientypen gemultiplext werden. Es wird nicht angenommen, dass die DSCPs beachtet werden, und es wird angenommen, dass sie auf Null gesetzt oder geändert werden können, da dies ein lokales Konfigurationsproblem ist.

Plattformen, die keinen Zugriff auf diese Schnittstellen bieten, können keinen konformen WebRTC-Endpunkt unterstützen.

Diese Spezifikation setzt nicht voraus, dass die Implementierung Zugriff auf ICMP oder rohes IP hat.

Die folgenden Protokolle können verwendet werden, aber sie können von einem WebRTC-Endpunkt implementiert werden und werden daher nicht als „vom System bereitgestellte Schnittstellen" definiert:

  • TURN: Traversal Using Relays Around NAT [RFC8656]
  • STUN: Session Traversal Utilities for NAT [RFC5389]
  • ICE: Interactive Connectivity Establishment [RFC8445]
  • TLS: Transport Layer Security [RFC8446]
  • DTLS: Datagram Transport Layer Security [RFC6347]

3.2. Ability to Use IPv4 and IPv6 (Fähigkeit zur Verwendung von IPv4 und IPv6)​

Webanwendungen, die in einem WebRTC-Browser ausgeführt werden, müssen (MUST) in der Lage sein, sowohl IPv4 als auch IPv6 zu verwenden, wo verfügbar -- das heißt, wenn zwei Peers nur IPv4-Konnektivität zueinander haben oder nur IPv6-Konnektivität zueinander haben, müssen (MUST) Anwendungen, die im WebRTC-Browser ausgeführt werden, kommunizieren können.

Wenn TURN verwendet wird und der TURN-Server IPv4- oder IPv6-Konnektivität zum Peer oder zum TURN-Server des Peers hat, müssen (MUST) Kandidaten der entsprechenden Typen unterstützt werden. Die „Happy Eyeballs"-Spezifikation für ICE [RFC8421] sollte (SHOULD) unterstützt werden.

3.3. Usage of Temporary IPv6 Addresses (Verwendung temporärer IPv6-Adressen)​

Die IPv6-Standardadressauswahlspezifikation [RFC6724] legt fest, dass temporäre Adressen [RFC4941] gegenüber permanenten Adressen bevorzugt werden sollen. Dies ist eine Änderung gegenüber den in [RFC3484] festgelegten Regeln. Für Anwendungen, die eine einzelne Adresse auswählen, wird dies normalerweise durch das in [RFC5014] angegebene IPV6_PREFER_SRC_TMP-Präferenzflag erreicht. Diese Regel, die sicherstellen soll, dass datenschutzverbesserte Adressen gegenüber statischen Adressen bevorzugt verwendet werden, hat jedoch nicht die richtige Wirkung in ICE, wo alle Adressen gesammelt und daher der Anwendung offengelegt werden. Daher wird stattdessen die folgende Regel angewendet:

Wenn ein WebRTC-Endpunkt alle IPv6-Adressen auf seinem Host sammelt und sowohl nicht veraltete temporäre Adressen als auch permanente Adressen desselben Geltungsbereichs vorhanden sind, sollte (SHOULD) der WebRTC-Endpunkt die permanenten Adressen verwerfen, bevor Adressen der Anwendung offengelegt oder in ICE verwendet werden. Dies entspricht der in [RFC6724] beschriebenen Standardrichtlinie.

Wenn einige, aber nicht alle temporären IPv6-Adressen als veraltet markiert sind, sollte (SHOULD) der WebRTC-Endpunkt die veralteten Adressen verwerfen, es sei denn, sie werden von einer laufenden Verbindung verwendet. Bei einem ICE-Neustart können (MAY) derzeit verwendete veraltete Adressen beibehalten werden.

Der primäre Mechanismus für den Umgang mit Middleboxen ist ICE, was eine geeignete Methode ist, um mit NAT-Boxen und Firewalls umzugehen, die Verkehr von innen akzeptieren, aber nur von außen, wenn es sich um eine Antwort auf internen Verkehr handelt (einfache zustandsbehaftete Firewalls).

ICE [RFC8445] muss (MUST) unterstützt werden. Die Implementierung muss (MUST) eine vollständige ICE-Implementierung sein, nicht ICE-Lite. Eine vollständige ICE-Implementierung ermöglicht die Interoperabilität mit sowohl ICE- als auch ICE-Lite-Implementierungen, wenn sie entsprechend bereitgestellt werden.

Um mit Situationen umzugehen, in denen sich beide Parteien hinter NATs des Typs befinden, der endpunktabhängiges Mapping durchführt (wie in [RFC5128], Abschnitt 2.4 definiert), muss (MUST) TURN [RFC8656] unterstützt werden.

WebRTC-Browser müssen (MUST) die Konfiguration von STUN- und TURN-Servern sowohl aus der Browserkonfiguration als auch aus einer Anwendung unterstützen.

Beachten Sie, dass andere Arbeiten zur STUN- und TURN-Serverentdeckung und -verwaltung existieren, einschließlich [RFC8155] für die Serverentdeckung sowie [RETURN].

Um mit Firewalls umzugehen, die den gesamten UDP-Verkehr blockieren, muss (MUST) der TURN-Modus unterstützt werden, der TCP zwischen dem WebRTC-Endpunkt und dem TURN-Server verwendet, und der TURN-Modus, der TLS über TCP zwischen dem WebRTC-Endpunkt und dem TURN-Server verwendet, muss (MUST) unterstützt werden. Siehe Abschnitt 3.1 von [RFC8656] für Details.

Um mit Situationen umzugehen, in denen sich eine Partei in einem IPv4-Netzwerk und die andere Partei in einem IPv6-Netzwerk befindet, müssen (MUST) TURN-Erweiterungen für IPv6 unterstützt werden.

TURN-TCP-Kandidaten, bei denen die Verbindung vom TURN-Server des WebRTC-Endpunkts zum Peer eine TCP-Verbindung ist, [RFC6062] können (MAY) unterstützt werden.

Solche Kandidaten werden jedoch aus folgenden Gründen nicht als signifikanten Vorteil angesehen.

Erstens wäre die Verwendung von TURN-TCP-Kandidaten nur in Fällen relevant, in denen beide Peers TCP verwenden müssen, um eine Verbindung herzustellen.

Zweitens wird dieser Anwendungsfall auf andere Weise unterstützt, indem beide Seiten UDP-Relay-Kandidaten unter Verwendung von TURN über TCP einrichten, um sich mit ihren jeweiligen Relay-Servern zu verbinden.

Drittens kann die Verwendung von TCP zwischen dem TURN-Server des WebRTC-Endpunkts und dem Peer zu mehr Leistungsproblemen führen als die Verwendung von UDP, z. B. aufgrund von Head-of-Line-Blocking.

ICE-TCP-Kandidaten [RFC6544] müssen (MUST) unterstützt werden; dies kann es Anwendungen ermöglichen, mit Peers mit öffentlichen IP-Adressen über UDP-blockierende Firewalls zu kommunizieren, ohne einen TURN-Server zu verwenden.

Wenn TCP-Verbindungen verwendet werden, muss (MUST) RTP-Framing gemäß [RFC4571] für alle Pakete verwendet werden. Dies umfasst RTP-Pakete, DTLS-Pakete zum Übertragen von Datenkanälen und STUN-Konnektivitätsprüfungspakete.

Der in Abschnitt 11 von [RFC5389] (300 Try Alternate) spezifizierte ALTERNATE-SERVER-Mechanismus muss (MUST) unterstützt werden.

Der WebRTC-Endpunkt kann (MAY) den Zugriff auf das Internet über einen HTTP-Proxy unterstützen. Wenn dies der Fall ist, muss (MUST) er den in [RFC7639] spezifizierten „ALPN"-Header enthalten, und die in Abschnitt 4.3.6 von [RFC7231] und [RFC7235] beschriebene Proxy-Authentifizierung muss (MUST) ebenfalls unterstützt werden.

3.5. Transport Protocols Implemented (Implementierte Transportprotokolle)​

Für den Medientransport wird sicheres RTP verwendet. Die Details des verwendeten RTP-Profils werden in „Media Transport and Use of RTP in WebRTC" [RFC8834] beschrieben, das die Verwendung eines Circuit Breakers [RFC8083] und Staukontrolle vorschreibt (siehe [RFC8836] für weitere Anleitungen).

Der Schlüsselaustausch muss (MUST) mit DTLS-SRTP durchgeführt werden, wie in [RFC8827] beschrieben.

Für den Datentransport über den WebRTC-Datenkanal [RFC8831] müssen (MUST) WebRTC-Endpunkte SCTP über DTLS über ICE unterstützen. Diese Kapselung ist in [RFC8261] spezifiziert. Die Aushandlung dieses Transports im Session Description Protocol (SDP) ist in [RFC8841] definiert. Die SCTP-Erweiterung für I-DATA [RFC8260] muss (MUST) unterstützt werden.

Das in [RFC8832] beschriebene Setup-Protokoll für WebRTC-Datenkanäle muss (MUST) unterstützt werden.

Hinweis: Die Interaktion zwischen DTLS-SRTP wie in [RFC5764] definiert und ICE wie in [RFC8445] definiert wird in Abschnitt 6 von [RFC8842] beschrieben. Die Wirkung dieser Spezifikation besteht darin, dass alle ICE-Kandidatenpaare, die mit einer einzelnen Komponente verbunden sind, Teil derselben DTLS-Assoziation sind. Daher wird es nur einen DTLS-Handshake geben, selbst wenn mehrere gültige Kandidatenpaare vorhanden sind.

WebRTC-Endpunkte müssen (MUST) das Multiplexing von DTLS und RTP über dasselbe Portpaar unterstützen, wie in der DTLS-SRTP-Spezifikation [RFC5764], Abschnitt 5.1.2, mit Klarstellungen in [RFC7983] beschrieben. Alle Anwendungsschicht-Protokoll-Payloads über diese DTLS-Verbindung sind SCTP-Pakete.

Die Protokollidentifikation muss (MUST) als Teil des DTLS-Handshakes bereitgestellt werden, wie in [RFC8833] spezifiziert.

Letztes Update am