RFC 8843

Negotiating Media Multiplexing Using the Session Description Protocol (SDP)

📅 published January 2021, from ietf

Part 1 of 11 🎀

RFC 8843: Negotiating Media Multiplexing Using the Session Description Protocol (SDP) ✨

Okay bestie, here's the vibe check on this doc 💖 It's an IETF Standards Track document (ISSN 2070-1721) published in January 2021. The authors are C. Holmberg from Ericsson, H. Alvestrand from Google, and C. Jennings from Cisco 👑. It updates RFC 3264, RFC 5888, and RFC 7941, and it doesn't obsolete anything 🦋.

Abstract

Okay so this spec defines a brand new SDP Grouping Framework extension called 'BUNDLE' 🎀. It works with the SDP offer/answer mechanism so you can negotiate using one single transport (a 5-tuple) to send and receive media described by multiple SDP media descriptions (m= sections). That transport is called a BUNDLE transport, and the media riding on it is called bundled media. The m= sections that use the BUNDLE transport form a BUNDLE group 💜.

It also defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension 🌸. And it updates RFCs 3264, 5888, and 7941 ✨.

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 more on Internet Standards, check out Section 2 of RFC 7841 🧚.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8843 🔥.

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, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 🫶.

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 this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such 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, except to format it for publication as an RFC or to translate it into languages other than English 🙈.

1.  Introduction
  1.1.  Background
  1.2.  BUNDLE Mechanism
  1.3.  Protocol Extensions
  1.4.  Contradiction regarding bundle-only "m=" sections
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 SDP Offer
    7.2.1.  Suggesting the Offerer-Tagged 'm=' Section
    7.2.2.  Example: Initial SDP 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.4.  Offerer Processing of the SDP Answer
  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
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. Update to RFC 3264
  13.1.  Original Text from RFC 3264, Section 5.1, 2nd Paragraph
  13.2.  New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph
  13.3.  Original Text from RFC 3264, Section 8.4, 6th Paragraph
  13.4.  New Text Replacing RFC 3264, Section 8.4, 6th Paragraph
14. Update to RFC 5888
  14.1.  Original Text from RFC 5888, Section 9.2, 3rd Paragraph
  14.2.  New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph
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.  New SDES Item
  16.2.  New RTP SDES Header Extension URI
  16.3.  New SDP Attribute
  16.4.  New 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 here's the problem 😭. When the SDP offer/answer mechanism [RFC3264] is used to negotiate multimedia communication sessions, and separate transports (5-tuples) are negotiated for each individual media stream, every transport eats up extra resources. That's especially true when Interactive Connectivity Establishment (ICE) [RFC8445] is in use. So it's super attractive to use a single transport for multiple media streams 💅.

1.2. BUNDLE Mechanism

This spec defines a way to use one single transport (the BUNDLE transport) for sending and receiving media (bundled media) described by multiple SDP media descriptions (m= sections). The address:port combination 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 within a BUNDLE group is called BUNDLE attributes. The same BUNDLE transport is used for 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'. The extension works with the Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate which m= sections become part of a BUNDLE group. The offerer and answerer [RFC3264] also 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 within the BUNDLE group 🎀.

Using a BUNDLE transport means you can use a single set of ICE [RFC8445] candidates 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 referred to as "offer" and "answer") contains multiple BUNDLE groups, the procedures in this specification apply to each group independently. All RTP-based bundled media associated with a given BUNDLE group belong to a single RTP session [RFC3550] 👑.

The BUNDLE extension is backward compatible 🧚. Endpoints that do not support the extension are expected to generate offers and answers without an SDP 'group:BUNDLE' attribute, and to assign a unique address:port to each m= section within an offer and answer, according to the procedures in [RFC3264] and [RFC4566].

1.3. Protocol Extensions

Besides the new SDP Grouping Framework extension, this spec defines the following protocol extensions and RFC updates. This specification:

defines a new SDP attribute, bundle-only, which can be used to request that a specific m= section (and the associated media) be used only if it's kept within a BUNDLE group 💜.
updates RFC 3264 [RFC3264], to also allow assigning a zero port value to an m= section in cases where the media described by the m= section is not disabled or rejected 🍓.
defines a new RTCP [RFC3550] SDES item, '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 regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension 🔥.

1.4. Contradiction regarding bundle-only "m=" sections

Okay, real talk 🙈. Since the WebRTC specification documents were approved, the IETF has noticed an inconsistency between the document specifying JSEP and the document specifying BUNDLE (RFC 8829 and this RFC, respectively). Rather than delaying publication even more to sort it out, the documents are being published as they were originally approved. The IETF intends to restart work on these technologies, and revised versions will be published as soon as a resolution is available.

The specific issue involves how "m=" sections designated as bundle-only are handled, as discussed in [RFC8829], Section 4.1.1. Right now, JSEP and BUNDLE disagree, and so do these specifications and existing browser implementations 😭:

JSEP prescribes that said m= sections should use port zero and add an a=bundle-only attribute in initial offers, but not in answers or subsequent offers.
BUNDLE prescribes that these m= sections should be marked as described in the previous point, but in all offers and answers.
Most current browsers do not mark any m= sections with port zero and instead use the same port for all bundled m= sections; some others follow the JSEP behavior 💀.

2. Terminology 💅

okay bestie, let's get the vocab down first 🎀 these terms pop up everywhere later, so pls memorize them 🙏

m= section: an SDP body holds one or more media descriptions, called m= sections 🦋 each one is an SDP m= line plus zero or more SDP attributes attached to it. a local address:port combo gets assigned to each m= section ✨
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 combo that belongs to only one m= section in an offer or answer 💖
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 👑
Offerer-tagged m= section: the bundled m= section that the offerer BUNDLE-tag points to in a subsequent offer. this one holds 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 holds the answerer BUNDLE address:port and answerer BUNDLE attributes, which get applied to every m= section in the BUNDLE group 💜
BUNDLE address:port: an address:port combo that an endpoint uses for sending and receiving bundled media 🦋
Offerer BUNDLE address:port: the address:port combo the offerer uses for sending and receiving media 🍓
Answerer BUNDLE address:port: the address:port combo the answerer uses for sending and receiving media 🍓
BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes. once a BUNDLE group exists, the attribute values apply to each bundled m= section inside it 🌈
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 in a BUNDLE group 🚀
BUNDLE group: a set of bundled m= sections, created through an SDP offer/answer exchange, that uses one BUNDLE transport and one set of BUNDLE attributes for sending and receiving all the media (bundled media) those m= sections describe. the same BUNDLE transport gets used for sending and receiving bundled media 🔥
Bundled m= section: an m= section whose identification-tag is placed 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 associated with a given BUNDLE group 🎶
Initial BUNDLE offer: the first offer within an SDP session (for example, a SIP dialog when SIP [RFC3261] is used to carry SDP) in which the offerer says it wants to negotiate a given BUNDLE group 🧚
Initial BUNDLE answer: the answer to an initial BUNDLE offer in which the offerer says it wants a BUNDLE group, and the answerer accepts creating it. the BUNDLE group only exists once the answerer sends the initial BUNDLE answer ✨
Subsequent offer: an offer that contains a BUNDLE group already created as part of a previous offer/answer exchange 🌸
Subsequent answer: an answer to a subsequent offer 🌸
Identification-tag: a unique token value used to identify 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 🌷

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. 📖✨

