idnits 2.17.1 draft-ietf-mmusic-msrp-usage-data-channel-23.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-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4975, updated by this document, for RFC5378 checks: 2003-05-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 22, 2020) is 1375 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Recio, Ed. 3 Internet-Draft Unaffiliated 4 Updates: 4975 (if approved) C. Holmberg 5 Intended status: Standards Track Ericsson 6 Expires: January 23, 2021 July 22, 2020 8 MSRP over Data Channels 9 draft-ietf-mmusic-msrp-usage-data-channel-23 11 Abstract 13 This document specifies how the Message Session Relay Protocol (MSRP) 14 can be transported as a WebRTC data channel sub-protocol, using the 15 SDP offer/answer generic data channel negotiation framework to 16 establish such a channel. Two network configurations are supported: 17 connecting two MSRP over data channel endpoints; and a gateway 18 configuration, connecting an MSRP over data channel endpoint with an 19 MSRP over TCP or TLS endpoint. This document updates RFC4975. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 23, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 5 58 3.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 5 59 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Use of the dcmap Attribute . . . . . . . . . . . . . . . 6 63 4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 6 64 4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 7 65 4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7 66 4.7. Support for MSRP File Transfer Function . . . . . . . . . 8 67 4.8. Example SDP Negotiation . . . . . . . . . . . . . . . . . 8 68 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9 71 5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9 72 5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9 73 5.5. Data Sending, Receiving and Reporting . . . . . . . . . . 9 74 5.6. Support for MSRP File Transfer Function . . . . . . . . . 10 75 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. Updates to RFC4975 . . . . . . . . . . . . . . . . . . . . . 11 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 9.1. msrps URI scheme . . . . . . . . . . . . . . . . . . . . 11 80 9.2. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11 81 9.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 12 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 83 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 85 channel-22' . . . . . . . . . . . . . . . . . . . . . . 18 86 11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 87 channel-21' . . . . . . . . . . . . . . . . . . . . . . 18 88 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 89 channel-20' . . . . . . . . . . . . . . . . . . . . . . 18 90 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 91 channel-19' . . . . . . . . . . . . . . . . . . . . . . 18 92 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 93 channel-18' . . . . . . . . . . . . . . . . . . . . . . 19 94 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 95 channel-17' . . . . . . . . . . . . . . . . . . . . . . 19 96 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 97 channel-16' . . . . . . . . . . . . . . . . . . . . . . 19 98 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 99 channel-15' . . . . . . . . . . . . . . . . . . . . . . 19 100 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 101 channel-14' . . . . . . . . . . . . . . . . . . . . . . 19 102 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 103 channel-13' . . . . . . . . . . . . . . . . . . . . . . 19 104 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 105 channel-12' . . . . . . . . . . . . . . . . . . . . . . 19 106 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 107 channel-11' . . . . . . . . . . . . . . . . . . . . . . 19 108 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data- 109 channel-10' . . . . . . . . . . . . . . . . . . . . . . 20 110 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data- 111 channel-09' . . . . . . . . . . . . . . . . . . . . . . 20 112 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data- 113 channel-08' . . . . . . . . . . . . . . . . . . . . . . 20 114 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data- 115 channel-07' . . . . . . . . . . . . . . . . . . . . . . 20 116 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data- 117 channel-06' . . . . . . . . . . . . . . . . . . . . . . 20 118 11.18. Changes against 'draft-ietf-mmusic-msrp-usage-data- 119 channel-05' . . . . . . . . . . . . . . . . . . . . . . 20 120 11.19. Changes against 'draft-ietf-mmusic-msrp-usage-data- 121 channel-04' . . . . . . . . . . . . . . . . . . . . . . 20 122 11.20. Changes against 'draft-ietf-mmusic-msrp-usage-data- 123 channel-03' . . . . . . . . . . . . . . . . . . . . . . 21 124 11.21. Changes against 'draft-ietf-mmusic-msrp-usage-data- 125 channel-02' . . . . . . . . . . . . . . . . . . . . . . 21 126 11.22. Changes against 'draft-ietf-mmusic-msrp-usage-data- 127 channel-01' . . . . . . . . . . . . . . . . . . . . . . 21 128 11.23. Changes against 'draft-ietf-mmusic-msrp-usage-data- 129 channel-00' . . . . . . . . . . . . . . . . . . . . . . 23 130 11.24. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 131 channel-01' . . . . . . . . . . . . . . . . . . . . . . 23 132 11.25. Changes against '-00' . . . . . . . . . . . . . . . . . 24 133 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 134 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 135 12.2. Informative References . . . . . . . . . . . . . . . . . 25 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 138 1. Introduction 140 The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for 141 transmitting a series of related instant messages in the context of a 142 session. In addition to instant messaging, MSRP can also be used for 143 image sharing or file transfer. MSRP was initially defined in 145 [RFC4975] to work over TCP and TLS connections, and over a WebSocket 146 subprotocol specified by [RFC7977]. 148 This document specifies the negotiation and transport of MSRP over a 149 WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is 150 carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and 151 MSRP is transported as a sub-protocol of a WebRTC data channel, 152 without the TCP and TLS layers. 154 Defining MSRP as a data channel sub-protocol has many benefits: 156 o provides to applications a proven protocol enabling instant 157 messaging, file transfer, image sharing 159 o integrates those features with other WebRTC voice, video and data 160 features 162 o leverages the SDP-based negotiation already defined for MSRP 164 o allows the interworking with MSRP endpoints running on a TCP or 165 TLS connection 167 Compared to WebSockets, which provide a message passing protocol to 168 applications with no direct access to TCP or TLS sockets, data 169 channels provide a low latency transport, leverage NAT-aware 170 connectivity and security features of WebRTC, and are increasingly 171 available not only in modern browsers but in other applications that 172 use WebRTC for media or other purposes, such as IoT or telemetry in 173 general, non-media data exchange, and so on. 175 Considering an MSRP endpoint as an MSRP application that uses a 176 WebRTC data channel, this document describes two configurations where 177 the other endpoint is respectively either another MSRP over data 178 channel endpoint (e.g., a WebRTC application) or an MSRP endpoint 179 using either TCP or TLS transport. 181 This document updates [RFC4975] as described in Section 7. 183 2. Conventions 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119][RFC8174] when, and only when, they appear in all 189 capitals, as shown here. 191 3. WebRTC Data Channel Considerations 193 3.1. MSRP Data Channel 195 In this document, an MSRP data channel is a data channel for which 196 the instantiated sub-protocol is "msrp", and where the channel is 197 negotiated using the SDP-based external negotiation method defined in 198 [I-D.ietf-mmusic-data-channel-sdpneg]. 200 The following WebRTC data channel property values 201 [I-D.ietf-rtcweb-data-channel] apply to an MSRP data channel: 203 +--------------------------+------------------+ 204 | Property | Value | 205 +--------------------------+------------------+ 206 | Subprotocol Identifier | msrp | 207 | Transmission reliability | reliable | 208 | Transmission order | in-order | 209 | Label | See Section 4.3 | 210 +--------------------------+------------------+ 212 4. SDP Considerations 214 This section describes the SDP considerations which are specific to 215 an MSRP data channel 217 4.1. MSRP URI 219 This document extends the MSRP URI syntax [RFC4975] by defining the 220 new transport parameter value "dc": 222 transport /= "dc" 223 ; Add "dc" to existing transports per Section 9 of [RFC4975] 225 MSRP design provides for new transport bindings (see Section 6 of 226 [RFC4975]). MSRP implementations are expected to allow unrecognized 227 transports for which there is no need to establish a connection to 228 the resource described by the URI, as it's the case of data channels 229 (Section 4.4). 231 4.2. msrp-scheme 233 The msrp-scheme portion of the MSRP-URI that represents an MSRP data 234 channel endpoint (used in the SDP path attribute and in the MSRP 235 message headers) is always "msrps", which indicates that the MSRP 236 data channel is always secured using DTLS as described in 237 [I-D.ietf-rtcweb-data-channel]. 239 4.3. Use of the dcmap Attribute 241 An offerer and answerer SHALL, in each offer and answer, include a 242 dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 243 the media description of the SCTP association for each MSRP data 244 channel session to be negotiated. 246 The attribute includes the following data channel parameters: 248 o "label=" labelstring 250 o "subprotocol=" "msrp" 252 The labelstring is set by the MSRP application according to 253 [I-D.ietf-mmusic-data-channel-sdpneg]. 255 The offerer and answerer SHALL NOT include the max-retr and the max- 256 time attribute parameters in the dcmap attribute. 258 The offerer and answerer MAY include the ordered attribute parameter 259 in the dcmap attribute. If included, the attribute parameter value 260 SHALL be set to "true". 262 Below is an example of the dcmap attribute for an MSRP session to be 263 negotiated with stream-id=2 and label="chat": 265 a=dcmap:2 label="chat";subprotocol="msrp" 267 4.4. Use of the dcsa Attribute 269 An offerer and answerer SHALL, in each offer and answer, include a 270 dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within 271 the media description for the SCTP association for each MSRP-specific 272 SDP attribute to be negotiated for each MSRP data channel being 273 negotiated. 275 An offerer and answerer SHALL include a dcsa attribute for each of 276 the following MSRP-specific SDP attributes: 278 o defined in [RFC4975]: "path". 280 o defined in [RFC6714]: "msrp-cema". 282 o defined in [RFC6135]: "setup". See Section 4.5 284 It is considered a protocol error if one or more of the dcsa embedded 285 attributes listed above are not included in an offer or answer. 287 An offerer and answerer MAY include a dcsa attribute for any of the 288 following MSRP-specific SDP attributes, following the procedures 289 defined for each attributes: 291 o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and 292 "max-size" 294 o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and 295 "sendrecv" 297 o defined in [RFC5547]: all the parameters related to MSRP file 298 transfer. See Section 4.7. 300 A subsequent offer or answer MAY update the previously negotiated 301 MSRP subprotocol attributes while keeping the same subprotocol 302 a=dcmap description. The semantics for newly negotiated MSRP 303 subprotocol attributes are per [RFC4975]. 305 When MSRP messages are transported on a data channel, the "path" 306 attribute is not used for routing of the messages. The MSRP data 307 channel is established using the SDP offer/answer procedures defined 308 in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are 309 then transported on that data channel. This is different from legacy 310 MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. However, when an 311 endpoint receives an MSRP message over a data channel, it MUST still 312 perform the MSRP-URI comparison procedures defined in [RFC4975]. 314 4.5. Use of the dcsa embedded setup Attribute 316 As described in Section 4.4, the usage of a dsca embedded setup 317 attribute is mandated for MSRP sessions over data channels. It is 318 used to negotiate which MSRP session endpoint assumes the active role 319 as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It 320 has no relationship with the DTLS connection establishment roles 321 [I-D.ietf-mmusic-sctp-sdp]. 323 The dcsa embedded setup attribute is of the form "a=dcsa:x 324 setup:", with x being the data channel's SCTP stream 325 identifier, so that such attribute is explicitly associated with an 326 MSRP session over a specific data channel. 328 4.6. Session Closing 330 An MSRP session is closed by closing the associated data channel, 331 following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg]. 333 The port value for the "m=" line SHOULD NOT be changed (e.g. to zero) 334 when closing an MSRP session (unless all data channels are being 335 closed and the SCTP association is no longer needed), since this 336 would close the SCTP association and impact all of the data channels. 337 In all cases in [RFC4975] where the procedure calls for setting the 338 port to zero for the MSRP "m=" line in an SDP offer for TCP 339 transport, the SDP offerer of an MSRP session with data channel 340 transport SHALL remove the corresponding dcmap and dcsa attributes. 342 4.7. Support for MSRP File Transfer Function 344 SDP attributes specified in [RFC5547] for a file transfer "m=" line 345 are embedded as subprotocol-specific attributes using the syntax 346 defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 348 4.8. Example SDP Negotiation 350 The following is an example of an "m=" line for data channels in an 351 SDP offer that includes the attributes needed to establish two MSRP 352 sessions: one for chat and one for file transfer. The example is 353 derived from a combination of examples in [RFC4975] and [RFC5547]. 355 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 356 c=IN IP4 198.51.100.79 357 a=max-message-size:100000 358 a=sctp-port:5000 359 a=setup:actpass 360 a=fingerprint:SHA-1 \ 361 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 362 a=tls-id:4a756565cddef001be82 363 a=dcmap:0 label="chat";subprotocol="msrp" 364 a=dcsa:0 msrp-cema 365 a=dcsa:0 setup:active 366 a=dcsa:0 accept-types:message/cpim text/plain 367 a=dcsa:0 path:msrps://198.51.100.79:54111/si438dsaodes;dc 368 a=dcmap:2 label="file transfer";subprotocol="msrp" 369 a=dcsa:2 sendonly 370 a=dcsa:2 msrp-cema 371 a=dcsa:2 setup:active 372 a=dcsa:2 accept-types:message/cpim 373 a=dcsa:2 accept-wrapped-types:* 374 a=dcsa:2 path:msrps://198.51.100.79:54111/jshA7we;dc 375 a=dcsa:2 file-selector:name:"picture1.jpg" \ 376 type:image/jpeg size:1463440 hash:sha-1:\ 377 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 378 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep 379 a=dcsa:2 file-disposition:attachment 380 a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" 381 a=dcsa:2 file-icon:cid:id2@bob.example.com 382 a=dcsa:2 file-range:1-1463440 384 5. MSRP Considerations 386 The procedures specified in [RFC4975] apply except when this document 387 specifies otherwise. This section describes the MSRP considerations 388 specific to an MSRP data channel. 390 5.1. Session Mapping 392 In this document, each MSRP session maps to one data channel exactly. 394 5.2. Session Opening 396 Section 4.5 describes how the active MSRP session endpoint role is 397 negotiated. The active MSRP session endpoint uses the data channel 398 established for this MSRP session by the generic data channel opening 399 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 401 As soon as the WebRTC data channel is opened, the MSRP session is 402 actually opened by the active MSRP session endpoint. In order to do 403 this the active MSRP endpoint sends an MSRP SEND message (empty or 404 not) to the other MSRP endpoint. 406 5.3. Session Closing 408 The closure of an MSRP session SHALL be signaled via SDP following 409 the requirements in Section 4.6 411 If the data channel used to transport the MSRP session fails and gets 412 torn down, the endpoints SHALL consider the MSRP session failed. An 413 MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP 414 data channel. 416 5.4. Data Framing 418 Each text-based MSRP message is sent on the corresponding SCTP stream 419 using standard MSRP framing and chunking procedures, as defined in 420 [RFC4975], with each MSRP chunk delivered in a single SCTP user 421 message. Therefore all sent MSRP chunks including the MSRP chunk 422 header SHALL have lengths of less than or equal to the value of the 423 peer's "a=max-message-size" attribute, which is associated with the 424 data channel's SCTP association. 426 5.5. Data Sending, Receiving and Reporting 428 Data sending, receiving and reporting procedures SHALL conform to 429 [RFC4975]. 431 5.6. Support for MSRP File Transfer Function 433 [RFC5547] defines an end-to-end file transfer method based on MSRP 434 and the SDP offer/answer mechanism. This file transfer method is 435 also usable by MSRP endpoints using data channels, with the following 436 considerations: 438 o As an MSRP session maps to one data channel, a file transfer 439 session maps also to one data channel. 441 o SDP attributes are negotiated as specified in Section 4.7. 443 o Once the file transfer is complete, the same data channel MAY be 444 reused for another file transfer. 446 6. Gateway Considerations 448 This section describes the network configuration where one MSRP 449 endpoint uses an MSRP data channel as MSRP transport, the other MSRP 450 endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP 451 endpoints interwork via a gateway. 453 Specifically, a gateway can be configured to interwork an MSRP 454 session over a data channel with a peer that does not support data 455 channel transport in one of two ways. 457 In one model, the gateway performs as an MSRP Back-to-Back User Agent 458 (B2BUA) to interwork all the procedures as necessary between the 459 endpoints. No further specification is needed for this model. 461 Alternately, the gateway can provide transport level interworking 462 between MSRP endpoints using different transport protocols. In 463 accordance with Section 4.4, path attributes SHALL NOT be used for 464 transport level interworking. 466 When the gateway performs transport level interworking between MSRP 467 endpoints, all of the procedures in Section 5 and Section 4 apply to 468 each peer, with the following additions: 470 o The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards 471 the non-data channel endpoint. 473 o If the non-data channel endpoint does not support MSRP CEMA, 474 transport level interworking mode is not possible, the gateway 475 needs to act as an MSRP B2BUA. 477 o The gateway SHALL NOT modify the path attribute received from data 478 channel or from non-data channel endpoints. 480 o The gateway SHALL NOT modify the setup value received from data 481 channel or from non-data channel endpoints. 483 o The endpoint establishing an MSRP session using data channel 484 transport SHALL NOT request inclusion of any relays, although it 485 MAY interoperate with a peer that signals the use of relays. 487 7. Updates to RFC4975 489 This document updates [RFC4975], by allowing the usage of the "msrps" 490 scheme when the underlying connection is protected with DTLS. 492 8. Security Considerations 494 MSRP traffic over data channels is secured, including 495 confidentiality, integrity and source authentication, as specified by 496 [I-D.ietf-rtcweb-data-channel]. 498 [RFC5547] specifies security considerations related to the usage of 499 MSRP for file transfer. 501 Note that discussion in [RFC4975] on MSRP message attribution to 502 remote identities applies to data channel transport. 504 If the Session Initiation Protocol (SIP) [RFC3261] is used to 505 implement the offer/answer transactions for establishing the MSRP 506 data channel, the SIP security considerations specified in [RFC3261] 507 apply. 509 9. IANA Considerations 511 NOTE to RFC Editor: Please replace all instances of all instances of 512 RFCXXXX with the number of this RFC. 514 9.1. msrps URI scheme 516 This document modifies the usage of the msrps URI scheme, registered 517 by [RFC4975], adding DTLS as a protected transport indicated by the 518 URI scheme. 520 A reference to RFCXXXX is added to the URI scheme "msrps" in the 521 Uniform Resource Identifier (URI) Schemes Registry. 523 9.2. Subprotocol Identifier MSRP 525 A reference to RFCXXXX is added to the subprotocol identifier "msrp" 526 in the "WebSocket Subprotocol Name Registry" 528 9.3. SDP Attributes 530 This document modifies the usage of a set of SDP attributes, if any 531 of those attributes is included in an SDP 'dsca' attribute associated 532 with an MSRP data channel. The modified usage of the SDP 'setup' 533 attribute is described in Section 4.5. The usage of the other SDP 534 attributes is described in Section 4.4. 536 o "path" 538 o "msrp-cema" 540 o "accept-types" 542 o "accept-wrapped-types" 544 o "max-size" 546 o "sendonly" 548 o "recvonly" 550 o "inactive" 552 o "sendrecv" 554 o "file-selector" 556 o "file-transfer-id" 558 o "file-disposition" 560 o "file-date" 562 o "file-icon" 564 o "file-range" 566 The usage level "dcsa(msrp)" is added to the registration of the SDP 567 'setup' attribute in the Session Description Protocol (SDP) 568 Parameters "att-field" sub-registry as follows: 570 +-----------------------+-------------------------------------------+ 571 | Contact name: | IESG | 572 | Contact email: | iesg@ietf.org | 573 | Attribute name: | setup | 574 | Usage level: | dcsa(msrp) | 575 | Purpose: | Negotiate the active role of an MSRP | 576 | | session over a data channel as per | 577 | | Section 4.5 | 578 | Reference: | RFCXXXX | 579 +-----------------------+-------------------------------------------+ 581 The usage level "dcsa(msrp)" is added to the registration of the SDP 582 'path' attribute in the Session Description Protocol (SDP) Parameters 583 "att-field" sub-registry as follows: 585 +-----------------------+-------------------------------------------+ 586 | Contact name: | IESG | 587 | Contact email: | iesg@ietf.org | 588 | Attribute name: | path | 589 | Usage level: | dcsa(msrp) | 590 | Purpose: | Indicate an endpoint, but not used for | 591 | | routing, as described in Section 4.4 | 592 | Reference: | RFCXXXX | 593 +-----------------------+-------------------------------------------+ 595 The usage level "dcsa(msrp)" is added to the registration of the SDP 596 'msrp-cema' attribute in the Session Description Protocol (SDP) 597 Parameters "att-field" sub-registry as follows: 599 +-----------------------+-------------------------------------------+ 600 | Contact name: | IESG | 601 | Contact email: | iesg@ietf.org | 602 | Attribute name: | msrp-cema | 603 | Usage level: | dcsa(msrp) | 604 | Purpose: | Indicate that the routing of MSRP | 605 | | messages transported on a data channel is | 606 | | more similar to the MSRP CEMA mechanism | 607 | | than the legacy MSRP routing mechanism. | 608 | Reference: | RFCXXXX | 609 +-----------------------+-------------------------------------------+ 611 The usage level "dcsa(msrp)" is added to the registration of the SDP 612 'accept-types' attribute in the Session Description Protocol (SDP) 613 Parameters "att-field" sub-registry as follows: 615 +-----------------------+-------------------------------------------+ 616 | Contact name: | IESG | 617 | Contact email: | iesg@ietf.org | 618 | Attribute name: | accept-types | 619 | Usage level: | dcsa(msrp) | 620 | Purpose: | Contain the list of media types that the | 621 | | endpoint is willing to receive. | 622 | Reference: | RFCXXXX | 623 +-----------------------+-------------------------------------------+ 625 The usage level "dcsa(msrp)" is added to the registration of the SDP 626 'accept-wrapped-types' attribute in the Session Description Protocol 627 (SDP) Parameters "att-field" sub-registry as follows: 629 +-----------------------+-------------------------------------------+ 630 | Contact name: | IESG | 631 | Contact email: | iesg@ietf.org | 632 | Attribute name: | accept-wrapped-types | 633 | Usage level: | dcsa(msrp) | 634 | Purpose: | Contain the list of media types that the | 635 | | endpoint is willing to receive in an MSRP | 636 | | message with multipart content. | 637 | Reference: | RFCXXXX | 638 +-----------------------+-------------------------------------------+ 640 The usage level "dcsa(msrp)" is added to the registration of the SDP 641 'max-size' attribute in the Session Description Protocol (SDP) 642 Parameters "att-field" sub-registry as follows: 644 +-----------------------+-------------------------------------------+ 645 | Contact name: | IESG | 646 | Contact email: | iesg@ietf.org | 647 | Attribute name: | max-size | 648 | Usage level: | dcsa(msrp) | 649 | Purpose: | Indicate the largest message an MSRP | 650 | | endpoint wishes to accept. | 651 | Reference: | RFCXXXX | 652 +-----------------------+-------------------------------------------+ 654 The usage level "dcsa(msrp)" is added to the registration of the SDP 655 'sendonly' attribute in the Session Description Protocol (SDP) 656 Parameters "att-field" sub-registry as follows: 658 +-----------------------+-------------------------------------------+ 659 | Contact name: | IESG | 660 | Contact email: | iesg@ietf.org | 661 | Attribute name: | sendonly | 662 | Usage level: | dcsa(msrp) | 663 | Purpose: | Negotiate the direction of the media flow | 664 | | on an MSRP data channel. | 665 | Reference: | RFCXXXX | 666 +-----------------------+-------------------------------------------+ 668 The usage level "dcsa(msrp)" is added to the registration of the SDP 669 'recvonly' attribute in the Session Description Protocol (SDP) 670 Parameters "att-field" sub-registry as follows: 672 +-----------------------+-------------------------------------------+ 673 | Contact name: | IESG | 674 | Contact email: | iesg@ietf.org | 675 | Attribute name: | recvonly | 676 | Usage level: | dcsa(msrp) | 677 | Purpose: | Negotiate the direction of the media flow | 678 | | on an MSRP data channel. | 679 | Reference: | RFCXXXX | 680 +-----------------------+-------------------------------------------+ 682 The usage level "dcsa(msrp)" is added to the registration of the SDP 683 'inactive' attribute in the Session Description Protocol (SDP) 684 Parameters "att-field" sub-registry as follows: 686 +-----------------------+-------------------------------------------+ 687 | Contact name: | IESG | 688 | Contact email: | iesg@ietf.org | 689 | Attribute name: | inactive | 690 | Usage level: | dcsa(msrp) | 691 | Purpose: | Negotiate the direction of the media flow | 692 | | on an MSRP data channel. | 693 | Reference: | RFCXXXX | 694 +-----------------------+-------------------------------------------+ 696 The usage level "dcsa(msrp)" is added to the registration of the SDP 697 'sendrecv' attribute in the Session Description Protocol (SDP) 698 Parameters "att-field" sub-registry as follows: 700 +-----------------------+-------------------------------------------+ 701 | Contact name: | IESG | 702 | Contact email: | iesg@ietf.org | 703 | Attribute name: | sendrecv | 704 | Usage level: | dcsa(msrp) | 705 | Purpose: | Negotiate the direction of the media flow | 706 | | on an MSRP data channel. | 707 | Reference: | RFCXXXX | 708 +-----------------------+-------------------------------------------+ 710 The usage level "dcsa(msrp)" is added to the registration of the SDP 711 'file-selector' attribute in the Session Description Protocol (SDP) 712 Parameters "att-field" sub-registry as follows: 714 +-----------------------+-------------------------------------------+ 715 | Contact name: | IESG | 716 | Contact email: | iesg@ietf.org | 717 | Attribute name: | file-selector | 718 | Usage level: | dcsa(msrp) | 719 | Purpose: | Indicate a file in an MSRP file transfer | 720 | | negotiation. | 721 | Reference: | RFCXXXX | 722 +-----------------------+-------------------------------------------+ 724 The usage level "dcsa(msrp)" is added to the registration of the SDP 725 'file-transfer-id' attribute in the Session Description Protocol 726 (SDP) Parameters "att-field" sub-registry as follows: 728 +-----------------------+-------------------------------------------+ 729 | Contact name: | IESG | 730 | Contact email: | iesg@ietf.org | 731 | Attribute name: | file-transfer-id | 732 | Usage level: | dcsa(msrp) | 733 | Purpose: | Indicate a unique identifier of the file | 734 | | transfer operation in an MSRP file | 735 | | transfer negotiation. | 736 | Reference: | RFCXXXX | 737 +-----------------------+-------------------------------------------+ 739 The usage level "dcsa(msrp)" is added to the registration of the SDP 740 'file-disposition' attribute in the Session Description Protocol 741 (SDP) Parameters "att-field" sub-registry as follows: 743 +-----------------------+-------------------------------------------+ 744 | Contact name: | IESG | 745 | Contact email: | iesg@ietf.org | 746 | Attribute name: | file-disposition | 747 | Usage level: | dcsa(msrp) | 748 | Purpose: | Provide a suggestion to the other | 749 | | endpoint about the intended disposition | 750 | | of the file in an MSRP file transfer | 751 | | negotiation. | 752 | Reference: | RFCXXXX | 753 +-----------------------+-------------------------------------------+ 755 The usage level "dcsa(msrp)" is added to the registration of the SDP 756 'file-date' attribute in the Session Description Protocol (SDP) 757 Parameters "att-field" sub-registry as follows: 759 +-----------------------+-------------------------------------------+ 760 | Contact name: | IESG | 761 | Contact email: | iesg@ietf.org | 762 | Attribute name: | file-date | 763 | Usage level: | dcsa(msrp) | 764 | Purpose: | Indicate a date related to the file in an | 765 | | MSRP file transfer negotiation. | 766 | Reference: | RFCXXXX | 767 +-----------------------+-------------------------------------------+ 769 The usage level "dcsa(msrp)" is added to the registration of the SDP 770 'file-icon' attribute in the Session Description Protocol (SDP) 771 Parameters "att-field" sub-registry as follows: 773 +-----------------------+-------------------------------------------+ 774 | Contact name: | IESG | 775 | Contact email: | iesg@ietf.org | 776 | Attribute name: | file-icon | 777 | Usage level: | dcsa(msrp) | 778 | Purpose: | Contain a pointer to a small preview icon | 779 | | representing the contents of the file in | 780 | | an MSRP file transfer negotiation. | 781 | Reference: | RFCXXXX | 782 +-----------------------+-------------------------------------------+ 784 The usage level "dcsa(msrp)" is added to the registration of the SDP 785 'file-range' attribute in the Session Description Protocol (SDP) 786 Parameters "att-field" sub-registry as follows: 788 +-----------------------+-------------------------------------------+ 789 | Contact name: | IESG | 790 | Contact email: | iesg@ietf.org | 791 | Attribute name: | file-range | 792 | Usage level: | dcsa(msrp) | 793 | Purpose: | Contain the range of transferred octets | 794 | | of the file in an MSRP file transfer | 795 | | negotiation. | 796 | Reference: | RFCXXXX | 797 +-----------------------+-------------------------------------------+ 799 10. Acknowledgments 801 The authors wish to acknowledge the borrowing of ideas from another 802 internet draft by Peter Dunkley and Gavin Llewellyn, and to thank 803 Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, 804 Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their 805 invaluable comments. 807 Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed 808 an earlier version, before the draft was re-adopted. 810 Julien Maisonneuve helped with the re-adoption of the draft, and 811 Maridi R. Makaraju (Raju) contributed valuable comments after the 812 draft was re-adopted. 814 11. CHANGE LOG 816 NOTE to RFC Editor: Please remove this Section before the publication 817 of RFCXXXX. 819 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-22' 821 o Changes based on Sec-Dir review. 823 11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-21' 825 o Changes based on Gen-Art review. 827 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-20' 829 o Changes based on AD review. 831 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-19' 833 o Minor nits. 835 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-18' 837 o Fix error in purpose of dcsa(marp) entry for 'path' attribute. 839 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-17' 841 o Shepherd's review: update to the file header, remove reference in 842 abstract, mention update on introduction, reorder and complete 843 IANA considerations. 845 o Editorial: a MSRP -> an MSRP; MSRP -> msrp for consistency; typos. 847 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-16' 849 o WGLC review: draft updates RFC4975; clarify introduction; rewrite 850 wording on path and transport negotiation; session closing 851 clarifications; references cleanup. 853 o Editorial: consistent SHALL usage; reorder updates, security and 854 IANA sections for consistency; typos; acknowledgements. 856 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15' 858 o More concise and clear introduction and section descriptions. 860 o Updates on author list, contributions and acknowledgements. 862 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14' 864 o Reorganization following t140-usage-data-channel structure. 866 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13' 868 o Clarify gateway procedures in accordance to mandatory use of CEMA. 870 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12' 872 o Make CEMA mandatory, clarify SDP procedures. 874 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 876 o Additional clarifications on cema and path attribute after mail 877 list feedback. 879 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 881 o Corrections and clarifications on cema and path attributes after 882 mail list feedback. 884 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 886 o Corrected area to ART. 888 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 890 o Updated reference to 4566bis. 892 o Expanded motivation paragraphs in introduction. 894 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 896 o Move security considerations after IANA considerations, following 897 RFC7322 suggested order. 899 o Update references to use xml.resource.org citation database. 901 o Reformat of the section discussing setup parameter 903 o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] 904 draft. 906 o Edit section 6 for clarity. 908 o Security requirements. 910 o Clarify comment on unrecognized transports and session opening. 912 o Update year, add editor. 914 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 916 o Modification of Keith's address information. 918 11.18. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 920 o Modification of Juergen's address information. 922 11.19. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 924 o Addition of "I-D.ietf-mmusic-rfc4566bis"/> to list of normative 925 references. 927 o Addition of IANA considerations for setup attribute as per section 928 8.2.4 of "I-D.ietf-mmusic-rfc4566bis"/>. 930 11.20. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 932 o Addition of IANA registration related Section 9.2. 934 11.21. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 936 o Addition of "a=setup:actpass", "a=connection:new", 937 "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to 938 the SDP example in Section 4.8. 940 o Addition of "RFC4145" and [I-D.ietf-mmusic-sctp-sdp] to list of 941 normative references. 943 o Addition of new Section 4.5 describing how the active MSRP session 944 endpoint role is negotiated. 946 o Extension of first paragraph of session-opening with new first 947 sentence "Section 4.5 describes how the active MSRP session 948 endpoint role is negotiated.". 950 o First sentence of second paragraph in session-opening was "As soon 951 as this data channel is opened, the MSRP session is actually 952 opened by the active MSRP endpoint which sends an MSRP SEND 953 message (empty or not) to the other MSRP endpoint." Replacement 954 of this sentence with "As soon as this data channel is opened, the 955 MSRP session is actually opened by the active MSRP endpoint. In 956 order to do this the active MSRP endpoint sends an MSRP SEND 957 message (empty or not) to the other MSRP endpoint." 959 o Addition of setup attribute specific behavior descriptions of data 960 channel to TCP or TLS interworking gateways in Section 6. 962 11.22. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 964 o In the abstract replacement of the first sentence "This document 965 specifies how the Message Session Relay Protocol (MSRP) can be 966 instantiated as a data channel sub-protocol, using the SDP offer/ 967 answer exchange-based external negotiation defined in 968 [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document 969 specifies how the Message Session Relay Protocol (MSRP) can be 970 instantiated as a data channel sub-protocol, using the SDP offer/ 971 answer exchange-based generic data channel negotiation framework" 972 in order to remove the reference from the abstract text. 974 o Addition of following sentence to the second paragraph in 975 Section 1: "The MSRP protocol negotiation defined in this document 976 is based on the generic SDP offer/answer exchange based data 977 channel negotiation as specified in 978 [I-D.ietf-mmusic-data-channel-sdpneg]". 980 o In Section 3.1 replacement of sub-protocol identifier "msrp" with 981 "MSRP" in order to make this consistent with the formal 982 specification in Section 4.3. 984 o Throughout the text replacement of "shall" with "SHALL" etc where 985 appropriate as per [RFC2119]. 987 o In Section 4.3 replacement of sentence 'The max-retr, max-time and 988 ordered parameters shall not be used.' with 'Ordered and reliable 989 data channels MUST always be used, such that the "max-retr" and 990 "max-time" parameters SHALL NOT be used. If the "ordered" 991 parameter is used, then its value MUST be equal to "true".'. 993 o In Section 4.3 removal of "(on default SCTP port 5000)" from the 994 sentence preceding the example "a=dcmap" attribute line. 996 o In Section 4.4 first paragraph was "The SDP offer shall also 997 include a dcsa attribute line (defined in 998 [I-D.ietf-mmusic-data-channel-sdpneg]) within the media 999 description for the SCTP association for each MSRP-specific SDP 1000 attribute to be negotiated for each MSRP data channel being 1001 negotiated.". Replacement of this paragraph with "The SDP offer 1002 SHALL also include within the media description for the SCTP 1003 association a dcsa attribute line (defined in 1004 [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP 1005 attribute to be negotiated for each MSRP data channel being 1006 negotiated.". 1008 o Appended following sentence at the end of the first paragraph of 1009 Section 5.4: "Therefore all sent MSRP chunks MUST have lengths of 1010 less than or equal to the value of the peer's "a=max-message-size" 1011 attribute, which is associated with the data channel's SCTP 1012 association.". 1014 o Addition of the previously missing colon to the "a=sctp-port" 1015 attribute line in Section 4.8. 1017 o In Section 5.3 replacement of the first paragraph "Closing of an 1018 MSRP session is done using the generic data channel closing 1019 procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with 1020 'The closure of an MSRP session MUST be signaled via an SDP offer/ 1021 answer exchange which removes the "a=dcmap:" and "a=dcsa:" 1022 attribute lines associated with the MSRP session from the 1023 associated DTLS/SCTP based media description. This results in the 1024 associated data channel being closed as well as per 1025 [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data 1026 channel closure procedure is typically initiated by the SDP 1027 answerer right after having accepted the SDP offer.'. 1029 11.23. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 1031 o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in 1032 list of normative references. 1034 o Replacement of previous document title "MSRP over SCTP/DTLS data 1035 channels" with "MSRP over Data Channels" in order to align with 1036 the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. 1038 o In "terminology", "WebRTC data channel" was defined as "A 1039 bidirectional channel consisting of paired SCTP outbound and 1040 inbound streams." Replacement of this definition with "Data 1041 channel: A WebRTC data channel as specified in 1042 [I-D.ietf-rtcweb-data-channel]", and consistent usage of either 1043 "data channel" or "MSRP data channel" in the remainder of the 1044 document." 1046 o In the introduction replacement of references to 1047 [I-D.ietf-rtcweb-data-protocol] with a reference to 1048 [I-D.ietf-rtcweb-data-channel]. 1050 o Consistent usage of '"m=" line' in whole document as per 1051 [RFC4566]. 1053 o In the gateway configuration section (Section 6) replacement of 1054 the first sentence "This section describes the network 1055 configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS 1056 connection, the other MSRP endpoint runs MSRP over one or more 1057 TLS/TCP connections, and the two endpoints interwork via an MSRP 1058 gateway" with "This section describes the network configuration 1059 where one MSRP endpoint uses data channels as MSRP transport, the 1060 other MSRP endpoint uses TLS/TCP connections as MSRP transport, 1061 and the two MSRP endpoints interwork via an MSRP gateway". 1063 11.24. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 1065 o Removed empty spaces after ";" in the examples' "a=dcmap" 1066 attribute lines. 1068 o In all examples, the "m=" line proto value "DTLS/SCTP" was 1069 replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines 1070 were replaced with "a=max-message-size" attribute lines, as per 1071 draft-ietf-mmusic-sctp-sdp-12. 1073 11.25. Changes against '-00' 1075 o Transport parameter change for MSRP to allow MSRP RFC transports. 1077 o Clarification on SDP offer/answer and removing duplicated 1078 procedures and refer them to draft-ejzak-mmusic-data-channel- 1079 sdpneg-02. 1081 12. References 1083 12.1. Normative References 1085 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1086 Requirement Levels", BCP 14, RFC 2119, 1087 DOI 10.17487/RFC2119, March 1997, 1088 . 1090 [I-D.ietf-rtcweb-data-protocol] 1091 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1092 Establishment Protocol", draft-ietf-rtcweb-data- 1093 protocol-09 (work in progress), January 2015. 1095 [I-D.ietf-rtcweb-data-channel] 1096 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1097 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1098 progress), January 2015. 1100 [I-D.ietf-mmusic-data-channel-sdpneg] 1101 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 1102 Even, "SDP-based Data Channel Negotiation", draft-ietf- 1103 mmusic-data-channel-sdpneg-28 (work in progress), May 1104 2019. 1106 [I-D.ietf-mmusic-sctp-sdp] 1107 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1108 "Session Description Protocol (SDP) Offer/Answer 1109 Procedures For Stream Control Transmission Protocol (SCTP) 1110 over Datagram Transport Layer Security (DTLS) Transport.", 1111 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1112 2017. 1114 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1115 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1116 July 2006, . 1118 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1119 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1120 DOI 10.17487/RFC4975, September 2007, 1121 . 1123 [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 1124 and P. Kyzivat, "A Session Description Protocol (SDP) 1125 Offer/Answer Mechanism to Enable File Transfer", RFC 5547, 1126 DOI 10.17487/RFC5547, May 2009, 1127 . 1129 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 1130 for the Message Session Relay Protocol (MSRP)", RFC 6135, 1131 DOI 10.17487/RFC6135, February 2011, 1132 . 1134 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1135 Establishment for Media Anchoring (CEMA) for the Message 1136 Session Relay Protocol (MSRP)", RFC 6714, 1137 DOI 10.17487/RFC6714, August 2012, 1138 . 1140 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 1141 and R. Ravindranath, "The WebSocket Protocol as a 1142 Transport for the Message Session Relay Protocol (MSRP)", 1143 RFC 7977, DOI 10.17487/RFC7977, September 2016, 1144 . 1146 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1147 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1148 May 2017, . 1150 12.2. Informative References 1152 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1153 A., Peterson, J., Sparks, R., Handley, M., and E. 1154 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1155 DOI 10.17487/RFC3261, June 2002, 1156 . 1158 Authors' Addresses 1160 Jose M. Recio (editor) 1161 Unaffiliated 1163 Email: jose@ch3m4.com 1164 Christer Holmberg 1165 Ericsson 1166 Hirsalantie 11 1167 Jorvas 02420 1168 Finland 1170 Email: christer.holmberg@ericsson.com