Internet DRAFT - draft-ejzak-mmusic-msrp-usage-data-channel
draft-ejzak-mmusic-msrp-usage-data-channel
MMUSIC K. Drage, Ed.
Internet-Draft M. Makaraju
Intended status: Standards Track J. Stoetzer-Bradler
Expires: April 30, 2015 Alcatel-Lucent
R. Ejzak
J. Marcon
Unaffiliated
October 27, 2014
MSRP over SCTP/DTLS data channels
draft-ejzak-mmusic-msrp-usage-data-channel-01
Abstract
This document specifies how the Message Session Relay Protocol (MSRP)
can be instantiated as a data channel sub-protocol, using the the SDP
offer/answer exchange-based external negotiation defined in
[I-D.ejzak-mmusic-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 30, 2015.
Copyright Notice
Copyright (c) 2014 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
Drage, et al. Expires April 30, 2015 [Page 1]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
(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. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. MSRP data channel . . . . . . . . . . . . . . . . . . . . 4
4.2. Session mapping . . . . . . . . . . . . . . . . . . . . . 4
4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 4
5. End-to-end configuration . . . . . . . . . . . . . . . . . . 4
5.1. Basic MSRP support . . . . . . . . . . . . . . . . . . . 4
5.1.1. Session negotiation . . . . . . . . . . . . . . . . . 5
5.1.1.1. Use of dcmap attribute . . . . . . . . . . . . . 5
5.1.1.2. Use of dcsa attribute . . . . . . . . . . . . . . 5
5.1.1.3. Example SDP negotiation . . . . . . . . . . . . . 6
5.1.2. Session opening . . . . . . . . . . . . . . . . . . . 7
5.1.3. Data framing . . . . . . . . . . . . . . . . . . . . 7
5.1.4. Data sending and reporting . . . . . . . . . . . . . 7
5.1.5. Session closing . . . . . . . . . . . . . . . . . . . 7
5.2. Support for MSRP File Transfer function . . . . . . . . . 7
6. Gateway configuration . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Changes against '-00' . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
Drage, et al. Expires April 30, 2015 [Page 2]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
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:
o provides to applications a proven protocol enabling instant
messaging, file transfer, image sharing
o integrates those features with other RTCWeb voice, video and data
features
o leverages the SDP-based negotiation already defined for MSRP
o 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[I-D.ietf-rtcweb-data-protocol],
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 call control signaling path,
e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer
model [RFC3264].
Drage, et al. Expires April 30, 2015 [Page 3]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
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 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-mmusic-data-channel-sdpneg].
4.2. Session mapping
In this design, the MSRP connection maps to the SCTP association and
the "SCTP stream pair" 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 /= "dc" / 1*ALPHANUM
; Add "dc" to existing transports per RFC4975
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
Drage, et al. Expires April 30, 2015 [Page 4]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
5.1.1. Session negotiation
5.1.1.1. Use of dcmap attribute
The SDP offer shall include a dcmap attribute line (defined in
[I-D.ejzak-mmusic-data-channel-sdpneg]), 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:
o "label=" labelstring
o "subprotocol=" "MSRP"
The labelstring is set by the MSRP application according to
[I-D.ejzak-mmusic-data-channel-sdpneg]. The max-retr, max-time and
ordered parameters shall not be used.
Rest of the SDP offer/answer procedures are per
[I-D.ejzak-mmusic-data-channel-sdpneg]
The following is an example of the dcmap attribute for an MSRP
session to be negotiated (on default SCTP port 5000) with stream=2
and label="chat":
a=dcmap:2 label="chat"; subprotocol="MSRP"
5.1.1.2. Use of dcsa attribute
The SDP offer shall also include a dcsa attribute line (defined in
[I-D.ejzak-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.
The MSRP-specific items that can be negotiated include at least all
of the following well-known attributes:
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"
Drage, et al. Expires April 30, 2015 [Page 5]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
o defined in [RFC5547]: all the parameters related to MSRP file
transfer. See Section 5.2.
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
[RFC4975]
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 webrtc-datachannel
c=IN IP4 79.97.215.79
a=fmtp:webrtc-datachannel max-message-size=100000
a=sctp-port 5000
a=dcmap:1 label="chat"; subprotocol="MSRP"
a=dcsa:1 accept-types:message/cpim text/plain
a=dcsa:1 path:msrps://bob.example.com:54111/si438dsaodes;dc
a=dcmap:2 label="file transfer"; \
subprotocol="MSRP"
a=dcsa::2 sendonly
a=dcsa:2 accept-types:message/cpim
a=dcsa:2 accept-wrapped-types:*
a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc
a=dcsa: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=dcsa:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=dcsa:2 file-disposition:attachment
a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=dcsa:2 file-icon:cid:id2@bob.example.com
a=dcsa:2 file-range:1-32349
Drage, et al. Expires April 30, 2015 [Page 6]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
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-mmusic-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
Closing of an MSRP session is done using the generic data channel
closing procedure defined in [I-D.ejzak-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.
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 endpoints using data channel, with the following
considerations:
Drage, et al. Expires April 30, 2015 [Page 7]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
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 using the syntax
defined in [I-D.ejzak-mmusic-data-channel-sdpneg].
o Once the file transfer is complete, the same data channel MAY be
reused for another file transfer.
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:
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.
Drage, et al. Expires April 30, 2015 [Page 8]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
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. CHANGE LOG
10.1. Changes against '-00'
o Transport parameter change for MSRP to allow MSRP RFC transports.
o Clarification on SDP offer/answer and removing duplicated
procedures and refer them to
[I-D.ejzak-mmusic-data-channel-sdpneg].
11. References
11.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., Jennings, C., and E. Rescorla, "Javascript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-07
(work in progress), July 2014.
[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
Establishment Protocol", draft-ietf-rtcweb-data-
protocol-08 (work in progress), September 2014.
Drage, et al. Expires April 30, 2015 [Page 9]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-12 (work in
progress), September 2014.
[I-D.ejzak-mmusic-data-channel-sdpneg]
Drage, K., Ejzak, R., and J. Marcon, "SDP-based "SCTP over
DTLS" data channel negotiation", draft-ejzak-mmusic-data-
channel-sdpneg-01 (work in progress), October 2014.
[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. 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.
11.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,
<http://www.w3.org/TR/2012/WD-webrtc-20120821>.
Authors' Addresses
Drage, et al. Expires April 30, 2015 [Page 10]
Internet-Draft MSRP over SCTP/DTLS data channels October 2014
Keith Drage (editor)
Alcatel-Lucent
Quadrant, Stonehill Green, Westlea
Swindon
UK
Email: keith.drage@alcatel-lucent.com
Raju Makaraju
Alcatel-Lucent
2000 Lucent Lane
Naperville, Illinois
US
Email: Raju.Makaraju@alcatel-lucent.com
Juergen Stoetzer-Bradler
Alcatel-Lucent
Lorenzstrasse 10
D-70435 Stuttgart
Germany
Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com
Richard Ejzak
Unaffiliated
Email: richard.ejzak@gmail.com
Jerome Marcon
Unaffiliated
Drage, et al. Expires April 30, 2015 [Page 11]
