This document defines a new Session Description Protocol (SDP) media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

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/rfc8858.

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.

[RFC 5761] defines how to multiplex RTP and RTCP on a single IP address and port, referred to as RTP/RTCP multiplexing. [RFC 5761] also defines an SDP [RFC 4566] attribute, 'rtcp-mux', that can be used by entities to indicate support of RTP/RTCP multiplexing and negotiate usage of it. As defined in [RFC 5761], if the peer endpoint does not support RTP/RTCP multiplexing, both endpoints should use separate ports for sending and receiving of RTCP (referred to as fallback to usage of separate ports for RTP and RTCP). Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose not to implement separation of RTP and RTCP. Examples of such applications are W3C WebRTC applications [WebRTC], which are not required to interoperate with non-WebRTC clients. For such applications, this document defines an SDP attribute to signal intent to require multiplexing. The use of this attribute in SDP offers [RFC 3264] may harm the interoperability of entities that ever need to interoperate with peers that do not support RTC/RTCP multiplexing. Also, while the SDP answerer [RFC 3264] might support, and prefer usage of, fallback to nonmultiplex, the attribute indicates that fallback to nonmultiplex cannot be enabled. One example of where nonmultiplex is preferred is where an endpoint is connected to a radio interface and wants to use different bearers (possibly with different quality characteristics) for RTP and RTCP. Another example is where one endpoint is acting as a gateway to a network where RTP/RTCP multiplexing cannot be used. In such a case, the endpoint may also prefer nonmultiplexing towards the other network. Otherwise, the endpoint would have to perform demultiplexing of RTP and RTCP. This document defines a new SDP media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates [RFC 5761] by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. This document also describes the Interactive Connectivity Establishment (ICE) [RFC 8445] considerations when indicating exclusive support of RTP/RTCP multiplexing.

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

This section defines a new SDP media-level attribute, 'rtcp-mux-only'.

• Name:

  rtcp-mux-only

  Value:

  N/A

  Usage Level:

  media

  Charset Dependent:

  no

  Syntax:

  rtcp-mux-only

  Example:

  a=rtcp-mux-only

In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to indicate exclusive support of RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line). In an SDP answer, the 'rtcp-mux' attribute [RFC 5761] indicates that the answerer supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line). The usage of the 'rtcp-mux-only' attribute in an SDP answer is forbidden. The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based media. The mux category [RFC 8859] for the 'rtcp-mux-only' attribute is "IDENTICAL", which means that the attribute, if used within a BUNDLE group [RFC 8843], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. The 'rtcp-mux-only' attribute applies to the whole associated media description. The attribute MUST NOT be defined per source (using the SDP 'ssrc' attribute [RFC 5576]). The SDP offer/answer procedures [RFC 3264] associated with the attribute are defined in Section 4.

This section defines the SDP offer/answer procedures [RFC 3264] for indicating exclusive support of RTP/RTCP multiplexing and negotiating usage of it. The procedures in this section apply to individual RTP-based SDP media descriptions ("m=" lines).

When sending the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, it MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MUST also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC 5761]. If the offerer associates an SDP 'rtcp' attribute [RFC 3605] with an SDP media description ("m=" line), and if the offerer also associates an SDP 'rtcp-mux-only' attribute with the same SDP media description ("m=" line), the address and port values of the SDP 'rtcp' attribute MUST match the corresponding values for RTP. NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing.

When an answerer receives an offer that contains an SDP 'rtcp-mux-only' attribute associated with an RTP-based SDP media description ("m=" line), then if the answerer accepts the usage of RTP/RTCP multiplexing, it MUST associate an SDP 'rtcp-mux' attribute with the corresponding SDP media description ("m=") in the associated answer, following the procedures in [RFC 5761]. If the answerer does not accept the usage of RTP/RTCP multiplexing, it MUST either reject the SDP media description ("m=") by setting the port value to zero in the associated answer, or reject the whole offer, following the procedures in [RFC 3264]. The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer.

If an offerer associated an SDP 'rtcp-mux-only' attribute with an RTP-based SDP media description ("m=" line) in an offer, and if the corresponding SDP media description ("m=" line) in the associated answer contains an SDP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP multiplexing procedures [RFC 5761] to the associated RTP-based media. If the corresponding SDP media description ("m=" line) in the associated answer does not contain an SDP 'rtcp-mux' attribute, the offerer MUST either take appropriate actions in order to disable the associated RTP-based media -- e.g., send a new offer with a zero port value associated with the SDP media description ("m=" line) -- or send a new offer without associating an SDP 'rtcp-mux-only' attribute with the SDP media description ("m=" line). NOTE: This document does not mandate specific actions on how to terminate the RTP media. The offerer might, for example, terminate the RTP media by sending a new offer in which the port value of the SDP media description is set to zero.