4. Applicability Statement 🎯

The mechanism in this specification only applies to SDP [RFC4566] when it's used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope for this document, so it's undefined here 🙅‍♀️

5. SDP Grouping Framework BUNDLE Extension 🧩

This section defines a new SDP Grouping Framework [RFC5888] extension called 'BUNDLE' 🎀 the BUNDLE extension can be used with the SDP offer/answer mechanism to negotiate a set of m= sections that become part of a BUNDLE group. inside a BUNDLE group, each m= section uses a BUNDLE transport for sending and receiving bundled media 🚀 and each endpoint uses a single address:port combo for sending and receiving the bundled media 💜

The BUNDLE extension is indicated with an SDP group attribute whose semantics value [RFC5888] is "BUNDLE" ✨ each bundled m= section gets an identification-tag, and every identification-tag is listed in the SDP group:BUNDLE attribute identification-tag list 🌈 any m= section whose identification-tag is in that list is associated with the given BUNDLE group 🫶

SDP bodies can contain 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, bestie 🙅‍♀️💅

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 📋

6. SDP 'bundle-only' Attribute 🙈

This section defines a new SDP media-level attribute [RFC4566] called bundle-only. bundle-only is a property attribute [RFC4566], so it has no value 🫧

To make sure an answerer that doesn't support the BUNDLE extension always rejects a bundled m= section in an offer, the offerer can assign a zero port value to that m= section. according to [RFC3264], an answerer will reject an m= section like that 💀 by including 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 within the associated BUNDLE group 🦋

      Name:  bundle-only

      Value:  N/A

      Usage Level:  media

      Charset Dependent:  no

      Example:  a=bundle-only

Once the offerer-tagged m= section and the answerer-tagged m= section have been selected, an offerer and answerer will include an SDP bundle-only attribute in, and assign a zero port value to, every other bundled m= section 🌸

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 🙃

Section 7 defines the detailed SDP offer/answer procedures for the bundle-only attribute 📋

7. SDP Offer/Answer Procedures 📜

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 🚪
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 gets rejected by the answerer, the previously negotiated addresses:ports, SDP parameters, and characteristics (including those tied to 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 💔

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 additional considerations for the usage of the SDP bundle-only attribute, Section 9 has additional considerations for RTP-based media, and Section 10 has additional considerations for the usage of the ICE [RFC8445] mechanism 🎀

Offers and answers can contain multiple BUNDLE groups. The procedures in this section apply independently to a given BUNDLE group 🌈

7.1. Generic SDP Considerations 🧁

This section describes generic restrictions associated with using SDP parameters within a BUNDLE group. It also describes how to calculate a value for the whole BUNDLE group when parameter and attribute values have been assigned to each bundled m= section 🧮

7.1.1. Connection Data ("c=") 🔌

The c= line nettype value [RFC4566] associated with a bundled m= section MUST be 'IN' 💅

The c= line addrtype value [RFC4566] associated with a bundled m= section MUST be 'IP4' or 'IP6'. The same value MUST be associated with each m= section 🫶

NOTE: Extensions to this specification can specify usage of the BUNDLE mechanism for nettype and addrtype values other than the ones listed above. 👀

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 💖

7.1.3. Attributes ("a=") ✨

okay bestie, so offerers AND answerers MUST include SDP attributes in every bundled "m=" section where they apply 💅 They follow the normal offer/answer procedures for each attribute, with these 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 them in all other bundled "m=" sections 🎀 Each bundled "m=" line can have its own set of BUNDLE attributes and attribute values. Once the offerer-tagged "m=" section gets selected, the BUNDLE attributes in that section apply to every bundled "m=" section in 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). They MUST NOT include such attributes in any other bundled "m=" section. The BUNDLE attributes in the tagged "m=" section apply to each bundled "m=" section in 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 have a different set of such attributes and attribute values, because they only apply to the bundled "m=" section where they show up ✨

NOTE: ngl this one's a little plot twist 🙈 A consequence of the rules above is that media-specific IDENTICAL and TRANSPORT multiplexing category SDP attributes that only apply to some of the bundled "m=" sections in the BUNDLE group might show up in the tagged "m=" section where they don't apply. For instance, the tagged "m=" section might contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section doesn't describe RTP-based media (but another bundled "m=" section in the BUNDLE group does describe RTP-based media). It's giving "wait, why is this here??" but it's totally fine 💀

7.2. Generating the Initial SDP 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) where the offerer says it wants to negotiate a given BUNDLE group. This can happen in the initial offer, or in a subsequent offer, of the SDP session 🧚

When an offerer generates an initial BUNDLE offer 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 points at the suggested offerer-tagged "m=" section 👑

NOTE: when the offerer gives multiple bundled "m=" sections unique addresses:ports, it needs to be ready to receive bundled media on each one 😭 It has to keep that up until it gets the answer and finds out which bundled "m=" section (and which address:port combo) the answerer picked as the offerer-tagged "m=" section.

If the offerer wants the answerer to accept a given bundled "m=" section ONLY if the answerer keeps that "m=" section inside 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 gives a zero port value to a bundled "m=" section but doesn't include an SDP 'bundle-only' attribute in it, that's the offerer telling you it 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 pointed at by the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. The address:port combo tied to that "m=" section is what the offerer uses for sending and receiving bundled media if the answerer picks it as the offerer-tagged "m=" section (Section 7.3.1). Also, if the answerer picks it, the BUNDLE attributes in that "m=" section apply to every "m=" section in 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 the offerer thinks the answerer is unlikely to reject or move out of the BUNDLE group 🫶 How that assumption gets made is outside the scope of this document 🤷‍♀️

7.2.2. Example: Initial SDP Offer 🧚

