idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-08.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 (February 17, 2016) is 2990 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) == Missing Reference: 'I-D.ietf-rtcweb-jsep' is mentioned on line 1147, but not defined == Missing Reference: 'RFC6455' is mentioned on line 1432, but not defined ** 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-12 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 9 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: August 20, 2016 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 February 17, 2016 11 SDP-based Data Channel Negotiation 12 draft-ietf-mmusic-data-channel-sdpneg-08 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 (Stream Control Transmission Protocol), where each 22 data channel might be used to transport other protocols, called 23 subprotocols. Data channel setup can be done using either the in- 24 band Data Channel Establishment Protocol (DCEP) or using some out-of- 25 band non-DCEP protocol. This document specifies how the SDP (Session 26 Description Protocol) offer/answer exchange can be used to achieve 27 such an out-of-band non-DCEP negotiation. Even though data channels 28 are designed for RTCWeb use initially, they may be used by other 29 protocols like, but not limited to, the CLUE protocol (which is 30 defined by the IETF "ControLling mUltiple streams for tElepresence" 31 working group). This document is intended to be used wherever data 32 channels are used. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 20, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 71 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 5 72 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 73 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 5 74 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 6 75 5.1.1.2. dcmap Multiplexing Category . . . . . . . . . . . 7 76 5.1.1.3. dcmap-stream-id Parameter . . . . . . . . . . . . 8 77 5.1.1.4. label Parameter . . . . . . . . . . . . . . . . . 8 78 5.1.1.5. subprotocol Parameter . . . . . . . . . . . . . . 8 79 5.1.1.6. max-retr Parameter . . . . . . . . . . . . . . . 9 80 5.1.1.7. max-time Parameter . . . . . . . . . . . . . . . 9 81 5.1.1.8. ordered Parameter . . . . . . . . . . . . . . . . 9 82 5.1.1.9. priority Parameter . . . . . . . . . . . . . . . 9 83 5.1.2. Other Media Level Attributes . . . . . . . . . . . . 9 84 5.1.2.1. dcsa Attribute . . . . . . . . . . . . . . . . . 10 85 5.1.2.2. dcsa Multiplexing Category . . . . . . . . . . . 11 86 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12 88 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 12 89 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 13 90 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 15 91 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 16 92 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 20 96 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21 97 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21 98 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 21 99 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 100 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 10.1. Changes against 'draft-ietf-mmusic-data-channel- 102 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 22 103 10.2. Changes against 'draft-ietf-mmusic-data-channel- 104 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 22 105 10.3. Changes against 'draft-ietf-mmusic-data-channel- 106 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23 107 10.4. Changes against 'draft-ietf-mmusic-data-channel- 108 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 23 109 10.5. Changes against 'draft-ietf-mmusic-data-channel- 110 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 24 111 10.6. Changes against 'draft-ietf-mmusic-data-channel- 112 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 25 113 10.7. Changes against 'draft-ietf-mmusic-data-channel- 114 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 26 115 10.8. Changes against 'draft-ietf-mmusic-data-channel- 116 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29 117 10.9. Changes against 'draft-ejzak-mmusic-data-channel- 118 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 31 119 10.10. Changes against '-01' . . . . . . . . . . . . . . . . . 32 120 10.11. Changes against '-00' . . . . . . . . . . . . . . . . . 33 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 122 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 123 11.2. Informative References . . . . . . . . . . . . . . . . . 34 124 Appendix A. Generic Data Channel Negotiation Aspects When Not 125 Using DCEP . . . . . . . . . . . . . . . . . . . . . 34 126 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 35 127 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 36 128 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 36 129 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 36 130 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 37 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 133 1. Introduction 135 The RTCWeb working group has defined the concept of bi-directional 136 data channels running on top of SCTP/DTLS (SCTP over the Datagram 137 Transport Layer Security protocol). RTCWeb allows applications to 138 use data channels. RTCWeb defines an in-band DCEP, however other in- 139 band or out-of-band protocols may be used for establishing data 140 channels. Each data channel consists of paired SCTP streams sharing 141 the same SCTP Stream Identifier. Data channels are created by 142 endpoint applications through the WebRTC API (Application Programming 143 Interface), or other users of a data channel like CLUE. They can be 144 used to transport proprietary or well-defined protocols, which in the 145 latter case can be signaled by the data channel "subprotocol" 146 parameter, conceptually similar to the WebSocket "subprotocol". 147 However, apart from the "subprotocol" value transmitted to the peer, 148 RTCWeb leaves it open how endpoint applications can agree on how to 149 instantiate a given subprotocol on a data channel, and whether it is 150 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 151 (or both). In particular, the SDP offer generated by the RTCweb data 152 channel stack includes no channel-specific information. 154 This document defines SDP offer/answer negotiation procedures to 155 establish data channels for transport of well-defined subprotocols, 156 to enable out-of-band negotiation. 158 This document makes use of MSRP (Message Session Relay Protocol) in 159 many of the examples. It does not provide a complete specification 160 of how to negotiate the use of a data channel to transport MSRP. 161 Procedures specific to each subprotocol such as MSRP are documented 162 elsewhere. The use of MSRP in some examples is only to show how the 163 generic procedures described herein might apply to a specific 164 subprotocol. 166 2. Conventions 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 3. Terminology 174 This document uses the following terms: 176 Data channel: A WebRTC data channel as specified in 177 [I-D.ietf-rtcweb-data-channel]. 179 Data channel stack: An entity which, upon application request, 180 runs the data channel protocol to keep track of states, sending 181 and receive data. If the application is a browser based 182 JavaScript application then this stack resides in the browser. If 183 the application is a native application then this stack resides in 184 the application and is accessible via some sort of APIs. 186 Data channel properties: Fixed properties assigned to a data 187 channel at the time of its creation. Some of these properties 188 determine the way the data channel stack transmits data on this 189 channel (e.g., stream identifier, reliability, order of 190 delivery...). 192 DCEP: Data Channel Establishment Protocol defined in 193 [I-D.ietf-rtcweb-data-protocol]. 195 In-band: Transmission through the peer-to-peer SCTP association. 197 Out-of-band: Transmission through the application signaling path. 199 Peer: From the perspective of one of the agents in a session, its 200 peer is the other agent. Specifically, from the perspective of 201 the SDP offerer, the peer is the SDP answerer. From the 202 perspective of the SDP answerer, the peer is the SDP offerer. 204 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 205 as specified in [RFC4960]. 207 Stream identifier: The identifier of the outbound and inbound SCTP 208 streams composing a data channel. 210 4. Applicability Statement 212 The mechanism in this document only applies to the Session 213 Description Protocol (SDP) [RFC4566], when used together with the SDP 214 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 215 scope of this document, and is thus undefined. 217 5. SDP Offer/Answer Negotiation 219 This section defines an SDP extension by which two clients can 220 negotiate data channel-specific and subprotocol-specific parameters 221 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 222 extension only defines usage in the context of SDP offer/answer. 224 Appendix A provides information how data channels work in general and 225 especially summarizes some key aspects, which should be considered 226 for the negotiation of data channels if DCEP is not used. 228 5.1. SDP Syntax 230 Two new SDP attributes are defined to support SDP offer/answer 231 negotiation of data channels. The first attribute provides for 232 negotiation of channel-specific parameters. The second attribute 233 provides for negotiation of subprotocol-specific parameters. 235 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 237 Associated with the SDP "m" line that defines the SCTP association 238 for data channels (defined in Section 3), each SDP offer and answer 239 includes one "a=dcmap:" attribute that defines the data channel 240 parameters for each data channel to be negotiated. Each such 241 attribute line specifies the following parameters for a data channel: 242 SCTP stream identifier, subprotocol, label, maximal number of 243 retransmissions, maximal retransmission time, order of delivery, and 244 priority. 246 The intention in exchanging these attributes is to create, on two 247 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 248 pairs of oppositely directed data channels having the same set of 249 attributes. It is assumed that the data channel properties 250 (reliable/partially reliable, ordered/unordered) are suitable per the 251 subprotocol transport requirements. 253 5.1.1.1. dcmap Attribute 255 "a=dcmap:" is a media level attribute having following ABNF 256 (Augmented Backus-Naur Form, [RFC5234]) syntax. 258 Formal Syntax: 260 Name: dcmap 262 Value: dcmap-value 264 Usage Level: media 266 Charset Dependent: no 268 Syntax: 270 dcmap-value = dcmap-stream-id 271 [ SP dcmap-opt *(";" dcmap-opt) ] 272 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 273 / maxretr-opt / maxtime-opt / priority-opt 274 ; Either only maxretr-opt or maxtime-opt 275 ; is present. 277 dcmap-stream-id = 1*DIGIT 278 ordering-opt = "ordered=" ordering-value 279 ordering-value = "true" / "false" 280 subprotocol-opt = "subprotocol=" quoted-string 281 label-opt = "label=" quoted-string 282 maxretr-opt = "max-retr=" maxretr-value 283 maxretr-value = "0" / integer 284 ; number of retransmissions, 285 ; less than 2^32, 286 ; derived from 'Reliability Parameter' of 287 ; [I-D.ietf-rtcweb-data-protocol] 289 maxtime-opt = "max-time=" maxtime-value 290 maxtime-value = "0" / integer 291 ; milliseconds, 292 ; less than 2^32, 293 ; derived from 'Reliability Parameter' of 294 ; [I-D.ietf-rtcweb-data-protocol] 295 priority-opt = "priority=" priority-value 296 priority-value = "0" / integer 297 ; unsigned integer value indicating the priority of 298 ; the data channel, 299 ; less than 2^16, 300 ; derived from 'Priority' of 301 ; [I-D.ietf-rtcweb-data-protocol] 303 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 304 quoted-char = SP / quoted-visible 305 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 306 escaped-char = "%" HEXDIG HEXDIG 307 DQUOTE = 308 integer = 310 Examples: 312 a=dcmap:0 313 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 314 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 315 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 316 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 318 Note: The last example (a=dcmap:4) shows a 'label' parameter value 319 which contains one non-printable 'escaped-char' character (the 320 tabulator character). 322 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 323 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 324 present. Both MUST NOT be present. 326 5.1.1.2. dcmap Multiplexing Category 328 Multiplexing characteristics of SDP attributes are described in 329 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 330 multiplexing categories are introduced there. 332 The multiplexing category of the "a=dcmap:" attribute is SPECIAL. 334 As the usage of multiple SCTP associations on top of a single DTLS 335 connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 336 "a=dcmap:" attribute multiplexing rules are specified for the 337 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. This document also 338 does not specify multiplexing rules for this attribute for SCTP or 339 SCTP/DTLS proto values. If future extensions of 340 [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 341 multiple SCTP associations on top of a single DTLS connection, or how 342 to add multiple SCTP associations to one BUNDLE group, then 343 multiplexing rules for the "a=dcmap:" attribute need to be defined as 344 well, for instance in an extension of this SDP based data channel 345 negotiation specification. 347 5.1.1.3. dcmap-stream-id Parameter 349 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 350 within the SCTP association used to form the data channel. 352 5.1.1.4. label Parameter 354 The 'label' parameter indicates the name of the channel. It 355 represents a label that can be used to distinguish, in the context of 356 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 357 RTCDataChannel objects. This parameter maps to the 'Label' parameter 358 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 359 optional. If it is not present, then its value defaults to the empty 360 string. 362 Note: The empty string MAY also be explicitly used as a 'label' 363 value, such that 'label=""' is equivalent to the 'label' parameter 364 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 365 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 367 5.1.1.5. subprotocol Parameter 369 The 'subprotocol' parameter indicates which protocol the client 370 expects to exchange via the channel. This parameter maps to the 371 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 372 Section 8.1 specifies how new subprotocol parameter values are 373 registered. 'Subprotocol' is an optional parameter. If the 374 'subprotocol' parameter is not present, then its value defaults to an 375 empty string. 377 Note: The empty string MAY also be explicitly used as 'subprotocol' 378 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 379 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 380 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 381 empty string. 383 5.1.1.6. max-retr Parameter 385 This parameter indicates that the data channel is partially reliable. 386 The 'max-retr' parameter indicates the maximal number of times a user 387 message will be retransmitted. The max-retr parameter is optional. 388 If the max-retr parameter is not present, then the maximal number of 389 retransmissions is determined as per the generic SCTP retransmission 390 rules as specified in [RFC4960]. This parameter maps to the 'Number 391 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 393 5.1.1.7. max-time Parameter 395 This parameter indicates that the data channel is partially reliable. 396 A user message will no longer be transmitted or retransmitted after a 397 specified life-time given in milliseconds in the 'max-time' 398 parameter. The max-time parameter is optional. If the max-time 399 parameter is not present, then the generic SCTP retransmission timing 400 rules apply as specified in [RFC4960]. This parameter maps to the 401 'Lifetime in ms' parameter defined in 402 [I-D.ietf-rtcweb-data-protocol]. 404 5.1.1.8. ordered Parameter 406 The 'ordered' parameter with value "true" indicates that the receiver 407 MUST dispatch DATA chunks in the data channel to the upper layer 408 while preserving the order. The ordered parameter is optional and 409 takes two values: "true" for ordered and "false" for unordered 410 delivery with "true" as the default value. Any other value is 411 ignored and default "ordered=true" is assumed. In the absence of 412 this parameter "ordered=true" is assumed. This parameter maps to the 413 ordered or unordered data channel types as defined in 414 [I-D.ietf-rtcweb-data-protocol]. 416 5.1.1.9. priority Parameter 418 The 'priority' parameter indicates the data channel's priority 419 relative to the priorities of other data channels, which may 420 additionally exist over the same SCTP association. The 'priority' 421 parameter maps to the 'Priority' parameter defined in 422 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 423 optional. In the absence of this parameter "priority=256" is 424 assumed. 426 5.1.2. Other Media Level Attributes 428 In the SDP, each data channel declaration MAY also be followed by 429 other media level SDP attributes, which are either specifically 430 defined for or applied to the subprotocol in use. Each of these 431 attributes is represented by one new attribute line, and it includes 432 the contents of a media-level SDP attribute already defined for use 433 with this (sub)protocol in another IETF (Internet Engineering Task 434 Force) document. Subprotocol specific attributes MAY also be defined 435 for exclusive use with data channel transport, but SHOULD use the 436 same syntax described here for other subprotocol related attributes. 438 5.1.2.1. dcsa Attribute 440 Each SDP attribute, related to the subprotocol, that would normally 441 be used to negotiate the subprotocol using SDP is replaced with an 442 attribute of the form "a=dcsa:stream-id original-attribute", where 443 dcsa stands for "data channel subprotocol attribute", stream-id is 444 the SCTP stream identifier assigned to this subprotocol instance, and 445 original-attribute represents the contents of the subprotocol related 446 attribute to be included. 448 The same syntax applies to any other SDP attribute required for 449 negotiation of this instance of the subprotocol. 451 Formal Syntax: 453 Name: dcsa 455 Value: dcsa-value 457 Usage Level: media 459 Charset Dependent: no 461 Syntax: 463 dcsa-value = stream-id SP attribute 464 attribute = 466 Example: 468 a=dcsa:2 accept-types:text/plain 470 Note that the above reference to [RFC4566] defines where the 471 attribute definition can be found; it does not provide any limitation 472 on support of attributes defined in other documents in accordance 473 with this attribute definition. Note however that not all SDP 474 attributes are suitable as a "a=dcsa:" parameter. 475 [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned 476 Numbers Authority) registered session and media level or media level 477 only SDP attributes. 479 Thus in the example above, the original attribute line "a=accept- 480 types:text/plain" is represented by the attribute line "a=dcsa:2 481 accept-types:text/plain", which specifies that this instance of the 482 MSRP subprotocol being transported on the SCTP association using the 483 data channel with stream id 2 accepts plain text files. 485 As opposed to the data channel "a=dcmap:" attribute parameters, these 486 parameters are subject to offer/answer negotiation following the 487 procedures defined in the subprotocol specific documents. 489 It is assumed that in general the usages of subprotocol related media 490 level attributes are independent from the subprotocol's transport 491 protocol. Such transport protocol independent subprotocol related 492 attributes are used in the same way as defined in the original 493 subprotocol specification, also if the subprotocol is transported 494 over a data channel and if the attribute is correspondingly embedded 495 in a "a=dcsa" attribute. 497 There may be cases, where the usage of a subprotocol related media 498 level attribute depends on the subprotocol's transport protocol. In 499 such cases the subprotocol related usage of the attribute is expected 500 to be described for the data channel transport. A data channel 501 specific usage of a subprotocol attribute is expected to be specified 502 in the same document, which registers the subprotocol's identifier 503 for data channel usage as described in Section 8.1. 505 5.1.2.2. dcsa Multiplexing Category 507 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 509 As the usage of multiple SCTP associations on top of a single DTLS 510 connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 511 "a=dcsa:" attribute multiplexing rules are specified for the 512 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. This document does 513 also not specify multiplexing rules for this attribute for SCTP or 514 SCTP/DTLS proto values. If future extensions of 515 [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 516 multiple SCTP associations on top of a single DTLS connection, or how 517 to add multiple SCTP associations to one BUNDLE group, then 518 multiplexing rules for the "a=dcsa:" attribute need to be defined as 519 well, for instance in an extension of this SDP based data channel 520 negotiation specification. 522 5.2. Procedures 523 5.2.1. Managing Stream Identifiers 525 If a SDP offer/answer exchange (could be the initial or a subsequent 526 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 527 description being accepted, and if this SDP offer/answer exchange 528 results in the establishment of a new SCTP association, then the SDP 529 offerer owns the even SCTP stream ids of this new SCTP association 530 and the answerer owns the odd SCTP stream identifiers. If this "m" 531 line is removed from the signaling session (its port number set to 532 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 533 SCTP based "m" line is renegotiated later on, then the even and odd 534 SCTP stream identifier ownership is re-determined as described above. 536 This document allows simultaneous use of SDP offer/answer and DCEP 537 negotiation. However, an SCTP stream MUST NOT be referenced in a 538 "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if 539 the associated SCTP stream has already been negotiated via DCEP. 540 Stream ids that are not currently used in SDP can be used for DCEP 541 negotiation. Stream id allocation per SDP offer/answer negotiation 542 may not align with DTLS role based allocation. This could cause 543 glare conditions when one side tries to do SDP offer/answer 544 negotiation on a stream id while the other end tries to open a data 545 channel on the same stream id using DCEP negotiation. To avoid these 546 glare conditions this document recommends that the data channel stack 547 user always selects stream ids per the above described SDP offer/ 548 answer rule even when DCEP negotiation is used. To avoid glare 549 conditions, it is possible to come up with a different stream id 550 allocation scheme, but such schemes are outside the scope of this 551 document. 553 5.2.2. Negotiating Data Channel Parameters 555 Conveying a reliable data channel is achieved by including neither 556 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 557 "a=dcmap:" attribute line. Conveying a partially reliable data 558 channel is achieved by including only one of 'max-retr' or 'max- 559 time'. By definition max-retr and max-time are mutually exclusive, 560 so at most one of them MAY be present in the "a=dcmap:" attribute 561 line. If a SDP offer contains both of these parameters then the 562 receiver of such an SDP offer MUST reject the SDP offer. If a SDP 563 answer contains both of these parameters then the offerer MAY treat 564 it as an error and MAY assume the associated SDP offer/answer failed 565 and MAY take appropriate recovery actions. These recovery options 566 are outside the scope of this document. 568 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 569 ordered parameters, if those were present in the offer, and MAY 570 include a label parameter. They MAY appear in any order, which could 571 be different from the SDP offer, in the SDP answer. 573 When sending a subsequent offer or an answer, and for as long as the 574 data channel is still open, the sender MUST replicate the same 575 information. 577 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 578 mapped to SDP in the following manner, where "ordered=true" is the 579 default and may be omitted: 581 DATA_CHANNEL_RELIABLE 582 ordered=true 584 DATA_CHANNEL_RELIABLE_UNORDERED 585 ordered=false 587 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 588 ordered=true;max-retr= 590 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 591 ordered=false;max-retr= 593 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 594 ordered=true;max-time= 596 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 597 ordered=false;max-time= 599 5.2.3. Opening a Data Channel 601 The procedure for opening a data channel using SDP offer/answer 602 negotiation starts with the agent preparing to send an SDP offer. If 603 a peer receives an SDP offer before starting to send a new SDP offer 604 with data channels that are to be SDP offer/answer negotiated, or 605 loses an SDP offer glare resolution procedure in this case, it MUST 606 wait until the ongoing SDP offer/answer completes before resuming the 607 SDP offer/answer negotiation procedure. 609 The agent that intends to send an SDP offer to create data channels 610 through SDP offer/answer negotiation performs the following: 612 o Creates data channels using stream identifiers from the owned set 613 (see Section 5.2.1). 615 o Generates a new SDP offer. 617 o Determines the list of stream identifiers assigned to data 618 channels opened through SDP offer/answer negotiation. 620 o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:" 621 attributes needed, if any, for each SDP offer/answer negotiated 622 data channel, as described in Section 5.1 and in Section 5.2.2. 624 o If it adds "a=dcsa" attributes to the SDP offer, then it SHOULD 625 add the subprotocol parameter to the "a=dcmap" attribute with a 626 non-empty subprotocol identifier. 628 o Sends the SDP offer. 630 The peer receiving such an SDP offer performs the following: 632 o Parses and applies the SDP offer, taking into account the 633 considerations discussed in Section 5.2.5. 635 o Analyzes the channel parameters and subprotocol attributes to 636 determine whether to accept each offered data channel. 638 o For accepted data channels, it creates peer instances for the data 639 channels with the agent using the channel parameters described in 640 the SDP offer. Note that the agent is asked to create data 641 channels with SCTP stream identifiers contained in the SDP offer 642 if the SDP offer is accepted. 644 o Generates an SDP answer. 646 o Completes the SDP answer with the "a=dcmap:" and optional 647 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 648 data channel, as described in Section 5.1 and in Section 5.2.2. 650 o Sends the SDP answer. 652 The agent receiving such an SDP answer performs the following: 654 o Closes any created data channels as described in Section 5.2.4 for 655 which the expected "a=dcmap:" and "a=dcsa:" attributes are not 656 present in the SDP answer. 658 o Applies the SDP answer. 660 Each agent application MUST wait to send data until it has 661 confirmation that the data channel at the peer is instantiated. For 662 WebRTC, this is when both data channel stacks have channel parameters 663 instantiated. This occurs: 665 o At both peers when a data channel is created without an 666 established SCTP association, as soon as the SCTP association is 667 successfully established. 669 o At the agent receiving an SDP offer for which there is an 670 established SCTP association, as soon as it creates an SDP offer/ 671 answer negotiated data channel based on information signaled in 672 the SDP offer. 674 o At the agent sending an SDP offer to create a new SDP offer/answer 675 negotiated data channel for which there is an established SCTP 676 association, when it receives the SDP answer confirming acceptance 677 of the data channel or when it begins to receive data on the data 678 channel from the peer, whichever occurs first. 680 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 681 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 683 5.2.4. Closing a Data Channel 685 When the application requests the closing of a data channel that was 686 negotiated via SDP offer/answer, the data channel stack always 687 performs an SCTP SSN reset for this channel. 689 It is specific to the subprotocol whether this closing MUST in 690 addition be signaled to the peer via a new SDP offer/answer exchange. 692 The intention to close a data channel can be signaled by sending a 693 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 694 lines for the data channel. The offerer SHOULD NOT change the port 695 value for the "m" line (e.g. to zero) when closing a data channel 696 (unless all data channels are being closed and the SCTP association 697 is no longer needed), since this would close the SCTP association and 698 impact all of the data channels. If the answerer accepts the SDP 699 offer then the answerer MUST close those data channels whose 700 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 701 received SDP offer, unless those data channels were already closed, 702 and the answerer MUST also exclude the corresponding attribute lines 703 in the answer. In addition to that, the SDP answerer MAY exclude 704 other data channels which were closed but not yet communicated to the 705 peer. So, the offerer MUST inspect the answer to see if it has to 706 close other data channels which are now not included in the answer. 708 If a new SDP offer/answer is used to close data channels then the 709 data channel(s) SHOULD only be closed by the answerer/offerer after a 710 successful SDP answer is sent/received. 712 This delayed closure is RECOMMENDED in order to handle cases where 713 a successful SDP answer is not received, in which case the state 714 of the session SHOULD be kept per the last successful SDP offer/ 715 answer. 717 If a client receives a data channel close indication (due to inband 718 SCTP SSN reset or some other reason) without associated SDP offer 719 then the client SHOULD generate an SDP offer which excludes this 720 closed data channel. 722 The application MUST also close any data channel that was negotiated 723 via SDP offer/answer, for which the stream identifiers are not listed 724 in an incoming SDP offer. 726 A closed data channel using local close (SCTP SSN reset), without an 727 additional SDP offer/answer to close it, may be reused for a new data 728 channel. This can only be done via new SDP offer/answer, describing 729 the new subprotocol and its attributes, only after the corresponding 730 data channel close acknowledgement is received from the peer (i.e. 731 SCTP SSN reset of both incoming and outgoing streams is completed). 732 This restriction is to avoid the race conditions between arrival of 733 "SDP offer which reuses stream" with "SCTP SSN reset which closes 734 outgoing stream" at the peer. 736 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 738 SDP offer has no "a=dcmap:" attributes. 740 * Initial SDP offer: No data channel is negotiated yet. The DTLS 741 connection and SCTP association is negotiated and, if agreed, 742 established as per [I-D.ietf-mmusic-sctp-sdp]. 744 * Subsequent SDP offer: All the SDP offer/answer negotiated data 745 channels are expected be closed now. The DTLS/SCTP association 746 remains open for SDP offer/answer or DCEP negotiation of data 747 channels. 749 SDP answer has no "a=dcmap:" attributes. 751 * Initial SDP answer: Either the peer does not support "a=dcmap:" 752 attributes or it rejected all the data channels. In either 753 case the offerer closes all the SDP offer/answer negotiated 754 data channels that were open at the time of initial offer. The 755 DTLS connection and SCTP association will still be setup. 757 * Subsequent SDP answer: All the SDP offer/answer negotiated data 758 channels are expected be closed now. The DTLS/SCTP association 759 remains open for future SDP offer/answer or DCEP negotiation of 760 data channels. 762 SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" 763 attributes. 765 * This is considered an error case. In this case the receiver of 766 such an SDP offer or answer SHOULD ignore the "a=dcsa:" 767 attributes and SHOULD process the SDP offer or answer as per 768 above case 'SDP offer has no "a=dcmap:" attributes' or case 769 'SDP answer has no "a=dcmap:" attributes'. 771 SDP offer has no "a=dcsa:" attributes for a data channel. 773 * This is allowed and indicates there are no subprotocol 774 parameters to convey. 776 SDP answer has no "a=dcsa:" attributes for a data channel. 778 * This is allowed and indicates there are no subprotocol 779 parameters to convey in the SDP answer. The number of 780 "a=dcsa:" attributes in the SDP answer does not have to match 781 the number of "a=dcsa:" attributes in the SDP offer. 783 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 784 attribute is unknown. 786 * The receiver of such an SDP offer or answer SHOULD ignore this 787 entire "a=dcsa" attribute line. 789 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 790 attribute is known, but whose subprotocol attribute semantic is 791 not known for the data channel transport case. 793 * The receiver of such an SDP offer or answer SHOULD ignore this 794 entire "a=dcsa" attribute line. 796 6. Examples 797 SDP offer: 798 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 799 c=IN IP4 10.10.10.1 800 a=max-message-size:100000 801 a=sctp-port:5000 802 a=setup:actpass 803 a=connection:new 804 a=fingerprint:SHA-1 \ 805 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 806 a=dcmap:0 subprotocol="BFCP";label="BFCP" 808 SDP answer: 809 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 810 c=IN IP4 10.10.10.2 811 a=max-message-size:100000 812 a=sctp-port:5002 813 a=setup:passive 814 a=connection:new 815 a=fingerprint:SHA-1 \ 816 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 818 Figure 1: Example 1 820 In the above example the SDP answerer rejected the data channel with 821 stream id 0 either for explicit reasons or because it does not 822 understand the "a=dcmap:" attribute. As a result the offerer will 823 close the data channel created with the SDP offer/answer negotiation 824 option. The SCTP association will still be setup over DTLS. At this 825 point the offerer or the answerer may use DCEP negotiation to open 826 data channels. 828 SDP offer: 829 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 830 c=IN IP4 10.10.10.1 831 a=max-message-size:100000 832 a=sctp-port:5000 833 a=setup:actpass 834 a=connection:new 835 a=fingerprint:SHA-1 \ 836 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 837 a=dcmap:0 subprotocol="BFCP";label="BFCP" 838 a=dcmap:2 subprotocol="MSRP";label="MSRP" 839 a=dcsa:2 accept-types:message/cpim text/plain 840 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 842 SDP answer: 843 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 844 c=IN IP4 10.10.10.2 845 a=max-message-size:100000 846 a=sctp-port:5002 847 a=setup:passive 848 a=connection:new 849 a=fingerprint:SHA-1 \ 850 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 851 a=dcmap:2 subprotocol="MSRP";label="MSRP" 852 a=dcsa:2 accept-types:message/cpim text/plain 853 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 855 Figure 2: Example 2 857 In the above example the SDP offer contains data channels for BFCP 858 (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 859 answer rejected BFCP and accepted MSRP. So, the offerer closes the 860 data channel for BFCP and both offerer and answerer may start using 861 the MSRP data channel (after SCTP/DTLS association is setup). The 862 data channel with stream id 0 is free and can be used for future DCEP 863 or SDP offer/answer negotiation. 865 Continuing the example in Figure 2. 867 Subsequent SDP offer: 868 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 869 c=IN IP4 10.10.10.1 870 a=max-message-size:100000 871 a=sctp-port:5000 872 a=setup:actpass 873 a=connection:existing 874 a=fingerprint:SHA-1 \ 875 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 876 a=dcmap:4 subprotocol="MSRP";label="MSRP" 877 a=dcsa:4 accept-types:message/cpim text/plain 878 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 880 Subsequent SDP answer: 881 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 882 c=IN IP4 10.10.10.2 883 a=max-message-size:100000 884 a=sctp-port:5002 885 a=setup:passive 886 a=connection:existing 887 a=fingerprint:SHA-1 \ 888 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 889 a=dcmap:4 subprotocol="MSRP";label="MSRP" 890 a=dcsa:4 accept-types:message/cpim text/plain 891 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 893 Figure 3: Example 3 895 The above example is a continuation of the example in Figure 2. The 896 SDP offer now removes the MSRP data channel with stream id 2, but 897 opens a new MSRP data channel with stream id 4. The answerer accepts 898 the entire offer. As a result the offerer closes the earlier 899 negotiated MSRP related data channel and both offerer and answerer 900 may start using new the MSRP related data channel. 902 7. Security Considerations 904 No security considerations are envisaged beyond those already 905 documented in [RFC4566]. 907 8. IANA Considerations 909 8.1. Subprotocol Identifiers 911 Registration of new subprotocol identifiers is performed using the 912 existing IANA "WebSocket Subprotocol Name Registry" table. 914 The following text should be added following the title of the table. 916 "This table also includes subprotocol identifiers specified for usage 917 within a WebRTC data channel." 919 The following reference should be added to under the heading 920 reference: "RFC XXXX". 922 This document assigns no new values to this table. 924 A subprotocol may simultaneously be defined for data channel 925 transport and for Websocket transport. In such a case the 926 "Subprotocol Definition" and "Reference" cells in the subprotocol's 927 row of the IANA "WebSocket Subprotocol Name Registry" table should 928 contain two entries. One entry in each of these cells should refer 929 to the Websocket related subprotocol specification, and the other 930 entry should refer to the data channel related subprotocol 931 specification. 933 NOTE to RFC Editor: Please replace "XXXX" with the number of this 934 RFC. 936 8.2. New SDP Attributes 938 8.2.1. dcmap 940 NOTE to RFC Editor: Please replace "XXXX" with the number of this 941 RFC. 943 This document defines a new SDP media-level attribute "a=dcmap:" as 944 follows: 946 +---------------------+-----------------------------------------+ 947 | Attribute name: | dcmap | 948 | Type of attribute: | media | 949 | Mux category: | SPECIAL | 950 | Charset Dependent: | No | 951 | Purpose: | Define data channel specific parameters | 952 | Appropriate values: | As defined in Section 5.1.1 | 953 | Contact name: | MMUSIC Chairs | 954 | Contact e-mail: | mmusic-chairs@ietf.org | 955 | Reference: | RFCXXXX | 956 +---------------------+-----------------------------------------+ 958 8.2.2. dcsa 960 NOTE to RFC Editor: Please replace "XXXX" with the number of this 961 RFC. 963 This document defines a new SDP media-level attribute "a=dcsa:" as 964 follows: 966 +---------------------+---------------------------------------------+ 967 | Attribute name: | dcsa | 968 | Type of attribute: | media | 969 | Mux category: | SPECIAL | 970 | Charset Dependent: | No | 971 | Purpose: | Define data channel subprotocol specific | 972 | | attributes | 973 | Appropriate values: | As defined in Section 5.1.2.1 | 974 | Contact name: | MMUSIC Chairs | 975 | Contact e-mail: | mmusic-chairs@ietf.org | 976 | Reference: | RFCXXXX | 977 +---------------------+---------------------------------------------+ 979 9. Acknowledgments 981 The authors wish to acknowledge the borrowing of ideas from other 982 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 983 and Gavin Llewellyn, and to thank Roni Even, Christian Groves, Gunnar 984 Hellstrom, Christer Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe 985 Rauschenbach for their invaluable comments. 987 10. CHANGE LOG 989 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 991 o Addition of two new paragraphs to Section 5.1.2.1 regarding 992 subprotocol attribute relationship with transport protocol. 994 o Addition of a note to Section 8.1 regarding subprotocols 995 simultaneously defined for data channel and Websocket usage. 997 o Addition of two further SDP offer/answer considerations to 998 Section 5.2.5 regarding unknown subprotocol attributes and known 999 subprotocol attributes with unknown data channel transport related 1000 semantic. 1002 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1004 o Changes addressing Christian Groves's WGLC review comments raised 1005 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1006 msg15357.html and http://www.ietf.org/mail- 1007 archive/web/mmusic/current/msg15359.html. 1009 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1011 o In IANA registration Section 8.2.1 and Section 8.2.2 replacement 1012 of contact name and e-mail address with "MMUSIC Chairs" and 1013 "mmusic-chairs@ietf.org". 1015 o In Section 5.1.2.1 replacement of "Thus in the example above, the 1016 original attribute line "a=accept- types:text/plain" is 1017 represented by the attribute line "a=dcsa:2 accept-types:text/ 1018 plain", which specifies that this instance of MSRP being 1019 transported on the SCTP association using the data channel with 1020 stream id 2 accepts plain text files." with "... which specifies 1021 that this instance of the MSRP subprotocol being transported ...". 1023 o The last paragraph of Section 5.1.2.1 started with "Note: This 1024 document does not provide a complete specification ...". Removal 1025 of "Note:" and move of this paragraph to the introduction in 1026 Section 1 as last paragraph. 1028 o Section 5.1.2's headline was "Subprotocol Specific Attributes". 1029 Change of this headline to "Other Media Level Attributes" and 1030 adaptations of the first paragraph of this section and the first 1031 paragraph of Section 5.1.2.1 in order to clarify that not only 1032 those attributes may be encapsulated in a "dcsa" attribute, which 1033 are specifically defined for the subprotocol, but that also other 1034 attributes may be encapsulated if they are related to the specific 1035 subprotocol instance. 1037 o Move of the last but one paragraph of Section 5.1.2.1 starting 1038 with "The same syntax applies to ..." right in front of the formal 1039 syntax definition of the "dcsa" attribute. 1041 o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 1042 in order not to explicitly restrict usage of the "a=dcmap:" and 1043 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1044 SCTP" or "TCP/DTLS/SCTP". 1046 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1048 o In Section 5.1.1.5 the first (and only) paragraph was "The 1049 'subprotocol' parameter indicates which protocol the client 1050 expects to exchange via the channel. 'Subprotocol' is an optional 1051 parameter. If the 'subprotocol' parameter is not present, then 1052 its value defaults to the empty string." Replacement of this 1053 paragraph with following two paragraphs: 1055 * The 'subprotocol' parameter indicates which protocol the client 1056 expects to exchange via the channel. This parameter maps to 1057 the 'Protocol' parameter defined in 1058 [I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new 1059 subprotocol parameter values are registered. 'Subprotocol' is 1060 an optional parameter. If the 'subprotocol' parameter is not 1061 present, then its value defaults to the empty string. 1063 * Note: The empty string MAY also be explicitly used as 1064 'subprotocol' value, such that 'subprotocol=""' is equivalent 1065 to the 'subprotocol' parameter not being present at all. 1066 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1067 message's 'Subprotocol' value to be an empty string. 1069 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1070 normative references. 1072 o Addition of dcmap attribute specific IANA registration 1073 Section 8.2.1. 1075 o Addition of dcsa attribute specific IANA registration 1076 Section 8.2.2. 1078 o Addition of new Section 5.1.1.2 describing the mux category of the 1079 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1080 related mux category section are similar to the "Mux Category" 1081 sections of the "a=sctp-port:" and "a=max-message-size:" 1082 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1084 o Addition of new Section 5.1.2.2 describing the mux category of the 1085 dcsa SDP attribute. 1087 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1089 o In Section 1 replacement of "RTCWeb leaves it open for other 1090 applications to use data channels and its in-band DCEP or out-of- 1091 band non-DCEP protocols for creating them" with "... to use data 1092 channels and its in-band DCEP or other in-band or out-of-band 1093 protocols for creating them". Additionally replacement of "In 1094 particular, the SDP offer generated by the application includes no 1095 channel-specific information" with "... generated by the RTCweb 1096 data channel stack includes no channel-specific information". 1098 o Move of former section 5 ("Data Channels") to new Appendix A and 1099 removal of JavaScript API specific discussions from this moved 1100 text (like mentioning of data channel stack specific states). 1101 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1102 Section 5. 1104 o In Section 5: 1106 * Relacement of Section 5's first paragraph "This section defines 1107 a method of non-DCEP negotiation by which two clients can 1108 negotiate data channel-specific and subprotocol-specific 1109 parameters, using the out-of-band SDP offer/answer exchange. 1110 This SDP extension can only be used with the SDP offer/answer 1111 model." with "This section defines an SDP extension by which 1112 two clients can negotiate data channel-specific and 1113 subprotocol-specific parameters without using DCEP 1114 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1115 defines usage in the context of SDP offer/answer." 1117 * Addition of new paragraph: "Appendix A provides information how 1118 data channels work in general and especially summarizes some 1119 key aspects, which should be considered for the negotiation of 1120 data channels if DCEP is not used." 1122 o In Section 5.1.1 replacement of "The intention of exchanging these 1123 attributes is to create data channels on both the peers with the 1124 same set of attributes without actually using the DCEP 1125 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1126 these attributes is to create, on two peers, without use of DCEP 1127 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1128 directed data channels having the same set of attributes". 1130 o In Section 5.1.1.6 replacement of "The 'max-retr' parameter 1131 indicates the maximal number a user message will be retransmitted" 1132 with "The 'max-retr' parameter indicates the maximal number of 1133 times a user message will be retransmitted". 1135 o In Section 5.2.1 replacement of "However, an SDP offer/answer 1136 exchange MUST NOT be initiated if the associated SCTP stream is 1137 already negotiated via DCEP" with "However, an SCTP stream MUST 1138 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1139 answer exchange if the associated SCTP stream has already been 1140 negotiated via DCEP". 1142 o In the examples in Section 6 addition of the previously missing 1143 colons to the "a=sctp-port" attribute lines. 1145 10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1147 o Move of reference [I-D.ietf-rtcweb-jsep] from the list of 1148 normative references to the list of informative references. 1150 o Addition of [IANA-SDP-Parameters] to the list of informative 1151 references and addition of following two sentences to the first 1152 paragraph after the ABNF definition: "Note however that not all 1153 SDP attributes are suitable as "a=dcsa:" parameter. 1155 [IANA-SDP-Parameters] contains the lists of IANA registered 1156 session and media level or media level only SDP attributes." 1158 o In the introduction replacement of last sentence "This document 1159 defines SDP-based out-of-band negotiation procedures to establish 1160 data channels for transport of well-defined subprotocols" with 1161 "This document defines SDP offer/answer negotiation procedures to 1162 establish data channels for transport of well-defined 1163 subprotocols, to enable out-of-band negotiation". 1165 o Throughout the document replacement of "external negotiation" with 1166 "SDP offer/answer negotiation" and removal of term "external 1167 negotiation" from the terminology list in Section 3. 1169 o Throughout the document replacement of "internal negotiation" with 1170 "DCEP" and removal of terms "internal negotiation" and "in-band 1171 negotiation" from the terminology list in Section 3. 1173 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1174 terms. 1176 o In Section 5.2.1 replacement of sentence "However, a single stream 1177 is managed using one method at a time." with "However, an SDP 1178 offer/answer exchange MUST NOT be initiated if the associated SCTP 1179 stream is already negotiated via DCEP". 1181 o In Section 5.2.2 replacement of sentence "By definition max-retr 1182 and max-time are mutually exclusive, so only one of them can be 1183 present in a=dcmap" with "By definition max-retr and max-time are 1184 mutually exclusive, so at most one of them MAY be present in 1185 a=dcmap". 1187 o Move of reference [WebRtcAPI] from list of normative references to 1188 list of informative references. 1190 o Removal of almost all text parts, which discussed JavaScript or 1191 other API specific aspects. Such API specific aspects were mainly 1192 discussed in sub-sections of Section 5 and Section 5 of draft- 1193 ietf-mmusic-data-channel-sdpneg-02. 1195 10.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1197 o New Section 4 regarding applicability to SDP offer/answer only. 1199 o Addition of new Section 8.1 "Subprotocol identifiers" as 1200 subsection of the "IANA Considerations" related Section 8. Also 1201 removal of the temporary note "To be completed. As [I-D.ietf- 1202 rtcweb-data-protocol] this document should refer to IANA's 1203 WebSocket Subprotocol Name Registry defined in [RFC6455]." 1205 o In Section 5.2.2: 1207 * In the first paragraph replacement of the sentence "If an SDP 1208 offer contains both of these parameters then such an SDP offer 1209 will be rejected." with "If an SDP offer contains both of these 1210 parameters then the receiver of such an SDP offer MUST reject 1211 the SDP offer." 1213 * In the second paragraph capitalization of "shall" and "may" 1214 such that both sentences now read: "The SDP answer SHALL echo 1215 the same subprotocol, max-retr, max-time, ordered parameters, 1216 if those were present in the offer, and MAY include a label 1217 parameter. They MAY appear in any order, which could be 1218 different from the SDP offer, in the SDP answer." 1220 * In the third paragraph replacement of the sentence "The same 1221 information MUST be replicated without changes in any 1222 subsequent offer or answer, as long as the data channel is 1223 still opened at the time of offer or answer generation." with 1224 "When sending a subsequent offer or an answer, and for as long 1225 as the data channel is still open, the sender MUST replicate 1226 the same information.". 1228 o In Section 5.2.2 the mapping of data channel types defined in 1229 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1230 parameters were illustrated using example "a=dcmap" attribute 1231 lines. Replacement of these example "a=dcmap" attribute lines 1232 with just the "a=dcmap" attribute parameters being relevant for 1233 the channel type. 1235 o In Section 5.2.5 the description of bullet point "SDP offer has no 1236 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1237 No data channel negotiated yet." Replacement of this description 1238 with "Initial SDP offer: No data channel is negotiated yet. The 1239 DTLS connection and SCTP association is negotiated and, if agreed, 1240 established as per [I-D.ietf-mmusic-sctp-sdp]." 1242 o In Section 5.2.5 in both bullet points related to "Subsequent SDP 1243 offer" and "Subsequent SDP answer" replacement of "All the 1244 externally negotiated data channels must be closed now." with "All 1245 the externally negotiated data channels are expected be closed 1246 now.". 1248 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1249 replacement of the two occurrences of "must" with "MUST". 1251 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1252 there was a comment saying that "Either only maxretr-opt or 1253 maxtime-opt is present. Both MUST not be present." Removal of 1254 the second normative sentence and instead addition of following 1255 new paragraph to the end of this section: "Within an 'a=dcmap' 1256 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1257 parameter or one 'maxtime-opt' parameter is present. Both MUST 1258 NOT be present." 1260 o In Section 5.1.1.8 replacement of the first sentence "The 1261 'ordered' parameter with value "true" indicates that DATA chunks 1262 in the channel MUST be dispatched to the upper layer by the 1263 receiver while preserving the order." with "The 'ordered' 1264 parameter with value "true" indicates that the receiver MUST 1265 dispatch DATA chunks in the data channel to the upper layer while 1266 preserving the order.". 1268 o In Section 5.2.3's first paragraph replacement of the one 1269 occurrence of "must" with "..., it MUST wait until ...". 1271 o In Section 5.2.4: 1273 * In the second paragraph replacement of "must" with "... whether 1274 this closing MUST in addition ..." 1276 * In the third paragraph replacement of the sentence "The port 1277 value for the "m" line SHOULD not be changed (e.g., to zero) 1278 when closing a data channel ..." with "The offerer SHOULD NOT 1279 change the port value for the "m" line (e.g., to zero) when 1280 closing a data channel ...". 1282 * In the last but two paragraph replacement of the sentence "... 1283 then an SDP offer which excludes this closed data channel 1284 SHOULD be generated." with "... then the client SHOULD generate 1285 an SDP offer which excludes this closed data channel.". 1287 * In the last but one paragraph replacement of "must" with "The 1288 application MUST also close...". 1290 o In Section 5.1.2 addition of following note after the formal 1291 definition of the 'a=dcsa' attribute: "Note that the above 1292 reference to RFC 4566 defines were the attribute definition can be 1293 found; it does not provide any limitation on support of attributes 1294 defined in other documents in accordance with this attribute 1295 definition." 1297 10.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1299 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1300 channel consisting of paired SCTP outbound and inbound streams." 1301 Replacement of this definition with "Data channel: A WebRTC data 1302 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1303 consistent usage of "data channel" in the remainder of the 1304 document including the document's headline." 1306 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1307 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1308 In particular we expect "webrtc-datachannel" to become a more 1309 general term.' 1311 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1313 o In Section 5.1.1 removal of the example dcmap attribute line 1314 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1315 already four examples right after the ABNF rules in 1316 Section 5.1.1.1. Corresponding removal of following related note: 1317 "Note: This document does not provide a complete specification of 1318 how to negotiate the use of a WebRTC data channel to transport 1319 BFCP. Procedures specific to each subprotocol such as BFCP will 1320 be documented elsewhere. The use of BFCP is only an example of 1321 how the generic procedures described herein might apply to a 1322 specific subprotocol." 1324 o In Section 5.1.1 removal of following note: "Note: This attribute 1325 is derived from attribute "webrtc-DataChannel", which was defined 1326 in old version 03 of the following draft, but which was removed 1327 along with any support for SDP external negotiation in subsequent 1328 versions: [I-D.ietf-mmusic-sctp-sdp]." 1330 o Insertion of following new sentence to the beginning of 1331 Section 5.1.1.1: "dcmap is a media level attribute having 1332 following ABNF syntax:" 1334 o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id 1335 specifying sentence, which previously was placed right before the 1336 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1337 parameter and is noted directly after the "a=dcmap:" attribute's 1338 colon' as this information is part of the ABNF specification. 1340 o In Section 5.1.1.1 modification of the 'ordering-value' values 1341 from "0" or "1" to "true" or "false". Corresponding text 1342 modifications in Section 5.1.1.8. 1344 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1345 to rule name "escaped-char", which was not defined. Instead a 1346 rule with name "escaped" was defined. Renamed that rule's name to 1347 "escaped-char". 1349 o Insertion of a dedicated note right after the "a=dcmap:4" 1350 attribute example in Section 5.1.1.1 regarding the non-printable 1351 "escaped-char" character within the "label" value. 1353 o In Section 5.1.2's second paragraph replacement of "sctp stream 1354 identifier" with "SCTP stream identifier". 1356 o In first paragraph of Section 5.2.1 replacement of first two 1357 sentences 'For the SDP-based external negotiation described in 1358 this document, the initial offerer based "SCTP over DTLS" owns by 1359 convention the even stream identifiers whereas the initial 1360 answerer owns the odd stream identifiers. This ownership is 1361 invariant for the whole lifetime of the signaling session, e.g. it 1362 does not change if the initial answerer sends a new offer to the 1363 initial offerer.' with 'If an SDP offer/answer exchange (could be 1364 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1365 TCP/DTLS/SCTP based media description being accepted, and if this 1366 SDP offer/answer exchange results in the establishment of a new 1367 SCTP association, then the SDP offerer owns the even SCTP stream 1368 ids of this new SCTP association and the answerer owns the odd 1369 SCTP stream identifiers. If this "m" line is removed from the 1370 signaling session (its port number set to zero), and if usage of 1371 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1372 renegotiated later on, then the even and odd SCTP stream 1373 identifier ownership is redetermined as well as described above.' 1375 o In Section 5.2.3 the first action of an SDP answerer, when 1376 receiving an SDP offer, was described as "Applies the SDP offer. 1377 Note that the browser ignores data channel specific attributes in 1378 the SDP." Replacement of these two sentences with "Parses and 1379 applies the SDP offer. Note that the typical parser normally 1380 ignores unknown SDP attributes, which includes data channel 1381 related attributes." 1383 o In Section 5.2.3 the second sentence of the third SDP answerer 1384 action was "Note that the browser is asked to create data channels 1385 with stream identifiers not "owned" by the agent.". Replacement 1386 of this sentence with "Note that the agent is asked to create data 1387 channels with SCTP stream identifiers contained in the SDP offer 1388 if the SDP offer is accepted." 1390 o In Section 5.2.4 the third paragraph began with "A data channel 1391 can be closed by sending a new SDP offer which excludes the dcmap 1392 and dcsa attribute lines for the data channel. The port value for 1393 the m line should not be changed (e.g., to zero) when closing a 1394 data channel (unless all data channels are being closed and the 1395 SCTP association is no longer needed), since this would close the 1396 SCTP association and impact all of the data channels. If the 1397 answerer accepts the SDP offer then it MUST also exclude the 1398 corresponding attribute lines in the answer. ..." Replacement of 1399 this part with "The intention to close a data channel can be 1400 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1401 and "a=dcsa:" attribute lines for the data channel. The port 1402 value for the "m" line SHOULD not be changed (e.g., to zero) when 1403 closing a data channel (unless all data channels are being closed 1404 and the SCTP association is no longer needed), since this would 1405 close the SCTP association and impact all of the data channels. 1406 If the answerer accepts the SDP offer then it MUST close those 1407 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1408 excluded from the received SDP offer, unless those data channels 1409 were already closed, and it MUST also exclude the corresponding 1410 attribute lines in the answer." 1412 o In Section 5.2.4 the hanging text after the third paragraph was 1413 "This delayed close is to handle cases where a successful SDP 1414 answer is not received, in which case the state of session should 1415 be kept per the last successful SDP offer/answer." Replacement of 1416 this sentence with "This delayed closure is RECOMMENDED in order 1417 to handle cases where a successful SDP answer is not received, in 1418 which case the state of the session SHOULD be kept per the last 1419 successful SDP offer/answer." 1421 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1422 Section 5.1.1 contained already procedural descriptions related to 1423 data channel reliability negotiation. Creation of new 1424 Section 5.2.2 and moval of reliability negotiation related text to 1425 this new section. 1427 10.9. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1429 o Removal of note "[ACTION ITEM]" from section "subprotocol 1430 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1431 should refer to IANA's WebSocket Subprotocol Name Registry defined 1432 in [RFC6455]. 1434 o In whole document, replacement of "unreliable" with "partially 1435 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1436 [I-D.ietf-rtcweb-data-protocol] in most places. 1438 o Clarification of the semantic if the "max-retr" parameter is not 1439 present in an a=dcmap attribute line. In section "max-retr 1440 parameter" the sentence "The max-retr parameter is optional with 1441 default value unbounded" was replaced with "The max-retr parameter 1442 is optional. If the max-retr parameter is not present, then the 1443 maximal number of retransmissions is determined as per the generic 1444 SCTP retransmission rules as specified in [RFC4960]". 1446 o Clarification of the semantic if the "max-time" parameter is not 1447 present in an a=dcmap attribute line. In section "max-time 1448 parameter" the sentence "The max-time parameter is optional with 1449 default value unbounded" was replaced with "The max-time parameter 1450 is optional. If the max-time parameter is not present, then the 1451 generic SCTP retransmission timing rules apply as specified in 1452 [RFC4960]". 1454 o In section "label parameter" the sentence "Label is a mandatory 1455 parameter." was removed and following new sentences (including the 1456 note) were added: "The 'label' parameter is optional. If it is 1457 not present, then its value defaults to the empty string. Note: 1458 The empty string may also be explicitly used as 'label' value, 1459 such that 'label=""' is equivalent to the 'label' parameter not 1460 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1461 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1463 o In section "subprotocol parameter" the sentence "Subprotocol is a 1464 mandatory parameter." was replaced with "'Subprotocol' is an 1465 optional parameter. If the 'subprotocol' parameter is not 1466 present, then its value defaults to the empty string." 1468 o In the "Examples" section, in the first two SDP offer examples in 1469 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1470 'label="BFCP"'. 1472 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1473 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1474 replaced with "a=max-message-size" attribute lines, as per draft- 1475 ietf-mmusic-sctp-sdp-12. 1477 10.10. Changes against '-01' 1479 o Formal syntax for dcmap and dcsa attribute lines. 1481 o Making subprotocol as an optional parameter in dcmap. 1483 o Specifying disallowed parameter combinations for max-time and max- 1484 retr. 1486 o Clarifications on WebRTC data channel close procedures. 1488 10.11. Changes against '-00' 1490 o Revisions to identify difference between internal and external 1491 negotiation and their usage. 1493 o Introduction of more generic terminology, e.g. "application" 1494 instead of "browser". 1496 o Clarification of how "max-retr and max-time affect the usage of 1497 unreliable and reliable WebRTC data channels. 1499 o Updates of examples to take into account the SDP syntax changes 1500 introduced with draft-ietf-mmusic-sctp-sdp-07. 1502 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1503 attributes as this is now contained in the a=sctp-port attribute, 1504 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1505 association on top of the DTLS connection. 1507 11. References 1509 11.1. Normative References 1511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1512 Requirement Levels", BCP 14, RFC 2119, 1513 DOI 10.17487/RFC2119, March 1997, 1514 . 1516 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1517 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1518 July 2006, . 1520 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1521 with Session Description Protocol (SDP)", RFC 3264, 1522 DOI 10.17487/RFC3264, June 2002, 1523 . 1525 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1526 Specifications: ABNF", STD 68, RFC 5234, 1527 DOI 10.17487/RFC5234, January 2008, 1528 . 1530 [I-D.ietf-rtcweb-data-channel] 1531 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1532 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1533 progress), January 2015. 1535 [I-D.ietf-mmusic-sctp-sdp] 1536 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1537 Control Transmission Protocol (SCTP)-Based Media Transport 1538 in the Session Description Protocol (SDP)", draft-ietf- 1539 mmusic-sctp-sdp-15 (work in progress), September 2015. 1541 [I-D.ietf-mmusic-sdp-mux-attributes] 1542 Nandakumar, S., "A Framework for SDP Attributes when 1543 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 1544 (work in progress), January 2016. 1546 11.2. Informative References 1548 [I-D.ietf-rtcweb-data-protocol] 1549 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1550 Establishment Protocol", draft-ietf-rtcweb-data- 1551 protocol-09 (work in progress), January 2015. 1553 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1554 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1555 . 1557 [IANA-SDP-Parameters] 1558 "Session Description Protocol (SDP) Parameters", Internet 1559 Assigned Numbers Authority Protocol Assignments Session 1560 Description Protocol (SDP) Parameters, 1561 . 1564 [WebRtcAPI] 1565 Bergkvist, A., Burnett, D., Jennings, C., and A. 1566 Narayanan, "WebRTC 1.0: Real-time Communication Between 1567 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1568 February 2015, 1569 . 1571 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1572 DCEP 1574 This appendix summarizes how data channels work in general and 1575 discusses some key aspects, which should be considered for the out- 1576 of-band negotiation of data channels if DCEP is not used. 1578 A WebRTC application creates a data channel by providing a number of 1579 setup parameters (subprotocol, label, maximal number of 1580 retransmissions, maximal retransmission time, order of delivery, 1581 priority). The application also specifies if it wants to make use of 1582 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1583 the application intends to negotiate data channels using the SDP 1584 offer/answer protocol. 1586 In any case, the SDP offer generated by the application is per 1587 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1588 the SCTP association on top of which data channels will run: 1590 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1591 c=IN IP4 79.97.215.79 1592 a=max-message-size:100000 1593 a=sctp-port:5000 1594 a=setup:actpass 1595 a=connection:new 1596 a=fingerprint:SHA-1 \ 1597 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1599 Note: A WebRTC application will only use "m" line format "webrtc- 1600 datachannel", and will not use other formats in the "m" line for 1601 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1602 only one SCTP association to be established on top of a DTLS 1603 association. 1605 Note: The above SDP media description does not contain any channel- 1606 specific information. 1608 A.1. Stream Identifier Numbering 1610 Independently from the requested type of negotiation, the application 1611 creating a data channel can either pass to the data channel stack the 1612 stream identifier to assign to the data channel or else let the data 1613 channel stack pick one identifier from the unused ones. 1615 To avoid glare situations, each endpoint can moreover own an 1616 exclusive set of stream identifiers, in which case an endpoint can 1617 only create a data channel with a stream identifier it owns. 1619 Which set of stream identifiers is owned by which endpoint is 1620 determined by convention or other means. 1622 For data channels negotiated with the DCEP, one endpoint owns by 1623 convention the even stream identifiers, whereas the other owns the 1624 odd stream identifiers, as defined in 1625 [I-D.ietf-rtcweb-data-protocol]. 1627 For data channels negotiated via some protocol different from 1628 DCEP, no convention is defined by default. 1630 A.2. Generic Data Channel Negotiation Not Using DCEP 1632 A.2.1. Overview 1634 DCEP negotiation only provides for negotiation of data channel 1635 transport parameters and does not provide for negotiation of 1636 subprotocol specific parameters. DCEP-less data channel negotiation 1637 can be defined to allow negotiation of parameters beyond those 1638 handled by DCEP, e.g., parameters specific to the subprotocol 1639 instantiated on a particular data channel. 1641 The following procedures are common to all methods of data channel 1642 negotiation not using DCEP, whether in-band (communicated using 1643 proprietary means on an already established data channel) or out-of- 1644 band (using SDP offer/answer or some other protocol associated with 1645 the signaling channel). 1647 A.2.2. Opening a Data Channel 1649 In the case of DCEP-less negotiation, the endpoint application has 1650 the option to fully control the stream identifier assignments. 1651 However these assignments have to coexist with the assignments 1652 controlled by the data channel stack for the DCEP negotiated data 1653 channels (if any). It is the responsibility of the application to 1654 ensure consistent assignment of stream identifiers. 1656 When the application requests the creation of a new data channel to 1657 be set up via DCEP-less negotiation, the data channel stack creates 1658 the data channel locally without sending any DATA_CHANNEL_OPEN 1659 message in-band. However, even if the ICE (Interactive Connectivity 1660 Establishment), DTLS and SCTP procedures were already successfully 1661 completed, the application can't send data on this data channel until 1662 the negotiation is complete with the peer. This is because the peer 1663 needs to be aware of and accept the usage of this data channel. The 1664 peer, after accepting the data channel offer, can start sending data 1665 immediately. This implies that the offerer may receive data channel 1666 subprotocol messages before the negotiation is complete and the 1667 application should be ready to handle it. 1669 If the peer rejects the data channel part of the offer then it 1670 doesn't have to do anything as the data channel was not created using 1671 the stack. The offerer on the other hand needs to close the data 1672 channel that was opened by invoking relevant data channel stack API 1673 procedures. 1675 It is also worth noting that a data channel stack implementation may 1676 not provide any API to create and close data channels; instead the 1677 data channels may be used on the fly as needed just by communicating 1678 via non-DCEP means or by even having some local configuration/ 1679 assumptions on both the peers. 1681 The application then negotiates the data channel properties and 1682 subprotocol properties with the peer's application using a mechanism 1683 different from DCEP. 1685 The peer then symmetrically creates a data channel with these 1686 negotiated data channel properties. This is the only way for the 1687 peer's data channel stack to know which properties to apply when 1688 transmitting data on this channel. The data channel stack must allow 1689 data channel creation with any non-conflicting stream identifier so 1690 that both peers can create the data channel with the same stream 1691 identifier. 1693 A.2.3. Closing a Data Channel 1695 When the application requests the closing of a data channel 1696 negotiated without DCEP, the data channel stack always performs an 1697 SCTP SSN reset for this channel. 1699 Depending upon the method used for DCEP-less negotiation and the 1700 subprotocol associated with the data channel, the closing might in 1701 addition be signaled to the peer via SDP offer/answer negotiation. 1703 Authors' Addresses 1705 Keith Drage (editor) 1706 Nokia 1707 Quadrant, Stonehill Green, Westlea 1708 Swindon 1709 UK 1711 Email: Keith.Drage@nokia.com 1713 Maridi R. Makaraju (Raju) 1714 Nokia 1715 2000 Lucent Lane 1716 Naperville, Illinois 1717 US 1719 Email: Raju.Makaraju@nokia.com 1720 Juergen Stoetzer-Bradler 1721 Nokia 1722 Lorenzstrasse 10 1723 D-70435 Stuttgart 1724 Germany 1726 Email: Juergen.Stoetzer-Bradler@nokia.com 1728 Richard Ejzak 1729 Unaffiliated 1731 Email: richard.ejzak@gmail.com 1733 Jerome Marcon 1734 Unaffiliated