idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-04.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 (August 4, 2015) is 3188 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5234' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'RFC5547' is defined on line 1288, but no explicit reference was found in the text == Unused Reference: 'RFC6135' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: 'RFC6714' is defined on line 1303, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-14 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-11 Summary: 1 error (**), 0 flaws (~~), 13 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: February 5, 2016 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 August 4, 2015 11 SDP-based Data Channel Negotiation 12 draft-ietf-mmusic-data-channel-sdpneg-04 14 Abstract 16 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 17 charged to provide protocols to support direct interactive rich 18 communications using audio, video, and data between two peers' web- 19 browsers. For the support of data communication, the RTCWeb working 20 group has in particular defined the concept of bi-directional data 21 channels over SCTP, where each data channel might be used to 22 transport other protocols, called sub-protocols. Data channel setup 23 can be done using either the in-band Data Channel Establishment 24 Protocol (DCEP) or using some out-of-band non-DCEP protocol. This 25 document specifies how the SDP offer/answer exchange can be used to 26 achieve such an out-of-band non-DCEP negotiation. Even though data 27 channels are designed for RTCWeb use initially they may be used by 28 other protocols like, but not limited to, the CLUE protocol. This 29 document is intended to be used wherever data channels are used. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 5, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 69 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 5 70 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 5 72 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 5 73 5.1.1.2. dcmap-stream-id Parameter . . . . . . . . . . . . 7 74 5.1.1.3. label Parameter . . . . . . . . . . . . . . . . . 7 75 5.1.1.4. subprotocol Parameter . . . . . . . . . . . . . . 7 76 5.1.1.5. max-retr Parameter . . . . . . . . . . . . . . . 7 77 5.1.1.6. max-time Parameter . . . . . . . . . . . . . . . 8 78 5.1.1.7. ordered Parameter . . . . . . . . . . . . . . . . 8 79 5.1.2. Sub-Protocol Specific Attributes . . . . . . . . . . 8 80 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 10 82 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 10 83 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 11 84 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 13 85 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 14 86 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 17 90 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 18 91 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 18 92 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 18 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 94 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 10.1. Changes against 'draft-ietf-mmusic-data-channel- 96 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 18 97 10.2. Changes against 'draft-ietf-mmusic-data-channel- 98 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 19 99 10.3. Changes against 'draft-ietf-mmusic-data-channel- 100 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 20 101 10.4. Changes against 'draft-ietf-mmusic-data-channel- 102 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 23 103 10.5. Changes against 'draft-ejzak-mmusic-data-channel- 104 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 25 105 10.6. Changes against '-01' . . . . . . . . . . . . . . . . . 26 106 10.7. Changes against '-00' . . . . . . . . . . . . . . . . . 27 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 109 11.2. Informative References . . . . . . . . . . . . . . . . . 28 110 Appendix A. Generic Data Channel Negotiation Aspects When Not 111 Using DCEP . . . . . . . . . . . . . . . . . . . . . 29 112 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 30 113 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 30 114 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 30 115 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 31 116 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 32 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 119 1. Introduction 121 The RTCWeb working group has defined the concept of bi-directional 122 data channels running on top of SCTP/DTLS. RTCWeb leaves it open for 123 other applications to use data channels and its in-band DCEP or other 124 in-band or out-of-band protocols for creating them. Each data 125 channel consists of paired SCTP streams sharing the same SCTP Stream 126 Identifier. Data channels are created by endpoint applications 127 through the WebRTC API, or other users of data channel like CLUE, and 128 can be used to transport proprietary or well-defined protocols, which 129 in the latter case can be signaled by the data channel "sub-protocol" 130 parameter, conceptually similar to the WebSocket "sub-protocol". 131 However, apart from the "sub-protocol" value transmitted to the peer, 132 RTCWeb leaves it open how endpoint applications can agree on how to 133 instantiate a given sub-protocol on a data channel, and whether it is 134 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 135 (or both). In particular, the SDP offer generated by the RTCweb data 136 channel stack includes no channel-specific information. 138 This document defines SDP offer/answer negotiation procedures to 139 establish data channels for transport of well-defined sub-protocols, 140 to enable out-of-band negotiation. 142 2. Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. Terminology 150 This document uses the following terms: 152 Data channel: A WebRTC data channel as specified in 153 [I-D.ietf-rtcweb-data-channel]. 155 Data channel stack: An entity which, upon application request, 156 runs the data channel protocol to keep track of states, sending 157 and receive data. If the application is a browser based 158 JavaScript application then this stack resides in the browser. If 159 the application is a native application then this stack resides in 160 the application and is accessible via some sort of APIs. 162 Data channel properties: Fixed properties assigned to a data 163 channel at the time of its creation. Some of these properties 164 determine the way the data channel stack transmits data on this 165 channel (e.g., stream identifier, reliability, order of 166 delivery...). 168 DCEP: Data Channel Establishment Protocol defined in 169 [I-D.ietf-rtcweb-data-protocol]. 171 In-band: Transmission through the peer-to-peer SCTP association. 173 Out-of-band: Transmission through the application signaling path. 175 Peer: From the perspective of one of the agents in a session, its 176 peer is the other agent. Specifically, from the perspective of 177 the SDP offerer, the peer is the SDP answerer. From the 178 perspective of the SDP answerer, the peer is the SDP offerer. 180 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 181 as specified in [RFC4960]. 183 Stream identifier: The identifier of the outbound and inbound SCTP 184 streams composing a data channel. 186 4. Applicability Statement 188 The mechanism in this specification only applies to the Session 189 Description Protocol (SDP) [RFC4566], when used together with the SDP 190 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 191 scope of this document, and is thus undefined. 193 5. SDP Offer/Answer Negotiation 195 This section defines an SDP extension by which two clients can 196 negotiate data channel-specific and sub-protocol-specific parameters 197 without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP 198 extension only defines usage in the context of SDP offer/answer. 200 Appendix A provides information how data channels work in general and 201 especially summarizes some key aspects, which should be considered 202 for the negotiation of data channels if DCEP is not used. 204 5.1. SDP Syntax 206 Two new SDP attributes are defined to support SDP offer/answer 207 negotiation of data channels. The first attribute provides for 208 negotiation of channel-specific parameters. The second attribute 209 provides for negotiation of sub-protocol-specific parameters. 211 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 213 Associated with the SDP "m" line that defines the SCTP association 214 for data channels (defined in Section 4), each SDP offer and answer 215 includes one "a=dcmap:" attribute that defines the data channel 216 parameters for each data channel to be negotiated. Each such 217 attribute line specifies the following parameters for a data channel: 218 SCTP stream identifier, sub-protocol, label, reliability, order of 219 delivery, and priority. 221 The intention in exchanging these attributes is to create, on two 222 peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched 223 pairs of oppositely directed data channels having the same set of 224 attributes. It is assumed that the data channel properties 225 (reliable/partially reliable, ordered/unordered) are suitable per the 226 sub-protocol transport requirements. 228 5.1.1.1. dcmap Attribute 230 "a=dcmap:" is a media level attribute having following ABNF syntax. 232 Formal Syntax: 234 Name: dcmap 236 Value: dcmap-value 238 Usage Level: media 240 Charset Dependent: no 242 Syntax: 244 dcmap-value = dcmap-stream-id 245 [ SP dcmap-opt *(";" dcmap-opt) ] 246 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 247 / maxretr-opt / maxtime-opt 248 ; Either only maxretr-opt or maxtime-opt 249 ; is present. 251 dcmap-stream-id = 1*DIGIT 252 ordering-opt = "ordered=" ordering-value 253 ordering-value = "true" / "false" 254 subprotocol-opt = "subprotocol=" quoted-string 255 label-opt = "label=" quoted-string 256 maxretr-opt = "max-retr=" maxretr-value 257 maxretr-value = 259 ; number of retransmissions 260 maxtime-opt = "max-time=" maxtime-value 261 maxtime-value = 263 ; milliseconds 265 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 266 quoted-char = SP / quoted-visible 267 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 268 escaped-char = "%" HEXDIG HEXDIG 269 DQUOTE = 270 integer = 272 Examples: 274 a=dcmap:0 275 a=dcmap:1 subprotocol="BFCP";max-time=60000 276 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 277 a=dcmap:3 label="Label 1";ordered=false;max-retr=5 278 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000;max-retr=3 279 Note: The last example (a=dcmap:4) shows a 'label' parameter value 280 which contains one non-printable 'escaped-char' character (the 281 tabulator character). 283 Within an 'a=dcmap' attribute line's 'dcmap-opt' value either only 284 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 285 present. Both MUST NOT be present. 287 5.1.1.2. dcmap-stream-id Parameter 289 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 290 within the SCTP association used to form the data channel. 292 5.1.1.3. label Parameter 294 The 'label' parameter indicates the name of the channel. It 295 represents a label that can be used to distinguish, in the context of 296 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 297 RTCDataChannel objects. This parameter maps to the 'Label' parameter 298 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 299 optional. If it is not present, then its value defaults to the empty 300 string. 302 Note: The empty string MAY also be explicitly used as 'label' value, 303 such that 'label=""' is equivalent to the 'label' parameter not being 304 present at all. [I-D.ietf-rtcweb-data-protocol] allows the 305 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 307 5.1.1.4. subprotocol Parameter 309 The 'subprotocol' parameter indicates which protocol the client 310 expects to exchange via the channel. 'Subprotocol' is an optional 311 parameter. If the 'subprotocol' parameter is not present, then its 312 value defaults to the empty string. 314 5.1.1.5. max-retr Parameter 316 This parameter indicates that the data channel is partially reliable. 317 The 'max-retr' parameter indicates the maximal number of times a user 318 message will be retransmitted. The max-retr parameter is optional. 319 If the max-retr parameter is not present, then the maximal number of 320 retransmissions is determined as per the generic SCTP retransmission 321 rules as specified in [RFC4960]. This parameter maps to the 'Number 322 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 324 5.1.1.6. max-time Parameter 326 This parameter indicates that the data channel is partially reliable. 327 A user message will no longer be transmitted or retransmitted after a 328 specified life-time given in milliseconds in the 'max-time' 329 parameter. The max-time parameter is optional. If the max-time 330 parameter is not present, then the generic SCTP retransmission timing 331 rules apply as specified in [RFC4960]. This parameter maps to the 332 'Lifetime in ms' parameter defined in 333 [I-D.ietf-rtcweb-data-protocol]. 335 5.1.1.7. ordered Parameter 337 The 'ordered' parameter with value "true" indicates that the receiver 338 MUST dispatch DATA chunks in the data channel to the upper layer 339 while preserving the order. The ordered parameter is optional and 340 takes two values: "true" for ordered and "false" for unordered 341 delivery with "true" as the default value. Any other value is 342 ignored and default "ordered=true" is assumed. In the absence of 343 this parameter "ordered=true" is assumed. This parameter maps to the 344 ordered or unordered data channel types as defined in 345 [I-D.ietf-rtcweb-data-protocol]. 347 5.1.2. Sub-Protocol Specific Attributes 349 In the SDP, each data channel declaration MAY also be followed by 350 other SDP attributes specific to the sub-protocol in use. Each of 351 these attributes is represented by one new attribute line, and it 352 includes the contents of a media-level SDP attribute already defined 353 for use with this (sub)protocol in another IETF specification. Sub- 354 protocol-specific attributes might also be defined for exclusive use 355 with data channel transport, but should use the same syntax described 356 here for other sub-protocol-specific attributes. 358 Each sub-protocol specific SDP attribute that would normally be used 359 to negotiate the subprotocol using SDP is replaced with an attribute 360 of the form "a=dcsa:stream-id original-attribute", where dcsa stands 361 for "data channel sub-protocol attribute", stream-id is the SCTP 362 stream identifier assigned to this sub-protocol instance, and 363 original-attribute represents the contents of the sub-protocol 364 related attribute to be included. 366 Formal Syntax: 368 Name: dcsa 370 Value: dcsa-value 372 Usage Level: media 374 Charset Dependent: no 376 Syntax: 378 dcsa-value = stream-id SP attribute 379 attribute = 381 Example: 383 a=dcsa:2 accept-types:text/plain 385 Note that the above reference to RFC 4566 defines where the attribute 386 definition can be found; it does not provide any limitation on 387 support of attributes defined in other documents in accordance with 388 this attribute definition. Note however that not all SDP attributes 389 are suitable as "a=dcsa:" parameter. [IANA-SDP-Parameters] contains 390 the lists of IANA registered session and media level or media level 391 only SDP attributes. 393 Thus in the example above, the original attribute line "a=accept- 394 types:text/plain" is represented by the attribute line "a=dcsa:2 395 accept-types:text/plain", which specifies that this instance of MSRP 396 being transported on the SCTP association using the data channel with 397 stream id 2 accepts plain text files. 399 As opposed to the data channel "a=dcmap:" attribute parameters, these 400 parameters are subject to offer/answer negotiation following the 401 procedures defined in the sub-protocol specific documents. 403 The same syntax applies to any other SDP attribute required for 404 negotiation of this instance of the sub-protocol. 406 Note: This document does not provide a complete specification of how 407 to negotiate the use of a data channel to transport MSRP. Procedures 408 specific to each sub-protocol such as MSRP will be documented 409 elsewhere. The use of MSRP is only an example of how the generic 410 procedures described herein might apply to a specific sub-protocol. 412 5.2. Procedures 414 5.2.1. Managing Stream Identifiers 416 If an SDP offer/answer exchange (could be the initial or a subsequent 417 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 418 description being accepted, and if this SDP offer/answer exchange 419 results in the establishment of a new SCTP association, then the SDP 420 offerer owns the even SCTP stream ids of this new SCTP association 421 and the answerer owns the odd SCTP stream identifiers. If this "m" 422 line is removed from the signaling session (its port number set to 423 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 424 SCTP based "m" line is renegotiated later on, then the even and odd 425 SCTP stream identifier ownership is redetermined as well as described 426 above. 428 This specification allows simultaneous use of SDP offer/answer and 429 DCEP negotiation. However, an SCTP stream MUST NOT be referenced in 430 a dcmap or dcsa attribute of an SDP offer/answer exchange if the 431 associated SCTP stream has already been negotiated via DCEP. Stream 432 ids that are not currently used in SDP can be used for DCEP 433 negotiation. Stream id allocation per SDP offer/answer negotiation 434 may not align with DTLS role based allocation. This could cause 435 glare conditions when one side trying to do SDP offer/answer 436 negotiation on a stream id while the other end trying to open a data 437 channel on the same stream id using DCEP negotiation. To avoid these 438 glare conditions this specification recommends that the data channel 439 stack user always selects stream ids per above described SDP offer/ 440 answer rule even when DCEP negotiation is used. To avoid glare 441 conditions, it is possible to come up with a different stream id 442 allocation scheme, but such schemes are outside the scope of this 443 specification. 445 5.2.2. Negotiating Data Channel Parameters 447 Conveying a reliable data channel is achieved by including neither 448 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 449 "a=dcmap" attribute line. Conveying a partially reliable data 450 channel is achieved by including only one of 'max-retr' or 'max- 451 time'. By definition max-retr and max-time are mutually exclusive, 452 so at most one of them MAY be present in the "a=dcmap" attribute 453 line. If an SDP offer contains both of these parameters then the 454 receiver of such an SDP offer MUST reject the SDP offer. If an SDP 455 answer contains both of these parameters then the offerer MAY treat 456 it as an error and MAY assume the associated SDP offer/answer failed 457 and MAY take appropriate recovery actions. These recovery options 458 are outside the scope of this specification. 460 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 461 ordered parameters, if those were present in the offer, and MAY 462 include a label parameter. They MAY appear in any order, which could 463 be different from the SDP offer, in the SDP answer. 465 When sending a subsequent offer or an answer, and for as long as the 466 data channel is still open, the sender MUST replicate the same 467 information. 469 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 470 mapped to SDP in the following manner, where "ordered=true" is the 471 default and may be omitted: 473 DATA_CHANNEL_RELIABLE 474 ordered=true 476 DATA_CHANNEL_RELIABLE_UNORDERED 477 ordered=false 479 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 480 ordered=true;max-retr= 482 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 483 ordered=false;max-retr= 485 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 486 ordered=true;max-time= 488 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 489 ordered=false;max-time= 491 5.2.3. Opening a Data Channel 493 The procedure for opening a data channel using SDP offer/answer 494 negotiation starts with the agent preparing to send an SDP offer. If 495 a peer receives an SDP offer before starting to send a new SDP offer 496 with data channels that are to be SDP offer/answer negotiated, or 497 loses an SDP offer glare resolution procedure in this case, it MUST 498 wait until the ongoing SDP offer/answer completes before resuming the 499 SDP offer/answer negotiation procedure. 501 The agent that intends to send an SDP offer to create data channels 502 through SDP offer/answer negotiation performs the following: 504 o Creates data channels using stream identifiers from the owned set 505 (see Section 5.2.1). 507 o Generates a new SDP offer. 509 o Determines the list of stream identifiers assigned to data 510 channels opened through SDP offer/answer negotiation. 512 o Completes the SDP offer with the dcmap and dcsa attributes needed, 513 if any, for each SDP offer/answer negotiated data channel, as 514 described in Section 5.1 and in Section 5.2.2. 516 o Sends the SDP offer. 518 The peer receiving such an SDP offer performs the following: 520 o Parses and applies the SDP offer. Note that the typical parser 521 normally ignores unknown SDP attributes, which includes data 522 channel related attributes. 524 o Analyzes the channel parameters and sub-protocol attributes to 525 determine whether to accept each offered data channel. 527 o For accepted data channels, it creates peer instances for the data 528 channels with the agent using the channel parameters described in 529 the SDP offer. Note that the agent is asked to create data 530 channels with SCTP stream identifiers contained in the SDP offer 531 if the SDP offer is accepted. 533 o Generates an SDP answer. 535 o Completes the SDP answer with the dcmap and optional dcsa 536 attributes needed for each SDP offer/answer negotiated data 537 channel, as described in Section 5.1 and in Section 5.2.2. 539 o Sends the SDP answer. 541 The agent receiving such an SDP answer performs the following: 543 o Closes any created data channels for which the expected dcmap and 544 dcsa attributes are not present in the SDP answer. 546 o Applies the SDP answer. 548 Each agent application MUST wait to send data until it has 549 confirmation that the data channel at the peer is instantiated. For 550 WebRTC, this is when both data channel stacks have channel parameters 551 instantiated. This occurs: 553 o At both peers when a data channel is created without an 554 established SCTP association, as soon as the SCTP association is 555 successfully established. 557 o At the agent receiving an SDP offer for which there is an 558 established SCTP association, as soon as it creates an SDP offer/ 559 answer negotiated data channel based on information signaled in 560 the SDP offer. 562 o At the agent sending an SDP offer to create a new SDP offer/answer 563 negotiated data channel for which there is an established SCTP 564 association, when it receives the SDP answer confirming acceptance 565 of the data channel or when it begins to receive data on the data 566 channel from the peer, whichever occurs first. 568 Note: DCEP is not used, that is neither the SDP offerer nor the SDP 569 answerer send an in-band DCEP DATA_CHANNEL_OPEN message. 571 5.2.4. Closing a Data Channel 573 When the application requests the closing of a data channel that was 574 negotiated via SDP offer/answer, the data channel stack always 575 performs an SCTP SSN reset for this channel. 577 It is specific to the sub-protocol whether this closing MUST in 578 addition be signaled to the peer via a new SDP offer/answer exchange. 580 The intention to close a data channel can be signaled by sending a 581 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 582 lines for the data channel. The offerer SHOULD NOT change the port 583 value for the "m" line (e.g. to zero) when closing a data channel 584 (unless all data channels are being closed and the SCTP association 585 is no longer needed), since this would close the SCTP association and 586 impact all of the data channels. If the answerer accepts the SDP 587 offer then the answerer MUST close those data channels whose 588 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 589 received SDP offer, unless those data channels were already closed, 590 and the answerer MUST also exclude the corresponding attribute lines 591 in the answer. In addition to that, the SDP answerer MAY exclude 592 other data channels which were closed but not yet communicated to the 593 peer. So, the offerer MUST inspect the answer to see if it has to 594 close other data channels which are now not included in the answer. 596 If a new SDP offer/answer is used to close data channels then the 597 data channel(s) SHOULD only be closed by the answerer/offerer after a 598 successful SDP answer is sent/received. 600 This delayed closure is RECOMMENDED in order to handle cases where 601 a successful SDP answer is not received, in which case the state 602 of the session SHOULD be kept per the last successful SDP offer/ 603 answer. 605 If a client receives a data channel close indication (due to inband 606 SCTP SSN reset or some other reason) without associated SDP offer 607 then the client SHOULD generate an SDP offer which excludes this 608 closed data channel. 610 The application MUST also close any data channel that was negotiated 611 via SDP offer/answer, for which the stream identifiers are not listed 612 in an incoming SDP offer. 614 A closed data channel using local close (SCTP SSN reset), without an 615 additional SDP offer/answer to close it, may be reused for a new data 616 channel. This can only be done via new SDP offer/answer, describing 617 the new sub-protocol and its attributes, only after the corresponding 618 data channel close acknowledgement is received from the peer (i.e. 619 SCTP SSN reset of both incoming and outgoing streams is completed). 620 This restriction is to avoid the race conditions between arrival of 621 "SDP offer which reuses stream" with "SCTP SSN reset which closes 622 outgoing stream" at the peer. 624 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 626 SDP offer has no "a=dcmap" attributes 628 * Initial SDP offer: No data channel is negotiated yet. The DTLS 629 connection and SCTP association is negotiated and, if agreed, 630 established as per [I-D.ietf-mmusic-sctp-sdp]. 632 * Subsequent SDP offer: All the SDP offer/answer negotiated data 633 channels are expected be closed now. The DTLS/SCTP association 634 remains open for SDP offer/answer or DCEP negotiation of data 635 channels. 637 SDP answer has no "a=dcmap" attributes 639 * Initial SDP answer: Either the peer does not support dcmap 640 attributes or it rejected all the data channels. In either 641 case the offerer closes all the SDP offer/answer negotiated 642 data channels that were open at the time of initial offer. The 643 DTLS connection and SCTP association will still be setup. 645 * Subsequent SDP answer: All the SDP offer/answer negotiated data 646 channels are expected be closed now. The DTLS/SCTP association 647 remains open for future SDP offer/answer or DCEP negotiation of 648 data channels. 650 SDP offer has no "a=dcsa" attributes for a data channel. 652 * This is allowed and indicates there are no sub-protocol 653 parameters to convey. 655 SDP answer has no "a=dcsa" attributes for a data channel. 657 * This is allowed and indicates there are no sub-protocol 658 parameters to convey in the SDP answer. The number of dcsa 659 attributes in the SDP answer does not have to match the number 660 of dcsa attributes in the SDP offer. 662 6. Examples 664 SDP offer: 665 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 666 c=IN IP4 10.10.10.1 667 a=max-message-size:100000 668 a=sctp-port:5000 669 a=setup:actpass 670 a=connection:new 671 a=fingerprint:SHA-1 \ 672 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 673 a=dcmap:0 subprotocol="BFCP";label="BFCP" 675 SDP answer: 676 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 677 c=IN IP4 10.10.10.2 678 a=max-message-size:100000 679 a=sctp-port:5002 680 a=setup:passive 681 a=connection:new 682 a=fingerprint:SHA-1 \ 683 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 685 Figure 1: Example 1 687 In the above example the SDP answerer rejected the data channel with 688 stream id 0 either for explicit reasons or because it does not 689 understand the "a=dcmap" attribute. As a result the offerer will 690 close the data channel created with the SDP offer/answer negotiation 691 option. The SCTP association will still be setup over DTLS. At this 692 point the offerer or the answerer may use DCEP negotiation to open 693 data channels. 695 SDP offer: 696 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 697 c=IN IP4 10.10.10.1 698 a=max-message-size:100000 699 a=sctp-port:5000 700 a=setup:actpass 701 a=connection:new 702 a=fingerprint:SHA-1 \ 703 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 704 a=dcmap:0 subprotocol="BFCP";label="BFCP" 705 a=dcmap:2 subprotocol="MSRP";label="MSRP" 706 a=dcsa:2 accept-types:message/cpim text/plain text/ 707 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 709 SDP answer: 710 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 711 c=IN IP4 10.10.10.2 712 a=max-message-size:100000 713 a=sctp-port:5002 714 a=setup:passive 715 a=connection:new 716 a=fingerprint:SHA-1 \ 717 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 718 a=dcmap:2 subprotocol="MSRP";label="MSRP" 719 a=dcsa:2 accept-types:message/cpim text/plain 720 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 722 Figure 2: Example 2 724 In the above example the SDP offer contains data channels for BFCP 725 and MSRP sub-protocols. The SDP answer rejected BFCP and accepted 726 MSRP. So, the offerer should close the data channel for BFCP and 727 both offerer and answerer may start using the MSRP data channel 728 (after SCTP/DTLS association is setup). The data channel with stream 729 id 0 is free and can be used for future DCEP or SDP offer/answer 730 negotiation. 732 Continuing on the earlier example in Figure 1. 734 Subsequent SDP offer: 735 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 736 c=IN IP4 10.10.10.1 737 a=max-message-size:100000 738 a=sctp-port:5000 739 a=setup:actpass 740 a=connection:existing 741 a=fingerprint:SHA-1 \ 742 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 743 a=dcmap:4 subprotocol="MSRP";label="MSRP" 744 a=dcsa:4 accept-types:message/cpim text/plain 745 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 747 Subsequent SDP answer: 748 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 749 c=IN IP4 10.10.10.2 750 a=max-message-size:100000 751 a=sctp-port:5002 752 a=setup:passive 753 a=connection:existing 754 a=fingerprint:SHA-1 \ 755 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 756 a=dcmap:4 subprotocol="MSRP";label="MSRP" 757 a=dcsa:4 accept-types:message/cpim text/plain 758 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 760 Figure 3: Example 3 762 The above example is a continuation of the example in Figure 1. The 763 SDP offer now removes the MSRP data channel with stream id 2, but 764 opens a new MSRP data channel with stream id 4. The answerer accepts 765 the entire offer. As a result the offerer closes the earlier 766 negotiated MSRP related data channel and both offerer and answerer 767 may start using new the MSRP related data channel. 769 7. Security Considerations 771 No security considerations are envisaged beyond those already 772 documented in [RFC4566]. 774 8. IANA Considerations 776 8.1. Subprotocol Identifiers 778 Registration of new subprotocol identifiers is performed using the 779 existing IANA table "WebSocket Subprotocol Name Registry". 781 The following text should be added following the title of the table. 783 "This table also includes subprotocol identifiers specified for usage 784 within a WebRTC data channel." 786 The following reference should be added to under the heading 787 reference: "RFC XXXX". 789 This document assigns no new values to this table. 791 NOTE to RFC Editor: Please replace "XXXX" with the number of this 792 RFC. 794 8.2. New SDP Attributes 796 8.2.1. dcmap 798 [Editor's note: This section still needs to be completed.] 800 8.2.2. dcsa 802 [Editor's note: This section still needs to be completed.] 804 9. Acknowledgments 806 The authors wish to acknowledge the borrowing of ideas from other 807 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 808 and Gavin Llewellyn, and to thank Roni Even, Christian Groves, 809 Christer Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe 810 Rauschenbach for their invaluable comments. 812 10. CHANGE LOG 814 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 816 o In Section 1 replacement of "RTCWeb leaves it open for other 817 applications to use data channels and its in-band DCEP or out-of- 818 band non-DCEP protocols for creating them" with "... to use data 819 channels and its in-band DCEP or other in-band or out-of-band 820 protocols for creating them". Additionally replacement of "In 821 particular, the SDP offer generated by the application includes no 822 channel-specific information" with "... generated by the RTCweb 823 data channel stack includes no channel-specific information". 825 o Move of former section 5 ("Data Channels") to new Appendix A and 826 removal of JavaScript API specific discussions from this moved 827 text (like mentioning of data channel stack specific states). 828 Therefore former section 6 ("SDP Offer/Answer Negotiation") is now 829 Section 5. 831 o In Section 5: 833 * Relacement of Section 5's first paragraph "This section defines 834 a method of non-DCEP negotiation by which two clients can 835 negotiate data channel-specific and sub-protocol-specific 836 parameters, using the out-of-band SDP offer/answer exchange. 837 This SDP extension can only be used with the SDP offer/answer 838 model." with "This section defines an SDP extension by which 839 two clients can negotiate data channel-specific and sub- 840 protocol-specific parameters without using DCEP 841 [I-D.ietf-rtcweb-data-protocol]. This SDP extension only 842 defines usage in the context of SDP offer/answer." 844 * Addition of new paragraph: "Appendix A provides information how 845 data channels work in general and especially summarizes some 846 key aspects, which should be considered for the negotiation of 847 data channels if DCEP is not used." 849 o In Section 5.1.1 replacement of "The intention of exchanging these 850 attributes is to create data channels on both the peers with the 851 same set of attributes without actually using the DCEP 852 [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging 853 these attributes is to create, on two peers, without use of DCEP 854 [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely 855 directed data channels having the same set of attributes". 857 o In Section 5.1.1.5 replacement of "The 'max-retr' parameter 858 indicates the maximal number a user message will be retransmitted" 859 with "The 'max-retr' parameter indicates the maximal number of 860 times a user message will be retransmitted". 862 o In Section 5.2.1 replacement of "However, an SDP offer/answer 863 exchange MUST NOT be initiated if the associated SCTP stream is 864 already negotiated via DCEP" with "However, an SCTP stream MUST 865 NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ 866 answer exchange if the associated SCTP stream has already been 867 negotiated via DCEP". 869 o In the examples in Section 6 addition of the previously missing 870 colons to the "a=sctp-port" attribute lines. 872 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 874 o Move of reference [I-D.ietf-rtcweb-jsep] from the list of 875 normative references to the list of informative references. 877 o Addition of [IANA-SDP-Parameters] to the list of informative 878 references and addition of following two sentences to the first 879 paragraph after the ABNF definition: "Note however that not all 880 SDP attributes are suitable as "a=dcsa:" parameter. 881 [IANA-SDP-Parameters] contains the lists of IANA registered 882 session and media level or media level only SDP attributes." 884 o In the introduction replacement of last sentence "This document 885 defines SDP-based out-of-band negotiation procedures to establish 886 data channels for transport of well-defined sub-protocols" with 887 "This document defines SDP offer/answer negotiation procedures to 888 establish data channels for transport of well-defined sub- 889 protocols, to enable out-of-band negotiation". 891 o Throughout the document replacement of "external negotiation" with 892 "SDP offer/answer negotiation" and removal of term "external 893 negotiation" from the terminology list in Section 3. 895 o Throughout the document replacement of "internal negotiation" with 896 "DCEP" and removal of terms "internal negotiation" and "in-band 897 negotiation" from the terminology list in Section 3. 899 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 900 terms. 902 o In Section 5.2.1 replacement of sentence "However, a single stream 903 is managed using one method at a time." with "However, an SDP 904 offer/answer exchange MUST NOT be initiated if the associated SCTP 905 stream is already negotiated via DCEP". 907 o In Section 5.2.2 replacement of sentence "By definition max-retr 908 and max-time are mutually exclusive, so only one of them can be 909 present in a=dcmap" with "By definition max-retr and max-time are 910 mutually exclusive, so at most one of them MAY be present in 911 a=dcmap". 913 o Move of reference [WebRtcAPI] from list of normative references to 914 list of informative references. 916 o Removal of almost all text parts, which discussed JavaScript or 917 other API specific aspects. Such API specific aspects were mainly 918 discussed in sub-sections of Section 5 and Section 5 of draft- 919 ietf-mmusic-data-channel-sdpneg-02. 921 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 923 o New Section 4 regarding applicability to SDP offer/answer only. 925 o Addition of new Section 8.1 "Subprotocol identifiers" as 926 subsection of the "IANA Considerations" related Section 8. Also 927 removal of the temporary note "To be completed. As [I-D.ietf- 928 rtcweb-data-protocol] this document should refer to IANA's 929 WebSocket Subprotocol Name Registry defined in [RFC6455]." 931 o In Section 5.2.2: 933 * In the first paragraph replacement of the sentence "If an SDP 934 offer contains both of these parameters then such an SDP offer 935 will be rejected." with "If an SDP offer contains both of these 936 parameters then the receiver of such an SDP offer MUST reject 937 the SDP offer." 939 * In the second paragraph capitalization of "shall" and "may" 940 such that both sentences now read: "The SDP answer SHALL echo 941 the same subprotocol, max-retr, max-time, ordered parameters, 942 if those were present in the offer, and MAY include a label 943 parameter. They MAY appear in any order, which could be 944 different from the SDP offer, in the SDP answer." 946 * In the third paragraph replacement of the sentence "The same 947 information MUST be replicated without changes in any 948 subsequent offer or answer, as long as the data channel is 949 still opened at the time of offer or answer generation." with 950 "When sending a subsequent offer or an answer, and for as long 951 as the data channel is still open, the sender MUST replicate 952 the same information.". 954 o In Section 5.2.2 the mapping of data channel types defined in 955 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 956 parameters were illustrated using example "a=dcmap" attribute 957 lines. Replacement of these example "a=dcmap" attribute lines 958 with just the "a=dcmap" attribute parameters being relevant for 959 the channel type. 961 o In Section 5.2.5 the description of bullet point "SDP offer has no 962 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 963 No data channel negotiated yet." Replacement of this description 964 with "Initial SDP offer: No data channel is negotiated yet. The 965 DTLS connection and SCTP association is negotiated and, if agreed, 966 established as per [I-D.ietf-mmusic-sctp-sdp]." 968 o In Section 5.2.5 in both bullet points related to "Subsequent SDP 969 offer" and "Subsequent SDP answer" replacement of "All the 970 externally negotiated data channels must be closed now." with "All 971 the externally negotiated data channels are expected be closed 972 now.". 974 o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" 975 replacement of the two occurrences of "must" with "MUST". 977 o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" 978 there was a comment saying that "Either only maxretr-opt or 979 maxtime-opt is present. Both MUST not be present." Removal of 980 the second normative sentence and instead addition of following 981 new paragraph to the end of this section: "Within an 'a=dcmap' 982 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 983 parameter or one 'maxtime-opt' parameter is present. Both MUST 984 NOT be present." 986 o In Section 5.1.1.7 replacement of the first sentence "The 987 'ordered' parameter with value "true" indicates that DATA chunks 988 in the channel MUST be dispatched to the upper layer by the 989 receiver while preserving the order." with "The 'ordered' 990 parameter with value "true" indicates that the receiver MUST 991 dispatch DATA chunks in the data channel to the upper layer while 992 preserving the order.". 994 o In Section 5.2.3's first paragraph replacement of the one 995 occurrence of "must" with "..., it MUST wait until ...". 997 o In Section 5.2.4: 999 * In the second paragraph replacement of "must" with "... whether 1000 this closing MUST in addition ..." 1002 * In the third paragraph replacement of the sentence "The port 1003 value for the "m" line SHOULD not be changed (e.g., to zero) 1004 when closing a data channel ..." with "The offerer SHOULD NOT 1005 change the port value for the "m" line (e.g., to zero) when 1006 closing a data channel ...". 1008 * In the last but two paragraph replacement of the sentence "... 1009 then an SDP offer which excludes this closed data channel 1010 SHOULD be generated." with "... then the client SHOULD generate 1011 an SDP offer which excludes this closed data channel.". 1013 * In the last but one paragraph replacement of "must" with "The 1014 application MUST also close...". 1016 o In Section 5.1.2 addition of following note after the formal 1017 definition of the 'a=dcsa' attribute: "Note that the above 1018 reference to RFC 4566 defines were the attribute definition can be 1019 found; it does not provide any limitation on support of attributes 1020 defined in other documents in accordance with this attribute 1021 definition." 1023 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1025 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1026 channel consisting of paired SCTP outbound and inbound streams." 1027 Replacement of this definition with "Data channel: A WebRTC data 1028 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1029 consistent usage of "data channel" in the remainder of the 1030 document including the document's headline." 1032 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1033 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1034 In particular we expect "webrtc-datachannel" to become a more 1035 general term.' 1037 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1039 o In Section 5.1.1 removal of the example dcmap attribute line 1040 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1041 already four examples right after the ABNF rules in 1042 Section 5.1.1.1. Corresponding removal of following related note: 1043 "Note: This document does not provide a complete specification of 1044 how to negotiate the use of a WebRTC data channel to transport 1045 BFCP. Procedures specific to each sub-protocol such as BFCP will 1046 be documented elsewhere. The use of BFCP is only an example of 1047 how the generic procedures described herein might apply to a 1048 specific sub-protocol." 1050 o In Section 5.1.1 removal of following note: "Note: This attribute 1051 is derived from attribute "webrtc-DataChannel", which was defined 1052 in old version 03 of the following draft, but which was removed 1053 along with any support for SDP external negotiation in subsequent 1054 versions: [I-D.ietf-mmusic-sctp-sdp]." 1056 o Insertion of following new sentence to the beginning of 1057 Section 5.1.1.1: "dcmap is a media level attribute having 1058 following ABNF syntax:" 1060 o Insertion of new Section 5.1.1.2 containing the dcmap-stream-id 1061 specifying sentence, which previously was placed right before the 1062 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1063 parameter and is noted directly after the "a=dcmap:" attribute's 1064 colon' as this information is part of the ABNF specification. 1066 o In Section 5.1.1.1 modification of the 'ordering-value' values 1067 from "0" or "1" to "true" or "false". Corresponding text 1068 modifications in Section 5.1.1.7. 1070 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 1071 to rule name "escaped-char", which was not defined. Instead a 1072 rule with name "escaped" was defined. Renamed that rule's name to 1073 "escaped-char". 1075 o Insertion of a dedicated note right after the "a=dcmap:4" 1076 attribute example in Section 5.1.1.1 regarding the non-printable 1077 "escaped-char" character within the "label" value. 1079 o In Section 5.1.2's second paragraph replacement of "sctp stream 1080 identifier" with "SCTP stream identifier". 1082 o In first paragraph of Section 5.2.1 replacement of first two 1083 sentences 'For the SDP-based external negotiation described in 1084 this document, the initial offerer based "SCTP over DTLS" owns by 1085 convention the even stream identifiers whereas the initial 1086 answerer owns the odd stream identifiers. This ownership is 1087 invariant for the whole lifetime of the signaling session, e.g. it 1088 does not change if the initial answerer sends a new offer to the 1089 initial offerer.' with 'If an SDP offer/answer exchange (could be 1090 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1091 TCP/DTLS/SCTP based media description being accepted, and if this 1092 SDP offer/answer exchange results in the establishment of a new 1093 SCTP association, then the SDP offerer owns the even SCTP stream 1094 ids of this new SCTP association and the answerer owns the odd 1095 SCTP stream identifiers. If this "m" line is removed from the 1096 signaling session (its port number set to zero), and if usage of 1097 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1098 renegotiated later on, then the even and odd SCTP stream 1099 identifier ownership is redetermined as well as described above.' 1101 o In Section 5.2.3 the first action of an SDP answerer, when 1102 receiving an SDP offer, was described as "Applies the SDP offer. 1103 Note that the browser ignores data channel specific attributes in 1104 the SDP." Replacement of these two sentences with "Parses and 1105 applies the SDP offer. Note that the typical parser normally 1106 ignores unknown SDP attributes, which includes data channel 1107 related attributes." 1109 o In Section 5.2.3 the second sentence of the third SDP answerer 1110 action was "Note that the browser is asked to create data channels 1111 with stream identifiers not "owned" by the agent.". Replacement 1112 of this sentence with "Note that the agent is asked to create data 1113 channels with SCTP stream identifiers contained in the SDP offer 1114 if the SDP offer is accepted." 1116 o In Section 5.2.4 the third paragraph began with "A data channel 1117 can be closed by sending a new SDP offer which excludes the dcmap 1118 and dcsa attribute lines for the data channel. The port value for 1119 the m line should not be changed (e.g., to zero) when closing a 1120 data channel (unless all data channels are being closed and the 1121 SCTP association is no longer needed), since this would close the 1122 SCTP association and impact all of the data channels. If the 1123 answerer accepts the SDP offer then it MUST also exclude the 1124 corresponding attribute lines in the answer. ..." Replacement of 1125 this part with "The intention to close a data channel can be 1126 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1127 and "a=dcsa:" attribute lines for the data channel. The port 1128 value for the "m" line SHOULD not be changed (e.g., to zero) when 1129 closing a data channel (unless all data channels are being closed 1130 and the SCTP association is no longer needed), since this would 1131 close the SCTP association and impact all of the data channels. 1132 If the answerer accepts the SDP offer then it MUST close those 1133 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1134 excluded from the received SDP offer, unless those data channels 1135 were already closed, and it MUST also exclude the corresponding 1136 attribute lines in the answer." 1138 o In Section 5.2.4 the hanging text after the third paragraph was 1139 "This delayed close is to handle cases where a successful SDP 1140 answer is not received, in which case the state of session should 1141 be kept per the last successful SDP offer/answer." Replacement of 1142 this sentence with "This delayed closure is RECOMMENDED in order 1143 to handle cases where a successful SDP answer is not received, in 1144 which case the state of the session SHOULD be kept per the last 1145 successful SDP offer/answer." 1147 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1148 Section 5.1.1 contained already procedural descriptions related to 1149 data channel reliability negotiation. Creation of new 1150 Section 5.2.2 and moval of reliability negotiation related text to 1151 this new section. 1153 10.5. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1155 o Removal of note "[ACTION ITEM]" from section "subprotocol 1156 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1157 should refer to IANA's WebSocket Subprotocol Name Registry defined 1158 in [RFC6455]. 1160 o In whole document, replacement of "unreliable" with "partially 1161 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1162 [I-D.ietf-rtcweb-data-protocol] in most places. 1164 o Clarification of the semantic if the "max-retr" parameter is not 1165 present in an a=dcmap attribute line. In section "max-retr 1166 parameter" the sentence "The max-retr parameter is optional with 1167 default value unbounded" was replaced with "The max-retr parameter 1168 is optional. If the max-retr parameter is not present, then the 1169 maximal number of retransmissions is determined as per the generic 1170 SCTP retransmission rules as specified in [RFC4960]". 1172 o Clarification of the semantic if the "max-time" parameter is not 1173 present in an a=dcmap attribute line. In section "max-time 1174 parameter" the sentence "The max-time parameter is optional with 1175 default value unbounded" was replaced with "The max-time parameter 1176 is optional. If the max-time parameter is not present, then the 1177 generic SCTP retransmission timing rules apply as specified in 1178 [RFC4960]". 1180 o In section "label parameter" the sentence "Label is a mandatory 1181 parameter." was removed and following new sentences (including the 1182 note) were added: "The 'label' parameter is optional. If it is 1183 not present, then its value defaults to the empty string. Note: 1184 The empty string may also be explicitly used as 'label' value, 1185 such that 'label=""' is equivalent to the 'label' parameter not 1186 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1187 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1189 o In section "subprotocol parameter" the sentence "Subprotocol is a 1190 mandatory parameter." was replaced with "'Subprotocol' is an 1191 optional parameter. If the 'subprotocol' parameter is not 1192 present, then its value defaults to the empty string." 1194 o In the "Examples" section, in the first two SDP offer examples in 1195 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1196 'label="BFCP"'. 1198 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1199 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1200 replaced with "a=max-message-size" attribute lines, as per draft- 1201 ietf-mmusic-sctp-sdp-12. 1203 10.6. Changes against '-01' 1205 o Formal syntax for dcmap and dcsa attribute lines. 1207 o Making subprotocol as an optional parameter in dcmap. 1209 o Specifying disallowed parameter combinations for max-time and max- 1210 retr. 1212 o Clarifications on WebRTC data channel close procedures. 1214 10.7. Changes against '-00' 1216 o Revisions to identify difference between internal and external 1217 negotiation and their usage. 1219 o Introduction of more generic terminology, e.g. "application" 1220 instead of "browser". 1222 o Clarification of how "max-retr and max-time affect the usage of 1223 unreliable and reliable WebRTC data channels. 1225 o Updates of examples to take into account the SDP syntax changes 1226 introduced with draft-ietf-mmusic-sctp-sdp-07. 1228 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1229 attributes as this is now contained in the a=sctp-port attribute, 1230 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1231 association on top of the DTLS connection. 1233 11. References 1235 11.1. Normative References 1237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1238 Requirement Levels", BCP 14, RFC 2119, 1239 DOI 10.17487/RFC2119, March 1997, 1240 . 1242 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1243 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1244 July 2006, . 1246 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1247 with Session Description Protocol (SDP)", RFC 3264, 1248 DOI 10.17487/RFC3264, June 2002, 1249 . 1251 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1252 Specifications: ABNF", STD 68, RFC 5234, 1253 DOI 10.17487/RFC5234, January 2008, 1254 . 1256 [I-D.ietf-rtcweb-data-channel] 1257 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1258 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1259 progress), January 2015. 1261 [I-D.ietf-mmusic-sctp-sdp] 1262 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1263 Control Transmission Protocol (SCTP)-Based Media Transport 1264 in the Session Description Protocol (SDP)", draft-ietf- 1265 mmusic-sctp-sdp-14 (work in progress), March 2015. 1267 11.2. Informative References 1269 [I-D.ietf-rtcweb-data-protocol] 1270 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1271 Establishment Protocol", draft-ietf-rtcweb-data- 1272 protocol-09 (work in progress), January 2015. 1274 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1275 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1276 . 1278 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1279 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1280 DOI 10.17487/RFC4975, September 2007, 1281 . 1283 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1284 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1285 DOI 10.17487/RFC4976, September 2007, 1286 . 1288 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 1289 and P. Kyzivat, "A Session Description Protocol (SDP) 1290 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 1291 DOI 10.17487/RFC5547, May 2009, 1292 . 1294 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 1295 for the Message Session Relay Protocol (MSRP)", RFC 6135, 1296 DOI 10.17487/RFC6135, February 2011, 1297 . 1299 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1300 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1301 . 1303 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1304 Establishment for Media Anchoring (CEMA) for the Message 1305 Session Relay Protocol (MSRP)", RFC 6714, 1306 DOI 10.17487/RFC6714, August 2012, 1307 . 1309 [I-D.ietf-rtcweb-jsep] 1310 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 1311 Session Establishment Protocol", draft-ietf-rtcweb-jsep-11 1312 (work in progress), July 2015. 1314 [IANA-SDP-Parameters] 1315 "Session Description Protocol (SDP) Parameters", Internet 1316 Assigned Numbers Authority Protocol Assignments Session 1317 Description Protocol (SDP) Parameters, 1318 . 1321 [WebRtcAPI] 1322 Bergkvist, A., Burnett, D., Jennings, C., and A. 1323 Narayanan, "WebRTC 1.0: Real-time Communication Between 1324 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1325 February 2015, 1326 . 1328 Appendix A. Generic Data Channel Negotiation Aspects When Not Using 1329 DCEP 1331 This appendix summarizes how data channels work in general and 1332 discusses some key aspects, which should be considered for the out- 1333 of-band negotiation of data channels if DCEP is not used. 1335 A WebRTC application creates a data channel by providing a number of 1336 setup parameters (sub-protocol, label, reliability, order of 1337 delivery, priority). The application also specifies if it wants to 1338 make use of the negotiation using the DCEP 1339 [I-D.ietf-rtcweb-data-protocol], or if the application intends to 1340 negotiate data channels using the SDP offer/answer protocol. 1342 In any case, the SDP offer generated by the application is per 1343 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 1344 the SCTP association on top of which data channels will run: 1346 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 1347 c=IN IP4 79.97.215.79 1348 a=max-message-size:100000 1349 a=sctp-port:5000 1350 a=setup:actpass 1351 a=connection:new 1352 a=fingerprint:SHA-1 \ 1353 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 1355 Note: A WebRTC application will only use "m" line format "webrtc- 1356 datachannel", and will not use other formats in the "m" line for 1357 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 1358 only one SCTP association to be established on top of a DTLS 1359 association. 1361 Note: Above SDP media description does not contain any channel- 1362 specific information. 1364 A.1. Stream Identifier Numbering 1366 Independently from the requested type of negotiation, the application 1367 creating a data channel can either pass to the data channel stack the 1368 stream identifier to assign to the data channel or else let the data 1369 channel stack pick one identifier from the ones unused. 1371 To avoid glare situations, each endpoint can moreover own an 1372 exclusive set of stream identifiers, in which case an endpoint can 1373 only create a data channel with a stream identifier it owns. 1375 Which set of stream identifiers is owned by which endpoint is 1376 determined by convention or other means. 1378 For data channels negotiated with the DCEP, one endpoint owns by 1379 convention the even stream identifiers, whereas the other owns the 1380 odd stream identifiers, as defined in 1381 [I-D.ietf-rtcweb-data-protocol]. 1383 For data channels negotiated via some protocol different from 1384 DCEP, no convention is defined by default. 1386 A.2. Generic Data Channel Negotiation Not Using DCEP 1388 A.2.1. Overview 1390 DCEP negotiation only provides for negotiation of data channel 1391 transport parameters and does not provide for negotiation of sub- 1392 protocol specific parameters. DCEP-less data channel negotiation can 1393 be defined to allow negotiation of parameters beyond those handled by 1394 DCEP, e.g., parameters specific to the sub-protocol instantiated on a 1395 particular data channel. 1397 The following procedures are common to all methods of data channel 1398 negotiation not using DCEP, whether in-band (communicated using 1399 proprietary means on an already established data channel) or out-of- 1400 band (using SDP offer/answer or some other protocol associated with 1401 the signaling channel). 1403 A.2.2. Opening a Data Channel 1405 In the case of DCEP-less negotiation, the endpoint application has 1406 the option to fully control the stream identifier assignments. 1407 However these assignments have to coexist with the assignments 1408 controlled by the data channel stack for the DCEP negotiated data 1409 channels (if any). It is the responsibility of the application to 1410 ensure consistent assignment of stream identifiers. 1412 When the application requests the creation of a new data channel to 1413 be set up via DCEP-less negotiation, the data channel stack creates 1414 the data channel locally without sending any DATA_CHANNEL_OPEN 1415 message in-band. However, even if the ICE, DTLS and SCTP procedures 1416 were already successfully completed, the application can't send data 1417 on this data channel until the negotiation is complete with the peer. 1418 This is because the peer needs to be aware of and accept the usage of 1419 this data channel. The peer, after accepting the data channel offer, 1420 can start sending data immediately. This implies that the offerer 1421 may receive data channel sub-protocol messages before the negotiation 1422 is complete and the application should be ready to handle it. 1424 If the peer rejects the data channel part of the offer then it 1425 doesn't have to do anything as the data channel was not created using 1426 the stack. The offerer on the other hand needs to close the data 1427 channel that was opened by invoking relevant data channel stack API 1428 procedures. 1430 It is also worth noting that a data channel stack implementation may 1431 not provide any API to create and close data channels; instead the 1432 data channels may be used on the fly as needed just by communicating 1433 via non-DCEP means or by even having some local configuration/ 1434 assumptions on both the peers. 1436 The application then negotiates the data channel properties and sub- 1437 protocol properties with the peer's application using a mechanism 1438 different from DCEP. 1440 The peer then symmetrically creates a data channel with these 1441 negotiated data channel properties. This is the only way for the 1442 peer's data channel stack to know which properties to apply when 1443 transmitting data on this channel. The data channel stack must allow 1444 data channel creation with any non-conflicting stream identifier so 1445 that both peers can create the data channel with the same stream 1446 identifier. 1448 A.2.3. Closing a Data Channel 1450 When the application requests the closing of a data channel 1451 negotiated without DCEP, the data channel stack always performs an 1452 SCTP SSN reset for this channel. 1454 Depending upon the method used for DCEP-less negotiation and the sub- 1455 protocol associated with the data channel, the closing might in 1456 addition be signaled to the peer via SDP offer/answer negotiation. 1458 Authors' Addresses 1460 Keith Drage (editor) 1461 Alcatel-Lucent 1462 Quadrant, Stonehill Green, Westlea 1463 Swindon 1464 UK 1466 Email: keith.drage@alcatel-lucent.com 1468 Maridi R. Makaraju (Raju) 1469 Alcatel-Lucent 1470 2000 Lucent Lane 1471 Naperville, Illinois 1472 US 1474 Email: Raju.Makaraju@alcatel-lucent.com 1476 Juergen Stoetzer-Bradler 1477 Alcatel-Lucent 1478 Lorenzstrasse 10 1479 D-70435 Stuttgart 1480 Germany 1482 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 1484 Richard Ejzak 1485 Unaffiliated 1487 Email: richard.ejzak@gmail.com 1489 Jerome Marcon 1490 Unaffiliated