RFC 8858

Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)

📅 published January 2021, from ietf

RFC 8858 💖 Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)

Okay bestie, the title block first 🎀. This one is by C. Holmberg from Ericsson, it's Standards Track (so it's an actual Internet standard, not just a vibe), and it's dated January 2021 📅. It updates [RFC5761] 🔥. It doesn't obsolete anything. The ISSN is 2070-1721 🌸.

Abstract ✨

Okay so this doc adds a brand new SDP media-level attribute called rtcp-mux-only 🦋. An endpoint can use it to say "I ONLY do RTP and RTCP multiplexing, no separate ports for me, periodt" 💅. It also updates [RFC5761] by clarifying that an offerer can use a mechanism to say it's not able to send and receive RTCP on separate ports 🫶.

Status of This Memo 🌈

This is an Internet Standards Track document 👑.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚.

For the current status, any errata, and how to give feedback, go to 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they're 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 🦋

Okay so [RFC5761] is the spec that explains how to multiplex RTP and RTCP on a single IP address and port. We call that RTP/RTCP multiplexing 🌸. [RFC5761] also defines an SDP [RFC4566] attribute called rtcp-mux 💖. Entities use it to say they support RTP/RTCP multiplexing and to negotiate whether they'll use it ✨.

As [RFC5761] explains, if the peer endpoint doesn't support RTP/RTCP multiplexing, both endpoints should use separate ports for sending and receiving RTCP. That's called falling back to separate ports for RTP and RTCP 🔄.

Some newer apps don't need backward compatibility with peers that can't multiplex RTCP, so they might decide not to implement separating RTP and RTCP at all 🧚. Examples are the W3C WebRTC applications [WebRTC], which aren't required to interoperate with non-WebRTC clients 🫶. For those apps, this document defines an SDP attribute to signal that they want to require multiplexing 💅. Using this attribute in SDP offers [RFC3264] could mess up interoperability for entities that someday need to talk to peers without RTP/RTCP multiplexing 😭. Also, even if the SDP answerer [RFC3264] supports falling back to nonmultiplexing (and prefers it), the attribute says that fallback can't be enabled 🙈.

Here's a case where nonmultiplexing is preferred: an endpoint is hooked up to a radio interface and wants different bearers (maybe with different quality characteristics) for RTP and RTCP 📡. Another case is when one endpoint acts as a gateway to a network where RTP/RTCP multiplexing can't be used. In that situation, the endpoint may also prefer nonmultiplexing towards the other network 🌉. Otherwise, the endpoint would have to demultiplex RTP and RTCP itself, and nobody wants that extra work 😤.

This document defines a new SDP media-level attribute, rtcp-mux-only, that an endpoint can use to indicate exclusive support of RTP/RTCP multiplexing 👑. It also updates [RFC5761] by clarifying that an offerer can use a mechanism to indicate that it isn't able to send and receive RTCP on separate ports 💜.

This document also covers the Interactive Connectivity Establishment (ICE) [RFC8445] considerations for 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 called 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 rtcp-mux-only to indicate exclusive support of RTP/RTCP multiplexing for the RTP-based media tied to that SDP media description (the "m=" line) 💖.

In an SDP answer, the rtcp-mux attribute [RFC5761] shows that the answerer supports RTP/RTCP multiplexing and accepts using it for the RTP-based media tied to that SDP media description (the "m=" line) 🫶.

Using rtcp-mux-only in an SDP answer is forbidden 🚫.

rtcp-mux-only is only defined for RTP-based media 🎯.

The mux category [RFC8859] for rtcp-mux-only is "IDENTICAL". That means the attribute, if it's used within a BUNDLE group [RFC8843], must be associated with all multiplexed RTP-based media descriptions in that 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] for this 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 its usage 💅.

