DISPATCH R.P. Ejzak
Internet-Draft J.M. Marcon
Intended status: Standards Track Alcatel-Lucent
Expires: April 24, 2014 October 21, 2013

MSRP over WebRTC data channels
draft-ejzak-dispatch-msrp-data-channel-00

Abstract

This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a WebRTC data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint).

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 http://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 April 24, 2014.

Copyright Notice

Copyright (c) 2013 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 (http://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 is currently defined to work over TCP and TLS connections.

This document defines the negotiation and transport of this MSRP protocol over WebRTC data channels, where a data channel is a bi-directional communication channel running on top of SCTP/DTLS (as per [I-D.ietf-rtcweb-data-protocol]) and where MSRP is instantiated as a sub-protocol of this data channel.

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

Considering an MSRP endpoint being an MSRP WebRTC application, 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.

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. Terminology

This document uses the following terms:

Data channel: A bidirectional channel consisting of paired SCTP outbound and inbound streams.
External negotiation: data channel negotiation based on out-of-band or in-band mechanisms other than the WebRTC data channel control protocol.
In-band: transmission through the peer-to-peer SCTP association.
Out-of-band: transmission through the WebRTC signaling path, e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer model [RFC3264].
MSRP data channel: A data channel specifically used to transport the messages of one MSRP session.
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.

4. Principles

4.1. MSRP data channel

In this document, an MSRP data channel is a WebRTC 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 [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg].

4.2. Session mapping

In this design, the MSRP connection maps to the SCTP association and the port assigned to data channels, and each MSRP session maps to one data channel exactly.

4.3. MSRP URI

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

transport  =  "tcp" / "dc" / 1*ALPHANUM
					

4.4. 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.

5. End-to-end configuration

This section describes the network configuration where each MSRP endpoint is running MSRP over an SCTP/DTLS (data channel) connection.

5.1. Basic MSRP support

5.1.1. Session negotiation

5.1.1.1. Use of webrtc-DataChannel attribute

The SDP offer shall include a webrtc-DataChannel attribute line (defined in [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]), within the m line for the SCTP association for each MSRP data channel session to be negotiated.

The attribute includes the following data channel parameters:

The streamidentifier and labelstring are set by the MSRP application according to [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]. The max_retr, max_time and unordered parameters shall not be used.

The SDP answer shall include the exact same attribute line to indicate acceptance of the data channel instance.

The following is an example of the webrtc-DataChannel attribute for an MSRP session to be negotiated on SCTP port 5000 with stream=2 and label="chat":

a=webrtc-DataChannel:5000 stream=2;label="chat"; subprotocol="MSRP"
						

5.1.1.2. Use of wdcsa attribute

The SDP offer shall also include a wdcsa attribute line (defined in [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]) within the m line for the SCTP association for each MSRP-specific SDP attribute to be negotiated for each MSRP data channel being negotiated. Note that the syntax allows for the attributes associated with multiple MSRP data channels (as well as attributes associated with other subprotocols) to be represented within a single m line.

The MSRP-specific items that can be negotiated include at least all of the following well-known attributes:

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 wdcsa attribute lines for each negotiated MSRP session, according to the MSRP-specific attribute negotiation rules in the corresponding specifications.

5.1.1.3. Example SDP negotiation

The following is an example of an m line for DataChannels 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 DTLS/SCTP 5000
c=IN IP4 79.97.215.79
a=sctpmap:5000 webrtc-datachannel 16
a=webrtc-DataChannel:5000 stream=1;label="chat"; subprotocol="MSRP"
a=wdcsa:5000:1 accept-types:message/cpim text/plain
a=wdcsa:5000:1 path:msrps://bob.example.com:54111/si438dsaodes;dc
a=webrtc-DataChannel:5000 stream=2;label="file transfer"; \
     subprotocol="MSRP"
a=wdcsa:5000:2 sendonly
a=wdcsa:5000:2 accept-types:message/cpim
a=wdcsa:5000:2 accept-wrapped-types:*
a=wdcsa:5000:2 path:msrps://bob.example.com:54111/jshA7we;dc
a=wdcsa:5000:2 file-selector:name:"My cool picture.jpg" \
     type:image/jpeg size:32349 hash:sha-1: \
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=wdcsa:5000:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=wdcsa:5000:2 file-disposition:attachment
a=wdcsa:5000:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=wdcsa:5000:2 file-icon:cid:id2@bob.example.com
a=wdcsa:5000:2 file-range:1-32349
						

5.1.2. Session opening

The active MSRP 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 [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg].

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. The msrp-cema attribute is implicitly associated with every MSRP session using data channel transport.

5.1.3. 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.

5.1.4. Data sending and reporting

Data sending and reporting procedures shall conform to RFC 4975.

5.1.5. Session closing

Either endpoint can close the MSRP session by closing the underlying data channel, using the generic data channel closing procedure defined in [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]. Closing an MSRP session should trigger an SDP negotiation where the SDP attributes for each affected data channel are removed.

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 webRTC-DataChannel and wdcsa attributes.

The SDP answerer must ensure that no webRTC-DataChannel or wdcsa attributes are present in the SDP answer if no corresponding attributes are present in the received SDP offer.

5.2. 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 WebRTC endpoints, with the following considerations:

6. Gateway configuration

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.

Specifically, a gateway can be configured to interwork an MSRP session using 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 Section 5 apply to each peer, with the following additions:

7. Security Considerations

To be completed.

8. IANA Considerations

To be completed.

9. Acknowledgments

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

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Establishment Protocol", Internet-Draft draft-ietf-rtcweb-jsep-02, October 2012.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S. and M. Tuexen, "WebRTC Data Channel Protocol", Internet-Draft draft-ietf-rtcweb-data-protocol-00, July 2013.
[I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S. and M. Tuexen, "RTCWeb Data Channels", Internet-Draft draft-ietf-rtcweb-data-channel-04, February 2013.
[I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] Ejzak, R. and J. Marcon, "SDP-based WebRTC data channel negotiation", Internet-Draft draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00, October 2013.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4975] Campbell, B., Mahy, R. and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R. and A.B. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 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, May 2009.
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, 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, August 2012.

10.2. Informative References

[WebRtcAPI] Bergkvist, A., Burnett, D., Narayanan, A. and C. Jennings, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20120821, August 2012.

Authors' Addresses

Richard Ejzak Alcatel-Lucent 1960 Lucent Lane Naperville, Illinois 60563-1594 US Phone: +1 630 979 7036 EMail: richard.ejzak@alcatel-lucent.com
Jerome Marcon Alcatel-Lucent Route de Villejust Nozay, 91620 France EMail: jerome.marcon@alcatel-lucent.com