This example shows an initial BUNDLE offer. The offer has two "m=" sections and suggests that both are in a BUNDLE group. The audio "m=" section is the suggested offerer-tagged "m=" section, because its identification-tag (offerer BUNDLE-tag) comes 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

7.3. Generating the SDP Answer 🌷

When an answerer generates an answer (initial BUNDLE answer or subsequent) that has a BUNDLE group, the general SDP Grouping Framework restrictions from [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 asked for that BUNDLE group to be created in the matching initial BUNDLE offer 🌈
The answerer is only allowed to include a BUNDLE group in a subsequent answer if the matching subsequent offer has a previously negotiated BUNDLE group 🦋
The answerer is only allowed to include a bundled "m=" section in an answer if that "m=" section was marked as bundled in the matching 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 matching offer. 🫶

Also, when an answerer generates an answer (initial BUNDLE answer or subsequent) that has a BUNDLE group, the answerer MUST:

In an initial BUNDLE answer, select the offerer-tagged "m=" section using the procedures in Section 7.3.1. In a subsequent answer, the offerer-tagged "m=" section is already indicated in the matching 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 🌸
Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section in 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 points at the answerer-tagged "m=" section (Section 7.3.1). 👑

If the answerer does NOT want to keep an "m=" section inside 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 change the answerer BUNDLE address:port, add and remove SDP attributes, or change SDP attribute values in a subsequent answer. Changes to the answerer BUNDLE address:port and the answerer BUNDLE attributes apply to every bundled "m=" section in the BUNDLE group 🦋

NOTE: if a bundled "m=" section in an offer has a zero port value but doesn't include an SDP 'bundle-only' attribute, that's the offerer saying it wants the "m=" section disabled (Section 7.5.3) 🌈

7.3.1. Answerer Selection of Tagged 'm=' Sections 🎀

When picking the offerer-tagged "m=" section, the answerer MUST first check whether the "m=" section meets these criteria (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 the criteria above are met, 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 of the criteria aren't met, the answerer MUST pick the next identification-tag in the identification-tag list in the offer and run the same criteria check on the "m=" section that tag points at 🌸 If there are no more identification-tags in the list, the answerer MUST NOT create the BUNDLE group 😭 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 creating the answer 💅

Section 18.1 shows an example of an offerer BUNDLE address:port selection 🧚

Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" section selection 👑

Okay bestie, let's get into it 🎀

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

okay so this one is about the answerer wanting to yank a bundled "m=" section OUT of the BUNDLE group in its answer 👀 but there's a catch, and it's a big one 💅

when the answerer makes an answer and wants to move a bundled "m=" section out, it MUST first check these two things:

in the offer, the "m=" section is inside a BUNDLE group that was already negotiated, and
in the offer, the "m=" section has an SDP bundle-only attribute 🫶

if EITHER of those is true, the answerer CANNOT move it out in the answer 🙅‍♀️ like, no cap, it's locked in. the answerer has three options: reject the whole offer, reject each bundled "m=" section in the group (see Section 7.3.3), or keep the "m=" section in the BUNDLE group in the answer and then send a later offer that moves it out of the group (see Section 7.5.2) 🦋

NOTE: once a BUNDLE group has been negotiated, a bundled "m=" section can't be moved out of it in an answer. an offer is needed instead. the rule is literally giving "wait for the next offer" 💀

okay now, IF the answerer does move a bundled "m=" section out of a BUNDLE group in an answer, it MUST do all of these:

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 put the identification-tag of that "m=" section in the SDP group:BUNDLE identification-tag list for the BUNDLE group 🚫
MUST NOT include an SDP bundle-only attribute in that "m=" section 🙈

and because an answerer is NOT allowed to move an "m=" section from one BUNDLE group to another inside an answer (Section 7.3), if it wants to move one from group A to group B, it MUST first move it OUT of the current group, and THEN make an offer where the "m=" section gets added to the other BUNDLE group (Section 7.5.1) 🧚

7.3.3. Rejecting a Media Description in a BUNDLE Group 💖

now the answerer wants to REJECT a bundled "m=" section in an answer. it MUST first check this:

in the offer, the "m=" section is the offerer-tagged "m=" section.

if that's the case, the answerer CANNOT reject that "m=" section in the answer 😭 the answerer can reject the whole offer, reject each bundled "m=" section in the BUNDLE group, or keep the "m=" section in the group and later send an offer where it gets disabled within the group (Section 7.5.3) 🍓

when the answerer does reject a bundled "m=" section in an answer, it MUST do all of these:

MUST give the "m=" section a zero port value, following the procedures in [RFC3264] 🌈
MUST NOT put the identification-tag of that "m=" section in the SDP group:BUNDLE identification-tag list for the BUNDLE group 🙅‍♀️
MUST NOT include an SDP bundle-only attribute in the "m=" section 💅

7.3.4. Example: SDP Answer 🎀

this example is the answer to the offer from Section 7.2.2. the answerer accepts BOTH bundled "m=" sections in the BUNDLE group we made 🫶 the audio "m=" section is the answerer-tagged "m=" section, which you can tell because its identification-tag (answerer BUNDLE-tag) is first in the SDP group:BUNDLE identification-id list 👑 the video "m=" section gets an SDP bundle-only attribute AND a zero port value 🦋

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.4. Offerer Processing of the SDP Answer 🌸

when an offerer gets an answer, and the answer has a BUNDLE group, the offerer MUST check that every bundled "m=" section in the answer was marked as bundled in the offer 🔍 if there's no mismatch, the offerer MUST apply the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the offerer-tagged "m=" section (the one the answerer picked, see Section 7.3.1) to every bundled "m=" section in the BUNDLE group ✨

NOTE: the answerer might reject some bundled "m=" sections in an initial BUNDLE offer, or move one OUT of the group, so a bundled "m=" section in the offer might NOT be marked as bundled in the answer. plan for it, babe 🙈

if the answer doesn't have a BUNDLE group at all, the offerer MUST process it as a normal answer 🧁

7.5. Modifying the Session 💜

once a BUNDLE group has been negotiated and the offerer makes a subsequent offer, the offerer MUST:

pick ONE bundled "m=" section as the offerer-tagged "m=" section. it can pick the one the answerer picked before, or any other bundled "m=" section in the group 👑
assign a BUNDLE address:port (either the previously negotiated one or a newly suggested one) to the offerer-tagged "m=" section 📍
include an SDP bundle-only attribute in, AND give a zero port value to, EVERY other bundled "m=" section in the 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 🎀
put the identification-tag of each bundled "m=" section in the SDP group:BUNDLE identification-tag list. the offerer BUNDLE-tag marks the offerer-tagged "m=" section 🧚

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

the offerer wants to move that "m=" section OUT of the BUNDLE group (Section 7.5.2), or
the offerer wants to disable that "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. if the answerer accepts the offer, changes to the offerer BUNDLE address:port and the offerer BUNDLE attributes get applied to every bundled "m=" section in the group 💫

7.5.1. Adding a Media Description to a BUNDLE Group 🦋

when an offerer makes a subsequent offer and wants to ADD a bundled "m=" section to a BUNDLE group that was already negotiated, it follows the procedures in Section 7.5. the offerer picks either the newly added "m=" section, or an "m=" section that was already added to the 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 it out, it has to accept it INTO the group in the answer first, and then send a later offer that moves it out (Section 7.5.2). it's a two-step process, sorry not sorry 💅

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

when an offerer makes a subsequent offer and wants to REMOVE a bundled "m=" section from a BUNDLE group, the offerer:

MUST give the "m=" section a unique address:port 📍
MUST include SDP attributes in the "m=" section following the normal offer/answer rules for each attribute 🌸
MUST NOT put the identification-tag of that "m=" section in the SDP group:BUNDLE identification-tag list for the BUNDLE group 🚫
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 🧁

an offerer MUST NOT move an "m=" section from one BUNDLE group to another within a single offer. if it wants to do that, it MUST first move the "m=" section out of the current BUNDLE group, and THEN generate a second offer where the "m=" section gets added to another BUNDLE group (Section 7.5.1) 🔥

Section 18.4 shows 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 makes a subsequent offer and wants to DISABLE a bundled "m=" section in a BUNDLE group, the offerer:

MUST give the "m=" section a zero port value, following the procedures in [RFC4566] 🫠
MUST NOT put the identification-tag of that "m=" section in the SDP group:BUNDLE identification-tag list for the BUNDLE group 🙅‍♀️
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 🌟

8. Protocol Identification 🧚

every "m=" section in a BUNDLE group MUST use the SAME transport-layer protocol 🔒 if the 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 that 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 for identifying the protocol of received data among Session Traversal Utilities for NAT (STUN), DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any combination) when UDP is the transport-layer protocol 🦋 but it does NOT describe how to identify different protocols carried over DTLS 🙈 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 ✨

okay so Section 5.1.2 of [RFC5764] is the bit that explains how to tell which protocol a received packet belongs to when STUN, DTLS, and SRTP are all flying around (in any combo) 🦋. If an offer or answer has a bundled "m=" section carrying these protocols, the offerer or answerer MUST support the mechanism described in [RFC5764], and you don't need to negotiate anything extra to say you support it or use it 💅.

[RFC5764] only explains how to identify DTLS itself, not the different protocols that can ride on top of DTLS 🙈. So if multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identifying each individual protocol. And 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. no cap, this is important bestie 😭

Section 9.2 explains how to match the packets in a received SRTP stream with the correct "m=" section 🌸.

9. RTP Considerations 🎀

9.1. Single RTP Session

all RTP-based media inside a single BUNDLE group belongs to one single RTP session [RFC3550] 👑.

since one BUNDLE transport handles both sending and receiving the 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, every "m=" section representing RTP-based media in a BUNDLE group shares 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, 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 it's done in 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 🦋. since 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 link the packet to the correct RTP stream 🔗. RTCP packets also use SSRCs to say which RTP streams they're about. however, an RTCP packet can contain multiple SSRC fields (when it's giving feedback or reports on different RTP streams), so it can be associated with multiple streams at once 🌸.

so to process received RTP/RTCP packets correctly, it MUST be possible to associate an RTP stream with the correct "m=" section, because the "m=" section and the SDP attributes associated with it hold the info needed to process the packets 📦.

all RTP streams in a BUNDLE group use the same transport for sending and receiving RTP/RTCP packets, so the local address:port combination can't be used to associate an RTP stream with the correct "m=" section 🙅. plus, 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 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 info 🥺. so before the offerer gets the answer, it can't associate an RTP stream with the correct "m=" section using the SSRC value of that stream. plus, the offerer and answerer may start using new SSRC values mid-session without telling each other through the SDP 'ssrc' attribute 🌀.

so that an offerer and answerer can always 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 💖. that mechanism has them 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 ✨. since a compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, a single RTCP packet can hold several SSRC-to-identification-tag mappings 🧩. the offerer and answerer maintain routing tables that get updated each time an RTP/RTCP packet contains new info that affects how packets should be routed 🗺️.

however, some legacy implementations may not include this identification-tag in their RTP and RTCP traffic when using the BUNDLE mechanism, and instead use a mechanism based on the payload type to associate RTP streams with SDP "m=" sections 🕰️. in that situation, each "m=" section needs to use unique payload type values, so the payload type is a reliable indicator of the relevant "m=" section for the RTP stream 🔑. if an implementation fails to ensure unique payload type values, it will be impossible to associate the RTP stream using that payload type value with a particular "m=" section 😬. note that when using the payload type to associate RTP streams with "m=" sections, an RTP stream (identified by its SSRC) gets mapped to an "m=" section when the first packet of that stream is received, and the mapping won't change even if the payload type that stream uses changes. in other words, the SSRC cannot "move" to a different "m=" section just by changing the payload type 🚫🔁.

applications can implement RTP stacks in lots of different ways 🛠️. the algorithm below details one way RTP streams can be associated with "m=" sections, but it is not meant to be prescriptive about exactly how an RTP stack needs to be implemented. applications MAY use any algorithm that achieves equivalent results to the ones described below 🌷.

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

construct a table mapping a MID to an "m=" section for each "m=" section in this BUNDLE group. note that an "m=" section may only have one MID.
construct a table mapping 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.
construct a table mapping 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.
construct a table mapping 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 be used to uniquely identify an "m=" section 🙃.
note that 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 corresponding to its SSRC. that RTP stream MUST then be associated with the correct "m=" section within a BUNDLE group for additional processing, following these steps 💌:

if the MID associated with the RTP stream is not in the table mapping a MID to an "m=" section, then the RTP stream is not decoded and the payload data is 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.2), update the MID associated with the RTP stream to match the MID carried in the RTP packet, and 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 on the matching "m=" section. if so, associate the RTP stream with that "m=" section. otherwise, the RTP stream is not decoded and the payload data is 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, then each CSRC is looked up in the incoming SSRC table, and a copy of the RTP packet is associated with the corresponding "m=" section for additional 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, then associated with the appropriate "m=" sections, and processed for the RTP streams represented by those "m=" sections. this routing is type dependent, since each kind of RTCP packet has its own mechanism for linking it to the relevant RTP streams 🎯.

RTCP packets that cannot be associated with an appropriate m= section MUST still be processed as usual by the RTP layer, which updates the metadata for the matching RTP streams 📦✨ This can happen in certain multiparty RTP topologies, or when RTCP packets carry only a subset of the SDES information 🧩

Here are the extra rules for each kind of RTCP packet 💅

If the RTCP packet is of type SDES, then for each chunk whose SSRC is in the incoming SSRC table, deliver a copy of the SDES packet to the m= section linked to that SSRC 🎀 Also, for any SDES MID items in those chunks, if the MID is in the table that maps a MID to an m= section, update the incoming SSRC table with an entry that maps the RTP stream for that chunk's SSRC to the m= section linked to that MID. The one exception is when 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 inside 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 shows up before any RTP packets do 🫠 So it can be beneficial for an implementation to delay RTCP packet routing. It could either prioritize processing the SDES item to make 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 compound packet might not reach higher layers. The impact is likely minor, since that 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 is in the incoming SSRC table, first deliver a copy of the BYE packet to the m= section linked to that SSRC. Then remove that SSRC's entry from the incoming SSRC table, but only 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 in the outgoing SSRC table, deliver a copy of the SR or RR packet to the m= section linked to that SSRC. Also, if the packet is of type SR and the sender SSRC for the packet is in the incoming SSRC table, deliver a copy of the SR packet to the m= section linked to 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 in the outgoing SSRC table, deliver a copy of the XR packet to the m= section linked to that SSRC. Also, if the sender SSRC for the packet is in the incoming SSRC table, deliver a copy of the XR packet to the m= section linked to 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 will contain 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 those 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 in the outgoing SSRC table, deliver the feedback packet to the m= section linked to 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 is being sent by the message recipient. Notifications are responses to an earlier request, so they reference an RTP stream that is being received by the message recipient 💫
If the RTCP packet is a feedback request that includes target SSRC(s), then for each target SSRC in the outgoing SSRC table, deliver a copy of the RTCP packet to the m= section linked to 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 in the incoming SSRC table, deliver a copy of the RTCP packet to the m= section linked to 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 sent in response to a prior TSTR.
- Temporary Maximum Media Stream Bit Rate Notification (TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a notification sent in response to a prior TMMBR, but it can also be sent unsolicited.

If the RTCP packet is of type APP, it is handled in an application-specific manner 🧚 If the application does not recognize the APP packet, then it MUST be discarded 🗑️

9.3. RTP/RTCP Multiplexing ✨

Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP multiplexing [RFC5761] for the RTP-based bundled media. In other words, the same transport is used for both RTP packets and RTCP packets 🎀 In addition, the offerer and answerer MUST support the SDP rtcp-mux-only attribute [RFC8858] 🫶

9.3.1. SDP Offer/Answer Procedures 💖

This section describes how an offerer and answerer use the SDP rtcp-mux [RFC5761] and SDP rtcp-mux-only [RFC8858] attributes to negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media 🌈

RTP/RTCP multiplexing only applies to RTP-based media. However, as described in Section 7.1.3, within an offer or answer, the SDP rtcp-mux and SDP rtcp-mux-only attributes might be included in a bundled m= section for non-RTP-based media. This is the case if that m= section is the offerer-tagged m= section or the answerer-tagged m= section 🍓

9.3.1.1. Generating the Initial SDP BUNDLE Offer 🌸

When an offerer generates an initial BUNDLE offer, if the offer contains one or more bundled m= sections for RTP-based media (or if there's a chance that m= sections for RTP-based media will be added to the BUNDLE group later), the offerer MUST include an SDP rtcp-mux attribute [RFC5761] in each bundled m= section, excluding any bundle-only m= sections 📝 In addition, the offerer MAY include an SDP rtcp-mux-only attribute [RFC8858] in one or more bundled m= sections for RTP-based media 🧁

NOTE: Whether the offerer includes the SDP rtcp-mux-only attribute depends on whether the offerer supports falling back to a separate port for RTCP, in case the answerer moves one or more m= sections for RTP-based media out of the BUNDLE group in the answer 🔁

NOTE: If the offerer includes an SDP rtcp-mux attribute in the bundled m= sections but does not include an SDP rtcp-mux-only attribute, the offerer can also include 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]. However, the fallback port will only be applied to m= sections for RTP-based media 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 m= section for RTP-based media (excluding a bundle-only m= section), just like it is for RTP 🔐

9.3.1.2. Generating the SDP Answer 💌

When an answerer generates an answer, if the answerer supports RTP-based media, and if a bundled m= section in the corresponding offer contained an SDP rtcp-mux attribute, the answerer MUST enable usage of RTP/RTCP multiplexing. This applies even if there are currently no bundled m= sections for RTP-based media within the BUNDLE group 🙌 The answerer MUST include an SDP rtcp-mux attribute in the answerer-tagged m= section, following the procedures for BUNDLE attributes (Section 7.1.3). In addition, if the m= section selected as the offerer-tagged m= section contained an SDP rtcp-mux-only attribute, the answerer MUST include an SDP rtcp-mux-only attribute in the answerer-tagged m= section 💅

In an initial BUNDLE offer, if the suggested offerer-tagged m= section contained an SDP rtcp-mux-only attribute, that m= section was for RTP-based media. So the answerer does not accept the m= section in the created BUNDLE group. Instead, the answerer MUST move the m= section out of the BUNDLE group (Section 7.3.2), include the attribute in the moved m= section, and enable RTP/RTCP multiplexing for the media associated with that m= section. Or it can reject the m= section (Section 7.3.3) 😤

The answerer MUST NOT include an SDP rtcp attribute in any bundled m= section in the answer 🚫 The answerer will use the port value of the offerer-tagged m= section for sending RTP and RTCP packets associated with RTP-based bundled media towards the offerer 📮

If RTP/RTCP multiplexing within a BUNDLE group was already negotiated in a previous offer/answer exchange, the answerer MUST include an SDP rtcp-mux attribute in the answerer-tagged m= section. It's not possible to disable RTP/RTCP multiplexing within a BUNDLE group 🔒

9.3.1.3. Offerer Processing of the SDP Answer 🎁

When an offerer receives an answer, if the answerer has accepted the usage of RTP/RTCP multiplexing (Section 9.3.1.2), the answerer follows the procedures for RTP/RTCP multiplexing defined in [RFC5761]. The offerer will use the port value of the answerer-tagged m= section for sending RTP and RTCP packets associated with RTP-based bundled media towards the answerer 🏹

NOTE: It is considered a protocol error if the answerer has not accepted the usage of RTP/RTCP multiplexing for RTP-based m= sections that the answerer included in the BUNDLE group 🚨

9.3.1.4. Modifying the Session 🦄

When an offerer generates a subsequent offer, the offerer MUST include an SDP rtcp-mux attribute in the offerer-tagged m= section. This follows the procedures for IDENTICAL multiplexing category attributes in Section 7.1.3 ✨

10. ICE Considerations 🧊

okay so this section is all about how to use BUNDLE together with ICE [RFC8445] 🫶

The generic procedures for negotiating ICE using SDP from [RFC8839] also apply when you pair ICE with BUNDLE, with a few exceptions 💅

once the BUNDLE transport is up, ICE connectivity checks and keepalives only need to run on the BUNDLE transport, not on every single bundled "m=" section in the group ✨
the generic SDP attribute offer/answer rules (Section 7.1.3) cover ICE-related attributes too 💖. So when an offerer sends an initial BUNDLE offer to negotiate a BUNDLE group, it 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 later one) with a BUNDLE group, or an offerer sends a later offer with a BUNDLE group, the ICE-related media-level attributes only go in the tagged "m=" section (the suggested offerer-tagged "m=" section or the answerer-tagged "m=" section). The ICE properties then apply to every bundled "m=" section in the BUNDLE group 🦋

NOTE: most ICE-related media-level SDP attributes belong to the TRANSPORT multiplexing category [RFC8859], and the generic SDP attribute offer/answer rules for that category apply to them 🌸. For ICE-related attributes, though, the same rules also apply to the 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 📝

Before ICE has picked the selected candidate pairs that will carry media, there might be several transports up at once (if several candidate pairs are being tested) 🧪. Once ICE has selected candidate pairs, those pairs form the BUNDLE transport 👑

Using ICE together with the BUNDLE extension is OPTIONAL 🌈. The procedures in this section only kick in when ICE is actually used. Also, applications might require ICE even when BUNDLE isn't used 💜

NOTE: if Trickle ICE [RFC8840] is used, an offerer and answerer might put a port value of 9 and an IPv4 address of 0.0.0.0 (or the IPv6 equivalent, ::) on multiple bundled "m=" sections in the initial BUNDLE offer 🍓. They still follow the normal offer and 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 no media can be sent until at least one candidate has been provided ⭐. Once a BUNDLE group is negotiated, any trickled candidates tied to one bundled "m=" section get applied to all the bundled "m=" sections in the BUNDLE group ✨

11. DTLS Considerations 🔐

One or more media streams in a BUNDLE group might use Datagram Transport Layer Security (DTLS) [RFC6347] to encrypt the data, or to negotiate encryption keys if some other 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] for the whole BUNDLE group 💅;
every use of the DTLS association within the BUNDLE group MUST use the same mechanism for deciding which endpoint (the offerer or the answerer) becomes the DTLS client and which becomes the DTLS server 🎀;
every use of the DTLS association within the BUNDLE group MUST use the same mechanism for deciding whether an offer or answer will trigger a brand-new DTLS association or reuse an existing one 🦋; and
if the DTLS client supports DTLS-SRTP, it MUST include the use_srtp extension in its DTLS ClientHello message [RFC5764]. The client MUST include the extension even if DTLS-SRTP 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 later, in case DTLS-SRTP encrypted media gets added to the BUNDLE group partway through the multimedia session 🧠✨