These procedures apply to individual RTP-based SDP media descriptions (the "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 (the "m=" line) 👑.

Also, if the offerer associates an SDP rtcp-mux-only attribute with an SDP media description (the "m=" line), the offerer MUST also associate an SDP rtcp-mux attribute with that same SDP media description, following the procedures in [RFC5761] 🫶.

If the offerer associates an SDP rtcp attribute [RFC3605] with an SDP media description (the "m=" line), and it also associates an SDP rtcp-mux-only attribute with that same SDP media description, then 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 containing an SDP rtcp-mux-only attribute associated with an RTP-based SDP media description (the "m=" line), then if the answerer accepts 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 doesn't accept RTP/RTCP multiplexing, it MUST either reject that 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 (the "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 (the "m=" line) in an offer, and the corresponding SDP media description (the "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 (the "m=" line) in the associated answer does not contain an SDP rtcp-mux attribute, the offerer MUST either take appropriate actions to disable the associated RTP-based media (for example, send a new offer with a zero port value for that SDP media description (the "m=" line)), or send a new offer without associating an SDP rtcp-mux-only attribute with that SDP media description (the "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 exclusive RTP/RTCP multiplexing for the media tied to an RTP-based SDP media description (the "m=" line), the offerer SHOULD associate an SDP rtcp-mux-only with the corresponding SDP media description (the "m=" line) 🌸.

Also, if the offerer associates an SDP rtcp-mux-only attribute with an SDP media description (the "m=" line), the offerer MUST also associate an SDP rtcp-mux attribute with that same SDP media description, following the procedures in [RFC5761] 💖.

If the offerer doesn't associate those attributes with the corresponding SDP media description (the "m=" line), that's a sign the offerer no longer wants RTP/RTCP multiplexing. In that case it MUST fall back to using 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 RTP/RTCP multiplexing for the media tied to an RTP-based SDP media description (the "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 RTP/RTCP multiplexing and separate ports for RTP and RTCP in a subsequent offer, unless there's a use case that really mandates it 🙏.

5. Update to RFC 5761 🌈

5.1. General 💅

okay so this section is literally updating Sections 5.1.1 and 5.1.3 of [RFC5761] 🦋 It clarifies that an offerer can use a mechanism to say "hey, I can't send and receive RTCP on separate ports," and the offerer shall terminate the affected streams if the answerer doesn't indicate support for RTP/RTCP multiplexing. 😭 Also, when the offerer can't do separate ports, it will NOT provide an SDP 'candidate' attribute for RTCP, and it won't provide a fallback port for RTCP either (using the SDP 'rtcp' attribute). Main character energy, but make it protocol-compliant 💖

Wait, I need to correct that last part: the original says "will not provide", so I'm keeping it lowercase. Here's the faithful version: when the offerer is not able to send and receive RTCP on separate ports, it will not provide an SDP 'candidate' attribute for RTCP, nor will it provide a fallback port for RTCP (using the SDP 'rtcp' attribute). ✨

5.2. Update to 4th Paragraph of Section 5.1.1 🎀

NOTE: heads up, bestie 🫶 [RFC8035] also updates Section 5.1.1 of [RFC5761]. The paragraph updated in this document is not updated by [RFC8035], but its location within Section 5.1.1 has 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 🧊

okay so ICE is the thing that helps peers find each other through NATs, right? 💅 As defined in [RFC8445], if an entity knows the remote peer supports RTP/RTCP multiplexing and is willing to use it, the entity will only provide RTP candidates (component ID 1). 🎀 BUT, and this is the tea ☕, only providing RTP candidates does not, by itself, mean the peer exclusively supports RTP/RTCP multiplexing. RTCP candidates also wouldn't be provided in cases where RTCP isn't supported at all, so you can't tell from that alone. 🙈 That's why extra info is needed to indicate exclusive RTP/RTCP multiplexing support, and this document defines that 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]. 😤 Nothing new is being added to the security list here, so the security notes in those two documents are the ones to keep in mind. Take them seriously, bestie 💜

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. 🦋 Here's the registration template:

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
📦 where this page comes from