RFC 9143

Negotiating Media Multiplexing Using the Session Description Protocol (SDP)

📅 published February 2022, from ietf

Okay bestie, welcome to RFC 9143! 🎀 This one is the big BUNDLE spec, and it's giving "we're all sharing one vibe" energy. ✨

Quick tea on the title block: this is RFC 9143, titled Negotiating Media Multiplexing Using the Session Description Protocol (SDP), published in February 2022. The authors are C. Holmberg from Ericsson, H. Alvestrand from Google, and C. Jennings from Cisco. It's a Standards Track document, so it's a real, official Internet standard 💅 and it's part of the IETF stream with ISSN 2070-1721. It obsoletes RFC 8843 and updates RFC 3264, RFC 5888, and RFC 7941. So if you're reading 8843, you're reading old news now 💀.

Abstract ✨

Okay so the big idea is a new SDP Grouping Framework extension called 'BUNDLE' 🦋. It lets the offer/answer mechanism agree that one single transport (a 5-tuple) can carry media for a bunch of SDP media descriptions ("m=" sections) at the same time. That shared transport is the "BUNDLE transport", the media riding on it is "bundled media", and all the "m=" sections sharing it form a BUNDLE group. Main character energy, literally 👑.

The spec also brings a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension 🌸. And yep, it updates RFCs 3264, 5888, and 7941, and obsoletes RFC 8843 🍓.

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want the scoop on Internet Standards, check Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, the info lives at https://www.rfc-editor.org/info/rfc9143 🧚.

Copyright Notice

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, since they spell out your rights and restrictions with respect to this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 🙈.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. Without getting an adequate license from whoever controls the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.

   1.  Introduction
     1.1.  Background
     1.2.  BUNDLE Mechanism
     1.3.  Protocol Extensions
     1.4.  Changes from RFC 8843
   2.  Terminology
   3.  Conventions
   4.  Applicability Statement
   5.  SDP Grouping Framework BUNDLE Extension
   6.  SDP 'bundle-only' Attribute
   7.  SDP Offer/Answer Procedures
     7.1.  Generic SDP Considerations
       7.1.1.  Connection Data ("c=")
       7.1.2.  Bandwidth ("b=")
       7.1.3.  Attributes ("a=")
     7.2.  Generating the Initial BUNDLE Offer
       7.2.1.  Suggesting the Offerer-Tagged "m=" Section
       7.2.2.  Example: Initial BUNDLE Offer
     7.3.  Generating the SDP Answer
       7.3.1.  Answerer Selection of Tagged "m=" Sections
       7.3.2.  Moving a Media Description Out of a BUNDLE Group
       7.3.3.  Rejecting a Media Description in a BUNDLE Group
       7.3.4.  Example: SDP Answer
       7.3.5.  RFC 8843 Considerations
     7.4.  Offerer Processing of the SDP Answer
       7.4.1.  RFC 8843 Considerations
     7.5.  Modifying the Session
       7.5.1.  Adding a Media Description to a BUNDLE Group
       7.5.2.  Moving a Media Description Out of a BUNDLE Group
       7.5.3.  Disabling a Media Description in a BUNDLE Group
     7.6.  3PCC Considerations
   8.  Protocol Identification
     8.1.  STUN, DTLS, and SRTP
   9.  RTP Considerations
     9.1.  Single RTP Session
       9.1.1.  Payload Type (PT) Value Reuse
     9.2.  Associating RTP/RTCP Streams with the Correct SDP Media
           Description
     9.3.  RTP/RTCP Multiplexing
       9.3.1.  SDP Offer/Answer Procedures
   10. ICE Considerations
   11. DTLS Considerations
   12. RTP Header Extensions Consideration
   13. Updates to RFC 3264
     13.1.  Original Text from RFC 3264, Section 5.1, Paragraph 2
     13.2.  New Text Replacing RFC 3264, Section 5.1, Paragraph 2
     13.3.  Original Text from RFC 3264, Section 8.4, Paragraph 6
     13.4.  New Text Replacing RFC 3264, Section 8.4, Paragraph 6
   14. Update to RFC 5888
     14.1.  Original Text from RFC 5888, Section 9.2, Paragraph 3
     14.2.  New Text Replacing RFC 5888, Section 9.2, Paragraph 3
   15. RTP/RTCP Extensions for identification-tag Transport
     15.1.  RTCP MID SDES Item
     15.2.  RTP SDES Header Extension for MID
   16. IANA Considerations
     16.1.  SDES Item
     16.2.  RTP SDES Header Extension URI
     16.3.  SDP Attribute
     16.4.  SDP Group Semantics
   17. Security Considerations
   18. Examples
     18.1.  Example: Tagged "m=" Section Selections
     18.2.  Example: BUNDLE Group Rejected
     18.3.  Example: Offerer Adds a Media Description to a BUNDLE
            Group
     18.4.  Example: Offerer Moves a Media Description Out of a BUNDLE
            Group
     18.5.  Example: Offerer Disables a Media Description within a
            BUNDLE Group
   19. References
     19.1.  Normative References
     19.2.  Informative References
   Appendix A.  Design Considerations
     A.1.  UA Interoperability
     A.2.  Usage of Port Number Value Zero
     A.3.  B2BUA and Proxy Interoperability
       A.3.1.  Traffic Policing
       A.3.2.  Bandwidth Allocation
     A.4.  Candidate Gathering
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

1.1. Background

Okay so, when the SDP offer/answer mechanism [RFC3264] is used to set up multimedia sessions, every individual media stream that gets its own separate transport (5-tuple) costs extra resources 😭. That gets especially expensive when Interactive Connectivity Establishment (ICE) [RFC8445] is in the mix. So it's super attractive to squeeze multiple media streams through a single transport 🫶.

1.2. BUNDLE Mechanism

This spec defines a way to use one transport (the BUNDLE transport) to send and receive media (the bundled media) described by several SDP media descriptions ("m=" sections) 🦋. The address:port combo an endpoint uses for sending and receiving bundled media is called the "BUNDLE address:port". The set of SDP attributes applied to each "m=" section in a BUNDLE group is called "BUNDLE attributes". The same BUNDLE transport handles both sending and receiving bundled media, which means the symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is always used for RTP-based bundled media 💖.

This spec defines a new SDP Grouping Framework [RFC5888] extension called 'BUNDLE'. It can be used with the Session Description Protocol (SDP) offer/answer mechanism [RFC3264] to negotiate which "m=" sections become part of a BUNDLE group. On top of that, the offerer and answerer [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUNDLE address:port) and the set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that get applied to each "m=" section in the BUNDLE group 💅.

Using a BUNDLE transport means you get a single set of ICE candidates [RFC8445] for the whole BUNDLE group 🌸.

A given BUNDLE address:port MUST only be associated with a single BUNDLE group. If an SDP offer or SDP answer (hereafter called "offer" and "answer") has multiple BUNDLE groups, the procedures in this spec apply to each group independently 🔥. All RTP-based bundled media tied to a given BUNDLE group belongs to a single RTP session [RFC3550] 👑.

BUNDLE is backward compatible, which is iconic 🌈. Endpoints that don't support the extension are expected to generate offers and answers without an SDP 'group:BUNDLE' attribute, and to give each "m=" section in an offer and answer its own unique address:port, following the procedures in [RFC3264] and [RFC4566] ✨.

1.3. Protocol Extensions

Besides the new SDP Grouping Framework extension, this spec defines some extra protocol extensions and makes some updates to other RFCs. Here's the lineup 🧚:

defines a new SDP attribute, 'bundle-only', which can be used to request that a specific "m=" section (and the associated media) only be used if it's kept within a BUNDLE group.
updates RFC 3264 [RFC3264] to also allow assigning a zero port value to an "m=" section when the media described by that "m=" section is not disabled or rejected.
defines a new RTCP [RFC3550] SDES item, Media Identification ('MID'), and a new RTP SDES header extension that can be used to associate RTP streams with "m=" sections 💜.
updates [RFC7941] by adding an exception, for the MID RTP header extension, to the requirement about protecting an SDES RTP header extension that carries an SDES item for the MID RTP header extension 🙈.
updates [RFC5888] by allowing an SDP 'group' attribute to contain an identification-tag that identifies an "m=" section whose port value is set to zero 🍓.

1.4. Changes from RFC 8843

So when [RFC8843] and [RFC8829] came out, the specs were inconsistent with each other 💀. The procedures for assigning the port value to a bundled "m=" section in an answer (initial or subsequent) and in a later offer didn't match up. This spec fixes that by lining up the port value assignment procedure with the one in [RFC8829] 🫶.

On top of that, this document implements changes from the following errata reports: [Err6431], [Err6437] 🎀.

2. Terminology ✨

okay bestie, let's get our vocab straight because this section is where all the BUNDLE lingo lives 💅

"m=" section: An SDP body holds one or more media descriptions, and each one is called an "m=" section 🎀. Each "m=" section is made of an SDP "m=" line plus zero or more SDP attributes attached to that line. Every "m=" section gets its own local address:port combination.
5-tuple: A bundle of five values: source address, source port, destination address, destination port, and transport-layer protocol 🦋.
Unique address:port: An address:port combination that belongs to exactly one "m=" section in an offer or answer. No sharing allowed 🙅‍♀️.
Offerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an offer 💜.
Answerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an answer 💜.
Suggested offerer-tagged "m=" section: The bundled "m=" section that the offerer BUNDLE-tag points to in an initial BUNDLE offer, before a BUNDLE group has been negotiated. It's the offerer being like "hey, what about this one?" 🌸
Offerer-tagged "m=" section: The bundled "m=" section that the offerer BUNDLE-tag points to in a subsequent offer. This one carries the offerer BUNDLE address:port and offerer BUNDLE attributes, which get applied to every "m=" section in the BUNDLE group 🧚.
Answerer-tagged "m=" section: The bundled "m=" section that the answerer BUNDLE-tag points to in an answer (initial BUNDLE answer or subsequent). It carries the answerer BUNDLE address:port and answerer BUNDLE attributes, and those get applied to every "m=" section in the BUNDLE group 🍓.
BUNDLE address:port: An address:port combination that an endpoint uses for sending and receiving bundled media 🎀.
Offerer BUNDLE address:port: The address:port combination the offerer uses for sending and receiving media 🦋.
Answerer BUNDLE address:port: The address:port combination the answerer uses for sending and receiving media 🦋.
BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes. Once a BUNDLE group exists, these attribute values apply to every bundled "m=" section in that group ✨.
Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the offerer-tagged "m=" section 💖.
Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the answerer-tagged "m=" section 💖.
BUNDLE transport: The transport (5-tuple) used by all media described by the "m=" sections inside a BUNDLE group 🌈.
BUNDLE group: A set of bundled "m=" sections, created through an SDP offer/answer exchange. It uses one BUNDLE transport and one set of BUNDLE attributes to send and receive all the media (bundled media) that those "m=" sections describe. The same BUNDLE transport is used for sending and receiving bundled media. Main character energy 👑.
Bundled "m=" section: An "m=" section whose identification-tag shows up in an SDP 'group:BUNDLE' attribute identification-tag list in an offer or answer 🫶.
Bundle-only "m=" section: A bundled "m=" section that contains an SDP 'bundle-only' attribute 🙈.
Bundled media: All the media tied to a given BUNDLE group 🎶.
Initial BUNDLE offer: The first offer inside an SDP session (for example, a SIP dialog when SIP [RFC3261] is used to carry SDP) where the offerer says it wants to negotiate a given BUNDLE group. The "hey, let's bundle!" moment 🌸.
Initial BUNDLE answer: The answer to an initial BUNDLE offer where the offerer wants to negotiate a BUNDLE group and the answerer says yes to creating it. The BUNDLE group only gets created once the answerer sends the initial BUNDLE answer 💅.
Subsequent offer: An offer that contains a BUNDLE group already created in a previous offer/answer exchange 🔥.
Subsequent answer: An answer to a subsequent offer 🔥.
Identification-tag: A unique token value that identifies an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section carries the unique identification-tag assigned to that "m=" section. The session-level SDP 'group' attribute [RFC5888] carries a list of identification-tags, naming the "m=" sections associated with that particular 'group' attribute 🏷️.

