idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-27.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 (April 29, 2019) is 1823 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: October 31, 2019 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 R. Even, Ed. 10 Huawei 11 April 29, 2019 13 SDP-based Data Channel Negotiation 14 draft-ietf-mmusic-data-channel-sdpneg-27 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 October 31, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 12 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", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119] [RFC8174] 184 3. Terminology 186 This document uses the following terms: 188 Data channel: A WebRTC data channel as specified in 189 [I-D.ietf-rtcweb-data-channel]. 191 Data channel stack: An entity which, upon application request, 192 runs the data channel protocol to keep track of states, sending 193 and receiving data. If the application is a browser based 194 JavaScript application then this stack resides in the browser. If 195 the application is a native application then this stack resides in 196 the application and is accessible via some sort of APIs. 198 Data channel properties: Fixed properties assigned to a data 199 channel at the time of its creation. Some of these properties 200 determine the way the data channel stack transmits data on this 201 channel (e.g., stream identifier, reliability, order of delivery, 202 etc.). 204 Data channel subprotocol: The application protocol which is 205 transported over a single data channel. Data channel subprotocol 206 messages are sent as data channel payload over an established data 207 channel. SDP offer/answer exchange can be used as specified in 208 this document to negotiate the establishment of data channels, 209 corresponding data channel properties, associated data channel 210 subprotocols and data channel subprotocol properties. In this 211 case the data channel subprotocols may be identified by the values 212 of the "subprotocol" parameters of the SDP "a=dcmap" attribute as 213 described in Section 5.1.4. Within this document the term "data 214 channel subprotocol" is often abbreviated as just "subprotocol". 216 DCEP: Data Channel Establishment Protocol defined in 217 [I-D.ietf-rtcweb-data-protocol]. 219 In-band: Transmission through the peer-to-peer SCTP association. 221 Out-of-band: Transmission through the application signaling path. 223 Peer: From the perspective of one of the agents in a session, its 224 peer is the other agent. Specifically, from the perspective of 225 the SDP offerer, the peer is the SDP answerer. From the 226 perspective of the SDP answerer, the peer is the SDP offerer. 228 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 229 as specified in [RFC4960]. 231 Stream identifier: The identifier of the outbound and inbound SCTP 232 streams composing a data channel. 234 4. Applicability Statement 236 The mechanism in this document only applies to the Session 237 Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used 238 together with the SDP offer/answer mechanism [RFC3264]. Declarative 239 usage of SDP is out of scope for this document, and is thus 240 undefined. 242 5. SDP Data Channel Attributes 244 This section defines two new SDP media-level attributes that can be 245 used together with the SDP Offer/Answer mechanism to negotiate data 246 channel-specific and subprotocol-specific parameters without the 247 usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute 248 provides for negotiation of channel-specific parameters. The second 249 attribute provides for negotiation of subprotocol-specific 250 parameters. 252 Note: Appendix A provides information how data channels work in 253 general and especially summarizes some key aspects, which should be 254 considered for the negotiation of data channels if DCEP is not used. 256 5.1. SDP DCMAP Attribute 258 This section defines a new media level attribute "a=dcmap:" that 259 defines the data channel parameters for each data channel to be 260 negotiated. 262 The attribute is used to create bi-directional SCTP data channels 263 having the same set of attributes. The data channel properties 264 (reliable/partially reliable, ordered/unordered) need to be suitable 265 per the subprotocol transport requirements. 267 5.1.1. DCMAP Attribute Syntax 269 "a=dcmap:" is a media level attribute having the following ABNF 270 (Augmented Backus-Naur Form, [RFC5234]) syntax. 272 Formal Syntax: 274 Name: dcmap 276 Value: dcmap-value 278 Usage Level: media 280 Charset Dependent: no 282 Syntax: 284 dcmap-value = dcmap-stream-id 285 [ SP dcmap-opt *(";" dcmap-opt) ] 286 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 287 / maxretr-opt / maxtime-opt / priority-opt 288 ; maxretr-opt and maxtime-opt are mutually exclusive 289 ; 291 dcmap-stream-id = 1*5DIGIT 292 ordering-opt = "ordered=" ordering-value 293 ordering-value = "true" / "false" 294 subprotocol-opt = "subprotocol=" quoted-string 295 label-opt = "label=" quoted-string 296 maxretr-opt = "max-retr=" maxretr-value 297 maxretr-value = "0" / integer 298 ; number of retransmissions, 299 ; less than 2^32, 300 ; derived from 'Reliability Parameter' of 301 ; [I-D.ietf-rtcweb-data-protocol] 302 maxtime-opt = "max-time=" maxtime-value 303 maxtime-value = "0" / integer 304 ; milliseconds, 305 ; less than 2^32, 306 ; derived from 'Reliability Parameter' of 307 ; [I-D.ietf-rtcweb-data-protocol] 308 priority-opt = "priority=" priority-value 309 priority-value = "0" / integer 310 ; unsigned integer value indicating the priority of 311 ; the data channel, 312 ; less than 2^16, 313 ; derived from 'Priority' of 314 ; [I-D.ietf-rtcweb-data-protocol] 316 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 317 quoted-char = SP / quoted-visible 318 quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 319 escaped-char = "%" HEXDIG HEXDIG 320 DQUOTE = 321 integer = 323 Examples: 325 a=dcmap:0 326 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 327 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 328 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 329 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 331 Note: The last example (a=dcmap:4) shows a 'label' parameter value 332 which contains one non-printable 'escaped-char' character (the 333 tabulator character). 335 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 336 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be 337 present. Both MUST NOT be present. 339 5.1.2. Dcmap-stream-id Parameter 341 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 342 within the SCTP association used to form the data channel. 344 5.1.3. Label Parameter 346 The 'label' parameter indicates the name of the channel. It 347 represents a label that can be used to distinguish, in the context of 348 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 349 RTCDataChannel objects. This parameter maps to the 'Label' parameter 350 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 351 optional. If it is not present, then its value defaults to the empty 352 string. 354 In order to communicate with WEbRTC API the label attribute should: 356 o Serialize the WebRTC label as a UTF-8 string [RFC3629]. 358 o Treat the UTF-8 serialization as a series of bytes 360 o For each byte in the serialization: 362 * If the byte can be expressed as a `quoted-char`, do so 364 * Otherwise, express the byte as an `escaped-char`. 366 Note: The empty string MAY also be explicitly used as a 'label' 367 value, such that 'label=""' is equivalent to the 'label' parameter 368 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 369 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 371 5.1.4. Subprotocol Parameter 373 The 'subprotocol' parameter indicates which protocol the client 374 expects to exchange via the channel. This parameter maps to the 375 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 376 Section 9.1 specifies how new subprotocol parameter values are 377 registered. 'subprotocol' is an optional parameter. If the 378 'subprotocol' parameter is not present, then its value defaults to an 379 empty string. 381 Note: The empty string MAY also be explicitly used as 'subprotocol' 382 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 383 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 384 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 385 empty string. 387 5.1.5. Max-retr Parameter 389 This parameter indicates that the data channel is partially reliable. 390 The 'max-retr' parameter indicates the maximal number of times a user 391 message will be retransmitted. The max-retr parameter is optional. 392 If the max-retr parameter and the max-time parameter are not present, 393 then reliable transmission is performed as specified in [RFC4960]. 394 This parameter maps to the 'Number of RTX' parameter defined in 395 [I-D.ietf-rtcweb-data-protocol]. 397 5.1.6. Max-time Parameter 399 This parameter indicates that the data channel is partially reliable. 400 A user message will no longer be transmitted or retransmitted after a 401 specified life-time given in milliseconds in the 'max-time' 402 parameter. The life-time starts when providing the user message to 403 the protocol stack. The max-time parameter is optional. If the max- 404 retr parameter and the max-time parameter are not present, then 405 reliable transmission is performed as specified in [RFC4960]. This 406 parameter maps to the 'Lifetime in ms' parameter defined in 407 [I-D.ietf-rtcweb-data-protocol]. 409 5.1.7. Ordered Parameter 411 The 'ordered' parameter with value "true" indicates that the receiver 412 will dispatch DATA chunks in the data channel to the upper layer 413 while preserving the order. The ordered parameter is optional and 414 takes two values: "true" for ordered and "false" for unordered 415 delivery with "true" as the default value. Any other value is 416 ignored and default "ordered=true" is assumed. In the absence of 417 this parameter "ordered=true" is assumed. This parameter maps to the 418 ordered or unordered data channel types as defined in 419 [I-D.ietf-rtcweb-data-protocol]. 421 5.1.8. Priority Parameter 423 The 'priority' parameter indicates the data channel's priority 424 relative to the priorities of other data channels, which may 425 additionally exist over the same SCTP association. The 'priority' 426 parameter maps to the 'Priority' parameter defined in 427 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 428 optional. In the absence of this parameter "priority=256" is 429 assumed. 431 5.1.9. DCMAP Multiplexing Category 433 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the 434 "a=dcmap:" attribute is SPECIAL. 436 As the usage of multiple SCTP associations on top of a single DTLS 437 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 438 "a=dcmap:" attribute multiplexing rules are specified for the 439 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 440 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 441 multiple SCTP associations on top of a single DTLS association, or 442 how to add multiple SCTP associations to one BUNDLE group, then 443 multiplexing rules for the "a=dcmap:" attribute need to be defined as 444 well, for instance in an extension of this SDP offer/answer based 445 data channel negotiation specification. 447 5.2. SDP DCSA Attribute 449 In the SDP media description, each data channel declaration MAY also 450 be followed by other media level SDP attributes, which are either 451 specifically defined for or applied to the subprotocol in use. Each 452 of these attributes is represented by one new attribute line, and it 453 includes the contents of a media-level SDP attribute already defined 454 for use with this (sub)protocol in another IETF document. 455 Subprotocol specific attributes MAY also be defined for exclusive use 456 with data channel transport, but MUST use the same syntax described 457 here for other subprotocol related attributes. 459 Each SDP attribute, related to the subprotocol, that would normally 460 be used to negotiate the subprotocol using SDP offer/answer is 461 replaced with an attribute of the form "a=dcsa:stream-id original- 462 attribute", where dcsa stands for "data channel subprotocol 463 attribute", stream-id is the SCTP stream identifier assigned to this 464 subprotocol instance, and original-attribute represents the contents 465 of the subprotocol related attribute to be included. 467 The same syntax applies to any other SDP attribute required for 468 negotiation of this instance of the subprotocol. 470 The detailed offer/answer procedures for the dcsa attribute are 471 dependent on the associated sub-protocol. If no offer/answer 472 procedures exist for the sub-protocol when used outside of the dcsa 473 attribute, no specification is needed for use with dcsa. The IANA 474 registration procedures for the WebSocket Subprotocol Name Registry 475 (Section 9.1) do not strictly require a specification of the offer/ 476 answer procedures for the sub-protocol when used with dcsa. If the 477 sub-protocol has defined offer/answer procedures when used outside of 478 dcsa, such a specification is encouraged to ensure interoperability. 480 If the sub-protocol has defined offer/answer procedures when used 481 outside of dcsa, but no specification exists for the offer/answer 482 procedures for the sub-protocol when used with dcsa, implementations 483 SHOULD assume the use of the default values for all otherwise- 484 negotiable and applicable sub-protocol parameters. 486 5.2.1. DCSA Syntax 488 Formal Syntax: 490 Name: dcsa 492 Value: dcsa-value 494 Usage Level: media 496 Charset Dependent: no 498 Syntax: 500 dcsa-value = stream-id SP attribute 501 stream-id = 1*5DIGIT 502 attribute = 504 Example: 506 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 508 a=dcsa:2 accept-types:text/plain 510 Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where 511 the attribute definition can be found; it does not provide any 512 limitation on support of attributes defined in other documents in 513 accordance with this attribute definition. Note however that not all 514 SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP 515 parameters contains the lists of IANA (Internet Assigned Numbers 516 Authority) registered session and media level or media level only SDP 517 attributes. 519 Thus in the example above, the original attribute line "a=accept- 520 types:text/plain" is represented by the attribute line "a=dcsa:2 521 accept-types:text/plain", which specifies that this instance of the 522 MSRP subprotocol being transported on the SCTP association using the 523 data channel with stream id 2 accepts plain text files. 525 As opposed to the data channel "a=dcmap:" attribute parameters, these 526 parameters are subject to offer/answer negotiation following the 527 procedures defined in the subprotocol specific documents. 529 It is assumed that in general the usages of subprotocol related media 530 level attributes are independent from the subprotocol's transport 531 protocol. Such transport protocol independent subprotocol related 532 attributes are used in the same way as defined in the original 533 subprotocol specification, also if the subprotocol is transported 534 over a data channel and if the attribute is correspondingly embedded 535 in a "a=dcsa" attribute. 537 There may be cases, where the usage of a subprotocol related media 538 level attribute depends on the subprotocol's transport protocol. In 539 such cases the subprotocol related usage of the attribute is expected 540 to be described for the data channel transport. A data channel 541 specific usage of a subprotocol attribute is expected to be specified 542 in the same document that registers the subprotocol's identifier for 543 data channel usage as described in Section 9.1. 545 SDP attributes that are only defined for use at the dcsa usage level, 546 SHALL use the dcsa usage level when registering the attribute. If 547 existing media attributes are used in a datachannel subprotocol 548 specific way, then a new dcsa usage level MUST be defined for the 549 existing media attribute. Where the SDP attribute is applicable to a 550 particular subprotocol/s this SHALL also be registered by indicating 551 the applicable subprotocol identifiers (see 552 /[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage 553 level. 555 5.2.2. DCSA Multiplexing Category 557 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 559 As the usage of multiple SCTP associations on top of a single DTLS 560 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 561 "a=dcsa:" attribute multiplexing rules are specified for the 562 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 563 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 564 multiple SCTP associations on top of a single DTLS association, or 565 how to add multiple SCTP associations to one BUNDLE group, then 566 multiplexing rules for the "a=dcsa:" attribute need to be defined as 567 well, for instance in an extension of this SDP based data channel 568 negotiation specification. 570 6. SDP Offer/Answer Procedures 572 This section defines how data channels can be negotiated using the 573 SDP offer/answer mechanism. A given media description can describe 574 multiple data channels (each represented by a separate SDP dcmap 575 attribute) that can be created, modified and closed using different 576 offer/answer exchanges. The procedures in this section apply for a 577 given data channel. 579 The generic offer/answer procedures for negotiating the SCTP 580 association used to realize data channels are defined in 581 [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data 582 channel specific procedures. 584 "Initial offer" refers to the offer in which a data channel is 585 opened. It can be the initial offer, or a subsequent offer, of the 586 associated SDP session. 588 The detailed offer/answer procedures for the dcsa attribute are 589 dependent on the associated sub-protocol see Section 5.2. 591 6.1. Managing Stream Identifiers 593 In order to avoid SCTP Stream identifier collisions, in alignment 594 with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS 595 client (for the SCTP association used to realize data channels) MUST 596 use even identifier values, and the endpoint acting as DTLS server 597 MUST use odd identifier values. 599 SCTP stream identifiers associated with data channels that have been 600 negotiated using DCEP MUST NOT be included in SDP offers and answers. 602 6.2. Negotiating Data Channel Parameters 604 The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 605 mapped to the dcmap SDP attribute parameters in the following manner 606 where "ordered=true" is the default and may be omitted: 608 DATA_CHANNEL_RELIABLE 609 ordered=true 611 DATA_CHANNEL_RELIABLE_UNORDERED 612 ordered=false 614 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 615 ordered=true;max-retr= 617 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 618 ordered=false;max-retr= 620 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 621 ordered=true;max-time= 623 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 624 ordered=false;max-time= 626 By definition max-retr and max-time are mutually exclusive, so both 627 MUST NOT be present in the "a=dcmap:" attribute line. If an SDP 628 offer contains both of these parameters then the receiver of such an 629 SDP offer MUST reject the SDP offer. If an SDP answer contains both 630 of these parameters then the offerer MUST treat the associated SDP 631 offer/answer as failed. 633 6.3. Generating the Initial Offer for A Data Channel 635 When an offerer sends an initial offer, in order to negotiate an SCTP 636 stream for a data channel, the offerer: 638 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 639 associated with the data channel in the "m=" section representing 640 the SCTP association used to realize the data channel; and 642 o MAY include one or more SDP dcsa attributes (Section 5.2) 643 associated with the data channel. The value of the stream-id part 644 of each attribute SHALL match the dcmap-stream-id value of the 645 dcmap attribute. 647 6.4. Generating SDP Answer 649 When an answerer receives an offer that includes an "m=" section for 650 an SCTP association, that describes an SCTP stream for a data 651 channel, if the answerer accepts the data channel it: 653 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 654 associated with the data channel in the "m=" section representing 655 the SCTP association used to realize the data channel. The value 656 of the dcmap-stream-id, max-retr and max-time values of the dcmap 657 attribute SHALL be identical to the value used for the data 658 channel in the offer; and 660 o MAY include one or more SDP dcsa attributes (Section 5.2) 661 associated with the data channel. 663 6.5. Offerer Processing of the SDP Answer 665 An offerer receiving an SDP answer performs the following: 667 o SHALL close any created data channels as described in 668 Section 6.6.1 for which the expected "a=dcmap:" attributes are not 669 present in the SDP answer. If the SDP answer has no "a=dcmap" 670 attribute either the peer does not support "a=dcmap:" attributes 671 or it rejected all the data channels. In either case the offerer 672 closes all the SDP offered data channels that were open at the 673 time of offer. The DTLS association and SCTP association will 674 still be setup. At this point the offerer may use DCEP 675 negotiation [I-D.ietf-rtcweb-data-protocol] to open data channels 677 Each agent application MUST wait to send data until it has 678 confirmation that the data channel at the peer is instantiated. For 679 WebRTC, this is when both data channel stacks have channel parameters 680 instantiated. This occurs: 682 o At both peers when a data channel is created without a previously 683 established SCTP association, as soon as the SCTP association is 684 successfully established. 686 o At the agent receiving an SDP offer for which there is an 687 established SCTP association, as soon as it creates the negotiated 688 data channel based on information signaled in the SDP offer. 690 o At the agent sending an SDP offer to create a new data channel for 691 which there is an established SCTP association, when it receives 692 the SDP answer confirming acceptance of the data channel or when 693 it begins to receive data on the data channel from the peer, 694 whichever occurs first. 696 6.6. Modifying the Session 698 When an offer sends a subsequent offer, that includes information for 699 a previously negotiated data channel, unless the offerer intends to 700 close the data channel (Section 6.6.1), the offerer SHALL include the 701 previously negotiated SDP attributes and attribute values associated 702 with the data channel. The answerer may reject the offer. The means 703 for rejecting an offer are dependent on the higher layer protocol. 705 The offer/answer exchange is atomic; if the answer is rejected, the 706 session reverts to the state prior to the offer [RFC3264]. 708 6.6.1. Closing a Data Channel 710 In order to close a data channel, the endpoint that wants to close 711 SHALL send the SCTP SSN reset message [RFC6525], following the 712 procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In 713 addition, if the closed data channel was negotiated using the offer/ 714 answer mechanism Section 6.3, the endpoint that closed the data 715 channel SHALL send a subsequent offer in which it either: 717 o removes the SDP dcmap attribute and SDP dcsa attributes associated 718 with the closed data channel. Once the endpoint receives a 719 successful answer, the SCTP stream identifier value can later be 720 used for a new data channel (negotiated using DCTP or using the 721 offer/answer mechanism); or 723 o after a reset has been performed re-uses the SCTP stream used for 724 the closed data channel for a new data channel, using the 725 procedures in Section 6.3. The offerer SHALL use a different SDP 726 dcmap attribute value for the data channel using the same SCTP 727 stream. 729 6.7. Various SDP Offer/Answer Considerations 731 An SDP offer or answer has no "a=dcmap:" attributes but has 732 "a=dcsa:" attributes. 734 * This is considered an error case. In this case the receiver of 735 such an SDP offer or answer MUST discard this "a=dcsa:" 736 attributes. 738 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 739 attribute is unknown. 741 * The receiver of such an SDP offer or answer SHOULD ignore this 742 entire "a=dcsa" attribute line. 744 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 745 attribute is known, but whose subprotocol attribute semantic is 746 not known for the data channel transport case. 748 * The receiver of such an SDP offer or answer SHOULD ignore this 749 entire "a=dcsa" attribute line. 751 7. Examples 753 SDP offer: 755 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 756 c=IN IP6 2001:db8::3 757 a=max-message-size:100000 758 a=sctp-port:5000 759 a=setup:actpass 760 a=fingerprint:SHA-1 \ 761 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 762 a=tls-id:abc3de65cddef001be82 763 a=dcmap:0 subprotocol="bfcp";label="bfcp" 765 SDP answer: 767 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 768 c=IN IP6 2001:db8::1 769 a=max-message-size:100000 770 a=sctp-port:5002 771 a=setup:passive 772 a=fingerprint:SHA-1 \ 773 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 774 a=tls-id:dcb3ae65cddef0532d42 776 Figure 1: Example 1 778 In the example in Figure 1 the SDP answerer rejected the data channel 779 with stream id 0 either for explicit reasons or because it does not 780 understand the "a=dcmap:" attribute. As a result the offerer will 781 close the data channel created with the SDP offer/answer negotiation 782 option. The SCTP association will still be setup over DTLS. At this 783 point the offerer or the answerer may use DCEP negotiation to open 784 data channels. 786 SDP offer: 788 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 789 c=IN IP4 192.0.2.1 790 a=max-message-size:100000 791 a=sctp-port:5000 792 a=setup:actpass 793 a=fingerprint:SHA-1 \ 794 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 795 a=tls-id:abc3de65cddef001be82 796 a=dcmap:0 subprotocol="bfcp";label="bfcp" 797 a=dcmap:2 subprotocol="msrp";label="msrp" 798 a=dcsa:2 accept-types:message/cpim text/plain 799 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 801 SDP answer: 803 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 804 c=IN IP4 192.0.2.2 805 a=max-message-size:100000 806 a=sctp-port:5002 807 a=setup:passive 808 a=fingerprint:SHA-1 \ 809 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 810 a=tls-id:dcb3ae65cddef0532d42 811 a=dcmap:2 subprotocol="msrp";label="msrp" 812 a=dcsa:2 accept-types:message/cpim text/plain 813 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 815 Figure 2: Example 2 817 In the example in Figure 2 the SDP offer contains data channels for 818 BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 819 answer rejected BFCP and accepted MSRP. So, the offerer closes the 820 data channel for BFCP and both offerer and answerer may start using 821 the MSRP data channel (after the SCTP association is set up). The 822 data channel with stream id 0 is free and can be used for future DCEP 823 or SDP offer/answer negotiation. 825 Continuing the example in Figure 2. 827 Subsequent SDP offer: 829 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 830 c=IN IP4 192.0.2.1 831 a=max-message-size:100000 832 a=sctp-port:5000 833 a=setup:actpass 834 a=fingerprint:SHA-1 \ 835 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 836 a=tls-id:abc3de65cddef001be82 837 a=dcmap:4 subprotocol="msrp";label="msrp" 838 a=dcsa:4 accept-types:message/cpim text/plain 839 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 841 Subsequent SDP answer: 843 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 844 c=IN IP4 192.0.2.2 845 a=max-message-size:100000 846 a=sctp-port:5002 847 a=setup:passive 848 a=fingerprint:SHA-1 \ 849 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 850 a=tls-id:dcb3ae65cddef0532d42 851 a=dcmap:4 subprotocol="msrp";label="msrp" 852 a=dcsa:4 accept-types:message/cpim text/plain 853 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 855 Figure 3: Example 3 857 The example in Figure 3 is a continuation of the example in Figure 2. 858 The SDP offerer now removes the MSRP data channel with stream id 2, 859 but opens a new MSRP data channel with stream id 4. The answerer 860 accepts the entire offer. As a result the offerer closes the earlier 861 negotiated MSRP related data channel and both offerer and answerer 862 may start using new the MSRP related data channel. 864 8. Security Considerations 866 This document specifies new SDP attributes used in the negotiation of 867 the DATA channel parameters. 869 These parameter are negotiated as part of opening a SCTP channel over 870 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol 871 may come with it's own security considerations that need to be 872 documented as part of the subprotocol definition. Otherwise this 873 document does not add any security considerations to the ones 874 specified in [I-D.ietf-mmusic-sctp-sdp] 875 Error cases like the use of unknown parameter values or violation the 876 odd/even rule MUST be handled by closing the corresponding Data 877 Channel. 879 9. IANA Considerations 881 9.1. Subprotocol Identifiers 883 Registration of new subprotocol identifiers is performed using the 884 existing IANA "WebSocket Subprotocol Name Registry" table. 886 The following text should be added following the title of the table. 888 "This table also includes subprotocol identifiers specified for usage 889 within a WebRTC data channel." 891 The following reference should be added to under the heading 892 reference: "RFC XXXX". 894 This document assigns no new values to this table. 896 A subprotocol may simultaneously be defined for data channel 897 transport and for Websocket transport. In such a case the 898 "Subprotocol Definition" and "Reference" cells in the subprotocol's 899 row of the IANA "WebSocket Subprotocol Name Registry" table should 900 contain two entries. One entry in each of these cells should refer 901 to the Websocket related subprotocol specification, and the other 902 entry should refer to the data channel related subprotocol 903 specification. 905 NOTE to RFC Editor: Please replace "XXXX" with the number of this 906 RFC. 908 9.2. New SDP Attributes 910 9.2.1. dcmap 912 NOTE to RFC Editor: Please replace "XXXX" with the number of this 913 RFC. 915 This document defines a new SDP media-level attribute "a=dcmap:" as 916 follows: 918 +-----------------------+-------------------------------------------+ 919 | Contact name: | IESG | 920 | Contact email: | iesg@ietf.org | 921 | Attribute name: | dcmap | 922 | Attribute syntax: | As per Section 5.1.1 | 923 | Attribute semantics: | As per Section 5.1.1 | 924 | Usage level: | media | 925 | Charset dependent: | No | 926 | Purpose: | Define data channel specific parameters | 927 | Appropriate values: | As per Section 5.1.1 | 928 | O/A procedures: | As per Section 6 | 929 | Mux category: | SPECIAL. See Section 5.1.9 | 930 | Reference: | RFCXXXX | 931 +-----------------------+-------------------------------------------+ 933 9.2.2. dcsa 935 NOTE to RFC Editor: Please replace "XXXX" with the number of this 936 RFC. 938 This document defines a new SDP media-level attribute "a=dcsa:" as 939 follows: 941 +-----------------------+-------------------------------------------+ 942 | Contact name: | IESG | 943 | Contact email: | iesg@ietf.org | 944 | Attribute name: | dcsa | 945 | Attribute syntax: | As per Section 5.2.1 | 946 | Attribute semantics: | As per Section 5.2.1 | 947 | Usage level: | media | 948 | Charset dependent: | No | 949 | Purpose: | Define data channel subprotocol specific | 950 | | attributes | 951 | Appropriate values: | As per Section 5.2.1 | 952 | O/A procedures: | As per Section 6 | 953 | Mux category: | SPECIAL. See Section 5.2.2 | 954 | Reference: | RFCXXXX | 955 +-----------------------+-------------------------------------------+ 957 10. Contributors 959 Juergen Stoetzer-Bradler co-authored this document. 961 11. Acknowledgments 963 The authors wish to acknowledge the borrowing of ideas from other 964 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 965 and Gavin Llewellyn, and to thank Flemming Andreasen, Christian 966 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe 967 Rauschenbach and Roman Shpount for their invaluable comments. 969 Special thanks to Christer Holmberg for helping finish the document 970 and cleaning the SDP offer/answer section. 972 12. CHANGE LOG 974 12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 976 o Editorial changes separate sections for offer/answer procedures. 978 o Update security section. 980 12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 982 o Change "dtls-id" to "tls-id" and assign 20 octet long values 984 o Remove of RFC4566bis draft from list of normative references. 986 12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 988 o Modification of Keith's address information. 990 12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 992 o dcmap-stream-id syntax change to limit size to 5 digits. 994 o Add missing 'x' prefix to quoted-visible syntax. 996 o Align SDP offerer and answerer handling when both max-retr and 997 max-time are present. 999 o Use of TEST-NET-1 ip addresses in examples. 1001 o Add missing a=dtls-id in one example. 1003 12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1005 o Removal of the "a=connection" attribute lines from all SDP 1006 examples. 1008 12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1010 o In the introduction: 1012 * Replacement of the sentence "The RTCWeb working group has 1013 defined the concept of bi-directional data channels running on 1014 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1015 Security protocol)" with "The RTCWeb working group has defined 1016 the concept of bi-directional data channels running on top of 1017 the Stream Control Transmission Protocol (SCTP)". 1019 * Addition of following sentences to the second paragraph: "These 1020 procedures are based on generic SDP offer/answer negotiation 1021 rules for SCTP based media transport as specified in 1022 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1023 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1024 could be defined over other SCTP based protocols, such as SCTP 1025 over IP. However, corresponding potential other "m" line proto 1026 values are not considered in this document." 1028 o Replacement of "DTLS connection" with "DTLS association" 1029 throughout the document. 1031 o In sections Section 5.1.9 and Section 5.2.2 removal of the 1032 sentences "This document also does not specify multiplexing rules 1033 for this attribute for SCTP or SCTP/DTLS proto values". 1035 o In the text related to "Subsequent SDP answer" in section 1036 Section 6.7 replacement of "The DTLS/SCTP association remains open 1037 ..." with "The SCTP association remains open ...". 1039 o In the text after the second SDP answer in section Section 7 1040 replacement of "... (after SCTP/DTLS association is setup)" with 1041 "... (after the SCTP association is set up)". 1043 o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative 1044 references. 1046 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1047 examples in Section 7. 1049 12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1051 o Addition of definition of "data channel subprotocol" to Section 3 1052 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1053 archive/web/mmusic/current/msg15827.html. 1055 o Addition of RFC4566bis draft to list of normative references. 1057 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1058 section 8.2.4 of RFC4566bis draft. 1060 o Addition of new "new-usage-level">. 1062 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1064 o Addition of two new paragraphs to Section 5.2.1 regarding 1065 subprotocol attribute relationship with transport protocol. 1067 o Addition of a note to Section 9.1 regarding subprotocols 1068 simultaneously defined for data channel and Websocket usage. 1070 o Addition of two further SDP offer/answer considerations to 1071 Section 6.7 regarding unknown subprotocol attributes and known 1072 subprotocol attributes with unknown data channel transport related 1073 semantic. 1075 12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1077 o Changes addressing Christian Groves's WGLC review comments raised 1078 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1079 msg15357.html and http://www.ietf.org/mail- 1080 archive/web/mmusic/current/msg15359.html. 1082 12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1084 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1085 of contact name and e-mail address with "MMUSIC Chairs" and 1086 "mmusic-chairs@ietf.org". 1088 o In Section 5.2.1 replacement of "Thus in the example above, the 1089 original attribute line "a=accept- types:text/plain" is 1090 represented by the attribute line "a=dcsa:2 accept-types:text/ 1091 plain", which specifies that this instance of MSRP being 1092 transported on the SCTP association using the data channel with 1093 stream id 2 accepts plain text files." with "... which specifies 1094 that this instance of the MSRP subprotocol being transported ...". 1096 o The last paragraph of Section 5.2.1 started with "Note: This 1097 document does not provide a complete specification ...". Removal 1098 of "Note:" and move of this paragraph to the introduction in 1099 Section 1 as last paragraph. 1101 o Section 5.2's headline was "Subprotocol Specific Attributes". 1102 Change of this headline to "Other Media Level Attributes" and 1103 adaptations of the first paragraph of this section and the first 1104 paragraph of Section 5.2.1 in order to clarify that not only those 1105 attributes may be encapsulated in a "dcsa" attribute, which are 1106 specifically defined for the subprotocol, but that also other 1107 attributes may be encapsulated if they are related to the specific 1108 subprotocol instance. 1110 o Move of the last but one paragraph of Section 5.2.1 starting with 1111 "The same syntax applies to ..." right in front of the formal 1112 syntax definition of the "dcsa" attribute. 1114 o Modifications of the text in Section 5.1.9 and Section 5.2.2 in 1115 order not to explicitly restrict usage of the "a=dcmap:" and 1116 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1117 SCTP" or "TCP/DTLS/SCTP". 1119 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1121 o In Section 5.1.4 the first (and only) paragraph was "The 1122 'subprotocol' parameter indicates which protocol the client 1123 expects to exchange via the channel. 'subprotocol' is an optional 1124 parameter. If the 'subprotocol' parameter is not present, then 1125 its value defaults to the empty string." Replacement of this 1126 paragraph with following two paragraphs: 1128 * The 'subprotocol' parameter indicates which protocol the client 1129 expects to exchange via the channel. This parameter maps to 1130 the 'Protocol' parameter defined in 1131 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1132 subprotocol parameter values are registered. 'subprotocol' is 1133 an optional parameter. If the 'subprotocol' parameter is not 1134 present, then its value defaults to the empty string. 1136 * Note: The empty string MAY also be explicitly used as 1137 'subprotocol' value, such that 'subprotocol=""' is equivalent 1138 to the 'subprotocol' parameter not being present at all. 1139 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1140 message's 'subprotocol' value to be an empty string. 1142 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1143 normative references. 1145 o Addition of dcmap attribute specific IANA registration 1146 Section 9.2.1. 1148 o Addition of dcsa attribute specific IANA registration 1149 Section 9.2.2. 1151 o Addition of new Section 5.1.9 describing the mux category of the 1152 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1153 related mux category section are similar to the "Mux Category" 1154 sections of the "a=sctp-port:" and "a=max-message-size:" 1155 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1157 o Addition of new Section 5.2.2 describing the mux category of the 1158 dcsa SDP attribute. 1160 12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1162 o In Section 1 replacement of "RTCWeb leaves it open for other 1163 applications to use data channels and its in-band DCEP or out-of- 1164 band non-DCEP protocols for creating them" with "... to use data 1165 channels and its in-band DCEP or other in-band or out-of-band 1166 protocols for creating them". Additionally replacement of "In 1167 particular, the SDP offer generated by the application includes no 1168 channel-specific information" with "... generated by the RTCweb 1169 data channel stack includes no channel-specific information". 1171 o Move of former section 5 ("Data Channels") to new Appendix A and 1172 removal of JavaScript API specific discussions from this moved 1173 text (like mentioning of data channel stack specific states). 1174 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1175 Section 5. 1177 o In Section 5: 1179 * Relacement of Section 5's first paragraph "This section defines 1180 a method of non-DCEP negotiation by which two clients can 1181 negotiate data channel-specific and subprotocol-specific 1182 parameters, using the out-of-band SDP offer/answer exchange. 1183 This SDP extension can only be used with the SDP offer/answer 1184 model." with "This section defines an SDP extension by which 1185 two clients can negotiate data channel-specific and 1186 subprotocol-specific parameters without using DCEP 1187 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1188 defines usage in the context of SDP offer/answer." 1190 * Addition of new paragraph: "Appendix A provides information how 1191 data channels work in general and especially summarizes some 1192 key aspects, which should be considered for the negotiation of 1193 data channels if DCEP is not used." 1195 o In Section 5.1 replacement of "The intention of exchanging these 1196 attributes is to create data channels on both the peers with the 1197 same set of attributes without actually using the DCEP 1198 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1199 these attributes is to create, on two peers, without use of DCEP 1200 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1201 directed data channels having the same set of attributes". 1203 o In Section 5.1.5 replacement of "The 'max-retr' parameter 1204 indicates the maximal number a user message will be retransmitted" 1205 with "The 'max-retr' parameter indicates the maximal number of 1206 times a user message will be retransmitted". 1208 o In Section 6.1 replacement of "However, an SDP offer/answer 1209 exchange MUST NOT be initiated if the associated SCTP stream is 1210 already negotiated via DCEP" with "However, an SCTP stream MUST 1211 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1212 answer exchange if the associated SCTP stream has already been 1213 negotiated via DCEP". 1215 o In the examples in Section 7 addition of the previously missing 1216 colons to the "a=sctp-port" attribute lines. 1218 12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1220 o Move of reference draft-ietf-rtcweb-jsep from the list of 1221 normative references to the list of informative references. 1222 Remover in -07 since not referenced 1224 o Addition of IANA SDP parameters to the list of informative 1225 references and addition of following two sentences to the first 1226 paragraph after the ABNF definition: "Note however that not all 1227 SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP 1228 parameters contains the lists of IANA registered session and media 1229 level or media level only SDP attributes." 1231 o In the introduction replacement of last sentence "This document 1232 defines SDP-based out-of-band negotiation procedures to establish 1233 data channels for transport of well-defined subprotocols" with 1234 "This document defines SDP offer/answer negotiation procedures to 1235 establish data channels for transport of well-defined 1236 subprotocols, to enable out-of-band negotiation". 1238 o Throughout the document replacement of "external negotiation" with 1239 "SDP offer/answer negotiation" and removal of term "external 1240 negotiation" from the terminology list in Section 3. 1242 o Throughout the document replacement of "internal negotiation" with 1243 "DCEP" and removal of terms "internal negotiation" and "in-band 1244 negotiation" from the terminology list in Section 3. 1246 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1247 terms. 1249 o In Section 6.1 replacement of sentence "However, a single stream 1250 is managed using one method at a time." with "However, an SDP 1251 offer/answer exchange MUST NOT be initiated if the associated SCTP 1252 stream is already negotiated via DCEP". 1254 o In Section 6.2 replacement of sentence "By definition max-retr and 1255 max-time are mutually exclusive, so only one of them can be 1256 present in a=dcmap" with "By definition max-retr and max-time are 1257 mutually exclusive, so aBoth MUST NOT be present in a=dcmap". 1259 o Move of reference [WebRtcAPI] from list of normative references to 1260 list of informative references. 1262 o Removal of almost all text parts, which discussed JavaScript or 1263 other API specific aspects. Such API specific aspects were mainly 1264 discussed in sub-sections of Section 5 and Section 5 of draft- 1265 ietf-mmusic-data-channel-sdpneg-02. 1267 12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1269 o New Section 4 regarding applicability to SDP offer/answer only. 1271 o Addition of new Section 9.1 "Subprotocol identifiers" as 1272 subsection of the "IANA Considerations" related Section 9. Also 1273 removal of the temporary note "To be completed. As [I-D.ietf- 1274 rtcweb-data-protocol] this document should refer to IANA's 1275 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1277 o In Section 6.2: 1279 * In the first paragraph replacement of the sentence "If an SDP 1280 offer contains both of these parameters then such an SDP offer 1281 will be rejected." with "If an SDP offer contains both of these 1282 parameters then the receiver of such an SDP offer MUST reject 1283 the SDP offer." 1285 * In the second paragraph capitalization of "shall" and "may" 1286 such that both sentences now read: "The SDP answer SHALL echo 1287 the same subprotocol, max-retr, max-time, ordered parameters, 1288 if those were present in the offer, and MAY include a label 1289 parameter. They MAY appear in any order, which could be 1290 different from the SDP offer, in the SDP answer." 1292 * In the third paragraph replacement of the sentence "The same 1293 information MUST be replicated without changes in any 1294 subsequent offer or answer, as long as the data channel is 1295 still opened at the time of offer or answer generation." with 1296 "When sending a subsequent offer or an answer, and for as long 1297 as the data channel is still open, the sender MUST replicate 1298 the same information.". 1300 o In Section 6.2 the mapping of data channel types defined in 1301 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1302 parameters were illustrated using example "a=dcmap" attribute 1303 lines. Replacement of these example "a=dcmap" attribute lines 1304 with just the "a=dcmap" attribute parameters being relevant for 1305 the channel type. 1307 o In Section 6.7 the description of bullet point "SDP offer has no 1308 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1309 No data channel negotiated yet." Replacement of this description 1310 with "Initial SDP offer: No data channel is negotiated yet. The 1311 DTLS connection and SCTP association is negotiated and, if agreed, 1312 established as per [I-D.ietf-mmusic-sctp-sdp]." 1314 o In Section 6.7 in both bullet points related to "Subsequent SDP 1315 offer" and "Subsequent SDP answer" replacement of "All the 1316 externally negotiated data channels must be closed now." with "All 1317 the externally negotiated data channels are expected to be closed 1318 now.". 1320 o In Appendix A.2.2's sixth paragraph replacement of the two 1321 occurrences of "must" with "MUST". 1323 o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" 1324 there was a comment saying that "Only maxretr-opt or maxtime-opt 1325 is present. Both MUST NOT be present." Removal of the second 1326 normative sentence and instead addition of following new paragraph 1327 to the end of this section: "Within an 'a=dcmap' attribute line's 1328 'dcmap-opt' value only one 'maxretr-opt' parameter or one 1329 'maxtime-opt' parameter is present. Both MUST NOT be present." 1331 o In Section 5.1.7 replacement of the first sentence "The 'ordered' 1332 parameter with value "true" indicates that DATA chunks in the 1333 channel MUST be dispatched to the upper layer by the receiver 1334 while preserving the order." with "The 'ordered' parameter with 1335 value "true" indicates that the receiver MUST dispatch DATA chunks 1336 in the data channel to the upper layer while preserving the 1337 order.". 1339 o In Section 6.3's first paragraph replacement of the one occurrence 1340 of "must" with "..., it MUST wait until ...". 1342 o In Section 6.6.1: 1344 * In the second paragraph replacement of "must" with "... whether 1345 this closing MUST in addition ..." 1347 * In the third paragraph replacement of the sentence "The port 1348 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1349 when closing a data channel ..." with "The offerer SHOULD NOT 1350 change the port value for the "m" line (e.g., to zero) when 1351 closing a data channel ...". 1353 * In the last but two paragraph replacement of the sentence "... 1354 then an SDP offer which excludes this closed data channel 1355 SHOULD be generated." with "... then the client SHOULD generate 1356 an SDP offer which excludes this closed data channel.". 1358 * In the last but one paragraph replacement of "must" with "The 1359 application MUST also close...". 1361 o In Section 5.2 addition of following note after the formal 1362 definition of the 'a=dcsa' attribute: "Note that the above 1363 reference to RFC 4566 defines were the attribute definition can be 1364 found; it does not provide any limitation on support of attributes 1365 defined in other documents in accordance with this attribute 1366 definition." 1368 12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1370 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1371 channel consisting of paired SCTP outbound and inbound streams." 1372 Replacement of this definition with "Data channel: A WebRTC data 1373 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1374 consistent usage of "data channel" in the remainder of the 1375 document including the document's headline." 1377 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1378 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1379 In particular we expect "webrtc-datachannel" to become a more 1380 general term.' 1382 o Consistent usage of '"m" line' in whole document as per RFC4566. 1384 o In Section 5.1 removal of the example dcmap attribute line 1385 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are 1386 already four examples right after the ABNF rules in Section 5.1.1. 1387 Corresponding removal of following related note: "Note: This 1388 document does not provide a complete specification of how to 1389 negotiate the use of a WebRTC data channel to transport BFCP. 1390 Procedures specific to each subprotocol such as BFCP will be 1391 documented elsewhere. The use of BFCP is only an example of how 1392 the generic procedures described herein might apply to a specific 1393 subprotocol." 1395 o In Section 5.1 removal of following note: "Note: This attribute is 1396 derived from attribute "webrtc-DataChannel", which was defined in 1397 old version 03 of the following draft, but which was removed along 1398 with any support for SDP external negotiation in subsequent 1399 versions: [I-D.ietf-mmusic-sctp-sdp]." 1401 o Insertion of following new sentence to the beginning of 1402 Section 5.1.1: "dcmap is a media level attribute having following 1403 ABNF syntax:" 1405 o Insertion of new Section 5.1.2 containing the dcmap-stream-id 1406 specifying sentence, which previously was placed right before the 1407 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1408 parameter and is noted directly after the "a=dcmap:" attribute's 1409 colon' as this information is part of the ABNF specification. 1411 o In Section 5.1.1 modification of the 'ordering-value' values from 1412 "0" or "1" to "true" or "false". Corresponding text modifications 1413 in Section 5.1.7. 1415 o In Section 5.1.1 the ABNF definition of "quoted-string" referred 1416 to rule name "escaped-char", which was not defined. Instead a 1417 rule with name "escaped" was defined. Renamed that rule's name to 1418 "escaped-char". 1420 o Insertion of a dedicated note right after the "a=dcmap:4" 1421 attribute example in Section 5.1.1 regarding the non-printable 1422 "escaped-char" character within the "label" value. 1424 o In Section 5.2's second paragraph replacement of "sctp stream 1425 identifier" with "SCTP stream identifier". 1427 o In first paragraph of Section 6.1 replacement of first two 1428 sentences 'For the SDP-based external negotiation described in 1429 this document, the initial offerer based "SCTP over DTLS" owns by 1430 convention the even stream identifiers whereas the initial 1431 answerer owns the odd stream identifiers. This ownership is 1432 invariant for the whole lifetime of the signaling session, e.g. it 1433 does not change if the initial answerer sends a new offer to the 1434 initial offerer.' with 'If an SDP offer/answer exchange (could be 1435 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1436 TCP/DTLS/SCTP based media description being accepted, and if this 1437 SDP offer/answer exchange results in the establishment of a new 1438 SCTP association, then the SDP offerer owns the even SCTP stream 1439 ids of this new SCTP association and the answerer owns the odd 1440 SCTP stream identifiers. If this "m" line is removed from the 1441 signaling session (its port number set to zero), and if usage of 1442 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1443 renegotiated later on, then the even and odd SCTP stream 1444 identifier ownership is redetermined as well as described above.' 1446 o In Section 6.3 the first action of an SDP answerer, when receiving 1447 an SDP offer, was described as "Applies the SDP offer. Note that 1448 the browser ignores data channel specific attributes in the SDP." 1449 Replacement of these two sentences with "Parses and applies the 1450 SDP offer. Note that the typical parser normally ignores unknown 1451 SDP attributes, which includes data channel related attributes." 1453 o In Section 6.3 the second sentence of the third SDP answerer 1454 action was "Note that the browser is asked to create data channels 1455 with stream identifiers not "owned" by the agent.". Replacement 1456 of this sentence with "Note that the agent is asked to create data 1457 channels with SCTP stream identifiers contained in the SDP offer 1458 if the SDP offer is accepted." 1460 o In Section 6.6.1 the third paragraph began with "A data channel 1461 can be closed by sending a new SDP offer which excludes the dcmap 1462 and dcsa attribute lines for the data channel. The port value for 1463 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1464 data channel (unless all data channels are being closed and the 1465 SCTP association is no longer needed), since this would close the 1466 SCTP association and impact all of the data channels. If the 1467 answerer accepts the SDP offer then it MUST also exclude the 1468 corresponding attribute lines in the answer. ..." Replacement of 1469 this part with "The intention to close a data channel can be 1470 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1471 and "a=dcsa:" attribute lines for the data channel. The port 1472 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1473 closing a data channel (unless all data channels are being closed 1474 and the SCTP association is no longer needed), since this would 1475 close the SCTP association and impact all of the data channels. 1476 If the answerer accepts the SDP offer then it MUST close those 1477 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1478 excluded from the received SDP offer, unless those data channels 1479 were already closed, and it MUST also exclude the corresponding 1480 attribute lines in the answer." 1482 o In Section 6.6.1 the hanging text after the third paragraph was 1483 "This delayed close is to handle cases where a successful SDP 1484 answer is not received, in which case the state of session should 1485 be kept per the last successful SDP offer/answer." Replacement of 1486 this sentence with "This delayed closure is RECOMMENDED in order 1487 to handle cases where a successful SDP answer is not received, in 1488 which case the state of the session SHOULD be kept per the last 1489 successful SDP offer/answer." 1491 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1492 Section 5.1 contained already procedural descriptions related to 1493 data channel reliability negotiation. Creation of new Section 6.2 1494 and moval of reliability negotiation related text to this new 1495 section. 1497 12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1499 o Removal of note "ACTION ITEM" from section "subprotocol 1500 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1501 should refer to IANA's WebSocket Subprotocol Name Registry defined 1502 in [RFC6455] 1504 o In whole document, replacement of "unreliable" with "partially 1505 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1506 [I-D.ietf-rtcweb-data-protocol] in most places. 1508 o Clarification of the semantic if the "max-retr" parameter is not 1509 present in an "a=dcmap" attribute line. In section "max-retr 1510 parameter" the sentence "The max-retr parameter is optional with 1511 default value unbounded" was replaced with "The max-retr parameter 1512 is optional. If the max-retr parameter is not present, then the 1513 maximal number of retransmissions is determined as per the generic 1514 SCTP retransmission rules as specified in [RFC4960]". 1516 o Clarification of the semantic if the "max-time" parameter is not 1517 present in an "a=dcmap" attribute line. In section "max-time 1518 parameter" the sentence "The max-time parameter is optional with 1519 default value unbounded" was replaced with "The max-time parameter 1520 is optional. If the max-time parameter is not present, then the 1521 generic SCTP retransmission timing rules apply as specified in 1522 [RFC4960]". 1524 o In section "label parameter" the sentence "Label is a mandatory 1525 parameter." was removed and following new sentences (including the 1526 note) were added: "The 'label' parameter is optional. If it is 1527 not present, then its value defaults to the empty string. Note: 1528 The empty string may also be explicitly used as 'label' value, 1529 such that 'label=""' is equivalent to the 'label' parameter not 1530 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1531 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1533 o In section "subprotocol parameter" the sentence "subprotocol is a 1534 mandatory parameter." was replaced with "'subprotocol' is an 1535 optional parameter. If the 'subprotocol' parameter is not 1536 present, then its value defaults to the empty string." 1538 o In the "Examples" section, in the first two SDP offer examples in 1539 the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 1540 'label="bfcp"'. 1542 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1543 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1544 replaced with "a=max-message-size" attribute lines, as per draft- 1545 ietf-mmusic-sctp-sdp-12. 1547 12.17. Changes against '-01' 1549 o Formal syntax for dcmap and dcsa attribute lines. 1551 o Making subprotocol as an optional parameter in dcmap. 1553 o Specifying disallowed parameter combinations for max-time and max- 1554 retr. 1556 o Clarifications on WebRTC data channel close procedures. 1558 12.18. Changes against '-00' 1560 o Revisions to identify difference between internal and external 1561 negotiation and their usage. 1563 o Introduction of more generic terminology, e.g. "application" 1564 instead of "browser". 1566 o Clarification of how "max-retr and max-time affect the usage of 1567 unreliable and reliable WebRTC data channels. 1569 o Updates of examples to take into account the SDP syntax changes 1570 introduced with draft-ietf-mmusic-sctp-sdp-07. 1572 o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" 1573 attributes as this is now contained in the a=sctp-port attribute, 1574 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1575 association on top of the DTLS connection. 1577 13. References 1579 13.1. Normative References 1581 [I-D.ietf-mmusic-rfc4566bis] 1582 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1583 Session Description Protocol", draft-ietf-mmusic- 1584 rfc4566bis-32 (work in progress), December 2018. 1586 [I-D.ietf-mmusic-sctp-sdp] 1587 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1588 "Session Description Protocol (SDP) Offer/Answer 1589 Procedures For Stream Control Transmission Protocol (SCTP) 1590 over Datagram Transport Layer Security (DTLS) Transport.", 1591 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1592 2017. 1594 [I-D.ietf-mmusic-sdp-mux-attributes] 1595 Nandakumar, S., "A Framework for SDP Attributes when 1596 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1597 (work in progress), February 2018. 1599 [I-D.ietf-rtcweb-data-channel] 1600 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1601 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1602 progress), January 2015. 1604 [I-D.ietf-rtcweb-data-protocol] 1605 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1606 Establishment Protocol", draft-ietf-rtcweb-data- 1607 protocol-09 (work in progress), January 2015. 1609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1610 Requirement Levels", BCP 14, RFC 2119, 1611 DOI 10.17487/RFC2119, March 1997, 1612 . 1614 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1615 with Session Description Protocol (SDP)", RFC 3264, 1616 DOI 10.17487/RFC3264, June 2002, 1617 . 1619 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1620 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1621 2003, . 1623 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1624 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1625 . 1627 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1628 Specifications: ABNF", STD 68, RFC 5234, 1629 DOI 10.17487/RFC5234, January 2008, 1630 . 1632 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1633 Transmission Protocol (SCTP) Stream Reconfiguration", 1634 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1635 . 1637 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1638 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1639 May 2017, . 1641 13.2. Informative References 1643 [I-D.ietf-clue-datachannel] 1644 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1645 clue-datachannel-18 (work in progress), April 2019. 1647 [I-D.ietf-mmusic-msrp-usage-data-channel] 1648 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1649 Marcon, J., and J. Recio, "MSRP over Data Channels", 1650 draft-ietf-mmusic-msrp-usage-data-channel-10 (work in 1651 progress), April 2019. 1653 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1654 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1655 November 2006, . 1657 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1658 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1659 DOI 10.17487/RFC4975, September 2007, 1660 . 1662 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1663 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1664 . 1666 [WebRtcAPI] 1667 Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., 1668 Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: 1669 Real-time Communication Between Browsers", World Wide Web 1670 Consortium CR CR-webrtc-20180927, September 2018, 1671 . 1673 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1674 DCEP 1676 This appendix summarizes how data channels work in general and 1677 discusses some key aspects, which should be considered for the out- 1678 of-band negotiation of data channels if DCEP is not used. 1680 A WebRTC application creates a data channel by providing a number of 1681 setup parameters (subprotocol, label, maximal number of 1682 retransmissions, maximal retransmission time, order of delivery, 1683 priority). The application also specifies if it wants to make use of 1684 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1685 the application intends to negotiate data channels using the SDP 1686 offer/answer protocol. 1688 In any case, the SDP offer generated by the application is per 1689 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1690 the SCTP association on top of which data channels will run: 1692 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1693 c=IN IP4 192.0.2.1 1694 a=max-message-size:100000 1695 a=sctp-port:5000 1696 a=tls-id:abc3de65cddef001be82 1697 a=setup:actpass 1698 a=fingerprint:SHA-1 \ 1699 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1701 Note: A WebRTC application will only use "m" line format "webrtc- 1702 datachannel", and will not use other formats in the "m" line for 1703 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1704 only one SCTP association to be established on top of a DTLS 1705 association. 1707 Note: The above SDP media description does not contain any channel- 1708 specific information. 1710 A.1. Stream Identifier Numbering 1712 Independently from the requested type of negotiation, the application 1713 creating a data channel can either pass the stream identifier to the 1714 data channel stack to assign to the data channel or else let the data 1715 channel stack pick one identifier from the unused ones. 1717 To avoid glare situations [RFC3264], each endpoint can moreover own 1718 an exclusive set of stream identifiers, in which case an endpoint can 1719 only create a data channel with a stream identifier it owns. 1721 Which set of stream identifiers is owned by which endpoint is 1722 determined by convention or other means. 1724 Note:For data channels negotiated with the DCEP, one endpoint owns 1725 by convention the even stream identifiers, whereas the other owns 1726 the odd stream identifiers, as defined in 1727 [I-D.ietf-rtcweb-data-protocol]. 1729 Note:For data channels negotiated via different protocol from 1730 DCEP, no convention is defined by default. 1732 A.2. Generic Data Channel Negotiation Not Using DCEP 1734 A.2.1. Overview 1736 DCEP negotiation only provides for negotiation of data channel 1737 transport parameters and does not provide for negotiation of 1738 subprotocol specific parameters. DCEP-less data channel negotiation 1739 can be defined to allow negotiation of parameters beyond those 1740 handled by DCEP, e.g., parameters specific to the subprotocol 1741 instantiated on a particular data channel. 1743 The following procedures are common to all methods of data channel 1744 negotiation not using DCEP, whether in-band (communicated using 1745 proprietary means on an already established data channel) or out-of- 1746 band (using SDP offer/answer or some other protocol associated with 1747 the signaling channel). 1749 A.2.2. Opening a Data Channel 1751 In the case of DCEP-less negotiation, the endpoint application has 1752 the option to fully control the stream identifier assignments. 1753 However these assignments have to coexist with the assignments 1754 controlled by the data channel stack for the DCEP negotiated data 1755 channels (if any). It is the responsibility of the application to 1756 ensure consistent assignment of stream identifiers. 1758 When the application requests the creation of a new data channel to 1759 be set up via DCEP-less negotiation, the data channel stack creates 1760 the data channel locally without sending any DATA_CHANNEL_OPEN 1761 message in-band. However, even if the ICE (Interactive Connectivity 1762 Establishment), DTLS and SCTP procedures were already successfully 1763 completed, the application can't send data on this data channel until 1764 the negotiation is complete with the peer. This is because the peer 1765 needs to be aware of and accept the usage of this data channel. The 1766 peer, after accepting the data channel offer, can start sending data 1767 immediately. This implies that the offerer may receive data channel 1768 subprotocol messages before the negotiation is complete and the 1769 application should be ready to handle it. 1771 If the peer rejects the data channel part of the offer then it 1772 doesn't have to do anything as the data channel was not created using 1773 the stack. The offerer on the other hand needs to close the data 1774 channel that was opened by invoking relevant data channel stack API 1775 procedures. 1777 It is also worth noting that a data channel stack implementation may 1778 not provide any API to create and close data channels; instead the 1779 data channels may be used on the fly as needed just by communicating 1780 via non-DCEP means or by even having some local configuration/ 1781 assumptions on both the peers. 1783 The application then negotiates the data channel properties and 1784 subprotocol properties with the peer's application using a mechanism 1785 different from DCEP. 1787 The peer then symmetrically creates a data channel with these 1788 negotiated data channel properties. This is the only way for the 1789 peer's data channel stack to know which properties to apply when 1790 transmitting data on this channel. The data channel stack must allow 1791 data channel creation with any non-conflicting stream identifier so 1792 that both peers can create the data channel with the same stream 1793 identifier. 1795 A.2.3. Closing a Data Channel 1797 When the application requests the closing of a data channel 1798 negotiated without DCEP, the data channel stack always performs an 1799 SCTP SSN reset for this channel. 1801 Depending upon the method used for DCEP-less negotiation and the 1802 subprotocol associated with the data channel, the closing might in 1803 addition be signaled to the peer via SDP offer/answer negotiation. 1805 Authors' Addresses 1807 Keith Drage 1808 Unaffiliated 1810 Email: drageke@ntlworld.com 1812 Maridi R. Makaraju (Raju) 1813 Nokia 1814 2000 Lucent Lane 1815 Naperville, Illinois 1816 US 1818 Email: Raju.Makaraju@nokia.com 1819 Richard Ejzak 1820 Unaffiliated 1822 Email: richard.ejzak@gmail.com 1824 Jerome Marcon 1825 Unaffiliated 1827 Email: jeromee.marcon@free.fr 1829 Roni Even (editor) 1830 Huawei 1832 Email: roni.even@huawei.com