Internet DRAFT - draft-marcon-msrp-over-webrtc-data-channels
draft-marcon-msrp-over-webrtc-data-channels
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:<port> <param=value>, 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,
<http://www.w3.org/TR/2012/WD-webrtc-20120821>.
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]