3. Conventions

okay so this section is the official "how to read the capital letters" rule 🙈 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. Only the all-caps versions count, no cap 💀.

4. Applicability Statement

the vibe check on where this spec even applies 🧐 The mechanism in this specification only applies to SDP [RFC4566], when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope of this document and is thus undefined. So if you're doing declarative SDP, this doc is not your playground 🚫.

5. SDP Grouping Framework BUNDLE Extension

this is where the BUNDLE extension officially shows up 🎀 This section defines a new SDP Grouping Framework [RFC5888] extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP offer/answer mechanism to negotiate a set of "m=" sections that will become part of a BUNDLE group. Inside a BUNDLE group, each "m=" section uses a BUNDLE transport for sending and receiving bundled media. Each endpoint uses a single address:port combination for sending and receiving the bundled media, which is giving very "one door for everyone" energy 🚪✨.

The BUNDLE extension is indicated using an SDP 'group' attribute with a semantics value [RFC5888] of "BUNDLE". Each bundled "m=" section gets an identification-tag, and each identification-tag gets listed in the SDP 'group:BUNDLE' attribute identification-tag list. Any "m=" section whose identification-tag is in that list belongs to the given BUNDLE group 🧚.

SDP bodies can hold multiple BUNDLE groups 🌈. Any given bundled "m=" section MUST NOT be associated with more than one BUNDLE group at any given time. No double-dipping, periodt 🙅‍♀️.

NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' attribute identification-tag list does not have to be the same as the order in which the "m=" sections occur in the SDP.

The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute is 'NORMAL' 💜.

Section 7 defines the detailed SDP offer/answer procedures for the BUNDLE extension. Go check it out, it's the juicy part 💅.

6. SDP 'bundle-only' Attribute

this section introduces a brand new SDP media-level attribute [RFC4566] called 'bundle-only' 🦋 'bundle-only' is a property attribute [RFC4566]; hence, it has no value. Property attribute, no value, got it ✨.

So here's the tea. To make sure an answerer that doesn't support the BUNDLE extension always rejects a bundled "m=" section in an offer, the offerer can give that "m=" section a zero port value. According to [RFC3264], an answerer will reject an "m=" section like that. Now, if the offerer puts an SDP 'bundle-only' attribute in a bundled "m=" section, the offerer can request that the answerer accepts the "m=" section only if the answerer supports the BUNDLE extension and keeps the "m=" section inside the associated BUNDLE group. Clever, right? 🧠🎀

Here's the registration info, copied exactly:

Name:  bundle-only

Value:  N/A

Usage Level:  media

Charset Dependent:  no

Example:  a=bundle-only

The usage of the 'bundle-only' attribute is only defined for a bundled "m=" section with a zero port value. Any other usage is unspecified 🤷‍♀️. If an offerer or answerer receives a 'bundle-only' attribute in a non-bundled "m=" section, the offerer or answerer MUST discard the attribute. Bye bye, attribute 👋.

Section 7 defines the detailed SDP offer/answer procedures for the 'bundle-only' attribute too 💖.

7. SDP Offer/Answer Procedures

this is the big one, the full offer/answer choreography 💃 This section describes the SDP offer/answer [RFC3264] procedures for:

Negotiating a BUNDLE group;
Suggesting and selecting the tagged "m=" sections (offerer-tagged "m=" section and answerer-tagged "m=" section);
Adding an "m=" section to a BUNDLE group;
Moving an "m=" section out of a BUNDLE group; and
Disabling an "m=" section within a BUNDLE group.

The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension 🫶. For example, if an offer is rejected by the answerer, the previously negotiated addresses:ports, SDP parameters, and characteristics (including those associated with a BUNDLE group) still apply. So if an offerer makes an offer to negotiate a BUNDLE group and the answerer rejects it, the BUNDLE group is not created. Rejected means no group, bestie 💀.

The procedures in this section are independent of the media type or "m=" line proto value assigned to a bundled "m=" section. Section 6 has extra considerations for the SDP 'bundle-only' attribute. Section 9 has extra considerations for RTP-based media. Section 10 has extra considerations for using the ICE mechanism [RFC8445] 🧊.

Offers and answers can contain multiple BUNDLE groups 🌈. The procedures in this section apply independently to each BUNDLE group. Each group gets its own little spotlight ✨.

7.1. Generic SDP Considerations

this part is all about the generic restrictions on SDP parameters inside a BUNDLE group 🎀 It also covers how to work out a value for the whole BUNDLE group when each bundled "m=" section has its own parameter and attribute values.

7.1.1. Connection Data ("c=")

The "c=" line nettype value [RFC4566] for a bundled "m=" section MUST be 'IN' 🌐.

The "c=" line addrtype value [RFC4566] for a bundled "m=" section MUST be 'IP4' or 'IP6'. The same value MUST be used for each "m=" section 💜.

NOTE: Extensions to this specification can specify usage of the BUNDLE mechanism for other nettype and addrtype values than the ones listed above. Future-proofing, but make it make sense 🔮.

7.1.2. Bandwidth ("b=")

An offerer and answerer MUST use the rules and restrictions defined in [RFC8859] for associating the SDP bandwidth ("b=") line with bundled "m=" sections. Follow the rules, slay 👑💅.

7.1.3. Attributes ("a=") 💅

okay so attributes, the vibe check for every bundled "m=" section 🫶 An offerer and answerer MUST include SDP attributes in every bundled "m=" section where applicable, following the normal offer/answer procedures for each attribute, with the following exceptions:

In the initial BUNDLE offer, the offerer MUST NOT include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) in bundle-only "m=" sections. The offerer MUST include such attributes in all other bundled "m=" sections. In the initial BUNDLE offer, each bundled "m=" line can contain a different set of BUNDLE attributes and attribute values. Once the offerer-tagged "m=" section has been selected, the BUNDLE attributes contained in the offerer-tagged "m=" section will apply to each bundled "m=" section within the BUNDLE group. 🎀
In a subsequent offer or in an answer (initial or subsequent), the offerer and answerer MUST include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) only in the tagged "m=" section (offerer-tagged "m=" section or answerer-tagged "m=" section). The offerer and answerer MUST NOT include such attributes in any other bundled "m=" section. The BUNDLE attributes contained in the tagged "m=" section will apply to each bundled "m=" section within the BUNDLE group. 🦋
In an offer (initial BUNDLE offer or subsequent) or in an answer (initial BUNDLE answer or subsequent), the offerer and answerer MUST include SDP attributes from categories other than IDENTICAL and TRANSPORT in each bundled "m=" section that a given attribute applies to. Each bundled "m=" line can contain a different set of such attributes and attribute values, as such attributes only apply to the given bundled "m=" section in which they are included. 🌸

NOTE: A consequence of the rules above is that media-specific IDENTICAL and TRANSPORT multiplexing category SDP attributes that are applicable only to some of the bundled "m=" sections within the BUNDLE group might appear in the tagged "m=" section for which they are not applicable. For instance, the tagged "m=" section might contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section does not describe RTP-based media (but another bundled "m=" section within the BUNDLE group does describe RTP-based media). 🙈

7.2. Generating the Initial BUNDLE Offer 🎬

The procedures in this section apply to the first offer within an SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP) in which the offerer indicates that it wants to negotiate a given BUNDLE group. This could occur in the initial offer, or in a subsequent offer, of the SDP session.

When an offerer generates an initial BUNDLE offer, in order to negotiate a BUNDLE group, it MUST:

Assign a unique address:port to each bundled "m=" section following the procedures in [RFC3264], excluding any bundle-only "m=" sections (see below);
Pick a bundled "m=" section as the suggested offerer-tagged "m=" (Section 7.2.1);
Include SDP attributes in the bundled "m=" sections following the rules in Section 7.1.3;
Include an SDP 'group:BUNDLE' attribute in the offer; and
Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the suggested offerer-tagged "m=" section.

NOTE: When the offerer assigns unique addresses:ports to multiple bundled "m=" sections, the offerer needs to be prepared to receive bundled media on each unique address:port until it receives the associated answer and finds out which bundled "m=" section (and associated address:port combination) the answerer has selected as the offerer-tagged "m=" section.

If the offerer wants to request that the answerer accept a given bundled "m=" section only if the answerer keeps the "m=" section within the negotiated BUNDLE group, the offerer MUST:

Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" section, and
Assign a zero port value to the "m=" section.

NOTE: If the offerer assigns a zero port value to a bundled "m=" section but does not include an SDP 'bundle-only' attribute in the "m=" section, it is an indication that the offerer wants to disable the "m=" section (Section 7.5.3).

Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. ✨

7.2.1. Suggesting the Offerer-Tagged "m=" Section 🏷️

In the initial BUNDLE offer, the bundled "m=" section indicated by the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled media if the answerer selects the "m=" section as the offerer-tagged "m=" section (Section 7.3.1). In addition, if the answerer selects the "m=" section as the offerer-tagged "m=" section, the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group.

The offerer MUST NOT suggest a bundle-only "m=" section as the offerer-tagged "m=" section.

It is RECOMMENDED that the suggested offerer-tagged "m=" section be a bundled "m=" section which the offerer believes is unlikely to be rejected or moved out of the BUNDLE group by the answerer. How such an assumption is made is outside the scope of this document. 🤞

7.2.2. Example: Initial BUNDLE Offer 🍓

The following example shows an initial BUNDLE offer. The offer includes two "m=" sections in the offer and suggests that both "m=" sections be included in a BUNDLE group. The audio "m=" section is the suggested offerer-tagged "m=" section, indicated by placing the identification-tag associated with the "m=" section (offerer BUNDLE-tag) first in the SDP 'group:BUNDLE' attribute identification-id list.

SDP Offer

  v=0
  o=alice 2890844526 2890844526 IN IP6 2001:db8::3
  s=
  c=IN IP6 2001:db8::3
  t=0 0
  a=group:BUNDLE foo bar

  m=audio 10000 RTP/AVP 0 8 97
  b=AS:200
  a=mid:foo
  a=rtcp-mux
  a=rtpmap:0 PCMU/8000
  a=rtpmap:8 PCMA/8000
  a=rtpmap:97 iLBC/8000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

  m=video 10002 RTP/AVP 31 32
  b=AS:1000
  a=mid:bar
  a=rtcp-mux
  a=rtpmap:31 H261/90000
  a=rtpmap:32 MPV/90000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

The following example shows an initial BUNDLE offer. The offer includes two "m=" sections in the offer and suggests that both "m=" sections are included in a BUNDLE group. The offerer includes an SDP 'bundle-only' attribute in the video "m=" section to request that the answerer accept the "m=" section only if the answerer supports the BUNDLE extension and if the answerer keeps the "m=" section within the associated BUNDLE group. The audio "m=" section is the suggested offerer-tagged "m=" section, indicated by placing the identification-tag associated with the "m=" section (offerer BUNDLE-tag) first in the SDP 'group:BUNDLE' attribute identification-id list.

