idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-24.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 (March 4, 2019) is 1872 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-15 == Outdated reference: A later version (-24) exists of draft-ietf-mmusic-msrp-usage-data-channel-09 -- 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: September 5, 2019 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 R. Even, Ed. 10 Huawei 11 March 4, 2019 13 SDP-based Data Channel Negotiation 14 draft-ietf-mmusic-data-channel-sdpneg-24 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 September 5, 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 . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . 9 73 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 74 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . 14 82 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 83 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15 84 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 85 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19 89 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 90 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19 91 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 12.1. Changes against 'draft-ietf-mmusic-data-channel- 97 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21 98 12.2. Changes against 'draft-ietf-mmusic-data-channel- 99 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21 100 12.3. Changes against 'draft-ietf-mmusic-data-channel- 101 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21 102 12.4. Changes against 'draft-ietf-mmusic-data-channel- 103 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21 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' . . . . . . . . . . . . . . . . . . . . . . . 23 112 12.9. Changes against 'draft-ietf-mmusic-data-channel- 113 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23 114 12.10. Changes against 'draft-ietf-mmusic-data-channel- 115 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23 116 12.11. Changes against 'draft-ietf-mmusic-data-channel- 117 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24 118 12.12. Changes against 'draft-ietf-mmusic-data-channel- 119 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25 120 12.13. Changes against 'draft-ietf-mmusic-data-channel- 121 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26 122 12.14. Changes against 'draft-ietf-mmusic-data-channel- 123 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27 124 12.15. Changes against 'draft-ietf-mmusic-data-channel- 125 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29 126 12.16. Changes against 'draft-ejzak-mmusic-data-channel- 127 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32 128 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33 129 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 132 13.2. Informative References . . . . . . . . . . . . . . . . . 35 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 . . . . . 37 137 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 138 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 139 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 142 1. Introduction 144 The concept of establishing a bi-directional data channels 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 prtocols 153 like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled 154 by the data channel "subprotocol" parameter, conceptually similar to 155 the WebSocket [RFC5234] "subprotocol". However, apart from the 156 "subprotocol" value transmitted to the peer, an endpoint applications 157 can agree on how to instantiate a given subprotocol on a data 158 channel, and whether it is signaled in-band using DCEP or out-of-band 159 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 202 delivery...). 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 sections 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 ; Only maxretr-opt or maxtime-opt 288 ; is present. 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 Note: The empty string MAY also be explicitly used as a 'label' 354 value, such that 'label=""' is equivalent to the 'label' parameter 355 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 356 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 358 5.1.4. Subprotocol Parameter 360 The 'subprotocol' parameter indicates which protocol the client 361 expects to exchange via the channel. This parameter maps to the 362 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 363 Section 9.1 specifies how new subprotocol parameter values are 364 registered. 'Subprotocol' is an optional parameter. If the 365 'subprotocol' parameter is not present, then its value defaults to an 366 empty string. 368 Note: The empty string MAY also be explicitly used as 'subprotocol' 369 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 370 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 371 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 372 empty string. 374 5.1.5. Max-retr Parameter 376 This parameter indicates that the data channel is partially reliable. 377 The 'max-retr' parameter indicates the maximal number of times a user 378 message will be retransmitted. The max-retr parameter is optional. 379 If the max-retr parameter is not present, then the maximal number of 380 retransmissions is determined as per the generic SCTP retransmission 381 rules as specified in [RFC4960]. This parameter maps to the 'Number 382 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 384 5.1.6. Max-time Parameter 386 This parameter indicates that the data channel is partially reliable. 387 A user message will no longer be transmitted or retransmitted after a 388 specified life-time given in milliseconds in the 'max-time' 389 parameter. The max-time parameter is optional. If the max-time 390 parameter is not present, then the generic SCTP retransmission timing 391 rules apply as specified in [RFC4960]. This parameter maps to the 392 'Lifetime in ms' parameter defined in 393 [I-D.ietf-rtcweb-data-protocol]. 395 5.1.7. Ordered Parameter 397 The 'ordered' parameter with value "true" indicates that the receiver 398 will dispatch DATA chunks in the data channel to the upper layer 399 while preserving the order. The ordered parameter is optional and 400 takes two values: "true" for ordered and "false" for unordered 401 delivery with "true" as the default value. Any other value is 402 ignored and default "ordered=true" is assumed. In the absence of 403 this parameter "ordered=true" is assumed. This parameter maps to the 404 ordered or unordered data channel types as defined in 405 [I-D.ietf-rtcweb-data-protocol]. 407 5.1.8. Priority Parameter 409 The 'priority' parameter indicates the data channel's priority 410 relative to the priorities of other data channels, which may 411 additionally exist over the same SCTP association. The 'priority' 412 parameter maps to the 'Priority' parameter defined in 413 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 414 optional. In the absence of this parameter "priority=256" is 415 assumed. 417 5.1.9. DCMAP Multiplexing Category 419 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the 420 "a=dcmap:" attribute is SPECIAL. 422 As the usage of multiple SCTP associations on top of a single DTLS 423 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 424 "a=dcmap:" attribute multiplexing rules are specified for the 425 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 426 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 427 multiple SCTP associations on top of a single DTLS association, or 428 how to add multiple SCTP associations to one BUNDLE group, then 429 multiplexing rules for the "a=dcmap:" attribute need to be defined as 430 well, for instance in an extension of this SDP offer/answer based 431 data channel negotiation specification. 433 5.2. SDP DCSA Attribute 435 In the SDP media description, each data channel declaration MAY also 436 be followed by other media level SDP attributes, which are either 437 specifically defined for or applied to the subprotocol in use. Each 438 of these attributes is represented by one new attribute line, and it 439 includes the contents of a media-level SDP attribute already defined 440 for use with this (sub)protocol in another IETF (Internet Engineering 441 Task Force) document. Subprotocol specific attributes MAY also be 442 defined for exclusive use with data channel transport, but MUST use 443 the same syntax described here for other subprotocol related 444 attributes. 446 Each SDP attribute, related to the subprotocol, that would normally 447 be used to negotiate the subprotocol using SDP offer/answer is 448 replaced with an attribute of the form "a=dcsa:stream-id original- 449 attribute", where dcsa stands for "data channel subprotocol 450 attribute", stream-id is the SCTP stream identifier assigned to this 451 subprotocol instance, and original-attribute represents the contents 452 of the subprotocol related attribute to be included. 454 The same syntax applies to any other SDP attribute required for 455 negotiation of this instance of the subprotocol. 457 The detailed offer/answer procedures for the dcsa attribute are 458 dependent on the associated sub-protocol. If no offer/answer 459 procedures exist for the sub-protocol when used outside of the dcsa 460 attribute, no specification is needed for use with dcsa. The IANA 461 registration procedures for the WebSocket Subprotocol Name Registry 462 (Section 9.1) do not strictly require a specification of the offer/ 463 answer procedures for the sub-protocol when used with dcsa. If the 464 sub-protocol has defined offer/answer procedures when used outside of 465 dcsa, such a specification is encouraged to ensure interoperability. 466 If the sub-protocol has defined offer/answer procedures when used 467 outside of dcsa, but no specification exists for the offer/answer 468 procedures for the sub-protocol when used with dcsa, implementations 469 SHOULD assume the use of the default values for all otherwise- 470 negotiable and applicable sub-protocol parameters. 472 5.2.1. DCSA Syntax 473 Formal Syntax: 475 Name: dcsa 477 Value: dcsa-value 479 Usage Level: media 481 Charset Dependent: no 483 Syntax: 485 dcsa-value = stream-id SP attribute 486 attribute = 488 Example: 490 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" 492 a=dcsa:2 accept-types:text/plain 494 Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where 495 the attribute definition can be found; it does not provide any 496 limitation on support of attributes defined in other documents in 497 accordance with this attribute definition. Note however that not all 498 SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP 499 parameters contains the lists of IANA (Internet Assigned Numbers 500 Authority) registered session and media level or media level only SDP 501 attributes. 503 Thus in the example above, the original attribute line "a=accept- 504 types:text/plain" is represented by the attribute line "a=dcsa:2 505 accept-types:text/plain", which specifies that this instance of the 506 MSRP subprotocol being transported on the SCTP association using the 507 data channel with stream id 2 accepts plain text files. 509 As opposed to the data channel "a=dcmap:" attribute parameters, these 510 parameters are subject to offer/answer negotiation following the 511 procedures defined in the subprotocol specific documents. 513 It is assumed that in general the usages of subprotocol related media 514 level attributes are independent from the subprotocol's transport 515 protocol. Such transport protocol independent subprotocol related 516 attributes are used in the same way as defined in the original 517 subprotocol specification, also if the subprotocol is transported 518 over a data channel and if the attribute is correspondingly embedded 519 in a "a=dcsa" attribute. 521 There may be cases, where the usage of a subprotocol related media 522 level attribute depends on the subprotocol's transport protocol. In 523 such cases the subprotocol related usage of the attribute is expected 524 to be described for the data channel transport. A data channel 525 specific usage of a subprotocol attribute is expected to be specified 526 in the same document that registers the subprotocol's identifier for 527 data channel usage as described in Section 9.1. 529 5.2.2. DCSA Multiplexing Category 531 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 533 As the usage of multiple SCTP associations on top of a single DTLS 534 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 535 "a=dcsa:" attribute multiplexing rules are specified for the 536 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 537 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 538 multiple SCTP associations on top of a single DTLS association, or 539 how to add multiple SCTP associations to one BUNDLE group, then 540 multiplexing rules for the "a=dcsa:" attribute need to be defined as 541 well, for instance in an extension of this SDP based data channel 542 negotiation specification. 544 6. SDP Offer/Answer Procedures 546 This section defines how data channels can be negotiated using the 547 SDP offer/answer mechanism. A given media description can describe 548 multiple data channels (each represented by a separate SDP dcmap 549 attribute) that can be created, modified and closed using different 550 offer/answer exchanges. The procedures in this section apply for a 551 given data channel. 553 The generic offer/answer procedures for negotiating the SCTP 554 association used to realize data channels are defined in 555 [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data 556 channel specific procedures. 558 "Initial offer" refers to the offer in which a data channel is 559 opened. It can be the initial offer, or a subsequent offer, of the 560 associated SDP session. 562 The detailed offer/answer procedures for the dcsa attribute are 563 dependent on the associated sub-protocol see Section 5.2. 565 6.1. Managing Stream Identifiers 567 In order to avoid SCTP Stream identifier collisions, in alignment 568 with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS 569 client (for the SCTP association used to realize data channels) MUST 570 use even identifier values, and the endpoint acting as DTLS server 571 MUST use odd identifier values. SCTP stream identifiers associated 572 with data channels that have been negotiated using DCEP MUST NOT be 573 included in SDP offers and answers. 575 SCTP stream identifiers associated with data channels that have been 576 negotiated using DCEP MUST NOT be included in SDP offers and answers. 578 6.2. Negotiating Data Channel Parameters 580 The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 581 mapped to the dcmap SDP attribute parameters in the following manner 582 where "ordered=true" is the default and may be omitted: 584 DATA_CHANNEL_RELIABLE 585 ordered=true 587 DATA_CHANNEL_RELIABLE_UNORDERED 588 ordered=false 590 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 591 ordered=true;max-retr= 593 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 594 ordered=false;max-retr= 596 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 597 ordered=true;max-time= 599 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 600 ordered=false;max-time= 602 By definition max-retr and max-time are mutually exclusive, so Both 603 MUST NOT be present in the "a=dcmap:" attribute line. If a SDP offer 604 contains both of these parameters then the receiver of such an SDP 605 offer MUST reject the SDP offer. If a SDP answer contains both of 606 these parameters then the offerer MUST treat the associated SDP 607 offer/answer failed. 609 6.3. Generating the Initial Offer for A Data Channel 611 When an offerer sends an initial offer, in order to negotiate an SCTP 612 stream for a data channel, the offerer: 614 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 615 associated with the data channel in the "m=" section representing 616 the SCTP association used to realize the data channel; and 618 o MAY include one or more SDP dcsa attributes (Section 5.2) 619 associated with the data channel. The value of the stream-id part 620 of each attribute SHALL match the dcmap-stream-id value of the 621 dcmap attribute. 623 6.4. Generating SDP Answer 625 When an answerer receives an offer that includes an "m=" section for 626 an SCTP association, that describes an SCTP stream for a data 627 channel, if the answerer accepts the data channel it: 629 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 630 associated with the data channel in the "m=" section representing 631 the SCTP association used to realize the data channel. The value 632 of the dcmap-stream-id, max-retr and max-time values of the dcmap 633 attribute SHALL be identical to the value used for the data 634 channel in the offer; and 636 o MAY include one or more SDP dcsa attributes (Section 5.2) 637 associated with the data channel. 639 6.5. Offerer Processing of the SDP Answer 641 An offerer receiving a SDP answer performs the following: 643 o SHALL close any created data channels as described in 644 Section 6.6.1 for which the expected "a=dcmap:" attributes are not 645 present in the SDP answer. If the SDP answer has no "a=dcmap" 646 attribute either the peer does not support "a=dcmap:" attributes 647 or it rejected all the data channels. In either case the offerer 648 closes all the SDP offered data channels that were open at the 649 time of offer. The DTLS association and SCTP association will 650 still be setup. 652 Each agent application MUST wait to send data until it has 653 confirmation that the data channel at the peer is instantiated. For 654 WebRTC, this is when both data channel stacks have channel parameters 655 instantiated. This occurs: 657 o At both peers when a data channel is created without a previously 658 established SCTP association, as soon as the SCTP association is 659 successfully established. 661 o At the agent receiving an SDP offer for which there is an 662 established SCTP association, as soon as it creates the negotiated 663 data channel based on information signaled in the SDP offer. 665 o At the agent sending an SDP offer to create a new data channel for 666 which there is an established SCTP association, when it receives 667 the SDP answer confirming acceptance of the data channel or when 668 it begins to receive data on the data channel from the peer, 669 whichever occurs first. 671 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 672 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 674 6.6. Modifying the Session 676 When an offer sends a subsequent offer, that includes information for 677 a previously negotiated data channel, unless the offerer intends to 678 close the data channel (Section 6.6.1), the offerer SHALL include the 679 previously negotiated SDP attributes and attribute values associated 680 with the data channel. 682 6.6.1. Closing a Data Channel 684 In order to close a data channel, the endpoint that wants to close 685 SHALL send the SCTP SSN reset message [RFC6525], following the 686 procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In 687 addition, if the closed data channel was negotiated using the offer/ 688 answer mechanism Section 6.3, the endpoint that closed the data 689 channel SHALL send a subsequent offer in which it either: 691 o removes the SDP dcmap attribute and SDP dcsa attributes associated 692 with the closed data channel. Once the endpoint receives a 693 successful answer, the SCTP stream identifier value can later be 694 used for a new data channel (negotiated using DCTP or using the 695 offer/answer mechanism); or 697 o immediately re-uses the SCTP stream used for the closed data 698 channel for a new data channel, using the procedures in 699 Section 6.3. The offerer SHALL use a different SDP dcmap 700 attribute value for the data channel using the same SCTP stream. 702 6.7. Various SDP Offer/Answer Considerations 704 An SDP offer or answer has no "a=dcmap:" attributes but has 705 "a=dcsa:" attributes. 707 * This is considered an error case. In this case the receiver of 708 such an SDP offer or answer MUST discard this "a=dcsa:" 709 attributes. 711 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 712 attribute is unknown. 714 * The receiver of such an SDP offer or answer SHOULD ignore this 715 entire "a=dcsa" attribute line. 717 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 718 attribute is known, but whose subprotocol attribute semantic is 719 not known for the data channel transport case. 721 * The receiver of such an SDP offer or answer SHOULD ignore this 722 entire "a=dcsa" attribute line. 724 7. Examples 726 SDP offer: 728 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 729 c=IN IP6 IP6 2001:db8::3 730 a=max-message-size:100000 731 a=sctp-port:5000 732 a=setup:actpass 733 a=fingerprint:SHA-1 \ 734 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 735 a=tls-id:abc3de65cddef001be82 736 a=dcmap:0 subprotocol="bfcp";label="bfcp" 738 SDP answer: 740 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 741 c=IN IP6 IP6 2001:db8::1 742 a=max-message-size:100000 743 a=sctp-port:5002 744 a=setup:passive 745 a=fingerprint:SHA-1 \ 746 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 747 a=tls-id:dcb3ae65cddef0532d42 749 Figure 1: Example 1 751 In the example in Figure 1 the SDP answerer rejected the data channel 752 with stream id 0 either for explicit reasons or because it does not 753 understand the "a=dcmap:" attribute. As a result the offerer will 754 close the data channel created with the SDP offer/answer negotiation 755 option. The SCTP association will still be setup over DTLS. At this 756 point the offerer or the answerer may use DCEP negotiation to open 757 data channels. 759 SDP offer: 761 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 762 c=IN IP4 192.0.2.1 763 a=max-message-size:100000 764 a=sctp-port:5000 765 a=setup:actpass 766 a=fingerprint:SHA-1 \ 767 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 768 a=tls-id:abc3de65cddef001be82 769 a=dcmap:0 subprotocol="bfcp";label="bfcp" 770 a=dcmap:2 subprotocol="msrp";label="msrp" 771 a=dcsa:2 accept-types:message/cpim text/plain 772 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 774 SDP answer: 776 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 777 c=IN IP4 192.0.2.2 778 a=max-message-size:100000 779 a=sctp-port:5002 780 a=setup:passive 781 a=fingerprint:SHA-1 \ 782 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 783 a=tls-id:dcb3ae65cddef0532d42 784 a=dcmap:2 subprotocol="msrp";label="msrp" 785 a=dcsa:2 accept-types:message/cpim text/plain 786 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 788 Figure 2: Example 2 790 In the example in Figure 2 the SDP offer contains data channels for 791 BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 792 answer rejected BFCP and accepted MSRP. So, the offerer closes the 793 data channel for BFCP and both offerer and answerer may start using 794 the MSRP data channel (after the SCTP association is set up). The 795 data channel with stream id 0 is free and can be used for future DCEP 796 or SDP offer/answer negotiation. 798 Continuing the example in Figure 2. 800 Subsequent SDP offer: 802 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 803 c=IN IP4 192.0.2.1 804 a=max-message-size:100000 805 a=sctp-port:5000 806 a=setup:actpass 807 a=fingerprint:SHA-1 \ 808 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 809 a=tls-id:abc3de65cddef001be82 810 a=dcmap:4 subprotocol="msrp";label="msrp" 811 a=dcsa:4 accept-types:message/cpim text/plain 812 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 814 Subsequent SDP answer: 816 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 817 c=IN IP4 192.0.2.2 818 a=max-message-size:100000 819 a=sctp-port:5002 820 a=setup:passive 821 a=fingerprint:SHA-1 \ 822 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 823 a=tls-id:dcb3ae65cddef0532d42 824 a=dcmap:4 subprotocol="msrp";label="msrp" 825 a=dcsa:4 accept-types:message/cpim text/plain 826 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 828 Figure 3: Example 3 830 The example in Figure 3 is a continuation of the example in Figure 2. 831 The SDP offerer now removes the MSRP data channel with stream id 2, 832 but opens a new MSRP data channel with stream id 4. The answerer 833 accepts the entire offer. As a result the offerer closes the earlier 834 negotiated MSRP related data channel and both offerer and answerer 835 may start using new the MSRP related data channel. 837 8. Security Considerations 839 This document specifies new SDP attributes used in the negotiation of 840 the DATA channel parameters. 842 These parameter are negotiated as part of opening a SCTP channel over 843 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol 844 may come with it's own security considerations that need to be 845 documented as part of the subprotocol definition. Otherwise this 846 document do not add any security considerations to the ones specified 847 in [I-D.ietf-mmusic-sctp-sdp] 848 Error cases like the use of unknown parameter values or violation the 849 odd/even rule must be handled by closing the corresponding Data 850 Channel. 852 9. IANA Considerations 854 9.1. Subprotocol Identifiers 856 Registration of new subprotocol identifiers is performed using the 857 existing IANA "WebSocket Subprotocol Name Registry" table. 859 The following text should be added following the title of the table. 861 "This table also includes subprotocol identifiers specified for usage 862 within a WebRTC data channel." 864 The following reference should be added to under the heading 865 reference: "RFC XXXX". 867 This document assigns no new values to this table. 869 A subprotocol may simultaneously be defined for data channel 870 transport and for Websocket transport. In such a case the 871 "Subprotocol Definition" and "Reference" cells in the subprotocol's 872 row of the IANA "WebSocket Subprotocol Name Registry" table should 873 contain two entries. One entry in each of these cells should refer 874 to the Websocket related subprotocol specification, and the other 875 entry should refer to the data channel related subprotocol 876 specification. 878 NOTE to RFC Editor: Please replace "XXXX" with the number of this 879 RFC. 881 9.2. New SDP Attributes 883 9.2.1. dcmap 885 NOTE to RFC Editor: Please replace "XXXX" with the number of this 886 RFC. 888 This document defines a new SDP media-level attribute "a=dcmap:" as 889 follows: 891 +-----------------------+-------------------------------------------+ 892 | Contact name: | IESG Chairs | 893 | Contact email: | iesg@ietf.org | 894 | Attribute name: | dcmap | 895 | Attribute syntax: | As per Section 5.1.1 | 896 | Attribute semantics: | As per Section 5.1.1 | 897 | Usage level: | media | 898 | Charset dependent: | No | 899 | Purpose: | Define data channel specific parameters | 900 | Appropriate values: | As per Section 5.1.1 | 901 | O/A procedures: | As per Section 6 | 902 | Mux category: | SPECIAL. See Section 5.1.9 | 903 | Reference: | RFCXXXX | 904 +-----------------------+-------------------------------------------+ 906 9.2.2. dcsa 908 NOTE to RFC Editor: Please replace "XXXX" with the number of this 909 RFC. 911 This document defines a new SDP media-level attribute "a=dcsa:" as 912 follows: 914 +-----------------------+-------------------------------------------+ 915 | Contact name: | IESG Chairs | 916 | Contact email: | iesg@ietf.org | 917 | Attribute name: | dcsa | 918 | Attribute syntax: | As per Section 5.2.1 | 919 | Attribute semantics: | As per Section 5.2.1 | 920 | Usage level: | media | 921 | Charset dependent: | No | 922 | Purpose: | Define data channel subprotocol specific | 923 | | attributes | 924 | Appropriate values: | As per Section 5.2.1 | 925 | O/A procedures: | As per Section 6 | 926 | Mux category: | SPECIAL. See Section 5.2.2 | 927 | Reference: | RFCXXXX | 928 +-----------------------+-------------------------------------------+ 930 9.3. New Usage Level 932 This document introduces a new "Data Channel Subprotocol Attribute" 933 (dcsa) usage level of the SDP media description to the IANA SDP att- 934 field registry. SDP attributes that are only defined for use at the 935 dcsa usage level, SHALL use the dcsa usage level when registering the 936 attribute. If existing media attributes are used in a datachannel 937 subprotocol specific way (Section 5.2.1), then a new dcsa usage level 938 MUST be defined for the existing media attribute. Where the SDP 939 attribute is applicable to a particular subprotocol/s this SHALL also 940 be registered by indicating the applicable subprotocol identifiers 941 (see Section 9.1) along with the dcsa usage level. E.g. 943 +-----------------------+-------------------------------------------+ 944 | ... | ... | 945 | Usage level: | dcsa(msrp) | 946 | ... | ... | 947 +-----------------------+-------------------------------------------+ 949 10. Contributors 951 Juergen Stoetzer-Bradler co-authored this document. 953 11. Acknowledgments 955 The authors wish to acknowledge the borrowing of ideas from other 956 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 957 and Gavin Llewellyn, and to thank Flemming Andreasen, Christian 958 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe 959 Rauschenbach and Roman Shpount for their invaluable comments. 961 Special thanks to Christer Holmberg for helping finish the document 962 and cleaning the SDP offer/answer section. 964 12. CHANGE LOG 966 12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 968 o Editorial changes separate sections for offer/answer procedures. 970 o Update security section. 972 12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 974 o Change "dtls-id" to "tls-id" and assign 20 octet long values 976 o Remove of RFC4566bis draft from list of normative references. 978 12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 980 o Modification of Keith's address information. 982 12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 984 o dcmap-stream-id syntax change to limit size to 5 digits. 986 o Add missing 'x' prefix to quoted-visible syntax. 988 o Align SDP offerer and answerer handling when both max-retr and 989 max-time are present. 991 o Use of TEST-NET-1 ip addresses in examples. 993 o Add missing a=dtls-id in one example. 995 12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 997 o Removal of the "a=connection" attribute lines from all SDP 998 examples. 1000 12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1002 o In the introduction: 1004 * Replacement of the sentence "The RTCWeb working group has 1005 defined the concept of bi-directional data channels running on 1006 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1007 Security protocol)" with "The RTCWeb working group has defined 1008 the concept of bi-directional data channels running on top of 1009 the Stream Control Transmission Protocol (SCTP)". 1011 * Addition of following sentences to the second paragraph: "These 1012 procedures are based on generic SDP offer/answer negotiation 1013 rules for SCTP based media transport as specified in 1014 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1015 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1016 could be defined over other SCTP based protocols, such as SCTP 1017 over IP. However, corresponding potential other "m" line proto 1018 values are not considered in this document." 1020 o Replacement of "DTLS connection" with "DTLS association" 1021 throughout the document. 1023 o In sections Section 5.1.9 and Section 5.2.2 removal of the 1024 sentences "This document also does not specify multiplexing rules 1025 for this attribute for SCTP or SCTP/DTLS proto values". 1027 o In the text related to "Subsequent SDP answer" in section 1028 Section 6.7 replacement of "The DTLS/SCTP association remains open 1029 ..." with "The SCTP association remains open ...". 1031 o In the text after the second SDP answer in section Section 7 1032 replacement of "... (after SCTP/DTLS association is setup)" with 1033 "... (after the SCTP association is set up)". 1035 o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative 1036 references. 1038 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1039 examples in Section 7. 1041 12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1043 o Addition of definition of "data channel subprotocol" to Section 3 1044 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1045 archive/web/mmusic/current/msg15827.html. 1047 o Addition of RFC4566bis draft to list of normative references. 1049 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1050 section 8.2.4 of RFC4566bis draft. 1052 o Addition of new Section 9.3. 1054 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1056 o Addition of two new paragraphs to Section 5.2.1 regarding 1057 subprotocol attribute relationship with transport protocol. 1059 o Addition of a note to Section 9.1 regarding subprotocols 1060 simultaneously defined for data channel and Websocket usage. 1062 o Addition of two further SDP offer/answer considerations to 1063 Section 6.7 regarding unknown subprotocol attributes and known 1064 subprotocol attributes with unknown data channel transport related 1065 semantic. 1067 12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1069 o Changes addressing Christian Groves's WGLC review comments raised 1070 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1071 msg15357.html and http://www.ietf.org/mail- 1072 archive/web/mmusic/current/msg15359.html. 1074 12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1076 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1077 of contact name and e-mail address with "MMUSIC Chairs" and 1078 "mmusic-chairs@ietf.org". 1080 o In Section 5.2.1 replacement of "Thus in the example above, the 1081 original attribute line "a=accept- types:text/plain" is 1082 represented by the attribute line "a=dcsa:2 accept-types:text/ 1083 plain", which specifies that this instance of MSRP being 1084 transported on the SCTP association using the data channel with 1085 stream id 2 accepts plain text files." with "... which specifies 1086 that this instance of the MSRP subprotocol being transported ...". 1088 o The last paragraph of Section 5.2.1 started with "Note: This 1089 document does not provide a complete specification ...". Removal 1090 of "Note:" and move of this paragraph to the introduction in 1091 Section 1 as last paragraph. 1093 o Section 5.2's headline was "Subprotocol Specific Attributes". 1094 Change of this headline to "Other Media Level Attributes" and 1095 adaptations of the first paragraph of this section and the first 1096 paragraph of Section 5.2.1 in order to clarify that not only those 1097 attributes may be encapsulated in a "dcsa" attribute, which are 1098 specifically defined for the subprotocol, but that also other 1099 attributes may be encapsulated if they are related to the specific 1100 subprotocol instance. 1102 o Move of the last but one paragraph of Section 5.2.1 starting with 1103 "The same syntax applies to ..." right in front of the formal 1104 syntax definition of the "dcsa" attribute. 1106 o Modifications of the text in Section 5.1.9 and Section 5.2.2 in 1107 order not to explicitly restrict usage of the "a=dcmap:" and 1108 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1109 SCTP" or "TCP/DTLS/SCTP". 1111 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1113 o In Section 5.1.4 the first (and only) paragraph was "The 1114 'subprotocol' parameter indicates which protocol the client 1115 expects to exchange via the channel. 'Subprotocol' is an optional 1116 parameter. If the 'subprotocol' parameter is not present, then 1117 its value defaults to the empty string." Replacement of this 1118 paragraph with following two paragraphs: 1120 * The 'subprotocol' parameter indicates which protocol the client 1121 expects to exchange via the channel. This parameter maps to 1122 the 'Protocol' parameter defined in 1123 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1124 subprotocol parameter values are registered. 'Subprotocol' is 1125 an optional parameter. If the 'subprotocol' parameter is not 1126 present, then its value defaults to the empty string. 1128 * Note: The empty string MAY also be explicitly used as 1129 'subprotocol' value, such that 'subprotocol=""' is equivalent 1130 to the 'subprotocol' parameter not being present at all. 1132 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1133 message's 'Subprotocol' value to be an empty string. 1135 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1136 normative references. 1138 o Addition of dcmap attribute specific IANA registration 1139 Section 9.2.1. 1141 o Addition of dcsa attribute specific IANA registration 1142 Section 9.2.2. 1144 o Addition of new Section 5.1.9 describing the mux category of the 1145 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1146 related mux category section are similar to the "Mux Category" 1147 sections of the "a=sctp-port:" and "a=max-message-size:" 1148 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1150 o Addition of new Section 5.2.2 describing the mux category of the 1151 dcsa SDP attribute. 1153 12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1155 o In Section 1 replacement of "RTCWeb leaves it open for other 1156 applications to use data channels and its in-band DCEP or out-of- 1157 band non-DCEP protocols for creating them" with "... to use data 1158 channels and its in-band DCEP or other in-band or out-of-band 1159 protocols for creating them". Additionally replacement of "In 1160 particular, the SDP offer generated by the application includes no 1161 channel-specific information" with "... generated by the RTCweb 1162 data channel stack includes no channel-specific information". 1164 o Move of former section 5 ("Data Channels") to new Appendix A and 1165 removal of JavaScript API specific discussions from this moved 1166 text (like mentioning of data channel stack specific states). 1167 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1168 Section 5. 1170 o In Section 5: 1172 * Relacement of Section 5's first paragraph "This section defines 1173 a method of non-DCEP negotiation by which two clients can 1174 negotiate data channel-specific and subprotocol-specific 1175 parameters, using the out-of-band SDP offer/answer exchange. 1176 This SDP extension can only be used with the SDP offer/answer 1177 model." with "This section defines an SDP extension by which 1178 two clients can negotiate data channel-specific and 1179 subprotocol-specific parameters without using DCEP 1181 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1182 defines usage in the context of SDP offer/answer." 1184 * Addition of new paragraph: "Appendix A provides information how 1185 data channels work in general and especially summarizes some 1186 key aspects, which should be considered for the negotiation of 1187 data channels if DCEP is not used." 1189 o In Section 5.1 replacement of "The intention of exchanging these 1190 attributes is to create data channels on both the peers with the 1191 same set of attributes without actually using the DCEP 1192 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1193 these attributes is to create, on two peers, without use of DCEP 1194 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1195 directed data channels having the same set of attributes". 1197 o In Section 5.1.5 replacement of "The 'max-retr' parameter 1198 indicates the maximal number a user message will be retransmitted" 1199 with "The 'max-retr' parameter indicates the maximal number of 1200 times a user message will be retransmitted". 1202 o In Section 6.1 replacement of "However, an SDP offer/answer 1203 exchange MUST NOT be initiated if the associated SCTP stream is 1204 already negotiated via DCEP" with "However, an SCTP stream MUST 1205 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1206 answer exchange if the associated SCTP stream has already been 1207 negotiated via DCEP". 1209 o In the examples in Section 7 addition of the previously missing 1210 colons to the "a=sctp-port" attribute lines. 1212 12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1214 o Move of reference draft-ietf-rtcweb-jsep from the list of 1215 normative references to the list of informative references. 1216 Remover in -07 since not referenced 1218 o Addition of IANA SDP parameters to the list of informative 1219 references and addition of following two sentences to the first 1220 paragraph after the ABNF definition: "Note however that not all 1221 SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP 1222 parameters contains the lists of IANA registered session and media 1223 level or media level only SDP attributes." 1225 o In the introduction replacement of last sentence "This document 1226 defines SDP-based out-of-band negotiation procedures to establish 1227 data channels for transport of well-defined subprotocols" with 1228 "This document defines SDP offer/answer negotiation procedures to 1229 establish data channels for transport of well-defined 1230 subprotocols, to enable out-of-band negotiation". 1232 o Throughout the document replacement of "external negotiation" with 1233 "SDP offer/answer negotiation" and removal of term "external 1234 negotiation" from the terminology list in Section 3. 1236 o Throughout the document replacement of "internal negotiation" with 1237 "DCEP" and removal of terms "internal negotiation" and "in-band 1238 negotiation" from the terminology list in Section 3. 1240 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1241 terms. 1243 o In Section 6.1 replacement of sentence "However, a single stream 1244 is managed using one method at a time." with "However, an SDP 1245 offer/answer exchange MUST NOT be initiated if the associated SCTP 1246 stream is already negotiated via DCEP". 1248 o In Section 6.2 replacement of sentence "By definition max-retr and 1249 max-time are mutually exclusive, so only one of them can be 1250 present in a=dcmap" with "By definition max-retr and max-time are 1251 mutually exclusive, so aBoth MUST NOT be present in a=dcmap". 1253 o Move of reference [WebRtcAPI] from list of normative references to 1254 list of informative references. 1256 o Removal of almost all text parts, which discussed JavaScript or 1257 other API specific aspects. Such API specific aspects were mainly 1258 discussed in sub-sections of Section 5 and Section 5 of draft- 1259 ietf-mmusic-data-channel-sdpneg-02. 1261 12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1263 o New Section 4 regarding applicability to SDP offer/answer only. 1265 o Addition of new Section 9.1 "Subprotocol identifiers" as 1266 subsection of the "IANA Considerations" related Section 9. Also 1267 removal of the temporary note "To be completed. As [I-D.ietf- 1268 rtcweb-data-protocol] this document should refer to IANA's 1269 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1271 o In Section 6.2: 1273 * In the first paragraph replacement of the sentence "If an SDP 1274 offer contains both of these parameters then such an SDP offer 1275 will be rejected." with "If an SDP offer contains both of these 1276 parameters then the receiver of such an SDP offer MUST reject 1277 the SDP offer." 1279 * In the second paragraph capitalization of "shall" and "may" 1280 such that both sentences now read: "The SDP answer SHALL echo 1281 the same subprotocol, max-retr, max-time, ordered parameters, 1282 if those were present in the offer, and MAY include a label 1283 parameter. They MAY appear in any order, which could be 1284 different from the SDP offer, in the SDP answer." 1286 * In the third paragraph replacement of the sentence "The same 1287 information MUST be replicated without changes in any 1288 subsequent offer or answer, as long as the data channel is 1289 still opened at the time of offer or answer generation." with 1290 "When sending a subsequent offer or an answer, and for as long 1291 as the data channel is still open, the sender MUST replicate 1292 the same information.". 1294 o In Section 6.2 the mapping of data channel types defined in 1295 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1296 parameters were illustrated using example "a=dcmap" attribute 1297 lines. Replacement of these example "a=dcmap" attribute lines 1298 with just the "a=dcmap" attribute parameters being relevant for 1299 the channel type. 1301 o In Section 6.7 the description of bullet point "SDP offer has no 1302 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1303 No data channel negotiated yet." Replacement of this description 1304 with "Initial SDP offer: No data channel is negotiated yet. The 1305 DTLS connection and SCTP association is negotiated and, if agreed, 1306 established as per [I-D.ietf-mmusic-sctp-sdp]." 1308 o In Section 6.7 in both bullet points related to "Subsequent SDP 1309 offer" and "Subsequent SDP answer" replacement of "All the 1310 externally negotiated data channels must be closed now." with "All 1311 the externally negotiated data channels are expected to be closed 1312 now.". 1314 o In Appendix A.2.2's sixth paragraph replacement of the two 1315 occurrences of "must" with "MUST". 1317 o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" 1318 there was a comment saying that "Only maxretr-opt or maxtime-opt 1319 is present. Both MUST NOT be present." Removal of the second 1320 normative sentence and instead addition of following new paragraph 1321 to the end of this section: "Within an 'a=dcmap' attribute line's 1322 'dcmap-opt' value only one 'maxretr-opt' parameter or one 1323 'maxtime-opt' parameter is present. Both MUST NOT be present." 1325 o In Section 5.1.7 replacement of the first sentence "The 'ordered' 1326 parameter with value "true" indicates that DATA chunks in the 1327 channel MUST be dispatched to the upper layer by the receiver 1328 while preserving the order." with "The 'ordered' parameter with 1329 value "true" indicates that the receiver MUST dispatch DATA chunks 1330 in the data channel to the upper layer while preserving the 1331 order.". 1333 o In Section 6.3's first paragraph replacement of the one occurrence 1334 of "must" with "..., it MUST wait until ...". 1336 o In Section 6.6.1: 1338 * In the second paragraph replacement of "must" with "... whether 1339 this closing MUST in addition ..." 1341 * In the third paragraph replacement of the sentence "The port 1342 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1343 when closing a data channel ..." with "The offerer SHOULD NOT 1344 change the port value for the "m" line (e.g., to zero) when 1345 closing a data channel ...". 1347 * In the last but two paragraph replacement of the sentence "... 1348 then an SDP offer which excludes this closed data channel 1349 SHOULD be generated." with "... then the client SHOULD generate 1350 an SDP offer which excludes this closed data channel.". 1352 * In the last but one paragraph replacement of "must" with "The 1353 application MUST also close...". 1355 o In Section 5.2 addition of following note after the formal 1356 definition of the 'a=dcsa' attribute: "Note that the above 1357 reference to RFC 4566 defines were the attribute definition can be 1358 found; it does not provide any limitation on support of attributes 1359 defined in other documents in accordance with this attribute 1360 definition." 1362 12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1364 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1365 channel consisting of paired SCTP outbound and inbound streams." 1366 Replacement of this definition with "Data channel: A WebRTC data 1367 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1368 consistent usage of "data channel" in the remainder of the 1369 document including the document's headline." 1371 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1372 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1374 In particular we expect "webrtc-datachannel" to become a more 1375 general term.' 1377 o Consistent usage of '"m" line' in whole document as per RFC4566. 1379 o In Section 5.1 removal of the example dcmap attribute line 1380 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are 1381 already four examples right after the ABNF rules in Section 5.1.1. 1382 Corresponding removal of following related note: "Note: This 1383 document does not provide a complete specification of how to 1384 negotiate the use of a WebRTC data channel to transport BFCP. 1385 Procedures specific to each subprotocol such as BFCP will be 1386 documented elsewhere. The use of BFCP is only an example of how 1387 the generic procedures described herein might apply to a specific 1388 subprotocol." 1390 o In Section 5.1 removal of following note: "Note: This attribute is 1391 derived from attribute "webrtc-DataChannel", which was defined in 1392 old version 03 of the following draft, but which was removed along 1393 with any support for SDP external negotiation in subsequent 1394 versions: [I-D.ietf-mmusic-sctp-sdp]." 1396 o Insertion of following new sentence to the beginning of 1397 Section 5.1.1: "dcmap is a media level attribute having following 1398 ABNF syntax:" 1400 o Insertion of new Section 5.1.2 containing the dcmap-stream-id 1401 specifying sentence, which previously was placed right before the 1402 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1403 parameter and is noted directly after the "a=dcmap:" attribute's 1404 colon' as this information is part of the ABNF specification. 1406 o In Section 5.1.1 modification of the 'ordering-value' values from 1407 "0" or "1" to "true" or "false". Corresponding text modifications 1408 in Section 5.1.7. 1410 o In Section 5.1.1 the ABNF definition of "quoted-string" referred 1411 to rule name "escaped-char", which was not defined. Instead a 1412 rule with name "escaped" was defined. Renamed that rule's name to 1413 "escaped-char". 1415 o Insertion of a dedicated note right after the "a=dcmap:4" 1416 attribute example in Section 5.1.1 regarding the non-printable 1417 "escaped-char" character within the "label" value. 1419 o In Section 5.2's second paragraph replacement of "sctp stream 1420 identifier" with "SCTP stream identifier". 1422 o In first paragraph of Section 6.1 replacement of first two 1423 sentences 'For the SDP-based external negotiation described in 1424 this document, the initial offerer based "SCTP over DTLS" owns by 1425 convention the even stream identifiers whereas the initial 1426 answerer owns the odd stream identifiers. This ownership is 1427 invariant for the whole lifetime of the signaling session, e.g. it 1428 does not change if the initial answerer sends a new offer to the 1429 initial offerer.' with 'If an SDP offer/answer exchange (could be 1430 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1431 TCP/DTLS/SCTP based media description being accepted, and if this 1432 SDP offer/answer exchange results in the establishment of a new 1433 SCTP association, then the SDP offerer owns the even SCTP stream 1434 ids of this new SCTP association and the answerer owns the odd 1435 SCTP stream identifiers. If this "m" line is removed from the 1436 signaling session (its port number set to zero), and if usage of 1437 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1438 renegotiated later on, then the even and odd SCTP stream 1439 identifier ownership is redetermined as well as described above.' 1441 o In Section 6.3 the first action of an SDP answerer, when receiving 1442 an SDP offer, was described as "Applies the SDP offer. Note that 1443 the browser ignores data channel specific attributes in the SDP." 1444 Replacement of these two sentences with "Parses and applies the 1445 SDP offer. Note that the typical parser normally ignores unknown 1446 SDP attributes, which includes data channel related attributes." 1448 o In Section 6.3 the second sentence of the third SDP answerer 1449 action was "Note that the browser is asked to create data channels 1450 with stream identifiers not "owned" by the agent.". Replacement 1451 of this sentence with "Note that the agent is asked to create data 1452 channels with SCTP stream identifiers contained in the SDP offer 1453 if the SDP offer is accepted." 1455 o In Section 6.6.1 the third paragraph began with "A data channel 1456 can be closed by sending a new SDP offer which excludes the dcmap 1457 and dcsa attribute lines for the data channel. The port value for 1458 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1459 data channel (unless all data channels are being closed and the 1460 SCTP association is no longer needed), since this would close the 1461 SCTP association and impact all of the data channels. If the 1462 answerer accepts the SDP offer then it MUST also exclude the 1463 corresponding attribute lines in the answer. ..." Replacement of 1464 this part with "The intention to close a data channel can be 1465 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1466 and "a=dcsa:" attribute lines for the data channel. The port 1467 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1468 closing a data channel (unless all data channels are being closed 1469 and the SCTP association is no longer needed), since this would 1470 close the SCTP association and impact all of the data channels. 1471 If the answerer accepts the SDP offer then it MUST close those 1472 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1473 excluded from the received SDP offer, unless those data channels 1474 were already closed, and it MUST also exclude the corresponding 1475 attribute lines in the answer." 1477 o In Section 6.6.1 the hanging text after the third paragraph was 1478 "This delayed close is to handle cases where a successful SDP 1479 answer is not received, in which case the state of session should 1480 be kept per the last successful SDP offer/answer." Replacement of 1481 this sentence with "This delayed closure is RECOMMENDED in order 1482 to handle cases where a successful SDP answer is not received, in 1483 which case the state of the session SHOULD be kept per the last 1484 successful SDP offer/answer." 1486 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1487 Section 5.1 contained already procedural descriptions related to 1488 data channel reliability negotiation. Creation of new Section 6.2 1489 and moval of reliability negotiation related text to this new 1490 section. 1492 12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1494 o Removal of note "ACTION ITEM" from section "subprotocol 1495 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1496 should refer to IANA's WebSocket Subprotocol Name Registry defined 1497 in [RFC6455] 1499 o In whole document, replacement of "unreliable" with "partially 1500 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1501 [I-D.ietf-rtcweb-data-protocol] in most places. 1503 o Clarification of the semantic if the "max-retr" parameter is not 1504 present in an "a=dcmap" attribute line. In section "max-retr 1505 parameter" the sentence "The max-retr parameter is optional with 1506 default value unbounded" was replaced with "The max-retr parameter 1507 is optional. If the max-retr parameter is not present, then the 1508 maximal number of retransmissions is determined as per the generic 1509 SCTP retransmission rules as specified in [RFC4960]". 1511 o Clarification of the semantic if the "max-time" parameter is not 1512 present in an "a=dcmap" attribute line. In section "max-time 1513 parameter" the sentence "The max-time parameter is optional with 1514 default value unbounded" was replaced with "The max-time parameter 1515 is optional. If the max-time parameter is not present, then the 1516 generic SCTP retransmission timing rules apply as specified in 1517 [RFC4960]". 1519 o In section "label parameter" the sentence "Label is a mandatory 1520 parameter." was removed and following new sentences (including the 1521 note) were added: "The 'label' parameter is optional. If it is 1522 not present, then its value defaults to the empty string. Note: 1523 The empty string may also be explicitly used as 'label' value, 1524 such that 'label=""' is equivalent to the 'label' parameter not 1525 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1526 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1528 o In section "subprotocol parameter" the sentence "Subprotocol is a 1529 mandatory parameter." was replaced with "'Subprotocol' is an 1530 optional parameter. If the 'subprotocol' parameter is not 1531 present, then its value defaults to the empty string." 1533 o In the "Examples" section, in the first two SDP offer examples in 1534 the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 1535 'label="bfcp"'. 1537 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1538 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1539 replaced with "a=max-message-size" attribute lines, as per draft- 1540 ietf-mmusic-sctp-sdp-12. 1542 12.17. Changes against '-01' 1544 o Formal syntax for dcmap and dcsa attribute lines. 1546 o Making subprotocol as an optional parameter in dcmap. 1548 o Specifying disallowed parameter combinations for max-time and max- 1549 retr. 1551 o Clarifications on WebRTC data channel close procedures. 1553 12.18. Changes against '-00' 1555 o Revisions to identify difference between internal and external 1556 negotiation and their usage. 1558 o Introduction of more generic terminology, e.g. "application" 1559 instead of "browser". 1561 o Clarification of how "max-retr and max-time affect the usage of 1562 unreliable and reliable WebRTC data channels. 1564 o Updates of examples to take into account the SDP syntax changes 1565 introduced with draft-ietf-mmusic-sctp-sdp-07. 1567 o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" 1568 attributes as this is now contained in the a=sctp-port attribute, 1569 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1570 association on top of the DTLS connection. 1572 13. References 1574 13.1. Normative References 1576 [I-D.ietf-mmusic-rfc4566bis] 1577 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1578 Session Description Protocol", draft-ietf-mmusic- 1579 rfc4566bis-32 (work in progress), December 2018. 1581 [I-D.ietf-mmusic-sctp-sdp] 1582 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1583 "Session Description Protocol (SDP) Offer/Answer 1584 Procedures For Stream Control Transmission Protocol (SCTP) 1585 over Datagram Transport Layer Security (DTLS) Transport.", 1586 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1587 2017. 1589 [I-D.ietf-mmusic-sdp-mux-attributes] 1590 Nandakumar, S., "A Framework for SDP Attributes when 1591 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1592 (work in progress), February 2018. 1594 [I-D.ietf-rtcweb-data-channel] 1595 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1596 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1597 progress), January 2015. 1599 [I-D.ietf-rtcweb-data-protocol] 1600 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1601 Establishment Protocol", draft-ietf-rtcweb-data- 1602 protocol-09 (work in progress), January 2015. 1604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1605 Requirement Levels", BCP 14, RFC 2119, 1606 DOI 10.17487/RFC2119, March 1997, 1607 . 1609 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1610 with Session Description Protocol (SDP)", RFC 3264, 1611 DOI 10.17487/RFC3264, June 2002, 1612 . 1614 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1615 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1616 . 1618 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1619 Specifications: ABNF", STD 68, RFC 5234, 1620 DOI 10.17487/RFC5234, January 2008, 1621 . 1623 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1624 Transmission Protocol (SCTP) Stream Reconfiguration", 1625 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1626 . 1628 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1629 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1630 May 2017, . 1632 13.2. Informative References 1634 [I-D.ietf-clue-datachannel] 1635 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1636 clue-datachannel-15 (work in progress), August 2018. 1638 [I-D.ietf-mmusic-msrp-usage-data-channel] 1639 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1640 Marcon, J., and J. Recio, "MSRP over Data Channels", 1641 draft-ietf-mmusic-msrp-usage-data-channel-09 (work in 1642 progress), May 2018. 1644 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1645 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1646 November 2006, . 1648 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1649 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1650 DOI 10.17487/RFC4975, September 2007, 1651 . 1653 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1654 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1655 . 1657 [WebRtcAPI] 1658 Bergkvist, A., Burnett, D., Jennings, C., and A. 1659 Narayanan, "WebRTC 1.0: Real-time Communication Between 1660 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1661 February 2015, 1662 . 1664 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1665 DCEP 1667 This appendix summarizes how data channels work in general and 1668 discusses some key aspects, which should be considered for the out- 1669 of-band negotiation of data channels if DCEP is not used. 1671 A WebRTC application creates a data channel by providing a number of 1672 setup parameters (subprotocol, label, maximal number of 1673 retransmissions, maximal retransmission time, order of delivery, 1674 priority). The application also specifies if it wants to make use of 1675 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1676 the application intends to negotiate data channels using the SDP 1677 offer/answer protocol. 1679 In any case, the SDP offer generated by the application is per 1680 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1681 the SCTP association on top of which data channels will run: 1683 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1684 c=IN IP4 192.0.2.1 1685 a=max-message-size:100000 1686 a=sctp-port:5000 1687 a=tls-id:abc3de65cddef001be82 1688 a=setup:actpass 1689 a=fingerprint:SHA-1 \ 1690 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1692 Note: A WebRTC application will only use "m" line format "webrtc- 1693 datachannel", and will not use other formats in the "m" line for 1694 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1695 only one SCTP association to be established on top of a DTLS 1696 association. 1698 Note: The above SDP media description does not contain any channel- 1699 specific information. 1701 A.1. Stream Identifier Numbering 1703 Independently from the requested type of negotiation, the application 1704 creating a data channel can either pass the stream identifier to the 1705 data channel stack to assign to the data channel or else let the data 1706 channel stack pick one identifier from the unused ones. 1708 To avoid glare situations, each endpoint can moreover own an 1709 exclusive set of stream identifiers, in which case an endpoint can 1710 only create a data channel with a stream identifier it owns. 1712 Which set of stream identifiers is owned by which endpoint is 1713 determined by convention or other means. 1715 Note:For data channels negotiated with the DCEP, one endpoint owns 1716 by convention the even stream identifiers, whereas the other owns 1717 the odd stream identifiers, as defined in 1718 [I-D.ietf-rtcweb-data-protocol]. 1720 Note:For data channels negotiated via different protocol from 1721 DCEP, no convention is defined by default. 1723 A.2. Generic Data Channel Negotiation Not Using DCEP 1725 A.2.1. Overview 1727 DCEP negotiation only provides for negotiation of data channel 1728 transport parameters and does not provide for negotiation of 1729 subprotocol specific parameters. DCEP-less data channel negotiation 1730 can be defined to allow negotiation of parameters beyond those 1731 handled by DCEP, e.g., parameters specific to the subprotocol 1732 instantiated on a particular data channel. 1734 The following procedures are common to all methods of data channel 1735 negotiation not using DCEP, whether in-band (communicated using 1736 proprietary means on an already established data channel) or out-of- 1737 band (using SDP offer/answer or some other protocol associated with 1738 the signaling channel). 1740 A.2.2. Opening a Data Channel 1742 In the case of DCEP-less negotiation, the endpoint application has 1743 the option to fully control the stream identifier assignments. 1744 However these assignments have to coexist with the assignments 1745 controlled by the data channel stack for the DCEP negotiated data 1746 channels (if any). It is the responsibility of the application to 1747 ensure consistent assignment of stream identifiers. 1749 When the application requests the creation of a new data channel to 1750 be set up via DCEP-less negotiation, the data channel stack creates 1751 the data channel locally without sending any DATA_CHANNEL_OPEN 1752 message in-band. However, even if the ICE (Interactive Connectivity 1753 Establishment), DTLS and SCTP procedures were already successfully 1754 completed, the application can't send data on this data channel until 1755 the negotiation is complete with the peer. This is because the peer 1756 needs to be aware of and accept the usage of this data channel. The 1757 peer, after accepting the data channel offer, can start sending data 1758 immediately. This implies that the offerer may receive data channel 1759 subprotocol messages before the negotiation is complete and the 1760 application should be ready to handle it. 1762 If the peer rejects the data channel part of the offer then it 1763 doesn't have to do anything as the data channel was not created using 1764 the stack. The offerer on the other hand needs to close the data 1765 channel that was opened by invoking relevant data channel stack API 1766 procedures. 1768 It is also worth noting that a data channel stack implementation may 1769 not provide any API to create and close data channels; instead the 1770 data channels may be used on the fly as needed just by communicating 1771 via non-DCEP means or by even having some local configuration/ 1772 assumptions on both the peers. 1774 The application then negotiates the data channel properties and 1775 subprotocol properties with the peer's application using a mechanism 1776 different from DCEP. 1778 The peer then symmetrically creates a data channel with these 1779 negotiated data channel properties. This is the only way for the 1780 peer's data channel stack to know which properties to apply when 1781 transmitting data on this channel. The data channel stack must allow 1782 data channel creation with any non-conflicting stream identifier so 1783 that both peers can create the data channel with the same stream 1784 identifier. 1786 A.2.3. Closing a Data Channel 1788 When the application requests the closing of a data channel 1789 negotiated without DCEP, the data channel stack always performs an 1790 SCTP SSN reset for this channel. 1792 Depending upon the method used for DCEP-less negotiation and the 1793 subprotocol associated with the data channel, the closing might in 1794 addition be signaled to the peer via SDP offer/answer negotiation. 1796 Authors' Addresses 1798 Keith Drage 1799 Unaffiliated 1801 Email: drageke@ntlworld.com 1803 Maridi R. Makaraju (Raju) 1804 Nokia 1805 2000 Lucent Lane 1806 Naperville, Illinois 1807 US 1809 Email: Raju.Makaraju@nokia.com 1811 Richard Ejzak 1812 Unaffiliated 1814 Email: richard.ejzak@gmail.com 1816 Jerome Marcon 1817 Unaffiliated 1819 Email: jeromee.marcon@free.fr 1821 Roni Even (editor) 1822 Huawei 1824 Email: roni.even@huawei.com