idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-28.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 11, 2019) is 1804 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 (-37) exists of draft-ietf-mmusic-rfc4566bis-32 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-24) exists of draft-ietf-mmusic-msrp-usage-data-channel-10 -- Obsolete informational reference (is this intentional?): RFC 4582 (Obsoleted by RFC 8855) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track M. Makaraju 5 Expires: November 12, 2019 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 R. Even, Ed. 10 Huawei 11 May 11, 2019 13 SDP-based Data Channel Negotiation 14 draft-ietf-mmusic-data-channel-sdpneg-28 16 Abstract 18 Data channel setup can be done using either the in-band Data Channel 19 Establishment Protocol (DCEP) or using some out-of-band non-DCEP 20 protocol. This document specifies how the SDP (Session Description 21 Protocol) offer/answer exchange can be used to achieve an out-of-band 22 non-DCEP negotiation for establishing a data channel. 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 https://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 November 12, 2019. 41 Copyright Notice 43 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 62 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 63 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 64 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6 65 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 66 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 67 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 68 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 69 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 70 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 71 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 10 72 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 73 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 74 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 75 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 76 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 13 77 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13 78 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 79 6.3. Generating the Initial Offer for A Data Channel . . . . . 14 80 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 81 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 82 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 83 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16 84 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 85 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 20 89 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 20 90 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 20 91 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 21 92 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 93 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 94 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 12.1. Changes against 'draft-ietf-mmusic-data-channel- 96 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 22 98 12.2. Changes against 'draft-ietf-mmusic-data-channel- 99 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 22 100 12.3. Changes against 'draft-ietf-mmusic-data-channel- 101 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 22 102 12.4. Changes against 'draft-ietf-mmusic-data-channel- 103 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 22 104 12.5. Changes against 'draft-ietf-mmusic-data-channel- 105 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22 106 12.6. Changes against 'draft-ietf-mmusic-data-channel- 107 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22 108 12.7. Changes against 'draft-ietf-mmusic-data-channel- 109 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 110 12.8. Changes against 'draft-ietf-mmusic-data-channel- 111 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 24 112 12.9. Changes against 'draft-ietf-mmusic-data-channel- 113 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 24 114 12.10. Changes against 'draft-ietf-mmusic-data-channel- 115 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 24 116 12.11. Changes against 'draft-ietf-mmusic-data-channel- 117 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 25 118 12.12. Changes against 'draft-ietf-mmusic-data-channel- 119 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 26 120 12.13. Changes against 'draft-ietf-mmusic-data-channel- 121 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 27 122 12.14. Changes against 'draft-ietf-mmusic-data-channel- 123 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 28 124 12.15. Changes against 'draft-ietf-mmusic-data-channel- 125 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 30 126 12.16. Changes against 'draft-ejzak-mmusic-data-channel- 127 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 33 128 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 34 129 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 34 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 132 13.2. Informative References . . . . . . . . . . . . . . . . . 36 133 Appendix A. Generic Data Channel Negotiation Aspects When Not 134 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 135 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 136 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 38 137 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 38 138 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 38 139 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 39 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 142 1. Introduction 144 The concept of establishing a bi-directional data channel running on 145 top of the Stream Control Transmission Protocol (SCTP) is in 146 [I-D.ietf-rtcweb-data-channel] allowing applications to use data 147 channels. An in-band Data Channel Establishment Protocol (DCEP) is 148 in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of- 149 band protocols may be used for establishing data channels. Each data 150 channel consists of paired SCTP streams sharing the same SCTP Stream 151 Identifier. Data channels are created by endpoint applications using 152 the WebRTC API (Application Programming Interface), or other 153 protocols like CLUE [I-D.ietf-clue-datachannel]. The protocols can 154 be signaled by the data channel "subprotocol" parameter, conceptually 155 similar to the WebSocket [RFC5234] "subprotocol". However, apart 156 from the "subprotocol" value transmitted to the peer, an endpoint 157 application can agree on how to instantiate a given subprotocol on a 158 data channel, and whether it is signaled in-band using DCEP or out- 159 of-band using a non-DCEP protocol (or both). 161 This document defines SDP offer/answer [RFC3264] procedures that 162 enable out-of-band negotiation for establishing data channels for 163 transport of well-defined subprotocols. These procedures are based 164 on generic SDP offer/answer negotiation rules for SCTP based media 165 transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" 166 line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. 168 This document uses MSRP (Message Session Relay Protocol) [RFC4975] 169 and BFCP (Binary Floor Control Protocol) [RFC4582] in many of the 170 examples. It does not provide a complete specification of how to 171 negotiate the use of a data channel to transport MSRP. Procedures 172 specific to each subprotocol would have to be documented elsewhere. 173 For MSRP they are documented in 174 [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some 175 examples is only to show how the generic procedures described herein 176 might apply to a specific subprotocol. 178 2. Conventions 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 182 "OPTIONAL" in this document are to be interpreted as described in 183 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 184 capitals, as shown here. 186 3. Terminology 188 This document uses the following terms: 190 Data channel: A WebRTC data channel as specified in 191 [I-D.ietf-rtcweb-data-channel]. 193 Data channel stack: An entity which, upon application request, 194 runs the data channel protocol to keep track of states, sending 195 and receiving data. If the application is a browser based 196 JavaScript application then this stack resides in the browser. If 197 the application is a native application then this stack resides in 198 the application and is accessible via some sort of APIs. 200 Data channel properties: Fixed properties assigned to a data 201 channel at the time of its creation. Some of these properties 202 determine the way the data channel stack transmits data on this 203 channel (e.g., stream identifier, reliability, order of delivery, 204 etc.). 206 Data channel subprotocol: The application protocol which is 207 transported over a single data channel. Data channel subprotocol 208 messages are sent as data channel payload over an established data 209 channel. SDP offer/answer exchange can be used as specified in 210 this document to negotiate the establishment of data channels, 211 corresponding data channel properties, associated data channel 212 subprotocols and data channel subprotocol properties. In this 213 case the data channel subprotocols may be identified by the values 214 of the "subprotocol" parameters of the SDP "a=dcmap" attribute as 215 described in Section 5.1.4. Within this document the term "data 216 channel subprotocol" is often abbreviated as just "subprotocol". 218 DCEP: Data Channel Establishment Protocol defined in 219 [I-D.ietf-rtcweb-data-protocol]. 221 In-band: Transmission through the peer-to-peer SCTP association. 223 Out-of-band: Transmission through the application signaling path. 225 Peer: From the perspective of one of the agents in a session, its 226 peer is the other agent. Specifically, from the perspective of 227 the SDP offerer, the peer is the SDP answerer. From the 228 perspective of the SDP answerer, the peer is the SDP offerer. 230 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 231 as specified in [RFC4960]. 233 Stream identifier: The identifier of the outbound and inbound SCTP 234 streams composing a data channel. 236 4. Applicability Statement 238 The mechanism in this document only applies to the Session 239 Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used 240 together with the SDP offer/answer mechanism [RFC3264]. Declarative 241 usage of SDP is out of scope for this document, and is thus 242 undefined. 244 5. SDP Data Channel Attributes 246 This section defines two new SDP media-level attributes that can be 247 used together with the SDP Offer/Answer mechanism to negotiate data 248 channel-specific and subprotocol-specific parameters without the 249 usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute 250 provides for negotiation of channel-specific parameters. The second 251 attribute provides for negotiation of subprotocol-specific 252 parameters. 254 Note: Appendix A provides information how data channels work in 255 general and especially summarizes some key aspects, which should be 256 considered for the negotiation of data channels if DCEP is not used. 258 5.1. SDP DCMAP Attribute 260 This section defines a new media level attribute "a=dcmap:" that 261 defines the data channel parameters for each data channel to be 262 negotiated. 264 The attribute is used to create bi-directional SCTP data channels 265 having the same set of attributes. The data channel properties 266 (reliable/partially reliable, ordered/unordered) need to be suitable 267 per the subprotocol transport requirements. 269 5.1.1. DCMAP Attribute Syntax 271 "a=dcmap:" is a media level attribute having the following ABNF 272 (Augmented Backus-Naur Form, [RFC5234]) syntax. 274 Formal Syntax: 276 Name: dcmap 278 Value: dcmap-value 280 Usage Level: media 281 Charset Dependent: no 283 Syntax: 285 dcmap-value = dcmap-stream-id 286 [ SP dcmap-opt *(";" dcmap-opt) ] 287 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 288 / maxretr-opt / maxtime-opt / priority-opt 289 ; maxretr-opt and maxtime-opt are mutually exclusive 290 ; 292 dcmap-stream-id = 1*5DIGIT 293 ordering-opt = "ordered=" ordering-value 294 ordering-value = "true" / "false" 295 subprotocol-opt = "subprotocol=" quoted-string 296 label-opt = "label=" quoted-string 297 maxretr-opt = "max-retr=" maxretr-value 298 maxretr-value = "0" / integer 299 ; number of retransmissions, 300 ; less than 2^32, 301 ; derived from 'Reliability Parameter' of 302 ; [I-D.ietf-rtcweb-data-protocol] 303 maxtime-opt = "max-time=" maxtime-value 304 maxtime-value = "0" / integer 305 ; milliseconds, 306 ; less than 2^32, 307 ; derived from 'Reliability Parameter' of 308 ; [I-D.ietf-rtcweb-data-protocol] 309 priority-opt = "priority=" priority-value 310 priority-value = "0" / integer 311 ; unsigned integer value indicating the priority of 312 ; the data channel, 313 ; less than 2^16, 314 ; derived from 'Priority' of 315 ; [I-D.ietf-rtcweb-data-protocol] 317 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 318 quoted-char = SP / quoted-visible 319 quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 320 escaped-char = "%" HEXDIG HEXDIG 321 DQUOTE = 322 integer = 324 Examples: 326 a=dcmap:0 327 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 328 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 329 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 330 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 332 Note: The last example (a=dcmap:4) shows a 'label' parameter value 333 which contains one non-printable 'escaped-char' character (the 334 tabulator character). 336 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 337 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be 338 present. Both MUST NOT be present. 340 5.1.2. Dcmap-stream-id Parameter 342 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 343 within the SCTP association used to form the data channel. 345 5.1.3. Label Parameter 347 The 'label' parameter indicates the name of the channel. It 348 represents a label that can be used to distinguish, in the context of 349 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 350 RTCDataChannel objects. This parameter maps to the 'Label' parameter 351 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 352 optional. If it is not present, then its value defaults to the empty 353 string. 355 In order to communicate with WEbRTC API the label attribute should: 357 o Serialize the WebRTC label as a UTF-8 string [RFC3629]. 359 o Treat the UTF-8 serialization as a series of bytes 361 o For each byte in the serialization: 363 * If the byte can be expressed as a `quoted-char`, do so 365 * Otherwise, express the byte as an `escaped-char`. 367 Note: The empty string MAY also be explicitly used as a 'label' 368 value, such that 'label=""' is equivalent to the 'label' parameter 369 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 370 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 372 5.1.4. Subprotocol Parameter 374 The 'subprotocol' parameter indicates which protocol the client 375 expects to exchange via the channel. This parameter maps to the 376 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 378 Section 9.1 specifies how new subprotocol parameter values are 379 registered. 'subprotocol' is an optional parameter. If the 380 'subprotocol' parameter is not present, then its value defaults to an 381 empty string. 383 Note: The empty string MAY also be explicitly used as 'subprotocol' 384 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 385 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 386 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 387 empty string. 389 5.1.5. Max-retr Parameter 391 This parameter indicates that the data channel is partially reliable. 392 The 'max-retr' parameter indicates the maximal number of times a user 393 message will be retransmitted. The max-retr parameter is optional. 394 If the max-retr parameter and the max-time parameter are not present, 395 then reliable transmission is performed as specified in [RFC4960]. 396 This parameter maps to the 'Number of RTX' parameter defined in 397 [I-D.ietf-rtcweb-data-protocol]. 399 5.1.6. Max-time Parameter 401 This parameter indicates that the data channel is partially reliable. 402 A user message will no longer be transmitted or retransmitted after a 403 specified life-time given in milliseconds in the 'max-time' 404 parameter. The life-time starts when providing the user message to 405 the protocol stack. The max-time parameter is optional. If the max- 406 retr parameter and the max-time parameter are not present, then 407 reliable transmission is performed as specified in [RFC4960]. This 408 parameter maps to the 'Lifetime in ms' parameter defined in 409 [I-D.ietf-rtcweb-data-protocol]. 411 5.1.7. Ordered Parameter 413 The 'ordered' parameter with value "true" indicates that the receiver 414 will dispatch DATA chunks in the data channel to the upper layer 415 while preserving the order. The ordered parameter is optional and 416 takes two values: "true" for ordered and "false" for unordered 417 delivery with "true" as the default value. Any other value is 418 ignored and default "ordered=true" is assumed. In the absence of 419 this parameter "ordered=true" is assumed. This parameter maps to the 420 ordered or unordered data channel types as defined in 421 [I-D.ietf-rtcweb-data-protocol]. 423 5.1.8. Priority Parameter 425 The 'priority' parameter indicates the data channel's priority 426 relative to the priorities of other data channels, which may 427 additionally exist over the same SCTP association. The 'priority' 428 parameter maps to the 'Priority' parameter defined in 429 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 430 optional. In the absence of this parameter "priority=256" is 431 assumed. 433 5.1.9. DCMAP Multiplexing Category 435 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the 436 "a=dcmap:" attribute is SPECIAL. 438 As the usage of multiple SCTP associations on top of a single DTLS 439 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 440 "a=dcmap:" attribute multiplexing rules are specified for the 441 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 442 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 443 multiple SCTP associations on top of a single DTLS association, or 444 how to add multiple SCTP associations to one BUNDLE group, then 445 multiplexing rules for the "a=dcmap:" attribute need to be defined as 446 well, for instance in an extension of this SDP offer/answer based 447 data channel negotiation specification. 449 5.2. SDP DCSA Attribute 451 In the SDP media description, each data channel declaration MAY also 452 be followed by other media level SDP attributes, which are either 453 specifically defined for or applied to the subprotocol in use. Each 454 of these attributes is represented by one new attribute line, and it 455 includes the contents of a media-level SDP attribute already defined 456 for use with this (sub)protocol in another IETF document. 457 Subprotocol specific attributes MAY also be defined for exclusive use 458 with data channel transport, but MUST use the same syntax described 459 here for other subprotocol related attributes. 461 Each SDP attribute, related to the subprotocol, that would normally 462 be used to negotiate the subprotocol using SDP offer/answer is 463 replaced with an attribute of the form "a=dcsa:stream-id original- 464 attribute", where dcsa stands for "data channel subprotocol 465 attribute", stream-id is the SCTP stream identifier assigned to this 466 subprotocol instance, and original-attribute represents the contents 467 of the subprotocol related attribute to be included. 469 The same syntax applies to any other SDP attribute required for 470 negotiation of this instance of the subprotocol. 472 The detailed offer/answer procedures for the dcsa attribute are 473 dependent on the associated sub-protocol. If no offer/answer 474 procedures exist for the sub-protocol when used outside of the dcsa 475 attribute, no specification is needed for use with dcsa. The IANA 476 registration procedures for the WebSocket Subprotocol Name Registry 477 (Section 9.1) do not strictly require a specification of the offer/ 478 answer procedures for the sub-protocol when used with dcsa. If the 479 sub-protocol has defined offer/answer procedures when used outside of 480 dcsa, such a specification is encouraged to ensure interoperability. 481 If the sub-protocol has defined offer/answer procedures when used 482 outside of dcsa, but no specification exists for the offer/answer 483 procedures for the sub-protocol when used with dcsa, implementations 484 SHOULD assume the use of the default values for all otherwise- 485 negotiable and applicable sub-protocol parameters. 487 5.2.1. DCSA Syntax 489 Formal Syntax: 491 Name: dcsa 493 Value: dcsa-value 495 Usage Level: media 497 Charset Dependent: no 499 Syntax: 501 dcsa-value = stream-id SP attribute 502 stream-id = 1*5DIGIT 503 attribute = 505 Example: 507 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 509 a=dcsa:2 accept-types:text/plain 511 Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where 512 the attribute definition can be found; it does not provide any 513 limitation on support of attributes defined in other documents in 514 accordance with this attribute definition. Note however that not all 515 SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP 516 parameters contains the lists of IANA (Internet Assigned Numbers 517 Authority) registered session and media level or media level only SDP 518 attributes. 520 Thus in the example above, the original attribute line "a=accept- 521 types:text/plain" is represented by the attribute line "a=dcsa:2 522 accept-types:text/plain", which specifies that this instance of the 523 MSRP subprotocol being transported on the SCTP association using the 524 data channel with stream id 2 accepts plain text files. 526 As opposed to the data channel "a=dcmap:" attribute parameters, these 527 parameters are subject to offer/answer negotiation following the 528 procedures defined in the subprotocol specific documents. 530 It is assumed that in general the usages of subprotocol related media 531 level attributes are independent from the subprotocol's transport 532 protocol. Such transport protocol independent subprotocol related 533 attributes are used in the same way as defined in the original 534 subprotocol specification, also if the subprotocol is transported 535 over a data channel and if the attribute is correspondingly embedded 536 in a "a=dcsa" attribute. 538 There may be cases, where the usage of a subprotocol related media 539 level attribute depends on the subprotocol's transport protocol. In 540 such cases the subprotocol related usage of the attribute is expected 541 to be described for the data channel transport. A data channel 542 specific usage of a subprotocol attribute is expected to be specified 543 in the same document that registers the subprotocol's identifier for 544 data channel usage as described in Section 9.1. 546 SDP attributes that are only defined for use at the dcsa usage level, 547 SHALL use the dcsa usage level when registering the attribute. If 548 existing media attributes are used in a datachannel subprotocol 549 specific way, then a new dcsa usage level MUST be defined for the 550 existing media attribute. Where the SDP attribute is applicable to a 551 particular subprotocol/s this SHALL also be registered by indicating 552 the applicable subprotocol identifiers (see 553 /[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage 554 level. 556 5.2.2. DCSA Multiplexing Category 558 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 560 As the usage of multiple SCTP associations on top of a single DTLS 561 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 562 "a=dcsa:" attribute multiplexing rules are specified for the 563 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 564 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 565 multiple SCTP associations on top of a single DTLS association, or 566 how to add multiple SCTP associations to one BUNDLE group, then 567 multiplexing rules for the "a=dcsa:" attribute need to be defined as 568 well, for instance in an extension of this SDP based data channel 569 negotiation specification. 571 6. SDP Offer/Answer Procedures 573 This section defines how data channels can be negotiated using the 574 SDP offer/answer mechanism. A given media description can describe 575 multiple data channels (each represented by a separate SDP dcmap 576 attribute) that can be created, modified and closed using different 577 offer/answer exchanges. The procedures in this section apply for a 578 given data channel. 580 The generic offer/answer procedures for negotiating the SCTP 581 association used to realize data channels are defined in 582 [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data 583 channel specific procedures. 585 "Initial offer" refers to the offer in which a data channel is 586 opened. It can be the initial offer, or a subsequent offer, of the 587 associated SDP session. 589 The detailed offer/answer procedures for the dcsa attribute are 590 dependent on the associated sub-protocol see Section 5.2. 592 6.1. Managing Stream Identifiers 594 In order to avoid SCTP Stream identifier collisions, in alignment 595 with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS 596 client (for the SCTP association used to realize data channels) MUST 597 use even identifier values, and the endpoint acting as DTLS server 598 MUST use odd identifier values. 600 SCTP stream identifiers associated with data channels that have been 601 negotiated using DCEP MUST NOT be included in SDP offers and answers. 603 6.2. Negotiating Data Channel Parameters 605 The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 606 mapped to the dcmap SDP attribute parameters in the following manner 607 where "ordered=true" is the default and may be omitted: 609 DATA_CHANNEL_RELIABLE 610 ordered=true 612 DATA_CHANNEL_RELIABLE_UNORDERED 613 ordered=false 615 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 616 ordered=true;max-retr= 618 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 619 ordered=false;max-retr= 621 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 622 ordered=true;max-time= 624 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 625 ordered=false;max-time= 627 By definition max-retr and max-time are mutually exclusive, so both 628 MUST NOT be present in the "a=dcmap:" attribute line. If an SDP 629 offer contains both of these parameters then the receiver of such an 630 SDP offer MUST reject the SDP offer. If an SDP answer contains both 631 of these parameters then the offerer MUST treat the associated SDP 632 offer/answer as failed. 634 6.3. Generating the Initial Offer for A Data Channel 636 When an offerer sends an initial offer, in order to negotiate an SCTP 637 stream for a data channel, the offerer: 639 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 640 associated with the data channel in the "m=" section representing 641 the SCTP association used to realize the data channel; and 643 o MAY include one or more SDP dcsa attributes (Section 5.2) 644 associated with the data channel. The value of the stream-id part 645 of each attribute SHALL match the dcmap-stream-id value of the 646 dcmap attribute. 648 6.4. Generating SDP Answer 650 When an answerer receives an offer that includes an "m=" section for 651 an SCTP association, that describes an SCTP stream for a data 652 channel, if the answerer accepts the data channel it: 654 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 655 associated with the data channel in the "m=" section representing 656 the SCTP association used to realize the data channel. The value 657 of the dcmap-stream-id, max-retr and max-time values of the dcmap 658 attribute SHALL be identical to the value used for the data 659 channel in the offer; and 661 o MAY include one or more SDP dcsa attributes (Section 5.2) 662 associated with the data channel. 664 6.5. Offerer Processing of the SDP Answer 666 An offerer receiving an SDP answer performs the following: 668 o SHALL close any created data channels as described in 669 Section 6.6.1 for which the expected "a=dcmap:" attributes are not 670 present in the SDP answer. If the SDP answer has no "a=dcmap" 671 attribute either the peer does not support "a=dcmap:" attributes 672 or it rejected all the data channels. In either case the offerer 673 closes all the SDP offered data channels that were open at the 674 time of offer. The DTLS association and SCTP association will 675 still be setup. At this point the offerer may use DCEP 676 negotiation [I-D.ietf-rtcweb-data-protocol] to open data channels 678 Each agent application MUST wait to send data until it has 679 confirmation that the data channel at the peer is instantiated. For 680 WebRTC, this is when both data channel stacks have channel parameters 681 instantiated. This occurs: 683 o At both peers when a data channel is created without a previously 684 established SCTP association, as soon as the SCTP association is 685 successfully established. 687 o At the agent receiving an SDP offer for which there is an 688 established SCTP association, as soon as it creates the negotiated 689 data channel based on information signaled in the SDP offer. 691 o At the agent sending an SDP offer to create a new data channel for 692 which there is an established SCTP association, when it receives 693 the SDP answer confirming acceptance of the data channel or when 694 it begins to receive data on the data channel from the peer, 695 whichever occurs first. 697 6.6. Modifying the Session 699 When an offer sends a subsequent offer, that includes information for 700 a previously negotiated data channel, unless the offerer intends to 701 close the data channel (Section 6.6.1), the offerer SHALL include the 702 previously negotiated SDP attributes and attribute values associated 703 with the data channel. The answerer may reject the offer. The means 704 for rejecting an offer are dependent on the higher layer protocol. 706 The offer/answer exchange is atomic; if the answer is rejected, the 707 session reverts to the state prior to the offer [RFC3264]. 709 6.6.1. Closing a Data Channel 711 In order to close a data channel, the endpoint that wants to close 712 SHALL send the SCTP SSN reset message [RFC6525], following the 713 procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In 714 addition, if the closed data channel was negotiated using the offer/ 715 answer mechanism Section 6.3, the endpoint that closed the data 716 channel SHALL send a subsequent offer in which it either: 718 o removes the SDP dcmap attribute and SDP dcsa attributes associated 719 with the closed data channel. Once the endpoint receives a 720 successful answer, the SCTP stream identifier value can later be 721 used for a new data channel (negotiated using DCTP or using the 722 offer/answer mechanism); or 724 o after a reset has been performed re-uses the SCTP stream used for 725 the closed data channel for a new data channel, using the 726 procedures in Section 6.3. The offerer SHALL use a different SDP 727 dcmap attribute value for the data channel using the same SCTP 728 stream. 730 6.7. Various SDP Offer/Answer Considerations 732 An SDP offer or answer has no "a=dcmap:" attributes but has 733 "a=dcsa:" attributes. 735 * This is considered an error case. In this case the receiver of 736 such an SDP offer or answer MUST discard this "a=dcsa:" 737 attributes. 739 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 740 attribute is unknown. 742 * The receiver of such an SDP offer or answer SHOULD ignore this 743 entire "a=dcsa" attribute line. 745 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 746 attribute is known, but whose subprotocol attribute semantic is 747 not known for the data channel transport case. 749 * The receiver of such an SDP offer or answer SHOULD ignore this 750 entire "a=dcsa" attribute line. 752 7. Examples 754 SDP offer: 756 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 757 c=IN IP6 2001:db8::3 758 a=max-message-size:100000 759 a=sctp-port:5000 760 a=setup:actpass 761 a=fingerprint:SHA-1 \ 762 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 763 a=tls-id:abc3de65cddef001be82 764 a=dcmap:0 subprotocol="bfcp";label="bfcp" 766 SDP answer: 768 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 769 c=IN IP6 2001:db8::1 770 a=max-message-size:100000 771 a=sctp-port:5002 772 a=setup:passive 773 a=fingerprint:SHA-1 \ 774 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 775 a=tls-id:dcb3ae65cddef0532d42 777 Figure 1: Example 1 779 In the example in Figure 1 the SDP answerer rejected the data channel 780 with stream id 0 either for explicit reasons or because it does not 781 understand the "a=dcmap:" attribute. As a result the offerer will 782 close the data channel created with the SDP offer/answer negotiation 783 option. The SCTP association will still be setup over DTLS. At this 784 point the offerer or the answerer may use DCEP negotiation to open 785 data channels. 787 SDP offer: 789 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 790 c=IN IP4 192.0.2.1 791 a=max-message-size:100000 792 a=sctp-port:5000 793 a=setup:actpass 794 a=fingerprint:SHA-1 \ 795 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 796 a=tls-id:abc3de65cddef001be82 797 a=dcmap:0 subprotocol="bfcp";label="bfcp" 798 a=dcmap:2 subprotocol="msrp";label="msrp" 799 a=dcsa:2 accept-types:message/cpim text/plain 800 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 802 SDP answer: 804 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 805 c=IN IP4 192.0.2.2 806 a=max-message-size:100000 807 a=sctp-port:5002 808 a=setup:passive 809 a=fingerprint:SHA-1 \ 810 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 811 a=tls-id:dcb3ae65cddef0532d42 812 a=dcmap:2 subprotocol="msrp";label="msrp" 813 a=dcsa:2 accept-types:message/cpim text/plain 814 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 816 Figure 2: Example 2 818 In the example in Figure 2 the SDP offer contains data channels for 819 BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 820 answer rejected BFCP and accepted MSRP. So, the offerer closes the 821 data channel for BFCP and both offerer and answerer may start using 822 the MSRP data channel (after the SCTP association is set up). The 823 data channel with stream id 0 is free and can be used for future DCEP 824 or SDP offer/answer negotiation. 826 Continuing the example in Figure 2. 828 Subsequent SDP offer: 830 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 831 c=IN IP4 192.0.2.1 832 a=max-message-size:100000 833 a=sctp-port:5000 834 a=setup:actpass 835 a=fingerprint:SHA-1 \ 836 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 837 a=tls-id:abc3de65cddef001be82 838 a=dcmap:4 subprotocol="msrp";label="msrp" 839 a=dcsa:4 accept-types:message/cpim text/plain 840 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 842 Subsequent SDP answer: 844 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 845 c=IN IP4 192.0.2.2 846 a=max-message-size:100000 847 a=sctp-port:5002 848 a=setup:passive 849 a=fingerprint:SHA-1 \ 850 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 851 a=tls-id:dcb3ae65cddef0532d42 852 a=dcmap:4 subprotocol="msrp";label="msrp" 853 a=dcsa:4 accept-types:message/cpim text/plain 854 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 856 Figure 3: Example 3 858 The example in Figure 3 is a continuation of the example in Figure 2. 859 The SDP offerer now removes the MSRP data channel with stream id 2, 860 but opens a new MSRP data channel with stream id 4. The answerer 861 accepts the entire offer. As a result the offerer closes the earlier 862 negotiated MSRP related data channel and both offerer and answerer 863 may start using new the MSRP related data channel. 865 8. Security Considerations 867 This document specifies new SDP attributes used in the negotiation of 868 the DATA channel parameters. 870 These parameter are negotiated as part of opening a SCTP channel over 871 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol 872 may come with it's own security considerations that need to be 873 documented as part of the subprotocol definition. Otherwise this 874 document does not add any security considerations to the ones 875 specified in [I-D.ietf-mmusic-sctp-sdp] 876 Error cases like the use of unknown parameter values or violation the 877 odd/even rule MUST be handled by closing the corresponding Data 878 Channel. 880 9. IANA Considerations 882 9.1. Subprotocol Identifiers 884 Registration of new subprotocol identifiers is performed using the 885 existing IANA "WebSocket Subprotocol Name Registry" table. 887 The following text should be added following the title of the table. 889 "This table also includes subprotocol identifiers specified for usage 890 within a WebRTC data channel." 892 The following reference should be added to under the heading 893 reference: "RFC XXXX". 895 This document assigns no new values to this table. 897 A subprotocol may simultaneously be defined for data channel 898 transport and for Websocket transport. In such a case the 899 "Subprotocol Definition" and "Reference" cells in the subprotocol's 900 row of the IANA "WebSocket Subprotocol Name Registry" table should 901 contain two entries. One entry in each of these cells should refer 902 to the Websocket related subprotocol specification, and the other 903 entry should refer to the data channel related subprotocol 904 specification. 906 NOTE to RFC Editor: Please replace "XXXX" with the number of this 907 RFC. 909 9.2. New SDP Attributes 911 9.2.1. dcmap 913 NOTE to RFC Editor: Please replace "XXXX" with the number of this 914 RFC. 916 This document defines a new SDP media-level attribute "a=dcmap:" as 917 follows: 919 +-----------------------+-------------------------------------------+ 920 | Contact name: | IESG | 921 | Contact email: | iesg@ietf.org | 922 | Attribute name: | dcmap | 923 | Attribute syntax: | As per Section 5.1.1 | 924 | Attribute semantics: | As per Section 5.1.1 | 925 | Usage level: | media | 926 | Charset dependent: | No | 927 | Purpose: | Define data channel specific parameters | 928 | Appropriate values: | As per Section 5.1.1 | 929 | O/A procedures: | As per Section 6 | 930 | Mux category: | SPECIAL. See Section 5.1.9 | 931 | Reference: | RFCXXXX | 932 +-----------------------+-------------------------------------------+ 934 9.2.2. dcsa 936 NOTE to RFC Editor: Please replace "XXXX" with the number of this 937 RFC. 939 This document defines a new SDP media-level attribute "a=dcsa:" as 940 follows: 942 +-----------------------+-------------------------------------------+ 943 | Contact name: | IESG | 944 | Contact email: | iesg@ietf.org | 945 | Attribute name: | dcsa | 946 | Attribute syntax: | As per Section 5.2.1 | 947 | Attribute semantics: | As per Section 5.2.1 | 948 | Usage level: | media | 949 | Charset dependent: | No | 950 | Purpose: | Define data channel subprotocol specific | 951 | | attributes | 952 | Appropriate values: | As per Section 5.2.1 | 953 | O/A procedures: | As per Section 6 | 954 | Mux category: | SPECIAL. See Section 5.2.2 | 955 | Reference: | RFCXXXX | 956 +-----------------------+-------------------------------------------+ 958 10. Contributors 960 Juergen Stoetzer-Bradler co-authored this document. 962 11. Acknowledgments 964 The authors wish to acknowledge the borrowing of ideas from other 965 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 966 and Gavin Llewellyn, and to thank Flemming Andreasen, Christian 967 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe 968 Rauschenbach and Roman Shpount for their invaluable comments. 970 Special thanks to Christer Holmberg for helping finish the document 971 and cleaning the SDP offer/answer section. 973 12. CHANGE LOG 975 12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 977 o Editorial changes separate sections for offer/answer procedures. 979 o Update security section. 981 12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 983 o Change "dtls-id" to "tls-id" and assign 20 octet long values 985 o Remove of RFC4566bis draft from list of normative references. 987 12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 989 o Modification of Keith's address information. 991 12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 993 o dcmap-stream-id syntax change to limit size to 5 digits. 995 o Add missing 'x' prefix to quoted-visible syntax. 997 o Align SDP offerer and answerer handling when both max-retr and 998 max-time are present. 1000 o Use of TEST-NET-1 ip addresses in examples. 1002 o Add missing a=dtls-id in one example. 1004 12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1006 o Removal of the "a=connection" attribute lines from all SDP 1007 examples. 1009 12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1011 o In the introduction: 1013 * Replacement of the sentence "The RTCWeb working group has 1014 defined the concept of bi-directional data channels running on 1015 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1016 Security protocol)" with "The RTCWeb working group has defined 1017 the concept of bi-directional data channels running on top of 1018 the Stream Control Transmission Protocol (SCTP)". 1020 * Addition of following sentences to the second paragraph: "These 1021 procedures are based on generic SDP offer/answer negotiation 1022 rules for SCTP based media transport as specified in 1023 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1024 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1025 could be defined over other SCTP based protocols, such as SCTP 1026 over IP. However, corresponding potential other "m" line proto 1027 values are not considered in this document." 1029 o Replacement of "DTLS connection" with "DTLS association" 1030 throughout the document. 1032 o In sections Section 5.1.9 and Section 5.2.2 removal of the 1033 sentences "This document also does not specify multiplexing rules 1034 for this attribute for SCTP or SCTP/DTLS proto values". 1036 o In the text related to "Subsequent SDP answer" in section 1037 Section 6.7 replacement of "The DTLS/SCTP association remains open 1038 ..." with "The SCTP association remains open ...". 1040 o In the text after the second SDP answer in section Section 7 1041 replacement of "... (after SCTP/DTLS association is setup)" with 1042 "... (after the SCTP association is set up)". 1044 o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative 1045 references. 1047 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1048 examples in Section 7. 1050 12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1052 o Addition of definition of "data channel subprotocol" to Section 3 1053 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1054 archive/web/mmusic/current/msg15827.html. 1056 o Addition of RFC4566bis draft to list of normative references. 1058 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1059 section 8.2.4 of RFC4566bis draft. 1061 o Addition of new "new-usage-level">. 1063 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1065 o Addition of two new paragraphs to Section 5.2.1 regarding 1066 subprotocol attribute relationship with transport protocol. 1068 o Addition of a note to Section 9.1 regarding subprotocols 1069 simultaneously defined for data channel and Websocket usage. 1071 o Addition of two further SDP offer/answer considerations to 1072 Section 6.7 regarding unknown subprotocol attributes and known 1073 subprotocol attributes with unknown data channel transport related 1074 semantic. 1076 12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1078 o Changes addressing Christian Groves's WGLC review comments raised 1079 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1080 msg15357.html and http://www.ietf.org/mail- 1081 archive/web/mmusic/current/msg15359.html. 1083 12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1085 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1086 of contact name and e-mail address with "MMUSIC Chairs" and 1087 "mmusic-chairs@ietf.org". 1089 o In Section 5.2.1 replacement of "Thus in the example above, the 1090 original attribute line "a=accept- types:text/plain" is 1091 represented by the attribute line "a=dcsa:2 accept-types:text/ 1092 plain", which specifies that this instance of MSRP being 1093 transported on the SCTP association using the data channel with 1094 stream id 2 accepts plain text files." with "... which specifies 1095 that this instance of the MSRP subprotocol being transported ...". 1097 o The last paragraph of Section 5.2.1 started with "Note: This 1098 document does not provide a complete specification ...". Removal 1099 of "Note:" and move of this paragraph to the introduction in 1100 Section 1 as last paragraph. 1102 o Section 5.2's headline was "Subprotocol Specific Attributes". 1103 Change of this headline to "Other Media Level Attributes" and 1104 adaptations of the first paragraph of this section and the first 1105 paragraph of Section 5.2.1 in order to clarify that not only those 1106 attributes may be encapsulated in a "dcsa" attribute, which are 1107 specifically defined for the subprotocol, but that also other 1108 attributes may be encapsulated if they are related to the specific 1109 subprotocol instance. 1111 o Move of the last but one paragraph of Section 5.2.1 starting with 1112 "The same syntax applies to ..." right in front of the formal 1113 syntax definition of the "dcsa" attribute. 1115 o Modifications of the text in Section 5.1.9 and Section 5.2.2 in 1116 order not to explicitly restrict usage of the "a=dcmap:" and 1117 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1118 SCTP" or "TCP/DTLS/SCTP". 1120 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1122 o In Section 5.1.4 the first (and only) paragraph was "The 1123 'subprotocol' parameter indicates which protocol the client 1124 expects to exchange via the channel. 'subprotocol' is an optional 1125 parameter. If the 'subprotocol' parameter is not present, then 1126 its value defaults to the empty string." Replacement of this 1127 paragraph with following two paragraphs: 1129 * The 'subprotocol' parameter indicates which protocol the client 1130 expects to exchange via the channel. This parameter maps to 1131 the 'Protocol' parameter defined in 1132 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1133 subprotocol parameter values are registered. 'subprotocol' is 1134 an optional parameter. If the 'subprotocol' parameter is not 1135 present, then its value defaults to the empty string. 1137 * Note: The empty string MAY also be explicitly used as 1138 'subprotocol' value, such that 'subprotocol=""' is equivalent 1139 to the 'subprotocol' parameter not being present at all. 1140 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1141 message's 'subprotocol' value to be an empty string. 1143 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1144 normative references. 1146 o Addition of dcmap attribute specific IANA registration 1147 Section 9.2.1. 1149 o Addition of dcsa attribute specific IANA registration 1150 Section 9.2.2. 1152 o Addition of new Section 5.1.9 describing the mux category of the 1153 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1154 related mux category section are similar to the "Mux Category" 1155 sections of the "a=sctp-port:" and "a=max-message-size:" 1156 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1158 o Addition of new Section 5.2.2 describing the mux category of the 1159 dcsa SDP attribute. 1161 12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1163 o In Section 1 replacement of "RTCWeb leaves it open for other 1164 applications to use data channels and its in-band DCEP or out-of- 1165 band non-DCEP protocols for creating them" with "... to use data 1166 channels and its in-band DCEP or other in-band or out-of-band 1167 protocols for creating them". Additionally replacement of "In 1168 particular, the SDP offer generated by the application includes no 1169 channel-specific information" with "... generated by the RTCweb 1170 data channel stack includes no channel-specific information". 1172 o Move of former section 5 ("Data Channels") to new Appendix A and 1173 removal of JavaScript API specific discussions from this moved 1174 text (like mentioning of data channel stack specific states). 1175 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1176 Section 5. 1178 o In Section 5: 1180 * Relacement of Section 5's first paragraph "This section defines 1181 a method of non-DCEP negotiation by which two clients can 1182 negotiate data channel-specific and subprotocol-specific 1183 parameters, using the out-of-band SDP offer/answer exchange. 1184 This SDP extension can only be used with the SDP offer/answer 1185 model." with "This section defines an SDP extension by which 1186 two clients can negotiate data channel-specific and 1187 subprotocol-specific parameters without using DCEP 1188 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1189 defines usage in the context of SDP offer/answer." 1191 * Addition of new paragraph: "Appendix A provides information how 1192 data channels work in general and especially summarizes some 1193 key aspects, which should be considered for the negotiation of 1194 data channels if DCEP is not used." 1196 o In Section 5.1 replacement of "The intention of exchanging these 1197 attributes is to create data channels on both the peers with the 1198 same set of attributes without actually using the DCEP 1199 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1200 these attributes is to create, on two peers, without use of DCEP 1201 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1202 directed data channels having the same set of attributes". 1204 o In Section 5.1.5 replacement of "The 'max-retr' parameter 1205 indicates the maximal number a user message will be retransmitted" 1206 with "The 'max-retr' parameter indicates the maximal number of 1207 times a user message will be retransmitted". 1209 o In Section 6.1 replacement of "However, an SDP offer/answer 1210 exchange MUST NOT be initiated if the associated SCTP stream is 1211 already negotiated via DCEP" with "However, an SCTP stream MUST 1212 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1213 answer exchange if the associated SCTP stream has already been 1214 negotiated via DCEP". 1216 o In the examples in Section 7 addition of the previously missing 1217 colons to the "a=sctp-port" attribute lines. 1219 12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1221 o Move of reference draft-ietf-rtcweb-jsep from the list of 1222 normative references to the list of informative references. 1223 Remover in -07 since not referenced 1225 o Addition of IANA SDP parameters to the list of informative 1226 references and addition of following two sentences to the first 1227 paragraph after the ABNF definition: "Note however that not all 1228 SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP 1229 parameters contains the lists of IANA registered session and media 1230 level or media level only SDP attributes." 1232 o In the introduction replacement of last sentence "This document 1233 defines SDP-based out-of-band negotiation procedures to establish 1234 data channels for transport of well-defined subprotocols" with 1235 "This document defines SDP offer/answer negotiation procedures to 1236 establish data channels for transport of well-defined 1237 subprotocols, to enable out-of-band negotiation". 1239 o Throughout the document replacement of "external negotiation" with 1240 "SDP offer/answer negotiation" and removal of term "external 1241 negotiation" from the terminology list in Section 3. 1243 o Throughout the document replacement of "internal negotiation" with 1244 "DCEP" and removal of terms "internal negotiation" and "in-band 1245 negotiation" from the terminology list in Section 3. 1247 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1248 terms. 1250 o In Section 6.1 replacement of sentence "However, a single stream 1251 is managed using one method at a time." with "However, an SDP 1252 offer/answer exchange MUST NOT be initiated if the associated SCTP 1253 stream is already negotiated via DCEP". 1255 o In Section 6.2 replacement of sentence "By definition max-retr and 1256 max-time are mutually exclusive, so only one of them can be 1257 present in a=dcmap" with "By definition max-retr and max-time are 1258 mutually exclusive, so aBoth MUST NOT be present in a=dcmap". 1260 o Move of reference [WebRtcAPI] from list of normative references to 1261 list of informative references. 1263 o Removal of almost all text parts, which discussed JavaScript or 1264 other API specific aspects. Such API specific aspects were mainly 1265 discussed in sub-sections of Section 5 and Section 5 of draft- 1266 ietf-mmusic-data-channel-sdpneg-02. 1268 12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1270 o New Section 4 regarding applicability to SDP offer/answer only. 1272 o Addition of new Section 9.1 "Subprotocol identifiers" as 1273 subsection of the "IANA Considerations" related Section 9. Also 1274 removal of the temporary note "To be completed. As [I-D.ietf- 1275 rtcweb-data-protocol] this document should refer to IANA's 1276 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1278 o In Section 6.2: 1280 * In the first paragraph replacement of the sentence "If an SDP 1281 offer contains both of these parameters then such an SDP offer 1282 will be rejected." with "If an SDP offer contains both of these 1283 parameters then the receiver of such an SDP offer MUST reject 1284 the SDP offer." 1286 * In the second paragraph capitalization of "shall" and "may" 1287 such that both sentences now read: "The SDP answer SHALL echo 1288 the same subprotocol, max-retr, max-time, ordered parameters, 1289 if those were present in the offer, and MAY include a label 1290 parameter. They MAY appear in any order, which could be 1291 different from the SDP offer, in the SDP answer." 1293 * In the third paragraph replacement of the sentence "The same 1294 information MUST be replicated without changes in any 1295 subsequent offer or answer, as long as the data channel is 1296 still opened at the time of offer or answer generation." with 1297 "When sending a subsequent offer or an answer, and for as long 1298 as the data channel is still open, the sender MUST replicate 1299 the same information.". 1301 o In Section 6.2 the mapping of data channel types defined in 1302 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1303 parameters were illustrated using example "a=dcmap" attribute 1304 lines. Replacement of these example "a=dcmap" attribute lines 1305 with just the "a=dcmap" attribute parameters being relevant for 1306 the channel type. 1308 o In Section 6.7 the description of bullet point "SDP offer has no 1309 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1310 No data channel negotiated yet." Replacement of this description 1311 with "Initial SDP offer: No data channel is negotiated yet. The 1312 DTLS connection and SCTP association is negotiated and, if agreed, 1313 established as per [I-D.ietf-mmusic-sctp-sdp]." 1315 o In Section 6.7 in both bullet points related to "Subsequent SDP 1316 offer" and "Subsequent SDP answer" replacement of "All the 1317 externally negotiated data channels must be closed now." with "All 1318 the externally negotiated data channels are expected to be closed 1319 now.". 1321 o In Appendix A.2.2's sixth paragraph replacement of the two 1322 occurrences of "must" with "MUST". 1324 o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" 1325 there was a comment saying that "Only maxretr-opt or maxtime-opt 1326 is present. Both MUST NOT be present." Removal of the second 1327 normative sentence and instead addition of following new paragraph 1328 to the end of this section: "Within an 'a=dcmap' attribute line's 1329 'dcmap-opt' value only one 'maxretr-opt' parameter or one 1330 'maxtime-opt' parameter is present. Both MUST NOT be present." 1332 o In Section 5.1.7 replacement of the first sentence "The 'ordered' 1333 parameter with value "true" indicates that DATA chunks in the 1334 channel MUST be dispatched to the upper layer by the receiver 1335 while preserving the order." with "The 'ordered' parameter with 1336 value "true" indicates that the receiver MUST dispatch DATA chunks 1337 in the data channel to the upper layer while preserving the 1338 order.". 1340 o In Section 6.3's first paragraph replacement of the one occurrence 1341 of "must" with "..., it MUST wait until ...". 1343 o In Section 6.6.1: 1345 * In the second paragraph replacement of "must" with "... whether 1346 this closing MUST in addition ..." 1348 * In the third paragraph replacement of the sentence "The port 1349 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1350 when closing a data channel ..." with "The offerer SHOULD NOT 1351 change the port value for the "m" line (e.g., to zero) when 1352 closing a data channel ...". 1354 * In the last but two paragraph replacement of the sentence "... 1355 then an SDP offer which excludes this closed data channel 1356 SHOULD be generated." with "... then the client SHOULD generate 1357 an SDP offer which excludes this closed data channel.". 1359 * In the last but one paragraph replacement of "must" with "The 1360 application MUST also close...". 1362 o In Section 5.2 addition of following note after the formal 1363 definition of the 'a=dcsa' attribute: "Note that the above 1364 reference to RFC 4566 defines were the attribute definition can be 1365 found; it does not provide any limitation on support of attributes 1366 defined in other documents in accordance with this attribute 1367 definition." 1369 12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1371 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1372 channel consisting of paired SCTP outbound and inbound streams." 1373 Replacement of this definition with "Data channel: A WebRTC data 1374 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1375 consistent usage of "data channel" in the remainder of the 1376 document including the document's headline." 1378 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1379 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1380 In particular we expect "webrtc-datachannel" to become a more 1381 general term.' 1383 o Consistent usage of '"m" line' in whole document as per RFC4566. 1385 o In Section 5.1 removal of the example dcmap attribute line 1386 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are 1387 already four examples right after the ABNF rules in Section 5.1.1. 1388 Corresponding removal of following related note: "Note: This 1389 document does not provide a complete specification of how to 1390 negotiate the use of a WebRTC data channel to transport BFCP. 1391 Procedures specific to each subprotocol such as BFCP will be 1392 documented elsewhere. The use of BFCP is only an example of how 1393 the generic procedures described herein might apply to a specific 1394 subprotocol." 1396 o In Section 5.1 removal of following note: "Note: This attribute is 1397 derived from attribute "webrtc-DataChannel", which was defined in 1398 old version 03 of the following draft, but which was removed along 1399 with any support for SDP external negotiation in subsequent 1400 versions: [I-D.ietf-mmusic-sctp-sdp]." 1402 o Insertion of following new sentence to the beginning of 1403 Section 5.1.1: "dcmap is a media level attribute having following 1404 ABNF syntax:" 1406 o Insertion of new Section 5.1.2 containing the dcmap-stream-id 1407 specifying sentence, which previously was placed right before the 1408 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1409 parameter and is noted directly after the "a=dcmap:" attribute's 1410 colon' as this information is part of the ABNF specification. 1412 o In Section 5.1.1 modification of the 'ordering-value' values from 1413 "0" or "1" to "true" or "false". Corresponding text modifications 1414 in Section 5.1.7. 1416 o In Section 5.1.1 the ABNF definition of "quoted-string" referred 1417 to rule name "escaped-char", which was not defined. Instead a 1418 rule with name "escaped" was defined. Renamed that rule's name to 1419 "escaped-char". 1421 o Insertion of a dedicated note right after the "a=dcmap:4" 1422 attribute example in Section 5.1.1 regarding the non-printable 1423 "escaped-char" character within the "label" value. 1425 o In Section 5.2's second paragraph replacement of "sctp stream 1426 identifier" with "SCTP stream identifier". 1428 o In first paragraph of Section 6.1 replacement of first two 1429 sentences 'For the SDP-based external negotiation described in 1430 this document, the initial offerer based "SCTP over DTLS" owns by 1431 convention the even stream identifiers whereas the initial 1432 answerer owns the odd stream identifiers. This ownership is 1433 invariant for the whole lifetime of the signaling session, e.g. it 1434 does not change if the initial answerer sends a new offer to the 1435 initial offerer.' with 'If an SDP offer/answer exchange (could be 1436 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1437 TCP/DTLS/SCTP based media description being accepted, and if this 1438 SDP offer/answer exchange results in the establishment of a new 1439 SCTP association, then the SDP offerer owns the even SCTP stream 1440 ids of this new SCTP association and the answerer owns the odd 1441 SCTP stream identifiers. If this "m" line is removed from the 1442 signaling session (its port number set to zero), and if usage of 1443 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1444 renegotiated later on, then the even and odd SCTP stream 1445 identifier ownership is redetermined as well as described above.' 1447 o In Section 6.3 the first action of an SDP answerer, when receiving 1448 an SDP offer, was described as "Applies the SDP offer. Note that 1449 the browser ignores data channel specific attributes in the SDP." 1450 Replacement of these two sentences with "Parses and applies the 1451 SDP offer. Note that the typical parser normally ignores unknown 1452 SDP attributes, which includes data channel related attributes." 1454 o In Section 6.3 the second sentence of the third SDP answerer 1455 action was "Note that the browser is asked to create data channels 1456 with stream identifiers not "owned" by the agent.". Replacement 1457 of this sentence with "Note that the agent is asked to create data 1458 channels with SCTP stream identifiers contained in the SDP offer 1459 if the SDP offer is accepted." 1461 o In Section 6.6.1 the third paragraph began with "A data channel 1462 can be closed by sending a new SDP offer which excludes the dcmap 1463 and dcsa attribute lines for the data channel. The port value for 1464 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1465 data channel (unless all data channels are being closed and the 1466 SCTP association is no longer needed), since this would close the 1467 SCTP association and impact all of the data channels. If the 1468 answerer accepts the SDP offer then it MUST also exclude the 1469 corresponding attribute lines in the answer. ..." Replacement of 1470 this part with "The intention to close a data channel can be 1471 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1472 and "a=dcsa:" attribute lines for the data channel. The port 1473 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1474 closing a data channel (unless all data channels are being closed 1475 and the SCTP association is no longer needed), since this would 1476 close the SCTP association and impact all of the data channels. 1477 If the answerer accepts the SDP offer then it MUST close those 1478 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1479 excluded from the received SDP offer, unless those data channels 1480 were already closed, and it MUST also exclude the corresponding 1481 attribute lines in the answer." 1483 o In Section 6.6.1 the hanging text after the third paragraph was 1484 "This delayed close is to handle cases where a successful SDP 1485 answer is not received, in which case the state of session should 1486 be kept per the last successful SDP offer/answer." Replacement of 1487 this sentence with "This delayed closure is RECOMMENDED in order 1488 to handle cases where a successful SDP answer is not received, in 1489 which case the state of the session SHOULD be kept per the last 1490 successful SDP offer/answer." 1492 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1493 Section 5.1 contained already procedural descriptions related to 1494 data channel reliability negotiation. Creation of new Section 6.2 1495 and moval of reliability negotiation related text to this new 1496 section. 1498 12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1500 o Removal of note "ACTION ITEM" from section "subprotocol 1501 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1502 should refer to IANA's WebSocket Subprotocol Name Registry defined 1503 in [RFC6455] 1505 o In whole document, replacement of "unreliable" with "partially 1506 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1507 [I-D.ietf-rtcweb-data-protocol] in most places. 1509 o Clarification of the semantic if the "max-retr" parameter is not 1510 present in an "a=dcmap" attribute line. In section "max-retr 1511 parameter" the sentence "The max-retr parameter is optional with 1512 default value unbounded" was replaced with "The max-retr parameter 1513 is optional. If the max-retr parameter is not present, then the 1514 maximal number of retransmissions is determined as per the generic 1515 SCTP retransmission rules as specified in [RFC4960]". 1517 o Clarification of the semantic if the "max-time" parameter is not 1518 present in an "a=dcmap" attribute line. In section "max-time 1519 parameter" the sentence "The max-time parameter is optional with 1520 default value unbounded" was replaced with "The max-time parameter 1521 is optional. If the max-time parameter is not present, then the 1522 generic SCTP retransmission timing rules apply as specified in 1523 [RFC4960]". 1525 o In section "label parameter" the sentence "Label is a mandatory 1526 parameter." was removed and following new sentences (including the 1527 note) were added: "The 'label' parameter is optional. If it is 1528 not present, then its value defaults to the empty string. Note: 1529 The empty string may also be explicitly used as 'label' value, 1530 such that 'label=""' is equivalent to the 'label' parameter not 1531 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1532 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1534 o In section "subprotocol parameter" the sentence "subprotocol is a 1535 mandatory parameter." was replaced with "'subprotocol' is an 1536 optional parameter. If the 'subprotocol' parameter is not 1537 present, then its value defaults to the empty string." 1539 o In the "Examples" section, in the first two SDP offer examples in 1540 the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 1541 'label="bfcp"'. 1543 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1544 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1545 replaced with "a=max-message-size" attribute lines, as per draft- 1546 ietf-mmusic-sctp-sdp-12. 1548 12.17. Changes against '-01' 1550 o Formal syntax for dcmap and dcsa attribute lines. 1552 o Making subprotocol as an optional parameter in dcmap. 1554 o Specifying disallowed parameter combinations for max-time and max- 1555 retr. 1557 o Clarifications on WebRTC data channel close procedures. 1559 12.18. Changes against '-00' 1561 o Revisions to identify difference between internal and external 1562 negotiation and their usage. 1564 o Introduction of more generic terminology, e.g. "application" 1565 instead of "browser". 1567 o Clarification of how "max-retr and max-time affect the usage of 1568 unreliable and reliable WebRTC data channels. 1570 o Updates of examples to take into account the SDP syntax changes 1571 introduced with draft-ietf-mmusic-sctp-sdp-07. 1573 o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" 1574 attributes as this is now contained in the a=sctp-port attribute, 1575 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1576 association on top of the DTLS connection. 1578 13. References 1580 13.1. Normative References 1582 [I-D.ietf-mmusic-rfc4566bis] 1583 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1584 Session Description Protocol", draft-ietf-mmusic- 1585 rfc4566bis-32 (work in progress), December 2018. 1587 [I-D.ietf-mmusic-sctp-sdp] 1588 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1589 "Session Description Protocol (SDP) Offer/Answer 1590 Procedures For Stream Control Transmission Protocol (SCTP) 1591 over Datagram Transport Layer Security (DTLS) Transport.", 1592 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1593 2017. 1595 [I-D.ietf-mmusic-sdp-mux-attributes] 1596 Nandakumar, S., "A Framework for SDP Attributes when 1597 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1598 (work in progress), February 2018. 1600 [I-D.ietf-rtcweb-data-channel] 1601 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1602 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1603 progress), January 2015. 1605 [I-D.ietf-rtcweb-data-protocol] 1606 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1607 Establishment Protocol", draft-ietf-rtcweb-data- 1608 protocol-09 (work in progress), January 2015. 1610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1611 Requirement Levels", BCP 14, RFC 2119, 1612 DOI 10.17487/RFC2119, March 1997, 1613 . 1615 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1616 with Session Description Protocol (SDP)", RFC 3264, 1617 DOI 10.17487/RFC3264, June 2002, 1618 . 1620 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1621 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1622 2003, . 1624 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1625 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1626 . 1628 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1629 Specifications: ABNF", STD 68, RFC 5234, 1630 DOI 10.17487/RFC5234, January 2008, 1631 . 1633 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1634 Transmission Protocol (SCTP) Stream Reconfiguration", 1635 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1636 . 1638 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1639 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1640 May 2017, . 1642 13.2. Informative References 1644 [I-D.ietf-clue-datachannel] 1645 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1646 clue-datachannel-18 (work in progress), April 2019. 1648 [I-D.ietf-mmusic-msrp-usage-data-channel] 1649 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1650 Marcon, J., and J. Recio, "MSRP over Data Channels", 1651 draft-ietf-mmusic-msrp-usage-data-channel-10 (work in 1652 progress), April 2019. 1654 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1655 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1656 November 2006, . 1658 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1659 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1660 DOI 10.17487/RFC4975, September 2007, 1661 . 1663 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1664 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1665 . 1667 [WebRtcAPI] 1668 Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., 1669 Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: 1670 Real-time Communication Between Browsers", World Wide Web 1671 Consortium CR CR-webrtc-20180927, September 2018, 1672 . 1674 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1675 DCEP 1677 This appendix summarizes how data channels work in general and 1678 discusses some key aspects, which should be considered for the out- 1679 of-band negotiation of data channels if DCEP is not used. 1681 A WebRTC application creates a data channel by providing a number of 1682 setup parameters (subprotocol, label, maximal number of 1683 retransmissions, maximal retransmission time, order of delivery, 1684 priority). The application also specifies if it wants to make use of 1685 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1686 the application intends to negotiate data channels using the SDP 1687 offer/answer protocol. 1689 In any case, the SDP offer generated by the application is per 1690 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1691 the SCTP association on top of which data channels will run: 1693 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1694 c=IN IP4 192.0.2.1 1695 a=max-message-size:100000 1696 a=sctp-port:5000 1697 a=tls-id:abc3de65cddef001be82 1698 a=setup:actpass 1699 a=fingerprint:SHA-1 \ 1700 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1702 Note: A WebRTC application will only use "m" line format "webrtc- 1703 datachannel", and will not use other formats in the "m" line for 1704 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1705 only one SCTP association to be established on top of a DTLS 1706 association. 1708 Note: The above SDP media description does not contain any channel- 1709 specific information. 1711 A.1. Stream Identifier Numbering 1713 Independently from the requested type of negotiation, the application 1714 creating a data channel can either pass the stream identifier to the 1715 data channel stack to assign to the data channel or else let the data 1716 channel stack pick one identifier from the unused ones. 1718 To avoid glare situations [RFC3264], each endpoint can moreover own 1719 an exclusive set of stream identifiers, in which case an endpoint can 1720 only create a data channel with a stream identifier it owns. 1722 Which set of stream identifiers is owned by which endpoint is 1723 determined by convention or other means. 1725 Note:For data channels negotiated with the DCEP, one endpoint owns 1726 by convention the even stream identifiers, whereas the other owns 1727 the odd stream identifiers, as defined in 1728 [I-D.ietf-rtcweb-data-protocol]. 1730 Note:For data channels negotiated via different protocol from 1731 DCEP, no convention is defined by default. 1733 A.2. Generic Data Channel Negotiation Not Using DCEP 1735 A.2.1. Overview 1737 DCEP negotiation only provides for negotiation of data channel 1738 transport parameters and does not provide for negotiation of 1739 subprotocol specific parameters. DCEP-less data channel negotiation 1740 can be defined to allow negotiation of parameters beyond those 1741 handled by DCEP, e.g., parameters specific to the subprotocol 1742 instantiated on a particular data channel. 1744 The following procedures are common to all methods of data channel 1745 negotiation not using DCEP, whether in-band (communicated using 1746 proprietary means on an already established data channel) or out-of- 1747 band (using SDP offer/answer or some other protocol associated with 1748 the signaling channel). 1750 A.2.2. Opening a Data Channel 1752 In the case of DCEP-less negotiation, the endpoint application has 1753 the option to fully control the stream identifier assignments. 1754 However these assignments have to coexist with the assignments 1755 controlled by the data channel stack for the DCEP negotiated data 1756 channels (if any). It is the responsibility of the application to 1757 ensure consistent assignment of stream identifiers. 1759 When the application requests the creation of a new data channel to 1760 be set up via DCEP-less negotiation, the data channel stack creates 1761 the data channel locally without sending any DATA_CHANNEL_OPEN 1762 message in-band. However, even if the ICE (Interactive Connectivity 1763 Establishment), DTLS and SCTP procedures were already successfully 1764 completed, the application can't send data on this data channel until 1765 the negotiation is complete with the peer. This is because the peer 1766 needs to be aware of and accept the usage of this data channel. The 1767 peer, after accepting the data channel offer, can start sending data 1768 immediately. This implies that the offerer may receive data channel 1769 subprotocol messages before the negotiation is complete and the 1770 application should be ready to handle it. 1772 If the peer rejects the data channel part of the offer then it 1773 doesn't have to do anything as the data channel was not created using 1774 the stack. The offerer on the other hand needs to close the data 1775 channel that was opened by invoking relevant data channel stack API 1776 procedures. 1778 It is also worth noting that a data channel stack implementation may 1779 not provide any API to create and close data channels; instead the 1780 data channels may be used on the fly as needed just by communicating 1781 via non-DCEP means or by even having some local configuration/ 1782 assumptions on both the peers. 1784 The application then negotiates the data channel properties and 1785 subprotocol properties with the peer's application using a mechanism 1786 different from DCEP. 1788 The peer then symmetrically creates a data channel with these 1789 negotiated data channel properties. This is the only way for the 1790 peer's data channel stack to know which properties to apply when 1791 transmitting data on this channel. The data channel stack must allow 1792 data channel creation with any non-conflicting stream identifier so 1793 that both peers can create the data channel with the same stream 1794 identifier. 1796 A.2.3. Closing a Data Channel 1798 When the application requests the closing of a data channel 1799 negotiated without DCEP, the data channel stack always performs an 1800 SCTP SSN reset for this channel. 1802 Depending upon the method used for DCEP-less negotiation and the 1803 subprotocol associated with the data channel, the closing might in 1804 addition be signaled to the peer via SDP offer/answer negotiation. 1806 Authors' Addresses 1808 Keith Drage 1809 Unaffiliated 1811 Email: drageke@ntlworld.com 1813 Maridi R. Makaraju (Raju) 1814 Nokia 1815 2000 Lucent Lane 1816 Naperville, Illinois 1817 US 1819 Email: Raju.Makaraju@nokia.com 1820 Richard Ejzak 1821 Unaffiliated 1823 Email: richard.ejzak@gmail.com 1825 Jerome Marcon 1826 Unaffiliated 1828 Email: jeromee.marcon@free.fr 1830 Roni Even (editor) 1831 Huawei 1833 Email: roni.even@huawei.com