idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-23.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 (January 17, 2019) is 1897 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: July 21, 2019 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 R. Even, Ed. 11 Huawei 12 January 17, 2019 14 SDP-based Data Channel Negotiation 15 draft-ietf-mmusic-data-channel-sdpneg-23 17 Abstract 19 Data channel setup can be done using either the in- band Data Channel 20 Establishment Protocol (DCEP) or using some out-of- band non-DCEP 21 protocol. This document specifies how the SDP (Session Description 22 Protocol) offer/answer exchange can be used to achieve an out-of-band 23 non-DCEP negotiation for establishing a data channel. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 21, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 63 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 64 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 65 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6 66 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 67 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 68 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 69 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 8 70 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 71 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 72 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9 73 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 9 74 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 75 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10 76 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 77 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 78 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13 79 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 80 6.3. Generating the Initial Offer for A Data Channel . . . . . 14 81 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 82 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14 83 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 84 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15 85 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 86 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19 90 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 91 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19 92 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20 93 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 11.1. Changes against 'draft-ietf-mmusic-data-channel- 97 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21 98 11.2. Changes against 'draft-ietf-mmusic-data-channel- 99 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21 100 11.3. Changes against 'draft-ietf-mmusic-data-channel- 101 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21 102 11.4. Changes against 'draft-ietf-mmusic-data-channel- 103 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21 104 11.5. Changes against 'draft-ietf-mmusic-data-channel- 105 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22 106 11.6. Changes against 'draft-ietf-mmusic-data-channel- 107 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22 108 11.7. Changes against 'draft-ietf-mmusic-data-channel- 109 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 110 11.8. Changes against 'draft-ietf-mmusic-data-channel- 111 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23 112 11.9. Changes against 'draft-ietf-mmusic-data-channel- 113 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23 114 11.10. Changes against 'draft-ietf-mmusic-data-channel- 115 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23 116 11.11. Changes against 'draft-ietf-mmusic-data-channel- 117 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24 118 11.12. Changes against 'draft-ietf-mmusic-data-channel- 119 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25 120 11.13. Changes against 'draft-ietf-mmusic-data-channel- 121 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26 122 11.14. Changes against 'draft-ietf-mmusic-data-channel- 123 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27 124 11.15. Changes against 'draft-ietf-mmusic-data-channel- 125 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29 126 11.16. Changes against 'draft-ejzak-mmusic-data-channel- 127 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32 128 11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33 129 11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 132 12.2. Informative References . . . . . . . . . . . . . . . . . 35 133 Appendix A. Generic Data Channel Negotiation Aspects When Not 134 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 135 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . . . . . . . . . 38 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. A sub-protocol 459 specification MUST define the offer/answer procedures for the dsca 460 attribute (if applicable) associated with the sub-protocol, if the 461 sub-protocol has defined offer/answer procedures when used outside of 462 dcsa. If no offer/answer procedures exist for the sub-protocol when 463 used outside of the dcsa attribute, no specification is required for 464 use with dcsa. 466 5.2.1. DCSA Syntax 467 Formal Syntax: 469 Name: dcsa 471 Value: dcsa-value 473 Usage Level: media 475 Charset Dependent: no 477 Syntax: 479 dcsa-value = stream-id SP attribute 480 attribute = 482 Example: 484 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 486 a=dcsa:2 accept-types:text/plain 488 Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where 489 the attribute definition can be found; it does not provide any 490 limitation on support of attributes defined in other documents in 491 accordance with this attribute definition. Note however that not all 492 SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP 493 parameters contains the lists of IANA (Internet Assigned Numbers 494 Authority) registered session and media level or media level only SDP 495 attributes. 497 Thus in the example above, the original attribute line "a=accept- 498 types:text/plain" is represented by the attribute line "a=dcsa:2 499 accept-types:text/plain", which specifies that this instance of the 500 MSRP subprotocol being transported on the SCTP association using the 501 data channel with stream id 2 accepts plain text files. 503 As opposed to the data channel "a=dcmap:" attribute parameters, these 504 parameters are subject to offer/answer negotiation following the 505 procedures defined in the subprotocol specific documents. 507 It is assumed that in general the usages of subprotocol related media 508 level attributes are independent from the subprotocol's transport 509 protocol. Such transport protocol independent subprotocol related 510 attributes are used in the same way as defined in the original 511 subprotocol specification, also if the subprotocol is transported 512 over a data channel and if the attribute is correspondingly embedded 513 in a "a=dcsa" attribute. 515 There may be cases, where the usage of a subprotocol related media 516 level attribute depends on the subprotocol's transport protocol. In 517 such cases the subprotocol related usage of the attribute is expected 518 to be described for the data channel transport. A data channel 519 specific usage of a subprotocol attribute is expected to be specified 520 in the same document that registers the subprotocol's identifier for 521 data channel usage as described in Section 9.1. 523 5.2.2. DCSA Multiplexing Category 525 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 527 As the usage of multiple SCTP associations on top of a single DTLS 528 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 529 "a=dcsa:" attribute multiplexing rules are specified for the 530 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 531 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 532 multiple SCTP associations on top of a single DTLS association, or 533 how to add multiple SCTP associations to one BUNDLE group, then 534 multiplexing rules for the "a=dcsa:" attribute need to be defined as 535 well, for instance in an extension of this SDP based data channel 536 negotiation specification. 538 6. SDP Offer/Answer Procedures 540 This section defines how data channels can be negotiated using the 541 SDP offer/answer mechanism. A given media description can describe 542 multiple data channels (each represented by a separate SDP dcmap 543 attribute) that can be created, modified and closed using different 544 offer/answer exchanges. The procedures in this section apply for a 545 given data channel. 547 The generic offer/answer procedures for negotiating the SCTP 548 association used to realize data channels are defined in 549 [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data 550 channel specific procedures. 552 "Initial offer" refers to the offer in which a data channel is 553 opened. It can be the initial offer, or a subsequent offer, of the 554 associated SDP session. 556 The detailed offer/answer procedures for the dcsa attribute are 557 dependent on the associated sub-protocol. A sub-protocol 558 specification MUST define the offer/answer procedures for the dsca 559 attribute (if applicable) associated with the sub-protocol. 561 6.1. Managing Stream Identifiers 563 In order to avoid SCTP Stream identifier collisions, in alignment 564 with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS 565 client (for the SCTP association used to realize data channels) MUST 566 use even identifier values, and the endpoint acting as DTLS server 567 MUST use odd identifier values. SCTP stream identifiers associated 568 with data channels that have been negotiated using DCEP MUST NOT be 569 included in SDP offers and answers. 571 SCTP stream identifiers associated with data channels that have been 572 negotiated using DCEP MUST NOT be included in SDP offers and answers. 574 6.2. Negotiating Data Channel Parameters 576 The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 577 mapped to the dcmap SDP attribute parameters in the following manner 578 where "ordered=true" is the default and may be omitted: 580 DATA_CHANNEL_RELIABLE 581 ordered=true 583 DATA_CHANNEL_RELIABLE_UNORDERED 584 ordered=false 586 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 587 ordered=true;max-retr= 589 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 590 ordered=false;max-retr= 592 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 593 ordered=true;max-time= 595 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 596 ordered=false;max-time= 598 By definition max-retr and max-time are mutually exclusive, so Both 599 MUST NOT be present in the "a=dcmap:" attribute line. If a SDP offer 600 contains both of these parameters then the receiver of such an SDP 601 offer MUST reject the SDP offer. If a SDP answer contains both of 602 these parameters then the offerer MUST treat the associated SDP 603 offer/answer failed. 605 6.3. Generating the Initial Offer for A Data Channel 607 When an offerer sends an initial offer, in order to negotiate an SCTP 608 stream for a data channel, the offerer: 610 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 611 associated with the data channel in the "m=" section representing 612 the SCTP association used to realize the data channel; and 614 o MAY include one or more SDP dcsa attributes (Section 5.2) 615 associated with the data channel. The value of the stream-id part 616 of each attribute SHALL match the dcmap-stream-id value of the 617 dcmap attribute. 619 6.4. Generating SDP Answer 621 When an answerer receives an offer that includes an "m=" section for 622 an SCTP association, that describes an SCTP stream for a data 623 channel, if the answerer accepts the data channel it: 625 o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) 626 associated with the data channel in the "m=" section representing 627 the SCTP association used to realize the data channel. The value 628 of the dcmap-stream-id, max-retr and max-time values of the dcmap 629 attribute SHALL be identical to the value used for the data 630 channel in the offer; and 632 o MAY include one or more SDP dcsa attributes (Section 5.2) 633 associated with the data channel. 635 6.5. Offerer Processing of the SDP Answer 637 An offerer receiving a SDP answer performs the following: 639 o SHALL close any created data channels as described in 640 Section 6.6.1 for which the expected "a=dcmap:" attributes are not 641 present in the SDP answer. If the SDP answer has no "a=dcmap" 642 attribute either the peer does not support "a=dcmap:" attributes 643 or it rejected all the data channels. In either case the offerer 644 closes all the SDP offered data channels that were open at the 645 time of offer. The DTLS association and SCTP association will 646 still be setup. 648 Each agent application MUST wait to send data until it has 649 confirmation that the data channel at the peer is instantiated. For 650 WebRTC, this is when both data channel stacks have channel parameters 651 instantiated. This occurs: 653 o At both peers when a data channel is created without a previously 654 established SCTP association, as soon as the SCTP association is 655 successfully established. 657 o At the agent receiving an SDP offer for which there is an 658 established SCTP association, as soon as it creates the negotiated 659 data channel based on information signaled in the SDP offer. 661 o At the agent sending an SDP offer to create a new data channel for 662 which there is an established SCTP association, when it receives 663 the SDP answer confirming acceptance of the data channel or when 664 it begins to receive data on the data channel from the peer, 665 whichever occurs first. 667 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 668 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 670 6.6. Modifying the Session 672 When an offer sends a subsequent offer, that includes information for 673 a previously negotiated data channel, unless the offerer intends to 674 close the data channel (Section 6.6.1), the offerer SHALL include the 675 previously negotiated SDP attributes and attribute values associated 676 with the data channel. 678 6.6.1. Closing a Data Channel 680 In order to close a data channel, the endpoint that wants to close 681 SHALL send the SCTP SSN reset message [RFC6525], following the 682 procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In 683 addition, if the closed data channel was negotiated using the offer/ 684 answer mechanism Section 6.3, the endpoint that closed the data 685 channel SHALL send a subsequent offer in which it either: 687 o removes the SDP dcmap attribute and SDP dcsa attributes associated 688 with the closed data channel. Once the endpoint receives a 689 successful answer, the SCTP stream identifier value can later be 690 used for a new data channel (negotiated using DCTP or using the 691 offer/answer mechanism); or 693 o immediately re-uses the SCTP stream used for the closed data 694 channel for a new data channel, using the procedures in 695 Section 6.3. The offerer SHALL use a different SDP dcmap 696 attribute value for the data channel using the same SCTP stream. 698 6.7. Various SDP Offer/Answer Considerations 700 An SDP offer or answer has no "a=dcmap:" attributes but has 701 "a=dcsa:" attributes. 703 * This is considered an error case. In this case the receiver of 704 such an SDP offer or answer MUST discard this "a=dcsa:" 705 attributes. 707 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 708 attribute is unknown. 710 * The receiver of such an SDP offer or answer SHOULD ignore this 711 entire "a=dcsa" attribute line. 713 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 714 attribute is known, but whose subprotocol attribute semantic is 715 not known for the data channel transport case. 717 * The receiver of such an SDP offer or answer SHOULD ignore this 718 entire "a=dcsa" attribute line. 720 7. Examples 722 SDP offer: 724 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 725 c=IN IP6 IP6 2001:db8::3 726 a=max-message-size:100000 727 a=sctp-port:5000 728 a=setup:actpass 729 a=fingerprint:SHA-1 \ 730 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 731 a=tls-id:abc3de65cddef001be82 732 a=dcmap:0 subprotocol="BFCP";label="BFCP" 734 SDP answer: 736 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 737 c=IN IP6 IP6 2001:db8::1 738 a=max-message-size:100000 739 a=sctp-port:5002 740 a=setup:passive 741 a=fingerprint:SHA-1 \ 742 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 743 a=tls-id:dcb3ae65cddef0532d42 745 Figure 1: Example 1 747 In the example in Figure 1 the SDP answerer rejected the data channel 748 with stream id 0 either for explicit reasons or because it does not 749 understand the "a=dcmap:" attribute. As a result the offerer will 750 close the data channel created with the SDP offer/answer negotiation 751 option. The SCTP association will still be setup over DTLS. At this 752 point the offerer or the answerer may use DCEP negotiation to open 753 data channels. 755 SDP offer: 757 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 758 c=IN IP4 192.0.2.1 759 a=max-message-size:100000 760 a=sctp-port:5000 761 a=setup:actpass 762 a=fingerprint:SHA-1 \ 763 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 764 a=tls-id:abc3de65cddef001be82 765 a=dcmap:0 subprotocol="BFCP";label="BFCP" 766 a=dcmap:2 subprotocol="MSRP";label="MSRP" 767 a=dcsa:2 accept-types:message/cpim text/plain 768 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 770 SDP answer: 772 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 773 c=IN IP4 192.0.2.2 774 a=max-message-size:100000 775 a=sctp-port:5002 776 a=setup:passive 777 a=fingerprint:SHA-1 \ 778 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 779 a=tls-id:dcb3ae65cddef0532d42 780 a=dcmap:2 subprotocol="MSRP";label="MSRP" 781 a=dcsa:2 accept-types:message/cpim text/plain 782 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 784 Figure 2: Example 2 786 In the example in Figure 2 the SDP offer contains data channels for 787 BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 788 answer rejected BFCP and accepted MSRP. So, the offerer closes the 789 data channel for BFCP and both offerer and answerer may start using 790 the MSRP data channel (after the SCTP association is set up). The 791 data channel with stream id 0 is free and can be used for future DCEP 792 or SDP offer/answer negotiation. 794 Continuing the example in Figure 2. 796 Subsequent SDP offer: 798 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 799 c=IN IP4 192.0.2.1 800 a=max-message-size:100000 801 a=sctp-port:5000 802 a=setup:actpass 803 a=fingerprint:SHA-1 \ 804 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 805 a=tls-id:abc3de65cddef001be82 806 a=dcmap:4 subprotocol="MSRP";label="MSRP" 807 a=dcsa:4 accept-types:message/cpim text/plain 808 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 810 Subsequent SDP answer: 812 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 813 c=IN IP4 192.0.2.2 814 a=max-message-size:100000 815 a=sctp-port:5002 816 a=setup:passive 817 a=fingerprint:SHA-1 \ 818 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 819 a=tls-id:dcb3ae65cddef0532d42 820 a=dcmap:4 subprotocol="MSRP";label="MSRP" 821 a=dcsa:4 accept-types:message/cpim text/plain 822 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 824 Figure 3: Example 3 826 The example in Figure 3 is a continuation of the example in Figure 2. 827 The SDP offerer now removes the MSRP data channel with stream id 2, 828 but opens a new MSRP data channel with stream id 4. The answerer 829 accepts the entire offer. As a result the offerer closes the earlier 830 negotiated MSRP related data channel and both offerer and answerer 831 may start using new the MSRP related data channel. 833 8. Security Considerations 835 This document specifies new SDP attributes used in the negotiation of 836 the DATA channel parameters. 838 These parameter are negotiated as part of opening a SCTP channel over 839 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol 840 may come with it's own security considerations that need to be 841 documented as part of the subprotocol definition. Otherwise this 842 document do not add any security considerations to the ones specified 843 in [I-D.ietf-mmusic-sctp-sdp] 844 Error cases like the use of unknown parameter values or violation the 845 odd/even rule must be handled by closing the corresponding Data 846 Channel. 848 9. IANA Considerations 850 9.1. Subprotocol Identifiers 852 Registration of new subprotocol identifiers is performed using the 853 existing IANA "WebSocket Subprotocol Name Registry" table. 855 The following text should be added following the title of the table. 857 "This table also includes subprotocol identifiers specified for usage 858 within a WebRTC data channel." 860 The following reference should be added to under the heading 861 reference: "RFC XXXX". 863 This document assigns no new values to this table. 865 A subprotocol may simultaneously be defined for data channel 866 transport and for Websocket transport. In such a case the 867 "Subprotocol Definition" and "Reference" cells in the subprotocol's 868 row of the IANA "WebSocket Subprotocol Name Registry" table should 869 contain two entries. One entry in each of these cells should refer 870 to the Websocket related subprotocol specification, and the other 871 entry should refer to the data channel related subprotocol 872 specification. 874 NOTE to RFC Editor: Please replace "XXXX" with the number of this 875 RFC. 877 9.2. New SDP Attributes 879 9.2.1. dcmap 881 NOTE to RFC Editor: Please replace "XXXX" with the number of this 882 RFC. 884 This document defines a new SDP media-level attribute "a=dcmap:" as 885 follows: 887 +-----------------------+-------------------------------------------+ 888 | Contact name: | IESG Chairs | 889 | Contact email: | iesg@ietf.org | 890 | Attribute name: | dcmap | 891 | Attribute syntax: | As per Section 5.1.1 | 892 | Attribute semantics: | As per Section 5.1.1 | 893 | Usage level: | media | 894 | Charset dependent: | No | 895 | Purpose: | Define data channel specific parameters | 896 | Appropriate values: | As per Section 5.1.1 | 897 | O/A procedures: | As per Section 6 | 898 | Mux category: | SPECIAL. See Section 5.1.9 | 899 | Reference: | RFCXXXX | 900 +-----------------------+-------------------------------------------+ 902 9.2.2. dcsa 904 NOTE to RFC Editor: Please replace "XXXX" with the number of this 905 RFC. 907 This document defines a new SDP media-level attribute "a=dcsa:" as 908 follows: 910 +-----------------------+-------------------------------------------+ 911 | Contact name: | IESG Chairs | 912 | Contact email: | iesg@ietf.org | 913 | Attribute name: | dcsa | 914 | Attribute syntax: | As per Section 5.2.1 | 915 | Attribute semantics: | As per Section 5.2.1 | 916 | Usage level: | media | 917 | Charset dependent: | No | 918 | Purpose: | Define data channel subprotocol specific | 919 | | attributes | 920 | Appropriate values: | As per Section 5.2.1 | 921 | O/A procedures: | As per Section 6 | 922 | Mux category: | SPECIAL. See Section 5.2.2 | 923 | Reference: | RFCXXXX | 924 +-----------------------+-------------------------------------------+ 926 9.3. New Usage Level 928 This document introduces a new "Data Channel Subprotocol Attribute" 929 (dcsa) usage level of the SDP media description to the IANA SDP att- 930 field registry. SDP attributes that are only defined for use at the 931 dcsa usage level, SHALL use the dcsa usage level when registering the 932 attribute. If existing media attributes are used in a datachannel 933 subprotocol specific way (Section 5.2.1), then a new dcsa usage level 934 MUST be defined for the existing media attribute. Where the SDP 935 attribute is applicable to a particular subprotocol/s this SHALL also 936 be registered by indicating the applicable subprotocol identifiers 937 (see Section 9.1) along with the dcsa usage level. E.g. 939 +-----------------------+-------------------------------------------+ 940 | ... | ... | 941 | Usage level: | dcsa(MSRP) | 942 | ... | ... | 943 +-----------------------+-------------------------------------------+ 945 10. Acknowledgments 947 The authors wish to acknowledge the borrowing of ideas from other 948 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 949 and Gavin Llewellyn, and to thank Flemming Andreasen, Christian 950 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe 951 Rauschenbach and Roman Shpount for their invaluable comments. 953 Special thanks to Christer Holmberg for helping finish the document 954 and cleaning the SDP offer/answer section. 956 11. CHANGE LOG 958 11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 960 o Editorial changes separate sections for offer/answer procedures. 962 o Update security section. 964 11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 966 o Change "dtls-id" to "tls-id" and assign 20 octet long values 968 o Remove of RFC4566bis draft from list of normative references. 970 11.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 972 o Modification of Keith's address information. 974 11.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 976 o dcmap-stream-id syntax change to limit size to 5 digits. 978 o Add missing 'x' prefix to quoted-visible syntax. 980 o Align SDP offerer and answerer handling when both max-retr and 981 max-time are present. 983 o Use of TEST-NET-1 ip addresses in examples. 985 o Add missing a=dtls-id in one example. 987 11.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 989 o Removal of the "a=connection" attribute lines from all SDP 990 examples. 992 11.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 994 o In the introduction: 996 * Replacement of the sentence "The RTCWeb working group has 997 defined the concept of bi-directional data channels running on 998 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 999 Security protocol)" with "The RTCWeb working group has defined 1000 the concept of bi-directional data channels running on top of 1001 the Stream Control Transmission Protocol (SCTP)". 1003 * Addition of following sentences to the second paragraph: "These 1004 procedures are based on generic SDP offer/answer negotiation 1005 rules for SCTP based media transport as specified in 1006 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1007 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1008 could be defined over other SCTP based protocols, such as SCTP 1009 over IP. However, corresponding potential other "m" line proto 1010 values are not considered in this document." 1012 o Replacement of "DTLS connection" with "DTLS association" 1013 throughout the document. 1015 o In sections Section 5.1.9 and Section 5.2.2 removal of the 1016 sentences "This document also does not specify multiplexing rules 1017 for this attribute for SCTP or SCTP/DTLS proto values". 1019 o In the text related to "Subsequent SDP answer" in section 1020 Section 6.7 replacement of "The DTLS/SCTP association remains open 1021 ..." with "The SCTP association remains open ...". 1023 o In the text after the second SDP answer in section Section 7 1024 replacement of "... (after SCTP/DTLS association is setup)" with 1025 "... (after the SCTP association is set up)". 1027 o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative 1028 references. 1030 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1031 examples in Section 7. 1033 11.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1035 o Addition of definition of "data channel subprotocol" to Section 3 1036 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1037 archive/web/mmusic/current/msg15827.html. 1039 o Addition of RFC4566bis draft to list of normative references. 1041 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1042 section 8.2.4 of RFC4566bis draft. 1044 o Addition of new Section 9.3. 1046 11.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1048 o Addition of two new paragraphs to Section 5.2.1 regarding 1049 subprotocol attribute relationship with transport protocol. 1051 o Addition of a note to Section 9.1 regarding subprotocols 1052 simultaneously defined for data channel and Websocket usage. 1054 o Addition of two further SDP offer/answer considerations to 1055 Section 6.7 regarding unknown subprotocol attributes and known 1056 subprotocol attributes with unknown data channel transport related 1057 semantic. 1059 11.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1061 o Changes addressing Christian Groves's WGLC review comments raised 1062 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1063 msg15357.html and http://www.ietf.org/mail- 1064 archive/web/mmusic/current/msg15359.html. 1066 11.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1068 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1069 of contact name and e-mail address with "MMUSIC Chairs" and 1070 "mmusic-chairs@ietf.org". 1072 o In Section 5.2.1 replacement of "Thus in the example above, the 1073 original attribute line "a=accept- types:text/plain" is 1074 represented by the attribute line "a=dcsa:2 accept-types:text/ 1075 plain", which specifies that this instance of MSRP being 1076 transported on the SCTP association using the data channel with 1077 stream id 2 accepts plain text files." with "... which specifies 1078 that this instance of the MSRP subprotocol being transported ...". 1080 o The last paragraph of Section 5.2.1 started with "Note: This 1081 document does not provide a complete specification ...". Removal 1082 of "Note:" and move of this paragraph to the introduction in 1083 Section 1 as last paragraph. 1085 o Section 5.2's headline was "Subprotocol Specific Attributes". 1086 Change of this headline to "Other Media Level Attributes" and 1087 adaptations of the first paragraph of this section and the first 1088 paragraph of Section 5.2.1 in order to clarify that not only those 1089 attributes may be encapsulated in a "dcsa" attribute, which are 1090 specifically defined for the subprotocol, but that also other 1091 attributes may be encapsulated if they are related to the specific 1092 subprotocol instance. 1094 o Move of the last but one paragraph of Section 5.2.1 starting with 1095 "The same syntax applies to ..." right in front of the formal 1096 syntax definition of the "dcsa" attribute. 1098 o Modifications of the text in Section 5.1.9 and Section 5.2.2 in 1099 order not to explicitly restrict usage of the "a=dcmap:" and 1100 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1101 SCTP" or "TCP/DTLS/SCTP". 1103 11.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1105 o In Section 5.1.4 the first (and only) paragraph was "The 1106 'subprotocol' parameter indicates which protocol the client 1107 expects to exchange via the channel. 'Subprotocol' is an optional 1108 parameter. If the 'subprotocol' parameter is not present, then 1109 its value defaults to the empty string." Replacement of this 1110 paragraph with following two paragraphs: 1112 * The 'subprotocol' parameter indicates which protocol the client 1113 expects to exchange via the channel. This parameter maps to 1114 the 'Protocol' parameter defined in 1115 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1116 subprotocol parameter values are registered. 'Subprotocol' is 1117 an optional parameter. If the 'subprotocol' parameter is not 1118 present, then its value defaults to the empty string. 1120 * Note: The empty string MAY also be explicitly used as 1121 'subprotocol' value, such that 'subprotocol=""' is equivalent 1122 to the 'subprotocol' parameter not being present at all. 1123 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1124 message's 'Subprotocol' value to be an empty string. 1126 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1127 normative references. 1129 o Addition of dcmap attribute specific IANA registration 1130 Section 9.2.1. 1132 o Addition of dcsa attribute specific IANA registration 1133 Section 9.2.2. 1135 o Addition of new Section 5.1.9 describing the mux category of the 1136 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1137 related mux category section are similar to the "Mux Category" 1138 sections of the "a=sctp-port:" and "a=max-message-size:" 1139 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1141 o Addition of new Section 5.2.2 describing the mux category of the 1142 dcsa SDP attribute. 1144 11.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1146 o In Section 1 replacement of "RTCWeb leaves it open for other 1147 applications to use data channels and its in-band DCEP or out-of- 1148 band non-DCEP protocols for creating them" with "... to use data 1149 channels and its in-band DCEP or other in-band or out-of-band 1150 protocols for creating them". Additionally replacement of "In 1151 particular, the SDP offer generated by the application includes no 1152 channel-specific information" with "... generated by the RTCweb 1153 data channel stack includes no channel-specific information". 1155 o Move of former section 5 ("Data Channels") to new Appendix A and 1156 removal of JavaScript API specific discussions from this moved 1157 text (like mentioning of data channel stack specific states). 1158 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1159 Section 5. 1161 o In Section 5: 1163 * Relacement of Section 5's first paragraph "This section defines 1164 a method of non-DCEP negotiation by which two clients can 1165 negotiate data channel-specific and subprotocol-specific 1166 parameters, using the out-of-band SDP offer/answer exchange. 1167 This SDP extension can only be used with the SDP offer/answer 1168 model." with "This section defines an SDP extension by which 1169 two clients can negotiate data channel-specific and 1170 subprotocol-specific parameters without using DCEP 1171 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1172 defines usage in the context of SDP offer/answer." 1174 * Addition of new paragraph: "Appendix A provides information how 1175 data channels work in general and especially summarizes some 1176 key aspects, which should be considered for the negotiation of 1177 data channels if DCEP is not used." 1179 o In Section 5.1 replacement of "The intention of exchanging these 1180 attributes is to create data channels on both the peers with the 1181 same set of attributes without actually using the DCEP 1182 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1183 these attributes is to create, on two peers, without use of DCEP 1184 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1185 directed data channels having the same set of attributes". 1187 o In Section 5.1.5 replacement of "The 'max-retr' parameter 1188 indicates the maximal number a user message will be retransmitted" 1189 with "The 'max-retr' parameter indicates the maximal number of 1190 times a user message will be retransmitted". 1192 o In Section 6.1 replacement of "However, an SDP offer/answer 1193 exchange MUST NOT be initiated if the associated SCTP stream is 1194 already negotiated via DCEP" with "However, an SCTP stream MUST 1195 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1196 answer exchange if the associated SCTP stream has already been 1197 negotiated via DCEP". 1199 o In the examples in Section 7 addition of the previously missing 1200 colons to the "a=sctp-port" attribute lines. 1202 11.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1204 o Move of reference draft-ietf-rtcweb-jsep from the list of 1205 normative references to the list of informative references. 1206 Remover in -07 since not referenced 1208 o Addition of IANA SDP parameters to the list of informative 1209 references and addition of following two sentences to the first 1210 paragraph after the ABNF definition: "Note however that not all 1211 SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP 1212 parameters contains the lists of IANA registered session and media 1213 level or media level only SDP attributes." 1215 o In the introduction replacement of last sentence "This document 1216 defines SDP-based out-of-band negotiation procedures to establish 1217 data channels for transport of well-defined subprotocols" with 1218 "This document defines SDP offer/answer negotiation procedures to 1219 establish data channels for transport of well-defined 1220 subprotocols, to enable out-of-band negotiation". 1222 o Throughout the document replacement of "external negotiation" with 1223 "SDP offer/answer negotiation" and removal of term "external 1224 negotiation" from the terminology list in Section 3. 1226 o Throughout the document replacement of "internal negotiation" with 1227 "DCEP" and removal of terms "internal negotiation" and "in-band 1228 negotiation" from the terminology list in Section 3. 1230 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1231 terms. 1233 o In Section 6.1 replacement of sentence "However, a single stream 1234 is managed using one method at a time." with "However, an SDP 1235 offer/answer exchange MUST NOT be initiated if the associated SCTP 1236 stream is already negotiated via DCEP". 1238 o In Section 6.2 replacement of sentence "By definition max-retr and 1239 max-time are mutually exclusive, so only one of them can be 1240 present in a=dcmap" with "By definition max-retr and max-time are 1241 mutually exclusive, so aBoth MUST NOT be present in a=dcmap". 1243 o Move of reference [WebRtcAPI] from list of normative references to 1244 list of informative references. 1246 o Removal of almost all text parts, which discussed JavaScript or 1247 other API specific aspects. Such API specific aspects were mainly 1248 discussed in sub-sections of Section 5 and Section 5 of draft- 1249 ietf-mmusic-data-channel-sdpneg-02. 1251 11.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1253 o New Section 4 regarding applicability to SDP offer/answer only. 1255 o Addition of new Section 9.1 "Subprotocol identifiers" as 1256 subsection of the "IANA Considerations" related Section 9. Also 1257 removal of the temporary note "To be completed. As [I-D.ietf- 1258 rtcweb-data-protocol] this document should refer to IANA's 1259 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1261 o In Section 6.2: 1263 * In the first paragraph replacement of the sentence "If an SDP 1264 offer contains both of these parameters then such an SDP offer 1265 will be rejected." with "If an SDP offer contains both of these 1266 parameters then the receiver of such an SDP offer MUST reject 1267 the SDP offer." 1269 * In the second paragraph capitalization of "shall" and "may" 1270 such that both sentences now read: "The SDP answer SHALL echo 1271 the same subprotocol, max-retr, max-time, ordered parameters, 1272 if those were present in the offer, and MAY include a label 1273 parameter. They MAY appear in any order, which could be 1274 different from the SDP offer, in the SDP answer." 1276 * In the third paragraph replacement of the sentence "The same 1277 information MUST be replicated without changes in any 1278 subsequent offer or answer, as long as the data channel is 1279 still opened at the time of offer or answer generation." with 1280 "When sending a subsequent offer or an answer, and for as long 1281 as the data channel is still open, the sender MUST replicate 1282 the same information.". 1284 o In Section 6.2 the mapping of data channel types defined in 1285 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1286 parameters were illustrated using example "a=dcmap" attribute 1287 lines. Replacement of these example "a=dcmap" attribute lines 1288 with just the "a=dcmap" attribute parameters being relevant for 1289 the channel type. 1291 o In Section 6.7 the description of bullet point "SDP offer has no 1292 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1293 No data channel negotiated yet." Replacement of this description 1294 with "Initial SDP offer: No data channel is negotiated yet. The 1295 DTLS connection and SCTP association is negotiated and, if agreed, 1296 established as per [I-D.ietf-mmusic-sctp-sdp]." 1298 o In Section 6.7 in both bullet points related to "Subsequent SDP 1299 offer" and "Subsequent SDP answer" replacement of "All the 1300 externally negotiated data channels must be closed now." with "All 1301 the externally negotiated data channels are expected to be closed 1302 now.". 1304 o In Appendix A.2.2's sixth paragraph replacement of the two 1305 occurrences of "must" with "MUST". 1307 o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" 1308 there was a comment saying that "Only maxretr-opt or maxtime-opt 1309 is present. Both MUST NOT be present." Removal of the second 1310 normative sentence and instead addition of following new paragraph 1311 to the end of this section: "Within an 'a=dcmap' attribute line's 1312 'dcmap-opt' value only one 'maxretr-opt' parameter or one 1313 'maxtime-opt' parameter is present. Both MUST NOT be present." 1315 o In Section 5.1.7 replacement of the first sentence "The 'ordered' 1316 parameter with value "true" indicates that DATA chunks in the 1317 channel MUST be dispatched to the upper layer by the receiver 1318 while preserving the order." with "The 'ordered' parameter with 1319 value "true" indicates that the receiver MUST dispatch DATA chunks 1320 in the data channel to the upper layer while preserving the 1321 order.". 1323 o In Section 6.3's first paragraph replacement of the one occurrence 1324 of "must" with "..., it MUST wait until ...". 1326 o In Section 6.6.1: 1328 * In the second paragraph replacement of "must" with "... whether 1329 this closing MUST in addition ..." 1331 * In the third paragraph replacement of the sentence "The port 1332 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1333 when closing a data channel ..." with "The offerer SHOULD NOT 1334 change the port value for the "m" line (e.g., to zero) when 1335 closing a data channel ...". 1337 * In the last but two paragraph replacement of the sentence "... 1338 then an SDP offer which excludes this closed data channel 1339 SHOULD be generated." with "... then the client SHOULD generate 1340 an SDP offer which excludes this closed data channel.". 1342 * In the last but one paragraph replacement of "must" with "The 1343 application MUST also close...". 1345 o In Section 5.2 addition of following note after the formal 1346 definition of the 'a=dcsa' attribute: "Note that the above 1347 reference to RFC 4566 defines were the attribute definition can be 1348 found; it does not provide any limitation on support of attributes 1349 defined in other documents in accordance with this attribute 1350 definition." 1352 11.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1354 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1355 channel consisting of paired SCTP outbound and inbound streams." 1356 Replacement of this definition with "Data channel: A WebRTC data 1357 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1358 consistent usage of "data channel" in the remainder of the 1359 document including the document's headline." 1361 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1362 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1363 In particular we expect "webrtc-datachannel" to become a more 1364 general term.' 1366 o Consistent usage of '"m" line' in whole document as per RFC4566. 1368 o In Section 5.1 removal of the example dcmap attribute line 1369 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1370 already four examples right after the ABNF rules in Section 5.1.1. 1371 Corresponding removal of following related note: "Note: This 1372 document does not provide a complete specification of how to 1373 negotiate the use of a WebRTC data channel to transport BFCP. 1374 Procedures specific to each subprotocol such as BFCP will be 1375 documented elsewhere. The use of BFCP is only an example of how 1376 the generic procedures described herein might apply to a specific 1377 subprotocol." 1379 o In Section 5.1 removal of following note: "Note: This attribute is 1380 derived from attribute "webrtc-DataChannel", which was defined in 1381 old version 03 of the following draft, but which was removed along 1382 with any support for SDP external negotiation in subsequent 1383 versions: [I-D.ietf-mmusic-sctp-sdp]." 1385 o Insertion of following new sentence to the beginning of 1386 Section 5.1.1: "dcmap is a media level attribute having following 1387 ABNF syntax:" 1389 o Insertion of new Section 5.1.2 containing the dcmap-stream-id 1390 specifying sentence, which previously was placed right before the 1391 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1392 parameter and is noted directly after the "a=dcmap:" attribute's 1393 colon' as this information is part of the ABNF specification. 1395 o In Section 5.1.1 modification of the 'ordering-value' values from 1396 "0" or "1" to "true" or "false". Corresponding text modifications 1397 in Section 5.1.7. 1399 o In Section 5.1.1 the ABNF definition of "quoted-string" referred 1400 to rule name "escaped-char", which was not defined. Instead a 1401 rule with name "escaped" was defined. Renamed that rule's name to 1402 "escaped-char". 1404 o Insertion of a dedicated note right after the "a=dcmap:4" 1405 attribute example in Section 5.1.1 regarding the non-printable 1406 "escaped-char" character within the "label" value. 1408 o In Section 5.2's second paragraph replacement of "sctp stream 1409 identifier" with "SCTP stream identifier". 1411 o In first paragraph of Section 6.1 replacement of first two 1412 sentences 'For the SDP-based external negotiation described in 1413 this document, the initial offerer based "SCTP over DTLS" owns by 1414 convention the even stream identifiers whereas the initial 1415 answerer owns the odd stream identifiers. This ownership is 1416 invariant for the whole lifetime of the signaling session, e.g. it 1417 does not change if the initial answerer sends a new offer to the 1418 initial offerer.' with 'If an SDP offer/answer exchange (could be 1419 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1420 TCP/DTLS/SCTP based media description being accepted, and if this 1421 SDP offer/answer exchange results in the establishment of a new 1422 SCTP association, then the SDP offerer owns the even SCTP stream 1423 ids of this new SCTP association and the answerer owns the odd 1424 SCTP stream identifiers. If this "m" line is removed from the 1425 signaling session (its port number set to zero), and if usage of 1426 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1427 renegotiated later on, then the even and odd SCTP stream 1428 identifier ownership is redetermined as well as described above.' 1430 o In Section 6.3 the first action of an SDP answerer, when receiving 1431 an SDP offer, was described as "Applies the SDP offer. Note that 1432 the browser ignores data channel specific attributes in the SDP." 1433 Replacement of these two sentences with "Parses and applies the 1434 SDP offer. Note that the typical parser normally ignores unknown 1435 SDP attributes, which includes data channel related attributes." 1437 o In Section 6.3 the second sentence of the third SDP answerer 1438 action was "Note that the browser is asked to create data channels 1439 with stream identifiers not "owned" by the agent.". Replacement 1440 of this sentence with "Note that the agent is asked to create data 1441 channels with SCTP stream identifiers contained in the SDP offer 1442 if the SDP offer is accepted." 1444 o In Section 6.6.1 the third paragraph began with "A data channel 1445 can be closed by sending a new SDP offer which excludes the dcmap 1446 and dcsa attribute lines for the data channel. The port value for 1447 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1448 data channel (unless all data channels are being closed and the 1449 SCTP association is no longer needed), since this would close the 1450 SCTP association and impact all of the data channels. If the 1451 answerer accepts the SDP offer then it MUST also exclude the 1452 corresponding attribute lines in the answer. ..." Replacement of 1453 this part with "The intention to close a data channel can be 1454 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1455 and "a=dcsa:" attribute lines for the data channel. The port 1456 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1457 closing a data channel (unless all data channels are being closed 1458 and the SCTP association is no longer needed), since this would 1459 close the SCTP association and impact all of the data channels. 1460 If the answerer accepts the SDP offer then it MUST close those 1461 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1462 excluded from the received SDP offer, unless those data channels 1463 were already closed, and it MUST also exclude the corresponding 1464 attribute lines in the answer." 1466 o In Section 6.6.1 the hanging text after the third paragraph was 1467 "This delayed close is to handle cases where a successful SDP 1468 answer is not received, in which case the state of session should 1469 be kept per the last successful SDP offer/answer." Replacement of 1470 this sentence with "This delayed closure is RECOMMENDED in order 1471 to handle cases where a successful SDP answer is not received, in 1472 which case the state of the session SHOULD be kept per the last 1473 successful SDP offer/answer." 1475 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1476 Section 5.1 contained already procedural descriptions related to 1477 data channel reliability negotiation. Creation of new Section 6.2 1478 and moval of reliability negotiation related text to this new 1479 section. 1481 11.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1483 o Removal of note "ACTION ITEM" from section "subprotocol 1484 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1485 should refer to IANA's WebSocket Subprotocol Name Registry defined 1486 in [RFC6455] 1488 o In whole document, replacement of "unreliable" with "partially 1489 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1490 [I-D.ietf-rtcweb-data-protocol] in most places. 1492 o Clarification of the semantic if the "max-retr" parameter is not 1493 present in an "a=dcmap" attribute line. In section "max-retr 1494 parameter" the sentence "The max-retr parameter is optional with 1495 default value unbounded" was replaced with "The max-retr parameter 1496 is optional. If the max-retr parameter is not present, then the 1497 maximal number of retransmissions is determined as per the generic 1498 SCTP retransmission rules as specified in [RFC4960]". 1500 o Clarification of the semantic if the "max-time" parameter is not 1501 present in an "a=dcmap" attribute line. In section "max-time 1502 parameter" the sentence "The max-time parameter is optional with 1503 default value unbounded" was replaced with "The max-time parameter 1504 is optional. If the max-time parameter is not present, then the 1505 generic SCTP retransmission timing rules apply as specified in 1506 [RFC4960]". 1508 o In section "label parameter" the sentence "Label is a mandatory 1509 parameter." was removed and following new sentences (including the 1510 note) were added: "The 'label' parameter is optional. If it is 1511 not present, then its value defaults to the empty string. Note: 1512 The empty string may also be explicitly used as 'label' value, 1513 such that 'label=""' is equivalent to the 'label' parameter not 1514 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1515 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1517 o In section "subprotocol parameter" the sentence "Subprotocol is a 1518 mandatory parameter." was replaced with "'Subprotocol' is an 1519 optional parameter. If the 'subprotocol' parameter is not 1520 present, then its value defaults to the empty string." 1522 o In the "Examples" section, in the first two SDP offer examples in 1523 the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 1524 'label="BFCP"'. 1526 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1527 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1528 replaced with "a=max-message-size" attribute lines, as per draft- 1529 ietf-mmusic-sctp-sdp-12. 1531 11.17. Changes against '-01' 1533 o Formal syntax for dcmap and dcsa attribute lines. 1535 o Making subprotocol as an optional parameter in dcmap. 1537 o Specifying disallowed parameter combinations for max-time and max- 1538 retr. 1540 o Clarifications on WebRTC data channel close procedures. 1542 11.18. Changes against '-00' 1544 o Revisions to identify difference between internal and external 1545 negotiation and their usage. 1547 o Introduction of more generic terminology, e.g. "application" 1548 instead of "browser". 1550 o Clarification of how "max-retr and max-time affect the usage of 1551 unreliable and reliable WebRTC data channels. 1553 o Updates of examples to take into account the SDP syntax changes 1554 introduced with draft-ietf-mmusic-sctp-sdp-07. 1556 o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" 1557 attributes as this is now contained in the a=sctp-port attribute, 1558 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1559 association on top of the DTLS connection. 1561 12. References 1563 12.1. Normative References 1565 [I-D.ietf-mmusic-rfc4566bis] 1566 Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1567 Session Description Protocol", draft-ietf-mmusic- 1568 rfc4566bis-32 (work in progress), December 2018. 1570 [I-D.ietf-mmusic-sctp-sdp] 1571 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1572 "Session Description Protocol (SDP) Offer/Answer 1573 Procedures For Stream Control Transmission Protocol (SCTP) 1574 over Datagram Transport Layer Security (DTLS) Transport.", 1575 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1576 2017. 1578 [I-D.ietf-mmusic-sdp-mux-attributes] 1579 Nandakumar, S., "A Framework for SDP Attributes when 1580 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1581 (work in progress), February 2018. 1583 [I-D.ietf-rtcweb-data-channel] 1584 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1585 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1586 progress), January 2015. 1588 [I-D.ietf-rtcweb-data-protocol] 1589 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1590 Establishment Protocol", draft-ietf-rtcweb-data- 1591 protocol-09 (work in progress), January 2015. 1593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1594 Requirement Levels", BCP 14, RFC 2119, 1595 DOI 10.17487/RFC2119, March 1997, 1596 . 1598 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1599 with Session Description Protocol (SDP)", RFC 3264, 1600 DOI 10.17487/RFC3264, June 2002, 1601 . 1603 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1604 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1605 . 1607 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1608 Specifications: ABNF", STD 68, RFC 5234, 1609 DOI 10.17487/RFC5234, January 2008, 1610 . 1612 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1613 Transmission Protocol (SCTP) Stream Reconfiguration", 1614 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1615 . 1617 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1618 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1619 May 2017, . 1621 12.2. Informative References 1623 [I-D.ietf-clue-datachannel] 1624 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1625 clue-datachannel-15 (work in progress), August 2018. 1627 [I-D.ietf-mmusic-msrp-usage-data-channel] 1628 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1629 Marcon, J., and J. Recio, "MSRP over Data Channels", 1630 draft-ietf-mmusic-msrp-usage-data-channel-09 (work in 1631 progress), May 2018. 1633 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1634 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1635 November 2006, . 1637 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1638 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1639 DOI 10.17487/RFC4975, September 2007, 1640 . 1642 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1643 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1644 . 1646 [WebRtcAPI] 1647 Bergkvist, A., Burnett, D., Jennings, C., and A. 1648 Narayanan, "WebRTC 1.0: Real-time Communication Between 1649 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1650 February 2015, 1651 . 1653 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1654 DCEP 1656 This appendix summarizes how data channels work in general and 1657 discusses some key aspects, which should be considered for the out- 1658 of-band negotiation of data channels if DCEP is not used. 1660 A WebRTC application creates a data channel by providing a number of 1661 setup parameters (subprotocol, label, maximal number of 1662 retransmissions, maximal retransmission time, order of delivery, 1663 priority). The application also specifies if it wants to make use of 1664 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1665 the application intends to negotiate data channels using the SDP 1666 offer/answer protocol. 1668 In any case, the SDP offer generated by the application is per 1669 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1670 the SCTP association on top of which data channels will run: 1672 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1673 c=IN IP4 192.0.2.1 1674 a=max-message-size:100000 1675 a=sctp-port:5000 1676 a=tls-id:abc3de65cddef001be82 1677 a=setup:actpass 1678 a=fingerprint:SHA-1 \ 1679 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1681 Note: A WebRTC application will only use "m" line format "webrtc- 1682 datachannel", and will not use other formats in the "m" line for 1683 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1684 only one SCTP association to be established on top of a DTLS 1685 association. 1687 Note: The above SDP media description does not contain any channel- 1688 specific information. 1690 A.1. Stream Identifier Numbering 1692 Independently from the requested type of negotiation, the application 1693 creating a data channel can either pass the stream identifier to the 1694 data channel stack to assign to the data channel or else let the data 1695 channel stack pick one identifier from the unused ones. 1697 To avoid glare situations, each endpoint can moreover own an 1698 exclusive set of stream identifiers, in which case an endpoint can 1699 only create a data channel with a stream identifier it owns. 1701 Which set of stream identifiers is owned by which endpoint is 1702 determined by convention or other means. 1704 Note:For data channels negotiated with the DCEP, one endpoint owns 1705 by convention the even stream identifiers, whereas the other owns 1706 the odd stream identifiers, as defined in 1707 [I-D.ietf-rtcweb-data-protocol]. 1709 Note:For data channels negotiated via different protocol from 1710 DCEP, no convention is defined by default. 1712 A.2. Generic Data Channel Negotiation Not Using DCEP 1714 A.2.1. Overview 1716 DCEP negotiation only provides for negotiation of data channel 1717 transport parameters and does not provide for negotiation of 1718 subprotocol specific parameters. DCEP-less data channel negotiation 1719 can be defined to allow negotiation of parameters beyond those 1720 handled by DCEP, e.g., parameters specific to the subprotocol 1721 instantiated on a particular data channel. 1723 The following procedures are common to all methods of data channel 1724 negotiation not using DCEP, whether in-band (communicated using 1725 proprietary means on an already established data channel) or out-of- 1726 band (using SDP offer/answer or some other protocol associated with 1727 the signaling channel). 1729 A.2.2. Opening a Data Channel 1731 In the case of DCEP-less negotiation, the endpoint application has 1732 the option to fully control the stream identifier assignments. 1733 However these assignments have to coexist with the assignments 1734 controlled by the data channel stack for the DCEP negotiated data 1735 channels (if any). It is the responsibility of the application to 1736 ensure consistent assignment of stream identifiers. 1738 When the application requests the creation of a new data channel to 1739 be set up via DCEP-less negotiation, the data channel stack creates 1740 the data channel locally without sending any DATA_CHANNEL_OPEN 1741 message in-band. However, even if the ICE (Interactive Connectivity 1742 Establishment), DTLS and SCTP procedures were already successfully 1743 completed, the application can't send data on this data channel until 1744 the negotiation is complete with the peer. This is because the peer 1745 needs to be aware of and accept the usage of this data channel. The 1746 peer, after accepting the data channel offer, can start sending data 1747 immediately. This implies that the offerer may receive data channel 1748 subprotocol messages before the negotiation is complete and the 1749 application should be ready to handle it. 1751 If the peer rejects the data channel part of the offer then it 1752 doesn't have to do anything as the data channel was not created using 1753 the stack. The offerer on the other hand needs to close the data 1754 channel that was opened by invoking relevant data channel stack API 1755 procedures. 1757 It is also worth noting that a data channel stack implementation may 1758 not provide any API to create and close data channels; instead the 1759 data channels may be used on the fly as needed just by communicating 1760 via non-DCEP means or by even having some local configuration/ 1761 assumptions on both the peers. 1763 The application then negotiates the data channel properties and 1764 subprotocol properties with the peer's application using a mechanism 1765 different from DCEP. 1767 The peer then symmetrically creates a data channel with these 1768 negotiated data channel properties. This is the only way for the 1769 peer's data channel stack to know which properties to apply when 1770 transmitting data on this channel. The data channel stack must allow 1771 data channel creation with any non-conflicting stream identifier so 1772 that both peers can create the data channel with the same stream 1773 identifier. 1775 A.2.3. Closing a Data Channel 1777 When the application requests the closing of a data channel 1778 negotiated without DCEP, the data channel stack always performs an 1779 SCTP SSN reset for this channel. 1781 Depending upon the method used for DCEP-less negotiation and the 1782 subprotocol associated with the data channel, the closing might in 1783 addition be signaled to the peer via SDP offer/answer negotiation. 1785 Authors' Addresses 1787 Keith Drage 1788 Unaffiliated 1790 Email: drageke@ntlworld.com 1791 Maridi R. Makaraju (Raju) 1792 Nokia 1793 2000 Lucent Lane 1794 Naperville, Illinois 1795 US 1797 Email: Raju.Makaraju@nokia.com 1799 Juergen Stoetzer-Bradler 1800 Unaffiliated 1802 Email: Juergen.S-B.ietf@email.de 1804 Richard Ejzak 1805 Unaffiliated 1807 Email: richard.ejzak@gmail.com 1809 Jerome Marcon 1810 Unaffiliated 1812 Email: jeromee.marcon@free.fr 1814 Roni Even (editor) 1815 Huawei 1817 Email: roni.even@huawei.com