• 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 kept within a BUNDLE group.
• updates RFC 3264 [RFC 3264] 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 [RFC 3550] SDES item, Media Identification ('MID'), and a new RTP SDES header extension that can be used to associate RTP streams with "m=" sections.
• updates [RFC 7941] 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.
• updates [RFC 5888] by allowing an SDP 'group' attribute to contain an identification-tag that identifies an "m=" section with the port value set to zero.

"m=" section:

SDP bodies contain one or more media descriptions, referred to as "m=" sections. Each "m=" section is represented by an SDP "m=" line and zero or more SDP attributes associated with the "m=" line. A local address:port combination is assigned to each "m=" section.

5-tuple:

A collection of the following values: source address, source port, destination address, destination port, and transport-layer protocol.

Unique address:port:

An address:port combination that is assigned 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 identified by the offerer BUNDLE-tag in an initial BUNDLE offer, before a BUNDLE group has been negotiated.

Offerer-tagged "m=" section:

The bundled "m=" section identified by the offerer BUNDLE-tag in a subsequent offer. The "m=" section contains characteristics (offerer BUNDLE address:port and offerer BUNDLE attributes) that are applied to each "m=" section within the BUNDLE group.

Answerer-tagged "m=" section:

The bundled "m=" section identified by the answerer BUNDLE-tag in an answer (initial BUNDLE answer or subsequent). The "m=" section contains characteristics (answerer BUNDLE address:port and answerer BUNDLE attributes) that are applied to each "m=" section within the BUNDLE group.

BUNDLE address:port:

An address:port combination that an endpoint uses for sending and receiving bundled media.

Offerer BUNDLE address:port:

The address:port combination used by the offerer for sending and receiving media.

Answerer BUNDLE address:port:

The address:port combination used by the answerer for sending and receiving media.

BUNDLE attributes:

IDENTICAL and TRANSPORT multiplexing category SDP attributes. Once a BUNDLE group has been created, the attribute values apply to each bundled "m=" section within the BUNDLE group.

Offerer BUNDLE attributes:

IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the offerer-tagged "m=" section.

Answerer BUNDLE attributes:

IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the answerer-tagged "m=" section.

BUNDLE transport:

The transport (5-tuple) used by all media described by the "m=" sections within a BUNDLE group.

BUNDLE group:

A set of bundled "m=" sections, created using an SDP offer/answer exchange, that uses a single BUNDLE transport and a single set of BUNDLE attributes for sending and receiving all media (bundled media) described by the set of "m=" sections. The same BUNDLE transport is 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 media associated with a given BUNDLE group.

Initial BUNDLE offer:

The first offer, within an SDP session (e.g., a SIP dialog when SIP [RFC 3261] is used to carry SDP), in which the offerer indicates that it wants to negotiate a given BUNDLE group.

Initial BUNDLE answer:

The answer to an initial BUNDLE offer in which the offerer indicates that it wants to negotiate a BUNDLE group, and the answerer accepts the creation of the BUNDLE group. The BUNDLE group is created once the answerer sends the initial BUNDLE answer.

Subsequent offer:

An offer that contains a BUNDLE group that has been created as part of a previous offer/answer exchange.

Subsequent answer:

An answer to a subsequent offer.

Identification-tag:

A unique token value that is used to identify an "m=" section. The SDP 'mid' attribute [RFC 5888] in an "m=" section carries the unique identification-tag assigned to that "m=" section. The session-level SDP 'group' attribute [RFC 5888] carries a list of identification-tags, identifying the "m=" sections associated with that particular 'group' attribute.

Name:

bundle-only

Value:

N/A

Usage Level:

media

Charset Dependent:

no

Example:

a=bundle-only

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 [RFC 8285], with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value defined in this specification in each bundled RTP-based "m=" section in every offer and answer.
• A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=" sections.

• 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, do not include it in the table, as it cannot 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.

• 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 RFC 7941, Section 4.2.6, 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 in 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. Associate the RTP stream with the corresponding "m=" section.
• Otherwise, mark the RTP stream as "not for decoding" and discard the payload.

