idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-09.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 (July 25, 2016) is 2831 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 1205, but not defined == Missing Reference: 'RFC6455' is mentioned on line 1489, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-37) exists of draft-ietf-mmusic-rfc4566bis-17 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-16 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-13 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 10 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: January 26, 2017 Nokia 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 July 25, 2016 11 SDP-based Data Channel Negotiation 12 draft-ietf-mmusic-data-channel-sdpneg-09 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 January 26, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6 74 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 6 75 5.1.1.2. dcmap Multiplexing Category . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . 10 83 5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10 84 5.1.2.1. dcsa Attribute . . . . . . . . . . . . . . . . . 10 85 5.1.2.2. dcsa Multiplexing Category . . . . . . . . . . . 12 86 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12 88 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 13 89 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 14 90 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 16 91 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 17 92 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 99 8.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 101 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 10.1. Changes against 'draft-ietf-mmusic-data-channel- 103 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 104 10.2. Changes against 'draft-ietf-mmusic-data-channel- 105 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23 106 10.3. Changes against 'draft-ietf-mmusic-data-channel- 107 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23 108 10.4. Changes against 'draft-ietf-mmusic-data-channel- 109 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23 110 10.5. Changes against 'draft-ietf-mmusic-data-channel- 111 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24 112 10.6. Changes against 'draft-ietf-mmusic-data-channel- 113 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25 114 10.7. Changes against 'draft-ietf-mmusic-data-channel- 115 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26 116 10.8. Changes against 'draft-ietf-mmusic-data-channel- 117 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27 118 10.9. Changes against 'draft-ietf-mmusic-data-channel- 119 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29 120 10.10. Changes against 'draft-ejzak-mmusic-data-channel- 121 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32 122 10.11. Changes against '-01' . . . . . . . . . . . . . . . . . 33 123 10.12. Changes against '-00' . . . . . . . . . . . . . . . . . 33 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 125 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 126 11.2. Informative References . . . . . . . . . . . . . . . . . 35 127 Appendix A. Generic Data Channel Negotiation Aspects When Not 128 Using DCEP . . . . . . . . . . . . . . . . . . . . . 35 129 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 36 130 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37 131 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 132 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 133 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 136 1. Introduction 138 The RTCWeb working group has defined the concept of bi-directional 139 data channels running on top of SCTP/DTLS (SCTP over the Datagram 140 Transport Layer Security protocol). RTCWeb allows applications to 141 use data channels. RTCWeb defines an in-band DCEP, however other in- 142 band or out-of-band protocols may be used for establishing data 143 channels. Each data channel consists of paired SCTP streams sharing 144 the same SCTP Stream Identifier. Data channels are created by 145 endpoint applications through the WebRTC API (Application Programming 146 Interface), or other users of a data channel like CLUE. They can be 147 used to transport proprietary or well-defined protocols, which in the 148 latter case can be signaled by the data channel "subprotocol" 149 parameter, conceptually similar to the WebSocket "subprotocol". 150 However, apart from the "subprotocol" value transmitted to the peer, 151 RTCWeb leaves it open how endpoint applications can agree on how to 152 instantiate a given subprotocol on a data channel, and whether it is 153 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 154 (or both). In particular, the SDP offer generated by the RTCweb data 155 channel stack includes no channel-specific information. 157 This document defines SDP offer/answer negotiation procedures to 158 establish data channels for transport of well-defined subprotocols, 159 to enable out-of-band negotiation. 161 This document makes use of MSRP (Message Session Relay Protocol) in 162 many of the examples. It does not provide a complete specification 163 of how to negotiate the use of a data channel to transport MSRP. 164 Procedures specific to each subprotocol such as MSRP are documented 165 elsewhere. The use of MSRP in some examples is only to show how the 166 generic procedures described herein might apply to a specific 167 subprotocol. 169 2. Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 3. Terminology 177 This document uses the following terms: 179 Data channel: A WebRTC data channel as specified in 180 [I-D.ietf-rtcweb-data-channel]. 182 Data channel stack: An entity which, upon application request, 183 runs the data channel protocol to keep track of states, sending 184 and receive data. If the application is a browser based 185 JavaScript application then this stack resides in the browser. If 186 the application is a native application then this stack resides in 187 the application and is accessible via some sort of APIs. 189 Data channel properties: Fixed properties assigned to a data 190 channel at the time of its creation. Some of these properties 191 determine the way the data channel stack transmits data on this 192 channel (e.g., stream identifier, reliability, order of 193 delivery...). 195 Data channel subprotocol: The application protocol which is 196 transported over a single data channel. Data channel subprotocol 197 messages are sent as data channel payload over an established data 198 channel. If an SDP offer/answer exchange is used as specified in 199 this document to negotiate the establishment of data channels, 200 corresponding data channel properties, associated data channel 201 subprotocols and data channel subprotocol properties, then the 202 data channel subprotocols may be identified by the values of the 203 "subprotocol" parameters of the SDP "a=dcmap" attribute as 204 described in Section 5.1.1.5. Within this document the term "data 205 channel subprotocol" is often abbreviated as just "subprotocol". 207 DCEP: Data Channel Establishment Protocol defined in 208 [I-D.ietf-rtcweb-data-protocol]. 210 In-band: Transmission through the peer-to-peer SCTP association. 212 Out-of-band: Transmission through the application signaling path. 214 Peer: From the perspective of one of the agents in a session, its 215 peer is the other agent. Specifically, from the perspective of 216 the SDP offerer, the peer is the SDP answerer. From the 217 perspective of the SDP answerer, the peer is the SDP offerer. 219 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 220 as specified in [RFC4960]. 222 Stream identifier: The identifier of the outbound and inbound SCTP 223 streams composing a data channel. 225 4. Applicability Statement 227 The mechanism in this document only applies to the Session 228 Description Protocol (SDP) [RFC4566], when used together with the SDP 229 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 230 scope of this document, and is thus undefined. 232 5. SDP Offer/Answer Negotiation 234 This section defines an SDP extension by which two clients can 235 negotiate data channel-specific and subprotocol-specific parameters 236 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 237 extension only defines usage in the context of SDP offer/answer. 239 Appendix A provides information how data channels work in general and 240 especially summarizes some key aspects, which should be considered 241 for the negotiation of data channels if DCEP is not used. 243 5.1. SDP Syntax 245 Two new SDP attributes are defined to support SDP offer/answer 246 negotiation of data channels. The first attribute provides for 247 negotiation of channel-specific parameters. The second attribute 248 provides for negotiation of subprotocol-specific parameters. 250 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 252 Associated with the SDP "m" line that defines the SCTP association 253 for data channels (defined in Section 3), each SDP offer and answer 254 includes one "a=dcmap:" attribute that defines the data channel 255 parameters for each data channel to be negotiated. Each such 256 attribute line specifies the following parameters for a data channel: 257 SCTP stream identifier, subprotocol, label, maximal number of 258 retransmissions, maximal retransmission time, order of delivery, and 259 priority. 261 The intention in exchanging these attributes is to create, on two 262 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 263 pairs of oppositely directed data channels having the same set of 264 attributes. It is assumed that the data channel properties 265 (reliable/partially reliable, ordered/unordered) are suitable per the 266 subprotocol transport requirements. 268 5.1.1.1. dcmap Attribute 270 "a=dcmap:" is a media level attribute having following ABNF 271 (Augmented Backus-Naur Form, [RFC5234]) syntax. 273 Formal Syntax: 275 Name: dcmap 277 Value: dcmap-value 279 Usage Level: media 281 Charset Dependent: no 283 Syntax: 285 dcmap-value = dcmap-stream-id 286 [ SP dcmap-opt *(";" dcmap-opt) ] 288 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 289 / maxretr-opt / maxtime-opt / priority-opt 290 ; Either only maxretr-opt or maxtime-opt 291 ; is present. 293 dcmap-stream-id = 1*DIGIT 294 ordering-opt = "ordered=" ordering-value 295 ordering-value = "true" / "false" 296 subprotocol-opt = "subprotocol=" quoted-string 297 label-opt = "label=" quoted-string 298 maxretr-opt = "max-retr=" maxretr-value 299 maxretr-value = "0" / integer 300 ; number of retransmissions, 301 ; less than 2^32, 302 ; derived from 'Reliability Parameter' of 303 ; [I-D.ietf-rtcweb-data-protocol] 304 maxtime-opt = "max-time=" maxtime-value 305 maxtime-value = "0" / integer 306 ; milliseconds, 307 ; less than 2^32, 308 ; derived from 'Reliability Parameter' of 309 ; [I-D.ietf-rtcweb-data-protocol] 310 priority-opt = "priority=" priority-value 311 priority-value = "0" / integer 312 ; unsigned integer value indicating the priority of 313 ; the data channel, 314 ; less than 2^16, 315 ; derived from 'Priority' of 316 ; [I-D.ietf-rtcweb-data-protocol] 318 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 319 quoted-char = SP / quoted-visible 320 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 321 escaped-char = "%" HEXDIG HEXDIG 322 DQUOTE = 323 integer = 325 Examples: 327 a=dcmap:0 328 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 329 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 330 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 331 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 333 Note: The last example (a=dcmap:4) shows a 'label' parameter value 334 which contains one non-printable 'escaped-char' character (the 335 tabulator character). 337 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 338 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 339 present. Both MUST NOT be present. 341 5.1.1.2. dcmap Multiplexing Category 343 Multiplexing characteristics of SDP attributes are described in 344 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 345 multiplexing categories are introduced there. 347 The multiplexing category of the "a=dcmap:" attribute is SPECIAL. 349 As the usage of multiple SCTP associations on top of a single DTLS 350 connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 351 "a=dcmap:" attribute multiplexing rules are specified for the 352 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. This document also 353 does not specify multiplexing rules for this attribute for SCTP or 354 SCTP/DTLS proto values. If future extensions of 355 [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 356 multiple SCTP associations on top of a single DTLS connection, or how 357 to add multiple SCTP associations to one BUNDLE group, then 358 multiplexing rules for the "a=dcmap:" attribute need to be defined as 359 well, for instance in an extension of this SDP based data channel 360 negotiation specification. 362 5.1.1.3. dcmap-stream-id Parameter 364 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 365 within the SCTP association used to form the data channel. 367 5.1.1.4. label Parameter 369 The 'label' parameter indicates the name of the channel. It 370 represents a label that can be used to distinguish, in the context of 371 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 372 RTCDataChannel objects. This parameter maps to the 'Label' parameter 373 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 374 optional. If it is not present, then its value defaults to the empty 375 string. 377 Note: The empty string MAY also be explicitly used as a 'label' 378 value, such that 'label=""' is equivalent to the 'label' parameter 379 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 380 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 382 5.1.1.5. subprotocol Parameter 384 The 'subprotocol' parameter indicates which protocol the client 385 expects to exchange via the channel. This parameter maps to the 386 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 387 Section 8.1 specifies how new subprotocol parameter values are 388 registered. 'Subprotocol' is an optional parameter. If the 389 'subprotocol' parameter is not present, then its value defaults to an 390 empty string. 392 Note: The empty string MAY also be explicitly used as 'subprotocol' 393 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 394 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 395 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 396 empty string. 398 5.1.1.6. max-retr Parameter 400 This parameter indicates that the data channel is partially reliable. 401 The 'max-retr' parameter indicates the maximal number of times a user 402 message will be retransmitted. The max-retr parameter is optional. 403 If the max-retr parameter is not present, then the maximal number of 404 retransmissions is determined as per the generic SCTP retransmission 405 rules as specified in [RFC4960]. This parameter maps to the 'Number 406 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 408 5.1.1.7. max-time Parameter 410 This parameter indicates that the data channel is partially reliable. 411 A user message will no longer be transmitted or retransmitted after a 412 specified life-time given in milliseconds in the 'max-time' 413 parameter. The max-time parameter is optional. If the max-time 414 parameter is not present, then the generic SCTP retransmission timing 415 rules apply as specified in [RFC4960]. This parameter maps to the 416 'Lifetime in ms' parameter defined in 417 [I-D.ietf-rtcweb-data-protocol]. 419 5.1.1.8. ordered Parameter 421 The 'ordered' parameter with value "true" indicates that the receiver 422 MUST dispatch DATA chunks in the data channel to the upper layer 423 while preserving the order. The ordered parameter is optional and 424 takes two values: "true" for ordered and "false" for unordered 425 delivery with "true" as the default value. Any other value is 426 ignored and default "ordered=true" is assumed. In the absence of 427 this parameter "ordered=true" is assumed. This parameter maps to the 428 ordered or unordered data channel types as defined in 429 [I-D.ietf-rtcweb-data-protocol]. 431 5.1.1.9. priority Parameter 433 The 'priority' parameter indicates the data channel's priority 434 relative to the priorities of other data channels, which may 435 additionally exist over the same SCTP association. The 'priority' 436 parameter maps to the 'Priority' parameter defined in 437 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 438 optional. In the absence of this parameter "priority=256" is 439 assumed. 441 5.1.2. Other Media Level Attributes 443 In the SDP, each data channel declaration MAY also be followed by 444 other media level SDP attributes, which are either specifically 445 defined for or applied to the subprotocol in use. Each of these 446 attributes is represented by one new attribute line, and it includes 447 the contents of a media-level SDP attribute already defined for use 448 with this (sub)protocol in another IETF (Internet Engineering Task 449 Force) document. Subprotocol specific attributes MAY also be defined 450 for exclusive use with data channel transport, but MUST use the same 451 syntax described here for other subprotocol related attributes. 453 5.1.2.1. dcsa Attribute 455 Each SDP attribute, related to the subprotocol, that would normally 456 be used to negotiate the subprotocol using SDP is replaced with an 457 attribute of the form "a=dcsa:stream-id original-attribute", where 458 dcsa stands for "data channel subprotocol attribute", stream-id is 459 the SCTP stream identifier assigned to this subprotocol instance, and 460 original-attribute represents the contents of the subprotocol related 461 attribute to be included. 463 The same syntax applies to any other SDP attribute required for 464 negotiation of this instance of the subprotocol. 466 Formal Syntax: 468 Name: dcsa 470 Value: dcsa-value 472 Usage Level: media 474 Charset Dependent: no 476 Syntax: 478 dcsa-value = stream-id SP attribute 479 attribute = 481 Example: 483 a=dcsa:2 accept-types:text/plain 485 Note that the above reference to [RFC4566] defines where the 486 attribute definition can be found; it does not provide any limitation 487 on support of attributes defined in other documents in accordance 488 with this attribute definition. Note however that not all SDP 489 attributes are suitable as a "a=dcsa:" parameter. 490 [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned 491 Numbers Authority) registered session and media level or media level 492 only SDP attributes. 494 Thus in the example above, the original attribute line "a=accept- 495 types:text/plain" is represented by the attribute line "a=dcsa:2 496 accept-types:text/plain", which specifies that this instance of the 497 MSRP subprotocol being transported on the SCTP association using the 498 data channel with stream id 2 accepts plain text files. 500 As opposed to the data channel "a=dcmap:" attribute parameters, these 501 parameters are subject to offer/answer negotiation following the 502 procedures defined in the subprotocol specific documents. 504 It is assumed that in general the usages of subprotocol related media 505 level attributes are independent from the subprotocol's transport 506 protocol. Such transport protocol independent subprotocol related 507 attributes are used in the same way as defined in the original 508 subprotocol specification, also if the subprotocol is transported 509 over a data channel and if the attribute is correspondingly embedded 510 in a "a=dcsa" attribute. 512 There may be cases, where the usage of a subprotocol related media 513 level attribute depends on the subprotocol's transport protocol. In 514 such cases the subprotocol related usage of the attribute is expected 515 to be described for the data channel transport. A data channel 516 specific usage of a subprotocol attribute is expected to be specified 517 in the same document, which registers the subprotocol's identifier 518 for data channel usage as described in Section 8.1. 520 5.1.2.2. dcsa Multiplexing Category 522 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 524 As the usage of multiple SCTP associations on top of a single DTLS 525 connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 526 "a=dcsa:" attribute multiplexing rules are specified for the 527 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. This document does 528 also not specify multiplexing rules for this attribute for SCTP or 529 SCTP/DTLS proto values. If future extensions of 530 [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 531 multiple SCTP associations on top of a single DTLS connection, or how 532 to add multiple SCTP associations to one BUNDLE group, then 533 multiplexing rules for the "a=dcsa:" attribute need to be defined as 534 well, for instance in an extension of this SDP based data channel 535 negotiation specification. 537 5.2. Procedures 539 5.2.1. Managing Stream Identifiers 541 If a SDP offer/answer exchange (could be the initial or a subsequent 542 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 543 description being accepted, and if this SDP offer/answer exchange 544 results in the establishment of a new SCTP association, then the SDP 545 offerer owns the even SCTP stream ids of this new SCTP association 546 and the answerer owns the odd SCTP stream identifiers. If this "m" 547 line is removed from the signaling session (its port number set to 548 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 549 SCTP based "m" line is renegotiated later on, then the even and odd 550 SCTP stream identifier ownership is re-determined as described above. 552 This document allows simultaneous use of SDP offer/answer and DCEP 553 negotiation. However, an SCTP stream MUST NOT be referenced in a 554 "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if 555 the associated SCTP stream has already been negotiated via DCEP. 556 Stream ids that are not currently used in SDP can be used for DCEP 557 negotiation. Stream id allocation per SDP offer/answer negotiation 558 may not align with DTLS role based allocation. This could cause 559 glare conditions when one side tries to do SDP offer/answer 560 negotiation on a stream id while the other end tries to open a data 561 channel on the same stream id using DCEP negotiation. To avoid these 562 glare conditions this document recommends that the data channel stack 563 user always selects stream ids per the above described SDP offer/ 564 answer rule even when DCEP negotiation is used. To avoid glare 565 conditions, it is possible to come up with a different stream id 566 allocation scheme, but such schemes are outside the scope of this 567 document. 569 5.2.2. Negotiating Data Channel Parameters 571 Conveying a reliable data channel is achieved by including neither 572 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 573 "a=dcmap:" attribute line. Conveying a partially reliable data 574 channel is achieved by including only one of 'max-retr' or 'max- 575 time'. By definition max-retr and max-time are mutually exclusive, 576 so at most one of them MAY be present in the "a=dcmap:" attribute 577 line. If a SDP offer contains both of these parameters then the 578 receiver of such an SDP offer MUST reject the SDP offer. If a SDP 579 answer contains both of these parameters then the offerer MAY treat 580 it as an error and MAY assume the associated SDP offer/answer failed 581 and MAY take appropriate recovery actions. These recovery options 582 are outside the scope of this document. 584 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 585 ordered parameters, if those were present in the offer, and MAY 586 include a label parameter. They MAY appear in any order, which could 587 be different from the SDP offer, in the SDP answer. 589 When sending a subsequent offer or an answer, and for as long as the 590 data channel is still open, the sender MUST replicate the same 591 information. 593 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 594 mapped to SDP in the following manner, where "ordered=true" is the 595 default and may be omitted: 597 DATA_CHANNEL_RELIABLE 598 ordered=true 600 DATA_CHANNEL_RELIABLE_UNORDERED 601 ordered=false 603 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 604 ordered=true;max-retr= 606 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 607 ordered=false;max-retr= 609 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 610 ordered=true;max-time= 612 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 613 ordered=false;max-time= 615 5.2.3. Opening a Data Channel 617 The procedure for opening a data channel using SDP offer/answer 618 negotiation starts with the agent preparing to send an SDP offer. If 619 a peer receives an SDP offer before starting to send a new SDP offer 620 with data channels that are to be SDP offer/answer negotiated, or 621 loses an SDP offer glare resolution procedure in this case, it MUST 622 wait until the ongoing SDP offer/answer completes before resuming the 623 SDP offer/answer negotiation procedure. 625 The agent that intends to send an SDP offer to create data channels 626 through SDP offer/answer negotiation performs the following: 628 o Creates data channels using stream identifiers from the owned set 629 (see Section 5.2.1). 631 o Generates a new SDP offer. 633 o Determines the list of stream identifiers assigned to data 634 channels opened through SDP offer/answer negotiation. 636 o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:" 637 attributes needed, if any, for each SDP offer/answer negotiated 638 data channel, as described in Section 5.1 and in Section 5.2.2. 640 o If it adds "a=dcsa" attributes to the SDP offer, then it SHOULD 641 add the subprotocol parameter to the "a=dcmap" attribute with a 642 non-empty subprotocol identifier. 644 o Sends the SDP offer. 646 The peer receiving such an SDP offer performs the following: 648 o Parses and applies the SDP offer, taking into account the 649 considerations discussed in Section 5.2.5. 651 o Analyzes the channel parameters and subprotocol attributes to 652 determine whether to accept each offered data channel. 654 o For accepted data channels, it creates peer instances for the data 655 channels with the agent using the channel parameters described in 656 the SDP offer. Note that the agent is asked to create data 657 channels with SCTP stream identifiers contained in the SDP offer 658 if the SDP offer is accepted. 660 o Generates an SDP answer. 662 o Completes the SDP answer with the "a=dcmap:" and optional 663 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 664 data channel, as described in Section 5.1 and in Section 5.2.2. 666 o Sends the SDP answer. 668 The agent receiving such an SDP answer performs the following: 670 o Closes any created data channels as described in Section 5.2.4 for 671 which the expected "a=dcmap:" and "a=dcsa:" attributes are not 672 present in the SDP answer. 674 o Applies the SDP answer. 676 Each agent application MUST wait to send data until it has 677 confirmation that the data channel at the peer is instantiated. For 678 WebRTC, this is when both data channel stacks have channel parameters 679 instantiated. This occurs: 681 o At both peers when a data channel is created without an 682 established SCTP association, as soon as the SCTP association is 683 successfully established. 685 o At the agent receiving an SDP offer for which there is an 686 established SCTP association, as soon as it creates an SDP offer/ 687 answer negotiated data channel based on information signaled in 688 the SDP offer. 690 o At the agent sending an SDP offer to create a new SDP offer/answer 691 negotiated data channel for which there is an established SCTP 692 association, when it receives the SDP answer confirming acceptance 693 of the data channel or when it begins to receive data on the data 694 channel from the peer, whichever occurs first. 696 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 697 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 699 5.2.4. Closing a Data Channel 701 When the application requests the closing of a data channel that was 702 negotiated via SDP offer/answer, the data channel stack always 703 performs an SCTP SSN reset for this channel. 705 It is specific to the subprotocol whether this closing MUST in 706 addition be signaled to the peer via a new SDP offer/answer exchange. 708 The intention to close a data channel can be signaled by sending a 709 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 710 lines for the data channel. The offerer SHOULD NOT change the port 711 value for the "m" line (e.g. to zero) when closing a data channel 712 (unless all data channels are being closed and the SCTP association 713 is no longer needed), since this would close the SCTP association and 714 impact all of the data channels. If the answerer accepts the SDP 715 offer then the answerer MUST close those data channels whose 716 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 717 received SDP offer, unless those data channels were already closed, 718 and the answerer MUST also exclude the corresponding attribute lines 719 in the answer. In addition to that, the SDP answerer MAY exclude 720 other data channels which were closed but not yet communicated to the 721 peer. So, the offerer MUST inspect the answer to see if it has to 722 close other data channels which are now not included in the answer. 724 If a new SDP offer/answer is used to close data channels then the 725 data channel(s) SHOULD only be closed by the answerer/offerer after a 726 successful SDP answer is sent/received. 728 This delayed closure is RECOMMENDED in order to handle cases where 729 a successful SDP answer is not received, in which case the state 730 of the session SHOULD be kept per the last successful SDP offer/ 731 answer. 733 If a client receives a data channel close indication (due to inband 734 SCTP SSN reset or some other reason) without associated SDP offer 735 then the client SHOULD generate an SDP offer which excludes this 736 closed data channel. 738 The application MUST also close any data channel that was negotiated 739 via SDP offer/answer, for which the stream identifiers are not listed 740 in an incoming SDP offer. 742 A closed data channel using local close (SCTP SSN reset), without an 743 additional SDP offer/answer to close it, may be reused for a new data 744 channel. This can only be done via new SDP offer/answer, describing 745 the new subprotocol and its attributes, only after the corresponding 746 data channel close acknowledgement is received from the peer (i.e. 747 SCTP SSN reset of both incoming and outgoing streams is completed). 748 This restriction is to avoid the race conditions between arrival of 749 "SDP offer which reuses stream" with "SCTP SSN reset which closes 750 outgoing stream" at the peer. 752 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 754 SDP offer has no "a=dcmap:" attributes. 756 * Initial SDP offer: No data channel is negotiated yet. The DTLS 757 connection and SCTP association is negotiated and, if agreed, 758 established as per [I-D.ietf-mmusic-sctp-sdp]. 760 * Subsequent SDP offer: All the SDP offer/answer negotiated data 761 channels are expected be closed now. The DTLS/SCTP association 762 remains open for SDP offer/answer or DCEP negotiation of data 763 channels. 765 SDP answer has no "a=dcmap:" attributes. 767 * Initial SDP answer: Either the peer does not support "a=dcmap:" 768 attributes or it rejected all the data channels. In either 769 case the offerer closes all the SDP offer/answer negotiated 770 data channels that were open at the time of initial offer. The 771 DTLS connection and SCTP association will still be setup. 773 * Subsequent SDP answer: All the SDP offer/answer negotiated data 774 channels are expected be closed now. The DTLS/SCTP association 775 remains open for future SDP offer/answer or DCEP negotiation of 776 data channels. 778 SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" 779 attributes. 781 * This is considered an error case. In this case the receiver of 782 such an SDP offer or answer SHOULD ignore the "a=dcsa:" 783 attributes and SHOULD process the SDP offer or answer as per 784 above case 'SDP offer has no "a=dcmap:" attributes' or case 785 'SDP answer has no "a=dcmap:" attributes'. 787 SDP offer has no "a=dcsa:" attributes for a data channel. 789 * This is allowed and indicates there are no subprotocol 790 parameters to convey. 792 SDP answer has no "a=dcsa:" attributes for a data channel. 794 * This is allowed and indicates there are no subprotocol 795 parameters to convey in the SDP answer. The number of 796 "a=dcsa:" attributes in the SDP answer does not have to match 797 the number of "a=dcsa:" attributes in the SDP offer. 799 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 800 attribute is unknown. 802 * The receiver of such an SDP offer or answer SHOULD ignore this 803 entire "a=dcsa" attribute line. 805 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 806 attribute is known, but whose subprotocol attribute semantic is 807 not known for the data channel transport case. 809 * The receiver of such an SDP offer or answer SHOULD ignore this 810 entire "a=dcsa" attribute line. 812 6. Examples 814 SDP offer: 815 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 816 c=IN IP4 10.10.10.1 817 a=max-message-size:100000 818 a=sctp-port:5000 819 a=setup:actpass 820 a=connection:new 821 a=fingerprint:SHA-1 \ 822 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 823 a=dcmap:0 subprotocol="BFCP";label="BFCP" 825 SDP answer: 826 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 827 c=IN IP4 10.10.10.2 828 a=max-message-size:100000 829 a=sctp-port:5002 830 a=setup:passive 831 a=connection:new 832 a=fingerprint:SHA-1 \ 833 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 835 Figure 1: Example 1 837 In the above example the SDP answerer rejected the data channel with 838 stream id 0 either for explicit reasons or because it does not 839 understand the "a=dcmap:" attribute. As a result the offerer will 840 close the data channel created with the SDP offer/answer negotiation 841 option. The SCTP association will still be setup over DTLS. At this 842 point the offerer or the answerer may use DCEP negotiation to open 843 data channels. 845 SDP offer: 846 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 847 c=IN IP4 10.10.10.1 848 a=max-message-size:100000 849 a=sctp-port:5000 850 a=setup:actpass 851 a=connection:new 852 a=fingerprint:SHA-1 \ 853 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 854 a=dcmap:0 subprotocol="BFCP";label="BFCP" 855 a=dcmap:2 subprotocol="MSRP";label="MSRP" 856 a=dcsa:2 accept-types:message/cpim text/plain 857 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 859 SDP answer: 860 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 861 c=IN IP4 10.10.10.2 862 a=max-message-size:100000 863 a=sctp-port:5002 864 a=setup:passive 865 a=connection:new 866 a=fingerprint:SHA-1 \ 867 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 868 a=dcmap:2 subprotocol="MSRP";label="MSRP" 869 a=dcsa:2 accept-types:message/cpim text/plain 870 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 872 Figure 2: Example 2 874 In the above example the SDP offer contains data channels for BFCP 875 (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 876 answer rejected BFCP and accepted MSRP. So, the offerer closes the 877 data channel for BFCP and both offerer and answerer may start using 878 the MSRP data channel (after SCTP/DTLS association is setup). The 879 data channel with stream id 0 is free and can be used for future DCEP 880 or SDP offer/answer negotiation. 882 Continuing the example in Figure 2. 884 Subsequent SDP offer: 885 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 886 c=IN IP4 10.10.10.1 887 a=max-message-size:100000 888 a=sctp-port:5000 889 a=setup:actpass 890 a=connection:existing 891 a=fingerprint:SHA-1 \ 892 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 893 a=dcmap:4 subprotocol="MSRP";label="MSRP" 894 a=dcsa:4 accept-types:message/cpim text/plain 895 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 897 Subsequent SDP answer: 898 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 899 c=IN IP4 10.10.10.2 900 a=max-message-size:100000 901 a=sctp-port:5002 902 a=setup:passive 903 a=connection:existing 904 a=fingerprint:SHA-1 \ 905 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 906 a=dcmap:4 subprotocol="MSRP";label="MSRP" 907 a=dcsa:4 accept-types:message/cpim text/plain 908 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 910 Figure 3: Example 3 912 The above example is a continuation of the example in Figure 2. The 913 SDP offer now removes the MSRP data channel with stream id 2, but 914 opens a new MSRP data channel with stream id 4. The answerer accepts 915 the entire offer. As a result the offerer closes the earlier 916 negotiated MSRP related data channel and both offerer and answerer 917 may start using new the MSRP related data channel. 919 7. Security Considerations 921 No security considerations are envisaged beyond those already 922 documented in [RFC4566]. 924 8. IANA Considerations 926 8.1. Subprotocol Identifiers 928 Registration of new subprotocol identifiers is performed using the 929 existing IANA "WebSocket Subprotocol Name Registry" table. 931 The following text should be added following the title of the table. 933 "This table also includes subprotocol identifiers specified for usage 934 within a WebRTC data channel." 936 The following reference should be added to under the heading 937 reference: "RFC XXXX". 939 This document assigns no new values to this table. 941 A subprotocol may simultaneously be defined for data channel 942 transport and for Websocket transport. In such a case the 943 "Subprotocol Definition" and "Reference" cells in the subprotocol's 944 row of the IANA "WebSocket Subprotocol Name Registry" table should 945 contain two entries. One entry in each of these cells should refer 946 to the Websocket related subprotocol specification, and the other 947 entry should refer to the data channel related subprotocol 948 specification. 950 NOTE to RFC Editor: Please replace "XXXX" with the number of this 951 RFC. 953 8.2. New SDP Attributes 955 8.2.1. dcmap 957 NOTE to RFC Editor: Please replace "XXXX" with the number of this 958 RFC. 960 This document defines a new SDP media-level attribute "a=dcmap:" as 961 follows: 963 +-----------------------+-------------------------------------------+ 964 | Contact name: | MMUSIC Chairs | 965 | Contact email: | mmusic-chairs@ietf.org | 966 | Attribute name: | dcmap | 967 | Attribute syntax: | As per Section 5.1.1.1 | 968 | Attribute semantics: | As per Section 5.1.1.1 | 969 | Usage level: | media | 970 | Charset dependent: | No | 971 | Purpose: | Define data channel specific parameters | 972 | Appropriate values: | As per Section 5.1.1.1 | 973 | O/A procedures: | As per Section 5.2 | 974 | Mux category: | SPECIAL. See Section 5.1.1.2 | 975 | Reference: | RFCXXXX | 976 +-----------------------+-------------------------------------------+ 978 8.2.2. dcsa 980 NOTE to RFC Editor: Please replace "XXXX" with the number of this 981 RFC. 983 This document defines a new SDP media-level attribute "a=dcsa:" as 984 follows: 986 +-----------------------+-------------------------------------------+ 987 | Contact name: | MMUSIC Chairs | 988 | Contact email: | mmusic-chairs@ietf.org | 989 | Attribute name: | dcsa | 990 | Attribute syntax: | As per Section 5.1.2.1 | 991 | Attribute semantics: | As per Section 5.1.2.1 | 992 | Usage level: | media | 993 | Charset dependent: | No | 994 | Purpose: | Define data channel subprotocol specific | 995 | | attributes | 996 | Appropriate values: | As per Section 5.1.2.1 | 997 | O/A procedures: | As per Section 5.2 | 998 | Mux category: | SPECIAL. See Section 5.1.2.2 | 999 | Reference: | RFCXXXX | 1000 +-----------------------+-------------------------------------------+ 1002 8.3. New Usage Level 1004 This document introduces a new "Data Channel Subprotocol Attribute" 1005 (dcsa) usage level to the SDP to the IANA SDP att-field registry. 1006 SDP attributes that are defined for use at the dcsa usage level only 1007 shall use the dcsa usage level when registering the attribute. If 1008 existing media attributes are used in a datachannel subprotocol 1009 specific way (Section 5.1.2.1), then a new dcsa usage level MUST be 1010 defined for the existing media attribute. Where the SDP attribute is 1011 applicable to a particular subprotocol/s this SHALL also be 1012 registered by indicating the applicable subprotocol identifiers (see 1013 Section 8.1) along with the dcsa usage level. E.g. 1015 +-----------------------+-------------------------------------------+ 1016 | ... | ... | 1017 | Usage level: | dcsa(MSRP) | 1018 | ... | ... | 1019 +-----------------------+-------------------------------------------+ 1021 9. Acknowledgments 1023 The authors wish to acknowledge the borrowing of ideas from other 1024 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 1025 and Gavin Llewellyn, and to thank Flemming Andreasen, Roni Even, 1026 Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, 1027 Jonathan Lennox, and Uwe Rauschenbach for their invaluable comments. 1029 10. CHANGE LOG 1031 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1033 o Addition of definition of "data channel subprotocol" to Section 3 1034 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1035 archive/web/mmusic/current/msg15827.html. 1037 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 1038 references. 1040 o Updates of tables in Section 8.2.1 and Section 8.2.2 as per 1041 section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis]. 1043 o Addition of new Section 8.3. 1045 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1047 o Addition of two new paragraphs to Section 5.1.2.1 regarding 1048 subprotocol attribute relationship with transport protocol. 1050 o Addition of a note to Section 8.1 regarding subprotocols 1051 simultaneously defined for data channel and Websocket usage. 1053 o Addition of two further SDP offer/answer considerations to 1054 Section 5.2.5 regarding unknown subprotocol attributes and known 1055 subprotocol attributes with unknown data channel transport related 1056 semantic. 1058 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1060 o Changes addressing Christian Groves's WGLC review comments raised 1061 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1062 msg15357.html and http://www.ietf.org/mail- 1063 archive/web/mmusic/current/msg15359.html. 1065 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1067 o In IANA registration Section 8.2.1 and Section 8.2.2 replacement 1068 of contact name and e-mail address with "MMUSIC Chairs" and 1069 "mmusic-chairs@ietf.org". 1071 o In Section 5.1.2.1 replacement of "Thus in the example above, the 1072 original attribute line "a=accept- types:text/plain" is 1073 represented by the attribute line "a=dcsa:2 accept-types:text/ 1074 plain", which specifies that this instance of MSRP being 1075 transported on the SCTP association using the data channel with 1076 stream id 2 accepts plain text files." with "... which specifies 1077 that this instance of the MSRP subprotocol being transported ...". 1079 o The last paragraph of Section 5.1.2.1 started with "Note: This 1080 document does not provide a complete specification ...". Removal 1081 of "Note:" and move of this paragraph to the introduction in 1082 Section 1 as last paragraph. 1084 o Section 5.1.2's headline was "Subprotocol Specific Attributes". 1085 Change of this headline to "Other Media Level Attributes" and 1086 adaptations of the first paragraph of this section and the first 1087 paragraph of Section 5.1.2.1 in order to clarify that not only 1088 those attributes may be encapsulated in a "dcsa" attribute, which 1089 are specifically defined for the subprotocol, but that also other 1090 attributes may be encapsulated if they are related to the specific 1091 subprotocol instance. 1093 o Move of the last but one paragraph of Section 5.1.2.1 starting 1094 with "The same syntax applies to ..." right in front of the formal 1095 syntax definition of the "dcsa" attribute. 1097 o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 1098 in order not to explicitly restrict usage of the "a=dcmap:" and 1099 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1100 SCTP" or "TCP/DTLS/SCTP". 1102 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1104 o In Section 5.1.1.5 the first (and only) paragraph was "The 1105 'subprotocol' parameter indicates which protocol the client 1106 expects to exchange via the channel. 'Subprotocol' is an optional 1107 parameter. If the 'subprotocol' parameter is not present, then 1108 its value defaults to the empty string." Replacement of this 1109 paragraph with following two paragraphs: 1111 * The 'subprotocol' parameter indicates which protocol the client 1112 expects to exchange via the channel. This parameter maps to 1113 the 'Protocol' parameter defined in 1114 [I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new 1115 subprotocol parameter values are registered. 'Subprotocol' is 1116 an optional parameter. If the 'subprotocol' parameter is not 1117 present, then its value defaults to the empty string. 1119 * Note: The empty string MAY also be explicitly used as 1120 'subprotocol' value, such that 'subprotocol=""' is equivalent 1121 to the 'subprotocol' parameter not being present at all. 1123 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1124 message's 'Subprotocol' value to be an empty string. 1126 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1127 normative references. 1129 o Addition of dcmap attribute specific IANA registration 1130 Section 8.2.1. 1132 o Addition of dcsa attribute specific IANA registration 1133 Section 8.2.2. 1135 o Addition of new Section 5.1.1.2 describing the mux category of the 1136 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1137 related mux category section are similar to the "Mux Category" 1138 sections of the "a=sctp-port:" and "a=max-message-size:" 1139 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1141 o Addition of new Section 5.1.2.2 describing the mux category of the 1142 dcsa SDP attribute. 1144 10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1146 o In Section 1 replacement of "RTCWeb leaves it open for other 1147 applications to use data channels and its in-band DCEP or out-of- 1148 band non-DCEP protocols for creating them" with "... to use data 1149 channels and its in-band DCEP or other in-band or out-of-band 1150 protocols for creating them". Additionally replacement of "In 1151 particular, the SDP offer generated by the application includes no 1152 channel-specific information" with "... generated by the RTCweb 1153 data channel stack includes no channel-specific information". 1155 o Move of former section 5 ("Data Channels") to new Appendix A and 1156 removal of JavaScript API specific discussions from this moved 1157 text (like mentioning of data channel stack specific states). 1158 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1159 Section 5. 1161 o In Section 5: 1163 * Relacement of Section 5's first paragraph "This section defines 1164 a method of non-DCEP negotiation by which two clients can 1165 negotiate data channel-specific and subprotocol-specific 1166 parameters, using the out-of-band SDP offer/answer exchange. 1167 This SDP extension can only be used with the SDP offer/answer 1168 model." with "This section defines an SDP extension by which 1169 two clients can negotiate data channel-specific and 1170 subprotocol-specific parameters without using DCEP 1172 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1173 defines usage in the context of SDP offer/answer." 1175 * Addition of new paragraph: "Appendix A provides information how 1176 data channels work in general and especially summarizes some 1177 key aspects, which should be considered for the negotiation of 1178 data channels if DCEP is not used." 1180 o In Section 5.1.1 replacement of "The intention of exchanging these 1181 attributes is to create data channels on both the peers with the 1182 same set of attributes without actually using the DCEP 1183 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1184 these attributes is to create, on two peers, without use of DCEP 1185 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1186 directed data channels having the same set of attributes". 1188 o In Section 5.1.1.6 replacement of "The 'max-retr' parameter 1189 indicates the maximal number a user message will be retransmitted" 1190 with "The 'max-retr' parameter indicates the maximal number of 1191 times a user message will be retransmitted". 1193 o In Section 5.2.1 replacement of "However, an SDP offer/answer 1194 exchange MUST NOT be initiated if the associated SCTP stream is 1195 already negotiated via DCEP" with "However, an SCTP stream MUST 1196 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1197 answer exchange if the associated SCTP stream has already been 1198 negotiated via DCEP". 1200 o In the examples in Section 6 addition of the previously missing 1201 colons to the "a=sctp-port" attribute lines. 1203 10.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1205 o Move of reference [I-D.ietf-rtcweb-jsep] from the list of 1206 normative references to the list of informative references. 1208 o Addition of [IANA-SDP-Parameters] to the list of informative 1209 references and addition of following two sentences to the first 1210 paragraph after the ABNF definition: "Note however that not all 1211 SDP attributes are suitable as "a=dcsa:" parameter. 1212 [IANA-SDP-Parameters] contains the lists of IANA registered 1213 session and media level or media level only SDP attributes." 1215 o In the introduction replacement of last sentence "This document 1216 defines SDP-based out-of-band negotiation procedures to establish 1217 data channels for transport of well-defined subprotocols" with 1218 "This document defines SDP offer/answer negotiation procedures to 1219 establish data channels for transport of well-defined 1220 subprotocols, to enable out-of-band negotiation". 1222 o Throughout the document replacement of "external negotiation" with 1223 "SDP offer/answer negotiation" and removal of term "external 1224 negotiation" from the terminology list in Section 3. 1226 o Throughout the document replacement of "internal negotiation" with 1227 "DCEP" and removal of terms "internal negotiation" and "in-band 1228 negotiation" from the terminology list in Section 3. 1230 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1231 terms. 1233 o In Section 5.2.1 replacement of sentence "However, a single stream 1234 is managed using one method at a time." with "However, an SDP 1235 offer/answer exchange MUST NOT be initiated if the associated SCTP 1236 stream is already negotiated via DCEP". 1238 o In Section 5.2.2 replacement of sentence "By definition max-retr 1239 and max-time are mutually exclusive, so only one of them can be 1240 present in a=dcmap" with "By definition max-retr and max-time are 1241 mutually exclusive, so at most one of them MAY be present in 1242 a=dcmap". 1244 o Move of reference [WebRtcAPI] from list of normative references to 1245 list of informative references. 1247 o Removal of almost all text parts, which discussed JavaScript or 1248 other API specific aspects. Such API specific aspects were mainly 1249 discussed in sub-sections of Section 5 and Section 5 of draft- 1250 ietf-mmusic-data-channel-sdpneg-02. 1252 10.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1254 o New Section 4 regarding applicability to SDP offer/answer only. 1256 o Addition of new Section 8.1 "Subprotocol identifiers" as 1257 subsection of the "IANA Considerations" related Section 8. Also 1258 removal of the temporary note "To be completed. As [I-D.ietf- 1259 rtcweb-data-protocol] this document should refer to IANA's 1260 WebSocket Subprotocol Name Registry defined in [RFC6455]." 1262 o In Section 5.2.2: 1264 * In the first paragraph replacement of the sentence "If an SDP 1265 offer contains both of these parameters then such an SDP offer 1266 will be rejected." with "If an SDP offer contains both of these 1267 parameters then the receiver of such an SDP offer MUST reject 1268 the SDP offer." 1270 * In the second paragraph capitalization of "shall" and "may" 1271 such that both sentences now read: "The SDP answer SHALL echo 1272 the same subprotocol, max-retr, max-time, ordered parameters, 1273 if those were present in the offer, and MAY include a label 1274 parameter. They MAY appear in any order, which could be 1275 different from the SDP offer, in the SDP answer." 1277 * In the third paragraph replacement of the sentence "The same 1278 information MUST be replicated without changes in any 1279 subsequent offer or answer, as long as the data channel is 1280 still opened at the time of offer or answer generation." with 1281 "When sending a subsequent offer or an answer, and for as long 1282 as the data channel is still open, the sender MUST replicate 1283 the same information.". 1285 o In Section 5.2.2 the mapping of data channel types defined in 1286 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1287 parameters were illustrated using example "a=dcmap" attribute 1288 lines. Replacement of these example "a=dcmap" attribute lines 1289 with just the "a=dcmap" attribute parameters being relevant for 1290 the channel type. 1292 o In Section 5.2.5 the description of bullet point "SDP offer has no 1293 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1294 No data channel negotiated yet." Replacement of this description 1295 with "Initial SDP offer: No data channel is negotiated yet. The 1296 DTLS connection and SCTP association is negotiated and, if agreed, 1297 established as per [I-D.ietf-mmusic-sctp-sdp]." 1299 o In Section 5.2.5 in both bullet points related to "Subsequent SDP 1300 offer" and "Subsequent SDP answer" replacement of "All the 1301 externally negotiated data channels must be closed now." with "All 1302 the externally negotiated data channels are expected be closed 1303 now.". 1305 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1306 replacement of the two occurrences of "must" with "MUST". 1308 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1309 there was a comment saying that "Either only maxretr-opt or 1310 maxtime-opt is present. Both MUST not be present." Removal of 1311 the second normative sentence and instead addition of following 1312 new paragraph to the end of this section: "Within an 'a=dcmap' 1313 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1314 parameter or one 'maxtime-opt' parameter is present. Both MUST 1315 NOT be present." 1317 o In Section 5.1.1.8 replacement of the first sentence "The 1318 'ordered' parameter with value "true" indicates that DATA chunks 1319 in the channel MUST be dispatched to the upper layer by the 1320 receiver while preserving the order." with "The 'ordered' 1321 parameter with value "true" indicates that the receiver MUST 1322 dispatch DATA chunks in the data channel to the upper layer while 1323 preserving the order.". 1325 o In Section 5.2.3's first paragraph replacement of the one 1326 occurrence of "must" with "..., it MUST wait until ...". 1328 o In Section 5.2.4: 1330 * In the second paragraph replacement of "must" with "... whether 1331 this closing MUST in addition ..." 1333 * In the third paragraph replacement of the sentence "The port 1334 value for the "m" line SHOULD not be changed (e.g., to zero) 1335 when closing a data channel ..." with "The offerer SHOULD NOT 1336 change the port value for the "m" line (e.g., to zero) when 1337 closing a data channel ...". 1339 * In the last but two paragraph replacement of the sentence "... 1340 then an SDP offer which excludes this closed data channel 1341 SHOULD be generated." with "... then the client SHOULD generate 1342 an SDP offer which excludes this closed data channel.". 1344 * In the last but one paragraph replacement of "must" with "The 1345 application MUST also close...". 1347 o In Section 5.1.2 addition of following note after the formal 1348 definition of the 'a=dcsa' attribute: "Note that the above 1349 reference to RFC 4566 defines were the attribute definition can be 1350 found; it does not provide any limitation on support of attributes 1351 defined in other documents in accordance with this attribute 1352 definition." 1354 10.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1356 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1357 channel consisting of paired SCTP outbound and inbound streams." 1358 Replacement of this definition with "Data channel: A WebRTC data 1359 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1360 consistent usage of "data channel" in the remainder of the 1361 document including the document's headline." 1363 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1364 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1365 In particular we expect "webrtc-datachannel" to become a more 1366 general term.' 1368 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1370 o In Section 5.1.1 removal of the example dcmap attribute line 1371 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1372 already four examples right after the ABNF rules in 1373 Section 5.1.1.1. Corresponding removal of following related note: 1374 "Note: This document does not provide a complete specification of 1375 how to negotiate the use of a WebRTC data channel to transport 1376 BFCP. Procedures specific to each subprotocol such as BFCP will 1377 be documented elsewhere. The use of BFCP is only an example of 1378 how the generic procedures described herein might apply to a 1379 specific subprotocol." 1381 o In Section 5.1.1 removal of following note: "Note: This attribute 1382 is derived from attribute "webrtc-DataChannel", which was defined 1383 in old version 03 of the following draft, but which was removed 1384 along with any support for SDP external negotiation in subsequent 1385 versions: [I-D.ietf-mmusic-sctp-sdp]." 1387 o Insertion of following new sentence to the beginning of 1388 Section 5.1.1.1: "dcmap is a media level attribute having 1389 following ABNF syntax:" 1391 o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id 1392 specifying sentence, which previously was placed right before the 1393 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1394 parameter and is noted directly after the "a=dcmap:" attribute's 1395 colon' as this information is part of the ABNF specification. 1397 o In Section 5.1.1.1 modification of the 'ordering-value' values 1398 from "0" or "1" to "true" or "false". Corresponding text 1399 modifications in Section 5.1.1.8. 1401 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1402 to rule name "escaped-char", which was not defined. Instead a 1403 rule with name "escaped" was defined. Renamed that rule's name to 1404 "escaped-char". 1406 o Insertion of a dedicated note right after the "a=dcmap:4" 1407 attribute example in Section 5.1.1.1 regarding the non-printable 1408 "escaped-char" character within the "label" value. 1410 o In Section 5.1.2's second paragraph replacement of "sctp stream 1411 identifier" with "SCTP stream identifier". 1413 o In first paragraph of Section 5.2.1 replacement of first two 1414 sentences 'For the SDP-based external negotiation described in 1415 this document, the initial offerer based "SCTP over DTLS" owns by 1416 convention the even stream identifiers whereas the initial 1417 answerer owns the odd stream identifiers. This ownership is 1418 invariant for the whole lifetime of the signaling session, e.g. it 1419 does not change if the initial answerer sends a new offer to the 1420 initial offerer.' with 'If an SDP offer/answer exchange (could be 1421 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1422 TCP/DTLS/SCTP based media description being accepted, and if this 1423 SDP offer/answer exchange results in the establishment of a new 1424 SCTP association, then the SDP offerer owns the even SCTP stream 1425 ids of this new SCTP association and the answerer owns the odd 1426 SCTP stream identifiers. If this "m" line is removed from the 1427 signaling session (its port number set to zero), and if usage of 1428 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1429 renegotiated later on, then the even and odd SCTP stream 1430 identifier ownership is redetermined as well as described above.' 1432 o In Section 5.2.3 the first action of an SDP answerer, when 1433 receiving an SDP offer, was described as "Applies the SDP offer. 1434 Note that the browser ignores data channel specific attributes in 1435 the SDP." Replacement of these two sentences with "Parses and 1436 applies the SDP offer. Note that the typical parser normally 1437 ignores unknown SDP attributes, which includes data channel 1438 related attributes." 1440 o In Section 5.2.3 the second sentence of the third SDP answerer 1441 action was "Note that the browser is asked to create data channels 1442 with stream identifiers not "owned" by the agent.". Replacement 1443 of this sentence with "Note that the agent is asked to create data 1444 channels with SCTP stream identifiers contained in the SDP offer 1445 if the SDP offer is accepted." 1447 o In Section 5.2.4 the third paragraph began with "A data channel 1448 can be closed by sending a new SDP offer which excludes the dcmap 1449 and dcsa attribute lines for the data channel. The port value for 1450 the m line should not be changed (e.g., to zero) when closing a 1451 data channel (unless all data channels are being closed and the 1452 SCTP association is no longer needed), since this would close the 1453 SCTP association and impact all of the data channels. If the 1454 answerer accepts the SDP offer then it MUST also exclude the 1455 corresponding attribute lines in the answer. ..." Replacement of 1456 this part with "The intention to close a data channel can be 1457 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1458 and "a=dcsa:" attribute lines for the data channel. The port 1459 value for the "m" line SHOULD not be changed (e.g., to zero) when 1460 closing a data channel (unless all data channels are being closed 1461 and the SCTP association is no longer needed), since this would 1462 close the SCTP association and impact all of the data channels. 1463 If the answerer accepts the SDP offer then it MUST close those 1464 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1465 excluded from the received SDP offer, unless those data channels 1466 were already closed, and it MUST also exclude the corresponding 1467 attribute lines in the answer." 1469 o In Section 5.2.4 the hanging text after the third paragraph was 1470 "This delayed close is to handle cases where a successful SDP 1471 answer is not received, in which case the state of session should 1472 be kept per the last successful SDP offer/answer." Replacement of 1473 this sentence with "This delayed closure is RECOMMENDED in order 1474 to handle cases where a successful SDP answer is not received, in 1475 which case the state of the session SHOULD be kept per the last 1476 successful SDP offer/answer." 1478 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1479 Section 5.1.1 contained already procedural descriptions related to 1480 data channel reliability negotiation. Creation of new 1481 Section 5.2.2 and moval of reliability negotiation related text to 1482 this new section. 1484 10.10. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1486 o Removal of note "[ACTION ITEM]" from section "subprotocol 1487 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1488 should refer to IANA's WebSocket Subprotocol Name Registry defined 1489 in [RFC6455]. 1491 o In whole document, replacement of "unreliable" with "partially 1492 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1493 [I-D.ietf-rtcweb-data-protocol] in most places. 1495 o Clarification of the semantic if the "max-retr" parameter is not 1496 present in an a=dcmap attribute line. In section "max-retr 1497 parameter" the sentence "The max-retr parameter is optional with 1498 default value unbounded" was replaced with "The max-retr parameter 1499 is optional. If the max-retr parameter is not present, then the 1500 maximal number of retransmissions is determined as per the generic 1501 SCTP retransmission rules as specified in [RFC4960]". 1503 o Clarification of the semantic if the "max-time" parameter is not 1504 present in an a=dcmap attribute line. In section "max-time 1505 parameter" the sentence "The max-time parameter is optional with 1506 default value unbounded" was replaced with "The max-time parameter 1507 is optional. If the max-time parameter is not present, then the 1508 generic SCTP retransmission timing rules apply as specified in 1509 [RFC4960]". 1511 o In section "label parameter" the sentence "Label is a mandatory 1512 parameter." was removed and following new sentences (including the 1513 note) were added: "The 'label' parameter is optional. If it is 1514 not present, then its value defaults to the empty string. Note: 1515 The empty string may also be explicitly used as 'label' value, 1516 such that 'label=""' is equivalent to the 'label' parameter not 1517 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1518 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1520 o In section "subprotocol parameter" the sentence "Subprotocol is a 1521 mandatory parameter." was replaced with "'Subprotocol' is an 1522 optional parameter. If the 'subprotocol' parameter is not 1523 present, then its value defaults to the empty string." 1525 o In the "Examples" section, in the first two SDP offer examples in 1526 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1527 'label="BFCP"'. 1529 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1530 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1531 replaced with "a=max-message-size" attribute lines, as per draft- 1532 ietf-mmusic-sctp-sdp-12. 1534 10.11. Changes against '-01' 1536 o Formal syntax for dcmap and dcsa attribute lines. 1538 o Making subprotocol as an optional parameter in dcmap. 1540 o Specifying disallowed parameter combinations for max-time and max- 1541 retr. 1543 o Clarifications on WebRTC data channel close procedures. 1545 10.12. Changes against '-00' 1547 o Revisions to identify difference between internal and external 1548 negotiation and their usage. 1550 o Introduction of more generic terminology, e.g. "application" 1551 instead of "browser". 1553 o Clarification of how "max-retr and max-time affect the usage of 1554 unreliable and reliable WebRTC data channels. 1556 o Updates of examples to take into account the SDP syntax changes 1557 introduced with draft-ietf-mmusic-sctp-sdp-07. 1559 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1560 attributes as this is now contained in the a=sctp-port attribute, 1561 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1562 association on top of the DTLS connection. 1564 11. References 1566 11.1. Normative References 1568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1569 Requirement Levels", BCP 14, RFC 2119, 1570 DOI 10.17487/RFC2119, March 1997, 1571 . 1573 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1574 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1575 July 2006, . 1577 [I-D.ietf-mmusic-rfc4566bis] 1578 Handley, M., Jacobson, V., Perkins, D., and A. Begen, 1579 "SDP: Session Description Protocol", draft-ietf-mmusic- 1580 rfc4566bis-17 (work in progress), June 2016. 1582 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1583 with Session Description Protocol (SDP)", RFC 3264, 1584 DOI 10.17487/RFC3264, June 2002, 1585 . 1587 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1588 Specifications: ABNF", STD 68, RFC 5234, 1589 DOI 10.17487/RFC5234, January 2008, 1590 . 1592 [I-D.ietf-rtcweb-data-channel] 1593 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1594 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1595 progress), January 2015. 1597 [I-D.ietf-mmusic-sctp-sdp] 1598 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1599 Control Transmission Protocol (SCTP)-Based Media Transport 1600 in the Session Description Protocol (SDP)", draft-ietf- 1601 mmusic-sctp-sdp-16 (work in progress), February 2016. 1603 [I-D.ietf-mmusic-sdp-mux-attributes] 1604 Nandakumar, S., "A Framework for SDP Attributes when 1605 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13 1606 (work in progress), June 2016. 1608 11.2. Informative References 1610 [I-D.ietf-rtcweb-data-protocol] 1611 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1612 Establishment Protocol", draft-ietf-rtcweb-data- 1613 protocol-09 (work in progress), January 2015. 1615 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1616 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1617 . 1619 [IANA-SDP-Parameters] 1620 "Session Description Protocol (SDP) Parameters", Internet 1621 Assigned Numbers Authority Protocol Assignments Session 1622 Description Protocol (SDP) Parameters, 1623 . 1626 [WebRtcAPI] 1627 Bergkvist, A., Burnett, D., Jennings, C., and A. 1628 Narayanan, "WebRTC 1.0: Real-time Communication Between 1629 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1630 February 2015, 1631 . 1633 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1634 DCEP 1636 This appendix summarizes how data channels work in general and 1637 discusses some key aspects, which should be considered for the out- 1638 of-band negotiation of data channels if DCEP is not used. 1640 A WebRTC application creates a data channel by providing a number of 1641 setup parameters (subprotocol, label, maximal number of 1642 retransmissions, maximal retransmission time, order of delivery, 1643 priority). The application also specifies if it wants to make use of 1644 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1645 the application intends to negotiate data channels using the SDP 1646 offer/answer protocol. 1648 In any case, the SDP offer generated by the application is per 1649 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1650 the SCTP association on top of which data channels will run: 1652 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1653 c=IN IP4 79.97.215.79 1654 a=max-message-size:100000 1655 a=sctp-port:5000 1656 a=setup:actpass 1657 a=connection:new 1658 a=fingerprint:SHA-1 \ 1659 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1661 Note: A WebRTC application will only use "m" line format "webrtc- 1662 datachannel", and will not use other formats in the "m" line for 1663 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1664 only one SCTP association to be established on top of a DTLS 1665 association. 1667 Note: The above SDP media description does not contain any channel- 1668 specific information. 1670 A.1. Stream Identifier Numbering 1672 Independently from the requested type of negotiation, the application 1673 creating a data channel can either pass to the data channel stack the 1674 stream identifier to assign to the data channel or else let the data 1675 channel stack pick one identifier from the unused ones. 1677 To avoid glare situations, each endpoint can moreover own an 1678 exclusive set of stream identifiers, in which case an endpoint can 1679 only create a data channel with a stream identifier it owns. 1681 Which set of stream identifiers is owned by which endpoint is 1682 determined by convention or other means. 1684 For data channels negotiated with the DCEP, one endpoint owns by 1685 convention the even stream identifiers, whereas the other owns the 1686 odd stream identifiers, as defined in 1687 [I-D.ietf-rtcweb-data-protocol]. 1689 For data channels negotiated via some protocol different from 1690 DCEP, no convention is defined by default. 1692 A.2. Generic Data Channel Negotiation Not Using DCEP 1694 A.2.1. Overview 1696 DCEP negotiation only provides for negotiation of data channel 1697 transport parameters and does not provide for negotiation of 1698 subprotocol specific parameters. DCEP-less data channel negotiation 1699 can be defined to allow negotiation of parameters beyond those 1700 handled by DCEP, e.g., parameters specific to the subprotocol 1701 instantiated on a particular data channel. 1703 The following procedures are common to all methods of data channel 1704 negotiation not using DCEP, whether in-band (communicated using 1705 proprietary means on an already established data channel) or out-of- 1706 band (using SDP offer/answer or some other protocol associated with 1707 the signaling channel). 1709 A.2.2. Opening a Data Channel 1711 In the case of DCEP-less negotiation, the endpoint application has 1712 the option to fully control the stream identifier assignments. 1713 However these assignments have to coexist with the assignments 1714 controlled by the data channel stack for the DCEP negotiated data 1715 channels (if any). It is the responsibility of the application to 1716 ensure consistent assignment of stream identifiers. 1718 When the application requests the creation of a new data channel to 1719 be set up via DCEP-less negotiation, the data channel stack creates 1720 the data channel locally without sending any DATA_CHANNEL_OPEN 1721 message in-band. However, even if the ICE (Interactive Connectivity 1722 Establishment), DTLS and SCTP procedures were already successfully 1723 completed, the application can't send data on this data channel until 1724 the negotiation is complete with the peer. This is because the peer 1725 needs to be aware of and accept the usage of this data channel. The 1726 peer, after accepting the data channel offer, can start sending data 1727 immediately. This implies that the offerer may receive data channel 1728 subprotocol messages before the negotiation is complete and the 1729 application should be ready to handle it. 1731 If the peer rejects the data channel part of the offer then it 1732 doesn't have to do anything as the data channel was not created using 1733 the stack. The offerer on the other hand needs to close the data 1734 channel that was opened by invoking relevant data channel stack API 1735 procedures. 1737 It is also worth noting that a data channel stack implementation may 1738 not provide any API to create and close data channels; instead the 1739 data channels may be used on the fly as needed just by communicating 1740 via non-DCEP means or by even having some local configuration/ 1741 assumptions on both the peers. 1743 The application then negotiates the data channel properties and 1744 subprotocol properties with the peer's application using a mechanism 1745 different from DCEP. 1747 The peer then symmetrically creates a data channel with these 1748 negotiated data channel properties. This is the only way for the 1749 peer's data channel stack to know which properties to apply when 1750 transmitting data on this channel. The data channel stack must allow 1751 data channel creation with any non-conflicting stream identifier so 1752 that both peers can create the data channel with the same stream 1753 identifier. 1755 A.2.3. Closing a Data Channel 1757 When the application requests the closing of a data channel 1758 negotiated without DCEP, the data channel stack always performs an 1759 SCTP SSN reset for this channel. 1761 Depending upon the method used for DCEP-less negotiation and the 1762 subprotocol associated with the data channel, the closing might in 1763 addition be signaled to the peer via SDP offer/answer negotiation. 1765 Authors' Addresses 1767 Keith Drage (editor) 1768 Nokia 1769 Quadrant, Stonehill Green, Westlea 1770 Swindon 1771 UK 1773 Email: Keith.Drage@nokia.com 1775 Maridi R. Makaraju (Raju) 1776 Nokia 1777 2000 Lucent Lane 1778 Naperville, Illinois 1779 US 1781 Email: Raju.Makaraju@nokia.com 1782 Juergen Stoetzer-Bradler 1783 Nokia 1784 Lorenzstrasse 10 1785 D-70435 Stuttgart 1786 Germany 1788 Email: Juergen.Stoetzer-Bradler@nokia.com 1790 Richard Ejzak 1791 Unaffiliated 1793 Email: richard.ejzak@gmail.com 1795 Jerome Marcon 1796 Unaffiliated