MMUSIC J. Marcon Internet-Draft R. Ejzak Intended status: Informational Alcatel-Lucent Expires: January 10, 2014 July 09, 2013 MSRP over WebRTC data channels draft-marcon-msrp-over-webrtc-data-channels-00 Abstract The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communication using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a WebRTC data channel sub-protocol, using the SDP offer/exchange to negotiate out-of-band the sub-protocol specific parameters. 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 January 10, 2014. Marcon & Ejzak Expires January 10, 2014 [Page 1] Internet-Draft MSRP over WebRTC data channels July 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. WebRTC Data Channels . . . . . . . . . . . . . . . . . . . . 4 5. End-to-end configuration . . . . . . . . . . . . . . . . . . 5 5.1. Support for SDP-based sub-protocol negotiation . . . . . 5 5.1.1. SDP syntax . . . . . . . . . . . . . . . . . . . . . 5 5.1.1.1. Channel-specific setup parameters . . . . . . . . 5 5.1.1.2. Sub-protocol specific attributes . . . . . . . . 6 5.1.2. Procedures . . . . . . . . . . . . . . . . . . . . . 7 5.1.2.1. Opening a data channel . . . . . . . . . . . . . 7 5.1.2.2. Closing a data channel . . . . . . . . . . . . . 7 5.2. Support for MSRP data channels . . . . . . . . . . . . . 7 5.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 7 5.2.2. MSRP URI . . . . . . . . . . . . . . . . . . . . . . 8 5.2.3. Session negotiation . . . . . . . . . . . . . . . . . 8 5.2.4. Session opening . . . . . . . . . . . . . . . . . . . 8 5.2.5. Data sending and reporting . . . . . . . . . . . . . 8 5.2.6. Session closing . . . . . . . . . . . . . . . . . . . 9 5.3. Support for MSRP File Transfer function . . . . . . . . . 9 6. Gateway configuration . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Marcon & Ejzak Expires January 10, 2014 [Page 2] Internet-Draft MSRP over WebRTC data channels July 2013 The Message Session Relay Protocol (MSRP) [RFC4975] is currently defined to work over TCP connections. The RTCWeb working group has defined the concept of bi-directional data channels running on top of SCTP/DTLS. Each data channel consists of paired SCTP streams sharing the same SCTP Stream Identifier. Data channels are created by endpoint applications through the WebRTC API, and can be used to transport proprietary or well-defined protocols, which in the latter case can be signaled by the data channel "sub-protocol" parameter, conceptually similar to the WebSocket "sub-protocol". However, apart from the "sub-protocol" value transmitted to the peer, RTCWeb leaves open how endpoint applications can agree on how to instantiate a given sub-protocol on a data channel, whether it be in-band or out-of-band (or both). As an example, the SDP offer generated by the browser includes no channel-specific information. 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. Defining the MSRP as a data channel sub-protocol has many benefits: o provide to WebRTC applications a proven protocol enabling instant messaging, file transfer, image sharing o integrate those features with other RTCWeb voice and video features o leverage the SDP-based negotiation already defined for MSRP o allows the interworking with MSRP endpoints running on a TCP connection This document defines the use MSRP of over WebRTC data channels, where one MSRP endpoint is an MSRP WebRTC application and the other endpoint is either an MSRP WebRTC application or an MSRP TCP application. 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: Marcon & Ejzak Expires January 10, 2014 [Page 3] Internet-Draft MSRP over WebRTC data channels July 2013 Data channel: A bidirectional channel consisting of paired SCTP outbound and inbound streams. In-band: transmission through the peer-to-peer SCTP association. Out-of-band: transmission through the WebRTC signaling path, 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. WebRTC Data Channels This section summarizes how WebRTC data channels work in general. A WebRTC application creates a data channel via the WebRTC Data Channel API, by providing a number of setup parameters (sub-protocol, label, reliability, order of delivery, priority). The browser then opens in-band the data channel using the DATA CHANNEL OPEN message defined in [draft-jesup-rtcweb-data-protocol]. This message carries some of the channel-specific parameters passed by the application (sub-protocol, label, reliability, order of delivery). In case an SCTP association is already established, the browser transmits immediately the DATA CHANNEL OPEN message to the peer, on an unused SCTP stream. In case no SCTP association is established, the browser triggers for an SDP offer/answer exchange, and sends the DATA CHANNEL OPEN message(s) once the SCTP association is established (i.e. subsequently to the reception of the answer). The SDP offer generated by the browser is as per [draft-ietf-mmusic- sctp-sdp]. In brief, it contains one m-line for the SCTP association on top of which data channels will run, and one attribute per protocol assigned to the SCTP ports: m=application 54111 DTLS/SCTP 5000 5001 5002 c=IN IP4 79.97.215.79 a=sctpmap:5000 webrtc-datachannel 16 Marcon & Ejzak Expires January 10, 2014 [Page 4] Internet-Draft MSRP over WebRTC data channels July 2013 a=sctpmap:5001 bfcp 2 a=sctpmap:5002 t38 1 Note: A WebRTC browser will only create an sctpmap attribute for the webrtc-datachannel protocol, and will not create sctpmap attributes for other protocols such as bfcp or t38. This example shows the hypothetical power of the syntax to support multiplexing of SCTP associations for different protocols on the same DTLS connection. Note: this SDP syntax does not contain any channel-specific information. 5. End-to-end configuration This section describes the network configuration where each MSRP endpoint is a WebRTC endpoint, running MSRP over an SCTP/DTLS connection. 5.1. Support for SDP-based sub-protocol negotiation In the default procedures described in Section 4, the channel- specific parameters are notified in-band to the peer, rather than negotiated with the peer. Also, no mechanism is defined to transmit subprotocol-specific parameters to the peer. This section defines a means to negotiate channel-specific and subprotocol-specific parameters, using the out-of-band SDP offer/ exchange. 5.1.1. SDP syntax The SDP only contains the declaration of data channels for which an SDP-based negotiation is required, and that are either being created or already opened. 5.1.1.1. Channel-specific setup parameters For each of these data channels, the SDP lists one attribute line providing the Stream Identifier, sub-protocol, label, reliability, order of delivery, priority. a=webrtc-DataChannel:5000 stream=2;label="channel 2"; \ subprotocol="file transfer";max_retr=3 NOTE: the related SDP syntax has to be imported from version 3 of [draft-ietf-mmusic-sctp-sdp]. Marcon & Ejzak Expires January 10, 2014 [Page 5] Internet-Draft MSRP over WebRTC data channels July 2013 This line MUST be replicated without changes in the SDP answer, if the answerer accepts the offered data channel. This line MUST be replicated without changes in any subsequent offer or answer, as long as the data channel is still opened at the time of offer or answer generation. The Sub-protocol, label, reliability and order of delivery parameters MUST be equal to those transmitted in-band in the DATA CHANNEL OPEN message. The Stream Identifier MUST be equal to the SCTP Stream Identifier on which the DATA CHANNEL OPEN message is sent. 5.1.1.2. Sub-protocol specific attributes In the SDP, each data channel declaration MAY also be followed by other SDP attributes specific to the sub-protocol in use. Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub)protocol in another IETF specification. Each sub-protocol specific attribute such as "a=accept-types:text/ plain" that would normally be used to negotiate an instance of MSRP is replaced with an attribute of the form "a=wdcsa:sctp-port:stream- id original-attribute", where wdcsa stands for "webrtc-DataChannel sub-protocol attribute", sctp-port is the sctp port number assigned for webrtc-DataChannel on the media line, stream-id is the sctp stream id assigned to this instance of MSRP, and original-attribute represents the contents of the MSRP related attribute to be included. a=webrtc-DataChannel:5000 stream=2;label="channel 2"; \ subprotocol="MSRP";max_retr=3 a=wdcsa:5000:2 accept-types:text/plain Thus the attribute "a=wdcsa:5000:2 accept-types:text/plain" specifies that this instance of MSRP on stream id 2 accepts plain text files. As opposed to the data channel setup parameters, these parameters are subject to offer/answer negotiation. The same syntax applies to any other SDP attribute required for negotiation of this instance of the sub-protocol. Marcon & Ejzak Expires January 10, 2014 [Page 6] Internet-Draft MSRP over WebRTC data channels July 2013 5.1.2. Procedures 5.1.2.1. Opening a data channel Opening a data channel is done in-band by the DATA CHANNEL OPEN message. However when the sub-protocol requires an SDP-based negotiation, applications MUST NOT send data on this channel till both SDP negotiation and DATA CHANNEL OPEN message sending are done, which may happen in any order. When the application creates a new data channel (requiring some sub- protocol specific negotiation), the browser follows in any case a generic behavior: o if no SCTP association is established, the browser triggers the SDP negotiation, and sends the DATA CHANNEL OPEN message once the answer is received and the SCTP association initialized. o if an SCTP association is established, the browser does not trigger any SDP negotiation but instead immediately sends a DATA CHANNEL OPEN message. The application then initiates a new offer/ answer exchange Note: in this case, as the DATA CHANNEL OPEN message is sent before the offer is created, Stream ID conflicts between offers sent to the peer, and DATA CHANNEL OPEN messages received from the peer should not occur. The application has the task to complete the browser-generated offer (or answer) with the data channel and subprotocol specific parameters in scope of the SCTP m-line. The browser is expected to ignore those parameters when the completed offer (or answer) is applied locally. 5.1.2.2. Closing a data channel Closing a data channel is done in-band by the SSN reset mechanism, and does not trigger a new offer/answer exchange. 5.2. Support for MSRP data channels 5.2.1. Overview This document defines how MSRP can be used as a WebRTC sub-protocol, where the MSRP-related negotiation is done as part of the SDP-based data channel negotiation defined in Section 5.1.1.2. Marcon & Ejzak Expires January 10, 2014 [Page 7] Internet-Draft MSRP over WebRTC data channels July 2013 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. 5.2.2. MSRP URI This document extends the MSRP URI syntax [RFC3986] by defining the new transport parameter value "dc": transport = "tcp" / "dc" / 1*ALPHANUM 5.2.3. Session negotiation Using the syntax a=webrtc-DataChannel: , the SDP declaration of a given MSRP data channel can include at least all the following well-known parameters: o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- types", "max-size" o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and "sendrecv" o defined in [RFC6135]: "setup" o defined in [RFC6714]: "msrp-cema" o defined in [RFC5547]: all the parameters related to MSRP file transfer 5.2.4. Session opening The MSRP session is normally opened by the active MSRP endpoint, which sends an MSRP SEND message (empty or not) to the other MSRP endpoint. The active MSRP endpoint does not use the path attribute to open a transport connection to its peer. Instead, the active MSRP endpoint uses the DataChannel established for this MSRP session by the procedures in Section 5.1. The cema attribute is implicitly associated with every MSRP session using data channel transport. 5.2.5. Data sending and reporting Marcon & Ejzak Expires January 10, 2014 [Page 8] Internet-Draft MSRP over WebRTC data channels July 2013 5.2.6. Session closing Either endpoint can close the MSRP session by closing the underlying data channel. Closing an MSRP session should not trigger an SDP negotiation. 5.3. 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: o As an MSRP session maps to one data channel, a file transfer session maps also to one data channel. o SDP attributes specified in [RFC5547] for a file transfer m-line are embedded as subprotocol-specific attributes as defined in Section 5.1.1.2. o Each file chunk is transmitted over one SCTP user message. o Once the file transfer is complete, the same data channel MAY be reused for another file transfer. o Following the aborting of a file transfer, the SDP can be updated by adding the "inactive" attribute to the list of subprotocol- specific attributes associated with the corresponding data channel. 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. Marcon & Ejzak Expires January 10, 2014 [Page 9] Internet-Draft MSRP over WebRTC data channels July 2013 When the gateway performs transport level interworking between MSRP endpoints, all of the procedures in section Section 5.1 apply to each peer, with the following additions: o 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. o 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. o 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. 7. Security Considerations To be completed. 8. IANA Considerations To be completed. 9. Acknowledgments The authors wish to thank... for their invaluable comments. 10. References 10.1. Normative References [I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work in progress), October 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Marcon & Ejzak Expires January 10, 2014 [Page 10] Internet-Draft MSRP over WebRTC data channels July 2013 [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. 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 [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data Channels", draft-ietf-rtcweb-data-channel-04 (work in progress), February 2013. [I-D.jesup-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Protocol", draft-jesup-rtcweb-data-protocol-04 (work in progress), February 2013. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [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, . Marcon & Ejzak Expires January 10, 2014 [Page 11] Internet-Draft MSRP over WebRTC data channels July 2013 Authors' Addresses Jerome Marcon Alcatel-Lucent Route de Villejust Nozay 91620 France Email: jerome.marcon@alcatel-lucent.com Richard Ejzak Alcatel-Lucent 1960 Lucent Lane Naperville, Illinois 60563-1594 US Phone: +1 630 979 7036 Email: richard.ejzak@alcatel-lucent.com Marcon & Ejzak Expires January 10, 2014 [Page 12]