[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ejzak-mmusic-msrp-usage-data-channel) 00 01 02 03 04 05 06

MMUSIC                                                     K. Drage, Ed.
Internet-Draft                                               M. Makaraju
Intended status: Standards Track                                   Nokia
Expires: April 22, 2017                              J. Stoetzer-Bradler

                                                                R. Ejzak
                                                               J. Marcon
                                                            Unaffiliated
                                                        October 19, 2016


                        MSRP over Data Channels
              draft-ietf-mmusic-msrp-usage-data-channel-06

Abstract

   This document specifies how the Message Session Relay Protocol (MSRP)
   can be instantiated as a data channel sub-protocol, using the SDP
   offer/answer exchange-based generic data channel negotiation
   framework.  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 22, 2017.

Copyright Notice

   Copyright (c) 2016 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 22, 2017                 [Page 1]


Internet-Draft           MSRP over Data Channels            October 2016


   (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Principles  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  MSRP Data Channel . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Session Mapping . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  MSRP URI  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  msrp-scheme . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  End-to-End Configuration  . . . . . . . . . . . . . . . . . .   5
     5.1.  Basic MSRP Support  . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Session Negotiation . . . . . . . . . . . . . . . . .   5
         5.1.1.1.  Use of the dcmap Attribute  . . . . . . . . . . .   5
         5.1.1.2.  Use of the dcsa Attribute . . . . . . . . . . . .   6
         5.1.1.3.  Use of the setup Attribute  . . . . . . . . . . .   6
         5.1.1.4.  Example SDP Negotiation . . . . . . . . . . . . .   7
       5.1.2.  Session Opening . . . . . . . . . . . . . . . . . . .   8
       5.1.3.  Data Framing  . . . . . . . . . . . . . . . . . . . .   8
       5.1.4.  Data Sending and Reporting  . . . . . . . . . . . . .   9
       5.1.5.  Session Closing . . . . . . . . . . . . . . . . . . .   9
     5.2.  Support for MSRP File Transfer Function . . . . . . . . .   9
   6.  Gateway Configuration . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Subprotocol Identifier MSRP . . . . . . . . . . . . . . .  11
     8.2.  setup Attribute . . . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   10. CHANGE LOG  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Changes against 'draft-ietf-mmusic-msrp-usage-data-
            channel-05'  . . . . . . . . . . . . . . . . . . . . . .  12
     10.2.  Changes against 'draft-ietf-mmusic-msrp-usage-data-
            channel-04'  . . . . . . . . . . . . . . . . . . . . . .  12
     10.3.  Changes against 'draft-ietf-mmusic-msrp-usage-data-
            channel-03'  . . . . . . . . . . . . . . . . . . . . . .  12
     10.4.  Changes against 'draft-ietf-mmusic-msrp-usage-data-
            channel-02'  . . . . . . . . . . . . . . . . . . . . . .  12
     10.5.  Changes against 'draft-ietf-mmusic-msrp-usage-data-
            channel-01'  . . . . . . . . . . . . . . . . . . . . . .  13
     10.6.  Changes against 'draft-ietf-mmusic-msrp-usage-data-



Drage, et al.            Expires April 22, 2017                 [Page 2]


Internet-Draft           MSRP over Data Channels            October 2016


            channel-00'  . . . . . . . . . . . . . . . . . . . . . .  14
     10.7.  Changes against 'draft-ejzak-mmusic-msrp-usage-data-
            channel-01'  . . . . . . . . . . . . . . . . . . . . . .  15
     10.8.  Changes against '-00'  . . . . . . . . . . . . . . . . .  15
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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.

   This document defines the negotiation and transport of this MSRP
   protocol over 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-channel]) and where MSRP is instantiated as a
   sub-protocol of this data channel.  The MSRP protocol negotiation
   defined in this document is based on the generic SDP offer/answer
   exchange based data channel negotiation as specified in
   [I-D.ietf-mmusic-data-channel-sdpneg].

   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-channel],
   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.








Drage, et al.            Expires April 22, 2017                 [Page 3]


