Transports for WebRTC
Extracted elements (31)
Even when multiple ICE candidate pairs are valid for a single component, there is only one DTLS handshake because all candidate pairs associated with a single component are part of the same DTLS association, as described in RFC8842 Section 6.
Temporary IPv6 addresses are preferred over permanent ones for privacy, but the standard IPV6_PREFER_SRC_TMP flag does not apply in ICE because ICE gathers and reveals all addresses. Therefore WebRTC defines its own rule: discard permanent addresses when nondeprecated temporaries of the same scope exist.
TURN TCP candidates (RFC6062), where the connection from the TURN server to the peer is TCP, are only MAY because: they are only relevant when both peers require TCP; the same use case is covered by both sides establishing UDP relay candidates over TURN/TCP; and TCP between TURN server and peer introduces head-of-line blocking.
A full ICE implementation (not ICE-Lite) is required to ensure interworking with both ICE and ICE-Lite peers when ICE-Lite peers are deployed appropriately.
An implementation MAY turn off DSCP markings if it detects symptoms of unexpected behavior such as priority inversion or blocking of packets with certain DSCP values; one detection strategy is to send initial ICE probes with DSCP 0 and then probe each intended DSCP after candidate pair selection.
A receiving implementation MUST be able to receive media and data in all configurations: fully bundled, fully unbundled, and intermediate bundling configurations.
A sending implementation MUST be able to support fully bundled (all media and data on a single 5-tuple) and fully unbundled (each media stream and data on its own 5-tuple) configurations.
All packets carrying data from the SCTP association supporting data channels MUST use a single DSCP, which SHOULD be the code point recommended by [RFC8837] for the highest-priority data channel carried.
All packets on one TCP connection, no matter what it carries, MUST use a single DSCP.
ICE [RFC8445] MUST be supported, and the implementation MUST be a full ICE implementation, not ICE-Lite. A full ICE implementation allows interworking with both ICE and ICE-Lite implementations when deployed appropriately.
ICE-TCP candidates [RFC6544] MUST be supported; this may allow applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server.
If TCP connections are used, RTP framing according to [RFC4571] MUST be used for all packets, including RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets.
Implementations SHOULD attempt to set QoS DSCP markings on packets sent, according to the guidelines in [RFC8837]; departure is appropriate when running on platforms where QoS marking is not implemented.
Key exchange MUST be done using DTLS-SRTP, as described in [RFC8827].
Protocol identification MUST be supplied as part of the DTLS handshake, as specified in [RFC8833] (ALPN for WebRTC).
The ALTERNATE-SERVER mechanism specified in Section 11 of [RFC5389] (300 Try Alternate) MUST be supported.
The data channel setup protocol described in [RFC8832] MUST be supported.
The 'Happy Eyeballs' specification for ICE [RFC8421] SHOULD be supported when TURN is used and the TURN server has IPv4 or IPv6 connectivity.
To deal with firewalls that block all UDP traffic, the mode of TURN using TCP between the WebRTC endpoint and the TURN server MUST be supported, and the mode using TLS over TCP MUST also be supported.
To deal with IPv4/IPv6 interoperability scenarios, TURN extensions for IPv6 MUST be supported.
To deal with NATs that perform endpoint-dependent mapping, TURN [RFC8656] MUST be supported.
Web applications running in a WebRTC browser MUST be able to utilize both IPv4 and IPv6 where available; when two peers have only IPv4 or only IPv6 connectivity, applications MUST be able to communicate.
WebRTC browsers MUST support configuration of STUN and TURN servers, from both browser configuration and an application.
WebRTC endpoints MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764] Section 5.1.2, with clarifications in [RFC7983].
WebRTC endpoints MUST support SCTP over DTLS over ICE for data channel transport, as specified in [RFC8261]. The SCTP extension for I-DATA [RFC8260] MUST be supported.
When a WebRTC endpoint gathers all IPv6 addresses and both nondeprecated temporary addresses and permanent addresses of the same scope are present, it SHOULD discard the permanent addresses before exposing them to the application or using them in ICE.
When a WebRTC endpoint sends data over multiple streams congestion-controlled under the same regime, it SHOULD emit data so that each stream at each priority level receives approximately twice the transmission capacity of the level below.
The data channel transport stack is SCTP over DTLS over ICE (UDP or TCP). All SCTP packets flow as application-layer payloads over the DTLS connection shared with media.
The required system-provided transport interfaces are UDP [RFC0768] and TCP [RFC0793], both with IPv4 and IPv6 support. For UDP, the ability to set DSCP per-packet is required for media prioritization.
The WebRTC prioritization model defines four API-level priority classes for media flows and data flows: 'very-low', 'low', 'medium', and 'high'. A high-priority flow can send 8 times as much data as a very-low-priority flow under congestion.
WebRTC security considerations are enumerated in [RFC8826] and security considerations pertaining to the use of DSCP are enumerated in [RFC8837]; this document defers to those references rather than restating them.