<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment --> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902"
     number="8843" category="std" docName="draft-ietf-mmusic-sdp-bundle-negotiation-54.txt" updates="3264,5888,7941"
     docName="draft-ietf-mmusic-sdp-bundle-negotiation-54" updates="3264, 5888, 7941" submissionType="IETF" xml:lang="en"> consensus="true" xml:lang="en" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3" >
  <!-- xml2rfc v2v3 conversion 2.36.0 -->

  <front>
    <title abbrev="Bundled media"> Media">
    Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
    </title>
    <seriesInfo name="RFC" value="8843"/>
    <author initials="C.H." initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <code>02420</code>
          <city>Jorvas</city>
          <country>Finland</country>
        </postal>
        <email>christer.holmberg@ericsson.com</email>
      </address>
    </author>
    <author fullname="Harald Tveit Alvestrand" surname="Alvestrand" initials="H. T."> initials="H." surname="Alvestrand">
      <organization>Google</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <city>Stockholm</city>
          <code>11122</code>
          <country>Sweden</country>
        </postal>
        <email>harald@alvestrand.no</email>
      </address>
    </author>
    <author fullname="Cullen Jennings" initials="C." surname="Jennings">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>400 3rd Avenue SW, Suite 350</street>
          <city>Calgary</city>
          <region>AB</region>
          <code>T2P 4H2</code>
          <country>Canada</country>
        </postal>
        <email>fluffy@iii.ca</email>
      </address>
    </author>
    <date year="2018" /> month="January" year="2021"/>
    <area>Transport</area>

    <workgroup>MMUSIC Working Group</workgroup>
    <keyword>RTP</keyword>
    <keyword>SDP</keyword>
    <keyword>Bundle</keyword>
    <keyword>Multiplexing</keyword>
    <keyword>RTCWEB</keyword>
    <keyword>CLUE</keyword>
    <keyword>RTCWEB</keyword>
    <keyword>MMUSIC</keyword>
    <keyword>AVT</keyword>
    <keyword>WEB</keyword>
    <keyword>Browser</keyword>

    <abstract>
      <t>
        This specification defines a new Session Description
        Protocol (SDP) Grouping Framework extension, extension called 'BUNDLE'.
        The extension can be used with the SDP Offer/Answer offer/answer mechanism
        to negotiate the usage of a single transport (5-tuple) for
        sending and receiving media described by multiple SDP media descriptions
        ("m=" sections). Such transport is referred to as a BUNDLE transport,
        and the media is referred to as bundled media. The "m=" sections that
        use the BUNDLE transport form a BUNDLE group.
      </t>
      <t>
        This specification updates RFC 3264, to also allow assigning a zero port value
        to a "m=" section in cases where the media described by the "m=" section
        is not disabled or rejected.
      </t>
      <t>
        This specification updates RFC 5888, to also allow an SDP 'group' attribute to
        contain an identification-tag that identifies a "m=" section with the port set to zero.
      </t>
      <t>
        This specification defines a new RTP Control Protocol (RTCP) source description Source
        Description (SDES) item and a new RTP header
        extension that can be used to correlate bundled RTP/RTCP packets
        with their appropriate "m=" section.
      </t> extension.</t>

      <t>
        This specification 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. RFCs 3264, 5888, and 7941.
     </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
    <section title="Background" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <section toc="default" numbered="true">
        <name>Background</name>
        <t>
        When the SDP offer/answer mechanism <xref format="default" pageno="false" target="RFC3264"/>
        is used to negotiate the establishment of multimedia communication sessions, if separate
        transports (5-tuples) are negotiated for each individual media stream, each transport consumes
        additional resources (especially when Interactive Connectivity Establishment (ICE)
        <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> is used).
        For this reason, it is attractive to use a single transport for multiple media streams.
        </t>
      </section>
      <section title="BUNDLE Mechanism" toc="default"> toc="default" numbered="true">
        <name>BUNDLE Mechanism</name>
        <t>
        This specification defines a way to use a single transport (BUNDLE transport)
        for sending and receiving media (bundled media) described by multiple SDP media descriptions
        ("m=" sections). The address:port combination used by an endpoint for sending and receiving
        bundled media is referred to as the BUNDLE address:port. The set of SDP attributes that are
        applied to each "m=" section within a BUNDLE group is referred to as BUNDLE attributes.
        The same BUNDLE transport is used for sending and receiving bundled media, which
        means that the symmetric Real-time Transport Protocol (RTP) mechanism <xref format="default"
       pageno="false" target="RFC4961"/> is always used for RTP-based bundled media.
        </t>

        <t>
        This specification defines a new SDP Grouping Framework <xref format="default" pageno="false" target="RFC5888"/> extension called 'BUNDLE'. The extension can be used with the Session Description
        Protocol (SDP) Offer/Answer mechanism <xref format="default" pageno="false" target="RFC3264"/>
        to negotiate which "m=" sections will become part of a BUNDLE group. In addition, the offerer and
        answerer <xref format="default" pageno="false" target="RFC3264"/> use the BUNDLE extension to negotiate
        the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUNDLE address:port) and the
        set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that will be applied to
        each "m=" section within the BUNDLE group.
        </t>

        <t>
        The use of a BUNDLE transport allows the usage of a single set of
        Interactive Connectivity Establishment (ICE)
        ICE <xref format="default" pageno="false"
        target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> candidates for the whole BUNDLE group.
        </t>
        <t>
        A given BUNDLE address:port MUST <bcp14>MUST</bcp14> 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 <xref format="default" pageno="false" target="RFC3550"/>.
        </t>
        <t>
        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, attribute and
        are expected to
        assign a unique address:port to each "m=" section within an offer and answer, according
        to the procedures in
       <xref format="default" pageno="false" target="RFC4566"/> target="RFC3264"/> and <xref format="default" pageno="false" target="RFC3264"/>. target="RFC4566"/>.
        </t>
      </section>
      <section title="Protocol Extensions" toc="default"> toc="default" numbered="true">
        <name>Protocol Extensions</name>
        <t>
        In addition to defining the new SDP Grouping Framework extension, this specification defines
        the following protocol extensions and RFC updates:
        <list style="symbols">
        <t>
          The specification updates.  This specification:
        </t>
        <ul spacing="normal">
          <li>
          defines a new SDP attribute, 'bundle-only', which can be used to
          request that a specific "m=" section (and the associated media) is be used only used if kept
          within a BUNDLE group.
        </t>
        <t>
          The specification
        </li>
          <li>
          updates RFC 3264 <xref format="default" pageno="false" target="RFC3264"/>, to also allow assigning a zero port value to a an "m=" section
          in cases where the media described by the "m=" section is not disabled or rejected.
        </t>
        <t>
          The specification
        </li>
          <li>
          defines a new RTP Control Protocol (RTCP) RTCP <xref format="default"
          pageno="false" target="RFC3550"/> source description (SDES) SDES item, 'MID', and a new RTP SDES header
          extension that can be used to associate RTP streams with "m=" sections.
        </t>
        <t>
          The specification
        </li>
          <li>
          updates <xref format="default" pageno="false" target="RFC7941"/>, target="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.
        </t>
        </list>
      </t>
        </li>
        </ul>
      </section>
  </section>

  <section anchor="sec-term" title="Terminology" toc="default">
    <t>
    <list style="symbols">
    <t>
      "m=" section: SDP bodies contain one or more media descriptions, referred to
      as "m=" sections. Each

<section>
<name>Contradiction regarding bundle-only "m=" section is represented by sections</name>
<t>
  Since the approval of the WebRTC specification documents, the IETF has become
  aware of an SDP "m=" line, inconsistency between the document specifying JSEP and zero or more
      SDP attributes associated with the "m=" line. A local address:port combination is
      assigned
  document specifying BUNDLE (RFC 8829 and this RFC, respectively).  Rather than
  delaying publication further to each "m=" section. come to a resolution, the documents are being
  published as they were originally approved.  The IETF intends to restart work
  on these technologies, and revised versions of these documents will be
  published as soon as a resolution becomes available.
</t>
<t>
      5-tuple:
  The specific issue involves the handling of "m=" sections that are designated
  as bundle-only, as discussed in <xref target="RFC8829" section="4.1.1"
  sectionFormat="comma"/>. Currently, there is divergence between JSEP and
  BUNDLE, as well as between these specifications and existing browser
  implementations:
</t>
<ul>
  <li>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.
  </li>
  <li>BUNDLE prescribes that these "m=" sections should be marked as described in the previous point, but in all offers and answers.
  </li>
  <li>Most current browsers do not mark any "m=" sections with port zero and instead use the same port for all bundled "m=" sections; one follows the JSEP behavior.
  </li>
