MSRP over Data Channels

The Message Session Relay Protocol (MSRP) is a protocol for transmitting a series of related instant messages in the context of a session. In addition to instant messaging, MSRP can also be used for image sharing or file transfer. MSRP is currently defined to work over TCP and TLS connections. This document defines the negotiation and transport of this MSRP protocol over data channels, where a data channel is a bi-directional communication channel running on top of SCTP/DTLS (as per ) and where MSRP is instantiated as a sub-protocol of this data channel. The MSRP protocol negotiation defined in this document is based on the generic SDP offer/answer exchange based data channel negotiation as specified in . Defining MSRP as a data channel sub-protocol has many benefits: provides to applications a proven protocol enabling instant messaging, file transfer, image sharing integrates those features with other RTCWeb voice, video and data features leverages the SDP-based negotiation already defined for MSRP allows the interworking with MSRP endpoints running on a TCP or TLS connection Considering an MSRP endpoint being an MSRP application that uses data channel from WebRTC specifications , this document describes two configurations where the other endpoint is respectively either another MSRP over data channel endpoint (e.g., a WebRTC application) or an MSRP endpoint using either TCP or TLS transport.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document uses the following terms: Data channel: A WebRTC data channel as specified in . MSRP data channel: A data channel specifically used to transport the messages of one MSRP session. External negotiation: Data channel negotiation based on out-of-band or in-band mechanisms other than the Data Channel Establishment Protocol specified in . In-band: Transmission through the peer-to-peer SCTP association. Out-of-band: Transmission through the call control signaling path, e.g., using JSEP and the SDP Offer/Answer model . Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDP offerer.

In this document, an MSRP data channel is a data channel for which the instantiated sub-protocol is "MSRP", and where the MSRP-related negotiation is done as part of the SDP-based external negotiation method defined in .

In this design, the MSRP session maps to the SCTP association and the "SCTP stream pair" assigned to the data channel, and each MSRP session maps to one data channel exactly.

This document extends the MSRP URI syntax by defining the new transport parameter value "dc":

The msrp-scheme portion of the MSRP-URI that represents an MSRP data channel endpoint (used in the SDP path attribute and in the MSRP message headers) is always "msrps", which indicates that the MSRP data channel is always secured using DTLS.

This section describes the network configuration where each MSRP endpoint is running MSRP over a data channel.

The SDP offer SHALL include a dcmap attribute line (defined in ), within the media description for the SCTP association for each MSRP data channel session to be negotiated. The attribute includes the following data channel parameters: "label=" labelstring "subprotocol=" "MSRP" The labelstring is set by the MSRP application according to . Ordered and reliable data channels MUST always be used, such that the "max-retr" and "max-time" parameters SHALL NOT be used. If the "ordered" parameter is used, then its value MUST be equal to "true". Rest of the SDP offer/answer procedures are per . The following is an example of the dcmap attribute for an MSRP session to be negotiated with stream=2 and label="chat":

The SDP offer SHALL also include within the media description for the SCTP association a dcsa attribute line (defined in ) for each MSRP-specific SDP attribute to be negotiated for each MSRP data channel being negotiated. The MSRP-specific items that can be negotiated include at least all of the following well-known attributes: defined in : "path", "accept-types", "accept-wrapped-types", "max-size" defined in : "sendonly", "recvonly", "inactive", and "sendrecv" defined in : "setup" defined in : "msrp-cema" defined in : all the parameters related to MSRP file transfer. See . The msrp-cema attribute SHALL be assumed to be present for every MSRP session using data channel transport, so the inclusion of the msrp-cema attribute is OPTIONAL. This ensures that the data channel transport for the MSRP session is established without using the path attribute. The SDP answer SHALL include zero or more corresponding dcsa attribute lines for each negotiated MSRP session, according to the MSRP-specific attribute negotiation rules in the corresponding specifications. A new SDP offer/answer MAY update the MSRP subprotocol attributes while keeping the same subprotocol a=dcmap description. The semantics for newly negotiated MSRP subprotocol attributes are per .

The SDP setup attribute, as introduced in , can be used in WebRTC data channel related SDP media descriptions as a media level attribute, which is associated with the corresponding UDP/DTLS/SCTP or TCP/DTLS/SCTP "m" line. In this case the setup attribute is of the form "a=setup:<role>", where <role> assumes values as defined in . Such a setup attribute is used as specified in in order to negotiate the establishment roles of the DTLS connection. If an MSRP session is negotiated over a data channel, then such an "a=setup" attribute has no relationship with the MSRP session. Additionally, the setup attribute can be embedded in a dcsa attribute and hence can explicitly be associated with an MSRP session over a specific data channel. In such a case it is of the form "a=dcsa:x setup:<role>", with x being the data channel's SCTP stream identifier. Such a dcsa embedded setup attribute has no relationship with the DTLS connection establishment roles. A dcsa embedded setup attribute MUST be used for MSRP sessions over data channels. The dcsa embedded setup attribute in an MSRP over data channel description is used to negotiate, which MSRP session endpoint assumes the active role as per Section 4.2.2 of and Section 5.4 of . It is considered an error if an MSRP over data channel description does not contain a dcsa embedded setup attribute.

