Negotiation Data Channels Using the Session Description Protocol (SDP)
Extracted elements (27)
The 'a=dcsa:' attribute wraps existing subprotocol SDP attributes rather than defining new ones, on the basis that subprotocol-related media-level attributes are generally independent of the transport protocol. This allows reuse of existing subprotocol specifications without modification.
The document uses the existing WebSocket Subprotocol Name Registry (rather than a new registry) for data channel subprotocol identifiers, allowing a subprotocol to simultaneously be defined for both data channel and WebSocket transport with entries in the same registry row.
Two separate SDP attributes ('a=dcmap:' for channel parameters and 'a=dcsa:' for subprotocol parameters) are defined rather than a single unified attribute, because channel properties are fixed at creation time while subprotocol attributes are subject to ongoing offer/answer negotiation following subprotocol-specific rules.
If a subprotocol has defined offer/answer procedures outside dcsa but no specification exists for use with dcsa, implementations SHOULD assume default values for all otherwise-negotiable subprotocol parameters.
If an SDP offer or answer has an 'a=dcsa:' attribute whose subprotocol attribute is unknown or whose semantic is not known for the data channel transport case, the receiver SHOULD ignore that entire 'a=dcsa:' attribute line.
The multiplexing category for both 'a=dcmap:' and 'a=dcsa:' attributes is SPECIAL. No multiplexing rules are specified for UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values, as multiple SCTP associations over a single DTLS association are outside the scope of RFC 8841.
An offerer sending a subsequent offer for a previously negotiated data channel SHALL include the previously negotiated SDP attributes and values, unless intending to close the channel.
Both 'max-retr' and 'max-time' parameters MUST NOT be present simultaneously in an 'a=dcmap:' attribute line, as they are mutually exclusive. If an SDP offer contains both, the receiver MUST reject the offer; if an SDP answer contains both, the offerer MUST treat the offer/answer as failed.
Each agent application MUST wait to send data until it has confirmation that the data channel at the peer is instantiated — either when the SCTP association is established, when the offer is received and channel created, or when the answer confirming acceptance is received (whichever comes first).
Error cases such as use of unknown parameter values or violations of the odd/even stream identifier rule MUST be handled by closing the corresponding data channel.
If an SDP offer or answer has 'a=dcsa:' attributes but no 'a=dcmap:' attributes, this is an error case and the receiver MUST discard the dcsa attributes.
In the SDP answer, the answerer SHALL include a dcmap attribute with 'dcmap-stream-id', 'max-retr', and 'max-time' values identical to those in the offer, and MAY include dcsa attributes.
SCTP stream identifiers associated with data channels negotiated using DCEP MUST NOT be included in SDP offers and answers.
The endpoint acting as a DTLS client MUST use even SCTP stream identifier values, and the endpoint acting as a DTLS server MUST use odd identifier values, to avoid stream identifier collisions.
To close a data channel, the endpoint SHALL send an SCTP SSN Reset message and subsequently send an offer either removing the dcmap/dcsa attributes or reusing the stream for a new channel with a different dcmap attribute value.
When a subprotocol is defined for use over data channels with the SDP offer/answer mechanism, any SDP attributes that may be negotiated using 'a=dcsa:' MUST be added to the IANA attribute-name registry with a new Usage Level of the form 'dcsa (foo)'.
When sending an initial offer, the offerer SHALL include an SDP dcmap attribute in the 'm=' section for the SCTP association, and MAY include one or more dcsa attributes whose 'stream-id' SHALL match the dcmap's 'dcmap-stream-id'.
The 'a=dcmap:' SDP media-level attribute defines data channel parameters for each data channel to be negotiated out-of-band. It carries stream-id and optional parameters: label, subprotocol, max-retr, max-time, ordered, and priority.
The 'a=dcsa:' SDP media-level attribute carries subprotocol-specific SDP attributes associated with a specific data channel, identified by stream-id. It wraps existing SDP attributes that would normally appear at the media level for the subprotocol.
The 'ordered' parameter in 'a=dcmap:' defaults to 'true' (ordered delivery). Setting it to 'false' selects unordered delivery. Any other value is ignored and 'ordered=true' is assumed.
The 'priority' parameter in 'a=dcmap:' indicates the data channel's relative priority as an unsigned integer less than 2^16. When absent, a default of 256 is assumed.
The 'subprotocol' parameter in 'a=dcmap:' identifies the application protocol transported over the data channel, mapping to the 'Protocol' parameter in RFC 8832. It defaults to the empty string when absent.
This document registers two new SDP media-level attributes with IANA: 'dcmap' (for data channel parameters) and 'dcsa' (for subprotocol-specific attributes), both with multiplexing category SPECIAL.
This document updates the IANA WebSocket Subprotocol Name Registry to also include subprotocol identifiers for use within WebRTC data channels. New subprotocol registrations for data channel use follow the existing WebSocket registry procedures.
Data channel parameters are negotiated as part of opening an SCTP channel over DTLS (per RFC 8841). Each subprotocol may introduce its own security considerations that must be documented in the subprotocol definition. This document adds no security considerations beyond those in RFC 8841.
The 'a=dcmap:' attribute value (dcmap-value) consists of a 1-to-5 digit stream identifier followed by optional semicolon-separated parameters: ordered (true/false), subprotocol (quoted-string), label (quoted-string), max-retr (integer < 2^32), max-time (integer < 2^32), and priority (integer < 2^16).
The 'a=dcsa:' attribute value (dcsa-value) consists of a 1-to-5 digit stream-id followed by a space and an RFC 8866 attribute, embedding subprotocol-specific SDP attributes within a data channel context.