</ul>
</section>

    </section>
    <section anchor="sec-term" toc="default" numbered="true">
      <name>Terminology</name>

      <ul empty="true">
        <li>
   <dl newline="false" spacing="normal">
      <dt>"m=" section:</dt><dd> 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.</dd>

      <dt>5-tuple:</dt><dd>A collection of the following values: source address, source
      port, destination address, destination port, and transport-layer
      protocol.
    </t>
    <t>
      Unique address:port: An
      protocol.</dd>

      <dt>Unique address:port:</dt><dd>An address:port combination that is assigned to
      only one "m=" section in an offer or answer.
    </t>
    <t>
      Offerer BUNDLE-tag: The answer.</dd>

      <dt>Offerer BUNDLE-tag:</dt><dd>The first identification-tag in a given
      SDP 'group:BUNDLE' attribute identification-tag list in an offer.
    </t>
    <t>
      Answerer BUNDLE-tag: The offer.</dd>

      <dt>Answerer BUNDLE-tag:</dt><dd>The first identification-tag in a given
      SDP 'group:BUNDLE' attribute identification-tag list in an answer.
    </t>
    <t> answer.</dd>

     <dt> Suggested offerer tagged offerer-tagged "m=" section: section:</dt><dd> The bundled "m=" section identified by the offerer BUNDLE-tag in an initial BUNDLE offer,
      before a BUNDLE group has been negotiated.
    </t>
    <t>
      Offerer tagged negotiated.</dd>

      <dt>Offerer-tagged "m=" section: The section:</dt><dd>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.
    </t>
    <t>
      Answerer tagged group.</dd>

      <dt>Answerer-tagged "m=" section: The section:</dt><dd>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.
    </t>
    <t>
      BUNDLE address:port: An group.</dd>

      <dt>BUNDLE address:port:</dt><dd>An address:port combination that an endpoint uses for sending and receiving
      bundled media.
    </t>
    <t>
      Offerer media.</dd>

     <dt>Offerer BUNDLE address:port: the address:port:</dt><dd>The address:port combination used by the offerer
      for sending and receiving media.
    </t>
    <t>
      Answerer media.</dd>

     <dt>Answerer BUNDLE address:port: the address:port:</dt><dd>The address:port combination used by the answerer
      for sending and receiving media.
    </t>
    <t>
      BUNDLE attributes: media.</dd>

     <dt>BUNDLE attributes:</dt><dd> 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.
    </t>
    <t>
      Offerer group.</dd>

      <dt>Offerer BUNDLE attributes: IDENTICAL attributes:</dt><dd>IDENTICAL and TRANSPORT multiplexing category SDP
      attributes included in the offerer tagged offerer-tagged "m=" section.
    </t>
    <t>
      Answerer </dd>

      <dt>Answerer BUNDLE attributes: IDENTICAL attributes:</dt><dd>IDENTICAL and TRANSPORT multiplexing category SDP
      attributes included in the answerer tagged answerer-tagged "m=" section.
    </t>
    <t>
      BUNDLE transport: The section.</dd>

      <dt>BUNDLE transport:</dt><dd>The transport (5-tuple) used by all media described by the
      "m=" sections within a BUNDLE group.
    </t>
    <t>
      BUNDLE group: A group.</dd>

      <dt>BUNDLE group:</dt><dd>A set of bundled "m=" sections, created using an SDP Offer/Answer offer/answer
      exchange, which 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.
    </t>
    <t>
      Bundled </dd>

     <dt>Bundled "m=" section: An section:</dt><dd>An "m=" section, whose identification-tag
      is placed in an SDP 'group:BUNDLE' attribute identification-tag list
      in an offer or answer.
    </t>
    <t>
      Bundle-only answer.</dd>

     <dt>Bundle-only "m=" section: A section:</dt><dd>A bundled "m=" section that contains an
      SDP 'bundle-only' attribute.
    </t>
    <t>
      Bundled media: All attribute.</dd>

     <dt>Bundled media:</dt><dd>All media associated with a given BUNDLE group.
    </t>
    <t>
      Initial group.</dd>

      <dt>Initial BUNDLE offer: The offer:</dt><dd>The first offer, within an SDP session (e.g. (e.g., a SIP dialog
      when the Session Initiation Protocol (SIP) SIP <xref format="default"
      pageno="false" target="RFC3261" /> target="RFC3261"/> is used to carry SDP), in which
      the offerer indicates that it wants to negotiate a given BUNDLE group.
    </t>
    <t>
      Initial group.</dd>

      <dt>Initial BUNDLE answer: The answer:</dt><dd>The answer to an initial BUNDLE offer in which the offerer indicates that it wants to negotiate
      a BUNDLE group, and where the answerer accepts the creation of the BUNDLE group. The BUNDLE group is
      created once the answerer sends the initial BUNDLE answer.
    </t>
    <t>
      Subsequent offer: An answer.</dd>

      <dt>Subsequent offer:</dt><dd>An offer which that contains a BUNDLE group that
      has been created as part of a previous offer/answer exchange.
    </t>
    <t>
      Subsequent answer: An exchange.</dd>

      <dt>Subsequent answer:</dt><dd>An answer to a subsequent offer.
    </t>
    <t>
      Identification-tag: A offer.</dd>

      <dt>Identification-tag:</dt><dd>A unique token value that is used to identify an
      "m=" section. The SDP 'mid' attribute <xref format="default" pageno="false"
      target="RFC5888" /> target="RFC5888"/> in an "m=" section carries the unique identification-tag
      assigned to that "m=" section. The session-level SDP 'group' attribute
      <xref format="default" pageno="false" target="RFC5888" /> target="RFC5888"/> carries a list of
      identification-tags, identifying the "m=" sections associated with that
      particular 'group' attribute.
    </t>
    </list>
    </t> attribute.</dd>
   </dl>
    </li>
      </ul>
    </section>
    <section title="Conventions" toc="default"> toc="default" numbered="true">
      <name>Conventions</name>
<t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref format="default" pageno="false" target="RFC2119" /> target="RFC2119"/>
    <xref format="default" pageno="false" target="RFC8174" /> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
</t>
    </section>
    <section title="Applicability Statement" toc="default"> toc="default" numbered="true">
      <name>Applicability Statement</name>
      <t>
      The mechanism in this specification only applies to the Session
      Description Protocol (SDP) SDP <xref format="default" pageno="false" target="RFC4566"/>, when used together with the SDP offer/answer
      mechanism <xref format="default" pageno="false" target="RFC3264"/>.
      Declarative usage of SDP is out of scope of this document, document and is
      thus undefined.
      </t>
    </section>
    <section title="SDP anchor="sec-group" toc="default" numbered="true">
      <name>SDP Grouping Framework BUNDLE Extension" anchor="sec-group" toc="default"> Extension</name>
      <t>
       This section defines a new SDP Grouping Framework <xref format="default" pageno="false" target="RFC5888"/> extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP
       Offer/Answer
       offer/answer mechanism to negotiate a set of "m=" sections that will become part of a BUNDLE
       group. Within a BUNDLE group, each "m=" section uses a BUNDLE transport for sending and
       receiving bundled media. Each endpoint uses a single address:port combination for sending and
       receiving the bundled media.
      </t>
      <t>
       The BUNDLE extension is indicated using an SDP 'group' attribute with a semantics value
       <xref format="default" pageno="false" target="RFC5888"/> of "BUNDLE".
       An identification-tag is assigned to each bundled
       "m=" section, and each identification-tag is listed in the SDP 'group:BUNDLE'
       attribute identification-tag list. Each "m=" section whose identification-tag
       is listed in the identification-tag list is associated with a given
       BUNDLE group.
      </t>
      <t>
       SDP bodies can contain multiple BUNDLE groups. Any given bundled "m="
       section MUST NOT <bcp14>MUST NOT</bcp14> be associated with more than one BUNDLE group at any given
       time.
      </t>
      <t>
       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.
      </t>
      <t>
       The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] <xref target="RFC8859"/> for the 'group:BUNDLE'
       attribute is 'NORMAL'.
      </t>
      <t>
       <xref target="sec-sdp-oa" pageno="false" format="default"/> defines the
       detailed SDP Offer/Answer offer/answer procedures for the BUNDLE extension.
      </t>
    </section>
    <section anchor="sec-bundle-only" title="SDP toc="default" numbered="true">
      <name>SDP 'bundle-only' Attribute" toc="default"> Attribute</name>
      <t>
      This section defines a new SDP media-level attribute <xref target="RFC4566" pageno="false" format="default"/>, 'bundle-only'. 'bundle-only' is a property attribute
      <xref target="RFC4566" pageno="false" format="default"/>, format="default"/> and hence has no value.
      </t>
      <t>
      In order to ensure that an answerer that does not support the BUNDLE extension always
      rejects a bundled "m=" section in an offer, the offerer can assign a zero port value to the "m="
      section. According to <xref target="RFC3264" pageno="false" format="default"/> format="default"/>, an answerer
      will reject such an "m=" section.
      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,
      extension and if the answerer keeps the "m=" section within the associated BUNDLE group.
      </t>
    <figure>
      <preamble></preamble>
      <artwork><![CDATA[

   Name: bundle-only

   Value: N/A

   Usage Level: media

   Charset Dependent: no

   Example:

     a=bundle-only

      ]]></artwork>
    </figure>

      <ul empty="true">
      <li>
  <dl newline="false" spacing="normal">
  <dt>Name:</dt><dd>bundle-only</dd>

  <dt>Value:</dt><dd>N/A</dd>

   <dt>Usage Level:</dt><dd>media</dd>

   <dt>Charset Dependent:</dt><dd>no</dd>

      <dt>Example:</dt><dd>a=bundle-only</dd></dl>
  </li></ul>

      <t>
      Once the offerer tagged offerer-tagged "m=" section and the answerer tagged 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.
      </t>
      <t>
      The usage of the 'bundle-only' attribute is only defined for a bundled "m=" section with
      a zero port value. Other usage is unspecified.
      </t>
      <t>
      <xref target="sec-sdp-oa" pageno="false" format="default"/> defines the detailed SDP
      Offer/Answer
      offer/answer procedures for the 'bundle-only' attribute.
      </t>
    </section>
    <section title="SDP Offer/Answer Procedures" anchor="sec-sdp-oa" toc="default"> toc="default" numbered="true">
      <name>SDP Offer/Answer Procedures</name>
      <t>
        This section describes the SDP Offer/Answer offer/answer <xref format="default"
        pageno="false" target="RFC3264"/> procedures for:
        <list style="symbols">
          <t>
      </t>
      <ul spacing="normal">
        <li>
            Negotiating a BUNDLE group; and
          </t>
          <t>
          </li>
        <li>
            Suggesting and selecting the tagged "m=" sections (offerer tagged (offerer-tagged "m=" section and answerer tagged answerer-tagged "m=" section); and
          </t>
          <t>
          </li>
        <li>
            Adding an "m=" section to a BUNDLE group; and
          </t>
          <t>
          </li>
        <li>
            Moving an "m=" section out of a BUNDLE group; and
          </t>
          <t>
          </li>
        <li>
            Disabling an "m=" section within a BUNDLE group.
          </t>
        </list>
      </t>
          </li>
      </ul>
      <t>
        The generic rules and procedures defined in <xref format="default" pageno="false" target="RFC3264"/> and <xref format="default" pageno="false" target="RFC5888"/>
        also apply to the BUNDLE extension. For example, if an offer is rejected
        by the answerer, the previously negotiated addresses:ports, SDP parameters parameters, and characteristics
        (including those associated with a BUNDLE group) apply. Hence, if an offerer
        generates an offer in order to negotiate a BUNDLE group,
        and the answerer rejects the offer, the BUNDLE group is not created.
      </t>
      <t>
        The procedures in this section are independent of the media type or
        "m=" line proto value assigned to a bundled "m=" section. <xref format="default" pageno="false" target="sec-rtp"/> defines additional
        considerations for RTP based media.
        <xref format="default" pageno="false" target="sec-bundle-only"/> defines
        additional considerations for the usage of the SDP 'bundle-only' attribute.
        <xref format="default" pageno="false" target="sec-rtp"/> defines additional
        considerations for RTP-based media.

        <xref format="default" target="sec-ice"/> defines additional
        considerations for the usage of Interactive Connectivity Establishment (ICE) the ICE
        <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> mechanism.
      </t>
      <t>
        Offers and answers can contain multiple BUNDLE groups. The procedures in this
        section apply independently to a given BUNDLE group.
      </t>
      <section title="Generic SDP Considerations" anchor="sec-sdp-cons" toc="default"> toc="default" numbered="true">
        <name>Generic SDP Considerations</name>
        <t>
          This section describes generic restrictions associated with the usage of
          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.
        </t>
        <section title="Connection Data (c=)" anchor="sec-sdp-cons-c" toc="default"> toc="default" numbered="true">
          <name>Connection Data ("c=")</name>
          <t>
            The "c=" line nettype value <xref format="default" pageno="false" target="RFC4566"/> associated with a bundled "m=" section MUST <bcp14>MUST</bcp14> be 'IN'.
          </t>
          <t>
            The "c=" line addrtype value <xref format="default" pageno="false" target="RFC4566"/> associated with a bundled "m=" section MUST <bcp14>MUST</bcp14> be 'IP4' or
            'IP6'. The same value MUST <bcp14>MUST</bcp14> be associated with each "m=" section.
          </t>
          <t>
            NOTE: Extensions to this specification can specify usage of the BUNDLE
            mechanism for other nettype and addrtype values than the ones listed above.
          </t>
        </section>
        <section title="Bandwidth (b=)" anchor="sec-sdp-cons-b" toc="default"> toc="default" numbered="true">
          <name>Bandwidth ("b=")</name>
          <t>
            An offerer and answerer MUST <bcp14>MUST</bcp14> use the rules and restrictions defined
            in <xref target="I-D.ietf-mmusic-sdp-mux-attributes" /> target="RFC8859" format="default"/> for
            associating the SDP bandwidth (b=) ("b=") line with bundled "m=" sections.
          </t>
        </section>
        <section anchor="sec-sdp-oa-cat" title="Attributes (a=)" toc="default"> toc="default" numbered="true">
          <name>Attributes ("a=")</name>
          <t>
            An offerer and answerer MUST <bcp14>MUST</bcp14> include SDP attributes in every bundled "m=" section where applicable,
            following the normal offer/answer procedures for each attribute, with the following exceptions:
            <list style="symbols">
            <t>
          </t>
          <ul spacing="normal">
            <li>
              In the initial BUNDLE offer, the offerer MUST NOT <bcp14>MUST NOT</bcp14>
              include IDENTICAL and TRANSPORT multiplexing category SDP
              attributes (BUNDLE attributes) in bundle-only "m=" sections. The
              offerer MUST <bcp14>MUST</bcp14> include such attributes in all other
              bundled "m=" sections. In the initial BUNDLE offer offer, each bundled
              "m=" line can contain a different set of BUNDLE attributes, attributes and
              attribute values. Once the offerer tagged offerer-tagged "m=" section has been
              selected, the BUNDLE attributes contained in the offerer tagged offerer-tagged
              "m=" section will apply to each bundled "m=" section within the
              BUNDLE group.
            </t>
            <t>
            </li>
            <li>
              In a subsequent offer, or in an answer (initial of subsequent),
              the offerer and answerer MUST <bcp14>MUST</bcp14> include IDENTICAL
              and TRANSPORT multiplexing category SDP attributes (BUNDLE
              attributes) only in the tagged "m=" section
              (offerer tagged (offerer-tagged "m="
              section or answerer tagged answerer-tagged "m=" section). The offerer and
              answerer MUST NOT <bcp14>MUST NOT</bcp14> 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.
            </t>
            <t>
            </li>
            <li>
              In an offer (initial BUNDLE offer or subsequent), or in an
              answer (initial BUNDLE answer or subsequent), the offerer and
              answerer MUST <bcp14>MUST</bcp14> include SDP attributes of other 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.
            </t>
            </list>
          </t>
            </li>
          </ul>
          <t>
            NOTE: A consequence of the rules above is that media-specific
            IDENTICAL and TRANSPORT multiplexing category SDP attributes which that
            are applicable only to some of the bundled "m=" sections within
            the BUNDLE group might appear in the tagged "m=" section for which
            they are not applicable. For instance, the tagged "m=" section
            might contain an SDP 'rtcp-mux' attribute even if the tagged "m="
            section does not describe RTP-based media (but another bundled
            "m=" section within the BUNDLE group does describe RTP-based
            media).
          </t>
        </section>
      </section>
      <section anchor="sec-sdp-oa-ino" title="Generating toc="default" numbered="true">
        <name>Generating the Initial SDP Offer" toc="default"> Offer</name>
        <t>
          The procedures in this section apply to the first offer, within an SDP session (e.g. (e.g., a SIP
          dialog when the Session Initiation Protocol (SIP) [RFC3261] SIP <xref target="RFC3261"/> is used to carry SDP), in which the
          offerer indicates that it wants to negotiate a given BUNDLE group. This could occur in the
          initial offer, or in a subsequent offer, of the SDP session.
        </t>
        <t>
          When an offerer generates an initial BUNDLE offer, in order to negotiate a
          BUNDLE group, it MUST:
          <list style="symbols">
            <t> <bcp14>MUST</bcp14>:
        </t>
        <ul spacing="normal">
          <li>
              Assign a unique address:port to each bundled "m=" section,
              following the procedures in <xref target="RFC3264" pageno="false" format="default"/>, excluding any bundle-only "m=" sections (see below); and
            </t>
            <t>
            </li>
          <li>
              Pick a bundled "m=" section as the suggested offerer tagged offerer-tagged "m=" section [<xref (<xref target="sec-sdp-oa-ino-req"
              pageno="false" format="default"/>]; and
            </t>
            <t> format="default"/>);
            </li>
          <li>
              Include SDP attributes in the bundled "m=" sections following the rules
              in [<xref <xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; and
            </t>
            <t> format="default"/>;
            </li>
          <li>
              Include an SDP 'group:BUNDLE' attribute in the offer; and
            </t>
            <t>
            </li>
          <li>
              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 offerer-tagged "m=" section.
            </t>
          </list>
        </t>
            </li>
        </ul>
        <t>
          NOTE: When the offerer assigns unique addresses:ports to multiple bundled "m=" sections, the offerer needs to be prepared
          to receive bundled media on each unique address:port, until it receives the associated answer and finds out which
          bundled "m=" section (and associated address:port combination) the answerer has selected as the offerer tagged offerer-tagged "m=" section.
        </t>
        <t>
          If the offerer wants to request that the answerer accepts a given bundled "m=" section only if
          the answerer keeps the "m=" section within the negotiated BUNDLE group, the offerer MUST:
          <list style="symbols">
            <t> <bcp14>MUST</bcp14>:
        </t>
        <ul spacing="normal">
          <li>
              Include an SDP 'bundle-only' attribute [<xref (<xref target="sec-sdp-oa-ino-req" pageno="false"
              format="default"/>] format="default"/>) in the "m=" section; section, and
            </t>
            <t>
            </li>
          <li>
              Assign a zero port value to the "m=" section.
            </t>
          </list>
        </t>
            </li>
        </ul>
        <t>
          NOTE: If the offerer assigns a zero port value to a bundled "m=" section, but does not include an
          SDP 'bundle-only' attribute in the "m=" section, it is an indication that the offerer wants
          to disable the "m=" section [<xref (<xref target="sec-sdp-oa-mod-dis" pageno="false" format="default"/>]. format="default"/>).
        </t>
        <t>
          [<xref
          Sections <xref target="sec-sdp-oa-ino-ex" pageno="false" format="default"/>] format="counter"/> and [<xref <xref target="sec-example-add" pageno="false" format="default"/>] format="counter"/> show
          an example of an initial BUNDLE offer.
        </t>
        <section title="Suggesting anchor="sec-sdp-oa-ino-req" toc="default" numbered="true">
          <name>Suggesting the Offerer tagged Offerer-Tagged 'm=' section" anchor="sec-sdp-oa-ino-req" toc="default"> Section</name>
          <t>
          In the initial BUNDLE offer, the bundled "m=" section indicated by the offerer BUNDLE-tag is the suggested offerer tagged offerer-tagged "m=" section.
          The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled
          media if the answerer selects the "m=" section as the offerer tagged offerer-tagged "m=" section [<xref (<xref target="sec-sdp-oa-ans-off"
          pageno="false" format="default"/>]. format="default"/>). In addition, if the answerer selects the "m=" section as the offerer tagged offerer-tagged "m=" section,
          the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group.
          </t>
          <t>
          The offerer MUST NOT <bcp14>MUST NOT</bcp14> suggest a bundle-only "m=" section as the offerer tagged offerer-tagged "m=" section.
          </t>
          <t>
          It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the suggested offerer tagged offerer-tagged "m=" section is be a bundled "m=" section
          that the offerer believes it is unlikely that the answerer will reject, reject or move out of the BUNDLE group.
          How such assumption is made is outside the scope of this document.
          </t>
        </section>
        <section anchor="sec-sdp-oa-ino-ex" title="Example: numbered="true" toc="default">
          <name>Example: Initial SDP Offer"> Offer</name>
          <t>
          The example shows an initial BUNDLE offer. The offer includes two
          "m=" sections in the offer, offer and suggests that both "m=" sections are included in a BUNDLE group.
          The audio "m=" section is the suggested offerer tagged offerer-tagged "m=" section, indicated by placing the
          identification-tag associated with the "m=" section (offerer BUNDLE-tag) first in the SDP group:BUNDLE
          attribute identification-id list.
          </t>
        <figure>
        <artwork align="left" alt="" height="" name="" type="" width=""
                 xml:space="preserve"><![CDATA[

SDP Offer

<t keepWithNext="true">SDP Offer</t>

          <sourcecode type="sdp"><![CDATA[
  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

]]></artwork>
      </figure>
]]></sourcecode>
        </section>
      </section>
      <section anchor="sec-sdp-oa-ans" title="Generating toc="default" numbered="true">
        <name>Generating the SDP Answer" toc="default"> Answer</name>
        <t>
          When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group group, the following general
          SDP grouping framework Grouping Framework restrictions, defined in <xref target="RFC5888" pageno="false" format="default"/>, also apply to the BUNDLE group:
          <list style="symbols">
            <t>
        </t>
        <ul spacing="normal">
          <li>
              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; and
            </t>
            <t>
            </li>
          <li>
              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; and
            </t>
            <t>
            </li>
          <li>
              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
            </t>
            <t>
            </li>
          <li>
              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.
            </t>
           </list>
        </t>
            </li>
        </ul>
        <t>
          In addition, when an answerer generates an answer (initial BUNDLE
          answer or subsequent) that contains a BUNDLE group, the answerer MUST:
          <list style="symbols">
            <t>
          <bcp14>MUST</bcp14>:
        </t>
        <ul spacing="normal">
          <li>
              In case of an initial BUNDLE answer, select the offerer tagged offerer-tagged
              "m=" section using the procedures in <xref
              target="sec-sdp-oa-ans-off"
              pageno="false" format="default"/>. In case of a
              subsequent answer, the offerer tagged offerer-tagged "m=" section is indicated
              in the corresponding subsequent offer, offer and MUST NOT <bcp14>MUST
              NOT</bcp14> be changed by the answerer; and
            </t>
            <t>
            </li>
          <li>
              Select the answerer tagged answerer-tagged "m=" section [<xref (<xref
              target="sec-sdp-oa-ans-off"
              pageno="false" format="default"/>]; and
            </t>
            <t> format="default"/>);
            </li>
          <li>
              Assign the answerer BUNDLE address:port to the answerer tagged answerer-tagged "m=" section; and
            </t>
            <t>
            </li>
          <li>
              Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every
              other bundled "m=" section within the BUNDLE group; and
            </t>
            <t>
            </li>
          <li>
              Include SDP attributes in the bundled "m=" sections following the rules
              in [<xref <xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; and
            </t>
            <t> format="default"/>;
            </li>
          <li>
              Include an SDP 'group:BUNDLE' attribute in the answer; and
            </t>
            <t>
            </li>
          <li>
              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 answerer-tagged "m=" section [<xref (<xref target="sec-sdp-oa-ans-off"
              pageno="false" format="default"/>].
            </t>
          </list>
        </t> format="default"/>).
            </li>
        </ul>
        <t>
          If the answerer does not want to keep an "m=" section within a BUNDLE group, it MUST:
          <list style="symbols">
            <t> <bcp14>MUST</bcp14>:
        </t>
        <ul spacing="normal">
          <li>
              Move the "m=" section out of the BUNDLE group [<xref (<xref target="sec-sdp-oa-ans-mov"
              pageno="false" format="default"/>]; format="default"/>); or
            </t>
            <t>
            </li>
          <li>
              Reject the "m=" section [<xref (<xref target="sec-sdp-oa-ans-rej" pageno="false"
              format="default"/>].
            </t>
          </list>
        </t> format="default"/>).
            </li>
        </ul>
        <t>
          The answerer can modify the answerer BUNDLE address:port, add and remove SDP attributes, or modify
          SDP attribute values, values in a subsequent answer. Changes to the answerer BUNDLE address:port
          and the answerer BUNDLE attributes will be applied to each bundled "m=" section within the BUNDLE group.
        </t>
        <t>
          NOTE: If a bundled "m=" section in an offer contains a zero port value, but the "m=" section
          does not contain an SDP 'bundle-only' attribute, it is an indication that the offerer wants
          to disable the "m=" section [<xref (<xref target="sec-sdp-oa-mod-dis" pageno="false" format="default"/>]. format="default"/>).
        </t>
        <section title="Answerer anchor="sec-sdp-oa-ans-off" toc="default" numbered="true">
          <name>Answerer Selection of tagged Tagged 'm=' sections" anchor="sec-sdp-oa-ans-off" toc="default"> Sections</name>
          <t>
          When selecting the answerer selects the offerer tagged offerer-tagged "m=" section, it first checks the suggested
          offerer tagged "m=" section [<xref target="sec-sdp-oa-ino-req" pageno="false" format="default"/>].
          The answerer MUST <bcp14>MUST</bcp14>
          first check whether the "m=" section fulfils fulfills the following criteria:
          <list style="symbols">
            <t> criteria
          <xref target="sec-sdp-oa-ino-req" format="default"/>:
          </t>
          <ul spacing="normal">
            <li>
              The answerer will not move the "m=" section out of the BUNDLE group
              [<xref
              (<xref target="sec-sdp-oa-ans-mov" pageno="false" format="default"/>]; and
            </t>
            <t> format="default"/>);
            </li>
            <li>
              The answerer will not reject the "m=" section [<xref (<xref target="sec-sdp-oa-ans-rej"
              pageno="false" format="default"/>]; format="default"/>); and
            </t>
            <t>
            </li>
            <li>
              The "m=" section does not contain a zero port value.
            </t>
          </list>
        </t>
            </li>
          </ul>
          <t>
          If all of the criteria above are fulfilled, the answerer MUST <bcp14>MUST</bcp14> select
          the "m=" section as the offerer tagged offerer-tagged "m=" section, section and MUST <bcp14>MUST</bcp14> also mark
          the corresponding "m=" section in the answer as the answerer tagged answerer-tagged "m=" section.
          In the answer answer, the answerer BUNDLE-tag indicates the answerer tagged answerer-tagged "m=" section.
          </t>
          <t>
          If one or more of the criteria are not fulfilled, the answerer MUST <bcp14>MUST</bcp14> pick the next
          identification-tag in the identification-tag list in the offer, offer and perform the same criteria
          check for the "m=" section indicated by that identification-tag. If there are no
          more identification-tags in the identification-tag list, the answerer MUST NOT <bcp14>MUST NOT</bcp14>
          create the BUNDLE group. Unless the answerer rejects the whole offer,
          the answerer MUST <bcp14>MUST</bcp14> apply the answerer procedures for moving an "m=" section out of a
          BUNDLE group [<xref (<xref target="sec-sdp-oa-ans-mov" pageno="false" format="default"/>] format="default"/>) or
          rejecting an "m=" section within a BUNDLE group [<xref (<xref target="sec-sdp-oa-ans-rej"
          pageno="false" format="default"/>] format="default"/>) to every bundled "m=" section in the offer when
          creating the answer.
          </t>
          <t>
          [<xref
          <xref target="sec-example-add" pageno="false" format="default"/>] format="default"/> shows an
          example of an offerer BUNDLE address:port selection.
          </t>
          <t>
          [<xref
          Sections <xref target="sec-sdp-oa-ans-ex" pageno="false" format="default"/>] format="counter"/> and
          [<xref
          <xref target="sec-example-add" pageno="false" format="default"/>] format="counter"/> show an example of an
          answerer tagged
          answerer-tagged "m=" section selection.
          </t>
        </section>
        <section title="Moving A anchor="sec-sdp-oa-ans-mov" toc="default" numbered="true">
          <name>Moving a Media Description Out Of A of a BUNDLE Group" anchor="sec-sdp-oa-ans-mov" toc="default"> Group</name>
          <t>
          When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of
          the negotiated BUNDLE group, the answerer MUST <bcp14>MUST</bcp14> first check the following criteria:
          <list style="symbols">
            <t>
          </t>
          <ul spacing="normal">
            <li>
              In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group; group, and
            </t>
            <t>
            </li>
            <li>
              In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute.
            </t>
          </list>
        </t>
            </li>
          </ul>
          <t>
          If either criterium criterion above is fulfilled fulfilled, the answerer can not cannot move the "m=" section out of
          the BUNDLE group in the answer. The answerer can either reject the whole offer, reject each
          bundled "m=" section within the BUNDLE group [<xref (<xref target="sec-sdp-oa-ans-rej" pageno="false" format="default"/>], format="default"/>),
          or keep the "m=" section within the BUNDLE group in the answer and later create an offer where
          the "m=" section is moved out of the BUNDLE group [<xref (<xref target="sec-sdp-oa-mod-mov"
          pageno="false" format="default"/>]. format="default"/>).
          </t>
          <t>
          NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section
          can not
          cannot be moved out of the BUNDLE group in an answer. Instead Instead, an offer is needed.
          </t>
          <t>
          When the answerer generates an answer, in which it moves a bundled "m=" section out
          of a BUNDLE group, the answerer:
          <list style="symbols">
          <t>
            MUST
          </t>
          <ul spacing="normal">
            <li>
           <bcp14>MUST</bcp14> assign a unique address:port to the "m=" section; and
          </t>
          <t>
            MUST
          </li>
            <li>
           <bcp14>MUST</bcp14> include any applicable SDP attribute in the "m=" section, using the normal
            offer/answer procedures for the each Attributes; and
          </t>
          <t>
            MUST NOT attribute;
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> place the identification-tag associated with the "m=" section in
            the SDP 'group:BUNDLE' attribute identification-tag list associated with
            the BUNDLE group.
          </t>
          <t>
            MUST NOT group; and
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> include an SDP 'bundle-only' attribute to the "m=" section; and
          </t>
          </list>
        </t> section.
          </li>
          </ul>
          <t>
          Because an answerer is not allowed to move an "m=" section from one BUNDLE group to another within an answer
          [<xref
          (<xref target="sec-sdp-oa-ans" pageno="false" format="default"/>], format="default"/>), if
          the answerer wants to move an "m=" section from one BUNDLE group to another another, it MUST <bcp14>MUST</bcp14> first move the
          "m=" section out of the current BUNDLE group, group and then generate an offer where the "m=" section is
          added to another BUNDLE group [<xref (<xref target="sec-sdp-oa-mod-add" pageno="false" format="default"/>]. format="default"/>).
          </t>
        </section>
        <section title="Rejecting anchor="sec-sdp-oa-ans-rej" toc="default" numbered="true">
          <name>Rejecting a Media Description in a BUNDLE Group" anchor="sec-sdp-oa-ans-rej" toc="default"> Group</name>
          <t>
          When an answerer wants to reject a bundled "m=" section in an answer, it MUST <bcp14>MUST</bcp14> first check
          the following criterion:
          <list style="symbols">
          <t>
          </t>
          <ul spacing="normal">
            <li>
            In the corresponding offer, the "m=" section is the offerer tagged offerer-tagged "m=" section.
          </t>
          </list>
        </t>
          </li>
          </ul>
          <t>
          If the criterium criterion above is fulfilled fulfilled, the answerer can not cannot reject the "m=" section in
          the answer. The answerer can either reject the whole offer, reject each bundled "m=" section
          within the BUNDLE group, or keep the "m=" section within the BUNDLE group in the answer and later create
          an offer where the "m=" section is disabled within the BUNDLE group [<xref (<xref target="sec-sdp-oa-mod-dis"
          pageno="false" format="default"/>]. format="default"/>).
          </t>
          <t>
          When an answerer generates an answer, in which it rejects a bundled "m=" section,
          the answerer:
          <list style="symbols">
          <t>
            MUST
          </t>
          <ul spacing="normal">
            <li>
            <bcp14>MUST</bcp14> assign a zero port value to the "m=" section, according to the procedures in
            <xref target="RFC3264" pageno="false" format="default"/>; and
          </t>
          <t>
            MUST NOT
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> place the identification-tag associated with the "m=" section in
            the SDP 'group:BUNDLE' attribute identification-tag list associated with
            the BUNDLE group; and
          </t>
          <t>
            MUST NOT
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> include an SDP 'bundle-only' attribute in the "m=" section.
          </t>
          </list>
        </t>
          </li>
          </ul>
        </section>
        <section title="Example: anchor="sec-sdp-oa-ans-ex" numbered="true" toc="default">
          <name>Example: SDP Answer" anchor="sec-sdp-oa-ans-ex"> Answer</name>
          <t>
          The example below shows an answer, based on the corresponding offer in
          [<xref
          <xref target="sec-sdp-oa-ino-ex" pageno="false" format="default"/>]. format="default"/>.
          The answerer accepts both bundled "m=" sections within the created
          BUNDLE group. The audio "m=" section is the answerer tagged answerer-tagged "m=" section, indicated
          by placing the identification-tag associated with the "m=" section
          (answerer BUNDLE-tag) first in the SDP group;BUNDLE attribute
          identification-id list. The answerer includes an SDP 'bundle-only'
          attribute in, and assigns a zero port value to, the video "m=" section.
          </t>
        <figure>
        <artwork align="left" alt="" height="" name="" type="" width=""
                 xml:space="preserve"><![CDATA[

SDP Answer

<t keepWithNext="true">SDP Answer</t>

         <sourcecode type="sdp"><![CDATA[
  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

]]></artwork>
      </figure>
]]></sourcecode>
        </section>
      </section>
      <section anchor="sec-sdp-oa-off-ans" title="Offerer toc="default" numbered="true">
        <name>Offerer Processing of the SDP Answer" toc="default"> Answer</name>
        <t>
        When an offerer receives an answer, if the answer contains a BUNDLE group, the offerer
        MUST
        <bcp14>MUST</bcp14> check that any bundled "m=" section in the answer was indicated as bundled in the
        corresponding offer. If there is no mismatch, the offerer MUST <bcp14>MUST</bcp14> apply the properties (BUNDLE address:port,
        BUNDLE attributes etc) attributes, etc.) of the offerer tagged offerer-tagged "m=" section (selected by the answerer
        [<xref answerer; see
        <xref format="default" pageno="false" target="sec-sdp-oa-ans-off"/>]) target="sec-sdp-oa-ans-off"/>) to each bundled "m=" section
        within the BUNDLE group.
        </t>
        <t>
        NOTE: As the answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer,
        or move a bundled "m=" section out of a BUNDLE group, a given bundled "m=" section in the
        offer might not be indicated as bundled in the corresponding answer.
        </t>
        <t>
        If the answer does not contain a BUNDLE group, the offerer MUST <bcp14>MUST</bcp14> process the answer
        as a normal answer.
        </t>
      </section>
      <section title="Modifying the Session" anchor="sec-sdp-oa-mod" toc="default"> toc="default" numbered="true">
        <name>Modifying the Session</name>
        <t>
          When a BUNDLE group has previously been previously negotiated, and an offerer generates a subsequent
          offer, the offerer MUST:
          <list style="symbols">
            <t> <bcp14>MUST</bcp14>:
        </t>
        <ul spacing="normal">
          <li>
              Pick one bundled "m=" section as the offerer tagged offerer-tagged "m=" section. The offerer
              can either pick either the "m=" section that was previously selected by the answerer
              as the offerer tagged offerer-tagged "m=" section, section or pick another bundled "m=" section within the
              BUNDLE group; and
            </t>
            <t>
            </li>
          <li>
              Assign a BUNDLE address:port (previously negotiated or newly suggest) suggested) to
              the offerer tagged offerer-tagged "m=" section; and
            </t>
            <t>
            </li>
          <li>
              Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every
              other bundled "m=" section within the BUNDLE group; and
            </t>
            <t>
            </li>
          <li>
              Include SDP attributes in the bundled "m=" sections following the rules in
              [<xref
              <xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; and
            </t>
            <t> format="default"/>;
            </li>
          <li>
              Include an SDP 'group:BUNDLE' attribute in the offer; and
            </t>
            <t>
            </li>
          <li>
              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 offerer-tagged "m=" section.
            </t>
          </list>
        </t>
            </li>
        </ul>
        <t>
          The offerer MUST NOT <bcp14>MUST NOT</bcp14> pick a given bundled "m=" section as the offerer tagged offerer-tagged "m=" section if:
          <list style="symbols">
            <t>
        </t>
        <ul spacing="normal">
          <li>
              The offerer wants to move the "m=" section out of the BUNDLE group
              [<xref
              (<xref target="sec-sdp-oa-mod-mov" pageno="false" format="default"/>]; format="default"/>), or
            </t>
            <t>
            </li>
          <li>
              The offerer wants to disable the "m=" section [<xref (<xref format="default"
              pageno="false" target="sec-sdp-oa-mod-dis"/>].
            </t>
          </list>
        </t> target="sec-sdp-oa-mod-dis"/>).
            </li>
        </ul>
        <t>
          The offerer can modify the offerer BUNDLE address:port, add and remove SDP attributes, or modify
          SDP attribute values, values in the subsequent offer. Changes to the offerer BUNDLE address:port and the
          offerer BUNDLE attributes will (if the offer is accepted by the answerer) be applied to each
          bundled "m=" section within the BUNDLE group.
        </t>
        <section title="Adding anchor="sec-sdp-oa-mod-add" toc="default" numbered="true">
          <name>Adding a Media Description to a BUNDLE group" anchor="sec-sdp-oa-mod-add" toc="default"> Group</name>
          <t>
          When an offerer generates a subsequent offer, in which it wants to add a bundled "m=" section to
          a previously negotiated BUNDLE group, the offerer follows the procedures in <xref target="sec-sdp-oa-mod"
          pageno="false" format="default"/>. The offerer either picks either the added "m=" section, section or an "m=" section
          previously added to the BUNDLE group, group as the offerer tagged offerer-tagged "m=" section.
          </t>
          <t>
          NOTE: As described in <xref target="sec-sdp-oa-ans-mov" pageno="false" format="default"/>, the answerer can not cannot move the added "m=" section
          out of the BUNDLE group in its answer. If the answer wants to move the "m=" section out of the BUNDLE group, it will have to first accept
          it into the BUNDLE group in the answer, and then send a subsequent offer where the "m=" section is moved out of the BUNDLE group
          [<xref
          (<xref target="sec-sdp-oa-mod-mov" pageno="false" format="default"/>]. format="default"/>).
          </t>
        </section>
        <section title="Moving anchor="sec-sdp-oa-mod-mov" toc="default" numbered="true">
          <name>Moving a Media Description Out of a BUNDLE Group" anchor="sec-sdp-oa-mod-mov" toc="default"> Group</name>
          <t>
          When an offerer generates a subsequent offer, in which it want wants to remove a bundled "m=" section from
          a BUNDLE group, the offerer:
          <list style="symbols">
          <t>
            MUST
          </t>
          <ul spacing="normal">
            <li>
            <bcp14>MUST</bcp14> assign a unique address:port to the "m=" section; and
          </t>
          <t>
            MUST
          </li>
            <li>
            <bcp14>MUST</bcp14> include SDP attributes in the "m=" section following the
            normal offer/answer rules for each attribute; and
          </t>
          <t>
            MUST NOT
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> place the identification-tag associated with the "m=" section in
            the SDP 'group:BUNDLE' attribute identification-tag list associated with
            the BUNDLE group; and
          </t>
          <t>
            MUST NOT
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> assign an SDP 'bundle-only' attribute to the "m=" section.
          </t>
          </list>
        </t>
          </li>
          </ul>
          <t>
          For the other bundled "m=" sections within the BUNDLE group, the offerer follows the procedures
          in [<xref <xref target="sec-sdp-oa-mod" pageno="false" format="default"/>]. format="default"/>.
          </t>
          <t>
          An offerer MUST NOT <bcp14>MUST NOT</bcp14> move an "m=" section from one BUNDLE group to another within a
          single offer. If the offerer wants to move an "m=" section from one BUNDLE group to
          another
          another, it MUST <bcp14>MUST</bcp14> first move the BUNDLE group out of the current BUNDLE group, and then
          generate a second offer where the "m=" section is added to another BUNDLE group
          [<xref
          (<xref target="sec-sdp-oa-mod-add" pageno="false" format="default"/>]. format="default"/>).
          </t>
          <t>
          [<xref
          <xref target="sec-example-off-mov" pageno="false" format="default"/>] format="default"/>
          shows an example of an offer for moving an "m=" section out of a BUNDLE group.
          </t>
        </section>
        <section title="Disabling anchor="sec-sdp-oa-mod-dis" toc="default" numbered="true">
          <name>Disabling a Media Description in a BUNDLE Group" anchor="sec-sdp-oa-mod-dis" toc="default"> Group</name>
          <t>
          When an offerer generates a subsequent offer, in which it want wants to disable a bundled "m=" section from
          a BUNDLE group, the offerer:
          <list style="symbols">
          <t>
            MUST
          </t>
          <ul spacing="normal">
            <li>
            <bcp14>MUST</bcp14> assign a zero port value to the "m=" section, following the procedures
            in <xref target="RFC4566" pageno="false" format="default"/>; and
          </t>
          <t>
            MUST NOT
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> place the identification-tag associated with the "m=" section in
            the SDP 'group:BUNDLE' attribute identification-tag list associated with
            the BUNDLE group; and
          </t>
          <t>
            MUST NOT
          </li>
            <li>
            <bcp14>MUST NOT</bcp14> assign an SDP 'bundle-only' attribute to the "m=" section.
          </t>
          </list>
        </t>
          </li>
          </ul>
          <t>
          For the other bundled "m=" sections within the BUNDLE group, the offerer follows the procedures
          in [<xref <xref target="sec-sdp-oa-mod" pageno="false" format="default"/>]. format="default"/>.
          </t>
          <t>
          [<xref
          <xref target="sec-example-off-dis" pageno="false" format="default"/>] format="default"/>
          shows an example of an offer and answer for disabling an "m=" section within a
          BUNDLE group.
          </t>
        </section>
      </section>
    </section>
    <section title="Protocol Identification" anchor="sec-protocol-id" toc="default"> toc="default" numbered="true">
      <name>Protocol Identification</name>
      <t>
      Each "m=" section within a BUNDLE group MUST <bcp14>MUST</bcp14> use the same transport-
      layer protocol. If bundled "m=" sections use different upper-layer protocols
      on top of the transport-layer protocol, there MUST <bcp14>MUST</bcp14> exist a publicly
      available specification which that describes how a mechanism how to associate associates
      received data with the correct protocol for this particular protocol combination.
      </t>
      <t>
      In addition, if received data can be associated with more than
      one bundled "m=" section, there MUST <bcp14>MUST</bcp14> exist a publicly available
      specification which that describes a mechanism for associating the
      received data with the correct "m=" section.
      </t>
      <t>
      This document describes a mechanism to identify the
      protocol of received data among the STUN, DTLS Session Traversal Utilities for NAT (STUN), DTLS, and SRTP protocols the Secure Real-time Transport Protocol (SRTP)
      (in any combination), combination) when UDP is used as a transport-layer protocol,
      but it does not describe how to identify different protocols transported on
      DTLS.
      While the mechanism is generally applicable to other protocols and
      transport-layer protocols, any such use requires further specification around
      that encompasses how to multiplex multiple protocols on a given transport-layer protocol, protocol
      and how to associate received data with the correct protocols.
      </t>
      <section anchor="sec-packets-id-sds" title="STUN, toc="default" numbered="true">
        <name>STUN, DTLS, SRTP" toc="default"> and SRTP</name>
        <t>
        Section 5.1.2 of <xref format="default" pageno="false" target="RFC5764"/> describes a
        mechanism to identify the protocol of a received packet among the STUN, DTLS DTLS, and
        SRTP protocols (in any combination).
        If an offer or answer includes a bundled "m=" section that represents these protocols, the offerer
        or answerer MUST <bcp14>MUST</bcp14> support the mechanism described in <xref format="default" pageno="false" target="RFC5764"/>, and no explicit negotiation is required in order to indicate support
        and usage of the mechanism.
        </t>
        <t>
        <xref format="default" pageno="false" target="RFC5764"/> does not describe how to identify
        different protocols transported on DTLS, only how to identify the DTLS protocol itself. If
        multiple protocols are transported on DTLS, there MUST <bcp14>MUST</bcp14> exist a specification describing a
        mechanism for identifying each individual protocol. In addition, if a received DTLS packet
        can be associated with more than one "m=" section, there MUST <bcp14>MUST</bcp14> exist a specification which that
        describes a mechanism for associating the received DTLS packets with the correct "m=" section.
        </t>
        <t>
        [<xref
        <xref format="default" pageno="false" target="sec-rtp-pt"/>] target="sec-rtp-pt"/> describes how to
        associate the packets in a received SRTP stream with the correct "m=" section.
        </t>
      </section>
    </section>
    <section anchor="sec-rtp" title="RTP Considerations" toc="default"> toc="default" numbered="true">
      <name>RTP Considerations</name>
      <section anchor="sec-rtp-sessions" title="Single toc="default" numbered="true">
        <name>Single RTP Session" toc="default"> Session</name>
        <t>
            All RTP-based media within a single BUNDLE group belong to a
            single RTP session <xref format="default" pageno="false" target="RFC3550"/>.
        </t>
        <t>
            Since a single BUNDLE transport is used for sending and receiving bundled media,
            the symmetric RTP mechanism <xref format="default" pageno="false" target="RFC4961"/>
            MUST
            <bcp14>MUST</bcp14> be used for RTP-based bundled media.
        </t>
        <t>
            Since a single RTP session is used for each BUNDLE group, all
            "m=" sections representing RTP-based media within a BUNDLE group will
            share a single SSRC Synchronization Source (SSRC) numbering space <xref format="default"
            pageno="false" target="RFC3550"/>.
        </t>
        <t>
            The following rules and restrictions apply for a single RTP
            session:
        </t>
          <t>
            <list style="symbols">
              <t>
        <ul spacing="normal">
          <li>
                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 [<xref (<xref format="default" pageno="false"
                target="sec-rtp-sessions-pt"/>].
              </t>
              <t> target="sec-rtp-sessions-pt"/>).
              </li>
          <li>
                The proto value in each bundled RTP-based "m=" section MUST <bcp14>MUST</bcp14> be identical
                (e.g., RTP/AVPF).
              </t>
              <t>
              </li>
          <li>
                The RTP MID header extension MUST <bcp14>MUST</bcp14> be enabled, by including
                an SDP 'extmap' attribute <xref format="default" pageno="false" target="RFC8285"/>,
                with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, in each
                bundled RTP-based "m=" section in every offer and answer.
              </t>
              <t>
              </li>
          <li>
                A given SSRC MUST NOT <bcp14>MUST NOT</bcp14> transmit RTP packets using payload types that
                originate from different bundled "m=" sections.
              </t>
            </list>
          </t>
              </li>
        </ul>
        <t>
            NOTE: The last bullet above is to avoid sending multiple media types
            from the same SSRC. If transmission of multiple media types are done
            with time overlap, RTP and RTCP fail to function. Even if done in
            proper sequence sequence, this causes RTP Timestamp timestamp rate switching issues
            <xref format="default" pageno="false" target="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 <xref format="default" pageno="false" target="RFC3550"/>).
        </t>
        <t>
            <xref format="default" pageno="false" target="RFC7657"/> defines Differentiated Services
            (Diffserv) considerations for RTP-based bundled media sent using a mixture of Diffserv Codepoints.
        </t>
        <section anchor="sec-rtp-sessions-pt" title="Payload toc="default" numbered="true">
          <name>Payload Type (PT) Value Reuse" toc="default"> Reuse</name>
          <t>
            Multiple bundled "m=" sections might describe RTP based RTP-based media. As all RTP based RTP-based
            media associated with a BUNDLE group belong 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 <bcp14>MUST</bcp14> share an identical codec
            configuration. This means that the codecs MUST <bcp14>MUST</bcp14> share the same media type,
            encoding name, clock rate rate, and any parameter that can affect the codec configuration
            and packetization. <xref format="default" pageno="false"
            target="I-D.ietf-mmusic-sdp-mux-attributes"/> target="RFC8859"/> lists SDP attributes, whose attribute
            values are required to be identical for all codecs that use the
	    same payload type value.
          </t>
        </section>
      </section>
      <section anchor="sec-rtp-pt" title="Associating toc="default" numbered="true">
        <name>Associating RTP/RTCP Streams with the Correct SDP Media Description" toc="default"> Description</name>
        <t>
            As described in <xref target="RFC3550" />, format="default"/>, RTP packets are associated with RTP
            streams <xref target="RFC7656" />. format="default"/>. Each RTP stream is identified by an SSRC
            value, and each RTP packet includes an SSRC field that is
            used to associate the packet with the correct RTP stream.
            RTCP packets also use SSRCs to identify which RTP streams the
            packet relates to. However, a an RTCP packet can contain multiple SSRC
            fields, in the course of providing feedback or reports on different RTP
            streams, and therefore can be associated with multiple such streams.
        </t>
        <t>
            In order to be able to process received RTP/RTCP packets
            correctly, it MUST <bcp14>MUST</bcp14> be possible to associate an RTP stream with
            the correct "m=" section, as the "m=" section and SDP attributes
            associated with the "m=" section contains information needed to
            process the packets.
        </t>
        <t>
            As all RTP streams associated with a BUNDLE group use the
            same transport for sending and receiving RTP/RTCP
            packets, the local address:port combination part of the transport
            cannot be used to associate an RTP stream with the correct "m=" section.
            In addition, multiple RTP streams might be associated with the same "m="
            section.
        </t>
        <t>
            An offerer and answerer can inform each other which SSRC
            values they will use for an RTP stream by using the SDP 'ssrc'
            attribute <xref format="default" pageno="false" target="RFC5576"/>.
            However, an offerer will not know which SSRC values the
            answerer will use until the offerer has received the answer
            providing that information. Due to this, before the offerer has
            received the answer, the offerer will not be able to associate
            an RTP stream with the correct "m=" section using the SSRC value
            associated with the RTP stream. In addition, the offerer and
            answerer may start using new SSRC values mid-session, without
            informing each other about using the SDP 'ssrc' attribute.
        </t>
        <t>
            In order for an offerer and answerer to always be able to
            associate an RTP stream with the correct "m=" section, the offerer
            and answerer using the BUNDLE extension MUST <bcp14>MUST</bcp14> support the
            mechanism defined in <xref format="default" pageno="false" target="sec-receiver-id"/>,
            where the offerer and answerer insert the identification-tag associated
            with an "m=" section (provided by the remote peer) into RTP and RTCP
            packets associated with a BUNDLE group.
        </t>
        <t>
             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 <xref format="default" pageno="false" target="sec-receiver-id"/>.
             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 contain several mappings of SSRC to identification-tag mappings. identification-tag. The
             offerer and answerer maintain tables used for routing that are updated
             each time an RTP/RTCP packet contains new information that affects how
             packets are to be routed.
        </t>
        <t>
            However, some legacy implementations may not include this identification-tag
            in their RTP and RTCP traffic when using the BUNDLE mechanism, mechanism and
            instead use a mechanism based on the payload type based mechanism to associate RTP streams
            with SDP "m=" sections.  In this situation, each "m=" section needs to
            use unique payload type values, in order for the payload type to be a
            reliable indicator of the relevant "m=" section for the RTP stream. If an
            implementation fails to ensure unique payload type values values, it will be
            impossible to associate the RTP stream using that payload type value
            to a particular "m=" section.
            Note that when using the payload type to associate RTP streams with
            "m=" sections sections, an RTP stream, identified by its SSRC, will be mapped
            to an "m=" section when the first packet of that RTP stream is
            received, and the mapping will not be changed even if the payload
            type used by that RTP stream changes.  In other words, the SSRC
            cannot "move" to a different "m=" section simply by changing the
            payload type.
        </t>
        <t>
             Applications can implement RTP stacks in many different
             ways. The algorithm below details one way that 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 <bcp14>MAY</bcp14> use any algorithm that achieves equivalent results to
             those described in the algorithm below.
        </t>
        <t>
             To prepare to associate RTP streams with the correct
             "m=" section, the following steps MUST <bcp14>MUST</bcp14> be followed for each BUNDLE group:
        </t>
         <t><list>
             <t>

        <ul empty="false" spacing="normal">
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 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.
             </t>
         </list></t>
             </li>
        </ul>
        <t>
             As "m=" sections are added or removed from the BUNDLE groups, or
             their configurations are changed, the tables above MUST <bcp14>MUST</bcp14> also be
             updated.
        </t>
        <t>
             When an RTP packet is received, it MUST <bcp14>MUST</bcp14> be delivered to the RTP
             stream corresponding to its SSRC. That RTP stream MUST <bcp14>MUST</bcp14> then be
             associated with the correct "m=" section within a BUNDLE group, for
             additional processing, according to the following steps:
        </t>
         <t><list>
             <t>
        <ul empty="false" spacing="normal">
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 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
                 <xref target="RFC7941" />, Section 4.2.6, sectionFormat="comma" 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.
             </t>
             <t>
             </li>
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 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.
             </t>
             <t>
             </li>
          <li>
                 Otherwise, mark the RTP stream as not "not for decoding decoding" and
                 discard the payload.
             </t>
           </list>
             </li>
        </ul>
        <t>
           If the RTP packet contains one or more contributing source Contributing Source (CSRC)
           identifiers, then each CSRC is looked up in the incoming SSRC table table,
           and a copy of the RTP packet is associated with the corresponding
           "m=" section for additional processing.
        </t>
        <t>
              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, type dependent, as each kind of RTCP packet has its own
              mechanism for associating it with the relevant RTP streams.
        </t>
        <t>
              RTCP packets that cannot be associated with an appropriate "m=" section
              MUST
              <bcp14>MUST</bcp14> still be processed as usual by the RTP layer, updating which updates the metadata
              associated with the corresponding RTP streams. This situation can occur with
              certain multiparty RTP topologies, topologies or when RTCP packets are sent containing
              a subset of the SDES information.
        </t>
        <t>
              Additional rules for processing various types of RTCP packets are
              explained below.
        </t>
          <t><list>
              <t>
        <ul empty="false" spacing="normal">
          <li>
                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
                <xref target="RFC7941"/>, Section 4.2.6.
            </t>
            <t> target="RFC7941" sectionFormat="comma" section="4.2.6"/>.
            </li>
          <li>
                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, 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.
            </t>
            <t>
            </li>
          <li>
                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 <xref target="RFC3550" />, Section 6.2.1.
            </t>
            <t> sectionFormat="comma" section="6.2.1"/>.
            </li>
          <li>
                If the RTCP packet is of type SR or RR, 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.
            </t>
            <t>
            </li>
          <li>
                If the implementation supports the RTCP XR Extended Report (XR) and the packet is of
                type XR, as defined in <xref target="RFC3611" />, format="default"/>,
                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.
            </t>
            <t>
            </li>
          <li>
                If the RTCP packet is a feedback message of type RTPFB (transport-layer FB
   message) or PSFB, PSFB (payload-specific FB message),
                as defined in <xref target="RFC4585" />, format="default"/>, 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) are is used for routing.
            </t>
            </li>
          <li>
            <t>
                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:
                <list style="hanging">
                    <t hangText="Generic NACK:">
                        <xref target="RFC4585"/> (PT=RTPFB, FMT=1).
            </t>
                    <t hangText="Picture
            <ul empty="true"><li>
            <dl newline="false" spacing="normal">
              <dt>Generic NACK:</dt>
              <dd>(PT=RTPFB, FMT=1) <xref target="RFC4585" format="default"/>.</dd>
              <dt>Picture Loss Indication (PLI):"> (PLI):</dt>
              <dd>(PT=PSFB, FMT=1) <xref target="RFC4585"/> (PT=PSFB, FMT=1).
                    </t>
                    <t hangText="Slice target="RFC4585" format="default"/>.</dd>
              <dt>Slice Loss Indication (SLI):">
                        <xref target="RFC4585"/> (SLI):</dt>
              <dd> (PT=PSFB, FMT=2).
                    </t>
                    <t hangText="Reference FMT=2) <xref target="RFC4585" format="default"/>.</dd>
              <dt>Reference Picture Selection Indication (RPSI):"> (RPSI):</dt>
              <dd>(PT=PSFB, FMT=3) <xref target="RFC4585"/> (PT=PSFB, FMT=3).
                    </t>
                </list>
            </t>
            <t> target="RFC4585" format="default"/>.</dd>
            </dl>
          </li>
         </ul></li></ul>

          <ul empty="false">
          <li>
                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 a an RTP stream that is being
                sent by the message recipient, whereas notifications are responses
                to an earlier request, request and therefore reference a an RTP stream that
                is being received by the message recipient.
            </t>
            </li>
          <li>
            <t>
                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:
                <list style="hanging">
                    <t hangText="Full
            </t>
            <ul empty="true"><li>
            <dl newline="false" spacing="normal">
              <dt>Full Intra Request (FIR):"> (FIR):</dt>
              <dd>(PT=PSFB, FMT=4) <xref target="RFC5104"/> (PT=PSFB, FMT=4).
                    </t>
                    <t hangText="Temporal-Spatial target="RFC5104" format="default"/>.
                    </dd>
              <dt>Temporal-Spatial Trade-off Request (TSTR):"> (TSTR):</dt>
              <dd>(PT=PSFB, FMT=5) <xref target="RFC5104"/> (PT=PSFB, FMT=5).
                    </t>
                    <t hangText="H.271 target="RFC5104" format="default"/>.
                    </dd>
              <dt>H.271 Video Back Channel Message (VBCM):"> (VBCM):</dt>
              <dd>(PT=PSFB, FMT=7) <xref target="RFC5104"/> (PT=PSFB, FMT=7).
                    </t>
                    <t hangText="Temporary target="RFC5104" format="default"/>.
                    </dd>
              <dt>Temporary Maximum Media Stream Bit Rate Request (TMMBR):"> (TMMBR):</dt>
              <dd>(PT=RTPFB, FMT=3) <xref target="RFC5104"/> (PT=RTPFB, FMT=3).
                    </t>
                    <t hangText="Layer target="RFC5104" format="default"/>.
                    </dd>
              <dt>Layer Refresh Request (LRR):"> (LRR):</dt>
              <dd>(PT=PSFB, FMT=10) <xref target="I-D.ietf-avtext-lrr"/> (PT=PSFB, FMT=10).
                    </t>
                </list>
            </t> target="I-D.ietf-avtext-lrr" format="default"/>.
                    </dd>
            </dl>
          </li></ul></li></ul>

          <ul empty="false"><li>
          <t>
                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:
                <list style="hanging">
                    <t hangText="Temporal-Spatial
            </t>

            <ul empty="true"><li>
            <dl newline="false" spacing="normal">
              <dt>Temporal-Spatial Trade-off Notification (TSTN):"> (TSTN):</dt>
              <dd>(PT=PSFB, FMT=6) <xref target="RFC5104"/> (PT=PSFB, FMT=6). target="RFC5104" format="default"/>. This message
                        is a notification in response to a prior TSTR.
                    </t>
                    <t hangText="Temporary
                    </dd>
              <dt>Temporary Maximum Media Stream Bit Rate Notification (TMMBN):"> (TMMBN):</dt>
              <dd>(PT=RTPFB, FMT=4) <xref target="RFC5104"/> (PT=RTPFB, FMT=4). target="RFC5104" format="default"/>. This message is a
                        notification in response to a prior TMMBR, but it can also be sent
                        unsolicited.
                    </t>
                </list>
            </t>
            <t>
                    </dd>
            </dl>
          </li></ul></li></ul>

           <ul empty="true">
          <li>
              If the RTCP packet is of type APP, then it is handled in an application
              specific application-specific
              manner. If the application does not recognise recognize the APP packet,
              then it MUST <bcp14>MUST</bcp14> be discarded.
            </t>
        </list>
        </t>
            </li>
        </ul>
      </section>

      <section title="RTP/RTCP Multiplexing" anchor="sec-rtprtcp-mux" toc="default"> toc="default" numbered="true">
        <name>RTP/RTCP Multiplexing</name>
        <t>
          Within a BUNDLE group, the offerer and answerer MUST <bcp14>MUST</bcp14> enable
          RTP/RTCP multiplexing <xref format="default" pageno="false" target="RFC5761"/> for the RTP-based bundled media (i.e., the
          same transport will be used for both RTP packets and RTCP packets).
          In addition, the offerer and answerer MUST <bcp14>MUST</bcp14> support the
          SDP 'rtcp-mux-only' attribute <xref format="default" pageno="false"
          target="I-D.ietf-mmusic-mux-exclusive"/>. target="RFC8858"/>.
        </t>
        <section title="SDP Offer/Answer Procedures" anchor="sec-rtprtcp-mux-oa" toc="default"> toc="default" numbered="true">
          <name>SDP Offer/Answer Procedures</name>
          <t>
            This section describes how an offerer and answerer use the
            SDP 'rtcp-mux' attribute <xref format="default" pageno="false" target="RFC5761"/> and the SDP 'rtcp-mux-only' attribute attributes
            <xref format="default" pageno="false" target="I-D.ietf-mmusic-mux-exclusive"/> target="RFC8858"/>
            to negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media.
          </t>
          <t>
            RTP/RTCP multiplexing only applies to RTP-based media. However, as described in
            <xref format="default" pageno="false" target="sec-sdp-oa-cat"/>, 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 (if such "m=" section is the offerer
            tagged offerer-tagged
            "m=" section or answerer tagged answerer-tagged "m=" section).
          </t>
          <section title="Generating anchor="sec-rtprtcp-mux-oa-ino" toc="default" numbered="true">
            <name>Generating the Initial SDP BUNDLE Offer" anchor="sec-rtprtcp-mux-oa-ino" toc="default"> Offer</name>
            <t>
            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 is a chance that "m=" sections
            for RTP-based media will later be added to the BUNDLE group), the offerer MUST <bcp14>MUST</bcp14>
            include an SDP 'rtcp-mux' attribute <xref format="default" pageno="false" target="RFC5761"/> in each
            bundled "m=" section (excluding any bundle-only "m=" sections). In addition, the offerer MAY <bcp14>MAY</bcp14> include an
            SDP 'rtcp-mux-only' attribute <xref format="default" pageno="false" target="I-D.ietf-mmusic-mux-exclusive"/> target="RFC8858"/>
            in one or more bundled "m=" sections for RTP-based media.
            </t>
            <t>
            NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
            depends on whether the offerer supports fallback to usage of 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.
            </t>
            <t>
            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 <xref format="default"
            pageno="false" target="RFC3605"/> in one or more RTP-based bundled "m=" sections in order
            to provide a fallback port for RTCP, as described in <xref format="default" pageno="false" target="RFC5761"/>. However, the fallback port will only be applied to "m=" sections for RTP-based
            media that are moved out of the BUNDLE group by the answerer.
            </t>
            <t>
            In the initial BUNDLE offer, the address:port combination for RTCP MUST <bcp14>MUST</bcp14> be unique in each
            bundled "m=" section for RTP-based media (excluding a bundle-only "m=" section), similar to RTP.
            </t>
          </section>
          <section title="Generating anchor="sec-rtprtcp-mux-oa-ans" toc="default" numbered="true">
            <name>Generating the SDP Answer" anchor="sec-rtprtcp-mux-oa-ans" toc="default"> Answer</name>
            <t>
            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 <bcp14>MUST</bcp14> enable usage of RTP/RTCP multiplexing, even if there currently
            are no bundled "m=" sections for RTP-based media within the BUNDLE group. The answerer MUST <bcp14>MUST</bcp14> include
            an SDP 'rtcp-mux' attribute in the answerer tagged answerer-tagged "m=" section, following the procedures for
            BUNDLE attributes [<xref (<xref format="default" pageno="false" target="sec-sdp-oa-cat"/>]. target="sec-sdp-oa-cat"/>).
            In addition, if the "m=" section that is selected as the offerer tagged offerer-tagged "m=" section contained
            an SDP "rtcp-mux-only" 'rtcp-mux-only' attribute, the answerer MUST <bcp14>MUST</bcp14> include an SDP "rtcp-mux-only" 'rtcp-mux-only' attribute
            in the answerer tagged answerer-tagged "m=" section.
            </t>

            <t>
            In an initial BUNDLE offer, if the suggested offerer tagged offerer-tagged "m=" section contained an
            SDP 'rtcp-mux-only' attribute, the "m=" section was for RTP-based media, and media; thus, the
            answerer does not accept the "m=" section in the created BUNDLE group, and the answerer
            MUST either
            <bcp14>MUST</bcp14> move the "m=" section out of the BUNDLE group [<xref (<xref format="default"
            pageno="false" target="sec-sdp-oa-ans-mov"/>], target="sec-sdp-oa-ans-mov"/>); include the attribute in the
            moved "m=" section and enable RTP/RTCP multiplexing for the media associated with
            the "m=" section, section; or reject the "m=" section [<xref (<xref format="default" pageno="false"
            target="sec-sdp-oa-ans-rej"/>]. target="sec-sdp-oa-ans-rej"/>).
            </t>
            <t>
            The answerer MUST NOT <bcp14>MUST NOT</bcp14> include an SDP 'rtcp' attribute in any bundled "m=" section
            in the answer. The answerer will use the port value of the tagged offerer offerer-tagged
            "m=" section sending RTP and RTCP packets associated with RTP-based bundled media
            towards the offerer.
            </t>
            <t>
            If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
            negotiated in a previous offer/answer exchange, the answerer MUST <bcp14>MUST</bcp14>
            include an SDP 'rtcp-mux' attribute in the answerer tagged answerer-tagged "m=" section . section.
            It is not possible to disable RTP/RTCP multiplexing within a BUNDLE group.
            </t>
          </section>
          <section title="Offerer anchor="sec-rtprtcp-mux-oa-pra" toc="default" numbered="true">
            <name>Offerer Processing of the SDP Answer" anchor="sec-rtprtcp-mux-oa-pra" toc="default"> Answer</name>
            <t>
            When an offerer receives an answer, if the answerer has accepted
            the usage of RTP/RTCP multiplexing [<xref target="sec-rtprtcp-mux-oa-ans"/>], (<xref target="sec-rtprtcp-mux-oa-ans" format="default"/>),
            the answerer follows the procedures for RTP/RTCP multiplexing defined
            in <xref format="default" pageno="false" target="RFC5761"/>. The
            offerer will use the port value of the answerer tagged answerer-tagged "m=" section
            for sending RTP and RTCP packets associated with
            RTP-based bundled media towards the answerer.
            </t>
            <t>
            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.
            </t>
          </section>
          <section title="Modifying the Session" anchor="sec-rtprtcp-mux-oa-mod" toc="default"> toc="default" numbered="true">
            <name>Modifying the Session</name>
            <t>
            When an offerer generates a subsequent offer, the offerer MUST <bcp14>MUST</bcp14> include
            an SDP 'rtcp-mux' attribute in the offerer tagged offerer-tagged "m=" section, following
            the procedures for IDENTICAL multiplexing category attributes in
            <xref format="default" pageno="false" target="sec-sdp-oa-cat"/>.
            </t>
          </section>
        </section>
      </section>
    </section>
    <section title="ICE Considerations" anchor="sec-ice" toc="default"> toc="default" numbered="true">
      <name>ICE Considerations</name>
      <t>
        This section describes how to use the BUNDLE grouping extension together
        with the Interactive Connectivity Establishment (ICE) ICE mechanism <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/>. target="RFC8445"/>.
      </t>
      <t>
        The generic procedures for negotiating the usage of ICE using SDP, defined
        in <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>, target="RFC8839" format="default"/>, also apply to the usage of ICE
        with BUNDLE, with the following exceptions:
      </t>
      <t>
        <list style="symbols">
          <t>
      <ul spacing="normal">
        <li>
            When the BUNDLE transport has been established, ICE connectivity checks and keep-alives keepalives
            only need to be performed for the BUNDLE transport, instead of per individual bundled "m=" section
            within the BUNDLE group.
          </t>
          <t>
          </li>
        <li>
            The generic SDP attribute offer/answer considerations [<xref (<xref format="default" pageno="false" target="sec-sdp-oa-cat"/>] target="sec-sdp-oa-cat"/>) also apply to ICE-related
            attributes. Therefore, when an offer offerer sends an initial BUNDLE offer (in order to negotiate a BUNDLE group) group), the offerer
            include
            includes ICE-related media-level attributes in each bundled "m=" section (excluding any bundle-only "m=" section), sections),
            and each "m=" section MUST <bcp14>MUST</bcp14> 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 offerer-tagged "m=" section or answerer tagged answerer-tagged "m=" section), and
            the ICE properties are applied to each bundled "m=" section within the BUNDLE group.
          </t>
        </list>
      </t>
          </li>
      </ul>
      <t>
        NOTE: Most ICE-related media-level SDP attributes belong to the TRANSPORT multiplexing category
        <xref target="I-D.ietf-mmusic-sdp-mux-attributes" />, target="RFC8859" format="default"/>, and the generic SDP attribute offer/answer
        considerations for the TRANSPORT multiplexing category apply to the attributes. However, in the case of
        ICE-related attributes, the same considerations also apply to ICE-related media-level attributes that
        belong to other multiplexing categories.
      </t>
      <t>
        NOTE: The following ICE-related media-level SDP attributes are defined in
        <xref target="I-D.ietf-mmusic-ice-sip-sdp" />: target="RFC8839" format="default"/>: 'candidate', 'remote-candidates', 'ice-mismatch',
        'ice-ufrag', 'ice-pwd', and 'ice-pacing'.
      </t>
      <t>
        Initially, before ICE has produced selected candidate pairs that will be used for media, there might
        be multiple transports established (if multiple candidate pairs are tested). Once ICE has selected
        candidate pairs, they form the BUNDLE transport.
      </t>
      <t>
        Support and usage of the ICE mechanism together with the BUNDLE extension
        is OPTIONAL, <bcp14>OPTIONAL</bcp14>, and the procedures in this section only apply when the
        ICE mechanism is used. Note that applications might mandate usage
        of the ICE mechanism even if the BUNDLE extension is not used.
      </t>
      <t>
        NOTE: If the trickle Trickle ICE mechanism <xref target="I-D.ietf-mmusic-trickle-ice-sip" /> target="RFC8840" format="default"/>
        is used, an offerer and answerer might assign a port value of '9', '9' and an IPv4
        address of '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" sections
        in the initial BUNDLE offer. The offerer and answerer will follow the normal procedures
        for generating the offers and answers, including picking a bundled "m=" section as the
        suggested offerer tagged offerer-tagged "m=" section, selecting the tagged "m=" sections sections, etc. The only
        difference is that media can not cannot be sent until one or more candidates have been provided.
        Once a BUNDLE group has been negotiated, trickled candidates associated with a bundled
        "m=" section will be applied to all bundled "m=" sections within the BUNDLE group.
      </t>
    </section>
    <section title="DTLS Considerations" anchor="sec-dtls" toc="default"> toc="default" numbered="true">
      <name>DTLS Considerations</name>
      <t>
        One or more media streams within a BUNDLE group might use
        the Datagram Transport Layer Security (DTLS) protocol
        <xref format="default" pageno="false" target="RFC6347"/>
        in order to encrypt the data, data or to negotiate encryption keys
        if another encryption mechanism is used to encrypt media.
      </t>
      <t>
        When DTLS is used within a BUNDLE group, the following rules
        apply:
        <list style="symbols">
        <t>
      </t>
      <ul spacing="normal">
        <li>
          There can only be one DTLS association
          <xref format="default" pageno="false" target="RFC6347"/>
          associated with the BUNDLE group; and
        </t>
        <t>
        </li>
        <li>
          Each usage of the DTLS association within the BUNDLE
          group MUST <bcp14>MUST</bcp14> use the same mechanism for determining
          which endpoints (the offerer or answerer) become
          DTLS client and DTLS server; and
        </t>
        <t>
        </li>
        <li>
          Each usage of the DTLS association within the BUNDLE
          group MUST <bcp14>MUST</bcp14> use the same mechanism for determining
          whether an offer or answer will trigger the
          establishment of a new DTLS association, association or whether
          an existing DTLS association will be used; and
        </t>
        <t>
        </li>

        <li>
          If the DTLS client supports DTLS-SRTP
          <xref format="default" pageno="false" target="RFC5764"/> DTLS-SRTP,
          it MUST <bcp14>MUST</bcp14> include the 'use_srtp' extension
          <xref format="default" pageno="false" target="RFC5764"/>
          in the DTLS ClientHello message
          <xref format="default" pageno="false" target="RFC5764"/>.
          The client MUST <bcp14>MUST</bcp14> include the extension even if the usage
          of DTLS-SRTP is not negotiated as part of the
          multimedia session (e.g., the SIP session <xref format="default"
          pageno="false" target="RFC3261"/>).
        </t>
        </list>
      </t>
        </li>
      </ul>
      <t>
        NOTE: The inclusion of the 'use_srtp' extension during the initial
        DTLS handshake ensures that a DTLS renegotiation will not be required
        in order to include the extension, in case DTLS-SRTP encrypted media
        is added to the BUNDLE group later during the multimedia session.
      </t>
    </section>
    <section title="RTP anchor="sec-extmap" toc="default" numbered="true">
      <name>RTP Header Extensions Consideration" anchor="sec-extmap" toc="default"> Consideration</name>
      <t>When <xref target="RFC8285"/> RTP header extensions <xref target="RFC8285" format="default"/> are used in the context of this
       specification, the identifier used for a given extension MUST <bcp14>MUST</bcp14> identify the same
       extension across all the bundled media descriptions. </t>
    </section>

    <section anchor="sec-3264" title="Update toc="default" numbered="true">
      <name>Update to RFC 3264" toc="default"> 3264</name>
      <t>
        This section updates RFC 3264, in order to allow extensions to define the usage of
        a zero port value in offers and answers for other purposes other than removing or disabling
        media streams. The following sections of RFC 3264 are being updated:
      </t>
      <t>
        <list style="symbols">
          <t>Section 5.1 (Unicast Streams).</t>
          <t>Section 8.4 (Putting
      <ul spacing="normal">
        <li>"Unicast Streams"; see <xref target="RFC3264" sectionFormat="of" section="5.1"/></li>
        <li>"Putting a Unicast Media Stream on Hold).</t>
        </list>
      </t> Hold"; see <xref target="RFC3264" sectionFormat="of" section="8.4"/>. </li>
      </ul>
      <section anchor="sec-3264-old-5_1" title="Original text of section 5.1 (2nd paragraph) of toc="default" numbered="true">
        <name>Original Text from RFC 3264" toc="default">
      <t> 3264, Section 5.1, 2nd Paragraph</name>
        <blockquote>
        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 <bcp14>MUST NOT</bcp14> 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.
      </t>
        </blockquote>
      </section>
      <section anchor="sec-3264-new-5_1" title="New text replacing section 5.1 (2nd paragraph) of toc="default" numbered="true">
        <name>New Text Replacing RFC 3264" toc="default"> 3264, Section 5.1, 2nd Paragraph</name>
        <t>
        For recvonly and sendrecv streams, the port number and address in the
        offer indicate where the offerer would like to receive the media
        stream. For sendonly RTP streams, the address and port number
        indirectly indicate where the offerer wants to receive RTCP reports.
        Unless there is an explicit indication otherwise, reports are sent to
        the port number one higher than the number indicated. The IP address
        and port present in the offer indicate nothing about the source IP
        address and source port of the RTP and RTCP packets that will be sent by
        the offerer. A By default, a port number of zero in the offer by default indicates that the
        stream is offered but MUST NOT <bcp14>MUST NOT</bcp14> be used, but an extension mechanism
        might specify different semantics for the usage of a zero port value.
        Furthermore, existing streams can be terminated by setting the port to
        zero (Section 8). In general, a port number of zero by default indicates
        that the media stream is not wanted.
        </t>
      </section>
      <section anchor="sec-3264-old-8_4" title="Original text of section 8.4 (6th paragraph) of RFC 3264" toc="default">
      <t> toc="default" numbered="true">
        <name>Original Text from RFC 3264, Section 8.4, 6th Paragraph</name>

        <blockquote>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 <bcp14>MUST NOT</bcp14> be zero, which would specify that the stream has been
   disabled.  An agent MUST <bcp14>MUST</bcp14> be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP is to should be sent to the peer.
      </t>
        </blockquote>

      </section>
      <section anchor="sec-3264-new-8_4" title="New text replacing section 8.4 (6th paragraph) of toc="default" numbered="true">
        <name>New Text Replacing RFC 3264" toc="default"> 3264, Section 8.4, 6th Paragraph</name>
        <t>
        RFC 2543 [10] specified <xref target="RFC2543"/> specifies that placing a user on hold was accomplished
        by setting the connection address to 0.0.0.0.  Its usage for putting
        a call on hold is no longer recommended, since it doesn't allow for
        RTCP to be used with held streams, doesn't work with IPv6, and breaks
        with connection oriented media. However, it can be useful in an
        initial offer when the offerer knows it wants to use a particular set
        of media streams and formats, but doesn't know the addresses and
        ports at the time of the offer. Of course, when used, the port
        number MUST NOT <bcp14>MUST NOT</bcp14> be zero, if it would specify that the stream has been
        disabled. However, an extension mechanism might specify different
        semantics of the zero port number usage. An agent MUST <bcp14>MUST</bcp14> be capable
        of receiving SDP with a connection address of 0.0.0.0, in which case it
        means that neither RTP nor RTCP is to be sent to the peer.
        </t>
      </section>
    </section>
    <section anchor="sec-5888" title="Update toc="default" numbered="true">
      <name>Update to RFC 5888" toc="default"> 5888</name>
      <t>
        This section updates RFC 5888 <xref format="default" pageno="false" target="RFC5888"/>), target="RFC5888"/>,
        in order to allow for extensions to allow an SDP 'group' attribute containing
        an identification-tag that identifies a an "m=" section with the port set to zero
        Section 9.2 (Group zero.
        "Group Value in Answers) of RFC 5888 Answers" (<xref  target="RFC5888" sectionFormat="of" section="9.2"/>)
        is updated.
      </t>
      <section anchor="sec-5888-old-9_2" title="Original text of section 9.2 (3rd paragraph) of toc="default" numbered="true">
        <name>Original Text from RFC 5888" toc="default">
      <t>
        SIP 5888, Section 9.2, 3rd Paragraph</name>

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

      </section>
      <section anchor="sec-5888-new-9_2" title="New text replacing section 9.2 (3rd paragraph) of toc="default" numbered="true">
        <name>New Text Replacing RFC 5888" toc="default"> 5888, Section 9.2, 3rd Paragraph</name>
        <t>
        SIP entities refuse media streams by setting the port to zero in the corresponding
        "m" line. "a=group" lines MUST NOT <bcp14>MUST NOT</bcp14> contain identification-tags that correspond to
        "m" lines with the port set to zero, but an extension mechanism might specify different
        semantics for including identification-tags that correspond to such "m=" lines.
        </t>
      </section>
    </section>
    <section title="RTP/RTCP extensions anchor="sec-receiver-id" toc="default" numbered="true">
      <name>RTP/RTCP Extensions for identification-tag transport" anchor="sec-receiver-id" toc="default"> Transport</name>
      <t>
        SDP
        Offerers and Answerers answerers <xref format="default" pageno="false" target="RFC3264"/>
        can associate identification-tags with "m=" sections within SDP Offers offers
        and Answers, answers, using the procedures in <xref format="default" pageno="false" target="RFC5888"/>. Each identification-tag uniquely represents an "m=" section.
      </t>
      <t>
        This section defines a new RTCP SDES item <xref format="default" pageno="false" target="RFC3550"/>, 'MID', which is used to carry identification-tags within RTCP
        SDES packets. This section also defines a new RTP SDES header extension
        <xref format="default" pageno="false" target="RFC7941"/>, which
        is used to carry the 'MID' RTCP SDES item in RTP packets.
      </t>
      <t>
        The SDES item and RTP SDES header extension make it possible for a receiver to associate
        each RTP stream with a specific "m=" section, with which the receiver has
        associated an identification-tag, even if those "m=" sections are part of the same RTP session.
        The RTP SDES header extension also ensures that the media recipient gets the identification-tag
        upon receipt of the first decodable media and is able to associate the media with the
        correct application.
      </t>
      <t>
        A media recipient informs the media sender about the identification-tag
        associated with an "m=" section through the use of an 'mid' a 'id' attribute
        <xref format="default" pageno="false" target="RFC5888"/>. The media sender then
        inserts the identification-tag in RTCP and RTP packets sent to the media recipient.
      </t>
      <t>
        NOTE: This The text above defines how identification-tags are carried in SDP Offers offers
        and Answers. answers. The usage of other signaling protocols for carrying identification-tags
        is not prevented, but the usage of such protocols is outside the scope of this document.
      </t>
      <t>
        <xref format="default" pageno="false" target="RFC3550"/> defines general procedures
        regarding the RTCP transmission interval. The RTCP MID SDES item SHOULD <bcp14>SHOULD</bcp14> be sent in
        the first few RTCP packets sent after joining the session, session and SHOULD <bcp14>SHOULD</bcp14> be sent regularly
        thereafter. The exact number of RTCP packets in which this SDES item is sent is
        intentionally not specified here, as it will depend on the expected packet loss packet-loss
        rate, the RTCP reporting interval, and the allowable overhead.
      </t>
      <t>
        The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD <bcp14>SHOULD</bcp14> be included
        in some RTP packets at the start of the session and whenever the SSRC changes. It might
        also be useful to include the header extension in RTP packets that comprise access points in the media
        (e.g., with video I-frames). The exact number of RTP packets in which this header
        extension is sent is intentionally not specified here, as it will depend on expected
        packet loss
        packet-loss rate and loss patterns, the overhead the application can tolerate, and
        the importance of immediate receipt of the identification-tag.
      </t>
      <t>
        For robustness, endpoints need to be prepared for situations where the
        reception of the identification-tag is delayed, delayed and SHOULD NOT <bcp14>SHOULD NOT</bcp14> terminate sessions
        in such cases, as the identification-tag is likely to arrive soon.
      </t>
      <section title="RTCP anchor="sec-receiver-id-sdes-item" toc="default" numbered="true">
        <name>RTCP MID SDES Item" anchor="sec-receiver-id-sdes-item" toc="default">
       <figure> Item</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
    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=TBD      MID=15   |     length    | identification-tag          ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
          The identification-tag payload is UTF-8 encoded <xref format="default"
          pageno="false" target="RFC3629"/>, as in SDP.
        </t>
        <t>
          The identification-tag is not zero terminated.
        </t>
        <t>
          [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
          identifier value.]
        </t>
      </section>
      <section title="RTP anchor="sec-receiver-id-rtp-he" toc="default" numbered="true">
        <name>RTP SDES Header Extension For MID" anchor="sec-receiver-id-rtp-he" toc="default"> MID</name>
        <t>
          The payload, containing the identification-tag, of the RTP SDES header extension element
          can be encoded using either the one-byte 1-byte or two-byte the 2-byte header <xref format="default"
          pageno="false" target="RFC7941"/>. The identification-tag payload is UTF-8
          encoded, as in SDP.
        </t>
        <t>
          The identification-tag is not zero terminated. Note, Note that the set of header extensions
          included in the packet needs to be padded to the next 32-bit boundary using zero
          bytes <xref format="default" pageno="false" target="RFC8285"/>.
        </t>
        <t>
          As the identification-tag is included in either an RTCP SDES item or item, an RTP SDES header
          extension, or both, there needs to be some consideration about the packet expansion
          caused by the identification-tag. To avoid Maximum Transmission Unit (MTU) issues
          for the RTP packets, the header extension's size needs to be taken into account when
          encoding the media.
        </t>
        <t>
          It is recommended that the identification-tag is be kept short. Due to the properties of
          the RTP header extension mechanism, when using the one-byte 1-byte header, a tag that is 1-3 bytes
          will result in a minimal number of 32-bit words used for the RTP SDES header extension,
          in case no other header extensions are included at the same time. Note, do take into
          account that some single characters when UTF-8 encoded will result in multiple octets.
          The identification-tag MUST NOT <bcp14>MUST NOT</bcp14> contain any user information, and applications SHALL <bcp14>SHALL</bcp14> avoid
          generating the identification-tag using a pattern that enables user- user or application
          identification.
        </t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="sec-receiver-id-iana" toc="default"> toc="default" numbered="true">
      <name>IANA Considerations</name>
      <section title="New SDES item" anchor="sec-receiver-id-iana-sdes-item" toc="default">
      <t>
        [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
        of this document.]
      </t>
      <t>
        [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
        identifier value.]
      </t> toc="default" numbered="true">
        <name>New SDES Item</name>
        <t>
        This document adds the MID SDES item to the IANA "RTP SDES item
        types" Item
        Types" registry as follows:
        </t>
      <figure>
        <artwork align="left"><![CDATA[

  Value:     TBD
  Abbrev.:   MID
  Name:      Media Identification
  Reference: RFCXXXX

        ]]></artwork>
      </figure>
	<ul empty="true"><li>
	  <dl newline="false" spacing="normal">
	    <dt>Value:</dt><dd>15</dd>
	    <dt>Abbrev.:</dt><dd>MID</dd>
	    <dt>Name:</dt><dd>Media Identification</dd>
	    <dt>Reference:</dt><dd>RFC 8843</dd>
	</dl></li></ul>
      </section>
      <section title="New anchor="sec-receiver-id-iana-rtp-uri" toc="default" numbered="true">
        <name>New RTP SDES Header Extension URI" anchor="sec-receiver-id-iana-rtp-uri" toc="default">
      <t>
        [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
        of this document.]
      </t> URI</name>
        <t>
        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:
        </t>
      <figure>
        <artwork align="left"><![CDATA[

  Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
  Description:   Media identification
  Contact:       IESG (iesg@ietf.org)
  Reference:     RFCXXXX
	<ul empty="true"><li>
	  <dl newline="false" spacing="normal">
	    <dt>Extension URI:</dt><dd>urn:ietf:params:rtp-hdrext:sdes:mid</dd>
	    <dt>Description:</dt><dd>Media identification</dd>
	    <dt>Contact:</dt><dd>IESG (iesg@ietf.org)</dd>
	    <dt>Reference:</dt><dd>RFC 8843</dd>
	</dl></li></ul>

<t>
  The SDES item does not reveal privacy information about the users.
  It is simply used to associate RTP-based media with the correct SDP
  media description ("m=" section) in the SDP used to negotiate the
  media.
  media.</t>

 <t> The purpose of the extension is for the offerer to be able to
  associate received multiplexed RTP-based media before the offerer
  receives the associated SDP answer.

        ]]></artwork>
      </figure> answer.</t>
      </section>
      <section title="New SDP Attribute" anchor="sec-receiver-id-iana-sdp-attribute" toc="default">
      <t>
        [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
        of this document.]
      </t> toc="default" numbered="true">
        <name>New SDP Attribute</name>
        <t>
        This document defines a new SDP media-level attribute,
        'bundle-only', according to the following data:
        </t>
      <figure>
        <artwork align="left"><![CDATA[

  Attribute name:     bundle-only
  Type
<ul empty="true"><li>
<dl newline="false" spacing="normal">
  <dt>Attribute name:</dt><dd>bundle-only</dd>
  <dt>Type of attribute:  media
  Subject attribute:</dt><dd>media</dd>
  <dt>Subject to charset: No
  Purpose:            Request charset:</dt><dd>No</dd>
  <dt>Purpose:</dt><dd>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:          RFCXXXX
  Mux category:       NORMAL

        ]]></artwork>
      </figure> answerer.</dd>
  <dt>Appropriate values:</dt><dd>N/A</dd>
  <dt>Contact name:</dt><dd>IESG</dd>
  <dt>Contact e-mail:</dt><dd>iesg@ietf.org</dd>
  <dt>Reference:</dt><dd>RFC 8843</dd>
  <dt>Mux category:</dt><dd>NORMAL</dd>
</dl></li></ul>

      </section>
      <section title="New anchor="sec-receiver-id-iana-sdp-group-semantics" toc="default" numbered="true">
        <name>New SDP Group Semantics" anchor="sec-receiver-id-iana-sdp-group-semantics" toc="default">
      <t>
        [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
        of this document.]
      </t> Semantics</name>
        <t>
        This document registers the following semantics with IANA in the
        "Semantics for the "group" 'group' SDP Attribute" subregistry (under the
        "Session Description Protocol (SDP) Parameters" registry: registry):
        </t>
      <figure>
        <artwork align="left"><![CDATA[

  Semantics                              Token   Reference
  -------------------------------------  ------  ---------
  Media bundling                         BUNDLE  [RFCXXXX]

  Mux category:       NORMAL

        ]]></artwork>
      </figure>

<table anchor="Table_1" align="left">
<thead>
    <tr>
      <th align="left">Semantics</th>
      <th align="left">Token</th>
      <th align="left">Mux Category</th>
      <th align="left">Reference</th>
    </tr>
</thead>
<tbody>
    <tr>
      <td align="left">Media bundling</td>
      <td align="left">BUNDLE</td>
      <td align="left">NORMAL</td>
      <td align="left">RFC 8843</td>
    </tr>
</tbody>
</table>
      </section>
    </section>
    <section anchor="sec-security" title="Security Considerations" toc="default"> toc="default" numbered="true">
      <name>Security Considerations</name>
      <t>The security considerations defined in <xref format="default"
      pageno="false" target="RFC3264"/> and <xref format="default"
      pageno="false" target="RFC5888"/> apply to the BUNDLE extension. Bundle BUNDLE
      does not change which information, e.g., RTP streams, flows over
      the network, with the exception of the usage of the MID SDES item as
      discussed below. Primarily
      Primarily, it changes which addresses and ports, and
      thus in which (RTP) sessions sessions, the information is flowing. flows to. This
      affects the security contexts being used and can cause previously
      separated information flows to share the same security context. This has very
      little impact on the performance of the security mechanism of the RTP
      sessions. In cases where one would have applied different security
      policies on the different RTP streams being bundled, or where the
      parties having access to the security contexts would have differed
      between the RTP streams, additional analysis of the implications are
      needed before selecting to apply BUNDLE.</t>

      <t>The identification-tag, independent of transport, RTCP SDES packet packet, or
      RTP header extension, can expose the value to parties beyond the
      signaling chain. Therefore, the identification-tag values MUST <bcp14>MUST</bcp14> be
      generated in a fashion that does not leak user information, e.g.,
      randomly or using a per-bundle group counter, and SHOULD <bcp14>SHOULD</bcp14> be 3 bytes or
      less,
      less to allow them to efficiently fit into the MID RTP header
      extension. Note that if implementations use different methods for
      generating identification-tags identification-tags, this could enable fingerprinting of the
      implementation making it vulnerable to targeted attacks. The
      identification-tag is exposed on the RTP stream level when included in
      the RTP header extensions, however extensions; however, what it reveals of 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. As
      the identification-tag is also used to route the media stream to the
      right application functionality functionality, it is important that the value
      received is the one intended by the sender, thus sender; thus, integrity and the
      authenticity of the source are important to prevent denial of service on
      the application. Existing SRTP configurations and other security
       mechanisms protecting the whole RTP/RTCP packets will provide the
      necessary protection.</t>

      <t>When the BUNDLE extension is used, the set of configurations of the
	  security mechanism used in all the bundled media descriptions will need to
	  be compatible so that they can be used simultaneously, at least
	  per direction or endpoint. When using SRTP SRTP, this will be the case, at least
	  for the IETF defined IETF-defined key-management solutions due to their SDP attributes
	  (a=crypto, a=fingerprint, a=mikey)
	  ("a=crypto", "a=fingerprint", "a=mikey") and their classification in <xref
	  target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t>
	  target="RFC8859" format="default"/>.</t>

      <t>The security considerations of "RTP Header
	  Extension for the RTP Control Protocol (RTCP) Source Description Items"
	  <xref target="RFC7941"/> requires target="RFC7941" format="default"/> require that when RTCP is confidentiality protected, then any SDES
	  RTP header extension carrying an SDES item, such as the MID RTP header
      extension, is also protected using commensurate strength algorithms.
      However, assuming the above requirements and recommendations are
      followed, there are no known significant security risks with leaving the
      MID RTP header extension without confidentiality protection.
      Therefore, this specification updates RFC 7941 by adding the exception that this requirement
      MAY
      <bcp14>MAY</bcp14> be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are
      discussed in Options "Options for Securing RTP Sessions Sessions" <xref target="RFC7201"/>, target="RFC7201" format="default"/>,
      for example example, SRTP <xref target="RFC3711"/> target="RFC3711" format="default"/> can provide the necessary security
      functions of ensuring the integrity and source authenticity.
      </t>
    </section>
    <section title="Examples" anchor="sec-example-alt1" toc="default"> toc="default" numbered="true">
      <name>Examples</name>
      <section title="Example: anchor="sec-example-add" toc="default" numbered="true">
        <name>Example: Tagged m= "m=" Section Selections" anchor="sec-example-add"
	toc="default"> Selections</name>
        <t>
        The example below shows:
        <list style="symbols">
          <t>An
        </t>
        <ul spacing="normal">

          <li>An initial BUNDLE offer, in which the offerer wants to
          negotiate a BUNDLE group, group and indicates the audio m= "m="
          section as the suggested offerer tagged offerer-tagged "m=" section.</t>
          <t>An section.</li>

          <li>An initial BUNDLE answer, in which the answerer accepts
          the creation of the BUNDLE group, selects the audio m= "m="
          section in the offer as the offerer tagged offerer-tagged "m=" section,
          selects the audio "m=" section in the answer as the answerer tagged
          answerer-tagged "m=" section section, and assigns the answerer BUNDLE
          address:port to that "m=" section.</t>
        </list>
      </t>
          <figure>
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP section.</li>
        </ul>

<t keepWithNext="true">SDP Offer (1) (1)</t>
       <sourcecode type="sdp"><![CDATA[
    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
]]></sourcecode>

<t keepWithNext="true">SDP Answer (2) (2)</t>
<sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
        </figure>
]]></sourcecode>

      </section>
      <section title="Example: anchor="sec-example-bunrej" toc="default" numbered="true">
        <name>Example: BUNDLE Group Rejected" anchor="sec-example-bunrej" toc="default"> Rejected</name>
        <t>
        The example below shows:
        <list style="symbols">
          <t>An
        </t>
        <ul spacing="normal">
          <li>An initial BUNDLE offer, in which the offerer wants to
          negotiate a BUNDLE group, group and indicates the audio m= "m=" section
          as the suggested offerer tagged offerer-tagged "m=" section.</t>
          <t>An section.</li>

          <li>An initial BUNDLE answer, in which the answerer rejects
          the creation of the BUNDLE group, generates a normal answer answer,
          and assigns a unique address:port to each "m=" section in
          the answer.</t>

        </list>
      </t>
      <figure>
      <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP answer.</li>
        </ul>
