MMUSIC J. Recio, Ed.
Internet-Draft Unaffiliated
Updates: RFC4975 (if approved) C. Holmberg
Intended status: Standards Track Ericsson
Expires: December 21, 2020 June 19, 2020

MSRP over Data Channels
draft-ietf-mmusic-msrp-usage-data-channel-19

Abstract

This document specifies how the Message Session Relay Protocol (MSRP) can be transported as a WebRTC data channel sub-protocol, using the SDP offer/answer generic data channel negotiation framework to establish such a channel. Two network configurations are supported: connecting two MSRP over data channel endpoints; and a gateway configuration, connecting an MSRP over data channel endpoint with an MSRP over TCP or TLS endpoint. This document updates RFC4975

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 21, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

The Message Session Relay Protocol (MSRP) [RFC4975] 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 was initially defined in [RFC4975] to work over TCP and TLS connections, and over a WebSocket subprotocol specified by [RFC7977].

This document specifies the negotiation and transport of MSRP over a WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and MSRP is transported as a sub-protocol of a WebRTC data channel, without the TCP and TLS layers.

Defining MSRP as a data channel sub-protocol has many benefits:

Compared to WebSockets, which provide a message passing protocol to applications with no direct access to TCP or TLS sockets, data channels provide a low latency transport, leverage NAT-aware connectivity and security features of WebRTC, and are increasingly available not only in modern browsers but in other applications that use WebRTC for media or other purposes, such as IoT or telemetry in general, non-media data exchange, and so on.

Considering an MSRP endpoint as an MSRP application that uses a WebRTC data channel, 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.

This document updates [RFC4975] as described in Section 7.

2. Conventions

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 [RFC2119].

3. WebRTC Data Channel Considerations

3.1. MSRP Data Channel

In this document, an MSRP data channel is a data channel for which the instantiated sub-protocol is "msrp", and where the channel is negotiated using the SDP-based external negotiation method defined in [I-D.ietf-mmusic-data-channel-sdpneg].

The following WebRTC data channel property values [I-D.ietf-rtcweb-data-channel] apply to an MSRP data channel:

Property Value
Subprotocol Identifier msrp
Transmission reliability reliable
Transmission order in-order
Label See Section 4.3

4. SDP Considerations

This section describes the SDP considerations which are specific to an MSRP data channel

4.1. MSRP URI

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

  transport  /= "dc"
                ; Add "dc" to existing transports per [RFC4975] 

MSRP design provides for new transport bindings, see Section 6 of [RFC4975], MSRP implementations are expected to allow unrecognized transports for which there is no need to establish a connection to the resource described by the URI, as it's the case of data channels (Section 4.4).

4.2. msrp-scheme

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 as described in [I-D.ietf-rtcweb-data-channel].

4.3. Use of the dcmap Attribute

An offerer and answerer SHALL, in each offer and answer, include a dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within the media description of the SCTP association for each MSRP data channel session to be negotiated.

The attribute includes the following data channel parameters:

The labelstring is set by the MSRP application according to [I-D.ietf-mmusic-data-channel-sdpneg].

The offerer and answerer SHALL NOT include the max-retr and the max-time attribute parameters in the dcmap attribute.

The offerer and answerer MAY include the ordered attribute parameter in the dcmap attribute. If included, the attribute parameter value SHALL be set to "true".

Below is an example of the dcmap attribute for an MSRP session to be negotiated with stream-id=2 and label="chat":

a=dcmap:2 label="chat";subprotocol="msrp"

4.4. Use of the dcsa Attribute

An offerer and answerer SHALL, in each offer and answer, include a dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within the media description for the SCTP association for each MSRP-specific SDP attribute to be negotiated for each MSRP data channel being negotiated.

An offerer and answerer SHALL include a dcsa attribute for each of the following MSRP-specific SDP attributes:

It is considered a protocol error if one or more of the dcsa embedded attributes listed above are not included in an offer or answer.

An offerer and answerer MAY include a dcsa attribute for any of the following MSRP-specific SDP attributes, following the procedures defined for each attributes:

A subsequent offer or answer MAY update the previously negotiated MSRP subprotocol attributes while keeping the same subprotocol a=dcmap description. The semantics for newly negotiated MSRP subprotocol attributes are per [RFC4975].

When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. The MSRP data channel is established using the SDP offer/answer procedures defined in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are then transported on that data channel. This is different from legacy MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. However, when an endpoint receives an MSRP message over a data channel, it MUST still perform the MSRP-URI comparison procedures defined in [RFC4975].

4.5. Use of the dcsa embedded setup Attribute

As described in Section 4.4, the usage of a dsca embedded setup attribute is mandated for MSRP sessions over data channels. It is used to negotiate which MSRP session endpoint assumes the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no relationship with the DTLS connection establishment roles [I-D.ietf-mmusic-sctp-sdp].

