Message Session Relay Protocol (MSRP) over Data Channels
updates
- rfc-4975 — The Message Session Relay Protocol (MSRP)
Extracted elements (26)
The 'msrp-cema' DCSA-embedded attribute is mandated because the 'path' attribute is not used for routing MSRP messages over data channels — the data channel itself is established by SDP offer/answer (RFC 8864), making MSRP CEMA-like behavior the operative model rather than legacy MSRP relay-based routing.
This document updates RFC 4975 by permitting the 'msrps' URI scheme when the underlying connection is protected with DTLS (not just TLS), since MSRP over data channels uses DTLS provided by the WebRTC stack rather than TLS over TCP.
WebRTC data channels are preferred over WebSocket for MSRP transport because data channels provide low-latency transport, leverage NAT-aware connectivity, and integrate the security features of WebRTC (DTLS), whereas WebSocket only provides message-passing with no direct access to TCP/TLS sockets.
A gateway can interwork MSRP over data channels with MSRP over TCP/TLS in two modes: as a B2BUA (no further specification needed) or at transport level using MSRP CEMA. If the non-data-channel endpoint does not support MSRP CEMA, transport-level interworking is not possible and the gateway must act as a B2BUA.
An endpoint establishing an MSRP session using data channel transport SHALL NOT request inclusion of any relays, although it MAY interoperate with a peer that signals the use of relays.
An offerer and answerer SHALL include a 'dcmap' attribute in each offer and answer for the SDP media description describing the SCTP association, with parameters 'label=' and 'subprotocol="msrp"'. The 'max-retr' and 'max-time' parameters SHALL NOT be included.
An offerer and answerer SHALL include a 'dcsa' attribute for each of the following MSRP-specific attributes: 'path' (RFC 4975), 'msrp-cema' (RFC 6714), and 'setup' (RFC 6135). Absence of any of these is a protocol error.
Data sending, receiving, and reporting procedures SHALL conform to RFC 4975. No special modifications are required for the data channel transport beyond the framing constraint in Section 5.4.
If the data channel used to transport the MSRP session fails and is torn down, both MSRP data channel endpoints SHALL consider the MSRP session failed. An endpoint MAY, based on local policy, try to negotiate a new MSRP data channel.
If the 'ordered' attribute parameter is included in the 'dcmap' attribute, its value SHALL be set to 'true'. In-order delivery is mandatory for MSRP over data channels.
In gateway transport-level interworking, the gateway SHALL use the MSRP CEMA mechanism (RFC 6714) toward the non-data-channel endpoint, and SHALL NOT modify the 'path' or 'setup' values received from either endpoint.
The closure of an MSRP session SHALL be signaled via SDP following the requirements in Section 4.6, using the data channel closing procedures in RFC 8864.
When an endpoint receives an MSRP message over a data channel, it MUST still perform the MSRP URI comparison procedures defined in RFC 4975, even though the 'path' attribute is not used for routing.
When closing an MSRP session, the SDP port value for the 'm=' line SHOULD NOT be set to zero (unless all data channels are closing and the SCTP association is no longer needed), since doing so would close the SCTP association and impact all data channels. Instead, the offerer SHALL remove the 'dcmap' and 'dcsa' attributes.
A new MSRP URI transport parameter value 'dc' (data channel) is defined, extending the existing MSRP URI syntax from RFC 4975. Implementations must allow unrecognized transports where no connection to the URI resource is needed.
An MSRP data channel is a WebRTC data channel with subprotocol identifier 'msrp', reliable transmission, in-order delivery, and a label negotiated via SDP. These four properties define the channel's fundamental characteristics.
Each MSRP session maps to exactly one data channel. Consequently, a file transfer session also maps to one data channel, which MAY be reused for another file transfer after completion.
The DCSA-embedded 'setup' attribute takes the form 'a=dcsa:x setup:<role>' where x is the data channel's SCTP stream identifier, explicitly binding the active/passive role negotiation to a specific MSRP session over a specific data channel. It has no relationship with DTLS connection establishment roles.
The msrp-scheme portion of the MSRP URI for a data channel endpoint is always 'msrps', indicating the session is always secured using DTLS as specified in RFC 8831. This applies to both the SDP 'path' attribute and MSRP message headers.
The 'msrps' URI scheme registration (originally created by RFC 4975) is updated by adding a reference to RFC 8873, extending it to cover DTLS as a protected transport indicated by the URI scheme.
The SDP Parameters 'att-field' subregistry is updated to add the usage level 'dcsa (msrp)' for 15 SDP attributes: accept-types, accept-wrapped-types, file-date, file-disposition, file-icon, file-range, file-selector, file-transfer-id, inactive, max-size, msrp-cema, path, recvonly, sendonly, sendrecv, setup, and sendrecv.
The WebSocket Subprotocol Name Registry entry for subprotocol identifier 'msrp' is updated with a reference to RFC 8873.
MSRP traffic over data channels — including confidentiality, integrity, and source authentication — is secured as specified by RFC 8831 (WebRTC Data Channels, which mandates DTLS). This provides stronger transport-layer security guarantees than the optional TLS in RFC 4975.
RFC 4975 allows MSRP transport over non-secured TCP connections and does not guarantee end-to-end TLS use; even with TLS on some hops, TCP may be used on others. Operators must establish policies to ensure MSRP traffic is protected between endpoints, particularly in gateway configurations mixing data channel and TCP/TLS transport.
Session opening: once the WebRTC data channel is opened, the active MSRP endpoint immediately opens the MSRP session by sending an MSRP SEND message (empty or not) to the passive endpoint. The active role is determined by the DCSA-embedded 'setup' attribute negotiation.
Each MSRP chunk is delivered in a single SCTP user message. All sent MSRP chunks SHALL have lengths less than or equal to the peer's 'max-message-size' attribute (RFC 8841) associated with the SCTP association. Standard MSRP framing and chunking procedures per RFC 4975 apply.