• If the RTCP packet is of type SDES, for each chunk in the packet whose SSRC is found in the incoming SSRC table, deliver a copy of the SDES packet to the "m=" section associated with that SSRC. In addition, for any SDES MID items contained in these chunks, if the MID is found in the table mapping a MID to an "m=" section, update the incoming SSRC table to include an entry that maps the RTP stream associated with the chunk's SSRC to the "m=" section associated with that MID, unless the packet is older than the packet that most recently updated the mapping for this SSRC, as discussed in RFC 7941, Section 4.2.6.
• Note that if an SDES packet is received as part of a compound RTCP packet, the SSRC to "m=" section mapping might not exist until the SDES packet is handled (e.g., in the case where RTCP for a source is received before any RTP packets). Therefore, it can be beneficial for an implementation to delay RTCP packet routing, such that it either prioritizes processing of the SDES item to generate or update the mapping or buffers the RTCP information that needs to be routed until the SDES item(s) has been processed. If the implementation is unable to follow this recommendation, the consequence could be that some RTCP information from this particular RTCP compound packet is not provided to higher layers. The impact from this is likely minor when this information relates to a future incoming RTP stream.
• If the RTCP packet is of type BYE, it indicates that the RTP streams referenced in the packet are ending. Therefore, for each SSRC indicated in the packet that is found in the incoming SSRC table, first deliver a copy of the BYE packet to the "m=" section associated with that SSRC, and then remove the entry for that SSRC from the incoming SSRC table after an appropriate delay to account for "straggler packets", as specified in RFC 3550, Section 6.2.1.
• If the RTCP packet is of type sender report (SR) or receiver report (RR), for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the SR or RR packet to the "m=" section associated with that SSRC. In addition, if the packet is of type SR and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the SR packet to the "m=" section associated with that SSRC.
• If the implementation supports the RTCP Extended Report (XR) and the packet is of type XR, as defined in [RFC 3611], for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC. In addition, if the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC.
• If the RTCP packet is a feedback message of type RTPFB (transport-layer FB message) or PSFB (payload-specific FB message), as defined in [RFC 4585], it will contain a media source SSRC, and this SSRC is used for routing certain subtypes of feedback messages. However, several subtypes of PSFB and RTPFB messages include a target SSRC(s) in a section called Feedback Control Information (FCI). For these messages, the target SSRC(s) is used for routing.
• If the RTCP packet is a feedback packet that does not include target SSRCs in its FCI section, and the media source SSRC is found in the outgoing SSRC table, deliver the feedback packet to the "m=" section associated with that SSRC. RTPFB and PSFB types that are handled in this way include:

  Generic NACK:

  (PT=RTPFB, FMT=1) [RFC 4585]

  Picture Loss Indication (PLI):

  (PT=PSFB, FMT=1) [RFC 4585]

  Slice Loss Indication (SLI):

  (PT=PSFB, FMT=2) [RFC 4585]

  Reference Picture Selection Indication (RPSI):

  (PT=PSFB, FMT=3) [RFC 4585]

• If the RTCP packet is a feedback message that does include a target SSRC(s) in its FCI section, it can either be a request or a notification. Requests reference an RTP stream that is being sent by the message recipient, whereas notifications are responses to an earlier request and therefore reference an RTP stream that is being received by the message recipient.
• If the RTCP packet is a feedback request that includes a target SSRC(s), for each target SSRC that is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with that SSRC. PSFB and RTPFB types that are handled in this way include:

  Full Intra Request (FIR):

  (PT=PSFB, FMT=4) [RFC 5104]

  Temporal-Spatial Trade-off Request (TSTR):

  (PT=PSFB, FMT=5) [RFC 5104]

  H.271 Video Back Channel Message (VBCM):

  (PT=PSFB, FMT=7) [RFC 5104]

  Temporary Maximum Media Stream Bit Rate Request (TMMBR):

  (PT=RTPFB, FMT=3) [RFC 5104]

  Layer Refresh Request (LRR):

  (PT=PSFB, FMT=10) [LLR-RTCP].

• If the RTCP packet is a feedback notification that includes a target SSRC(s), for each target SSRC that is found in the incoming SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with the RTP stream with a matching SSRC. PSFB and RTPFB types that are handled in this way include:

  Temporal-Spatial Trade-off Notification (TSTN):

  (PT=PSFB, FMT=6) [RFC 5104]. This message is a notification in response to a prior TSTR.

  Temporary Maximum Media Stream Bit Rate Notification (TMMBN):

  (PT=RTPFB, FMT=4) [RFC 5104]. This message is a notification in response to a prior TMMBR, but it can also be sent unsolicited.

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

• When the BUNDLE transport has been established, ICE connectivity checks and keepalives only need to be performed for the BUNDLE transport, instead of per individual bundled "m=" section within the BUNDLE group.
• The generic SDP attribute offer/answer considerations (Section 7.1.3) also apply to ICE-related attributes. Therefore, when an offerer sends an initial BUNDLE offer (in order to negotiate a BUNDLE group), the offerer includes ICE-related media-level attributes in each bundled "m=" section (excluding any bundle-only "m=" sections), and each "m=" section MUST contain unique ICE properties. When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group and when an offerer sends a subsequent offer that contains a BUNDLE group, ICE-related media-level attributes are only included in the tagged "m=" section (suggested offerer-tagged "m=" section or answerer-tagged "m=" section), and the ICE properties are applied to each bundled "m=" section within the BUNDLE group.

• There can only be one DTLS association [RFC 6347] associated with the BUNDLE group;
• Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for determining which endpoints (the offerer or answerer) become DTLS client and DTLS server;
• Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for determining whether an offer or answer will trigger the establishment of a new DTLS association or if an existing DTLS association will be used instead; and
• If the DTLS client supports DTLS-SRTP, it MUST include the 'use_srtp' extension in the DTLS ClientHello message [RFC 5764]. The client MUST include the extension even if the usage of DTLS-SRTP is not negotiated as part of the multimedia session (e.g., the SIP session [RFC 3261]).

