WebRTC Data Channel Establishment Protocol
Extracted elements (24)
Allowing the opener to send user data before receiving DATA_CHANNEL_ACK reduces latency for applications that need to send immediately after opening, at the cost of requiring ordered delivery of those early messages to preserve semantics if the channel turns out to be unordered.
An SCTP stream-reset request on a stream for which no DATA_CHANNEL_ACK has been received signals failure of the data channel setup procedure to the original opener, without requiring an explicit error message type.
DCEP uses an in-band two-way handshake over SCTP encapsulated in DTLS, reusing the already-standardized transport and security features of SCTP and DTLS rather than defining a new transport or security layer.
To avoid collisions when both sides simultaneously open a data channel, the DTLS client MUST use even stream identifiers and the DTLS server MUST use odd stream identifiers. This leverages the existing DTLS role negotiation to assign disjoint identifier spaces without additional signaling.
Message Type values 0x00 and 0x01 in the DCEP Message Types registry are reserved (not unassigned) specifically to avoid interoperability problems, as these values were used in draft versions of this document.
All DCEP messages MUST be sent using ordered delivery and reliable transmission on the same outgoing stream as the user messages of the corresponding data channel, and MUST use the assigned PPID for DCEP (50). Other messages MUST NOT use this PPID.
Before any message has been received on a data channel (i.e., before DATA_CHANNEL_ACK or any user message arrives), all outgoing user messages for that channel MUST be sent ordered, regardless of the channel's configured ordering. After the first received message, ordered channels MUST send ordered and unordered channels MUST send unordered.
Each side MUST use streams with either even or odd stream identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS, the DTLS client MUST use even stream identifiers and the DTLS server MUST use odd stream identifiers.
If a DATA_CHANNEL_OPEN message is received on an already-used stream, has invalid parameters, violates the odd/even rule, or is malformed, the receiver MUST close the corresponding data channel and MUST NOT send a DATA_CHANNEL_ACK.
If new Channel Types in the DCEP Channel Types registry support both ordered and unordered message delivery, the high-order bit MUST be used to indicate whether message delivery is unordered.
Receiving a user data message on an unused stream indicates an error; the corresponding data channel MUST be closed as described in RFC 8831.
A data channel consists of two SCTP streams with the same stream identifier (one in each direction) managed together as a single bidirectional channel. Stream identifiers range from 0 to 65534; 65535 is reserved.
The Channel Type field (1 byte) in DATA_CHANNEL_OPEN specifies reliability and ordering: DATA_CHANNEL_RELIABLE (0x00), DATA_CHANNEL_RELIABLE_UNORDERED (0x80), DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01), DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81), DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02), and DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82).
The Protocol field in DATA_CHANNEL_OPEN is a variable-length UTF-8 string identifying the application protocol; an empty string means unspecified, and a non-empty string MUST be a value registered in the WebSocket Subprotocol Name Registry (RFC 6455). No uniqueness is guaranteed.
The Reliability Parameter (4 bytes) in DATA_CHANNEL_OPEN specifies the maximum number of retransmissions for REXMIT channel types, or the maximum lifetime in milliseconds for TIMED channel types. For reliable channels it MUST be set to 0 and MUST be ignored on receipt.
IANA created the 'Data Channel Establishment Protocol (DCEP) Parameters' standalone registry, containing two subregistries: 'Message Types' and 'Channel Types'. New entries in both require RFC Required action per RFC 8126.
IANA updated the SCTP Payload Protocol Identifier previously registered as 'WebRTC Control' (value 50) to 'WebRTC DCEP', referencing RFC 8832, within the 'SCTP Payload Protocol Identifiers' registry created by RFC 4960.
The DCEP 'Channel Types' registry manages the 1-byte Channel Type field in DATA_CHANNEL_OPEN. Initial entries cover six channel types (0x00–0x02 and 0x80–0x82), with 0x7f and 0xff reserved for extensibility. New Channel Types supporting ordered/unordered delivery MUST use the high-order bit to indicate unordered.
The DCEP 'Message Types' registry manages the 1-byte Message Type field. Initial entries: Reserved (0x00, 0x01, 0xff), DATA_CHANNEL_ACK (0x02), DATA_CHANNEL_OPEN (0x03), Unassigned (0x04–0xfe). Values 0x00 and 0x01 are reserved to avoid interoperability problems with draft versions.
DCEP itself provides no privacy, integrity, or authentication. It relies entirely on the enclosing protocol suite (SCTP over DTLS as specified in RFC 8261) for those properties. General WebRTC security considerations are addressed in RFC 8826 and RFC 8827.
Receivers must be prepared for DATA_CHANNEL_OPEN messages with Label and Protocol fields at maximum length (65535 bytes each), and must handle error cases such as inconsistent field lengths, unknown parameter values, and odd/even rule violations by closing the corresponding data channel. Implementations must also handle peers opening the maximum number of data channels.
A data channel is opened via a two-way handshake: the initiator sends DATA_CHANNEL_OPEN on a chosen outgoing stream; the peer responds with DATA_CHANNEL_ACK on the stream with the same identifier; upon exchange the data channel is open. The opening side MAY send user data before receiving the ACK.
DATA_CHANNEL_ACK message consists solely of a 1-byte Message Type field with value 0x02. It is sent in response to DATA_CHANNEL_OPEN to signal that the handshake is complete.
DATA_CHANNEL_OPEN message: 1-byte Message Type (0x03), 1-byte Channel Type, 2-byte Priority, 4-byte Reliability Parameter, 2-byte Label Length, 2-byte Protocol Length, variable-length UTF-8 Label, and variable-length UTF-8 Protocol fields.