12. RTP Header Extensions Consideration 🧩

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

13. Update to RFC 3264 📣

this section updates RFC 3264 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 🌷. The following 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.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph

Here's the original text, kept verbatim so nobody gets confused 📜

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, 2nd Paragraph

okay so for recvonly and sendrecv streams, the port and address in the offer say where the offerer wants to receive the media 📡. For sendonly RTP streams, the address and port indirectly say where the offerer wants to get RTCP reports, and unless it's explicitly said otherwise, those reports go to the port one higher than the one listed 🎯. The IP address and port in the offer tell you nothing about the source IP address and source port of the RTP and RTCP packets the offerer will send 🙈. By default, a port of zero in the offer means the stream is offered but MUST NOT be used 🛑, though an extension mechanism might define different semantics for a zero port value 🧚. Existing streams can still be shut down by setting the port to zero (Section 8). Generally, by default, a zero port means the media stream isn't wanted 💀

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

Here's the original text again, verbatim 📜

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.

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

so RFC 2543 [RFC2543] said that putting a user on hold meant setting the connection address to 0.0.0.0 🙃. Using that for holding a call is no longer recommended 🚫, since it doesn't let RTCP work with held streams, doesn't work with IPv6, and breaks connection-oriented media. It can still be handy in an initial offer when the offerer knows which media streams and formats it wants but doesn't know the addresses and ports yet 🧃. When it's used, though, the port number MUST NOT be zero if that would mean the stream is disabled 🙅‍♀️. An extension mechanism might define different semantics for zero port usage 🌈. Every agent MUST be able to receive SDP with a connection address of 0.0.0.0, and when it does, that means neither RTP nor RTCP is to be sent to the peer 💜

