idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2016) is 2831 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-15 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-08 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-37) exists of draft-ietf-mmusic-rfc4566bis-17 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage, Ed. 3 Internet-Draft M. Makaraju 4 Intended status: Standards Track J. Stoetzer-Bradler 5 Expires: January 26, 2017 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 July 25, 2016 11 MSRP over Data Channels 12 draft-ietf-mmusic-msrp-usage-data-channel-05 14 Abstract 16 This document specifies how the Message Session Relay Protocol (MSRP) 17 can be instantiated as a data channel sub-protocol, using the SDP 18 offer/answer exchange-based generic data channel negotiation 19 framework. Two network configurations are documented: a WebRTC end- 20 to-end configuration (connecting two MSRP over data channel 21 endpoints), and a gateway configuration (connecting an MSRP over data 22 channel endpoint with an MSRP over TCP endpoint). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 26, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 4 64 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5 67 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 5 68 5.1.1. Session Negotiation . . . . . . . . . . . . . . . . . 5 69 5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 5 70 5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 5 71 5.1.1.3. Use of the setup Attribute . . . . . . . . . . . 6 72 5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 7 73 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8 74 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 8 75 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9 76 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9 77 5.2. Support for MSRP File Transfer Function . . . . . . . . . 9 78 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 82 8.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 84 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 86 channel-04' . . . . . . . . . . . . . . . . . . . . . . 12 87 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 88 channel-03' . . . . . . . . . . . . . . . . . . . . . . 12 89 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 90 channel-02' . . . . . . . . . . . . . . . . . . . . . . 12 91 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 92 channel-01' . . . . . . . . . . . . . . . . . . . . . . 13 93 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 94 channel-00' . . . . . . . . . . . . . . . . . . . . . . 14 95 10.6. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 96 channel-01' . . . . . . . . . . . . . . . . . . . . . . 15 98 10.7. Changes against '-00' . . . . . . . . . . . . . . . . . 15 99 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 105 transmitting a series of related instant messages in the context of a 106 session. In addition to instant messaging, MSRP can also be used for 107 image sharing or file transfer. MSRP is currently defined to work 108 over TCP and TLS connections. 110 This document defines the negotiation and transport of this MSRP 111 protocol over data channels, where a data channel is a bi-directional 112 communication channel running on top of SCTP/DTLS (as per 113 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 114 sub-protocol of this data channel. The MSRP protocol negotiation 115 defined in this document is based on the generic SDP offer/answer 116 exchange based data channel negotiation as specified in 117 [I-D.ietf-mmusic-data-channel-sdpneg]. 119 Defining MSRP as a data channel sub-protocol has many benefits: 121 o provides to applications a proven protocol enabling instant 122 messaging, file transfer, image sharing 124 o integrates those features with other RTCWeb voice, video and data 125 features 127 o leverages the SDP-based negotiation already defined for MSRP 129 o allows the interworking with MSRP endpoints running on a TCP or 130 TLS connection 132 Considering an MSRP endpoint being an MSRP application that uses data 133 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 134 this document describes two configurations where the other endpoint 135 is respectively either another MSRP over data channel endpoint (e.g., 136 a WebRTC application) or an MSRP endpoint using either TCP or TLS 137 transport. 139 2. Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Terminology 147 This document uses the following terms: 149 Data channel: A WebRTC data channel as specified in 150 [I-D.ietf-rtcweb-data-channel]. 152 MSRP data channel: A data channel specifically used to transport 153 the messages of one MSRP session. 155 External negotiation: Data channel negotiation based on out-of- 156 band or in-band mechanisms other than the Data Channel 157 Establishment Protocol specified in 158 [I-D.ietf-rtcweb-data-protocol]. 160 In-band: Transmission through the peer-to-peer SCTP association. 162 Out-of-band: Transmission through the call control signaling path, 163 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 164 model [RFC3264]. 166 Peer: From the perspective of one of the agents in a session, its 167 peer is the other agent. Specifically, from the perspective of 168 the SDP offerer, the peer is the SDP answerer. From the 169 perspective of the SDP answerer, the peer is the SDP offerer. 171 4. Principles 173 4.1. MSRP Data Channel 175 In this document, an MSRP data channel is a data channel for which 176 the instantiated sub-protocol is "MSRP", and where the MSRP-related 177 negotiation is done as part of the SDP-based external negotiation 178 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 180 4.2. Session Mapping 182 In this design, the MSRP session maps to the SCTP association and the 183 "SCTP stream pair" assigned to the data channel, and each MSRP 184 session maps to one data channel exactly. 186 4.3. MSRP URI 188 This document extends the MSRP URI syntax [RFC4975] by defining the 189 new transport parameter value "dc": 191 transport /= "dc" / 1*ALPHANUM 192 ; Add "dc" to existing transports per [RFC4975] 194 4.4. msrp-scheme 196 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 197 channel endpoint (used in the SDP path attribute and in the MSRP 198 message headers) is always "msrps", which indicates that the MSRP 199 data channel is always secured using DTLS. 201 5. End-to-End Configuration 203 This section describes the network configuration where each MSRP 204 endpoint is running MSRP over a data channel. 206 5.1. Basic MSRP Support 208 5.1.1. Session Negotiation 210 5.1.1.1. Use of the dcmap Attribute 212 The SDP offer SHALL include a dcmap attribute line (defined in 213 [I-D.ietf-mmusic-data-channel-sdpneg]), within the media description 214 for the SCTP association for each MSRP data channel session to be 215 negotiated. 217 The attribute includes the following data channel parameters: 219 o "label=" labelstring 221 o "subprotocol=" "MSRP" 223 The labelstring is set by the MSRP application according to 224 [I-D.ietf-mmusic-data-channel-sdpneg]. Ordered and reliable data 225 channels MUST always be used, such that the "max-retr" and "max-time" 226 parameters SHALL NOT be used. If the "ordered" parameter is used, 227 then its value MUST be equal to "true". 229 Rest of the SDP offer/answer procedures are per 230 [I-D.ietf-mmusic-data-channel-sdpneg]. 232 The following is an example of the dcmap attribute for an MSRP 233 session to be negotiated with stream=2 and label="chat": 235 a=dcmap:2 label="chat";subprotocol="MSRP" 237 5.1.1.2. Use of the dcsa Attribute 239 The SDP offer SHALL also include within the media description for the 240 SCTP association a dcsa attribute line (defined in 241 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 242 attribute to be negotiated for each MSRP data channel being 243 negotiated. 245 The MSRP-specific items that can be negotiated include at least all 246 of the following well-known attributes: 248 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 249 types", "max-size" 251 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 252 "sendrecv" 254 o defined in [RFC6135]: "setup" 256 o defined in [RFC6714]: "msrp-cema" 258 o defined in [RFC5547]: all the parameters related to MSRP file 259 transfer. See Section 5.2. 261 The msrp-cema attribute SHALL be assumed to be present for every MSRP 262 session using data channel transport, so the inclusion of the msrp- 263 cema attribute is OPTIONAL. This ensures that the data channel 264 transport for the MSRP session is established without using the path 265 attribute. 267 The SDP answer SHALL include zero or more corresponding dcsa 268 attribute lines for each negotiated MSRP session, according to the 269 MSRP-specific attribute negotiation rules in the corresponding 270 specifications. 272 A new SDP offer/answer MAY update the MSRP subprotocol attributes 273 while keeping the same subprotocol a=dcmap description. The 274 semantics for newly negotiated MSRP subprotocol attributes are per 275 [RFC4975]. 277 5.1.1.3. Use of the setup Attribute 279 The SDP setup attribute, as introduced in [RFC4145], can be used in 280 WebRTC data channel related SDP media descriptions as a media level 281 attribute, which is associated with the corresponding UDP/DTLS/SCTP 282 or TCP/DTLS/SCTP "m" line. In this case the setup attribute is of 283 the form "a=setup:", where assumes values as defined in 284 [RFC4145]. Such a setup attribute is used as specified in 285 [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment 286 roles of the DTLS connection. If an MSRP session is negotiated over 287 a data channel, then such an "a=setup" attribute has no relationship 288 with the MSRP session. 290 Additionally, the setup attribute can be embedded in a dcsa attribute 291 and hence can explicitly be associated with an MSRP session over a 292 specific data channel. In such a case it is of the form "a=dcsa:x 293 setup:", with x being the data channel's SCTP stream 294 identifier. Such a dcsa embedded setup attribute has no relationship 295 with the DTLS connection establishment roles. 297 A dcsa embedded setup attribute MUST be used for MSRP sessions over 298 data channels. 300 The dcsa embedded setup attribute in an MSRP over data channel 301 description is used to negotiate, which MSRP session endpoint assumes 302 the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of 303 [RFC4975]. 305 It is considered an error if an MSRP over data channel description 306 does not contain a dcsa embedded setup attribute. 308 5.1.1.4. Example SDP Negotiation 310 The following is an example of an "m" line for data channels in an 311 SDP offer that includes the attributes needed to establish two MSRP 312 sessions: one for chat and one for file transfer. The example is 313 derived from a combination of examples in [RFC4975] and [RFC5547]. 315 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 316 c=IN IP4 79.97.215.79 317 a=max-message-size:100000 318 a=sctp-port:5000 319 a=setup:actpass 320 a=connection:new 321 a=fingerprint:SHA-256 \ 322 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 323 a=dcmap:0 label="chat";subprotocol="MSRP" 324 a=dcsa:0 setup:active 325 a=dcsa:0 accept-types:message/cpim text/plain 326 a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc 327 a=dcmap:2 label="file transfer";subprotocol="MSRP" 328 a=dcsa:2 sendonly 329 a=dcsa:2 setup:active 330 a=dcsa:2 accept-types:message/cpim 331 a=dcsa:2 accept-wrapped-types:* 332 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 333 a=dcsa:2 file-selector:name:"My cool picture.jpg" \ 334 type:image/jpeg size:32349 hash:sha-1: \ 335 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 336 a=dcsa:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd 337 a=dcsa:2 file-disposition:attachment 338 a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" 339 a=dcsa:2 file-icon:cid:id2@bob.example.com 340 a=dcsa:2 file-range:1-32349 342 5.1.2. Session Opening 344 Section 5.1.1.3 describes how the active MSRP session endpoint role 345 is negotiated. The active MSRP session endpoint does not use the 346 path attribute to open a transport connection to its peer. Instead, 347 it uses the data channel established for this MSRP session by the 348 generic data channel opening procedure defined in 349 [I-D.ietf-mmusic-data-channel-sdpneg]. 351 As soon as this data channel is opened, the MSRP session is actually 352 opened by the active MSRP session endpoint. In order to do this the 353 active MSRP endpoint sends an MSRP SEND message (empty or not) to the 354 other MSRP endpoint. The msrp-cema attribute is implicitly 355 associated with every MSRP session using data channel transport. 357 5.1.3. Data Framing 359 Each text-based MSRP message is sent on the corresponding SCTP stream 360 using standard MSRP framing and chunking procedures, as defined in 361 [RFC4975], with each MSRP chunk delivered in a single SCTP user 362 message. Therefore all sent MSRP chunks including the MSRP chunk 363 header MUST have lengths of less than or equal to the value of the 364 peer's "a=max-message-size" attribute, which is associated with the 365 data channel's SCTP association. 367 5.1.4. Data Sending and Reporting 369 Data sending and reporting procedures SHALL conform to RFC 4975. 371 5.1.5. Session Closing 373 The closure of an MSRP session MUST be signaled via an SDP offer/ 374 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 375 lines associated with the MSRP session from the associated DTLS/SCTP 376 based media description. This results in the associated data channel 377 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 378 where the actual data channel closure procedure is typically 379 initiated by the SDP answerer right after having accepted the SDP 380 offer. 382 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 383 when closing an MSRP session (unless all data channels are being 384 closed and the SCTP association is no longer needed), since this 385 would close the SCTP association and impact all of the data channels. 386 In all cases in [RFC4975] where the procedure calls for setting the 387 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 388 the SDP offerer of an MSRP session with data channel transport SHALL 389 remove the corresponding dcmap and dcsa attributes. 391 The SDP answerer must ensure that no dcmap or dcsa attributes are 392 present in the SDP answer if no corresponding attributes are present 393 in the received SDP offer. 395 5.2. Support for MSRP File Transfer Function 397 [RFC5547] defines an end-to-end file transfer method based on MSRP 398 and the SDP offer/answer mechanism. This file transfer method is 399 also usable by MSRP endpoints using data channels, with the following 400 considerations: 402 o As an MSRP session maps to one data channel, a file transfer 403 session maps also to one data channel. 405 o SDP attributes specified in [RFC5547] for a file transfer "m" line 406 are embedded as subprotocol-specific attributes using the syntax 407 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 409 o Once the file transfer is complete, the same data channel MAY be 410 reused for another file transfer. 412 6. Gateway Configuration 414 This section describes the network configuration where one MSRP 415 endpoint uses data channels as MSRP transport, the other MSRP 416 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 417 endpoints interwork via an MSRP gateway. 419 Specifically, a gateway can be configured to interwork an MSRP 420 session over a data channel with a peer that does not support data 421 channel transport in one of two ways. In one model, the gateway 422 performs as a MSRP B2BUA to interwork all the procedures as necessary 423 between the endpoints. No further specification is needed for this 424 model. 426 Alternately, the gateway can use CEMA procedures to provide transport 427 level interworking between MSRP endpoints using different transport 428 protocols as follows. 430 When the gateway performs transport level interworking between MSRP 431 endpoints, all of the procedures in Section 5 apply to each peer, 432 with the following additions: 434 o The endpoint establishing an MSRP session using data channel 435 transport SHALL NOT request inclusion of any relays, although it 436 MAY interoperate with a peer that signals the use of relays. 438 o The gateway receiving an SDP offer that includes a request to 439 negotiate an MSRP session on a data channel can provide transport 440 level interworking in the same manner as a CEMA SBC by forwarding 441 TCP or TLS transport parameters in a new "m" line with the 442 appropriate attributes within the forwarded SDP offer. 444 * Especially, the gateway interworks the received MSRP over data 445 channel associated dcsa embedded setup attribute with the media 446 description level "a=setup" attribute of the MSRP over TCP or 447 TLS "m" line within its forwarded SDP offer. 449 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 450 session using TCP or TLS transport with an endpoint that only 451 supports data channel transport for MSRP can provide transport 452 level interworking in the same manner as a CEMA SBC by 453 establishing a new data channel for the MSRP session with the 454 target endpoint. 456 * In this case the gateway interworks the received MSRP over TCP 457 or TLS associated "a=setup" attribute with the dcsa embedded 458 setup attribute of the generated MSRP over data channel 459 description. 461 7. Security Considerations 463 To be completed. 465 8. IANA Considerations 467 8.1. Subprotocol Identifier MSRP 469 NOTE to RFC Editor: Please replace "XXXX" with the number of this 470 RFC. 472 This document adds the subprotocol identifier "MSRP" to the 473 "WebSocket Subprotocol Name Registry" as follows: 475 +--------------------------+---------+ 476 | Subprotocol Identifier: | MSRP | 477 | Subprotocol Common Name: | MSRP | 478 | Subprotocol Definition: | RFCXXXX | 479 | Reference: | RFCXXXX | 480 +--------------------------+---------+ 482 8.2. setup Attribute 484 NOTE to RFC Editor: Please replace "XXXX" with the number of this 485 RFC. 487 This document modifies the usage of the SDP setup attribute, if this 488 attribute is embedded in a dcsa attribute and associated with an MSRP 489 session over a data channel. The modified usage is described in 490 Section 5.1.1.3. 492 Usage level "dcsa(MSRP)" should be added to the IANA registration of 493 the SDP setup attribute as follows: 495 +-----------------------+-------------------------------------------+ 496 | Contact name: | MMUSIC Chairs | 497 | Contact email: | mmusic-chairs@ietf.org | 498 | Attribute name: | setup | 499 | Usage level: | dcsa(MSRP) | 500 | Purpose: | Negotiate the active role of an MSRP | 501 | | session over a data channel as per | 502 | | Section 5.1.1.3 | 503 | Reference: | RFCXXXX | 504 +-----------------------+-------------------------------------------+ 506 9. Acknowledgments 508 The authors wish to acknowledge the borrowing of ideas from another 509 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 510 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 511 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 512 Keith Drage for their invaluable comments. 514 10. CHANGE LOG 516 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 518 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 519 references. 521 o Addition of Section 8.2 as per section 8.2.4 of 522 [I-D.ietf-mmusic-rfc4566bis]. 524 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 526 o Addition of IANA registration related Section 8.1. 528 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 530 o Addition of "a=setup:actpass", "a=connection:new", 531 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 532 the SDP example in Section 5.1.1.4. 534 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 535 normative references. 537 o Addition of new Section 5.1.1.3 describing how the active MSRP 538 session endpoint role is negotiated. 540 o Extension of first paragraph of Section 5.1.2 with new first 541 sentence "Section 5.1.1.3 describes how the active MSRP session 542 endpoint role is negotiated.". 544 o First sentence of second paragraph in Section 5.1.2 was "As soon 545 as this data channel is opened, the MSRP session is actually 546 opened by the active MSRP endpoint which sends an MSRP SEND 547 message (empty or not) to the other MSRP endpoint." Replacement 548 of this sentence with "As soon as this data channel is opened, the 549 MSRP session is actually opened by the active MSRP endpoint. In 550 order to do this the active MSRP endpoint sends an MSRP SEND 551 message (empty or not) to the other MSRP endpoint." 553 o Addition of setup attribute specific behavior descriptions of data 554 channel to TCP or TLS interworking gateways in Section 6. 556 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 558 o In the abstract replacement of the first sentence "This document 559 specifies how the Message Session Relay Protocol (MSRP) can be 560 instantiated as a data channel sub-protocol, using the SDP offer/ 561 answer exchange-based external negotiation defined in 562 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 563 specifies how the Message Session Relay Protocol (MSRP) can be 564 instantiated as a data channel sub-protocol, using the SDP offer/ 565 answer exchange-based generic data channel negotiation framework" 566 in order to remove the reference from the abstract text. 568 o Addition of following sentence to the second paragraph in 569 Section 1: "The MSRP protocol negotiation defined in this document 570 is based on the generic SDP offer/answer exchange based data 571 channel negotiation as specified in 572 [I-D.ietf-mmusic-data-channel-sdpneg]". 574 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 575 "MSRP" in order to make this consistent with the formal 576 specification in Section 5.1.1.1. 578 o Throughout the text replacement of "shall" with "SHALL" etc where 579 appropriate as per [RFC2119]. 581 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 582 and ordered parameters shall not be used.' with 'Ordered and 583 reliable data channels MUST always be used, such that the "max- 584 retr" and "max-time" parameters SHALL NOT be used. If the 585 "ordered" parameter is used, then its value MUST be equal to 586 "true".'. 588 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 589 the sentence preceding the example "a=dcmap" attribute line. 591 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 592 include a dcsa attribute line (defined in 593 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 594 description for the SCTP association for each MSRP-specific SDP 595 attribute to be negotiated for each MSRP data channel being 596 negotiated.". Replacement of this paragraph with "The SDP offer 597 SHALL also include within the media description for the SCTP 598 association a dcsa attribute line (defined in 599 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 600 attribute to be negotiated for each MSRP data channel being 601 negotiated.". 603 o Appended following sentence at the end of the first paragraph of 604 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 605 of less than or equal to the value of the peer's "a=max-message- 606 size" attribute, which is associated with the data channel's SCTP 607 association.". 609 o Addition of the previously missing colon to the "a=sctp-port" 610 attribute line in Section 5.1.1.4. 612 o In Section 5.1.5 replacement of the first paragraph "Closing of an 613 MSRP session is done using the generic data channel closing 614 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 615 'The closure of an MSRP session MUST be signaled via an SDP offer/ 616 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 617 attribute lines associated with the MSRP session from the 618 associated DTLS/SCTP based media description. This results in the 619 associated data channel being closed as well as per 620 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 621 channel closure procedure is typically initiated by the SDP 622 answerer right after having accepted the SDP offer.'. 624 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 626 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 627 list of normative references. 629 o Replacement of previous document title "MSRP over SCTP/DTLS data 630 channels" with "MSRP over Data Channels" in order to align with 631 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 633 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 634 channel consisting of paired SCTP outbound and inbound streams." 635 Replacement of this definition with "Data channel: A WebRTC data 636 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 637 consistent usage of either "data channel" or "MSRP data channel" 638 in the remainder of the document." 640 o In the introduction replacement of references to 641 [I-D.ietf-rtcweb-data-protocol] with a reference to 642 [I-D.ietf-rtcweb-data-channel]. 644 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 646 o In the gateway configuration section (Section 6) replacement of 647 the first sentence "This section describes the network 648 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 649 connection, the other MSRP endpoint runs MSRP over one or more 650 TLS/TCP connections, and the two endpoints interwork via an MSRP 651 gateway" with "This section describes the network configuration 652 where one MSRP endpoint uses data channels as MSRP transport, the 653 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 654 and the two MSRP endpoints interwork via an MSRP gateway". 656 10.6. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 658 o Removed empty spaces after ";" in the examples' "a=dcmap" 659 attribute lines. 661 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 662 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 663 replaced with "a=max-message-size" attribute lines, as per draft- 664 ietf-mmusic-sctp-sdp-12. 666 10.7. Changes against '-00' 668 o Transport parameter change for MSRP to allow MSRP RFC transports. 670 o Clarification on SDP offer/answer and removing duplicated 671 procedures and refer them to draft-ejzak-mmusic-data-channel- 672 sdpneg-02. 674 11. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [I-D.ietf-rtcweb-jsep] 682 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 683 Session Establishment Protocol", draft-ietf-rtcweb-jsep-15 684 (work in progress), July 2016. 686 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 687 with Session Description Protocol (SDP)", RFC 3264, 688 DOI 10.17487/RFC3264, June 2002, 689 . 691 [I-D.ietf-rtcweb-data-protocol] 692 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 693 Establishment Protocol", draft-ietf-rtcweb-data- 694 protocol-09 (work in progress), January 2015. 696 [I-D.ietf-rtcweb-data-channel] 697 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 698 Channels", draft-ietf-rtcweb-data-channel-13 (work in 699 progress), January 2015. 701 [I-D.ietf-mmusic-data-channel-sdpneg] 702 Drage, K., (Raju), M., Stoetzer-Bradler, J., Ejzak, R., 703 and J. Marcon, "SDP-based Data Channel Negotiation", 704 draft-ietf-mmusic-data-channel-sdpneg-08 (work in 705 progress), February 2016. 707 [I-D.ietf-mmusic-sctp-sdp] 708 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 709 Control Transmission Protocol (SCTP)-Based Media Transport 710 in the Session Description Protocol (SDP)", draft-ietf- 711 mmusic-sctp-sdp-16 (work in progress), February 2016. 713 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 714 the Session Description Protocol (SDP)", RFC 4145, 715 DOI 10.17487/RFC4145, September 2005, 716 . 718 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 719 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 720 July 2006, . 722 [I-D.ietf-mmusic-rfc4566bis] 723 Handley, M., Jacobson, V., Perkins, D., and A. Begen, 724 "SDP: Session Description Protocol", draft-ietf-mmusic- 725 rfc4566bis-17 (work in progress), June 2016. 727 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 728 "The Message Session Relay Protocol (MSRP)", RFC 4975, 729 DOI 10.17487/RFC4975, September 2007, 730 . 732 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 733 and P. Kyzivat, "A Session Description Protocol (SDP) 734 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 735 DOI 10.17487/RFC5547, May 2009, 736 . 738 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 739 for the Message Session Relay Protocol (MSRP)", RFC 6135, 740 DOI 10.17487/RFC6135, February 2011, 741 . 743 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 744 Establishment for Media Anchoring (CEMA) for the Message 745 Session Relay Protocol (MSRP)", RFC 6714, 746 DOI 10.17487/RFC6714, August 2012, 747 . 749 Authors' Addresses 751 Keith Drage (editor) 752 Nokia 753 Quadrant, Stonehill Green, Westlea 754 Swindon 755 UK 757 Email: Keith.Drage@nokia.com 759 Maridi R. Makaraju (Raju) 760 Nokia 761 2000 Lucent Lane 762 Naperville, Illinois 763 US 765 Email: Raju.Makaraju@nokia.com 767 Juergen Stoetzer-Bradler 768 Nokia 769 Lorenzstrasse 10 770 D-70435 Stuttgart 771 Germany 773 Email: Juergen.Stoetzer-Bradler@nokia.com 775 Richard Ejzak 776 Unaffiliated 778 Email: richard.ejzak@gmail.com 780 Jerome Marcon 781 Unaffiliated