The dcsa embedded setup attribute is of the form "a=dcsa:x setup:<role>", with x being the data channel's SCTP stream identifier, so that such attribute is explicitly associated with an MSRP session over a specific data channel.

4.6. Session Closing

An MSRP session is closed by closing the associated data channel, following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg].

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 [RFC4975] 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.

4.7. Support for MSRP File Transfer Function

SDP attributes specified in [RFC5547] for a file transfer "m=" line are embedded as subprotocol-specific attributes using the syntax defined in [I-D.ietf-mmusic-data-channel-sdpneg].

4.8. Example SDP Negotiation

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 [RFC4975] and [RFC5547].

   m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
   c=IN IP4 198.51.100.79
   a=max-message-size:100000
   a=sctp-port:5000
   a=setup:actpass
   a=fingerprint:SHA-1 \
       4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=tls-id:4a756565cddef001be82
   a=dcmap:0 label="chat";subprotocol="msrp"
   a=dcsa:0 msrp-cema
   a=dcsa:0 setup:active
   a=dcsa:0 accept-types:message/cpim text/plain
   a=dcsa:0 path:msrps://198.51.100.79:54111/si438dsaodes;dc
   a=dcmap:2 label="file transfer";subprotocol="msrp"
   a=dcsa:2 sendonly
   a=dcsa:2 msrp-cema
   a=dcsa:2 setup:active
   a=dcsa:2 accept-types:message/cpim
   a=dcsa:2 accept-wrapped-types:*
   a=dcsa:2 path:msrps://198.51.100.79:54111/jshA7we;dc
   a=dcsa:2 file-selector:name:"picture1.jpg" \
        type:image/jpeg size:1463440 hash:sha-1:\
        FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4
   a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep
   a=dcsa:2 file-disposition:attachment
   a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800"
   a=dcsa:2 file-icon:cid:id2@bob.example.com
   a=dcsa:2 file-range:1-1463440

5. MSRP Considerations

The procedures specified in [RFC4975] apply except when this document specifies otherwise. This section describes the MSRP considerations specific to an MSRP data channel.

5.1. Session Mapping

In this document, each MSRP session maps to one data channel exactly.

5.2. Session Opening

Section 4.5 describes how the active MSRP session endpoint role is negotiated. The active MSRP session endpoint uses the data channel established for this MSRP session by the generic data channel opening procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg].

As soon as the WebRTC 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.

5.3. Session Closing

The closure of an MSRP session SHALL be signaled via SDP following the requirements in Section 4.6

If the data channel used to transport the MSRP session fails and gets torn down, the endpoints SHALL consider the MSRP session failed. An MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP data channel.

5.4. Data Framing

Each text-based MSRP message is sent on the corresponding SCTP stream using standard MSRP framing and chunking procedures, as defined in [RFC4975], with each MSRP chunk delivered in a single SCTP user message. Therefore all sent MSRP chunks including the MSRP chunk header SHALL 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.

5.5. Data Sending, Receiving and Reporting

Data sending, receiving and reporting procedures SHALL conform to [RFC4975].

5.6. Support for MSRP File Transfer Function

[RFC5547] 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:

6. Gateway Considerations

This section describes the network configuration where one MSRP endpoint uses an MSRP data channel as MSRP transport, the other MSRP endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP endpoints interwork via a 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 an MSRP B2BUA to interwork all the procedures as necessary between the endpoints. No further specification is needed for this model.

Alternately, the gateway can provide transport level interworking between MSRP endpoints using different transport protocols. In accordance with Section 4.4, path attributes SHALL NOT be used for transport level interworking.

When the gateway performs transport level interworking between MSRP endpoints, all of the procedures in Section 5 and Section 4 apply to each peer, with the following additions:

7. Updates to RFC4975

This document updates [RFC4975], by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS.

8. Security Considerations

MSRP traffic over data channels is secured, including confidentiality, integrity and source authentication, as specified by [I-D.ietf-rtcweb-data-channel]

Note that discussion in [RFC4975] on MSRP message attribution to remote identities applies to data channel transport.

9. IANA Considerations

NOTE to RFC Editor: Please replace all instances of all instances of RFCXXXX with the number of this RFC.

9.1. msrps URI scheme

This document modifies the usage of the msrps URI scheme, registered by [RFC4975], adding DTLS as a protected transport indicated by the URI scheme.

A reference to RFCXXXX is added to the URI scheme "msrps" in the Uniform Resource Identifier (URI) Schemes Registry.

9.2. Subprotocol Identifier MSRP

This document adds a reference to the subprotocol identifier "msrp" in the "WebSocket Subprotocol Name Registry"

9.3. SDP Attributes

This document modifies the usage of the SDP setup attribute, if this attribute is included in an SDP 'dcsa' attribute associated to an MSRP data channel. The modified usage is described in Section 4.5.

