idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-26.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 23, 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 (-18) exists of draft-ietf-clue-datachannel-17 == 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 (~~), 6 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 25, 2019 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 R. Even, Ed. 10 Huawei 11 April 23, 2019 13 SDP-based Data Channel Negotiation 14 draft-ietf-mmusic-data-channel-sdpneg-26 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 25, 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 of this document, and is thus undefined. 241 5. SDP Data Channel Attributes 243 This section defines two new SDP media-level attributes that can be 244 used together with the SDP Offer/Answer mechanism to negotiate data 245 channel-specific and subprotocol-specific parameters without the 246 usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute 247 provides for negotiation of channel-specific parameters. The second 248 attribute provides for negotiation of subprotocol-specific 249 parameters. 251 Note: Appendix A provides information how data channels work in 252 general and especially summarizes some key aspects, which should be 253 considered for the negotiation of data channels if DCEP is not used. 255 5.1. SDP DCMAP Attribute 257 This section defines a new media level attribute "a=dcmap:" that 258 defines the data channel parameters for each data channel to be 259 negotiated. 261 The attribute is used to create bi-directional SCTP data channels 262 having the same set of attributes. The data channel properties 263 (reliable/partially reliable, ordered/unordered) need to be suitable 264 per the subprotocol transport requirements. 266 5.1.1. DCMAP Attribute Syntax 268 "a=dcmap:" is a media level attribute having the following ABNF 269 (Augmented Backus-Naur Form, [RFC5234]) syntax. 271 Formal Syntax: 273 Name: dcmap 275 Value: dcmap-value 277 Usage Level: media 279 Charset Dependent: no 281 Syntax: 283 dcmap-value = dcmap-stream-id 284 [ SP dcmap-opt *(";" dcmap-opt) ] 285 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 286 / maxretr-opt / maxtime-opt / priority-opt 287 ; maxretr-opt and maxtime-opt are mutually exclusive 288 ; 290 dcmap-stream-id = 1*5DIGIT 291 ordering-opt = "ordered=" ordering-value 292 ordering-value = "true" / "false" 293 subprotocol-opt = "subprotocol=" quoted-string 294 label-opt = "label=" quoted-string 295 maxretr-opt = "max-retr=" maxretr-value 296 maxretr-value = "0" / integer 297 ; number of retransmissions, 298 ; less than 2^32, 299 ; derived from 'Reliability Parameter' of 300 ; [I-D.ietf-rtcweb-data-protocol] 301 maxtime-opt = "max-time=" maxtime-value 302 maxtime-value = "0" / integer 303 ; milliseconds, 304 ; less than 2^32, 305 ; derived from 'Reliability Parameter' of 306 ; [I-D.ietf-rtcweb-data-protocol] 307 priority-opt = "priority=" priority-value 308 priority-value = "0" / integer 309 ; unsigned integer value indicating the priority of 310 ; the data channel, 311 ; less than 2^16, 312 ; derived from 'Priority' of 313 ; [I-D.ietf-rtcweb-data-protocol] 315 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 316 quoted-char = SP / quoted-visible 317 quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 318 escaped-char = "%" HEXDIG HEXDIG 319 DQUOTE = 320 integer = 322 Examples: 324 a=dcmap:0 325 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 326 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 327 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 328 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 330 Note: The last example (a=dcmap:4) shows a 'label' parameter value 331 which contains one non-printable 'escaped-char' character (the 332 tabulator character). 334 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 335 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be 336 present. Both MUST NOT be present. 338 5.1.2. Dcmap-stream-id Parameter 340 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 341 within the SCTP association used to form the data channel. 343 5.1.3. Label Parameter 345 The 'label' parameter indicates the name of the channel. It 346 represents a label that can be used to distinguish, in the context of 347 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 348 RTCDataChannel objects. This parameter maps to the 'Label' parameter 349 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 350 optional. If it is not present, then its value defaults to the empty 351 string. 353 In order to communicate with WEbRTC API the label attribute should: 355 o Serialize the WebRTC label as a UTF-8 string [RFC3629]. 357 o Treat the UTF-8 serialization as a series of bytes 359 o For each byte in the serialization: 361 * If the byte can be expressed as a `quoted-char`, do so 363 * Otherwise, express the byte as an `escaped-char`. 365 Note: The empty string MAY also be explicitly used as a 'label' 366 value, such that 'label=""' is equivalent to the 'label' parameter 367 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 368 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 370 5.1.4. Subprotocol Parameter 372 The 'subprotocol' parameter indicates which protocol the client 373 expects to exchange via the channel. This parameter maps to the 374 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 375 Section 9.1 specifies how new subprotocol parameter values are 376 registered. 'subprotocol' is an optional parameter. If the 377 'subprotocol' parameter is not present, then its value defaults to an 378 empty string. 380 Note: The empty string MAY also be explicitly used as 'subprotocol' 381 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 382 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 383 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 384 empty string. 386 5.1.5. Max-retr Parameter 388 This parameter indicates that the data channel is partially reliable. 389 The 'max-retr' parameter indicates the maximal number of times a user 390 message will be retransmitted. The max-retr parameter is optional. 391 If the max-retr parameter and the max-time parameter are not present, 392 then reliable transmission is performed as specified in [RFC4960]. 393 This parameter maps to the 'Number of RTX' parameter defined in 394 [I-D.ietf-rtcweb-data-protocol]. 396 5.1.6. Max-time Parameter 398 This parameter indicates that the data channel is partially reliable. 399 A user message will no longer be transmitted or retransmitted after a 400 specified life-time given in milliseconds in the 'max-time' 401 parameter. The life-time starts when providing the user message to 402 the protocol stack. The max-time parameter is optional. If the max- 403 retr parameter and the max-time parameter are not present, then 404 reliable transmission is performed as specified in [RFC4960]. This 405 parameter maps to the 'Lifetime in ms' parameter defined in 406 [I-D.ietf-rtcweb-data-protocol]. 408 5.1.7. Ordered Parameter 410 The 'ordered' parameter with value "true" indicates that the receiver 411 will dispatch DATA chunks in the data channel to the upper layer 412 while preserving the order. The ordered parameter is optional and 413 takes two values: "true" for ordered and "false" for unordered 414 delivery with "true" as the default value. Any other value is 415 ignored and default "ordered=true" is assumed. In the absence of 416 this parameter "ordered=true" is assumed. This parameter maps to the 417 ordered or unordered data channel types as defined in 418 [I-D.ietf-rtcweb-data-protocol]. 420 5.1.8. Priority Parameter 422 The 'priority' parameter indicates the data channel's priority 423 relative to the priorities of other data channels, which may 424 additionally exist over the same SCTP association. The 'priority' 425 parameter maps to the 'Priority' parameter defined in 426 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 427 optional. In the absence of this parameter "priority=256" is 428 assumed. 430 5.1.9. DCMAP Multiplexing Category 432 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the 433 "a=dcmap:" attribute is SPECIAL. 435 As the usage of multiple SCTP associations on top of a single DTLS 436 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 437 "a=dcmap:" attribute multiplexing rules are specified for the 438 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 439 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 440 multiple SCTP associations on top of a single DTLS association, or 441 how to add multiple SCTP associations to one BUNDLE group, then 442 multiplexing rules for the "a=dcmap:" attribute need to be defined as 443 well, for instance in an extension of this SDP offer/answer based 444 data channel negotiation specification. 446 5.2. SDP DCSA Attribute 448 In the SDP media description, each data channel declaration MAY also 449 be followed by other media level SDP attributes, which are either 450 specifically defined for or applied to the subprotocol in use. Each 451 of these attributes is represented by one new attribute line, and it 452 includes the contents of a media-level SDP attribute already defined 453 for use with this (sub)protocol in another IETF document. 454 Subprotocol specific attributes MAY also be defined for exclusive use 455 with data channel transport, but MUST use the same syntax described 456 here for other subprotocol related attributes. 458 Each SDP attribute, related to the subprotocol, that would normally 459 be used to negotiate the subprotocol using SDP offer/answer is 460 replaced with an attribute of the form "a=dcsa:stream-id original- 461 attribute", where dcsa stands for "data channel subprotocol 462 attribute", stream-id is the SCTP stream identifier assigned to this 463 subprotocol instance, and original-attribute represents the contents 464 of the subprotocol related attribute to be included. 466 The same syntax applies to any other SDP attribute required for 467 negotiation of this instance of the subprotocol. 469 The detailed offer/answer procedures for the dcsa attribute are 470 dependent on the associated sub-protocol. If no offer/answer 471 procedures exist for the sub-protocol when used outside of the dcsa 472 attribute, no specification is needed for use with dcsa. The IANA 473 registration procedures for the WebSocket Subprotocol Name Registry 474 (Section 9.1) do not strictly require a specification of the offer/ 475 answer procedures for the sub-protocol when used with dcsa. If the 476 sub-protocol has defined offer/answer procedures when used outside of 477 dcsa, such a specification is encouraged to ensure interoperability. 479 If the sub-protocol has defined offer/answer procedures when used 480 outside of dcsa, but no specification exists for the offer/answer 481 procedures for the sub-protocol when used with dcsa, implementations 482 SHOULD assume the use of the default values for all otherwise- 483 negotiable and applicable sub-protocol parameters. 485 5.2.1. DCSA Syntax 487 Formal Syntax: 489 Name: dcsa 491 Value: dcsa-value 493 Usage Level: media 495 Charset Dependent: no 497 Syntax: 499 dcsa-value = stream-id SP attribute 500 stream-id = 1*5DIGIT 501 attribute = 503 Example: 505 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 507 a=dcsa:2 accept-types:text/plain 509 Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where 510 the attribute definition can be found; it does not provide any 511 limitation on support of attributes defined in other documents in 512 accordance with this attribute definition. Note however that not all 513 SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP 514 parameters contains the lists of IANA (Internet Assigned Numbers 515 Authority) registered session and media level or media level only SDP 516 attributes. 518 Thus in the example above, the original attribute line "a=accept- 519 types:text/plain" is represented by the attribute line "a=dcsa:2 520 accept-types:text/plain", which specifies that this instance of the 521 MSRP subprotocol being transported on the SCTP association using the 522 data channel with stream id 2 accepts plain text files. 524 As opposed to the data channel "a=dcmap:" attribute parameters, these 525 parameters are subject to offer/answer negotiation following the 526 procedures defined in the subprotocol specific documents. 528 It is assumed that in general the usages of subprotocol related media 529 level attributes are independent from the subprotocol's transport 530 protocol. Such transport protocol independent subprotocol related 531 attributes are used in the same way as defined in the original 532 subprotocol specification, also if the subprotocol is transported 533 over a data channel and if the attribute is correspondingly embedded 534 in a "a=dcsa" attribute. 536 There may be cases, where the usage of a subprotocol related media 537 level attribute depends on the subprotocol's transport protocol. In 538 such cases the subprotocol related usage of the attribute is expected 539 to be described for the data channel transport. A data channel 540 specific usage of a subprotocol attribute is expected to be specified 541 in the same document that registers the subprotocol's identifier for 542 data channel usage as described in Section 9.1. 544 SDP attributes that are only defined for use at the dcsa usage level, 545 SHALL use the dcsa usage level when registering the attribute. If 546 existing media attributes are used in a datachannel subprotocol 547 specific way, then a new dcsa usage level MUST be defined for the 548 existing media attribute. Where the SDP attribute is applicable to a 549 particular subprotocol/s this SHALL also be registered by indicating 550 the applicable subprotocol identifiers (see 551 /[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage 552 level. 554 5.2.2. DCSA Multiplexing Category 556 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 558 As the usage of multiple SCTP associations on top of a single DTLS 559 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 560 "a=dcsa:" attribute multiplexing rules are specified for the 561 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 562 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 563 multiple SCTP associations on top of a single DTLS association, or 564 how to add multiple SCTP associations to one BUNDLE group, then 565 multiplexing rules for the "a=dcsa:" attribute need to be defined as 566 well, for instance in an extension of this SDP based data channel 567 negotiation specification. 569 6. SDP Offer/Answer Procedures 571 This section defines how data channels can be negotiated using the 572 SDP offer/answer mechanism. A given media description can describe 573 multiple data channels (each represented by a separate SDP dcmap 574 attribute) that can be created, modified and closed using different 575 offer/answer exchanges. The procedures in this section apply for a 576 given data channel. 578 The generic offer/answer procedures for negotiating the SCTP 579 association used to realize data channels are defined in 580 [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data 581 channel specific procedures. 583 "Initial offer" refers to the offer in which a data channel is 584 opened. It can be the initial offer, or a subsequent offer, of the 585 associated SDP session. 587 The detailed offer/answer procedures for the dcsa attribute are 588 dependent on the associated sub-protocol see Section 5.2. 590 6.1. Managing Stream Identifiers 592 In order to avoid SCTP Stream identifier collisions, in alignment 593 with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS 594 client (for the SCTP association used to realize data channels) MUST 595 use even identifier values, and the endpoint acting as DTLS server 596 MUST use odd identifier values. 598 SCTP stream identifiers associated with data channels that have been 599 negotiated using DCEP MUST NOT be included in SDP offers and answers. 601 6.2. Negotiating Data Channel Parameters 603 The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 604 mapped to the dcmap SDP attribute parameters in the following manner 605 where "ordered=true" is the default and may be omitted: 607 DATA_CHANNEL_RELIABLE 608 ordered=true 610 DATA_CHANNEL_RELIABLE_UNORDERED 611 ordered=false 613 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 614 ordered=true;max-retr= 616 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 617 ordered=false;max-retr= 619 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 620 ordered=true;max-time= 622 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 623 ordered=false;max-time= 625 By definition max-retr and max-time are mutually exclusive, so both 626 MUST NOT be present in the "a=dcmap:" attribute line. If an SDP 627 offer contains both of these parameters then the receiver of such an 628 SDP offer MUST reject the SDP offer. If an SDP answer contains both 629 of these parameters then the offerer MUST treat the associated SDP 630 offer/answer failed. 632 6.3. Generating the Initial Offer for A Data Channel 634 When an offerer sends an initial offer, in order to negotiate an SCTP 635 stream for a data channel, the offerer: 637 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 638 associated with the data channel in the "m=" section representing 639 the SCTP association used to realize the data channel; and 641 o MAY include one or more SDP dcsa attributes (Section 5.2) 642 associated with the data channel. The value of the stream-id part 643 of each attribute SHALL match the dcmap-stream-id value of the 644 dcmap attribute. 646 6.4. Generating SDP Answer 648 When an answerer receives an offer that includes an "m=" section for 649 an SCTP association, that describes an SCTP stream for a data 650 channel, if the answerer accepts the data channel it: 652 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 653 associated with the data channel in the "m=" section representing 654 the SCTP association used to realize the data channel. The value 655 of the dcmap-stream-id, max-retr and max-time values of the dcmap 656 attribute SHALL be identical to the value used for the data 657 channel in the offer; and 659 o MAY include one or more SDP dcsa attributes (Section 5.2) 660 associated with the data channel. 662 6.5. Offerer Processing of the SDP Answer 664 An offerer receiving an SDP answer performs the following: 666 o SHALL close any created data channels as described in 667 Section 6.6.1 for which the expected "a=dcmap:" attributes are not 668 present in the SDP answer. If the SDP answer has no "a=dcmap" 669 attribute either the peer does not support "a=dcmap:" attributes 670 or it rejected all the data channels. In either case the offerer 671 closes all the SDP offered data channels that were open at the 672 time of offer. The DTLS association and SCTP association will 673 still be setup. 675 Each agent application MUST wait to send data until it has 676 confirmation that the data channel at the peer is instantiated. For 677 WebRTC, this is when both data channel stacks have channel parameters 678 instantiated. This occurs: 680 o At both peers when a data channel is created without a previously 681 established SCTP association, as soon as the SCTP association is 682 successfully established. 684 o At the agent receiving an SDP offer for which there is an 685 established SCTP association, as soon as it creates the negotiated 686 data channel based on information signaled in the SDP offer. 688 o At the agent sending an SDP offer to create a new data channel for 689 which there is an established SCTP association, when it receives 690 the SDP answer confirming acceptance of the data channel or when 691 it begins to receive data on the data channel from the peer, 692 whichever occurs first. 694 6.6. Modifying the Session 696 When an offer sends a subsequent offer, that includes information for 697 a previously negotiated data channel, unless the offerer intends to 698 close the data channel (Section 6.6.1), the offerer SHALL include the 699 previously negotiated SDP attributes and attribute values associated 700 with the data channel. The answerer may reject the offer. The means 701 for rejecting an offer are dependent on the higher layer protocol. 703 The offer/answer exchange is atomic; if the answer is rejected, the 704 session reverts to the state prior to the offer [RFC3264]. 706 6.6.1. Closing a Data Channel 708 In order to close a data channel, the endpoint that wants to close 709 SHALL send the SCTP SSN reset message [RFC6525], following the 710 procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In 711 addition, if the closed data channel was negotiated using the offer/ 712 answer mechanism Section 6.3, the endpoint that closed the data 713 channel SHALL send a subsequent offer in which it either: 715 o removes the SDP dcmap attribute and SDP dcsa attributes associated 716 with the closed data channel. Once the endpoint receives a 717 successful answer, the SCTP stream identifier value can later be 718 used for a new data channel (negotiated using DCTP or using the 719 offer/answer mechanism); or 721 o after a reset has been performed re-uses the SCTP stream used for 722 the closed data channel for a new data channel, using the 723 procedures in Section 6.3. The offerer SHALL use a different SDP 724 dcmap attribute value for the data channel using the same SCTP 725 stream. 727 6.7. Various SDP Offer/Answer Considerations 729 An SDP offer or answer has no "a=dcmap:" attributes but has 730 "a=dcsa:" attributes. 732 * This is considered an error case. In this case the receiver of 733 such an SDP offer or answer MUST discard this "a=dcsa:" 734 attributes. 736 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 737 attribute is unknown. 739 * The receiver of such an SDP offer or answer SHOULD ignore this 740 entire "a=dcsa" attribute line. 742 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 743 attribute is known, but whose subprotocol attribute semantic is 744 not known for the data channel transport case. 746 * The receiver of such an SDP offer or answer SHOULD ignore this 747 entire "a=dcsa" attribute line. 749 7. Examples 751 SDP offer: 753 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 754 c=IN IP6 2001:db8::3 755 a=max-message-size:100000 756 a=sctp-port:5000 757 a=setup:actpass 758 a=fingerprint:SHA-1 \ 759 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 760 a=tls-id:abc3de65cddef001be82 761 a=dcmap:0 subprotocol="bfcp";label="bfcp" 763 SDP answer: 765 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 766 c=IN IP6 2001:db8::1 767 a=max-message-size:100000 768 a=sctp-port:5002 769 a=setup:passive 770 a=fingerprint:SHA-1 \ 771 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 772 a=tls-id:dcb3ae65cddef0532d42 774 Figure 1: Example 1 776 In the example in Figure 1 the SDP answerer rejected the data channel 777 with stream id 0 either for explicit reasons or because it does not 778 understand the "a=dcmap:" attribute. As a result the offerer will 779 close the data channel created with the SDP offer/answer negotiation 780 option. The SCTP association will still be setup over DTLS. At this 781 point the offerer or the answerer may use DCEP negotiation to open 782 data channels. 784 SDP offer: 786 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 787 c=IN IP4 192.0.2.1 788 a=max-message-size:100000 789 a=sctp-port:5000 790 a=setup:actpass 791 a=fingerprint:SHA-1 \ 792 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 793 a=tls-id:abc3de65cddef001be82 794 a=dcmap:0 subprotocol="bfcp";label="bfcp" 795 a=dcmap:2 subprotocol="msrp";label="msrp" 796 a=dcsa:2 accept-types:message/cpim text/plain 797 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 799 SDP answer: 801 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 802 c=IN IP4 192.0.2.2 803 a=max-message-size:100000 804 a=sctp-port:5002 805 a=setup:passive 806 a=fingerprint:SHA-1 \ 807 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 808 a=tls-id:dcb3ae65cddef0532d42 809 a=dcmap:2 subprotocol="msrp";label="msrp" 810 a=dcsa:2 accept-types:message/cpim text/plain 811 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 813 Figure 2: Example 2 815 In the example in Figure 2 the SDP offer contains data channels for 816 BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 817 answer rejected BFCP and accepted MSRP. So, the offerer closes the 818 data channel for BFCP and both offerer and answerer may start using 819 the MSRP data channel (after the SCTP association is set up). The 820 data channel with stream id 0 is free and can be used for future DCEP 821 or SDP offer/answer negotiation. 823 Continuing the example in Figure 2. 825 Subsequent SDP offer: 827 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 828 c=IN IP4 192.0.2.1 829 a=max-message-size:100000 830 a=sctp-port:5000 831 a=setup:actpass 832 a=fingerprint:SHA-1 \ 833 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 834 a=tls-id:abc3de65cddef001be82 835 a=dcmap:4 subprotocol="msrp";label="msrp" 836 a=dcsa:4 accept-types:message/cpim text/plain 837 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 839 Subsequent SDP answer: 841 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 842 c=IN IP4 192.0.2.2 843 a=max-message-size:100000 844 a=sctp-port:5002 845 a=setup:passive 846 a=fingerprint:SHA-1 \ 847 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 848 a=tls-id:dcb3ae65cddef0532d42 849 a=dcmap:4 subprotocol="msrp";label="msrp" 850 a=dcsa:4 accept-types:message/cpim text/plain 851 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 853 Figure 3: Example 3 855 The example in Figure 3 is a continuation of the example in Figure 2. 856 The SDP offerer now removes the MSRP data channel with stream id 2, 857 but opens a new MSRP data channel with stream id 4. The answerer 858 accepts the entire offer. As a result the offerer closes the earlier 859 negotiated MSRP related data channel and both offerer and answerer 860 may start using new the MSRP related data channel. 862 8. Security Considerations 864 This document specifies new SDP attributes used in the negotiation of 865 the DATA channel parameters. 867 These parameter are negotiated as part of opening a SCTP channel over 868 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol 869 may come with it's own security considerations that need to be 870 documented as part of the subprotocol definition. Otherwise this 871 document does not add any security considerations to the ones 872 specified in [I-D.ietf-mmusic-sctp-sdp] 873 Error cases like the use of unknown parameter values or violation the 874 odd/even rule MUST be handled by closing the corresponding Data 875 Channel. 877 9. IANA Considerations 879 9.1. Subprotocol Identifiers 881 Registration of new subprotocol identifiers is performed using the 882 existing IANA "WebSocket Subprotocol Name Registry" table. 884 The following text should be added following the title of the table. 886 "This table also includes subprotocol identifiers specified for usage 887 within a WebRTC data channel." 889 The following reference should be added to under the heading 890 reference: "RFC XXXX". 892 This document assigns no new values to this table. 894 A subprotocol may simultaneously be defined for data channel 895 transport and for Websocket transport. In such a case the 896 "Subprotocol Definition" and "Reference" cells in the subprotocol's 897 row of the IANA "WebSocket Subprotocol Name Registry" table should 898 contain two entries. One entry in each of these cells should refer 899 to the Websocket related subprotocol specification, and the other 900 entry should refer to the data channel related subprotocol 901 specification. 903 NOTE to RFC Editor: Please replace "XXXX" with the number of this 904 RFC. 906 9.2. New SDP Attributes 908 9.2.1. dcmap 910 NOTE to RFC Editor: Please replace "XXXX" with the number of this 911 RFC. 913 This document defines a new SDP media-level attribute "a=dcmap:" as 914 follows: 916 +-----------------------+-------------------------------------------+ 917 | Contact name: | IESG | 918 | Contact email: | iesg@ietf.org | 919 | Attribute name: | dcmap | 920 | Attribute syntax: | As per Section 5.1.1 | 921 | Attribute semantics: | As per Section 5.1.1 | 922 | Usage level: | media | 923 | Charset dependent: | No | 924 | Purpose: | Define data channel specific parameters | 925 | Appropriate values: | As per Section 5.1.1 | 926 | O/A procedures: | As per Section 6 | 927 | Mux category: | SPECIAL. See Section 5.1.9 | 928 | Reference: | RFCXXXX | 929 +-----------------------+-------------------------------------------+ 931 9.2.2. dcsa 933 NOTE to RFC Editor: Please replace "XXXX" with the number of this 934 RFC. 936 This document defines a new SDP media-level attribute "a=dcsa:" as 937 follows: 939 +-----------------------+-------------------------------------------+ 940 | Contact name: | IESG | 941 | Contact email: | iesg@ietf.org | 942 | Attribute name: | dcsa | 943 | Attribute syntax: | As per Section 5.2.1 | 944 | Attribute semantics: | As per Section 5.2.1 | 945 | Usage level: | media | 946 | Charset dependent: | No | 947 | Purpose: | Define data channel subprotocol specific | 948 | | attributes | 949 | Appropriate values: | As per Section 5.2.1 | 950 | O/A procedures: | As per Section 6 | 951 | Mux category: | SPECIAL. See Section 5.2.2 | 952 | Reference: | RFCXXXX | 953 +-----------------------+-------------------------------------------+ 955 10. Contributors 957 Juergen Stoetzer-Bradler co-authored this document. 959 11. Acknowledgments 961 The authors wish to acknowledge the borrowing of ideas from other 962 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 963 and Gavin Llewellyn, and to thank Flemming Andreasen, Christian 964 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe 965 Rauschenbach and Roman Shpount for their invaluable comments. 967 Special thanks to Christer Holmberg for helping finish the document 968 and cleaning the SDP offer/answer section. 970 12. CHANGE LOG 972 12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 974 o Editorial changes separate sections for offer/answer procedures. 976 o Update security section. 978 12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 980 o Change "dtls-id" to "tls-id" and assign 20 octet long values 982 o Remove of RFC4566bis draft from list of normative references. 984 12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 986 o Modification of Keith's address information. 988 12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 990 o dcmap-stream-id syntax change to limit size to 5 digits. 992 o Add missing 'x' prefix to quoted-visible syntax. 994 o Align SDP offerer and answerer handling when both max-retr and 995 max-time are present. 997 o Use of TEST-NET-1 ip addresses in examples. 999 o Add missing a=dtls-id in one example. 1001 12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1003 o Removal of the "a=connection" attribute lines from all SDP 1004 examples. 1006 12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1008 o In the introduction: 1010 * Replacement of the sentence "The RTCWeb working group has 1011 defined the concept of bi-directional data channels running on 1012 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1013 Security protocol)" with "The RTCWeb working group has defined 1014 the concept of bi-directional data channels running on top of 1015 the Stream Control Transmission Protocol (SCTP)". 1017 * Addition of following sentences to the second paragraph: "These 1018 procedures are based on generic SDP offer/answer negotiation 1019 rules for SCTP based media transport as specified in 1020 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1021 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1022 could be defined over other SCTP based protocols, such as SCTP 1023 over IP. However, corresponding potential other "m" line proto 1024 values are not considered in this document." 1026 o Replacement of "DTLS connection" with "DTLS association" 1027 throughout the document. 1029 o In sections Section 5.1.9 and Section 5.2.2 removal of the 1030 sentences "This document also does not specify multiplexing rules 1031 for this attribute for SCTP or SCTP/DTLS proto values". 1033 o In the text related to "Subsequent SDP answer" in section 1034 Section 6.7 replacement of "The DTLS/SCTP association remains open 1035 ..." with "The SCTP association remains open ...". 1037 o In the text after the second SDP answer in section Section 7 1038 replacement of "... (after SCTP/DTLS association is setup)" with 1039 "... (after the SCTP association is set up)". 1041 o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative 1042 references. 1044 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1045 examples in Section 7. 1047 12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1049 o Addition of definition of "data channel subprotocol" to Section 3 1050 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1051 archive/web/mmusic/current/msg15827.html. 1053 o Addition of RFC4566bis draft to list of normative references. 1055 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1056 section 8.2.4 of RFC4566bis draft. 1058 o Addition of new "new-usage-level">. 1060 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1062 o Addition of two new paragraphs to Section 5.2.1 regarding 1063 subprotocol attribute relationship with transport protocol. 1065 o Addition of a note to Section 9.1 regarding subprotocols 1066 simultaneously defined for data channel and Websocket usage. 1068 o Addition of two further SDP offer/answer considerations to 1069 Section 6.7 regarding unknown subprotocol attributes and known 1070 subprotocol attributes with unknown data channel transport related 1071 semantic. 1073 12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1075 o Changes addressing Christian Groves's WGLC review comments raised 1076 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1077 msg15357.html and http://www.ietf.org/mail- 1078 archive/web/mmusic/current/msg15359.html. 1080 12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1082 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1083 of contact name and e-mail address with "MMUSIC Chairs" and 1084 "mmusic-chairs@ietf.org". 1086 o In Section 5.2.1 replacement of "Thus in the example above, the 1087 original attribute line "a=accept- types:text/plain" is 1088 represented by the attribute line "a=dcsa:2 accept-types:text/ 1089 plain", which specifies that this instance of MSRP being 1090 transported on the SCTP association using the data channel with 1091 stream id 2 accepts plain text files." with "... which specifies 1092 that this instance of the MSRP subprotocol being transported ...". 1094 o The last paragraph of Section 5.2.1 started with "Note: This 1095 document does not provide a complete specification ...". Removal 1096 of "Note:" and move of this paragraph to the introduction in 1097 Section 1 as last paragraph. 1099 o Section 5.2's headline was "Subprotocol Specific Attributes". 1100 Change of this headline to "Other Media Level Attributes" and 1101 adaptations of the first paragraph of this section and the first 1102 paragraph of Section 5.2.1 in order to clarify that not only those 1103 attributes may be encapsulated in a "dcsa" attribute, which are 1104 specifically defined for the subprotocol, but that also other 1105 attributes may be encapsulated if they are related to the specific 1106 subprotocol instance. 1108 o Move of the last but one paragraph of Section 5.2.1 starting with 1109 "The same syntax applies to ..." right in front of the formal 1110 syntax definition of the "dcsa" attribute. 1112 o Modifications of the text in Section 5.1.9 and Section 5.2.2 in 1113 order not to explicitly restrict usage of the "a=dcmap:" and 1114 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1115 SCTP" or "TCP/DTLS/SCTP". 1117 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1119 o In Section 5.1.4 the first (and only) paragraph was "The 1120 'subprotocol' parameter indicates which protocol the client 1121 expects to exchange via the channel. 'subprotocol' is an optional 1122 parameter. If the 'subprotocol' parameter is not present, then 1123 its value defaults to the empty string." Replacement of this 1124 paragraph with following two paragraphs: 1126 * The 'subprotocol' parameter indicates which protocol the client 1127 expects to exchange via the channel. This parameter maps to 1128 the 'Protocol' parameter defined in 1129 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1130 subprotocol parameter values are registered. 'subprotocol' is 1131 an optional parameter. If the 'subprotocol' parameter is not 1132 present, then its value defaults to the empty string. 1134 * Note: The empty string MAY also be explicitly used as 1135 'subprotocol' value, such that 'subprotocol=""' is equivalent 1136 to the 'subprotocol' parameter not being present at all. 1137 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1138 message's 'subprotocol' value to be an empty string. 1140 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1141 normative references. 1143 o Addition of dcmap attribute specific IANA registration 1144 Section 9.2.1. 1146 o Addition of dcsa attribute specific IANA registration 1147 Section 9.2.2. 1149 o Addition of new Section 5.1.9 describing the mux category of the 1150 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1151 related mux category section are similar to the "Mux Category" 1152 sections of the "a=sctp-port:" and "a=max-message-size:" 1153 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1155 o Addition of new Section 5.2.2 describing the mux category of the 1156 dcsa SDP attribute. 1158 12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1160 o In Section 1 replacement of "RTCWeb leaves it open for other 1161 applications to use data channels and its in-band DCEP or out-of- 1162 band non-DCEP protocols for creating them" with "... to use data 1163 channels and its in-band DCEP or other in-band or out-of-band 1164 protocols for creating them". Additionally replacement of "In 1165 particular, the SDP offer generated by the application includes no 1166 channel-specific information" with "... generated by the RTCweb 1167 data channel stack includes no channel-specific information". 1169 o Move of former section 5 ("Data Channels") to new Appendix A and 1170 removal of JavaScript API specific discussions from this moved 1171 text (like mentioning of data channel stack specific states). 1172 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1173 Section 5. 1175 o In Section 5: 1177 * Relacement of Section 5's first paragraph "This section defines 1178 a method of non-DCEP negotiation by which two clients can 1179 negotiate data channel-specific and subprotocol-specific 1180 parameters, using the out-of-band SDP offer/answer exchange. 1181 This SDP extension can only be used with the SDP offer/answer 1182 model." with "This section defines an SDP extension by which 1183 two clients can negotiate data channel-specific and 1184 subprotocol-specific parameters without using DCEP 1185 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1186 defines usage in the context of SDP offer/answer." 1188 * Addition of new paragraph: "Appendix A provides information how 1189 data channels work in general and especially summarizes some 1190 key aspects, which should be considered for the negotiation of 1191 data channels if DCEP is not used." 1193 o In Section 5.1 replacement of "The intention of exchanging these 1194 attributes is to create data channels on both the peers with the 1195 same set of attributes without actually using the DCEP 1196 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1197 these attributes is to create, on two peers, without use of DCEP 1198 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1199 directed data channels having the same set of attributes". 1201 o In Section 5.1.5 replacement of "The 'max-retr' parameter 1202 indicates the maximal number a user message will be retransmitted" 1203 with "The 'max-retr' parameter indicates the maximal number of 1204 times a user message will be retransmitted". 1206 o In Section 6.1 replacement of "However, an SDP offer/answer 1207 exchange MUST NOT be initiated if the associated SCTP stream is 1208 already negotiated via DCEP" with "However, an SCTP stream MUST 1209 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1210 answer exchange if the associated SCTP stream has already been 1211 negotiated via DCEP". 1213 o In the examples in Section 7 addition of the previously missing 1214 colons to the "a=sctp-port" attribute lines. 1216 12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1218 o Move of reference draft-ietf-rtcweb-jsep from the list of 1219 normative references to the list of informative references. 1220 Remover in -07 since not referenced 1222 o Addition of IANA SDP parameters to the list of informative 1223 references and addition of following two sentences to the first 1224 paragraph after the ABNF definition: "Note however that not all 1225 SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP 1226 parameters contains the lists of IANA registered session and media 1227 level or media level only SDP attributes." 1229 o In the introduction replacement of last sentence "This document 1230 defines SDP-based out-of-band negotiation procedures to establish 1231 data channels for transport of well-defined subprotocols" with 1232 "This document defines SDP offer/answer negotiation procedures to 1233 establish data channels for transport of well-defined 1234 subprotocols, to enable out-of-band negotiation". 1236 o Throughout the document replacement of "external negotiation" with 1237 "SDP offer/answer negotiation" and removal of term "external 1238 negotiation" from the terminology list in Section 3. 1240 o Throughout the document replacement of "internal negotiation" with 1241 "DCEP" and removal of terms "internal negotiation" and "in-band 1242 negotiation" from the terminology list in Section 3. 1244 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1245 terms. 1247 o In Section 6.1 replacement of sentence "However, a single stream 1248 is managed using one method at a time." with "However, an SDP 1249 offer/answer exchange MUST NOT be initiated if the associated SCTP 1250 stream is already negotiated via DCEP". 1252 o In Section 6.2 replacement of sentence "By definition max-retr and 1253 max-time are mutually exclusive, so only one of them can be 1254 present in a=dcmap" with "By definition max-retr and max-time are 1255 mutually exclusive, so aBoth MUST NOT be present in a=dcmap". 1257 o Move of reference [WebRtcAPI] from list of normative references to 1258 list of informative references. 1260 o Removal of almost all text parts, which discussed JavaScript or 1261 other API specific aspects. Such API specific aspects were mainly 1262 discussed in sub-sections of Section 5 and Section 5 of draft- 1263 ietf-mmusic-data-channel-sdpneg-02. 1265 12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1267 o New Section 4 regarding applicability to SDP offer/answer only. 1269 o Addition of new Section 9.1 "Subprotocol identifiers" as 1270 subsection of the "IANA Considerations" related Section 9. Also 1271 removal of the temporary note "To be completed. As [I-D.ietf- 1272 rtcweb-data-protocol] this document should refer to IANA's 1273 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1275 o In Section 6.2: 1277 * In the first paragraph replacement of the sentence "If an SDP 1278 offer contains both of these parameters then such an SDP offer 1279 will be rejected." with "If an SDP offer contains both of these 1280 parameters then the receiver of such an SDP offer MUST reject 1281 the SDP offer." 1283 * In the second paragraph capitalization of "shall" and "may" 1284 such that both sentences now read: "The SDP answer SHALL echo 1285 the same subprotocol, max-retr, max-time, ordered parameters, 1286 if those were present in the offer, and MAY include a label 1287 parameter. They MAY appear in any order, which could be 1288 different from the SDP offer, in the SDP answer." 1290 * In the third paragraph replacement of the sentence "The same 1291 information MUST be replicated without changes in any 1292 subsequent offer or answer, as long as the data channel is 1293 still opened at the time of offer or answer generation." with 1294 "When sending a subsequent offer or an answer, and for as long 1295 as the data channel is still open, the sender MUST replicate 1296 the same information.". 1298 o In Section 6.2 the mapping of data channel types defined in 1299 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1300 parameters were illustrated using example "a=dcmap" attribute 1301 lines. Replacement of these example "a=dcmap" attribute lines 1302 with just the "a=dcmap" attribute parameters being relevant for 1303 the channel type. 1305 o In Section 6.7 the description of bullet point "SDP offer has no 1306 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1307 No data channel negotiated yet." Replacement of this description 1308 with "Initial SDP offer: No data channel is negotiated yet. The 1309 DTLS connection and SCTP association is negotiated and, if agreed, 1310 established as per [I-D.ietf-mmusic-sctp-sdp]." 1312 o In Section 6.7 in both bullet points related to "Subsequent SDP 1313 offer" and "Subsequent SDP answer" replacement of "All the 1314 externally negotiated data channels must be closed now." with "All 1315 the externally negotiated data channels are expected to be closed 1316 now.". 1318 o In Appendix A.2.2's sixth paragraph replacement of the two 1319 occurrences of "must" with "MUST". 1321 o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" 1322 there was a comment saying that "Only maxretr-opt or maxtime-opt 1323 is present. Both MUST NOT be present." Removal of the second 1324 normative sentence and instead addition of following new paragraph 1325 to the end of this section: "Within an 'a=dcmap' attribute line's 1326 'dcmap-opt' value only one 'maxretr-opt' parameter or one 1327 'maxtime-opt' parameter is present. Both MUST NOT be present." 1329 o In Section 5.1.7 replacement of the first sentence "The 'ordered' 1330 parameter with value "true" indicates that DATA chunks in the 1331 channel MUST be dispatched to the upper layer by the receiver 1332 while preserving the order." with "The 'ordered' parameter with 1333 value "true" indicates that the receiver MUST dispatch DATA chunks 1334 in the data channel to the upper layer while preserving the 1335 order.". 1337 o In Section 6.3's first paragraph replacement of the one occurrence 1338 of "must" with "..., it MUST wait until ...". 1340 o In Section 6.6.1: 1342 * In the second paragraph replacement of "must" with "... whether 1343 this closing MUST in addition ..." 1345 * In the third paragraph replacement of the sentence "The port 1346 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1347 when closing a data channel ..." with "The offerer SHOULD NOT 1348 change the port value for the "m" line (e.g., to zero) when 1349 closing a data channel ...". 1351 * In the last but two paragraph replacement of the sentence "... 1352 then an SDP offer which excludes this closed data channel 1353 SHOULD be generated." with "... then the client SHOULD generate 1354 an SDP offer which excludes this closed data channel.". 1356 * In the last but one paragraph replacement of "must" with "The 1357 application MUST also close...". 1359 o In Section 5.2 addition of following note after the formal 1360 definition of the 'a=dcsa' attribute: "Note that the above 1361 reference to RFC 4566 defines were the attribute definition can be 1362 found; it does not provide any limitation on support of attributes 1363 defined in other documents in accordance with this attribute 1364 definition." 1366 12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1368 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1369 channel consisting of paired SCTP outbound and inbound streams." 1370 Replacement of this definition with "Data channel: A WebRTC data 1371 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1372 consistent usage of "data channel" in the remainder of the 1373 document including the document's headline." 1375 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1376 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1377 In particular we expect "webrtc-datachannel" to become a more 1378 general term.' 1380 o Consistent usage of '"m" line' in whole document as per RFC4566. 1382 o In Section 5.1 removal of the example dcmap attribute line 1383 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are 1384 already four examples right after the ABNF rules in Section 5.1.1. 1385 Corresponding removal of following related note: "Note: This 1386 document does not provide a complete specification of how to 1387 negotiate the use of a WebRTC data channel to transport BFCP. 1388 Procedures specific to each subprotocol such as BFCP will be 1389 documented elsewhere. The use of BFCP is only an example of how 1390 the generic procedures described herein might apply to a specific 1391 subprotocol." 1393 o In Section 5.1 removal of following note: "Note: This attribute is 1394 derived from attribute "webrtc-DataChannel", which was defined in 1395 old version 03 of the following draft, but which was removed along 1396 with any support for SDP external negotiation in subsequent 1397 versions: [I-D.ietf-mmusic-sctp-sdp]." 1399 o Insertion of following new sentence to the beginning of 1400 Section 5.1.1: "dcmap is a media level attribute having following 1401 ABNF syntax:" 1403 o Insertion of new Section 5.1.2 containing the dcmap-stream-id 1404 specifying sentence, which previously was placed right before the 1405 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1406 parameter and is noted directly after the "a=dcmap:" attribute's 1407 colon' as this information is part of the ABNF specification. 1409 o In Section 5.1.1 modification of the 'ordering-value' values from 1410 "0" or "1" to "true" or "false". Corresponding text modifications 1411 in Section 5.1.7. 1413 o In Section 5.1.1 the ABNF definition of "quoted-string" referred 1414 to rule name "escaped-char", which was not defined. Instead a 1415 rule with name "escaped" was defined. Renamed that rule's name to 1416 "escaped-char". 1418 o Insertion of a dedicated note right after the "a=dcmap:4" 1419 attribute example in Section 5.1.1 regarding the non-printable 1420 "escaped-char" character within the "label" value. 1422 o In Section 5.2's second paragraph replacement of "sctp stream 1423 identifier" with "SCTP stream identifier". 1425 o In first paragraph of Section 6.1 replacement of first two 1426 sentences 'For the SDP-based external negotiation described in 1427 this document, the initial offerer based "SCTP over DTLS" owns by 1428 convention the even stream identifiers whereas the initial 1429 answerer owns the odd stream identifiers. This ownership is 1430 invariant for the whole lifetime of the signaling session, e.g. it 1431 does not change if the initial answerer sends a new offer to the 1432 initial offerer.' with 'If an SDP offer/answer exchange (could be 1433 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1434 TCP/DTLS/SCTP based media description being accepted, and if this 1435 SDP offer/answer exchange results in the establishment of a new 1436 SCTP association, then the SDP offerer owns the even SCTP stream 1437 ids of this new SCTP association and the answerer owns the odd 1438 SCTP stream identifiers. If this "m" line is removed from the 1439 signaling session (its port number set to zero), and if usage of 1440 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1441 renegotiated later on, then the even and odd SCTP stream 1442 identifier ownership is redetermined as well as described above.' 1444 o In Section 6.3 the first action of an SDP answerer, when receiving 1445 an SDP offer, was described as "Applies the SDP offer. Note that 1446 the browser ignores data channel specific attributes in the SDP." 1447 Replacement of these two sentences with "Parses and applies the 1448 SDP offer. Note that the typical parser normally ignores unknown 1449 SDP attributes, which includes data channel related attributes." 1451 o In Section 6.3 the second sentence of the third SDP answerer 1452 action was "Note that the browser is asked to create data channels 1453 with stream identifiers not "owned" by the agent.". Replacement 1454 of this sentence with "Note that the agent is asked to create data 1455 channels with SCTP stream identifiers contained in the SDP offer 1456 if the SDP offer is accepted." 1458 o In Section 6.6.1 the third paragraph began with "A data channel 1459 can be closed by sending a new SDP offer which excludes the dcmap 1460 and dcsa attribute lines for the data channel. The port value for 1461 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1462 data channel (unless all data channels are being closed and the 1463 SCTP association is no longer needed), since this would close the 1464 SCTP association and impact all of the data channels. If the 1465 answerer accepts the SDP offer then it MUST also exclude the 1466 corresponding attribute lines in the answer. ..." Replacement of 1467 this part with "The intention to close a data channel can be 1468 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1469 and "a=dcsa:" attribute lines for the data channel. The port 1470 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1471 closing a data channel (unless all data channels are being closed 1472 and the SCTP association is no longer needed), since this would 1473 close the SCTP association and impact all of the data channels. 1474 If the answerer accepts the SDP offer then it MUST close those 1475 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1476 excluded from the received SDP offer, unless those data channels 1477 were already closed, and it MUST also exclude the corresponding 1478 attribute lines in the answer." 1480 o In Section 6.6.1 the hanging text after the third paragraph was 1481 "This delayed close is to handle cases where a successful SDP 1482 answer is not received, in which case the state of session should 1483 be kept per the last successful SDP offer/answer." Replacement of 1484 this sentence with "This delayed closure is RECOMMENDED in order 1485 to handle cases where a successful SDP answer is not received, in 1486 which case the state of the session SHOULD be kept per the last 1487 successful SDP offer/answer." 1489 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1490 Section 5.1 contained already procedural descriptions related to 1491 data channel reliability negotiation. Creation of new Section 6.2 1492 and moval of reliability negotiation related text to this new 1493 section. 1495 12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1497 o Removal of note "ACTION ITEM" from section "subprotocol 1498 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1499 should refer to IANA's WebSocket Subprotocol Name Registry defined 1500 in [RFC6455] 1502 o In whole document, replacement of "unreliable" with "partially 1503 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1504 [I-D.ietf-rtcweb-data-protocol] in most places. 1506 o Clarification of the semantic if the "max-retr" parameter is not 1507 present in an "a=dcmap" attribute line. In section "max-retr 1508 parameter" the sentence "The max-retr parameter is optional with 1509 default value unbounded" was replaced with "The max-retr parameter 1510 is optional. If the max-retr parameter is not present, then the 1511 maximal number of retransmissions is determined as per the generic 1512 SCTP retransmission rules as specified in [RFC4960]". 1514 o Clarification of the semantic if the "max-time" parameter is not 1515 present in an "a=dcmap" attribute line. In section "max-time 1516 parameter" the sentence "The max-time parameter is optional with 1517 default value unbounded" was replaced with "The max-time parameter 1518 is optional. If the max-time parameter is not present, then the 1519 generic SCTP retransmission timing rules apply as specified in 1520 [RFC4960]". 1522 o In section "label parameter" the sentence "Label is a mandatory 1523 parameter." was removed and following new sentences (including the 1524 note) were added: "The 'label' parameter is optional. If it is 1525 not present, then its value defaults to the empty string. Note: 1526 The empty string may also be explicitly used as 'label' value, 1527 such that 'label=""' is equivalent to the 'label' parameter not 1528 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1529 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1531 o In section "subprotocol parameter" the sentence "subprotocol is a 1532 mandatory parameter." was replaced with "'subprotocol' is an 1533 optional parameter. If the 'subprotocol' parameter is not 1534 present, then its value defaults to the empty string." 1536 o In the "Examples" section, in the first two SDP offer examples in 1537 the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 1538 'label="bfcp"'. 1540 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1541 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1542 replaced with "a=max-message-size" attribute lines, as per draft- 1543 ietf-mmusic-sctp-sdp-12. 1545 12.17. Changes against '-01' 1547 o Formal syntax for dcmap and dcsa attribute lines. 1549 o Making subprotocol as an optional parameter in dcmap. 1551 o Specifying disallowed parameter combinations for max-time and max- 1552 retr. 1554 o Clarifications on WebRTC data channel close procedures. 1556 12.18. Changes against '-00' 1558 o Revisions to identify difference between internal and external 1559 negotiation and their usage. 1561 o Introduction of more generic terminology, e.g. "application" 1562 instead of "browser". 1564 o Clarification of how "max-retr and max-time affect the usage of 1565 unreliable and reliable WebRTC data channels. 1567 o Updates of examples to take into account the SDP syntax changes 1568 introduced with draft-ietf-mmusic-sctp-sdp-07. 1570 o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" 1571 attributes as this is now contained in the a=sctp-port attribute, 1572 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1573 association on top of the DTLS connection. 1575 13. References 1577 13.1. Normative References 1579 [I-D.ietf-mmusic-rfc4566bis] 1580 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1581 Session Description Protocol", draft-ietf-mmusic- 1582 rfc4566bis-32 (work in progress), December 2018. 1584 [I-D.ietf-mmusic-sctp-sdp] 1585 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1586 "Session Description Protocol (SDP) Offer/Answer 1587 Procedures For Stream Control Transmission Protocol (SCTP) 1588 over Datagram Transport Layer Security (DTLS) Transport.", 1589 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1590 2017. 1592 [I-D.ietf-mmusic-sdp-mux-attributes] 1593 Nandakumar, S., "A Framework for SDP Attributes when 1594 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1595 (work in progress), February 2018. 1597 [I-D.ietf-rtcweb-data-channel] 1598 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1599 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1600 progress), January 2015. 1602 [I-D.ietf-rtcweb-data-protocol] 1603 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1604 Establishment Protocol", draft-ietf-rtcweb-data- 1605 protocol-09 (work in progress), January 2015. 1607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1608 Requirement Levels", BCP 14, RFC 2119, 1609 DOI 10.17487/RFC2119, March 1997, 1610 . 1612 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1613 with Session Description Protocol (SDP)", RFC 3264, 1614 DOI 10.17487/RFC3264, June 2002, 1615 . 1617 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1618 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1619 2003, . 1621 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1622 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1623 . 1625 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1626 Specifications: ABNF", STD 68, RFC 5234, 1627 DOI 10.17487/RFC5234, January 2008, 1628 . 1630 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1631 Transmission Protocol (SCTP) Stream Reconfiguration", 1632 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1633 . 1635 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1636 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1637 May 2017, . 1639 13.2. Informative References 1641 [I-D.ietf-clue-datachannel] 1642 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1643 clue-datachannel-17 (work in progress), April 2019. 1645 [I-D.ietf-mmusic-msrp-usage-data-channel] 1646 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1647 Marcon, J., and J. Recio, "MSRP over Data Channels", 1648 draft-ietf-mmusic-msrp-usage-data-channel-10 (work in 1649 progress), April 2019. 1651 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1652 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1653 November 2006, . 1655 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1656 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1657 DOI 10.17487/RFC4975, September 2007, 1658 . 1660 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1661 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1662 . 1664 [WebRtcAPI] 1665 Bergkvist, A., Burnett, D., Jennings, C., and A. 1666 Narayanan, "WebRTC 1.0: Real-time Communication Between 1667 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1668 February 2015, 1669 . 1671 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1672 DCEP 1674 This appendix summarizes how data channels work in general and 1675 discusses some key aspects, which should be considered for the out- 1676 of-band negotiation of data channels if DCEP is not used. 1678 A WebRTC application creates a data channel by providing a number of 1679 setup parameters (subprotocol, label, maximal number of 1680 retransmissions, maximal retransmission time, order of delivery, 1681 priority). The application also specifies if it wants to make use of 1682 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1683 the application intends to negotiate data channels using the SDP 1684 offer/answer protocol. 1686 In any case, the SDP offer generated by the application is per 1687 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1688 the SCTP association on top of which data channels will run: 1690 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1691 c=IN IP4 192.0.2.1 1692 a=max-message-size:100000 1693 a=sctp-port:5000 1694 a=tls-id:abc3de65cddef001be82 1695 a=setup:actpass 1696 a=fingerprint:SHA-1 \ 1697 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1699 Note: A WebRTC application will only use "m" line format "webrtc- 1700 datachannel", and will not use other formats in the "m" line for 1701 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1702 only one SCTP association to be established on top of a DTLS 1703 association. 1705 Note: The above SDP media description does not contain any channel- 1706 specific information. 1708 A.1. Stream Identifier Numbering 1710 Independently from the requested type of negotiation, the application 1711 creating a data channel can either pass the stream identifier to the 1712 data channel stack to assign to the data channel or else let the data 1713 channel stack pick one identifier from the unused ones. 1715 To avoid glare situations, each endpoint can moreover own an 1716 exclusive set of stream identifiers, in which case an endpoint can 1717 only create a data channel with a stream identifier it owns. 1719 Which set of stream identifiers is owned by which endpoint is 1720 determined by convention or other means. 1722 Note:For data channels negotiated with the DCEP, one endpoint owns 1723 by convention the even stream identifiers, whereas the other owns 1724 the odd stream identifiers, as defined in 1725 [I-D.ietf-rtcweb-data-protocol]. 1727 Note:For data channels negotiated via different protocol from 1728 DCEP, no convention is defined by default. 1730 A.2. Generic Data Channel Negotiation Not Using DCEP 1732 A.2.1. Overview 1734 DCEP negotiation only provides for negotiation of data channel 1735 transport parameters and does not provide for negotiation of 1736 subprotocol specific parameters. DCEP-less data channel negotiation 1737 can be defined to allow negotiation of parameters beyond those 1738 handled by DCEP, e.g., parameters specific to the subprotocol 1739 instantiated on a particular data channel. 1741 The following procedures are common to all methods of data channel 1742 negotiation not using DCEP, whether in-band (communicated using 1743 proprietary means on an already established data channel) or out-of- 1744 band (using SDP offer/answer or some other protocol associated with 1745 the signaling channel). 1747 A.2.2. Opening a Data Channel 1749 In the case of DCEP-less negotiation, the endpoint application has 1750 the option to fully control the stream identifier assignments. 1751 However these assignments have to coexist with the assignments 1752 controlled by the data channel stack for the DCEP negotiated data 1753 channels (if any). It is the responsibility of the application to 1754 ensure consistent assignment of stream identifiers. 1756 When the application requests the creation of a new data channel to 1757 be set up via DCEP-less negotiation, the data channel stack creates 1758 the data channel locally without sending any DATA_CHANNEL_OPEN 1759 message in-band. However, even if the ICE (Interactive Connectivity 1760 Establishment), DTLS and SCTP procedures were already successfully 1761 completed, the application can't send data on this data channel until 1762 the negotiation is complete with the peer. This is because the peer 1763 needs to be aware of and accept the usage of this data channel. The 1764 peer, after accepting the data channel offer, can start sending data 1765 immediately. This implies that the offerer may receive data channel 1766 subprotocol messages before the negotiation is complete and the 1767 application should be ready to handle it. 1769 If the peer rejects the data channel part of the offer then it 1770 doesn't have to do anything as the data channel was not created using 1771 the stack. The offerer on the other hand needs to close the data 1772 channel that was opened by invoking relevant data channel stack API 1773 procedures. 1775 It is also worth noting that a data channel stack implementation may 1776 not provide any API to create and close data channels; instead the 1777 data channels may be used on the fly as needed just by communicating 1778 via non-DCEP means or by even having some local configuration/ 1779 assumptions on both the peers. 1781 The application then negotiates the data channel properties and 1782 subprotocol properties with the peer's application using a mechanism 1783 different from DCEP. 1785 The peer then symmetrically creates a data channel with these 1786 negotiated data channel properties. This is the only way for the 1787 peer's data channel stack to know which properties to apply when 1788 transmitting data on this channel. The data channel stack must allow 1789 data channel creation with any non-conflicting stream identifier so 1790 that both peers can create the data channel with the same stream 1791 identifier. 1793 A.2.3. Closing a Data Channel 1795 When the application requests the closing of a data channel 1796 negotiated without DCEP, the data channel stack always performs an 1797 SCTP SSN reset for this channel. 1799 Depending upon the method used for DCEP-less negotiation and the 1800 subprotocol associated with the data channel, the closing might in 1801 addition be signaled to the peer via SDP offer/answer negotiation. 1803 Authors' Addresses 1805 Keith Drage 1806 Unaffiliated 1808 Email: drageke@ntlworld.com 1810 Maridi R. Makaraju (Raju) 1811 Nokia 1812 2000 Lucent Lane 1813 Naperville, Illinois 1814 US 1816 Email: Raju.Makaraju@nokia.com 1817 Richard Ejzak 1818 Unaffiliated 1820 Email: richard.ejzak@gmail.com 1822 Jerome Marcon 1823 Unaffiliated 1825 Email: jeromee.marcon@free.fr 1827 Roni Even (editor) 1828 Huawei 1830 Email: roni.even@huawei.com