14. Update to RFC 5888 🎀

this section updates RFC 5888 [RFC5888] so that extensions can let an SDP 'group' attribute include an identification-tag that identifies an "m=" section whose port is set to zero. "Group Value in Answers" (Section 9.2 of [RFC5888]) is updated 🦋

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

Here's the original text, verbatim 📜

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, 3rd Paragraph

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 define different semantics for including identification-tags that correspond to such "m=" lines ✨

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

Okay so bestie, offerers and answerers ([RFC3264]) can slap identification-tags onto their "m=" sections inside offers and answers, using the procedures in [RFC5888] 💅 Each identification-tag uniquely represents one "m=" section. Iconic. 🦋

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] 🌸, which carries that 'MID' RTCP SDES item inside RTP packets. The whole point is giving receivers a way to match each RTP stream to the right "m=" section 💖, even when all those "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 they can route it to the correct application. No cap, that's clutch. 👑

A media recipient tells the media sender which identification-tag goes with which "m=" section by using an 'id' attribute [RFC5888] 🧚. The media sender then stuffs that identification-tag into the RTCP and RTP packets it sends back 🍓.

NOTE: All of the above explains how identification-tags travel in offers and answers. Using other signaling protocols to carry identification-tags is not forbidden 🙈, but those protocols are totally outside the scope of this document.