<t keepWithNext="true">SDP Offer (1) (1)</t>

  <sourcecode type="sdp"><![CDATA[
    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
]]></sourcecode>

<t keepWithNext="true">SDP Answer (2) (2)</t>

  <sourcecode type="sdp"><![CDATA[
    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

      ]]></artwork>
      </figure>
]]></sourcecode>
      </section>
      <section title="Example: anchor="sec-example-off-add" toc="default" numbered="true">
        <name>Example: Offerer Adds a Media Description to a BUNDLE Group" anchor="sec-example-off-add" toc="default"> Group</name>
        <t>
        The example below shows:
        <list style="symbols">
          <t>A
        </t>
        <ul spacing="normal">
          <li>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, group; indicates the new "m=" section as the
          offerer tagged
          offerer-tagged "m=" section section; and assigns the offerer BUNDLE address:port to that "m=" section.</t>
          <t>A section.</li>

          <li>A subsequent answer, in which the answerer indicates the new video "m=" section in the answer as the answerer tagged answerer-tagged "m=" section
          and assigns the answerer BUNDLE address:port to that "m=" section.</t>
        </list>
      </t>
          <figure>
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP section.</li>
        </ul>
<t keepWithNext="true">SDP Offer (1) (1)</t>

  <sourcecode type="sdp"><![CDATA[
    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
]]></sourcecode>

