idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-05.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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" there was a comment saying that "Either only maxretr-opt or maxtime-opt is present. Both MUST not be present." Removal of the second normative sentence and instead addition of following new paragraph to the end of this section: "Within an 'a=dcmap' attribute line's 'dcmap-opt' value either only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter is present. Both MUST NOT be present." == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: * In the third paragraph replacement of the sentence "The port value for the "m" line SHOULD not be changed (e.g., to zero) when closing a data channel ..." with "The offerer SHOULD NOT change the port value for the "m" line (e.g., to zero) when closing a data channel ...". == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o In Section 5.2.4 the third paragraph began with "A data channel can be closed by sending a new SDP offer which excludes the dcmap and dcsa attribute lines for the data channel. The port value for the m line should not be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST also exclude the corresponding attribute lines in the answer. ..." Replacement of this part with "The intention to close a data channel can be signaled by sending a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for the data channel. The port value for the "m" line SHOULD not be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST close those data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the received SDP offer, unless those data channels were already closed, and it MUST also exclude the corresponding attribute lines in the answer." -- The document date (October 5, 2015) is 3098 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) == Unused Reference: 'RFC5234' is defined on line 1378, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 1415, but no explicit reference was found in the text == Unused Reference: 'RFC5547' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'RFC6135' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'RFC6714' is defined on line 1435, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-15 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-10 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-11 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage, Ed. 3 Internet-Draft M. Makaraju 4 Intended status: Standards Track J. Stoetzer-Bradler 5 Expires: April 7, 2016 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 October 5, 2015 11 SDP-based Data Channel Negotiation 12 draft-ietf-mmusic-data-channel-sdpneg-05 14 Abstract 16 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 17 charged to provide protocols to support direct interactive rich 18 communications using audio, video, and data between two peers' web- 19 browsers. For the support of data communication, the RTCWeb working 20 group has in particular defined the concept of bi-directional data 21 channels over SCTP, where each data channel might be used to 22 transport other protocols, called sub-protocols. Data channel setup 23 can be done using either the in-band Data Channel Establishment 24 Protocol (DCEP) or using some out-of-band non-DCEP protocol. This 25 document specifies how the SDP offer/answer exchange can be used to 26 achieve such an out-of-band non-DCEP negotiation. Even though data 27 channels are designed for RTCWeb use initially they may be used by 28 other protocols like, but not limited to, the CLUE protocol. This 29 document is intended to be used wherever data channels are used. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 7, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 69 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 5 70 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 5 72 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 5 73 5.1.1.2. dcmap Multiplexing Category . . . . . . . . . . . 7 74 5.1.1.3. dcmap-stream-id Parameter . . . . . . . . . . . . 7 75 5.1.1.4. label Parameter . . . . . . . . . . . . . . . . . 7 76 5.1.1.5. subprotocol Parameter . . . . . . . . . . . . . . 8 77 5.1.1.6. max-retr Parameter . . . . . . . . . . . . . . . 8 78 5.1.1.7. max-time Parameter . . . . . . . . . . . . . . . 8 79 5.1.1.8. ordered Parameter . . . . . . . . . . . . . . . . 8 80 5.1.2. Sub-Protocol Specific Attributes . . . . . . . . . . 9 81 5.1.2.1. dcsa Attribute . . . . . . . . . . . . . . . . . 9 82 5.1.2.2. dcsa Multiplexing Category . . . . . . . . . . . 10 83 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 10 85 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 11 86 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 12 87 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 14 88 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 15 89 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 18 93 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 94 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19 95 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 19 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 98 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 10.1. Changes against 'draft-ietf-mmusic-data-channel- 100 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 20 101 10.2. Changes against 'draft-ietf-mmusic-data-channel- 102 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 21 103 10.3. Changes against 'draft-ietf-mmusic-data-channel- 104 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 22 105 10.4. Changes against 'draft-ietf-mmusic-data-channel- 106 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 23 107 10.5. Changes against 'draft-ietf-mmusic-data-channel- 108 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 25 109 10.6. Changes against 'draft-ejzak-mmusic-data-channel- 110 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 111 10.7. Changes against '-01' . . . . . . . . . . . . . . . . . 29 112 10.8. Changes against '-00' . . . . . . . . . . . . . . . . . 29 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 115 11.2. Informative References . . . . . . . . . . . . . . . . . 30 116 Appendix A. Generic Data Channel Negotiation Aspects When Not 117 Using DCEP . . . . . . . . . . . . . . . . . . . . . 32 118 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 32 119 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 33 120 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 33 121 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 33 122 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 34 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 125 1. Introduction 127 The RTCWeb working group has defined the concept of bi-directional 128 data channels running on top of SCTP/DTLS. RTCWeb leaves it open for 129 other applications to use data channels and its in-band DCEP or other 130 in-band or out-of-band protocols for creating them. Each data 131 channel consists of paired SCTP streams sharing the same SCTP Stream 132 Identifier. Data channels are created by endpoint applications 133 through the WebRTC API, or other users of data channel like CLUE, and 134 can be used to transport proprietary or well-defined protocols, which 135 in the latter case can be signaled by the data channel "sub-protocol" 136 parameter, conceptually similar to the WebSocket "sub-protocol". 137 However, apart from the "sub-protocol" value transmitted to the peer, 138 RTCWeb leaves it open how endpoint applications can agree on how to 139 instantiate a given sub-protocol on a data channel, and whether it is 140 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 141 (or both). In particular, the SDP offer generated by the RTCweb data 142 channel stack includes no channel-specific information. 144 This document defines SDP offer/answer negotiation procedures to 145 establish data channels for transport of well-defined sub-protocols, 146 to enable out-of-band negotiation. 148 2. Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Terminology 156 This document uses the following terms: 158 Data channel: A WebRTC data channel as specified in 159 [I-D.ietf-rtcweb-data-channel]. 161 Data channel stack: An entity which, upon application request, 162 runs the data channel protocol to keep track of states, sending 163 and receive data. If the application is a browser based 164 JavaScript application then this stack resides in the browser. If 165 the application is a native application then this stack resides in 166 the application and is accessible via some sort of APIs. 168 Data channel properties: Fixed properties assigned to a data 169 channel at the time of its creation. Some of these properties 170 determine the way the data channel stack transmits data on this 171 channel (e.g., stream identifier, reliability, order of 172 delivery...). 174 DCEP: Data Channel Establishment Protocol defined in 175 [I-D.ietf-rtcweb-data-protocol]. 177 In-band: Transmission through the peer-to-peer SCTP association. 179 Out-of-band: Transmission through the application signaling path. 181 Peer: From the perspective of one of the agents in a session, its 182 peer is the other agent. Specifically, from the perspective of 183 the SDP offerer, the peer is the SDP answerer. From the 184 perspective of the SDP answerer, the peer is the SDP offerer. 186 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 187 as specified in [RFC4960]. 189 Stream identifier: The identifier of the outbound and inbound SCTP 190 streams composing a data channel. 192 4. Applicability Statement 194 The mechanism in this specification only applies to the Session 195 Description Protocol (SDP) [RFC4566], when used together with the SDP 196 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 197 scope of this document, and is thus undefined. 199 5. SDP Offer/Answer Negotiation 201 This section defines an SDP extension by which two clients can 202 negotiate data channel-specific and sub-protocol-specific parameters 203 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 204 extension only defines usage in the context of SDP offer/answer. 206 Appendix A provides information how data channels work in general and 207 especially summarizes some key aspects, which should be considered 208 for the negotiation of data channels if DCEP is not used. 210 5.1. SDP Syntax 212 Two new SDP attributes are defined to support SDP offer/answer 213 negotiation of data channels. The first attribute provides for 214 negotiation of channel-specific parameters. The second attribute 215 provides for negotiation of sub-protocol-specific parameters. 217 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 219 Associated with the SDP "m" line that defines the SCTP association 220 for data channels (defined in Section 4), each SDP offer and answer 221 includes one "a=dcmap:" attribute that defines the data channel 222 parameters for each data channel to be negotiated. Each such 223 attribute line specifies the following parameters for a data channel: 224 SCTP stream identifier, sub-protocol, label, reliability, order of 225 delivery, and priority. 227 The intention in exchanging these attributes is to create, on two 228 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 229 pairs of oppositely directed data channels having the same set of 230 attributes. It is assumed that the data channel properties 231 (reliable/partially reliable, ordered/unordered) are suitable per the 232 sub-protocol transport requirements. 234 5.1.1.1. dcmap Attribute 236 "a=dcmap:" is a media level attribute having following ABNF syntax. 238 Formal Syntax: 240 Name: dcmap 242 Value: dcmap-value 244 Usage Level: media 246 Charset Dependent: no 248 Syntax: 250 dcmap-value = dcmap-stream-id 251 [ SP dcmap-opt *(";" dcmap-opt) ] 252 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 253 / maxretr-opt / maxtime-opt 254 ; Either only maxretr-opt or maxtime-opt 255 ; is present. 257 dcmap-stream-id = 1*DIGIT 258 ordering-opt = "ordered=" ordering-value 259 ordering-value = "true" / "false" 260 subprotocol-opt = "subprotocol=" quoted-string 261 label-opt = "label=" quoted-string 262 maxretr-opt = "max-retr=" maxretr-value 263 maxretr-value = 265 ; number of retransmissions 266 maxtime-opt = "max-time=" maxtime-value 267 maxtime-value = 269 ; milliseconds 271 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 272 quoted-char = SP / quoted-visible 273 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 274 escaped-char = "%" HEXDIG HEXDIG 275 DQUOTE = 276 integer = 278 Examples: 280 a=dcmap:0 281 a=dcmap:1 subprotocol="BFCP";max-time=60000 282 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 283 a=dcmap:3 label="Label 1";ordered=false;max-retr=5 284 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000;max-retr=3 285 Note: The last example (a=dcmap:4) shows a 'label' parameter value 286 which contains one non-printable 'escaped-char' character (the 287 tabulator character). 289 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 290 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 291 present. Both MUST NOT be present. 293 5.1.1.2. dcmap Multiplexing Category 295 Multiplexing characteristics of SDP attributes are described in 296 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 297 multiplexing categories are introduced there. 299 The multiplexing category of the "a=dcmap:" attribute is SPECIAL. 300 Usage of this attribute is only applicable when associated with 301 UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines. 303 As the usage of multiple SCTP associations on top of a single DTLS 304 connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 305 multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/ 306 SCTP proto values. If future extensions of 307 [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 308 multiple SCTP associations of top of a single DTLS connection, then 309 multiplexing rules for the "a=dcmap:" attribute need to be defined as 310 well, for instance in an extension of this SDP based data channel 311 negotiation specification. 313 5.1.1.3. dcmap-stream-id Parameter 315 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 316 within the SCTP association used to form the data channel. 318 5.1.1.4. label Parameter 320 The 'label' parameter indicates the name of the channel. It 321 represents a label that can be used to distinguish, in the context of 322 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 323 RTCDataChannel objects. This parameter maps to the 'Label' parameter 324 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 325 optional. If it is not present, then its value defaults to the empty 326 string. 328 Note: The empty string MAY also be explicitly used as 'label' value, 329 such that 'label=""' is equivalent to the 'label' parameter not being 330 present at all. [I-D.ietf-rtcweb-data-protocol] allows the 331 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 333 5.1.1.5. subprotocol Parameter 335 The 'subprotocol' parameter indicates which protocol the client 336 expects to exchange via the channel. This parameter maps to the 337 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 338 Section 8.1 specifies how new subprotocol parameter values are 339 registered. 'Subprotocol' is an optional parameter. If the 340 'subprotocol' parameter is not present, then its value defaults to 341 the empty string. 343 Note: The empty string MAY also be explicitly used as 'subprotocol' 344 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 345 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 346 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 347 empty string. 349 5.1.1.6. max-retr Parameter 351 This parameter indicates that the data channel is partially reliable. 352 The 'max-retr' parameter indicates the maximal number of times a user 353 message will be retransmitted. The max-retr parameter is optional. 354 If the max-retr parameter is not present, then the maximal number of 355 retransmissions is determined as per the generic SCTP retransmission 356 rules as specified in [RFC4960]. This parameter maps to the 'Number 357 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 359 5.1.1.7. max-time Parameter 361 This parameter indicates that the data channel is partially reliable. 362 A user message will no longer be transmitted or retransmitted after a 363 specified life-time given in milliseconds in the 'max-time' 364 parameter. The max-time parameter is optional. If the max-time 365 parameter is not present, then the generic SCTP retransmission timing 366 rules apply as specified in [RFC4960]. This parameter maps to the 367 'Lifetime in ms' parameter defined in 368 [I-D.ietf-rtcweb-data-protocol]. 370 5.1.1.8. ordered Parameter 372 The 'ordered' parameter with value "true" indicates that the receiver 373 MUST dispatch DATA chunks in the data channel to the upper layer 374 while preserving the order. The ordered parameter is optional and 375 takes two values: "true" for ordered and "false" for unordered 376 delivery with "true" as the default value. Any other value is 377 ignored and default "ordered=true" is assumed. In the absence of 378 this parameter "ordered=true" is assumed. This parameter maps to the 379 ordered or unordered data channel types as defined in 380 [I-D.ietf-rtcweb-data-protocol]. 382 5.1.2. Sub-Protocol Specific Attributes 384 In the SDP, each data channel declaration MAY also be followed by 385 other SDP attributes specific to the sub-protocol in use. Each of 386 these attributes is represented by one new attribute line, and it 387 includes the contents of a media-level SDP attribute already defined 388 for use with this (sub)protocol in another IETF specification. Sub- 389 protocol-specific attributes might also be defined for exclusive use 390 with data channel transport, but should use the same syntax described 391 here for other sub-protocol-specific attributes. 393 5.1.2.1. dcsa Attribute 395 Each sub-protocol specific SDP attribute that would normally be used 396 to negotiate the subprotocol using SDP is replaced with an attribute 397 of the form "a=dcsa:stream-id original-attribute", where dcsa stands 398 for "data channel sub-protocol attribute", stream-id is the SCTP 399 stream identifier assigned to this sub-protocol instance, and 400 original-attribute represents the contents of the sub-protocol 401 related attribute to be included. 403 Formal Syntax: 405 Name: dcsa 407 Value: dcsa-value 409 Usage Level: media 411 Charset Dependent: no 413 Syntax: 415 dcsa-value = stream-id SP attribute 416 attribute = 418 Example: 420 a=dcsa:2 accept-types:text/plain 422 Note that the above reference to RFC 4566 defines where the attribute 423 definition can be found; it does not provide any limitation on 424 support of attributes defined in other documents in accordance with 425 this attribute definition. Note however that not all SDP attributes 426 are suitable as "a=dcsa:" parameter. [IANA-SDP-Parameters] contains 427 the lists of IANA registered session and media level or media level 428 only SDP attributes. 430 Thus in the example above, the original attribute line "a=accept- 431 types:text/plain" is represented by the attribute line "a=dcsa:2 432 accept-types:text/plain", which specifies that this instance of MSRP 433 being transported on the SCTP association using the data channel with 434 stream id 2 accepts plain text files. 436 As opposed to the data channel "a=dcmap:" attribute parameters, these 437 parameters are subject to offer/answer negotiation following the 438 procedures defined in the sub-protocol specific documents. 440 The same syntax applies to any other SDP attribute required for 441 negotiation of this instance of the sub-protocol. 443 Note: This document does not provide a complete specification of how 444 to negotiate the use of a data channel to transport MSRP. Procedures 445 specific to each sub-protocol such as MSRP will be documented 446 elsewhere. The use of MSRP is only an example of how the generic 447 procedures described herein might apply to a specific sub-protocol. 449 5.1.2.2. dcsa Multiplexing Category 451 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 452 Usage of this attribute is only applicable when associated with 453 UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines. 455 As the usage of multiple SCTP associations on top of a single DTLS 456 connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 457 multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/ 458 SCTP proto values. If future extensions of 459 [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 460 multiple SCTP associations of top of a single DTLS connection, then 461 multiplexing rules for the "a=dcsa:" attribute need to be defined as 462 well, for instance in an extension of this SDP based data channel 463 negotiation specification. 465 5.2. Procedures 467 5.2.1. Managing Stream Identifiers 469 If an SDP offer/answer exchange (could be the initial or a subsequent 470 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 471 description being accepted, and if this SDP offer/answer exchange 472 results in the establishment of a new SCTP association, then the SDP 473 offerer owns the even SCTP stream ids of this new SCTP association 474 and the answerer owns the odd SCTP stream identifiers. If this "m" 475 line is removed from the signaling session (its port number set to 476 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 477 SCTP based "m" line is renegotiated later on, then the even and odd 478 SCTP stream identifier ownership is redetermined as well as described 479 above. 481 This specification allows simultaneous use of SDP offer/answer and 482 DCEP negotiation. However, an SCTP stream MUST NOT be referenced in 483 a "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange 484 if the associated SCTP stream has already been negotiated via DCEP. 485 Stream ids that are not currently used in SDP can be used for DCEP 486 negotiation. Stream id allocation per SDP offer/answer negotiation 487 may not align with DTLS role based allocation. This could cause 488 glare conditions when one side trying to do SDP offer/answer 489 negotiation on a stream id while the other end trying to open a data 490 channel on the same stream id using DCEP negotiation. To avoid these 491 glare conditions this specification recommends that the data channel 492 stack user always selects stream ids per above described SDP offer/ 493 answer rule even when DCEP negotiation is used. To avoid glare 494 conditions, it is possible to come up with a different stream id 495 allocation scheme, but such schemes are outside the scope of this 496 specification. 498 5.2.2. Negotiating Data Channel Parameters 500 Conveying a reliable data channel is achieved by including neither 501 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 502 "a=dcmap:" attribute line. Conveying a partially reliable data 503 channel is achieved by including only one of 'max-retr' or 'max- 504 time'. By definition max-retr and max-time are mutually exclusive, 505 so at most one of them MAY be present in the "a=dcmap:" attribute 506 line. If an SDP offer contains both of these parameters then the 507 receiver of such an SDP offer MUST reject the SDP offer. If an SDP 508 answer contains both of these parameters then the offerer MAY treat 509 it as an error and MAY assume the associated SDP offer/answer failed 510 and MAY take appropriate recovery actions. These recovery options 511 are outside the scope of this specification. 513 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 514 ordered parameters, if those were present in the offer, and MAY 515 include a label parameter. They MAY appear in any order, which could 516 be different from the SDP offer, in the SDP answer. 518 When sending a subsequent offer or an answer, and for as long as the 519 data channel is still open, the sender MUST replicate the same 520 information. 522 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 523 mapped to SDP in the following manner, where "ordered=true" is the 524 default and may be omitted: 526 DATA_CHANNEL_RELIABLE 527 ordered=true 529 DATA_CHANNEL_RELIABLE_UNORDERED 530 ordered=false 532 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 533 ordered=true;max-retr= 535 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 536 ordered=false;max-retr= 538 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 539 ordered=true;max-time= 541 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 542 ordered=false;max-time= 544 5.2.3. Opening a Data Channel 546 The procedure for opening a data channel using SDP offer/answer 547 negotiation starts with the agent preparing to send an SDP offer. If 548 a peer receives an SDP offer before starting to send a new SDP offer 549 with data channels that are to be SDP offer/answer negotiated, or 550 loses an SDP offer glare resolution procedure in this case, it MUST 551 wait until the ongoing SDP offer/answer completes before resuming the 552 SDP offer/answer negotiation procedure. 554 The agent that intends to send an SDP offer to create data channels 555 through SDP offer/answer negotiation performs the following: 557 o Creates data channels using stream identifiers from the owned set 558 (see Section 5.2.1). 560 o Generates a new SDP offer. 562 o Determines the list of stream identifiers assigned to data 563 channels opened through SDP offer/answer negotiation. 565 o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:" 566 attributes needed, if any, for each SDP offer/answer negotiated 567 data channel, as described in Section 5.1 and in Section 5.2.2. 569 o Sends the SDP offer. 571 The peer receiving such an SDP offer performs the following: 573 o Parses and applies the SDP offer. Note that the typical parser 574 normally ignores unknown SDP attributes, which includes data 575 channel related attributes. 577 o Analyzes the channel parameters and sub-protocol attributes to 578 determine whether to accept each offered data channel. 580 o For accepted data channels, it creates peer instances for the data 581 channels with the agent using the channel parameters described in 582 the SDP offer. Note that the agent is asked to create data 583 channels with SCTP stream identifiers contained in the SDP offer 584 if the SDP offer is accepted. 586 o Generates an SDP answer. 588 o Completes the SDP answer with the "a=dcmap:" and optional 589 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 590 data channel, as described in Section 5.1 and in Section 5.2.2. 592 o Sends the SDP answer. 594 The agent receiving such an SDP answer performs the following: 596 o Closes any created data channels for which the expected "a=dcmap:" 597 and "a=dcsa:" attributes are not present in the SDP answer. 599 o Applies the SDP answer. 601 Each agent application MUST wait to send data until it has 602 confirmation that the data channel at the peer is instantiated. For 603 WebRTC, this is when both data channel stacks have channel parameters 604 instantiated. This occurs: 606 o At both peers when a data channel is created without an 607 established SCTP association, as soon as the SCTP association is 608 successfully established. 610 o At the agent receiving an SDP offer for which there is an 611 established SCTP association, as soon as it creates an SDP offer/ 612 answer negotiated data channel based on information signaled in 613 the SDP offer. 615 o At the agent sending an SDP offer to create a new SDP offer/answer 616 negotiated data channel for which there is an established SCTP 617 association, when it receives the SDP answer confirming acceptance 618 of the data channel or when it begins to receive data on the data 619 channel from the peer, whichever occurs first. 621 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 622 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 624 5.2.4. Closing a Data Channel 626 When the application requests the closing of a data channel that was 627 negotiated via SDP offer/answer, the data channel stack always 628 performs an SCTP SSN reset for this channel. 630 It is specific to the sub-protocol whether this closing MUST in 631 addition be signaled to the peer via a new SDP offer/answer exchange. 633 The intention to close a data channel can be signaled by sending a 634 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 635 lines for the data channel. The offerer SHOULD NOT change the port 636 value for the "m" line (e.g. to zero) when closing a data channel 637 (unless all data channels are being closed and the SCTP association 638 is no longer needed), since this would close the SCTP association and 639 impact all of the data channels. If the answerer accepts the SDP 640 offer then the answerer MUST close those data channels whose 641 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 642 received SDP offer, unless those data channels were already closed, 643 and the answerer MUST also exclude the corresponding attribute lines 644 in the answer. In addition to that, the SDP answerer MAY exclude 645 other data channels which were closed but not yet communicated to the 646 peer. So, the offerer MUST inspect the answer to see if it has to 647 close other data channels which are now not included in the answer. 649 If a new SDP offer/answer is used to close data channels then the 650 data channel(s) SHOULD only be closed by the answerer/offerer after a 651 successful SDP answer is sent/received. 653 This delayed closure is RECOMMENDED in order to handle cases where 654 a successful SDP answer is not received, in which case the state 655 of the session SHOULD be kept per the last successful SDP offer/ 656 answer. 658 If a client receives a data channel close indication (due to inband 659 SCTP SSN reset or some other reason) without associated SDP offer 660 then the client SHOULD generate an SDP offer which excludes this 661 closed data channel. 663 The application MUST also close any data channel that was negotiated 664 via SDP offer/answer, for which the stream identifiers are not listed 665 in an incoming SDP offer. 667 A closed data channel using local close (SCTP SSN reset), without an 668 additional SDP offer/answer to close it, may be reused for a new data 669 channel. This can only be done via new SDP offer/answer, describing 670 the new sub-protocol and its attributes, only after the corresponding 671 data channel close acknowledgement is received from the peer (i.e. 672 SCTP SSN reset of both incoming and outgoing streams is completed). 673 This restriction is to avoid the race conditions between arrival of 674 "SDP offer which reuses stream" with "SCTP SSN reset which closes 675 outgoing stream" at the peer. 677 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 679 SDP offer has no "a=dcmap:" attributes 681 * Initial SDP offer: No data channel is negotiated yet. The DTLS 682 connection and SCTP association is negotiated and, if agreed, 683 established as per [I-D.ietf-mmusic-sctp-sdp]. 685 * Subsequent SDP offer: All the SDP offer/answer negotiated data 686 channels are expected be closed now. The DTLS/SCTP association 687 remains open for SDP offer/answer or DCEP negotiation of data 688 channels. 690 SDP answer has no "a=dcmap:" attributes 692 * Initial SDP answer: Either the peer does not support "a=dcmap:" 693 attributes or it rejected all the data channels. In either 694 case the offerer closes all the SDP offer/answer negotiated 695 data channels that were open at the time of initial offer. The 696 DTLS connection and SCTP association will still be setup. 698 * Subsequent SDP answer: All the SDP offer/answer negotiated data 699 channels are expected be closed now. The DTLS/SCTP association 700 remains open for future SDP offer/answer or DCEP negotiation of 701 data channels. 703 SDP offer has no "a=dcsa:" attributes for a data channel. 705 * This is allowed and indicates there are no sub-protocol 706 parameters to convey. 708 SDP answer has no "a=dcsa:" attributes for a data channel. 710 * This is allowed and indicates there are no sub-protocol 711 parameters to convey in the SDP answer. The number of 712 "a=dcsa:" attributes in the SDP answer does not have to match 713 the number of "a=dcsa:" attributes in the SDP offer. 715 6. Examples 717 SDP offer: 718 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 719 c=IN IP4 10.10.10.1 720 a=max-message-size:100000 721 a=sctp-port:5000 722 a=setup:actpass 723 a=connection:new 724 a=fingerprint:SHA-1 \ 725 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 726 a=dcmap:0 subprotocol="BFCP";label="BFCP" 728 SDP answer: 729 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 730 c=IN IP4 10.10.10.2 731 a=max-message-size:100000 732 a=sctp-port:5002 733 a=setup:passive 734 a=connection:new 735 a=fingerprint:SHA-1 \ 736 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 738 Figure 1: Example 1 740 In the above example the SDP answerer rejected the data channel with 741 stream id 0 either for explicit reasons or because it does not 742 understand the "a=dcmap:" attribute. As a result the offerer will 743 close the data channel created with the SDP offer/answer negotiation 744 option. The SCTP association will still be setup over DTLS. At this 745 point the offerer or the answerer may use DCEP negotiation to open 746 data channels. 748 SDP offer: 749 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 750 c=IN IP4 10.10.10.1 751 a=max-message-size:100000 752 a=sctp-port:5000 753 a=setup:actpass 754 a=connection:new 755 a=fingerprint:SHA-1 \ 756 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 757 a=dcmap:0 subprotocol="BFCP";label="BFCP" 758 a=dcmap:2 subprotocol="MSRP";label="MSRP" 759 a=dcsa:2 accept-types:message/cpim text/plain 760 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 762 SDP answer: 763 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 764 c=IN IP4 10.10.10.2 765 a=max-message-size:100000 766 a=sctp-port:5002 767 a=setup:passive 768 a=connection:new 769 a=fingerprint:SHA-1 \ 770 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 771 a=dcmap:2 subprotocol="MSRP";label="MSRP" 772 a=dcsa:2 accept-types:message/cpim text/plain 773 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 775 Figure 2: Example 2 777 In the above example the SDP offer contains data channels for BFCP 778 and MSRP sub-protocols. The SDP answer rejected BFCP and accepted 779 MSRP. So, the offerer should close the data channel for BFCP and 780 both offerer and answerer may start using the MSRP data channel 781 (after SCTP/DTLS association is setup). The data channel with stream 782 id 0 is free and can be used for future DCEP or SDP offer/answer 783 negotiation. 785 Continuing on the earlier example in Figure 1. 787 Subsequent SDP offer: 788 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 789 c=IN IP4 10.10.10.1 790 a=max-message-size:100000 791 a=sctp-port:5000 792 a=setup:actpass 793 a=connection:existing 794 a=fingerprint:SHA-1 \ 795 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 796 a=dcmap:4 subprotocol="MSRP";label="MSRP" 797 a=dcsa:4 accept-types:message/cpim text/plain 798 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 800 Subsequent SDP answer: 801 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 802 c=IN IP4 10.10.10.2 803 a=max-message-size:100000 804 a=sctp-port:5002 805 a=setup:passive 806 a=connection:existing 807 a=fingerprint:SHA-1 \ 808 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 809 a=dcmap:4 subprotocol="MSRP";label="MSRP" 810 a=dcsa:4 accept-types:message/cpim text/plain 811 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 813 Figure 3: Example 3 815 The above example is a continuation of the example in Figure 1. The 816 SDP offer now removes the MSRP data channel with stream id 2, but 817 opens a new MSRP data channel with stream id 4. The answerer accepts 818 the entire offer. As a result the offerer closes the earlier 819 negotiated MSRP related data channel and both offerer and answerer 820 may start using new the MSRP related data channel. 822 7. Security Considerations 824 No security considerations are envisaged beyond those already 825 documented in [RFC4566]. 827 8. IANA Considerations 829 8.1. Subprotocol Identifiers 831 Registration of new subprotocol identifiers is performed using the 832 existing IANA table "WebSocket Subprotocol Name Registry". 834 The following text should be added following the title of the table. 836 "This table also includes subprotocol identifiers specified for usage 837 within a WebRTC data channel." 839 The following reference should be added to under the heading 840 reference: "RFC XXXX". 842 This document assigns no new values to this table. 844 NOTE to RFC Editor: Please replace "XXXX" with the number of this 845 RFC. 847 8.2. New SDP Attributes 849 8.2.1. dcmap 851 NOTE to RFC Editor: Please replace "XXXX" with the number of this 852 RFC. 854 This document defines a new SDP media-level attribute "a=dcmap:" as 855 follows: 857 +---------------------+-----------------------------------------+ 858 | Attribute name: | dcmap | 859 | Type of attribute: | media | 860 | Mux category: | SPECIAL | 861 | Charset Dependent: | No | 862 | Purpose: | Define data channel specific parameters | 863 | Appropriate values: | As defined in Section 5.1.1 | 864 | Contact name: | Maridi R. Makaraju (Raju) | 865 | Contact e-mail: | Raju.Makaraju@alcatel-lucent.com | 866 | Reference: | RFCXXXX | 867 +---------------------+-----------------------------------------+ 869 8.2.2. dcsa 871 NOTE to RFC Editor: Please replace "XXXX" with the number of this 872 RFC. 874 This document defines a new SDP media-level attribute "a=dcsa:" as 875 follows: 877 +---------------------+---------------------------------------------+ 878 | Attribute name: | dcsa | 879 | Type of attribute: | media | 880 | Mux category: | SPECIAL | 881 | Charset Dependent: | No | 882 | Purpose: | Define data channel sub-protocol specific | 883 | | attributes | 884 | Appropriate values: | As defined in Section 5.1.2 | 885 | Contact name: | Maridi R. Makaraju (Raju) | 886 | Contact e-mail: | Raju.Makaraju@alcatel-lucent.com | 887 | Reference: | RFCXXXX | 888 +---------------------+---------------------------------------------+ 890 9. Acknowledgments 892 The authors wish to acknowledge the borrowing of ideas from other 893 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 894 and Gavin Llewellyn, and to thank Roni Even, Christian Groves, 895 Christer Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe 896 Rauschenbach for their invaluable comments. 898 10. CHANGE LOG 900 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 902 o In Section 5.1.1.5 the first (and only) paragraph was "The 903 'subprotocol' parameter indicates which protocol the client 904 expects to exchange via the channel. 'Subprotocol' is an optional 905 parameter. If the 'subprotocol' parameter is not present, then 906 its value defaults to the empty string." Replacement of this 907 paragraph with following two paragraphs: 909 * The 'subprotocol' parameter indicates which protocol the client 910 expects to exchange via the channel. This parameter maps to 911 the 'Protocol' parameter defined in 912 [I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new 913 subprotocol parameter values are registered. 'Subprotocol' is 914 an optional parameter. If the 'subprotocol' parameter is not 915 present, then its value defaults to the empty string. 917 * Note: The empty string MAY also be explicitly used as 918 'subprotocol' value, such that 'subprotocol=""' is equivalent 919 to the 'subprotocol' parameter not being present at all. 920 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 921 message's 'Subprotocol' value to be an empty string. 923 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 924 normative references. 926 o Addition of dcmap attribute specific IANA registration 927 Section 8.2.1. 929 o Addition of dcsa attribute specific IANA registration 930 Section 8.2.2. 932 o Addition of new Section 5.1.1.2 describing the mux category of the 933 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 934 related mux category section are similar to the "Mux Category" 935 sections of the "a=sctp-port:" and "a=max-message-size:" 936 attributes in [I-D.ietf-mmusic-sctp-sdp]. 938 o Addition of new Section 5.1.2.2 describing the mux category of the 939 dcsa SDP attribute. 941 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 943 o In Section 1 replacement of "RTCWeb leaves it open for other 944 applications to use data channels and its in-band DCEP or out-of- 945 band non-DCEP protocols for creating them" with "... to use data 946 channels and its in-band DCEP or other in-band or out-of-band 947 protocols for creating them". Additionally replacement of "In 948 particular, the SDP offer generated by the application includes no 949 channel-specific information" with "... generated by the RTCweb 950 data channel stack includes no channel-specific information". 952 o Move of former section 5 ("Data Channels") to new Appendix A and 953 removal of JavaScript API specific discussions from this moved 954 text (like mentioning of data channel stack specific states). 955 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 956 Section 5. 958 o In Section 5: 960 * Relacement of Section 5's first paragraph "This section defines 961 a method of non-DCEP negotiation by which two clients can 962 negotiate data channel-specific and sub-protocol-specific 963 parameters, using the out-of-band SDP offer/answer exchange. 964 This SDP extension can only be used with the SDP offer/answer 965 model." with "This section defines an SDP extension by which 966 two clients can negotiate data channel-specific and sub- 967 protocol-specific parameters without using DCEP 968 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 969 defines usage in the context of SDP offer/answer." 971 * Addition of new paragraph: "Appendix A provides information how 972 data channels work in general and especially summarizes some 973 key aspects, which should be considered for the negotiation of 974 data channels if DCEP is not used." 976 o In Section 5.1.1 replacement of "The intention of exchanging these 977 attributes is to create data channels on both the peers with the 978 same set of attributes without actually using the DCEP 979 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 980 these attributes is to create, on two peers, without use of DCEP 981 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 982 directed data channels having the same set of attributes". 984 o In Section 5.1.1.6 replacement of "The 'max-retr' parameter 985 indicates the maximal number a user message will be retransmitted" 986 with "The 'max-retr' parameter indicates the maximal number of 987 times a user message will be retransmitted". 989 o In Section 5.2.1 replacement of "However, an SDP offer/answer 990 exchange MUST NOT be initiated if the associated SCTP stream is 991 already negotiated via DCEP" with "However, an SCTP stream MUST 992 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 993 answer exchange if the associated SCTP stream has already been 994 negotiated via DCEP". 996 o In the examples in Section 6 addition of the previously missing 997 colons to the "a=sctp-port" attribute lines. 999 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1001 o Move of reference [I-D.ietf-rtcweb-jsep] from the list of 1002 normative references to the list of informative references. 1004 o Addition of [IANA-SDP-Parameters] to the list of informative 1005 references and addition of following two sentences to the first 1006 paragraph after the ABNF definition: "Note however that not all 1007 SDP attributes are suitable as "a=dcsa:" parameter. 1008 [IANA-SDP-Parameters] contains the lists of IANA registered 1009 session and media level or media level only SDP attributes." 1011 o In the introduction replacement of last sentence "This document 1012 defines SDP-based out-of-band negotiation procedures to establish 1013 data channels for transport of well-defined sub-protocols" with 1014 "This document defines SDP offer/answer negotiation procedures to 1015 establish data channels for transport of well-defined sub- 1016 protocols, to enable out-of-band negotiation". 1018 o Throughout the document replacement of "external negotiation" with 1019 "SDP offer/answer negotiation" and removal of term "external 1020 negotiation" from the terminology list in Section 3. 1022 o Throughout the document replacement of "internal negotiation" with 1023 "DCEP" and removal of terms "internal negotiation" and "in-band 1024 negotiation" from the terminology list in Section 3. 1026 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1027 terms. 1029 o In Section 5.2.1 replacement of sentence "However, a single stream 1030 is managed using one method at a time." with "However, an SDP 1031 offer/answer exchange MUST NOT be initiated if the associated SCTP 1032 stream is already negotiated via DCEP". 1034 o In Section 5.2.2 replacement of sentence "By definition max-retr 1035 and max-time are mutually exclusive, so only one of them can be 1036 present in a=dcmap" with "By definition max-retr and max-time are 1037 mutually exclusive, so at most one of them MAY be present in 1038 a=dcmap". 1040 o Move of reference [WebRtcAPI] from list of normative references to 1041 list of informative references. 1043 o Removal of almost all text parts, which discussed JavaScript or 1044 other API specific aspects. Such API specific aspects were mainly 1045 discussed in sub-sections of Section 5 and Section 5 of draft- 1046 ietf-mmusic-data-channel-sdpneg-02. 1048 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1050 o New Section 4 regarding applicability to SDP offer/answer only. 1052 o Addition of new Section 8.1 "Subprotocol identifiers" as 1053 subsection of the "IANA Considerations" related Section 8. Also 1054 removal of the temporary note "To be completed. As [I-D.ietf- 1055 rtcweb-data-protocol] this document should refer to IANA's 1056 WebSocket Subprotocol Name Registry defined in [RFC6455]." 1058 o In Section 5.2.2: 1060 * In the first paragraph replacement of the sentence "If an SDP 1061 offer contains both of these parameters then such an SDP offer 1062 will be rejected." with "If an SDP offer contains both of these 1063 parameters then the receiver of such an SDP offer MUST reject 1064 the SDP offer." 1066 * In the second paragraph capitalization of "shall" and "may" 1067 such that both sentences now read: "The SDP answer SHALL echo 1068 the same subprotocol, max-retr, max-time, ordered parameters, 1069 if those were present in the offer, and MAY include a label 1070 parameter. They MAY appear in any order, which could be 1071 different from the SDP offer, in the SDP answer." 1073 * In the third paragraph replacement of the sentence "The same 1074 information MUST be replicated without changes in any 1075 subsequent offer or answer, as long as the data channel is 1076 still opened at the time of offer or answer generation." with 1077 "When sending a subsequent offer or an answer, and for as long 1078 as the data channel is still open, the sender MUST replicate 1079 the same information.". 1081 o In Section 5.2.2 the mapping of data channel types defined in 1082 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1083 parameters were illustrated using example "a=dcmap" attribute 1084 lines. Replacement of these example "a=dcmap" attribute lines 1085 with just the "a=dcmap" attribute parameters being relevant for 1086 the channel type. 1088 o In Section 5.2.5 the description of bullet point "SDP offer has no 1089 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1090 No data channel negotiated yet." Replacement of this description 1091 with "Initial SDP offer: No data channel is negotiated yet. The 1092 DTLS connection and SCTP association is negotiated and, if agreed, 1093 established as per [I-D.ietf-mmusic-sctp-sdp]." 1095 o In Section 5.2.5 in both bullet points related to "Subsequent SDP 1096 offer" and "Subsequent SDP answer" replacement of "All the 1097 externally negotiated data channels must be closed now." with "All 1098 the externally negotiated data channels are expected be closed 1099 now.". 1101 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1102 replacement of the two occurrences of "must" with "MUST". 1104 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1105 there was a comment saying that "Either only maxretr-opt or 1106 maxtime-opt is present. Both MUST not be present." Removal of 1107 the second normative sentence and instead addition of following 1108 new paragraph to the end of this section: "Within an 'a=dcmap' 1109 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1110 parameter or one 'maxtime-opt' parameter is present. Both MUST 1111 NOT be present." 1113 o In Section 5.1.1.8 replacement of the first sentence "The 1114 'ordered' parameter with value "true" indicates that DATA chunks 1115 in the channel MUST be dispatched to the upper layer by the 1116 receiver while preserving the order." with "The 'ordered' 1117 parameter with value "true" indicates that the receiver MUST 1118 dispatch DATA chunks in the data channel to the upper layer while 1119 preserving the order.". 1121 o In Section 5.2.3's first paragraph replacement of the one 1122 occurrence of "must" with "..., it MUST wait until ...". 1124 o In Section 5.2.4: 1126 * In the second paragraph replacement of "must" with "... whether 1127 this closing MUST in addition ..." 1129 * In the third paragraph replacement of the sentence "The port 1130 value for the "m" line SHOULD not be changed (e.g., to zero) 1131 when closing a data channel ..." with "The offerer SHOULD NOT 1132 change the port value for the "m" line (e.g., to zero) when 1133 closing a data channel ...". 1135 * In the last but two paragraph replacement of the sentence "... 1136 then an SDP offer which excludes this closed data channel 1137 SHOULD be generated." with "... then the client SHOULD generate 1138 an SDP offer which excludes this closed data channel.". 1140 * In the last but one paragraph replacement of "must" with "The 1141 application MUST also close...". 1143 o In Section 5.1.2 addition of following note after the formal 1144 definition of the 'a=dcsa' attribute: "Note that the above 1145 reference to RFC 4566 defines were the attribute definition can be 1146 found; it does not provide any limitation on support of attributes 1147 defined in other documents in accordance with this attribute 1148 definition." 1150 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1152 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1153 channel consisting of paired SCTP outbound and inbound streams." 1154 Replacement of this definition with "Data channel: A WebRTC data 1155 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1156 consistent usage of "data channel" in the remainder of the 1157 document including the document's headline." 1159 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1160 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1161 In particular we expect "webrtc-datachannel" to become a more 1162 general term.' 1164 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1166 o In Section 5.1.1 removal of the example dcmap attribute line 1167 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1168 already four examples right after the ABNF rules in 1169 Section 5.1.1.1. Corresponding removal of following related note: 1170 "Note: This document does not provide a complete specification of 1171 how to negotiate the use of a WebRTC data channel to transport 1172 BFCP. Procedures specific to each sub-protocol such as BFCP will 1173 be documented elsewhere. The use of BFCP is only an example of 1174 how the generic procedures described herein might apply to a 1175 specific sub-protocol." 1177 o In Section 5.1.1 removal of following note: "Note: This attribute 1178 is derived from attribute "webrtc-DataChannel", which was defined 1179 in old version 03 of the following draft, but which was removed 1180 along with any support for SDP external negotiation in subsequent 1181 versions: [I-D.ietf-mmusic-sctp-sdp]." 1183 o Insertion of following new sentence to the beginning of 1184 Section 5.1.1.1: "dcmap is a media level attribute having 1185 following ABNF syntax:" 1187 o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id 1188 specifying sentence, which previously was placed right before the 1189 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1190 parameter and is noted directly after the "a=dcmap:" attribute's 1191 colon' as this information is part of the ABNF specification. 1193 o In Section 5.1.1.1 modification of the 'ordering-value' values 1194 from "0" or "1" to "true" or "false". Corresponding text 1195 modifications in Section 5.1.1.8. 1197 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1198 to rule name "escaped-char", which was not defined. Instead a 1199 rule with name "escaped" was defined. Renamed that rule's name to 1200 "escaped-char". 1202 o Insertion of a dedicated note right after the "a=dcmap:4" 1203 attribute example in Section 5.1.1.1 regarding the non-printable 1204 "escaped-char" character within the "label" value. 1206 o In Section 5.1.2's second paragraph replacement of "sctp stream 1207 identifier" with "SCTP stream identifier". 1209 o In first paragraph of Section 5.2.1 replacement of first two 1210 sentences 'For the SDP-based external negotiation described in 1211 this document, the initial offerer based "SCTP over DTLS" owns by 1212 convention the even stream identifiers whereas the initial 1213 answerer owns the odd stream identifiers. This ownership is 1214 invariant for the whole lifetime of the signaling session, e.g. it 1215 does not change if the initial answerer sends a new offer to the 1216 initial offerer.' with 'If an SDP offer/answer exchange (could be 1217 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1218 TCP/DTLS/SCTP based media description being accepted, and if this 1219 SDP offer/answer exchange results in the establishment of a new 1220 SCTP association, then the SDP offerer owns the even SCTP stream 1221 ids of this new SCTP association and the answerer owns the odd 1222 SCTP stream identifiers. If this "m" line is removed from the 1223 signaling session (its port number set to zero), and if usage of 1224 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1225 renegotiated later on, then the even and odd SCTP stream 1226 identifier ownership is redetermined as well as described above.' 1228 o In Section 5.2.3 the first action of an SDP answerer, when 1229 receiving an SDP offer, was described as "Applies the SDP offer. 1230 Note that the browser ignores data channel specific attributes in 1231 the SDP." Replacement of these two sentences with "Parses and 1232 applies the SDP offer. Note that the typical parser normally 1233 ignores unknown SDP attributes, which includes data channel 1234 related attributes." 1236 o In Section 5.2.3 the second sentence of the third SDP answerer 1237 action was "Note that the browser is asked to create data channels 1238 with stream identifiers not "owned" by the agent.". Replacement 1239 of this sentence with "Note that the agent is asked to create data 1240 channels with SCTP stream identifiers contained in the SDP offer 1241 if the SDP offer is accepted." 1243 o In Section 5.2.4 the third paragraph began with "A data channel 1244 can be closed by sending a new SDP offer which excludes the dcmap 1245 and dcsa attribute lines for the data channel. The port value for 1246 the m line should not be changed (e.g., to zero) when closing a 1247 data channel (unless all data channels are being closed and the 1248 SCTP association is no longer needed), since this would close the 1249 SCTP association and impact all of the data channels. If the 1250 answerer accepts the SDP offer then it MUST also exclude the 1251 corresponding attribute lines in the answer. ..." Replacement of 1252 this part with "The intention to close a data channel can be 1253 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1254 and "a=dcsa:" attribute lines for the data channel. The port 1255 value for the "m" line SHOULD not be changed (e.g., to zero) when 1256 closing a data channel (unless all data channels are being closed 1257 and the SCTP association is no longer needed), since this would 1258 close the SCTP association and impact all of the data channels. 1259 If the answerer accepts the SDP offer then it MUST close those 1260 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1261 excluded from the received SDP offer, unless those data channels 1262 were already closed, and it MUST also exclude the corresponding 1263 attribute lines in the answer." 1265 o In Section 5.2.4 the hanging text after the third paragraph was 1266 "This delayed close is to handle cases where a successful SDP 1267 answer is not received, in which case the state of session should 1268 be kept per the last successful SDP offer/answer." Replacement of 1269 this sentence with "This delayed closure is RECOMMENDED in order 1270 to handle cases where a successful SDP answer is not received, in 1271 which case the state of the session SHOULD be kept per the last 1272 successful SDP offer/answer." 1274 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1275 Section 5.1.1 contained already procedural descriptions related to 1276 data channel reliability negotiation. Creation of new 1277 Section 5.2.2 and moval of reliability negotiation related text to 1278 this new section. 1280 10.6. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1282 o Removal of note "[ACTION ITEM]" from section "subprotocol 1283 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1284 should refer to IANA's WebSocket Subprotocol Name Registry defined 1285 in [RFC6455]. 1287 o In whole document, replacement of "unreliable" with "partially 1288 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1289 [I-D.ietf-rtcweb-data-protocol] in most places. 1291 o Clarification of the semantic if the "max-retr" parameter is not 1292 present in an a=dcmap attribute line. In section "max-retr 1293 parameter" the sentence "The max-retr parameter is optional with 1294 default value unbounded" was replaced with "The max-retr parameter 1295 is optional. If the max-retr parameter is not present, then the 1296 maximal number of retransmissions is determined as per the generic 1297 SCTP retransmission rules as specified in [RFC4960]". 1299 o Clarification of the semantic if the "max-time" parameter is not 1300 present in an a=dcmap attribute line. In section "max-time 1301 parameter" the sentence "The max-time parameter is optional with 1302 default value unbounded" was replaced with "The max-time parameter 1303 is optional. If the max-time parameter is not present, then the 1304 generic SCTP retransmission timing rules apply as specified in 1305 [RFC4960]". 1307 o In section "label parameter" the sentence "Label is a mandatory 1308 parameter." was removed and following new sentences (including the 1309 note) were added: "The 'label' parameter is optional. If it is 1310 not present, then its value defaults to the empty string. Note: 1311 The empty string may also be explicitly used as 'label' value, 1312 such that 'label=""' is equivalent to the 'label' parameter not 1313 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1314 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1316 o In section "subprotocol parameter" the sentence "Subprotocol is a 1317 mandatory parameter." was replaced with "'Subprotocol' is an 1318 optional parameter. If the 'subprotocol' parameter is not 1319 present, then its value defaults to the empty string." 1321 o In the "Examples" section, in the first two SDP offer examples in 1322 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1323 'label="BFCP"'. 1325 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1326 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1327 replaced with "a=max-message-size" attribute lines, as per draft- 1328 ietf-mmusic-sctp-sdp-12. 1330 10.7. Changes against '-01' 1332 o Formal syntax for dcmap and dcsa attribute lines. 1334 o Making subprotocol as an optional parameter in dcmap. 1336 o Specifying disallowed parameter combinations for max-time and max- 1337 retr. 1339 o Clarifications on WebRTC data channel close procedures. 1341 10.8. Changes against '-00' 1343 o Revisions to identify difference between internal and external 1344 negotiation and their usage. 1346 o Introduction of more generic terminology, e.g. "application" 1347 instead of "browser". 1349 o Clarification of how "max-retr and max-time affect the usage of 1350 unreliable and reliable WebRTC data channels. 1352 o Updates of examples to take into account the SDP syntax changes 1353 introduced with draft-ietf-mmusic-sctp-sdp-07. 1355 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1356 attributes as this is now contained in the a=sctp-port attribute, 1357 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1358 association on top of the DTLS connection. 1360 11. References 1362 11.1. Normative References 1364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1365 Requirement Levels", BCP 14, RFC 2119, 1366 DOI 10.17487/RFC2119, March 1997, 1367 . 1369 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1370 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1371 July 2006, . 1373 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1374 with Session Description Protocol (SDP)", RFC 3264, 1375 DOI 10.17487/RFC3264, June 2002, 1376 . 1378 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1379 Specifications: ABNF", STD 68, RFC 5234, 1380 DOI 10.17487/RFC5234, January 2008, 1381 . 1383 [I-D.ietf-rtcweb-data-channel] 1384 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1385 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1386 progress), January 2015. 1388 [I-D.ietf-mmusic-sctp-sdp] 1389 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1390 Control Transmission Protocol (SCTP)-Based Media Transport 1391 in the Session Description Protocol (SDP)", draft-ietf- 1392 mmusic-sctp-sdp-15 (work in progress), September 2015. 1394 [I-D.ietf-mmusic-sdp-mux-attributes] 1395 Nandakumar, S., "A Framework for SDP Attributes when 1396 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-10 1397 (work in progress), July 2015. 1399 11.2. Informative References 1401 [I-D.ietf-rtcweb-data-protocol] 1402 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1403 Establishment Protocol", draft-ietf-rtcweb-data- 1404 protocol-09 (work in progress), January 2015. 1406 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1407 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1408 . 1410 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1411 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1412 DOI 10.17487/RFC4975, September 2007, 1413 . 1415 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1416 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1417 DOI 10.17487/RFC4976, September 2007, 1418 . 1420 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 1421 and P. Kyzivat, "A Session Description Protocol (SDP) 1422 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 1423 DOI 10.17487/RFC5547, May 2009, 1424 . 1426 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 1427 for the Message Session Relay Protocol (MSRP)", RFC 6135, 1428 DOI 10.17487/RFC6135, February 2011, 1429 . 1431 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1432 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1433 . 1435 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1436 Establishment for Media Anchoring (CEMA) for the Message 1437 Session Relay Protocol (MSRP)", RFC 6714, 1438 DOI 10.17487/RFC6714, August 2012, 1439 . 1441 [I-D.ietf-rtcweb-jsep] 1442 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 1443 Session Establishment Protocol", draft-ietf-rtcweb-jsep-11 1444 (work in progress), July 2015. 1446 [IANA-SDP-Parameters] 1447 "Session Description Protocol (SDP) Parameters", Internet 1448 Assigned Numbers Authority Protocol Assignments Session 1449 Description Protocol (SDP) Parameters, 1450 . 1453 [WebRtcAPI] 1454 Bergkvist, A., Burnett, D., Jennings, C., and A. 1455 Narayanan, "WebRTC 1.0: Real-time Communication Between 1456 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1457 February 2015, 1458 . 1460 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1461 DCEP 1463 This appendix summarizes how data channels work in general and 1464 discusses some key aspects, which should be considered for the out- 1465 of-band negotiation of data channels if DCEP is not used. 1467 A WebRTC application creates a data channel by providing a number of 1468 setup parameters (sub-protocol, label, reliability, order of 1469 delivery, priority). The application also specifies if it wants to 1470 make use of the negotiation using the DCEP 1471 [I-D.ietf-rtcweb-data-protocol], or if the application intends to 1472 negotiate data channels using the SDP offer/answer protocol. 1474 In any case, the SDP offer generated by the application is per 1475 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1476 the SCTP association on top of which data channels will run: 1478 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1479 c=IN IP4 79.97.215.79 1480 a=max-message-size:100000 1481 a=sctp-port:5000 1482 a=setup:actpass 1483 a=connection:new 1484 a=fingerprint:SHA-1 \ 1485 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1487 Note: A WebRTC application will only use "m" line format "webrtc- 1488 datachannel", and will not use other formats in the "m" line for 1489 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1490 only one SCTP association to be established on top of a DTLS 1491 association. 1493 Note: Above SDP media description does not contain any channel- 1494 specific information. 1496 A.1. Stream Identifier Numbering 1498 Independently from the requested type of negotiation, the application 1499 creating a data channel can either pass to the data channel stack the 1500 stream identifier to assign to the data channel or else let the data 1501 channel stack pick one identifier from the ones unused. 1503 To avoid glare situations, each endpoint can moreover own an 1504 exclusive set of stream identifiers, in which case an endpoint can 1505 only create a data channel with a stream identifier it owns. 1507 Which set of stream identifiers is owned by which endpoint is 1508 determined by convention or other means. 1510 For data channels negotiated with the DCEP, one endpoint owns by 1511 convention the even stream identifiers, whereas the other owns the 1512 odd stream identifiers, as defined in 1513 [I-D.ietf-rtcweb-data-protocol]. 1515 For data channels negotiated via some protocol different from 1516 DCEP, no convention is defined by default. 1518 A.2. Generic Data Channel Negotiation Not Using DCEP 1520 A.2.1. Overview 1522 DCEP negotiation only provides for negotiation of data channel 1523 transport parameters and does not provide for negotiation of sub- 1524 protocol specific parameters. DCEP-less data channel negotiation can 1525 be defined to allow negotiation of parameters beyond those handled by 1526 DCEP, e.g., parameters specific to the sub-protocol instantiated on a 1527 particular data channel. 1529 The following procedures are common to all methods of data channel 1530 negotiation not using DCEP, whether in-band (communicated using 1531 proprietary means on an already established data channel) or out-of- 1532 band (using SDP offer/answer or some other protocol associated with 1533 the signaling channel). 1535 A.2.2. Opening a Data Channel 1537 In the case of DCEP-less negotiation, the endpoint application has 1538 the option to fully control the stream identifier assignments. 1539 However these assignments have to coexist with the assignments 1540 controlled by the data channel stack for the DCEP negotiated data 1541 channels (if any). It is the responsibility of the application to 1542 ensure consistent assignment of stream identifiers. 1544 When the application requests the creation of a new data channel to 1545 be set up via DCEP-less negotiation, the data channel stack creates 1546 the data channel locally without sending any DATA_CHANNEL_OPEN 1547 message in-band. However, even if the ICE, DTLS and SCTP procedures 1548 were already successfully completed, the application can't send data 1549 on this data channel until the negotiation is complete with the peer. 1550 This is because the peer needs to be aware of and accept the usage of 1551 this data channel. The peer, after accepting the data channel offer, 1552 can start sending data immediately. This implies that the offerer 1553 may receive data channel sub-protocol messages before the negotiation 1554 is complete and the application should be ready to handle it. 1556 If the peer rejects the data channel part of the offer then it 1557 doesn't have to do anything as the data channel was not created using 1558 the stack. The offerer on the other hand needs to close the data 1559 channel that was opened by invoking relevant data channel stack API 1560 procedures. 1562 It is also worth noting that a data channel stack implementation may 1563 not provide any API to create and close data channels; instead the 1564 data channels may be used on the fly as needed just by communicating 1565 via non-DCEP means or by even having some local configuration/ 1566 assumptions on both the peers. 1568 The application then negotiates the data channel properties and sub- 1569 protocol properties with the peer's application using a mechanism 1570 different from DCEP. 1572 The peer then symmetrically creates a data channel with these 1573 negotiated data channel properties. This is the only way for the 1574 peer's data channel stack to know which properties to apply when 1575 transmitting data on this channel. The data channel stack must allow 1576 data channel creation with any non-conflicting stream identifier so 1577 that both peers can create the data channel with the same stream 1578 identifier. 1580 A.2.3. Closing a Data Channel 1582 When the application requests the closing of a data channel 1583 negotiated without DCEP, the data channel stack always performs an 1584 SCTP SSN reset for this channel. 1586 Depending upon the method used for DCEP-less negotiation and the sub- 1587 protocol associated with the data channel, the closing might in 1588 addition be signaled to the peer via SDP offer/answer negotiation. 1590 Authors' Addresses 1591 Keith Drage (editor) 1592 Alcatel-Lucent 1593 Quadrant, Stonehill Green, Westlea 1594 Swindon 1595 UK 1597 Email: keith.drage@alcatel-lucent.com 1599 Maridi R. Makaraju (Raju) 1600 Alcatel-Lucent 1601 2000 Lucent Lane 1602 Naperville, Illinois 1603 US 1605 Email: Raju.Makaraju@alcatel-lucent.com 1607 Juergen Stoetzer-Bradler 1608 Alcatel-Lucent 1609 Lorenzstrasse 10 1610 D-70435 Stuttgart 1611 Germany 1613 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 1615 Richard Ejzak 1616 Unaffiliated 1618 Email: richard.ejzak@gmail.com 1620 Jerome Marcon 1621 Unaffiliated