Internet-Draft           MSRP over Data Channels            October 2016


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 WebRTC data channel as specified in
      [I-D.ietf-rtcweb-data-channel].

      MSRP data channel: A data channel specifically used to transport
      the messages of one MSRP session.

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

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

      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.ietf-mmusic-data-channel-sdpneg].

4.2.  Session Mapping

   In this design, the MSRP session maps to the SCTP association and the
   "SCTP stream pair" assigned to the data channel, and each MSRP
   session maps to one data channel exactly.





Drage, et al.            Expires April 22, 2017                 [Page 4]


Internet-Draft           MSRP over Data Channels            October 2016


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 a data channel.

5.1.  Basic MSRP Support

5.1.1.  Session Negotiation

5.1.1.1.  Use of the dcmap Attribute

   The SDP offer SHALL include a dcmap attribute line (defined in
   [I-D.ietf-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.ietf-mmusic-data-channel-sdpneg].  Ordered and reliable data
   channels MUST always be used, such that the "max-retr" and "max-time"
   parameters SHALL NOT be used.  If the "ordered" parameter is used,
   then its value MUST be equal to "true".

   Rest of the SDP offer/answer procedures are per
   [I-D.ietf-mmusic-data-channel-sdpneg].

   The following is an example of the dcmap attribute for an MSRP
   session to be negotiated with stream=2 and label="chat":



Drage, et al.            Expires April 22, 2017                 [Page 5]


Internet-Draft           MSRP over Data Channels            October 2016


   a=dcmap:2 label="chat";subprotocol="MSRP"

5.1.1.2.  Use of the dcsa Attribute

   The SDP offer SHALL also include within the media description for the
   SCTP association a dcsa attribute line (defined in
   [I-D.ietf-mmusic-data-channel-sdpneg]) 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"

   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.  Use of the setup Attribute

   The SDP setup attribute, as introduced in [RFC4145], can be used in
   WebRTC data channel related SDP media descriptions as a media level
   attribute, which is associated with the corresponding UDP/DTLS/SCTP
   or TCP/DTLS/SCTP "m" line.  In this case the setup attribute is of



Drage, et al.            Expires April 22, 2017                 [Page 6]


Internet-Draft           MSRP over Data Channels            October 2016


   the form "a=setup:<role>", where <role> assumes values as defined in
   [RFC4145].  Such a setup attribute is used as specified in
   [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment
   roles of the DTLS connection.  If an MSRP session is negotiated over
   a data channel, then such an "a=setup" attribute has no relationship
   with the MSRP session.

   Additionally, the setup attribute can be embedded in a dcsa attribute
   and hence can explicitly be associated with an MSRP session over a
   specific data channel.  In such a case it is of the form "a=dcsa:x
   setup:<role>", with x being the data channel's SCTP stream
   identifier.  Such a dcsa embedded setup attribute has no relationship
   with the DTLS connection establishment roles.

   A dcsa embedded setup attribute MUST be used for MSRP sessions over
   data channels.

   The dcsa embedded setup attribute in an MSRP over data channel
   description is used to negotiate, which MSRP session endpoint assumes
   the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of
   [RFC4975].

   It is considered an error if an MSRP over data channel description
   does not contain a dcsa embedded setup attribute.

5.1.1.4.  Example SDP Negotiation

   The following is an example of an "m" line for data channels 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].




















Drage, et al.            Expires April 22, 2017                 [Page 7]


Internet-Draft           MSRP over Data Channels            October 2016


      m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
      c=IN IP4 79.97.215.79
      a=max-message-size:100000
      a=sctp-port:5000
      a=setup:actpass
      a=connection:new
      a=fingerprint:SHA-256 \
           4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
      a=dcmap:0 label="chat";subprotocol="MSRP"
      a=dcsa:0 setup:active
      a=dcsa:0 accept-types:message/cpim text/plain
      a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc
      a=dcmap:2 label="file transfer";subprotocol="MSRP"
      a=dcsa:2 sendonly
      a=dcsa:2 setup:active
      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

5.1.2.  Session Opening

   Section 5.1.1.3 describes how the active MSRP session endpoint role
   is negotiated.  The active MSRP session 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.ietf-mmusic-data-channel-sdpneg].

   As soon as this data channel is opened, the MSRP session is actually
   opened by the active MSRP session endpoint.  In order to do this the
   active MSRP endpoint 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.  Therefore all sent MSRP chunks including the MSRP chunk