This document also adds a reference to the following attributes in the Session Description Protocol (SDP) Parameters registry, if these attributes are included in SDP 'dcsa' attributes associated to an MSRP data channel. Usage of these attributes is described in section Section 4.4:

The usage level "dcsa(msrp)" is added to the registration of the SDP 'setup' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: setup
Usage level: dcsa(msrp)
Purpose: Negotiate the active role of an MSRP session over a data channel as per Section 4.5
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'path' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: path
Usage level: dcsa(msrp)
Purpose: Indicate an endpoint, but not used for routing, as described in Section 4.4
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'msrp-cema' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: msrp-cema
Usage level: dcsa(msrp)
Purpose: Indicate that the routing of MSRP messages transported on a data channel is more similar to the MSRP CEMA mechanism than the legacy MSRP routing mechanism.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'accept-types' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: accept-types
Usage level: dcsa(msrp)
Purpose: Contain the list of media types that the endpoint is willing to receive.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'accept-wrapped-types' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: accept-wrapped-types
Usage level: dcsa(msrp)
Purpose: Contain the list of media types that the endpoint is willing to receive in an MSRP message with multipart content.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'max-size' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: max-size
Usage level: dcsa(msrp)
Purpose: Indicate the largest message an MSRP endpoint wishes to accept.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'sendonly' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: sendonly
Usage level: dcsa(msrp)
Purpose: Negotiate the direction of the media flow on an MSRP data channel.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'recvonly' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: recvonly
Usage level: dcsa(msrp)
Purpose: Negotiate the direction of the media flow on an MSRP data channel.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'inactive' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: inactive
Usage level: dcsa(msrp)
Purpose: Negotiate the direction of the media flow on an MSRP data channel.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'sendrecv' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: sendrecv
Usage level: dcsa(msrp)
Purpose: Negotiate the direction of the media flow on an MSRP data channel.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-selector' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: file-selector
Usage level: dcsa(msrp)
Purpose: Indicate a file in an MSRP file transfer negotiation.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-transfer-id' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: file-transfer-id
Usage level: dcsa(msrp)
Purpose: Indicate a unique identifier of the file transfer operation in an MSRP file transfer negotiation.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-disposition' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: file-disposition
Usage level: dcsa(msrp)
Purpose: Provide a suggestion to the other endpoint about the intended disposition of the file in an MSRP file transfer negotiation.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-date' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: file-date
Usage level: dcsa(msrp)
Purpose: Indicate a date related to the file in an MSRP file transfer negotiation.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-icon' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: file-icon
Usage level: dcsa(msrp)
Purpose: Contain a pointer to a small preview icon representing the contents of the file in an MSRP file transfer negotiation.
Reference: RFCXXXX

The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-range' attribute in the Session Description Protocol (SDP) Parameters registry as follows:

Contact name: IESG
Contact email: iesg@ietf.org
Attribute name: file-range
Usage level: dcsa(msrp)
Purpose: Contain the range of transferred octets of the file in an MSRP file transfer negotiation.
Reference: RFCXXXX

10. Acknowledgments

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, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their invaluable comments.

Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed an earlier version, before the draft was re-adopted.

Julien Maisonneuve helped with the re-adoption of the draft, and Maridi R. Makaraju (Raju) contributed valuable comments after the draft was re-adopted.

11. CHANGE LOG

11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-18'

11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-17'

11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-16'

11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15'

11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14'

11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13'

11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12'

11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11'

11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10'

11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09'

11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08'

11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07'

11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06'

11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05'

11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04'

11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03'

11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02'

11.18. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01'

11.19. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00'

11.20. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01'

11.21. Changes against '-00'

12. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S. and M. Tuexen, "WebRTC Data Channel Establishment Protocol", Internet-Draft draft-ietf-rtcweb-data-protocol-09, January 2015.
[I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S. and M. Tuexen, "WebRTC Data Channels", Internet-Draft draft-ietf-rtcweb-data-channel-13, January 2015.
[I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J. and R. Even, "SDP-based Data Channel Negotiation", Internet-Draft draft-ietf-mmusic-data-channel-sdpneg-28, May 2019.
[I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S. and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", Internet-Draft draft-ietf-mmusic-sctp-sdp-26, April 2017.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006.
[RFC4975] Campbell, B., Mahy, R. and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007.
[RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S. and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, DOI 10.17487/RFC5547, May 2009.
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 2011.
[RFC6714] Holmberg, C., Blau, S. and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/RFC6714, August 2012.
[RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G. and R. Ravindranath, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", RFC 7977, DOI 10.17487/RFC7977, September 2016.

Authors' Addresses

Jose M. Recio (editor) Unaffiliated EMail: jose@ch3m4.com
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420, Finland EMail: christer.holmberg@ericsson.com