idnits 2.17.1 draft-ejzak-mmusic-data-channel-sdpneg-02.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. -- The document date (October 27, 2014) is 3466 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 297, but not defined == Missing Reference: 'ACTION ITEM' is mentioned on line 487, but not defined == Unused Reference: 'RFC3264' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-data-channel' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'RFC5547' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'RFC6135' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'RFC6714' is defined on line 1000, 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-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'WebRtcAPI' == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-08 Summary: 1 error (**), 0 flaws (~~), 17 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: April 30, 2015 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 October 27, 2014 11 SDP-based "SCTP over DTLS" data channel negotiation 12 draft-ejzak-mmusic-data-channel-sdpneg-02 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) WebRTC 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 April 30, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 9 80 5.1.1.2. label parameter . . . . . . . . . . . . . . . . . 10 81 5.1.1.3. subprotocol parameter . . . . . . . . . . . . . . 11 82 5.1.1.4. max-retr parameter . . . . . . . . . . . . . . . 11 83 5.1.1.5. max-time parameter . . . . . . . . . . . . . . . 11 84 5.1.1.6. ordered parameter . . . . . . . . . . . . . . . . 11 85 5.1.2. Sub-protocol specific attributes . . . . . . . . . . 11 86 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.2.1. Managing stream identifiers . . . . . . . . . . . . . 13 88 5.2.2. Opening a data channel . . . . . . . . . . . . . . . 13 89 5.2.3. Closing a data channel . . . . . . . . . . . . . . . 15 90 5.2.4. Various SDP offer/answer scenarios and considerations 16 91 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 95 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 10.1. Changes against '-01' . . . . . . . . . . . . . . . . . 20 97 10.2. Changes against '-00' . . . . . . . . . . . . . . . . . 20 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 11.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 The RTCWeb working group has defined the concept of bi-directional 107 data channels running on top of SCTP/DTLS. RTCWeb leaves it open for 108 other applications to use data channels and its in-band or out-of- 109 band protocol for creating them. Each data channel consists of 110 paired SCTP streams sharing the same SCTP Stream Identifier. Data 111 channels are created by endpoint applications through the WebRTC API, 112 or other users of data channel like CLUE, and can be used to 113 transport proprietary or well-defined protocols, which in the latter 114 case can be signaled by the data channel "sub-protocol" parameter, 115 conceptually similar to the WebSocket "sub-protocol". However, apart 116 from the "sub-protocol" value transmitted to the peer, RTCWeb leaves 117 it open how endpoint applications can agree on how to instantiate a 118 given sub-protocol on a data channel, and whether it is signaled in- 119 band or out-of-band (or both). In particular, the SDP offer 120 generated by the application includes no channel-specific 121 information. 123 This document defines SDP-based out-of-band negotiation procedures to 124 establish data channels for transport of well-defined sub-protocols. 126 2. Conventions 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. Terminology 134 This document uses the following terms: 136 Data channel: A bidirectional channel consisting of paired SCTP 137 outbound and inbound streams. 139 Data channel stack: An entity which, upon application request, 140 runs data channel protocol to keep track of states, sending and 141 receive data. If the application is browser based Javascript 142 application then this stack resides in the browser. If the 143 application is a native application then this stack resides in 144 application and accessible to it via some sort of APIs. 146 Data channel properties: fixed properties assigned to a data 147 channel at the time of its creation. Some of these properties 148 determine the way the data channel stack transmits data on this 149 channel (e.g., stream identifier, reliability, order of 150 delivery...) 152 DCEP - Data Channel Establishment Protocol defined in 153 [I-D.ietf-rtcweb-data-protocol]. 155 External negotiation: Data channel negotiation based on SDP offer/ 156 answer outlined in this specification. 158 Internal negotiation: Data channel negotiation based on Data 159 Channel Establishment Protocol defined in 160 [I-D.ietf-rtcweb-data-protocol]. 162 In-band: transmission through the peer-to-peer SCTP association. 164 In-band negotiation: data channel negotiation based Data Channel 165 Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol]. 167 Out-of-band: transmission through the application signaling path. 169 Peer: From the perspective of one of the agents in a session, its 170 peer is the other agent. Specifically, from the perspective of 171 the SDP offerer, the peer is the SDP answerer. From the 172 perspective of the SDP answerer, the peer is the SDP offerer. 174 Stream identifier: the identifier of the outbound and inbound SCTP 175 streams composing a data channel. 177 4. Data Channels 179 This section summarizes how data channels work in general. Note that 180 the references to 'browser' here is intentional as in this specific 181 example the data channel user is a webrtc enabled browser. 183 A WebRTC application creates a data channel via the Data Channel API, 184 by providing a number of setup parameters (sub-protocol, label, 185 reliability, order of delivery, priority). The application also 186 specifies if it wants to make use of the in-band negotiation using 187 the DCEP [I-D.ietf-rtcweb-data-protocol], or if the application 188 intends to perform an "external negotiation" using some other in-band 189 or out-of-band mechanism. 191 In any case, the SDP offer generated by the browser is per 192 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one m-line for the 193 SCTP association on top of which data channels will run, and one 194 attribute per protocol assigned to the SCTP ports: 196 OPEN ISSUE: The syntax in [I-D.ietf-mmusic-sctp-sdp] may change as 197 that document progresses. In particular we expect "webrtc- 198 datachannel" to become a more general term. 200 m=application 54111 DTLS/SCTP webrtc-datachannel 201 c=IN IP4 79.97.215.79 202 a=fmtp:webrtc-datachannel max-message-size=100000 203 a=sctp-port 5000 204 a=setup:actpass 205 a=connection:new 206 a=fingerprint:SHA-1 \ 207 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 209 Note: A WebRTC browser will only use m-line format "webrtc- 210 datachannel", and will not use other formats in the m-line for other 211 protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports only one 212 SCTP association to be established on top of a DTLS session. 214 Note: This SDP syntax does not contain any channel-specific 215 information. 217 4.1. Stream identifier numbering 219 Independently from the requested type of negotiation, the application 220 creating a data channel can either pass to the browser the stream 221 identifier to assign to the data channel or else let the browser pick 222 one identifier from the ones unused. 224 To avoid glare situations, each endpoint can moreover own an 225 exclusive set of stream identifiers, in which case an endpoint can 226 only create a data channel with a stream identifier it owns. 228 Which set of stream identifiers is owned by which endpoint is 229 determined by convention or other means. 231 For data channels negotiated in-band, one endpoint owns by 232 convention the even stream identifiers, whereas the other owns the 233 odd stream identifiers, as defined in 234 [I-D.ietf-rtcweb-data-protocol]. 236 For data channels externally negotiated, no convention is defined 237 by default. 239 4.2. Generic external negotiation 241 4.2.1. Overview 243 In-band negotiation only provides for negotiation of data channel 244 transport parameters and does not provide for negotiation of sub- 245 protocol specific parameters. External negotiation can be defined to 246 allow negotiation of parameters beyond those handled by in-band 247 negotiation, e.g., parameters specific to the sub-protocol 248 instantiated on a particular data channel. See Section 5.1.2 for an 249 example of such a parameter. 251 The following procedures are common to all methods of external 252 negotiation, whether in-band (communicated using proprietary means on 253 an already established data channel) or out-of-band (using SDP or 254 some other protocol associated with the signaling channel). 256 4.2.2. Opening a data channel 258 In the case of external negotiation, the endpoint application has the 259 option to fully control the stream identifier assignments. However 260 these assignments have to coexist with the assignments controlled by 261 the data channel stack for the in-band negotiated data channels (if 262 any). It is the responsibility of the application to ensure 263 consistent assignment of stream identifiers. 265 When the application requests the creation of a new data channel to 266 be set up via external negotiation, the data channel stack creates 267 the data channel locally without sending any DATA CHANNEL OPEN 268 message in-band, and sets the data channel state to Connecting if the 269 SCTP association is not yet established, or sets the data channel 270 state to Open if the SCTP association is already established. The 271 side which starts external negotiation creates data channel using 272 underlying data channel stack API and the data channel is put into 273 open state immediately (assuming ICE, SCTP procedures were already 274 done). However, the application can't send data on this data channel 275 until external negotiation is complete with the peer. This is 276 because peer needs to be aware and accept the data channel via 277 external negotiation. The peer after accepting the data channel 278 offer can start sending data immediately. This implies that offerer 279 may get data channel message before external negotiation is complete 280 and the application should be ready to handle it. 282 If the peer rejects the data channel part of the offer then it 283 doesn't have to do anything as the data channel was not created using 284 the stack. The offerer on the other hand needs to close the data 285 channel that was opened by invoking relevant data channel stack API 286 procedures. 288 It is also worth noting that a data channel stack implementation may 289 not provide any API to create and close data channels; instead the 290 data channels are used on the fly as needed just by communicating via 291 external means or by even having some local configuration/assumptions 292 on both the peers. 294 The application then externally negotiates the data channel 295 properties and sub-protocol properties with the peer's application. 297 [ASSUMPTION] The peer must then symmetrically create a data channel 298 with these negotiated data channel properties. This is the only way 299 for the peer's data channel stack to know which properties to apply 300 when transmitting data on this channel. The data channel stack must 301 allow data channel creation with any non-conflicting stream 302 identifier so that both peers can create the data channel with the 303 same stream identifier. 305 In case the external negotiation is correlated with an SDP offer/ 306 answer exchange that establishes the SCTP association, the SCTP 307 initialization completion triggers a callback from the data channel 308 stack to an application on both the ends to change the data channel 309 state from Connecting to Open. The details of this interface is 310 specific to the data channel user application. Browser based 311 applications (could include hybrid apps) will use [WebRtcAPI], while 312 native applications use a compatible API, which is yet to be 313 specified. See Section 5.2.2 for details on when the data channel 314 stack can assume the data channel is open, and on when the 315 application can assume the data channel is open. 317 4.2.3. Closing a data channel 319 When the application requests the closing of an externally negotiated 320 data channel, the data channel stack always performs an in-band SSN 321 reset for this channel. 323 Depending upon the method used for external negotiation and the sub- 324 protocol associated with the data channel, the closing might in 325 addition be signaled to the peer via external negotiation. 327 5. SDP-based external negotiation 329 This section defines a method of external negotiation by which two 330 clients can negotiate data channel-specific and sub-protocol-specific 331 parameters, using the out-of-band SDP offer/answer exchange. This 332 SDP extension can only be used with SDP offer/answer model. 334 5.1. SDP syntax 336 Two new SDP attributes are defined to support external negotiation of 337 data channels. The first attribute provides for negotiation of 338 channel-specific parameters. The second attribute provides for 339 negotiation of sub-protocol-specific parameters. 341 5.1.1. SDP attribute for data channel parameter negotiation 343 Associated with the SDP "m" line that defines the SCTP association 344 for data channels (defined in Section 4), each SDP offer and answer 345 includes an attribute line that defines the data channel parameters 346 for each data channel to be negotiated. Each attribute line 347 specifies the following parameters for a data channel: Stream 348 Identifier, sub-protocol, label, reliability, order of delivery, and 349 priority. Conveying a reliable data channel is achieved by including 350 neither 'max-retr' nor 'max-time'. Conveying an unreliable data 351 channel is achieved by including only one of 'max-retr' or 'max- 352 time'. By definition max-retr and max-time are mutually exclusive, 353 so only one of them can be present in a=dcmap. If an SDP offer 354 contains both of these parameters then such an SDP offer will be 355 rejected. If an SDP answer contains both of these parameters then 356 the offerer may treat it as an error and may assume the associated 357 SDP offer/answer failed and may take appropriate recovery actions. 358 These recovery options are outside the scope of this specification. 359 Following is an example of the attribute line for sub-protocol "BFCP" 360 and stream id "2": 362 a=dcmap:2 subprotocol="BFCP";label="channel 2" 364 The SDP answer shall echo the same subprotocol, max-retr, max-time, 365 ordered parameters, if those were present in the offer, and may 366 include a label parameter. They may appear in any order, which could 367 be different from the SDP offer, in the SDP answer. 369 The same information MUST be replicated without changes in any 370 subsequent offer or answer, as long as the data channel is still 371 opened at the time of offer or answer generation. 373 Note: This attribute is derived from attribute "webrtc- 374 DataChannel", which was defined in old version 03 of the following 375 draft, but which was removed along with any support for SDP 376 external negotiation in subsequent versions: 377 [I-D.ietf-mmusic-sctp-sdp]. 379 Note: This document does not provide a complete specification of 380 how to negotiate the use of a data channel to transport BFCP. 381 Procedures specific to each sub-protocol such as BFCP will be 382 documented elsewhere. The use of BFCP is only an example of how 383 the generic procedures described herein might apply to a specific 384 sub-protocol. 386 The intention of exchanging these attributes is to create data 387 channels on both the peers with the same set of attributes without 388 actually using [I-D.ietf-rtcweb-data-protocol]. It is assumed that 389 the data channel properties (reliable/unreliable, ordered/unordered) 390 are suitable per the sub-protocol transport requirements. Data 391 channel types defined in [I-D.ietf-rtcweb-data-protocol] are mapped 392 to SDP in the following manner: 394 DATA_CHANNEL_RELIABLE 395 a=dcmap:2 subprotocol="BFCP";label="channel 2" 397 DATA_CHANNEL_RELIABLE_UNORDERED 398 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 399 ordered=0 401 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 402 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 403 max-retr=3 405 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED 406 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 407 max-retr=3;ordered=0; 409 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 410 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 411 max-time=10000; 413 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED 414 a=dcmap:2 subprotocol="BFCP";label="channel 2";\ 415 max-time=10000; ordered=0 417 5.1.1.1. dcmap attribute 419 The 'stream' parameter indicates the actual stream identifier within 420 the association used to form the channel. Stream is a mandatory 421 parameter and is noted directly after the "a=dcmap:" attribute's 422 colon. 424 Formal Syntax: 425 TBD: Should this be moved to SDP grammar section? 427 Name: dcmap 429 Value: dcmap-value 430 Usage Level: media 432 Charset Dependent: no 434 Syntax: 436 dcmap-value = dcmap-stream-id 437 [ SP dcmap-opt *(";" dcmap-opt) ] 438 dcmap-opt = ordering-opt / subprotocol-opt / label-opt 439 / maxretr-opt / maxtime-opt 440 ; Either only maxretr-opt or maxtime-opt 441 ; is present. 442 ; Both MUST not be present. 444 dcmap-stream-id = 1*DIGIT 445 ordering-opt = "ordered=" ordering-value 446 ordering-value = "0"/"1" 447 subprotocol-opt = "subprotocol=" quoted-string 448 label-opt = "label=" quoted-string 449 maxretr-opt = "max-retr=" maxretr-value 450 maxretr-value = 452 ; number of retransmissions 453 maxtime-opt = "max-time=" maxtime-value 454 maxtime-value = 456 ; milliseconds 458 quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE 459 quoted-char = SP / quoted-visible 460 quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % 461 escaped = "%" HEXDIG HEXDIG 462 DQUOTE = 463 integer = 465 Examples: 467 a=dcmap:0 468 a=dcmap:1 subprotocol="BFCP";max-time=60000 469 a=dcmap:2 subprotocol="MSRP";ordered;label="MSRP" 470 a=dcmap:3 label="Label 1";unordered;max-retr=5 471 a=dcmap:4 label="foo%09bar";ordered;max-time=15000;max-retr=3 473 5.1.1.2. label parameter 475 The optional 'label' parameter indicates the name of the channel. It 476 represents a label that can be used to distinguish, in the context of 477 the WebRTC API, an RTCDataChannel object from other RTCDataChannel 478 objects. Label is a mandatory parameter. This parameter maps to the 479 'label' parameter defined in [I-D.ietf-rtcweb-data-protocol] 481 5.1.1.3. subprotocol parameter 483 The 'subprotocol' parameter indicates which protocol the client 484 expects to exchange via the channel. Subprotocol is a mandatory 485 parameter. 487 [ACTION ITEM] The IANA registry to be used for the subprotocol 488 parameter is still to be determined. It also needs to be determined 489 what the relationship is to existing registries and how to reference 490 already-existing protocols. 492 5.1.1.4. max-retr parameter 494 This parameter indicates that the data channel is unreliable. The 495 'max-retr' parameter indicates the max times a user message will be 496 retransmitted. The max-retr parameter is optional with default value 497 unbounded. This parameter maps to the 'Number of RTX' parameter 498 defined in [I-D.ietf-rtcweb-data-protocol] 500 5.1.1.5. max-time parameter 502 This parameter indicates that the data channel is unreliable. A user 503 messages 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 with default value 506 unbounded. This parameter maps to the 'Lifetime in ms' parameter 507 defined in [I-D.ietf-rtcweb-data-protocol] 509 5.1.1.6. ordered parameter 511 The ordered' parameter indicates that DATA chunks in the channel MUST 512 be dispatched to the upper layer by the receiver while preserving the 513 order. The ordered parameter is optional and takes two values: "0" 514 for ordered and "1" for ordered delivery with "1" as the default 515 value. Any other value is ignored and default ordered is assumed. 516 If the ordered parameter is absent, the receiver is required to 517 deliver DATA chunks to the upper layer in proper order. This 518 parameter maps to the ordered or unorderd data channel types as 519 defined in [I-D.ietf-rtcweb-data-protocol] 521 5.1.2. Sub-protocol specific attributes 523 In the SDP, each data channel declaration MAY also be followed by 524 other SDP attributes specific to the sub-protocol in use. Each of 525 these attributes is represented by one new attribute line, and it 526 includes the contents of a media-level SDP attribute already defined 527 for use with this (sub)protocol in another IETF specification. Sub- 528 protocol-specific attributes might also be defined for exclusive use 529 with data channel transport, but should use the same syntax described 530 here for other sub-protocol-specific attributes. 532 Each sub-protocol specific SDP attribute that would normally be used 533 to negotiate the subprotocol using SDP is replaced with an attribute 534 of the form "a=dcsa: stream-id original-attribute", where dcsa stands 535 for "data channel sub-protocol attribute", stream-id is the sctp 536 stream identifier assigned to this sub-protocol instance, and 537 original-attribute represents the contents of the sub-protocol 538 related attribute to be included. 540 Formal Syntax: 542 Name: dcsa 544 Value: dcsa-value 546 Usage Level: media 548 Charset Dependent: no 550 Syntax: 552 dcsa-value = stream-id SP attribute 553 attribute = 555 Examples: 557 a=dcsa:2 accept-types:text/plain 559 Thus in the example above, the original attribute line "a=accept- 560 types:text/plain" is represented by the attribute line "a=dcsa:2 561 accept-types:text/plain", which specifies that this instance of MSRP 562 being transported on the sctp association using the data channel with 563 stream id 2 accepts plain text files. The above example creates a 564 reliable, ordered data channel. 566 As opposed to the data channel setup parameters, these parameters are 567 subject to offer/answer negotiation following the procedures defined 568 in the sub-protocol specific documents. 570 The same syntax applies to any other SDP attribute required for 571 negotiation of this instance of the sub-protocol. 573 Note: This document does not provide a complete specification of how 574 to negotiate the use of a data channel to transport MSRP. Procedures 575 specific to each sub-protocol such as MSRP will be documented 576 elsewhere. The use of MSRP is only an example of how the generic 577 procedures described herein might apply to a specific sub-protocol. 579 5.2. Procedures 581 5.2.1. Managing stream identifiers 583 For the SDP-based external negotiation described in this document, 584 the initial offerer based "SCTP over DTLS" owns by convention the 585 even stream identifiers whereas the initial answerer owns the odd 586 stream identifiers. This ownership is invariant for the whole 587 lifetime of the signaling session, e.g. it does not change if the 588 initial answerer sends a new offer to the initial offerer. 590 This specification allows simultaneous use of external and internal 591 negotiation. However, a single stream is managed using one method at 592 a time. Stream ids that are not currently used in SDP can be used 593 for internal negotiation. Stream id allocation per SDP based 594 external negotiation may not align with DTLS role based allocation. 595 This could cause glare conditions when one side trying to do external 596 negotiation on a stream id while the other end trying to open data 597 channel on the same stream id using internal negotiation. To avoid 598 these glare conditions this specification recommends that the data 599 channel stack user always selects stream ids per SDP offer/answer 600 rule even when internal negotiation is used. To avoid glare 601 conditions, it is possible to come up with a different stream id 602 allocation scheme, but such schemes are outside the scope of this 603 specification. 605 5.2.2. Opening a data channel 607 The procedure for opening a data channel using external negotiation 608 starts with the agent preparing to send an SDP offer. If a peer 609 receives an SDP offer before getting to send a new SDP offer with 610 data channels that are to be externally negotiated, or loses an SDP 611 offer glare resolution procedure in this case, it must wait until the 612 ongoing SDP offer/answer completes before resuming the external 613 negotiation procedure. 615 The agent that intends to send an SDP offer to create data channels 616 through SDP-based external negotiation performs the following: 618 o Creates data channels using stream identifiers from the owned set 619 (see Section 5.2.1). 621 o As described in Section 4.2.2, if the SCTP association is not yet 622 established, then the newly created data channels are in the 623 Connecting state, else if the SCTP association is already 624 established, then the newly created data channels are in the Open 625 state. 627 o Generates a new SDP offer. In the case of the browser based 628 applications the browser generates the offer via the createOffer() 629 API call [I-D.ietf-rtcweb-jsep]. 631 o Determines the list of stream identifiers assigned to data 632 channels opened through external negotiation. 634 o Completes the SDP offer with the dcmap and dcsa attributes needed, 635 if any, for each externally-negotiated data channel, as described 636 in Section 5.1. 638 o Sends the SDP offer. 640 The peer receiving such an SDP offer performs the following: 642 o Applies the SDP offer. Note that the browser ignores data channel 643 specific attributes in the SDP. 645 o Analyzes the channel parameters and sub-protocol attributes to 646 determine whether to accept each offered data channel. 648 o For accepted data channels, creates peer instances for the data 649 channels with the browser using the channel parameters described 650 in the SDP offer. Note that the browser is asked to create data 651 channels with stream identifiers not "owned" by the agent. 653 o As described in Section 4.2.2, if the SCTP association is not yet 654 established, then the newly created data channels are in the 655 Connecting state, else if the SCTP association is already 656 established, then the newly created data channels are in the Open 657 state. 659 o Generates an SDP answer. 661 o Completes the SDP answer with the dcmap and optional dcsa 662 attributes needed for each externally-negotiated data channel, as 663 described in Section 5.1. 665 o Sends the SDP answer. 667 The agent receiving such an SDP answer performs the following: 669 o Closes any created data channels (whether in Connecting or Open 670 state) for which the expected dcmap and dcsa attributes are not 671 present in the SDP answer. 673 o Applies the SDP answer. 675 Any data channels in Connecting state are transitioned to the Open 676 state when the SCTP association is established. 678 Each agent application MUST wait to send data until it has 679 confirmation that the data channel at the peer is in the Open state. 680 For webrtc, this is when both data channel stacks have channel 681 parameters instantiated. This occurs: 683 o At both peers when a data channel is created without an 684 established SCTP association, as soon as the data channel stacks 685 report that the data channel transitions to the Open state from 686 the Connecting state. 688 o At the agent receiving an SDP offer for which there is an 689 established SCTP association, as soon as it creates an externally 690 negotiated data channel in the Open state based on information 691 signaled in the SDP offer. 693 o At the agent sending an SDP offer to create a new externally 694 negotiated data channel for which there is an established SCTP 695 association, when it receives the SDP answer confirming acceptance 696 of the data channel or when it begins to receive data on the data 697 channel from the peer, whichever occurs first. 699 5.2.3. Closing a data channel 701 When the application requests the closing of a data channel that was 702 externally negotiated, the data channel stack always performs an in- 703 band SSN reset for this channel. 705 It is specific to the sub-protocol whether this closing must in 706 addition be signaled to the peer via a new SDP offer/answer exchange. 708 A data channel can be closed by sending a new SDP offer which 709 excludes the dcmap and dcsa attributes lines for the data channel. 710 The port value for the m line should not be changed (e.g., to zero) 711 when closing a data channel (unless all data channels are being 712 closed and the SCTP association is no longer needed), since this 713 would close the SCTP association and impact all of the data channels. 714 If answerer accepts the SDP offer then it MUST also exclude the 715 corresponding attribute lines in the answer. In addition to that, 716 SDP answerer may exclude other data channels which were closed but 717 not yet communicated to the peer. So, offerer MUST inspect the 718 answer to see if it has to close other data channels which are now 719 not included in the answer 721 If a new SDP offer/answer is used to close data channels then the 722 data channel(s) should only be closed by the answerer/offerer after 723 successful SDP answer is sent/received. 725 This delayed close is to handle cases where a successful SDP 726 answer is not received, in which case the state of session should 727 be kept per the last successful SDP offer/answer. 729 If a client receives a data channel close indication (due to inband 730 SSN reset or some other reason) without associated SDP offer then an 731 SDP offer which excludes this closed data channel SHOULD be 732 generated. 734 The application must also close any data channel that was externally 735 negotiated, for which the stream identifiers are not listed in an 736 incoming SDP offer. 738 A closed data channel using local close (SCTP reset), without an 739 additional SDP offer/answer to close it, may be reused for a new data 740 channel. This can only be done via new SDP offer/answer, describing 741 the new sub-protocol and its attributes, only after the corresponding 742 data channel close acknowledgement is received from the peer (i.e. 743 SCTP reset of both incoming and outgoing streams is completed). This 744 restriction is to avoid the race conditions between arrival of "SDP 745 offer which reuses stream" with "SCTP reset which closes outgoing 746 stream" at the peer 748 5.2.4. Various SDP offer/answer scenarios and considerations 750 SDP offer has no a=dcmap attributes 752 * Initial SDP offer: No data channel negotiated yet. 754 * Subsequent SDP offer: All the externally negotiated data 755 channels must be closed now. The DTLS/SCTP association remains 756 open for external or internal negotiation of data channels. 758 SDP answer has no a=dcmap attributes 760 * Initial SDP answer: Either the peer does not support dcmap 761 attributes or it rejected all the data channels. In either 762 case offerer closes all the externally negotiated data channels 763 that were open at the time of initial offer. The DTLS/SCTP 764 association will still be setup. 766 * Sub-sequent SDP answer: All the externally negotiated data 767 channels must be closed now. The DTLS/SCTP association remains 768 open for future external or internal negotiation of data 769 channels. 771 SDP offer has no a=dcsa attributes for a data channel. 773 * This is allowed and indicates there are no sub-protocol 774 parameters to convey. 776 SDP answer has no a=dcsa attributes for a data channel. 778 * This is allowed and indicates there are no sub-protocol 779 parameters to convey in the SDP answer. The number of dcsa 780 attributes in the SDP answer does not have to match the number 781 of dcsa attributes in the SDP offer. 783 6. Examples 785 SDP offer: 786 m=application 10001 DTLS/SCTP webrtc-datachannel 787 c=IN IP4 10.10.10.1 788 a=fmtp:webrtc-datachannel max-message-size=100000 789 a=sctp-port 5000 790 a=setup:actpass 791 a=connection:new 792 a=fingerprint:SHA-1 \ 793 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 794 a=dcmap:0 subprotocol="BFCP";label="BGCP" 796 SDP answer: 797 m=application 10002 DTLS/SCTP webrtc-datachannel 798 c=IN IP4 10.10.10.2 799 a=fmtp:webrtc-datachannel max-message-size=100000 800 a=sctp-port 5002 801 a=setup:passive 802 a=connection:new 803 a=fingerprint:SHA-1 \ 804 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 806 Figure 1: Example 1 808 In the above example the SDP answerer rejected the data channel with 809 stream id 0 either for explicit reasons or because it does not 810 understand the a=dcmap attribute. As a result the offerer will close 811 the data channel created with the external negotiation option. The 812 SCTP association will still be setup over DTLS. At this point 813 offerer or answerer may use internal negotiation to open data 814 channels. 816 SDP offer: 817 m=application 10001 DTLS/SCTP webrtc-datachannel 818 c=IN IP4 10.10.10.1 819 a=fmtp:webrtc-datachannel max-message-size=100000 820 a=sctp-port 5000 821 a=setup:actpass 822 a=connection:new 823 a=fingerprint:SHA-1 \ 824 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 825 a=dcmap:0 subprotocol="BFCP";label="BGCP" 826 a=dcmap:2 subprotocol="MSRP";label="MSRP" 827 a=dcsa:2 accept-types:message/cpim text/plain text/ 828 a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc 830 SDP answer: 831 m=application 10002 DTLS/SCTP webrtc-datachannel 832 c=IN IP4 10.10.10.2 833 a=fmtp:webrtc-datachannel max-message-size=100000 834 a=sctp-port 5002 835 a=setup:passive 836 a=connection:new 837 a=fingerprint:SHA-1 \ 838 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 839 a=dcmap:2 subprotocol="MSRP";label="MSRP" 840 a=dcsa:2 accept-types:message/cpim text/plain 841 a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc 843 Figure 2: Example 2 845 In the above example SDP offer contains data channels for BFCP and 846 MSRP sub-protocols. SDP answer rejected BFCP and accepted MSRP. So, 847 the offerer should close the data channel for BFCP and both offerer 848 and answerer may start using MSRP data channel (after SCTP/DTLS 849 association is setup). The data channel with stream id 0 is free and 850 can be used for future internal or external negotiation. 852 Continuing on the earlier example in Figure 1. 854 Subsequent SDP offer: 855 m=application 10001 DTLS/SCTP webrtc-datachannel 856 c=IN IP4 10.10.10.1 857 a=fmtp:webrtc-datachannel max-message-size=100000 858 a=sctp-port 5000 859 a=setup:actpass 860 a=connection:existing 861 a=fingerprint:SHA-1 \ 862 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 863 a=dcmap:4 subprotocol="MSRP";label="MSRP" 864 a=dcsa:4 accept-types:message/cpim text/plain 865 a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc 867 Subsequent SDP answer: 868 m=application 10002 DTLS/SCTP webrtc-datachannel 869 c=IN IP4 10.10.10.2 870 a=fmtp:webrtc-datachannel max-message-size=100000 871 a=sctp-port 5002 872 a=setup:passive 873 a=connection:existing 874 a=fingerprint:SHA-1 \ 875 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 876 a=dcmap:4 subprotocol="MSRP";label="MSRP" 877 a=dcsa:4 accept-types:message/cpim text/plain 878 a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc 880 Figure 3: Example 3 882 The above example is a continuation of the example in Figure 1. The 883 SDP offer now removes the MSRP data channel with stream id 2, but 884 opens a new MSRP data channel with stream id 4. The answerer 885 accepted the entire offer. As a result the offerer closes the 886 earlier negotiated MSRP related data channel and both offerer and 887 answerer may start using new the MSRP related data channel. 889 7. Security Considerations 891 No security considerations are envisaged beyond those already 892 documented in [RFC4566] 894 8. IANA Considerations 896 To be completed. 898 9. Acknowledgments 900 The authors wish to acknowledge the borrowing of ideas from other 901 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 902 and Gavin Llewellyn, and to thank Paul Kyzivat, Jonathan Lennox, and 903 Uwe Rauschenbach for their invaluable comments. 905 10. CHANGE LOG 907 10.1. Changes against '-01' 909 o Formal syntax for dcmap and dcsa attribute lines. 911 o Making subprotocol as an optional parameter in dcmap. 913 o Specifying disallowed parameter combinations for max-time and max- 914 retr. 916 o Clarifications on data channel close procedures. 918 10.2. Changes against '-00' 920 o Revisions to identify difference between internal and external 921 negotiation and their usage. 923 o Introduction of more generic terminology, e.g. "application" 924 instead of "browser". 926 o Clarification of how "max-retr and max-time affect the usage of 927 unreliable and reliable data channels. 929 o Updates of examples to take into account the SDP syntax changes 930 introduced with draft-ietf-mmusic-sctp-sdp-07. 932 o Removal of the SCTP port number from the a=dcmap and a=dcsa 933 attributes as this is now contained in the a=sctp-port attribute, 934 and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP 935 association on top of the DTLS connection. 937 11. References 939 11.1. Normative References 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, March 1997. 944 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 945 Description Protocol", RFC 4566, July 2006. 947 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 948 with Session Description Protocol (SDP)", RFC 3264, June 949 2002. 951 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 952 Specifications: ABNF", STD 68, RFC 5234, January 2008. 954 [I-D.ietf-rtcweb-jsep] 955 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 956 Session Establishment Protocol", draft-ietf-rtcweb-jsep-07 957 (work in progress), July 2014. 959 [I-D.ietf-rtcweb-data-channel] 960 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 961 Channels", draft-ietf-rtcweb-data-channel-12 (work in 962 progress), September 2014. 964 [I-D.ietf-mmusic-sctp-sdp] 965 Loreto, S. and G. Camarillo, "Stream Control Transmission 966 Protocol (SCTP)-Based Media Transport in the Session 967 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07 968 (work in progress), July 2014. 970 [WebRtcAPI] 971 Bergkvist, A., Burnett, D., Jennings, C., and A. 972 Narayanan, "WebRTC 1.0: Real-time Communication Between 973 Browsers", World Wide Web Consortium WD-webrtc-20130910, 974 September 2013, 975 . 977 11.2. Informative References 979 [I-D.ietf-rtcweb-data-protocol] 980 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 981 Establishment Protocol", draft-ietf-rtcweb-data- 982 protocol-08 (work in progress), September 2014. 984 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 985 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 987 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 988 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 989 September 2007. 991 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 992 and P. Kyzivat, "A Session Description Protocol (SDP) 993 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 994 May 2009. 996 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 997 for the Message Session Relay Protocol (MSRP)", RFC 6135, 998 February 2011. 1000 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1001 Establishment for Media Anchoring (CEMA) for the Message 1002 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 1004 Authors' Addresses 1006 Keith Drage (editor) 1007 Alcatel-Lucent 1008 Quadrant, Stonehill Green, Westlea 1009 Swindon 1010 UK 1012 Email: keith.drage@alcatel-lucent.com 1014 Raju Makaraju 1015 Alcatel-Lucent 1016 2000 Lucent Lane 1017 Naperville, Illinois 1018 US 1020 Email: Raju.Makaraju@alcatel-lucent.com 1022 Juergen Stoetzer-Bradler 1023 Alcatel-Lucent 1024 Lorenzstrasse 10 1025 D-70435 Stuttgart 1026 Germany 1028 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 1030 Richard Ejzak 1031 Unaffiliated 1033 Email: richard.ejzak@gmail.com 1035 Jerome Marcon 1036 Unaffiliated