Drage, et al.            Expires April 22, 2017                 [Page 8]


Internet-Draft           MSRP over Data Channels            October 2016


   header MUST have lengths of less than or equal to the value of the
   peer's "a=max-message-size" attribute, which is associated with the
   data channel's SCTP association.

5.1.4.  Data Sending and Reporting

   Data sending and reporting procedures SHALL conform to RFC 4975.

5.1.5.  Session Closing

   The closure of an MSRP session MUST be signaled via an SDP offer/
   answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute
   lines associated with the MSRP session from the associated DTLS/SCTP
   based media description.  This results in the associated data channel
   being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg],
   where the actual data channel closure procedure is typically
   initiated by the SDP answerer right after having accepted the SDP
   offer.

   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 channels, with the following
   considerations:

   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.ietf-mmusic-data-channel-sdpneg].

   o  Once the file transfer is complete, the same data channel MAY be
      reused for another file transfer.



Drage, et al.            Expires April 22, 2017                 [Page 9]


Internet-Draft           MSRP over Data Channels            October 2016


6.  Gateway Configuration

   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.

   Specifically, a gateway can be configured to interwork an MSRP
   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
   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.

      *  Especially, the gateway interworks the received MSRP over data
         channel associated dcsa embedded setup attribute with the media
         description level "a=setup" attribute of the MSRP over TCP or
         TLS "m" line within its 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.

      *  In this case the gateway interworks the received MSRP over TCP
         or TLS associated "a=setup" attribute with the dcsa embedded
         setup attribute of the generated MSRP over data channel
         description.



Drage, et al.            Expires April 22, 2017                [Page 10]


Internet-Draft           MSRP over Data Channels            October 2016


7.  Security Considerations

   To be completed.

8.  IANA Considerations

8.1.  Subprotocol Identifier MSRP

   NOTE to RFC Editor: Please replace "XXXX" with the number of this
   RFC.

   This document adds the subprotocol identifier "MSRP" to the
   "WebSocket Subprotocol Name Registry" as follows:

                  +--------------------------+---------+
                  | Subprotocol Identifier:  | MSRP    |
                  | Subprotocol Common Name: | MSRP    |
                  | Subprotocol Definition:  | RFCXXXX |
                  | Reference:               | RFCXXXX |
                  +--------------------------+---------+

8.2.  setup Attribute

   NOTE to RFC Editor: Please replace "XXXX" with the number of this
   RFC.

   This document modifies the usage of the SDP setup attribute, if this
   attribute is embedded in a dcsa attribute and associated with an MSRP
   session over a data channel.  The modified usage is described in
   Section 5.1.1.3.

   Usage level "dcsa(MSRP)" should be added to the IANA registration of
   the SDP setup attribute as follows:

   +-----------------------+-------------------------------------------+
   | Contact name:         | MMUSIC Chairs                             |
   | Contact email:        | mmusic-chairs@ietf.org                    |
   | Attribute name:       | setup                                     |
   | Usage level:          | dcsa(MSRP)                                |
   | Purpose:              | Negotiate the active role of an MSRP      |
   |                       | session over a data channel as per        |
   |                       | Section 5.1.1.3                           |
   | Reference:            | RFCXXXX                                   |
   +-----------------------+-------------------------------------------+







Drage, et al.            Expires April 22, 2017                [Page 11]


Internet-Draft           MSRP over Data Channels            October 2016


9.  Acknowledgments

   The authors wish to acknowledge the borrowing of ideas from another
   internet draft by Peter Dunkley and Gavin Llewellyn, and to thank
   Flemming Andreasen, Christian Groves, Christer Holmberg, Paul
   Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and
   Keith Drage for their invaluable comments.