[RFC3550] sets out 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 keep being sent regularly after that 💜. Exactly how many RTCP packets carry this SDES item is intentionally left unspecified 🤷‍♀️, because it depends on the expected packet-loss rate, the RTCP reporting interval, and how much overhead is allowed 💅.

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 handy to include the header extension in RTP packets that are access points in the media (like video I-frames) 🎀. Exactly how many RTP packets get this header extension is intentionally unspecified too, since it depends on 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 🌸.

For robustness 🛡️, endpoints need to be ready for the identification-tag to show up late, and they SHOULD NOT terminate sessions in that case 🙅‍♀️, because the identification-tag is likely to arrive soon 🥹.

15.1. RTCP MID SDES Item 💌

    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 🌍.

The identification-tag is not zero terminated 🙌.

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 using either the 1-byte or the 2-byte header [RFC7941] ✨. The identification-tag payload is UTF-8 encoded, just like in SDP 💖.

The identification-tag is not zero terminated 🙅‍♀️. Also note that the set of header extensions in the packet needs to be padded out to the next 32-bit boundary using zero bytes [RFC8285] 🧸.

Since the identification-tag gets included in an RTCP SDES item, an RTP SDES header extension, or both 🤓, we need to think about the packet expansion it causes. To avoid Maximum Transmission Unit (MTU) issues for RTP packets 🚧, the header extension's size has to be taken into account when encoding the media 💅.

