idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ejzak-mmusic-data-channel-sdpneg]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 (January 27, 2015) is 3371 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) == Unused Reference: 'I-D.ietf-rtcweb-data-channel' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'WebRtcAPI' is defined on line 477, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-08 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: July 31, 2015 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 January 27, 2015 11 MSRP over SCTP/DTLS data channels 12 draft-ietf-mmusic-msrp-usage-data-channel-00 14 Abstract 16 This document specifies how the Message Session Relay Protocol (MSRP) 17 can be instantiated as a data channel sub-protocol, using the the SDP 18 offer/answer exchange-based external negotiation defined in 19 [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations 20 are documented: a WebRTC end-to-end configuration (connecting two 21 MSRP over data channel endpoints), and a gateway configuration 22 (connecting an MSRP over data channel endpoint with an MSRP over TCP 23 endpoint). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 31, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. MSRP data channel . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Session mapping . . . . . . . . . . . . . . . . . . . . . 4 65 4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. End-to-end configuration . . . . . . . . . . . . . . . . . . 4 68 5.1. Basic MSRP support . . . . . . . . . . . . . . . . . . . 5 69 5.1.1. Session negotiation . . . . . . . . . . . . . . . . . 5 70 5.1.1.1. Use of dcmap attribute . . . . . . . . . . . . . 5 71 5.1.1.2. Use of dcsa attribute . . . . . . . . . . . . . . 5 72 5.1.1.3. Example SDP negotiation . . . . . . . . . . . . . 6 73 5.1.2. Session opening . . . . . . . . . . . . . . . . . . . 7 74 5.1.3. Data framing . . . . . . . . . . . . . . . . . . . . 7 75 5.1.4. Data sending and reporting . . . . . . . . . . . . . 7 76 5.1.5. Session closing . . . . . . . . . . . . . . . . . . . 7 77 5.2. Support for MSRP File Transfer function . . . . . . . . . 7 78 6. Gateway configuration . . . . . . . . . . . . . . . . . . . . 8 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10.1. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 84 channel-01' . . . . . . . . . . . . . . . . . . . . . . 9 85 10.2. Changes against '-00' . . . . . . . . . . . . . . . . . 9 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 11.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 94 transmitting a series of related instant messages in the context of a 95 session. In addition to instant messaging, MSRP can also be used for 96 image sharing or file transfer. MSRP is currently defined to work 97 over TCP and TLS connections. 99 This document defines the negotiation and transport of this MSRP 100 protocol over WebRTC data channels, where a data channel is a bi- 101 directional communication channel running on top of SCTP/DTLS (as per 102 [I-D.ietf-rtcweb-data-protocol]) and where MSRP is instantiated as a 103 sub-protocol of this data channel. 105 Defining MSRP as a data channel sub-protocol has many benefits: 107 o provides to applications a proven protocol enabling instant 108 messaging, file transfer, image sharing 110 o integrates those features with other RTCWeb voice, video and data 111 features 113 o leverages the SDP-based negotiation already defined for MSRP 115 o allows the interworking with MSRP endpoints running on a TCP or 116 TLS connection 118 Considering an MSRP endpoint being an MSRP application that uses data 119 channel from WebRTC specifications[I-D.ietf-rtcweb-data-protocol], 120 this document describes two configurations where the other endpoint 121 is respectively either another MSRP over data channel endpoint (e.g., 122 a WebRTC application) or an MSRP endpoint using either TCP or TLS 123 transport. 125 2. Conventions 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Terminology 133 This document uses the following terms: 135 Data channel: A bidirectional channel consisting of paired SCTP 136 outbound and inbound streams. 138 External negotiation: data channel negotiation based on out-of- 139 band or in-band mechanisms other than the WebRTC data channel 140 control protocol. 142 In-band: transmission through the peer-to-peer SCTP association. 144 Out-of-band: transmission through the call control signaling path, 145 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 146 model [RFC3264]. 148 MSRP data channel: A data channel specifically used to transport 149 the messages of one MSRP session. 151 Peer: From the perspective of one of the agents in a session, its 152 peer is the other agent. Specifically, from the perspective of 153 the SDP offerer, the peer is the SDP answerer. From the 154 perspective of the SDP answerer, the peer is the SDP offerer. 156 4. Principles 158 4.1. MSRP data channel 160 In this document, an MSRP data channel is a data channel for which 161 the instantiated sub-protocol is "msrp", and where the MSRP-related 162 negotiation is done as part of the SDP-based external negotiation 163 method defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 165 4.2. Session mapping 167 In this design, the MSRP connection maps to the SCTP association and 168 the "SCTP stream pair" assigned to data channels, and each MSRP 169 session maps to one data channel exactly. 171 4.3. MSRP URI 173 This document extends the MSRP URI syntax [RFC4975] by defining the 174 new transport parameter value "dc": 176 transport /= "dc" / 1*ALPHANUM 177 ; Add "dc" to existing transports per [RFC4975] 179 4.4. msrp-scheme 181 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 182 channel endpoint (used in the SDP path attribute and in the MSRP 183 message headers) is always "msrps", which indicates that the MSRP 184 data channel is always secured using DTLS. 186 5. End-to-end configuration 188 This section describes the network configuration where each MSRP 189 endpoint is running MSRP over an SCTP/DTLS (data channel) connection. 191 5.1. Basic MSRP support 193 5.1.1. Session negotiation 195 5.1.1.1. Use of dcmap attribute 197 The SDP offer shall include a dcmap attribute line (defined in 198 [I-D.ejzak-mmusic-data-channel-sdpneg]), within the media description 199 for the SCTP association for each MSRP data channel session to be 200 negotiated. 202 The attribute includes the following data channel parameters: 204 o "label=" labelstring 206 o "subprotocol=" "MSRP" 208 The labelstring is set by the MSRP application according to 209 [I-D.ejzak-mmusic-data-channel-sdpneg]. The max-retr, max-time and 210 ordered parameters shall not be used. 212 Rest of the SDP offer/answer procedures are per 213 [I-D.ejzak-mmusic-data-channel-sdpneg] 215 The following is an example of the dcmap attribute for an MSRP 216 session to be negotiated (on default SCTP port 5000) with stream=2 217 and label="chat": 219 a=dcmap:2 label="chat";subprotocol="MSRP" 221 5.1.1.2. Use of dcsa attribute 223 The SDP offer shall also include a dcsa attribute line (defined in 224 [I-D.ejzak-mmusic-data-channel-sdpneg]) within the media description 225 for the SCTP association for each MSRP-specific SDP attribute to be 226 negotiated for each MSRP data channel being negotiated. 228 The MSRP-specific items that can be negotiated include at least all 229 of the following well-known attributes: 231 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 232 types", "max-size" 234 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 235 "sendrecv" 237 o defined in [RFC6135]: "setup" 238 o defined in [RFC6714]: "msrp-cema" 240 o defined in [RFC5547]: all the parameters related to MSRP file 241 transfer. See Section 5.2. 243 The msrp-cema attribute shall be assumed to be present for every MSRP 244 session using data channel transport, so the inclusion of the msrp- 245 cema attribute is optional. This ensures that the data channel 246 transport for the MSRP session is established without using the path 247 attribute. 249 The SDP answer shall include zero or more corresponding dcsa 250 attribute lines for each negotiated MSRP session, according to the 251 MSRP-specific attribute negotiation rules in the corresponding 252 specifications. 254 A new SDP offer/answer may update the MSRP subprotocol attributes 255 while keeping the same subprotocol a=dcmap description. The 256 semantics for newly negotiated MSRP subprotocol attributes are per 257 [RFC4975] 259 5.1.1.3. Example SDP negotiation 261 The following is an example of an m line for DataChannels in an SDP 262 offer that includes the attributes needed to establish two MSRP 263 sessions: one for chat and one for file transfer. The example is 264 derived from a combination of examples in [RFC4975] and [RFC5547]. 266 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 267 c=IN IP4 79.97.215.79 268 a=max-message-size:100000 269 a=sctp-port 5000 270 a=dcmap:1 label="chat";subprotocol="MSRP" 271 a=dcsa:1 accept-types:message/cpim text/plain 272 a=dcsa:1 path:msrps://bob.example.com:54111/si438dsaodes;dc 273 a=dcmap:2 label="file transfer";subprotocol="MSRP" 274 a=dcsa::2 sendonly 275 a=dcsa:2 accept-types:message/cpim 276 a=dcsa:2 accept-wrapped-types:* 277 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 278 a=dcsa:2 file-selector:name:"My cool picture.jpg" \ 279 type:image/jpeg size:32349 hash:sha-1: \ 280 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 281 a=dcsa:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd 282 a=dcsa:2 file-disposition:attachment 283 a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" 284 a=dcsa:2 file-icon:cid:id2@bob.example.com 285 a=dcsa:2 file-range:1-32349 287 5.1.2. Session opening 289 The active MSRP endpoint does not use the path attribute to open a 290 transport connection to its peer. Instead, it uses the data channel 291 established for this MSRP session by the generic data channel opening 292 procedure defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 294 As soon as this data channel is opened, the MSRP session is actually 295 opened by the active MSRP endpoint which sends an MSRP SEND message 296 (empty or not) to the other MSRP endpoint. The msrp-cema attribute 297 is implicitly associated with every MSRP session using data channel 298 transport. 300 5.1.3. Data framing 302 Each text-based MSRP message is sent on the corresponding SCTP stream 303 using standard MSRP framing and chunking procedures, as defined in 304 [RFC4975], with each MSRP chunk delivered in a single SCTP user 305 message. 307 5.1.4. Data sending and reporting 309 Data sending and reporting procedures shall conform to RFC 4975. 311 5.1.5. Session closing 313 Closing of an MSRP session is done using the generic data channel 314 closing procedure defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 316 The port value for the m line should not be changed (e.g., to zero) 317 when closing an MSRP session (unless all data channels are being 318 closed and the SCTP association is no longer needed), since this 319 would close the SCTP association and impact all of the data channels. 320 In all cases in [RFC4975] where the procedure calls for setting the 321 port to zero for the MSRP m line in an SDP offer for TCP transport, 322 the SDP offerer of an MSRP session with data channel transport shall 323 remove the corresponding dcmap and dcsa attributes. 325 The SDP answerer must ensure that no dcmap or dcsa attributes are 326 present in the SDP answer if no corresponding attributes are present 327 in the received SDP offer. 329 5.2. Support for MSRP File Transfer function 331 [RFC5547] defines an end-to-end file transfer method based on MSRP 332 and the SDP offer/answer mechanism. This file transfer method is 333 also usable by MSRP endpoints using data channel, with the following 334 considerations: 336 o As an MSRP session maps to one data channel, a file transfer 337 session maps also to one data channel. 339 o SDP attributes specified in [RFC5547] for a file transfer m-line 340 are embedded as subprotocol-specific attributes using the syntax 341 defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 343 o Once the file transfer is complete, the same data channel MAY be 344 reused for another file transfer. 346 6. Gateway configuration 348 This section describes the network configuration where one endpoint 349 runs MSRP over a WebRTC SCTP/DTLS connection, the other MSRP endpoint 350 runs MSRP over one or more TLS/TCP connections, and the two endpoints 351 interwork via an MSRP gateway. 353 Specifically, a gateway can be configured to interwork an MSRP 354 session using a data channel with a peer that does not support data 355 channel transport in one of two ways. In one model, the gateway 356 performs as a MSRP B2BUA to interwork all the procedures as necessary 357 between the endpoints. No further specification is needed for this 358 model. 360 Alternately, the gateway can use CEMA procedures to provide transport 361 level interworking between MSRP endpoints using different transport 362 protocols as follows. 364 When the gateway performs transport level interworking between MSRP 365 endpoints, all of the procedures in Section 5 apply to each peer, 366 with the following additions: 368 o The endpoint establishing an MSRP session using data channel 369 transport shall not request inclusion of any relays, although it 370 may interoperate with a peer that signals the use of relays. 372 o The gateway receiving an SDP offer that includes a request to 373 negotiate an MSRP session on a data channel can provide transport 374 level interworking in the same manner as a CEMA SBC by forwarding 375 TCP or TLS transport parameters in a new m line with the 376 appropriate attributes within the forwarded SDP offer. 378 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 379 session using TCP or TLS transport with an endpoint that only 380 supports data channel transport for MSRP can provide transport 381 level interworking in the same manner as a CEMA SBC by 382 establishing a new data channel for the MSRP session with the 383 target endpoint. 385 7. Security Considerations 387 To be completed. 389 8. IANA Considerations 391 To be completed. 393 9. Acknowledgments 395 The authors wish to acknowledge the borrowing of ideas from another 396 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 397 Paul Kyzivat, Jonathan Lennox, Christian Groves, Uwe Rauschenbach and 398 Keith Drage for their invaluable comments. 400 10. CHANGE LOG 402 10.1. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 404 o Removed empty spaces after ";" in the examples' "a=dcmap" 405 attribute lines. 407 o In all examples, the m-line proto value "DTLS/SCTP" was replaced 408 with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were 409 replaced with "a=max-message-size" attribute lines, as per draft- 410 ietf-mmusic-sctp-sdp-12. 412 10.2. Changes against '-00' 414 o Transport parameter change for MSRP to allow MSRP RFC transports. 416 o Clarification on SDP offer/answer and removing duplicated 417 procedures and refer them to 418 [I-D.ejzak-mmusic-data-channel-sdpneg]. 420 11. References 422 11.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [I-D.ietf-rtcweb-jsep] 428 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 429 Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 430 (work in progress), October 2014. 432 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 433 with Session Description Protocol (SDP)", RFC 3264, June 434 2002. 436 [I-D.ietf-rtcweb-data-protocol] 437 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 438 Establishment Protocol", draft-ietf-rtcweb-data- 439 protocol-09 (work in progress), January 2015. 441 [I-D.ietf-rtcweb-data-channel] 442 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 443 Channels", draft-ietf-rtcweb-data-channel-13 (work in 444 progress), January 2015. 446 [I-D.ejzak-mmusic-data-channel-sdpneg] 447 Drage, K., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon, 448 "SDP-based "SCTP over DTLS" data channel negotiation", 449 draft-ejzak-mmusic-data-channel-sdpneg-02 (work in 450 progress), October 2014. 452 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 453 Description Protocol", RFC 4566, July 2006. 455 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 456 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 458 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 459 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 460 September 2007. 462 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 463 and P. Kyzivat, "A Session Description Protocol (SDP) 464 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 465 May 2009. 467 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 468 for the Message Session Relay Protocol (MSRP)", RFC 6135, 469 February 2011. 471 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 472 Establishment for Media Anchoring (CEMA) for the Message 473 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 475 11.2. Informative References 477 [WebRtcAPI] 478 Bergkvist, A., Burnett, D., Narayanan, A., and C. 479 Jennings, "WebRTC 1.0: Real-time Communication Between 480 Browsers", World Wide Web Consortium WD WD-webrtc- 481 20120821, August 2012, 482 . 484 Authors' Addresses 486 Keith Drage (editor) 487 Alcatel-Lucent 488 Quadrant, Stonehill Green, Westlea 489 Swindon 490 UK 492 Email: keith.drage@alcatel-lucent.com 494 Raju Makaraju 495 Alcatel-Lucent 496 2000 Lucent Lane 497 Naperville, Illinois 498 US 500 Email: Raju.Makaraju@alcatel-lucent.com 502 Juergen Stoetzer-Bradler 503 Alcatel-Lucent 504 Lorenzstrasse 10 505 D-70435 Stuttgart 506 Germany 508 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 510 Richard Ejzak 511 Unaffiliated 513 Email: richard.ejzak@gmail.com 515 Jerome Marcon 516 Unaffiliated