idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-18.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 date (May 1, 2018) is 2186 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 (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-14 == Outdated reference: A later version (-24) exists of draft-ietf-mmusic-msrp-usage-data-channel-08 -- Obsolete informational reference (is this intentional?): RFC 4582 (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track M. Makaraju 5 Expires: November 2, 2018 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 R. Even, Ed. 11 Huawei 12 May 1, 2018 14 SDP-based Data Channel Negotiation 15 draft-ietf-mmusic-data-channel-sdpneg-18 17 Abstract 19 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 20 charged to provide protocols to support direct interactive rich 21 communications using audio, video, and data between two peers' web- 22 browsers. For the support of data communication, the RTCWeb working 23 group has in particular defined the concept of bi-directional data 24 channels over SCTP (Stream Control Transmission Protocol), where each 25 data channel might be used to transport other protocols, called 26 subprotocols. Data channel setup can be done using either the in- 27 band Data Channel Establishment Protocol (DCEP) or using some out-of- 28 band non-DCEP protocol. This document specifies how the SDP (Session 29 Description Protocol) offer/answer exchange can be used to achieve 30 such an out-of-band non-DCEP negotiation. Even though data channels 31 are designed for RTCWeb use initially, they may be used by other 32 protocols like, but not limited to, the CLUE protocol (which is 33 defined by the IETF "ControLling mUltiple streams for tElepresence" 34 working group). This document is intended to be used wherever data 35 channels are used. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on November 2, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 75 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 76 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 77 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 7 78 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 79 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 80 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 81 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 82 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 83 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 84 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 10 85 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 86 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 87 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 88 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 89 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 90 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 12 91 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 92 6.3. Generating Initial Offer . . . . . . . . . . . . . . . . 14 93 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 94 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 95 6.6. Subsequent Offers . . . . . . . . . . . . . . . . . . . . 16 96 6.6.1. Adding a Data Channel . . . . . . . . . . . . . . . . 16 97 6.6.2. Closing a Data Channel . . . . . . . . . . . . . . . 16 98 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 17 99 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 103 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21 104 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21 105 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22 106 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 108 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 11.1. Changes against 'draft-ietf-mmusic-data-channel- 110 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 23 111 11.2. Changes against 'draft-ietf-mmusic-data-channel- 112 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 23 113 11.3. Changes against 'draft-ietf-mmusic-data-channel- 114 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 23 115 11.4. Changes against 'draft-ietf-mmusic-data-channel- 116 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 23 117 11.5. Changes against 'draft-ietf-mmusic-data-channel- 118 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 24 119 11.6. Changes against 'draft-ietf-mmusic-data-channel- 120 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 24 121 11.7. Changes against 'draft-ietf-mmusic-data-channel- 122 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 25 123 11.8. Changes against 'draft-ietf-mmusic-data-channel- 124 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25 125 11.9. Changes against 'draft-ietf-mmusic-data-channel- 126 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 25 127 11.10. Changes against 'draft-ietf-mmusic-data-channel- 128 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 25 129 11.11. Changes against 'draft-ietf-mmusic-data-channel- 130 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 26 131 11.12. Changes against 'draft-ietf-mmusic-data-channel- 132 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27 133 11.13. Changes against 'draft-ietf-mmusic-data-channel- 134 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 135 11.14. Changes against 'draft-ietf-mmusic-data-channel- 136 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 29 137 11.15. Changes against 'draft-ietf-mmusic-data-channel- 138 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 31 139 11.16. Changes against 'draft-ejzak-mmusic-data-channel- 140 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 34 141 11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 35 142 11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 35 143 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 144 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 145 12.2. Informative References . . . . . . . . . . . . . . . . . 37 146 Appendix A. Generic Data Channel Negotiation Aspects When Not 147 Using DCEP . . . . . . . . . . . . . . . . . . . . . 38 148 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 39 149 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39 150 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39 151 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39 152 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 155 1. Introduction 157 The RTCWeb working group has defined the concept of bi-directional 158 data channels running on top of the Stream Control Transmission 159 Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows 160 applications to use data channels. RTCWeb defines an in-band Data 161 Channel Establishment Protocol (DCEP) 162 [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band 163 protocols may be used for establishing data channels. Each data 164 channel consists of paired SCTP streams sharing the same SCTP Stream 165 Identifier. Data channels are created by endpoint applications 166 through the WebRTC API (Application Programming Interface), or other 167 users of a data channel like CLUE [I-D.ietf-clue-datachannel] They 168 can be used to transport proprietary or well-defined protocols, which 169 in the latter case can be signaled by the data channel "subprotocol" 170 parameter, conceptually similar to the WebSocket "subprotocol". 171 However, apart from the "subprotocol" value transmitted to the peer, 172 RTCWeb leaves it open how endpoint applications can agree on how to 173 instantiate a given subprotocol on a data channel, and whether it is 174 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 175 (or both). In particular, the SDP offer generated by the RTCweb data 176 channel stack includes no channel-specific information. 178 This document defines SDP offer/answer [RFC3264] procedures that 179 enable out-of-band negotiation for establishing data channels for 180 transport of well-defined subprotocols. These procedures are based 181 on generic SDP offer/answer negotiation rules for SCTP based media 182 transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" 183 line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. 185 This document makes use of MSRP (Message Session Relay Protocol) 186 [RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many 187 of the examples. It does not provide a complete specification of how 188 to negotiate the use of a data channel to transport MSRP. Procedures 189 specific to each subprotocol would have to be documented elsewhere. 190 For MSRP they are documented in 191 [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some 192 examples is only to show how the generic procedures described herein 193 might apply to a specific subprotocol. 195 2. Conventions 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 3. Terminology 203 This document uses the following terms: 205 Data channel: A WebRTC data channel as specified in 206 [I-D.ietf-rtcweb-data-channel]. 208 Data channel stack: An entity which, upon application request, 209 runs the data channel protocol to keep track of states, sending 210 and receiving data. If the application is a browser based 211 JavaScript application then this stack resides in the browser. If 212 the application is a native application then this stack resides in 213 the application and is accessible via some sort of APIs. 215 Data channel properties: Fixed properties assigned to a data 216 channel at the time of its creation. Some of these properties 217 determine the way the data channel stack transmits data on this 218 channel (e.g., stream identifier, reliability, order of 219 delivery...). 221 Data channel subprotocol: The application protocol which is 222 transported over a single data channel. Data channel subprotocol 223 messages are sent as data channel payload over an established data 224 channel. If an SDP offer/answer exchange is used as specified in 225 this document to negotiate the establishment of data channels, 226 corresponding data channel properties, associated data channel 227 subprotocols and data channel subprotocol properties, then the 228 data channel subprotocols may be identified by the values of the 229 "subprotocol" parameters of the SDP "a=dcmap" attribute as 230 described in Section 5.1.4. Within this document the term "data 231 channel subprotocol" is often abbreviated as just "subprotocol". 233 DCEP: Data Channel Establishment Protocol defined in 234 [I-D.ietf-rtcweb-data-protocol]. 236 In-band: Transmission through the peer-to-peer SCTP association. 238 Out-of-band: Transmission through the application signaling path. 240 Peer: From the perspective of one of the agents in a session, its 241 peer is the other agent. Specifically, from the perspective of 242 the SDP offerer, the peer is the SDP answerer. From the 243 perspective of the SDP answerer, the peer is the SDP offerer. 245 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 246 as specified in [RFC4960]. 248 Stream identifier: The identifier of the outbound and inbound SCTP 249 streams composing a data channel. 251 4. Applicability Statement 253 The mechanism in this document only applies to the Session 254 Description Protocol (SDP) [RFC4566], when used together with the SDP 255 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 256 scope of this document, and is thus undefined. 258 5. SDP Data Channel Attributes 260 This sections defines two new SDP media-level attributes, that can be 261 used together with the SDP Offer/Answer mechanism to negotiate data 262 channel-specific and subprotocol-specific parameters, without the 263 usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute 264 provides for negotiation of channel-specific parameters. The second 265 attribute provides for negotiation of subprotocol-specific 266 parameters. 268 Note: Appendix A provides information how data channels work in 269 general and especially summarizes some key aspects, which should be 270 considered for the negotiation of data channels if DCEP is not used. 272 5.1. SDP DCMAP Attribute 274 This section defines a new media level attribute "a=dcmap:" that 275 defines the data channel parameters for each data channel to be 276 negotiated. 278 The attribute is used to create, on two peers matched data channels 279 as pairs of oppositely directed SCTP streams having the same set of 280 attributes. It is assumed that the data channel properties 281 (reliable/partially reliable, ordered/unordered) are suitable per the 282 subprotocol transport requirements. 284 5.1.1. DCMAP Attribute Syntax 286 "a=dcmap:" is a media level attribute having the following ABNF 287 (Augmented Backus-Naur Form, [RFC5234]) syntax. 289 Formal Syntax: 291 Name: dcmap 293 Value: dcmap-value 295 Usage Level: media 297 Charset Dependent: no 299 Syntax: 301 dcmap-value = dcmap-stream-id 302 [ SP dcmap-opt *(";" dcmap-opt) ] 303 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 304 / maxretr-opt / maxtime-opt / priority-opt 305 ; Either only maxretr-opt or maxtime-opt 306 ; is present. 308 dcmap-stream-id = 1*5DIGIT 309 ordering-opt = "ordered=" ordering-value 310 ordering-value = "true" / "false" 311 subprotocol-opt = "subprotocol=" quoted-string 312 label-opt = "label=" quoted-string 313 maxretr-opt = "max-retr=" maxretr-value 314 maxretr-value = "0" / integer 315 ; number of retransmissions, 316 ; less than 2^32, 317 ; derived from 'Reliability Parameter' of 318 ; [I-D.ietf-rtcweb-data-protocol] 319 maxtime-opt = "max-time=" maxtime-value 320 maxtime-value = "0" / integer 321 ; milliseconds, 322 ; less than 2^32, 323 ; derived from 'Reliability Parameter' of 324 ; [I-D.ietf-rtcweb-data-protocol] 325 priority-opt = "priority=" priority-value 326 priority-value = "0" / integer 327 ; unsigned integer value indicating the priority of 328 ; the data channel, 329 ; less than 2^16, 330 ; derived from 'Priority' of 331 ; [I-D.ietf-rtcweb-data-protocol] 333 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 334 quoted-char = SP / quoted-visible 335 quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 336 escaped-char = "%" HEXDIG HEXDIG 337 DQUOTE = 338 integer = 340 Examples: 342 a=dcmap:0 343 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 344 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 345 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 346 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 348 Note: The last example (a=dcmap:4) shows a 'label' parameter value 349 which contains one non-printable 'escaped-char' character (the 350 tabulator character). 352 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 353 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 354 present. Both MUST NOT be present. 356 5.1.2. Dcmap-stream-id Parameter 358 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 359 within the SCTP association used to form the data channel. 361 5.1.3. Label Parameter 363 The 'label' parameter indicates the name of the channel. It 364 represents a label that can be used to distinguish, in the context of 365 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 366 RTCDataChannel objects. This parameter maps to the 'Label' parameter 367 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 368 optional. If it is not present, then its value defaults to the empty 369 string. 371 Note: The empty string MAY also be explicitly used as a 'label' 372 value, such that 'label=""' is equivalent to the 'label' parameter 373 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 374 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 376 5.1.4. Subprotocol Parameter 378 The 'subprotocol' parameter indicates which protocol the client 379 expects to exchange via the channel. This parameter maps to the 380 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 382 Section 9.1 specifies how new subprotocol parameter values are 383 registered. 'Subprotocol' is an optional parameter. If the 384 'subprotocol' parameter is not present, then its value defaults to an 385 empty string. 387 Note: The empty string MAY also be explicitly used as 'subprotocol' 388 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 389 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 390 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 391 empty string. 393 5.1.5. Max-retr Parameter 395 This parameter indicates that the data channel is partially reliable. 396 The 'max-retr' parameter indicates the maximal number of times a user 397 message will be retransmitted. The max-retr parameter is optional. 398 If the max-retr parameter is not present, then the maximal number of 399 retransmissions is determined as per the generic SCTP retransmission 400 rules as specified in [RFC4960]. This parameter maps to the 'Number 401 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 403 5.1.6. Max-time Parameter 405 This parameter indicates that the data channel is partially reliable. 406 A user message will no longer be transmitted or retransmitted after a 407 specified life-time given in milliseconds in the 'max-time' 408 parameter. The max-time parameter is optional. If the max-time 409 parameter is not present, then the generic SCTP retransmission timing 410 rules apply as specified in [RFC4960]. This parameter maps to the 411 'Lifetime in ms' parameter defined in 412 [I-D.ietf-rtcweb-data-protocol]. 414 5.1.7. Ordered Parameter 416 The 'ordered' parameter with value "true" indicates that the receiver 417 MUST dispatch DATA chunks in the data channel to the upper layer 418 while preserving the order. The ordered parameter is optional and 419 takes two values: "true" for ordered and "false" for unordered 420 delivery with "true" as the default value. Any other value is 421 ignored and default "ordered=true" is assumed. In the absence of 422 this parameter "ordered=true" is assumed. This parameter maps to the 423 ordered or unordered data channel types as defined in 424 [I-D.ietf-rtcweb-data-protocol]. 426 5.1.8. Priority Parameter 428 The 'priority' parameter indicates the data channel's priority 429 relative to the priorities of other data channels, which may 430 additionally exist over the same SCTP association. The 'priority' 431 parameter maps to the 'Priority' parameter defined in 432 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 433 optional. In the absence of this parameter "priority=256" is 434 assumed. 436 5.1.9. DCMAP Multiplexing Category 438 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the 439 "a=dcmap:" attribute is SPECIAL. 441 As the usage of multiple SCTP associations on top of a single DTLS 442 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 443 "a=dcmap:" attribute multiplexing rules are specified for the 444 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 445 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 446 multiple SCTP associations on top of a single DTLS association, or 447 how to add multiple SCTP associations to one BUNDLE group, then 448 multiplexing rules for the "a=dcmap:" attribute need to be defined as 449 well, for instance in an extension of this SDP offer/answer based 450 data channel negotiation specification. 452 5.2. SDP DCSA Attribute 454 In the SDP media description, each data channel declaration MAY also 455 be followed by other media level SDP attributes, which are either 456 specifically defined for or applied to the subprotocol in use. Each 457 of these attributes is represented by one new attribute line, and it 458 includes the contents of a media-level SDP attribute already defined 459 for use with this (sub)protocol in another IETF (Internet Engineering 460 Task Force) document. Subprotocol specific attributes MAY also be 461 defined for exclusive use with data channel transport, but MUST use 462 the same syntax described here for other subprotocol related 463 attributes. 465 Each SDP attribute, related to the subprotocol, that would normally 466 be used to negotiate the subprotocol using SDP offer/answer is 467 replaced with an attribute of the form "a=dcsa:stream-id original- 468 attribute", where dcsa stands for "data channel subprotocol 469 attribute", stream-id is the SCTP stream identifier assigned to this 470 subprotocol instance, and original-attribute represents the contents 471 of the subprotocol related attribute to be included. 473 The same syntax applies to any other SDP attribute required for 474 negotiation of this instance of the subprotocol. 476 5.2.1. DCSA Syntax 478 Formal Syntax: 480 Name: dcsa 482 Value: dcsa-value 484 Usage Level: media 486 Charset Dependent: no 488 Syntax: 490 dcsa-value = stream-id SP attribute 491 attribute = 493 Example: 495 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 497 a=dcsa:2 accept-types:text/plain 499 Note that the above reference to [RFC4566] defines where the 500 attribute definition can be found; it does not provide any limitation 501 on support of attributes defined in other documents in accordance 502 with this attribute definition. Note however that not all SDP 503 attributes are suitable as a "a=dcsa:" parameter. 504 [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned 505 Numbers Authority) registered session and media level or media level 506 only SDP attributes. 508 Thus in the example above, the original attribute line "a=accept- 509 types:text/plain" is represented by the attribute line "a=dcsa:2 510 accept-types:text/plain", which specifies that this instance of the 511 MSRP subprotocol being transported on the SCTP association using the 512 data channel with stream id 2 accepts plain text files. 514 As opposed to the data channel "a=dcmap:" attribute parameters, these 515 parameters are subject to offer/answer negotiation following the 516 procedures defined in the subprotocol specific documents. 518 It is assumed that in general the usages of subprotocol related media 519 level attributes are independent from the subprotocol's transport 520 protocol. Such transport protocol independent subprotocol related 521 attributes are used in the same way as defined in the original 522 subprotocol specification, also if the subprotocol is transported 523 over a data channel and if the attribute is correspondingly embedded 524 in a "a=dcsa" attribute. 526 There may be cases, where the usage of a subprotocol related media 527 level attribute depends on the subprotocol's transport protocol. In 528 such cases the subprotocol related usage of the attribute is expected 529 to be described for the data channel transport. A data channel 530 specific usage of a subprotocol attribute is expected to be specified 531 in the same document that registers the subprotocol's identifier for 532 data channel usage as described in Section 9.1. 534 5.2.2. DCSA Multiplexing Category 536 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 538 As the usage of multiple SCTP associations on top of a single DTLS 539 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 540 "a=dcsa:" attribute multiplexing rules are specified for the 541 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 542 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 543 multiple SCTP associations on top of a single DTLS association, or 544 how to add multiple SCTP associations to one BUNDLE group, then 545 multiplexing rules for the "a=dcsa:" attribute need to be defined as 546 well, for instance in an extension of this SDP based data channel 547 negotiation specification. 549 6. SDP Offer/Answer Procedures 551 6.1. Managing Stream Identifiers 553 If a SDP offer/answer exchange (could be the initial or a subsequent 554 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 555 description being accepted, and if this SDP offer/answer exchange 556 results in the establishment of a new SCTP association, then the SDP 557 offerer owns the even SCTP stream ids of this new SCTP association 558 and the answerer owns the odd SCTP stream identifiers. If this "m" 559 line is removed from the signaling session (its port number set to 560 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 561 SCTP based "m" line is renegotiated later on, then the even and odd 562 SCTP stream identifier ownership is re-determined as described above. 564 This document allows simultaneous use of SDP offer/answer and DCEP 565 negotiation. However, an SCTP stream MUST NOT be referenced in a 566 "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if 567 the associated SCTP stream has already been negotiated via DCEP. 568 Stream ids that are not currently used in SDP offer/answer can be 569 used for DCEP negotiation. Stream id allocation per SDP offer/answer 570 negotiation may not align with DTLS role based allocation. This 571 could cause glare conditions when one side tries to do SDP offer/ 572 answer negotiation on a stream id while the other end tries to open a 573 data channel on the same stream id using DCEP negotiation. To avoid 574 these glare conditions this document recommends that the data channel 575 stack user always selects stream ids per the above described SDP 576 offer/answer rule even when DCEP negotiation is used. To avoid glare 577 conditions, it is possible to come up with a different stream id 578 allocation scheme, but such schemes are outside the scope of this 579 document. 581 6.2. Negotiating Data Channel Parameters 583 Conveying a reliable data channel is achieved by including neither 584 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 585 "a=dcmap:" attribute line. Conveying a partially reliable data 586 channel is achieved by including only one of 'max-retr' or 'max- 587 time'. By definition max-retr and max-time are mutually exclusive, 588 so at most one of them MAY be present in the "a=dcmap:" attribute 589 line. If a SDP offer contains both of these parameters then the 590 receiver of such an SDP offer MUST reject the SDP offer. If a SDP 591 answer contains both of these parameters then the offerer MUST treat 592 the associated SDP offer/answer failed and take appropriate recovery 593 actions. These recovery options are outside the scope of this 594 document. 596 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 597 ordered parameters, if those were present in the offer, and MAY 598 include a label parameter. They MAY appear in any order, which could 599 be different from the SDP offer, in the SDP answer. 601 When sending a subsequent offer or an answer, and for as long as the 602 data channel is still open, the sender MUST replicate the same 603 information. 605 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 606 mapped to SDP media description in the following manner, where 607 "ordered=true" is the default and may be omitted: 609 DATA_CHANNEL_RELIABLE 610 ordered=true 612 DATA_CHANNEL_RELIABLE_UNORDERED 613 ordered=false 615 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 616 ordered=true;max-retr= 618 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 619 ordered=false;max-retr= 621 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 622 ordered=true;max-time= 624 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 625 ordered=false;max-time= 627 6.3. Generating Initial Offer 629 The agent that intends to send an SDP offer to create data channels 630 through SDP offer/answer negotiation performs the following: 632 o Creates data channels using stream identifiers from the owned set 633 (see Section 6.1). Note that the UDP/DTLS/SCTP association may 634 have been negotiated previously. 636 o Determines the list of stream identifiers assigned to data 637 channels opened through SDP offer/answer negotiation. 639 o Generates the SDP offer with the "a=dcmap:" and "a=dcsa:" 640 attributes needed, if any, for each SDP offer/answer negotiated 641 data channel, as described in Section 5 and in Section 6.2. 643 o The "a=dcsa" attributes to the SDP offer SHOULD have the 644 subprotocol parameters to the "a=dcmap" attribute with a non-empty 645 subprotocol identifier. 647 6.4. Generating SDP Answer 649 The peer receiving such an SDP offer performs the following: 651 o Parses and applies the SDP offer, taking into account the 652 considerations discussed in Section 6.7. 654 o Analyzes the channel parameters and subprotocol attributes to 655 determine whether to accept each offered data channel. 657 o For accepted data channels, the agent MUST create peer instances 658 for the data channels using the SCTP stream identifiers and 659 channel parameters contained in the SDP offer. 661 o Generates an SDP answer. 663 o Completes the SDP answer with the "a=dcmap:" and optional 664 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 665 data channel, as described in Section 5 and in Section 6.2. The 666 number of "a=dcsa:" attributes in the SDP answer does not have to 667 match the number of "a=dcsa:" attributes in the SDP offer. 669 6.5. Offerer Processing of the SDP Answer 671 An offerer receiving a SDP answer performs the following: 673 o Closes any created data channels as described in Section 6.6.2 for 674 which the expected "a=dcmap:" and "a=dcsa:" attributes are not 675 present in the SDP answer. If the SDP answer does has no 676 "a=dcmap" attribute either the peer does not support "a=dcmap:" 677 attributes or it rejected all the data channels. In either case 678 the offerer closes all the SDP offer/answer negotiated data 679 channels that were open at the time of offer. The DTLS 680 association and SCTP association will still be setup. 682 o Applies the SDP answer. 684 Each agent application MUST wait to send data until it has 685 confirmation that the data channel at the peer is instantiated. For 686 WebRTC, this is when both data channel stacks have channel parameters 687 instantiated. This occurs: 689 o At both peers when a data channel is created without an 690 established SCTP association, as soon as the SCTP association is 691 successfully established. 693 o At the agent receiving an SDP offer for which there is an 694 established SCTP association, as soon as it creates an SDP offer/ 695 answer negotiated data channel based on information signaled in 696 the SDP offer. 698 o At the agent sending an SDP offer to create a new SDP offer/answer 699 negotiated data channel for which there is an established SCTP 700 association, when it receives the SDP answer confirming acceptance 701 of the data channel or when it begins to receive data on the data 702 channel from the peer, whichever occurs first. 704 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 705 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 707 6.6. Subsequent Offers 709 Subsequent offers should include all parameters of the existing 710 channels. If the offer wants to remove a data channel it will remove 711 the attributes with the dcmap-stream-id it wants to remove, see the 712 examples in the examples section Section 7. 714 6.6.1. Adding a Data Channel 716 When an application wants to add a data channel it MUST send a new 717 offer adding a new a=dcmap with a new dcmap-stream-id and optionally 718 a=dcsa attributes. 720 6.6.2. Closing a Data Channel 722 When the application requests the closing of a data channel that was 723 negotiated via SDP offer/answer, the data channel stack always 724 performs an SCTP SSN reset [RFC6525] for this channel. The SCTP SSN 725 reset the Stream Sequence Number of the stream back to zero. 727 It is specific to the subprotocol whether this data channel will be 728 closed or will be re-used by a new Offer/Answer Exchange exchange. 730 The intention to close a data channel MUST be signaled by sending a 731 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 732 lines for the data channel. The offerer SHOULD NOT change the port 733 value for the "m" line (e.g. to zero) when closing a data channel 734 (unless all data channels are being closed and the SCTP association 735 is no longer needed), since this would close the SCTP association and 736 impact all of the data channels. If the answerer accepts the SDP 737 offer then the answerer MUST close those data channels whose 738 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 739 received SDP offer, unless those data channels were already closed, 740 and the answerer MUST also exclude the corresponding attribute lines 741 in the answer. In addition to that, the SDP answerer MAY exclude 742 other data channels which were closed but not yet communicated to the 743 peer. So, the offerer MUST inspect the answer to see if it has to 744 close other data channels that are now not included in the answer. 746 If a new SDP offer/answer is used to close data channels then the 747 data channel(s) SHOULD only be closed by the answerer/offerer after a 748 successful SDP answer is sent/received. 750 This delayed closure is RECOMMENDED in order to handle cases where 751 a successful SDP answer is not received, in which case the state 752 of the session SHOULD be kept per the last successful SDP offer/ 753 answer. 755 If a client receives a data channel close indication (due to inband 756 SCTP SSN reset or some other reason) without associated SDP offer 757 then the client SHOULD generate an SDP offer which excludes this 758 closed data channel. 760 The application MUST also close any data channel that was negotiated 761 via SDP offer/answer, for which the stream identifiers are not listed 762 in an incoming SDP offer. 764 A closed data channel using local close (SCTP SSN reset), without an 765 additional SDP offer/answer to close it, may be reused for a new data 766 channel. This MUST be done via new SDP offer/answer, describing the 767 new subprotocol and its attributes, only after the corresponding data 768 channel close acknowledgment is received from the peer (i.e. SCTP 769 SSN reset of both incoming and outgoing streams is completed). This 770 restriction is to avoid the race conditions between arrival of "SDP 771 offer which reuses stream" with "SCTP SSN reset which closes outgoing 772 stream" at the peer. 774 If the offer or the answer do not include any "a=dcmap" attributes 775 all the SDP offer/answer negotiated data channels are expected to be 776 closed now. The DTLS/SCTP association remains open for new SDP 777 offer/answer or DCEP negotiation of data channels. 779 6.7. Various SDP Offer/Answer Considerations 781 SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" 782 attributes. 784 * This is considered an error case. In this case the receiver of 785 such an SDP offer or answer SHOULD ignore the "a=dcsa:" 786 attributes and SHOULD process the SDP offer or answer as per 787 above case 'SDP offer has no "a=dcmap:" attributes' or case 788 'SDP answer has no "a=dcmap:" attributes'. 790 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 791 attribute is unknown. 793 * The receiver of such an SDP offer or answer SHOULD ignore this 794 entire "a=dcsa" attribute line. 796 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 797 attribute is known, but whose subprotocol attribute semantic is 798 not known for the data channel transport case. 800 * The receiver of such an SDP offer or answer SHOULD ignore this 801 entire "a=dcsa" attribute line. 803 7. Examples 805 SDP offer: 807 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 808 c=IN IP6 IP6 2001:db8::3 809 a=max-message-size:100000 810 a=sctp-port:5000 811 a=setup:actpass 812 a=fingerprint:SHA-1 \ 813 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 814 a=tls-id:abc3de65cddef001be82 815 a=dcmap:0 subprotocol="BFCP";label="BFCP" 817 SDP answer: 819 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 820 c=IN IP6 IP6 2001:db8::1 821 a=max-message-size:100000 822 a=sctp-port:5002 823 a=setup:passive 824 a=fingerprint:SHA-1 \ 825 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 826 a=tls-id:dcb3ae65cddef0532d42 828 Figure 1: Example 1 830 In the above example the SDP answerer rejected the data channel with 831 stream id 0 either for explicit reasons or because it does not 832 understand the "a=dcmap:" attribute. As a result the offerer will 833 close the data channel created with the SDP offer/answer negotiation 834 option. The SCTP association will still be setup over DTLS. At this 835 point the offerer or the answerer may use DCEP negotiation to open 836 data channels. 838 SDP offer: 840 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 841 c=IN IP4 192.0.2.1 842 a=max-message-size:100000 843 a=sctp-port:5000 844 a=setup:actpass 845 a=fingerprint:SHA-1 \ 846 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 847 a=tls-id:abc3de65cddef001be82 848 a=dcmap:0 subprotocol="BFCP";label="BFCP" 849 a=dcmap:2 subprotocol="MSRP";label="MSRP" 850 a=dcsa:2 accept-types:message/cpim text/plain 851 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 853 SDP answer: 855 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 856 c=IN IP4 192.0.2.2 857 a=max-message-size:100000 858 a=sctp-port:5002 859 a=setup:passive 860 a=fingerprint:SHA-1 \ 861 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 862 a=tls-id:dcb3ae65cddef0532d42 863 a=dcmap:2 subprotocol="MSRP";label="MSRP" 864 a=dcsa:2 accept-types:message/cpim text/plain 865 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 867 Figure 2: Example 2 869 In the above example the SDP offer contains data channels for BFCP 870 (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 871 answer rejected BFCP and accepted MSRP. So, the offerer closes the 872 data channel for BFCP and both offerer and answerer may start using 873 the MSRP data channel (after the SCTP association is set up). The 874 data channel with stream id 0 is free and can be used for future DCEP 875 or SDP offer/answer negotiation. 877 Continuing the example in Figure 2. 879 Subsequent SDP offer: 881 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 882 c=IN IP4 192.0.2.1 883 a=max-message-size:100000 884 a=sctp-port:5000 885 a=setup:actpass 886 a=fingerprint:SHA-1 \ 887 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 888 a=tls-id:abc3de65cddef001be82 889 a=dcmap:4 subprotocol="MSRP";label="MSRP" 890 a=dcsa:4 accept-types:message/cpim text/plain 891 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 893 Subsequent SDP answer: 895 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 896 c=IN IP4 192.0.2.2 897 a=max-message-size:100000 898 a=sctp-port:5002 899 a=setup:passive 900 a=fingerprint:SHA-1 \ 901 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 902 a=tls-id:dcb3ae65cddef0532d42 903 a=dcmap:4 subprotocol="MSRP";label="MSRP" 904 a=dcsa:4 accept-types:message/cpim text/plain 905 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 907 Figure 3: Example 3 909 The above example is a continuation of the example in Figure 2. The 910 SDP offerer now removes the MSRP data channel with stream id 2, but 911 opens a new MSRP data channel with stream id 4. The answerer accepts 912 the entire offer. As a result the offerer closes the earlier 913 negotiated MSRP related data channel and both offerer and answerer 914 may start using new the MSRP related data channel. 916 8. Security Considerations 918 This document specifies new SDP attributes used in the negotiation of 919 the DATA channel parameters. 921 These parameter are negotiated as part of opening a SCTP channel over 922 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. This document do 923 not add any security considerations to the ones specified in the 924 above document 925 Error cases like the use of unknown parameter values or violation the 926 odd/even rule must be handled by closing the corresponding Data 927 Channel. 929 9. IANA Considerations 931 9.1. Subprotocol Identifiers 933 Registration of new subprotocol identifiers is performed using the 934 existing IANA "WebSocket Subprotocol Name Registry" table. 936 The following text should be added following the title of the table. 938 "This table also includes subprotocol identifiers specified for usage 939 within a WebRTC data channel." 941 The following reference should be added to under the heading 942 reference: "RFC XXXX". 944 This document assigns no new values to this table. 946 A subprotocol may simultaneously be defined for data channel 947 transport and for Websocket transport. In such a case the 948 "Subprotocol Definition" and "Reference" cells in the subprotocol's 949 row of the IANA "WebSocket Subprotocol Name Registry" table should 950 contain two entries. One entry in each of these cells should refer 951 to the Websocket related subprotocol specification, and the other 952 entry should refer to the data channel related subprotocol 953 specification. 955 NOTE to RFC Editor: Please replace "XXXX" with the number of this 956 RFC. 958 9.2. New SDP Attributes 960 9.2.1. dcmap 962 NOTE to RFC Editor: Please replace "XXXX" with the number of this 963 RFC. 965 This document defines a new SDP media-level attribute "a=dcmap:" as 966 follows: 968 +-----------------------+-------------------------------------------+ 969 | Contact name: | IESG Chairs | 970 | Contact email: | iesg@ietf.org | 971 | Attribute name: | dcmap | 972 | Attribute syntax: | As per Section 5.1.1 | 973 | Attribute semantics: | As per Section 5.1.1 | 974 | Usage level: | media | 975 | Charset dependent: | No | 976 | Purpose: | Define data channel specific parameters | 977 | Appropriate values: | As per Section 5.1.1 | 978 | O/A procedures: | As per Section 6 | 979 | Mux category: | SPECIAL. See Section 5.1.9 | 980 | Reference: | RFCXXXX | 981 +-----------------------+-------------------------------------------+ 983 9.2.2. dcsa 985 NOTE to RFC Editor: Please replace "XXXX" with the number of this 986 RFC. 988 This document defines a new SDP media-level attribute "a=dcsa:" as 989 follows: 991 +-----------------------+-------------------------------------------+ 992 | Contact name: | IESG Chairs | 993 | Contact email: | iesg@ietf.org | 994 | Attribute name: | dcsa | 995 | Attribute syntax: | As per Section 5.2.1 | 996 | Attribute semantics: | As per Section 5.2.1 | 997 | Usage level: | media | 998 | Charset dependent: | No | 999 | Purpose: | Define data channel subprotocol specific | 1000 | | attributes | 1001 | Appropriate values: | As per Section 5.2.1 | 1002 | O/A procedures: | As per Section 6 | 1003 | Mux category: | SPECIAL. See Section 5.2.2 | 1004 | Reference: | RFCXXXX | 1005 +-----------------------+-------------------------------------------+ 1007 9.3. New Usage Level 1009 This document introduces a new "Data Channel Subprotocol Attribute" 1010 (dcsa) usage level of the SDP media description to the IANA SDP att- 1011 field registry. SDP attributes that are defined for use at the dcsa 1012 usage level only SHALL use the dcsa usage level when registering the 1013 attribute. If existing media attributes are used in a datachannel 1014 subprotocol specific way (Section 5.2.1), then a new dcsa usage level 1015 MUST be defined for the existing media attribute. Where the SDP 1016 attribute is applicable to a particular subprotocol/s this SHALL also 1017 be registered by indicating the applicable subprotocol identifiers 1018 (see Section 9.1) along with the dcsa usage level. E.g. 1020 +-----------------------+-------------------------------------------+ 1021 | ... | ... | 1022 | Usage level: | dcsa(MSRP) | 1023 | ... | ... | 1024 +-----------------------+-------------------------------------------+ 1026 10. Acknowledgments 1028 The authors wish to acknowledge the borrowing of ideas from other 1029 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 1030 and Gavin Llewellyn, and to thank Flemming Andreasen, Christian 1031 Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, Jonathan 1032 Lennox, Uwe Rauschenbach and Roman Shpount for their invaluable 1033 comments. 1035 11. CHANGE LOG 1037 11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 1039 o Editorial changes separate sections for offer/answer procedures. 1041 o Update security section. 1043 11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 1045 o Change "dtls-id" to "tls-id" and assign 20 octet long values 1047 o Remove of RFC4566bis draft from list of normative references. 1049 11.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 1051 o Modification of Keith's address information. 1053 11.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 1055 o dcmap-stream-id syntax change to limit size to 5 digits. 1057 o Add missing 'x' prefix to quoted-visible syntax. 1059 o Align SDP offerer and answerer handling when both max-retr and 1060 max-time are present. 1062 o Use of TEST-NET-1 ip addresses in examples. 1064 o Add missing a=dtls-id in one example. 1066 11.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1068 o Removal of the "a=connection" attribute lines from all SDP 1069 examples. 1071 11.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1073 o In the introduction: 1075 * Replacement of the sentence "The RTCWeb working group has 1076 defined the concept of bi-directional data channels running on 1077 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1078 Security protocol)" with "The RTCWeb working group has defined 1079 the concept of bi-directional data channels running on top of 1080 the Stream Control Transmission Protocol (SCTP)". 1082 * Addition of following sentences to the second paragraph: "These 1083 procedures are based on generic SDP offer/answer negotiation 1084 rules for SCTP based media transport as specified in 1085 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1086 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1087 could be defined over other SCTP based protocols, such as SCTP 1088 over IP. However, corresponding potential other "m" line proto 1089 values are not considered in this document." 1091 o Replacement of "DTLS connection" with "DTLS association" 1092 throughout the document. 1094 o In sections Section 5.1.9 and Section 5.2.2 removal of the 1095 sentences "This document also does not specify multiplexing rules 1096 for this attribute for SCTP or SCTP/DTLS proto values". 1098 o In the text related to "Subsequent SDP answer" in section 1099 Section 6.7 replacement of "The DTLS/SCTP association remains open 1100 ..." with "The SCTP association remains open ...". 1102 o In the text after the second SDP answer in section Section 7 1103 replacement of "... (after SCTP/DTLS association is setup)" with 1104 "... (after the SCTP association is set up)". 1106 o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative 1107 references. 1109 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1110 examples in Section 7. 1112 11.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1114 o Addition of definition of "data channel subprotocol" to Section 3 1115 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1116 archive/web/mmusic/current/msg15827.html. 1118 o Addition of RFC4566bis draft to list of normative references. 1120 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1121 section 8.2.4 of RFC4566bis draft. 1123 o Addition of new Section 9.3. 1125 11.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1127 o Addition of two new paragraphs to Section 5.2.1 regarding 1128 subprotocol attribute relationship with transport protocol. 1130 o Addition of a note to Section 9.1 regarding subprotocols 1131 simultaneously defined for data channel and Websocket usage. 1133 o Addition of two further SDP offer/answer considerations to 1134 Section 6.7 regarding unknown subprotocol attributes and known 1135 subprotocol attributes with unknown data channel transport related 1136 semantic. 1138 11.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1140 o Changes addressing Christian Groves's WGLC review comments raised 1141 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1142 msg15357.html and http://www.ietf.org/mail- 1143 archive/web/mmusic/current/msg15359.html. 1145 11.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1147 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1148 of contact name and e-mail address with "MMUSIC Chairs" and 1149 "mmusic-chairs@ietf.org". 1151 o In Section 5.2.1 replacement of "Thus in the example above, the 1152 original attribute line "a=accept- types:text/plain" is 1153 represented by the attribute line "a=dcsa:2 accept-types:text/ 1154 plain", which specifies that this instance of MSRP being 1155 transported on the SCTP association using the data channel with 1156 stream id 2 accepts plain text files." with "... which specifies 1157 that this instance of the MSRP subprotocol being transported ...". 1159 o The last paragraph of Section 5.2.1 started with "Note: This 1160 document does not provide a complete specification ...". Removal 1161 of "Note:" and move of this paragraph to the introduction in 1162 Section 1 as last paragraph. 1164 o Section 5.2's headline was "Subprotocol Specific Attributes". 1165 Change of this headline to "Other Media Level Attributes" and 1166 adaptations of the first paragraph of this section and the first 1167 paragraph of Section 5.2.1 in order to clarify that not only those 1168 attributes may be encapsulated in a "dcsa" attribute, which are 1169 specifically defined for the subprotocol, but that also other 1170 attributes may be encapsulated if they are related to the specific 1171 subprotocol instance. 1173 o Move of the last but one paragraph of Section 5.2.1 starting with 1174 "The same syntax applies to ..." right in front of the formal 1175 syntax definition of the "dcsa" attribute. 1177 o Modifications of the text in Section 5.1.9 and Section 5.2.2 in 1178 order not to explicitly restrict usage of the "a=dcmap:" and 1179 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1180 SCTP" or "TCP/DTLS/SCTP". 1182 11.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1184 o In Section 5.1.4 the first (and only) paragraph was "The 1185 'subprotocol' parameter indicates which protocol the client 1186 expects to exchange via the channel. 'Subprotocol' is an optional 1187 parameter. If the 'subprotocol' parameter is not present, then 1188 its value defaults to the empty string." Replacement of this 1189 paragraph with following two paragraphs: 1191 * The 'subprotocol' parameter indicates which protocol the client 1192 expects to exchange via the channel. This parameter maps to 1193 the 'Protocol' parameter defined in 1194 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1195 subprotocol parameter values are registered. 'Subprotocol' is 1196 an optional parameter. If the 'subprotocol' parameter is not 1197 present, then its value defaults to the empty string. 1199 * Note: The empty string MAY also be explicitly used as 1200 'subprotocol' value, such that 'subprotocol=""' is equivalent 1201 to the 'subprotocol' parameter not being present at all. 1202 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1203 message's 'Subprotocol' value to be an empty string. 1205 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1206 normative references. 1208 o Addition of dcmap attribute specific IANA registration 1209 Section 9.2.1. 1211 o Addition of dcsa attribute specific IANA registration 1212 Section 9.2.2. 1214 o Addition of new Section 5.1.9 describing the mux category of the 1215 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1216 related mux category section are similar to the "Mux Category" 1217 sections of the "a=sctp-port:" and "a=max-message-size:" 1218 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1220 o Addition of new Section 5.2.2 describing the mux category of the 1221 dcsa SDP attribute. 1223 11.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1225 o In Section 1 replacement of "RTCWeb leaves it open for other 1226 applications to use data channels and its in-band DCEP or out-of- 1227 band non-DCEP protocols for creating them" with "... to use data 1228 channels and its in-band DCEP or other in-band or out-of-band 1229 protocols for creating them". Additionally replacement of "In 1230 particular, the SDP offer generated by the application includes no 1231 channel-specific information" with "... generated by the RTCweb 1232 data channel stack includes no channel-specific information". 1234 o Move of former section 5 ("Data Channels") to new Appendix A and 1235 removal of JavaScript API specific discussions from this moved 1236 text (like mentioning of data channel stack specific states). 1237 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1238 Section 5. 1240 o In Section 5: 1242 * Relacement of Section 5's first paragraph "This section defines 1243 a method of non-DCEP negotiation by which two clients can 1244 negotiate data channel-specific and subprotocol-specific 1245 parameters, using the out-of-band SDP offer/answer exchange. 1246 This SDP extension can only be used with the SDP offer/answer 1247 model." with "This section defines an SDP extension by which 1248 two clients can negotiate data channel-specific and 1249 subprotocol-specific parameters without using DCEP 1250 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1251 defines usage in the context of SDP offer/answer." 1253 * Addition of new paragraph: "Appendix A provides information how 1254 data channels work in general and especially summarizes some 1255 key aspects, which should be considered for the negotiation of 1256 data channels if DCEP is not used." 1258 o In Section 5.1 replacement of "The intention of exchanging these 1259 attributes is to create data channels on both the peers with the 1260 same set of attributes without actually using the DCEP 1261 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1262 these attributes is to create, on two peers, without use of DCEP 1263 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1264 directed data channels having the same set of attributes". 1266 o In Section 5.1.5 replacement of "The 'max-retr' parameter 1267 indicates the maximal number a user message will be retransmitted" 1268 with "The 'max-retr' parameter indicates the maximal number of 1269 times a user message will be retransmitted". 1271 o In Section 6.1 replacement of "However, an SDP offer/answer 1272 exchange MUST NOT be initiated if the associated SCTP stream is 1273 already negotiated via DCEP" with "However, an SCTP stream MUST 1274 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1275 answer exchange if the associated SCTP stream has already been 1276 negotiated via DCEP". 1278 o In the examples in Section 7 addition of the previously missing 1279 colons to the "a=sctp-port" attribute lines. 1281 11.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1283 o Move of reference draft-ietf-rtcweb-jsep from the list of 1284 normative references to the list of informative references. 1285 Remover in -07 since not referenced 1287 o Addition of [IANA-SDP-Parameters] to the list of informative 1288 references and addition of following two sentences to the first 1289 paragraph after the ABNF definition: "Note however that not all 1290 SDP attributes are suitable as "a=dcsa:" parameter. 1291 [IANA-SDP-Parameters] contains the lists of IANA registered 1292 session and media level or media level only SDP attributes." 1294 o In the introduction replacement of last sentence "This document 1295 defines SDP-based out-of-band negotiation procedures to establish 1296 data channels for transport of well-defined subprotocols" with 1297 "This document defines SDP offer/answer negotiation procedures to 1298 establish data channels for transport of well-defined 1299 subprotocols, to enable out-of-band negotiation". 1301 o Throughout the document replacement of "external negotiation" with 1302 "SDP offer/answer negotiation" and removal of term "external 1303 negotiation" from the terminology list in Section 3. 1305 o Throughout the document replacement of "internal negotiation" with 1306 "DCEP" and removal of terms "internal negotiation" and "in-band 1307 negotiation" from the terminology list in Section 3. 1309 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1310 terms. 1312 o In Section 6.1 replacement of sentence "However, a single stream 1313 is managed using one method at a time." with "However, an SDP 1314 offer/answer exchange MUST NOT be initiated if the associated SCTP 1315 stream is already negotiated via DCEP". 1317 o In Section 6.2 replacement of sentence "By definition max-retr and 1318 max-time are mutually exclusive, so only one of them can be 1319 present in a=dcmap" with "By definition max-retr and max-time are 1320 mutually exclusive, so at most one of them MAY be present in 1321 a=dcmap". 1323 o Move of reference [WebRtcAPI] from list of normative references to 1324 list of informative references. 1326 o Removal of almost all text parts, which discussed JavaScript or 1327 other API specific aspects. Such API specific aspects were mainly 1328 discussed in sub-sections of Section 5 and Section 5 of draft- 1329 ietf-mmusic-data-channel-sdpneg-02. 1331 11.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1333 o New Section 4 regarding applicability to SDP offer/answer only. 1335 o Addition of new Section 9.1 "Subprotocol identifiers" as 1336 subsection of the "IANA Considerations" related Section 9. Also 1337 removal of the temporary note "To be completed. As [I-D.ietf- 1338 rtcweb-data-protocol] this document should refer to IANA's 1339 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1341 o In Section 6.2: 1343 * In the first paragraph replacement of the sentence "If an SDP 1344 offer contains both of these parameters then such an SDP offer 1345 will be rejected." with "If an SDP offer contains both of these 1346 parameters then the receiver of such an SDP offer MUST reject 1347 the SDP offer." 1349 * In the second paragraph capitalization of "shall" and "may" 1350 such that both sentences now read: "The SDP answer SHALL echo 1351 the same subprotocol, max-retr, max-time, ordered parameters, 1352 if those were present in the offer, and MAY include a label 1353 parameter. They MAY appear in any order, which could be 1354 different from the SDP offer, in the SDP answer." 1356 * In the third paragraph replacement of the sentence "The same 1357 information MUST be replicated without changes in any 1358 subsequent offer or answer, as long as the data channel is 1359 still opened at the time of offer or answer generation." with 1360 "When sending a subsequent offer or an answer, and for as long 1361 as the data channel is still open, the sender MUST replicate 1362 the same information.". 1364 o In Section 6.2 the mapping of data channel types defined in 1365 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1366 parameters were illustrated using example "a=dcmap" attribute 1367 lines. Replacement of these example "a=dcmap" attribute lines 1368 with just the "a=dcmap" attribute parameters being relevant for 1369 the channel type. 1371 o In Section 6.7 the description of bullet point "SDP offer has no 1372 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1373 No data channel negotiated yet." Replacement of this description 1374 with "Initial SDP offer: No data channel is negotiated yet. The 1375 DTLS connection and SCTP association is negotiated and, if agreed, 1376 established as per [I-D.ietf-mmusic-sctp-sdp]." 1378 o In Section 6.7 in both bullet points related to "Subsequent SDP 1379 offer" and "Subsequent SDP answer" replacement of "All the 1380 externally negotiated data channels must be closed now." with "All 1381 the externally negotiated data channels are expected to be closed 1382 now.". 1384 o In Appendix A.2.2's sixth paragraph replacement of the two 1385 occurrences of "must" with "MUST". 1387 o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" 1388 there was a comment saying that "Either only maxretr-opt or 1389 maxtime-opt is present. Both MUST NOT be present." Removal of 1390 the second normative sentence and instead addition of following 1391 new paragraph to the end of this section: "Within an 'a=dcmap' 1392 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1393 parameter or one 'maxtime-opt' parameter is present. Both MUST 1394 NOT be present." 1396 o In Section 5.1.7 replacement of the first sentence "The 'ordered' 1397 parameter with value "true" indicates that DATA chunks in the 1398 channel MUST be dispatched to the upper layer by the receiver 1399 while preserving the order." with "The 'ordered' parameter with 1400 value "true" indicates that the receiver MUST dispatch DATA chunks 1401 in the data channel to the upper layer while preserving the 1402 order.". 1404 o In Section 6.3's first paragraph replacement of the one occurrence 1405 of "must" with "..., it MUST wait until ...". 1407 o In Section 6.6.2: 1409 * In the second paragraph replacement of "must" with "... whether 1410 this closing MUST in addition ..." 1412 * In the third paragraph replacement of the sentence "The port 1413 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1414 when closing a data channel ..." with "The offerer SHOULD NOT 1415 change the port value for the "m" line (e.g., to zero) when 1416 closing a data channel ...". 1418 * In the last but two paragraph replacement of the sentence "... 1419 then an SDP offer which excludes this closed data channel 1420 SHOULD be generated." with "... then the client SHOULD generate 1421 an SDP offer which excludes this closed data channel.". 1423 * In the last but one paragraph replacement of "must" with "The 1424 application MUST also close...". 1426 o In Section 5.2 addition of following note after the formal 1427 definition of the 'a=dcsa' attribute: "Note that the above 1428 reference to RFC 4566 defines were the attribute definition can be 1429 found; it does not provide any limitation on support of attributes 1430 defined in other documents in accordance with this attribute 1431 definition." 1433 11.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1435 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1436 channel consisting of paired SCTP outbound and inbound streams." 1437 Replacement of this definition with "Data channel: A WebRTC data 1438 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1439 consistent usage of "data channel" in the remainder of the 1440 document including the document's headline." 1442 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1443 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1445 In particular we expect "webrtc-datachannel" to become a more 1446 general term.' 1448 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1450 o In Section 5.1 removal of the example dcmap attribute line 1451 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1452 already four examples right after the ABNF rules in Section 5.1.1. 1453 Corresponding removal of following related note: "Note: This 1454 document does not provide a complete specification of how to 1455 negotiate the use of a WebRTC data channel to transport BFCP. 1456 Procedures specific to each subprotocol such as BFCP will be 1457 documented elsewhere. The use of BFCP is only an example of how 1458 the generic procedures described herein might apply to a specific 1459 subprotocol." 1461 o In Section 5.1 removal of following note: "Note: This attribute is 1462 derived from attribute "webrtc-DataChannel", which was defined in 1463 old version 03 of the following draft, but which was removed along 1464 with any support for SDP external negotiation in subsequent 1465 versions: [I-D.ietf-mmusic-sctp-sdp]." 1467 o Insertion of following new sentence to the beginning of 1468 Section 5.1.1: "dcmap is a media level attribute having following 1469 ABNF syntax:" 1471 o Insertion of new Section 5.1.2 containing the dcmap-stream-id 1472 specifying sentence, which previously was placed right before the 1473 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1474 parameter and is noted directly after the "a=dcmap:" attribute's 1475 colon' as this information is part of the ABNF specification. 1477 o In Section 5.1.1 modification of the 'ordering-value' values from 1478 "0" or "1" to "true" or "false". Corresponding text modifications 1479 in Section 5.1.7. 1481 o In Section 5.1.1 the ABNF definition of "quoted-string" referred 1482 to rule name "escaped-char", which was not defined. Instead a 1483 rule with name "escaped" was defined. Renamed that rule's name to 1484 "escaped-char". 1486 o Insertion of a dedicated note right after the "a=dcmap:4" 1487 attribute example in Section 5.1.1 regarding the non-printable 1488 "escaped-char" character within the "label" value. 1490 o In Section 5.2's second paragraph replacement of "sctp stream 1491 identifier" with "SCTP stream identifier". 1493 o In first paragraph of Section 6.1 replacement of first two 1494 sentences 'For the SDP-based external negotiation described in 1495 this document, the initial offerer based "SCTP over DTLS" owns by 1496 convention the even stream identifiers whereas the initial 1497 answerer owns the odd stream identifiers. This ownership is 1498 invariant for the whole lifetime of the signaling session, e.g. it 1499 does not change if the initial answerer sends a new offer to the 1500 initial offerer.' with 'If an SDP offer/answer exchange (could be 1501 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1502 TCP/DTLS/SCTP based media description being accepted, and if this 1503 SDP offer/answer exchange results in the establishment of a new 1504 SCTP association, then the SDP offerer owns the even SCTP stream 1505 ids of this new SCTP association and the answerer owns the odd 1506 SCTP stream identifiers. If this "m" line is removed from the 1507 signaling session (its port number set to zero), and if usage of 1508 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1509 renegotiated later on, then the even and odd SCTP stream 1510 identifier ownership is redetermined as well as described above.' 1512 o In Section 6.3 the first action of an SDP answerer, when receiving 1513 an SDP offer, was described as "Applies the SDP offer. Note that 1514 the browser ignores data channel specific attributes in the SDP." 1515 Replacement of these two sentences with "Parses and applies the 1516 SDP offer. Note that the typical parser normally ignores unknown 1517 SDP attributes, which includes data channel related attributes." 1519 o In Section 6.3 the second sentence of the third SDP answerer 1520 action was "Note that the browser is asked to create data channels 1521 with stream identifiers not "owned" by the agent.". Replacement 1522 of this sentence with "Note that the agent is asked to create data 1523 channels with SCTP stream identifiers contained in the SDP offer 1524 if the SDP offer is accepted." 1526 o In Section 6.6.2 the third paragraph began with "A data channel 1527 can be closed by sending a new SDP offer which excludes the dcmap 1528 and dcsa attribute lines for the data channel. The port value for 1529 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1530 data channel (unless all data channels are being closed and the 1531 SCTP association is no longer needed), since this would close the 1532 SCTP association and impact all of the data channels. If the 1533 answerer accepts the SDP offer then it MUST also exclude the 1534 corresponding attribute lines in the answer. ..." Replacement of 1535 this part with "The intention to close a data channel can be 1536 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1537 and "a=dcsa:" attribute lines for the data channel. The port 1538 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1539 closing a data channel (unless all data channels are being closed 1540 and the SCTP association is no longer needed), since this would 1541 close the SCTP association and impact all of the data channels. 1542 If the answerer accepts the SDP offer then it MUST close those 1543 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1544 excluded from the received SDP offer, unless those data channels 1545 were already closed, and it MUST also exclude the corresponding 1546 attribute lines in the answer." 1548 o In Section 6.6.2 the hanging text after the third paragraph was 1549 "This delayed close is to handle cases where a successful SDP 1550 answer is not received, in which case the state of session should 1551 be kept per the last successful SDP offer/answer." Replacement of 1552 this sentence with "This delayed closure is RECOMMENDED in order 1553 to handle cases where a successful SDP answer is not received, in 1554 which case the state of the session SHOULD be kept per the last 1555 successful SDP offer/answer." 1557 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1558 Section 5.1 contained already procedural descriptions related to 1559 data channel reliability negotiation. Creation of new Section 6.2 1560 and moval of reliability negotiation related text to this new 1561 section. 1563 11.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1565 o Removal of note "ACTION ITEM" from section "subprotocol 1566 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1567 should refer to IANA's WebSocket Subprotocol Name Registry defined 1568 in [RFC6455] 1570 o In whole document, replacement of "unreliable" with "partially 1571 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1572 [I-D.ietf-rtcweb-data-protocol] in most places. 1574 o Clarification of the semantic if the "max-retr" parameter is not 1575 present in an "a=dcmap" attribute line. In section "max-retr 1576 parameter" the sentence "The max-retr parameter is optional with 1577 default value unbounded" was replaced with "The max-retr parameter 1578 is optional. If the max-retr parameter is not present, then the 1579 maximal number of retransmissions is determined as per the generic 1580 SCTP retransmission rules as specified in [RFC4960]". 1582 o Clarification of the semantic if the "max-time" parameter is not 1583 present in an "a=dcmap" attribute line. In section "max-time 1584 parameter" the sentence "The max-time parameter is optional with 1585 default value unbounded" was replaced with "The max-time parameter 1586 is optional. If the max-time parameter is not present, then the 1587 generic SCTP retransmission timing rules apply as specified in 1588 [RFC4960]". 1590 o In section "label parameter" the sentence "Label is a mandatory 1591 parameter." was removed and following new sentences (including the 1592 note) were added: "The 'label' parameter is optional. If it is 1593 not present, then its value defaults to the empty string. Note: 1594 The empty string may also be explicitly used as 'label' value, 1595 such that 'label=""' is equivalent to the 'label' parameter not 1596 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1597 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1599 o In section "subprotocol parameter" the sentence "Subprotocol is a 1600 mandatory parameter." was replaced with "'Subprotocol' is an 1601 optional parameter. If the 'subprotocol' parameter is not 1602 present, then its value defaults to the empty string." 1604 o In the "Examples" section, in the first two SDP offer examples in 1605 the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 1606 'label="BFCP"'. 1608 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1609 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1610 replaced with "a=max-message-size" attribute lines, as per draft- 1611 ietf-mmusic-sctp-sdp-12. 1613 11.17. Changes against '-01' 1615 o Formal syntax for dcmap and dcsa attribute lines. 1617 o Making subprotocol as an optional parameter in dcmap. 1619 o Specifying disallowed parameter combinations for max-time and max- 1620 retr. 1622 o Clarifications on WebRTC data channel close procedures. 1624 11.18. Changes against '-00' 1626 o Revisions to identify difference between internal and external 1627 negotiation and their usage. 1629 o Introduction of more generic terminology, e.g. "application" 1630 instead of "browser". 1632 o Clarification of how "max-retr and max-time affect the usage of 1633 unreliable and reliable WebRTC data channels. 1635 o Updates of examples to take into account the SDP syntax changes 1636 introduced with draft-ietf-mmusic-sctp-sdp-07. 1638 o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" 1639 attributes as this is now contained in the a=sctp-port attribute, 1640 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1641 association on top of the DTLS connection. 1643 12. References 1645 12.1. Normative References 1647 [I-D.ietf-mmusic-sctp-sdp] 1648 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1649 "Session Description Protocol (SDP) Offer/Answer 1650 Procedures For Stream Control Transmission Protocol (SCTP) 1651 over Datagram Transport Layer Security (DTLS) Transport.", 1652 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1653 2017. 1655 [I-D.ietf-mmusic-sdp-mux-attributes] 1656 Nandakumar, S., "A Framework for SDP Attributes when 1657 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1658 (work in progress), February 2018. 1660 [I-D.ietf-rtcweb-data-channel] 1661 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1662 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1663 progress), January 2015. 1665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1666 Requirement Levels", BCP 14, RFC 2119, 1667 DOI 10.17487/RFC2119, March 1997, 1668 . 1670 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1671 with Session Description Protocol (SDP)", RFC 3264, 1672 DOI 10.17487/RFC3264, June 2002, 1673 . 1675 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1676 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1677 July 2006, . 1679 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1680 Specifications: ABNF", STD 68, RFC 5234, 1681 DOI 10.17487/RFC5234, January 2008, 1682 . 1684 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 1685 Transmission Protocol (SCTP) Stream Reconfiguration", 1686 RFC 6525, DOI 10.17487/RFC6525, February 2012, 1687 . 1689 12.2. Informative References 1691 [I-D.ietf-clue-datachannel] 1692 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1693 clue-datachannel-14 (work in progress), August 2016. 1695 [I-D.ietf-mmusic-dtls-sdp] 1696 Holmberg, C. and R. Shpount, "Session Description Protocol 1697 (SDP) Offer/Answer Considerations for Datagram Transport 1698 Layer Security (DTLS) and Transport Layer Security (TLS)", 1699 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 1700 2017. 1702 [I-D.ietf-mmusic-msrp-usage-data-channel] 1703 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1704 Marcon, J., and J. Recio, "MSRP over Data Channels", 1705 draft-ietf-mmusic-msrp-usage-data-channel-08 (work in 1706 progress), March 2018. 1708 [I-D.ietf-rtcweb-data-protocol] 1709 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1710 Establishment Protocol", draft-ietf-rtcweb-data- 1711 protocol-09 (work in progress), January 2015. 1713 [IANA-SDP-Parameters] 1714 "Session Description Protocol (SDP) Parameters", Internet 1715 Assigned Numbers Authority Protocol Assignments Session 1716 Description Protocol (SDP) Parameters, 1717 . 1720 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1721 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1722 November 2006, . 1724 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1725 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1726 . 1728 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1729 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1730 DOI 10.17487/RFC4975, September 2007, 1731 . 1733 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1734 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1735 . 1737 [WebRtcAPI] 1738 Bergkvist, A., Burnett, D., Jennings, C., and A. 1739 Narayanan, "WebRTC 1.0: Real-time Communication Between 1740 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1741 February 2015, 1742 . 1744 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1745 DCEP 1747 This appendix summarizes how data channels work in general and 1748 discusses some key aspects, which should be considered for the out- 1749 of-band negotiation of data channels if DCEP is not used. 1751 A WebRTC application creates a data channel by providing a number of 1752 setup parameters (subprotocol, label, maximal number of 1753 retransmissions, maximal retransmission time, order of delivery, 1754 priority). The application also specifies if it wants to make use of 1755 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1756 the application intends to negotiate data channels using the SDP 1757 offer/answer protocol. 1759 In any case, the SDP offer generated by the application is per 1760 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1761 the SCTP association on top of which data channels will run: 1763 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1764 c=IN IP4 192.0.2.1 1765 a=max-message-size:100000 1766 a=sctp-port:5000 1767 a=tls-id:abc3de65cddef001be82 1768 a=setup:actpass 1769 a=fingerprint:SHA-1 \ 1770 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1772 Note: A WebRTC application will only use "m" line format "webrtc- 1773 datachannel", and will not use other formats in the "m" line for 1774 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1775 only one SCTP association to be established on top of a DTLS 1776 association. 1778 Note: The above SDP media description does not contain any channel- 1779 specific information. 1781 A.1. Stream Identifier Numbering 1783 Independently from the requested type of negotiation, the application 1784 creating a data channel can either pass the stream identifier to the 1785 data channel stack to assign to the data channel or else let the data 1786 channel stack pick one identifier from the unused ones. 1788 To avoid glare situations, each endpoint can moreover own an 1789 exclusive set of stream identifiers, in which case an endpoint can 1790 only create a data channel with a stream identifier it owns. 1792 Which set of stream identifiers is owned by which endpoint is 1793 determined by convention or other means. 1795 Note:For data channels negotiated with the DCEP, one endpoint owns 1796 by convention the even stream identifiers, whereas the other owns 1797 the odd stream identifiers, as defined in 1798 [I-D.ietf-rtcweb-data-protocol]. 1800 Note:For data channels negotiated via different protocol from 1801 DCEP, no convention is defined by default. 1803 A.2. Generic Data Channel Negotiation Not Using DCEP 1805 A.2.1. Overview 1807 DCEP negotiation only provides for negotiation of data channel 1808 transport parameters and does not provide for negotiation of 1809 subprotocol specific parameters. DCEP-less data channel negotiation 1810 can be defined to allow negotiation of parameters beyond those 1811 handled by DCEP, e.g., parameters specific to the subprotocol 1812 instantiated on a particular data channel. 1814 The following procedures are common to all methods of data channel 1815 negotiation not using DCEP, whether in-band (communicated using 1816 proprietary means on an already established data channel) or out-of- 1817 band (using SDP offer/answer or some other protocol associated with 1818 the signaling channel). 1820 A.2.2. Opening a Data Channel 1822 In the case of DCEP-less negotiation, the endpoint application has 1823 the option to fully control the stream identifier assignments. 1824 However these assignments have to coexist with the assignments 1825 controlled by the data channel stack for the DCEP negotiated data 1826 channels (if any). It is the responsibility of the application to 1827 ensure consistent assignment of stream identifiers. 1829 When the application requests the creation of a new data channel to 1830 be set up via DCEP-less negotiation, the data channel stack creates 1831 the data channel locally without sending any DATA_CHANNEL_OPEN 1832 message in-band. However, even if the ICE (Interactive Connectivity 1833 Establishment), DTLS and SCTP procedures were already successfully 1834 completed, the application can't send data on this data channel until 1835 the negotiation is complete with the peer. This is because the peer 1836 needs to be aware of and accept the usage of this data channel. The 1837 peer, after accepting the data channel offer, can start sending data 1838 immediately. This implies that the offerer may receive data channel 1839 subprotocol messages before the negotiation is complete and the 1840 application should be ready to handle it. 1842 If the peer rejects the data channel part of the offer then it 1843 doesn't have to do anything as the data channel was not created using 1844 the stack. The offerer on the other hand needs to close the data 1845 channel that was opened by invoking relevant data channel stack API 1846 procedures. 1848 It is also worth noting that a data channel stack implementation may 1849 not provide any API to create and close data channels; instead the 1850 data channels may be used on the fly as needed just by communicating 1851 via non-DCEP means or by even having some local configuration/ 1852 assumptions on both the peers. 1854 The application then negotiates the data channel properties and 1855 subprotocol properties with the peer's application using a mechanism 1856 different from DCEP. 1858 The peer then symmetrically creates a data channel with these 1859 negotiated data channel properties. This is the only way for the 1860 peer's data channel stack to know which properties to apply when 1861 transmitting data on this channel. The data channel stack must allow 1862 data channel creation with any non-conflicting stream identifier so 1863 that both peers can create the data channel with the same stream 1864 identifier. 1866 A.2.3. Closing a Data Channel 1868 When the application requests the closing of a data channel 1869 negotiated without DCEP, the data channel stack always performs an 1870 SCTP SSN reset for this channel. 1872 Depending upon the method used for DCEP-less negotiation and the 1873 subprotocol associated with the data channel, the closing might in 1874 addition be signaled to the peer via SDP offer/answer negotiation. 1876 Authors' Addresses 1878 Keith Drage 1879 Unaffiliated 1881 Email: drageke@ntlworld.com 1883 Maridi R. Makaraju (Raju) 1884 Nokia 1885 2000 Lucent Lane 1886 Naperville, Illinois 1887 US 1889 Email: Raju.Makaraju@nokia.com 1891 Juergen Stoetzer-Bradler 1892 Unaffiliated 1894 Email: Juergen.S-B.ietf@email.de 1896 Richard Ejzak 1897 Unaffiliated 1899 Email: richard.ejzak@gmail.com 1901 Jerome Marcon 1902 Unaffiliated 1904 Email: jeromee.marcon@free.fr 1906 Roni Even (editor) 1907 Huawei 1909 Email: roni.even@huawei.com