10.  CHANGE LOG

10.1.  Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05'

   o  Modification of Juergen's address information.

10.2.  Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04'

   o  Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative
      references.

   o  Addition of Section 8.2 as per section 8.2.4 of
      [I-D.ietf-mmusic-rfc4566bis].

10.3.  Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03'

   o  Addition of IANA registration related Section 8.1.

10.4.  Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02'

   o  Addition of "a=setup:actpass", "a=connection:new",
      "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to
      the SDP example in Section 5.1.1.4.

   o  Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of
      normative references.

   o  Addition of new Section 5.1.1.3 describing how the active MSRP
      session endpoint role is negotiated.

   o  Extension of first paragraph of Section 5.1.2 with new first
      sentence "Section 5.1.1.3 describes how the active MSRP session
      endpoint role is negotiated.".

   o  First sentence of second paragraph in Section 5.1.2 was "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."  Replacement
      of this sentence with "As soon as this data channel is opened, the
      MSRP session is actually opened by the active MSRP endpoint.  In



Drage, et al.            Expires April 22, 2017                [Page 12]


Internet-Draft           MSRP over Data Channels            October 2016


      order to do this the active MSRP endpoint sends an MSRP SEND
      message (empty or not) to the other MSRP endpoint."

   o  Addition of setup attribute specific behavior descriptions of data
      channel to TCP or TLS interworking gateways in Section 6.