SDP Offer

  v=0
  o=alice 2890844526 2890844526 IN IP6 2001:db8::3
  s=
  c=IN IP6 2001:db8::3
  t=0 0
  a=group:BUNDLE foo bar

  m=audio 10000 RTP/AVP 0 8 97
  b=AS:200
  a=mid:foo
  a=rtcp-mux
  a=rtpmap:0 PCMU/8000
  a=rtpmap:8 PCMA/8000
  a=rtpmap:97 iLBC/8000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

  m=video 0 RTP/AVP 31 32
  b=AS:1000
  a=mid:bar
  a=bundle-only
  a=rtpmap:31 H261/90000
  a=rtpmap:32 MPV/90000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

7.3. Generating the SDP Answer 🎀

When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, the following general SDP Grouping Framework restrictions, defined in [RFC5888], also apply to the BUNDLE group:

The answerer is only allowed to include a BUNDLE group in an initial BUNDLE answer if the offerer requested the BUNDLE group to be created in the corresponding initial BUNDLE offer;
The answerer is only allowed to include a BUNDLE group in a subsequent answer if the corresponding subsequent offer contains a previously negotiated BUNDLE group;
The answerer is only allowed to include a bundled "m=" section in an answer if the "m=" section was indicated as bundled in the corresponding offer; and
The answerer is only allowed to include a bundled "m=" section in the same BUNDLE group as the bundled "m=" line in the corresponding offer.

In addition, when an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, the answerer MUST:

In case of an initial BUNDLE answer, select the offerer-tagged "m=" section using the procedures in Section 7.3.1. In case of a subsequent answer, the offerer-tagged "m=" section is indicated in the corresponding subsequent offer and MUST NOT be changed by the answerer;
Select the answerer-tagged "m=" section (Section 7.3.1);
Assign the answerer BUNDLE address:port to the answerer-tagged "m=" section and to every other bundled "m=" section within the BUNDLE group;
Include SDP attributes in the bundled "m=" sections following the rules in Section 7.1.3;
Include an SDP 'group:BUNDLE' attribute in the answer; and
Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag indicates the answerer-tagged "m=" section (Section 7.3.1).

If the answerer does not want to keep an "m=" section within a BUNDLE group, it MUST:

Move the "m=" section out of the BUNDLE group (Section 7.3.2); or
Reject the "m=" section (Section 7.3.3).

The answerer can modify the answerer BUNDLE address:port, add and remove SDP attributes, or modify SDP attribute values in a subsequent answer. Changes to the answerer BUNDLE address:port and the answerer BUNDLE attributes will be applied to each bundled "m=" section within the BUNDLE group. 🌈

NOTE: If a bundled "m=" section in an offer contains a zero port value, but the "m=" section does not contain an SDP 'bundle-only' attribute, it is an indication that the offerer wants to disable the "m=" section (Section 7.5.3).

7.3.1. Answerer Selection of Tagged "m=" Sections ✨

okay so when the answerer is picking the offerer-tagged "m=" section, it MUST first check whether that "m=" section passes these checks (Section 7.2.1) 💅:

The answerer will not move the "m=" section out of the BUNDLE group (Section 7.3.2);
The answerer will not reject the "m=" section (Section 7.3.3); and
The "m=" section does not contain a zero port value.

if all of those pass, the answerer MUST select that "m=" section as the offerer-tagged "m=" section 🎀 and MUST also mark the matching "m=" section in the answer as the answerer-tagged "m=" section. in the answer, the answerer BUNDLE-tag points at the answerer-tagged "m=" section.

if one or more checks fail, the answerer MUST pick the next identification-tag in the identification-tag list in the offer and run the same checks on the "m=" section that tag points to 🔁. if there are no more identification-tags left, the answerer MUST NOT create the BUNDLE group 💀. also, unless the answerer rejects the whole offer, the answerer MUST apply the answerer procedures for moving an "m=" section out of a BUNDLE group (Section 7.3.2) or rejecting an "m=" section within a BUNDLE group (Section 7.3.3) to every bundled "m=" section in the offer when it creates the answer.

Section 18.1 has an example of an offerer BUNDLE address:port selection 🦋.

Sections 7.3.4 and 18.1 show examples of answerer-tagged "m=" section selection 🧚.

7.3.2. Moving a Media Description Out of a BUNDLE Group 🌸

when an answerer generates the answer, it MUST first check these criteria if it wants to move a bundled "m=" section out of the negotiated BUNDLE group:

In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group, and
In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute.

if either criterion above is fulfilled, the answerer cannot move that "m=" section out of the BUNDLE group in the answer 🙅‍♀️. the answerer can reject the whole offer, reject each bundled "m=" section within the BUNDLE group (Section 7.3.3), or keep the "m=" section in the BUNDLE group in the answer and later make an offer where that "m=" section gets moved out of the BUNDLE group (Section 7.5.2).

NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section cannot be moved out of the BUNDLE group in an answer. Instead, an offer is needed. 😭

when the answerer makes an answer that moves a bundled "m=" section out of a BUNDLE group, the answerer:

MUST assign a unique address:port to the "m=" section;
MUST include any applicable SDP attribute in the "m=" section using the normal offer/answer procedures for each attribute;
MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and
MUST NOT include an SDP 'bundle-only' attribute in the "m=" section.

because an answerer isn't allowed to move an "m=" section from one BUNDLE group to another within an answer (Section 7.3), if the answerer wants to move an "m=" section from one BUNDLE group to a different one, it MUST first move the "m=" section out of the current BUNDLE group and then make an offer where the "m=" section is added to the other BUNDLE group (Section 7.5.1) 🔄✨.

7.3.3. Rejecting a Media Description in a BUNDLE Group 🚫

when an answerer wants to reject a bundled "m=" section in an answer, it MUST first check this criterion:

In the corresponding offer (subsequent), the "m=" section is the offerer-tagged "m=" section.

if that criterion is fulfilled, the answerer cannot reject the "m=" section in the answer 🥺. the answerer can reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or keep the "m=" section in the BUNDLE group in the answer and later make an offer where the "m=" section is disabled within the BUNDLE group (Section 7.5.3).

when an answerer makes an answer that rejects a bundled "m=" section, the answerer:

MUST assign a zero port value to the "m=" section, following the procedures in [RFC3264];
MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and
MUST NOT include an SDP 'bundle-only' attribute in the "m=" section.

7.3.4. Example: SDP Answer 🎀

this example shows an answer based on the corresponding offer in Section 7.2.2 💖. the answerer accepts both bundled "m=" sections within the BUNDLE group it created. the audio "m=" section is the answerer-tagged "m=" section, which you can tell because its identification-tag (the answerer BUNDLE-tag) comes first in the SDP 'group:BUNDLE' attribute identification-id list 👑.

SDP Answer

  v=0
  o=bob 2808844564 2808844564 IN IP6 2001:db8::1
  s=
  c=IN IP6 2001:db8::1
  t=0 0
  a=group:BUNDLE foo bar

  m=audio 20000 RTP/AVP 0
  b=AS:200
  a=mid:foo
  a=rtcp-mux
  a=rtpmap:0 PCMU/8000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

  m=video 20000 RTP/AVP 32
  b=AS:1000
  a=mid:bar
  a=rtpmap:32 MPV/90000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

7.3.5. RFC 8843 Considerations 🕰️

in [RFC8843], the offerer didn't give the offerer BUNDLE address:port to every "m=" section in the BUNDLE group when it modified the session (Section 7.5). instead, it only gave the offerer BUNDLE address:port to the offerer-tagged "m=" section. every other "m=" section in the BUNDLE group got an SDP 'bundle-only' attribute and a zero port value 🧸. how an answerer that follows this specification handles that kind of offer is considered an implementation issue (for example, based on whether the answerer needs to stay backward compatible with offerers that follow [RFC8843]), and it's outside the scope of this specification 🤷‍♀️. the example below shows that kind of SDP Offer:

SDP Offer

  v=0
  o=alice 2890844526 2890844526 IN IP6 2001:db8::3
  s=
  c=IN IP6 2001:db8::3
  t=0 0
  a=group:BUNDLE foo bar

  m=audio 10000 RTP/AVP 0 8 97
  b=AS:200
  a=mid:foo
  a=rtcp-mux
  a=rtpmap:0 PCMU/8000
  a=rtpmap:8 PCMA/8000
  a=rtpmap:97 iLBC/8000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

  m=video 0 RTP/AVP 31 32
  b=AS:1000
  a=mid:bar
  a=bundle-only
  a=rtpmap:31 H261/90000
  a=rtpmap:32 MPV/90000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

7.4. Offerer Processing of the SDP Answer 📨

when an offerer gets an answer that contains a BUNDLE group, the offerer MUST check that every bundled "m=" section in the answer was marked as bundled in the corresponding offer (for the same BUNDLE group) 🔍. if nothing mismatches, the offerer MUST apply the properties (BUNDLE address:port, BUNDLE attributes, and so on) of the offerer-tagged "m=" section (the one the answerer selected; see Section 7.3.1) to every bundled "m=" section within the BUNDLE group 💅.

NOTE: The answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer, or move a bundled "m=" section out of a BUNDLE group. Because of that, a given bundled "m=" section in the offer might not be marked as bundled in the corresponding answer. 🙈

if the answer doesn't contain a BUNDLE group, the offerer MUST process the answer as a normal answer 🌈.

7.4.1. RFC 8843 Considerations 🦋

in [RFC8843], the answerer didn't give the answerer BUNDLE address:port to every "m=" section in the BUNDLE group when it generated the SDP Answer (Section 7.3). it only gave the answerer BUNDLE address:port to the answerer-tagged "m=" section. every other "m=" section in the BUNDLE group got an SDP 'bundle-only' attribute and a zero port value 🍓. how an offerer that follows this specification handles that kind of SDP Answer is considered an implementation issue (for example, based on whether the answerer needs to stay backward compatible with offerers that follow [RFC8843]), and it's outside the scope of this specification 🫶. the example below shows that kind of SDP Answer:

SDP Answer

  v=0
  o=bob 2808844564 2808844564 IN IP6 2001:db8::1
  s=
  c=IN IP6 2001:db8::1
  t=0 0
  a=group:BUNDLE foo bar

  m=audio 20000 RTP/AVP 0
  b=AS:200
  a=mid:foo
  a=rtcp-mux
  a=rtpmap:0 PCMU/8000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

  m=video 0 RTP/AVP 32
  b=AS:1000
  a=mid:bar
  a=bundle-only
  a=rtpmap:32 MPV/90000
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

7.5. Modifying the Session 🔧

when a BUNDLE group was negotiated earlier and an offerer makes a subsequent offer, the offerer MUST:

Pick one bundled "m=" section as the offerer-tagged "m=" section. The offerer can pick either the "m=" section the answerer previously selected as the offerer-tagged "m=" section, or another bundled "m=" section within the BUNDLE group 👑;
Assign a BUNDLE address:port (either previously negotiated or newly suggested) to the offerer-tagged "m=" section and to every other bundled "m=" section within the BUNDLE group;
Include SDP attributes in the bundled "m=" sections following the rules in Section 7.1.3;
Include an SDP 'group:BUNDLE' attribute in the offer; and
Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the offerer-tagged "m=" section.

the offerer MUST NOT pick a given bundled "m=" section as the offerer-tagged "m=" section if:

The offerer wants to move the "m=" section out of the BUNDLE group (Section 7.5.2), or
The offerer wants to disable the "m=" section (Section 7.5.3).

the offerer can change the offerer BUNDLE address:port, add and remove SDP attributes, or change SDP attribute values in the subsequent offer ✨. changes to the offerer BUNDLE address:port and the offerer BUNDLE attributes will (if the answerer accepts the offer) be applied to every bundled "m=" section within the BUNDLE group 🎉.

7.5.1. Adding a Media Description to a BUNDLE Group 🫧

when an offerer makes a subsequent offer where it wants to add a bundled "m=" section to a BUNDLE group that was negotiated earlier, the offerer follows the procedures in Section 7.5 🧚‍♀️. the offerer picks either the added "m=" section or an "m=" section that was already added to the BUNDLE group as the offerer-tagged "m=" section.

