idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-16.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 25, 2017) is 2313 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-16 ** 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-07 -- 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: June 28, 2018 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 R. Even, Ed. 11 Huawei 12 December 25, 2017 14 SDP-based Data Channel Negotiation 15 draft-ietf-mmusic-data-channel-sdpneg-16 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 June 28, 2018. 54 Copyright Notice 56 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 75 5. SDP Data Channel attributes . . . . . . . . . . . . . . . . . 6 76 5.1. SDP data channel attributes . . . . . . . . . . . . . . . 6 77 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6 78 5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10 79 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 80 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 12 81 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 82 6.3. Generating initial Offer . . . . . . . . . . . . . . . . 14 83 6.4. Generating SDP answer . . . . . . . . . . . . . . . . . . 15 84 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 85 6.6. Closing a Data Channel . . . . . . . . . . . . . . . . . 16 86 6.7. Various SDP Offer/Answer Scenarios and Considerations . . 17 87 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 22 91 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 22 92 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 22 93 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 23 94 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 23 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 96 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 11.1. Changes against 'draft-ietf-mmusic-data-channel- 98 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 24 99 11.2. Changes against 'draft-ietf-mmusic-data-channel- 100 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 24 101 11.3. Changes against 'draft-ietf-mmusic-data-channel- 102 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 24 103 11.4. Changes against 'draft-ietf-mmusic-data-channel- 104 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 24 105 11.5. Changes against 'draft-ietf-mmusic-data-channel- 106 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 25 107 11.6. Changes against 'draft-ietf-mmusic-data-channel- 108 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 25 109 11.7. Changes against 'draft-ietf-mmusic-data-channel- 110 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 26 111 11.8. Changes against 'draft-ietf-mmusic-data-channel- 112 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 26 113 11.9. Changes against 'draft-ietf-mmusic-data-channel- 114 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 26 115 11.10. Changes against 'draft-ietf-mmusic-data-channel- 116 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 26 117 11.11. Changes against 'draft-ietf-mmusic-data-channel- 118 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 27 119 11.12. Changes against 'draft-ietf-mmusic-data-channel- 120 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 28 121 11.13. Changes against 'draft-ietf-mmusic-data-channel- 122 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 29 123 11.14. Changes against 'draft-ietf-mmusic-data-channel- 124 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 30 125 11.15. Changes against 'draft-ietf-mmusic-data-channel- 126 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 32 127 11.16. Changes against 'draft-ejzak-mmusic-data-channel- 128 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 35 129 11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 36 130 11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 36 131 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 132 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 133 12.2. Informative References . . . . . . . . . . . . . . . . . 38 134 Appendix A. Generic Data Channel Negotiation Aspects When Not 135 Using DCEP . . . . . . . . . . . . . . . . . . . . . 39 136 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 39 137 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 40 138 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 40 139 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 40 140 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 41 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 143 1. Introduction 145 The RTCWeb working group has defined the concept of bi-directional 146 data channels running on top of the Stream Control Transmission 147 Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows 148 applications to use data channels. RTCWeb defines an in-band Data 149 Channel Establishment Protocol (DCEP) 150 [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band 151 protocols may be used for establishing data channels. Each data 152 channel consists of paired SCTP streams sharing the same SCTP Stream 153 Identifier. Data channels are created by endpoint applications 154 through the WebRTC API (Application Programming Interface), or other 155 users of a data channel like CLUE [I-D.ietf-clue-datachannel] They 156 can be used to transport proprietary or well-defined protocols, which 157 in the latter case can be signaled by the data channel "subprotocol" 158 parameter, conceptually similar to the WebSocket "subprotocol". 159 However, apart from the "subprotocol" value transmitted to the peer, 160 RTCWeb leaves it open how endpoint applications can agree on how to 161 instantiate a given subprotocol on a data channel, and whether it is 162 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 163 (or both). In particular, the SDP offer generated by the RTCweb data 164 channel stack includes no channel-specific information. 166 This document defines SDP offer/answer [RFC3264] negotiation 167 procedures to establish data channels for transport of well-defined 168 subprotocols, to enable out-of-band negotiation. These procedures 169 are based on generic SDP offer/answer negotiation rules for SCTP 170 based media transport as specified in [I-D.ietf-mmusic-sctp-sdp] for 171 the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In 172 the future, data channels could be defined over other SCTP based 173 protocols, such as SCTP over IP. However, corresponding potential 174 other "m=" line proto values are not considered in this document. 176 This document makes use of MSRP (Message Session Relay Protocol) and 177 BFCP (Binary Floor Control Protocol) in many of the examples. It 178 does not provide a complete specification of how to negotiate the use 179 of a data channel to transport MSRP. Procedures specific to each 180 subprotocol would have to be documented elsewhere. For MSRP they are 181 documented in [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of 182 MSRP in some examples is only to show how the generic procedures 183 described herein might apply to a specific subprotocol. 185 2. Conventions 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 3. Terminology 193 This document uses the following terms: 195 Data channel: A WebRTC data channel as specified in 196 [I-D.ietf-rtcweb-data-channel]. 198 Data channel stack: An entity which, upon application request, 199 runs the data channel protocol to keep track of states, sending 200 and receiving data. If the application is a browser based 201 JavaScript application then this stack resides in the browser. If 202 the application is a native application then this stack resides in 203 the application and is accessible via some sort of APIs. 205 Data channel properties: Fixed properties assigned to a data 206 channel at the time of its creation. Some of these properties 207 determine the way the data channel stack transmits data on this 208 channel (e.g., stream identifier, reliability, order of 209 delivery...). 211 Data channel subprotocol: The application protocol which is 212 transported over a single data channel. Data channel subprotocol 213 messages are sent as data channel payload over an established data 214 channel. If an SDP offer/answer exchange is used as specified in 215 this document to negotiate the establishment of data channels, 216 corresponding data channel properties, associated data channel 217 subprotocols and data channel subprotocol properties, then the 218 data channel subprotocols may be identified by the values of the 219 "subprotocol" parameters of the SDP "a=dcmap" attribute as 220 described in Section 5.1.1.5. Within this document the term "data 221 channel subprotocol" is often abbreviated as just "subprotocol". 223 DCEP: Data Channel Establishment Protocol defined in 224 [I-D.ietf-rtcweb-data-protocol]. 226 In-band: Transmission through the peer-to-peer SCTP association. 228 Out-of-band: Transmission through the application signaling path. 230 Peer: From the perspective of one of the agents in a session, its 231 peer is the other agent. Specifically, from the perspective of 232 the SDP offerer, the peer is the SDP answerer. From the 233 perspective of the SDP answerer, the peer is the SDP offerer. 235 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 236 as specified in [RFC4960]. 238 Stream identifier: The identifier of the outbound and inbound SCTP 239 streams composing a data channel. 241 4. Applicability Statement 243 The mechanism in this document only applies to the Session 244 Description Protocol (SDP) [RFC4566], when used together with the SDP 245 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 246 scope of this document, and is thus undefined. 248 5. SDP Data Channel attributes 250 This section defines an SDP extension by which two clients can 251 negotiate data channel-specific and subprotocol-specific parameters 252 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 253 extension only defines usage in the context of SDP offer/answer. 255 Appendix A provides information how data channels work in general and 256 especially summarizes some key aspects, which should be considered 257 for the negotiation of data channels if DCEP is not used. 259 5.1. SDP data channel attributes 261 Two new SDP attributes are defined to support SDP offer/answer 262 negotiation of data channels. The first attribute provides for 263 negotiation of channel-specific parameters. The second attribute 264 provides for negotiation of subprotocol-specific parameters. 266 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 268 This section defines a new media level attribute "a=dcmap:" that 269 defines the data channel parameters for each data channel to be 270 negotiated. The attribute specifies the following parameters for a 271 data channel: SCTP stream identifier, subprotocol, label, maximal 272 number of retransmissions, maximal retransmission time, order of 273 delivery, and priority. 275 The intention in exchanging this attribute is to create, on two 276 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 277 data channels as pairs of oppositely directed SCTP streams having the 278 same set of attributes. It is assumed that the data channel 279 properties (reliable/partially reliable, ordered/unordered) are 280 suitable per the subprotocol transport requirements. 282 5.1.1.1. dcmap Attribute 284 "a=dcmap:" is a media level attribute having following ABNF 285 (Augmented Backus-Naur Form, [RFC5234]) syntax. 287 Formal Syntax: 289 Name: dcmap 291 Value: dcmap-value 293 Usage Level: media 295 Charset Dependent: no 297 Syntax: 299 dcmap-value = dcmap-stream-id 300 [ SP dcmap-opt *(";" dcmap-opt) ] 301 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 302 / maxretr-opt / maxtime-opt / priority-opt 303 ; Either only maxretr-opt or maxtime-opt 304 ; is present. 306 dcmap-stream-id = 1*5DIGIT 307 ordering-opt = "ordered=" ordering-value 308 ordering-value = "true" / "false" 309 subprotocol-opt = "subprotocol=" quoted-string 310 label-opt = "label=" quoted-string 311 maxretr-opt = "max-retr=" maxretr-value 312 maxretr-value = "0" / integer 313 ; number of retransmissions, 314 ; less than 2^32, 315 ; derived from 'Reliability Parameter' of 316 ; [I-D.ietf-rtcweb-data-protocol] 317 maxtime-opt = "max-time=" maxtime-value 318 maxtime-value = "0" / integer 319 ; milliseconds, 320 ; less than 2^32, 321 ; derived from 'Reliability Parameter' of 322 ; [I-D.ietf-rtcweb-data-protocol] 323 priority-opt = "priority=" priority-value 324 priority-value = "0" / integer 325 ; unsigned integer value indicating the priority of 326 ; the data channel, 327 ; less than 2^16, 328 ; derived from 'Priority' of 329 ; [I-D.ietf-rtcweb-data-protocol] 331 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 332 quoted-char = SP / quoted-visible 333 quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 334 escaped-char = "%" HEXDIG HEXDIG 335 DQUOTE = 336 integer = 338 Examples: 340 a=dcmap:0 341 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 342 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 343 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 344 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 346 Note: The last example (a=dcmap:4) shows a 'label' parameter value 347 which contains one non-printable 'escaped-char' character (the 348 tabulator character). 350 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 351 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 352 present. Both MUST NOT be present. 354 5.1.1.2. dcmap Multiplexing Category 356 Multiplexing characteristics of SDP attributes are described in 357 [I-D.ietf-mmusic-sdp-mux-attributes]. 359 The multiplexing category of the "a=dcmap:" attribute is SPECIAL. 361 As the usage of multiple SCTP associations on top of a single DTLS 362 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 363 "a=dcmap:" attribute multiplexing rules are specified for the 364 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 365 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 366 multiple SCTP associations on top of a single DTLS association, or 367 how to add multiple SCTP associations to one BUNDLE group, then 368 multiplexing rules for the "a=dcmap:" attribute need to be defined as 369 well, for instance in an extension of this SDP offer/answer based 370 data channel negotiation specification. 372 5.1.1.3. dcmap-stream-id Parameter 374 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 375 within the SCTP association used to form the data channel. 377 5.1.1.4. label Parameter 379 The 'label' parameter indicates the name of the channel. It 380 represents a label that can be used to distinguish, in the context of 381 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 382 RTCDataChannel objects. This parameter maps to the 'Label' parameter 383 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 384 optional. If it is not present, then its value defaults to the empty 385 string. 387 Note: The empty string MAY also be explicitly used as a 'label' 388 value, such that 'label=""' is equivalent to the 'label' parameter 389 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 390 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 392 5.1.1.5. subprotocol Parameter 394 The 'subprotocol' parameter indicates which protocol the client 395 expects to exchange via the channel. This parameter maps to the 396 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 397 Section 9.1 specifies how new subprotocol parameter values are 398 registered. 'Subprotocol' is an optional parameter. If the 399 'subprotocol' parameter is not present, then its value defaults to an 400 empty string. 402 Note: The empty string MAY also be explicitly used as 'subprotocol' 403 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 404 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 405 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 406 empty string. 408 5.1.1.6. max-retr Parameter 410 This parameter indicates that the data channel is partially reliable. 411 The 'max-retr' parameter indicates the maximal number of times a user 412 message will be retransmitted. The max-retr parameter is optional. 413 If the max-retr parameter is not present, then the maximal number of 414 retransmissions is determined as per the generic SCTP retransmission 415 rules as specified in [RFC4960]. This parameter maps to the 'Number 416 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 418 5.1.1.7. max-time Parameter 420 This parameter indicates that the data channel is partially reliable. 421 A user message will no longer be transmitted or retransmitted after a 422 specified life-time given in milliseconds in the 'max-time' 423 parameter. The max-time parameter is optional. If the max-time 424 parameter is not present, then the generic SCTP retransmission timing 425 rules apply as specified in [RFC4960]. This parameter maps to the 426 'Lifetime in ms' parameter defined in 427 [I-D.ietf-rtcweb-data-protocol]. 429 5.1.1.8. ordered Parameter 431 The 'ordered' parameter with value "true" indicates that the receiver 432 MUST dispatch DATA chunks in the data channel to the upper layer 433 while preserving the order. The ordered parameter is optional and 434 takes two values: "true" for ordered and "false" for unordered 435 delivery with "true" as the default value. Any other value is 436 ignored and default "ordered=true" is assumed. In the absence of 437 this parameter "ordered=true" is assumed. This parameter maps to the 438 ordered or unordered data channel types as defined in 439 [I-D.ietf-rtcweb-data-protocol]. 441 5.1.1.9. priority Parameter 443 The 'priority' parameter indicates the data channel's priority 444 relative to the priorities of other data channels, which may 445 additionally exist over the same SCTP association. The 'priority' 446 parameter maps to the 'Priority' parameter defined in 447 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 448 optional. In the absence of this parameter "priority=256" is 449 assumed. 451 5.1.2. Other Media Level Attributes 453 In the SDP media description, each data channel declaration MAY also 454 be followed by other media level SDP attributes, which are either 455 specifically defined for or applied to the subprotocol in use. Each 456 of these attributes is represented by one new attribute line, and it 457 includes the contents of a media-level SDP attribute already defined 458 for use with this (sub)protocol in another IETF (Internet Engineering 459 Task Force) document. Subprotocol specific attributes MAY also be 460 defined for exclusive use with data channel transport, but MUST use 461 the same syntax described here for other subprotocol related 462 attributes. 464 5.1.2.1. dcsa Attribute 466 Each SDP attribute, related to the subprotocol, that would normally 467 be used to negotiate the subprotocol using SDP offer/answer is 468 replaced with an attribute of the form "a=dcsa:stream-id original- 469 attribute", where dcsa stands for "data channel subprotocol 470 attribute", stream-id is the SCTP stream identifier assigned to this 471 subprotocol instance, and original-attribute represents the contents 472 of the subprotocol related attribute to be included. 474 The same syntax applies to any other SDP attribute required for 475 negotiation of this instance of the subprotocol. 477 Formal Syntax: 479 Name: dcsa 481 Value: dcsa-value 483 Usage Level: media 485 Charset Dependent: no 487 Syntax: 489 dcsa-value = stream-id SP attribute 490 attribute = 492 Example (other MSRP related SDP attributes are omitted for brevity): 494 a=dcsa:2 accept-types:text/plain 496 Note that the above reference to [RFC4566] defines where the 497 attribute definition can be found; it does not provide any limitation 498 on support of attributes defined in other documents in accordance 499 with this attribute definition. Note however that not all SDP 500 attributes are suitable as a "a=dcsa:" parameter. 501 [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned 502 Numbers Authority) registered session and media level or media level 503 only SDP attributes. 505 Thus in the example above, the original attribute line "a=accept- 506 types:text/plain" is represented by the attribute line "a=dcsa:2 507 accept-types:text/plain", which specifies that this instance of the 508 MSRP subprotocol being transported on the SCTP association using the 509 data channel with stream id 2 accepts plain text files. 511 As opposed to the data channel "a=dcmap:" attribute parameters, these 512 parameters are subject to offer/answer negotiation following the 513 procedures defined in the subprotocol specific documents. 515 It is assumed that in general the usages of subprotocol related media 516 level attributes are independent from the subprotocol's transport 517 protocol. Such transport protocol independent subprotocol related 518 attributes are used in the same way as defined in the original 519 subprotocol specification, also if the subprotocol is transported 520 over a data channel and if the attribute is correspondingly embedded 521 in a "a=dcsa" attribute. 523 There may be cases, where the usage of a subprotocol related media 524 level attribute depends on the subprotocol's transport protocol. In 525 such cases the subprotocol related usage of the attribute is expected 526 to be described for the data channel transport. A data channel 527 specific usage of a subprotocol attribute is expected to be specified 528 in the same document that registers the subprotocol's identifier for 529 data channel usage as described in Section 9.1. 531 5.1.2.2. dcsa Multiplexing Category 533 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 535 As the usage of multiple SCTP associations on top of a single DTLS 536 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 537 "a=dcsa:" attribute multiplexing rules are specified for the 538 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 539 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 540 multiple SCTP associations on top of a single DTLS association, or 541 how to add multiple SCTP associations to one BUNDLE group, then 542 multiplexing rules for the "a=dcsa:" attribute need to be defined as 543 well, for instance in an extension of this SDP based data channel 544 negotiation specification. 546 6. SDP Offer/Answer Procedures 548 6.1. Managing Stream Identifiers 550 If a SDP offer/answer exchange (could be the initial or a subsequent 551 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 552 description being accepted, and if this SDP offer/answer exchange 553 results in the establishment of a new SCTP association, then the SDP 554 offerer owns the even SCTP stream ids of this new SCTP association 555 and the answerer owns the odd SCTP stream identifiers. If this "m" 556 line is removed from the signaling session (its port number set to 557 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 558 SCTP based "m" line is renegotiated later on, then the even and odd 559 SCTP stream identifier ownership is re-determined as described above. 561 This document allows simultaneous use of SDP offer/answer and DCEP 562 negotiation. However, an SCTP stream MUST NOT be referenced in a 563 "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if 564 the associated SCTP stream has already been negotiated via DCEP. 565 Stream ids that are not currently used in SDP offer/answer can be 566 used for DCEP negotiation. Stream id allocation per SDP offer/answer 567 negotiation may not align with DTLS role based allocation. This 568 could cause glare conditions when one side tries to do SDP offer/ 569 answer negotiation on a stream id while the other end tries to open a 570 data channel on the same stream id using DCEP negotiation. To avoid 571 these glare conditions this document recommends that the data channel 572 stack user always selects stream ids per the above described SDP 573 offer/answer rule even when DCEP negotiation is used. To avoid glare 574 conditions, it is possible to come up with a different stream id 575 allocation scheme, but such schemes are outside the scope of this 576 document. 578 6.2. Negotiating Data Channel Parameters 580 Conveying a reliable data channel is achieved by including neither 581 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 582 "a=dcmap:" attribute line. Conveying a partially reliable data 583 channel is achieved by including only one of 'max-retr' or 'max- 584 time'. By definition max-retr and max-time are mutually exclusive, 585 so at most one of them MAY be present in the "a=dcmap:" attribute 586 line. If a SDP offer contains both of these parameters then the 587 receiver of such an SDP offer MUST reject the SDP offer. If a SDP 588 answer contains both of these parameters then the offerer MUST treat 589 the associated SDP offer/answer failed and take appropriate recovery 590 actions. These recovery options are outside the scope of this 591 document. 593 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 594 ordered parameters, if those were present in the offer, and MAY 595 include a label parameter. They MAY appear in any order, which could 596 be different from the SDP offer, in the SDP answer. 598 When sending a subsequent offer or an answer, and for as long as the 599 data channel is still open, the sender MUST replicate the same 600 information. 602 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 603 mapped to SDP media description in the following manner, where 604 "ordered=true" is the default and may be omitted: 606 DATA_CHANNEL_RELIABLE 607 ordered=true 609 DATA_CHANNEL_RELIABLE_UNORDERED 610 ordered=false 612 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 613 ordered=true;max-retr= 615 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 616 ordered=false;max-retr= 618 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 619 ordered=true;max-time= 621 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 622 ordered=false;max-time= 624 6.3. Generating initial Offer 626 The procedure for opening a data channel using SDP offer/answer 627 negotiation starts with the agent preparing to send an SDP offer. If 628 a peer receives an SDP offer before starting to send a new SDP offer 629 with data channels that are to be SDP offer/answer negotiated, or 630 loses an SDP offer glare resolution procedure in this case, it MUST 631 wait until the ongoing SDP offer/answer completes before resuming the 632 SDP offer/answer negotiation procedure. 634 The agent that intends to send an SDP offer to create data channels 635 through SDP offer/answer negotiation performs the following: 637 o Creates data channels using stream identifiers from the owned set 638 (see Section 6.1). 640 o Generates a new SDP offer. 642 o Determines the list of stream identifiers assigned to data 643 channels opened through SDP offer/answer negotiation. 645 o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:" 646 attributes needed, if any, for each SDP offer/answer negotiated 647 data channel, as described in Section 5.1 and in Section 6.2. 649 o If it adds "a=dcsa" attributes to the SDP offer, then it SHOULD 650 add the subprotocol parameter to the "a=dcmap" attribute with a 651 non-empty subprotocol identifier. 653 o Sends the SDP offer. 655 6.4. Generating SDP answer 657 The peer receiving such an SDP offer performs the following: 659 o Parses and applies the SDP offer, taking into account the 660 considerations discussed in Section 6.7. 662 o Analyzes the channel parameters and subprotocol attributes to 663 determine whether to accept each offered data channel. 665 o For accepted data channels, the agent MUST create peer instances 666 for the data channels using the SCTP stream identifiers and 667 channel parameters contained in the SDP offer. 669 o Generates an SDP answer. 671 o Completes the SDP answer with the "a=dcmap:" and optional 672 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 673 data channel, as described in Section 5.1 and in Section 6.2. 675 o Sends the SDP answer. 677 6.5. Offerer Processing of the SDP Answer 679 The agent receiving such an SDP answer performs the following: 681 o Closes any created data channels as described in Section 6.6 for 682 which the expected "a=dcmap:" and "a=dcsa:" attributes are not 683 present in the SDP answer. 685 o Applies the SDP answer. 687 Each agent application MUST wait to send data until it has 688 confirmation that the data channel at the peer is instantiated. For 689 WebRTC, this is when both data channel stacks have channel parameters 690 instantiated. This occurs: 692 o At both peers when a data channel is created without an 693 established SCTP association, as soon as the SCTP association is 694 successfully established. 696 o At the agent receiving an SDP offer for which there is an 697 established SCTP association, as soon as it creates an SDP offer/ 698 answer negotiated data channel based on information signaled in 699 the SDP offer. 701 o At the agent sending an SDP offer to create a new SDP offer/answer 702 negotiated data channel for which there is an established SCTP 703 association, when it receives the SDP answer confirming acceptance 704 of the data channel or when it begins to receive data on the data 705 channel from the peer, whichever occurs first. 707 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 708 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 710 6.6. Closing a Data Channel 712 When the application requests the closing of a data channel that was 713 negotiated via SDP offer/answer, the data channel stack always 714 performs an SCTP SSN reset for this channel. 716 It is specific to the subprotocol whether this closing MUST in 717 addition be signaled to the peer via a new SDP offer/answer exchange. 719 The intention to close a data channel can be signaled by sending a 720 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 721 lines for the data channel. The offerer SHOULD NOT change the port 722 value for the "m" line (e.g. to zero) when closing a data channel 723 (unless all data channels are being closed and the SCTP association 724 is no longer needed), since this would close the SCTP association and 725 impact all of the data channels. If the answerer accepts the SDP 726 offer then the answerer MUST close those data channels whose 727 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 728 received SDP offer, unless those data channels were already closed, 729 and the answerer MUST also exclude the corresponding attribute lines 730 in the answer. In addition to that, the SDP answerer MAY exclude 731 other data channels which were closed but not yet communicated to the 732 peer. So, the offerer MUST inspect the answer to see if it has to 733 close other data channels that are now not included in the answer. 735 If a new SDP offer/answer is used to close data channels then the 736 data channel(s) SHOULD only be closed by the answerer/offerer after a 737 successful SDP answer is sent/received. 739 This delayed closure is RECOMMENDED in order to handle cases where 740 a successful SDP answer is not received, in which case the state 741 of the session SHOULD be kept per the last successful SDP offer/ 742 answer. 744 If a client receives a data channel close indication (due to inband 745 SCTP SSN reset or some other reason) without associated SDP offer 746 then the client SHOULD generate an SDP offer which excludes this 747 closed data channel. 749 The application MUST also close any data channel that was negotiated 750 via SDP offer/answer, for which the stream identifiers are not listed 751 in an incoming SDP offer. 753 A closed data channel using local close (SCTP SSN reset), without an 754 additional SDP offer/answer to close it, may be reused for a new data 755 channel. This can only be done via new SDP offer/answer, describing 756 the new subprotocol and its attributes, only after the corresponding 757 data channel close acknowledgement is received from the peer (i.e. 758 SCTP SSN reset of both incoming and outgoing streams is completed). 759 This restriction is to avoid the race conditions between arrival of 760 "SDP offer which reuses stream" with "SCTP SSN reset which closes 761 outgoing stream" at the peer. 763 6.7. Various SDP Offer/Answer Scenarios and Considerations 765 SDP offer has no "a=dcmap:" attributes. 767 * Initial SDP offer: No data channel is negotiated yet. The DTLS 768 association and SCTP association is negotiated and, if agreed, 769 established as per [I-D.ietf-mmusic-sctp-sdp]. 771 * Subsequent SDP offer: All the SDP offer/answer negotiated data 772 channels are expected to be closed now. The DTLS/SCTP 773 association remains open for SDP offer/answer or DCEP 774 negotiation of data channels. 776 SDP answer has no "a=dcmap:" attributes. 778 * Initial SDP answer: Either the peer does not support "a=dcmap:" 779 attributes or it rejected all the data channels. In either 780 case the offerer closes all the SDP offer/answer negotiated 781 data channels that were open at the time of initial offer. The 782 DTLS association and SCTP association will still be setup. 784 * Subsequent SDP answer: All the SDP offer/answer negotiated data 785 channels are expected to be closed now. The SCTP association 786 remains open for future SDP offer/answer or DCEP negotiation of 787 data channels. 789 SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" 790 attributes. 792 * This is considered an error case. In this case the receiver of 793 such an SDP offer or answer SHOULD ignore the "a=dcsa:" 794 attributes and SHOULD process the SDP offer or answer as per 795 above case 'SDP offer has no "a=dcmap:" attributes' or case 796 'SDP answer has no "a=dcmap:" attributes'. 798 SDP offer has no "a=dcsa:" attributes for a data channel. 800 * This is allowed and indicates there are no subprotocol 801 parameters to convey. 803 SDP answer has no "a=dcsa:" attributes for a data channel. 805 * This is allowed and indicates there are no subprotocol 806 parameters to convey in the SDP answer. The number of 807 "a=dcsa:" attributes in the SDP answer does not have to match 808 the number of "a=dcsa:" attributes in the SDP offer. 810 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 811 attribute is unknown. 813 * The receiver of such an SDP offer or answer SHOULD ignore this 814 entire "a=dcsa" attribute line. 816 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 817 attribute is known, but whose subprotocol attribute semantic is 818 not known for the data channel transport case. 820 * The receiver of such an SDP offer or answer SHOULD ignore this 821 entire "a=dcsa" attribute line. 823 7. Examples 824 SDP offer: 826 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 827 c=IN IP4 192.0.2.1 828 a=max-message-size:100000 829 a=sctp-port:5000 830 a=setup:actpass 831 a=fingerprint:SHA-1 \ 832 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 833 a=tls-id:abc3de65cddef001be82 834 a=dcmap:0 subprotocol="BFCP";label="BFCP" 836 SDP answer: 838 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 839 c=IN IP4 192.0.2.2 840 a=max-message-size:100000 841 a=sctp-port:5002 842 a=setup:passive 843 a=fingerprint:SHA-1 \ 844 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 845 a=tls-id:dcb3ae65cddef0532d42 847 Figure 1: Example 1 849 In the above example the SDP answerer rejected the data channel with 850 stream id 0 either for explicit reasons or because it does not 851 understand the "a=dcmap:" attribute. As a result the offerer will 852 close the data channel created with the SDP offer/answer negotiation 853 option. The SCTP association will still be setup over DTLS. At this 854 point the offerer or the answerer may use DCEP negotiation to open 855 data channels. 857 SDP offer: 859 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 860 c=IN IP4 192.0.2.1 861 a=max-message-size:100000 862 a=sctp-port:5000 863 a=setup:actpass 864 a=fingerprint:SHA-1 \ 865 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 866 a=tls-id:abc3de65cddef001be82 867 a=dcmap:0 subprotocol="BFCP";label="BFCP" 868 a=dcmap:2 subprotocol="MSRP";label="MSRP" 869 a=dcsa:2 accept-types:message/cpim text/plain 870 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 872 SDP answer: 874 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 875 c=IN IP4 192.0.2.2 876 a=max-message-size:100000 877 a=sctp-port:5002 878 a=setup:passive 879 a=fingerprint:SHA-1 \ 880 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 881 a=tls-id:dcb3ae65cddef0532d42 882 a=dcmap:2 subprotocol="MSRP";label="MSRP" 883 a=dcsa:2 accept-types:message/cpim text/plain 884 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 886 Figure 2: Example 2 888 In the above example the SDP offer contains data channels for BFCP 889 (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 890 answer rejected BFCP and accepted MSRP. So, the offerer closes the 891 data channel for BFCP and both offerer and answerer may start using 892 the MSRP data channel (after the SCTP association is set up). The 893 data channel with stream id 0 is free and can be used for future DCEP 894 or SDP offer/answer negotiation. 896 Continuing the example in Figure 2. 898 Subsequent SDP offer: 900 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 901 c=IN IP4 192.0.2.1 902 a=max-message-size:100000 903 a=sctp-port:5000 904 a=setup:actpass 905 a=fingerprint:SHA-1 \ 906 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 907 a=tls-id:abc3de65cddef001be82 908 a=dcmap:4 subprotocol="MSRP";label="MSRP" 909 a=dcsa:4 accept-types:message/cpim text/plain 910 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 912 Subsequent SDP answer: 914 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 915 c=IN IP4 192.0.2.2 916 a=max-message-size:100000 917 a=sctp-port:5002 918 a=setup:passive 919 a=fingerprint:SHA-1 \ 920 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 921 a=tls-id:dcb3ae65cddef0532d42 922 a=dcmap:4 subprotocol="MSRP";label="MSRP" 923 a=dcsa:4 accept-types:message/cpim text/plain 924 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 926 Figure 3: Example 3 928 The above example is a continuation of the example in Figure 2. The 929 SDP offerer now removes the MSRP data channel with stream id 2, but 930 opens a new MSRP data channel with stream id 4. The answerer accepts 931 the entire offer. As a result the offerer closes the earlier 932 negotiated MSRP related data channel and both offerer and answerer 933 may start using new the MSRP related data channel. 935 8. Security Considerations 937 This document specifies new SDP attributes used in the negotiation of 938 the DATA channel parameters. 940 These parameter are negotiated as part of opening a SCTP channel over 941 DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. This document do 942 not add any security considerations to the ones specified in the 943 above document 944 Error cases like the use of unknown parameter values or violation the 945 odd/even rule must be handled by closing the corresponding Data 946 Channel. 948 9. IANA Considerations 950 9.1. Subprotocol Identifiers 952 Registration of new subprotocol identifiers is performed using the 953 existing IANA "WebSocket Subprotocol Name Registry" table. 955 The following text should be added following the title of the table. 957 "This table also includes subprotocol identifiers specified for usage 958 within a WebRTC data channel." 960 The following reference should be added to under the heading 961 reference: "RFC XXXX". 963 This document assigns no new values to this table. 965 A subprotocol may simultaneously be defined for data channel 966 transport and for Websocket transport. In such a case the 967 "Subprotocol Definition" and "Reference" cells in the subprotocol's 968 row of the IANA "WebSocket Subprotocol Name Registry" table should 969 contain two entries. One entry in each of these cells should refer 970 to the Websocket related subprotocol specification, and the other 971 entry should refer to the data channel related subprotocol 972 specification. 974 NOTE to RFC Editor: Please replace "XXXX" with the number of this 975 RFC. 977 9.2. New SDP Attributes 979 9.2.1. dcmap 981 NOTE to RFC Editor: Please replace "XXXX" with the number of this 982 RFC. 984 This document defines a new SDP media-level attribute "a=dcmap:" as 985 follows: 987 +-----------------------+-------------------------------------------+ 988 | Contact name: | MMUSIC Chairs | 989 | Contact email: | mmusic-chairs@ietf.org | 990 | Attribute name: | dcmap | 991 | Attribute syntax: | As per Section 5.1.1.1 | 992 | Attribute semantics: | As per Section 5.1.1.1 | 993 | Usage level: | media | 994 | Charset dependent: | No | 995 | Purpose: | Define data channel specific parameters | 996 | Appropriate values: | As per Section 5.1.1.1 | 997 | O/A procedures: | As per Section 6 | 998 | Mux category: | SPECIAL. See Section 5.1.1.2 | 999 | Reference: | RFCXXXX | 1000 +-----------------------+-------------------------------------------+ 1002 9.2.2. dcsa 1004 NOTE to RFC Editor: Please replace "XXXX" with the number of this 1005 RFC. 1007 This document defines a new SDP media-level attribute "a=dcsa:" as 1008 follows: 1010 +-----------------------+-------------------------------------------+ 1011 | Contact name: | MMUSIC Chairs | 1012 | Contact email: | mmusic-chairs@ietf.org | 1013 | Attribute name: | dcsa | 1014 | Attribute syntax: | As per Section 5.1.2.1 | 1015 | Attribute semantics: | As per Section 5.1.2.1 | 1016 | Usage level: | media | 1017 | Charset dependent: | No | 1018 | Purpose: | Define data channel subprotocol specific | 1019 | | attributes | 1020 | Appropriate values: | As per Section 5.1.2.1 | 1021 | O/A procedures: | As per Section 6 | 1022 | Mux category: | SPECIAL. See Section 5.1.2.2 | 1023 | Reference: | RFCXXXX | 1024 +-----------------------+-------------------------------------------+ 1026 9.3. New Usage Level 1028 This document introduces a new "Data Channel Subprotocol Attribute" 1029 (dcsa) usage level of the SDP media description to the IANA SDP att- 1030 field registry. SDP attributes that are defined for use at the dcsa 1031 usage level only SHALL use the dcsa usage level when registering the 1032 attribute. If existing media attributes are used in a datachannel 1033 subprotocol specific way (Section 5.1.2.1), then a new dcsa usage 1034 level MUST be defined for the existing media attribute. Where the 1035 SDP attribute is applicable to a particular subprotocol/s this SHALL 1036 also be registered by indicating the applicable subprotocol 1037 identifiers (see Section 9.1) along with the dcsa usage level. E.g. 1039 +-----------------------+-------------------------------------------+ 1040 | ... | ... | 1041 | Usage level: | dcsa(MSRP) | 1042 | ... | ... | 1043 +-----------------------+-------------------------------------------+ 1045 10. Acknowledgments 1047 The authors wish to acknowledge the borrowing of ideas from other 1048 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 1049 and Gavin Llewellyn, and to thank Flemming Andreasen, Roni Even, 1050 Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, 1051 Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their 1052 invaluable comments. 1054 11. CHANGE LOG 1056 11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' 1058 o Editorial changes separate sections for offer/answer procedures. 1060 o Update security section. 1062 11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 1064 o Change "dtls-id" to "tls-id" and assign 20 octet long values 1066 o Remove of RFC4566bis draft from list of normative references. 1068 11.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 1070 o Modification of Keith's address information. 1072 11.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 1074 o dcmap-stream-id syntax change to limit size to 5 digits. 1076 o Add missing 'x' prefix to quoted-visible syntax. 1078 o Align SDP offerer and answerer handling when both max-retr and 1079 max-time are present. 1081 o Use of TEST-NET-1 ip addresses in examples. 1083 o Add missing a=dtls-id in one example. 1085 11.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1087 o Removal of the "a=connection" attribute lines from all SDP 1088 examples. 1090 11.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1092 o In the introduction: 1094 * Replacement of the sentence "The RTCWeb working group has 1095 defined the concept of bi-directional data channels running on 1096 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1097 Security protocol)" with "The RTCWeb working group has defined 1098 the concept of bi-directional data channels running on top of 1099 the Stream Control Transmission Protocol (SCTP)". 1101 * Addition of following sentences to the second paragraph: "These 1102 procedures are based on generic SDP offer/answer negotiation 1103 rules for SCTP based media transport as specified in 1104 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1105 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1106 could be defined over other SCTP based protocols, such as SCTP 1107 over IP. However, corresponding potential other "m" line proto 1108 values are not considered in this document." 1110 o Replacement of "DTLS connection" with "DTLS association" 1111 throughout the document. 1113 o In sections Section 5.1.1.2 and Section 5.1.2.2 removal of the 1114 sentences "This document also does not specify multiplexing rules 1115 for this attribute for SCTP or SCTP/DTLS proto values". 1117 o In the text related to "Subsequent SDP answer" in section 1118 Section 6.7 replacement of "The DTLS/SCTP association remains open 1119 ..." with "The SCTP association remains open ...". 1121 o In the text after the second SDP answer in section Section 7 1122 replacement of "... (after SCTP/DTLS association is setup)" with 1123 "... (after the SCTP association is set up)". 1125 o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative 1126 references. 1128 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1129 examples in Section 7. 1131 11.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1133 o Addition of definition of "data channel subprotocol" to Section 3 1134 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1135 archive/web/mmusic/current/msg15827.html. 1137 o Addition of RFC4566bis draft to list of normative references. 1139 o Updates of tables in Section 9.2.1 and Section 9.2.2 as per 1140 section 8.2.4 of RFC4566bis draft. 1142 o Addition of new Section 9.3. 1144 11.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1146 o Addition of two new paragraphs to Section 5.1.2.1 regarding 1147 subprotocol attribute relationship with transport protocol. 1149 o Addition of a note to Section 9.1 regarding subprotocols 1150 simultaneously defined for data channel and Websocket usage. 1152 o Addition of two further SDP offer/answer considerations to 1153 Section 6.7 regarding unknown subprotocol attributes and known 1154 subprotocol attributes with unknown data channel transport related 1155 semantic. 1157 11.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1159 o Changes addressing Christian Groves's WGLC review comments raised 1160 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1161 msg15357.html and http://www.ietf.org/mail- 1162 archive/web/mmusic/current/msg15359.html. 1164 11.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1166 o In IANA registration Section 9.2.1 and Section 9.2.2 replacement 1167 of contact name and e-mail address with "MMUSIC Chairs" and 1168 "mmusic-chairs@ietf.org". 1170 o In Section 5.1.2.1 replacement of "Thus in the example above, the 1171 original attribute line "a=accept- types:text/plain" is 1172 represented by the attribute line "a=dcsa:2 accept-types:text/ 1173 plain", which specifies that this instance of MSRP being 1174 transported on the SCTP association using the data channel with 1175 stream id 2 accepts plain text files." with "... which specifies 1176 that this instance of the MSRP subprotocol being transported ...". 1178 o The last paragraph of Section 5.1.2.1 started with "Note: This 1179 document does not provide a complete specification ...". Removal 1180 of "Note:" and move of this paragraph to the introduction in 1181 Section 1 as last paragraph. 1183 o Section 5.1.2's headline was "Subprotocol Specific Attributes". 1184 Change of this headline to "Other Media Level Attributes" and 1185 adaptations of the first paragraph of this section and the first 1186 paragraph of Section 5.1.2.1 in order to clarify that not only 1187 those attributes may be encapsulated in a "dcsa" attribute, which 1188 are specifically defined for the subprotocol, but that also other 1189 attributes may be encapsulated if they are related to the specific 1190 subprotocol instance. 1192 o Move of the last but one paragraph of Section 5.1.2.1 starting 1193 with "The same syntax applies to ..." right in front of the formal 1194 syntax definition of the "dcsa" attribute. 1196 o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 1197 in order not to explicitly restrict usage of the "a=dcmap:" and 1198 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1199 SCTP" or "TCP/DTLS/SCTP". 1201 11.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1203 o In Section 5.1.1.5 the first (and only) paragraph was "The 1204 'subprotocol' parameter indicates which protocol the client 1205 expects to exchange via the channel. 'Subprotocol' is an optional 1206 parameter. If the 'subprotocol' parameter is not present, then 1207 its value defaults to the empty string." Replacement of this 1208 paragraph with following two paragraphs: 1210 * The 'subprotocol' parameter indicates which protocol the client 1211 expects to exchange via the channel. This parameter maps to 1212 the 'Protocol' parameter defined in 1213 [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new 1214 subprotocol parameter values are registered. 'Subprotocol' is 1215 an optional parameter. If the 'subprotocol' parameter is not 1216 present, then its value defaults to the empty string. 1218 * Note: The empty string MAY also be explicitly used as 1219 'subprotocol' value, such that 'subprotocol=""' is equivalent 1220 to the 'subprotocol' parameter not being present at all. 1221 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1222 message's 'Subprotocol' value to be an empty string. 1224 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1225 normative references. 1227 o Addition of dcmap attribute specific IANA registration 1228 Section 9.2.1. 1230 o Addition of dcsa attribute specific IANA registration 1231 Section 9.2.2. 1233 o Addition of new Section 5.1.1.2 describing the mux category of the 1234 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1235 related mux category section are similar to the "Mux Category" 1236 sections of the "a=sctp-port:" and "a=max-message-size:" 1237 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1239 o Addition of new Section 5.1.2.2 describing the mux category of the 1240 dcsa SDP attribute. 1242 11.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1244 o In Section 1 replacement of "RTCWeb leaves it open for other 1245 applications to use data channels and its in-band DCEP or out-of- 1246 band non-DCEP protocols for creating them" with "... to use data 1247 channels and its in-band DCEP or other in-band or out-of-band 1248 protocols for creating them". Additionally replacement of "In 1249 particular, the SDP offer generated by the application includes no 1250 channel-specific information" with "... generated by the RTCweb 1251 data channel stack includes no channel-specific information". 1253 o Move of former section 5 ("Data Channels") to new Appendix A and 1254 removal of JavaScript API specific discussions from this moved 1255 text (like mentioning of data channel stack specific states). 1256 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1257 Section 5. 1259 o In Section 5: 1261 * Relacement of Section 5's first paragraph "This section defines 1262 a method of non-DCEP negotiation by which two clients can 1263 negotiate data channel-specific and subprotocol-specific 1264 parameters, using the out-of-band SDP offer/answer exchange. 1265 This SDP extension can only be used with the SDP offer/answer 1266 model." with "This section defines an SDP extension by which 1267 two clients can negotiate data channel-specific and 1268 subprotocol-specific parameters without using DCEP 1269 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1270 defines usage in the context of SDP offer/answer." 1272 * Addition of new paragraph: "Appendix A provides information how 1273 data channels work in general and especially summarizes some 1274 key aspects, which should be considered for the negotiation of 1275 data channels if DCEP is not used." 1277 o In Section 5.1.1 replacement of "The intention of exchanging these 1278 attributes is to create data channels on both the peers with the 1279 same set of attributes without actually using the DCEP 1280 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1281 these attributes is to create, on two peers, without use of DCEP 1282 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1283 directed data channels having the same set of attributes". 1285 o In Section 5.1.1.6 replacement of "The 'max-retr' parameter 1286 indicates the maximal number a user message will be retransmitted" 1287 with "The 'max-retr' parameter indicates the maximal number of 1288 times a user message will be retransmitted". 1290 o In Section 6.1 replacement of "However, an SDP offer/answer 1291 exchange MUST NOT be initiated if the associated SCTP stream is 1292 already negotiated via DCEP" with "However, an SCTP stream MUST 1293 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1294 answer exchange if the associated SCTP stream has already been 1295 negotiated via DCEP". 1297 o In the examples in Section 7 addition of the previously missing 1298 colons to the "a=sctp-port" attribute lines. 1300 11.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1302 o Move of reference draft-ietf-rtcweb-jsep from the list of 1303 normative references to the list of informative references. 1304 Remover in -07 since not referenced 1306 o Addition of [IANA-SDP-Parameters] to the list of informative 1307 references and addition of following two sentences to the first 1308 paragraph after the ABNF definition: "Note however that not all 1309 SDP attributes are suitable as "a=dcsa:" parameter. 1310 [IANA-SDP-Parameters] contains the lists of IANA registered 1311 session and media level or media level only SDP attributes." 1313 o In the introduction replacement of last sentence "This document 1314 defines SDP-based out-of-band negotiation procedures to establish 1315 data channels for transport of well-defined subprotocols" with 1316 "This document defines SDP offer/answer negotiation procedures to 1317 establish data channels for transport of well-defined 1318 subprotocols, to enable out-of-band negotiation". 1320 o Throughout the document replacement of "external negotiation" with 1321 "SDP offer/answer negotiation" and removal of term "external 1322 negotiation" from the terminology list in Section 3. 1324 o Throughout the document replacement of "internal negotiation" with 1325 "DCEP" and removal of terms "internal negotiation" and "in-band 1326 negotiation" from the terminology list in Section 3. 1328 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1329 terms. 1331 o In Section 6.1 replacement of sentence "However, a single stream 1332 is managed using one method at a time." with "However, an SDP 1333 offer/answer exchange MUST NOT be initiated if the associated SCTP 1334 stream is already negotiated via DCEP". 1336 o In Section 6.2 replacement of sentence "By definition max-retr and 1337 max-time are mutually exclusive, so only one of them can be 1338 present in a=dcmap" with "By definition max-retr and max-time are 1339 mutually exclusive, so at most one of them MAY be present in 1340 a=dcmap". 1342 o Move of reference [WebRtcAPI] from list of normative references to 1343 list of informative references. 1345 o Removal of almost all text parts, which discussed JavaScript or 1346 other API specific aspects. Such API specific aspects were mainly 1347 discussed in sub-sections of Section 5 and Section 5 of draft- 1348 ietf-mmusic-data-channel-sdpneg-02. 1350 11.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1352 o New Section 4 regarding applicability to SDP offer/answer only. 1354 o Addition of new Section 9.1 "Subprotocol identifiers" as 1355 subsection of the "IANA Considerations" related Section 9. Also 1356 removal of the temporary note "To be completed. As [I-D.ietf- 1357 rtcweb-data-protocol] this document should refer to IANA's 1358 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1360 o In Section 6.2: 1362 * In the first paragraph replacement of the sentence "If an SDP 1363 offer contains both of these parameters then such an SDP offer 1364 will be rejected." with "If an SDP offer contains both of these 1365 parameters then the receiver of such an SDP offer MUST reject 1366 the SDP offer." 1368 * In the second paragraph capitalization of "shall" and "may" 1369 such that both sentences now read: "The SDP answer SHALL echo 1370 the same subprotocol, max-retr, max-time, ordered parameters, 1371 if those were present in the offer, and MAY include a label 1372 parameter. They MAY appear in any order, which could be 1373 different from the SDP offer, in the SDP answer." 1375 * In the third paragraph replacement of the sentence "The same 1376 information MUST be replicated without changes in any 1377 subsequent offer or answer, as long as the data channel is 1378 still opened at the time of offer or answer generation." with 1379 "When sending a subsequent offer or an answer, and for as long 1380 as the data channel is still open, the sender MUST replicate 1381 the same information.". 1383 o In Section 6.2 the mapping of data channel types defined in 1384 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1385 parameters were illustrated using example "a=dcmap" attribute 1386 lines. Replacement of these example "a=dcmap" attribute lines 1387 with just the "a=dcmap" attribute parameters being relevant for 1388 the channel type. 1390 o In Section 6.7 the description of bullet point "SDP offer has no 1391 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1392 No data channel negotiated yet." Replacement of this description 1393 with "Initial SDP offer: No data channel is negotiated yet. The 1394 DTLS connection and SCTP association is negotiated and, if agreed, 1395 established as per [I-D.ietf-mmusic-sctp-sdp]." 1397 o In Section 6.7 in both bullet points related to "Subsequent SDP 1398 offer" and "Subsequent SDP answer" replacement of "All the 1399 externally negotiated data channels must be closed now." with "All 1400 the externally negotiated data channels are expected to be closed 1401 now.". 1403 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1404 replacement of the two occurrences of "must" with "MUST". 1406 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1407 there was a comment saying that "Either only maxretr-opt or 1408 maxtime-opt is present. Both MUST NOT be present." Removal of 1409 the second normative sentence and instead addition of following 1410 new paragraph to the end of this section: "Within an 'a=dcmap' 1411 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1412 parameter or one 'maxtime-opt' parameter is present. Both MUST 1413 NOT be present." 1415 o In Section 5.1.1.8 replacement of the first sentence "The 1416 'ordered' parameter with value "true" indicates that DATA chunks 1417 in the channel MUST be dispatched to the upper layer by the 1418 receiver while preserving the order." with "The 'ordered' 1419 parameter with value "true" indicates that the receiver MUST 1420 dispatch DATA chunks in the data channel to the upper layer while 1421 preserving the order.". 1423 o In Section 6.3's first paragraph replacement of the one occurrence 1424 of "must" with "..., it MUST wait until ...". 1426 o In Section 6.6: 1428 * In the second paragraph replacement of "must" with "... whether 1429 this closing MUST in addition ..." 1431 * In the third paragraph replacement of the sentence "The port 1432 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1433 when closing a data channel ..." with "The offerer SHOULD NOT 1434 change the port value for the "m" line (e.g., to zero) when 1435 closing a data channel ...". 1437 * In the last but two paragraph replacement of the sentence "... 1438 then an SDP offer which excludes this closed data channel 1439 SHOULD be generated." with "... then the client SHOULD generate 1440 an SDP offer which excludes this closed data channel.". 1442 * In the last but one paragraph replacement of "must" with "The 1443 application MUST also close...". 1445 o In Section 5.1.2 addition of following note after the formal 1446 definition of the 'a=dcsa' attribute: "Note that the above 1447 reference to RFC 4566 defines were the attribute definition can be 1448 found; it does not provide any limitation on support of attributes 1449 defined in other documents in accordance with this attribute 1450 definition." 1452 11.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1454 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1455 channel consisting of paired SCTP outbound and inbound streams." 1456 Replacement of this definition with "Data channel: A WebRTC data 1457 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1458 consistent usage of "data channel" in the remainder of the 1459 document including the document's headline." 1461 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1462 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1464 In particular we expect "webrtc-datachannel" to become a more 1465 general term.' 1467 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1469 o In Section 5.1.1 removal of the example dcmap attribute line 1470 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1471 already four examples right after the ABNF rules in 1472 Section 5.1.1.1. Corresponding removal of following related note: 1473 "Note: This document does not provide a complete specification of 1474 how to negotiate the use of a WebRTC data channel to transport 1475 BFCP. Procedures specific to each subprotocol such as BFCP will 1476 be documented elsewhere. The use of BFCP is only an example of 1477 how the generic procedures described herein might apply to a 1478 specific subprotocol." 1480 o In Section 5.1.1 removal of following note: "Note: This attribute 1481 is derived from attribute "webrtc-DataChannel", which was defined 1482 in old version 03 of the following draft, but which was removed 1483 along with any support for SDP external negotiation in subsequent 1484 versions: [I-D.ietf-mmusic-sctp-sdp]." 1486 o Insertion of following new sentence to the beginning of 1487 Section 5.1.1.1: "dcmap is a media level attribute having 1488 following ABNF syntax:" 1490 o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id 1491 specifying sentence, which previously was placed right before the 1492 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1493 parameter and is noted directly after the "a=dcmap:" attribute's 1494 colon' as this information is part of the ABNF specification. 1496 o In Section 5.1.1.1 modification of the 'ordering-value' values 1497 from "0" or "1" to "true" or "false". Corresponding text 1498 modifications in Section 5.1.1.8. 1500 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1501 to rule name "escaped-char", which was not defined. Instead a 1502 rule with name "escaped" was defined. Renamed that rule's name to 1503 "escaped-char". 1505 o Insertion of a dedicated note right after the "a=dcmap:4" 1506 attribute example in Section 5.1.1.1 regarding the non-printable 1507 "escaped-char" character within the "label" value. 1509 o In Section 5.1.2's second paragraph replacement of "sctp stream 1510 identifier" with "SCTP stream identifier". 1512 o In first paragraph of Section 6.1 replacement of first two 1513 sentences 'For the SDP-based external negotiation described in 1514 this document, the initial offerer based "SCTP over DTLS" owns by 1515 convention the even stream identifiers whereas the initial 1516 answerer owns the odd stream identifiers. This ownership is 1517 invariant for the whole lifetime of the signaling session, e.g. it 1518 does not change if the initial answerer sends a new offer to the 1519 initial offerer.' with 'If an SDP offer/answer exchange (could be 1520 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1521 TCP/DTLS/SCTP based media description being accepted, and if this 1522 SDP offer/answer exchange results in the establishment of a new 1523 SCTP association, then the SDP offerer owns the even SCTP stream 1524 ids of this new SCTP association and the answerer owns the odd 1525 SCTP stream identifiers. If this "m" line is removed from the 1526 signaling session (its port number set to zero), and if usage of 1527 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1528 renegotiated later on, then the even and odd SCTP stream 1529 identifier ownership is redetermined as well as described above.' 1531 o In Section 6.3 the first action of an SDP answerer, when receiving 1532 an SDP offer, was described as "Applies the SDP offer. Note that 1533 the browser ignores data channel specific attributes in the SDP." 1534 Replacement of these two sentences with "Parses and applies the 1535 SDP offer. Note that the typical parser normally ignores unknown 1536 SDP attributes, which includes data channel related attributes." 1538 o In Section 6.3 the second sentence of the third SDP answerer 1539 action was "Note that the browser is asked to create data channels 1540 with stream identifiers not "owned" by the agent.". Replacement 1541 of this sentence with "Note that the agent is asked to create data 1542 channels with SCTP stream identifiers contained in the SDP offer 1543 if the SDP offer is accepted." 1545 o In Section 6.6 the third paragraph began with "A data channel can 1546 be closed by sending a new SDP offer which excludes the dcmap and 1547 dcsa attribute lines for the data channel. The port value for the 1548 m line SHOULD NOT be changed (e.g., to zero) when closing a data 1549 channel (unless all data channels are being closed and the SCTP 1550 association is no longer needed), since this would close the SCTP 1551 association and impact all of the data channels. If the answerer 1552 accepts the SDP offer then it MUST also exclude the corresponding 1553 attribute lines in the answer. ..." Replacement of this part with 1554 "The intention to close a data channel can be signaled by sending 1555 a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" 1556 attribute lines for the data channel. The port value for the "m" 1557 line SHOULD NOT be changed (e.g., to zero) when closing a data 1558 channel (unless all data channels are being closed and the SCTP 1559 association is no longer needed), since this would close the SCTP 1560 association and impact all of the data channels. If the answerer 1561 accepts the SDP offer then it MUST close those data channels whose 1562 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 1563 received SDP offer, unless those data channels were already 1564 closed, and it MUST also exclude the corresponding attribute lines 1565 in the answer." 1567 o In Section 6.6 the hanging text after the third paragraph was 1568 "This delayed close is to handle cases where a successful SDP 1569 answer is not received, in which case the state of session should 1570 be kept per the last successful SDP offer/answer." Replacement of 1571 this sentence with "This delayed closure is RECOMMENDED in order 1572 to handle cases where a successful SDP answer is not received, in 1573 which case the state of the session SHOULD be kept per the last 1574 successful SDP offer/answer." 1576 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1577 Section 5.1.1 contained already procedural descriptions related to 1578 data channel reliability negotiation. Creation of new Section 6.2 1579 and moval of reliability negotiation related text to this new 1580 section. 1582 11.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1584 o Removal of note "[ACTION ITEM]" from section "subprotocol 1585 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1586 should refer to IANA's WebSocket Subprotocol Name Registry defined 1587 in [RFC6455] 1589 o In whole document, replacement of "unreliable" with "partially 1590 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1591 [I-D.ietf-rtcweb-data-protocol] in most places. 1593 o Clarification of the semantic if the "max-retr" parameter is not 1594 present in an a=dcmap attribute line. In section "max-retr 1595 parameter" the sentence "The max-retr parameter is optional with 1596 default value unbounded" was replaced with "The max-retr parameter 1597 is optional. If the max-retr parameter is not present, then the 1598 maximal number of retransmissions is determined as per the generic 1599 SCTP retransmission rules as specified in [RFC4960]". 1601 o Clarification of the semantic if the "max-time" parameter is not 1602 present in an a=dcmap attribute line. In section "max-time 1603 parameter" the sentence "The max-time parameter is optional with 1604 default value unbounded" was replaced with "The max-time parameter 1605 is optional. If the max-time parameter is not present, then the 1606 generic SCTP retransmission timing rules apply as specified in 1607 [RFC4960]". 1609 o In section "label parameter" the sentence "Label is a mandatory 1610 parameter." was removed and following new sentences (including the 1611 note) were added: "The 'label' parameter is optional. If it is 1612 not present, then its value defaults to the empty string. Note: 1613 The empty string may also be explicitly used as 'label' value, 1614 such that 'label=""' is equivalent to the 'label' parameter not 1615 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1616 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1618 o In section "subprotocol parameter" the sentence "Subprotocol is a 1619 mandatory parameter." was replaced with "'Subprotocol' is an 1620 optional parameter. If the 'subprotocol' parameter is not 1621 present, then its value defaults to the empty string." 1623 o In the "Examples" section, in the first two SDP offer examples in 1624 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1625 'label="BFCP"'. 1627 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1628 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1629 replaced with "a=max-message-size" attribute lines, as per draft- 1630 ietf-mmusic-sctp-sdp-12. 1632 11.17. Changes against '-01' 1634 o Formal syntax for dcmap and dcsa attribute lines. 1636 o Making subprotocol as an optional parameter in dcmap. 1638 o Specifying disallowed parameter combinations for max-time and max- 1639 retr. 1641 o Clarifications on WebRTC data channel close procedures. 1643 11.18. Changes against '-00' 1645 o Revisions to identify difference between internal and external 1646 negotiation and their usage. 1648 o Introduction of more generic terminology, e.g. "application" 1649 instead of "browser". 1651 o Clarification of how "max-retr and max-time affect the usage of 1652 unreliable and reliable WebRTC data channels. 1654 o Updates of examples to take into account the SDP syntax changes 1655 introduced with draft-ietf-mmusic-sctp-sdp-07. 1657 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1658 attributes as this is now contained in the a=sctp-port attribute, 1659 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1660 association on top of the DTLS connection. 1662 12. References 1664 12.1. Normative References 1666 [I-D.ietf-mmusic-sctp-sdp] 1667 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1668 "Session Description Protocol (SDP) Offer/Answer 1669 Procedures For Stream Control Transmission Protocol (SCTP) 1670 over Datagram Transport Layer Security (DTLS) Transport.", 1671 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1672 2017. 1674 [I-D.ietf-mmusic-sdp-mux-attributes] 1675 Nandakumar, S., "A Framework for SDP Attributes when 1676 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1677 (work in progress), December 2016. 1679 [I-D.ietf-rtcweb-data-channel] 1680 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1681 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1682 progress), January 2015. 1684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1685 Requirement Levels", BCP 14, RFC 2119, 1686 DOI 10.17487/RFC2119, March 1997, 1687 . 1689 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1690 with Session Description Protocol (SDP)", RFC 3264, 1691 DOI 10.17487/RFC3264, June 2002, 1692 . 1694 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1695 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1696 July 2006, . 1698 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1699 Specifications: ABNF", STD 68, RFC 5234, 1700 DOI 10.17487/RFC5234, January 2008, 1701 . 1703 12.2. Informative References 1705 [I-D.ietf-clue-datachannel] 1706 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1707 clue-datachannel-14 (work in progress), August 2016. 1709 [I-D.ietf-mmusic-dtls-sdp] 1710 Holmberg, C. and R. Shpount, "Session Description Protocol 1711 (SDP) Offer/Answer Considerations for Datagram Transport 1712 Layer Security (DTLS) and Transport Layer Security (TLS)", 1713 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 1714 2017. 1716 [I-D.ietf-mmusic-msrp-usage-data-channel] 1717 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1718 and J. Marcon, "MSRP over Data Channels", draft-ietf- 1719 mmusic-msrp-usage-data-channel-07 (work in progress), 1720 September 2017. 1722 [I-D.ietf-rtcweb-data-protocol] 1723 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1724 Establishment Protocol", draft-ietf-rtcweb-data- 1725 protocol-09 (work in progress), January 2015. 1727 [IANA-SDP-Parameters] 1728 "Session Description Protocol (SDP) Parameters", Internet 1729 Assigned Numbers Authority Protocol Assignments Session 1730 Description Protocol (SDP) Parameters, 1731 . 1734 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1735 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1736 . 1738 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1739 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1740 . 1742 [WebRtcAPI] 1743 Bergkvist, A., Burnett, D., Jennings, C., and A. 1744 Narayanan, "WebRTC 1.0: Real-time Communication Between 1745 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1746 February 2015, 1747 . 1749 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1750 DCEP 1752 This appendix summarizes how data channels work in general and 1753 discusses some key aspects, which should be considered for the out- 1754 of-band negotiation of data channels if DCEP is not used. 1756 A WebRTC application creates a data channel by providing a number of 1757 setup parameters (subprotocol, label, maximal number of 1758 retransmissions, maximal retransmission time, order of delivery, 1759 priority). The application also specifies if it wants to make use of 1760 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1761 the application intends to negotiate data channels using the SDP 1762 offer/answer protocol. 1764 In any case, the SDP offer generated by the application is per 1765 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1766 the SCTP association on top of which data channels will run: 1768 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1769 c=IN IP4 192.0.2.1 1770 a=max-message-size:100000 1771 a=sctp-port:5000 1772 a=tls-id:abc3de65cddef001be82 1773 a=setup:actpass 1774 a=fingerprint:SHA-1 \ 1775 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1777 Note: A WebRTC application will only use "m" line format "webrtc- 1778 datachannel", and will not use other formats in the "m" line for 1779 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1780 only one SCTP association to be established on top of a DTLS 1781 association. 1783 Note: The above SDP media description does not contain any channel- 1784 specific information. 1786 A.1. Stream Identifier Numbering 1788 Independently from the requested type of negotiation, the application 1789 creating a data channel can either pass the stream identifier to the 1790 data channel stack to assign to the data channel or else let the data 1791 channel stack pick one identifier from the unused ones. 1793 To avoid glare situations, each endpoint can moreover own an 1794 exclusive set of stream identifiers, in which case an endpoint can 1795 only create a data channel with a stream identifier it owns. 1797 Which set of stream identifiers is owned by which endpoint is 1798 determined by convention or other means. 1800 Note:For data channels negotiated with the DCEP, one endpoint owns 1801 by convention the even stream identifiers, whereas the other owns 1802 the odd stream identifiers, as defined in 1803 [I-D.ietf-rtcweb-data-protocol]. 1805 Note:For data channels negotiated via different protocol from 1806 DCEP, no convention is defined by default. 1808 A.2. Generic Data Channel Negotiation Not Using DCEP 1810 A.2.1. Overview 1812 DCEP negotiation only provides for negotiation of data channel 1813 transport parameters and does not provide for negotiation of 1814 subprotocol specific parameters. DCEP-less data channel negotiation 1815 can be defined to allow negotiation of parameters beyond those 1816 handled by DCEP, e.g., parameters specific to the subprotocol 1817 instantiated on a particular data channel. 1819 The following procedures are common to all methods of data channel 1820 negotiation not using DCEP, whether in-band (communicated using 1821 proprietary means on an already established data channel) or out-of- 1822 band (using SDP offer/answer or some other protocol associated with 1823 the signaling channel). 1825 A.2.2. Opening a Data Channel 1827 In the case of DCEP-less negotiation, the endpoint application has 1828 the option to fully control the stream identifier assignments. 1829 However these assignments have to coexist with the assignments 1830 controlled by the data channel stack for the DCEP negotiated data 1831 channels (if any). It is the responsibility of the application to 1832 ensure consistent assignment of stream identifiers. 1834 When the application requests the creation of a new data channel to 1835 be set up via DCEP-less negotiation, the data channel stack creates 1836 the data channel locally without sending any DATA_CHANNEL_OPEN 1837 message in-band. However, even if the ICE (Interactive Connectivity 1838 Establishment), DTLS and SCTP procedures were already successfully 1839 completed, the application can't send data on this data channel until 1840 the negotiation is complete with the peer. This is because the peer 1841 needs to be aware of and accept the usage of this data channel. The 1842 peer, after accepting the data channel offer, can start sending data 1843 immediately. This implies that the offerer may receive data channel 1844 subprotocol messages before the negotiation is complete and the 1845 application should be ready to handle it. 1847 If the peer rejects the data channel part of the offer then it 1848 doesn't have to do anything as the data channel was not created using 1849 the stack. The offerer on the other hand needs to close the data 1850 channel that was opened by invoking relevant data channel stack API 1851 procedures. 1853 It is also worth noting that a data channel stack implementation may 1854 not provide any API to create and close data channels; instead the 1855 data channels may be used on the fly as needed just by communicating 1856 via non-DCEP means or by even having some local configuration/ 1857 assumptions on both the peers. 1859 The application then negotiates the data channel properties and 1860 subprotocol properties with the peer's application using a mechanism 1861 different from DCEP. 1863 The peer then symmetrically creates a data channel with these 1864 negotiated data channel properties. This is the only way for the 1865 peer's data channel stack to know which properties to apply when 1866 transmitting data on this channel. The data channel stack must allow 1867 data channel creation with any non-conflicting stream identifier so 1868 that both peers can create the data channel with the same stream 1869 identifier. 1871 A.2.3. Closing a Data Channel 1873 When the application requests the closing of a data channel 1874 negotiated without DCEP, the data channel stack always performs an 1875 SCTP SSN reset for this channel. 1877 Depending upon the method used for DCEP-less negotiation and the 1878 subprotocol associated with the data channel, the closing might in 1879 addition be signaled to the peer via SDP offer/answer negotiation. 1881 Authors' Addresses 1883 Keith Drage 1884 Unaffiliated 1886 Email: drageke@ntlworld.com 1887 Maridi R. Makaraju (Raju) 1888 Nokia 1889 2000 Lucent Lane 1890 Naperville, Illinois 1891 US 1893 Email: Raju.Makaraju@nokia.com 1895 Juergen Stoetzer-Bradler 1896 Unaffiliated 1898 Email: Juergen.S-B.ietf@email.de 1900 Richard Ejzak 1901 Unaffiliated 1903 Email: richard.ejzak@gmail.com 1905 Jerome Marcon 1906 Unaffiliated 1908 Roni Even (editor) 1909 Huawei 1911 Email: roni.even@huawei.com