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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 2.1. Definitions
• 3. The WebRTC Data Channel
• 4. MSRP WebRTC Data Channel Transport
• 4.1. General
• 4.2. Updates to RFC 4975
• 4.2.1. MSRP URI Transport Parameter
• 4.2.2. SDP
• 4.3. Opening Data Channels for MSRP
• 5. Examples
• 5.1. SDP exchange
• 5.2. SEND
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Implementation Guidelines
• A.1. MSRP WebRTC Client Considerations
• Authors' Addresses

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

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

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]):

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

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

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.

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

9.2. Informative References

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