idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-15.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 4, 2017) is 2334 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) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 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 7, 2018 Nokia 6 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 R. Even, Ed. 11 Huawei 12 December 4, 2017 14 SDP-based Data Channel Negotiation 15 draft-ietf-mmusic-data-channel-sdpneg-15 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 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 75 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 6 76 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 77 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6 78 5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10 79 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12 81 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 13 82 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 14 83 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 16 84 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 17 85 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 89 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21 90 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21 91 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22 92 8.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 94 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 10.1. Changes against 'draft-ietf-mmusic-data-channel- 96 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 23 98 10.2. Changes against 'draft-ietf-mmusic-data-channel- 99 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 23 100 10.3. Changes against 'draft-ietf-mmusic-data-channel- 101 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 23 102 10.4. Changes against 'draft-ietf-mmusic-data-channel- 103 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 24 104 10.5. Changes against 'draft-ietf-mmusic-data-channel- 105 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 24 106 10.6. Changes against 'draft-ietf-mmusic-data-channel- 107 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 25 108 10.7. Changes against 'draft-ietf-mmusic-data-channel- 109 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25 110 10.8. Changes against 'draft-ietf-mmusic-data-channel- 111 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 25 112 10.9. Changes against 'draft-ietf-mmusic-data-channel- 113 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 25 114 10.10. Changes against 'draft-ietf-mmusic-data-channel- 115 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 26 116 10.11. Changes against 'draft-ietf-mmusic-data-channel- 117 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27 118 10.12. Changes against 'draft-ietf-mmusic-data-channel- 119 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 120 10.13. Changes against 'draft-ietf-mmusic-data-channel- 121 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 29 122 10.14. Changes against 'draft-ietf-mmusic-data-channel- 123 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 31 124 10.15. Changes against 'draft-ejzak-mmusic-data-channel- 125 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 34 126 10.16. Changes against '-01' . . . . . . . . . . . . . . . . . 35 127 10.17. Changes against '-00' . . . . . . . . . . . . . . . . . 35 128 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 129 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 130 11.2. Informative References . . . . . . . . . . . . . . . . . 37 131 Appendix A. Generic Data Channel Negotiation Aspects When Not 132 Using DCEP . . . . . . . . . . . . . . . . . . . . . 37 133 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 38 134 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39 135 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39 136 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39 137 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 140 1. Introduction 142 The RTCWeb working group has defined the concept of bi-directional 143 data channels running on top of the Stream Control Transmission 144 Protocol (SCTP). RTCWeb allows applications to use data channels. 145 RTCWeb defines an in-band Data Channel Establishment Protocol (DCEP), 146 however other in-band or out-of-band protocols may be used for 147 establishing data channels. Each data channel consists of paired 148 SCTP streams sharing the same SCTP Stream Identifier. Data channels 149 are created by endpoint applications through the WebRTC API 150 (Application Programming Interface), or other users of a data channel 151 like CLUE. They can be used to transport proprietary or well-defined 152 protocols, which in the latter case can be signaled by the data 153 channel "subprotocol" parameter, conceptually similar to the 154 WebSocket "subprotocol". However, apart from the "subprotocol" value 155 transmitted to the peer, RTCWeb leaves it open how endpoint 156 applications can agree on how to instantiate a given subprotocol on a 157 data channel, and whether it is signaled in-band using DCEP or out- 158 of-band using a non-DCEP protocol (or both). In particular, the SDP 159 offer generated by the RTCweb data channel stack includes no channel- 160 specific information. 162 This document defines SDP offer/answer negotiation procedures to 163 establish data channels for transport of well-defined subprotocols, 164 to enable out-of-band negotiation. These procedures are based on 165 generic SDP offer/answer negotiation rules for SCTP based media 166 transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" 167 line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, 168 data channels could be defined over other SCTP based protocols, such 169 as SCTP over IP. However, corresponding potential other "m" line 170 proto values are not considered in this document. 172 This document makes use of MSRP (Message Session Relay Protocol) and 173 BFCP (Binary Floor Control Protocol) in many of the examples. It 174 does not provide a complete specification of how to negotiate the use 175 of a data channel to transport MSRP. Procedures specific to each 176 subprotocol such as MSRP are documented elsewhere. The use of MSRP 177 in some examples is only to show how the generic procedures described 178 herein might apply to a specific subprotocol. 180 2. Conventions 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Terminology 188 This document uses the following terms: 190 Data channel: A WebRTC data channel as specified in 191 [I-D.ietf-rtcweb-data-channel]. 193 Data channel stack: An entity which, upon application request, 194 runs the data channel protocol to keep track of states, sending 195 and receiving data. If the application is a browser based 196 JavaScript application then this stack resides in the browser. If 197 the application is a native application then this stack resides in 198 the application and is accessible via some sort of APIs. 200 Data channel properties: Fixed properties assigned to a data 201 channel at the time of its creation. Some of these properties 202 determine the way the data channel stack transmits data on this 203 channel (e.g., stream identifier, reliability, order of 204 delivery...). 206 Data channel subprotocol: The application protocol which is 207 transported over a single data channel. Data channel subprotocol 208 messages are sent as data channel payload over an established data 209 channel. If an SDP offer/answer exchange is used as specified in 210 this document to negotiate the establishment of data channels, 211 corresponding data channel properties, associated data channel 212 subprotocols and data channel subprotocol properties, then the 213 data channel subprotocols may be identified by the values of the 214 "subprotocol" parameters of the SDP "a=dcmap" attribute as 215 described in Section 5.1.1.5. Within this document the term "data 216 channel subprotocol" is often abbreviated as just "subprotocol". 218 DCEP: Data Channel Establishment Protocol defined in 219 [I-D.ietf-rtcweb-data-protocol]. 221 In-band: Transmission through the peer-to-peer SCTP association. 223 Out-of-band: Transmission through the application signaling path. 225 Peer: From the perspective of one of the agents in a session, its 226 peer is the other agent. Specifically, from the perspective of 227 the SDP offerer, the peer is the SDP answerer. From the 228 perspective of the SDP answerer, the peer is the SDP offerer. 230 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 231 as specified in [RFC4960]. 233 Stream identifier: The identifier of the outbound and inbound SCTP 234 streams composing a data channel. 236 4. Applicability Statement 238 The mechanism in this document only applies to the Session 239 Description Protocol (SDP) [RFC4566], when used together with the SDP 240 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 241 scope of this document, and is thus undefined. 243 5. SDP Offer/Answer Negotiation 245 This section defines an SDP extension by which two clients can 246 negotiate data channel-specific and subprotocol-specific parameters 247 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 248 extension only defines usage in the context of SDP offer/answer. 250 Appendix A provides information how data channels work in general and 251 especially summarizes some key aspects, which should be considered 252 for the negotiation of data channels if DCEP is not used. 254 5.1. SDP Syntax 256 Two new SDP attributes are defined to support SDP offer/answer 257 negotiation of data channels. The first attribute provides for 258 negotiation of channel-specific parameters. The second attribute 259 provides for negotiation of subprotocol-specific parameters. 261 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 263 Associated with the SDP "m" line that defines the SCTP association 264 for data channels (defined in Section 3), each SDP offer and answer 265 includes one "a=dcmap:" attribute that defines the data channel 266 parameters for each data channel to be negotiated. Each such 267 attribute line specifies the following parameters for a data channel: 268 SCTP stream identifier, subprotocol, label, maximal number of 269 retransmissions, maximal retransmission time, order of delivery, and 270 priority. 272 The intention in exchanging these attributes is to create, on two 273 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 274 pairs of oppositely directed data channels having the same set of 275 attributes. It is assumed that the data channel properties 276 (reliable/partially reliable, ordered/unordered) are suitable per the 277 subprotocol transport requirements. 279 5.1.1.1. dcmap Attribute 281 "a=dcmap:" is a media level attribute having following ABNF 282 (Augmented Backus-Naur Form, [RFC5234]) syntax. 284 Formal Syntax: 286 Name: dcmap 287 Value: dcmap-value 289 Usage Level: media 291 Charset Dependent: no 293 Syntax: 295 dcmap-value = dcmap-stream-id 296 [ SP dcmap-opt *(";" dcmap-opt) ] 297 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 298 / maxretr-opt / maxtime-opt / priority-opt 299 ; Either only maxretr-opt or maxtime-opt 300 ; is present. 302 dcmap-stream-id = 1*5DIGIT 303 ordering-opt = "ordered=" ordering-value 304 ordering-value = "true" / "false" 305 subprotocol-opt = "subprotocol=" quoted-string 306 label-opt = "label=" quoted-string 307 maxretr-opt = "max-retr=" maxretr-value 308 maxretr-value = "0" / integer 309 ; number of retransmissions, 310 ; less than 2^32, 311 ; derived from 'Reliability Parameter' of 312 ; [I-D.ietf-rtcweb-data-protocol] 313 maxtime-opt = "max-time=" maxtime-value 314 maxtime-value = "0" / integer 315 ; milliseconds, 316 ; less than 2^32, 317 ; derived from 'Reliability Parameter' of 318 ; [I-D.ietf-rtcweb-data-protocol] 319 priority-opt = "priority=" priority-value 320 priority-value = "0" / integer 321 ; unsigned integer value indicating the priority of 322 ; the data channel, 323 ; less than 2^16, 324 ; derived from 'Priority' of 325 ; [I-D.ietf-rtcweb-data-protocol] 327 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 328 quoted-char = SP / quoted-visible 329 quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % 330 escaped-char = "%" HEXDIG HEXDIG 331 DQUOTE = 332 integer = 334 Examples: 336 a=dcmap:0 337 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 338 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 339 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 340 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 342 Note: The last example (a=dcmap:4) shows a 'label' parameter value 343 which contains one non-printable 'escaped-char' character (the 344 tabulator character). 346 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 347 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 348 present. Both MUST NOT be present. 350 5.1.1.2. dcmap Multiplexing Category 352 Multiplexing characteristics of SDP attributes are described in 353 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 354 multiplexing categories are introduced there. 356 The multiplexing category of the "a=dcmap:" attribute is SPECIAL. 358 As the usage of multiple SCTP associations on top of a single DTLS 359 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 360 "a=dcmap:" attribute multiplexing rules are specified for the 361 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 362 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 363 multiple SCTP associations on top of a single DTLS association, or 364 how to add multiple SCTP associations to one BUNDLE group, then 365 multiplexing rules for the "a=dcmap:" attribute need to be defined as 366 well, for instance in an extension of this SDP based data channel 367 negotiation specification. 369 5.1.1.3. dcmap-stream-id Parameter 371 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 372 within the SCTP association used to form the data channel. 374 5.1.1.4. label Parameter 376 The 'label' parameter indicates the name of the channel. It 377 represents a label that can be used to distinguish, in the context of 378 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 379 RTCDataChannel objects. This parameter maps to the 'Label' parameter 380 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 381 optional. If it is not present, then its value defaults to the empty 382 string. 384 Note: The empty string MAY also be explicitly used as a 'label' 385 value, such that 'label=""' is equivalent to the 'label' parameter 386 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 387 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 389 5.1.1.5. subprotocol Parameter 391 The 'subprotocol' parameter indicates which protocol the client 392 expects to exchange via the channel. This parameter maps to the 393 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 394 Section 8.1 specifies how new subprotocol parameter values are 395 registered. 'Subprotocol' is an optional parameter. If the 396 'subprotocol' parameter is not present, then its value defaults to an 397 empty string. 399 Note: The empty string MAY also be explicitly used as 'subprotocol' 400 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 401 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 402 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 403 empty string. 405 5.1.1.6. max-retr Parameter 407 This parameter indicates that the data channel is partially reliable. 408 The 'max-retr' parameter indicates the maximal number of times a user 409 message will be retransmitted. The max-retr parameter is optional. 410 If the max-retr parameter is not present, then the maximal number of 411 retransmissions is determined as per the generic SCTP retransmission 412 rules as specified in [RFC4960]. This parameter maps to the 'Number 413 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 415 5.1.1.7. max-time Parameter 417 This parameter indicates that the data channel is partially reliable. 418 A user message will no longer be transmitted or retransmitted after a 419 specified life-time given in milliseconds in the 'max-time' 420 parameter. The max-time parameter is optional. If the max-time 421 parameter is not present, then the generic SCTP retransmission timing 422 rules apply as specified in [RFC4960]. This parameter maps to the 423 'Lifetime in ms' parameter defined in 424 [I-D.ietf-rtcweb-data-protocol]. 426 5.1.1.8. ordered Parameter 428 The 'ordered' parameter with value "true" indicates that the receiver 429 MUST dispatch DATA chunks in the data channel to the upper layer 430 while preserving the order. The ordered parameter is optional and 431 takes two values: "true" for ordered and "false" for unordered 432 delivery with "true" as the default value. Any other value is 433 ignored and default "ordered=true" is assumed. In the absence of 434 this parameter "ordered=true" is assumed. This parameter maps to the 435 ordered or unordered data channel types as defined in 436 [I-D.ietf-rtcweb-data-protocol]. 438 5.1.1.9. priority Parameter 440 The 'priority' parameter indicates the data channel's priority 441 relative to the priorities of other data channels, which may 442 additionally exist over the same SCTP association. The 'priority' 443 parameter maps to the 'Priority' parameter defined in 444 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 445 optional. In the absence of this parameter "priority=256" is 446 assumed. 448 5.1.2. Other Media Level Attributes 450 In the SDP, each data channel declaration MAY also be followed by 451 other media level SDP attributes, which are either specifically 452 defined for or applied to the subprotocol in use. Each of these 453 attributes is represented by one new attribute line, and it includes 454 the contents of a media-level SDP attribute already defined for use 455 with this (sub)protocol in another IETF (Internet Engineering Task 456 Force) document. Subprotocol specific attributes MAY also be defined 457 for exclusive use with data channel transport, but MUST use the same 458 syntax described here for other subprotocol related attributes. 460 5.1.2.1. dcsa Attribute 462 Each SDP attribute, related to the subprotocol, that would normally 463 be used to negotiate the subprotocol using SDP is replaced with an 464 attribute of the form "a=dcsa:stream-id original-attribute", where 465 dcsa stands for "data channel subprotocol attribute", stream-id is 466 the SCTP stream identifier assigned to this subprotocol instance, and 467 original-attribute represents the contents of the subprotocol related 468 attribute to be included. 470 The same syntax applies to any other SDP attribute required for 471 negotiation of this instance of the subprotocol. 473 Formal Syntax: 475 Name: dcsa 477 Value: dcsa-value 479 Usage Level: media 481 Charset Dependent: no 483 Syntax: 485 dcsa-value = stream-id SP attribute 486 attribute = 488 Example (other MSRP related SDP attributes are omitted for brevity): 490 a=dcsa:2 accept-types:text/plain 492 Note that the above reference to [RFC4566] defines where the 493 attribute definition can be found; it does not provide any limitation 494 on support of attributes defined in other documents in accordance 495 with this attribute definition. Note however that not all SDP 496 attributes are suitable as a "a=dcsa:" parameter. 497 [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned 498 Numbers Authority) registered session and media level or media level 499 only SDP attributes. 501 Thus in the example above, the original attribute line "a=accept- 502 types:text/plain" is represented by the attribute line "a=dcsa:2 503 accept-types:text/plain", which specifies that this instance of the 504 MSRP subprotocol being transported on the SCTP association using the 505 data channel with stream id 2 accepts plain text files. 507 As opposed to the data channel "a=dcmap:" attribute parameters, these 508 parameters are subject to offer/answer negotiation following the 509 procedures defined in the subprotocol specific documents. 511 It is assumed that in general the usages of subprotocol related media 512 level attributes are independent from the subprotocol's transport 513 protocol. Such transport protocol independent subprotocol related 514 attributes are used in the same way as defined in the original 515 subprotocol specification, also if the subprotocol is transported 516 over a data channel and if the attribute is correspondingly embedded 517 in a "a=dcsa" attribute. 519 There may be cases, where the usage of a subprotocol related media 520 level attribute depends on the subprotocol's transport protocol. In 521 such cases the subprotocol related usage of the attribute is expected 522 to be described for the data channel transport. A data channel 523 specific usage of a subprotocol attribute is expected to be specified 524 in the same document, that registers the subprotocol's identifier for 525 data channel usage as described in Section 8.1. 527 5.1.2.2. dcsa Multiplexing Category 529 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 531 As the usage of multiple SCTP associations on top of a single DTLS 532 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 533 "a=dcsa:" attribute multiplexing rules are specified for the 534 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 535 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 536 multiple SCTP associations on top of a single DTLS association, or 537 how to add multiple SCTP associations to one BUNDLE group, then 538 multiplexing rules for the "a=dcsa:" attribute need to be defined as 539 well, for instance in an extension of this SDP based data channel 540 negotiation specification. 542 5.2. Procedures 544 5.2.1. Managing Stream Identifiers 546 If a SDP offer/answer exchange (could be the initial or a subsequent 547 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 548 description being accepted, and if this SDP offer/answer exchange 549 results in the establishment of a new SCTP association, then the SDP 550 offerer owns the even SCTP stream ids of this new SCTP association 551 and the answerer owns the odd SCTP stream identifiers. If this "m" 552 line is removed from the signaling session (its port number set to 553 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 554 SCTP based "m" line is renegotiated later on, then the even and odd 555 SCTP stream identifier ownership is re-determined as described above. 557 This document allows simultaneous use of SDP offer/answer and DCEP 558 negotiation. However, an SCTP stream MUST NOT be referenced in a 559 "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if 560 the associated SCTP stream has already been negotiated via DCEP. 561 Stream ids that are not currently used in SDP can be used for DCEP 562 negotiation. Stream id allocation per SDP offer/answer negotiation 563 may not align with DTLS role based allocation. This could cause 564 glare conditions when one side tries to do SDP offer/answer 565 negotiation on a stream id while the other end tries to open a data 566 channel on the same stream id using DCEP negotiation. To avoid these 567 glare conditions this document recommends that the data channel stack 568 user always selects stream ids per the above described SDP offer/ 569 answer rule even when DCEP negotiation is used. To avoid glare 570 conditions, it is possible to come up with a different stream id 571 allocation scheme, but such schemes are outside the scope of this 572 document. 574 5.2.2. Negotiating Data Channel Parameters 576 Conveying a reliable data channel is achieved by including neither 577 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 578 "a=dcmap:" attribute line. Conveying a partially reliable data 579 channel is achieved by including only one of 'max-retr' or 'max- 580 time'. By definition max-retr and max-time are mutually exclusive, 581 so at most one of them MAY be present in the "a=dcmap:" attribute 582 line. If a SDP offer contains both of these parameters then the 583 receiver of such an SDP offer MUST reject the SDP offer. If a SDP 584 answer contains both of these parameters then the offerer MUST treat 585 the associated SDP offer/answer failed and take appropriate recovery 586 actions. These recovery options are outside the scope of this 587 document. 589 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 590 ordered parameters, if those were present in the offer, and MAY 591 include a label parameter. They MAY appear in any order, which could 592 be different from the SDP offer, in the SDP answer. 594 When sending a subsequent offer or an answer, and for as long as the 595 data channel is still open, the sender MUST replicate the same 596 information. 598 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 599 mapped to SDP in the following manner, where "ordered=true" is the 600 default and may be omitted: 602 DATA_CHANNEL_RELIABLE 603 ordered=true 605 DATA_CHANNEL_RELIABLE_UNORDERED 606 ordered=false 608 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 609 ordered=true;max-retr= 611 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 612 ordered=false;max-retr= 614 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 615 ordered=true;max-time= 617 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 618 ordered=false;max-time= 620 5.2.3. Opening a Data Channel 622 The procedure for opening a data channel using SDP offer/answer 623 negotiation starts with the agent preparing to send an SDP offer. If 624 a peer receives an SDP offer before starting to send a new SDP offer 625 with data channels that are to be SDP offer/answer negotiated, or 626 loses an SDP offer glare resolution procedure in this case, it MUST 627 wait until the ongoing SDP offer/answer completes before resuming the 628 SDP offer/answer negotiation procedure. 630 The agent that intends to send an SDP offer to create data channels 631 through SDP offer/answer negotiation performs the following: 633 o Creates data channels using stream identifiers from the owned set 634 (see Section 5.2.1). 636 o Generates a new SDP offer. 638 o Determines the list of stream identifiers assigned to data 639 channels opened through SDP offer/answer negotiation. 641 o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:" 642 attributes needed, if any, for each SDP offer/answer negotiated 643 data channel, as described in Section 5.1 and in Section 5.2.2. 645 o If it adds "a=dcsa" attributes to the SDP offer, then it SHOULD 646 add the subprotocol parameter to the "a=dcmap" attribute with a 647 non-empty subprotocol identifier. 649 o Sends the SDP offer. 651 The peer receiving such an SDP offer performs the following: 653 o Parses and applies the SDP offer, taking into account the 654 considerations discussed in Section 5.2.5. 656 o Analyzes the channel parameters and subprotocol attributes to 657 determine whether to accept each offered data channel. 659 o For accepted data channels, the agent MUST create peer instances 660 for the data channels using the SCTP stream identifiers and 661 channel parameters contained in the SDP offer. 663 o Generates an SDP answer. 665 o Completes the SDP answer with the "a=dcmap:" and optional 666 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 667 data channel, as described in Section 5.1 and in Section 5.2.2. 669 o Sends the SDP answer. 671 The agent receiving such an SDP answer performs the following: 673 o Closes any created data channels as described in Section 5.2.4 for 674 which the expected "a=dcmap:" and "a=dcsa:" attributes are not 675 present in the SDP answer. 677 o Applies the SDP answer. 679 Each agent application MUST wait to send data until it has 680 confirmation that the data channel at the peer is instantiated. For 681 WebRTC, this is when both data channel stacks have channel parameters 682 instantiated. This occurs: 684 o At both peers when a data channel is created without an 685 established SCTP association, as soon as the SCTP association is 686 successfully established. 688 o At the agent receiving an SDP offer for which there is an 689 established SCTP association, as soon as it creates an SDP offer/ 690 answer negotiated data channel based on information signaled in 691 the SDP offer. 693 o At the agent sending an SDP offer to create a new SDP offer/answer 694 negotiated data channel for which there is an established SCTP 695 association, when it receives the SDP answer confirming acceptance 696 of the data channel or when it begins to receive data on the data 697 channel from the peer, whichever occurs first. 699 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 700 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 702 5.2.4. Closing a Data Channel 704 When the application requests the closing of a data channel that was 705 negotiated via SDP offer/answer, the data channel stack always 706 performs an SCTP SSN reset for this channel. 708 It is specific to the subprotocol whether this closing MUST in 709 addition be signaled to the peer via a new SDP offer/answer exchange. 711 The intention to close a data channel can be signaled by sending a 712 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 713 lines for the data channel. The offerer SHOULD NOT change the port 714 value for the "m" line (e.g. to zero) when closing a data channel 715 (unless all data channels are being closed and the SCTP association 716 is no longer needed), since this would close the SCTP association and 717 impact all of the data channels. If the answerer accepts the SDP 718 offer then the answerer MUST close those data channels whose 719 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 720 received SDP offer, unless those data channels were already closed, 721 and the answerer MUST also exclude the corresponding attribute lines 722 in the answer. In addition to that, the SDP answerer MAY exclude 723 other data channels which were closed but not yet communicated to the 724 peer. So, the offerer MUST inspect the answer to see if it has to 725 close other data channels that are now not included in the answer. 727 If a new SDP offer/answer is used to close data channels then the 728 data channel(s) SHOULD only be closed by the answerer/offerer after a 729 successful SDP answer is sent/received. 731 This delayed closure is RECOMMENDED in order to handle cases where 732 a successful SDP answer is not received, in which case the state 733 of the session SHOULD be kept per the last successful SDP offer/ 734 answer. 736 If a client receives a data channel close indication (due to inband 737 SCTP SSN reset or some other reason) without associated SDP offer 738 then the client SHOULD generate an SDP offer which excludes this 739 closed data channel. 741 The application MUST also close any data channel that was negotiated 742 via SDP offer/answer, for which the stream identifiers are not listed 743 in an incoming SDP offer. 745 A closed data channel using local close (SCTP SSN reset), without an 746 additional SDP offer/answer to close it, may be reused for a new data 747 channel. This can only be done via new SDP offer/answer, describing 748 the new subprotocol and its attributes, only after the corresponding 749 data channel close acknowledgement is received from the peer (i.e. 750 SCTP SSN reset of both incoming and outgoing streams is completed). 751 This restriction is to avoid the race conditions between arrival of 752 "SDP offer which reuses stream" with "SCTP SSN reset which closes 753 outgoing stream" at the peer. 755 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 757 SDP offer has no "a=dcmap:" attributes. 759 * Initial SDP offer: No data channel is negotiated yet. The DTLS 760 association and SCTP association is negotiated and, if agreed, 761 established as per [I-D.ietf-mmusic-sctp-sdp]. 763 * Subsequent SDP offer: All the SDP offer/answer negotiated data 764 channels are expected to be closed now. The DTLS/SCTP 765 association remains open for SDP offer/answer or DCEP 766 negotiation of data channels. 768 SDP answer has no "a=dcmap:" attributes. 770 * Initial SDP answer: Either the peer does not support "a=dcmap:" 771 attributes or it rejected all the data channels. In either 772 case the offerer closes all the SDP offer/answer negotiated 773 data channels that were open at the time of initial offer. The 774 DTLS association and SCTP association will still be setup. 776 * Subsequent SDP answer: All the SDP offer/answer negotiated data 777 channels are expected to be closed now. The SCTP association 778 remains open for future SDP offer/answer or DCEP negotiation of 779 data channels. 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 has no "a=dcsa:" attributes for a data channel. 792 * This is allowed and indicates there are no subprotocol 793 parameters to convey. 795 SDP answer has no "a=dcsa:" attributes for a data channel. 797 * This is allowed and indicates there are no subprotocol 798 parameters to convey in the SDP answer. The number of 799 "a=dcsa:" attributes in the SDP answer does not have to match 800 the number of "a=dcsa:" attributes in the SDP offer. 802 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 803 attribute is unknown. 805 * The receiver of such an SDP offer or answer SHOULD ignore this 806 entire "a=dcsa" attribute line. 808 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 809 attribute is known, but whose subprotocol attribute semantic is 810 not known for the data channel transport case. 812 * The receiver of such an SDP offer or answer SHOULD ignore this 813 entire "a=dcsa" attribute line. 815 6. Examples 817 SDP offer: 819 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 820 c=IN IP4 192.0.2.1 821 a=max-message-size:100000 822 a=sctp-port:5000 823 a=setup:actpass 824 a=fingerprint:SHA-1 \ 825 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 826 a=tls-id:abc3de65cddef001be82 827 a=dcmap:0 subprotocol="BFCP";label="BFCP" 829 SDP answer: 831 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 832 c=IN IP4 192.0.2.2 833 a=max-message-size:100000 834 a=sctp-port:5002 835 a=setup:passive 836 a=fingerprint:SHA-1 \ 837 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 838 a=tls-id:dcb3ae65cddef0532d42 840 Figure 1: Example 1 842 In the above example the SDP answerer rejected the data channel with 843 stream id 0 either for explicit reasons or because it does not 844 understand the "a=dcmap:" attribute. As a result the offerer will 845 close the data channel created with the SDP offer/answer negotiation 846 option. The SCTP association will still be setup over DTLS. At this 847 point the offerer or the answerer may use DCEP negotiation to open 848 data channels. 850 SDP offer: 852 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 853 c=IN IP4 192.0.2.1 854 a=max-message-size:100000 855 a=sctp-port:5000 856 a=setup:actpass 857 a=fingerprint:SHA-1 \ 858 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 859 a=tls-id:abc3de65cddef001be82 860 a=dcmap:0 subprotocol="BFCP";label="BFCP" 861 a=dcmap:2 subprotocol="MSRP";label="MSRP" 862 a=dcsa:2 accept-types:message/cpim text/plain 863 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 865 SDP answer: 867 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 868 c=IN IP4 192.0.2.2 869 a=max-message-size:100000 870 a=sctp-port:5002 871 a=setup:passive 872 a=fingerprint:SHA-1 \ 873 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 874 a=tls-id:dcb3ae65cddef0532d42 875 a=dcmap:2 subprotocol="MSRP";label="MSRP" 876 a=dcsa:2 accept-types:message/cpim text/plain 877 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 879 Figure 2: Example 2 881 In the above example the SDP offer contains data channels for BFCP 882 (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 883 answer rejected BFCP and accepted MSRP. So, the offerer closes the 884 data channel for BFCP and both offerer and answerer may start using 885 the MSRP data channel (after the SCTP association is set up). The 886 data channel with stream id 0 is free and can be used for future DCEP 887 or SDP offer/answer negotiation. 889 Continuing the example in Figure 2. 891 Subsequent SDP offer: 893 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 894 c=IN IP4 192.0.2.1 895 a=max-message-size:100000 896 a=sctp-port:5000 897 a=setup:actpass 898 a=fingerprint:SHA-1 \ 899 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 900 a=tls-id:abc3de65cddef001be82 901 a=dcmap:4 subprotocol="MSRP";label="MSRP" 902 a=dcsa:4 accept-types:message/cpim text/plain 903 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 905 Subsequent SDP answer: 907 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 908 c=IN IP4 192.0.2.2 909 a=max-message-size:100000 910 a=sctp-port:5002 911 a=setup:passive 912 a=fingerprint:SHA-1 \ 913 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 914 a=tls-id:dcb3ae65cddef0532d42 915 a=dcmap:4 subprotocol="MSRP";label="MSRP" 916 a=dcsa:4 accept-types:message/cpim text/plain 917 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 919 Figure 3: Example 3 921 The above example is a continuation of the example in Figure 2. The 922 SDP offerer now removes the MSRP data channel with stream id 2, but 923 opens a new MSRP data channel with stream id 4. The answerer accepts 924 the entire offer. As a result the offerer closes the earlier 925 negotiated MSRP related data channel and both offerer and answerer 926 may start using new the MSRP related data channel. 928 7. Security Considerations 930 No security considerations are envisaged beyond those already 931 documented in [RFC4566]. 933 8. IANA Considerations 934 8.1. Subprotocol Identifiers 936 Registration of new subprotocol identifiers is performed using the 937 existing IANA "WebSocket Subprotocol Name Registry" table. 939 The following text should be added following the title of the table. 941 "This table also includes subprotocol identifiers specified for usage 942 within a WebRTC data channel." 944 The following reference should be added to under the heading 945 reference: "RFC XXXX". 947 This document assigns no new values to this table. 949 A subprotocol may simultaneously be defined for data channel 950 transport and for Websocket transport. In such a case the 951 "Subprotocol Definition" and "Reference" cells in the subprotocol's 952 row of the IANA "WebSocket Subprotocol Name Registry" table should 953 contain two entries. One entry in each of these cells should refer 954 to the Websocket related subprotocol specification, and the other 955 entry should refer to the data channel related subprotocol 956 specification. 958 NOTE to RFC Editor: Please replace "XXXX" with the number of this 959 RFC. 961 8.2. New SDP Attributes 963 8.2.1. dcmap 965 NOTE to RFC Editor: Please replace "XXXX" with the number of this 966 RFC. 968 This document defines a new SDP media-level attribute "a=dcmap:" as 969 follows: 971 +-----------------------+-------------------------------------------+ 972 | Contact name: | MMUSIC Chairs | 973 | Contact email: | mmusic-chairs@ietf.org | 974 | Attribute name: | dcmap | 975 | Attribute syntax: | As per Section 5.1.1.1 | 976 | Attribute semantics: | As per Section 5.1.1.1 | 977 | Usage level: | media | 978 | Charset dependent: | No | 979 | Purpose: | Define data channel specific parameters | 980 | Appropriate values: | As per Section 5.1.1.1 | 981 | O/A procedures: | As per Section 5.2 | 982 | Mux category: | SPECIAL. See Section 5.1.1.2 | 983 | Reference: | RFCXXXX | 984 +-----------------------+-------------------------------------------+ 986 8.2.2. dcsa 988 NOTE to RFC Editor: Please replace "XXXX" with the number of this 989 RFC. 991 This document defines a new SDP media-level attribute "a=dcsa:" as 992 follows: 994 +-----------------------+-------------------------------------------+ 995 | Contact name: | MMUSIC Chairs | 996 | Contact email: | mmusic-chairs@ietf.org | 997 | Attribute name: | dcsa | 998 | Attribute syntax: | As per Section 5.1.2.1 | 999 | Attribute semantics: | As per Section 5.1.2.1 | 1000 | Usage level: | media | 1001 | Charset dependent: | No | 1002 | Purpose: | Define data channel subprotocol specific | 1003 | | attributes | 1004 | Appropriate values: | As per Section 5.1.2.1 | 1005 | O/A procedures: | As per Section 5.2 | 1006 | Mux category: | SPECIAL. See Section 5.1.2.2 | 1007 | Reference: | RFCXXXX | 1008 +-----------------------+-------------------------------------------+ 1010 8.3. New Usage Level 1012 This document introduces a new "Data Channel Subprotocol Attribute" 1013 (dcsa) usage level to the SDP to the IANA SDP att-field registry. 1014 SDP attributes that are defined for use at the dcsa usage level only 1015 SHALL use the dcsa usage level when registering the attribute. If 1016 existing media attributes are used in a datachannel subprotocol 1017 specific way (Section 5.1.2.1), then a new dcsa usage level MUST be 1018 defined for the existing media attribute. Where the SDP attribute is 1019 applicable to a particular subprotocol/s this SHALL also be 1020 registered by indicating the applicable subprotocol identifiers (see 1021 Section 8.1) along with the dcsa usage level. E.g. 1023 +-----------------------+-------------------------------------------+ 1024 | ... | ... | 1025 | Usage level: | dcsa(MSRP) | 1026 | ... | ... | 1027 +-----------------------+-------------------------------------------+ 1029 9. Acknowledgments 1031 The authors wish to acknowledge the borrowing of ideas from other 1032 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 1033 and Gavin Llewellyn, and to thank Flemming Andreasen, Roni Even, 1034 Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, 1035 Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their 1036 invaluable comments. 1038 10. CHANGE LOG 1040 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' 1042 o Change "dtls-id" to "tls-id" and assign 20 octet long values 1044 o Remove of RFC4566bis draft from list of normative references. 1046 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' 1048 o Modification of Keith's address information. 1050 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' 1052 o dcmap-stream-id syntax change to limit size to 5 digits. 1054 o Add missing 'x' prefix to quoted-visible syntax. 1056 o Align SDP offerer and answerer handling when both max-retr and 1057 max-time are present. 1059 o Use of TEST-NET-1 ip addresses in examples. 1061 o Add missing a=dtls-id in one example. 1063 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1065 o Removal of the "a=connection" attribute lines from all SDP 1066 examples. 1068 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1070 o In the introduction: 1072 * Replacement of the sentence "The RTCWeb working group has 1073 defined the concept of bi-directional data channels running on 1074 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1075 Security protocol)" with "The RTCWeb working group has defined 1076 the concept of bi-directional data channels running on top of 1077 the Stream Control Transmission Protocol (SCTP)". 1079 * Addition of following sentences to the second paragraph: "These 1080 procedures are based on generic SDP offer/answer negotiation 1081 rules for SCTP based media transport as specified in 1082 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1083 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 1084 could be defined over other SCTP based protocols, such as SCTP 1085 over IP. However, corresponding potential other "m" line proto 1086 values are not considered in this document." 1088 o Replacement of "DTLS connection" with "DTLS association" 1089 throughout the document. 1091 o In sections Section 5.1.1.2 and Section 5.1.2.2 removal of the 1092 sentences "This document also does not specify multiplexing rules 1093 for this attribute for SCTP or SCTP/DTLS proto values". 1095 o In the text related to "Subsequent SDP answer" in section 1096 Section 5.2.5 replacement of "The DTLS/SCTP association remains 1097 open ..." with "The SCTP association remains open ...". 1099 o In the text after the second SDP answer in section Section 6 1100 replacement of "... (after SCTP/DTLS association is setup)" with 1101 "... (after the SCTP association is set up)". 1103 o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative 1104 references. 1106 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1107 examples in Section 6. 1109 10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1111 o Addition of definition of "data channel subprotocol" to Section 3 1112 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1113 archive/web/mmusic/current/msg15827.html. 1115 o Addition of RFC4566bis draft to list of normative references. 1117 o Updates of tables in Section 8.2.1 and Section 8.2.2 as per 1118 section 8.2.4 of RFC4566bis draft. 1120 o Addition of new Section 8.3. 1122 10.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1124 o Addition of two new paragraphs to Section 5.1.2.1 regarding 1125 subprotocol attribute relationship with transport protocol. 1127 o Addition of a note to Section 8.1 regarding subprotocols 1128 simultaneously defined for data channel and Websocket usage. 1130 o Addition of two further SDP offer/answer considerations to 1131 Section 5.2.5 regarding unknown subprotocol attributes and known 1132 subprotocol attributes with unknown data channel transport related 1133 semantic. 1135 10.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1137 o Changes addressing Christian Groves's WGLC review comments raised 1138 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1139 msg15357.html and http://www.ietf.org/mail- 1140 archive/web/mmusic/current/msg15359.html. 1142 10.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1144 o In IANA registration Section 8.2.1 and Section 8.2.2 replacement 1145 of contact name and e-mail address with "MMUSIC Chairs" and 1146 "mmusic-chairs@ietf.org". 1148 o In Section 5.1.2.1 replacement of "Thus in the example above, the 1149 original attribute line "a=accept- types:text/plain" is 1150 represented by the attribute line "a=dcsa:2 accept-types:text/ 1151 plain", which specifies that this instance of MSRP being 1152 transported on the SCTP association using the data channel with 1153 stream id 2 accepts plain text files." with "... which specifies 1154 that this instance of the MSRP subprotocol being transported ...". 1156 o The last paragraph of Section 5.1.2.1 started with "Note: This 1157 document does not provide a complete specification ...". Removal 1158 of "Note:" and move of this paragraph to the introduction in 1159 Section 1 as last paragraph. 1161 o Section 5.1.2's headline was "Subprotocol Specific Attributes". 1162 Change of this headline to "Other Media Level Attributes" and 1163 adaptations of the first paragraph of this section and the first 1164 paragraph of Section 5.1.2.1 in order to clarify that not only 1165 those attributes may be encapsulated in a "dcsa" attribute, which 1166 are specifically defined for the subprotocol, but that also other 1167 attributes may be encapsulated if they are related to the specific 1168 subprotocol instance. 1170 o Move of the last but one paragraph of Section 5.1.2.1 starting 1171 with "The same syntax applies to ..." right in front of the formal 1172 syntax definition of the "dcsa" attribute. 1174 o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 1175 in order not to explicitly restrict usage of the "a=dcmap:" and 1176 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1177 SCTP" or "TCP/DTLS/SCTP". 1179 10.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1181 o In Section 5.1.1.5 the first (and only) paragraph was "The 1182 'subprotocol' parameter indicates which protocol the client 1183 expects to exchange via the channel. 'Subprotocol' is an optional 1184 parameter. If the 'subprotocol' parameter is not present, then 1185 its value defaults to the empty string." Replacement of this 1186 paragraph with following two paragraphs: 1188 * The 'subprotocol' parameter indicates which protocol the client 1189 expects to exchange via the channel. This parameter maps to 1190 the 'Protocol' parameter defined in 1191 [I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new 1192 subprotocol parameter values are registered. 'Subprotocol' is 1193 an optional parameter. If the 'subprotocol' parameter is not 1194 present, then its value defaults to the empty string. 1196 * Note: The empty string MAY also be explicitly used as 1197 'subprotocol' value, such that 'subprotocol=""' is equivalent 1198 to the 'subprotocol' parameter not being present at all. 1199 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1200 message's 'Subprotocol' value to be an empty string. 1202 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1203 normative references. 1205 o Addition of dcmap attribute specific IANA registration 1206 Section 8.2.1. 1208 o Addition of dcsa attribute specific IANA registration 1209 Section 8.2.2. 1211 o Addition of new Section 5.1.1.2 describing the mux category of the 1212 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1213 related mux category section are similar to the "Mux Category" 1214 sections of the "a=sctp-port:" and "a=max-message-size:" 1215 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1217 o Addition of new Section 5.1.2.2 describing the mux category of the 1218 dcsa SDP attribute. 1220 10.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1222 o In Section 1 replacement of "RTCWeb leaves it open for other 1223 applications to use data channels and its in-band DCEP or out-of- 1224 band non-DCEP protocols for creating them" with "... to use data 1225 channels and its in-band DCEP or other in-band or out-of-band 1226 protocols for creating them". Additionally replacement of "In 1227 particular, the SDP offer generated by the application includes no 1228 channel-specific information" with "... generated by the RTCweb 1229 data channel stack includes no channel-specific information". 1231 o Move of former section 5 ("Data Channels") to new Appendix A and 1232 removal of JavaScript API specific discussions from this moved 1233 text (like mentioning of data channel stack specific states). 1234 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1235 Section 5. 1237 o In Section 5: 1239 * Relacement of Section 5's first paragraph "This section defines 1240 a method of non-DCEP negotiation by which two clients can 1241 negotiate data channel-specific and subprotocol-specific 1242 parameters, using the out-of-band SDP offer/answer exchange. 1243 This SDP extension can only be used with the SDP offer/answer 1244 model." with "This section defines an SDP extension by which 1245 two clients can negotiate data channel-specific and 1246 subprotocol-specific parameters without using DCEP 1247 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1248 defines usage in the context of SDP offer/answer." 1250 * Addition of new paragraph: "Appendix A provides information how 1251 data channels work in general and especially summarizes some 1252 key aspects, which should be considered for the negotiation of 1253 data channels if DCEP is not used." 1255 o In Section 5.1.1 replacement of "The intention of exchanging these 1256 attributes is to create data channels on both the peers with the 1257 same set of attributes without actually using the DCEP 1258 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1259 these attributes is to create, on two peers, without use of DCEP 1260 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1261 directed data channels having the same set of attributes". 1263 o In Section 5.1.1.6 replacement of "The 'max-retr' parameter 1264 indicates the maximal number a user message will be retransmitted" 1265 with "The 'max-retr' parameter indicates the maximal number of 1266 times a user message will be retransmitted". 1268 o In Section 5.2.1 replacement of "However, an SDP offer/answer 1269 exchange MUST NOT be initiated if the associated SCTP stream is 1270 already negotiated via DCEP" with "However, an SCTP stream MUST 1271 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1272 answer exchange if the associated SCTP stream has already been 1273 negotiated via DCEP". 1275 o In the examples in Section 6 addition of the previously missing 1276 colons to the "a=sctp-port" attribute lines. 1278 10.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1280 o Move of reference draft-ietf-rtcweb-jsep from the list of 1281 normative references to the list of informative references. 1282 Remover in -07 since not referenced 1284 o Addition of [IANA-SDP-Parameters] to the list of informative 1285 references and addition of following two sentences to the first 1286 paragraph after the ABNF definition: "Note however that not all 1287 SDP attributes are suitable as "a=dcsa:" parameter. 1288 [IANA-SDP-Parameters] contains the lists of IANA registered 1289 session and media level or media level only SDP attributes." 1291 o In the introduction replacement of last sentence "This document 1292 defines SDP-based out-of-band negotiation procedures to establish 1293 data channels for transport of well-defined subprotocols" with 1294 "This document defines SDP offer/answer negotiation procedures to 1295 establish data channels for transport of well-defined 1296 subprotocols, to enable out-of-band negotiation". 1298 o Throughout the document replacement of "external negotiation" with 1299 "SDP offer/answer negotiation" and removal of term "external 1300 negotiation" from the terminology list in Section 3. 1302 o Throughout the document replacement of "internal negotiation" with 1303 "DCEP" and removal of terms "internal negotiation" and "in-band 1304 negotiation" from the terminology list in Section 3. 1306 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1307 terms. 1309 o In Section 5.2.1 replacement of sentence "However, a single stream 1310 is managed using one method at a time." with "However, an SDP 1311 offer/answer exchange MUST NOT be initiated if the associated SCTP 1312 stream is already negotiated via DCEP". 1314 o In Section 5.2.2 replacement of sentence "By definition max-retr 1315 and max-time are mutually exclusive, so only one of them can be 1316 present in a=dcmap" with "By definition max-retr and max-time are 1317 mutually exclusive, so at most one of them MAY be present in 1318 a=dcmap". 1320 o Move of reference [WebRtcAPI] from list of normative references to 1321 list of informative references. 1323 o Removal of almost all text parts, which discussed JavaScript or 1324 other API specific aspects. Such API specific aspects were mainly 1325 discussed in sub-sections of Section 5 and Section 5 of draft- 1326 ietf-mmusic-data-channel-sdpneg-02. 1328 10.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1330 o New Section 4 regarding applicability to SDP offer/answer only. 1332 o Addition of new Section 8.1 "Subprotocol identifiers" as 1333 subsection of the "IANA Considerations" related Section 8. Also 1334 removal of the temporary note "To be completed. As [I-D.ietf- 1335 rtcweb-data-protocol] this document should refer to IANA's 1336 WebSocket Subprotocol Name Registry defined in [RFC6455]" 1338 o In Section 5.2.2: 1340 * In the first paragraph replacement of the sentence "If an SDP 1341 offer contains both of these parameters then such an SDP offer 1342 will be rejected." with "If an SDP offer contains both of these 1343 parameters then the receiver of such an SDP offer MUST reject 1344 the SDP offer." 1346 * In the second paragraph capitalization of "shall" and "may" 1347 such that both sentences now read: "The SDP answer SHALL echo 1348 the same subprotocol, max-retr, max-time, ordered parameters, 1349 if those were present in the offer, and MAY include a label 1350 parameter. They MAY appear in any order, which could be 1351 different from the SDP offer, in the SDP answer." 1353 * In the third paragraph replacement of the sentence "The same 1354 information MUST be replicated without changes in any 1355 subsequent offer or answer, as long as the data channel is 1356 still opened at the time of offer or answer generation." with 1357 "When sending a subsequent offer or an answer, and for as long 1358 as the data channel is still open, the sender MUST replicate 1359 the same information.". 1361 o In Section 5.2.2 the mapping of data channel types defined in 1362 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1363 parameters were illustrated using example "a=dcmap" attribute 1364 lines. Replacement of these example "a=dcmap" attribute lines 1365 with just the "a=dcmap" attribute parameters being relevant for 1366 the channel type. 1368 o In Section 5.2.5 the description of bullet point "SDP offer has no 1369 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1370 No data channel negotiated yet." Replacement of this description 1371 with "Initial SDP offer: No data channel is negotiated yet. The 1372 DTLS connection and SCTP association is negotiated and, if agreed, 1373 established as per [I-D.ietf-mmusic-sctp-sdp]." 1375 o In Section 5.2.5 in both bullet points related to "Subsequent SDP 1376 offer" and "Subsequent SDP answer" replacement of "All the 1377 externally negotiated data channels must be closed now." with "All 1378 the externally negotiated data channels are expected to be closed 1379 now.". 1381 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1382 replacement of the two occurrences of "must" with "MUST". 1384 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1385 there was a comment saying that "Either only maxretr-opt or 1386 maxtime-opt is present. Both MUST NOT be present." Removal of 1387 the second normative sentence and instead addition of following 1388 new paragraph to the end of this section: "Within an 'a=dcmap' 1389 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1390 parameter or one 'maxtime-opt' parameter is present. Both MUST 1391 NOT be present." 1393 o In Section 5.1.1.8 replacement of the first sentence "The 1394 'ordered' parameter with value "true" indicates that DATA chunks 1395 in the channel MUST be dispatched to the upper layer by the 1396 receiver while preserving the order." with "The 'ordered' 1397 parameter with value "true" indicates that the receiver MUST 1398 dispatch DATA chunks in the data channel to the upper layer while 1399 preserving the order.". 1401 o In Section 5.2.3's first paragraph replacement of the one 1402 occurrence of "must" with "..., it MUST wait until ...". 1404 o In Section 5.2.4: 1406 * In the second paragraph replacement of "must" with "... whether 1407 this closing MUST in addition ..." 1409 * In the third paragraph replacement of the sentence "The port 1410 value for the "m" line SHOULD NOT be changed (e.g., to zero) 1411 when closing a data channel ..." with "The offerer SHOULD NOT 1412 change the port value for the "m" line (e.g., to zero) when 1413 closing a data channel ...". 1415 * In the last but two paragraph replacement of the sentence "... 1416 then an SDP offer which excludes this closed data channel 1417 SHOULD be generated." with "... then the client SHOULD generate 1418 an SDP offer which excludes this closed data channel.". 1420 * In the last but one paragraph replacement of "must" with "The 1421 application MUST also close...". 1423 o In Section 5.1.2 addition of following note after the formal 1424 definition of the 'a=dcsa' attribute: "Note that the above 1425 reference to RFC 4566 defines were the attribute definition can be 1426 found; it does not provide any limitation on support of attributes 1427 defined in other documents in accordance with this attribute 1428 definition." 1430 10.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1432 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1433 channel consisting of paired SCTP outbound and inbound streams." 1434 Replacement of this definition with "Data channel: A WebRTC data 1435 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1436 consistent usage of "data channel" in the remainder of the 1437 document including the document's headline." 1439 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1440 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1442 In particular we expect "webrtc-datachannel" to become a more 1443 general term.' 1445 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1447 o In Section 5.1.1 removal of the example dcmap attribute line 1448 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1449 already four examples right after the ABNF rules in 1450 Section 5.1.1.1. Corresponding removal of following related note: 1451 "Note: This document does not provide a complete specification of 1452 how to negotiate the use of a WebRTC data channel to transport 1453 BFCP. Procedures specific to each subprotocol such as BFCP will 1454 be documented elsewhere. The use of BFCP is only an example of 1455 how the generic procedures described herein might apply to a 1456 specific subprotocol." 1458 o In Section 5.1.1 removal of following note: "Note: This attribute 1459 is derived from attribute "webrtc-DataChannel", which was defined 1460 in old version 03 of the following draft, but which was removed 1461 along with any support for SDP external negotiation in subsequent 1462 versions: [I-D.ietf-mmusic-sctp-sdp]." 1464 o Insertion of following new sentence to the beginning of 1465 Section 5.1.1.1: "dcmap is a media level attribute having 1466 following ABNF syntax:" 1468 o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id 1469 specifying sentence, which previously was placed right before the 1470 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1471 parameter and is noted directly after the "a=dcmap:" attribute's 1472 colon' as this information is part of the ABNF specification. 1474 o In Section 5.1.1.1 modification of the 'ordering-value' values 1475 from "0" or "1" to "true" or "false". Corresponding text 1476 modifications in Section 5.1.1.8. 1478 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1479 to rule name "escaped-char", which was not defined. Instead a 1480 rule with name "escaped" was defined. Renamed that rule's name to 1481 "escaped-char". 1483 o Insertion of a dedicated note right after the "a=dcmap:4" 1484 attribute example in Section 5.1.1.1 regarding the non-printable 1485 "escaped-char" character within the "label" value. 1487 o In Section 5.1.2's second paragraph replacement of "sctp stream 1488 identifier" with "SCTP stream identifier". 1490 o In first paragraph of Section 5.2.1 replacement of first two 1491 sentences 'For the SDP-based external negotiation described in 1492 this document, the initial offerer based "SCTP over DTLS" owns by 1493 convention the even stream identifiers whereas the initial 1494 answerer owns the odd stream identifiers. This ownership is 1495 invariant for the whole lifetime of the signaling session, e.g. it 1496 does not change if the initial answerer sends a new offer to the 1497 initial offerer.' with 'If an SDP offer/answer exchange (could be 1498 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1499 TCP/DTLS/SCTP based media description being accepted, and if this 1500 SDP offer/answer exchange results in the establishment of a new 1501 SCTP association, then the SDP offerer owns the even SCTP stream 1502 ids of this new SCTP association and the answerer owns the odd 1503 SCTP stream identifiers. If this "m" line is removed from the 1504 signaling session (its port number set to zero), and if usage of 1505 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1506 renegotiated later on, then the even and odd SCTP stream 1507 identifier ownership is redetermined as well as described above.' 1509 o In Section 5.2.3 the first action of an SDP answerer, when 1510 receiving an SDP offer, was described as "Applies the SDP offer. 1511 Note that the browser ignores data channel specific attributes in 1512 the SDP." Replacement of these two sentences with "Parses and 1513 applies the SDP offer. Note that the typical parser normally 1514 ignores unknown SDP attributes, which includes data channel 1515 related attributes." 1517 o In Section 5.2.3 the second sentence of the third SDP answerer 1518 action was "Note that the browser is asked to create data channels 1519 with stream identifiers not "owned" by the agent.". Replacement 1520 of this sentence with "Note that the agent is asked to create data 1521 channels with SCTP stream identifiers contained in the SDP offer 1522 if the SDP offer is accepted." 1524 o In Section 5.2.4 the third paragraph began with "A data channel 1525 can be closed by sending a new SDP offer which excludes the dcmap 1526 and dcsa attribute lines for the data channel. The port value for 1527 the m line SHOULD NOT be changed (e.g., to zero) when closing a 1528 data channel (unless all data channels are being closed and the 1529 SCTP association is no longer needed), since this would close the 1530 SCTP association and impact all of the data channels. If the 1531 answerer accepts the SDP offer then it MUST also exclude the 1532 corresponding attribute lines in the answer. ..." Replacement of 1533 this part with "The intention to close a data channel can be 1534 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1535 and "a=dcsa:" attribute lines for the data channel. The port 1536 value for the "m" line SHOULD NOT be changed (e.g., to zero) when 1537 closing a data channel (unless all data channels are being closed 1538 and the SCTP association is no longer needed), since this would 1539 close the SCTP association and impact all of the data channels. 1540 If the answerer accepts the SDP offer then it MUST close those 1541 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1542 excluded from the received SDP offer, unless those data channels 1543 were already closed, and it MUST also exclude the corresponding 1544 attribute lines in the answer." 1546 o In Section 5.2.4 the hanging text after the third paragraph was 1547 "This delayed close is to handle cases where a successful SDP 1548 answer is not received, in which case the state of session should 1549 be kept per the last successful SDP offer/answer." Replacement of 1550 this sentence with "This delayed closure is RECOMMENDED in order 1551 to handle cases where a successful SDP answer is not received, in 1552 which case the state of the session SHOULD be kept per the last 1553 successful SDP offer/answer." 1555 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1556 Section 5.1.1 contained already procedural descriptions related to 1557 data channel reliability negotiation. Creation of new 1558 Section 5.2.2 and moval of reliability negotiation related text to 1559 this new section. 1561 10.15. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1563 o Removal of note "[ACTION ITEM]" from section "subprotocol 1564 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1565 should refer to IANA's WebSocket Subprotocol Name Registry defined 1566 in [RFC6455] 1568 o In whole document, replacement of "unreliable" with "partially 1569 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1570 [I-D.ietf-rtcweb-data-protocol] in most places. 1572 o Clarification of the semantic if the "max-retr" parameter is not 1573 present in an a=dcmap attribute line. In section "max-retr 1574 parameter" the sentence "The max-retr parameter is optional with 1575 default value unbounded" was replaced with "The max-retr parameter 1576 is optional. If the max-retr parameter is not present, then the 1577 maximal number of retransmissions is determined as per the generic 1578 SCTP retransmission rules as specified in [RFC4960]". 1580 o Clarification of the semantic if the "max-time" parameter is not 1581 present in an a=dcmap attribute line. In section "max-time 1582 parameter" the sentence "The max-time parameter is optional with 1583 default value unbounded" was replaced with "The max-time parameter 1584 is optional. If the max-time parameter is not present, then the 1585 generic SCTP retransmission timing rules apply as specified in 1586 [RFC4960]". 1588 o In section "label parameter" the sentence "Label is a mandatory 1589 parameter." was removed and following new sentences (including the 1590 note) were added: "The 'label' parameter is optional. If it is 1591 not present, then its value defaults to the empty string. Note: 1592 The empty string may also be explicitly used as 'label' value, 1593 such that 'label=""' is equivalent to the 'label' parameter not 1594 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1595 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1597 o In section "subprotocol parameter" the sentence "Subprotocol is a 1598 mandatory parameter." was replaced with "'Subprotocol' is an 1599 optional parameter. If the 'subprotocol' parameter is not 1600 present, then its value defaults to the empty string." 1602 o In the "Examples" section, in the first two SDP offer examples in 1603 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1604 'label="BFCP"'. 1606 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1607 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1608 replaced with "a=max-message-size" attribute lines, as per draft- 1609 ietf-mmusic-sctp-sdp-12. 1611 10.16. Changes against '-01' 1613 o Formal syntax for dcmap and dcsa attribute lines. 1615 o Making subprotocol as an optional parameter in dcmap. 1617 o Specifying disallowed parameter combinations for max-time and max- 1618 retr. 1620 o Clarifications on WebRTC data channel close procedures. 1622 10.17. Changes against '-00' 1624 o Revisions to identify difference between internal and external 1625 negotiation and their usage. 1627 o Introduction of more generic terminology, e.g. "application" 1628 instead of "browser". 1630 o Clarification of how "max-retr and max-time affect the usage of 1631 unreliable and reliable WebRTC data channels. 1633 o Updates of examples to take into account the SDP syntax changes 1634 introduced with draft-ietf-mmusic-sctp-sdp-07. 1636 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1637 attributes as this is now contained in the a=sctp-port attribute, 1638 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1639 association on top of the DTLS connection. 1641 11. References 1643 11.1. Normative References 1645 [I-D.ietf-mmusic-sctp-sdp] 1646 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1647 "Session Description Protocol (SDP) Offer/Answer 1648 Procedures For Stream Control Transmission Protocol (SCTP) 1649 over Datagram Transport Layer Security (DTLS) Transport.", 1650 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1651 2017. 1653 [I-D.ietf-mmusic-sdp-mux-attributes] 1654 Nandakumar, S., "A Framework for SDP Attributes when 1655 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1656 (work in progress), December 2016. 1658 [I-D.ietf-rtcweb-data-channel] 1659 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1660 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1661 progress), January 2015. 1663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1664 Requirement Levels", BCP 14, RFC 2119, 1665 DOI 10.17487/RFC2119, March 1997, 1666 . 1668 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1669 with Session Description Protocol (SDP)", RFC 3264, 1670 DOI 10.17487/RFC3264, June 2002, 1671 . 1673 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1674 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1675 July 2006, . 1677 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1678 Specifications: ABNF", STD 68, RFC 5234, 1679 DOI 10.17487/RFC5234, January 2008, 1680 . 1682 11.2. Informative References 1684 [I-D.ietf-mmusic-dtls-sdp] 1685 Holmberg, C. and R. Shpount, "Session Description Protocol 1686 (SDP) Offer/Answer Considerations for Datagram Transport 1687 Layer Security (DTLS) and Transport Layer Security (TLS)", 1688 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 1689 2017. 1691 [I-D.ietf-rtcweb-data-protocol] 1692 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1693 Establishment Protocol", draft-ietf-rtcweb-data- 1694 protocol-09 (work in progress), January 2015. 1696 [IANA-SDP-Parameters] 1697 "Session Description Protocol (SDP) Parameters", Internet 1698 Assigned Numbers Authority Protocol Assignments Session 1699 Description Protocol (SDP) Parameters, 1700 . 1703 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1704 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1705 . 1707 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1708 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1709 . 1711 [WebRtcAPI] 1712 Bergkvist, A., Burnett, D., Jennings, C., and A. 1713 Narayanan, "WebRTC 1.0: Real-time Communication Between 1714 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1715 February 2015, 1716 . 1718 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1719 DCEP 1721 This appendix summarizes how data channels work in general and 1722 discusses some key aspects, which should be considered for the out- 1723 of-band negotiation of data channels if DCEP is not used. 1725 A WebRTC application creates a data channel by providing a number of 1726 setup parameters (subprotocol, label, maximal number of 1727 retransmissions, maximal retransmission time, order of delivery, 1728 priority). The application also specifies if it wants to make use of 1729 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1730 the application intends to negotiate data channels using the SDP 1731 offer/answer protocol. 1733 In any case, the SDP offer generated by the application is per 1734 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1735 the SCTP association on top of which data channels will run: 1737 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1738 c=IN IP4 192.0.2.1 1739 a=max-message-size:100000 1740 a=sctp-port:5000 1741 a=tls-id:abc3de65cddef001be82 1742 a=setup:actpass 1743 a=fingerprint:SHA-1 \ 1744 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1746 Note: A WebRTC application will only use "m" line format "webrtc- 1747 datachannel", and will not use other formats in the "m" line for 1748 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1749 only one SCTP association to be established on top of a DTLS 1750 association. 1752 Note: The above SDP media description does not contain any channel- 1753 specific information. 1755 A.1. Stream Identifier Numbering 1757 Independently from the requested type of negotiation, the application 1758 creating a data channel can either pass the stream identifier to the 1759 data channel stack to assign to the data channel or else let the data 1760 channel stack pick one identifier from the unused ones. 1762 To avoid glare situations, each endpoint can moreover own an 1763 exclusive set of stream identifiers, in which case an endpoint can 1764 only create a data channel with a stream identifier it owns. 1766 Which set of stream identifiers is owned by which endpoint is 1767 determined by convention or other means. 1769 Note:For data channels negotiated with the DCEP, one endpoint owns 1770 by convention the even stream identifiers, whereas the other owns 1771 the odd stream identifiers, as defined in 1772 [I-D.ietf-rtcweb-data-protocol]. 1774 Note:For data channels negotiated via some protocol different from 1775 DCEP, no convention is defined by default. 1777 A.2. Generic Data Channel Negotiation Not Using DCEP 1779 A.2.1. Overview 1781 DCEP negotiation only provides for negotiation of data channel 1782 transport parameters and does not provide for negotiation of 1783 subprotocol specific parameters. DCEP-less data channel negotiation 1784 can be defined to allow negotiation of parameters beyond those 1785 handled by DCEP, e.g., parameters specific to the subprotocol 1786 instantiated on a particular data channel. 1788 The following procedures are common to all methods of data channel 1789 negotiation not using DCEP, whether in-band (communicated using 1790 proprietary means on an already established data channel) or out-of- 1791 band (using SDP offer/answer or some other protocol associated with 1792 the signaling channel). 1794 A.2.2. Opening a Data Channel 1796 In the case of DCEP-less negotiation, the endpoint application has 1797 the option to fully control the stream identifier assignments. 1798 However these assignments have to coexist with the assignments 1799 controlled by the data channel stack for the DCEP negotiated data 1800 channels (if any). It is the responsibility of the application to 1801 ensure consistent assignment of stream identifiers. 1803 When the application requests the creation of a new data channel to 1804 be set up via DCEP-less negotiation, the data channel stack creates 1805 the data channel locally without sending any DATA_CHANNEL_OPEN 1806 message in-band. However, even if the ICE (Interactive Connectivity 1807 Establishment), DTLS and SCTP procedures were already successfully 1808 completed, the application can't send data on this data channel until 1809 the negotiation is complete with the peer. This is because the peer 1810 needs to be aware of and accept the usage of this data channel. The 1811 peer, after accepting the data channel offer, can start sending data 1812 immediately. This implies that the offerer may receive data channel 1813 subprotocol messages before the negotiation is complete and the 1814 application should be ready to handle it. 1816 If the peer rejects the data channel part of the offer then it 1817 doesn't have to do anything as the data channel was not created using 1818 the stack. The offerer on the other hand needs to close the data 1819 channel that was opened by invoking relevant data channel stack API 1820 procedures. 1822 It is also worth noting that a data channel stack implementation may 1823 not provide any API to create and close data channels; instead the 1824 data channels may be used on the fly as needed just by communicating 1825 via non-DCEP means or by even having some local configuration/ 1826 assumptions on both the peers. 1828 The application then negotiates the data channel properties and 1829 subprotocol properties with the peer's application using a mechanism 1830 different from DCEP. 1832 The peer then symmetrically creates a data channel with these 1833 negotiated data channel properties. This is the only way for the 1834 peer's data channel stack to know which properties to apply when 1835 transmitting data on this channel. The data channel stack must allow 1836 data channel creation with any non-conflicting stream identifier so 1837 that both peers can create the data channel with the same stream 1838 identifier. 1840 A.2.3. Closing a Data Channel 1842 When the application requests the closing of a data channel 1843 negotiated without DCEP, the data channel stack always performs an 1844 SCTP SSN reset for this channel. 1846 Depending upon the method used for DCEP-less negotiation and the 1847 subprotocol associated with the data channel, the closing might in 1848 addition be signaled to the peer via SDP offer/answer negotiation. 1850 Authors' Addresses 1852 Keith Drage 1853 Unaffiliated 1855 Email: drageke@ntlworld.com 1857 Maridi R. Makaraju (Raju) 1858 Nokia 1859 2000 Lucent Lane 1860 Naperville, Illinois 1861 US 1863 Email: Raju.Makaraju@nokia.com 1865 Juergen Stoetzer-Bradler 1866 Unaffiliated 1868 Email: Juergen.S-B.ietf@email.de 1869 Richard Ejzak 1870 Unaffiliated 1872 Email: richard.ejzak@gmail.com 1874 Jerome Marcon 1875 Unaffiliated 1877 Roni Even (editor) 1878 Huawei 1880 Email: roni.even@huawei.com