It is recommended that the identification-tag be kept short 🍓. Because of how the RTP header extension mechanism works, when using the 1-byte header, a tag that is 1-3 bytes gives a minimal number of 32-bit words for the RTP SDES header extension 🎀, as long as no other header extensions are included at the same time. Heads up though, some single characters take up multiple octets once UTF-8 encoded 👀. The identification-tag MUST NOT contain any user information 🙈, and applications SHALL avoid generating the identification-tag using a pattern that makes it possible to identify a user or application 🔒.

16. IANA Considerations 📋

16.1. New SDES Item 🌷

This document adds the MID SDES item to the IANA "RTP SDES Item Types" registry as follows:

   Value:  15

   Abbrev.:  MID

   Name:  Media Identification

   Reference:  RFC 8843

16.2. New RTP SDES Header Extension URI 🔗

This document defines a new extension URI in the RTP SDES Compact Header Extensions sub-registry of the RTP Compact Header Extensions registry sub-registry, according to the following data:

   Extension URI:  urn:ietf:params:rtp-hdrext:sdes:mid

   Description:  Media identification

   Contact:  IESG (iesg@ietf.org)

   Reference:  RFC 8843

The SDES item does not reveal privacy information about the users 🥰. It's simply used to match RTP-based media with the correct SDP media description ("m=" section) in the SDP used to negotiate the media 🎯.

The whole purpose of the extension is so the offerer can match up received multiplexed RTP-based media before the offerer gets the associated answer 💜.

16.3. New SDP Attribute 🎀

This document defines a new SDP media-level attribute, 'bundle-only', according to the following 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 8843

   Mux category:  NORMAL

16.4. New SDP Group Semantics 🌈

This document registers the following semantics with IANA in the "Semantics for the 'group' SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry):

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

                          Table 1

17. Security Considerations 🔐

Okay, serious moment bestie 😭. The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension 🛡️. BUNDLE does not change which information flows over the network (e.g., RTP streams), with the exception of the usage of the MID SDES item discussed below 🌊. Mainly, it changes which addresses and ports, and therefore which (RTP) sessions, the information flows to 🗺️. That affects the security contexts being used and can cause previously separated information flows to share the same security context 😳. It has very little impact on the performance of the security mechanism of the RTP sessions 🏎️. In cases where you'd have applied different security policies to the different bundled RTP streams, or where the parties with access to the security contexts would have differed between the RTP streams, you need additional analysis of the implications before choosing to apply BUNDLE 🧐.

The identification-tag can expose its value to parties beyond the signaling chain 👀, no matter the transport, RTCP SDES packet, or RTP header extension it's in. So identification-tag values MUST be generated in a way that does not leak user information (e.g., randomly or using a per-bundle group counter) 🎲, and SHOULD be 3 bytes or less so they fit efficiently into the MID RTP header extension 📦. Note that if implementations use different methods for generating identification-tags, that could enable fingerprinting of the implementation, making it vulnerable to targeted attacks 🚨. The identification-tag is exposed at the RTP stream level when it's included in the RTP header extensions 📡. However, what it reveals about the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header extensions 🕵️‍♀️. Since the identification-tag is also used to route the media stream to the right application functionality, it's important that the value received is the one the sender intended 🎯. So integrity and authenticity of the source matter a lot to prevent denial of service on the application 🙅‍♀️. Existing SRTP configurations and other security mechanisms that protect the whole RTP/RTCP packets will provide the necessary protection 🔒.

When the BUNDLE extension is used, the set of configurations of the security mechanism used in all the bundled media descriptions needs to be compatible, so they can be used at the same time, at least per direction or endpoint 🤝. When using SRTP, this will be 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] require that when RTCP is confidentiality protected, any SDES RTP header extension carrying an SDES item (like the MID RTP header extension) is also protected using commensurate strength algorithms 🔐. However, as long as the above requirements and recommendations are followed, there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection 🥳. So this specification updates RFC 7941 by adding the exception that 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] 📚. For example, SRTP [RFC3711] can provide the necessary security functions of ensuring integrity and source authenticity 💜.

18. Examples 🍭

18. Examples 🎀

18.1. Example: Tagged "m=" Section Selections

okay bestie, this one is a whole BUNDLE party 🎉 It shows:

An initial BUNDLE offer 💖 The offerer wants to negotiate a BUNDLE group and suggests the audio m= section as the offerer-tagged m= section.
An initial BUNDLE answer ✨ The answerer accepts the creation of the BUNDLE group, picks the audio m= section from the offer as the offerer-tagged m= section, picks the audio m= section in the answer as the answerer-tagged m= section, and gives 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 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

18.2. Example: BUNDLE Group Rejected

this one is the "nah, we're not bundling" plot twist 🙈 It shows:

An initial BUNDLE offer 🌸 The offerer wants to negotiate a BUNDLE group and suggests the audio m= section as the offerer-tagged m= section.
An initial BUNDLE answer 💅 The answerer rejects the creation of the BUNDLE group, generates 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

ooh, a glow-up mid-call ✨ It shows:

A subsequent offer 🦋 The offerer adds a new bundled m= section (video), identified by the zen identification-tag, to a previously negotiated BUNDLE group. It marks the new m= section as the offerer-tagged m= section and gives the offerer BUNDLE address:port to that m= section.
A subsequent answer 🧚 The answerer marks the new video m= section in the answer as the answerer-tagged m= section and gives 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 zen foo bar

    m=audio 0 RTP/AVP 0 8 97
    b=AS:200
    a=mid:foo
    a=bundle-only
    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

    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 0 RTP/AVP 0
    b=AS:200
    a=mid:foo
    a=bundle-only
    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

    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 "bye, you're leaving the group" arc 💀 It shows:

