diff options
Diffstat (limited to 'doc/rfc/rfc8873.txt')
| -rw-r--r-- | doc/rfc/rfc8873.txt | 877 |
1 files changed, 877 insertions, 0 deletions
diff --git a/doc/rfc/rfc8873.txt b/doc/rfc/rfc8873.txt new file mode 100644 index 0000000..215590f --- /dev/null +++ b/doc/rfc/rfc8873.txt @@ -0,0 +1,877 @@ + + + + +Internet Engineering Task Force (IETF) JM. Recio, Ed. +Request for Comments: 8873 Unaffiliated +Updates: 4975 C. Holmberg +Category: Standards Track Ericsson +ISSN: 2070-1721 January 2021 + + + Message Session Relay Protocol (MSRP) over Data Channels + +Abstract + + This document specifies how a Web Real-Time Communication (WebRTC) + data channel can be used as a transport mechanism for the Message + Session Relay Protocol (MSRP) and how the Session Description + Protocol (SDP) offer/answer mechanism can be used to negotiate such a + data channel, referred to as an MSRP data channel. Two network + configurations are supported: the connection of two MSRP data channel + endpoints; and a gateway configuration, which connects an MSRP data + channel endpoint with an MSRP endpoint that uses either TCP or TLS. + This document updates RFC 4975. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8873. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions + 3. WebRTC Data Channel Considerations + 3.1. MSRP Data Channel + 4. SDP Considerations + 4.1. MSRP URI + 4.2. MSRP URI msrp-scheme + 4.3. Use of the 'dcmap' Attribute + 4.4. Use of the 'dcsa' Attribute + 4.5. Use of the DCSA-Embedded 'setup' Attribute + 4.6. Session Closing + 4.7. Support for MSRP File Transfer Function + 4.8. Example + 5. MSRP Considerations + 5.1. Session Mapping + 5.2. Session Opening + 5.3. Session Closing + 5.4. Data Framing + 5.5. Data Sending, Receiving, and Reporting + 5.6. Support for MSRP File Transfer Function + 6. Gateway Considerations + 7. Updates to RFC 4975 + 8. Security Considerations + 9. IANA Considerations + 9.1. "msrps" URI scheme + 9.2. Subprotocol Identifier "msrp" + 9.3. SDP Attributes + 10. References + 10.1. Normative References + 10.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for + transmitting a series of related instant messages in the context of a + session. In addition to instant messaging, MSRP can also be used for + image sharing or file transfer. MSRP was initially defined in + [RFC4975] to work over TCP and TLS connections, and over a WebSocket + subprotocol specified by [RFC7977]. + + This document specifies how a Web Real-Time Communication (WebRTC) + data channel [RFC8831] can be used as a transport mechanism for MSRP + without the TCP and TLS layers, and how the Session Description + Protocol (SDP) offer/answer mechanism for data channels [RFC8864] can + be used to negotiate such a data channel. + + In this document, an MSRP data channel refers to a WebRTC data + channel for which the instantiated subprotocol is "msrp" and the data + channel is negotiated using the SDP offer/answer mechanism [RFC8864]. + + Defining MSRP as a data channel subprotocol has many benefits: + + * provides to applications a proven protocol enabling instant + messaging, file transfer, image sharing + + * integrates those features with other WebRTC voice, video, and data + features + + * leverages the SDP-based negotiation already defined for MSRP + + * allows the interworking with MSRP endpoints running on a TCP or + TLS connection + + Compared to the WebSocket protocol, which provides a message-passing + protocol to applications with no direct access to TCP or TLS sockets, + data channels provide a low-latency transport and leverage NAT-aware + connectivity and the security features of WebRTC. + + This document defines an MSRP data channel endpoint as an MSRP + application that uses a WebRTC data channel for MSRP transport. This + document describes configurations for connecting such endpoint to + another MSRP data channel endpoint, or to an MSRP endpoint that uses + either TCP or TLS transport. + + This document updates [RFC4975] as described in Section 7. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. WebRTC Data Channel Considerations + +3.1. MSRP Data Channel + + The following WebRTC data channel property values [RFC8831] apply to + an MSRP data channel: + + +==========================+=================+ + | Property | Value | + +==========================+=================+ + | Subprotocol Identifier | msrp | + +--------------------------+-----------------+ + | Transmission reliability | reliable | + +--------------------------+-----------------+ + | Transmission order | in-order | + +--------------------------+-----------------+ + | Label | See Section 4.3 | + +--------------------------+-----------------+ + + Table 1 + +4. SDP Considerations + + The generic SDP considerations, including the SDP offer/answer + procedures [RFC3264], for negotiating a WebRTC data channel are + defined in [RFC8864]. This section and its subsections define the + SDP considerations that are specific to an MSRP data channel, + identified by the "subprotocol" attribute parameter, with an "msrp" + parameter value in the 'dcmap' attribute. + +4.1. MSRP URI + + This document extends the MSRP URI syntax [RFC4975] by defining the + new transport parameter value "dc" (an abbreviation of data channel): + + transport /= "dc" + ; Add "dc" to existing transports per Section 9 of [RFC4975] + + MSRP design provides for new transport bindings (see Section 6 of + [RFC4975]). MSRP implementations are expected to allow unrecognized + transports for which there is no need to establish a connection to + the resource described by the URI, as is the case of data channels + (Section 4.4). + +4.2. MSRP URI msrp-scheme + + The msrp-scheme portion of the MSRP URI that represents an MSRP data + channel endpoint (used in the SDP 'path' attribute and in the MSRP + message headers) is always "msrps", which indicates that the MSRP + data channel is always secured using DTLS as described in [RFC8831]. + +4.3. Use of the 'dcmap' Attribute + + An offerer and answerer SHALL, in each offer and answer, include a + 'dcmap' attribute [RFC8864] in the SDP media description ("m=" + section) [RFC4566] describing the SCTP association [RFC4960] used to + realize the MSRP data channel. + + The attribute includes the following data channel parameters: + + * "label=" labelstring + + * "subprotocol=" "msrp" + + The labelstring is set by the MSRP application according to + [RFC8864]. + + The offerer and answerer SHALL NOT include the "max-retr" and the + "max-time" attribute parameters in the 'dcmap' attribute. + + The offerer and answerer MAY include the "ordered" attribute + parameter in the 'dcmap' attribute. If included, the attribute + parameter value SHALL be set to "true". + + Below is an example of a 'dcmap' attribute for an MSRP session to be + negotiated with the "dcmap-stream-id" parameter set to 2 and the + "label" parameter set to "chat": + + a=dcmap:2 label="chat";subprotocol="msrp" + +4.4. Use of the 'dcsa' Attribute + + An offerer and answerer can, in each offer and answer, include one or + more data channel subprotocol attributes ('dcsa' attributes) + [RFC8864] in the "m=" section describing the SCTP association used to + realize the MSRP data channel. An SDP attribute included in a 'dcsa' + attribute is referred to as a DCSA-embedded attribute. + + If an offerer or answerer receives a 'dcsa' attribute that contains + an SDP attribute for which usage has not been defined for an MSRP + data channel, the offerer or answerer should ignore the 'dcsa' + attribute, following the rules in Section 6.7 of [RFC8864]. + + An offerer and answerer SHALL include a 'dcsa' attribute for each of + the following MSRP-specific SDP attributes: + + * defined in [RFC4975]: 'path'. + + * defined in [RFC6714]: 'msrp-cema'. + + * defined in [RFC6135]: 'setup'. See Section 4.5. + + It is considered a protocol error if one or more of the DCSA-embedded + attributes listed above are not included in an offer or answer. + + An offerer and answerer MAY include a 'dcsa' attribute for any of the + following MSRP-specific SDP attributes, following the procedures + defined for each attribute: + + * defined in [RFC4975]: 'accept-types', 'accept-wrapped-types', and + 'max-size'. + + * defined in [RFC4566]: 'sendonly', 'recvonly', 'inactive', and + 'sendrecv'. + + * defined in [RFC5547]: all the parameters related to MSRP file + transfer. See Section 4.7. + + A subsequent offer or answer MAY update the previously negotiated + MSRP subprotocol attributes while keeping the 'dcmap' attribute + associated with the MSRP data channel unchanged. The semantics for + newly negotiated MSRP subprotocol attributes are per [RFC4975]. + + When MSRP messages are transported on a data channel, the 'path' + attribute is not used for the routing of the messages. The MSRP data + channel is established using the SDP offer/answer procedures defined + in [RFC8864], and the MSRP messages are then transported on that data + channel. This is different from legacy MSRP [RFC4975] but similar to + MSRP Connection Establishment for Media Anchoring (MSRP CEMA) + [RFC6714]. Because of this, a DCSA-embedded 'msrp-cema' attribute is + mandated for MSRP sessions over data channels. However, when an + endpoint receives an MSRP message over a data channel, it MUST still + perform the MSRP URI comparison procedures defined in [RFC4975]. + +4.5. Use of the DCSA-Embedded 'setup' Attribute + + As described in Section 4.4, the usage of a DCSA-embedded 'setup' + attribute is mandated for MSRP sessions over data channels. It is + used to negotiate which MSRP data channel endpoint assumes the active + role as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. + It has no relationship with the DTLS connection establishment roles + [RFC8841]. + + The DCSA-embedded 'setup' attribute is of the form "a=dcsa:x + setup:<role>", with x being the data channel's SCTP stream + identifier, so that the 'setup' attribute is explicitly associated + with an MSRP session over a specific data channel. + +4.6. Session Closing + + An MSRP session is closed by closing the associated data channel + following the procedures in [RFC8864]. + + The port value for the "m=" line SHOULD NOT be changed (e.g., to + zero) when closing an MSRP session (unless all data channels are + being closed and the SCTP association is no longer needed) since this + would close the SCTP association and impact all of the data channels. + In all cases in [RFC4975] where the procedure calls for setting the + port to zero in the MSRP "m=" line in an SDP offer for TCP transport, + the SDP offerer of an MSRP session with data channel transport SHALL + remove the corresponding 'dcmap' and 'dcsa' attributes. + +4.7. Support for MSRP File Transfer Function + + SDP attributes specified in [RFC5547] for a file transfer "m=" line + are embedded as subprotocol-specific attributes using the syntax + defined in [RFC8864]. + +4.8. Example + + Below is an example of an offer and an answer that include the + attributes needed to establish two MSRP sessions: one for chat and + one for file transfer. The example is derived from a combination of + examples in [RFC4975] and [RFC5547]. + + Offer: + + m=application 54111 UDP/DTLS/SCTP webrtc-datachannel + c=IN IP6 2001:db8::3 + a=max-message-size:100000 + a=sctp-port:5000 + a=setup:actpass + a=fingerprint:SHA-256 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:\ + 3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD + a=tls-id:4a756565cddef001be82 + a=dcmap:0 label="chat";subprotocol="msrp" + a=dcsa:0 msrp-cema + a=dcsa:0 setup:active + a=dcsa:0 accept-types:message/cpim text/plain + a=dcsa:0 path:msrps://2001:db8::3:54111/si438dsaodes;dc + a=dcmap:2 label="file transfer";subprotocol="msrp" + a=dcsa:2 sendonly + a=dcsa:2 msrp-cema + a=dcsa:2 setup:active + a=dcsa:2 accept-types:message/cpim + a=dcsa:2 accept-wrapped-types:* + a=dcsa:2 path:msrps://2001:db8::3:54111/jshA7we;dc + a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ + size:1463440 hash:sha-256:7C:DF:3E:5D:49:6B:19:E5:12:AB:4A:AD:\ + 4A:B1:3F:82:3E:3B:54:12:02:5D:18:DF:49:6B:19:E5:7C:AB:B9:AD + a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep + a=dcsa:2 file-disposition:attachment + a=dcsa:2 file-date:creation:"Tue, 11 Aug 2020 19:05:30 +0200" + a=dcsa:2 file-icon:cid:id2@bob.example.com + a=dcsa:2 file-range:1-1463440 + + Answer: + + m=application 51444 UDP/DTLS/SCTP webrtc-datachannel + c=IN IP6 IP6 2001:db8::1 + a=max-message-size:100000 + a=sctp-port:6000 + a=setup:passive + a=fingerprint:SHA-256 5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:\ + B1:3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D + a=tls-id:65cd4a7565debe82f100 + a=dcmap:0 label="chat";subprotocol="msrp" + a=dcsa:0 msrp-cema + a=dcsa:0 setup:passive + a=dcsa:0 accept-types:message/cpim text/plain + a=dcsa:0 path:msrps://2001:db8::1:51444/di551fsaodes;dc + a=dcmap:2 label="file transfer";subprotocol="msrp" + a=dcsa:2 recvonly + a=dcsa:2 msrp-cema + a=dcsa:2 setup:passive + a=dcsa:2 accept-types:message/cpim + a=dcsa:2 accept-wrapped-types:* + a=dcsa:2 path:msrps://2001:db8::1:51444/jksh7Bwc;dc + a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ + size:1463440 + a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep + a=dcsa:2 file-range:1-1463440 + + Note that due to RFC formatting conventions, this document splits SDP + content that exceeds 72 characters across lines, marking this line + folding with a backslash character. This backslash and its trailing + CRLF and whitespace would not appear in actual SDP content. + +5. MSRP Considerations + + The procedures specified in [RFC4975] apply except when this document + specifies otherwise. This section describes the MSRP considerations + specific to an MSRP data channel. + +5.1. Session Mapping + + In this document, each MSRP session maps to one data channel exactly. + +5.2. Session Opening + + Section 4.5 describes how the active MSRP data channel endpoint role + is negotiated. The active MSRP data channel endpoint uses the data + channel established for this MSRP session by the generic data channel + opening procedure defined in [RFC8864]. + + As soon as the WebRTC data channel is opened, the MSRP session is + actually opened by the active MSRP data channel endpoint. In order + to do this, the active MSRP data channel endpoint sends an MSRP SEND + message (empty or not) to the peer (passive) MSRP data channel + endpoint. + +5.3. Session Closing + + The closure of an MSRP session SHALL be signaled via SDP following + the requirements in Section 4.6. + + If the data channel used to transport the MSRP session fails and is + torn down, the MSRP data channel endpoints SHALL consider the MSRP + session failed. An MSRP data channel endpoint MAY, based on local + policy, try to negotiate a new MSRP data channel. + +5.4. Data Framing + + Each text-based MSRP message is sent on the corresponding data + channel using standard MSRP framing and chunking procedures, as + defined in [RFC4975], with each MSRP chunk delivered in a single SCTP + user message. Therefore all sent MSRP chunks SHALL have lengths of + less than or equal to the value of the peer's 'max-message-size' + attribute [RFC8841] associated with the SCTP association. + +5.5. Data Sending, Receiving, and Reporting + + Data sending, receiving, and reporting procedures SHALL conform to + [RFC4975]. + +5.6. Support for MSRP File Transfer Function + + [RFC5547] defines an end-to-end file transfer method based on MSRP + and the SDP offer/answer mechanism. This file transfer method is + also usable by MSRP data channel endpoints with the following + considerations: + + * As an MSRP session maps to one data channel, a file transfer + session maps also to one data channel. + + * SDP attributes are negotiated as specified in Section 4.7. + + * Once the file transfer is complete, the same data channel MAY be + reused for another file transfer. + +6. Gateway Considerations + + This section describes the network configuration where one MSRP + endpoint uses an MSRP data channel as MSRP transport, the other MSRP + endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP + endpoints interwork via a gateway. + + Specifically, a gateway can be configured to interwork an MSRP + session over a data channel with a peer that does not support data + channel transport in one of two ways. + + In one model, the gateway performs as an MSRP Back-to-Back User Agent + (B2BUA) to interwork all the procedures as necessary between the + endpoints. No further specification is needed for this model. + + Alternately, the gateway can provide transport-level interworking + between MSRP endpoints using different transport protocols. In + accordance with Section 4.4, 'path' attributes SHALL NOT be used for + transport-level interworking. + + When the gateway performs transport-level interworking between MSRP + endpoints, all of the procedures in Section 4 and Section 5 apply to + each peer, with the following additions: + + * The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards + the non-data channel endpoint. + + * If the non-data channel endpoint does not support MSRP CEMA, + transport-level interworking mode is not possible, and the gateway + needs to act as an MSRP B2BUA. + + * The gateway SHALL NOT modify the 'path' attribute received from + data channel or from non-data channel endpoints. + + * The gateway SHALL NOT modify the 'setup' value received from data + channel or from non-data channel endpoints. + + * The endpoint establishing an MSRP session using data channel + transport SHALL NOT request inclusion of any relays, although it + MAY interoperate with a peer that signals the use of relays. + +7. Updates to RFC 4975 + + This document updates [RFC4975] by allowing the usage of the "msrps" + scheme when the underlying connection is protected with DTLS. + +8. Security Considerations + + MSRP traffic over data channels, including confidentiality, + integrity, and source authentication, is secured as specified by + [RFC8831]. However, [RFC4975] allows transport of MSRP traffic over + nonsecured TCP connections and does not provide a mechanism to + guarantee usage of TLS end to end. As described in [RFC4975], even + if TLS is used between some hops, TCP might still be used between + other hops. Operators need to establish proper policies in order to + ensure that the MSRP traffic is protected between endpoints. + + [RFC5547] specifies security considerations related to the usage of + MSRP for file transfer. + + [RFC7092] specifies security considerations related to B2BUAs. + + Note that the discussion in Section 14.5 of [RFC4975] on MSRP message + attribution to remote identities applies to data channel transport. + + If the Session Initiation Protocol (SIP) [RFC3261] is used to + implement the offer/answer transactions for establishing the MSRP + data channel, the SIP security considerations specified in [RFC3261] + apply. + +9. IANA Considerations + +9.1. "msrps" URI scheme + + This document modifies the usage of the "msrps" URI scheme, + registered by [RFC4975], by adding DTLS as a protected transport + indicated by the URI scheme. + + A reference to RFC 8873 has been added to the URI scheme "msrps" in + the "Uniform Resource Identifier (URI) Schemes" registry. + +9.2. Subprotocol Identifier "msrp" + + A reference to RFC 8873 has been added to the subprotocol identifier + "msrp" in the "WebSocket Subprotocol Name Registry". + +9.3. SDP Attributes + + This document modifies the usage of a set of SDP attributes if any of + those attributes is included in an SDP 'dcsa' attribute associated + with an MSRP data channel. The modified usage of the SDP 'setup' + attribute is described in Section 4.5. The usage of the other SDP + attributes is described in Section 4.4. + + * 'accept-types' + + * 'accept-wrapped-types' + + * 'file-date' + + * 'file-disposition' + + * 'file-icon' + + * 'file-range' + + * 'file-selector' + + * 'file-transfer-id' + + * 'inactive' + + * 'max-size' + + * 'msrp-cema' + + * 'path' + + * 'recvonly' + + * 'sendonly' + + * 'sendrecv' + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'accept-types' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: accept-types + Usage level: dcsa (msrp) + Purpose: Contain the list of media types that the endpoint + is willing to receive. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'accept-wrapped-types' attribute in the Session Description + Protocol (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: accept-wrapped-types + Usage level: dcsa (msrp) + Purpose: Contain the list of media types that the endpoint + is willing to receive in an MSRP message with + multipart content. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'file-date' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: file-date + Usage level: dcsa (msrp) + Purpose: Indicate one or more dates related to the file in + an MSRP file transfer negotiation. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'file-disposition' attribute in the Session Description + Protocol (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: file-disposition + Usage level: dcsa (msrp) + Purpose: Provide a suggestion to the other endpoint about + the intended disposition of the file in an MSRP + file transfer negotiation. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'file-icon' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: file-icon + Usage level: dcsa (msrp) + Purpose: Contain a pointer to a small preview icon + representing the contents of the file in an MSRP + file transfer negotiation. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'file-range' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: file-range + Usage level: dcsa (msrp) + Purpose: Contain the range of transferred octets of the file + in an MSRP file transfer negotiation. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'file-selector' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: file-selector + Usage level: dcsa (msrp) + Purpose: Indicate a file in an MSRP file transfer + negotiation. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'file-transfer-id' attribute in the Session Description + Protocol (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: file-transfer-id + Usage level: dcsa (msrp) + Purpose: Indicate a unique identifier of the file transfer + operation in an MSRP file transfer negotiation. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'inactive' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: inactive + Usage level: dcsa (msrp) + Purpose: Negotiate the direction of the media flow on an + MSRP data channel. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'max-size' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: max-size + Usage level: dcsa (msrp) + Purpose: Indicate the largest message an MSRP endpoint + wishes to accept. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'msrp-cema' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: msrp-cema + Usage level: dcsa (msrp) + Purpose: Indicate that the routing of MSRP messages + transported on a data channel is more similar to + the MSRP CEMA mechanism than the legacy MSRP + routing mechanism. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'path' attribute in the Session Description Protocol (SDP) + Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: path + Usage level: dcsa (msrp) + Purpose: Indicate an endpoint, but not used for routing, as + described in Section 4.4. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'recvonly' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: recvonly + Usage level: dcsa (msrp) + Purpose: Negotiate the direction of the media flow on an + MSRP data channel. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'sendonly' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: sendonly + Usage level: dcsa (msrp) + Purpose: Negotiate the direction of the media flow on an + MSRP data channel. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'setup' attribute in the "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: setup + Usage level: dcsa (msrp) + Purpose: Negotiate the active role of an MSRP session over a + data channel as per Section 4.5. + Reference: RFC 8873 + + The usage level "dcsa (msrp)" has been added to the registration of + the SDP 'sendrecv' attribute in the Session Description Protocol + (SDP) Parameters "att-field" subregistry as follows: + + Contact name: IESG + Contact email: iesg@ietf.org + Attribute name: sendrecv + Usage level: dcsa (msrp) + Purpose: Negotiate the direction of the media flow on an + MSRP data channel. + Reference: RFC 8873 + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., + "The Message Session Relay Protocol (MSRP)", RFC 4975, + DOI 10.17487/RFC4975, September 2007, + <https://www.rfc-editor.org/info/rfc4975>. + + [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., + and P. Kyzivat, "A Session Description Protocol (SDP) + Offer/Answer Mechanism to Enable File Transfer", RFC 5547, + DOI 10.17487/RFC5547, May 2009, + <https://www.rfc-editor.org/info/rfc5547>. + + [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model + for the Message Session Relay Protocol (MSRP)", RFC 6135, + DOI 10.17487/RFC6135, February 2011, + <https://www.rfc-editor.org/info/rfc6135>. + + [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection + Establishment for Media Anchoring (CEMA) for the Message + Session Relay Protocol (MSRP)", RFC 6714, + DOI 10.17487/RFC6714, August 2012, + <https://www.rfc-editor.org/info/rfc6714>. + + [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., + and R. Ravindranath, "The WebSocket Protocol as a + Transport for the Message Session Relay Protocol (MSRP)", + RFC 7977, DOI 10.17487/RFC7977, September 2016, + <https://www.rfc-editor.org/info/rfc7977>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data + Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, + <https://www.rfc-editor.org/info/rfc8831>. + + [RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, + "Session Description Protocol (SDP) Offer/Answer + Procedures for Stream Control Transmission Protocol (SCTP) + over Datagram Transport Layer Security (DTLS) Transport", + RFC 8841, DOI 10.17487/RFC8841, January 2021, + <https://www.rfc-editor.org/info/rfc8841>. + + [RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. + Even, Ed., "Negotiation Data Channels Using the Session + Description Protocol (SDP)", RFC 8864, + DOI 10.17487/RFC8864, January 2021, + <https://www.rfc-editor.org/info/rfc8864>. + +10.2. Informative References + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session + Initiation Protocol (SIP) Back-to-Back User Agents", + RFC 7092, DOI 10.17487/RFC7092, December 2013, + <https://www.rfc-editor.org/info/rfc7092>. + +Acknowledgments + + The authors wish to acknowledge the borrowing of ideas from another + Internet-Draft by Peter Dunkley and Gavin Llewellyn, and to thank + Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, + Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their + invaluable comments. + + Richard Ejzak, Keith Drage, and Juergen Stoetzer-Bradler contributed + to an earlier draft version of this document before the draft was + readopted. + + Julien Maisonneuve helped with the readoption of this document, and + Maridi R. Makaraju (Raju) contributed valuable comments after the + document was readopted. + +Authors' Addresses + + Jose M. Recio (editor) + Unaffiliated + + Email: jose@ch3m4.com + + + Christer Holmberg + Ericsson + Hirsalantie 11 + FI-02420 Jorvas + Finland + + Email: christer.holmberg@ericsson.com |