One document matched: draft-ejzak-dispatch-msrp-data-channel-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY DATAREQ SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-channel.xml">
<!ENTITY DATAPROTO SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtcweb-data-protocol-00.xml">
<!ENTITY DCSDPNEG SYSTEM "reference.I-D.draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.xml">
<!ENTITY JSEP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtcweb-jsep-02.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3758 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml">
<!ENTITY RFC4976 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4976.xml">
<!ENTITY RFC5547 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5547.xml">
<!ENTITY RFC6135 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6135.xml">
<!ENTITY RFC6714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6714.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ejzak-dispatch-msrp-data-channel-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MSRP over WebRTC data channels">MSRP over WebRTC data channels</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Ejzak" initials="R.P." surname="Ejzak">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>1960 Lucent Lane</street>
<!-- Reorder these if your country does things differently -->
<city>Naperville</city>
<region>Illinois</region>
<code>60563-1594</code>
<country>US</country>
</postal>
<phone>+1 630 979 7036</phone>
<email>richard.ejzak@alcatel-lucent.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jerome Marcon" initials="J.M." surname="Marcon">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Route de Villejust</street>
<!-- Reorder these if your country does things differently -->
<code>91620</code>
<city>Nozay</city>
<country>France</country>
</postal>
<email>jerome.marcon@alcatel-lucent.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>RAI</area>
<workgroup>DISPATCH</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a WebRTC data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in <xref target="I-D.ejzak-dispatch-webrtc-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).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Message Session Relay Protocol (MSRP) <xref target="RFC4975"></xref> 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.</t>
<t>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 <xref target="I-D.ietf-rtcweb-data-protocol"/>) and where MSRP is instantiated as a sub-protocol of this data channel.</t>
<t>Defining MSRP as a data channel sub-protocol has many benefits:
<list style='symbols'>
<t>provides to WebRTC applications a proven protocol enabling instant messaging, file transfer, image sharing</t>
<t>integrates those features with other RTCWeb voice, video and data features</t>
<t>leverages the SDP-based negotiation already defined for MSRP</t>
<t>allows the interworking with MSRP endpoints running on a TCP or TLS connection</t>
</list>
</t>
<t>Considering an MSRP endpoint being an MSRP WebRTC application, 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.</t>
</section>
<section title="Conventions">
<t>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 <xref target="RFC2119"></xref>.</t>
</section>
<section title="Terminology">
<t>This document uses the following terms:
<list style='hanging'>
<t>Data channel: A bidirectional channel consisting of paired SCTP outbound and inbound streams.</t>
<t>External negotiation: data channel negotiation based on out-of-band or in-band mechanisms other than the WebRTC data channel control protocol.</t>
<t>In-band: transmission through the peer-to-peer SCTP association.</t>
<t>Out-of-band: transmission through the WebRTC signaling path, e.g., using <xref target="I-D.ietf-rtcweb-jsep">JSEP</xref> and the SDP Offer/Answer model <xref target="RFC3264"></xref>.</t>
<t>MSRP data channel: A data channel specifically used to transport the messages of one MSRP session.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Principles">
<section title="MSRP data channel">
<t>In this document, an MSRP data channel is a WebRTC 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 <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>.</t>
</section>
<section title="Session mapping">
<t>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.</t>
</section>
<section title="MSRP URI">
<t>This document extends the MSRP URI syntax <xref target="RFC4975"></xref> by defining the new transport parameter value "dc":</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
transport = "tcp" / "dc" / 1*ALPHANUM
]]></artwork>
</figure>
</section>
<section title="msrp-scheme">
<t>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.</t>
</section>
</section>
<section title="End-to-end configuration" anchor="end_to_end">
<t>This section describes the network configuration where each MSRP endpoint is running MSRP over an SCTP/DTLS (data channel) connection.</t>
<section title="Basic MSRP support">
<section title="Session negotiation">
<section title="Use of webrtc-DataChannel attribute">
<t>The SDP offer shall include a webrtc-DataChannel attribute line (defined in <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>), within the m line for the SCTP association for each MSRP data channel session to be negotiated.</t>
<t>The attribute includes the following data channel parameters:
<list style='symbols'>
<t>"stream=" streamidentifier</t>
<t>"label=" labelstring</t>
<t>"subprotocol=" "MSRP"</t>
</list>
</t>
<t>The streamidentifier and labelstring are set by the MSRP application according to <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>. The max_retr, max_time and unordered parameters shall not be used.</t>
<t>The SDP answer shall include the exact same attribute line to indicate acceptance of the data channel instance.</t>
<t>The following is an example of the webrtc-DataChannel attribute for an MSRP session to be negotiated on SCTP port 5000 with stream=2 and label="chat":</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
a=webrtc-DataChannel:5000 stream=2;label="chat"; subprotocol="MSRP"
]]></artwork>
</figure>
</section>
<section title="Use of wdcsa attribute">
<t>The SDP offer shall also include a wdcsa attribute line (defined in <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>) within the m line for the SCTP association for each MSRP-specific SDP attribute to be negotiated for each MSRP data channel being negotiated. Note that the syntax allows for the attributes associated with multiple MSRP data channels (as well as attributes associated with other subprotocols) to be represented within a single m line.</t>
<t>The MSRP-specific items that can be negotiated include at least all of the following well-known attributes:
<list style='symbols'>
<t>defined in <xref target="RFC4975"/>: "path", "accept-types", "accept-wrapped-types", "max-size"</t>
<t>defined in <xref target="RFC4566"/>: "sendonly", "recvonly", "inactive", and "sendrecv"</t>
<t>defined in <xref target="RFC6135"/>: "setup"</t>
<t>defined in <xref target="RFC6714"/>: "msrp-cema"</t>
<t>defined in <xref target="RFC5547"/>: all the parameters related to MSRP file transfer. See <xref target="file_transfer"/>.</t>
</list>
</t>
<t>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.</t>
<t>The SDP answer shall include zero or more corresponding wdcsa attribute lines for each negotiated MSRP session, according to the MSRP-specific attribute negotiation rules in the corresponding specifications.</t>
</section>
<section title="Example SDP negotiation">
<t>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 <xref target="RFC4975"/> and <xref target="RFC5547"/>.</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
m=application 54111 DTLS/SCTP 5000
c=IN IP4 79.97.215.79
a=sctpmap:5000 webrtc-datachannel 16
a=webrtc-DataChannel:5000 stream=1;label="chat"; subprotocol="MSRP"
a=wdcsa:5000:1 accept-types:message/cpim text/plain
a=wdcsa:5000:1 path:msrps://bob.example.com:54111/si438dsaodes;dc
a=webrtc-DataChannel:5000 stream=2;label="file transfer"; \
subprotocol="MSRP"
a=wdcsa:5000:2 sendonly
a=wdcsa:5000:2 accept-types:message/cpim
a=wdcsa:5000:2 accept-wrapped-types:*
a=wdcsa:5000:2 path:msrps://bob.example.com:54111/jshA7we;dc
a=wdcsa:5000: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=wdcsa:5000:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=wdcsa:5000:2 file-disposition:attachment
a=wdcsa:5000:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=wdcsa:5000:2 file-icon:cid:id2@bob.example.com
a=wdcsa:5000:2 file-range:1-32349
]]></artwork>
</figure>
</section>
</section>
<section title="Session opening">
<t>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 <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>.</t>
<t>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.</t>
</section>
<section title="Data framing">
<t>Each text-based MSRP message is sent on the corresponding SCTP stream using standard MSRP framing and chunking procedures, as defined in <xref target="RFC4975"/>, with each MSRP chunk delivered in a single SCTP user message.</t>
</section>
<section title="Data sending and reporting">
<t>Data sending and reporting procedures shall conform to RFC 4975.</t>
</section>
<section title="Session closing">
<t>Either endpoint can close the MSRP session by closing the underlying data channel, using the generic data channel closing procedure defined in <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>. Closing an MSRP session should trigger an SDP negotiation where the SDP attributes for each affected data channel are removed.</t>
<t>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 <xref target="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 webRTC-DataChannel and wdcsa attributes.</t>
<t>The SDP answerer must ensure that no webRTC-DataChannel or wdcsa attributes are present in the SDP answer if no corresponding attributes are present in the received SDP offer.</t>
</section>
</section>
<section title="Support for MSRP File Transfer function" anchor="file_transfer">
<t><xref target="RFC5547"></xref> 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:
<list style='symbols'>
<t>As an MSRP session maps to one data channel, a file transfer session maps also to one data channel.</t>
<t>SDP attributes specified in <xref target="RFC5547"/> for a file transfer m-line are embedded as subprotocol-specific attributes using the syntax defined in <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg"/>.</t>
<t>Once the file transfer is complete, the same data channel MAY be reused for another file transfer.</t>
</list>
</t>
</section>
</section>
<section title="Gateway configuration">
<t>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.</t>
<t>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.</t>
<t>Alternately, the gateway can use CEMA procedures to provide transport level interworking between MSRP endpoints using different transport protocols as follows.</t>
<t>When the gateway performs transport level interworking between MSRP endpoints, all of the procedures in <xref target="end_to_end"/> apply to each peer, with the following additions:
<list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To be completed.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>To be completed.</t>
</section>
<section title="Acknowledgments">
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2119;
&JSEP;
&RFC3264;
&DATAPROTO;
&DATAREQ;
&DCSDPNEG;
&RFC4566;
&RFC4975;
&RFC4976;
&RFC5547;
&RFC6135;
&RFC6714;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor='WebRtcAPI' target='http://www.w3.org/TR/2012/WD-webrtc-20120821'>
<front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'>
<organization />
</author>
<author initials='D.' surname='Burnett' fullname='Daniel C. Burnett'>
<organization />
</author>
<author initials='A.' surname='Narayanan' fullname='Anant Narayanan'>
<organization />
</author>
<author initials='C.' surname='Jennings' fullname='Cullen Jennings'>
<organization />
</author>
<date month='August' day='21' year='2012' />
</front>
<seriesInfo name='World Wide Web Consortium WD' value='WD-webrtc-20120821' />
<format type='HTML' target='http://www.w3.org/TR/2012/WD-webrtc-20120821' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:10:48 |