idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-07.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 (September 10, 2017) is 2420 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-23 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-12 ** 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 (~~), 5 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 Unaffiliated 4 Intended status: Standards Track M. Makaraju 5 Expires: March 14, 2018 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 September 10, 2017 12 MSRP over Data Channels 13 draft-ietf-mmusic-msrp-usage-data-channel-07 15 Abstract 17 This document specifies how the Message Session Relay Protocol (MSRP) 18 can be instantiated as a data channel sub-protocol, using the SDP 19 offer/answer exchange-based generic data channel negotiation 20 framework. Two network configurations are documented: a WebRTC end- 21 to-end configuration (connecting two MSRP over data channel 22 endpoints), and a gateway configuration (connecting an MSRP over data 23 channel endpoint with an MSRP over TCP endpoint). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 14, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5 68 5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 5 69 5.1.1. Session Negotiation . . . . . . . . . . . . . . . . . 5 70 5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 5 71 5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 6 72 5.1.1.3. Use of the setup Attribute . . . . . . . . . . . 6 73 5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 7 74 5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8 75 5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 8 76 5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9 77 5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9 78 5.2. Support for MSRP File Transfer Function . . . . . . . . . 9 79 6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 83 8.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-06' . . . . . . . . . . . . . . . . . . . . . . 12 88 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-05' . . . . . . . . . . . . . . . . . . . . . . 12 90 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-04' . . . . . . . . . . . . . . . . . . . . . . 12 92 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-03' . . . . . . . . . . . . . . . . . . . . . . 12 94 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-02' . . . . . . . . . . . . . . . . . . . . . . 12 96 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-01' . . . . . . . . . . . . . . . . . . . . . . 13 98 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-00' . . . . . . . . . . . . . . . . . . . . . . 14 100 10.8. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 101 channel-01' . . . . . . . . . . . . . . . . . . . . . . 15 102 10.9. Changes against '-00' . . . . . . . . . . . . . . . . . 15 103 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 106 1. Introduction 108 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 109 transmitting a series of related instant messages in the context of a 110 session. In addition to instant messaging, MSRP can also be used for 111 image sharing or file transfer. MSRP is currently defined to work 112 over TCP and TLS connections. 114 This document defines the negotiation and transport of this MSRP 115 protocol over data channels, where a data channel is a bi-directional 116 communication channel running on top of SCTP/DTLS (as per 117 [I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a 118 sub-protocol of this data channel. The MSRP protocol negotiation 119 defined in this document is based on the generic SDP offer/answer 120 exchange based data channel negotiation as specified in 121 [I-D.ietf-mmusic-data-channel-sdpneg]. 123 Defining MSRP as a data channel sub-protocol has many benefits: 125 o provides to applications a proven protocol enabling instant 126 messaging, file transfer, image sharing 128 o integrates those features with other RTCWeb voice, video and data 129 features 131 o leverages the SDP-based negotiation already defined for MSRP 133 o allows the interworking with MSRP endpoints running on a TCP or 134 TLS connection 136 Considering an MSRP endpoint being an MSRP application that uses data 137 channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel], 138 this document describes two configurations where the other endpoint 139 is respectively either another MSRP over data channel endpoint (e.g., 140 a WebRTC application) or an MSRP endpoint using either TCP or TLS 141 transport. 143 2. Conventions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Terminology 151 This document uses the following terms: 153 Data channel: A WebRTC data channel as specified in 154 [I-D.ietf-rtcweb-data-channel]. 156 MSRP data channel: A data channel specifically used to transport 157 the messages of one MSRP session. 159 External negotiation: Data channel negotiation based on out-of- 160 band or in-band mechanisms other than the Data Channel 161 Establishment Protocol specified in 162 [I-D.ietf-rtcweb-data-protocol]. 164 In-band: Transmission through the peer-to-peer SCTP association. 166 Out-of-band: Transmission through the call control signaling path, 167 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 168 model [RFC3264]. 170 Peer: From the perspective of one of the agents in a session, its 171 peer is the other agent. Specifically, from the perspective of 172 the SDP offerer, the peer is the SDP answerer. From the 173 perspective of the SDP answerer, the peer is the SDP offerer. 175 4. Principles 177 4.1. MSRP Data Channel 179 In this document, an MSRP data channel is a data channel for which 180 the instantiated sub-protocol is "MSRP", and where the MSRP-related 181 negotiation is done as part of the SDP-based external negotiation 182 method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 184 4.2. Session Mapping 186 In this design, the MSRP session maps to the SCTP association and the 187 "SCTP stream pair" assigned to the data channel, and each MSRP 188 session maps to one data channel exactly. 190 4.3. MSRP URI 192 This document extends the MSRP URI syntax [RFC4975] by defining the 193 new transport parameter value "dc": 195 transport /= "dc" / 1*ALPHANUM 196 ; Add "dc" to existing transports per [RFC4975] 198 4.4. msrp-scheme 200 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 201 channel endpoint (used in the SDP path attribute and in the MSRP 202 message headers) is always "msrps", which indicates that the MSRP 203 data channel is always secured using DTLS. 205 5. End-to-End Configuration 207 This section describes the network configuration where each MSRP 208 endpoint is running MSRP over a data channel. 210 5.1. Basic MSRP Support 212 5.1.1. Session Negotiation 214 5.1.1.1. Use of the dcmap Attribute 216 The SDP offer SHALL include a dcmap attribute line (defined in 217 [I-D.ietf-mmusic-data-channel-sdpneg]), within the media description 218 for the SCTP association for each MSRP data channel session to be 219 negotiated. 221 The attribute includes the following data channel parameters: 223 o "label=" labelstring 225 o "subprotocol=" "MSRP" 227 The labelstring is set by the MSRP application according to 228 [I-D.ietf-mmusic-data-channel-sdpneg]. Ordered and reliable data 229 channels MUST always be used, such that the "max-retr" and "max-time" 230 parameters SHALL NOT be used. If the "ordered" parameter is used, 231 then its value MUST be equal to "true". 233 Rest of the SDP offer/answer procedures are per 234 [I-D.ietf-mmusic-data-channel-sdpneg]. 236 The following is an example of the dcmap attribute for an MSRP 237 session to be negotiated with stream=2 and label="chat": 239 a=dcmap:2 label="chat";subprotocol="MSRP" 241 5.1.1.2. Use of the dcsa Attribute 243 The SDP offer SHALL also include within the media description for the 244 SCTP association a dcsa attribute line (defined in 245 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 246 attribute to be negotiated for each MSRP data channel being 247 negotiated. 249 The MSRP-specific items that can be negotiated include at least all 250 of the following well-known attributes: 252 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 253 types", "max-size" 255 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 256 "sendrecv" 258 o defined in [RFC6135]: "setup" 260 o defined in [RFC6714]: "msrp-cema" 262 o defined in [RFC5547]: all the parameters related to MSRP file 263 transfer. See Section 5.2. 265 The msrp-cema attribute SHALL be assumed to be present for every MSRP 266 session using data channel transport, so the inclusion of the msrp- 267 cema attribute is OPTIONAL. This ensures that the data channel 268 transport for the MSRP session is established without using the path 269 attribute. 271 The SDP answer SHALL include zero or more corresponding dcsa 272 attribute lines for each negotiated MSRP session, according to the 273 MSRP-specific attribute negotiation rules in the corresponding 274 specifications. 276 A new SDP offer/answer MAY update the MSRP subprotocol attributes 277 while keeping the same subprotocol a=dcmap description. The 278 semantics for newly negotiated MSRP subprotocol attributes are per 279 [RFC4975]. 281 5.1.1.3. Use of the setup Attribute 283 The SDP setup attribute, as introduced in [RFC4145], can be used in 284 WebRTC data channel related SDP media descriptions as a media level 285 attribute, which is associated with the corresponding UDP/DTLS/SCTP 286 or TCP/DTLS/SCTP "m" line. In this case the setup attribute is of 287 the form "a=setup:", where assumes values as defined in 288 [RFC4145]. Such a setup attribute is used as specified in 289 [I-D.ietf-mmusic-sctp-sdp] in order to negotiate the establishment 290 roles of the DTLS connection. If an MSRP session is negotiated over 291 a data channel, then such an "a=setup" attribute has no relationship 292 with the MSRP session. 294 Additionally, the setup attribute can be embedded in a dcsa attribute 295 and hence can explicitly be associated with an MSRP session over a 296 specific data channel. In such a case it is of the form "a=dcsa:x 297 setup:", with x being the data channel's SCTP stream 298 identifier. Such a dcsa embedded setup attribute has no relationship 299 with the DTLS connection establishment roles. 301 A dcsa embedded setup attribute MUST be used for MSRP sessions over 302 data channels. 304 The dcsa embedded setup attribute in an MSRP over data channel 305 description is used to negotiate, which MSRP session endpoint assumes 306 the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of 307 [RFC4975]. 309 It is considered an error if an MSRP over data channel description 310 does not contain a dcsa embedded setup attribute. 312 5.1.1.4. Example SDP Negotiation 314 The following is an example of an "m" line for data channels in an 315 SDP offer that includes the attributes needed to establish two MSRP 316 sessions: one for chat and one for file transfer. The example is 317 derived from a combination of examples in [RFC4975] and [RFC5547]. 319 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 320 c=IN IP4 79.97.215.79 321 a=max-message-size:100000 322 a=sctp-port:5000 323 a=setup:actpass 324 a=connection:new 325 a=fingerprint:SHA-256 \ 326 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 327 a=dcmap:0 label="chat";subprotocol="MSRP" 328 a=dcsa:0 setup:active 329 a=dcsa:0 accept-types:message/cpim text/plain 330 a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc 331 a=dcmap:2 label="file transfer";subprotocol="MSRP" 332 a=dcsa:2 sendonly 333 a=dcsa:2 setup:active 334 a=dcsa:2 accept-types:message/cpim 335 a=dcsa:2 accept-wrapped-types:* 336 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 337 a=dcsa:2 file-selector:name:"My cool picture.jpg" \ 338 type:image/jpeg size:32349 hash:sha-1: \ 339 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 340 a=dcsa:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd 341 a=dcsa:2 file-disposition:attachment 342 a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" 343 a=dcsa:2 file-icon:cid:id2@bob.example.com 344 a=dcsa:2 file-range:1-32349 346 5.1.2. Session Opening 348 Section 5.1.1.3 describes how the active MSRP session endpoint role 349 is negotiated. The active MSRP session endpoint does not use the 350 path attribute to open a transport connection to its peer. Instead, 351 it uses the data channel established for this MSRP session by the 352 generic data channel opening procedure defined in 353 [I-D.ietf-mmusic-data-channel-sdpneg]. 355 As soon as this data channel is opened, the MSRP session is actually 356 opened by the active MSRP session endpoint. In order to do this the 357 active MSRP endpoint sends an MSRP SEND message (empty or not) to the 358 other MSRP endpoint. The msrp-cema attribute is implicitly 359 associated with every MSRP session using data channel transport. 361 5.1.3. Data Framing 363 Each text-based MSRP message is sent on the corresponding SCTP stream 364 using standard MSRP framing and chunking procedures, as defined in 365 [RFC4975], with each MSRP chunk delivered in a single SCTP user 366 message. Therefore all sent MSRP chunks including the MSRP chunk 367 header MUST have lengths of less than or equal to the value of the 368 peer's "a=max-message-size" attribute, which is associated with the 369 data channel's SCTP association. 371 5.1.4. Data Sending and Reporting 373 Data sending and reporting procedures SHALL conform to RFC 4975. 375 5.1.5. Session Closing 377 The closure of an MSRP session MUST be signaled via an SDP offer/ 378 answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute 379 lines associated with the MSRP session from the associated DTLS/SCTP 380 based media description. This results in the associated data channel 381 being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg], 382 where the actual data channel closure procedure is typically 383 initiated by the SDP answerer right after having accepted the SDP 384 offer. 386 The port value for the "m" line SHOULD NOT be changed (e.g. to zero) 387 when closing an MSRP session (unless all data channels are being 388 closed and the SCTP association is no longer needed), since this 389 would close the SCTP association and impact all of the data channels. 390 In all cases in [RFC4975] where the procedure calls for setting the 391 port to zero for the MSRP "m" line in an SDP offer for TCP transport, 392 the SDP offerer of an MSRP session with data channel transport SHALL 393 remove the corresponding dcmap and dcsa attributes. 395 The SDP answerer must ensure that no dcmap or dcsa attributes are 396 present in the SDP answer if no corresponding attributes are present 397 in the received SDP offer. 399 5.2. Support for MSRP File Transfer Function 401 [RFC5547] defines an end-to-end file transfer method based on MSRP 402 and the SDP offer/answer mechanism. This file transfer method is 403 also usable by MSRP endpoints using data channels, with the following 404 considerations: 406 o As an MSRP session maps to one data channel, a file transfer 407 session maps also to one data channel. 409 o SDP attributes specified in [RFC5547] for a file transfer "m" line 410 are embedded as subprotocol-specific attributes using the syntax 411 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 413 o Once the file transfer is complete, the same data channel MAY be 414 reused for another file transfer. 416 6. Gateway Configuration 418 This section describes the network configuration where one MSRP 419 endpoint uses data channels as MSRP transport, the other MSRP 420 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 421 endpoints interwork via an MSRP gateway. 423 Specifically, a gateway can be configured to interwork an MSRP 424 session over a data channel with a peer that does not support data 425 channel transport in one of two ways. In one model, the gateway 426 performs as a MSRP B2BUA to interwork all the procedures as necessary 427 between the endpoints. No further specification is needed for this 428 model. 430 Alternately, the gateway can use CEMA procedures to provide transport 431 level interworking between MSRP endpoints using different transport 432 protocols as follows. 434 When the gateway performs transport level interworking between MSRP 435 endpoints, all of the procedures in Section 5 apply to each peer, 436 with the following additions: 438 o The endpoint establishing an MSRP session using data channel 439 transport SHALL NOT request inclusion of any relays, although it 440 MAY interoperate with a peer that signals the use of relays. 442 o The gateway receiving an SDP offer that includes a request to 443 negotiate an MSRP session on a data channel can provide transport 444 level interworking in the same manner as a CEMA SBC by forwarding 445 TCP or TLS transport parameters in a new "m" line with the 446 appropriate attributes within the forwarded SDP offer. 448 * Especially, the gateway interworks the received MSRP over data 449 channel associated dcsa embedded setup attribute with the media 450 description level "a=setup" attribute of the MSRP over TCP or 451 TLS "m" line within its forwarded SDP offer. 453 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 454 session using TCP or TLS transport with an endpoint that only 455 supports data channel transport for MSRP can provide transport 456 level interworking in the same manner as a CEMA SBC by 457 establishing a new data channel for the MSRP session with the 458 target endpoint. 460 * In this case the gateway interworks the received MSRP over TCP 461 or TLS associated "a=setup" attribute with the dcsa embedded 462 setup attribute of the generated MSRP over data channel 463 description. 465 7. Security Considerations 467 To be completed. 469 8. IANA Considerations 471 8.1. Subprotocol Identifier MSRP 473 NOTE to RFC Editor: Please replace "XXXX" with the number of this 474 RFC. 476 This document adds the subprotocol identifier "MSRP" to the 477 "WebSocket Subprotocol Name Registry" as follows: 479 +--------------------------+---------+ 480 | Subprotocol Identifier: | MSRP | 481 | Subprotocol Common Name: | MSRP | 482 | Subprotocol Definition: | RFCXXXX | 483 | Reference: | RFCXXXX | 484 +--------------------------+---------+ 486 8.2. setup Attribute 488 NOTE to RFC Editor: Please replace "XXXX" with the number of this 489 RFC. 491 This document modifies the usage of the SDP setup attribute, if this 492 attribute is embedded in a dcsa attribute and associated with an MSRP 493 session over a data channel. The modified usage is described in 494 Section 5.1.1.3. 496 Usage level "dcsa(MSRP)" should be added to the IANA registration of 497 the SDP setup attribute as follows: 499 +-----------------------+-------------------------------------------+ 500 | Contact name: | MMUSIC Chairs | 501 | Contact email: | mmusic-chairs@ietf.org | 502 | Attribute name: | setup | 503 | Usage level: | dcsa(MSRP) | 504 | Purpose: | Negotiate the active role of an MSRP | 505 | | session over a data channel as per | 506 | | Section 5.1.1.3 | 507 | Reference: | RFCXXXX | 508 +-----------------------+-------------------------------------------+ 510 9. Acknowledgments 512 The authors wish to acknowledge the borrowing of ideas from another 513 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 514 Flemming Andreasen, Christian Groves, Christer Holmberg, Paul 515 Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and 516 Keith Drage for their invaluable comments. 518 10. CHANGE LOG 520 10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 522 o Modification of Keith's address information. 524 10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 526 o Modification of Juergen's address information. 528 10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 530 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 531 references. 533 o Addition of Section 8.2 as per section 8.2.4 of 534 [I-D.ietf-mmusic-rfc4566bis]. 536 10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 538 o Addition of IANA registration related Section 8.1. 540 10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 542 o Addition of "a=setup:actpass", "a=connection:new", 543 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 544 the SDP example in Section 5.1.1.4. 546 o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of 547 normative references. 549 o Addition of new Section 5.1.1.3 describing how the active MSRP 550 session endpoint role is negotiated. 552 o Extension of first paragraph of Section 5.1.2 with new first 553 sentence "Section 5.1.1.3 describes how the active MSRP session 554 endpoint role is negotiated.". 556 o First sentence of second paragraph in Section 5.1.2 was "As soon 557 as this data channel is opened, the MSRP session is actually 558 opened by the active MSRP endpoint which sends an MSRP SEND 559 message (empty or not) to the other MSRP endpoint." Replacement 560 of this sentence with "As soon as this data channel is opened, the 561 MSRP session is actually opened by the active MSRP endpoint. In 562 order to do this the active MSRP endpoint sends an MSRP SEND 563 message (empty or not) to the other MSRP endpoint." 565 o Addition of setup attribute specific behavior descriptions of data 566 channel to TCP or TLS interworking gateways in Section 6. 568 10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 570 o In the abstract replacement of the first sentence "This document 571 specifies how the Message Session Relay Protocol (MSRP) can be 572 instantiated as a data channel sub-protocol, using the SDP offer/ 573 answer exchange-based external negotiation defined in 574 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 575 specifies how the Message Session Relay Protocol (MSRP) can be 576 instantiated as a data channel sub-protocol, using the SDP offer/ 577 answer exchange-based generic data channel negotiation framework" 578 in order to remove the reference from the abstract text. 580 o Addition of following sentence to the second paragraph in 581 Section 1: "The MSRP protocol negotiation defined in this document 582 is based on the generic SDP offer/answer exchange based data 583 channel negotiation as specified in 584 [I-D.ietf-mmusic-data-channel-sdpneg]". 586 o In Section 4.1 replacement of sub-protocol identifier "msrp" with 587 "MSRP" in order to make this consistent with the formal 588 specification in Section 5.1.1.1. 590 o Throughout the text replacement of "shall" with "SHALL" etc where 591 appropriate as per [RFC2119]. 593 o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time 594 and ordered parameters shall not be used.' with 'Ordered and 595 reliable data channels MUST always be used, such that the "max- 596 retr" and "max-time" parameters SHALL NOT be used. If the 597 "ordered" parameter is used, then its value MUST be equal to 598 "true".'. 600 o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from 601 the sentence preceding the example "a=dcmap" attribute line. 603 o In Section 5.1.1.2 first paragraph was "The SDP offer shall also 604 include a dcsa attribute line (defined in 605 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 606 description for the SCTP association for each MSRP-specific SDP 607 attribute to be negotiated for each MSRP data channel being 608 negotiated.". Replacement of this paragraph with "The SDP offer 609 SHALL also include within the media description for the SCTP 610 association a dcsa attribute line (defined in 611 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 612 attribute to be negotiated for each MSRP data channel being 613 negotiated.". 615 o Appended following sentence at the end of the first paragraph of 616 Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths 617 of less than or equal to the value of the peer's "a=max-message- 618 size" attribute, which is associated with the data channel's SCTP 619 association.". 621 o Addition of the previously missing colon to the "a=sctp-port" 622 attribute line in Section 5.1.1.4. 624 o In Section 5.1.5 replacement of the first paragraph "Closing of an 625 MSRP session is done using the generic data channel closing 626 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 627 'The closure of an MSRP session MUST be signaled via an SDP offer/ 628 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 629 attribute lines associated with the MSRP session from the 630 associated DTLS/SCTP based media description. This results in the 631 associated data channel being closed as well as per 632 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 633 channel closure procedure is typically initiated by the SDP 634 answerer right after having accepted the SDP offer.'. 636 10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 638 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 639 list of normative references. 641 o Replacement of previous document title "MSRP over SCTP/DTLS data 642 channels" with "MSRP over Data Channels" in order to align with 643 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 645 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 646 channel consisting of paired SCTP outbound and inbound streams." 647 Replacement of this definition with "Data channel: A WebRTC data 648 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 649 consistent usage of either "data channel" or "MSRP data channel" 650 in the remainder of the document." 652 o In the introduction replacement of references to 653 [I-D.ietf-rtcweb-data-protocol] with a reference to 654 [I-D.ietf-rtcweb-data-channel]. 656 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 658 o In the gateway configuration section (Section 6) replacement of 659 the first sentence "This section describes the network 660 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 661 connection, the other MSRP endpoint runs MSRP over one or more 662 TLS/TCP connections, and the two endpoints interwork via an MSRP 663 gateway" with "This section describes the network configuration 664 where one MSRP endpoint uses data channels as MSRP transport, the 665 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 666 and the two MSRP endpoints interwork via an MSRP gateway". 668 10.8. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 670 o Removed empty spaces after ";" in the examples' "a=dcmap" 671 attribute lines. 673 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 674 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 675 replaced with "a=max-message-size" attribute lines, as per draft- 676 ietf-mmusic-sctp-sdp-12. 678 10.9. Changes against '-00' 680 o Transport parameter change for MSRP to allow MSRP RFC transports. 682 o Clarification on SDP offer/answer and removing duplicated 683 procedures and refer them to draft-ejzak-mmusic-data-channel- 684 sdpneg-02. 686 11. Normative References 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, 690 DOI 10.17487/RFC2119, March 1997, 691 . 693 [I-D.ietf-rtcweb-jsep] 694 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 695 Session Establishment Protocol", draft-ietf-rtcweb-jsep-23 696 (work in progress), September 2017. 698 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 699 with Session Description Protocol (SDP)", RFC 3264, 700 DOI 10.17487/RFC3264, June 2002, 701 . 703 [I-D.ietf-rtcweb-data-protocol] 704 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 705 Establishment Protocol", draft-ietf-rtcweb-data- 706 protocol-09 (work in progress), January 2015. 708 [I-D.ietf-rtcweb-data-channel] 709 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 710 Channels", draft-ietf-rtcweb-data-channel-13 (work in 711 progress), January 2015. 713 [I-D.ietf-mmusic-data-channel-sdpneg] 714 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 715 and J. Marcon, "SDP-based Data Channel Negotiation", 716 draft-ietf-mmusic-data-channel-sdpneg-12 (work in 717 progress), March 2017. 719 [I-D.ietf-mmusic-sctp-sdp] 720 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 721 "Session Description Protocol (SDP) Offer/Answer 722 Procedures For Stream Control Transmission Protocol (SCTP) 723 over Datagram Transport Layer Security (DTLS) Transport.", 724 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 725 2017. 727 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 728 the Session Description Protocol (SDP)", RFC 4145, 729 DOI 10.17487/RFC4145, September 2005, 730 . 732 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 733 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 734 July 2006, . 736 [I-D.ietf-mmusic-rfc4566bis] 737 Handley, M., Jacobson, V., Perkins, C., and A. Begen, 738 "SDP: Session Description Protocol", draft-ietf-mmusic- 739 rfc4566bis-17 (work in progress), June 2016. 741 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 742 "The Message Session Relay Protocol (MSRP)", RFC 4975, 743 DOI 10.17487/RFC4975, September 2007, 744 . 746 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 747 and P. Kyzivat, "A Session Description Protocol (SDP) 748 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 749 DOI 10.17487/RFC5547, May 2009, 750 . 752 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 753 for the Message Session Relay Protocol (MSRP)", RFC 6135, 754 DOI 10.17487/RFC6135, February 2011, 755 . 757 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 758 Establishment for Media Anchoring (CEMA) for the Message 759 Session Relay Protocol (MSRP)", RFC 6714, 760 DOI 10.17487/RFC6714, August 2012, 761 . 763 Authors' Addresses 765 Keith Drage (editor) 766 Unaffiliated 768 Email: drageke@ntlworld.com 770 Maridi R. Makaraju (Raju) 771 Nokia 772 2000 Lucent Lane 773 Naperville, Illinois 774 US 776 Email: Raju.Makaraju@nokia.com 778 Juergen Stoetzer-Bradler 779 Unaffiliated 781 Email: Juergen.S-B.ietf@email.de 783 Richard Ejzak 784 Unaffiliated 786 Email: richard.ejzak@gmail.com 788 Jerome Marcon 789 Unaffiliated