Message Session Relay Protocol (MSRP) over Data ChannelsUnaffiliatedjose@ch3m4.comEricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.com
ART
MMUSICwebrtc
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
.
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
() 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
. Introduction
. Conventions
. WebRTC Data Channel Considerations
. MSRP Data Channel
. SDP Considerations
. MSRP URI
. MSRP URI msrp-scheme
. Use of the 'dcmap' Attribute
. Use of the 'dcsa' Attribute
. Use of the DCSA-Embedded 'setup' Attribute
. Session Closing
. Support for MSRP File Transfer Function
. Example
. MSRP Considerations
. Session Mapping
. Session Opening
. Session Closing
. Data Framing
. Data Sending, Receiving, and Reporting
. Support for MSRP File Transfer Function
. Gateway Considerations
. Updates to RFC 4975
. Security Considerations
. IANA Considerations
. "msrps" URI scheme
. Subprotocol Identifier "msrp"
. SDP Attributes
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
Introduction
The Message Session Relay Protocol (MSRP) 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 to work over
TCP and TLS connections, and over a WebSocket subprotocol specified by .
This document specifies how a Web Real-Time Communication (WebRTC)
data channel 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 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
.
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 as described in .
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 when, and only when, they appear in all capitals, as
shown here.
WebRTC Data Channel ConsiderationsMSRP Data ChannelThe following WebRTC data channel property values
apply to an MSRP data channel:
Property
Value
Subprotocol Identifier
msrp
Transmission reliability
reliable
Transmission order
in-order
Label
See
SDP ConsiderationsThe generic SDP considerations, including the SDP offer/answer
procedures , for negotiating a WebRTC data channel are
defined in . 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.MSRP URIThis document extends the MSRP URI syntax 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 ).
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 ().MSRP URI msrp-schemeThe 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 .Use of the 'dcmap' AttributeAn offerer and answerer SHALL, in each offer and answer,
include a 'dcmap' attribute in the SDP
media description ("m=" section) describing the SCTP association 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 .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"
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) 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 .
An offerer and answerer SHALL include a 'dcsa' attribute for each of the following MSRP-specific SDP attributes:
defined in : 'path'.
defined in : 'msrp-cema'.
defined in : 'setup'.
See .
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 : 'accept-types', 'accept-wrapped-types', and 'max-size'.
defined in : 'sendonly', 'recvonly', 'inactive', and 'sendrecv'.
defined in : all the parameters related to MSRP file transfer. See .
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 .
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 , and the MSRP messages are then transported
on that data channel. This is different from legacy MSRP but similar to
MSRP Connection Establishment for Media Anchoring (MSRP CEMA) .
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
.
Use of the DCSA-Embedded 'setup' Attribute
As described in , 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
and
. It has no relationship with the DTLS connection establishment roles .
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.
Session ClosingAn MSRP session is closed by closing the associated data channel
following the procedures in .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 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.Support for MSRP File Transfer FunctionSDP attributes specified in for a file transfer "m=" line are embedded as subprotocol-specific attributes using the syntax defined in .ExampleBelow 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 and .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.
MSRP ConsiderationsThe procedures specified in apply except when this document specifies otherwise. This section describes the MSRP considerations specific to an MSRP data channel.Session MappingIn this document, each MSRP session maps to one data channel exactly.Session Opening 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 .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.Session ClosingThe closure of an MSRP session SHALL be signaled via
SDP following the requirements in .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.Data FramingEach text-based MSRP message is sent on the corresponding data channel using standard MSRP framing and chunking procedures, as defined in , 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 associated with the SCTP association.Data Sending, Receiving, and ReportingData sending, receiving, and reporting procedures SHALL conform to .Support for MSRP File Transfer Function 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 .
Once the file transfer is complete, the same data channel MAY be reused for another file transfer.
Gateway ConsiderationsThis 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 ,
'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 and
apply to each peer, with the following additions:
The gateway SHALL use the MSRP CEMA mechanism 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.
Updates to RFC 4975This document updates
by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS.Security ConsiderationsMSRP traffic over data channels, including confidentiality, integrity, and source authentication,
is secured as specified by .
However, 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 , 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. specifies security considerations related to the usage of MSRP for file transfer. specifies security considerations related to B2BUAs.Note that the discussion in on MSRP message attribution to remote identities applies to data channel transport.If the Session Initiation Protocol (SIP) is used to implement the offer/answer transactions for establishing the MSRP data channel, the SIP security considerations specified in apply.IANA Considerations"msrps" URI schemeThis document modifies the usage of the "msrps" URI scheme,
registered by ,
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.Subprotocol Identifier "msrp"A reference to RFC 8873 has been added to the subprotocol identifier
"msrp" in the "WebSocket Subprotocol Name Registry".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 . The usage of the other
SDP attributes is described in .
'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
.
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
.
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
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]Stream Control Transmission ProtocolThis document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]The Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File TransferThis document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]An Alternative Connection Model for the Message Session Relay Protocol (MSRP)This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFCs 4975 and 4976.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.WebRTC Data ChannelsSession Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) TransportNegotiation Data Channels Using the Session Description Protocol (SDP)UnaffiliatedNokiaUnaffiliatedUnaffiliatedHuaweiInformative ReferencesSIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User AgentsIn many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.AcknowledgmentsThe authors wish to acknowledge the borrowing of ideas from
another Internet-Draft by and
, and to thank
, ,
, ,
, , and
for their invaluable comments., , and
contributed to an earlier draft version
of this document before the draft was readopted. helped with the readoption of this document, and
contributed valuable comments
after the document was readopted.Authors' AddressesUnaffiliatedjose@ch3m4.comEricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.com