idnits 2.17.1 draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.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 1 instance 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 -- The document date (October 14, 2013) is 3840 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 237, but not defined == Missing Reference: 'ACTION ITEM' is mentioned on line 433, but not defined == Unused Reference: 'RFC4566' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-jsep' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-data-channel' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'WebRtcAPI' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC4975' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC5547' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC6135' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC6714' is defined on line 622, 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-04 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-05 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'WebRtcAPI' == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-00 Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH R. Ejzak 3 Internet-Draft J. Marcon 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: April 17, 2014 October 14, 2013 7 SDP-based WebRTC data channel negotiation 8 draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 10 Abstract 12 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 13 charged to provide protocols to support direct interactive rich 14 communication using audio, video, and data between two peers' web- 15 browsers. For the support of data communication, the RTCWeb working 16 group has in particular defined the concept of bi-directional data 17 channels over SCTP, where each data channel might be used to 18 transport other protocols, called sub-protocols. Data channel setup 19 can be done using either the in-band WebRTC Data Channel protocol or 20 some external (in-band or out-of-band) negotiation. This document 21 specifies how the SDP offer/answer exchange can be used to achieve 22 such an external negotiation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 17, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. WebRTC Data Channels . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Stream identifier numbering . . . . . . . . . . . . . . . 4 63 4.2. Generic external negotiation . . . . . . . . . . . . . . 5 64 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2.2. Opening a data channel . . . . . . . . . . . . . . . 5 66 4.2.3. Closing a data channel . . . . . . . . . . . . . . . 6 67 5. SDP-based external negotiation . . . . . . . . . . . . . . . 6 68 5.1. SDP syntax . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1.1. SDP attribute for data channel parameter negotiation 7 70 5.1.1.1. stream parameter . . . . . . . . . . . . . . . . 7 71 5.1.1.2. label parameter . . . . . . . . . . . . . . . . . 7 72 5.1.1.3. subprotocol parameter . . . . . . . . . . . . . . 8 73 5.1.1.4. max_retr parameter . . . . . . . . . . . . . . . 8 74 5.1.1.5. max_time parameter . . . . . . . . . . . . . . . 8 75 5.1.1.6. unordered parameter . . . . . . . . . . . . . . . 8 76 5.1.2. Sub-protocol specific attributes . . . . . . . . . . 9 77 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2.1. Managing stream identifiers . . . . . . . . . . . . . 10 79 5.2.2. Opening a data channel . . . . . . . . . . . . . . . 10 80 5.2.3. Closing a data channel . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 9.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 The RTCWeb working group has defined the concept of bi-directional 92 data channels running on top of SCTP/DTLS. Each data channel 93 consists of paired SCTP streams sharing the same SCTP Stream 94 Identifier. Data channels are created by endpoint applications 95 through the WebRTC API, and can be used to transport proprietary or 96 well-defined protocols, which in the latter case can be signaled by 97 the data channel "sub-protocol" parameter, conceptually similar to 98 the WebSocket "sub-protocol". However, apart from the "sub-protocol" 99 value transmitted to the peer, RTCWeb leaves open how endpoint 100 applications can agree on how to instantiate a given sub-protocol on 101 a data channel, and whether it is signaled in-band or out-of-band (or 102 both). In particular, the SDP offer generated by the browser 103 includes no channel-specific information. 105 This document defines SDP-based out-of-band negotiation procedures to 106 establish WebRTC data channels for transport of well-defined sub- 107 protocols. 109 2. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Terminology 117 This document uses the following terms: 119 Data channel: A bidirectional channel consisting of paired SCTP 120 outbound and inbound streams. 122 Data channel properties: fixed properties assigned to a data 123 channel at the time of its creation. Some of these properties 124 determine the way the browser transmits data on this channel 125 (e.g., stream identifier, reliability, order of delivery...) 127 External negotiation: data channel negotiation based on out-of- 128 band or in-band mechanisms other than the WebRTC data channel 129 protocol. 131 In-band: transmission through the peer-to-peer SCTP association. 133 In-band negotiation: data channel negotiation based on the in-band 134 WebRTC data channel protocol defined in 135 [I-D.ietf-rtcweb-data-protocol]. 137 Out-of-band: transmission through the WebRTC signaling path. 139 Peer: From the perspective of one of the agents in a session, its 140 peer is the other agent. Specifically, from the perspective of 141 the SDP offerer, the peer is the SDP answerer. From the 142 perspective of the SDP answerer, the peer is the SDP offerer. 144 Stream identifier: the identifier of the outbound and inbound SCTP 145 streams composing a data channel. 147 4. WebRTC Data Channels 149 This section summarizes how WebRTC data channels work in general. 151 A WebRTC application creates a data channel via the WebRTC Data 152 Channel API, by providing a number of setup parameters (sub-protocol, 153 label, reliability, order of delivery, priority). The application 154 also specifies if the browser takes charge of the in-band negotiation 155 using the WebRTC data protocol, or if the application intends to 156 perform an "external negotiation" using some other in-band or out-of- 157 band mechanism. 159 In any case, the SDP offer generated by the browser is per 160 [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one m-line for the 161 SCTP association on top of which data channels will run, and one 162 attribute per protocol assigned to the SCTP ports: 164 m=application 54111 DTLS/SCTP 5000 5001 5002 165 c=IN IP4 79.97.215.79 166 a=sctpmap:5000 webrtc-datachannel 16 167 a=sctpmap:5001 bfcp 2 168 a=sctpmap:5002 t38 1 170 Note: A WebRTC browser will only create an sctpmap attribute for the 171 webrtc-datachannel protocol, and will not create sctpmap attributes 172 for other protocols such as bfcp or t38. This example shows the 173 hypothetical power of the syntax to support multiplexing of SCTP 174 associations for different protocols on the same DTLS connection. 176 Note: This SDP syntax does not contain any channel-specific 177 information. 179 4.1. Stream identifier numbering 181 Independently from the requested type of negotiation, the application 182 creating a data channel can either pass to the browser the stream 183 identifier to assign to the data channel or else let the browser pick 184 one identifier from the ones unused. 186 To avoid glare situations, each endpoint can moreover own an 187 exclusive set of stream identifiers, in which case an endpoint can 188 only create a data channel with a stream identifier it owns. 190 Which set of stream identifiers is owned by which endpoint is 191 determined by convention or other means. 193 For data channels negotiated in-band, one endpoint owns by 194 convention the even stream identifiers, whereas the other owns the 195 odd stream identifiers, as defined in 196 [I-D.ietf-rtcweb-data-protocol]. 198 For data channels externally negotiated, no convention is defined 199 by default. 201 4.2. Generic external negotiation 203 4.2.1. Overview 205 In-band negotiation only provides for negotiation of data channel 206 transport parameters and does not provide for negotiation of sub- 207 protocol specific parameters. External negotiation can be defined to 208 allow negotiation of parameters beyond those handled by in-band 209 negotiation, e.g., parameters specific to the sub-protocol 210 instantiated on a particular data channel. See Section 5.1.2 for an 211 example of such a parameter. 213 The following procedures are common to all methods of external 214 negotiation, whether in-band (communicated using proprietary means on 215 an already established data channel) or out-of-band (using SDP or 216 some other protocol associated with the signaling channel). 218 4.2.2. Opening a data channel 220 In the case of external negotiation, the endpoint application has the 221 option to fully control the stream identifier assignments. However 222 these assignments have to coexist with the assignments controlled by 223 the browser for the in-band negotiated data channels (if any). It is 224 the responsibility of the application to ensure consistent assignment 225 of stream identifiers. 227 When the application requests the creation of a new data channel to 228 be set up via external negotiation, the browser creates the data 229 channel locally without sending any DATA CHANNEL OPEN message in- 230 band, and sets the data channel state to Connecting if the SCTP 231 association is not yet established, or sets the data channel state to 232 Open if the SCTP association is already established. 234 The application then externally negotiates the data channel 235 properties and sub-protocol properties with the peer's application. 237 [ASSUMPTION] The peer must then symmetrically create a data channel 238 with these negotiated data channel properties. This is the only way 239 for the peer's browser to know which properties to apply when 240 transmitting data on this channel. The browser must allow data 241 channel creation with any non-conflicting stream identifier so that 242 both peers can create the data channel with the same stream 243 identifier. 245 In case the external negotiation is correlated with an SDP offer/ 246 answer exchange that establishes the SCTP association, the SCTP 247 initialization completion triggers each endpoint's browser to change 248 the data channel state from Connecting to Open. 250 Each application must ensure that a data channel is in the Open state 251 both locally and at the peer prior to sending data. This document 252 includes procedures for doing so that are specific to using SDP offer 253 /answer for external negotiation. 255 [ACTION ITEM] Determine if these procedures are fully consistent with 256 the data channel design and whether additional clarification is 257 needed in data channel documents to ensure proper support of external 258 negotiation. 260 4.2.3. Closing a data channel 262 When the application requests the closing of an externally negotiated 263 data channel, the browser always performs an in-band SSN reset for 264 this channel. 266 Depending upon the method used for external negotiation and the sub- 267 protocol associated with the data channel, the closing might in 268 addition be signaled to the peer via external negotiation. 270 5. SDP-based external negotiation 272 This section defines a method of external negotiation by which two 273 WebRTC endpoints can negotiate data channel-specific and sub- 274 protocol-specific parameters, using the out-of-band SDP offer/answer 275 exchange. 277 5.1. SDP syntax 279 Two new SDP attributes are defined to support external negotiation of 280 data channels. The first attribute provides for negotiation of 281 channel-specific parameters. The second attribute provides for 282 negotiation of sub-protocol-specific parameters. 284 5.1.1. SDP attribute for data channel parameter negotiation 286 Associated with the m line that defines the SCTP association for data 287 channels (defined in Section 4), each SDP offer and answer includes 288 an attribute line that defines the data channel parameters for each 289 data channel to be negotiated. Each attribute line specifies the 290 following parameters for a data channel: Stream Identifier, sub- 291 protocol, label, reliability, order of delivery, and priority. The 292 following is an example of the attribute line for sub-protocol "BFCP" 293 and stream id "2" : 295 a=webrtc-DataChannel:5000 stream=2;label="channel 2"; \ 296 subprotocol="BFCP";max_retr=3 298 This line MUST be replicated without changes in the SDP answer, if 299 the answerer accepts the offered data channel. 301 This line MUST be replicated without changes in any subsequent offer 302 or answer, as long as the data channel is still opened at the time of 303 offer or answer generation. 305 Note: This attribute was defined in old version 03 of the 306 following draft but was removed along with any support for SDP 307 external negotiation in subsequent versions: 308 [I-D.ietf-mmusic-sctp-sdp]. 310 Note: This document does not provide a complete specification of 311 how to negotiate the use of a data channel to transport BFCP. 312 Procedures specific to each sub-protocol such as BFCP will be 313 documented elsewhere. The use of BFCP is only an example of how 314 the generic procedures described herein might apply to a specific 315 sub-protocol. 317 5.1.1.1. stream parameter 319 The 'stream' parameter indicates the actual stream identifier within 320 the association used to form the channel. Stream is a mandatory 321 parameter. 323 stream-attr = "a=stream=" streamidentifier 324 streamidentifier = 1*DIGIT 326 5.1.1.2. label parameter 328 The 'label' parameter indicates the name of the channel. It 329 represents a label that can be used to distinguish, in the context of 330 the WebRTC API, an RTCDataChannel object from other RTCDataChannel 331 objects. Label is a mandatory parameter. 333 label-attr = "a=label=" labelstring 334 labelstring = text 335 text = byte-string 337 5.1.1.3. subprotocol parameter 339 The 'subprotocol' parameter indicates which protocol the client 340 expects to exchange via the channel. Subprotocol is a mandatory 341 parameter. 343 subprotocol-attr = "a=subprotocol=" labelstring 344 labelstring = text 345 text = byte-string 347 [ACTION ITEM] The IANA registry to be used for the subprotocol 348 parameter is still to be determined. It also needs to be determined 349 what the relationship is to existing registries and how to reference 350 already-existing protocols. 352 5.1.1.4. max_retr parameter 354 The 'max_retr' parameter indicates the max times a user message will 355 be retransmitted. The max_retr parameter is optional with default 356 value unbounded. 358 maxretr-attr = "a=maxretr=" maxretrvalue 359 maxretrvalue = 1*DIGIT 361 5.1.1.5. max_time parameter 363 A user messages will no longer be transmitted or retransmitted after 364 a specified life-time given in milliseconds in the 'max_time' 365 parameter. The max_time parameter is optional with default value 366 unbounded. 368 maxtime-attr = "a=maxtime=" maxtimevalue 369 maxtimevalue = 1*DIGIT 371 5.1.1.6. unordered parameter 372 The 'unordered' parameter indicates that DATA chunks in the channel 373 MUST be dispatched to the upper layer by the receiver without any 374 attempt to reorder. The unordered parameter is optional. If the 375 unordered parameter is absent, the receiver is required to deliver 376 DATA chunks to the upper layer in proper order. 378 5.1.2. Sub-protocol specific attributes 380 In the SDP, each data channel declaration MAY also be followed by 381 other SDP attributes specific to the sub-protocol in use. Each of 382 these attributes is represented by one new attribute line, and it 383 includes the contents of a media-level SDP attribute already defined 384 for use with this (sub)protocol in another IETF specification. Sub- 385 protocol-specific attributes might also be defined for exclusive use 386 with data channel transport, but should use the same syntax described 387 here for other sub-protocol-specific attributes. 389 Each sub-protocol specific SDP attribute that would normally be used 390 to negotiate the subprotocol using SDP is replaced with an attribute 391 of the form "a=wdcsa:sctp-port:stream-id original-attribute", where 392 wdcsa stands for "webrtc-DataChannel sub-protocol attribute", sctp- 393 port is the sctp port number assigned for webrtc-DataChannel on the 394 media line, stream-id is the sctp stream identifier assigned to this 395 sub-protocol instance, and original-attribute represents the contents 396 of the sub-protocol related attribute to be included. 398 a=webrtc-DataChannel:5000 stream=2;label="channel 2"; \ 399 subprotocol="MSRP";max_retr=3 400 a=wdcsa:5000:2 accept-types:text/plain 402 Thus in the example above, the original attribute line "a=accept- 403 types:text/plain" is represented by the attribute line 404 "a=wdcsa:5000:2 accept-types:text/plain", which specifies that this 405 instance of MSRP being transported on the sctp association using port 406 number 5000 and the data channel with stream id 2 accepts plain text 407 files. 409 As opposed to the data channel setup parameters, these parameters are 410 subject to offer/answer negotiation following the procedures defined 411 in the sub-protocol specific documents. 413 The same syntax applies to any other SDP attribute required for 414 negotiation of this instance of the sub-protocol. 416 Note: This document does not provide a complete specification of how 417 to negotiate the use of a data channel to transport MSRP. Procedures 418 specific to each sub-protocol such as MSRP will be documented 419 elsewhere. The use of MSRP is only an example of how the generic 420 procedures described herein might apply to a specific sub-protocol. 422 5.2. Procedures 424 5.2.1. Managing stream identifiers 426 For the SDP-based external negotiation described in this document, 427 the initial offerer (in the context of a PeerConnection) owns by 428 convention the even stream identifiers whereas the initial answerer 429 owns the odd stream identifiers. This ownership is invariant for the 430 whole lifetime of the PeerConnection, e.g. it does not change if the 431 initial answerer sends a new offer to the initial offerer. 433 [ACTION ITEM] This convention is different from the convention 434 currently defined for in-band negotiation, where even/odd assignment 435 is determined by DTLS role. Since DTLS role cannot be determined 436 until after the initial SDP offer/answer is complete, this convention 437 cannot be used for external negotiation. It might be appropriate to 438 change the convention for stream identifier assignment for in-band 439 negotiation for consistency with external negotiation. Otherwise it 440 might be necessary to prohibit simultaneous use of in-band and 441 external negotiation for data channels. 443 5.2.2. Opening a data channel 445 The procedure for opening a data channel using external negotiation 446 starts with the agent preparing to send an SDP offer. If a peer 447 receives an SDP offer before getting to send a new SDP offer with 448 data channels that are to be externally negotiated, or loses an SDP 449 offer glare resolution procedure in this case, it must wait until the 450 ongoing SDP offer/answer completes before resuming the external 451 negotiation procedure. 453 The agent that intends to send an SDP offer to create data channels 454 through SDP-based external negotiation performs the following: 456 o Creates data channels using stream identifiers from the owned set 457 (see Section 5.2.1). 459 o As described in Section 4.2.2, if the SCTP association is not yet 460 established, then the newly created data channels are in the 461 Connecting state, else if the SCTP association is already 462 established, then the newly created data channels are in the Open 463 state. 465 o Obtains a new SDP offer from the browser. 467 o Determines the list of stream identifiers assigned to data 468 channels opened through external negotiation. 470 o Completes the SDP offer with the webrtc-DataChannel and wdcsa 471 attributes needed for each externally-negotiated data channel, as 472 described in Section 5.1. 474 o Sends the SDP offer. 476 The peer receiving such an SDP offer performs the following: 478 o Applies the SDP offer. Note that the browser ignores data channel 479 specific attributes in the SDP. 481 o Analyzes the channel parameters and sub-protocol attributes to 482 determine whether to accept each offered data channel. 484 o For accepted data channels, creates peer instances for the data 485 channels with the browser using the channel parameters described 486 in the SDP offer. Note that the browser is asked to create data 487 channels with stream identifiers not "owned" by the agent. 489 o As described in Section 4.2.2, if the SCTP association is not yet 490 established, then the newly created data channels are in the 491 Connecting state, else if the SCTP association is already 492 established, then the newly created data channels are in the Open 493 state. 495 o Obtains a new SDP answer from the browser. 497 o Completes the SDP answer with the webrtc-DataChannel and wdcsa 498 attributes needed for each externally-negotiated data channel, as 499 described in Section 5.1. 501 o Sends the SDP answer. 503 The agent receiving such an SDP answer performs the following: 505 o Closes any created data channels (whether in Connecting or Open 506 state) for which the expected webrtc-DataChannel and wdcsa 507 attributes are not present in the SDP answer. 509 o Applies the SDP answer. 511 Any data channels in Connecting state are transitioned to the Open 512 state when the SCTP association is established. 514 Each agent application must wait to send data until it has 515 confirmation that the data channel at the peer is in the Open state. 516 This occurs: 518 o At both peers when a data channel is created without an 519 established SCTP association, as soon as the browsers report that 520 the data channel transitions to the Open state from the Connecting 521 state. 523 o At the agent receiving an SDP offer for which there is an 524 established SCTP association, as soon as it creates an externally 525 negotiated data channel in the Open state based on information 526 signaled in the SDP offer. 528 o At the agent sending an SDP offer to create a new externally 529 negotiated data channel for which there is an established SCTP 530 association, when it receives the SDP answer confirming acceptance 531 of the data channel or when it begins to receive data on the data 532 channel from the peer, whichever occurs first. 534 5.2.3. Closing a data channel 536 When the application requests the closing of a data channel that was 537 externally negotiated, the browser always performs an in-band SSN 538 reset for this channel. 540 It is specific to the sub-protocol whether this closing must in 541 addition be signaled to the peer via a new SDP offer/answer exchange. 543 The application must also close any data channel that was externally 544 negotiated, for which the stream identifiers are not listed in an 545 incoming SDP offer. 547 6. Security Considerations 549 To be completed. 551 7. IANA Considerations 553 To be completed. 555 8. Acknowledgments 557 The authors wish to acknowledge the borrowing of ideas from other 558 internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley 559 and Gavin Llewellyn, and to thank Paul Kyzivat, Jonathan Lennox, Uwe 560 Rauschenbach and Keith Drage for their invaluable comments. 562 9. References 564 9.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, March 1997. 569 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 570 Description Protocol", RFC 4566, July 2006. 572 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 573 with Session Description Protocol (SDP)", RFC 3264, June 574 2002. 576 [I-D.ietf-rtcweb-jsep] 577 Uberti, J. and C. Jennings, "Javascript Session 578 Establishment Protocol", draft-ietf-rtcweb-jsep-04 (work 579 in progress), September 2013. 581 [I-D.ietf-rtcweb-data-channel] 582 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 583 Channels", draft-ietf-rtcweb-data-channel-05 (work in 584 progress), July 2013. 586 [I-D.ietf-mmusic-sctp-sdp] 587 Loreto, S. and G. Camarillo, "Stream Control Transmission 588 Protocol (SCTP)-Based Media Transport in the Session 589 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 590 (work in progress), June 2013. 592 [WebRtcAPI] 593 Bergkvist, A., Burnett, D., Narayanan, A., and C. 594 Jennings, "WebRTC 1.0: Real-time Communication Between 595 Browsers", World Wide Web Consortium WD WD- 596 webrtc-20120821, August 2012, 597 . 599 9.2. Informative References 601 [I-D.ietf-rtcweb-data-protocol] 602 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 603 Protocol", draft-ietf-rtcweb-data-protocol-00 (work in 604 progress), July 2013. 606 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 607 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 609 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 610 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 611 September 2007. 613 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 614 and P. Kyzivat, "A Session Description Protocol (SDP) 615 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 616 May 2009. 618 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 619 for the Message Session Relay Protocol (MSRP)", RFC 6135, 620 February 2011. 622 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 623 Establishment for Media Anchoring (CEMA) for the Message 624 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 626 Authors' Addresses 628 Richard Ejzak 629 Alcatel-Lucent 630 1960 Lucent Lane 631 Naperville, Illinois 60563-1594 632 US 634 Phone: +1 630 979 7036 635 Email: richard.ejzak@alcatel-lucent.com 637 Jerome Marcon 638 Alcatel-Lucent 639 Route de Villejust 640 Nozay 91620 641 France 643 Email: jerome.marcon@alcatel-lucent.com