idnits 2.17.1 draft-ejzak-mmusic-msrp-usage-data-channel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (October 27, 2014) is 3468 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 429, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'WebRtcAPI' is defined on line 464, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-07 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-08 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-02) exists of draft-ejzak-mmusic-data-channel-sdpneg-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 9 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: April 30, 2015 Alcatel-Lucent 6 R. Ejzak 7 J. Marcon 8 Unaffiliated 9 October 27, 2014 11 MSRP over SCTP/DTLS data channels 12 draft-ejzak-mmusic-msrp-usage-data-channel-01 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 April 30, 2015. 42 Copyright Notice 44 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 4 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 '-00' . . . . . . . . . . . . . . . . . 9 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 11.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 92 transmitting a series of related instant messages in the context of a 93 session. In addition to instant messaging, MSRP can also be used for 94 image sharing or file transfer. MSRP is currently defined to work 95 over TCP and TLS connections. 97 This document defines the negotiation and transport of this MSRP 98 protocol over WebRTC data channels, where a data channel is a bi- 99 directional communication channel running on top of SCTP/DTLS (as per 100 [I-D.ietf-rtcweb-data-protocol]) and where MSRP is instantiated as a 101 sub-protocol of this data channel. 103 Defining MSRP as a data channel sub-protocol has many benefits: 105 o provides to applications a proven protocol enabling instant 106 messaging, file transfer, image sharing 108 o integrates those features with other RTCWeb voice, video and data 109 features 111 o leverages the SDP-based negotiation already defined for MSRP 113 o allows the interworking with MSRP endpoints running on a TCP or 114 TLS connection 116 Considering an MSRP endpoint being an MSRP application that uses data 117 channel from WebRTC specifications[I-D.ietf-rtcweb-data-protocol], 118 this document describes two configurations where the other endpoint 119 is respectively either another MSRP over data channel endpoint (e.g., 120 a WebRTC application) or an MSRP endpoint using either TCP or TLS 121 transport. 123 2. Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Terminology 131 This document uses the following terms: 133 Data channel: A bidirectional channel consisting of paired SCTP 134 outbound and inbound streams. 136 External negotiation: data channel negotiation based on out-of- 137 band or in-band mechanisms other than the WebRTC data channel 138 control protocol. 140 In-band: transmission through the peer-to-peer SCTP association. 142 Out-of-band: transmission through the call control signaling path, 143 e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer 144 model [RFC3264]. 146 MSRP data channel: A data channel specifically used to transport 147 the messages of one MSRP session. 149 Peer: From the perspective of one of the agents in a session, its 150 peer is the other agent. Specifically, from the perspective of 151 the SDP offerer, the peer is the SDP answerer. From the 152 perspective of the SDP answerer, the peer is the SDP offerer. 154 4. Principles 156 4.1. MSRP data channel 158 In this document, an MSRP data channel is a data channel for which 159 the instantiated sub-protocol is "msrp", and where the MSRP-related 160 negotiation is done as part of the SDP-based external negotiation 161 method defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 163 4.2. Session mapping 165 In this design, the MSRP connection maps to the SCTP association and 166 the "SCTP stream pair" assigned to data channels, and each MSRP 167 session maps to one data channel exactly. 169 4.3. MSRP URI 171 This document extends the MSRP URI syntax [RFC4975] by defining the 172 new transport parameter value "dc": 174 transport /= "dc" / 1*ALPHANUM 175 ; Add "dc" to existing transports per RFC4975 177 4.4. msrp-scheme 179 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 180 channel endpoint (used in the SDP path attribute and in the MSRP 181 message headers) is always "msrps", which indicates that the MSRP 182 data channel is always secured using DTLS. 184 5. End-to-end configuration 186 This section describes the network configuration where each MSRP 187 endpoint is running MSRP over an SCTP/DTLS (data channel) connection. 189 5.1. Basic MSRP support 190 5.1.1. Session negotiation 192 5.1.1.1. Use of dcmap attribute 194 The SDP offer shall include a dcmap attribute line (defined in 195 [I-D.ejzak-mmusic-data-channel-sdpneg]), within the media description 196 for the SCTP association for each MSRP data channel session to be 197 negotiated. 199 The attribute includes the following data channel parameters: 201 o "label=" labelstring 203 o "subprotocol=" "MSRP" 205 The labelstring is set by the MSRP application according to 206 [I-D.ejzak-mmusic-data-channel-sdpneg]. The max-retr, max-time and 207 ordered parameters shall not be used. 209 Rest of the SDP offer/answer procedures are per 210 [I-D.ejzak-mmusic-data-channel-sdpneg] 212 The following is an example of the dcmap attribute for an MSRP 213 session to be negotiated (on default SCTP port 5000) with stream=2 214 and label="chat": 216 a=dcmap:2 label="chat"; subprotocol="MSRP" 218 5.1.1.2. Use of dcsa attribute 220 The SDP offer shall also include a dcsa attribute line (defined in 221 [I-D.ejzak-mmusic-data-channel-sdpneg]) within the media description 222 for the SCTP association for each MSRP-specific SDP attribute to be 223 negotiated for each MSRP data channel being negotiated. 225 The MSRP-specific items that can be negotiated include at least all 226 of the following well-known attributes: 228 o defined in [RFC4975]: "path", "accept-types", "accept-wrapped- 229 types", "max-size" 231 o defined in [RFC4566]: "sendonly", "recvonly", "inactive", and 232 "sendrecv" 234 o defined in [RFC6135]: "setup" 236 o defined in [RFC6714]: "msrp-cema" 237 o defined in [RFC5547]: all the parameters related to MSRP file 238 transfer. See Section 5.2. 240 The msrp-cema attribute shall be assumed to be present for every MSRP 241 session using data channel transport, so the inclusion of the msrp- 242 cema attribute is optional. This ensures that the data channel 243 transport for the MSRP session is established without using the path 244 attribute. 246 The SDP answer shall include zero or more corresponding dcsa 247 attribute lines for each negotiated MSRP session, according to the 248 MSRP-specific attribute negotiation rules in the corresponding 249 specifications. 251 A new SDP offer/answer may update the MSRP subprotocol attributes 252 while keeping the same subprotocol a=dcmap description. The 253 semantics for newly negotiated MSRP subprotocol attributes are per 254 [RFC4975] 256 5.1.1.3. Example SDP negotiation 258 The following is an example of an m line for DataChannels in an SDP 259 offer that includes the attributes needed to establish two MSRP 260 sessions: one for chat and one for file transfer. The example is 261 derived from a combination of examples in [RFC4975] and [RFC5547]. 263 m=application 54111 DTLS/SCTP webrtc-datachannel 264 c=IN IP4 79.97.215.79 265 a=fmtp:webrtc-datachannel max-message-size=100000 266 a=sctp-port 5000 267 a=dcmap:1 label="chat"; subprotocol="MSRP" 268 a=dcsa:1 accept-types:message/cpim text/plain 269 a=dcsa:1 path:msrps://bob.example.com:54111/si438dsaodes;dc 270 a=dcmap:2 label="file transfer"; \ 271 subprotocol="MSRP" 272 a=dcsa::2 sendonly 273 a=dcsa:2 accept-types:message/cpim 274 a=dcsa:2 accept-wrapped-types:* 275 a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc 276 a=dcsa:2 file-selector:name:"My cool picture.jpg" \ 277 type:image/jpeg size:32349 hash:sha-1: \ 278 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 279 a=dcsa:2 file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd 280 a=dcsa:2 file-disposition:attachment 281 a=dcsa:2 file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" 282 a=dcsa:2 file-icon:cid:id2@bob.example.com 283 a=dcsa:2 file-range:1-32349 285 5.1.2. Session opening 287 The active MSRP endpoint does not use the path attribute to open a 288 transport connection to its peer. Instead, it uses the data channel 289 established for this MSRP session by the generic data channel opening 290 procedure defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 292 As soon as this data channel is opened, the MSRP session is actually 293 opened by the active MSRP endpoint which sends an MSRP SEND message 294 (empty or not) to the other MSRP endpoint. The msrp-cema attribute 295 is implicitly associated with every MSRP session using data channel 296 transport. 298 5.1.3. Data framing 300 Each text-based MSRP message is sent on the corresponding SCTP stream 301 using standard MSRP framing and chunking procedures, as defined in 302 [RFC4975], with each MSRP chunk delivered in a single SCTP user 303 message. 305 5.1.4. Data sending and reporting 307 Data sending and reporting procedures shall conform to RFC 4975. 309 5.1.5. Session closing 311 Closing of an MSRP session is done using the generic data channel 312 closing procedure defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 314 The port value for the m line should not be changed (e.g., to zero) 315 when closing an MSRP session (unless all data channels are being 316 closed and the SCTP association is no longer needed), since this 317 would close the SCTP association and impact all of the data channels. 318 In all cases in [RFC4975] where the procedure calls for setting the 319 port to zero for the MSRP m line in an SDP offer for TCP transport, 320 the SDP offerer of an MSRP session with data channel transport shall 321 remove the corresponding dcmap and dcsa attributes. 323 The SDP answerer must ensure that no dcmap or dcsa attributes are 324 present in the SDP answer if no corresponding attributes are present 325 in the received SDP offer. 327 5.2. Support for MSRP File Transfer function 329 [RFC5547] defines an end-to-end file transfer method based on MSRP 330 and the SDP offer/answer mechanism. This file transfer method is 331 also usable by MSRP endpoints using data channel, with the following 332 considerations: 334 o As an MSRP session maps to one data channel, a file transfer 335 session maps also to one data channel. 337 o SDP attributes specified in [RFC5547] for a file transfer m-line 338 are embedded as subprotocol-specific attributes using the syntax 339 defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 341 o Once the file transfer is complete, the same data channel MAY be 342 reused for another file transfer. 344 6. Gateway configuration 346 This section describes the network configuration where one endpoint 347 runs MSRP over a WebRTC SCTP/DTLS connection, the other MSRP endpoint 348 runs MSRP over one or more TLS/TCP connections, and the two endpoints 349 interwork via an MSRP gateway. 351 Specifically, a gateway can be configured to interwork an MSRP 352 session using a data channel with a peer that does not support data 353 channel transport in one of two ways. In one model, the gateway 354 performs as a MSRP B2BUA to interwork all the procedures as necessary 355 between the endpoints. No further specification is needed for this 356 model. 358 Alternately, the gateway can use CEMA procedures to provide transport 359 level interworking between MSRP endpoints using different transport 360 protocols as follows. 362 When the gateway performs transport level interworking between MSRP 363 endpoints, all of the procedures in Section 5 apply to each peer, 364 with the following additions: 366 o The endpoint establishing an MSRP session using data channel 367 transport shall not request inclusion of any relays, although it 368 may interoperate with a peer that signals the use of relays. 370 o The gateway receiving an SDP offer that includes a request to 371 negotiate an MSRP session on a data channel can provide transport 372 level interworking in the same manner as a CEMA SBC by forwarding 373 TCP or TLS transport parameters in a new m line with the 374 appropriate attributes within the forwarded SDP offer. 376 o Similarly, a gateway receiving an SDP offer to negotiate an MSRP 377 session using TCP or TLS transport with an endpoint that only 378 supports data channel transport for MSRP can provide transport 379 level interworking in the same manner as a CEMA SBC by 380 establishing a new data channel for the MSRP session with the 381 target endpoint. 383 7. Security Considerations 385 To be completed. 387 8. IANA Considerations 389 To be completed. 391 9. Acknowledgments 393 The authors wish to acknowledge the borrowing of ideas from another 394 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 395 Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach and Keith Drage for 396 their invaluable comments. 398 10. CHANGE LOG 400 10.1. Changes against '-00' 402 o Transport parameter change for MSRP to allow MSRP RFC transports. 404 o Clarification on SDP offer/answer and removing duplicated 405 procedures and refer them to 406 [I-D.ejzak-mmusic-data-channel-sdpneg]. 408 11. References 410 11.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, March 1997. 415 [I-D.ietf-rtcweb-jsep] 416 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 417 Session Establishment Protocol", draft-ietf-rtcweb-jsep-07 418 (work in progress), July 2014. 420 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 421 with Session Description Protocol (SDP)", RFC 3264, June 422 2002. 424 [I-D.ietf-rtcweb-data-protocol] 425 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 426 Establishment Protocol", draft-ietf-rtcweb-data- 427 protocol-08 (work in progress), September 2014. 429 [I-D.ietf-rtcweb-data-channel] 430 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 431 Channels", draft-ietf-rtcweb-data-channel-12 (work in 432 progress), September 2014. 434 [I-D.ejzak-mmusic-data-channel-sdpneg] 435 Drage, K., Ejzak, R., and J. Marcon, "SDP-based "SCTP over 436 DTLS" data channel negotiation", draft-ejzak-mmusic-data- 437 channel-sdpneg-01 (work in progress), October 2014. 439 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 440 Description Protocol", RFC 4566, July 2006. 442 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 443 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 445 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 446 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 447 September 2007. 449 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 450 and P. Kyzivat, "A Session Description Protocol (SDP) 451 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 452 May 2009. 454 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 455 for the Message Session Relay Protocol (MSRP)", RFC 6135, 456 February 2011. 458 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 459 Establishment for Media Anchoring (CEMA) for the Message 460 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 462 11.2. Informative References 464 [WebRtcAPI] 465 Bergkvist, A., Burnett, D., Narayanan, A., and C. 466 Jennings, "WebRTC 1.0: Real-time Communication Between 467 Browsers", World Wide Web Consortium WD WD-webrtc- 468 20120821, August 2012, 469 . 471 Authors' Addresses 472 Keith Drage (editor) 473 Alcatel-Lucent 474 Quadrant, Stonehill Green, Westlea 475 Swindon 476 UK 478 Email: keith.drage@alcatel-lucent.com 480 Raju Makaraju 481 Alcatel-Lucent 482 2000 Lucent Lane 483 Naperville, Illinois 484 US 486 Email: Raju.Makaraju@alcatel-lucent.com 488 Juergen Stoetzer-Bradler 489 Alcatel-Lucent 490 Lorenzstrasse 10 491 D-70435 Stuttgart 492 Germany 494 Email: Juergen.Stoetzer-Bradler@alcatel-lucent.com 496 Richard Ejzak 497 Unaffiliated 499 Email: richard.ejzak@gmail.com 501 Jerome Marcon 502 Unaffiliated