idnits 2.17.1 draft-marcon-msrp-over-webrtc-data-channels-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 (July 09, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3986' is mentioned on line 329, but not defined == Unused Reference: 'RFC4976' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-data-channel' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'I-D.jesup-rtcweb-data-protocol' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'WebRtcAPI' is defined on line 496, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-02 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Marcon 3 Internet-Draft R. Ejzak 4 Intended status: Informational Alcatel-Lucent 5 Expires: January 10, 2014 July 09, 2013 7 MSRP over WebRTC data channels 8 draft-marcon-msrp-over-webrtc-data-channels-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. This document 19 specifies how the Message Session Relay Protocol (MSRP) can be 20 instantiated as a WebRTC data channel sub-protocol, using the SDP 21 offer/exchange to negotiate out-of-band the sub-protocol specific 22 parameters. Two network configurations are documented: a WebRTC end- 23 to-end configuration (connecting two MSRP over data channel 24 endpoints), and a gateway configuration (connecting an MSRP over data 25 channel endpoint with an MSRP over TCP endpoint). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 10, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. WebRTC Data Channels . . . . . . . . . . . . . . . . . . . . 4 65 5. End-to-end configuration . . . . . . . . . . . . . . . . . . 5 66 5.1. Support for SDP-based sub-protocol negotiation . . . . . 5 67 5.1.1. SDP syntax . . . . . . . . . . . . . . . . . . . . . 5 68 5.1.1.1. Channel-specific setup parameters . . . . . . . . 5 69 5.1.1.2. Sub-protocol specific attributes . . . . . . . . 6 70 5.1.2. Procedures . . . . . . . . . . . . . . . . . . . . . 7 71 5.1.2.1. Opening a data channel . . . . . . . . . . . . . 7 72 5.1.2.2. Closing a data channel . . . . . . . . . . . . . 7 73 5.2. Support for MSRP data channels . . . . . . . . . . . . . 7 74 5.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 7 75 5.2.2. MSRP URI . . . . . . . . . . . . . . . . . . . . . . 8 76 5.2.3. Session negotiation . . . . . . . . . . . . . . . . . 8 77 5.2.4. Session opening . . . . . . . . . . . . . . . . . . . 8 78 5.2.5. Data sending and reporting . . . . . . . . . . . . . 8 79 5.2.6. Session closing . . . . . . . . . . . . . . . . . . . 9 80 5.3. Support for MSRP File Transfer function . . . . . . . . . 9 81 6. Gateway configuration . . . . . . . . . . . . . . . . . . . . 9 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 10.2. Informative References . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 91 The Message Session Relay Protocol (MSRP) [RFC4975] is currently 92 defined to work over TCP connections. 94 The RTCWeb working group has defined the concept of bi-directional 95 data channels running on top of SCTP/DTLS. Each data channel 96 consists of paired SCTP streams sharing the same SCTP Stream 97 Identifier. Data channels are created by endpoint applications 98 through the WebRTC API, and can be used to transport proprietary or 99 well-defined protocols, which in the latter case can be signaled by 100 the data channel "sub-protocol" parameter, conceptually similar to 101 the WebSocket "sub-protocol". However, apart from the "sub-protocol" 102 value transmitted to the peer, RTCWeb leaves open how endpoint 103 applications can agree on how to instantiate a given sub-protocol on 104 a data channel, whether it be in-band or out-of-band (or both). As 105 an example, the SDP offer generated by the browser includes no 106 channel-specific information. 108 MSRP is a protocol for transmitting a series of related instant 109 messages in the context of a session. In addition to instant 110 messaging, MSRP can also be used for image sharing or file transfer. 112 Defining the MSRP as a data channel sub-protocol has many benefits: 114 o provide to WebRTC applications a proven protocol enabling instant 115 messaging, file transfer, image sharing 117 o integrate those features with other RTCWeb voice and video 118 features 120 o leverage the SDP-based negotiation already defined for MSRP 122 o allows the interworking with MSRP endpoints running on a TCP 123 connection 125 This document defines the use MSRP of over WebRTC data channels, 126 where one MSRP endpoint is an MSRP WebRTC application and the other 127 endpoint is either an MSRP WebRTC application or an MSRP TCP 128 application. 130 2. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Terminology 138 This document uses the following terms: 140 Data channel: A bidirectional channel consisting of paired SCTP 141 outbound and inbound streams. 143 In-band: transmission through the peer-to-peer SCTP association. 145 Out-of-band: transmission through the WebRTC signaling path, using 146 JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer model 147 [RFC3264]. 149 MSRP data channel: A data channel specifically used to transport 150 the messages of one MSRP session. 152 Peer: From the perspective of one of the agents in a session, its 153 peer is the other agent. Specifically, from the perspective of 154 the SDP offerer, the peer is the SDP answerer. From the 155 perspective of the SDP answerer, the peer is the SDP offerer. 157 4. WebRTC Data Channels 159 This section summarizes how WebRTC data channels work in general. 161 A WebRTC application creates a data channel via the WebRTC Data 162 Channel API, by providing a number of setup parameters (sub-protocol, 163 label, reliability, order of delivery, priority). 165 The browser then opens in-band the data channel using the DATA 166 CHANNEL OPEN message defined in [draft-jesup-rtcweb-data-protocol]. 167 This message carries some of the channel-specific parameters passed 168 by the application (sub-protocol, label, reliability, order of 169 delivery). 171 In case an SCTP association is already established, the browser 172 transmits immediately the DATA CHANNEL OPEN message to the peer, on 173 an unused SCTP stream. 175 In case no SCTP association is established, the browser triggers for 176 an SDP offer/answer exchange, and sends the DATA CHANNEL OPEN 177 message(s) once the SCTP association is established (i.e. 178 subsequently to the reception of the answer). 180 The SDP offer generated by the browser is as per [draft-ietf-mmusic- 181 sctp-sdp]. In brief, it contains one m-line for the SCTP association 182 on top of which data channels will run, and one attribute per 183 protocol assigned to the SCTP ports: 185 m=application 54111 DTLS/SCTP 5000 5001 5002 186 c=IN IP4 79.97.215.79 187 a=sctpmap:5000 webrtc-datachannel 16 188 a=sctpmap:5001 bfcp 2 189 a=sctpmap:5002 t38 1 191 Note: A WebRTC browser will only create an sctpmap attribute for the 192 webrtc-datachannel protocol, and will not create sctpmap attributes 193 for other protocols such as bfcp or t38. This example shows the 194 hypothetical power of the syntax to support multiplexing of SCTP 195 associations for different protocols on the same DTLS connection. 197 Note: this SDP syntax does not contain any channel-specific 198 information. 200 5. End-to-end configuration 202 This section describes the network configuration where each MSRP 203 endpoint is a WebRTC endpoint, running MSRP over an SCTP/DTLS 204 connection. 206 5.1. Support for SDP-based sub-protocol negotiation 208 In the default procedures described in Section 4, the channel- 209 specific parameters are notified in-band to the peer, rather than 210 negotiated with the peer. Also, no mechanism is defined to transmit 211 subprotocol-specific parameters to the peer. 213 This section defines a means to negotiate channel-specific and 214 subprotocol-specific parameters, using the out-of-band SDP offer/ 215 exchange. 217 5.1.1. SDP syntax 219 The SDP only contains the declaration of data channels for which an 220 SDP-based negotiation is required, and that are either being created 221 or already opened. 223 5.1.1.1. Channel-specific setup parameters 225 For each of these data channels, the SDP lists one attribute line 226 providing the Stream Identifier, sub-protocol, label, reliability, 227 order of delivery, priority. 229 a=webrtc-DataChannel:5000 stream=2;label="channel 2"; \ 230 subprotocol="file transfer";max_retr=3 232 NOTE: the related SDP syntax has to be imported from version 3 of 233 [draft-ietf-mmusic-sctp-sdp]. 235 This line MUST be replicated without changes in the SDP answer, if 236 the answerer accepts the offered data channel. 238 This line MUST be replicated without changes in any subsequent offer 239 or answer, as long as the data channel is still opened at the time of 240 offer or answer generation. 242 The Sub-protocol, label, reliability and order of delivery parameters 243 MUST be equal to those transmitted in-band in the DATA CHANNEL OPEN 244 message. The Stream Identifier MUST be equal to the SCTP Stream 245 Identifier on which the DATA CHANNEL OPEN message is sent. 247 5.1.1.2. Sub-protocol specific attributes 249 In the SDP, each data channel declaration MAY also be followed by 250 other SDP attributes specific to the sub-protocol in use. Each of 251 these attributes is represented by one new attribute line, and it 252 includes the contents of a media-level SDP attribute already defined 253 for use with this (sub)protocol in another IETF specification. 255 Each sub-protocol specific attribute such as "a=accept-types:text/ 256 plain" that would normally be used to negotiate an instance of MSRP 257 is replaced with an attribute of the form "a=wdcsa:sctp-port:stream- 258 id original-attribute", where wdcsa stands for "webrtc-DataChannel 259 sub-protocol attribute", sctp-port is the sctp port number assigned 260 for webrtc-DataChannel on the media line, stream-id is the sctp 261 stream id assigned to this instance of MSRP, and original-attribute 262 represents the contents of the MSRP related attribute to be included. 264 a=webrtc-DataChannel:5000 stream=2;label="channel 2"; \ 265 subprotocol="MSRP";max_retr=3 266 a=wdcsa:5000:2 accept-types:text/plain 268 Thus the attribute "a=wdcsa:5000:2 accept-types:text/plain" specifies 269 that this instance of MSRP on stream id 2 accepts plain text files. 271 As opposed to the data channel setup parameters, these parameters are 272 subject to offer/answer negotiation. 274 The same syntax applies to any other SDP attribute required for 275 negotiation of this instance of the sub-protocol. 277 5.1.2. Procedures 279 5.1.2.1. Opening a data channel 281 Opening a data channel is done in-band by the DATA CHANNEL OPEN 282 message. However when the sub-protocol requires an SDP-based 283 negotiation, applications MUST NOT send data on this channel till 284 both SDP negotiation and DATA CHANNEL OPEN message sending are done, 285 which may happen in any order. 287 When the application creates a new data channel (requiring some sub- 288 protocol specific negotiation), the browser follows in any case a 289 generic behavior: 291 o if no SCTP association is established, the browser triggers the 292 SDP negotiation, and sends the DATA CHANNEL OPEN message once the 293 answer is received and the SCTP association initialized. 295 o if an SCTP association is established, the browser does not 296 trigger any SDP negotiation but instead immediately sends a DATA 297 CHANNEL OPEN message. The application then initiates a new offer/ 298 answer exchange 300 Note: in this case, as the DATA CHANNEL OPEN message is sent before 301 the offer is created, Stream ID conflicts between offers sent to the 302 peer, and DATA CHANNEL OPEN messages received from the peer should 303 not occur. 305 The application has the task to complete the browser-generated offer 306 (or answer) with the data channel and subprotocol specific parameters 307 in scope of the SCTP m-line. The browser is expected to ignore those 308 parameters when the completed offer (or answer) is applied locally. 310 5.1.2.2. Closing a data channel 312 Closing a data channel is done in-band by the SSN reset mechanism, 313 and does not trigger a new offer/answer exchange. 315 5.2. Support for MSRP data channels 317 5.2.1. Overview 319 This document defines how MSRP can be used as a WebRTC sub-protocol, 320 where the MSRP-related negotiation is done as part of the SDP-based 321 data channel negotiation defined in Section 5.1.1.2. 323 In this design, the MSRP connection maps to the SCTP association and 324 the port assigned to data channels, and each MSRP session maps to one 325 data channel exactly. 327 5.2.2. MSRP URI 329 This document extends the MSRP URI syntax [RFC3986] by defining the 330 new transport parameter value "dc": 332 transport = "tcp" / "dc" / 1*ALPHANUM 334 5.2.3. Session negotiation 336 Using the syntax a=webrtc-DataChannel: , the SDP 337 declaration of a given MSRP data channel can include at least all the 338 following well-known parameters: 340 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 341 types", "max-size" 343 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 344 "sendrecv" 346 o defined in [RFC6135]: "setup" 348 o defined in [RFC6714]: "msrp-cema" 350 o defined in [RFC5547]: all the parameters related to MSRP file 351 transfer 353 5.2.4. Session opening 355 The MSRP session is normally opened by the active MSRP endpoint, 356 which sends an MSRP SEND message (empty or not) to the other MSRP 357 endpoint. The active MSRP endpoint does not use the path attribute 358 to open a transport connection to its peer. Instead, the active MSRP 359 endpoint uses the DataChannel established for this MSRP session by 360 the procedures in Section 5.1. The cema attribute is implicitly 361 associated with every MSRP session using data channel transport. 363 5.2.5. Data sending and reporting 364 5.2.6. Session closing 366 Either endpoint can close the MSRP session by closing the underlying 367 data channel. Closing an MSRP session should not trigger an SDP 368 negotiation. 370 5.3. Support for MSRP File Transfer function 372 [RFC5547] defines an end-to-end file transfer method based on MSRP 373 and the SDP offer/answer mechanism. This file transfer method is 374 also usable by MSRP WebRTC endpoints, with the following 375 considerations: 377 o As an MSRP session maps to one data channel, a file transfer 378 session maps also to one data channel. 380 o SDP attributes specified in [RFC5547] for a file transfer m-line 381 are embedded as subprotocol-specific attributes as defined in 382 Section 5.1.1.2. 384 o Each file chunk is transmitted over one SCTP user message. 386 o Once the file transfer is complete, the same data channel MAY be 387 reused for another file transfer. 389 o Following the aborting of a file transfer, the SDP can be updated 390 by adding the "inactive" attribute to the list of subprotocol- 391 specific attributes associated with the corresponding data 392 channel. 394 6. Gateway configuration 396 This section describes the network configuration where one endpoint 397 runs MSRP over a WebRTC SCTP/DTLS connection, the other MSRP endpoint 398 runs MSRP over one or more TLS/TCP connections, and the two endpoints 399 interwork via an MSRP gateway. 401 Specifically, a gateway can be configured to interwork an MSRP 402 session using a data channel with a peer that does not support data 403 channel transport in one of two ways. In one model, the gateway 404 performs as a MSRP B2BUA to interwork all the procedures as necessary 405 between the endpoints. No further specification is needed for this 406 model. 408 Alternately, the gateway can use CEMA procedures to provide transport 409 level interworking between MSRP endpoints using different transport 410 protocols as follows. 412 When the gateway performs transport level interworking between MSRP 413 endpoints, all of the procedures in section Section 5.1 apply to each 414 peer, with the following additions: 416 o The endpoint establishing an MSRP session using data channel 417 transport shall not request inclusion of any relays, although it 418 may interoperate with a peer that signals the use of relays. 420 o The gateway receiving an SDP offer that includes a request to 421 negotiate an MSRP session on a data channel can provide transport 422 level interworking in the same manner as a CEMA SBC by forwarding 423 TCP or TLS transport parameters in a new m line with the 424 appropriate attributes within the forwarded SDP offer. 426 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 427 session using TCP or TLS transport with an endpoint that only 428 supports data channel transport for MSRP can provide transport 429 level interworking in the same manner as a CEMA SBC by 430 establishing a new data channel for the MSRP session with the 431 target endpoint. 433 7. Security Considerations 435 To be completed. 437 8. IANA Considerations 439 To be completed. 441 9. Acknowledgments 443 The authors wish to thank... for their invaluable comments. 445 10. References 447 10.1. Normative References 449 [I-D.ietf-rtcweb-jsep] 450 Uberti, J. and C. Jennings, "Javascript Session 451 Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work 452 in progress), October 2012. 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 458 Description Protocol", RFC 4566, July 2006. 460 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 461 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 463 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 464 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 465 September 2007. 467 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 468 and P. Kyzivat, "A Session Description Protocol (SDP) 469 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 470 May 2009. 472 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 473 for the Message Session Relay Protocol (MSRP)", RFC 6135, 474 February 2011. 476 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 477 Establishment for Media Anchoring (CEMA) for the Message 478 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 480 10.2. Informative References 482 [I-D.ietf-rtcweb-data-channel] 483 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 484 Channels", draft-ietf-rtcweb-data-channel-04 (work in 485 progress), February 2013. 487 [I-D.jesup-rtcweb-data-protocol] 488 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 489 Protocol", draft-jesup-rtcweb-data-protocol-04 (work in 490 progress), February 2013. 492 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 493 with Session Description Protocol (SDP)", RFC 3264, June 494 2002. 496 [WebRtcAPI] 497 Bergkvist, A., Burnett, D., Narayanan, A., and C. 498 Jennings, "WebRTC 1.0: Real-time Communication Between 499 Browsers", World Wide Web Consortium WD WD- 500 webrtc-20120821, August 2012, 501 . 503 Authors' Addresses 505 Jerome Marcon 506 Alcatel-Lucent 507 Route de Villejust 508 Nozay 91620 509 France 511 Email: jerome.marcon@alcatel-lucent.com 513 Richard Ejzak 514 Alcatel-Lucent 515 1960 Lucent Lane 516 Naperville, Illinois 60563-1594 517 US 519 Phone: +1 630 979 7036 520 Email: richard.ejzak@alcatel-lucent.com