• "Unicast Streams"; see Section 5.1 of RFC 3264.
• "Putting a Unicast Media Stream on Hold"; see Section 8.4 of RFC 3264.

Value:

15

Abbrev.:

MID

Name:

Media Identification

Reference:

RFC 9143

Extension URI:

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

Description:

Media identification

Contact:

IESG (iesg@ietf.org)

Reference:

RFC 9143

Attribute name:

bundle-only

Type of attribute:

media

Subject to charset:

No

Purpose:

Request a media description to be accepted in the answer only if kept within a BUNDLE group by the answerer.

Appropriate values:

N/A

Contact name:

IESG

Contact e-mail:

iesg@ietf.org

Reference:

RFC 9143

Mux category:

NORMAL

• An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group and indicates the audio "m=" section as the suggested offerer-tagged "m=" section.
• An initial BUNDLE answer, in which the answerer accepts the creation of the BUNDLE group, selects the audio "m=" section in the offer as the offerer-tagged "m=" section, selects the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section.

    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

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

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

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

• An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group and indicates the audio "m=" section as the suggested offerer-tagged "m=" section.
• An initial BUNDLE answer, in which the answerer rejects the creation of the BUNDLE group, generates a normal answer, and assigns a unique address:port to each "m=" section in the answer.

    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

    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

• A subsequent offer, in which the offerer adds a new bundled "m=" section (video), indicated by the "zen" identification-tag, to a previously negotiated BUNDLE group; indicates the new "m=" section as the offerer-tagged "m=" section; and assigns the offerer BUNDLE address:port to that "m=" section.
• A subsequent answer, in which the answerer indicates the new video "m=" section in the answer as the answerer-tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section.

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

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

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

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

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

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

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

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

• A subsequent offer, in which the offerer removes an "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group; indicates one of the bundled "m=" sections (audio) remaining in the BUNDLE group as the offerer-tagged "m=" section; and assigns the offerer BUNDLE address:port to that "m=" section.
• A subsequent answer, in which the answerer removes the "m=" section from the BUNDLE group, indicates the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section.

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

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

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

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

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

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

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

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

• A subsequent offer, in which the offerer disables (by assigning a zero port value) an "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group; indicates one of the bundled "m=" sections (audio) remaining active in the BUNDLE group as the offerer-tagged "m=" section; and assigns the offerer BUNDLE address:port to that "m=" section.
• A subsequent answer, in which the answerer disables the "m=" section, indicates the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section.

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

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

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

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

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

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

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

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

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3264]

J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.

[RFC3550]

H. Schulzrinne, S. Casner, R. Frederick, 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]

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

[RFC3629]

F. Yergeau, "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]

M. Baugher, D. McGrew, M. Naslund, E. Carrara, 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]

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

[RFC4961]

D. Wing, "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<https://www.rfc-editor.org/info/rfc4961>.

[RFC5761]

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

[RFC5764]

D. McGrew, 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]

G. Camarillo, 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]

E. Rescorla, 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]

M. Westerlund, B. Burman, R. Even, 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]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8285]

D. Singer, H. Desineni, and R. Even, "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>.

[RFC8445]

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

[RFC8839]

M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, 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]

E. Ivov, T. Stach, E. Marocco, 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]

C. Holmberg, "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]

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

[Err6431]

RFC Errata, "Erratum ID 6431",
<https://www.rfc-editor.org/errata/eid6431>.

[Err6437]

RFC Errata, "Erratum ID 6437",
<https://www.rfc-editor.org/errata/eid6437>.

[LLR-RTCP]

Google, Inc., , , , , and , "The Layer Refresh Request (LRR) RTCP Feedback Message", Internet-Draft draft-ietf-avtext-lrr-07, July 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07>.

[RFC2543]

M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, DOI 10.17487/RFC2543, March 1999,
<https://www.rfc-editor.org/info/rfc2543>.

[RFC3261]

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.

[RFC3611]

T. Friedman, R. Caceres, and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>.

[RFC4585]

J. Ott, S. Wenger, N. Sato, C. Burmeister, 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]

S. Wenger, U. Chandra, M. Westerlund, 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]

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

[RFC7160]

M. Petit-Huguenin, and G. Zorn, "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]

M. Westerlund, and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.

[RFC7656]

J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, and B. Burman, "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]

D. Black, 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]

J. Uberti, C. Jennings, and E. Rescorla, "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021,
<https://www.rfc-editor.org/info/rfc8829>.

[RFC8838]

E. Ivov, J. Uberti, and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/rfc8838>.

[RFC8843]

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

1)

Interoperability with existing User Agents (UAs).

2)

Interoperability with intermediary Back-to-Back User Agent (B2BUA) and proxy entities.

3)

The number of ICE candidates and the time to gather them.

4)

Different error scenarios and when they occur.

5)

SDP offer/answer impacts, including usage of port number value zero.

Christer Holmberg

Harald Tveit Alvestrand

Cullen Jennings