rtcp-mux-only: Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)
A one-word SDP attribute that says an endpoint will only send RTP and RTCP together on a single port.
Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, January 2021, <https://www.rfc-editor.org/info/rfc8858>.
@misc{rfc8858,
series = {Request for Comments},
number = 8858,
howpublished = {RFC 8858},
publisher = {RFC Editor},
doi = {10.17487/RFC8858},
url = {https://www.rfc-editor.org/info/rfc8858},
author = {C. Holmberg},
title = {{Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)}},
pagetotal = 9,
year = 2021,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8858 Ericsson
Updates: 5761 January 2021
Category: Standards Track
ISSN: 2070-1721
Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP)
Multiplexing Using the Session Description Protocol (SDP)
Abstract
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.
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/rfc8858.
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. SDP 'rtcp-mux-only' Attribute
4. SDP Offer/Answer Procedures
4.1. General
4.2. Generating the Initial SDP Offer
4.3. Generating the Answer
4.4. Offerer Processing of the SDP Answer
4.5. Modifying the Session
5. Update to RFC 5761
5.1. General
5.2. Update to 4th Paragraph of Section 5.1.1
5.3. Update to 2nd Paragraph of Section 5.1.3
6. ICE Considerations
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Author's Address
1. Introduction
[RFC5761] defines how to multiplex RTP and RTCP on a single IP
address and port, referred to as RTP/RTCP multiplexing. [RFC5761]
also defines an SDP [RFC4566] attribute, 'rtcp-mux', that can be used
by entities to indicate support of RTP/RTCP multiplexing and
negotiate usage of it.
As defined in [RFC5761], 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 [RFC3264] 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 [RFC3264] 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 [RFC5761] 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) [RFC8445] considerations when indicating
exclusive support of RTP/RTCP multiplexing.
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. SDP 'rtcp-mux-only' Attribute
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 [RFC5761] 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 [RFC8859] for the 'rtcp-mux-only' attribute is
"IDENTICAL", which means that the attribute, if used within a BUNDLE
group [RFC8843], 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 [RFC5576]).
The SDP offer/answer procedures [RFC3264] associated with the
attribute are defined in Section 4.
4. SDP Offer/Answer Procedures
4.1. General
This section defines the SDP offer/answer procedures [RFC3264] 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).
4.2. Generating the Initial SDP Offer
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 [RFC5761].
If the offerer associates an SDP 'rtcp' attribute [RFC3605] 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.
4.3. Generating the Answer
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 [RFC5761]. 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 [RFC3264].
The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with
an SDP media description ("m=" line) in the answer.
4.4. Offerer Processing of the SDP 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 [RFC5761] 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.
4.5. Modifying the Session
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 [RFC5761].
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.
5. Update to RFC 5761
5.1. General
This section updates Sections 5.1.1 and 5.1.3 of [RFC5761] 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).
5.2. Update to 4th Paragraph of Section 5.1.1
NOTE: [RFC8035] also updates Section 5.1.1 of [RFC5761]. While the
paragraph updated in this document is not updated by [RFC8035], the
location of the paragraph within Section 5.1.1 is moved.
OLD TEXT:
| If the answer does not contain an "a=rtcp-mux" attribute, the
| offerer MUST NOT multiplex RTP and RTCP packets on a single port.
| Instead, it should send and receive RTCP on a port allocated
| according to the usual port-selection rules (either the port pair,
| or a signalled port if the "a=rtcp:" attribute [10] is also
| included). This will occur when talking to a peer that does not
| understand the "a=rtcp-mux" attribute.
NEW TEXT:
| If the answer does not contain an "a=rtcp-mux" attribute, the
| offerer MUST NOT multiplex RTP and RTCP packets on a single port.
| Instead, it should send and receive RTCP on a port allocated
| according to the usual port-selection rules (either the port pair,
| or a signaled port if the "a=rtcp:" attribute [10] is also
| included). This will occur when talking to a peer that does not
| understand the "a=rtcp-mux" attribute. However, if the offerer
| indicated in the offer that it is not able to send and receive
| RTCP on a separate port, the offerer MUST disable the media
| streams associated with the attribute. The mechanism for
| indicating that the offerer is not able to send and receive RTCP
| on a separate port is outside the scope of this specification.
5.3. Update to 2nd Paragraph of Section 5.1.3
OLD TEXT:
| If it is desired to use both ICE and multiplexed RTP and RTCP, the
| initial offer MUST contain an "a=rtcp-mux" attribute to indicate
| that RTP and RTCP multiplexing is desired and MUST contain
| "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:"
| line indicating a fallback port for RTCP in the case that the
| answerer does not support RTP and RTCP multiplexing. This MUST be
| done for each media where RTP and RTCP multiplexing is desired.
NEW TEXT:
| If it is desired to use both ICE and multiplexed RTP and RTCP, the
| initial offer MUST contain an "a=rtcp-mux" attribute to indicate
| that RTP and RTCP multiplexing is desired and MUST contain
| "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:"
| line indicating a fallback port for RTCP in the case that the
| answerer does not support RTP and RTCP multiplexing. This MUST be
| done for each media where RTP and RTCP multiplexing is desired.
| However, if the offerer indicates in the offer that it is not able
| to send and receive RTCP on a separate port, the offerer MUST NOT
| include "a=candidate:" lines for RTCP and MUST NOT provide a
| fallback port for RTCP using the "a=rtcp:" line.
6. ICE Considerations
As defined in [RFC8445], 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.
7. Security Considerations
This document does not introduce new security considerations beyond
those specified in [RFC3605] and [RFC5761].
8. IANA Considerations
This document updates the "Session Description Protocol Parameters"
registry as specified in Section 8.2.4 of [RFC4566]. 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
9. References
9.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>.
[RFC5761] Perkins, C. 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] Holmberg, C., "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] 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>.
[RFC8445] Keranen, A., Holmberg, C., 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] Holmberg, C., Alvestrand, H., 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] Nandakumar, S., "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>.
9.2. Informative References
[RFC3605] Huitema, C., "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] Lennox, J., Ott, J., 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] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
Real-time Communication Between Browsers", W3C Proposed
Recommendation, <https://www.w3.org/TR/webrtc/>.
Acknowledgements
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.
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland
Email: christer.holmberg@ericsson.com
AI ELI5
On this page
§1Why Say 'Multiplexing Only'
RFC 5761 defines how to carry RTP (media) and RTCP (control reports) on a single IP address and port, called RTP/RTCP multiplexing. It also defines the SDP attribute rtcp-mux for offering and negotiating it. If the peer does not support multiplexing, both sides are expected to fall back to separate ports for RTP and RTCP.
Some newer applications do not want that fallback. The RFC gives W3C WebRTC applications as an example, since they are not required to interoperate with non-WebRTC clients. Other reasons come from the network: an endpoint on a radio interface may want different bearers for RTP and RTCP, and a gateway to a network where multiplexing cannot be used would otherwise have to demultiplex RTP and RTCP itself.
The RFC warns that using the new attribute in offers may harm interoperability for any entity that ever has to talk to peers that cannot multiplex.
Most programs can use one shared road or two separate roads. A few can only use the shared one, and this document gives them a way to say so up front.
§3The rtcp-mux-only Attribute
The attribute is named rtcp-mux-only. It has no value, is used at the media level (on an m= line's description), and is not charset dependent. An example is a=rtcp-mux-only.
In an offer, it indicates exclusive support of RTP/RTCP multiplexing for the RTP-based media of that media description. It is defined only for RTP-based media. Using it in an SDP answer is forbidden; in an answer, the plain rtcp-mux attribute says the answerer supports and accepts multiplexing.
Its mux category (from RFC 8859) is IDENTICAL. Inside a BUNDLE group, it must therefore appear on all the multiplexed RTP-based media descriptions. It applies to the whole media description, and it MUST NOT be defined per source with the SDP ssrc attribute.
It is a tiny label with no extra words. An offer can carry it; an answer must never carry it.
§4Offer/Answer Procedures
Initial offer. To indicate exclusive multiplexing, the offerer MUST add rtcp-mux-only to the media description, and MUST also add rtcp-mux to the same description. If it also uses the SDP rtcp attribute, the address and port in it MUST match the ones used for RTP. Using rtcp is not mandated.
Answer. If the answerer accepts multiplexing, it MUST add rtcp-mux. If it does not, it MUST either reject that media description by setting its port to zero or reject the whole offer. The answerer MUST NOT add rtcp-mux-only.
Offerer processing. If the answer has rtcp-mux, the offerer applies the multiplexing procedures of RFC 5761. If not, it MUST either disable the media (for example with a new offer that has a zero port) or send a new offer without rtcp-mux-only.
Later offers. If exclusive multiplexing was already negotiated, the offerer SHOULD keep rtcp-mux-only (with rtcp-mux). Leaving the attributes out means the offerer no longer wants multiplexing and MUST fall back to separate ports once the offer is accepted. If it was not negotiated before, the offerer MAY now offer it. Switching back and forth is RECOMMENDED against unless a use case demands it.
The asker shows the sign and the shared-road label. The other side either agrees by showing the shared-road label, or says no. If it says no, the asker has to give up on that stream or ask again without the sign.
- OfferMedia description has rtcp-mux-only and rtcp-mux.
- Answer with rtcp-muxAccepts; must not include rtcp-mux-only.
- Answer with port 0Rejects the media; the offerer disables it or re-offers without rtcp-mux-only.
§5Update to RFC 5761
This RFC changes two paragraphs of RFC 5761, using OLD and NEW text.
In Section 5.1.1, if the answer has no a=rtcp-mux, the offerer still MUST NOT multiplex and should use separate RTCP ports. The new text adds: if the offerer had indicated in its offer that it cannot send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. How that indication is made is outside the scope of RFC 5761 itself. The text also changes the spelling 'signalled' to 'signaled'. The RFC notes that RFC 8035 also updates this section and moves the paragraph, but does not change it.
In Section 5.1.3, when ICE and multiplexing are both wanted, the offer normally carries candidates for both RTP and RTCP plus an a=rtcp: fallback port. The new text adds that an offerer which cannot use a separate RTCP port MUST NOT include RTCP candidates and MUST NOT give a fallback port in a=rtcp:.
The older rulebook said what to do when the other side says no. This document adds a rule for people who cannot use the backup plan: stop the stream, and do not offer backup roads.
§6ICE Considerations
Under ICE (RFC 8445), an entity that knows the remote peer supports and is willing to use RTP/RTCP multiplexing provides only RTP candidates (component ID 1).
Offering only RTP candidates does not by itself mean exclusive multiplexing, because RTCP candidates are also left out when RTCP is not supported at all. Extra information is therefore needed, and the rtcp-mux-only attribute is that mechanism.
Leaving out the second road on the map could mean 'I only use one road' or 'I do not send reports at all'. The sign removes the doubt.
§7Security and IANA Registration
The RFC introduces no new security considerations beyond those of RFC 3605 and RFC 5761.
IANA registers rtcp-mux-only in the 'Session Description Protocol Parameters' registry as a media-level attribute, not subject to charset, with the purpose 'Indicate exclusive support of RTP/RTCP multiplexing', appropriate values N/A and mux category IDENTICAL.
Adding the sign creates no new danger beyond the ones that already existed. It was also written down in the official list of labels.