NOTE: As described in Section 7.3.2, the answerer cannot move the added "m=" section out of the BUNDLE group in its answer. If the answerer wants to move the "m=" section out of the BUNDLE group, it will have to accept it into the BUNDLE group in the answer first, and then send a subsequent offer where the "m=" section is moved out of the BUNDLE group (Section 7.5.2) 💀✨.

7.5.2. Moving a Media Description Out of a BUNDLE Group 🦋

okay so, when an offerer whips up a subsequent offer and wants to kick a bundled "m=" section out of a BUNDLE group, there's a checklist 💅:

the offerer MUST assign a unique address:port to the "m=" section;
the offerer MUST include SDP attributes in the "m=" section following the normal offer/answer rules for each attribute;
the offerer MUST NOT place the identification-tag associated with the "m=" section in the SDP group:BUNDLE attribute identification-tag list associated with the BUNDLE group; and
the offerer MUST NOT assign an SDP bundle-only attribute to the "m=" section.

For the other bundled "m=" sections in the BUNDLE group, the offerer just follows the procedures in Section 7.5 🫶.

An offerer MUST NOT move an "m=" section from one BUNDLE group to another within a single offer. 🙈 If the offerer wants to move an "m=" section to a different BUNDLE group, it MUST first move the BUNDLE group out of the current BUNDLE group, and then generate a second offer where the "m=" section is added to another BUNDLE group (Section 7.5.1). no shortcuts, bestie.

Section 18.4 has an example of an offer for moving an "m=" section out of a BUNDLE group ✨.

7.5.3. Disabling a Media Description in a BUNDLE Group 💖

when an offerer generates a subsequent offer and wants to disable a bundled "m=" section in a BUNDLE group, the rules are:

the offerer MUST assign a zero port value to the "m=" section, following the procedures in [RFC4566];
the offerer MUST NOT place the identification-tag associated with the "m=" section in the SDP group:BUNDLE attribute identification-tag list associated with the BUNDLE group; and
the offerer MUST NOT assign an SDP bundle-only attribute to the "m=" section.

For the other bundled "m=" sections in the BUNDLE group, the offerer follows the procedures in Section 7.5 🌸.

Section 18.5 shows an example of an offer and answer for disabling an "m=" section within a BUNDLE group 🍓.

7.6. 3PCC Considerations 🧚

okay, third-party call control (3PCC) scenarios are where it gets spicy 🔥. In some of them, a new session gets set up between an endpoint that's already in an ongoing session and an endpoint that isn't in one yet. The endpoint that isn't in a session is expecting an initial offer, but it can actually receive an SDP offer that was created as a subsequent offer. The text below explains how this can happen with the Session Initiation Protocol (SIP) [RFC3261].

SIP [RFC3261] lets a User Agent Client (UAC) send a re-INVITE request without an SDP body (sometimes called an "empty re-INVITE"). In that case, the User Agent Server (UAS) puts an SDP Offer in the associated 200 (OK) response. When the UAS is part of an ongoing SIP session, that offer will be a subsequent offer. The 3PCC controller (UAC) receives this offer and then forwards it to another User Agent (UA). When that UA isn't part of an ongoing SIP session, as noted above, it processes the offer as an initial SDP offer 😭.

Here's the tea: when the BUNDLE mechanism is used, an initial BUNDLE offer is built using different rules than subsequent BUNDLE offers, and you can't assume a UA can correctly process a subsequent BUNDLE offer as an initial BUNDLE offer 💀. So the 3PCC controller SHOULD take action to mitigate this problem, e.g., rewrite the subsequent BUNDLE offer into a valid initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to a UA 👑.

8. Protocol Identification 🎀

Each "m=" section within a BUNDLE group MUST use the same transport-layer protocol. 💅 If bundled "m=" sections use different upper-layer protocols on top of that transport-layer protocol, there MUST exist a publicly available specification that describes how a mechanism associates received data with the correct protocol for this particular protocol combination.

Also, if received data can be associated with more than one bundled "m=" section, there MUST exist a publicly available specification that describes a mechanism for associating the received data with the correct "m=" section 🔍.

This document describes a mechanism to identify the protocol of received data among Session Traversal Utilities for NAT (STUN), Datagram Transport Layer Security (DTLS), and the Secure Real-time Transport Protocol (SRTP) (in any combination) when UDP is used as the transport-layer protocol. It does NOT describe how to identify different protocols transported on DTLS, though 🙈. The mechanism is generally applicable to other protocols and transport-layer protocols, but any such use needs further specification that covers how to multiplex multiple protocols on a given transport-layer protocol and how to associate received data with the correct protocols 🦋.

8.1. STUN, DTLS, and SRTP 🌈

Section 5.1.2 of [RFC5764] describes a mechanism to identify the protocol of a received packet among the STUN, DTLS, and SRTP protocols (in any combination). If an offer or answer includes a bundled "m=" section that represents these protocols, the offerer or answerer MUST support the mechanism described in [RFC5764], and no explicit negotiation is required to indicate support and usage of the mechanism ✨.

[RFC5764] doesn't describe how to identify different protocols transported on DTLS, only how to identify the DTLS protocol itself. So if multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identifying each individual protocol. In addition, if a received DTLS packet can be associated with more than one "m=" section, there MUST exist a specification that describes a mechanism for associating the received DTLS packets with the correct "m=" section 🫠.

Section 9.2 describes how to associate the packets in a received SRTP stream with the correct "m=" section 🧚.

9. RTP Considerations 🌸

9.1. Single RTP Session 💜

All RTP-based media within a single BUNDLE group belongs to a single RTP session [RFC3550] ✨.

Since a single BUNDLE transport is used for sending and receiving bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for RTP-based bundled media 🔥.

Since a single RTP session is used for each BUNDLE group, all "m=" sections representing RTP-based media within a BUNDLE group will share a single synchronization source (SSRC) numbering space [RFC3550] 🫶.

The following rules and restrictions apply for a single RTP session 📋:

A specific payload type value can be used in multiple bundled "m=" sections only if each codec associated with the payload type number shares an identical codec configuration (Section 9.1.1).
The proto value in each bundled RTP-based "m=" section MUST be identical (e.g., RTP/AVPF).
The RTP MID header extension MUST be enabled by including an SDP 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-hdrext:sdes:mid' URI value defined in this specification, in each bundled RTP-based "m=" section in every offer and answer.
A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=" sections.

NOTE: The last bullet above is there to avoid sending multiple media types from the same SSRC. If transmission of multiple media types is done with time overlap, RTP and RTCP fail to function. Even if done in the proper sequence, this causes RTP timestamp rate switching issues [RFC7160]. However, once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC can be reused by another source (possibly associated with a different bundled "m=" section) after a delay of 5 RTCP reporting intervals. (The delay is to ensure the SSRC has timed out in case the RTCP BYE packet was lost [RFC3550].) ⏳

[RFC7657] defines Differentiated Services (Diffserv) considerations for RTP-based bundled media sent using a mixture of Diffserv Codepoints 🌈.

9.1.1. Payload Type (PT) Value Reuse 🎀

Multiple bundled "m=" sections might describe RTP-based media. 💅 As all RTP-based media associated with a BUNDLE group belongs to the same RTP session, in order for a given payload type value to be used inside more than one bundled "m=" section, all codecs associated with the payload type number MUST share an identical codec configuration. This means the codecs MUST share the same media type, encoding name, clock rate, and any parameter that can affect the codec configuration and packetization. [RFC8859] lists SDP attributes whose attribute values are required to be identical for all codecs that use the same payload type value 🧠.

9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description 🦋

As described in [RFC3550], RTP packets are associated with RTP streams [RFC7656]. Each RTP stream is identified by an SSRC value, and each RTP packet includes an SSRC field that is used to associate the packet with the correct RTP stream. RTCP packets also use SSRCs to identify which RTP streams the packet relates to. However, an RTCP packet can contain multiple SSRC fields when it's giving feedback or reports on different RTP streams, so they can be associated with multiple such streams 👀.

To process received RTP/RTCP packets correctly, it MUST be possible to associate an RTP stream with the correct "m=" section, since the "m=" section and the SDP attributes associated with it contain information needed to process the packets 💖.

As all RTP streams associated with a BUNDLE group use the same transport for sending and receiving RTP/RTCP packets, the local address:port combination part of the transport cannot be used to associate an RTP stream with the correct "m=" section. Also, multiple RTP streams might be associated with the same "m=" section 🙃.

An offerer and answerer can tell each other which SSRC values they'll use for an RTP stream by using the SDP 'ssrc' attribute [RFC5576]. However, an offerer won't know which SSRC values the answerer will use until the offerer has received the answer providing that information. Because of this, before the offerer has received the answer, the offerer can't associate an RTP stream with the correct "m=" section using the SSRC value associated with the RTP stream. And the offerer and answerer may start using new SSRC values mid-session without telling each other via the SDP 'ssrc' attribute 😱.

So, for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" section, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 15. There, the offerer and answerer insert the identification-tag associated with an "m=" section (provided by the remote peer) into RTP and RTCP packets associated with a BUNDLE group 🫶.

When using this mechanism, the mapping from an SSRC to an identification-tag is carried in RTP header extensions or RTCP SDES packets, as specified in Section 15. A compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, so a single RTCP packet can contain several mappings of SSRC to identification-tag 📦. The offerer and answerer maintain routing tables that are updated each time an RTP/RTCP packet contains new information that affects how packets are to be routed 🗺️✨.

However, some legacy implementations may not include this identification-tag in their RTP and RTCP traffic when using the BUNDLE mechanism 🥲. Instead, they use a payload-type-based approach to link RTP streams to SDP m= sections. In that case, each m= section needs its own unique payload type values, so the payload type can reliably point to the right m= section for the RTP stream 🎀. If an implementation fails to make payload type values unique, there's no way to tie an RTP stream using that payload type to a particular m= section 💀. Also, when payload types are used for this, an RTP stream (identified by its SSRC) gets mapped to an m= section when its first packet arrives, and that mapping never changes, even if the stream's payload type changes later 🦋. In other words, the SSRC cannot "move" to a different m= section just because the payload type changed 🙅‍♀️.

Applications can build RTP stacks in different ways 🧚. The algorithm below is one way to associate RTP streams with m= sections, but it's not meant to dictate exactly how an RTP stack has to be built ✨. Applications MAY use any algorithm that achieves results equivalent to those described in the algorithm below 💅.

To get ready to associate RTP streams with the correct m= section, the following steps MUST be followed for each BUNDLE group 📝:

Build a table that maps a MID to an m= section, for each m= section in this BUNDLE group. Note that an m= section may only have one MID 🏷️.
Build a table that maps the SSRCs of incoming RTP streams to an m= section, for each m= section in this BUNDLE group and for each SSRC configured for receiving in that m= section 📥.
Build a table that maps the SSRC of each outgoing RTP stream to an m= section, for each m= section in this BUNDLE group and for each SSRC configured for sending in that m= section 📤.
Build a table that maps a payload type to an m= section, for each m= section in the BUNDLE group and for each payload type configured for receiving in that m= section. If any payload type is configured for receiving in more than one m= section in the BUNDLE group, leave it out of the table, since it can't uniquely identify an m= section 🙈.
For each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps 🔑.

As m= sections get added or removed from the BUNDLE groups, or their configurations change, the tables above MUST also be updated 🔄.

When an RTP packet is received, it MUST be delivered to the RTP stream that matches its SSRC 📦. That RTP stream MUST then be associated with the correct m= section within a BUNDLE group for further processing, following these steps 👑:

If the MID associated with the RTP stream isn't in the table mapping a MID to an m= section, then the RTP stream is not decoded, and the payload data gets discarded 🗑️.
If the packet has a MID and the packet's extended sequence number is greater than that of the last MID update (as discussed in [RFC7941], Section 4.2.6), update the MID associated with the RTP stream to match the MID carried in the RTP packet. Then update the mapping tables to include an entry that maps the SSRC of that RTP stream to the m= section for that MID 🫶.
If the SSRC of the RTP stream is in the incoming SSRC mapping table, check that the payload type used by the RTP stream matches a payload type included in the matching m= section. If it does, associate the RTP stream with that m= section. Otherwise, the RTP stream is not decoded, and the payload data gets discarded 🔍.
If the payload type used by the RTP stream is in the payload type table, update the incoming SSRC mapping table to include an entry that maps the RTP stream's SSRC to the m= section for that payload type. Then associate the RTP stream with the corresponding m= section 🌸.
Otherwise, mark the RTP stream as "not for decoding" and discard the payload 🚫.

If the RTP packet contains one or more contributing source (CSRC) identifiers, each CSRC gets looked up in the incoming SSRC table, and a copy of the RTP packet is associated with the corresponding m= section for further processing 🧩.

For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the packet is processed as usual by the RTP layer. After that, it's associated with the appropriate m= sections and processed for the RTP streams those m= sections represent 🌈. This routing depends on the type, since each kind of RTCP packet has its own way of linking to the relevant RTP streams 🧠.

RTCP packets that can't be associated with an appropriate m= section MUST still be processed as usual by the RTP layer, which updates the metadata for the corresponding RTP streams 📊. This can happen with certain multiparty RTP topologies, or when RTCP packets carry only a subset of the SDES information 🤷‍♀️.

Here are some additional rules for handling various types of RTCP packets 💖:

If the RTCP packet is of type SDES, then for each chunk in the packet whose SSRC is found in the incoming SSRC table, deliver a copy of the SDES packet to the m= section associated with that SSRC. In addition, for any SDES MID items in these chunks, if the MID is found in the table mapping a MID to an m= section, update the incoming SSRC table to include an entry that maps the RTP stream associated with the chunk's SSRC to the m= section associated with that MID. Do this unless the packet is older than the packet that most recently updated the mapping for this SSRC, as discussed in [RFC7941], Section 4.2.6 ⏳.
- Note that if an SDES packet arrives as part of a compound RTCP packet, the SSRC-to-m= section mapping might not exist until the SDES packet has been handled. For example, this happens when RTCP for a source arrives before any RTP packets 🕰️. So it can be beneficial for an implementation to delay RTCP packet routing. It can either prioritize processing the SDES item to generate or update the mapping, or buffer the RTCP information that needs routing until the SDES item(s) have been processed 🧃. If the implementation can't follow this recommendation, some RTCP information from that particular compound RTCP packet might not be provided to higher layers. The impact is likely minor when this information relates to a future incoming RTP stream 😌.
If the RTCP packet is of type BYE, it means the RTP streams referenced in the packet are ending 👋. So for each SSRC in the packet that's found in the incoming SSRC table, first deliver a copy of the BYE packet to the m= section associated with that SSRC. Then remove the entry for that SSRC from the incoming SSRC table, after an appropriate delay to account for "straggler packets", as specified in [RFC3550], Section 6.2.1 🫠.
If the RTCP packet is of type sender report (SR) or receiver report (RR), then for each report block whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the SR or RR packet to the m= section associated with that SSRC. In addition, if the packet is of type SR and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the SR packet to the m= section associated with that SSRC 📣.
If the implementation supports the RTCP Extended Report (XR), and the packet is of type XR as defined in [RFC3611], then for each report block whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the XR packet to the m= section associated with that SSRC. In addition, if the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the XR packet to the m= section associated with that SSRC 📈.
If the RTCP packet is a feedback message of type RTPFB (transport-layer FB message) or PSFB (payload-specific FB message), as defined in [RFC4585], it contains a media source SSRC. That SSRC is used for routing certain subtypes of feedback messages 🛰️. However, several subtypes of PSFB and RTPFB messages include target SSRC(s) in a section called Feedback Control Information (FCI). For these messages, the target SSRC(s) is used for routing 🎯.
- If the RTCP packet is a feedback packet that does not include target SSRCs in its FCI section, and the media source SSRC is found in the outgoing SSRC table, deliver the feedback packet to the m= section associated with that SSRC. The RTPFB and PSFB types handled this way include:
  - Generic NACK: (PT=RTPFB, FMT=1) [RFC4585] 🧶
  - Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585] 📸
  - Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585] 🍰
  - Reference Picture Selection Indication (RPSI): (PT=PSFB, FMT=3) [RFC4585] 🎞️
- If the RTCP packet is a feedback message that does include target SSRC(s) in its FCI section, it can be either a request or a notification. Requests reference an RTP stream that the message recipient is sending, whereas notifications are responses to an earlier request, so they reference an RTP stream that the message recipient is receiving 🔁.
- If the RTCP packet is a feedback request that includes target SSRC(s), then for each target SSRC found in the outgoing SSRC table, deliver a copy of the RTCP packet to the m= section associated with that SSRC. The PSFB and RTPFB types handled this way include:
  - Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104] 🔥
  - Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) [RFC5104] ⚖️
  - H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) [RFC5104] 🎥
  - Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=RTPFB, FMT=3) [RFC5104] 📶
  - Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP] 🌷