When an offerer sends a subsequent offer, if the offerer and answerer have previously negotiated usage of exclusive RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with the corresponding SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MUST also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC 5761]. If the offerer does not associate the attributes with the corresponding SDP media description ("m=" line), it is an indication that the offerer no longer wants to use RTP/RTCP multiplexing and instead MUST fall back to usage of separate ports for RTP and RTCP once the offer has been accepted by the answerer. When an offerer sends a subsequent offer, if the offerer and answerer have not previously negotiated usage of RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, following the procedures in Section 4.2. The offerer MUST process the associated answer following the procedures in Section 4.4. It is RECOMMENDED to not switch between usage of RTP/RTCP multiplexing and usage of separate ports for RTP and RTCP in a subsequent offer, unless there is a use case that mandates it.

This section updates Sections 5.1.1 and 5.1.3 of [RFC 5761] by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports, and that the offerer shall terminate the affected streams if the answerer does not indicate support of RTP/RTCP multiplexing. It also clarifies that, when the offerer is not able to send and receive RTCP on separate ports, the offerer will not provide an SDP 'candidate' attribute for RTCP, nor will the offerer provide a fallback port for RTCP (using the SDP 'rtcp' attribute).

NOTE: [RFC 8035] also updates Section 5.1.1 of RFC 5761. While the paragraph updated in this document is not updated by [RFC 8035], the location of the paragraph within Section 5.1.1 is moved. OLD TEXT:

---

---

NEW TEXT:

---

---

OLD TEXT:

---

---

NEW TEXT:

---

---

As defined in [RFC 8445], if an entity is aware that the remote peer supports, and is willing to use, RTP/RTCP multiplexing, the entity will only provide RTP candidates (component ID 1). However, only providing RTP candidates does not, as such, imply exclusive support of RTP/RTCP multiplexing. RTCP candidates also would not be provided in cases where RTCP is not supported at all. Therefore, additional information is needed in order to indicate support of exclusive RTP/RTCP multiplexing. This document defines such a mechanism using the SDP 'rtcp-mux-only' attribute.

This document does not introduce new security considerations beyond those specified in [RFC 3605] and [RFC 5761].

This document updates the "Session Description Protocol Parameters" registry as specified in Section 8.2.4 of RFC 4566. Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media-level attributes.

• Attribute name:

  rtcp-mux-only

  Type of attribute:

  media-level

  Subject to charset:

  no

  Purpose:

  Indicate exclusive support of RTP/RTCP multiplexing

  Appropriate Values:

  N/A

  Contact name:

  Christer Holmberg (christer.holmberg@ericsson.com)

  Mux Category:

  IDENTICAL

[RFC2119]

S. Bradner, "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]

J. Rosenberg, 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]

M. Handley, V. Jacobson, and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006,
<https://www.rfc-editor.org/info/rfc4566>.

[RFC5761]

C. Perkins, and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010,
<https://www.rfc-editor.org/info/rfc5761>.

[RFC8035]

C. Holmberg, "Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing", RFC 8035, DOI 10.17487/RFC8035, November 2016,
<https://www.rfc-editor.org/info/rfc8035>.

[RFC8174]

B. Leiba, "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>.

[RFC8445]

A. Keranen, C. Holmberg, and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.

[RFC8843]

C Holmberg, H Alvestrand, and C Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021,
<https://www.rfc-editor.org/info/rfc8843>.

[RFC8859]

S Nandakumar, "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/rfc8859>.

[RFC3605]

C. Huitema, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003,
<https://www.rfc-editor.org/info/rfc3605>.

[RFC5576]

J. Lennox, J. Ott, and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>.

[WebRTC]

C Jennings, H Boström, and J-I Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers",
<https://www.w3.org/TR/webrtc/>.

Thanks to Roman Shpount, Paul Kyzivat, Ari Keränen, Bo Burman, Tomas Frankkila, and Martin Thomson for their comments and input on the document. Thanks to Francis Dupont for the GENART review.

Christer Holmberg