The following is an example of an "m" line for data channels in an SDP offer that includes the attributes needed to establish two MSRP sessions: one for chat and one for file transfer. The example is derived from a combination of examples in and .

describes how the active MSRP session endpoint role is negotiated. The active MSRP session endpoint does not use the path attribute to open a transport connection to its peer. Instead, it uses the data channel established for this MSRP session by the generic data channel opening procedure defined in . As soon as this data channel is opened, the MSRP session is actually opened by the active MSRP session endpoint. In order to do this the active MSRP endpoint sends an MSRP SEND message (empty or not) to the other MSRP endpoint. The msrp-cema attribute is implicitly associated with every MSRP session using data channel transport.

Each text-based MSRP message is sent on the corresponding SCTP stream using standard MSRP framing and chunking procedures, as defined in , with each MSRP chunk delivered in a single SCTP user message. Therefore all sent MSRP chunks including the MSRP chunk header MUST have lengths of less than or equal to the value of the peer's "a=max-message-size" attribute, which is associated with the data channel's SCTP association.

Data sending and reporting procedures SHALL conform to RFC 4975.

The closure of an MSRP session MUST be signaled via an SDP offer/answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from the associated DTLS/SCTP based media description. This results in the associated data channel being closed as well as per , where the actual data channel closure procedure is typically initiated by the SDP answerer right after having accepted the SDP offer. The port value for the "m" line SHOULD NOT be changed (e.g. to zero) when closing an MSRP session (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. In all cases in where the procedure calls for setting the port to zero for the MSRP "m" line in an SDP offer for TCP transport, the SDP offerer of an MSRP session with data channel transport SHALL remove the corresponding dcmap and dcsa attributes. The SDP answerer must ensure that no dcmap or dcsa attributes are present in the SDP answer if no corresponding attributes are present in the received SDP offer.

defines an end-to-end file transfer method based on MSRP and the SDP offer/answer mechanism. This file transfer method is also usable by MSRP endpoints using data channels, with the following considerations: As an MSRP session maps to one data channel, a file transfer session maps also to one data channel. SDP attributes specified in for a file transfer "m" line are embedded as subprotocol-specific attributes using the syntax defined in . Once the file transfer is complete, the same data channel MAY be reused for another file transfer.

This section describes the network configuration where one MSRP endpoint uses data channels as MSRP transport, the other MSRP endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP endpoints interwork via an MSRP gateway. Specifically, a gateway can be configured to interwork an MSRP session over a data channel with a peer that does not support data channel transport in one of two ways. In one model, the gateway performs as a MSRP B2BUA to interwork all the procedures as necessary between the endpoints. No further specification is needed for this model. Alternately, the gateway can use CEMA procedures to provide transport level interworking between MSRP endpoints using different transport protocols as follows. When the gateway performs transport level interworking between MSRP endpoints, all of the procedures in apply to each peer, with the following additions: The 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. The gateway receiving an SDP offer that includes a request to negotiate an MSRP session on a data channel can provide transport level interworking in the same manner as a CEMA SBC by forwarding TCP or TLS transport parameters in a new "m" line with the appropriate attributes within the forwarded SDP offer. Especially, the gateway interworks the received MSRP over data channel associated dcsa embedded setup attribute with the media description level "a=setup" attribute of the MSRP over TCP or TLS "m" line within its forwarded SDP offer. Similarly, a gateway receiving an SDP offer to negotiate an MSRP session using TCP or TLS transport with an endpoint that only supports data channel transport for MSRP can provide transport level interworking in the same manner as a CEMA SBC by establishing a new data channel for the MSRP session with the target endpoint. In this case the gateway interworks the received MSRP over TCP or TLS associated "a=setup" attribute with the dcsa embedded setup attribute of the generated MSRP over data channel description.

To be completed.

NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document adds the subprotocol identifier "MSRP" to the "WebSocket Subprotocol Name Registry" as follows: Subprotocol Identifier: MSRP Subprotocol Common Name: MSRP Subprotocol Definition: RFCXXXX Reference: RFCXXXX

NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document modifies the usage of the SDP setup attribute, if this attribute is embedded in a dcsa attribute and associated with an MSRP session over a data channel. The modified usage is described in . Usage level "dcsa(MSRP)" should be added to the IANA registration of the SDP setup attribute as follows: Contact name: MMUSIC Chairs Contact email: mmusic-chairs@ietf.org Attribute name: setup Usage level: dcsa(MSRP) Purpose: Negotiate the active role of an MSRP session over a data channel as per Reference: RFCXXXX

The authors wish to acknowledge the borrowing of ideas from another internet draft by Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves, Christer Holmberg, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and Keith Drage for their invaluable comments.

Addition of to list of normative references. Addition of as per section 8.2.4 of .

Addition of IANA registration related .

Addition of "a=setup:actpass", "a=connection:new", "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to the SDP example in . Addition of and to list of normative references. Addition of new describing how the active MSRP session endpoint role is negotiated. Extension of first paragraph of with new first sentence " describes how the active MSRP session endpoint role is negotiated.". First sentence of second paragraph in was "As soon as this data channel is opened, the MSRP session is actually opened by the active MSRP endpoint which sends an MSRP SEND message (empty or not) to the other MSRP endpoint." Replacement of this sentence with "As soon as this data channel is opened, the MSRP session is actually opened by the active MSRP endpoint. In order to do this the active MSRP endpoint sends an MSRP SEND message (empty or not) to the other MSRP endpoint." Addition of setup attribute specific behavior descriptions of data channel to TCP or TLS interworking gateways in .

In the abstract replacement of the first sentence "This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based external negotiation defined in " with "This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based generic data channel negotiation framework" in order to remove the reference from the abstract text. Addition of following sentence to the second paragraph in : "The MSRP protocol negotiation defined in this document is based on the generic SDP offer/answer exchange based data channel negotiation as specified in ". In replacement of sub-protocol identifier "msrp" with "MSRP" in order to make this consistent with the formal specification in . Throughout the text replacement of "shall" with "SHALL" etc where appropriate as per . In replacement of sentence 'The max-retr, max-time and ordered parameters shall not be used.' with 'Ordered and reliable data channels MUST always be used, such that the "max-retr" and "max-time" parameters SHALL NOT be used. If the "ordered" parameter is used, then its value MUST be equal to "true".'. In removal of "(on default SCTP port 5000)" from the sentence preceding the example "a=dcmap" attribute line. In first paragraph was "The SDP offer shall also include a dcsa attribute line (defined in ) within the media description for the SCTP association for each MSRP-specific SDP attribute to be negotiated for each MSRP data channel being negotiated.". Replacement of this paragraph with "The SDP offer SHALL also include within the media description for the SCTP association a dcsa attribute line (defined in ) for each MSRP-specific SDP attribute to be negotiated for each MSRP data channel being negotiated.". Appended following sentence at the end of the first paragraph of : "Therefore all sent MSRP chunks MUST have lengths of less than or equal to the value of the peer's "a=max-message-size" attribute, which is associated with the data channel's SCTP association.". Addition of the previously missing colon to the "a=sctp-port" attribute line in . In replacement of the first paragraph "Closing of an MSRP session is done using the generic data channel closing procedure defined in ." with 'The closure of an MSRP session MUST be signaled via an SDP offer/answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from the associated DTLS/SCTP based media description. This results in the associated data channel being closed as well as per , where the actual data channel closure procedure is typically initiated by the SDP answerer right after having accepted the SDP offer.'.

Additional reference to in list of normative references. Replacement of previous document title "MSRP over SCTP/DTLS data channels" with "MSRP over Data Channels" in order to align with the terminology used in . In "WebRTC data channel" was defined as "A bidirectional channel consisting of paired SCTP outbound and inbound streams." Replacement of this definition with "Data channel: A WebRTC data channel as specified in ", and consistent usage of either "data channel" or "MSRP data channel" in the remainder of the document." In the introduction replacement of references to with a reference to . Consistent usage of '"m" line' in whole document as per . In the gateway configuration section replacement of the first sentence "This section describes the network configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS connection, the other MSRP endpoint runs MSRP over one or more TLS/TCP connections, and the two endpoints interwork via an MSRP gateway" with "This section describes the network configuration where one MSRP endpoint uses data channels as MSRP transport, the other MSRP endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP endpoints interwork via an MSRP gateway".

Removed empty spaces after ";" in the examples' "a=dcmap" attribute lines. In all examples, the "m" line proto value "DTLS/SCTP" was replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were replaced with "a=max-message-size" attribute lines, as per draft-ietf-mmusic-sctp-sdp-12.

Transport parameter change for MSRP to allow MSRP RFC transports. Clarification on SDP offer/answer and removing duplicated procedures and refer them to draft-ejzak-mmusic-data-channel-sdpneg-02.