<t keepWithNext="true">SDP Answer (2) (2)</t>

  <sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
        </figure>
]]></sourcecode>
      </section>
      <section title="Example: anchor="sec-example-off-mov" toc="default" numbered="true">
        <name>Example: Offerer Moves a Media Description Out of a BUNDLE Group" anchor="sec-example-off-mov" toc="default"> Group</name>
        <t>
        The example below shows:
        <list style="symbols">
          <t>A
        </t>
        <ul spacing="normal">
          <li>A subsequent offer, in which the offerer removes a an "m=" section (video), indicated by the "zen"
          identification-tag, from a previously negotiated BUNDLE group, group; indicates one of the bundled "m=" sections (audio)
          remaining in the BUNDLE group as the offerer tagged offerer-tagged "m=" section section; and assigns the offerer BUNDLE address:port to that "m=" section.</t>
          <t>A section.</li>

          <li>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 answerer-tagged "m=" section section, and assigns the answerer BUNDLE address:port to that "m=" section.</t>
        </list>
      </t>
          <figure>
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP section.</li>
        </ul>

<t keepWithNext="true">SDP Offer (1) (1)</t>

  <sourcecode type="sdp"><![CDATA[
    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
]]></sourcecode>

<t keepWithNext="true">SDP Answer (2) (2)</t>

  <sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
        </figure>
]]></sourcecode>
      </section>
      <section title="Example: anchor="sec-example-off-dis" toc="default" numbered="true">
        <name>Example: Offerer Disables a Media Description Within within a BUNDLE Group" anchor="sec-example-off-dis" toc="default"> Group</name>
        <t>
        The example below shows:
        <list style="symbols">
          <t>A
        </t>
        <ul spacing="normal">
          <li>A subsequent offer, in which the offerer disables (by assigning a zero port value) a an "m=" section (video), indicated by the "zen"
          identification-tag, from a previously negotiated BUNDLE group, group; indicates one of the bundled "m=" sections (audio)
          remaining active in the BUNDLE group as the offerer tagged offerer-tagged "m=" section section; and assigns the offerer BUNDLE address:port to that "m=" section.</t>
          <t>A section.</li>

          <li>A subsequent answer, in which the answerer disables the "m=" section, indicates the audio "m=" section
          in the answer as the answerer tagged answerer-tagged "m=" section section, and assigns the answerer BUNDLE address:port to that "m=" section.</t>
        </list>
      </t>
          <figure>
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP section.</li>
        </ul>

