idnits 2.17.1 draft-ietf-mmusic-data-channel-sdpneg-01.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: dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt ; Either only maxretr-opt or maxtime-opt ; 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: 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. In addition to that, the SDP answerer MAY exclude other data channels which were closed but not yet communicated to the peer. So, the offerer MUST inspect the answer to see if it has to close other data channels which are now not included in the answer. == 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 (March 9, 2015) is 3336 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 299, but not defined == Unused Reference: 'RFC3264' is defined on line 1143, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'RFC5547' is defined on line 1190, but no explicit reference was found in the text == Unused Reference: 'RFC6135' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'RFC6714' is defined on line 1202, 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-rtcweb-jsep-08 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'WebRtcAPI' -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 3 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: September 10, 2015 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 March 9, 2015 11 SDP-based Data Channel Negotiation 12 draft-ietf-mmusic-data-channel-sdpneg-01 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 internal in-band band (also referred to 24 as 'internal' for the rest of the document) Data Channel 25 Establishment Protocol or some external out-of-band simply referred 26 to as 'external negotiation' in the rest of the document . This 27 document specifies how the SDP offer/answer exchange can be used to 28 achieve such an external negotiation. Even though data channels are 29 designed for RTCWeb use initially they may be used by other protocols 30 like, but not limited to, the CLUE protocol. This document is 31 intended to be used wherever data channels are used. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 10, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Data Channels . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 5 72 4.2. Generic External Negotiation . . . . . . . . . . . . . . 6 73 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 6 75 4.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 7 76 5. SDP-based External Negotiation . . . . . . . . . . . . . . . 7 77 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 78 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 8 79 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 8 80 5.1.1.2. dcmap-stream-id Parameter . . . . . . . . . . . . 10 81 5.1.1.3. label Parameter . . . . . . . . . . . . . . . . . 10 82 5.1.1.4. subprotocol Parameter . . . . . . . . . . . . . . 10 83 5.1.1.5. max-retr Parameter . . . . . . . . . . . . . . . 10 84 5.1.1.6. max-time Parameter . . . . . . . . . . . . . . . 10 85 5.1.1.7. ordered Parameter . . . . . . . . . . . . . . . . 11 86 5.1.2. Sub-Protocol Specific Attributes . . . . . . . . . . 11 87 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12 89 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 13 90 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 14 91 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 16 92 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 17 93 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 97 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 10.1. Changes against 'draft-ietf-mmusic-data-channel- 99 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 21 100 10.2. Changes against 'draft-ejzak-mmusic-data-channel- 101 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 24 102 10.3. Changes against '-01' . . . . . . . . . . . . . . . . . 25 103 10.4. Changes against '-00' . . . . . . . . . . . . . . . . . 25 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 106 11.2. Informative References . . . . . . . . . . . . . . . . . 26 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 109 1. Introduction 111 The RTCWeb working group has defined the concept of bi-directional 112 data channels running on top of SCTP/DTLS. RTCWeb leaves it open for 113 other applications to use data channels and its in-band or out-of- 114 band protocol for creating them. Each data channel consists of 115 paired SCTP streams sharing the same SCTP Stream Identifier. Data 116 channels are created by endpoint applications through the WebRTC API, 117 or other users of data channel like CLUE, and can be used to 118 transport proprietary or well-defined protocols, which in the latter 119 case can be signaled by the data channel "sub-protocol" parameter, 120 conceptually similar to the WebSocket "sub-protocol". However, apart 121 from the "sub-protocol" value transmitted to the peer, RTCWeb leaves 122 it open how endpoint applications can agree on how to instantiate a 123 given sub-protocol on a data channel, and whether it is signaled in- 124 band or out-of-band (or both). In particular, the SDP offer 125 generated by the application includes no channel-specific 126 information. 128 This document defines SDP-based out-of-band negotiation procedures to 129 establish data channels for transport of well-defined sub-protocols. 131 2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. Terminology 139 This document uses the following terms: 141 Data channel: A WebRTC data channel as specified in 142 [I-D.ietf-rtcweb-data-channel]. 144 Data channel stack: An entity which, upon application request, 145 runs data channel protocol to keep track of states, sending and 146 receive data. If the application is browser based JavaScript 147 application then this stack resides in the browser. If the 148 application is a native application then this stack resides in 149 application and accessible to it via some sort of APIs. 151 Data channel properties: fixed properties assigned to a data 152 channel at the time of its creation. Some of these properties 153 determine the way the data channel stack transmits data on this 154 channel (e.g., stream identifier, reliability, order of 155 delivery...). 157 DCEP - Data Channel Establishment Protocol defined in 158 [I-D.ietf-rtcweb-data-protocol]. 160 External negotiation: Data channel negotiation based on SDP offer/ 161 answer outlined in this specification. 163 Internal negotiation: Data channel negotiation based on the Data 164 Channel Establishment Protocol defined in 165 [I-D.ietf-rtcweb-data-protocol]. 167 In-band: transmission through the peer-to-peer SCTP association. 169 In-band negotiation: data channel negotiation based on the Data 170 Channel Establishment Protocol defined in 171 [I-D.ietf-rtcweb-data-protocol]. 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 Stream identifier: the identifier of the outbound and inbound SCTP 181 streams composing a data channel. 183 4. Data Channels 185 This section summarizes how data channels work in general. Note that 186 the references to 'browser' here is intentional as in this specific 187 example the data channel user is a Webrtc enabled browser. 189 A WebRTC application creates a data channel via the data channel API, 190 by providing a number of setup parameters (sub-protocol, label, 191 reliability, order of delivery, priority). The application also 192 specifies if it wants to make use of the in-band negotiation using 193 the DCEP [I-D.ietf-rtcweb-data-protocol], or if the application 194 intends to perform an "external negotiation" using some other in-band 195 or out-of-band mechanism. 197 In any case, the SDP offer generated by the browser is per 198 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for 199 the SCTP association on top of which data channels will run, and one 200 attribute per protocol assigned to the SCTP ports: 202 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 203 c=IN IP4 79.97.215.79 204 a=max-message-size:100000 205 a=sctp-port 5000 206 a=setup:actpass 207 a=connection:new 208 a=fingerprint:SHA-1 \ 209 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 211 Note: A WebRTC browser will only use "m" line format "webrtc- 212 datachannel", and will not use other formats in the "m" line for 213 other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports 214 only one SCTP association to be established on top of a DTLS session. 216 Note: This SDP syntax does not contain any channel-specific 217 information. 219 4.1. Stream Identifier Numbering 221 Independently from the requested type of negotiation, the application 222 creating a data channel can either pass to the browser the stream 223 identifier to assign to the data channel or else let the browser pick 224 one identifier from the ones unused. 226 To avoid glare situations, each endpoint can moreover own an 227 exclusive set of stream identifiers, in which case an endpoint can 228 only create a data channel with a stream identifier it owns. 230 Which set of stream identifiers is owned by which endpoint is 231 determined by convention or other means. 233 For data channels negotiated in-band, one endpoint owns by 234 convention the even stream identifiers, whereas the other owns the 235 odd stream identifiers, as defined in 236 [I-D.ietf-rtcweb-data-protocol]. 238 For data channels externally negotiated, no convention is defined 239 by default. 241 4.2. Generic External Negotiation 243 4.2.1. Overview 245 In-band negotiation only provides for negotiation of data channel 246 transport parameters and does not provide for negotiation of sub- 247 protocol specific parameters. External negotiation can be defined to 248 allow negotiation of parameters beyond those handled by in-band 249 negotiation, e.g., parameters specific to the sub-protocol 250 instantiated on a particular data channel. See Section 5.1.2 for an 251 example of such a parameter. 253 The following procedures are common to all methods of external 254 negotiation, whether in-band (communicated using proprietary means on 255 an already established data channel) or out-of-band (using SDP or 256 some other protocol associated with the signaling channel). 258 4.2.2. Opening a Data Channel 260 In the case of external negotiation, the endpoint application has the 261 option to fully control the stream identifier assignments. However 262 these assignments have to coexist with the assignments controlled by 263 the data channel stack for the in-band negotiated data channels (if 264 any). It is the responsibility of the application to ensure 265 consistent assignment of stream identifiers. 267 When the application requests the creation of a new data channel to 268 be set up via external negotiation, the data channel stack creates 269 the data channel locally without sending any DATA_CHANNEL_OPEN 270 message in-band, and sets the data channel state to Connecting if the 271 SCTP association is not yet established, or sets the data channel 272 state to Open if the SCTP association is already established. The 273 side which starts external negotiation creates data channel using 274 underlying data channel stack API and the data channel is put into 275 open state immediately (assuming ICE, SCTP procedures were already 276 done). However, the application can't send data on this data channel 277 until external negotiation is complete with the peer. This is 278 because peer needs to be aware and accept the data channel via 279 external negotiation. The peer after accepting the data channel 280 offer can start sending data immediately. This implies that the 281 offerer may get data channel message before external negotiation is 282 complete and the application should be ready to handle it. 284 If the peer rejects the data channel part of the offer then it 285 doesn't have to do anything as the data channel was not created using 286 the stack. The offerer on the other hand needs to close the data 287 channel that was opened by invoking relevant data channel stack API 288 procedures. 290 It is also worth noting that a data channel stack implementation may 291 not provide any API to create and close data channels; instead the 292 data channels are used on the fly as needed just by communicating via 293 external means or by even having some local configuration/assumptions 294 on both the peers. 296 The application then externally negotiates the data channel 297 properties and sub-protocol properties with the peer's application. 299 [ASSUMPTION] The peer must then symmetrically create a data channel 300 with these negotiated data channel properties. This is the only way 301 for the peer's data channel stack to know which properties to apply 302 when transmitting data on this channel. The data channel stack must 303 allow data channel creation with any non-conflicting stream 304 identifier so that both peers can create the data channel with the 305 same stream identifier. 307 In case the external negotiation is correlated with an SDP offer/ 308 answer exchange that establishes the SCTP association, the SCTP 309 initialization completion triggers a callback from the data channel 310 stack to an application on both the ends to change the data channel 311 state from Connecting to Open. The details of this interface is 312 specific to the data channel user application. Browser based 313 applications (could include hybrid apps) will use [WebRtcAPI], while 314 native applications use a compatible API, which is yet to be 315 specified. See Section 5.2.3 for details on when the data channel 316 stack can assume the data channel is open, and on when the 317 application can assume the data channel is open. 319 4.2.3. Closing a Data Channel 321 When the application requests the closing of an externally negotiated 322 data channel, the data channel stack always performs an in-band SSN 323 reset for this channel. 325 Depending upon the method used for external negotiation and the sub- 326 protocol associated with the data channel, the closing might in 327 addition be signaled to the peer via external negotiation. 329 5. SDP-based External Negotiation 331 This section defines a method of external negotiation by which two 332 clients can negotiate data channel-specific and sub-protocol-specific 333 parameters, using the out-of-band SDP offer/answer exchange. This 334 SDP extension can only be used with SDP offer/answer model. 336 5.1. SDP Syntax 338 Two new SDP attributes are defined to support external negotiation of 339 data channels. The first attribute provides for negotiation of 340 channel-specific parameters. The second attribute provides for 341 negotiation of sub-protocol-specific parameters. 343 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 345 Associated with the SDP "m" line that defines the SCTP association 346 for data channels (defined in Section 4), each SDP offer and answer 347 includes one "a=dcmap:" attribute that defines the data channel 348 parameters for each data channel to be negotiated. Each such 349 attribute line specifies the following parameters for a data channel: 350 SCTP stream identifier, sub-protocol, label, reliability, order of 351 delivery, and priority. 353 The intention of exchanging these attributes is to create data 354 channels on both the peers with the same set of attributes without 355 actually using [I-D.ietf-rtcweb-data-protocol]. It is assumed that 356 the data channel properties (reliable/partially reliable, ordered/ 357 unordered) are suitable per the sub-protocol transport requirements. 359 5.1.1.1. dcmap Attribute 361 "a=dcmap:" is a media level attribute having following ABNF syntax. 363 Formal Syntax: 365 Name: dcmap 367 Value: dcmap-value 369 Usage Level: media 371 Charset Dependent: no 373 Syntax: 375 dcmap-value = dcmap-stream-id 376 [ SP dcmap-opt *(";" dcmap-opt) ] 377 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 378 / maxretr-opt / maxtime-opt 379 ; Either only maxretr-opt or maxtime-opt 380 ; is present. 381 ; Both MUST not be present. 383 dcmap-stream-id = 1*DIGIT 384 ordering-opt = "ordered=" ordering-value 385 ordering-value = "true" / "false" 386 subprotocol-opt = "subprotocol=" quoted-string 387 label-opt = "label=" quoted-string 388 maxretr-opt = "max-retr=" maxretr-value 389 maxretr-value = 391 ; number of retransmissions 392 maxtime-opt = "max-time=" maxtime-value 393 maxtime-value = 395 ; milliseconds 397 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 398 quoted-char = SP / quoted-visible 399 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 400 escaped-char = "%" HEXDIG HEXDIG 401 DQUOTE = 402 integer = 404 Examples: 406 a=dcmap:0 407 a=dcmap:1 subprotocol="BFCP";max-time=60000 408 a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" 409 a=dcmap:3 label="Label 1";ordered=false;max-retr=5 410 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000;max-retr=3 411 Note: The last example (a=dcmap:4) shows a 'label' parameter value 412 which contains one non-printable 'escaped-char' character (the 413 tabulator character). 415 5.1.1.2. dcmap-stream-id Parameter 417 The 'dcmap-stream-id' parameter indicates the SCTP stream identifier 418 within the SCTP association used to form the data channel. 420 5.1.1.3. label Parameter 422 The 'label' parameter indicates the name of the channel. It 423 represents a label that can be used to distinguish, in the context of 424 the WebRTC API, an RTCDataChannel object from other RTCDataChannel 425 objects. This parameter maps to the 'Label' parameter defined in 426 [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. 427 If it is not present, then its value defaults to the empty string. 429 Note: The empty string may also be explicitly used as 'label' value, 430 such that 'label=""' is equivalent to the 'label' parameter not being 431 present at all. [I-D.ietf-rtcweb-data-protocol] allows the 432 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 434 5.1.1.4. subprotocol Parameter 436 The 'subprotocol' parameter indicates which protocol the client 437 expects to exchange via the channel. 'Subprotocol' is an optional 438 parameter. If the 'subprotocol' parameter is not present, then its 439 value defaults to the empty string. 441 5.1.1.5. max-retr Parameter 443 This parameter indicates that the data channel is partially reliable. 444 The 'max-retr' parameter indicates the max times a user message will 445 be retransmitted. The max-retr parameter is optional. If the max- 446 retr parameter is not present, then the maximal number of 447 retransmissions is determined as per the generic SCTP retransmission 448 rules as specified in [RFC4960]. This parameter maps to the 'Number 449 of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 451 5.1.1.6. max-time Parameter 453 This parameter indicates that the data channel is partially reliable. 454 A user message will no longer be transmitted or retransmitted after a 455 specified life-time given in milliseconds in the 'max-time' 456 parameter. The max-time parameter is optional. If the max-time 457 parameter is not present, then the generic SCTP retransmission timing 458 rules apply as specified in [RFC4960]. This parameter maps to the 459 'Lifetime in ms' parameter defined in 460 [I-D.ietf-rtcweb-data-protocol]. 462 5.1.1.7. ordered Parameter 464 The 'ordered' parameter with value "true" indicates that DATA chunks 465 in the channel MUST be dispatched to the upper layer by the receiver 466 while preserving the order. The ordered parameter is optional and 467 takes two values: "true" for ordered and "false" for unordered 468 delivery with "true" as the default value. Any other value is 469 ignored and default "ordered=true" is assumed. In the absence of 470 this parameter "ordered=true" is assumed. This parameter maps to the 471 ordered or unordered data channel types as defined in 472 [I-D.ietf-rtcweb-data-protocol]. 474 5.1.2. Sub-Protocol Specific Attributes 476 In the SDP, each data channel declaration MAY also be followed by 477 other SDP attributes specific to the sub-protocol in use. Each of 478 these attributes is represented by one new attribute line, and it 479 includes the contents of a media-level SDP attribute already defined 480 for use with this (sub)protocol in another IETF specification. Sub- 481 protocol-specific attributes might also be defined for exclusive use 482 with data channel transport, but should use the same syntax described 483 here for other sub-protocol-specific attributes. 485 Each sub-protocol specific SDP attribute that would normally be used 486 to negotiate the subprotocol using SDP is replaced with an attribute 487 of the form "a=dcsa:stream-id original-attribute", where dcsa stands 488 for "data channel sub-protocol attribute", stream-id is the SCTP 489 stream identifier assigned to this sub-protocol instance, and 490 original-attribute represents the contents of the sub-protocol 491 related attribute to be included. 493 Formal Syntax: 495 Name: dcsa 497 Value: dcsa-value 499 Usage Level: media 501 Charset Dependent: no 503 Syntax: 505 dcsa-value = stream-id SP attribute 506 attribute = 508 Example: 510 a=dcsa:2 accept-types:text/plain 512 Thus in the example above, the original attribute line "a=accept- 513 types:text/plain" is represented by the attribute line "a=dcsa:2 514 accept-types:text/plain", which specifies that this instance of MSRP 515 being transported on the sctp association using the data channel with 516 stream id 2 accepts plain text files. 518 As opposed to the data channel "a=dcmap:" attribute parameters, these 519 parameters are subject to offer/answer negotiation following the 520 procedures defined in the sub-protocol specific documents. 522 The same syntax applies to any other SDP attribute required for 523 negotiation of this instance of the sub-protocol. 525 Note: This document does not provide a complete specification of how 526 to negotiate the use of a data channel to transport MSRP. Procedures 527 specific to each sub-protocol such as MSRP will be documented 528 elsewhere. The use of MSRP is only an example of how the generic 529 procedures described herein might apply to a specific sub-protocol. 531 5.2. Procedures 533 5.2.1. Managing Stream Identifiers 535 If an SDP offer / answer exchange (could be the initial or a 536 subsequent one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based 537 media description being accepted, and if this SDP offer / answer 538 exchange results in the establishment of a new SCTP association, then 539 the SDP offerer owns the even SCTP stream ids of this new SCTP 540 association and the answerer owns the odd SCTP stream identifiers. 542 If this "m" line is removed from the signaling session (its port 543 number set to zero), and if usage of this or of a new UDP/DTLS/SCTP 544 or TCP/DTLS/SCTP based "m" line is renegotiated later on, then the 545 even and odd SCTP stream identifier ownership is redetermined as well 546 as described above. 548 This specification allows simultaneous use of external and internal 549 negotiation. However, a single stream is managed using one method at 550 a time. Stream ids that are not currently used in SDP can be used 551 for internal negotiation. Stream id allocation per SDP based 552 external negotiation may not align with DTLS role based allocation. 553 This could cause glare conditions when one side trying to do external 554 negotiation on a stream id while the other end trying to open a data 555 channel on the same stream id using internal negotiation. To avoid 556 these glare conditions this specification recommends that the data 557 channel stack user always selects stream ids per above described SDP 558 offer / answer rule even when internal negotiation is used. To avoid 559 glare conditions, it is possible to come up with a different stream 560 id allocation scheme, but such schemes are outside the scope of this 561 specification. 563 5.2.2. Negotiating Data Channel Parameters 565 Conveying a reliable data channel is achieved by including neither 566 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 567 a=dcmap attribute line. Conveying a partially reliable data channel 568 is achieved by including only one of 'max-retr' or 'max-time'. By 569 definition max-retr and max-time are mutually exclusive, so only one 570 of them can be present in a=dcmap. If an SDP offer contains both of 571 these parameters then such an SDP offer will be rejected. If an SDP 572 answer contains both of these parameters then the offerer may treat 573 it as an error and may assume the associated SDP offer/answer failed 574 and may take appropriate recovery actions. These recovery options 575 are outside the scope of this specification. 577 The SDP answer shall echo the same subprotocol, max-retr, max-time, 578 ordered parameters, if those were present in the offer, and may 579 include a label parameter. They may appear in any order, which could 580 be different from the SDP offer, in the SDP answer. 582 The same information MUST be replicated without changes in any 583 subsequent offer or answer, as long as the data channel is still 584 opened at the time of offer or answer generation. 586 Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are 587 mapped to SDP in the following manner: 589 DATA_CHANNEL_RELIABLE 590 a=dcmap:2 subprotocol="BFCP";label="channel 2" 592 DATA_CHANNEL_RELIABLE_UNORDERED 593 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 594 ordered=0 596 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 597 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 598 max-retr=3 600 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 601 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 602 max-retr=3;ordered=0; 604 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 605 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 606 max-time=10000; 608 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 609 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 610 max-time=10000; ordered=0 612 5.2.3. Opening a Data Channel 614 The procedure for opening a data channel using external negotiation 615 starts with the agent preparing to send an SDP offer. If a peer 616 receives an SDP offer before getting to send a new SDP offer with 617 data channels that are to be externally negotiated, or loses an SDP 618 offer glare resolution procedure in this case, it must wait until the 619 ongoing SDP offer/answer completes before resuming the external 620 negotiation procedure. 622 The agent that intends to send an SDP offer to create data channels 623 through SDP-based external negotiation performs the following: 625 o Creates data channels using stream identifiers from the owned set 626 (see Section 5.2.1). 628 o As described in Section 4.2.2, if the SCTP association is not yet 629 established, then the newly created data channels are in the 630 Connecting state, else if the SCTP association is already 631 established, then the newly created data channels are in the Open 632 state. 634 o Generates a new SDP offer. In the case of the browser based 635 applications the browser generates the offer via the createOffer() 636 API call [I-D.ietf-rtcweb-jsep]. 638 o Determines the list of stream identifiers assigned to data 639 channels opened through external negotiation. 641 o Completes the SDP offer with the dcmap and dcsa attributes needed, 642 if any, for each externally-negotiated data channel, as described 643 in Section 5.1 and in Section 5.2.2. 645 o Sends the SDP offer. 647 The peer receiving such an SDP offer performs the following: 649 o Parses and applies the SDP offer. Note that the typical parser 650 normally ignores unknown SDP attributes, which includes data 651 channel related attributes. 653 o Analyzes the channel parameters and sub-protocol attributes to 654 determine whether to accept each offered data channel. 656 o For accepted data channels, it creates peer instances for the data 657 channels with the agent using the channel parameters described in 658 the SDP offer. Note that the agent is asked to create data 659 channels with SCTP stream identifiers contained in the SDP offer 660 if the SDP offer is accepted. 662 o As described in Section 4.2.2, if the SCTP association is not yet 663 established, then the newly created data channels are in the 664 Connecting state, else if the SCTP association is already 665 established, then the newly created data channels are in the Open 666 state. 668 o Generates an SDP answer. 670 o Completes the SDP answer with the dcmap and optional dcsa 671 attributes needed for each externally-negotiated data channel, as 672 described in Section 5.1 and in Section 5.2.2. 674 o Sends the SDP answer. 676 The agent receiving such an SDP answer performs the following: 678 o Closes any created data channels (whether in Connecting or Open 679 state) for which the expected dcmap and dcsa attributes are not 680 present in the SDP answer. 682 o Applies the SDP answer. 684 Any data channels in Connecting state are transitioned to the Open 685 state when the SCTP association is established. 687 Each agent application MUST wait to send data until it has 688 confirmation that the data channel at the peer is in the Open state. 689 For WebRTC, this is when both data channel stacks have channel 690 parameters instantiated. This occurs: 692 o At both peers when a data channel is created without an 693 established SCTP association, as soon as the data channel stacks 694 report that the data channel transitions to the Open state from 695 the Connecting state. 697 o At the agent receiving an SDP offer for which there is an 698 established SCTP association, as soon as it creates an externally 699 negotiated data channel in the Open state based on information 700 signaled in the SDP offer. 702 o At the agent sending an SDP offer to create a new externally 703 negotiated data channel for which there is an established SCTP 704 association, when it receives the SDP answer confirming acceptance 705 of the data channel or when it begins to receive data on the data 706 channel from the peer, whichever occurs first. 708 5.2.4. Closing a Data Channel 710 When the application requests the closing of a data channel that was 711 externally negotiated, the data channel stack always performs an in- 712 band SSN reset for this channel. 714 It is specific to the sub-protocol whether this closing must in 715 addition be signaled to the peer via a new SDP offer/answer exchange. 717 The intention to close a data channel can be signaled by sending a 718 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute 719 lines for the data channel. The port value for the "m" line SHOULD 720 not be changed (e.g., to zero) when closing a data channel (unless 721 all data channels are being closed and the SCTP association is no 722 longer needed), since this would close the SCTP association and 723 impact all of the data channels. If the answerer accepts the SDP 724 offer then it MUST close those data channels whose "a=dcmap:" and 725 "a=dcsa:" attribute lines were excluded from the received SDP offer, 726 unless those data channels were already closed, and it MUST also 727 exclude the corresponding attribute lines in the answer. In addition 728 to that, the SDP answerer MAY exclude other data channels which were 729 closed but not yet communicated to the peer. So, the offerer MUST 730 inspect the answer to see if it has to close other data channels 731 which are now not included in the answer. 733 If a new SDP offer/answer is used to close data channels then the 734 data channel(s) SHOULD only be closed by the answerer/offerer after a 735 successful SDP answer is sent/received. 737 This delayed closure is RECOMMENDED in order to handle cases where 738 a successful SDP answer is not received, in which case the state 739 of the session SHOULD be kept per the last successful SDP offer/ 740 answer. 742 If a client receives a data channel close indication (due to inband 743 SSN reset or some other reason) without associated SDP offer then an 744 SDP offer which excludes this closed data channel SHOULD be 745 generated. 747 The application must also close any data channel that was externally 748 negotiated, for which the stream identifiers are not listed in an 749 incoming SDP offer. 751 A closed data channel using local close (SCTP reset), without an 752 additional SDP offer/answer to close it, may be reused for a new data 753 channel. This can only be done via new SDP offer/answer, describing 754 the new sub-protocol and its attributes, only after the corresponding 755 data channel close acknowledgement is received from the peer (i.e. 756 SCTP reset of both incoming and outgoing streams is completed). This 757 restriction is to avoid the race conditions between arrival of "SDP 758 offer which reuses stream" with "SCTP reset which closes outgoing 759 stream" at the peer 761 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 763 SDP offer has no a=dcmap attributes 765 * Initial SDP offer: No data channel negotiated yet. 767 * Subsequent SDP offer: All the externally negotiated data 768 channels must be closed now. The DTLS/SCTP association remains 769 open for external or internal negotiation of data channels. 771 SDP answer has no a=dcmap attributes 773 * Initial SDP answer: Either the peer does not support dcmap 774 attributes or it rejected all the data channels. In either 775 case offerer closes all the externally negotiated data channels 776 that were open at the time of initial offer. The DTLS/SCTP 777 association will still be setup. 779 * Sub-sequent SDP answer: All the externally negotiated data 780 channels must be closed now. The DTLS/SCTP association remains 781 open for future external or internal negotiation of data 782 channels. 784 SDP offer has no a=dcsa attributes for a data channel. 786 * This is allowed and indicates there are no sub-protocol 787 parameters to convey. 789 SDP answer has no a=dcsa attributes for a data channel. 791 * This is allowed and indicates there are no sub-protocol 792 parameters to convey in the SDP answer. The number of dcsa 793 attributes in the SDP answer does not have to match the number 794 of dcsa attributes in the SDP offer. 796 6. Examples 798 SDP offer: 799 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 800 c=IN IP4 10.10.10.1 801 a=max-message-size:100000 802 a=sctp-port 5000 803 a=setup:actpass 804 a=connection:new 805 a=fingerprint:SHA-1 \ 806 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 807 a=dcmap:0 subprotocol="BFCP";label="BFCP" 809 SDP answer: 810 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 811 c=IN IP4 10.10.10.2 812 a=max-message-size:100000 813 a=sctp-port 5002 814 a=setup:passive 815 a=connection:new 816 a=fingerprint:SHA-1 \ 817 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 819 Figure 1: Example 1 821 In the above example the SDP answerer rejected the data channel with 822 stream id 0 either for explicit reasons or because it does not 823 understand the a=dcmap attribute. As a result the offerer will close 824 the data channel created with the external negotiation option. The 825 SCTP association will still be setup over DTLS. At this point the 826 offerer or the answerer may use internal negotiation to open data 827 channels. 829 SDP offer: 830 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 831 c=IN IP4 10.10.10.1 832 a=max-message-size:100000 833 a=sctp-port 5000 834 a=setup:actpass 835 a=connection:new 836 a=fingerprint:SHA-1 \ 837 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 838 a=dcmap:0 subprotocol="BFCP";label="BFCP" 839 a=dcmap:2 subprotocol="MSRP";label="MSRP" 840 a=dcsa:2 accept-types:message/cpim text/plain text/ 841 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 843 SDP answer: 844 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 845 c=IN IP4 10.10.10.2 846 a=max-message-size:100000 847 a=sctp-port 5002 848 a=setup:passive 849 a=connection:new 850 a=fingerprint:SHA-1 \ 851 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 852 a=dcmap:2 subprotocol="MSRP";label="MSRP" 853 a=dcsa:2 accept-types:message/cpim text/plain 854 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 856 Figure 2: Example 2 858 In the above example SDP offer contains data channels for BFCP and 859 MSRP sub-protocols. SDP answer rejected BFCP and accepted MSRP. So, 860 the offerer should close the data channel for BFCP and both offerer 861 and answerer may start using MSRP data channel (after SCTP/DTLS 862 association is setup). The data channel with stream id 0 is free and 863 can be used for future internal or external negotiation. 865 Continuing on the earlier example in Figure 1. 867 Subsequent SDP offer: 868 m=application 10001 UDP/DTLS/SCTP webrtc-datachannel 869 c=IN IP4 10.10.10.1 870 a=max-message-size:100000 871 a=sctp-port 5000 872 a=setup:actpass 873 a=connection:existing 874 a=fingerprint:SHA-1 \ 875 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 876 a=dcmap:4 subprotocol="MSRP";label="MSRP" 877 a=dcsa:4 accept-types:message/cpim text/plain 878 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 880 Subsequent SDP answer: 881 m=application 10002 UDP/DTLS/SCTP webrtc-datachannel 882 c=IN IP4 10.10.10.2 883 a=max-message-size:100000 884 a=sctp-port 5002 885 a=setup:passive 886 a=connection:existing 887 a=fingerprint:SHA-1 \ 888 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 889 a=dcmap:4 subprotocol="MSRP";label="MSRP" 890 a=dcsa:4 accept-types:message/cpim text/plain 891 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 893 Figure 3: Example 3 895 The above example is a continuation of the example in Figure 1. The 896 SDP offer now removes the MSRP data channel with stream id 2, but 897 opens a new MSRP data channel with stream id 4. The answerer 898 accepted the entire offer. As a result the offerer closes the 899 earlier negotiated MSRP related data channel and both offerer and 900 answerer may start using new the MSRP related data channel. 902 7. Security Considerations 904 No security considerations are envisaged beyond those already 905 documented in [RFC4566] 907 8. IANA Considerations 909 To be completed. As [I-D.ietf-rtcweb-data-protocol] this document 910 should refer to IANA's WebSocket Subprotocol Name Registry defined in 911 [RFC6455]. 913 9. Acknowledgments 915 The authors wish to acknowledge the borrowing of ideas from other 916 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 917 and Gavin Llewellyn, and to thank Christian Groves, Christer 918 Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe Rauschenbach for 919 their invaluable comments. 921 10. CHANGE LOG 923 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 925 o In Section 3 "WebRTC data channel" was defined as "A bidirectional 926 channel consisting of paired SCTP outbound and inbound streams." 927 Replacement of this definition with "Data channel: A WebRTC data 928 channel as specified in [I-D.ietf-rtcweb-data-channel]", and 929 consistent usage of "data channel" in the remainder of the 930 document including the document's headline." 932 o In Section 4 removal of following note: 'OPEN ISSUE: The syntax in 933 [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. 934 In particular we expect "webrtc-datachannel" to become a more 935 general term.' 937 o Consistent usage of '"m" line' in whole document as per [RFC4566]. 939 o In Section 5.1.1 removal of the example dcmap attribute line 940 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 941 already four examples right after the ABNF rules in 942 Section 5.1.1.1. Corresponding removal of following related note: 943 "Note: This document does not provide a complete specification of 944 how to negotiate the use of a WebRTC data channel to transport 945 BFCP. Procedures specific to each sub-protocol such as BFCP will 946 be documented elsewhere. The use of BFCP is only an example of 947 how the generic procedures described herein might apply to a 948 specific sub-protocol." 950 o In Section 5.1.1 removal of following note: "Note: This attribute 951 is derived from attribute "webrtc-DataChannel", which was defined 952 in old version 03 of the following draft, but which was removed 953 along with any support for SDP external negotiation in subsequent 954 versions: [I-D.ietf-mmusic-sctp-sdp]." 956 o Insertion of following new sentence to the beginning of 957 Section 5.1.1.1: "dcmap is a media level attribute having 958 following ABNF syntax:" 960 o Insertion of new Section 5.1.1.2 containing the dcmap-stream-id 961 specifying sentence, which previously was placed right before the 962 formal ABNF rules. Removal of the sentence 'Stream is a mandatory 963 parameter and is noted directly after the "a=dcmap:" attribute's 964 colon' as this information is part of the ABNF specification. 966 o In Section 5.1.1.1 modification of the 'ordering-value' values 967 from "0" or "1" to "true" or "false". Corresponding text 968 modifications in Section 5.1.1.7. 970 o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred 971 to rule name "escaped-char", which was not defined. Instead a 972 rule with name "escaped" was defined. Renamed that rule's name to 973 "escaped-char". 975 o Insertion of a dedicated note right after the "a=dcmap:4" 976 attribute example in Section 5.1.1.1 regarding the non-printable 977 "escaped-char" character within the "label" value. 979 o In Section 5.1.2's second paragraph replacement of "sctp stream 980 identifier" with "SCTP stream identifier". 982 o In first paragraph of Section 5.2.1 replacement of first two 983 sentences 'For the SDP-based external negotiation described in 984 this document, the initial offerer based "SCTP over DTLS" owns by 985 convention the even stream identifiers whereas the initial 986 answerer owns the odd stream identifiers. This ownership is 987 invariant for the whole lifetime of the signaling session, e.g. it 988 does not change if the initial answerer sends a new offer to the 989 initial offerer.' with 'If an SDP offer / answer exchange (could 990 be the initial or a subsequent one) results in a UDP/DTLS/SCTP or 991 TCP/DTLS/SCTP based media description being accepted, and if this 992 SDP offer / answer exchange results in the establishment of a new 993 SCTP association, then the SDP offerer owns the even SCTP stream 994 ids of this new SCTP association and the answerer owns the odd 995 SCTP stream identifiers. If this "m" line is removed from the 996 signaling session (its port number set to zero), and if usage of 997 this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is 998 renegotiated later on, then the even and odd SCTP stream 999 identifier ownership is redetermined as well as described above.' 1001 o In Section 5.2.3 the first action of an SDP answerer, when 1002 receiving an SDP offer, was described as "Applies the SDP offer. 1003 Note that the browser ignores data channel specific attributes in 1004 the SDP." Replacement of these two sentences with "Parses and 1005 applies the SDP offer. Note that the typical parser normally 1006 ignores unknown SDP attributes, which includes data channel 1007 related attributes." 1009 o In Section 5.2.3 the second sentence of the third SDP answerer 1010 action was "Note that the browser is asked to create data channels 1011 with stream identifiers not "owned" by the agent.". Replacement 1012 of this sentence with "Note that the agent is asked to create data 1013 channels with SCTP stream identifiers contained in the SDP offer 1014 if the SDP offer is accepted." 1016 o In Section 5.2.4 the third paragraph began with "A data channel 1017 can be closed by sending a new SDP offer which excludes the dcmap 1018 and dcsa attribute lines for the data channel. The port value for 1019 the m line should not be changed (e.g., to zero) when closing a 1020 data channel (unless all data channels are being closed and the 1021 SCTP association is no longer needed), since this would close the 1022 SCTP association and impact all of the data channels. If the 1023 answerer accepts the SDP offer then it MUST also exclude the 1024 corresponding attribute lines in the answer. ..." Replacement of 1025 this part with "The intention to close a data channel can be 1026 signaled by sending a new SDP offer which excludes the "a=dcmap:" 1027 and "a=dcsa:" attribute lines for the data channel. The port 1028 value for the "m" line SHOULD not be changed (e.g., to zero) when 1029 closing a data channel (unless all data channels are being closed 1030 and the SCTP association is no longer needed), since this would 1031 close the SCTP association and impact all of the data channels. 1032 If the answerer accepts the SDP offer then it MUST close those 1033 data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were 1034 excluded from the received SDP offer, unless those data channels 1035 were already closed, and it MUST also exclude the corresponding 1036 attribute lines in the answer." 1038 o In Section 5.2.4 the hanging text after the third paragraph was 1039 "This delayed close is to handle cases where a successful SDP 1040 answer is not received, in which case the state of session should 1041 be kept per the last successful SDP offer/answer." Replacement of 1042 this sentence with "This delayed closure is RECOMMENDED in order 1043 to handle cases where a successful SDP answer is not received, in 1044 which case the state of the session SHOULD be kept per the last 1045 successful SDP offer/answer." 1047 o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects 1048 Section 5.1.1 contained already procedural descriptions related to 1049 data channel reliability negotiation. Creation of new 1050 Section 5.2.2 and moval of reliability negotiation related text to 1051 this new section. 1053 10.2. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 1055 o Removal of note "[ACTION ITEM]" from section "subprotocol 1056 parameter". As [I-D.ietf-rtcweb-data-protocol] this document 1057 should refer to IANA's WebSocket Subprotocol Name Registry defined 1058 in [RFC6455]. 1060 o In whole document, replacement of "unreliable" with "partially 1061 reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in 1062 [I-D.ietf-rtcweb-data-protocol] in most places. 1064 o Clarification of the semantic if the "max-retr" parameter is not 1065 present in an a=dcmap attribute line. In section "max-retr 1066 parameter" the sentence "The max-retr parameter is optional with 1067 default value unbounded" was replaced with "The max-retr parameter 1068 is optional. If the max-retr parameter is not present, then the 1069 maximal number of retransmissions is determined as per the generic 1070 SCTP retransmission rules as specified in [RFC4960]". 1072 o Clarification of the semantic if the "max-time" parameter is not 1073 present in an a=dcmap attribute line. In section "max-time 1074 parameter" the sentence "The max-time parameter is optional with 1075 default value unbounded" was replaced with "The max-time parameter 1076 is optional. If the max-time parameter is not present, then the 1077 generic SCTP retransmission timing rules apply as specified in 1078 [RFC4960]". 1080 o In section "label parameter" the sentence "Label is a mandatory 1081 parameter." was removed and following new sentences (including the 1082 note) were added: "The 'label' parameter is optional. If it is 1083 not present, then its value defaults to the empty string. Note: 1084 The empty string may also be explicitly used as 'label' value, 1085 such that 'label=""' is equivalent to the 'label' parameter not 1086 being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 1087 DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." 1089 o In section "subprotocol parameter" the sentence "Subprotocol is a 1090 mandatory parameter." was replaced with "'Subprotocol' is an 1091 optional parameter. If the 'subprotocol' parameter is not 1092 present, then its value defaults to the empty string." 1094 o In the "Examples" section, in the first two SDP offer examples in 1095 the a=dcmap attribute lines 'label="BGCP"' was replaced with 1096 'label="BFCP"'. 1098 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced 1099 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 1100 replaced with "a=max-message-size" attribute lines, as per draft- 1101 ietf-mmusic-sctp-sdp-12. 1103 10.3. Changes against '-01' 1105 o Formal syntax for dcmap and dcsa attribute lines. 1107 o Making subprotocol as an optional parameter in dcmap. 1109 o Specifying disallowed parameter combinations for max-time and max- 1110 retr. 1112 o Clarifications on WebRTC data channel close procedures. 1114 10.4. Changes against '-00' 1116 o Revisions to identify difference between internal and external 1117 negotiation and their usage. 1119 o Introduction of more generic terminology, e.g. "application" 1120 instead of "browser". 1122 o Clarification of how "max-retr and max-time affect the usage of 1123 unreliable and reliable WebRTC data channels. 1125 o Updates of examples to take into account the SDP syntax changes 1126 introduced with draft-ietf-mmusic-sctp-sdp-07. 1128 o Removal of the SCTP port number from the a=dcmap and a=dcsa 1129 attributes as this is now contained in the a=sctp-port attribute, 1130 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 1131 association on top of the DTLS connection. 1133 11. References 1135 11.1. Normative References 1137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1138 Requirement Levels", BCP 14, RFC 2119, March 1997. 1140 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1141 Description Protocol", RFC 4566, July 2006. 1143 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1144 with Session Description Protocol (SDP)", RFC 3264, June 1145 2002. 1147 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1148 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1150 [I-D.ietf-rtcweb-jsep] 1151 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 1152 Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 1153 (work in progress), October 2014. 1155 [I-D.ietf-rtcweb-data-channel] 1156 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1157 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1158 progress), January 2015. 1160 [I-D.ietf-mmusic-sctp-sdp] 1161 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1162 Control Transmission Protocol (SCTP)-Based Media Transport 1163 in the Session Description Protocol (SDP)", draft-ietf- 1164 mmusic-sctp-sdp-14 (work in progress), March 2015. 1166 [WebRtcAPI] 1167 Bergkvist, A., Burnett, D., Jennings, C., and A. 1168 Narayanan, "WebRTC 1.0: Real-time Communication Between 1169 Browsers", World Wide Web Consortium WD-webrtc-20130910, 1170 September 2013, 1171 . 1173 11.2. Informative References 1175 [I-D.ietf-rtcweb-data-protocol] 1176 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1177 Establishment Protocol", draft-ietf-rtcweb-data- 1178 protocol-09 (work in progress), January 2015. 1180 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1181 4960, September 2007. 1183 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1184 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1186 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1187 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1188 September 2007. 1190 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 1191 and P. Kyzivat, "A Session Description Protocol (SDP) 1192 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 1193 May 2009. 1195 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 1196 for the Message Session Relay Protocol (MSRP)", RFC 6135, 1197 February 2011. 1199 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 1200 6455, December 2011. 1202 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1203 Establishment for Media Anchoring (CEMA) for the Message 1204 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 1206 Authors' Addresses 1208 Keith Drage (editor) 1209 Alcatel-Lucent 1210 Quadrant, Stonehill Green, Westlea 1211 Swindon 1212 UK 1214 Email: keith.drage@alcatel-lucent.com 1216 Maridi R. Makaraju (Raju) 1217 Alcatel-Lucent 1218 2000 Lucent Lane 1219 Naperville, Illinois 1220 US 1222 Email: Raju.Makaraju@alcatel-lucent.com 1224 Juergen Stoetzer-Bradler 1225 Alcatel-Lucent 1226 Lorenzstrasse 10 1227 D-70435 Stuttgart 1228 Germany 1230 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 1232 Richard Ejzak 1233 Unaffiliated 1235 Email: richard.ejzak@gmail.com 1237 Jerome Marcon 1238 Unaffiliated