10.5.  Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01'

   o  In the abstract replacement of the first sentence "This document
      specifies how the Message Session Relay Protocol (MSRP) can be
      instantiated as a data channel sub-protocol, using the SDP offer/
      answer exchange-based external negotiation defined in
      [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document
      specifies how the Message Session Relay Protocol (MSRP) can be
      instantiated as a data channel sub-protocol, using the SDP offer/
      answer exchange-based generic data channel negotiation framework"
      in order to remove the reference from the abstract text.

   o  Addition of following sentence to the second paragraph in
      Section 1: "The MSRP protocol negotiation defined in this document
      is based on the generic SDP offer/answer exchange based data
      channel negotiation as specified in
      [I-D.ietf-mmusic-data-channel-sdpneg]".

   o  In Section 4.1 replacement of sub-protocol identifier "msrp" with
      "MSRP" in order to make this consistent with the formal
      specification in Section 5.1.1.1.

   o  Throughout the text replacement of "shall" with "SHALL" etc where
      appropriate as per [RFC2119].

   o  In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time
      and ordered parameters shall not be used.' with 'Ordered and
      reliable data channels MUST always be used, such that the "max-
      retr" and "max-time" parameters SHALL NOT be used.  If the
      "ordered" parameter is used, then its value MUST be equal to
      "true".'.

   o  In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from
      the sentence preceding the example "a=dcmap" attribute line.

   o  In Section 5.1.1.2 first paragraph was "The SDP offer shall also
      include a dcsa attribute line (defined in
      [I-D.ietf-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.".  Replacement of this paragraph with "The SDP offer
      SHALL also include within the media description for the SCTP



Drage, et al.            Expires April 22, 2017                [Page 13]


Internet-Draft           MSRP over Data Channels            October 2016


      association a dcsa attribute line (defined in
      [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP
      attribute to be negotiated for each MSRP data channel being
      negotiated.".

   o  Appended following sentence at the end of the first paragraph of
      Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths
      of less than or equal to the value of the peer's "a=max-message-
      size" attribute, which is associated with the data channel's SCTP
      association.".

   o  Addition of the previously missing colon to the "a=sctp-port"
      attribute line in Section 5.1.1.4.

   o  In Section 5.1.5 replacement of the first paragraph "Closing of an
      MSRP session is done using the generic data channel closing
      procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with
      'The closure of an MSRP session MUST be signaled via an SDP offer/
      answer exchange which removes the "a=dcmap:" and "a=dcsa:"
      attribute lines associated with the MSRP session from the
      associated DTLS/SCTP based media description.  This results in the
      associated data channel being closed as well as per
      [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data
      channel closure procedure is typically initiated by the SDP
      answerer right after having accepted the SDP offer.'.

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




Drage, et al.            Expires April 22, 2017                [Page 14]


Internet-Draft           MSRP over Data Channels            October 2016


   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.7.  Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01'

   o  Removed empty spaces after ";" in the examples' "a=dcmap"
      attribute lines.

   o  In all examples, the "m" line proto value "DTLS/SCTP" was replaced
      with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
      replaced with "a=max-message-size" attribute lines, as per draft-
      ietf-mmusic-sctp-sdp-12.

10.8.  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 draft-ejzak-mmusic-data-channel-
      sdpneg-02.

11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [I-D.ietf-rtcweb-jsep]
              Uberti, J., Jennings, C., and E. Rescorla, "Javascript
              Session Establishment Protocol", draft-ietf-rtcweb-jsep-16
              (work in progress), September 2016.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.







Drage, et al.            Expires April 22, 2017                [Page 15]


Internet-Draft           MSRP over Data Channels            October 2016


   [I-D.ietf-rtcweb-data-protocol]
              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
              Establishment Protocol", draft-ietf-rtcweb-data-
              protocol-09 (work in progress), January 2015.

   [I-D.ietf-rtcweb-data-channel]
              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
              Channels", draft-ietf-rtcweb-data-channel-13 (work in
              progress), January 2015.

   [I-D.ietf-mmusic-data-channel-sdpneg]
              Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
              and (. (Unknown), "SDP-based Data Channel Negotiation",
              draft-ietf-mmusic-data-channel-sdpneg-10 (work in
              progress), September 2016.

   [I-D.ietf-mmusic-sctp-sdp]
              Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
              "Session Description Protocol (SDP) Offer/Answer
              Procedures For Stream Control Transmission Protocol (SCTP)
              over Datagram Transport Layer Security (DTLS) Transport.",
              draft-ietf-mmusic-sctp-sdp-18 (work in progress), October
              2016.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              DOI 10.17487/RFC4145, September 2005,
              <http://www.rfc-editor.org/info/rfc4145>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [I-D.ietf-mmusic-rfc4566bis]
              Handley, M., Jacobson, V., Perkins, C., and A. Begen,
              "SDP: Session Description Protocol", draft-ietf-mmusic-
              rfc4566bis-17 (work in progress), June 2016.

   [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
              "The Message Session Relay Protocol (MSRP)", RFC 4975,
              DOI 10.17487/RFC4975, September 2007,
              <http://www.rfc-editor.org/info/rfc4975>.

   [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,
              DOI 10.17487/RFC5547, May 2009,
              <http://www.rfc-editor.org/info/rfc5547>.



Drage, et al.            Expires April 22, 2017                [Page 16]


Internet-Draft           MSRP over Data Channels            October 2016


   [RFC6135]  Holmberg, C. and S. Blau, "An Alternative Connection Model
              for the Message Session Relay Protocol (MSRP)", RFC 6135,
              DOI 10.17487/RFC6135, February 2011,
              <http://www.rfc-editor.org/info/rfc6135>.

   [RFC6714]  Holmberg, C., Blau, S., and E. Burger, "Connection
              Establishment for Media Anchoring (CEMA) for the Message
              Session Relay Protocol (MSRP)", RFC 6714,
              DOI 10.17487/RFC6714, August 2012,
              <http://www.rfc-editor.org/info/rfc6714>.

Authors' Addresses

   Keith Drage (editor)
   Nokia
   Quadrant, Stonehill Green, Westlea
   Swindon
   UK

   Email: Keith.Drage@nokia.com


   Maridi R. Makaraju (Raju)
   Nokia
   2000 Lucent Lane
   Naperville, Illinois
   US

   Email: Raju.Makaraju@nokia.com


   Juergen Stoetzer-Bradler

   Email: Juergen.S-B.ietf@email.de


   Richard Ejzak
   Unaffiliated

   Email: richard.ejzak@gmail.com


   Jerome Marcon
   Unaffiliated







Drage, et al.            Expires April 22, 2017                [Page 17]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/