Internet DRAFT - draft-pd-msrp-webrtc
draft-pd-msrp-webrtc
Network Working Group P. Dunkley
Internet-Draft G. Llewellyn
Updates: 4975 (if approved) Crocodile RCS Ltd
Intended status: Standards Track May 10, 2013
Expires: November 11, 2013
The WebRTC Data Channel as a Transport for the Message Session Relay
Protocol (MSRP)
draft-pd-msrp-webrtc-00
Abstract
The WebRTC Data Channel enables two-way real-time communication
between browsers. This document updates normatively updates RFC 4975
to add support for WebRTC Data Channel as a transport for MSRP
(Message Session Relay Protocol). This will enable secure, low-
latency, structured peer-to-peer messaging between WebRTC end-points.
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 November 11, 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
Dunkley & Llewellyn Expires November 11, 2013 [Page 1]
Internet-Draft MSRP over WebRTC Data Channel May 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebRTC Data Channel . . . . . . . . . . . . . . . . . . . . 3
4. MSRP WebRTC Data Channel Transport . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . . 4
4.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . . 4
4.2.2. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Opening Data Channels for MSRP . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. SDP exchange . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 9
A.1. MSRP WebRTC Client Considerations . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Dunkley & Llewellyn Expires November 11, 2013 [Page 2]
Internet-Draft MSRP over WebRTC Data Channel May 2013
1. Introduction
The WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] enables
secure, reliable, low-latency message exchange between browsers.
Network Address Translation (NAT) issues between browsers are handled
through the use of ICE [RFC5245].
Modern web browsers include a WebRTC client stack complying with the
WebRTC API [WEBRTC-API] as specified by the W3C. The specification in
this document enables usage of MSRP in these scenarios.
This specification updates MSRP [RFC4975] to support WebRTC Data
Channel as a transport for the exchange of MSRP messages between
browsers.
MSRP over WebRTC is well suited for MSRP interactions between clients
that require security, reliability, low-latency, and where there are
no local policies requiring authorisation and/or logging of
interactions. For client-to-server messaging or where local policy
requires authentication and/or logging MSRP over WebSocket
[I-D.pd-dispatch-msrp-websocket] should be considered.
2. Terminology
All diagrams, examples, and notes in this specification are non-
normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.
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].
2.1. Definitions
MSRP WebRTC Client: An MSRP entity capable of opening WebRTC Data
Channel connections to other MSRP entities.
3. The WebRTC Data Channel
_This section is non-normative._
The WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] is a transport
layer on top of SCTP over DTLS over UDP in which clients exchange
message units in both directions.
WebRTC Data Channel defines message units to be used by applications
Dunkley & Llewellyn Expires November 11, 2013 [Page 3]
Internet-Draft MSRP over WebRTC Data Channel May 2013
for the exchange of data, so it provides a message boundary-
preserving transport layer. These message units contain binary data.
4. MSRP WebRTC Data Channel Transport
4.1. General
Each MSRP chunk MUST be carried within a single Data Channel message,
and a Data Channel message MUST NOT contain more than one MSRP chunk.
This simplifies parsing of MSRP messages for clients. When large
messages are sent MSRP chunking (as defined in section 5.1 of
[RFC4975]) MUST be used to split the message into several smaller
MSRP chunks.
4.2. Updates to RFC 4975
4.2.1. MSRP URI Transport Parameter
This document defines the value "dc" as the transport parameter value
for an MSRP URI [RFC3986] to be contacted using WebRTC Data Channel
as transport.
The updated augmented BNF (Backus-Naur Form) [RFC5234] for this
parameter is the following (the original BNF for this parameter can
be found in [RFC4975]):
transport = "tcp" / "dc" / 1*ALPHANUM
4.2.2. SDP
When using MSRP over WebRTC the SDP connection and media-lines will
be generated by browser when the "createOffer" method
[I-D.ietf-rtcweb-jsep] is called. MSRP WebRTC Clients MUST NOT
create connection and media-lines as described in section 8.1 of
[RFC4975].
Other MSRP related SDP fields are contained within attribute-lines
which MUST be added to browser generated SDP.
As all MSRP over WebRTC messages are routed directly between MSRP
WebRTC Clients there are no backwards compatibility issues with non-
WebRTC MSRP clients.
The "dc" transport parameter will appear in the endpoint URI in SDP
"path" attribute ([RFC4975] section 8.2).
Dunkley & Llewellyn Expires November 11, 2013 [Page 4]
Internet-Draft MSRP over WebRTC Data Channel May 2013
4.3. Opening Data Channels for MSRP
Section 5.4 of [I-D.ietf-mmusic-sctp-sdp] defines the "subprotocol
Attribute" enabling the client to indicate which protocol it would
like to speak on a channel. This document defines a new subprotocol
of "MSRP" which MUST be used on channels carrying MSRP over WebRTC.
When establishing MSRP sessions clients often include a lot of meta-
data [RFC5547] about the intended use of the session in attribute-
lines within the SDP (for example, when performing file-transfer
filename, type, and size are indicated). There is no information in
these attribute-lines that that will enable a client to associate
them with a specific channel. To solve this issue MSRP WebRTC
Clients MUST create SCTP associations with only 1 channel (that is,
one stream in each direction).
Section 5 of [I-D.jesup-rtcweb-data-protocol] allows applications
to specify the number of streams for an SCTP association. It is
usually the case that more streams are desirable to enable
additional communication between browsers without the need for
renegotiation and to create new Data Channels; this is not
applicable to MSRP. Additional MSRP sessions require renegotion
so that the meta-data [RFC5547] describing the intended use of the
session can be exchanged.
5. Examples
5.1. SDP exchange
The following example shows SDP that could be included in a SIP
message to set up an MSRP session between Alice and Bob.
Note that SDP does not permit line folding. A "\" in the examples
shows a line continuation due to limitations in line length of this
document. Neither the backslash nor the extra CRLF is included in
the actual SDP.
Alice makes an offer:
m=application 54111 DTLS/SCTP 5000
c=IN IP4 79.97.215.79
a=sctpmap:5000 webrtc-DataChannel 1
a=webrtc-DataChannel:5000 \
stream=1;label="channel 1";subprotocol="msrp"
a=accept-types:message/cpim text/plain text/html
a=path:msrp://df7jal23ls0d.invalid:5000/98cjs;dc
Dunkley & Llewellyn Expires November 11, 2013 [Page 5]
Internet-Draft MSRP over WebRTC Data Channel May 2013
In this offer, Alice wishes to receive MSRP messages using the WebRTC
Data Channel. She can accept message/cpim, text/plain, and text/html
message bodies in SEND requests.
Bob's answer to this offer could look like:
m=application 63241 DTLS/SCTP 3000
c=IN IP4 79.97.215.84
a=sctpmap:3000 webrtc-DataChannel 1
a=webrtc-DataChannel:3000
stream=1;label="channel 1";subprotocol="msrp"
a=accept-types:message/cpim text/plain
a=path:msrp://jk3apo92lf5w.invalid:3000/20ksw;dc
Here Bob wishes to receive the MSRP messages. He can accept only
message/cpim and text/plain message bodies in SEND requests and has
rejected the text/html content offered by Alice.
5.2. SEND
Alice (MSRP DC) Bob
| |
|SEND F1 |
|---------------------------->|
|200 OK F2 |
|<----------------------------|
In the same scenario Alice sends an instant message to Bob (session
details having been previously negotiated by some other mechanism -
such as SDP.
Dunkley & Llewellyn Expires November 11, 2013 [Page 6]
Internet-Draft MSRP over WebRTC Data Channel May 2013
F1 SEND Alice -> Bob (transport DC)
MSRP 6aef SEND
To-Path: msrp://jk3apo92lf5w.invalid:3000/20ksw;dc
From-Path: msrp://df7jal23ls0d.invalid:5000/98cjs;dc
Success-Report: no
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------6aef$
F2 200 OK Bob -> Alice (transport DC)
MSRP 6aef 200 OK
To-Path: msrp://df7jal23ls0d.invalid:5000/98cjs;dc
From-Path: msrp://jk3apo92lf5w.invalid:3000/20ksw;dc
-------6aef$
6. Security Considerations
The WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] provides
secure communication between browsers. As such there are no specific
security considerations for this draft.
7. IANA Considerations
This specification does not require any IANA registry changes.
8. Acknowledgements
Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and
Victor Pascual, the authors of [I-D.ietf-sipcore-sip-websocket] which
has inspired this draft.
9. References
9.1. Normative References
[I-D.ietf-mmusic-sctp-sdp]
Loreto, S. and G. Camarillo, "Stream Control Transmission
Protocol (SCTP)-Based Media Transport in the Session
Dunkley & Llewellyn Expires November 11, 2013 [Page 7]
Internet-Draft MSRP over WebRTC Data Channel May 2013
Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-03
(work in progress), January 2013.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References
[I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session
Establishment Protocol", draft-ietf-rtcweb-jsep-03 (work
in progress), February 2013.
[I-D.ietf-sipcore-sip-websocket]
Castillo, I., Millan, J., and V. Pascual, "The WebSocket
Protocol as a Transport for the Session Initiation
Protocol (SIP)", draft-ietf-sipcore-sip-websocket-08 (work
in progress), March 2013.
[I-D.pd-dispatch-msrp-websocket]
Dunkley, P., Llewellyn, G., and V. Pascual, "The WebSocket
Protocol as a Transport for the Message Session Relay
Protocol (MSRP)", draft-pd-dispatch-msrp-websocket-01
(work in progress), January 2013.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Dunkley & Llewellyn Expires November 11, 2013 [Page 8]
Internet-Draft MSRP over WebRTC Data Channel May 2013
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[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.
[WEBRTC-API]
W3C, Bergkvist, A., Ed., Burnett, D., Ed., Jennings, C.,
Ed., and A. Narayanan, Ed., "WebRTC 1.0: Real-time
Communication Between Browsers", September 2012.
Appendix A. Implementation Guidelines
_This section is non-normative._
A.1. MSRP WebRTC Client Considerations
The JavaScript stack in web browsers does not have the ability to
discover the local transport address used for originating WebRTC
connections. Therefore the MSRP WebSocket Client constructs a domain
name consisting of a random token followed by the ".invalid" top-
level domain name, as stated in [RFC2606], and uses it within its
From-Path headers.
Authors' Addresses
Peter Dunkley
Crocodile RCS Ltd
Forum 3, Parkway
Solent Business Park, Whiteley
Fareham PO15 7FH
United Kingdom
Email: peter.dunkley@crocodile-rcs.com
Dunkley & Llewellyn Expires November 11, 2013 [Page 9]
Internet-Draft MSRP over WebRTC Data Channel May 2013
Gavin Llewellyn
Crocodile RCS Ltd
Forum 3, Parkway
Solent Business Park, Whiteley
Fareham PO15 7FH
United Kingdom
Email: gavin.llewellyn@crocodile-rcs.com
Dunkley & Llewellyn Expires November 11, 2013 [Page 10]