<t keepWithNext="true">SDP Offer (1) (1)</t>
  <sourcecode type="sdp"><![CDATA[
    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
]]></sourcecode>

<t keepWithNext="true">SDP Answer (2) (2)</t>

  <sourcecode type="sdp"><![CDATA[
    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

      ]]></artwork>
      </figure>
]]></sourcecode>
      </section>
    </section>

  <section anchor="sec-acks" title="Acknowledgements" toc="default">
    <t>
      The usage

  </middle>
  <back>

<displayreference target="I-D.ietf-avtext-lrr" to="LLR-RTCP"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3605.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4961.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5761.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5888.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7941.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8285.xml"/>

        <!--Note: reference.I-D.draft-ietf-ice-rfc5245bis-20 is now RFC 8445-->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>

<!--draft-ietf-mmusic-sdp-mux-attributes-17; part of the SDP grouping extension C238; 8859 -->
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
          <front>
            <title>A Framework 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 text (e.g., SDP examples)
      have been borrowed (and, in some cases, modified) from those alternative
      proposals.
    </t>
    <t>
      The SDP examples are also modified versions from the ones in the Alvestrand
      proposal.
    </t>
    <t>
      Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Stach,
      Ari Keranen, 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.
    </t>
    <t>
       Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti,
       and Magnus Westerlund for providing the text for the section on
       RTP/RTCP stream association.
    </t>
    <t>
      Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for providing
      help and text on the RTP/RTCP procedures.
    </t>
    <t>
       Thanks to Charlie Kaufman for performing the Sec-Dir review.
    </t>
    <t>
       Thanks to Linda Dunbar for performing the Gen-ART review.
    </t>
    <t>
      Thanks to Spotify for providing music for the countless hours of
      document editing.
    </t>
  </section>

  <section title="Change Log">
    <t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51
      <list style="symbols">
        <t>Changes based on IESG reviews.</t>
        <t>- Clarification of 'initial offer' terminology.</t>
        <t>- Merging of tagged m- section selection sections.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50
      <list style="symbols">
        <t>Changes based on IESG reviews.</t>
        <t>- Adding of tagged m- section concept.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49
      <list style="symbols">
        <t>Changes based on IESG reviews.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48
      <list style="symbols">
        <t>Changes based on Sec-Dir review by Charlie Kaufman.</t>
        <t>- s/unique address/unique address:port</t>
        <t>Changes based on Gen-ART review by Linda Dunbar.</t>
        <t>Mux category for group:BUNDLE attribute added.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47
      <list style="symbols">
        <t>Changes based on AD review by Ben Campbell.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46
      <list style="symbols">
        <t>Pre-RFC5378 disclaimer removed put back.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45
      <list style="symbols">
        <t>Mux category for SDP 'group:BUNDLE' attribute added.</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/54</t>
        <t>Pre-RFC5378 disclaimer removed.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44
      <list style="symbols">
        <t>Minor editorial nits based on pull request by Colin P.</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/53</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43
      <list style="symbols">
        <t>Changes based on WG chairs review.</t>
        <t>Text added in order to close GitHub issues by Taylor B.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42
      <list style="symbols">
        <t>Changes based on final WG review.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41
      <list style="symbols">
        <t>Update to section 6 o RFC 3264:</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/47</t>
        <t>Editorial clarification on BUNDLE address selection:</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/46</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40
      <list style="symbols">
        <t>Editorial changes and technical restrictions in order to make the
        specification more understandable:</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/45</t>
        <t>- BUNDLE address is only assigned to m- section indicated by BUNDLE-tag.</t>
        <t>- bundle-only attribute also used in answers and subsequent offers.</t>
        <t>- Answerer cannot reject, or remove, the bundled m- section that contains the
        BUNDLE address.</t>
        <t>- ICE Offer/Answer sections removed, due to duplicated information.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39
      <list style="symbols">
        <t>Editorial terminology changes.</t>
        <t>RFC 5285 reference replaced by reference to RFC 8285.</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/44</t>
        <t>- Clarify that an m- section can not be moved between BUNDLE groups
        without first moving the m- section out of a BUNDLE group.</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/41</t>
        <t>- Addition of BUNDLE transport concept.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38
      <list style="symbols">
        <t>Changes to RTP streaming mapping section based on text from Colin Perkins.</t>
        <t>The following GitHub pull requests were merged:</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/34</t>
        <t>- Proposed updates to RTP processing</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/35</t>
        <t>- fixed reference to receiver-id section</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37
      <list style="symbols">
        <t>The following GitHub pull request was merged:</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/33</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36
      <list style="symbols">
        <t>The following GitHub pull requests were merged:</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/32</t>
        <t>- extmap handling in BUNDLE.</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/31</t>
        <t>- Additional Acknowledgement text added.</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/30</t>
        <t>- MID SDES item security procedures updated</t>
        <t>https://github.com/cdh4u/draft-sdp-bundle/pull/29</t>
        <t>- Appendix B of JSEP moved into BUNDLE.</t>
        <t>- Associating RTP/RTCP packets with SDP m- lines.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35
      <list style="symbols">
        <t>Editorial changes on RTP streaming mapping section based on comments from Colin Perkins.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34
      <list style="symbols">
        <t>RTP streams, instead of RTP packets, are associated with m- lines.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33
      <list style="symbols">
        <t>Editorial changes based on comments from Eric Rescorla and Cullen Jennings:</t>
        <t>- Changes regarding usage of RTP/RTCP multiplexing attributes.</t>
        <t>- Additional text regarding associating RTP/RTCP packets with SDP m- lines.</t>
        <t>- Reference correction.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32
      <list style="symbols">
        <t>Editorial changes based on comments from Eric Rescorla and Cullen Jennings:</t>
        <t>- Justification for mechanism added to Introduction.</t>
        <t>- Clarify that the order of m- lines in the group:BUNDLE
          attribute does not have to be the same as the order in which
          the m- lines are listed in the SDP.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31
      <list style="symbols">
        <t>Editorial changes based on GitHub Pull requests by Martin Thomson:</t>
        <t>- https://github.com/cdh4u/draft-sdp-bundle/pull/2</t>
        <t>- https://github.com/cdh4u/draft-sdp-bundle/pull/1</t>
        <t>Editorial change based on comment from Diederick Huijbers (9th July 2016).</t>
        <t>Changes based on comments from Flemming Andreasen (21st June 2016):</t>
        <t>- Mux category for SDP bundle-only attribute added.</t>
        <t>- Mux category considerations editorial clarification.</t>
        <t>- Editorial changes.</t>
        <t>RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext.</t>
        <t>Note whether Design Considerations appendix is to be kept removed:</t>
        <t>- Appendix is kept within document.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30
      <list style="symbols">
        <t>Indicating in the Abstract and Introduction that
        the document updates RFC 3264.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29
      <list style="symbols">
        <t>Change based on WGLC comment from Colin Perkins.</t>
        <t>- Clarify that SSRC can be reused by another source
             after a delay of 5 RTCP reporting intervals.</t>
        <t>Change based on WGLC comment from Alissa Cooper.</t>
        <t>- IANA registry name fix.</t>
        <t>- Additional IANA registration information added.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28
      <list style="symbols">
       <t>- Alignment with exclusive mux procedures.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27
      <list style="symbols">
       <t>- Yet another terminology change.</t>
       <t>- Mux category considerations added.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26
      <list style="symbols">
        <t>- ICE considerations modified: ICE-related SDP attributes only added
             to the bundled m- line representing the selected BUNDLE address.</t>
        <t>- Reference to draft-ietf-mmusic-ice-sip-sdp added.</t>
        <t>- Reference to RFC 5245 replaced with reference to draft-ietf-ice-rfc5245bis.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25
      <list style="symbols">
        <t>- RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux considerations.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24
      <list style="symbols">
        <t>- Reference and procedures associated with exclusive RTP/RTCP mux added</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23
      <list style="symbols">
        <t>- RTCP-MUX mandatory for bundled RTP m- lines</t>
        <t>- Editorial fixes based on comments from Flemming Andreasen</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22
      <list style="symbols">
        <t>- Correction of Ari's family name</t>
        <t>- Editorial fixes based on comments from Thomas Stach</t>
        <t>- RTP/RTCP correction based on comment from Magnus Westerlund</t>
        <t>-- http://www.ietf.org/mail-archive/web/mmusic/current/msg14861.html</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21
      <list style="symbols">
        <t>- Correct based on comment from Paul Kyzivat</t>
        <t>-- 'received packets' replaced with 'received data'</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
      <list style="symbols">
        <t>- Clarification based on comment from James Guballa</t>
        <t>- Clarification based on comment from Flemming Andreasen</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19
      <list style="symbols">
        <t>- DTLS Considerations section added.</t>
        <t>- BUNDLE semantics added to the IANA Considerations</t>
        <t>- Changes based on WGLC comments from Adam Roach</t>
        <t>-- http://www.ietf.org/mail-archive/web/mmusic/current/msg14673.html</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18
      <list style="symbols">
        <t>- Changes based on agreements at IETF#92</t>
        <t>-- BAS Offer removed, based on agreement at IETF#92.</t>
        <t>-- Procedures regarding usage of SDP "b=" line is replaced with a
        reference to to draft-ietf-mmusic-sdp-mux-attributes.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17
      <list style="symbols">
        <t>- Editorial changes based on comments from Magnus Westerlund.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16
      <list style="symbols">
        <t>- Modification of RTP/RTCP multiplexing section, based
        on comments from Magnus Westerlund.</t>
        <t>- Reference updates.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15
      <list style="symbols">
        <t>- Editorial fix.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14
      <list style="symbols">
        <t>- Editorial changes.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13
      <list style="symbols">
        <t>Changes to allow a newly suggested offerer BUNDLE address
        to be assigned to each bundled m- line.</t>
        <t>Changes based on WGLC comments from Paul Kyzivat</t>
        <t>- Editorial fixes</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12
      <list style="symbols">
        <t>Usage of SDP 'extmap' attribute added</t>
        <t>SDP 'bundle-only' attribute scoped with "m=" lines with a zero port value</t>
        <t>Changes based on WGLC comments from Thomas Stach</t>
        <t>- ICE candidates not assigned to bundle-only m- lines with a zero port value</t>
        <t>- Editorial changes</t>
        <t>Changes based on WGLC comments from Colin Perkins</t>
        <t>- Editorial changes:</t>
        <t>-- "RTP SDES item" -> "RTCP SDES item"</t>
        <t>-- "RTP MID SDES item" -> "RTCP MID SDES item"</t>
        <t>- Changes in section 10.1.1:</t>
        <t>-- "SHOULD NOT" -> "MUST NOT"</t>
        <t>-- Additional text added to the Note</t>
        <t>- Change to section 13.2:</t>
        <t>-- Clarify that mid value is not zero terminated</t>
        <t>- Change to section 13.3:</t>
        <t>-- Clarify that mid value is not zero terminated</t>
        <t>-- Clarify padding</t>
        <t>Changes based on WGLC comments from Paul Kyzivat</t>
        <t>- Editorial changes:</t>
        <t>Changes based on WGLC comments from Jonathan Lennox</t>
        <t>- Editorial changes:</t>
        <t>- Defintion of SDP bundle-only attribute alligned with
        structure in 4566bis draft</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11
      <list style="symbols">
        <t>Editorial corrections based on comments from Harald Alvestrand.</t>
        <t>Editorial corrections based on comments from Cullen Jennings.</t>
        <t>Reference update (RFC 7160).</t>
        <t>Clarification about RTCP packet sending when RTP/RTCP multiplexing
        is not used (http://www.ietf.org/mail-archive/web/mmusic/current/msg13765.html).</t>
        <t>Additional text added to the Security Considerations.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10
      <list style="symbols">
        <t>SDP bundle-only attribute added to IANA Considerations.</t>
        <t>SDES item and RTP header extension added to Abstract and Introduction.</t>
        <t>Modification to text updating section 8.2 of RFC 3264.</t>
        <t>Reference corrections.</t>
        <t>Editorial corrections.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09
      <list style="symbols">
        <t>Terminology change: "bundle-only attribute assigned to m= line" to
        "bundle-only attribute associated with m= line".</t>
        <t>Editorial corrections.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08
      <list style="symbols">
        <t>Editorial corrections.</t>
        <t>- "of"->"if" (8.3.2.5).</t>
        <t>- "optional"->"OPTIONAL" (9.1).</t>
        <t>- Syntax/ABNF for 'bundle-only' attribute added.</t>
        <t>- SDP Offer/Answer sections merged.</t>
        <t>- 'Request new offerer BUNDLE address' section added</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07
      <list style="symbols">
        <t>OPEN ISSUE regarding Receiver-ID closed.</t>
        <t>- RTP MID SDES Item.</t>
        <t>- RTP MID Header Extension.</t>
        <t>OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers closed.</t>
        <t>- Indicating that, when rtcp-mux is used, the answerer MUST NOT include
        an 'rtcp' attribute in the answer, based on the procedures in section 5.1.3 of
        RFC 5761.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06
      <list style="symbols">
        <t>Draft title changed.</t>
        <t>Added "SDP" to section names containing "Offer" or "Answer".</t>
        <t>Editorial fixes based on comments from Paul Kyzivat (http://www.ietf.org/mail-archive/web/mmusic/current/msg13314.html).</t>
        <t>Editorial fixed based on comments from Colin Perkins (http://www.ietf.org/mail-archive/web/mmusic/current/msg13318.html).</t>
        <t>- Removed text about extending BUNDLE to allow multiple RTP sessions within a BUNDLE group.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05
      <list style="symbols">
        <t>Major re-structure of SDP Offer/Answer sections, to align with RFC 3264 structure.</t>
        <t>Additional definitions added.</t>
        <t>- Shared address.</t>
        <t>- Bundled "m=" line.</t>
        <t>- Bundle-only "m=" line.</t>
        <t>- Offerer suggested BUNDLE mid.</t>
        <t>- Answerer selected BUNDLE mid.</t>
        <t>Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address to multiple "m=" lines until it has
        received an SDP Answer indicating support of the BUNDLE extension.</t>
        <t>Q8 Closed (IETF#88): An Offerer can, before it knows whether the Answerer supports the BUNDLE extension,
        assign a zero port value to a 'bundle-only' "m=" line.</t>
        <t>SDP 'bundle-only' attribute section added.</t>
        <t>Connection data nettype/addrtype restrictions added.</t>
        <t>RFC 3264 update section added.</t>
        <t>Indicating that a specific payload type value can be used in multiple "m=" lines, if the value
        represents the same codec configuration in each "m=" line.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04
      <list style="symbols">
        <t>Updated Offerer procedures (http://www.ietf.org/mail-archive/web/mmusic/current/msg12293.html).</t>
        <t>Updated Answerer procedures (http://www.ietf.org/mail-archive/web/mmusic/current/msg12333.html).</t>
        <t>Usage Session Description Protocol (SDP)
            Attributes When Multiplexing</title>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization/>
            </author>
            <date month="January" year="2021"/>
          </front>
	   <seriesInfo name="RFC" value="8859"/>
           <seriesInfo name="DOI" value="10.17487/RFC8859"/>
        </reference>

<!--draft-ietf-mmusic-mux-exclusive-12; part of SDP 'bundle-only' attribute added.</t>
        <t>Reference to Trickle ICE document added.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
      <list style="symbols">
        <t>Mechanism modified, to be based on usage C238; RFC 8858-->
<reference anchor='RFC8858' target="https://www.rfc-editor.org/info/rfc8858">
<front>
<title>Indicating Exclusive Support of SDP Offers
        with both different RTP and identical port number values, depending
        on whether it is known if RTP Control Protocol (RTCP)
       Multiplexing Using the remote endpoint supports Session Description Protocol (SDP)</title>
<author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name='RFC' value='8858' />
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>

<!--draft-ietf-mmusic-ice-sip-sdp-39; part of C238; RFC 8839 -->
<reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)</title>
<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
    <organization />
</author>

<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
    <organization />
</author>

<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>

<author initials='A' surname='Keränen' fullname='Ari Keränen'>
    <organization />
</author>

<author initials='R' surname='Shpount' fullname='Roman Shpount'>
    <organization />
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>

<!--draft-ietf-mmusic-trickle-ice-sip-18; part of C238 - 8840 -->
	<reference anchor="RFC8840" target="https://www.rfc-editor.org/info/rfc8840">
          <front>
            <title>A Session Initiation Protocol (SIP) Usage for Incremental
            Provisioning of Candidates for the
        extension.</t>
        <t>Cullen Jennings added as co-author.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01
      <list style="symbols">
        <t>No changes. New version due to expiration.</t>
      </list>
    </t>
    <t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00
      <list style="symbols">
        <t>No changes. New version due to expiration.</t>
      </list>
    </t>
    <t>Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00
      <list style="symbols">
        <t>Draft name changed.</t>
        <t>Harald Alvestrand added as co-author.</t>
        <t>"Multiplex" terminology changed to "bundle".</t>
        <t>Added text about single versus multiple RTP Sessions.</t>
        <t>Added reference to Interactive Connectivity
            Establishment (Trickle ICE)</title>
            <author initials="E" surname="Ivov" fullname="Emil Ivov">
              <organization/>
            </author>
            <author initials="T" surname="Stach" fullname="Thomas Stach">
              <organization/>
            </author>
            <author initials="E" surname="Marocco" fullname="Enrico Marocco">
              <organization/>
            </author>
            <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
              <organization/>
            </author>
            <date month="January" year="2021"/>
          </front>
	  <seriesInfo name="RFC" value="8840"/>
          <seriesInfo name="DOI" value="10.17487/RFC8840"/>
        </reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2543.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3611.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5576.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7160.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7657.xml"/>

<!-- draft-ietf-rtcweb-jsep; RFC 3550.</t>
      </list>
    </t>
  </section>
</middle>

<back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119"?>
    <?rfc include="reference.RFC.3264"?>
    <?rfc include="reference.RFC.3550"?>
    <?rfc include="reference.RFC.3605"?>
    <?rfc include="reference.RFC.3629"?>
    <?rfc include='reference.RFC.3711'?>
    <?rfc include="reference.RFC.4566"?>
    <?rfc include="reference.RFC.4961"?>
    <?rfc include="reference.RFC.5761"?>
    <?rfc include="reference.RFC.5764"?>
    <?rfc include="reference.RFC.5888"?>
    <?rfc include="reference.RFC.6347"?>
    <?rfc include="reference.RFC.7941"?>
    <?rfc include="reference.RFC.8174"?>
    <?rfc include="reference.RFC.8285"?>
    <?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-20"?>
    <?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?>
    <?rfc include="reference.I-D.draft-ietf-mmusic-mux-exclusive-12"?>
    <?rfc include="reference.I-D.draft-ietf-mmusic-ice-sip-sdp-20"?>
    <?rfc include="reference.I-D.draft-ietf-mmusic-trickle-ice-sip-14"?> 8829 -->
 <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
 <front>
 <title>JavaScript Session Establishment Protocol (JSEP)</title>
 <author initials='J.' surname='Uberti' fullname='Justin Uberti'>
   <organization/>
 </author>
 <author initials="C." surname="Jennings" fullname="Cullen Jennings">
   <organization/>
 </author>
 <author initials="E." surname="Rescorla" fullname="Eric Rescorla"
         role="editor">
 <organization/>
 </author>
 <date month='January' year='2021'/>
 </front>
 <seriesInfo name="RFC" value="8829"/>
 <seriesInfo name="DOI" value="10.17487/RFC8829"/>
 </reference>

<!--draft-ietf-ice-trickle-21; part of C238; RFC-to-be 8838 -->
<reference anchor="RFC8838" target="https://www.rfc-editor.org/info/rfc8838">
  <front>
    <title>Trickle ICE: Incremental Provisioning of Candidates for the
    Interactive Connectivity Establishment (ICE) Protocol</title>

    <author initials="E" surname="Ivov" fullname="Emil Ivov">
      <organization />
    </author>

    <author initials="J" surname="Uberti" fullname="Justin Uberti">
      <organization />
    </author>

    <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization />
    </author>

    <date month="January" year="2021" />
  </front>
  <seriesInfo name="RFC" value="8838" />
  <seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>

        <!--draft-ietf-avtext-lrr-07; in MISSREF and part of C324-->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtext-lrr.xml"/>

      </references>

    <references title="Informative References">
    <?rfc include="reference.RFC.3261"?>
    <?rfc include="reference.RFC.3611"?>
    <?rfc include="reference.RFC.5104"?>
    <?rfc include="reference.RFC.4585"?>
    <?rfc include="reference.RFC.5576"?>
    <?rfc include="reference.RFC.7160"?>
    <?rfc include="reference.RFC.7201"?>
    <?rfc include="reference.RFC.7656"?>
    <?rfc include="reference.RFC.7657"?>
    <?rfc include="reference.I-D.draft-ietf-ice-trickle-21"?>
    <?rfc include="reference.I-D.draft-ietf-avtext-lrr-07"?>
    </references>
    <section  title="Design Considerations" toc="default"> toc="default" numbered="true">
      <name>Design Considerations</name>
      <t>
        One of the main issues regarding the BUNDLE grouping extensions has been whether,
        in SDP Offers offers and SDP Answers, answers, the same port value can be inserted in "m="
        lines associated with a BUNDLE group, as the purpose of the extension is to negotiate
        the usage of a single transport for media specified by the "m=" sections. Issues
        with both approaches, discussed in the Appendix Appendix, have been raised. The outcome was to
        specify a mechanism which that uses SDP Offers offers with both different and identical port values.
      </t>
      <t>
        Below are the primary issues that have been considered when defining the "BUNDLE"
        grouping extension:
        <list style="symbols">
          <t>1) Interoperability
      </t>
      <ol spacing="normal" type="%d)">
        <li>Interoperability with existing UAs.</t>
          <t>2) Interoperability User Agents (UAs).</li>
        <li>Interoperability with intermediary Back to Back Back-to-Back User Agent (B2BUA) and proxy entities.</t>
          <t>3) Time entities.</li>
        <li>Time to gather, and the number of, ICE candidates.</t>
          <t>4) Different candidates.</li>
        <li>Different error scenarios, scenarios and when they occur.</t>
          <t>5) SDP Offer/Answer occur.</li>
        <li>SDP offer/answer impacts, including usage of port number value zero.</t>
        </list>
      </t> zero.</li>
      </ol>
      <section  title="UA Interoperability" toc="default"> toc="default" numbered="true">
        <name>UA Interoperability</name>
        <t>
        Consider the following SDP Offer/Answer offer/answer exchange, where Alice sends an SDP Offer offer to Bob:
        </t>
      <figure>
        <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP Offer