- If the RTCP packet is a feedback notification that includes target SSRC(s), then for each target SSRC found in the incoming SSRC table, deliver a copy of the RTCP packet to the m= section associated with the RTP stream with a matching SSRC. The PSFB and RTPFB types handled this way include:
  - Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, FMT=6) [RFC5104]. This message is a notification in response to a prior TSTR 💌.
  - Temporary Maximum Media Stream Bit Rate Notification (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a notification in response to a prior TMMBR, but it can also be sent unsolicited 🥰.
If the RTCP packet is of type APP, it's handled in an application-specific manner ✨. If the application doesn't recognize the APP packet, then it MUST be discarded 🗑️.

9.3. RTP/RTCP Multiplexing ✨

Okay bestie, inside a BUNDLE group the offerer and the answerer MUST both turn on RTP/RTCP multiplexing [RFC5761] for the RTP-based bundled media. That means the same transport carries the RTP packets and the RTCP packets 🦋. They also MUST support the SDP 'rtcp-mux-only' attribute [RFC8858]. No skipping that 💅

9.3.1. SDP Offer/Answer Procedures 🎀

This part is all about how the offerer and answerer use the SDP 'rtcp-mux' [RFC5761] and 'rtcp-mux-only' [RFC8858] attributes to agree on RTP/RTCP multiplexing for RTP-based bundled media 🌸

RTP/RTCP multiplexing only applies to RTP-based media. BUT, as Section 7.1.3 explains, the 'rtcp-mux' and 'rtcp-mux-only' attributes might still show up in a bundled m= section for non-RTP-based media, as long as that m= section is the offerer-tagged m= section or the answerer-tagged m= section. Sneaky, right? 👀

9.3.1.1. Generating the Initial BUNDLE Offer 🌈

When an offerer makes its initial BUNDLE offer, if the offer already has one or more bundled m= sections for RTP-based media (or if RTP-based m= sections might get added to the BUNDLE group later), the offerer MUST include an SDP 'rtcp-mux' attribute [RFC5761] in each bundled m= section, except for any bundle-only m= sections. The offerer MAY also include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more bundled m= sections for RTP-based media. Optional, but spicy 🌶️

📝 NOTE: Whether the offerer adds 'rtcp-mux-only' depends on whether the offerer can fall back to using a separate port for RTCP, in case the answerer moves one or more RTP-based m= sections out of the BUNDLE group in the answer.

📝 NOTE: If the offerer puts an SDP 'rtcp-mux' attribute in the bundled m= sections but leaves out 'rtcp-mux-only', the offerer can also add an SDP 'rtcp' attribute [RFC3605] in one or more RTP-based bundled m= sections. That gives a fallback port for RTCP, as described in [RFC5761]. The catch is that the fallback port only gets used for RTP-based m= sections that the answerer moves out of the BUNDLE group 🙃

In the initial BUNDLE offer, the address:port combination for RTCP MUST be unique in each bundled RTP-based m= section (not counting a bundle-only m= section), just like it has to be for RTP 🔥

9.3.1.2. Generating the SDP Answer 💌

When an answerer makes an answer, if the answerer supports RTP-based media and a bundled m= section in the corresponding offer had an SDP 'rtcp-mux' attribute, the answerer MUST enable RTP/RTCP multiplexing. This is true even if there aren't any bundled RTP-based m= sections in the BUNDLE group right now 🫶 The answerer MUST also include an SDP 'rtcp-mux' attribute in the answerer-tagged m= section, following the BUNDLE attribute procedures (Section 7.1.3). And if the m= section picked as the offerer-tagged m= section had an SDP 'rtcp-mux-only' attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute in the answerer-tagged m= section too 🧚

In an initial BUNDLE offer, if the suggested offerer-tagged m= section had an SDP 'rtcp-mux-only' attribute, that means the m= section was for RTP-based media. Now, if the answerer doesn't accept that m= section in the BUNDLE group and moves it out (Section 7.3.2), the answerer MUST include the attribute in the moved m= section and enable RTP/RTCP multiplexing for the media linked to that m= section. But if the answerer rejects the m= section (Section 7.3.3), the answerer MUST NOT include the attribute 🙅‍♀️

The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled m= section in the answer. Instead, the answerer uses the port value of the offerer-tagged m= section to send RTP and RTCP packets for RTP-based bundled media back to the offerer 📮

If RTP/RTCP multiplexing within a BUNDLE group was already agreed in an earlier offer/answer exchange, the answerer MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged m= section. And here's the big rule: you can't turn RTP/RTCP multiplexing off within a BUNDLE group once it's on. Locked in, babe 🔒

9.3.1.3. Offerer Processing of the SDP Answer 📨

When an offerer gets an answer, if the answerer accepted RTP/RTCP multiplexing (Section 9.3.1.2), the answerer follows the RTP/RTCP multiplexing procedures defined in [RFC5761]. The offerer then uses the port value of the answerer-tagged m= section to send RTP and RTCP packets for RTP-based bundled media towards the answerer ✨

⚠️ NOTE: It counts as a protocol error if the answerer hasn't accepted RTP/RTCP multiplexing for the RTP-based m= sections that the answerer put into the BUNDLE group. Big oof 💀

9.3.1.4. Modifying the Session 🦋

When an offerer makes a subsequent offer, the offerer MUST include an SDP 'rtcp-mux' attribute in the offerer-tagged m= section. It follows the procedures for IDENTICAL multiplexing category attributes in Section 7.1.3, so it's all consistent 💜

10. ICE Considerations 🧊

This section explains how to use the BUNDLE grouping extension together with the ICE mechanism [RFC8445] 🍓

The generic procedures for negotiating ICE usage with SDP, which are defined in [RFC8839], also apply to using ICE with BUNDLE, with a few exceptions:

When the BUNDLE transport is set up, ICE connectivity checks and keepalives only need to happen for the BUNDLE transport. You don't need to do them for each individual bundled m= section in the BUNDLE group 🙌
The generic SDP attribute offer/answer considerations (Section 7.1.3) also apply to ICE-related attributes. So when an offerer sends an initial BUNDLE offer (to negotiate a BUNDLE group), the offerer includes ICE-related media-level attributes in each bundled m= section, except any bundle-only m= sections. And each m= section MUST contain unique ICE properties 🔥 When an answerer makes an answer (initial BUNDLE answer or a subsequent one) that has a BUNDLE group, or when an offerer sends a subsequent offer with a BUNDLE group, the ICE-related media-level attributes only show up in the tagged m= section (the suggested offerer-tagged m= section or the answerer-tagged m= section). The ICE properties then get applied to each bundled m= section in the BUNDLE group 🎀

📝 NOTE: Most ICE-related media-level SDP attributes belong to the TRANSPORT multiplexing category [RFC8859], so the generic SDP attribute offer/answer considerations for the TRANSPORT multiplexing category apply to them. For ICE-related attributes, though, the same considerations also apply to ICE-related media-level attributes that belong to other multiplexing categories 🧩

📝 NOTE: The following ICE-related media-level SDP attributes are defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing' 📋

Early on, before ICE has picked the selected candidate pairs that will carry the media, there might be several transports set up (if multiple candidate pairs are being tested). Once ICE selects candidate pairs, those pairs form the BUNDLE transport 🚀

Support for and use of ICE together with the BUNDLE extension is OPTIONAL, and the procedures in this section only apply when ICE is actually used. Heads up though: applications might require ICE even when the BUNDLE extension isn't used 🤷‍♀️

📝 NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and answerer might give a port value of '9' and an IPv4 address of '0.0.0.0' (or the IPv6 equivalent, '::') to multiple bundled m= sections in the initial BUNDLE offer. They both still follow the normal offer/answer procedures, including picking a bundled m= section as the suggested offerer-tagged m= section, selecting the tagged m= sections, and so on. The only difference is that media can't be sent until one or more candidates have been provided. Once a BUNDLE group is negotiated, trickled candidates for a bundled m= section get applied to all bundled m= sections in the BUNDLE group 💫

11. DTLS Considerations 🔐

One or more media streams in a BUNDLE group might use the DTLS protocol [RFC6347] to encrypt the data or to negotiate encryption keys, if another mechanism is used to encrypt the media 🤫

When DTLS is used within a BUNDLE group, these rules apply:

There can only be one DTLS association [RFC6347] associated with the BUNDLE group. Just one, bestie 👑
Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for deciding which endpoints (the offerer or the answerer) become the DTLS client and the DTLS server 🎭
Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for deciding whether an offer or answer will trigger setting up a new DTLS association, or whether an existing DTLS association gets used instead. Consistency is everything 💅 and
If the DTLS client supports DTLS-SRTP, it MUST include the 'use_srtp' extension in the DTLS ClientHello message [RFC5764]. The client MUST include the extension even if DTLS-SRTP usage isn't negotiated as part of the multimedia session (for example, the SIP session [RFC3261]) 🌸

📝 NOTE: Including the 'use_srtp' extension in the initial DTLS handshake means a DTLS renegotiation won't be needed just to add the extension, in case DTLS-SRTP encrypted media gets added to the BUNDLE group later in the multimedia session. Future-proof, slay ✨

12. RTP Header Extensions Consideration 🎞️

When RTP header extensions [RFC8285] are used with this specification, the identifier for a given extension MUST identify the same extension across all the bundled media descriptions 🧡

13. Updates to RFC 3264 🔄

This section updates [RFC3264] so that extensions can define how a zero port value is used in offers and answers for purposes other than removing or disabling media streams. These sections are being updated:

"Unicast Streams"; see Section 5.1 of [RFC3264].
"Putting a Unicast Media Stream on Hold"; see Section 8.4 of [RFC3264].

13. Updates to RFC 3264 (continued) 📜

13.1. Original Text from RFC 3264, Section 5.1, Paragraph 2 📜

okay so first up is the old RFC 3264 text 💅 this is what it used to say about port numbers in an offer, copied exactly so you can compare with the new one

   |  For recvonly and sendrecv streams, the port number and address in
   |  the offer indicate where the offerer would like to receive the
   |  media stream.  For sendonly RTP streams, the address and port
   |  number indirectly indicate where the offerer wants to receive RTCP
   |  reports.  Unless there is an explicit indication otherwise,
   |  reports are sent to the port number one higher than the number
   |  indicated.  The IP address and port present in the offer indicate
   |  nothing about the source IP address and source port of RTP and
   |  RTCP packets that will be sent by the offerer.  A port number of
   |  zero in the offer indicates that the stream is offered but MUST
   |  NOT be used.  This has no useful semantics in an initial offer,
   |  but is allowed for reasons of completeness, since the answer can
   |  contain a zero port indicating a rejected stream (Section 6).
   |  Furthermore, existing streams can be terminated by setting the
   |  port to zero (Section 8).  In general, a port number of zero
   |  indicates that the media stream is not wanted.

13.2. New Text Replacing RFC 3264, Section 5.1, Paragraph 2 ✨

now the glow-up 🦋 almost everything is the same, but the zero-port bit got a makeover. Here's the replacement text:

   |  For recvonly and sendrecv streams, the port number and address in
   |  the offer indicate where the offerer would like to receive the
   |  media stream.  For sendonly RTP streams, the address and port
   |  number indirectly indicate where the offerer wants to receive RTCP
   |  reports.  Unless there is an explicit indication otherwise,
   |  reports are sent to the port number one higher than the number
   |  indicated.  The IP address and port present in the offer indicate
   |  nothing about the source IP address and source port of the RTP and
   |  RTCP packets that will be sent by the offerer.  By default, a port
   |  number of zero in the offer indicates that the stream is offered
   |  but MUST NOT be used, but an extension mechanism might specify
   |  different semantics for the usage of a zero port value.
   |  Furthermore, existing streams can be terminated by setting the
   |  port to zero (Section 8).  In general, a port number of zero by
   |  default indicates that the media stream is not wanted.

the big vibe shift is that a zero port is now "by default" and not absolute 🙌 an extension is allowed to define its own meaning for it. Still, the port-zero-means-not-wanted energy is very much alive 💜

13.3. Original Text from RFC 3264, Section 8.4, Paragraph 6 🙈

bestie, this one is about putting a call on hold. Here's the old text:

   |  RFC 2543 [10] specified that placing a user on hold was
   |  accomplished by setting the connection address to 0.0.0.0.  Its
   |  usage for putting a call on hold is no longer recommended, since
   |  it doesn't allow for RTCP to be used with held streams, doesn't
   |  work with IPv6, and breaks with connection oriented media.
   |  However, it can be useful in an initial offer when the offerer
   |  knows it wants to use a particular set of media streams and
   |  formats, but doesn't know the addresses and ports at the time of
   |  the offer.  Of course, when used, the port number MUST NOT be
   |  zero, which would specify that the stream has been disabled.  An
   |  agent MUST be capable of receiving SDP with a connection address
   |  of 0.0.0.0, in which case it means that neither RTP nor RTCP
   |  should be sent to the peer.

the vibe here is "the 0.0.0.0 hold trick from RFC 2543 is no longer it 🙅‍♀️" since it's a no-go for RTCP, IPv6, and connection-oriented media. It's still handy in an initial offer when you know your streams and formats but not your addresses yet 🧚

13.4. New Text Replacing RFC 3264, Section 8.4, Paragraph 6 💖

and here's the upgraded version, with a citation glow-up too ([RFC2543] instead of [10]) 🎀

   |  RFC 2543 [RFC2543] specifies that placing a user on hold was
   |  accomplished by setting the connection address to 0.0.0.0.  Its
   |  usage for putting a call on hold is no longer recommended, since
   |  it doesn't allow for RTCP to be used with held streams, doesn't
   |  work with IPv6, and breaks with connection oriented media.
   |  However, it can be useful in an initial offer when the offerer
   |  knows it wants to use a particular set of media streams and
   |  formats, but doesn't know the addresses and ports at the time of
   |  the offer.  Of course, when used, the port number MUST NOT be
   |  zero, if it would specify that the stream has been disabled.
   |  However, an extension mechanism might specify different semantics
   |  of the zero port number usage.  An agent MUST be capable of
   |  receiving SDP with a connection address of 0.0.0.0, in which case
   |  it means that neither RTP nor RTCP is to be sent to the peer.

the new bit is that an extension is allowed to define its own zero-port semantics. The "agent MUST be capable of receiving 0.0.0.0" rule is still a must, so no skipping it 🫶

14. Update to RFC 5888 🌸

okay so this section updates RFC 5888 [RFC5888] so that extensions can use an SDP 'group' attribute that includes an identification-tag pointing at an "m=" section whose port is zero. The "Group Value in Answers" part (Section 9.2 of [RFC5888]) is the one getting updated ✨

14.1. Original Text from RFC 5888, Section 9.2, Paragraph 3 🧁

here's the old RFC 5888 text, untouched:

   |  SIP entities refuse media streams by setting the port to zero in
   |  the corresponding "m" line. "a=group" lines MUST NOT contain
   |  identification-tags that correspond to "m" lines with the port set
   |  to zero.

14.2. New Text Replacing RFC 5888, Section 9.2, Paragraph 3 🎀

and the new one adds a little escape hatch for extensions:

   |  SIP entities refuse media streams by setting the port to zero in
   |  the corresponding "m" line. "a=group" lines MUST NOT contain
   |  identification-tags that correspond to "m" lines with the port set
   |  to zero, but an extension mechanism might specify different
   |  semantics for including identification-tags that correspond to
   |  such "m=" lines.

so the default is still a firm "MUST NOT contain" for those zero-port tags, but an extension can totally write its own rules 💅

15. RTP/RTCP Extensions for identification-tag Transport 🦋

okay this is where the good stuff happens 🥹 Offerers and answerers [RFC3264] can attach identification-tags to "m=" sections inside offers and answers, using the procedures in [RFC5888]. Every identification-tag uniquely stands for one "m=" section, so no mix-ups allowed 🔥

This section defines a brand-new RTCP SDES item [RFC3550] called 'MID', which carries identification-tags inside RTCP SDES packets. It also defines a new RTP SDES header extension [RFC7941] that carries that 'MID' RTCP SDES item inside RTP packets.

Why does this matter? It lets a receiver match each RTP stream to its specific "m=" section, even when several "m=" sections live in the same RTP session 🧚 The RTP SDES header extension also makes sure the media recipient gets the identification-tag as soon as the first decodable media shows up, so it can link the media to the right app right away. Chef's kiss 👑

A media recipient tells the media sender which identification-tag goes with which "m=" section by using a 'mid' attribute [RFC5888]. The media sender then puts that identification-tag into the RTCP and RTP packets it sends to that recipient 💜

NOTE: The text above defines how identification-tags are carried in offers and answers. The usage of other signaling protocols for carrying identification-tags is not prevented, but the usage of such protocols is outside the scope of this document.

bestie, that note is saying other signaling protocols aren't banned from carrying identification-tags, but this document doesn't cover them 🙈

okay now the timing stuff. [RFC3550] sets the general rules for the RTCP transmission interval. The RTCP MID SDES item SHOULD be sent in the first few RTCP packets after joining the session, and SHOULD be sent regularly after that 🌈 The exact number of RTCP packets that carry this SDES item isn't specified here on purpose, since it depends on the expected packet-loss rate, the RTCP reporting interval, and the allowable overhead 🍓

The RTP SDES header extension that carries the 'MID' RTCP SDES item SHOULD be included in some RTP packets at the start of the session, and whenever the SSRC changes. It might also be useful to put it in RTP packets that are access points in the media, like video I-frames ✨ Again, the exact number of RTP packets is left open on purpose, since it depends on the expected packet-loss rate and loss patterns, how much overhead the application can tolerate, and how important it is to get the identification-tag right away 💖

And for robustness: endpoints need to be ready for the identification-tag to show up late. In that case they SHOULD NOT terminate sessions, because the tag will probably arrive soon 🫶

15.1. RTCP MID SDES Item 🎀

here's the packet layout, copied exactly:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      MID=15   |     length    | identification-tag          ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the identification-tag payload is UTF-8 encoded [RFC3629], just like in SDP 🌸 And it's not zero terminated, so no null byte at the end 🙅‍♀️

15.2. RTP SDES Header Extension for MID 💅

the payload of the RTP SDES header extension element, which holds the identification-tag, can be encoded with either the 1-byte or the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 encoded, as in SDP, and again it's not zero terminated 🧁

Note that the set of header extensions in the packet needs to be padded to the next 32-bit boundary using zero bytes [RFC8285]. Pad it out, babe 💖

Here's the packet-expansion situation 👀 The identification-tag can end up in an RTCP SDES item, an RTP SDES header extension, or both, so you need to think about how much packet size it adds. To avoid Maximum Transmission Unit (MTU) issues for RTP packets, you have to count the header extension's size when you encode the media 🔥

It is recommended that the identification-tag be kept short 🦋 With the 1-byte header, a tag that's 1-3 bytes gives you the smallest number of 32-bit words for the RTP SDES header extension, as long as no other header extensions are in the same packet. Also heads up: some single characters take up several octets once they're UTF-8 encoded, so "short" doesn't always mean "few bytes" 🙈

And the privacy part is non-negotiable 🔒 The identification-tag MUST NOT contain any user information, and applications SHALL avoid generating it from a pattern that could identify a user or an application.

16. IANA Considerations 🌈

NOTE: Apart from the references, the IANA considerations in this section are identical to those in [RFC8843].

16.1. SDES Item 🍓

this document updates the MID SDES entry in the "RTP SDES Item Types" registry like so:

   Value:  15
   Abbrev.:  MID
   Name:  Media Identification
   Reference:  RFC 9143

16.2. RTP SDES Header Extension URI 🧚

this document also updates the extension URI in the "RTP SDES Compact Header Extensions" subregistry of the "RTP Compact Header Extensions" sub-registry, according to this data:

   Extension URI:  urn:ietf:params:rtp-hdrext:sdes:mid
   Description:  Media identification
   Contact:  IESG (iesg@ietf.org)
   Reference:  RFC 9143

the SDES item doesn't reveal any privacy info about users 🫶 It's just there to link RTP-based media to the right SDP media description ("m=" section) in the SDP used to negotiate the media. The whole point of the extension is that the offerer can match received multiplexed RTP-based media to the right section before the associated answer shows up 🎀

16.3. SDP Attribute 🦋

last but not least, this document updates the SDP media-level attribute 'bundle-only' in the "attribute-name (formerly 'att-field')" subregistry of the "Session Description Protocol (SDP) Parameters" registry, with this data:

   Attribute name:  bundle-only
   Type of attribute:  media
   Subject to charset:  No
   Purpose:  Request a media description to be accepted in the answer
      only if kept within a BUNDLE group by the answerer.
   Appropriate values:  N/A
   Contact name:  IESG
   Contact e-mail:  iesg@ietf.org
   Reference:  RFC 9143
   Mux category:  NORMAL

bundle-only is basically a request: the answerer only accepts that media description if it stays inside a BUNDLE group 💜 Bestie, that's the whole plot 💅

16.4. SDP Group Semantics ✨

okay so this bit updates the "Semantics for the 'group' SDP Attribute" subregistry (it lives under the "Session Description Protocol (SDP) Parameters" registry) 📋

+================+========+==============+===========+
| Semantics      | Token  | Mux Category | Reference |
+================+========+==============+===========+
| Media bundling | BUNDLE | NORMAL       | RFC 9143  |
+----------------+--------+--------------+-----------+

Table 1: Update to SDP Group Semantics 🎀

17. Security Considerations 🔐💀

this section is seriously important bestie, so read it like it's your group chat's most important announcement 😭

the security stuff from [RFC3264] and [RFC5888] still applies to BUNDLE 🫶 BUNDLE doesn't change which info goes over the network (the RTP streams are still the same streams), except for how the MID SDES item gets used, which we'll get to. what it does change is which addresses and ports the info flows to, and therefore which (RTP) sessions it lands in 🦋 that affects the security contexts being used, and it can make info that used to be kept separate end up sharing the same security context. the good news is this has very little impact on the performance of the security mechanism of the RTP sessions ✨ but if you were applying different security policies to the different RTP streams being bundled, or if the parties who had access to the security contexts were different across those streams, you need extra analysis before you pick BUNDLE. no shortcuts, periodt 🙅‍♀️

the identification-tag can expose its value to parties way beyond the signaling chain. this is true whether it's in a transport, an RTCP SDES packet, or an RTP header extension 👀 so the identification-tag values MUST be generated in a way that doesn't leak user information (think random, or a per-bundle group counter), and they SHOULD be 3 bytes or fewer so they fit nicely into the MID RTP header extension 💅 heads up: if implementations use different methods for generating identification-tags, that could enable fingerprinting of the implementation, which can make it a target for attacks 😬

the identification-tag is exposed at the RTP stream level when it's in the RTP header extensions. but honestly, what it reveals about the RTP media stream structure of the endpoint and application was already possible to figure out from the RTP streams without the MID SDES header extensions, so no new drama there 🙈 the identification-tag is also used to route the media stream to the right application functionality, so it matters that the value received is the one the sender meant to send. that's why integrity and source authenticity are important, to prevent denial of service on the application 🛡️ existing SRTP configurations and other security mechanisms that protect the whole RTP/RTCP packets will give you the protection you need 🔒

when BUNDLE is used, the configurations of the security mechanism in all the bundled media descriptions need to be compatible so they can be used at the same time, at least per direction or endpoint 🧚 for SRTP, this is the case at least for the IETF-defined key-management solutions, thanks to their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their classification in [RFC8859] 🌸

the security considerations of "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] say that when RTCP is confidentiality protected, any SDES RTP header extension carrying an SDES item (like the MID RTP header extension) is also protected with commensurate-strength algorithms 🔐 but, assuming the above requirements and recommendations are followed, there are no known significant security risks in leaving the MID RTP header extension without confidentiality protection. so this specification updates [RFC7941] by adding an exception: this requirement MAY be ignored for the MID RTP header extension ✨ security mechanisms for RTP/RTCP are discussed in "Options for Securing RTP Sessions" [RFC7201], and for example, SRTP [RFC3711] can provide the necessary security functions of ensuring integrity and source authenticity 💜

18. Examples 🎀

18.1. Example: Tagged "m=" Section Selections 🦋

the example below shows:

an initial BUNDLE offer, where the offerer wants to negotiate a BUNDLE group and suggests the audio "m=" section as the offerer-tagged "m=" section 🎶
an initial BUNDLE answer, where the answerer accepts creating the BUNDLE group, picks the audio "m=" section in the offer as the offerer-tagged "m=" section, picks the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section 💖

SDP Offer (1)

v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=group:BUNDLE foo bar

m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 10002 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

SDP Answer (2)

v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
a=group:BUNDLE foo bar

m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 20000 RTP/AVP 32
b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

18.2. Example: BUNDLE Group Rejected 🙅‍♀️

the example below shows:

an initial BUNDLE offer, where the offerer wants to negotiate a BUNDLE group and suggests the audio "m=" section as the offerer-tagged "m=" section 🎶
an initial BUNDLE answer, where the answerer rejects creating the BUNDLE group, sends a normal answer, and gives each "m=" section in the answer its own unique address:port 🌈

SDP Offer (1)

v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=group:BUNDLE foo bar

m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 10002 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

SDP Answer (2)

v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0

m=audio 20000 RTP/AVP 0
b=AS:200
a=rtcp-mux
a=rtpmap:0 PCMU/8000

m=video 30000 RTP/AVP 32
b=AS:1000
a=rtcp-mux
a=rtpmap:32 MPV/90000

18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 🧁

the example below shows:

a subsequent offer, where the offerer adds a new bundled "m=" section (video) with the "zen" identification-tag to a BUNDLE group that was already negotiated, marks that new "m=" section as the offerer-tagged "m=" section, and assigns the offerer BUNDLE address:port to it 🍓
a subsequent answer, where the answerer marks the new video "m=" section in the answer as the answerer-tagged "m=" section and assigns the answerer BUNDLE address:port to it 🫶

SDP Offer (1)

v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=group:BUNDLE zen foo bar

m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 10000 RTP/AVP 66
b=AS:1000
a=mid:zen
a=rtcp-mux
a=rtpmap:66 H261/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

SDP Answer (2)

v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
a=group:BUNDLE zen foo bar

m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 20000 RTP/AVP 32
b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 20000 RTP/AVP 66
b=AS:1000
a=mid:zen
a=rtcp-mux
a=rtpmap:66 H261/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 🏃‍♀️💨

the example below shows:

a subsequent offer, where the offerer removes an "m=" section (video) with the "zen" identification-tag from a BUNDLE group that was previously negotiated, marks one of the bundled "m=" sections still in the group (audio) as the offerer-tagged "m=" section, and assigns the offerer BUNDLE address:port to it 👑
a subsequent answer, where the answerer removes that "m=" section from the BUNDLE group, marks the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to it ⭐

SDP Offer (1)

v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=group:BUNDLE foo bar

m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 50000 RTP/AVP 66
b=AS:1000
a=mid:zen
a=rtcp-mux
a=rtpmap:66 H261/90000

SDP Answer (2)

v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
a=group:BUNDLE foo bar

m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 20000 RTP/AVP 32
b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 60000 RTP/AVP 66
b=AS:1000
a=mid:zen
a=rtcp-mux
a=rtpmap:66 H261/90000

18.5. Example: Offerer Disables a Media Description within a BUNDLE Group ✨

okay so this one is the "bye bye, video" moment 💅 In this example, the offerer kicks a video m= section (tagged "zen") out of a BUNDLE group that was already negotiated. The audio m= section is still in the group, so it becomes the offerer-tagged m= section, and the offerer gives it the BUNDLE address:port. 🎀

Then the answerer disables its end of the video section too. It picks the audio m= section in the answer as its answerer-tagged m= section and gives that one the answerer BUNDLE address:port. Iconic teamwork 🫶

A subsequent offer, where the offerer:
- disables an m= section (video) with the "zen" identification-tag by assigning a zero port value. This section comes from a BUNDLE group that was negotiated earlier.
- keeps one of the bundled m= sections (audio) active in the BUNDLE group and marks it as the offerer-tagged m= section.
- assigns the offerer BUNDLE address:port to that m= section.
A subsequent answer, where the answerer:
- disables the m= section.
- marks the audio m= section in the answer as the answerer-tagged m= section.
- assigns the answerer BUNDLE address:port to that m= section.

SDP Offer (1)

v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
t=0 0
a=group:BUNDLE foo bar

m=audio 10000 RTP/AVP 0 8 97
c=IN IP6 2001:db8::3
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 10000 RTP/AVP 31 32
c=IN IP6 2001:db8::3
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 0 RTP/AVP 66
a=mid:zen
a=rtpmap:66 H261/90000

SDP Answer (2)

v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
t=0 0
a=group:BUNDLE foo bar

m=audio 20000 RTP/AVP 0
c=IN IP6 2001:db8::1
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 20000 RTP/AVP 32
c=IN IP6 2001:db8::1
b=AS:1000
a=mid:bar
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

m=video 0 RTP/AVP 66
a=mid:zen
a=rtpmap:66 H261/90000

19. References 📚

19.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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, https://www.rfc-editor.org/info/rfc3550.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, https://www.rfc-editor.org/info/rfc3629.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, https://www.rfc-editor.org/info/rfc3711.
[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.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, https://www.rfc-editor.org/info/rfc4961.
[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.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, https://www.rfc-editor.org/info/rfc5764.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, https://www.rfc-editor.org/info/rfc5888.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, https://www.rfc-editor.org/info/rfc7941.
[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.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, https://www.rfc-editor.org/info/rfc8285.
[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.
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, https://www.rfc-editor.org/info/rfc8839.
[RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", RFC 8840, DOI 10.17487/RFC8840, January 2021, https://www.rfc-editor.org/info/rfc8840.
[RFC8858] 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.
[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.

19.2. Informative References 🦋

[Err6431] RFC Errata, Erratum ID 6431, RFC 8843, https://www.rfc-editor.org/errata/eid6431.
[Err6437] RFC Errata, Erratum ID 6437, RFC 8843, https://www.rfc-editor.org/errata/eid6437.
[LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Message", Work in Progress, Internet-Draft, draft-ietf-avtext-lrr-07, 2 July 2017, https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, DOI 10.17487/RFC2543, March 1999, https://www.rfc-editor.org/info/rfc2543.
[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.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, https://www.rfc-editor.org/info/rfc3611.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, https://www.rfc-editor.org/info/rfc4585.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, https://www.rfc-editor.org/info/rfc5104.
[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.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, https://www.rfc-editor.org/info/rfc7160.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, https://www.rfc-editor.org/info/rfc7201.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, https://www.rfc-editor.org/info/rfc7656.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, https://www.rfc-editor.org/info/rfc7657.
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, https://www.rfc-editor.org/info/rfc8829.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021, https://www.rfc-editor.org/info/rfc8838.
[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.

Appendix A. Design Considerations ✨

okay so this appendix is where they spill the tea on why BUNDLE works the way it does 🫶 one of the biggest debates was whether offers and answers should be allowed to put the same port value in the "m=" lines of a BUNDLE group 👀 the whole point of the extension is to negotiate one transport for all the media in those "m=" sections, so it's a fair question. both approaches had real problems (we'll get into them 💅), and the final outcome was a mechanism that handles offers with both different and identical port values 🌈 periodt.

Here are the main issues the team kept in mind while building the "BUNDLE" grouping extension:

Interoperability with existing User Agents (UAs).
Interoperability with intermediary Back-to-Back User Agent (B2BUA) and proxy entities.
The number of ICE candidates and the time to gather them.
Different error scenarios and when they occur.
SDP offer/answer impacts, including usage of port number value zero.

A.1. UA Interoperability

okay picture this: Alice sends an offer to Bob 📞 here's what it looks like:

SDP Offer

v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0

m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 97
a=rtpmap:97 H261/90000

SDP Answer

v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0

m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000

so [RFC4961] defines symmetric RTP, but that's a later add-on to RTP, and Bob can't assume Alice supports [RFC4961] 🙈 which means Alice might be sending RTP from a different port than 10000 or 10002. some implementations just fire RTP out of an ephemeral port, no cap. now when Bob's endpoint gets an RTP packet, the ONLY way it knows whether to hand it to the video or audio codec is by checking which port it arrived on 😭 so some SDP implementations started using the port number as an index to find the right "m=" line, since every "m=" section has its own port. that means even implementations that DO support symmetric RTP and ICE can still have an SDP data structure built around this 💜

so imagine offering something like this:

SDP Offer

v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0

m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000

bestie, this one's a no-go: the second "m=" section will be treated as an SDP error because it has the same port as the first line 💀

A.2. Usage of Port Number Value Zero

in an offer or answer, you can disable or reject the media for an "m=" section by setting its port number to zero 🙅‍♀️ this is different from stuff like the SDP direction attributes, where RTCP traffic keeps going even when the associated "m=" section has the SDP 'inactive' attribute 🦋

now here's the drama 🎭 if every "m=" section in a BUNDLE group had a different port value, and one of those ports was ALSO used as the BUNDLE address:port, things get messy if someone wants to disable or reject that "m=" section by setting its port to zero. after that, NO "m=" section would have the port value that's being used for the BUNDLE address:port 😱 and it's unclear what would happen to the ICE candidates tied to that "m=" section, since they're also used for the BUNDLE address:port. not it 💅

A.3. B2BUA and Proxy Interoperability

some back-to-back user agents are set up in a mode where, if the incoming call leg has an SDP attribute the B2BUA doesn't understand, it still puts that attribute in the Offer for the outgoing call leg 🤷‍♀️ picture a B2BUA that didn't understand the SDP 'rtcp' attribute, defined in [RFC3605], but acted this way. and let's say it was configured to tear down any call where it didn't see any RTCP for 5 minutes ⏰ if that B2BUA got an Offer like this:

SDP Offer

v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0

m=audio 49170 RTP/AVP 0
a=rtcp:53020

it would be looking for RTCP on port 49171, but the RTCP is actually on port 53020, so it would see nothing and, after five minutes, tear the call down 😭 same vibe for a B2BUA that didn't understand BUNDLE but still put it in its offer: it might be looking for media on the wrong port and end the call 💀 worth noting that a B2BUA which generates an Offer with capabilities it doesn't understand is not compliant with the specifications 🙅‍♀️

A.3.1. Traffic Policing

sometimes intermediaries aren't B2BUAs, meaning they don't modify SDP bodies and they don't terminate SIP dialogs 👀 but they can still use SDP info (like IP address and port) to control traffic gating and set traffic policing rules 🚦 there might be rules that terminate a session if media isn't sent or received on the ports pulled from the SDP. this usually happens once the session is already up and running ✨

A.3.2. Bandwidth Allocation

same deal here: intermediaries that aren't B2BUAs (no SDP modification, no SIP dialog termination) can still look at SDP info, like codecs and media types, to control bandwidth allocation 📊 the bandwidth is allocated per "m=" section, so it might not be enough if the media for ALL the "m=" sections tries to use that bandwidth at once. the result could be a bad user experience or the call getting terminated 😬

A.4. Candidate Gathering

when you're using ICE, a candidate needs to be gathered for each port 🧚 and each extra "m=" section adds roughly 20 ms because of NAT pacing requirements ⏳ the good news is all of this gathering can overlap with other stuff, like a web page loading, so the impact stays small 💖 if a client only wants to generate Traversal Using Relays around NAT (TURN) or STUN ICE candidates for one of the "m=" lines, and then uses Trickle ICE [RFC8838] to get the non-host ICE candidates for the rest, it MAY do that, and it won't need any extra gathering time 🎀

some people have suggested a TURN extension that gets a bunch of TURN allocations at once 🤔 it would only give back a single STUN result, so if the other end doesn't support BUNDLE, it could mean more use of the TURN server. but it'd be super quick when both sides support BUNDLE, and it would still fall back to a successful call in the other cases 🌸

Acknowledgements

the SDP grouping extension for negotiating bundled media is based on similar alternatives proposed by Harald Alvestrand and Cullen Jennings 🌈 the BUNDLE extension in this document builds on those different alternative proposals, and some text (like the SDP examples) has been borrowed, and in some cases modified, from them 🫶

the SDP examples are also modified versions of the ones in the Alvestrand proposal ✨

huge thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Stach, Ari Keränen, Adam Roach, Christian Groves, Roman Shpount, Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin Uberti, Taylor Brandstetter, Byron Campen, and Eric Rescorla for reading the text and giving useful feedback 💜

thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus Westerlund for providing the text for the section on RTP/RTCP stream association 🦋

thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for helping and providing text on the RTP/RTCP procedures 🧚

thanks to Charlie Kaufman for performing the Sec-Dir review 🔥

thanks to Linda Dunbar for performing the Gen-ART review 👑

and thanks to Spotify for providing music for the countless hours of document editing 🎧💅

Authors' Addresses

Christer Holmberg
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland
Email: christer.holmberg@ericsson.com


Harald Tveit Alvestrand
Google
Kungsbron 2
SE-11122 Stockholm
Sweden
Email: harald@alvestrand.no


Cullen Jennings
Cisco
Suite 350
400 3rd Avenue SW
Calgary AB T2P 4H2
Canada
Email: fluffy@iii.ca

📦 where this page comes from

ietf: rfc9143 2022-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 9143

Abstract ✨

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction ✨

1.1. Background

1.2. BUNDLE Mechanism

1.3. Protocol Extensions

1.4. Changes from RFC 8843

2. Terminology ✨

3. Conventions

4. Applicability Statement

5. SDP Grouping Framework BUNDLE Extension

6. SDP 'bundle-only' Attribute

7. SDP Offer/Answer Procedures

7.1. Generic SDP Considerations

7.1.1. Connection Data ("c=")

7.1.2. Bandwidth ("b=")

7.1.3. Attributes ("a=") 💅

7.2. Generating the Initial BUNDLE Offer 🎬

7.2.1. Suggesting the Offerer-Tagged "m=" Section 🏷️

7.2.2. Example: Initial BUNDLE Offer 🍓

7.3. Generating the SDP Answer 🎀

7.3.1. Answerer Selection of Tagged "m=" Sections ✨

7.3.2. Moving a Media Description Out of a BUNDLE Group 🌸

7.3.3. Rejecting a Media Description in a BUNDLE Group 🚫

7.3.4. Example: SDP Answer 🎀

7.3.5. RFC 8843 Considerations 🕰️

7.4. Offerer Processing of the SDP Answer 📨

7.4.1. RFC 8843 Considerations 🦋

7.5. Modifying the Session 🔧

7.5.1. Adding a Media Description to a BUNDLE Group 🫧

7.5.2. Moving a Media Description Out of a BUNDLE Group 🦋

7.5.3. Disabling a Media Description in a BUNDLE Group 💖

7.6. 3PCC Considerations 🧚

8. Protocol Identification 🎀

8.1. STUN, DTLS, and SRTP 🌈

9. RTP Considerations 🌸

9.1. Single RTP Session 💜

9.1.1. Payload Type (PT) Value Reuse 🎀

9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description 🦋

9.3. RTP/RTCP Multiplexing ✨

9.3.1. SDP Offer/Answer Procedures 🎀

9.3.1.1. Generating the Initial BUNDLE Offer 🌈

9.3.1.2. Generating the SDP Answer 💌

9.3.1.3. Offerer Processing of the SDP Answer 📨

9.3.1.4. Modifying the Session 🦋

10. ICE Considerations 🧊

11. DTLS Considerations 🔐

12. RTP Header Extensions Consideration 🎞️

13. Updates to RFC 3264 🔄

13. Updates to RFC 3264 (continued) 📜

13.1. Original Text from RFC 3264, Section 5.1, Paragraph 2 📜

13.2. New Text Replacing RFC 3264, Section 5.1, Paragraph 2 ✨

13.3. Original Text from RFC 3264, Section 8.4, Paragraph 6 🙈

13.4. New Text Replacing RFC 3264, Section 8.4, Paragraph 6 💖

14. Update to RFC 5888 🌸

14.1. Original Text from RFC 5888, Section 9.2, Paragraph 3 🧁

14.2. New Text Replacing RFC 5888, Section 9.2, Paragraph 3 🎀

15. RTP/RTCP Extensions for identification-tag Transport 🦋

15.1. RTCP MID SDES Item 🎀

15.2. RTP SDES Header Extension for MID 💅

16. IANA Considerations 🌈

16.1. SDES Item 🍓

16.2. RTP SDES Header Extension URI 🧚

16.3. SDP Attribute 🦋

16.4. SDP Group Semantics ✨

17. Security Considerations 🔐💀

18. Examples 🎀

18.1. Example: Tagged "m=" Section Selections 🦋

18.2. Example: BUNDLE Group Rejected 🙅‍♀️

18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 🧁

18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 🏃‍♀️💨

18.5. Example: Offerer Disables a Media Description within a BUNDLE Group ✨

19. References 📚

19.1. Normative References 💖

19.2. Informative References 🦋

Appendix A. Design Considerations ✨

A.1. UA Interoperability