A subsequent offer 🌈 The offerer removes an m= section (video), identified by the zen identification-tag, from a previously negotiated BUNDLE group. It marks one of the bundled m= sections that stays in the BUNDLE group (audio) as the offerer-tagged m= section and gives the offerer BUNDLE address:port to that m= section.
A subsequent answer 👑 The answerer removes the m= section from the BUNDLE group, marks the audio m= section in the answer as the answerer-tagged m= section, and gives 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 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

    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 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

    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

last one, and it's a quiet exit 🥀 It shows:

A subsequent offer 🍓 The offerer disables an m= section (video), identified by the zen identification-tag, by assigning it a zero port value. That section is part of a previously negotiated BUNDLE group. The offerer marks one of the bundled m= sections that remains active in the BUNDLE group (audio) as the offerer-tagged m= section and gives the offerer BUNDLE address:port to that m= section.
A subsequent answer 💜 The answerer disables the m= section, marks the audio m= section in the answer as the answerer-tagged m= section, and gives 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 0 RTP/AVP 31 32
    c=IN IP6 2001:db8::3
    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

    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 0 RTP/AVP 32
    c=IN IP6 2001:db8::1
    b=AS:1000
    a=mid:bar
    a=bundle-only
    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

[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://tools.ietf.org/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>.

Appendix A. Design Considerations 🎀

okay bestie, this appendix is the "why did we do it this way" tea ☕🦋 The big debate around the BUNDLE grouping extension was whether offers and answers can put the same port value in the "m=" lines of a BUNDLE group. Like, the whole point is to negotiate one transport for all the media in those "m=" sections, so people argued hard about it 😭 Both approaches came with issues (we'll walk through them here 🧚), and the final call was a mechanism that works with offers using both different AND identical port values. Iconic compromise energy 💅

Here are the main things the team considered when they were defining BUNDLE:

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

A.1. UA Interoperability 💖

okay so picture this: Alice sends an offer to Bob. Here's what that 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

Now the plot twist 🙈 RFC 4961 covers symmetric RTP, but it's a later extension to RTP, so Bob can't just assume Alice supports it. That means Alice might be sending RTP from a port that isn't 10000 or 10002. Some implementations literally just send from an ephemeral port 🥲 So when Bob's endpoint gets an RTP packet, the only way it knows whether that packet goes to the video or audio codec is by checking which port it arrived on.

This is where things get messy. Some implementations use the port number as a lookup key to find the right "m=" line, since every "m=" section has its own port number. So even implementations that DO support symmetric RTP and ICE can still be built around an SDP data structure like this one, which has "m=" sections sharing the same port:

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

And the result? The second "m=" section gets treated as an SDP error, because it uses the same port as the first line. That's the bad vibe BUNDLE had to think about 😭🔥

That's the whole appendix, bestie. Thanks for sticking with the tea ✨💜

A.2. Usage of Port Number Value Zero

okay so, in an offer or answer, the media in an m= section can be disabled or rejected by setting its port number to 0 🙅‍♀️. this is different from stuff like the SDP direction attributes, where RTCP keeps flowing even when the inactive attribute is on that m= section 📡. the traffic just doesn't stop 💀

now picture a BUNDLE group where each m= section has its own port value 🎀. if one of those ports gets used as the BUNDLE address:port, things get messy the second an endpoint tries to disable or reject the m= section tied to that port by setting it to 0. after that, no m= section would have the port that's being used for the BUNDLE address:port 😱. and it's unclear what happens to the ICE candidates tied to that m= section, since they're also used for the BUNDLE address:port 🫠

A.3. B2BUA and Proxy Interoperability

some back-to-back user agents (B2BUAs) can be 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 🙈. say the B2BUA doesn't understand the SDP rtcp attribute, which is defined in RFC 3605, and it acts this way anyway. say it's also set up to tear down any call where it doesn't see RTCP for 5 minutes. if it gets 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'd be looking for RTCP on port 49171 and wouldn't see any, because the RTCP is actually on port 53020. after five minutes, it tears down the call 😭

similarly, a B2BUA that doesn't understand BUNDLE but still puts it in its offer may be looking for media on the wrong port, and then it tears down the call too 📞💔. worth noting: a B2BUA that 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 the IP address and port) to control traffic gating and set traffic policing rules. there might be rules that end a session if media isn't sent or received on the ports retrieved from the SDP. this typically happens once the session is already established and ongoing 🚦

A.3.2. Bandwidth Allocation

sometimes intermediaries aren't B2BUAs either 🙃. they may still use SDP info (like codecs and media types) to control bandwidth allocation. the bandwidth is allocated per m= section, which means it might not be enough if the media in all the m= sections tries to use that bandwidth at once. that can lead to 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 🧭. each extra m= section adds about 20 ms because of NAT pacing requirements. all of this gathering can overlap with other stuff, like a web page loading, so the impact stays small ✨. if the 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 of the m= sections, it MAY do that and won't need any extra gathering time 🏃‍♀️💨

some people have suggested a TURN extension to get a bunch of TURN allocations at once 🤔. that would only provide a single STUN result. so if the other end didn't support BUNDLE, it may cause more use of the TURN server. but it'd be quick when both sides support BUNDLE, and it would 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 described in this document is based on the different alternative proposals, and the text (for example, the SDP examples) has been borrowed (and, in some cases, modified) from those alternative proposals.

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

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 providing 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 providing help and 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 👑

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
400 3rd Avenue SW, Suite 350
Calgary AB T2P 4H2
Canada

Email: fluffy@iii.ca

📦 where this page comes from

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

RFC 8843

RFC 8843: Negotiating Media Multiplexing Using the Session Description Protocol (SDP) ✨

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. Contradiction regarding bundle-only "m=" sections

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 SDP Offer 🍓

7.2.1. Suggesting the Offerer-Tagged 'm=' Section 🎀

7.2.2. Example: Initial SDP 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.4. Offerer Processing of the SDP Answer 🌸

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 💀

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 SDP 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. Update to RFC 3264 📣

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

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

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

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

14. Update to RFC 5888 🎀

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

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

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. New SDES Item 🌷

16.2. New RTP SDES Header Extension URI 🔗

16.3. New SDP Attribute 🎀

16.4. New SDP Group Semantics 🌈

17. Security Considerations 🔐

18. Examples 🍭

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