<t keepWithNext="true">SDP Offer</t>

<sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
      </figure>
      <figure>
        <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP Answer
]]></sourcecode>
<t keepWithNext="true">SDP Answer</t>

 <sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
      </figure>
]]></sourcecode>
        <t>
        RFC 4961 specifies a way of doing symmetric RTP RTP, but that is a later
        extension to RTP RTP, and Bob can not cannot assume that Alice supports RFC 4961. This
        means that Alice may be sending RTP from a different port than 10000 or
        10002 - -- some implementations simply send the RTP from an ephemeral
        port. When Bob's endpoint receives an RTP packet, the only way that Bob
        knows if the packet is to be passed to the video or audio codec is by looking at
        the port it was received on.
        This led prompted some SDP implementations to use the
        fact that each "m=" section had a different port number to use that port number as an index to find the
        correct m "m=" line in the SDP. SDP, since each "m"= section contains a different port number. As a result, some
        implementations that do support symmetric RTP and ICE still use an SDP data
        structure where SDP with "m=" sections with the same port such as:
        </t>
      <figure>
        <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP Offer
<t keepWithNext="true">SDP Offer</t>

<sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
      </figure>
]]></sourcecode>
        <t>
        will result in the second "m=" section being considered an SDP error
        because it has the same port as the first line.
        </t>
      </section>
      <section  title="Usage toc="default" numbered="true">
        <name>Usage of Port Number Value Zero" toc="default"> Zero</name>
        <t>
        In an SDP Offer offer or SDP Answer, answer, the media specified by an "m=" section can be
        disabled/rejected by setting the port number value to zero. This is different
        from
        from, e.g., using the SDP direction attributes, where RTCP traffic will
        continue even if the SDP "inactive" 'inactive' attribute is indicated for the
        associated "m=" section.
        </t>
        <t>
        If each "m=" section associated with a BUNDLE group would contain different
        port values, and one of those port values would be used for a BUNDLE address:port
        associated with the BUNDLE group, problems would occur if an endpoint wants to
        disable/reject the "m=" section associated with that port, by setting the port
        value to zero. After that, no "m=" section would contain the port value which that
        is used for the BUNDLE address:port. In addition, it is unclear what would happen
        to the ICE candidates associated with the "m=" section, as they are also used for
        the BUNDLE address:port.
        </t>
      </section>
      <section  title="B2BUA And toc="default" numbered="true">
        <name>B2BUA and Proxy Interoperability" toc="default"> Interoperability</name>
        <t>
        Some back to back back-to-back user agents may be configured in a mode where if
        the incoming call leg contains an SDP attribute the B2BUA does not
        understand, the B2BUA still generates that SDP attribute in the Offer
        for the outgoing call leg. Consider a B2BUA that did not understand
        the SDP "rtcp" 'rtcp' attribute, defined in RFC 3605, yet acted this way.
        Further assume that the B2BUA was configured to tear down any call
        where it did not see any RTCP for 5 minutes. In this case, if the B2BUA
        received an Offer like:
        </t>
    <figure>
      <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[

SDP Offer
<t keepWithNext="true">SDP Offer</t>

<sourcecode type="sdp"><![CDATA[
    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

]]></artwork>
        </figure>
]]></sourcecode>
        <t>
      It would be looking for RTCP on port 49171 but would not see any
      because the RTCP would be on port 53020 53020, and after five minutes, it would
      tear down the call. Similarly, a B2BUA that did not understand BUNDLE yet
      put BUNDLE it in its offer may be looking for media on the wrong port and
      tear down the call. It is worth noting that a B2BUA that generated an
      Offer with capabilities it does not understand is not compliant with the
      specifications.
        </t>
        <section  title="Traffic Policing" toc="default"> toc="default" numbered="true">
          <name>Traffic Policing</name>
          <t>
          Sometimes intermediaries do not act as B2BUAs, in the sense that
          they don't modify SDP bodies, bodies nor do they terminate SIP dialogs.
          Still, however,
          However, they may still use SDP information (e.g., IP address and
          port) in order to control traffic gating functions, functions and to set
          traffic policing rules. There might be rules which that will trigger
          a session to be terminated in case media is not sent or received
          on the ports retrieved from the SDP. This typically occurs once the
          session is already established and ongoing.
          </t>
        </section>
        <section  title="Bandwidth Allocation" toc="default"> toc="default" numbered="true">
          <name>Bandwidth Allocation</name>
          <t>
          Sometimes
          Sometimes, intermediaries do not act as B2BUAs, in the sense that
          they don't modify SDP bodies, bodies nor do they terminate SIP dialogs.
          Still, however,
          However, they may still use SDP information (e.g., codecs and
          media types) in order to control bandwidth allocation functions.
          The bandwidth allocation is done per "m=" section, which means that
          it might not be enough if media specified by all "m=" sections
          try to use that bandwidth. That may either simply lead to either bad
          user experience, experience or to termination of the call.
          </t>
        </section>
      </section>
      <section  title="Candidate Gathering" toc="default"> toc="default" numbered="true">
        <name>Candidate Gathering</name>
        <t>
        When using ICE, a candidate needs to be gathered for each port. This
        takes approximately 20 ms extra for each extra "m=" section due to the NAT
        pacing requirements. All of this gathering can be overlapped with other
        things while while, e.g., a web-page web page is loading to minimize the impact. If the client
        only wants to generate TURN Traversal Using Relays around NAT (TURN) or STUN ICE candidates for one of the "m="
        lines and then use trickle Trickle ICE <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/>
        to get the non host non-host ICE candidates for the rest of the "m=" sections, it MAY <bcp14>MAY</bcp14> do
        that and will not need any additional gathering time.
        </t>
        <t>
        Some people have suggested a TURN extension to get a bunch of TURN
        allocations at once. This would only provide a single STUN result result, so in
        cases where the other end did not support BUNDLE, it may cause more use of
        the TURN server server, but it would be quick in the cases where both sides
        supported BUNDLE and would fall back to a successful call in the other
        cases.
        </t>
      </section>

   <section anchor="sec-acks" toc="default" numbered="false">
      <name>Acknowledgements</name>
      <t>
      The usage of the SDP grouping extension for negotiating bundled media is
      based on similar alternatives proposed by <contact fullname="Harald
      Alvestrand"/> and <contact fullname="Cullen Jennings"/>. The BUNDLE
      extension described in this document is based on the different
      alternative proposals, and text (e.g., SDP examples) has been borrowed
      (and, in some cases, modified) from those alternative proposals.
      </t>
      <t>
      The SDP examples are also modified versions from the ones in the Alvestrand
      proposal.
      </t>
      <t>
      Thanks to <contact fullname="Paul Kyzivat"/>, <contact fullname="Martin
      Thomson"/>, <contact fullname="Flemming Andreasen"/>, <contact
      fullname="Thomas Stach"/>, <contact fullname="Ari Keränen"/>, <contact
      fullname="Adam Roach"/>, <contact fullname="Christian Groves"/>,
      <contact fullname="Roman Shpount"/>, <contact fullname="Suhas
      Nandakumar"/>, <contact fullname="Nils Ohlmeier"/>, <contact
      fullname="Jens Guballa"/>, <contact fullname="Raju Makaraju"/>, <contact
      fullname="Justin Uberti"/>, <contact fullname="Taylor Brandstetter"/>,
      <contact fullname="Byron Campen"/>, and <contact fullname="Eric
      Rescorla"/> for reading the text and providing useful feedback.
      </t>
      <t>
	Thanks to <contact fullname="Bernard Aboba"/>, <contact fullname="Peter
	Thatcher"/>, <contact fullname="Justin Uberti"/>, and <contact
	fullname="Magnus Westerlund"/> for providing the text for the section on
	RTP/RTCP stream association.
      </t>
      <t>
      Thanks to <contact fullname="Magnus Westerlund"/>, <contact
      fullname="Colin Perkins"/>, and <contact fullname="Jonathan Lennox"/>
      for providing help and text on the RTP/RTCP procedures.
      </t>
      <t>
       Thanks to <contact fullname="Charlie Kaufman"/> for performing the Sec-Dir review.
      </t>
      <t>
       Thanks to <contact fullname="Linda Dunbar"/> for performing the Gen-ART review.
      </t>
      <t>
      Thanks to Spotify for providing music for the countless hours of
      document editing.
      </t>
    </section>
    </section>
  </back>
</rfc>