Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport
Extracted elements (29)
Both SCTP endpoints take the 'active' role during association establishment (unlike TCP where one endpoint is 'active' and one is 'passive'). This means the SDP 'setup' attribute does not apply to SCTP association establishment, though it does apply to the underlying DTLS association and TCP connection.
TCP/DTLS/SCTP forces ordered and reliable delivery of SCTP packets due to TCP's characteristics, limiting the utility of SCTP's unordered or unreliable delivery options. It is therefore RECOMMENDED to use TCP/DTLS/SCTP only when UDP traffic is blocked.
TCP/DTLS/SCTP uses the RFC 4571 framing method (a length field preceding each DTLS message) rather than raw TLS-over-TCP, because this allows reuse of existing TCP-based media framing infrastructure. A separate proto value would be required for TLS-over-TCP without RFC 4571 framing.
The SDP 'sctp-port' attribute is used to manage SCTP association lifecycle (close and re-establish) rather than the SDP 'connection' attribute, because the 'connection' attribute does not apply to SCTP. A new sctp-port value triggers closure of the old association and establishment of a new one without affecting the underlying DTLS association.
All ICE-enabled SCTP-over-DTLS endpoints SHOULD implement support for UDP/DTLS/SCTP to maximize interoperability. When ICE is not used, the proto value MUST always reflect the transport protocol actually in use.
Multihoming is not supported when using SCTP-over-DTLS because DTLS does not expose address management of the underlying transport protocols (UDP or TCP) to its upper layer.
While RFC 8261 allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support negotiation of a single SCTP association per DTLS association. Future mux extensions must also define mux rules for the sctp-port and max-message-size attributes.
An m= line with proto 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' MUST have exactly one fmt value, and that fmt value MUST be registered by IANA in the association-usage name registry.
An SCTP endpoint MUST NOT send an SCTP user message with a size larger than the maximum size indicated by the peer via the 'max-message-size' attribute.
During ICE nomination, implementations MUST be ready to receive data on any of the candidates, even if this means simultaneously sending and receiving data using UDP/DTLS/SCTP in one direction and TCP/DTLS/SCTP in the other.
Each endpoint MUST associate one or more certificate fingerprints (via the SDP 'fingerprint' attribute) and an SDP 'tls-id' attribute with the m= line, following RFC 8122 and RFC 8842 procedures respectively.
For TCP/DTLS/SCTP, the SDP 'setup' attribute value 'holdconn' MUST NOT be used, because DTLS is transported on top of TCP and RFC 8842 forbids holdconn for DTLS.
If the SDP 'sctp-port' attribute in the answer has a value of zero, the offerer MUST NOT establish an SCTP association, and if one exists, MUST close it. If the answer m= line itself contains a zero port, the offerer MUST NOT establish any TCP connection, DTLS association, or SCTP association.
If the SDP 'sctp-port' attribute is not present on an m= line that uses a UDP/DTLS/SCTP or TCP/DTLS/SCTP proto value, that m= line MUST be considered invalid.
Implementations MUST treat all ICE candidate pairs associated with an SCTP-over-DTLS association as part of the same DTLS association. Shifting between candidate pairs, including between UDP and TCP pairs, MUST NOT trigger a new SCTP or DTLS handshake.
SDP direction attributes (sendrecv/sendonly/recvonly/inactive) MUST be ignored for SCTP associations unless their semantics for a given SCTP association usage have been explicitly defined.
To close an SCTP association without closing the underlying DTLS association, the offerer MUST signal a new (different) sctp-port value to replace it, or a zero sctp-port value to close it without immediately replacing it. Changing sctp-port does not impact the underlying DTLS association.
When establishing an SCTP association, both endpoints MUST take the 'active' role and both MUST use the same SCTP port as both client port and server port, to prevent two separate SCTP associations from being created.
When generating an initial SDP offer, the offerer MUST include an SDP 'setup' attribute and an SDP 'sctp-port' attribute with the m= line. For TCP/DTLS/SCTP, it MUST also include an SDP 'connection' attribute with value 'new'.
When generating an SDP answer that includes a new SCTP port value in the offer, the answerer MUST also use a new SCTP port value. If the offer contains a zero SCTP port or the answerer rejects the association, the answerer MUST use a zero SCTP port value in the answer.
When sending an SDP offer or answer during ICE negotiation, the proto value MUST match the transport of the default candidate: 'UDP/DTLS/SCTP' for UDP default, 'TCP/DTLS/SCTP' for TCP default. After ICE nomination, the proto value MUST match the nominated candidate pair's transport.
The SDP 'max-message-size' media-level attribute indicates the maximum SCTP user message size (in bytes) an endpoint is willing to receive. A value of zero means any size is accepted (subject to memory). If absent, the default is 64 KB.
The SDP 'sctp-port' media-level attribute indicates the SCTP port associated with an m= line using UDP/DTLS/SCTP or TCP/DTLS/SCTP. The m= line port field carries the underlying UDP/TCP port, while 'sctp-port' carries the SCTP port. Syntax: sctp-port-value = 1*5(DIGIT); range 0–65535; leading zeroes MUST NOT be used.
Two new SDP proto values are defined: 'UDP/DTLS/SCTP' describes an SCTP association on top of DTLS on top of UDP, and 'TCP/DTLS/SCTP' describes an SCTP association on top of DTLS on top of TCP. These are media-transport-layer identifiers that do not describe the upper-layer protocol.
A new IANA registry 'association-usage Name Registry' is created for fmt values used with the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto identifiers. Registration policy is First Come First Served. The initial entry is 'webrtc-datachannel' (referencing RFC 8832 and RFC 8841).
Two new proto values are added to the IANA 'Session Description Protocol (SDP) Parameters' registry: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP', both referencing RFC 8841.
Two new SDP media-level attributes are registered with IANA: 'sctp-port' (indicates the SCTP port) and 'max-message-size' (indicates the maximum SCTP user message size in bytes), both with mux category CAUTION.
This specification introduces no new security considerations beyond those in RFC 4566 (SDP), RFC 3264 (offer/answer), RFC 4145 (TCP-based SDP), RFC 8122 (TLS in SDP), RFC 4960 (SCTP), and RFC 8261 (SCTP-over-DTLS). Security of the SCTP-over-DTLS association is derived from DTLS, whose roles are negotiated via the SDP 'setup' and 'fingerprint' attributes per RFC 8122 and RFC 8842.
An 'm=' line using UDP/DTLS/SCTP or TCP/DTLS/SCTP takes the form: media='application', port=UDP or TCP port number, proto='UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', fmt=a token identifying the association-usage (e.g., 'webrtc-datachannel'). Exactly one fmt value is permitted per such m= line.