idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-11.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 (January 15, 2017) is 2657 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 1261, but not defined == Missing Reference: 'RFC6455' is mentioned on line 1545, 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-20 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 == Outdated reference: A later version (-32) exists of draft-ietf-mmusic-dtls-sdp-15 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 11 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 Nokia 5 Expires: July 19, 2017 J. Stoetzer-Bradler 7 R. Ejzak 8 J. Marcon 9 Unaffiliated 10 January 15, 2017 12 SDP-based Data Channel Negotiation 13 draft-ietf-mmusic-data-channel-sdpneg-11 15 Abstract 17 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 18 charged to provide protocols to support direct interactive rich 19 communications using audio, video, and data between two peers' web- 20 browsers. For the support of data communication, the RTCWeb working 21 group has in particular defined the concept of bi-directional data 22 channels over SCTP (Stream Control Transmission Protocol), where each 23 data channel might be used to transport other protocols, called 24 subprotocols. Data channel setup can be done using either the in- 25 band Data Channel Establishment Protocol (DCEP) or using some out-of- 26 band non-DCEP protocol. This document specifies how the SDP (Session 27 Description Protocol) offer/answer exchange can be used to achieve 28 such an out-of-band non-DCEP negotiation. Even though data channels 29 are designed for RTCWeb use initially, they may be used by other 30 protocols like, but not limited to, the CLUE protocol (which is 31 defined by the IETF "ControLling mUltiple streams for tElepresence" 32 working group). This document is intended to be used wherever data 33 channels are used. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 12, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 72 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 6 73 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6 75 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 7 76 5.1.1.2. dcmap Multiplexing Category . . . . . . . . . . . 8 77 5.1.1.3. dcmap-stream-id Parameter . . . . . . . . . . . . 8 78 5.1.1.4. label Parameter . . . . . . . . . . . . . . . . . 9 79 5.1.1.5. subprotocol Parameter . . . . . . . . . . . . . . 9 80 5.1.1.6. max-retr Parameter . . . . . . . . . . . . . . . 9 81 5.1.1.7. max-time Parameter . . . . . . . . . . . . . . . 9 82 5.1.1.8. ordered Parameter . . . . . . . . . . . . . . . . 10 83 5.1.1.9. priority Parameter . . . . . . . . . . . . . . . 10 84 5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10 85 5.1.2.1. dcsa Attribute . . . . . . . . . . . . . . . . . 10 86 5.1.2.2. dcsa Multiplexing Category . . . . . . . . . . . 12 87 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12 89 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 13 90 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 14 91 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 16 92 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 17 93 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 22 97 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 22 98 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 22 99 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 23 100 8.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 23 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 102 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 10.1. Changes against 'draft-ietf-mmusic-data-channel- 104 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 24 105 10.2. Changes against 'draft-ietf-mmusic-data-channel- 106 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 24 107 10.3. Changes against 'draft-ietf-mmusic-data-channel- 108 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 25 109 10.4. Changes against 'draft-ietf-mmusic-data-channel- 110 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25 111 10.5. Changes against 'draft-ietf-mmusic-data-channel- 112 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 26 113 10.6. Changes against 'draft-ietf-mmusic-data-channel- 114 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 26 115 10.7. Changes against 'draft-ietf-mmusic-data-channel- 116 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 27 117 10.8. Changes against 'draft-ietf-mmusic-data-channel- 118 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27 119 10.9. Changes against 'draft-ietf-mmusic-data-channel- 120 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 29 121 10.10. Changes against 'draft-ietf-mmusic-data-channel- 122 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 30 123 10.11. Changes against 'draft-ietf-mmusic-data-channel- 124 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 32 125 10.12. Changes against 'draft-ejzak-mmusic-data-channel- 126 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 35 127 10.13. Changes against '-01' . . . . . . . . . . . . . . . . . 36 128 10.14. Changes against '-00' . . . . . . . . . . . . . . . . . 36 129 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 130 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 131 11.2. Informative References . . . . . . . . . . . . . . . . . 37 132 Appendix A. Generic Data Channel Negotiation Aspects When Not 133 Using DCEP . . . . . . . . . . . . . . . . . . . . . 38 134 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 39 135 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39 136 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39 137 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39 138 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 141 1. Introduction 143 The RTCWeb working group has defined the concept of bi-directional 144 data channels running on top of the Stream Control Transmission 145 Protocol (SCTP). RTCWeb allows applications to use data channels. 146 RTCWeb defines an in-band Data Channel Establishment Protocol (DCEP), 147 however other in-band or out-of-band protocols may be used for 148 establishing data channels. Each data channel consists of paired 149 SCTP streams sharing the same SCTP Stream Identifier. Data channels 150 are created by endpoint applications through the WebRTC API 151 (Application Programming Interface), or other users of a data channel 152 like CLUE. They can be used to transport proprietary or well-defined 153 protocols, which in the latter case can be signaled by the data 154 channel "subprotocol" parameter, conceptually similar to the 155 WebSocket "subprotocol". However, apart from the "subprotocol" value 156 transmitted to the peer, RTCWeb leaves it open how endpoint 157 applications can agree on how to instantiate a given subprotocol on a 158 data channel, and whether it is signaled in-band using DCEP or out- 159 of-band using a non-DCEP protocol (or both). In particular, the SDP 160 offer generated by the RTCweb data channel stack includes no channel- 161 specific information. 163 This document defines SDP offer/answer negotiation procedures to 164 establish data channels for transport of well-defined subprotocols, 165 to enable out-of-band negotiation. These procedures are based on 166 generic SDP offer/answer negotiation rules for SCTP based media 167 transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" 168 line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In future data 169 channels could be defined over other SCTP based protocols, such as 170 SCTP over IP. However, corresponding potential other "m" line proto 171 values are not considered in this document. 173 This document makes use of MSRP (Message Session Relay Protocol) in 174 many of the examples. It does not provide a complete specification 175 of how to negotiate the use of a data channel to transport MSRP. 176 Procedures specific to each subprotocol such as MSRP are documented 177 elsewhere. The use of MSRP in some examples is only to show how the 178 generic procedures described herein might apply to a specific 179 subprotocol. 181 2. Conventions 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 3. Terminology 189 This document uses the following terms: 191 Data channel: A WebRTC data channel as specified in 192 [I-D.ietf-rtcweb-data-channel]. 194 Data channel stack: An entity which, upon application request, 195 runs the data channel protocol to keep track of states, sending 196 and receive data. If the application is a browser based 197 JavaScript application then this stack resides in the browser. If 198 the application is a native application then this stack resides in 199 the application and is accessible via some sort of APIs. 201 Data channel properties: Fixed properties assigned to a data 202 channel at the time of its creation. Some of these properties 203 determine the way the data channel stack transmits data on this 204 channel (e.g., stream identifier, reliability, order of 205 delivery...). 207 Data channel subprotocol: The application protocol which is 208 transported over a single data channel. Data channel subprotocol 209 messages are sent as data channel payload over an established data 210 channel. If an SDP offer/answer exchange is used as specified in 211 this document to negotiate the establishment of data channels, 212 corresponding data channel properties, associated data channel 213 subprotocols and data channel subprotocol properties, then the 214 data channel subprotocols may be identified by the values of the 215 "subprotocol" parameters of the SDP "a=dcmap" attribute as 216 described in Section 5.1.1.5. Within this document the term "data 217 channel subprotocol" is often abbreviated as just "subprotocol". 219 DCEP: Data Channel Establishment Protocol defined in 220 [I-D.ietf-rtcweb-data-protocol]. 222 In-band: Transmission through the peer-to-peer SCTP association. 224 Out-of-band: Transmission through the application signaling path. 226 Peer: From the perspective of one of the agents in a session, its 227 peer is the other agent. Specifically, from the perspective of 228 the SDP offerer, the peer is the SDP answerer. From the 229 perspective of the SDP answerer, the peer is the SDP offerer. 231 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 232 as specified in [RFC4960]. 234 Stream identifier: The identifier of the outbound and inbound SCTP 235 streams composing a data channel. 237 4. Applicability Statement 239 The mechanism in this document only applies to the Session 240 Description Protocol (SDP) [RFC4566], when used together with the SDP 241 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 242 scope of this document, and is thus undefined. 244 5. SDP Offer/Answer Negotiation 246 This section defines an SDP extension by which two clients can 247 negotiate data channel-specific and subprotocol-specific parameters 248 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 249 extension only defines usage in the context of SDP offer/answer. 251 Appendix A provides information how data channels work in general and 252 especially summarizes some key aspects, which should be considered 253 for the negotiation of data channels if DCEP is not used. 255 5.1. SDP Syntax 257 Two new SDP attributes are defined to support SDP offer/answer 258 negotiation of data channels. The first attribute provides for 259 negotiation of channel-specific parameters. The second attribute 260 provides for negotiation of subprotocol-specific parameters. 262 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 264 Associated with the SDP "m" line that defines the SCTP association 265 for data channels (defined in Section 3), each SDP offer and answer 266 includes one "a=dcmap:" attribute that defines the data channel 267 parameters for each data channel to be negotiated. Each such 268 attribute line specifies the following parameters for a data channel: 269 SCTP stream identifier, subprotocol, label, maximal number of 270 retransmissions, maximal retransmission time, order of delivery, and 271 priority. 273 The intention in exchanging these attributes is to create, on two 274 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 275 pairs of oppositely directed data channels having the same set of 276 attributes. It is assumed that the data channel properties 277 (reliable/partially reliable, ordered/unordered) are suitable per the 278 subprotocol transport requirements. 280 5.1.1.1. dcmap Attribute 282 "a=dcmap:" is a media level attribute having following ABNF 283 (Augmented Backus-Naur Form, [RFC5234]) syntax. 285 Formal Syntax: 287 Name: dcmap 289 Value: dcmap-value 291 Usage Level: media 293 Charset Dependent: no 295 Syntax: 297 dcmap-value = dcmap-stream-id 298 [ SP dcmap-opt *(";" dcmap-opt) ] 299 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 300 / maxretr-opt / maxtime-opt / priority-opt 301 ; Either only maxretr-opt or maxtime-opt 302 ; is present. 304 dcmap-stream-id = 1*DIGIT 305 ordering-opt = "ordered=" ordering-value 306 ordering-value = "true" / "false" 307 subprotocol-opt = "subprotocol=" quoted-string 308 label-opt = "label=" quoted-string 309 maxretr-opt = "max-retr=" maxretr-value 310 maxretr-value = "0" / integer 311 ; number of retransmissions, 312 ; less than 2^32, 313 ; derived from 'Reliability Parameter' of 314 ; [I-D.ietf-rtcweb-data-protocol] 315 maxtime-opt = "max-time=" maxtime-value 316 maxtime-value = "0" / integer 317 ; milliseconds, 318 ; less than 2^32, 319 ; derived from 'Reliability Parameter' of 320 ; [I-D.ietf-rtcweb-data-protocol] 321 priority-opt = "priority=" priority-value 322 priority-value = "0" / integer 323 ; unsigned integer value indicating the priority of 324 ; the data channel, 325 ; less than 2^16, 326 ; derived from 'Priority' of 327 ; [I-D.ietf-rtcweb-data-protocol] 329 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 330 quoted-char = SP / quoted-visible 331 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 332 escaped-char = "%" HEXDIG HEXDIG 333 DQUOTE = 334 integer = 336 Examples: 338 a=dcmap:0 339 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 340 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 341 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 342 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 344 Note: The last example (a=dcmap:4) shows a 'label' parameter value 345 which contains one non-printable 'escaped-char' character (the 346 tabulator character). 348 Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only 349 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 350 present. Both MUST NOT be present. 352 5.1.1.2. dcmap Multiplexing Category 354 Multiplexing characteristics of SDP attributes are described in 355 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 356 multiplexing categories are introduced there. 358 The multiplexing category of the "a=dcmap:" attribute is SPECIAL. 360 As the usage of multiple SCTP associations on top of a single DTLS 361 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 362 "a=dcmap:" attribute multiplexing rules are specified for the 363 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 364 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 365 multiple SCTP associations on top of a single DTLS association, or 366 how to add multiple SCTP associations to one BUNDLE group, then 367 multiplexing rules for the "a=dcmap:" attribute need to be defined as 368 well, for instance in an extension of this SDP based data channel 369 negotiation specification. 371 5.1.1.3. dcmap-stream-id Parameter 373 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 374 within the SCTP association used to form the data channel. 376 5.1.1.4. label Parameter 378 The 'label' parameter indicates the name of the channel. It 379 represents a label that can be used to distinguish, in the context of 380 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 381 RTCDataChannel objects. This parameter maps to the 'Label' parameter 382 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 383 optional. If it is not present, then its value defaults to the empty 384 string. 386 Note: The empty string MAY also be explicitly used as a 'label' 387 value, such that 'label=""' is equivalent to the 'label' parameter 388 not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 389 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 391 5.1.1.5. subprotocol Parameter 393 The 'subprotocol' parameter indicates which protocol the client 394 expects to exchange via the channel. This parameter maps to the 395 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 396 Section 8.1 specifies how new subprotocol parameter values are 397 registered. 'Subprotocol' is an optional parameter. If the 398 'subprotocol' parameter is not present, then its value defaults to an 399 empty string. 401 Note: The empty string MAY also be explicitly used as 'subprotocol' 402 value, such that 'subprotocol=""' is equivalent to the 'subprotocol' 403 parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] 404 allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an 405 empty string. 407 5.1.1.6. max-retr Parameter 409 This parameter indicates that the data channel is partially reliable. 410 The 'max-retr' parameter indicates the maximal number of times a user 411 message will be retransmitted. The max-retr parameter is optional. 412 If the max-retr parameter is not present, then the maximal number of 413 retransmissions is determined as per the generic SCTP retransmission 414 rules as specified in [RFC4960]. This parameter maps to the 'Number 415 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 417 5.1.1.7. max-time Parameter 419 This parameter indicates that the data channel is partially reliable. 420 A user message will no longer be transmitted or retransmitted after a 421 specified life-time given in milliseconds in the 'max-time' 422 parameter. The max-time parameter is optional. If the max-time 423 parameter is not present, then the generic SCTP retransmission timing 424 rules apply as specified in [RFC4960]. This parameter maps to the 425 'Lifetime in ms' parameter defined in 426 [I-D.ietf-rtcweb-data-protocol]. 428 5.1.1.8. ordered Parameter 430 The 'ordered' parameter with value "true" indicates that the receiver 431 MUST dispatch DATA chunks in the data channel to the upper layer 432 while preserving the order. The ordered parameter is optional and 433 takes two values: "true" for ordered and "false" for unordered 434 delivery with "true" as the default value. Any other value is 435 ignored and default "ordered=true" is assumed. In the absence of 436 this parameter "ordered=true" is assumed. This parameter maps to the 437 ordered or unordered data channel types as defined in 438 [I-D.ietf-rtcweb-data-protocol]. 440 5.1.1.9. priority Parameter 442 The 'priority' parameter indicates the data channel's priority 443 relative to the priorities of other data channels, which may 444 additionally exist over the same SCTP association. The 'priority' 445 parameter maps to the 'Priority' parameter defined in 446 [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is 447 optional. In the absence of this parameter "priority=256" is 448 assumed. 450 5.1.2. Other Media Level Attributes 452 In the SDP, each data channel declaration MAY also be followed by 453 other media level SDP attributes, which are either specifically 454 defined for or applied to the subprotocol in use. Each of these 455 attributes is represented by one new attribute line, and it includes 456 the contents of a media-level SDP attribute already defined for use 457 with this (sub)protocol in another IETF (Internet Engineering Task 458 Force) document. Subprotocol specific attributes MAY also be defined 459 for exclusive use with data channel transport, but MUST use the same 460 syntax described here for other subprotocol related attributes. 462 5.1.2.1. dcsa Attribute 464 Each SDP attribute, related to the subprotocol, that would normally 465 be used to negotiate the subprotocol using SDP is replaced with an 466 attribute of the form "a=dcsa:stream-id original-attribute", where 467 dcsa stands for "data channel subprotocol attribute", stream-id is 468 the SCTP stream identifier assigned to this subprotocol instance, and 469 original-attribute represents the contents of the subprotocol related 470 attribute to be included. 472 The same syntax applies to any other SDP attribute required for 473 negotiation of this instance of the subprotocol. 475 Formal Syntax: 477 Name: dcsa 479 Value: dcsa-value 481 Usage Level: media 483 Charset Dependent: no 485 Syntax: 487 dcsa-value = stream-id SP attribute 488 attribute = 490 Example: 492 a=dcsa:2 accept-types:text/plain 494 Note that the above reference to [RFC4566] defines where the 495 attribute definition can be found; it does not provide any limitation 496 on support of attributes defined in other documents in accordance 497 with this attribute definition. Note however that not all SDP 498 attributes are suitable as a "a=dcsa:" parameter. 499 [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned 500 Numbers Authority) registered session and media level or media level 501 only SDP attributes. 503 Thus in the example above, the original attribute line "a=accept- 504 types:text/plain" is represented by the attribute line "a=dcsa:2 505 accept-types:text/plain", which specifies that this instance of the 506 MSRP subprotocol being transported on the SCTP association using the 507 data channel with stream id 2 accepts plain text files. 509 As opposed to the data channel "a=dcmap:" attribute parameters, these 510 parameters are subject to offer/answer negotiation following the 511 procedures defined in the subprotocol specific documents. 513 It is assumed that in general the usages of subprotocol related media 514 level attributes are independent from the subprotocol's transport 515 protocol. Such transport protocol independent subprotocol related 516 attributes are used in the same way as defined in the original 517 subprotocol specification, also if the subprotocol is transported 518 over a data channel and if the attribute is correspondingly embedded 519 in a "a=dcsa" attribute. 521 There may be cases, where the usage of a subprotocol related media 522 level attribute depends on the subprotocol's transport protocol. In 523 such cases the subprotocol related usage of the attribute is expected 524 to be described for the data channel transport. A data channel 525 specific usage of a subprotocol attribute is expected to be specified 526 in the same document, which registers the subprotocol's identifier 527 for data channel usage as described in Section 8.1. 529 5.1.2.2. dcsa Multiplexing Category 531 The multiplexing category of the "a=dcsa:" attribute is SPECIAL. 533 As the usage of multiple SCTP associations on top of a single DTLS 534 association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no 535 "a=dcsa:" attribute multiplexing rules are specified for the 536 UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions 537 of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of 538 multiple SCTP associations on top of a single DTLS association, or 539 how to add multiple SCTP associations to one BUNDLE group, then 540 multiplexing rules for the "a=dcsa:" attribute need to be defined as 541 well, for instance in an extension of this SDP based data channel 542 negotiation specification. 544 5.2. Procedures 546 5.2.1. Managing Stream Identifiers 548 If a SDP offer/answer exchange (could be the initial or a subsequent 549 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 550 description being accepted, and if this SDP offer/answer exchange 551 results in the establishment of a new SCTP association, then the SDP 552 offerer owns the even SCTP stream ids of this new SCTP association 553 and the answerer owns the odd SCTP stream identifiers. If this "m" 554 line is removed from the signaling session (its port number set to 555 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 556 SCTP based "m" line is renegotiated later on, then the even and odd 557 SCTP stream identifier ownership is re-determined as described above. 559 This document allows simultaneous use of SDP offer/answer and DCEP 560 negotiation. However, an SCTP stream MUST NOT be referenced in a 561 "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if 562 the associated SCTP stream has already been negotiated via DCEP. 563 Stream ids that are not currently used in SDP can be used for DCEP 564 negotiation. Stream id allocation per SDP offer/answer negotiation 565 may not align with DTLS role based allocation. This could cause 566 glare conditions when one side tries to do SDP offer/answer 567 negotiation on a stream id while the other end tries to open a data 568 channel on the same stream id using DCEP negotiation. To avoid these 569 glare conditions this document recommends that the data channel stack 570 user always selects stream ids per the above described SDP offer/ 571 answer rule even when DCEP negotiation is used. To avoid glare 572 conditions, it is possible to come up with a different stream id 573 allocation scheme, but such schemes are outside the scope of this 574 document. 576 5.2.2. Negotiating Data Channel Parameters 578 Conveying a reliable data channel is achieved by including neither 579 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 580 "a=dcmap:" attribute line. Conveying a partially reliable data 581 channel is achieved by including only one of 'max-retr' or 'max- 582 time'. By definition max-retr and max-time are mutually exclusive, 583 so at most one of them MAY be present in the "a=dcmap:" attribute 584 line. If a SDP offer contains both of these parameters then the 585 receiver of such an SDP offer MUST reject the SDP offer. If a SDP 586 answer contains both of these parameters then the offerer MAY treat 587 it as an error and MAY assume the associated SDP offer/answer failed 588 and MAY take appropriate recovery actions. These recovery options 589 are outside the scope of this document. 591 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 592 ordered parameters, if those were present in the offer, and MAY 593 include a label parameter. They MAY appear in any order, which could 594 be different from the SDP offer, in the SDP answer. 596 When sending a subsequent offer or an answer, and for as long as the 597 data channel is still open, the sender MUST replicate the same 598 information. 600 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 601 mapped to SDP in the following manner, where "ordered=true" is the 602 default and may be omitted: 604 DATA_CHANNEL_RELIABLE 605 ordered=true 607 DATA_CHANNEL_RELIABLE_UNORDERED 608 ordered=false 610 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 611 ordered=true;max-retr= 613 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 614 ordered=false;max-retr= 616 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 617 ordered=true;max-time= 619 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 620 ordered=false;max-time= 622 5.2.3. Opening a Data Channel 624 The procedure for opening a data channel using SDP offer/answer 625 negotiation starts with the agent preparing to send an SDP offer. If 626 a peer receives an SDP offer before starting to send a new SDP offer 627 with data channels that are to be SDP offer/answer negotiated, or 628 loses an SDP offer glare resolution procedure in this case, it MUST 629 wait until the ongoing SDP offer/answer completes before resuming the 630 SDP offer/answer negotiation procedure. 632 The agent that intends to send an SDP offer to create data channels 633 through SDP offer/answer negotiation performs the following: 635 o Creates data channels using stream identifiers from the owned set 636 (see Section 5.2.1). 638 o Generates a new SDP offer. 640 o Determines the list of stream identifiers assigned to data 641 channels opened through SDP offer/answer negotiation. 643 o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:" 644 attributes needed, if any, for each SDP offer/answer negotiated 645 data channel, as described in Section 5.1 and in Section 5.2.2. 647 o If it adds "a=dcsa" attributes to the SDP offer, then it SHOULD 648 add the subprotocol parameter to the "a=dcmap" attribute with a 649 non-empty subprotocol identifier. 651 o Sends the SDP offer. 653 The peer receiving such an SDP offer performs the following: 655 o Parses and applies the SDP offer, taking into account the 656 considerations discussed in Section 5.2.5. 658 o Analyzes the channel parameters and subprotocol attributes to 659 determine whether to accept each offered data channel. 661 o For accepted data channels, it creates peer instances for the data 662 channels with the agent using the channel parameters described in 663 the SDP offer. Note that the agent is asked to create data 664 channels with SCTP stream identifiers contained in the SDP offer 665 if the SDP offer is accepted. 667 o Generates an SDP answer. 669 o Completes the SDP answer with the "a=dcmap:" and optional 670 "a=dcsa:" attributes needed for each SDP offer/answer negotiated 671 data channel, as described in Section 5.1 and in Section 5.2.2. 673 o Sends the SDP answer. 675 The agent receiving such an SDP answer performs the following: 677 o Closes any created data channels as described in Section 5.2.4 for 678 which the expected "a=dcmap:" and "a=dcsa:" attributes are not 679 present in the SDP answer. 681 o Applies the SDP answer. 683 Each agent application MUST wait to send data until it has 684 confirmation that the data channel at the peer is instantiated. For 685 WebRTC, this is when both data channel stacks have channel parameters 686 instantiated. This occurs: 688 o At both peers when a data channel is created without an 689 established SCTP association, as soon as the SCTP association is 690 successfully established. 692 o At the agent receiving an SDP offer for which there is an 693 established SCTP association, as soon as it creates an SDP offer/ 694 answer negotiated data channel based on information signaled in 695 the SDP offer. 697 o At the agent sending an SDP offer to create a new SDP offer/answer 698 negotiated data channel for which there is an established SCTP 699 association, when it receives the SDP answer confirming acceptance 700 of the data channel or when it begins to receive data on the data 701 channel from the peer, whichever occurs first. 703 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 704 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 706 5.2.4. Closing a Data Channel 708 When the application requests the closing of a data channel that was 709 negotiated via SDP offer/answer, the data channel stack always 710 performs an SCTP SSN reset for this channel. 712 It is specific to the subprotocol whether this closing MUST in 713 addition be signaled to the peer via a new SDP offer/answer exchange. 715 The intention to close a data channel can be signaled by sending a 716 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 717 lines for the data channel. The offerer SHOULD NOT change the port 718 value for the "m" line (e.g. to zero) when closing a data channel 719 (unless all data channels are being closed and the SCTP association 720 is no longer needed), since this would close the SCTP association and 721 impact all of the data channels. If the answerer accepts the SDP 722 offer then the answerer MUST close those data channels whose 723 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 724 received SDP offer, unless those data channels were already closed, 725 and the answerer MUST also exclude the corresponding attribute lines 726 in the answer. In addition to that, the SDP answerer MAY exclude 727 other data channels which were closed but not yet communicated to the 728 peer. So, the offerer MUST inspect the answer to see if it has to 729 close other data channels which are now not included in the answer. 731 If a new SDP offer/answer is used to close data channels then the 732 data channel(s) SHOULD only be closed by the answerer/offerer after a 733 successful SDP answer is sent/received. 735 This delayed closure is RECOMMENDED in order to handle cases where 736 a successful SDP answer is not received, in which case the state 737 of the session SHOULD be kept per the last successful SDP offer/ 738 answer. 740 If a client receives a data channel close indication (due to inband 741 SCTP SSN reset or some other reason) without associated SDP offer 742 then the client SHOULD generate an SDP offer which excludes this 743 closed data channel. 745 The application MUST also close any data channel that was negotiated 746 via SDP offer/answer, for which the stream identifiers are not listed 747 in an incoming SDP offer. 749 A closed data channel using local close (SCTP SSN reset), without an 750 additional SDP offer/answer to close it, may be reused for a new data 751 channel. This can only be done via new SDP offer/answer, describing 752 the new subprotocol and its attributes, only after the corresponding 753 data channel close acknowledgement is received from the peer (i.e. 754 SCTP SSN reset of both incoming and outgoing streams is completed). 755 This restriction is to avoid the race conditions between arrival of 756 "SDP offer which reuses stream" with "SCTP SSN reset which closes 757 outgoing stream" at the peer. 759 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 761 SDP offer has no "a=dcmap:" attributes. 763 * Initial SDP offer: No data channel is negotiated yet. The DTLS 764 association and SCTP association is negotiated and, if agreed, 765 established as per [I-D.ietf-mmusic-sctp-sdp]. 767 * Subsequent SDP offer: All the SDP offer/answer negotiated data 768 channels are expected be closed now. The DTLS/SCTP association 769 remains open for SDP offer/answer or DCEP negotiation of data 770 channels. 772 SDP answer has no "a=dcmap:" attributes. 774 * Initial SDP answer: Either the peer does not support "a=dcmap:" 775 attributes or it rejected all the data channels. In either 776 case the offerer closes all the SDP offer/answer negotiated 777 data channels that were open at the time of initial offer. The 778 DTLS association and SCTP association will still be setup. 780 * Subsequent SDP answer: All the SDP offer/answer negotiated data 781 channels are expected be closed now. The SCTP association 782 remains open for future SDP offer/answer or DCEP negotiation of 783 data channels. 785 SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" 786 attributes. 788 * This is considered an error case. In this case the receiver of 789 such an SDP offer or answer SHOULD ignore the "a=dcsa:" 790 attributes and SHOULD process the SDP offer or answer as per 791 above case 'SDP offer has no "a=dcmap:" attributes' or case 792 'SDP answer has no "a=dcmap:" attributes'. 794 SDP offer has no "a=dcsa:" attributes for a data channel. 796 * This is allowed and indicates there are no subprotocol 797 parameters to convey. 799 SDP answer has no "a=dcsa:" attributes for a data channel. 801 * This is allowed and indicates there are no subprotocol 802 parameters to convey in the SDP answer. The number of 803 "a=dcsa:" attributes in the SDP answer does not have to match 804 the number of "a=dcsa:" attributes in the SDP offer. 806 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 807 attribute is unknown. 809 * The receiver of such an SDP offer or answer SHOULD ignore this 810 entire "a=dcsa" attribute line. 812 SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 813 attribute is known, but whose subprotocol attribute semantic is 814 not known for the data channel transport case. 816 * The receiver of such an SDP offer or answer SHOULD ignore this 817 entire "a=dcsa" attribute line. 819 6. Examples 820 SDP offer: 822 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 823 c=IN IP4 10.10.10.1 824 a=max-message-size:100000 825 a=sctp-port:5000 826 a=setup:actpass 827 a=fingerprint:SHA-1 \ 828 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 829 a=dtls-id:4a7565 830 a=dcmap:0 subprotocol="BFCP";label="BFCP" 832 SDP answer: 834 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 835 c=IN IP4 10.10.10.2 836 a=max-message-size:100000 837 a=sctp-port:5002 838 a=setup:passive 839 a=fingerprint:SHA-1 \ 840 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 841 a=dtls-id:532d42 843 Figure 1: Example 1 845 In the above example the SDP answerer rejected the data channel with 846 stream id 0 either for explicit reasons or because it does not 847 understand the "a=dcmap:" attribute. As a result the offerer will 848 close the data channel created with the SDP offer/answer negotiation 849 option. The SCTP association will still be setup over DTLS. At this 850 point the offerer or the answerer may use DCEP negotiation to open 851 data channels. 853 SDP offer: 855 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 856 c=IN IP4 10.10.10.1 857 a=max-message-size:100000 858 a=sctp-port:5000 859 a=setup:actpass 860 a=fingerprint:SHA-1 \ 861 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 862 a=dtls-id:4a7565 863 a=dcmap:0 subprotocol="BFCP";label="BFCP" 864 a=dcmap:2 subprotocol="MSRP";label="MSRP" 865 a=dcsa:2 accept-types:message/cpim text/plain 866 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 868 SDP answer: 870 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 871 c=IN IP4 10.10.10.2 872 a=max-message-size:100000 873 a=sctp-port:5002 874 a=setup:passive 875 a=fingerprint:SHA-1 \ 876 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 877 a=dtls-id:532d42 878 a=dcmap:2 subprotocol="MSRP";label="MSRP" 879 a=dcsa:2 accept-types:message/cpim text/plain 880 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 882 Figure 2: Example 2 884 In the above example the SDP offer contains data channels for BFCP 885 (Binary Floor Control Protocol) and MSRP subprotocols. The SDP 886 answer rejected BFCP and accepted MSRP. So, the offerer closes the 887 data channel for BFCP and both offerer and answerer may start using 888 the MSRP data channel (after the SCTP association is set up). The 889 data channel with stream id 0 is free and can be used for future DCEP 890 or SDP offer/answer negotiation. 892 Continuing the example in Figure 2. 894 Subsequent SDP offer: 896 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 897 c=IN IP4 10.10.10.1 898 a=max-message-size:100000 899 a=sctp-port:5000 900 a=setup:actpass 901 a=fingerprint:SHA-1 \ 902 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 903 a=dtls-id:4a7565 904 a=dcmap:4 subprotocol="MSRP";label="MSRP" 905 a=dcsa:4 accept-types:message/cpim text/plain 906 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 908 Subsequent SDP answer: 910 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 911 c=IN IP4 10.10.10.2 912 a=max-message-size:100000 913 a=sctp-port:5002 914 a=setup:passive 915 a=fingerprint:SHA-1 \ 916 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 917 a=dtls-id:532d42 918 a=dcmap:4 subprotocol="MSRP";label="MSRP" 919 a=dcsa:4 accept-types:message/cpim text/plain 920 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 922 Figure 3: Example 3 924 The above example is a continuation of the example in Figure 2. The 925 SDP offerer now removes the MSRP data channel with stream id 2, but 926 opens a new MSRP data channel with stream id 4. The answerer accepts 927 the entire offer. As a result the offerer closes the earlier 928 negotiated MSRP related data channel and both offerer and answerer 929 may start using new the MSRP related data channel. 931 7. Security Considerations 933 No security considerations are envisaged beyond those already 934 documented in [RFC4566]. 936 8. IANA Considerations 937 8.1. Subprotocol Identifiers 939 Registration of new subprotocol identifiers is performed using the 940 existing IANA "WebSocket Subprotocol Name Registry" table. 942 The following text should be added following the title of the table. 944 "This table also includes subprotocol identifiers specified for usage 945 within a WebRTC data channel." 947 The following reference should be added to under the heading 948 reference: "RFC XXXX". 950 This document assigns no new values to this table. 952 A subprotocol may simultaneously be defined for data channel 953 transport and for Websocket transport. In such a case the 954 "Subprotocol Definition" and "Reference" cells in the subprotocol's 955 row of the IANA "WebSocket Subprotocol Name Registry" table should 956 contain two entries. One entry in each of these cells should refer 957 to the Websocket related subprotocol specification, and the other 958 entry should refer to the data channel related subprotocol 959 specification. 961 NOTE to RFC Editor: Please replace "XXXX" with the number of this 962 RFC. 964 8.2. New SDP Attributes 966 8.2.1. dcmap 968 NOTE to RFC Editor: Please replace "XXXX" with the number of this 969 RFC. 971 This document defines a new SDP media-level attribute "a=dcmap:" as 972 follows: 974 +-----------------------+-------------------------------------------+ 975 | Contact name: | MMUSIC Chairs | 976 | Contact email: | mmusic-chairs@ietf.org | 977 | Attribute name: | dcmap | 978 | Attribute syntax: | As per Section 5.1.1.1 | 979 | Attribute semantics: | As per Section 5.1.1.1 | 980 | Usage level: | media | 981 | Charset dependent: | No | 982 | Purpose: | Define data channel specific parameters | 983 | Appropriate values: | As per Section 5.1.1.1 | 984 | O/A procedures: | As per Section 5.2 | 985 | Mux category: | SPECIAL. See Section 5.1.1.2 | 986 | Reference: | RFCXXXX | 987 +-----------------------+-------------------------------------------+ 989 8.2.2. dcsa 991 NOTE to RFC Editor: Please replace "XXXX" with the number of this 992 RFC. 994 This document defines a new SDP media-level attribute "a=dcsa:" as 995 follows: 997 +-----------------------+-------------------------------------------+ 998 | Contact name: | MMUSIC Chairs | 999 | Contact email: | mmusic-chairs@ietf.org | 1000 | Attribute name: | dcsa | 1001 | Attribute syntax: | As per Section 5.1.2.1 | 1002 | Attribute semantics: | As per Section 5.1.2.1 | 1003 | Usage level: | media | 1004 | Charset dependent: | No | 1005 | Purpose: | Define data channel subprotocol specific | 1006 | | attributes | 1007 | Appropriate values: | As per Section 5.1.2.1 | 1008 | O/A procedures: | As per Section 5.2 | 1009 | Mux category: | SPECIAL. See Section 5.1.2.2 | 1010 | Reference: | RFCXXXX | 1011 +-----------------------+-------------------------------------------+ 1013 8.3. New Usage Level 1015 This document introduces a new "Data Channel Subprotocol Attribute" 1016 (dcsa) usage level to the SDP to the IANA SDP att-field registry. 1017 SDP attributes that are defined for use at the dcsa usage level only 1018 shall use the dcsa usage level when registering the attribute. If 1019 existing media attributes are used in a datachannel subprotocol 1020 specific way (Section 5.1.2.1), then a new dcsa usage level MUST be 1021 defined for the existing media attribute. Where the SDP attribute is 1022 applicable to a particular subprotocol/s this SHALL also be 1023 registered by indicating the applicable subprotocol identifiers (see 1024 Section 8.1) along with the dcsa usage level. E.g. 1026 +-----------------------+-------------------------------------------+ 1027 | ... | ... | 1028 | Usage level: | dcsa(MSRP) | 1029 | ... | ... | 1030 +-----------------------+-------------------------------------------+ 1032 9. Acknowledgments 1034 The authors wish to acknowledge the borrowing of ideas from other 1035 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 1036 and Gavin Llewellyn, and to thank Flemming Andreasen, Roni Even, 1037 Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, 1038 Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their 1039 invaluable comments. 1041 10. CHANGE LOG 1043 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' 1045 o Removal of the "a=connection" attribute lines from all SDP 1046 examples. 1048 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' 1050 o In the introduction: 1052 * Replacement of the sentence "The RTCWeb working group has 1053 defined the concept of bi-directional data channels running on 1054 top of SCTP/DTLS (SCTP over the Datagram Transport Layer 1055 Security protocol)" with "The RTCWeb working group has defined 1056 the concept of bi-directional data channels running on top of 1057 the Stream Control Transmission Protocol (SCTP)". 1059 * Addition of following sentences to the second paragraph: "These 1060 procedures are based on generic SDP offer/answer negotiation 1061 rules for SCTP based media transport as specified in 1062 [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values 1063 UDP/DTLS/SCTP and TCP/DTLS/SCTP. In future data channels could 1064 be defined over other SCTP based protocols, such as SCTP over 1065 IP. However, corresponding potential other "m" line proto 1066 values are not considered in this document." 1068 o Replacement of "DTLS connection" with "DTLS association" 1069 throughout the document. 1071 o In sections Section 5.1.1.2 and Section 5.1.2.2 removal of the 1072 sentences "This document also does not specify multiplexing rules 1073 for this attribute for SCTP or SCTP/DTLS proto values". 1075 o In the text related to "Subsequent SDP answer" in section 1076 Section 5.2.5 replacement of "The DTLS/SCTP association remains 1077 open ..." with "The SCTP association remains open ...". 1079 o In the text after the second SDP answer in section Section 6 1080 replacement of "... (after SCTP/DTLS association is setup)" with 1081 "... (after the SCTP association is set up)". 1083 o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative 1084 references. 1086 o Addition of "a=dtls-id" attribute lines to the SDP offer/answer 1087 examples in Section 6. 1089 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 1091 o Addition of definition of "data channel subprotocol" to Section 3 1092 as proposed on the MMUSIC list, https://www.ietf.org/mail- 1093 archive/web/mmusic/current/msg15827.html. 1095 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative 1096 references. 1098 o Updates of tables in Section 8.2.1 and Section 8.2.2 as per 1099 section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis]. 1101 o Addition of new Section 8.3. 1103 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 1105 o Addition of two new paragraphs to Section 5.1.2.1 regarding 1106 subprotocol attribute relationship with transport protocol. 1108 o Addition of a note to Section 8.1 regarding subprotocols 1109 simultaneously defined for data channel and Websocket usage. 1111 o Addition of two further SDP offer/answer considerations to 1112 Section 5.2.5 regarding unknown subprotocol attributes and known 1113 subprotocol attributes with unknown data channel transport related 1114 semantic. 1116 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' 1118 o Changes addressing Christian Groves's WGLC review comments raised 1119 in http://www.ietf.org/mail-archive/web/mmusic/current/ 1120 msg15357.html and http://www.ietf.org/mail- 1121 archive/web/mmusic/current/msg15359.html. 1123 10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' 1125 o In IANA registration Section 8.2.1 and Section 8.2.2 replacement 1126 of contact name and e-mail address with "MMUSIC Chairs" and 1127 "mmusic-chairs@ietf.org". 1129 o In Section 5.1.2.1 replacement of "Thus in the example above, the 1130 original attribute line "a=accept- types:text/plain" is 1131 represented by the attribute line "a=dcsa:2 accept-types:text/ 1132 plain", which specifies that this instance of MSRP being 1133 transported on the SCTP association using the data channel with 1134 stream id 2 accepts plain text files." with "... which specifies 1135 that this instance of the MSRP subprotocol being transported ...". 1137 o The last paragraph of Section 5.1.2.1 started with "Note: This 1138 document does not provide a complete specification ...". Removal 1139 of "Note:" and move of this paragraph to the introduction in 1140 Section 1 as last paragraph. 1142 o Section 5.1.2's headline was "Subprotocol Specific Attributes". 1143 Change of this headline to "Other Media Level Attributes" and 1144 adaptations of the first paragraph of this section and the first 1145 paragraph of Section 5.1.2.1 in order to clarify that not only 1146 those attributes may be encapsulated in a "dcsa" attribute, which 1147 are specifically defined for the subprotocol, but that also other 1148 attributes may be encapsulated if they are related to the specific 1149 subprotocol instance. 1151 o Move of the last but one paragraph of Section 5.1.2.1 starting 1152 with "The same syntax applies to ..." right in front of the formal 1153 syntax definition of the "dcsa" attribute. 1155 o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 1156 in order not to explicitly restrict usage of the "a=dcmap:" and 1157 "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ 1158 SCTP" or "TCP/DTLS/SCTP". 1160 10.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 1162 o In Section 5.1.1.5 the first (and only) paragraph was "The 1163 'subprotocol' parameter indicates which protocol the client 1164 expects to exchange via the channel. 'Subprotocol' is an optional 1165 parameter. If the 'subprotocol' parameter is not present, then 1166 its value defaults to the empty string." Replacement of this 1167 paragraph with following two paragraphs: 1169 * The 'subprotocol' parameter indicates which protocol the client 1170 expects to exchange via the channel. This parameter maps to 1171 the 'Protocol' parameter defined in 1172 [I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new 1173 subprotocol parameter values are registered. 'Subprotocol' is 1174 an optional parameter. If the 'subprotocol' parameter is not 1175 present, then its value defaults to the empty string. 1177 * Note: The empty string MAY also be explicitly used as 1178 'subprotocol' value, such that 'subprotocol=""' is equivalent 1179 to the 'subprotocol' parameter not being present at all. 1180 [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN 1181 message's 'Subprotocol' value to be an empty string. 1183 o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of 1184 normative references. 1186 o Addition of dcmap attribute specific IANA registration 1187 Section 8.2.1. 1189 o Addition of dcsa attribute specific IANA registration 1190 Section 8.2.2. 1192 o Addition of new Section 5.1.1.2 describing the mux category of the 1193 dcmap SDP attribute. This section and the new "a=dcsa:" attribute 1194 related mux category section are similar to the "Mux Category" 1195 sections of the "a=sctp-port:" and "a=max-message-size:" 1196 attributes in [I-D.ietf-mmusic-sctp-sdp]. 1198 o Addition of new Section 5.1.2.2 describing the mux category of the 1199 dcsa SDP attribute. 1201 10.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 1203 o In Section 1 replacement of "RTCWeb leaves it open for other 1204 applications to use data channels and its in-band DCEP or out-of- 1205 band non-DCEP protocols for creating them" with "... to use data 1206 channels and its in-band DCEP or other in-band or out-of-band 1207 protocols for creating them". Additionally replacement of "In 1208 particular, the SDP offer generated by the application includes no 1209 channel-specific information" with "... generated by the RTCweb 1210 data channel stack includes no channel-specific information". 1212 o Move of former section 5 ("Data Channels") to new Appendix A and 1213 removal of JavaScript API specific discussions from this moved 1214 text (like mentioning of data channel stack specific states). 1215 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 1216 Section 5. 1218 o In Section 5: 1220 * Relacement of Section 5's first paragraph "This section defines 1221 a method of non-DCEP negotiation by which two clients can 1222 negotiate data channel-specific and subprotocol-specific 1223 parameters, using the out-of-band SDP offer/answer exchange. 1224 This SDP extension can only be used with the SDP offer/answer 1225 model." with "This section defines an SDP extension by which 1226 two clients can negotiate data channel-specific and 1227 subprotocol-specific parameters without using DCEP 1228 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 1229 defines usage in the context of SDP offer/answer." 1231 * Addition of new paragraph: "Appendix A provides information how 1232 data channels work in general and especially summarizes some 1233 key aspects, which should be considered for the negotiation of 1234 data channels if DCEP is not used." 1236 o In Section 5.1.1 replacement of "The intention of exchanging these 1237 attributes is to create data channels on both the peers with the 1238 same set of attributes without actually using the DCEP 1239 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 1240 these attributes is to create, on two peers, without use of DCEP 1241 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 1242 directed data channels having the same set of attributes". 1244 o In Section 5.1.1.6 replacement of "The 'max-retr' parameter 1245 indicates the maximal number a user message will be retransmitted" 1246 with "The 'max-retr' parameter indicates the maximal number of 1247 times a user message will be retransmitted". 1249 o In Section 5.2.1 replacement of "However, an SDP offer/answer 1250 exchange MUST NOT be initiated if the associated SCTP stream is 1251 already negotiated via DCEP" with "However, an SCTP stream MUST 1252 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 1253 answer exchange if the associated SCTP stream has already been 1254 negotiated via DCEP". 1256 o In the examples in Section 6 addition of the previously missing 1257 colons to the "a=sctp-port" attribute lines. 1259 10.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 1261 o Move of reference [I-D.ietf-rtcweb-jsep] from the list of 1262 normative references to the list of informative references. 1264 o Addition of [IANA-SDP-Parameters] to the list of informative 1265 references and addition of following two sentences to the first 1266 paragraph after the ABNF definition: "Note however that not all 1267 SDP attributes are suitable as "a=dcsa:" parameter. 1268 [IANA-SDP-Parameters] contains the lists of IANA registered 1269 session and media level or media level only SDP attributes." 1271 o In the introduction replacement of last sentence "This document 1272 defines SDP-based out-of-band negotiation procedures to establish 1273 data channels for transport of well-defined subprotocols" with 1274 "This document defines SDP offer/answer negotiation procedures to 1275 establish data channels for transport of well-defined 1276 subprotocols, to enable out-of-band negotiation". 1278 o Throughout the document replacement of "external negotiation" with 1279 "SDP offer/answer negotiation" and removal of term "external 1280 negotiation" from the terminology list in Section 3. 1282 o Throughout the document replacement of "internal negotiation" with 1283 "DCEP" and removal of terms "internal negotiation" and "in-band 1284 negotiation" from the terminology list in Section 3. 1286 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1287 terms. 1289 o In Section 5.2.1 replacement of sentence "However, a single stream 1290 is managed using one method at a time." with "However, an SDP 1291 offer/answer exchange MUST NOT be initiated if the associated SCTP 1292 stream is already negotiated via DCEP". 1294 o In Section 5.2.2 replacement of sentence "By definition max-retr 1295 and max-time are mutually exclusive, so only one of them can be 1296 present in a=dcmap" with "By definition max-retr and max-time are 1297 mutually exclusive, so at most one of them MAY be present in 1298 a=dcmap". 1300 o Move of reference [WebRtcAPI] from list of normative references to 1301 list of informative references. 1303 o Removal of almost all text parts, which discussed JavaScript or 1304 other API specific aspects. Such API specific aspects were mainly 1305 discussed in sub-sections of Section 5 and Section 5 of draft- 1306 ietf-mmusic-data-channel-sdpneg-02. 1308 10.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1310 o New Section 4 regarding applicability to SDP offer/answer only. 1312 o Addition of new Section 8.1 "Subprotocol identifiers" as 1313 subsection of the "IANA Considerations" related Section 8. Also 1314 removal of the temporary note "To be completed. As [I-D.ietf- 1315 rtcweb-data-protocol] this document should refer to IANA's 1316 WebSocket Subprotocol Name Registry defined in [RFC6455]." 1318 o In Section 5.2.2: 1320 * In the first paragraph replacement of the sentence "If an SDP 1321 offer contains both of these parameters then such an SDP offer 1322 will be rejected." with "If an SDP offer contains both of these 1323 parameters then the receiver of such an SDP offer MUST reject 1324 the SDP offer." 1326 * In the second paragraph capitalization of "shall" and "may" 1327 such that both sentences now read: "The SDP answer SHALL echo 1328 the same subprotocol, max-retr, max-time, ordered parameters, 1329 if those were present in the offer, and MAY include a label 1330 parameter. They MAY appear in any order, which could be 1331 different from the SDP offer, in the SDP answer." 1333 * In the third paragraph replacement of the sentence "The same 1334 information MUST be replicated without changes in any 1335 subsequent offer or answer, as long as the data channel is 1336 still opened at the time of offer or answer generation." with 1337 "When sending a subsequent offer or an answer, and for as long 1338 as the data channel is still open, the sender MUST replicate 1339 the same information.". 1341 o In Section 5.2.2 the mapping of data channel types defined in 1342 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1343 parameters were illustrated using example "a=dcmap" attribute 1344 lines. Replacement of these example "a=dcmap" attribute lines 1345 with just the "a=dcmap" attribute parameters being relevant for 1346 the channel type. 1348 o In Section 5.2.5 the description of bullet point "SDP offer has no 1349 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1350 No data channel negotiated yet." Replacement of this description 1351 with "Initial SDP offer: No data channel is negotiated yet. The 1352 DTLS connection and SCTP association is negotiated and, if agreed, 1353 established as per [I-D.ietf-mmusic-sctp-sdp]." 1355 o In Section 5.2.5 in both bullet points related to "Subsequent SDP 1356 offer" and "Subsequent SDP answer" replacement of "All the 1357 externally negotiated data channels must be closed now." with "All 1358 the externally negotiated data channels are expected be closed 1359 now.". 1361 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1362 replacement of the two occurrences of "must" with "MUST". 1364 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1365 there was a comment saying that "Either only maxretr-opt or 1366 maxtime-opt is present. Both MUST not be present." Removal of 1367 the second normative sentence and instead addition of following 1368 new paragraph to the end of this section: "Within an 'a=dcmap' 1369 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1370 parameter or one 'maxtime-opt' parameter is present. Both MUST 1371 NOT be present." 1373 o In Section 5.1.1.8 replacement of the first sentence "The 1374 'ordered' parameter with value "true" indicates that DATA chunks 1375 in the channel MUST be dispatched to the upper layer by the 1376 receiver while preserving the order." with "The 'ordered' 1377 parameter with value "true" indicates that the receiver MUST 1378 dispatch DATA chunks in the data channel to the upper layer while 1379 preserving the order.". 1381 o In Section 5.2.3's first paragraph replacement of the one 1382 occurrence of "must" with "..., it MUST wait until ...". 1384 o In Section 5.2.4: 1386 * In the second paragraph replacement of "must" with "... whether 1387 this closing MUST in addition ..." 1389 * In the third paragraph replacement of the sentence "The port 1390 value for the "m" line SHOULD not be changed (e.g., to zero) 1391 when closing a data channel ..." with "The offerer SHOULD NOT 1392 change the port value for the "m" line (e.g., to zero) when 1393 closing a data channel ...". 1395 * In the last but two paragraph replacement of the sentence "... 1396 then an SDP offer which excludes this closed data channel 1397 SHOULD be generated." with "... then the client SHOULD generate 1398 an SDP offer which excludes this closed data channel.". 1400 * In the last but one paragraph replacement of "must" with "The 1401 application MUST also close...". 1403 o In Section 5.1.2 addition of following note after the formal 1404 definition of the 'a=dcsa' attribute: "Note that the above 1405 reference to RFC 4566 defines were the attribute definition can be 1406 found; it does not provide any limitation on support of attributes 1407 defined in other documents in accordance with this attribute 1408 definition." 1410 10.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1412 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1413 channel consisting of paired SCTP outbound and inbound streams." 1414 Replacement of this definition with "Data channel: A WebRTC data 1415 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1416 consistent usage of "data channel" in the remainder of the 1417 document including the document's headline." 1419 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1420 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1421 In particular we expect "webrtc-datachannel" to become a more 1422 general term.' 1424 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1426 o In Section 5.1.1 removal of the example dcmap attribute line 1427 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1428 already four examples right after the ABNF rules in 1429 Section 5.1.1.1. Corresponding removal of following related note: 1430 "Note: This document does not provide a complete specification of 1431 how to negotiate the use of a WebRTC data channel to transport 1432 BFCP. Procedures specific to each subprotocol such as BFCP will 1433 be documented elsewhere. The use of BFCP is only an example of 1434 how the generic procedures described herein might apply to a 1435 specific subprotocol." 1437 o In Section 5.1.1 removal of following note: "Note: This attribute 1438 is derived from attribute "webrtc-DataChannel", which was defined 1439 in old version 03 of the following draft, but which was removed 1440 along with any support for SDP external negotiation in subsequent 1441 versions: [I-D.ietf-mmusic-sctp-sdp]." 1443 o Insertion of following new sentence to the beginning of 1444 Section 5.1.1.1: "dcmap is a media level attribute having 1445 following ABNF syntax:" 1447 o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id 1448 specifying sentence, which previously was placed right before the 1449 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1450 parameter and is noted directly after the "a=dcmap:" attribute's 1451 colon' as this information is part of the ABNF specification. 1453 o In Section 5.1.1.1 modification of the 'ordering-value' values 1454 from "0" or "1" to "true" or "false". Corresponding text 1455 modifications in Section 5.1.1.8. 1457 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1458 to rule name "escaped-char", which was not defined. Instead a 1459 rule with name "escaped" was defined. Renamed that rule's name to 1460 "escaped-char". 1462 o Insertion of a dedicated note right after the "a=dcmap:4" 1463 attribute example in Section 5.1.1.1 regarding the non-printable 1464 "escaped-char" character within the "label" value. 1466 o In Section 5.1.2's second paragraph replacement of "sctp stream 1467 identifier" with "SCTP stream identifier". 1469 o In first paragraph of Section 5.2.1 replacement of first two 1470 sentences 'For the SDP-based external negotiation described in 1471 this document, the initial offerer based "SCTP over DTLS" owns by 1472 convention the even stream identifiers whereas the initial 1473 answerer owns the odd stream identifiers. This ownership is 1474 invariant for the whole lifetime of the signaling session, e.g. it 1475 does not change if the initial answerer sends a new offer to the 1476 initial offerer.' with 'If an SDP offer/answer exchange (could be 1477 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1478 TCP/DTLS/SCTP based media description being accepted, and if this 1479 SDP offer/answer exchange results in the establishment of a new 1480 SCTP association, then the SDP offerer owns the even SCTP stream 1481 ids of this new SCTP association and the answerer owns the odd 1482 SCTP stream identifiers. If this "m" line is removed from the 1483 signaling session (its port number set to zero), and if usage of 1484 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1485 renegotiated later on, then the even and odd SCTP stream 1486 identifier ownership is redetermined as well as described above.' 1488 o In Section 5.2.3 the first action of an SDP answerer, when 1489 receiving an SDP offer, was described as "Applies the SDP offer. 1490 Note that the browser ignores data channel specific attributes in 1491 the SDP." Replacement of these two sentences with "Parses and 1492 applies the SDP offer. Note that the typical parser normally 1493 ignores unknown SDP attributes, which includes data channel 1494 related attributes." 1496 o In Section 5.2.3 the second sentence of the third SDP answerer 1497 action was "Note that the browser is asked to create data channels 1498 with stream identifiers not "owned" by the agent.". Replacement 1499 of this sentence with "Note that the agent is asked to create data 1500 channels with SCTP stream identifiers contained in the SDP offer 1501 if the SDP offer is accepted." 1503 o In Section 5.2.4 the third paragraph began with "A data channel 1504 can be closed by sending a new SDP offer which excludes the dcmap 1505 and dcsa attribute lines for the data channel. The port value for 1506 the m line should not be changed (e.g., to zero) when closing a 1507 data channel (unless all data channels are being closed and the 1508 SCTP association is no longer needed), since this would close the 1509 SCTP association and impact all of the data channels. If the 1510 answerer accepts the SDP offer then it MUST also exclude the 1511 corresponding attribute lines in the answer. ..." Replacement of 1512 this part with "The intention to close a data channel can be 1513 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1514 and "a=dcsa:" attribute lines for the data channel. The port 1515 value for the "m" line SHOULD not be changed (e.g., to zero) when 1516 closing a data channel (unless all data channels are being closed 1517 and the SCTP association is no longer needed), since this would 1518 close the SCTP association and impact all of the data channels. 1519 If the answerer accepts the SDP offer then it MUST close those 1520 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1521 excluded from the received SDP offer, unless those data channels 1522 were already closed, and it MUST also exclude the corresponding 1523 attribute lines in the answer." 1525 o In Section 5.2.4 the hanging text after the third paragraph was 1526 "This delayed close is to handle cases where a successful SDP 1527 answer is not received, in which case the state of session should 1528 be kept per the last successful SDP offer/answer." Replacement of 1529 this sentence with "This delayed closure is RECOMMENDED in order 1530 to handle cases where a successful SDP answer is not received, in 1531 which case the state of the session SHOULD be kept per the last 1532 successful SDP offer/answer." 1534 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1535 Section 5.1.1 contained already procedural descriptions related to 1536 data channel reliability negotiation. Creation of new 1537 Section 5.2.2 and moval of reliability negotiation related text to 1538 this new section. 1540 10.12. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1542 o Removal of note "[ACTION ITEM]" from section "subprotocol 1543 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1544 should refer to IANA's WebSocket Subprotocol Name Registry defined 1545 in [RFC6455]. 1547 o In whole document, replacement of "unreliable" with "partially 1548 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1549 [I-D.ietf-rtcweb-data-protocol] in most places. 1551 o Clarification of the semantic if the "max-retr" parameter is not 1552 present in an a=dcmap attribute line. In section "max-retr 1553 parameter" the sentence "The max-retr parameter is optional with 1554 default value unbounded" was replaced with "The max-retr parameter 1555 is optional. If the max-retr parameter is not present, then the 1556 maximal number of retransmissions is determined as per the generic 1557 SCTP retransmission rules as specified in [RFC4960]". 1559 o Clarification of the semantic if the "max-time" parameter is not 1560 present in an a=dcmap attribute line. In section "max-time 1561 parameter" the sentence "The max-time parameter is optional with 1562 default value unbounded" was replaced with "The max-time parameter 1563 is optional. If the max-time parameter is not present, then the 1564 generic SCTP retransmission timing rules apply as specified in 1565 [RFC4960]". 1567 o In section "label parameter" the sentence "Label is a mandatory 1568 parameter." was removed and following new sentences (including the 1569 note) were added: "The 'label' parameter is optional. If it is 1570 not present, then its value defaults to the empty string. Note: 1571 The empty string may also be explicitly used as 'label' value, 1572 such that 'label=""' is equivalent to the 'label' parameter not 1573 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1574 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1576 o In section "subprotocol parameter" the sentence "Subprotocol is a 1577 mandatory parameter." was replaced with "'Subprotocol' is an 1578 optional parameter. If the 'subprotocol' parameter is not 1579 present, then its value defaults to the empty string." 1581 o In the "Examples" section, in the first two SDP offer examples in 1582 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1583 'label="BFCP"'. 1585 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1586 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1587 replaced with "a=max-message-size" attribute lines, as per draft- 1588 ietf-mmusic-sctp-sdp-12. 1590 10.13. Changes against '-01' 1592 o Formal syntax for dcmap and dcsa attribute lines. 1594 o Making subprotocol as an optional parameter in dcmap. 1596 o Specifying disallowed parameter combinations for max-time and max- 1597 retr. 1599 o Clarifications on WebRTC data channel close procedures. 1601 10.14. Changes against '-00' 1603 o Revisions to identify difference between internal and external 1604 negotiation and their usage. 1606 o Introduction of more generic terminology, e.g. "application" 1607 instead of "browser". 1609 o Clarification of how "max-retr and max-time affect the usage of 1610 unreliable and reliable WebRTC data channels. 1612 o Updates of examples to take into account the SDP syntax changes 1613 introduced with draft-ietf-mmusic-sctp-sdp-07. 1615 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1616 attributes as this is now contained in the a=sctp-port attribute, 1617 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1618 association on top of the DTLS connection. 1620 11. References 1622 11.1. Normative References 1624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1625 Requirement Levels", BCP 14, RFC 2119, 1626 DOI 10.17487/RFC2119, March 1997, 1627 . 1629 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1630 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1631 July 2006, . 1633 [I-D.ietf-mmusic-rfc4566bis] 1634 Handley, M., Jacobson, V., Perkins, C., and A. Begen, 1635 "SDP: Session Description Protocol", draft-ietf-mmusic- 1636 rfc4566bis-17 (work in progress), June 2016. 1638 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1639 with Session Description Protocol (SDP)", RFC 3264, 1640 DOI 10.17487/RFC3264, June 2002, 1641 . 1643 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1644 Specifications: ABNF", STD 68, RFC 5234, 1645 DOI 10.17487/RFC5234, January 2008, 1646 . 1648 [I-D.ietf-rtcweb-data-channel] 1649 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1650 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1651 progress), January 2015. 1653 [I-D.ietf-mmusic-sctp-sdp] 1654 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1655 "Session Description Protocol (SDP) Offer/Answer 1656 Procedures For Stream Control Transmission Protocol (SCTP) 1657 over Datagram Transport Layer Security (DTLS) Transport.", 1658 draft-ietf-mmusic-sctp-sdp-20 (work in progress), December 1659 2016. 1661 [I-D.ietf-mmusic-sdp-mux-attributes] 1662 Nandakumar, S., "A Framework for SDP Attributes when 1663 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1664 (work in progress), December 2016. 1666 11.2. Informative References 1668 [I-D.ietf-rtcweb-data-protocol] 1669 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1670 Establishment Protocol", draft-ietf-rtcweb-data- 1671 protocol-09 (work in progress), January 2015. 1673 [I-D.ietf-mmusic-dtls-sdp] 1674 Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer 1675 Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-15 (work 1676 in progress), October 2016. 1678 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1679 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1680 . 1682 [IANA-SDP-Parameters] 1683 "Session Description Protocol (SDP) Parameters", Internet 1684 Assigned Numbers Authority Protocol Assignments Session 1685 Description Protocol (SDP) Parameters, 1686 . 1689 [WebRtcAPI] 1690 Bergkvist, A., Burnett, D., Jennings, C., and A. 1691 Narayanan, "WebRTC 1.0: Real-time Communication Between 1692 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1693 February 2015, 1694 . 1696 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1697 DCEP 1699 This appendix summarizes how data channels work in general and 1700 discusses some key aspects, which should be considered for the out- 1701 of-band negotiation of data channels if DCEP is not used. 1703 A WebRTC application creates a data channel by providing a number of 1704 setup parameters (subprotocol, label, maximal number of 1705 retransmissions, maximal retransmission time, order of delivery, 1706 priority). The application also specifies if it wants to make use of 1707 the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if 1708 the application intends to negotiate data channels using the SDP 1709 offer/answer protocol. 1711 In any case, the SDP offer generated by the application is per 1712 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1713 the SCTP association on top of which data channels will run: 1715 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1716 c=IN IP4 79.97.215.79 1717 a=max-message-size:100000 1718 a=sctp-port:5000 1719 a=setup:actpass 1720 a=fingerprint:SHA-1 \ 1721 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1723 Note: A WebRTC application will only use "m" line format "webrtc- 1724 datachannel", and will not use other formats in the "m" line for 1725 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1726 only one SCTP association to be established on top of a DTLS 1727 association. 1729 Note: The above SDP media description does not contain any channel- 1730 specific information. 1732 A.1. Stream Identifier Numbering 1734 Independently from the requested type of negotiation, the application 1735 creating a data channel can either pass to the data channel stack the 1736 stream identifier to assign to the data channel or else let the data 1737 channel stack pick one identifier from the unused ones. 1739 To avoid glare situations, each endpoint can moreover own an 1740 exclusive set of stream identifiers, in which case an endpoint can 1741 only create a data channel with a stream identifier it owns. 1743 Which set of stream identifiers is owned by which endpoint is 1744 determined by convention or other means. 1746 For data channels negotiated with the DCEP, one endpoint owns by 1747 convention the even stream identifiers, whereas the other owns the 1748 odd stream identifiers, as defined in 1749 [I-D.ietf-rtcweb-data-protocol]. 1751 For data channels negotiated via some protocol different from 1752 DCEP, no convention is defined by default. 1754 A.2. Generic Data Channel Negotiation Not Using DCEP 1756 A.2.1. Overview 1758 DCEP negotiation only provides for negotiation of data channel 1759 transport parameters and does not provide for negotiation of 1760 subprotocol specific parameters. DCEP-less data channel negotiation 1761 can be defined to allow negotiation of parameters beyond those 1762 handled by DCEP, e.g., parameters specific to the subprotocol 1763 instantiated on a particular data channel. 1765 The following procedures are common to all methods of data channel 1766 negotiation not using DCEP, whether in-band (communicated using 1767 proprietary means on an already established data channel) or out-of- 1768 band (using SDP offer/answer or some other protocol associated with 1769 the signaling channel). 1771 A.2.2. Opening a Data Channel 1773 In the case of DCEP-less negotiation, the endpoint application has 1774 the option to fully control the stream identifier assignments. 1775 However these assignments have to coexist with the assignments 1776 controlled by the data channel stack for the DCEP negotiated data 1777 channels (if any). It is the responsibility of the application to 1778 ensure consistent assignment of stream identifiers. 1780 When the application requests the creation of a new data channel to 1781 be set up via DCEP-less negotiation, the data channel stack creates 1782 the data channel locally without sending any DATA_CHANNEL_OPEN 1783 message in-band. However, even if the ICE (Interactive Connectivity 1784 Establishment), DTLS and SCTP procedures were already successfully 1785 completed, the application can't send data on this data channel until 1786 the negotiation is complete with the peer. This is because the peer 1787 needs to be aware of and accept the usage of this data channel. The 1788 peer, after accepting the data channel offer, can start sending data 1789 immediately. This implies that the offerer may receive data channel 1790 subprotocol messages before the negotiation is complete and the 1791 application should be ready to handle it. 1793 If the peer rejects the data channel part of the offer then it 1794 doesn't have to do anything as the data channel was not created using 1795 the stack. The offerer on the other hand needs to close the data 1796 channel that was opened by invoking relevant data channel stack API 1797 procedures. 1799 It is also worth noting that a data channel stack implementation may 1800 not provide any API to create and close data channels; instead the 1801 data channels may be used on the fly as needed just by communicating 1802 via non-DCEP means or by even having some local configuration/ 1803 assumptions on both the peers. 1805 The application then negotiates the data channel properties and 1806 subprotocol properties with the peer's application using a mechanism 1807 different from DCEP. 1809 The peer then symmetrically creates a data channel with these 1810 negotiated data channel properties. This is the only way for the 1811 peer's data channel stack to know which properties to apply when 1812 transmitting data on this channel. The data channel stack must allow 1813 data channel creation with any non-conflicting stream identifier so 1814 that both peers can create the data channel with the same stream 1815 identifier. 1817 A.2.3. Closing a Data Channel 1819 When the application requests the closing of a data channel 1820 negotiated without DCEP, the data channel stack always performs an 1821 SCTP SSN reset for this channel. 1823 Depending upon the method used for DCEP-less negotiation and the 1824 subprotocol associated with the data channel, the closing might in 1825 addition be signaled to the peer via SDP offer/answer negotiation. 1827 Authors' Addresses 1829 Keith Drage (editor) 1830 Nokia 1831 Quadrant, Stonehill Green, Westlea 1832 Swindon 1833 UK 1835 Email: Keith.Drage@nokia.com 1837 Maridi R. Makaraju (Raju) 1838 Nokia 1839 2000 Lucent Lane 1840 Naperville, Illinois 1841 US 1843 Email: Raju.Makaraju@nokia.com 1845 Juergen Stoetzer-Bradler 1847 Email: Juergen.S-B.ietf@email.de 1849 Richard Ejzak 1850 Unaffiliated 1852 Email: richard.ejzak@gmail.com 1854 Jerome Marcon 1855 Unaffiliated