draft-ietf-mmusic-msrp-usage-data-channel-00.txt   draft-ietf-mmusic-msrp-usage-data-channel-01.txt 
MMUSIC K. Drage, Ed. MMUSIC K. Drage, Ed.
Internet-Draft M. Makaraju Internet-Draft M. Makaraju
Intended status: Standards Track J. Stoetzer-Bradler Intended status: Standards Track J. Stoetzer-Bradler
Expires: July 31, 2015 Alcatel-Lucent Expires: September 9, 2015 Alcatel-Lucent
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
January 27, 2015 March 8, 2015
MSRP over SCTP/DTLS data channels MSRP over Data Channels
draft-ietf-mmusic-msrp-usage-data-channel-00 draft-ietf-mmusic-msrp-usage-data-channel-01
Abstract Abstract
This document specifies how the Message Session Relay Protocol (MSRP) This document specifies how the Message Session Relay Protocol (MSRP)
can be instantiated as a data channel sub-protocol, using the the SDP can be instantiated as a data channel sub-protocol, using the the SDP
offer/answer exchange-based external negotiation defined in offer/answer exchange-based external negotiation defined in
[I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations [I-D.ietf-mmusic-data-channel-sdpneg]. Two network configurations
are documented: a WebRTC end-to-end configuration (connecting two are documented: a WebRTC end-to-end configuration (connecting two
MSRP over data channel endpoints), and a gateway configuration MSRP over data channel endpoints), and a gateway configuration
(connecting an MSRP over data channel endpoint with an MSRP over TCP (connecting an MSRP over data channel endpoint with an MSRP over TCP
endpoint). endpoint).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2015. This Internet-Draft will expire on September 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. MSRP data channel . . . . . . . . . . . . . . . . . . . . 4 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4
4.2. Session mapping . . . . . . . . . . . . . . . . . . . . . 4 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 4
4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 4 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 4
5. End-to-end configuration . . . . . . . . . . . . . . . . . . 4 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5
5.1. Basic MSRP support . . . . . . . . . . . . . . . . . . . 5 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 5
5.1.1. Session negotiation . . . . . . . . . . . . . . . . . 5 5.1.1. Session Negotiation . . . . . . . . . . . . . . . . . 5
5.1.1.1. Use of dcmap attribute . . . . . . . . . . . . . 5 5.1.1.1. Use of dcmap Attribute . . . . . . . . . . . . . 5
5.1.1.2. Use of dcsa attribute . . . . . . . . . . . . . . 5 5.1.1.2. Use of dcsa Attribute . . . . . . . . . . . . . . 5
5.1.1.3. Example SDP negotiation . . . . . . . . . . . . . 6 5.1.1.3. Example SDP Negotiation . . . . . . . . . . . . . 6
5.1.2. Session opening . . . . . . . . . . . . . . . . . . . 7 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 7
5.1.3. Data framing . . . . . . . . . . . . . . . . . . . . 7 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 7
5.1.4. Data sending and reporting . . . . . . . . . . . . . 7 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 7
5.1.5. Session closing . . . . . . . . . . . . . . . . . . . 7 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 8
5.2. Support for MSRP File Transfer function . . . . . . . . . 7 5.2. Support for MSRP File Transfer Function . . . . . . . . . 8
6. Gateway configuration . . . . . . . . . . . . . . . . . . . . 8 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-01' . . . . . . . . . . . . . . . . . . . . . . 9 channel-00' . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Changes against '-00' . . . . . . . . . . . . . . . . . 9 10.2. Changes against 'draft-ejzak-mmusic-msrp-usage-data-
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 channel-01' . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.3. Changes against '-00' . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for
transmitting a series of related instant messages in the context of a transmitting a series of related instant messages in the context of a
session. In addition to instant messaging, MSRP can also be used for session. In addition to instant messaging, MSRP can also be used for
image sharing or file transfer. MSRP is currently defined to work image sharing or file transfer. MSRP is currently defined to work
over TCP and TLS connections. over TCP and TLS connections.
This document defines the negotiation and transport of this MSRP This document defines the negotiation and transport of this MSRP
protocol over WebRTC data channels, where a data channel is a bi- protocol over data channels, where a data channel is a bi-directional
directional communication channel running on top of SCTP/DTLS (as per communication channel running on top of SCTP/DTLS (as per
[I-D.ietf-rtcweb-data-protocol]) and where MSRP is instantiated as a [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a
sub-protocol of this data channel. sub-protocol of this data channel.
Defining MSRP as a data channel sub-protocol has many benefits: Defining MSRP as a data channel sub-protocol has many benefits:
o provides to applications a proven protocol enabling instant o provides to applications a proven protocol enabling instant
messaging, file transfer, image sharing messaging, file transfer, image sharing
o integrates those features with other RTCWeb voice, video and data o integrates those features with other RTCWeb voice, video and data
features features
o leverages the SDP-based negotiation already defined for MSRP o leverages the SDP-based negotiation already defined for MSRP
o allows the interworking with MSRP endpoints running on a TCP or o allows the interworking with MSRP endpoints running on a TCP or
TLS connection TLS connection
Considering an MSRP endpoint being an MSRP application that uses data Considering an MSRP endpoint being an MSRP application that uses data
channel from WebRTC specifications[I-D.ietf-rtcweb-data-protocol], channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel],
this document describes two configurations where the other endpoint this document describes two configurations where the other endpoint
is respectively either another MSRP over data channel endpoint (e.g., is respectively either another MSRP over data channel endpoint (e.g.,
a WebRTC application) or an MSRP endpoint using either TCP or TLS a WebRTC application) or an MSRP endpoint using either TCP or TLS
transport. transport.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the following terms: This document uses the following terms:
Data channel: A bidirectional channel consisting of paired SCTP Data channel: A WebRTC data channel as specified in
outbound and inbound streams. [I-D.ietf-rtcweb-data-channel].
External negotiation: data channel negotiation based on out-of- MSRP data channel: A data channel specifically used to transport
band or in-band mechanisms other than the WebRTC data channel the messages of one MSRP session.
control protocol.
In-band: transmission through the peer-to-peer SCTP association. External negotiation: Data channel negotiation based on out-of-
band or in-band mechanisms other than the Data Channel
Establishment Protocol specified in
[I-D.ietf-rtcweb-data-protocol].
Out-of-band: transmission through the call control signaling path, 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 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer
model [RFC3264]. 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: From the perspective of one of the agents in a session, its
peer is the other agent. Specifically, from the perspective of peer is the other agent. Specifically, from the perspective of
the SDP offerer, the peer is the SDP answerer. From the the SDP offerer, the peer is the SDP answerer. From the
perspective of the SDP answerer, the peer is the SDP offerer. perspective of the SDP answerer, the peer is the SDP offerer.
4. Principles 4. Principles
4.1. MSRP data channel 4.1. MSRP Data Channel
In this document, an MSRP data channel is a data channel for which In this document, an MSRP data channel is a data channel for which
the instantiated sub-protocol is "msrp", and where the MSRP-related the instantiated sub-protocol is "msrp", and where the MSRP-related
negotiation is done as part of the SDP-based external negotiation negotiation is done as part of the SDP-based external negotiation
method defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. method defined in [I-D.ietf-mmusic-data-channel-sdpneg].
4.2. Session mapping 4.2. Session Mapping
In this design, the MSRP connection maps to the SCTP association and In this design, the MSRP session maps to the SCTP association and the
the "SCTP stream pair" assigned to data channels, and each MSRP "SCTP stream pair" assigned to the data channel, and each MSRP
session maps to one data channel exactly. session maps to one data channel exactly.
4.3. MSRP URI 4.3. MSRP URI
This document extends the MSRP URI syntax [RFC4975] by defining the This document extends the MSRP URI syntax [RFC4975] by defining the
new transport parameter value "dc": new transport parameter value "dc":
transport /= "dc" / 1*ALPHANUM transport /= "dc" / 1*ALPHANUM
; Add "dc" to existing transports per [RFC4975] ; Add "dc" to existing transports per [RFC4975]
4.4. msrp-scheme 4.4. msrp-scheme
The msrp-scheme portion of the MSRP-URI that represents an MSRP data 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 channel endpoint (used in the SDP path attribute and in the MSRP
message headers) is always "msrps", which indicates that the MSRP message headers) is always "msrps", which indicates that the MSRP
data channel is always secured using DTLS. data channel is always secured using DTLS.
5. End-to-end configuration 5. End-to-End Configuration
This section describes the network configuration where each MSRP This section describes the network configuration where each MSRP
endpoint is running MSRP over an SCTP/DTLS (data channel) connection. endpoint is running MSRP over a data channel.
5.1. Basic MSRP support 5.1. Basic MSRP Support
5.1.1. Session negotiation 5.1.1. Session Negotiation
5.1.1.1. Use of dcmap attribute 5.1.1.1. Use of dcmap Attribute
The SDP offer shall include a dcmap attribute line (defined in The SDP offer shall include a dcmap attribute line (defined in
[I-D.ejzak-mmusic-data-channel-sdpneg]), within the media description [I-D.ietf-mmusic-data-channel-sdpneg]), within the media description
for the SCTP association for each MSRP data channel session to be for the SCTP association for each MSRP data channel session to be
negotiated. negotiated.
The attribute includes the following data channel parameters: The attribute includes the following data channel parameters:
o "label=" labelstring o "label=" labelstring
o "subprotocol=" "MSRP" o "subprotocol=" "MSRP"
The labelstring is set by the MSRP application according to The labelstring is set by the MSRP application according to
[I-D.ejzak-mmusic-data-channel-sdpneg]. The max-retr, max-time and [I-D.ietf-mmusic-data-channel-sdpneg]. The max-retr, max-time and
ordered parameters shall not be used. ordered parameters shall not be used.
Rest of the SDP offer/answer procedures are per Rest of the SDP offer/answer procedures are per
[I-D.ejzak-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
The following is an example of the dcmap attribute for an MSRP The following is an example of the dcmap attribute for an MSRP
session to be negotiated (on default SCTP port 5000) with stream=2 session to be negotiated (on default SCTP port 5000) with stream=2
and label="chat": and label="chat":
a=dcmap:2 label="chat";subprotocol="MSRP" a=dcmap:2 label="chat";subprotocol="MSRP"
5.1.1.2. Use of dcsa attribute 5.1.1.2. Use of dcsa Attribute
The SDP offer shall also include a dcsa attribute line (defined in The SDP offer shall also include a dcsa attribute line (defined in
[I-D.ejzak-mmusic-data-channel-sdpneg]) within the media description [I-D.ietf-mmusic-data-channel-sdpneg]) within the media description
for the SCTP association for each MSRP-specific SDP attribute to be for the SCTP association for each MSRP-specific SDP attribute to be
negotiated for each MSRP data channel being negotiated. negotiated for each MSRP data channel being negotiated.
The MSRP-specific items that can be negotiated include at least all The MSRP-specific items that can be negotiated include at least all
of the following well-known attributes: of the following well-known attributes:
o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- o defined in [RFC4975]: "path", "accept-types", "accept-wrapped-
types", "max-size" types", "max-size"
o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and
skipping to change at page 6, line 25 skipping to change at page 6, line 31
The SDP answer shall include zero or more corresponding dcsa The SDP answer shall include zero or more corresponding dcsa
attribute lines for each negotiated MSRP session, according to the attribute lines for each negotiated MSRP session, according to the
MSRP-specific attribute negotiation rules in the corresponding MSRP-specific attribute negotiation rules in the corresponding
specifications. specifications.
A new SDP offer/answer may update the MSRP subprotocol attributes A new SDP offer/answer may update the MSRP subprotocol attributes
while keeping the same subprotocol a=dcmap description. The while keeping the same subprotocol a=dcmap description. The
semantics for newly negotiated MSRP subprotocol attributes are per semantics for newly negotiated MSRP subprotocol attributes are per
[RFC4975] [RFC4975]
5.1.1.3. Example SDP negotiation 5.1.1.3. Example SDP Negotiation
The following is an example of an m line for DataChannels in an SDP The following is an example of an "m" line for data channels in an
offer that includes the attributes needed to establish two MSRP SDP offer that includes the attributes needed to establish two MSRP
sessions: one for chat and one for file transfer. The example is sessions: one for chat and one for file transfer. The example is
derived from a combination of examples in [RFC4975] and [RFC5547]. derived from a combination of examples in [RFC4975] and [RFC5547].
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 79.97.215.79 c=IN IP4 79.97.215.79
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port 5000 a=sctp-port 5000
a=dcmap:1 label="chat";subprotocol="MSRP" a=dcmap:1 label="chat";subprotocol="MSRP"
a=dcsa:1 accept-types:message/cpim text/plain a=dcsa:1 accept-types:message/cpim text/plain
a=dcsa:1 path:msrps://bob.example.com:54111/si438dsaodes;dc a=dcsa:1 path:msrps://bob.example.com:54111/si438dsaodes;dc
skipping to change at page 7, line 5 skipping to change at page 7, line 26
a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc
a=dcsa:2 file-selector:name:"My cool picture.jpg" \ a=dcsa:2 file-selector:name:"My cool picture.jpg" \
type:image/jpeg size:32349 hash:sha-1: \ 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 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-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=dcsa:2 file-disposition:attachment a=dcsa:2 file-disposition:attachment
a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" 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-icon:cid:id2@bob.example.com
a=dcsa:2 file-range:1-32349 a=dcsa:2 file-range:1-32349
5.1.2. Session opening 5.1.2. Session Opening
The active MSRP endpoint does not use the path attribute to open a The active MSRP endpoint does not use the path attribute to open a
transport connection to its peer. Instead, it uses the data channel transport connection to its peer. Instead, it uses the data channel
established for this MSRP session by the generic data channel opening established for this MSRP session by the generic data channel opening
procedure defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg].
As soon as this data channel is opened, the MSRP session is actually 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 opened by the active MSRP endpoint which sends an MSRP SEND message
(empty or not) to the other MSRP endpoint. The msrp-cema attribute (empty or not) to the other MSRP endpoint. The msrp-cema attribute
is implicitly associated with every MSRP session using data channel is implicitly associated with every MSRP session using data channel
transport. transport.
5.1.3. Data framing 5.1.3. Data Framing
Each text-based MSRP message is sent on the corresponding SCTP stream Each text-based MSRP message is sent on the corresponding SCTP stream
using standard MSRP framing and chunking procedures, as defined in using standard MSRP framing and chunking procedures, as defined in
[RFC4975], with each MSRP chunk delivered in a single SCTP user [RFC4975], with each MSRP chunk delivered in a single SCTP user
message. message.
5.1.4. Data sending and reporting 5.1.4. Data Sending and Reporting
Data sending and reporting procedures shall conform to RFC 4975. Data sending and reporting procedures shall conform to RFC 4975.
5.1.5. Session closing 5.1.5. Session Closing
Closing of an MSRP session is done using the generic data channel Closing of an MSRP session is done using the generic data channel
closing procedure defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. closing procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg].
The port value for the m line should not be changed (e.g., to zero) 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 when closing an MSRP session (unless all data channels are being
closed and the SCTP association is no longer needed), since this closed and the SCTP association is no longer needed), since this
would close the SCTP association and impact all of the data channels. would close the SCTP association and impact all of the data channels.
In all cases in [RFC4975] where the procedure calls for setting the 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, 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 the SDP offerer of an MSRP session with data channel transport shall
remove the corresponding dcmap and dcsa attributes. remove the corresponding dcmap and dcsa attributes.
The SDP answerer must ensure that no dcmap or dcsa attributes are The SDP answerer must ensure that no dcmap or dcsa attributes are
present in the SDP answer if no corresponding attributes are present present in the SDP answer if no corresponding attributes are present
in the received SDP offer. in the received SDP offer.
5.2. Support for MSRP File Transfer function 5.2. Support for MSRP File Transfer Function
[RFC5547] defines an end-to-end file transfer method based on MSRP [RFC5547] defines an end-to-end file transfer method based on MSRP
and the SDP offer/answer mechanism. This file transfer method is and the SDP offer/answer mechanism. This file transfer method is
also usable by MSRP endpoints using data channel, with the following also usable by MSRP endpoints using data channels, with the following
considerations: considerations:
o As an MSRP session maps to one data channel, a file transfer o As an MSRP session maps to one data channel, a file transfer
session maps also to one data channel. session maps also to one data channel.
o SDP attributes specified in [RFC5547] for a file transfer m-line o SDP attributes specified in [RFC5547] for a file transfer "m" line
are embedded as subprotocol-specific attributes using the syntax are embedded as subprotocol-specific attributes using the syntax
defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. defined in [I-D.ietf-mmusic-data-channel-sdpneg].
o Once the file transfer is complete, the same data channel MAY be o Once the file transfer is complete, the same data channel MAY be
reused for another file transfer. reused for another file transfer.
6. Gateway configuration 6. Gateway Configuration
This section describes the network configuration where one endpoint This section describes the network configuration where one MSRP
runs MSRP over a WebRTC SCTP/DTLS connection, the other MSRP endpoint endpoint uses data channels as MSRP transport, the other MSRP
runs MSRP over one or more TLS/TCP connections, and the two endpoints endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP
interwork via an MSRP gateway. endpoints interwork via an MSRP gateway.
Specifically, a gateway can be configured to interwork an MSRP Specifically, a gateway can be configured to interwork an MSRP
session using a data channel with a peer that does not support data session over a data channel with a peer that does not support data
channel transport in one of two ways. In one model, the gateway channel transport in one of two ways. In one model, the gateway
performs as a MSRP B2BUA to interwork all the procedures as necessary performs as a MSRP B2BUA to interwork all the procedures as necessary
between the endpoints. No further specification is needed for this between the endpoints. No further specification is needed for this
model. model.
Alternately, the gateway can use CEMA procedures to provide transport Alternately, the gateway can use CEMA procedures to provide transport
level interworking between MSRP endpoints using different transport level interworking between MSRP endpoints using different transport
protocols as follows. protocols as follows.
When the gateway performs transport level interworking between MSRP When the gateway performs transport level interworking between MSRP
endpoints, all of the procedures in Section 5 apply to each peer, endpoints, all of the procedures in Section 5 apply to each peer,
with the following additions: with the following additions:
o The endpoint establishing an MSRP session using data channel o The endpoint establishing an MSRP session using data channel
transport shall not request inclusion of any relays, although it transport shall not request inclusion of any relays, although it
may interoperate with a peer that signals the use of relays. may interoperate with a peer that signals the use of relays.
o The gateway receiving an SDP offer that includes a request to o The gateway receiving an SDP offer that includes a request to
negotiate an MSRP session on a data channel can provide transport negotiate an MSRP session on a data channel can provide transport
level interworking in the same manner as a CEMA SBC by forwarding level interworking in the same manner as a CEMA SBC by forwarding
TCP or TLS transport parameters in a new m line with the TCP or TLS transport parameters in a new "m" line with the
appropriate attributes within the forwarded SDP offer. appropriate attributes within the forwarded SDP offer.
o Similarly, a gateway receiving an SDP offer to negotiate an MSRP o Similarly, a gateway receiving an SDP offer to negotiate an MSRP
session using TCP or TLS transport with an endpoint that only session using TCP or TLS transport with an endpoint that only
supports data channel transport for MSRP can provide transport supports data channel transport for MSRP can provide transport
level interworking in the same manner as a CEMA SBC by level interworking in the same manner as a CEMA SBC by
establishing a new data channel for the MSRP session with the establishing a new data channel for the MSRP session with the
target endpoint. target endpoint.
7. Security Considerations 7. Security Considerations
skipping to change at page 9, line 17 skipping to change at page 9, line 42
To be completed. To be completed.
8. IANA Considerations 8. IANA Considerations
To be completed. To be completed.
9. Acknowledgments 9. Acknowledgments
The authors wish to acknowledge the borrowing of ideas from another The authors wish to acknowledge the borrowing of ideas from another
internet draft by Peter Dunkley and Gavin Llewellyn, and to thank internet draft by Peter Dunkley and Gavin Llewellyn, and to thank
Paul Kyzivat, Jonathan Lennox, Christian Groves, Uwe Rauschenbach and Christian Groves, Christer Holmberg, Paul Kyzivat, Jonathan Lennox,
Keith Drage for their invaluable comments. Uwe Rauschenbach and Keith Drage for their invaluable comments.
10. CHANGE LOG 10. CHANGE LOG
10.1. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00'
o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in
list of normative references.
o Replacement of previous document title "MSRP over SCTP/DTLS data
channels" with "MSRP over Data Channels" in order to align with
the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg].
o In Section 3 "WebRTC data channel" was defined as "A bidirectional
channel consisting of paired SCTP outbound and inbound streams."
Replacement of this definition with "Data channel: A WebRTC data
channel as specified in [I-D.ietf-rtcweb-data-channel]", and
consistent usage of either "data channel" or "MSRP data channel"
in the remainder of the document."
o In the introduction replacement of references to
[I-D.ietf-rtcweb-data-protocol] with a reference to
[I-D.ietf-rtcweb-data-channel].
o Consistent usage of '"m" line' in whole document as per [RFC4566].
o In the gateway configuration section (Section 6) replacement of
the first sentence "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" with "This section describes the network configuration
where one MSRP endpoint uses data channels as MSRP transport, the
other MSRP endpoint uses TLS/TCP connections as MSRP transport,
and the two MSRP endpoints interwork via an MSRP gateway".
10.2. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01'
o Removed empty spaces after ";" in the examples' "a=dcmap" o Removed empty spaces after ";" in the examples' "a=dcmap"
attribute lines. attribute lines.
o In all examples, the m-line proto value "DTLS/SCTP" was replaced o In all examples, the "m" line proto value "DTLS/SCTP" was replaced
with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
replaced with "a=max-message-size" attribute lines, as per draft- replaced with "a=max-message-size" attribute lines, as per draft-
ietf-mmusic-sctp-sdp-12. ietf-mmusic-sctp-sdp-12.
10.2. Changes against '-00' 10.3. Changes against '-00'
o Transport parameter change for MSRP to allow MSRP RFC transports. o Transport parameter change for MSRP to allow MSRP RFC transports.
o Clarification on SDP offer/answer and removing duplicated o Clarification on SDP offer/answer and removing duplicated
procedures and refer them to procedures and refer them to
[I-D.ejzak-mmusic-data-channel-sdpneg]. [I-D.ejzak-mmusic-data-channel-sdpneg].
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 10, line 25 skipping to change at page 11, line 37
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[I-D.ejzak-mmusic-data-channel-sdpneg] [I-D.ejzak-mmusic-data-channel-sdpneg]
Drage, K., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon, Drage, K., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon,
"SDP-based "SCTP over DTLS" data channel negotiation", "SDP-based "SCTP over DTLS" data channel negotiation",
draft-ejzak-mmusic-data-channel-sdpneg-02 (work in draft-ejzak-mmusic-data-channel-sdpneg-02 (work in
progress), October 2014. progress), October 2014.
[I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Stoetzer-Bradler, J., Ejzak, R., Marcon, J.,
and R. Makaraju, "SDP-based "SCTP over DTLS" data channel
negotiation", draft-ietf-mmusic-data-channel-sdpneg-00
(work in progress), January 2015.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976, for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007. September 2007.
skipping to change at page 11, line 22 skipping to change at page 12, line 37
Authors' Addresses Authors' Addresses
Keith Drage (editor) Keith Drage (editor)
Alcatel-Lucent Alcatel-Lucent
Quadrant, Stonehill Green, Westlea Quadrant, Stonehill Green, Westlea
Swindon Swindon
UK UK
Email: keith.drage@alcatel-lucent.com Email: keith.drage@alcatel-lucent.com
Raju Makaraju Maridi R. Makaraju (Raju)
Alcatel-Lucent Alcatel-Lucent
2000 Lucent Lane 2000 Lucent Lane
Naperville, Illinois Naperville, Illinois
US US
Email: Raju.Makaraju@alcatel-lucent.com Email: Raju.Makaraju@alcatel-lucent.com
Juergen Stoetzer-Bradler Juergen Stoetzer-Bradler
Alcatel-Lucent Alcatel-Lucent
Lorenzstrasse 10 Lorenzstrasse 10
D-70435 Stuttgart D-70435 Stuttgart
Germany Germany
Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com
Richard Ejzak Richard Ejzak
Unaffiliated Unaffiliated
 End of changes. 55 change blocks. 
86 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/