idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-03.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 6.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 6.2.4 the third paragraph began with "A data channel can be closed by sending a new SDP offer which excludes the dcmap and dcsa attribute lines for the data channel. The port value for the m line should not be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST also exclude the corresponding attribute lines in the answer. ..." Replacement of this part with "The intention to close a data channel can be signaled by sending a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for the data channel. The port value for the "m" line SHOULD not be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST close those data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the received SDP offer, unless those data channels were already closed, and it MUST also exclude the corresponding attribute lines in the answer." -- The document date (July 21, 2015) is 3200 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: 'ASSUMPTION' is mentioned on line 335, but not defined == Unused Reference: 'RFC5234' is defined on line 1364, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 1396, but no explicit reference was found in the text == Unused Reference: 'RFC5547' is defined on line 1401, but no explicit reference was found in the text == Unused Reference: 'RFC6135' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: 'RFC6714' is defined on line 1416, 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 (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC K. Drage, Ed. 3 Internet-Draft M. Makaraju 4 Intended status: Standards Track J. Stoetzer-Bradler 5 Expires: January 22, 2016 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 July 21, 2015 11 SDP-based Data Channel Negotiation 12 draft-ietf-mmusic-data-channel-sdpneg-03 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 January 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 69 5. Data Channels . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 5 71 5.2. Generic Non-DCEP Negotiation . . . . . . . . . . . . . . 6 72 5.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 73 5.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 6 74 5.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 8 75 6. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 8 76 6.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.1.1. SDP Attribute for Data Channel Parameter Negotiation 9 78 6.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 9 79 6.1.1.2. dcmap-stream-id Parameter . . . . . . . . . . . . 11 80 6.1.1.3. label Parameter . . . . . . . . . . . . . . . . . 11 81 6.1.1.4. subprotocol Parameter . . . . . . . . . . . . . . 11 82 6.1.1.5. max-retr Parameter . . . . . . . . . . . . . . . 11 83 6.1.1.6. max-time Parameter . . . . . . . . . . . . . . . 12 84 6.1.1.7. ordered Parameter . . . . . . . . . . . . . . . . 12 85 6.1.2. Sub-Protocol Specific Attributes . . . . . . . . . . 12 86 6.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 14 88 6.2.2. Negotiating Data Channel Parameters . . . . . . . . . 14 89 6.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 15 90 6.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 17 91 6.2.5. Various SDP Offer/Answer Scenarios and Considerations 18 92 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 96 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 22 97 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 22 98 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 100 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 11.1. Changes against 'draft-ietf-mmusic-data-channel- 102 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 22 103 11.2. Changes against 'draft-ietf-mmusic-data-channel- 104 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 23 105 11.3. Changes against 'draft-ietf-mmusic-data-channel- 106 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 25 107 11.4. Changes against 'draft-ejzak-mmusic-data-channel- 108 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 109 11.5. Changes against '-01' . . . . . . . . . . . . . . . . . 29 110 11.6. Changes against '-00' . . . . . . . . . . . . . . . . . 29 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 113 12.2. Informative References . . . . . . . . . . . . . . . . . 31 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Introduction 118 The RTCWeb working group has defined the concept of bi-directional 119 data channels running on top of SCTP/DTLS. RTCWeb leaves it open for 120 other applications to use data channels and its in-band DCEP or out- 121 of-band non-DCEP protocols for creating them. Each data channel 122 consists of paired SCTP streams sharing the same SCTP Stream 123 Identifier. Data channels are created by endpoint applications 124 through the WebRTC API, or other users of data channel like CLUE, and 125 can be used to transport proprietary or well-defined protocols, which 126 in the latter case can be signaled by the data channel "sub-protocol" 127 parameter, conceptually similar to the WebSocket "sub-protocol". 128 However, apart from the "sub-protocol" value transmitted to the peer, 129 RTCWeb leaves it open how endpoint applications can agree on how to 130 instantiate a given sub-protocol on a data channel, and whether it is 131 signaled in-band using DCEP or out-of-band using a non-DCEP protocol 132 (or both). In particular, the SDP offer generated by the application 133 includes no channel-specific information. 135 This document defines SDP offer/answer negotiation procedures to 136 establish data channels for transport of well-defined sub-protocols, 137 to enable out-of-band negotiation. 139 2. Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Terminology 147 This document uses the following terms: 149 Data channel: A WebRTC data channel as specified in 150 [I-D.ietf-rtcweb-data-channel]. 152 Data channel stack: An entity which, upon application request, 153 runs the data channel protocol to keep track of states, sending 154 and receive data. If the application is a browser based 155 JavaScript application then this stack resides in the browser. If 156 the application is a native application then this stack resides in 157 the application and is accessible via some sort of APIs. 159 Data channel properties: Fixed properties assigned to a data 160 channel at the time of its creation. Some of these properties 161 determine the way the data channel stack transmits data on this 162 channel (e.g., stream identifier, reliability, order of 163 delivery...). 165 DCEP: Data Channel Establishment Protocol defined in 166 [I-D.ietf-rtcweb-data-protocol]. 168 In-band: Transmission through the peer-to-peer SCTP association. 170 Out-of-band: Transmission through the application signaling path. 172 Peer: From the perspective of one of the agents in a session, its 173 peer is the other agent. Specifically, from the perspective of 174 the SDP offerer, the peer is the SDP answerer. From the 175 perspective of the SDP answerer, the peer is the SDP offerer. 177 SCTP Stream Sequence Number (SSN): the SCTP stream sequence number 178 as specified in [RFC4960]. 180 Stream identifier: The identifier of the outbound and inbound SCTP 181 streams composing a data channel. 183 4. Applicability Statement 185 The mechanism in this specification only applies to the Session 186 Description Protocol (SDP) [RFC4566], when used together with the SDP 187 offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of 188 scope of this document, and is thus undefined. 190 5. Data Channels 192 This section summarizes how data channels work in general. 194 A WebRTC application creates a data channel by providing a number of 195 setup parameters (sub-protocol, label, reliability, order of 196 delivery, priority). The application also specifies if it wants to 197 make use of the negotiation using the DCEP 198 [I-D.ietf-rtcweb-data-protocol], or if the application intends to 199 negotiate data channels using the SDP offer/answer protocol. 201 In any case, the SDP offer generated by the browser is per 202 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 203 the SCTP association on top of which data channels will run: 205 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 206 c=IN IP4 79.97.215.79 207 a=max-message-size:100000 208 a=sctp-port 5000 209 a=setup:actpass 210 a=connection:new 211 a=fingerprint:SHA-1 \ 212 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 214 Note: A WebRTC browser will only use "m" line format "webrtc- 215 datachannel", and will not use other formats in the "m" line for 216 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 217 only one SCTP association to be established on top of a DTLS session. 219 Note: This SDP syntax does not contain any channel-specific 220 information. 222 5.1. Stream Identifier Numbering 224 [Editor's note: This entire Section 5.1 could possibly be removed as 225 there is another section (Section 6.2.1) which is dedicated to SCTP 226 stream id usage.] 228 Independently from the requested type of negotiation, the application 229 creating a data channel can either pass to the browser the stream 230 identifier to assign to the data channel or else let the browser pick 231 one identifier from the ones unused. 233 To avoid glare situations, each endpoint can moreover own an 234 exclusive set of stream identifiers, in which case an endpoint can 235 only create a data channel with a stream identifier it owns. 237 Which set of stream identifiers is owned by which endpoint is 238 determined by convention or other means. 240 For data channels negotiated with the DCEP, one endpoint owns by 241 convention the even stream identifiers, whereas the other owns the 242 odd stream identifiers, as defined in 243 [I-D.ietf-rtcweb-data-protocol]. 245 For data channels negotiated via some non-DCEP protocol, no 246 convention is defined by default. 248 5.2. Generic Non-DCEP Negotiation 250 [Editor's note: As this document now focuses on SDP offer/answer 251 negotiation only, should this entire Section 5.2 (and all its sub- 252 sections) be removed? Parts of the information provided in these 253 sub-sections might be moved to Section 6, Section 6.2.1 and 254 Section 6.2.3 as indicated below in further editor notes. Another 255 option might be to move this section and its sub-section to an 256 informative appendix.] 258 5.2.1. Overview 260 DCEP negotiation only provides for negotiation of data channel 261 transport parameters and does not provide for negotiation of sub- 262 protocol specific parameters. Non-DCEP negotiation can be defined to 263 allow negotiation of parameters beyond those handled by DCEP 264 negotiation, e.g., parameters specific to the sub-protocol 265 instantiated on a particular data channel. See Section 6.1.2 for an 266 example of such a parameter. 268 [Editor's note: The information in the preceding paragraph might be 269 moved to Section 6.] 271 The following procedures are common to all methods of non-DCEP 272 negotiation, whether in-band (communicated using proprietary means on 273 an already established data channel) or out-of-band (using SDP offer/ 274 answer or some other protocol associated with the signaling channel). 276 [Editor's note: The preceding paragraph could be deleted.] 278 5.2.2. Opening a Data Channel 280 In the case of non-DCEP negotiation, the endpoint application has the 281 option to fully control the stream identifier assignments. However 282 these assignments have to coexist with the assignments controlled by 283 the data channel stack for the DCEP negotiated data channels (if 284 any). It is the responsibility of the application to ensure 285 consistent assignment of stream identifiers. 287 [Editor's note: The information in the preceding paragraph could be 288 moved to Section 6.2.1.] 290 When the application requests the creation of a new data channel to 291 be set up via non-DCEP negotiation, the data channel stack creates 292 the data channel locally without sending any DATA_CHANNEL_OPEN 293 message in-band [Editor's note: The information in this first part of 294 the sentence could be moved to section 6.2.3], and sets the data 295 channel state to Connecting if the SCTP association is not yet 296 established, or sets the data channel state to Open if the SCTP 297 association is already established. The side which starts non-DCEP 298 negotiation creates a data channel using underlying data channel 299 stack API and the data channel is put into open state immediately 300 (assuming ICE, SCTP procedures were already done). [Editor's note: 301 The API related information could be deleted.] However, the 302 application can't send data on this data channel until non-DCEP 303 negotiation is complete with the peer. This is because the peer 304 needs to be aware and accept the data channel via non-DCEP 305 negotiation. The peer after accepting the data channel offer can 306 start sending data immediately. This implies that the offerer may 307 get data channel sub-protocol messages before non-DCEP negotiation is 308 complete and the application should be ready to handle it. [Editor's 309 note: The information in these last four sentences could be moved to 310 Section 6.2.3.] 312 If the peer rejects the data channel part of the offer then it 313 doesn't have to do anything as the data channel was not created using 314 the stack. The offerer on the other hand needs to close the data 315 channel that was opened by invoking relevant data channel stack API 316 procedures. 318 [Editor's note: The information in the preceding paragraph could be 319 moved to Section 6.2.3 (to a new bullet point there).] 321 It is also worth noting that a data channel stack implementation may 322 not provide any API to create and close data channels; instead the 323 data channels are used on the fly as needed just by communicating via 324 non-DCEP means or by even having some local configuration/assumptions 325 on both the peers. 327 [Editor's note: The preceding paragraph could be deleted.] 329 The application then negotiates the data channel properties and sub- 330 protocol properties with the peer's application using a mechanism 331 different from DCEP. 333 [Editor's note: The preceding paragraph could be deleted.] 335 [ASSUMPTION] The peer MUST then symmetrically create a data channel 336 with these negotiated data channel properties. This is the only way 337 for the peer's data channel stack to know which properties to apply 338 when transmitting data on this channel. [Editor's note: The previous 339 sentence could be deleted.] The data channel stack MUST allow data 340 channel creation with any non-conflicting stream identifier so that 341 both peers can create the data channel with the same stream 342 identifier. [Editor's note: The information in this sentence could 343 be moved to Section 6.2.3.] 345 In case the non-DCEP negotiation is correlated with an SDP offer/ 346 answer exchange that establishes the SCTP association, the SCTP 347 initialization completion triggers a callback from the data channel 348 stack to an application on both the ends to change the data channel 349 state from Connecting to Open. The details of this interface is 350 specific to the data channel user application. Browser based 351 applications (could include hybrid apps) will use [WebRtcAPI], while 352 native applications use a compatible API, which is yet to be 353 specified. See Section 6.2.3 for details on when the data channel 354 stack can assume the data channel is open, and on when the 355 application can assume the data channel is open. 357 [Editor's note: The preceding paragraph could be deleted.] 359 5.2.3. Closing a Data Channel 361 When the application requests the closing of a non-DCEP negotiated 362 data channel, the data channel stack always performs an SCTP SSN 363 reset for this channel. 365 [Editor's note: The preceding paragraph could be deleted.] 367 Depending upon the method used for non-DCEP negotiation and the sub- 368 protocol associated with the data channel, the closing might in 369 addition be signaled to the peer via non-DCEP negotiation. 371 [Editor's note: The preceding paragraph could be deleted.] 373 6. SDP Offer/Answer Negotiation 375 This section defines a method of non-DCEP negotiation by which two 376 clients can negotiate data channel-specific and sub-protocol-specific 377 parameters, using the out-of-band SDP offer/answer exchange. This 378 SDP extension can only be used with the SDP offer/answer model. 380 6.1. SDP Syntax 382 Two new SDP attributes are defined to support SDP offer/answer 383 negotiation of data channels. The first attribute provides for 384 negotiation of channel-specific parameters. The second attribute 385 provides for negotiation of sub-protocol-specific parameters. 387 6.1.1. SDP Attribute for Data Channel Parameter Negotiation 389 Associated with the SDP "m" line that defines the SCTP association 390 for data channels (defined in Section 4), each SDP offer and answer 391 includes one "a=dcmap:" attribute that defines the data channel 392 parameters for each data channel to be negotiated. Each such 393 attribute line specifies the following parameters for a data channel: 394 SCTP stream identifier, sub-protocol, label, reliability, order of 395 delivery, and priority. 397 The intention of exchanging these attributes is to create data 398 channels on both the peers with the same set of attributes without 399 actually using the DCEP [I-D.ietf-rtcweb-data-protocol]. It is 400 assumed that the data channel properties (reliable/partially 401 reliable, ordered/unordered) are suitable per the sub-protocol 402 transport requirements. 404 6.1.1.1. dcmap Attribute 406 "a=dcmap:" is a media level attribute having following ABNF syntax. 408 Formal Syntax: 410 Name: dcmap 412 Value: dcmap-value 414 Usage Level: media 416 Charset Dependent: no 418 Syntax: 420 dcmap-value = dcmap-stream-id 421 [ SP dcmap-opt *(";" dcmap-opt) ] 422 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 423 / maxretr-opt / maxtime-opt 424 ; Either only maxretr-opt or maxtime-opt 425 ; is present. 427 dcmap-stream-id = 1*DIGIT 428 ordering-opt = "ordered=" ordering-value 429 ordering-value = "true" / "false" 430 subprotocol-opt = "subprotocol=" quoted-string 431 label-opt = "label=" quoted-string 432 maxretr-opt = "max-retr=" maxretr-value 433 maxretr-value = 435 ; number of retransmissions 436 maxtime-opt = "max-time=" maxtime-value 437 maxtime-value = 439 ; milliseconds 441 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 442 quoted-char = SP / quoted-visible 443 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 444 escaped-char = "%" HEXDIG HEXDIG 445 DQUOTE = 446 integer = 448 Examples: 450 a=dcmap:0 451 a=dcmap:1 subprotocol="BFCP";max-time=60000 452 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 453 a=dcmap:3 label="Label 1";ordered=false;max-retr=5 454 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000;max-retr=3 455 Note: The last example (a=dcmap:4) shows a 'label' parameter value 456 which contains one non-printable 'escaped-char' character (the 457 tabulator character). 459 Within an 'a=dcmap' attribute line's 'dcmap-opt' value either only 460 one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 461 present. Both MUST NOT be present. 463 6.1.1.2. dcmap-stream-id Parameter 465 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 466 within the SCTP association used to form the data channel. 468 6.1.1.3. label Parameter 470 The 'label' parameter indicates the name of the channel. It 471 represents a label that can be used to distinguish, in the context of 472 the WebRTC API [WebRtcAPI], an RTCDataChannel object from other 473 RTCDataChannel objects. This parameter maps to the 'Label' parameter 474 defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is 475 optional. If it is not present, then its value defaults to the empty 476 string. 478 Note: The empty string MAY also be explicitly used as 'label' value, 479 such that 'label=""' is equivalent to the 'label' parameter not being 480 present at all. [I-D.ietf-rtcweb-data-protocol] allows the 481 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 483 6.1.1.4. subprotocol Parameter 485 The 'subprotocol' parameter indicates which protocol the client 486 expects to exchange via the channel. 'Subprotocol' is an optional 487 parameter. If the 'subprotocol' parameter is not present, then its 488 value defaults to the empty string. 490 6.1.1.5. max-retr Parameter 492 This parameter indicates that the data channel is partially reliable. 493 The 'max-retr' parameter indicates the maximal number a user message 494 will be retransmitted. The max-retr parameter is optional. If the 495 max-retr parameter is not present, then the maximal number of 496 retransmissions is determined as per the generic SCTP retransmission 497 rules as specified in [RFC4960]. This parameter maps to the 'Number 498 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 500 6.1.1.6. max-time Parameter 502 This parameter indicates that the data channel is partially reliable. 503 A user message will no longer be transmitted or retransmitted after a 504 specified life-time given in milliseconds in the 'max-time' 505 parameter. The max-time parameter is optional. If the max-time 506 parameter is not present, then the generic SCTP retransmission timing 507 rules apply as specified in [RFC4960]. This parameter maps to the 508 'Lifetime in ms' parameter defined in 509 [I-D.ietf-rtcweb-data-protocol]. 511 6.1.1.7. ordered Parameter 513 The 'ordered' parameter with value "true" indicates that the receiver 514 MUST dispatch DATA chunks in the data channel to the upper layer 515 while preserving the order. The ordered parameter is optional and 516 takes two values: "true" for ordered and "false" for unordered 517 delivery with "true" as the default value. Any other value is 518 ignored and default "ordered=true" is assumed. In the absence of 519 this parameter "ordered=true" is assumed. This parameter maps to the 520 ordered or unordered data channel types as defined in 521 [I-D.ietf-rtcweb-data-protocol]. 523 6.1.2. Sub-Protocol Specific Attributes 525 In the SDP, each data channel declaration MAY also be followed by 526 other SDP attributes specific to the sub-protocol in use. Each of 527 these attributes is represented by one new attribute line, and it 528 includes the contents of a media-level SDP attribute already defined 529 for use with this (sub)protocol in another IETF specification. Sub- 530 protocol-specific attributes might also be defined for exclusive use 531 with data channel transport, but should use the same syntax described 532 here for other sub-protocol-specific attributes. 534 Each sub-protocol specific SDP attribute that would normally be used 535 to negotiate the subprotocol using SDP is replaced with an attribute 536 of the form "a=dcsa:stream-id original-attribute", where dcsa stands 537 for "data channel sub-protocol attribute", stream-id is the SCTP 538 stream identifier assigned to this sub-protocol instance, and 539 original-attribute represents the contents of the sub-protocol 540 related attribute to be included. 542 Formal Syntax: 544 Name: dcsa 546 Value: dcsa-value 548 Usage Level: media 550 Charset Dependent: no 552 Syntax: 554 dcsa-value = stream-id SP attribute 555 attribute = 557 Example: 559 a=dcsa:2 accept-types:text/plain 561 Note that the above reference to RFC 4566 defines where the attribute 562 definition can be found; it does not provide any limitation on 563 support of attributes defined in other documents in accordance with 564 this attribute definition. Note however that not all SDP attributes 565 are suitable as "a=dcsa:" parameter. [IANA-SDP-Parameters] contains 566 the lists of IANA registered session and media level or media level 567 only SDP attributes. 569 Thus in the example above, the original attribute line "a=accept- 570 types:text/plain" is represented by the attribute line "a=dcsa:2 571 accept-types:text/plain", which specifies that this instance of MSRP 572 being transported on the SCTP association using the data channel with 573 stream id 2 accepts plain text files. 575 As opposed to the data channel "a=dcmap:" attribute parameters, these 576 parameters are subject to offer/answer negotiation following the 577 procedures defined in the sub-protocol specific documents. 579 The same syntax applies to any other SDP attribute required for 580 negotiation of this instance of the sub-protocol. 582 Note: This document does not provide a complete specification of how 583 to negotiate the use of a data channel to transport MSRP. Procedures 584 specific to each sub-protocol such as MSRP will be documented 585 elsewhere. The use of MSRP is only an example of how the generic 586 procedures described herein might apply to a specific sub-protocol. 588 6.2. Procedures 590 6.2.1. Managing Stream Identifiers 592 If an SDP offer/answer exchange (could be the initial or a subsequent 593 one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media 594 description being accepted, and if this SDP offer/answer exchange 595 results in the establishment of a new SCTP association, then the SDP 596 offerer owns the even SCTP stream ids of this new SCTP association 597 and the answerer owns the odd SCTP stream identifiers. If this "m" 598 line is removed from the signaling session (its port number set to 599 zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ 600 SCTP based "m" line is renegotiated later on, then the even and odd 601 SCTP stream identifier ownership is redetermined as well as described 602 above. 604 This specification allows simultaneous use of SDP offer/answer and 605 DCEP negotiation. However, an SDP offer/answer exchange MUST NOT be 606 initiated if the associated SCTP stream is already negotiated via 607 DCEP. Stream ids that are not currently used in SDP can be used for 608 DCEP negotiation. Stream id allocation per SDP offer/answer 609 negotiation may not align with DTLS role based allocation. This 610 could cause glare conditions when one side trying to do SDP offer/ 611 answer negotiation on a stream id while the other end trying to open 612 a data channel on the same stream id using DCEP negotiation. To 613 avoid these glare conditions this specification recommends that the 614 data channel stack user always selects stream ids per above described 615 SDP offer/answer rule even when DCEP negotiation is used. To avoid 616 glare conditions, it is possible to come up with a different stream 617 id allocation scheme, but such schemes are outside the scope of this 618 specification. 620 6.2.2. Negotiating Data Channel Parameters 622 Conveying a reliable data channel is achieved by including neither 623 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 624 a=dcmap attribute line. Conveying a partially reliable data channel 625 is achieved by including only one of 'max-retr' or 'max-time'. By 626 definition max-retr and max-time are mutually exclusive, so at most 627 one of them MAY be present in a=dcmap. If an SDP offer contains both 628 of these parameters then the receiver of such an SDP offer MUST 629 reject the SDP offer. If an SDP answer contains both of these 630 parameters then the offerer MAY treat it as an error and MAY assume 631 the associated SDP offer/answer failed and MAY take appropriate 632 recovery actions. These recovery options are outside the scope of 633 this specification. 635 The SDP answer SHALL echo the same subprotocol, max-retr, max-time, 636 ordered parameters, if those were present in the offer, and MAY 637 include a label parameter. They MAY appear in any order, which could 638 be different from the SDP offer, in the SDP answer. 640 When sending a subsequent offer or an answer, and for as long as the 641 data channel is still open, the sender MUST replicate the same 642 information. 644 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 645 mapped to SDP in the following manner, where "ordered=true" is the 646 default and may be omitted: 648 DATA_CHANNEL_RELIABLE 649 ordered=true 651 DATA_CHANNEL_RELIABLE_UNORDERED 652 ordered=false 654 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 655 ordered=true;max-retr= 657 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 658 ordered=false;max-retr= 660 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 661 ordered=true;max-time= 663 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 664 ordered=false;max-time= 666 6.2.3. Opening a Data Channel 668 The procedure for opening a data channel using SDP offer/answer 669 negotiation starts with the agent preparing to send an SDP offer. If 670 a peer receives an SDP offer before starting to send a new SDP offer 671 with data channels that are to be SDP offer/answer negotiated, or 672 loses an SDP offer glare resolution procedure in this case, it MUST 673 wait until the ongoing SDP offer/answer completes before resuming the 674 SDP offer/answer negotiation procedure. 676 The agent that intends to send an SDP offer to create data channels 677 through SDP offer/answer negotiation performs the following: 679 o Creates data channels using stream identifiers from the owned set 680 (see Section 6.2.1). 682 o Generates a new SDP offer. 684 o Determines the list of stream identifiers assigned to data 685 channels opened through SDP offer/answer negotiation. 687 o Completes the SDP offer with the dcmap and dcsa attributes needed, 688 if any, for each SDP offer/answer negotiated data channel, as 689 described in Section 6.1 and in Section 6.2.2. 691 o Sends the SDP offer. 693 The peer receiving such an SDP offer performs the following: 695 o Parses and applies the SDP offer. Note that the typical parser 696 normally ignores unknown SDP attributes, which includes data 697 channel related attributes. 699 o Analyzes the channel parameters and sub-protocol attributes to 700 determine whether to accept each offered data channel. 702 o For accepted data channels, it creates peer instances for the data 703 channels with the agent using the channel parameters described in 704 the SDP offer. Note that the agent is asked to create data 705 channels with SCTP stream identifiers contained in the SDP offer 706 if the SDP offer is accepted. 708 o Generates an SDP answer. 710 o Completes the SDP answer with the dcmap and optional dcsa 711 attributes needed for each SDP offer/answer negotiated data 712 channel, as described in Section 6.1 and in Section 6.2.2. 714 o Sends the SDP answer. 716 The agent receiving such an SDP answer performs the following: 718 o Closes any created data channels for which the expected dcmap and 719 dcsa attributes are not present in the SDP answer. 721 o Applies the SDP answer. 723 Each agent application MUST wait to send data until it has 724 confirmation that the data channel at the peer is instantiated. For 725 WebRTC, this is when both data channel stacks have channel parameters 726 instantiated. This occurs: 728 o At both peers when a data channel is created without an 729 established SCTP association, as soon as the SCTP association is 730 successfully established. 732 o At the agent receiving an SDP offer for which there is an 733 established SCTP association, as soon as it creates an SDP offer/ 734 answer negotiated data channel based on information signaled in 735 the SDP offer. 737 o At the agent sending an SDP offer to create a new SDP offer/answer 738 negotiated data channel for which there is an established SCTP 739 association, when it receives the SDP answer confirming acceptance 740 of the data channel or when it begins to receive data on the data 741 channel from the peer, whichever occurs first. 743 6.2.4. Closing a Data Channel 745 When the application requests the closing of a data channel that was 746 negotiated via SDP offer/answer, the data channel stack always 747 performs an SCTP SSN reset for this channel. 749 It is specific to the sub-protocol whether this closing MUST in 750 addition be signaled to the peer via a new SDP offer/answer exchange. 752 The intention to close a data channel can be signaled by sending a 753 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 754 lines for the data channel. The offerer SHOULD NOT change the port 755 value for the "m" line (e.g. to zero) when closing a data channel 756 (unless all data channels are being closed and the SCTP association 757 is no longer needed), since this would close the SCTP association and 758 impact all of the data channels. If the answerer accepts the SDP 759 offer then the answerer MUST close those data channels whose 760 "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the 761 received SDP offer, unless those data channels were already closed, 762 and the answerer MUST also exclude the corresponding attribute lines 763 in the answer. In addition to that, the SDP answerer MAY exclude 764 other data channels which were closed but not yet communicated to the 765 peer. So, the offerer MUST inspect the answer to see if it has to 766 close other data channels which are now not included in the answer. 768 If a new SDP offer/answer is used to close data channels then the 769 data channel(s) SHOULD only be closed by the answerer/offerer after a 770 successful SDP answer is sent/received. 772 This delayed closure is RECOMMENDED in order to handle cases where 773 a successful SDP answer is not received, in which case the state 774 of the session SHOULD be kept per the last successful SDP offer/ 775 answer. 777 If a client receives a data channel close indication (due to inband 778 SCTP SSN reset or some other reason) without associated SDP offer 779 then the client SHOULD generate an SDP offer which excludes this 780 closed data channel. 782 The application MUST also close any data channel that was negotiated 783 via SDP offer/answer, for which the stream identifiers are not listed 784 in an incoming SDP offer. 786 A closed data channel using local close (SCTP SSN reset), without an 787 additional SDP offer/answer to close it, may be reused for a new data 788 channel. This can only be done via new SDP offer/answer, describing 789 the new sub-protocol and its attributes, only after the corresponding 790 data channel close acknowledgement is received from the peer (i.e. 791 SCTP SSN reset of both incoming and outgoing streams is completed). 792 This restriction is to avoid the race conditions between arrival of 793 "SDP offer which reuses stream" with "SCTP SSN reset which closes 794 outgoing stream" at the peer. 796 6.2.5. Various SDP Offer/Answer Scenarios and Considerations 798 SDP offer has no a=dcmap attributes 800 * Initial SDP offer: No data channel is negotiated yet. The DTLS 801 connection and SCTP association is negotiated and, if agreed, 802 established as per [I-D.ietf-mmusic-sctp-sdp]. 804 * Subsequent SDP offer: All the SDP offer/answer negotiated data 805 channels are expected be closed now. The DTLS/SCTP association 806 remains open for SDP offer/answer or DCEP negotiation of data 807 channels. 809 SDP answer has no a=dcmap attributes 811 * Initial SDP answer: Either the peer does not support dcmap 812 attributes or it rejected all the data channels. In either 813 case the offerer closes all the SDP offer/answer negotiated 814 data channels that were open at the time of initial offer. The 815 DTLS connection and SCTP association will still be setup. 817 * Subsequent SDP answer: All the SDP offer/answer negotiated data 818 channels are expected be closed now. The DTLS/SCTP association 819 remains open for future SDP offer/answer or DCEP negotiation of 820 data channels. 822 SDP offer has no a=dcsa attributes for a data channel. 824 * This is allowed and indicates there are no sub-protocol 825 parameters to convey. 827 SDP answer has no a=dcsa attributes for a data channel. 829 * This is allowed and indicates there are no sub-protocol 830 parameters to convey in the SDP answer. The number of dcsa 831 attributes in the SDP answer does not have to match the number 832 of dcsa attributes in the SDP offer. 834 7. Examples 836 SDP offer: 837 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 838 c=IN IP4 10.10.10.1 839 a=max-message-size:100000 840 a=sctp-port 5000 841 a=setup:actpass 842 a=connection:new 843 a=fingerprint:SHA-1 \ 844 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 845 a=dcmap:0 subprotocol="BFCP";label="BFCP" 847 SDP answer: 848 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 849 c=IN IP4 10.10.10.2 850 a=max-message-size:100000 851 a=sctp-port 5002 852 a=setup:passive 853 a=connection:new 854 a=fingerprint:SHA-1 \ 855 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 857 Figure 1: Example 1 859 In the above example the SDP answerer rejected the data channel with 860 stream id 0 either for explicit reasons or because it does not 861 understand the a=dcmap attribute. As a result the offerer will close 862 the data channel created with the SDP offer/answer negotiation 863 option. The SCTP association will still be setup over DTLS. At this 864 point the offerer or the answerer may use DCEP negotiation to open 865 data channels. 867 SDP offer: 868 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 869 c=IN IP4 10.10.10.1 870 a=max-message-size:100000 871 a=sctp-port 5000 872 a=setup:actpass 873 a=connection:new 874 a=fingerprint:SHA-1 \ 875 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 876 a=dcmap:0 subprotocol="BFCP";label="BFCP" 877 a=dcmap:2 subprotocol="MSRP";label="MSRP" 878 a=dcsa:2 accept-types:message/cpim text/plain text/ 879 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 881 SDP answer: 882 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 883 c=IN IP4 10.10.10.2 884 a=max-message-size:100000 885 a=sctp-port 5002 886 a=setup:passive 887 a=connection:new 888 a=fingerprint:SHA-1 \ 889 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 890 a=dcmap:2 subprotocol="MSRP";label="MSRP" 891 a=dcsa:2 accept-types:message/cpim text/plain 892 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 894 Figure 2: Example 2 896 In the above example the SDP offer contains data channels for BFCP 897 and MSRP sub-protocols. The SDP answer rejected BFCP and accepted 898 MSRP. So, the offerer should close the data channel for BFCP and 899 both offerer and answerer may start using the MSRP data channel 900 (after SCTP/DTLS association is setup). The data channel with stream 901 id 0 is free and can be used for future DCEP or SDP offer/answer 902 negotiation. 904 Continuing on the earlier example in Figure 1. 906 Subsequent SDP offer: 907 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 908 c=IN IP4 10.10.10.1 909 a=max-message-size:100000 910 a=sctp-port 5000 911 a=setup:actpass 912 a=connection:existing 913 a=fingerprint:SHA-1 \ 914 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 915 a=dcmap:4 subprotocol="MSRP";label="MSRP" 916 a=dcsa:4 accept-types:message/cpim text/plain 917 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 919 Subsequent SDP answer: 920 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 921 c=IN IP4 10.10.10.2 922 a=max-message-size:100000 923 a=sctp-port 5002 924 a=setup:passive 925 a=connection:existing 926 a=fingerprint:SHA-1 \ 927 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 928 a=dcmap:4 subprotocol="MSRP";label="MSRP" 929 a=dcsa:4 accept-types:message/cpim text/plain 930 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 932 Figure 3: Example 3 934 The above example is a continuation of the example in Figure 1. The 935 SDP offer now removes the MSRP data channel with stream id 2, but 936 opens a new MSRP data channel with stream id 4. The answerer accepts 937 the entire offer. As a result the offerer closes the earlier 938 negotiated MSRP related data channel and both offerer and answerer 939 may start using new the MSRP related data channel. 941 8. Security Considerations 943 No security considerations are envisaged beyond those already 944 documented in [RFC4566]. 946 9. IANA Considerations 948 9.1. Subprotocol Identifiers 950 Registration of new subprotocol identifiers is performed using the 951 existing IANA table "WebSocket Subprotocol Name Registry". 953 The following text should be added following the title of the table. 955 "This table also includes subprotocol identifiers specified for usage 956 within a WebRTC data channel." 958 The following reference should be added to under the heading 959 reference: "RFC XXXX". 961 This document assigns no new values to this table. 963 NOTE to RFC Editor: Please replace "XXXX" with the number of this 964 RFC. 966 9.2. New SDP Attributes 968 9.2.1. dcmap 970 [Editor's note: This section still needs to be completed.] 972 9.2.2. dcsa 974 [Editor's note: This section still needs to be completed.] 976 10. Acknowledgments 978 The authors wish to acknowledge the borrowing of ideas from other 979 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 980 and Gavin Llewellyn, and to thank Roni Even, Christian Groves, 981 Christer Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe 982 Rauschenbach for their invaluable comments. 984 11. CHANGE LOG 986 11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 988 o Move of reference [I-D.ietf-rtcweb-jsep] from the list of 989 normative references to the list of informative references. 991 o Addition of [IANA-SDP-Parameters] to the list of informative 992 references and addition of following two sentences to the first 993 paragraph after the ABNF definition: "Note however that not all 994 SDP attributes are suitable as "a=dcsa:" parameter. 995 [IANA-SDP-Parameters] contains the lists of IANA registered 996 session and media level or media level only SDP attributes." 998 o In the introduction replacement of last sentence "This document 999 defines SDP-based out-of-band negotiation procedures to establish 1000 data channels for transport of well-defined sub-protocols" with 1001 "This document defines SDP offer/answer negotiation procedures to 1002 establish data channels for transport of well-defined sub- 1003 protocols, to enable out-of-band negotiation". 1005 o Throughout the document replacement of "external negotiation" with 1006 "SDP offer/answer negotiation" and removal of term "external 1007 negotiation" from the terminology list in Section 3. 1009 o Throughout the document replacement of "internal negotiation" with 1010 "DCEP" and removal of terms "internal negotiation" and "in-band 1011 negotiation" from the terminology list in Section 3. 1013 o Addition of "SCTP Stream Sequence Number (SSN)" to the list of 1014 terms. 1016 o In Section 6.2.1 replacement of sentence "However, a single stream 1017 is managed using one method at a time." with "However, an SDP 1018 offer/answer exchange MUST NOT be initiated if the associated SCTP 1019 stream is already negotiated via DCEP". 1021 o In Section 6.2.2 replacement of sentence "By definition max-retr 1022 and max-time are mutually exclusive, so only one of them can be 1023 present in a=dcmap" with "By definition max-retr and max-time are 1024 mutually exclusive, so at most one of them MAY be present in 1025 a=dcmap". 1027 o Move of reference [WebRtcAPI] from list of normative references to 1028 list of informative references. 1030 o Removal of almost all text parts, which discussed JavaScript or 1031 other API specific aspects. Such API specific aspects were mainly 1032 discussed in sub-sections of Section 5 and Section 6. 1034 11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 1036 o New Section 4 regarding applicability to SDP offer/answer only. 1038 o Addition of new Section 9.1 "Subprotocol identifiers" as 1039 subsection of the "IANA Considerations" related Section 9. Also 1040 removal of the temporary note "To be completed. As [I-D.ietf- 1041 rtcweb-data-protocol] this document should refer to IANA's 1042 WebSocket Subprotocol Name Registry defined in [RFC6455]." 1044 o In Section 6.2.2: 1046 * In the first paragraph replacement of the sentence "If an SDP 1047 offer contains both of these parameters then such an SDP offer 1048 will be rejected." with "If an SDP offer contains both of these 1049 parameters then the receiver of such an SDP offer MUST reject 1050 the SDP offer." 1052 * In the second paragraph capitalization of "shall" and "may" 1053 such that both sentences now read: "The SDP answer SHALL echo 1054 the same subprotocol, max-retr, max-time, ordered parameters, 1055 if those were present in the offer, and MAY include a label 1056 parameter. They MAY appear in any order, which could be 1057 different from the SDP offer, in the SDP answer." 1059 * In the third paragraph replacement of the sentence "The same 1060 information MUST be replicated without changes in any 1061 subsequent offer or answer, as long as the data channel is 1062 still opened at the time of offer or answer generation." with 1063 "When sending a subsequent offer or an answer, and for as long 1064 as the data channel is still open, the sender MUST replicate 1065 the same information.". 1067 o In Section 6.2.2 the mapping of data channel types defined in 1068 [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute 1069 parameters were illustrated using example "a=dcmap" attribute 1070 lines. Replacement of these example "a=dcmap" attribute lines 1071 with just the "a=dcmap" attribute parameters being relevant for 1072 the channel type. 1074 o In Section 6.2.5 the description of bullet point "SDP offer has no 1075 a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: 1076 No data channel negotiated yet." Replacement of this description 1077 with "Initial SDP offer: No data channel is negotiated yet. The 1078 DTLS connection and SCTP association is negotiated and, if agreed, 1079 established as per [I-D.ietf-mmusic-sctp-sdp]." 1081 o In Section 6.2.5 in both bullet points related to "Subsequent SDP 1082 offer" and "Subsequent SDP answer" replacement of "All the 1083 externally negotiated data channels must be closed now." with "All 1084 the externally negotiated data channels are expected be closed 1085 now.". 1087 o In Section 5.2.2's sixth paragraph beginning with "[ASSUMPTION]" 1088 replacement of the two occurrences of "must" with "MUST". 1090 o In Section 6.1.1.1 in the definition of the ABNF rule "dcmap-opt" 1091 there was a comment saying that "Either only maxretr-opt or 1092 maxtime-opt is present. Both MUST not be present." Removal of 1093 the second normative sentence and instead addition of following 1094 new paragraph to the end of this section: "Within an 'a=dcmap' 1095 attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 1096 parameter or one 'maxtime-opt' parameter is present. Both MUST 1097 NOT be present." 1099 o In Section 6.1.1.7 replacement of the first sentence "The 1100 'ordered' parameter with value "true" indicates that DATA chunks 1101 in the channel MUST be dispatched to the upper layer by the 1102 receiver while preserving the order." with "The 'ordered' 1103 parameter with value "true" indicates that the receiver MUST 1104 dispatch DATA chunks in the data channel to the upper layer while 1105 preserving the order.". 1107 o In Section 6.2.3's first paragraph replacement of the one 1108 occurrence of "must" with "..., it MUST wait until ...". 1110 o In Section 6.2.4: 1112 * In the second paragraph replacement of "must" with "... whether 1113 this closing MUST in addition ..." 1115 * In the third paragraph replacement of the sentence "The port 1116 value for the "m" line SHOULD not be changed (e.g., to zero) 1117 when closing a data channel ..." with "The offerer SHOULD NOT 1118 change the port value for the "m" line (e.g., to zero) when 1119 closing a data channel ...". 1121 * In the last but two paragraph replacement of the sentence "... 1122 then an SDP offer which excludes this closed data channel 1123 SHOULD be generated." with "... then the client SHOULD generate 1124 an SDP offer which excludes this closed data channel.". 1126 * In the last but one paragraph replacement of "must" with "The 1127 application MUST also close...". 1129 o In Section 6.1.2 addition of following note after the formal 1130 definition of the 'a=dcsa' attribute: "Note that the above 1131 reference to RFC 4566 defines were the attribute definition can be 1132 found; it does not provide any limitation on support of attributes 1133 defined in other documents in accordance with this attribute 1134 definition." 1136 11.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 1138 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 1139 channel consisting of paired SCTP outbound and inbound streams." 1140 Replacement of this definition with "Data channel: A WebRTC data 1141 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 1142 consistent usage of "data channel" in the remainder of the 1143 document including the document's headline." 1145 o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in 1146 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 1147 In particular we expect "webrtc-datachannel" to become a more 1148 general term.' 1150 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 1152 o In Section 6.1.1 removal of the example dcmap attribute line 1153 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 1154 already four examples right after the ABNF rules in 1155 Section 6.1.1.1. Corresponding removal of following related note: 1156 "Note: This document does not provide a complete specification of 1157 how to negotiate the use of a WebRTC data channel to transport 1158 BFCP. Procedures specific to each sub-protocol such as BFCP will 1159 be documented elsewhere. The use of BFCP is only an example of 1160 how the generic procedures described herein might apply to a 1161 specific sub-protocol." 1163 o In Section 6.1.1 removal of following note: "Note: This attribute 1164 is derived from attribute "webrtc-DataChannel", which was defined 1165 in old version 03 of the following draft, but which was removed 1166 along with any support for SDP external negotiation in subsequent 1167 versions: [I-D.ietf-mmusic-sctp-sdp]." 1169 o Insertion of following new sentence to the beginning of 1170 Section 6.1.1.1: "dcmap is a media level attribute having 1171 following ABNF syntax:" 1173 o Insertion of new Section 6.1.1.2 containing the dcmap-stream-id 1174 specifying sentence, which previously was placed right before the 1175 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 1176 parameter and is noted directly after the "a=dcmap:" attribute's 1177 colon' as this information is part of the ABNF specification. 1179 o In Section 6.1.1.1 modification of the 'ordering-value' values 1180 from "0" or "1" to "true" or "false". Corresponding text 1181 modifications in Section 6.1.1.7. 1183 o In Section 6.1.1.1 the ABNF definition of "quoted-string" referred 1184 to rule name "escaped-char", which was not defined. Instead a 1185 rule with name "escaped" was defined. Renamed that rule's name to 1186 "escaped-char". 1188 o Insertion of a dedicated note right after the "a=dcmap:4" 1189 attribute example in Section 6.1.1.1 regarding the non-printable 1190 "escaped-char" character within the "label" value. 1192 o In Section 6.1.2's second paragraph replacement of "sctp stream 1193 identifier" with "SCTP stream identifier". 1195 o In first paragraph of Section 6.2.1 replacement of first two 1196 sentences 'For the SDP-based external negotiation described in 1197 this document, the initial offerer based "SCTP over DTLS" owns by 1198 convention the even stream identifiers whereas the initial 1199 answerer owns the odd stream identifiers. This ownership is 1200 invariant for the whole lifetime of the signaling session, e.g. it 1201 does not change if the initial answerer sends a new offer to the 1202 initial offerer.' with 'If an SDP offer/answer exchange (could be 1203 the initial or a subsequent one) results in a UDP/DTLS/SCTP or 1204 TCP/DTLS/SCTP based media description being accepted, and if this 1205 SDP offer/answer exchange results in the establishment of a new 1206 SCTP association, then the SDP offerer owns the even SCTP stream 1207 ids of this new SCTP association and the answerer owns the odd 1208 SCTP stream identifiers. If this "m" line is removed from the 1209 signaling session (its port number set to zero), and if usage of 1210 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 1211 renegotiated later on, then the even and odd SCTP stream 1212 identifier ownership is redetermined as well as described above.' 1214 o In Section 6.2.3 the first action of an SDP answerer, when 1215 receiving an SDP offer, was described as "Applies the SDP offer. 1216 Note that the browser ignores data channel specific attributes in 1217 the SDP." Replacement of these two sentences with "Parses and 1218 applies the SDP offer. Note that the typical parser normally 1219 ignores unknown SDP attributes, which includes data channel 1220 related attributes." 1222 o In Section 6.2.3 the second sentence of the third SDP answerer 1223 action was "Note that the browser is asked to create data channels 1224 with stream identifiers not "owned" by the agent.". Replacement 1225 of this sentence with "Note that the agent is asked to create data 1226 channels with SCTP stream identifiers contained in the SDP offer 1227 if the SDP offer is accepted." 1229 o In Section 6.2.4 the third paragraph began with "A data channel 1230 can be closed by sending a new SDP offer which excludes the dcmap 1231 and dcsa attribute lines for the data channel. The port value for 1232 the m line should not be changed (e.g., to zero) when closing a 1233 data channel (unless all data channels are being closed and the 1234 SCTP association is no longer needed), since this would close the 1235 SCTP association and impact all of the data channels. If the 1236 answerer accepts the SDP offer then it MUST also exclude the 1237 corresponding attribute lines in the answer. ..." Replacement of 1238 this part with "The intention to close a data channel can be 1239 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1240 and "a=dcsa:" attribute lines for the data channel. The port 1241 value for the "m" line SHOULD not be changed (e.g., to zero) when 1242 closing a data channel (unless all data channels are being closed 1243 and the SCTP association is no longer needed), since this would 1244 close the SCTP association and impact all of the data channels. 1245 If the answerer accepts the SDP offer then it MUST close those 1246 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1247 excluded from the received SDP offer, unless those data channels 1248 were already closed, and it MUST also exclude the corresponding 1249 attribute lines in the answer." 1251 o In Section 6.2.4 the hanging text after the third paragraph was 1252 "This delayed close is to handle cases where a successful SDP 1253 answer is not received, in which case the state of session should 1254 be kept per the last successful SDP offer/answer." Replacement of 1255 this sentence with "This delayed closure is RECOMMENDED in order 1256 to handle cases where a successful SDP answer is not received, in 1257 which case the state of the session SHOULD be kept per the last 1258 successful SDP offer/answer." 1260 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1261 Section 6.1.1 contained already procedural descriptions related to 1262 data channel reliability negotiation. Creation of new 1263 Section 6.2.2 and moval of reliability negotiation related text to 1264 this new section. 1266 11.4. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1268 o Removal of note "[ACTION ITEM]" from section "subprotocol 1269 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1270 should refer to IANA's WebSocket Subprotocol Name Registry defined 1271 in [RFC6455]. 1273 o In whole document, replacement of "unreliable" with "partially 1274 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1275 [I-D.ietf-rtcweb-data-protocol] in most places. 1277 o Clarification of the semantic if the "max-retr" parameter is not 1278 present in an a=dcmap attribute line. In section "max-retr 1279 parameter" the sentence "The max-retr parameter is optional with 1280 default value unbounded" was replaced with "The max-retr parameter 1281 is optional. If the max-retr parameter is not present, then the 1282 maximal number of retransmissions is determined as per the generic 1283 SCTP retransmission rules as specified in [RFC4960]". 1285 o Clarification of the semantic if the "max-time" parameter is not 1286 present in an a=dcmap attribute line. In section "max-time 1287 parameter" the sentence "The max-time parameter is optional with 1288 default value unbounded" was replaced with "The max-time parameter 1289 is optional. If the max-time parameter is not present, then the 1290 generic SCTP retransmission timing rules apply as specified in 1291 [RFC4960]". 1293 o In section "label parameter" the sentence "Label is a mandatory 1294 parameter." was removed and following new sentences (including the 1295 note) were added: "The 'label' parameter is optional. If it is 1296 not present, then its value defaults to the empty string. Note: 1297 The empty string may also be explicitly used as 'label' value, 1298 such that 'label=""' is equivalent to the 'label' parameter not 1299 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1300 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1302 o In section "subprotocol parameter" the sentence "Subprotocol is a 1303 mandatory parameter." was replaced with "'Subprotocol' is an 1304 optional parameter. If the 'subprotocol' parameter is not 1305 present, then its value defaults to the empty string." 1307 o In the "Examples" section, in the first two SDP offer examples in 1308 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1309 'label="BFCP"'. 1311 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1312 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1313 replaced with "a=max-message-size" attribute lines, as per draft- 1314 ietf-mmusic-sctp-sdp-12. 1316 11.5. Changes against '-01' 1318 o Formal syntax for dcmap and dcsa attribute lines. 1320 o Making subprotocol as an optional parameter in dcmap. 1322 o Specifying disallowed parameter combinations for max-time and max- 1323 retr. 1325 o Clarifications on WebRTC data channel close procedures. 1327 11.6. Changes against '-00' 1329 o Revisions to identify difference between internal and external 1330 negotiation and their usage. 1332 o Introduction of more generic terminology, e.g. "application" 1333 instead of "browser". 1335 o Clarification of how "max-retr and max-time affect the usage of 1336 unreliable and reliable WebRTC data channels. 1338 o Updates of examples to take into account the SDP syntax changes 1339 introduced with draft-ietf-mmusic-sctp-sdp-07. 1341 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1342 attributes as this is now contained in the a=sctp-port attribute, 1343 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1344 association on top of the DTLS connection. 1346 12. References 1348 12.1. Normative References 1350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1351 Requirement Levels", BCP 14, RFC 2119, 1352 DOI 10.17487/RFC2119, March 1997, 1353 . 1355 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1356 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1357 July 2006, . 1359 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1360 with Session Description Protocol (SDP)", RFC 3264, 1361 DOI 10.17487/RFC3264, June 2002, 1362 . 1364 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1365 Specifications: ABNF", STD 68, RFC 5234, 1366 DOI 10.17487/RFC5234, January 2008, 1367 . 1369 [I-D.ietf-rtcweb-data-channel] 1370 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1371 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1372 progress), January 2015. 1374 [I-D.ietf-mmusic-sctp-sdp] 1375 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1376 Control Transmission Protocol (SCTP)-Based Media Transport 1377 in the Session Description Protocol (SDP)", draft-ietf- 1378 mmusic-sctp-sdp-14 (work in progress), March 2015. 1380 12.2. Informative References 1382 [I-D.ietf-rtcweb-data-protocol] 1383 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1384 Establishment Protocol", draft-ietf-rtcweb-data- 1385 protocol-09 (work in progress), January 2015. 1387 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1388 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1389 . 1391 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1392 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1393 DOI 10.17487/RFC4975, September 2007, 1394 . 1396 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1397 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1398 DOI 10.17487/RFC4976, September 2007, 1399 . 1401 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 1402 and P. Kyzivat, "A Session Description Protocol (SDP) 1403 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 1404 DOI 10.17487/RFC5547, May 2009, 1405 . 1407 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 1408 for the Message Session Relay Protocol (MSRP)", RFC 6135, 1409 DOI 10.17487/RFC6135, February 2011, 1410 . 1412 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1413 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1414 . 1416 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1417 Establishment for Media Anchoring (CEMA) for the Message 1418 Session Relay Protocol (MSRP)", RFC 6714, 1419 DOI 10.17487/RFC6714, August 2012, 1420 . 1422 [I-D.ietf-rtcweb-jsep] 1423 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 1424 Session Establishment Protocol", draft-ietf-rtcweb-jsep-11 1425 (work in progress), July 2015. 1427 [IANA-SDP-Parameters] 1428 "Session Description Protocol (SDP) Parameters", Internet 1429 Assigned Numbers Authority Protocol Assignments Session 1430 Description Protocol (SDP) Parameters, 1431 . 1434 [WebRtcAPI] 1435 Bergkvist, A., Burnett, D., Jennings, C., and A. 1436 Narayanan, "WebRTC 1.0: Real-time Communication Between 1437 Browsers", World Wide Web Consortium WD-webrtc-20150210, 1438 February 2015, 1439 . 1441 Authors' Addresses 1443 Keith Drage (editor) 1444 Alcatel-Lucent 1445 Quadrant, Stonehill Green, Westlea 1446 Swindon 1447 UK 1449 Email: keith.drage@alcatel-lucent.com 1451 Maridi R. Makaraju (Raju) 1452 Alcatel-Lucent 1453 2000 Lucent Lane 1454 Naperville, Illinois 1455 US 1457 Email: Raju.Makaraju@alcatel-lucent.com 1459 Juergen Stoetzer-Bradler 1460 Alcatel-Lucent 1461 Lorenzstrasse 10 1462 D-70435 Stuttgart 1463 Germany 1465 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 1467 Richard Ejzak 1468 Unaffiliated 1470 Email: richard.ejzak@gmail.com 1471 Jerome Marcon 1472 Unaffiliated