<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> "rfc2629-xhtml.ent">
<rfc category='std' ipr='trust200902'
     docName='draft-ietf-mmusic-trickle-ice-sip-18'>

<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?> xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-mmusic-trickle-ice-sip-18" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" consensus="true" number="8840">
  <!-- xml2rfc v2v3 conversion 2.34.0 -->

  <front>
    <title abbrev='Trickle abbrev="Trickle ICE for SIP'> SIP">
      A Session Initiation Protocol (SIP) Usage for
      Incremental Provisioning of Candidates for
      the Interactive Connectivity Establishment (Trickle ICE)
    </title>
    <seriesInfo name="RFC" value="8840"/>
    <author initials='E.' surname='Ivov'
            fullname='Emil Ivov'> initials="E." surname="Ivov" fullname="Emil Ivov">
      <organization abbrev='Jitsi'>Jitsi</organization> abbrev="Jitsi">Jitsi</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Strasbourg</city>
          <code>67000</code>
          <country>France</country>
        </postal>
        <phone>+33 6 72 81 15 55</phone>
        <email>emcho@jitsi.org</email>
      </address>
    </author>
    <author initials="T." surname="Stach" fullname="Thomas Stach" > Stach">
      <organization>Unaffiliated</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Vienna</city>
          <region></region>
          <region/>
          <code>1130</code>
          <country>Austria</country>
        </postal>
        <email>thomass.stach@gmail.com</email>
      </address>
    </author>
    <author initials='E.' surname='Marocco' fullname='Enrico Marocco'> initials="E." surname="Marocco" fullname="Enrico Marocco">
      <organization>Telecom Italia</organization>
      <address>
        <postal>
          <street>Via G. Reiss Romoli, 274</street>
          <city>Turin</city>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <email>enrico.marocco@telecomitalia.it</email>
      </address>
    </author>
    <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>
    <date /> month="May" year="2020"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

    <abstract>
      <t>
        The Interactive Connectivity Establishment (ICE) protocol
        describes a Network Address Translator (NAT) traversal mechanism
        for UDP-based multimedia sessions established with the
        Offer/Answer model. The ICE extension for Incremental
        Provisioning of Candidates (Trickle ICE) defines a mechanism
        that allows ICE Agents to shorten session establishment delays
        by making the candidate gathering and connectivity checking
        phases of ICE non-blocking and by executing them in parallel.
      </t>
      <t>
        This document defines usage semantics for Trickle ICE with the Session
        Initiation Protocol (SIP).  The document also defines a new SIP Info
        Package to support this usage together with the corresponding media
        type.  Additionally, a new SDP Session Description Protocol (SDP)
        'end-of-candidates' attribute and a new SIP Option Tag 'trickle-ice'
        are defined.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The Interactive Connectivity Establishment (ICE) protocol
        <xref target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445" format="default"/> describes
        a mechanism for Network Address Translator (NAT) traversal
        that consists of three main phases.
      </t>
      <t>
        During the first phase phase, an agent gathers a set of candidate
        transport addresses (source IP address, port IP, port, and transport
        protocol).
        This is followed by a second phase
        where these candidates are sent to a
        remote agent within
        the Session Description Protocol (SDP) body of a SIP message.
        At the remote agent agent, the gathering procedure is repeated and
        candidates are sent to the first agent.
        Once the candidate information is available, a third phase
        starts in parallel where connectivity between all candidates
        in both sets is checked (connectivity checks).
        Once these phases
        have been completed, and only then, both agents can begin
        communication.
      </t>
      <t>
        According to <xref target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445" format="default"/>,
        the three phases above happen consecutively, in a blocking way,
        which can introduce undesirable setup delay during session
        establishment.
        The Trickle ICE extension
        <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/> defines generic
        semantics required for these ICE phases to happen
        in a parallel, non-blocking way and hence speed speeds up session
        establishment.
      </t>
      <t>
        This specification defines a usage of Trickle ICE with
        the Session Initiation Protocol (SIP)<xref target="RFC3261"/>. target="RFC3261" format="default"/>.
        It describes how ICE
        candidates are to be exchanged incrementally using SIP INFO
        requests <xref target="RFC6086"/> target="RFC6086" format="default"/>
        and how the Half Trickle and Full Trickle modes defined in
        <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/> are to be used by
        SIP User Agents (UAs) depending on their expectations for
        support of Trickle ICE by a remote agent.
      </t>
      <t>
        This document defines a new Info Package as specified in
        <xref target="RFC6086"/> target="RFC6086" format="default"/> for use with Trickle ICE together
        with the corresponding media type,
        SDP attribute attribute, and SIP option tag.
      </t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</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 target="RFC2119"/>, target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
      <t>
        This specification makes use of terminology defined by the
        ICE protocol for Interactive Connectivity Establishment in
        <xref target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445" format="default"/> and by its Trickle ICE extension in
        <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>. It is assumed that
        the reader is familiar with the terminology from both documents.
      </t>

<!--[rfced] FYI, we updated the expansion of NAT to be 'Traversal
Using Relays around NAT (TURN)' (instead of 'Traversal Using
Relay NAT (TURN)') to match RFC 5766 and the companion documents.

Updated:
   [RFC8445] also describes how ICE makes use of the Session
   Traversal Utilities for NAT (STUN) protocol [RFC5389] and its
   extension Traversal Using Relay NAT (TURN) [RFC5766].
-->
      <t>  <xref target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445" format="default"/> also describes
         how ICE makes use of the
         Session Traversal Utilities for NAT (STUN) protocol
         <xref target="RFC5389"/> target="RFC5389" format="default"/> and its extension
         Traversal Using Relay Relays around NAT (TURN) <xref target="RFC5766"/>. target="RFC5766" format="default"/>.
      </t>
    </section>
    <section title="Protocol Overview" anchor='overview'> anchor="overview" numbered="true" toc="default">
      <name>Protocol Overview</name>
      <t>
        When using  ICE for SIP according to
        <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> target="RFC8839" format="default"/>,
        the ICE candidates are exchanged solely via
        SDP Offer/Answer as per <xref target="RFC3264"/>. target="RFC3264" format="default"/>.
        This specification defines an additional mechanism
        where candidates can be exchanged using SIP INFO messages
        and a newly defined Info Package <xref target="RFC6086"/>. target="RFC6086" format="default"/>.
        This also allows ICE
        candidates also to be sent in parallel to an ongoing Offer/Answer
        negotiation and/or after the completion of the Offer/Answer
        negotiation.
      </t>
      <t>
        Typically, in cases where Trickle ICE is fully supported,
        the Offerer sends an INVITE request
        containing a subset of candidates.
        Once an early dialog is established established,
        the Offerer can continue sending
        candidates in INFO requests within that dialog.
      </t>
      <t>
        Similarly, an Answerer can send
        ICE candidates using INFO requests within
        the dialog established by its 18x provisional response.
        <xref target="fig-intro-example"/> target="fig-intro-example" format="default"/> shows such a sample
        exchange:
      </t>
      <t>

<!--[rfced] FYI, we updated 'Turn' to 'TURN' in Figures 1 and 9.
If this is not correct, please let us know.

Original:
STUN/Turn
Servers

Updated:
STUN/TURN
Servers
-->
      <figure title="Sample anchor="fig-intro-example">
        <name>Sample Trickle ICE scenario Scenario with SIP"
                anchor="fig-intro-example">
          <artwork><![CDATA[
   STUN/Turn SIP</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   STUN/TURN                                                STUN/TURN
    Servers          Alice                      Bob          Servers
       |               |                         |                |
       |  STUN Bi.Req. |     INVITE (Offer)      |                |
       |<--------------|------------------------>|                |
       |               |      183 (Answer)       | TURN Alloc Req |
       | STUN Bi.Resp. |<------------------------|--------------->|
       |-------------->|  INFO/OK (SRFLX Cand.)  |                |
       |               |------------------------>| TURN Alloc Resp|
       |               |  INFO/OK (Relay Cand.)  |<---------------|
       |               |<------------------------|                |
       |               |                         |                |
       |               |  More Cands & ConnChecks|                |
       |               |<=======================>|                |
       |               |                         |                |
       |               |          200 OK         |                |
       |               |<------------------------|                |
       |               |            ACK          |                |
       |               |------------------------>|                |
       |               |                         |                |
       |               |<===== MEDIA FLOWS =====>|                |
       |               |                         |                |

       Note: SRFLX "SRFLX" denotes server-reflexive candidates ]]></artwork>
      </figure>
      </t>
      <section title="Discovery issues" anchor="disco-issues"> anchor="disco-issues" numbered="true" toc="default">
        <name>Discovery Issues</name>
        <t>
          In order to benefit from Trickle ICE's full potential and
          reduce session establishment latency to a minimum, Trickle ICE
          agents need to generate SDP Offers and Answers that contain
          incomplete,
          incomplete and potentially empty sets of candidates. Such Offers
          and Answers can only be handled meaningfully by agents that
          actually support incremental candidate provisioning, which
          implies the need to confirm such support before  using
          it.
        </t>
        <t>
          Contrary to other protocols,
          where "in advance" capability
          discovery is widely implemented, the mechanisms that allow this
          for SIP (i.e., a combination of UA Capabilities capabilities
          <xref target="RFC3840"/> target="RFC3840" format="default"/> and Globally Routable User Agent URIs (GRUU) (GRUUs) <xref target="RFC5627"/>) target="RFC5627" format="default"/>)
          have only seen low levels of adoption.
          This presents an issue
          for Trickle ICE implementations as SIP UAs do not have an
          obvious means of verifying that their peer will support
          incremental candidate provisioning.
        </t>
        <t>
          The Half Trickle mode of operation defined in the Trickle
          ICE specification <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/>
          provides one way around this, by requiring the first Offer to
          contain a complete set of local ICE candidates
          and only using only
          incremental provisioning of remote candidates
          for the rest of the session.
        </t>
        <t>
          While using Half Trickle does provide a working solution solution, it
          also comes at the price of increased latency. Therefore,
          <xref target="disco"/> therefore target="disco" format="default"/> makes several alternative
          suggestions that enable SIP UAs to engage in Full Trickle
          right from their first Offer: <xref target="disco-prov"/> target="disco-prov" format="default"/>
          discusses the use of on-line online provisioning as a means of
          allowing the use of Trickle ICE for all endpoints in controlled
          environments. <xref target="disco-gruu"/> target="disco-gruu" format="default"/> describes
          anticipatory discovery for implementations that actually do
          support GRUU and UA Capabilities capabilities, and
          <xref target="half-full-trickle"/> target="half-full-trickle" format="default"/> discusses the implementation
          and use of Half Trickle by SIP UAs where none of the above
          are an option.
        </t>
      </section>
      <section title="Relationship numbered="true" toc="default">
        <name>Relationship with the Offer/Answer Model"> Model</name>
        <t>
          From the perspective of SIP middle boxes middleboxes and proxies proxies,
          the Offer/Answer exchange for
          Trickle ICE looks partly similar to the Offer/Answer exchange
          for regular ICE for SIP
          <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. target="RFC8839" format="default"/>.
          However, in order to have the full picture of the candidate
          exchange, the newly introduced INFO messages
          need to be considered as well.
        </t>
        <t>
        <figure title="Distinguishing anchor="fig-oa-and-trickle">
          <name>Distinguishing between Trickle ICE and
          traditional signaling." anchor="fig-oa-and-trickle">
            <artwork>
  <![CDATA[ Traditional Signaling</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------+  +-------------------------------+
|   Alice      +--------------+ |  | +--------------+       Bob    |
|              | Offer/Answer | |  | | Offer/Answer |              |
| +--------+   |    Module    | |  | |    Module    |   +--------+ |
| |  ICE   |   +--------------+ |  | +--------------+   |  ICE   | |
| | Module |         |          |  |        |           | Module | |
| +--------+         |          |  |        |           +--------+ |
+-------------------------------+  +-------------------------------+
      |              |                      |                |
      |              |    INVITE (Offer)    |                |
      |              |--------------------->|                |
      |              |     183 (Answer)     |                |
      |              |<---------------------|                |
      |              |                      |                |
      |                                                      |
      |             SIP INFO (more candidates)               |
      |----------------------------------------------------->|
      |             SIP INFO (more candidates)               |
      |<-----------------------------------------------------|
      |                                                      |
      |          STUN Binding Requests/Responses             |
      |----------------------------------------------------->|
      |          STUN Binding Requests/Responses             |
      |<-----------------------------------------------------|
      |                                                      |

]]>
            </artwork>                                                      |]]></artwork>
        </figure>
        </t>
        <t>
          From an architectural viewpoint, as displayed in
          <xref target="fig-oa-and-trickle"/>, target="fig-oa-and-trickle" format="default"/>, exchanging candidates
          through SIP INFO requests could be represented as signaling
          between ICE modules and not between Offer/Answer modules of
          SIP User Agents. UAs. Then, such INFO requests
          do not impact the state of the Offer/Answer transaction other
          than providing additional candidates.
          Consequently, INFO requests are not considered Offers or Answers.
          Nevertheless, candidates that have been exchanged
          using INFO requests
          SHALL
          <bcp14>SHALL</bcp14> be included in subsequent Offers or Answers.
          The version number in the "o=" line of that subsequent Offer
          needs to be incremented by 1 per the rules
          in <xref target="RFC3264"/>. target="RFC3264" format="default"/>.
        </t>
      </section>
    </section>
    <section title="Incremental anchor="OAproc" numbered="true" toc="default">
      <name>Incremental Signaling of ICE candidates" anchor="OAproc"> Candidates</name>
      <t>
        Trickle ICE Agents will exchange
        ICE descriptions compliant to
        <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/>
        via Offer/Answer procedures and/or INFO request bodies.
        This requires the following SIP-specific extensions:
      </t>
      <t>
        <list style="numbers">
          <t>
      <ol spacing="normal" type="1">
        <li>
            Trickle ICE Agents MUST <bcp14>MUST</bcp14> indicate support for Trickle ICE by
            including the SIP option-tag 'trickle-ice' in a SIP Supported: header field
            within all SIP INVITE requests and  responses.
          </t>
          <t>
          </li>
        <li>
            Trickle ICE Agents MUST <bcp14>MUST</bcp14> indicate support for Trickle ICE by
            including the ice-option 'trickle'
            within all SDP Offers and Answers in accordance to
            <xref target="I-D.ietf-ice-trickle"/>.
          </t>
          <t> target="RFC8838" format="default"/>.
          </li>
        <li>
          Trickle ICE Agents MAY <bcp14>MAY</bcp14> include any number of ICE candidates,
          i.e.
          i.e., from zero to the complete set of candidates,
          in their initial Offer or Answer.
          If the complete candidate set is included already included
          in the initial Offer, this it is called Half-Trickle.
          </t>
          <t> Half Trickle.
          </li>
        <li>
            Trickle ICE Agents MAY <bcp14>MAY</bcp14> exchange additional ICE candidates using INFO requests
            within an existing INVITE dialog usage (including an early dialog)
            as specified in <xref target="RFC6086"/>. target="RFC6086" format="default"/>.
            The INFO requests carry an Info-Package: trickle-ice.
            Trickle ICE Agents MUST <bcp14>MUST</bcp14> be prepared to receive INFO requests
            within that same dialog usage,
            containing additional candidates and/or
            an indication that trickling of such candidates has ended.
          </t>
          <t>
          </li>
        <li>
            Trickle ICE Agents MAY <bcp14>MAY</bcp14> exchange additional ICE candidates
            before the Answerer has sent the Answer provided that
            an invite dialog usage is established at both Trickle ICE Agents.
            Note that in case of forking forking, multiple early dialogs may exist.
          </t>
        </list>
      </t>
          </li>
      </ol>
      <t>
         The following sections provide further details on how
         Trickle ICE Agents perform the initial Offer/Answer exchange
         (<xref target="InitialOA"/>), target="InitialOA" format="default"/>),
         perform subsequent Offer/Answer exchanges
         (<xref target="subsOA"/>) target="subsOA" format="default"/>),
         and establish the INVITE dialog usage
         (<xref target="dialog-est"/>) target="dialog-est" format="default"/>)
         such that they can incrementally trickle candidates
         (<xref target="info-sdp"/>). target="info-sdp" format="default"/>).
      </t>
      <section title="Initial anchor="InitialOA" numbered="true" toc="default">
        <name>Initial Offer/Answer Exchange" anchor="InitialOA"> Exchange</name>
        <section title="Sending anchor="IniOS" numbered="true" toc="default">
          <name>Sending the Initial Offer"  anchor="IniOS"> Offer</name>
          <t>
                 If the Offerer includes candidates in its initial Offer,
                 it MUST <bcp14>MUST</bcp14> encode these candidates as specified in
                 <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. target="RFC8839" format="default"/>.
          </t>
          <t>If the Offerer wants to send its initial Offer
                 before knowing any candidate for one or more media descriptions,
                 it MUST <bcp14>MUST</bcp14> set the port to the default value  '9' for these media descriptions.
                 If the Offerer does not want to include the
                 host IP address in the corresponding c-line,
                 e.g.
                 e.g., due to privacy reasons,
                 it SHOULD <bcp14>SHOULD</bcp14> include a default address in the c-line,
                  which is set to the IPv4 address 0.0.0.0 or
                 to the IPv6 equivalent ::.
          </t>
          <t>
<!--[rfced] Please review whether the reference to RFC 6086 is correct
in the following text as we do not see mention of the RTCP transport
address or the "a=rtcp" attribute in that document.

Original:
   In this case, the Offerer obviously cannot know the RTCP transport
   address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086].
-->
                 In this case, the Offerer obviously cannot know the
		 RTCP transport address;
                 thus, it <bcp14>MUST NOT</bcp14> include the "a=rtcp" attribute <xref target="RFC6086"/>. target="RFC6086" format="default"/>.
                 This avoids potential ICE mismatch
                 (see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>) target="RFC8839" format="default"/>) for the RTCP transport address.
          </t>
          <t>
                 If the Offerer wants to use RTCP multiplexing
                 <xref target="RFC5761"/> target="RFC5761" format="default"/>
                 and/or exclusive RTCP multiplexing
                 <xref target="I-D.ietf-mmusic-mux-exclusive"/>, target="RFC8858" format="default"/>,
                 it still will include the "a=rtcp-mux" and/or
                 "a=rctp-mux-only" attribute
                 in the initial Offer.
          </t>
          <t>
                 In any case, the Offerer MUST <bcp14>MUST</bcp14> include
                 the attribute "a=ice-options:trickle" in accordance to
                <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/> and
                MUST
                <bcp14>MUST</bcp14> include in each "m="-line "m=" line a "a=mid:" attribute
                in accordance to <xref target="RFC5888"/>. target="RFC5888" format="default"/>.

                The "a=mid:" attribute identifies the "m="-line "m=" line
                to which a candidate belongs and
                helps in case of multiple "m="-lines, "m=" lines,
                when candidates candidate gathering could occur in a an order different
                from the order of the "m="-lines. "m=" lines.
          </t>
        </section>
        <section title="Receiving anchor="IniOR" numbered="true" toc="default">
          <name>Receiving the Initial Offer"  anchor="IniOR"> Offer</name>
          <t>
                 If the initial Offer included candidates,
                 the Answerer uses these candidates to start ICE processing
                 as specified in <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
          </t>
          <t>
                 If the initial Offer included the attribute a=ice-options:trickle, "a=ice-options:trickle",
                 the Answerer MUST <bcp14>MUST</bcp14> be prepared for receiving trickled candidates later on.
          </t>
          <t>
                 In case of a "m/c=" line with default values values,
                 none of the eventually trickled candidates
                 will match the default destination.
                 This situation MUST NOT <bcp14>MUST NOT</bcp14> cause an ICE mismatch
                 (see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>). target="RFC8839" format="default"/>).
          </t>
        </section>
        <section title="Sending anchor="IniAS" numbered="true" toc="default">
          <name>Sending the Initial Answer"  anchor="IniAS"> Answer</name>
          <t>
                 If the Answerer includes candidates in its initial Answer,
                 it MUST <bcp14>MUST</bcp14> encode these candidates as specified in
                 <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. target="RFC8839" format="default"/>.
          </t>
          <t>If the Answerer wants to send its initial Answer
                 before knowing any candidate for one or more media descriptions,
                 it MUST <bcp14>MUST</bcp14> set the port to the default value  '9' for these media descriptions.
                 If the  Answerer does not want to include the
                 host IP address in the corresponding c-line,
                 e.g.
                 e.g., due to privacy reasons,
                 it SHOULD <bcp14>SHOULD</bcp14> include a default address in the c-line,
                  which is set to the IPv4 address 0.0.0.0 or
                 to the IPv6 equivalent ::.
          </t>
          <t>
                 In this case, the Answerer obviously cannot know the RTCP transport address and, address; thus, MUST NOT
                 it <bcp14>MUST NOT</bcp14> include the "a=rtcp" attribute <xref target="RFC6086"/>. target="RFC6086" format="default"/>.
                 This avoids potential ICE mismatch
                 (see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>) target="RFC8839" format="default"/>) for the RTCP transport address.
          </t>
          <t>
                 If the Answerer accepts to the use of RTCP multiplexing
                 <xref target="RFC5761"/> target="RFC5761" format="default"/>
                 and/or exclusive RTCP multiplexing
                 <xref target="I-D.ietf-mmusic-mux-exclusive"/>, target="RFC8858" format="default"/>,
                 it will include the "a=rtcp-mux" attribute
                 in the initial Answer.
          </t>
          <t>
                 In any case, the Answerer MUST <bcp14>MUST</bcp14> include
                 the attribute "a=ice-options:trickle" in accordance to
                <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/> and
                MUST
                <bcp14>MUST</bcp14> include in each "m="-line "m=" line
                a "a=mid:" attribute in accordance to
                <xref target="RFC5888"/>. target="RFC5888" format="default"/>.
          </t>
        </section>
        <section title="Receiving anchor="IniAR" numbered="true" toc="default">
          <name>Receiving the Initial Answer"  anchor="IniAR"> Answer</name>
          <t>
                 If the initial Answer included candidates,
                 the Offerer uses these candidates to start ICE processing
                 as specified in <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
          </t>
          <t>
                 In case of a "m/c=" line with default values values,
                 none of the eventually trickled candidates
                 will match the default destination.
                 This situation MUST NOT <bcp14>MUST NOT</bcp14> cause an ICE mismatch
                 (see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>). target="RFC8839" format="default"/>).
          </t>
        </section>
      </section>
      <section title="Subsequent anchor="subsOA" numbered="true" toc="default">
        <name>Subsequent Offer/Answer Exchanges" anchor="subsOA"> Exchanges</name>
        <t>
<!--[rfced] Please review if Section 4.2 ("Generic Procedures") is
the correct section to reference in the following. Should it
perhaps be Section 4.4 ("Subsequent Offer/Answer Exchanges")?

Original:
   Subsequent Offer/Answer exchanges are handled as for regular ICE (see
   section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]).

Note: I-D.ietf-mmusic-ice-sip-sdp is RFC-to-be 8839 available
from https://www.rfc-editor.org/authors/rfc8839.html
-->
            Subsequent Offer/Answer exchanges are handled
            the same as regular ICE (see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>). target="RFC8839" sectionFormat="of" section="4.2"/>).
        </t>
        <t>
<!--[rfced] Please let us know how to update the following
section number as I-D.ietf-mmusic-ice-sip-sdp (RFC-to-be 8839)
does not contain Section 3.2.

Original:
   If an Offer or Answer needs to be sent while the ICE agents are in
   the middle of trickling section 3.2 of [I-D.ietf-mmusic-ice-sip-sdp])
   applies.
-->
        <t> If an Offer or Answer needs to be sent while the ICE agents
            are in the middle of trickling,
            <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>) target="RFC8839" sectionFormat="of" section="3.2"/> applies.
            This means that an ICE agent includes candidate attributes
            for all local candidates it had trickled previously
            for a specific media stream.
        </t>

                      <t>
[RFC EDITOR NOTE: The section  3.2 in above sentence is correct for version 20 of said I-D.
 Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
          </t>
      </section>
      <section title="Establishing anchor="dialog-est" numbered="true" toc="default">
        <name>Establishing the Dialog" anchor="dialog-est"> Dialog</name>
        <t>
          In order to be able to start trickling, the
          following two conditions need to be satisfied at the SIP UAs:
        </t>
        <t>
          <list style="symbols">
            <t>
        <ul spacing="normal">
          <li>
              Trickle ICE support at the peer agent MUST <bcp14>MUST</bcp14> be confirmed.
            </t>
            <t>
            </li>
          <li>
              A dialog MUST <bcp14>MUST</bcp14> have been created between the peers.
            </t>
          </list>
        </t>
            </li>
        </ul>
        <t>
          <xref target="disco"/> target="disco" format="default"/> discusses in detail the various options
          for satisfying the first of the above conditions. Regardless However, regardless
          of those mechanisms, however, agents are certain to have a
          clear understanding of whether their peers support trickle
          ICE once an Offer and an Answer have been exchanged,
          which also allows for ICE processing to commence
          (see <xref target="offerer-can-trickle"/>). target="offerer-can-trickle" format="default"/>).
        </t>
        <section title="Establishing anchor="relprov" numbered="true" toc="default">
          <name>Establishing Dialog State through Reliable Offer/Answer Delivery" anchor="relprov">
          <t> Delivery</name>
          <figure title="SIP anchor="offerer-can-trickle">
            <name>A SIP Offerer can freely trickle as soon as it receives an Answer."
                  anchor="offerer-can-trickle">
              <artwork><![CDATA[ Answer</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------>|
                  |      183 (Answer)       |
                  |<------------------------|
                  |        PRACK/OK         |
                  |------------------------>|
                  |                         |
          +----------------------------------------+
          |Alice and Bob know that both can trickle|
          |and know that the dialog is in the early|
          |state. Send INFO!                       |
          +----------------------------------------+
                  |                         |
                  |  INFO/OK (+SRFLX Cand.) |
                  |------------------------>|
                  |  INFO/OK (+SRFLX Cand.) |
                  |<------------------------|
                  |                         |

        Note: SRFLX "SRFLX" denotes server-reflexive candidates

              ]]></artwork> candidates]]></artwork>
          </figure>
          </t>
          <t>
            As shown in <xref target="offerer-can-trickle"/> target="offerer-can-trickle" format="default"/>,
            satisfying both conditions is relatively trivial for
            ICE Agents that have sent an Offer in an INVITE and that have
            received an Answer in a reliable provisional response.
            It is guaranteed to have confirmed support (or lack thereof) for
            Trickle ICE at the Answerer (or lack thereof) and to have
            fully initialized the SIP dialog at both ends.
            Offerers and Answerers (after receipt of the PRACK request)
            in the above situation can therefore
            freely commence trickling within the newly established dialog.
          </t>
        </section>
        <section title="Establishing anchor="unrelprov" numbered="true" toc="default">
          <name>Establishing Dialog State through Unreliable Offer/Answer Delivery" anchor="unrelprov"> Delivery</name>
          <t>
            The situation is a bit more delicate for agents that have
            received an Offer in an INVITE request and have sent an Answer
            in an unreliable provisional response because, once the
            response has been sent, the Answerer does not
            know when or if it has been received
            (<xref target="answerer-cant-trickle"/>). target="answerer-cant-trickle" format="default"/>).
          </t>
          <t>
          <figure title="A anchor="answerer-cant-trickle">
            <name>A SIP UA that sent an Answer in an unreliable provisional response does not know if it was received and or if the dialog at the side of the Offerer has entered the early
                           state"
                  anchor="answerer-cant-trickle">
              <artwork><![CDATA[ state</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------>|
                  |      183 (Answer)       |
                  |<------------------------|
                  |                         |
                  |               +----------------------+
                  |               |Bob:  I don't know if |
                  |               |Alice got my 183 or if|
                  |               |her dialog is already |
                  |               |in the early state.   |
                  |               |  Can I send INFO???  |
                  |               +----------------------+
                  |                         | ]]></artwork>
          </figure>
          </t>
          <t>

<!--[rfced] Please confirm whether RFC 3262 is the correct reference
in the text below, as we see "an exponential backoff" in that document
but no mention of back-off timers. (Two instances.)

Original (4.3.2):
   In order to clear this ambiguity as soon as possible, the Answerer
   needs to retransmit the provisional response with the exponential
   back-off timers described in [RFC3262].

Original (4.3.3):
   Agents that choose to establish the dialog in this way, MUST
   retransmit these responses with the exponential back-off timers
   described in [RFC3262].
-->
            In order to clear this ambiguity as soon as possible,
            the Answerer needs to retransmit the provisional response
            with the exponential backoff timers described in
            <xref target="RFC3262"/>. target="RFC3262" format="default"/>.
            These retransmissions MUST <bcp14>MUST</bcp14> cease on receipt
            of an INFO request carrying a 'trickle-ice' Info Package body,
            on receipt of any other in-dialog request from the offerer offerer, or
            on transmission of the Answer in a 2xx response.
            The offerer cannot send in-dialog requests until it receives
            a response, so the arrival of such a request proves that
            the response has arrived.

<!--[rfced] Please let us know how to update these section numbers
as I-D.ietf-mmusic-ice-sip-sdp does not contain Section 6.1.1.

Original:
   Using the INFO request for dialog confirmation is similar
   to the procedure described in section 6.1.1 of <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>
   [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is
   replaced by the INFO request.
            </t>
          <t>
[RFC EDITOR NOTE: The

Original:
   This is again similar
   to the procedure described in section 6.1.1 in above sentence of
   [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is correct not yet
   provided.
-->

            Using the INFO request for version 20 of said I-D.
 Authors need dialog confirmation
            is similar to cross-check during Auth48 since it could have have changed the procedure described in
            <xref target="RFC8839" sectionFormat="of" section="6.1.1"/>, except that
            the meantime.]
          </t> STUN binding Request is replaced by the INFO request.
          </t>
          <t>
            The Offerer MUST <bcp14>MUST</bcp14> send a Trickle ICE INFO request as soon as
            it receives an SDP Answer in an unreliable provisional
            response. This INFO request MUST <bcp14>MUST</bcp14> repeat the candidates
            that were already provided in the Offer (as would be the case
            when Half Trickle is performed or when new candidates have not
            been learned since then).
            The first case could happen when Half Trickle is used and
            all candidate candidates are already in the initial offer.
            The second case could happen when Full Trickle is used and
            the offerer is currently gathering additional candidates, candidates
            but did not yet get them.
            Also, if the initial Offer did not contain any candidates,
            depending on how the Offerer gathers its candidates and
            how long it takes to do so, this INFO could still contain no candidates.
          </t>
          <t>
            When Full Trickle is used and if newly learned candidates
            are available, the Offerer SHOULD <bcp14>SHOULD</bcp14> also deliver
            these candidates in said INFO request,
            unless it wants to hold back some candidates in reserve,
            e.g.
            e.g., in case that these candidates
            are expensive to use and would only be trickled
            if all other candidates failed.
          </t>
          <t>
            The Offerer SHOULD <bcp14>SHOULD</bcp14> include an end-of-candidates attribute
            in case candidate discovery has ended in the mean time meantime
            and no further candidates are to be trickled.
          </t>
          <t>
            As soon as an Answerer has received such an INFO request,
            the Answerer has an indication that a dialog is established
            at both ends and trickling can begin trickling
            (<xref target="answerer-can-now-trickle"/>). target="answerer-can-now-trickle" format="default"/>).
          </t>
          <t>
              Note: The +SRFLX "+SRFLX" in
             <xref target="answerer-can-now-trickle"/> target="answerer-can-now-trickle" format="default"/>
             indicates that additionally additional newly learned server-reflexive candidates are included.
          </t>
          <t>
          <figure title="A anchor="answerer-can-now-trickle">
            <name>A SIP UA that received an INFO request after sending an unreliable                            provisional response knows that the dialog at the side of the receiver has entered the early
                           state" anchor="answerer-can-now-trickle">
              <artwork><![CDATA[             state</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------>|
                  |      183 (Answer)       |
                  |<------------------------|
                  |  INFO/OK (+SRFLX Cand.) |
                  |------------------------>|
                  |                         |
                  |               +----------------------+
                  |               |Bob:  Now I know Alice|
                  |               | is ready. Send INFO! |
                  |               +----------------------+
                  |  INFO/OK (+SRFLX Cand.) |
                  |<------------------------|
                  |                         |
                  |    200/ACK (Answer)     |
                  |<------------------------|

          Note: SRFLX "SRFLX" denotes server-reflexive candidates ]]></artwork>
          </figure>
          </t>
          <t>
          When sending the Answer in the 200 OK response to the INVITE request,
          the Answerer needs to repeat
          exactly the same Answer that was previously sent
          in the unreliable provisional
          response in order to fulfill the corresponding requirements in
          <xref target="RFC3264"/>. target="RFC3264" format="default"/>.
          Thus, the Offerer needs to be prepared
          for receiving a different number of candidates
          in that repeated Answer than previously exchanged via trickling
          and MUST <bcp14>MUST</bcp14> ignore the candidate information
          in that 200 OK response.
          </t>
        </section>
        <section title="Initiating anchor="head-start" numbered="true" toc="default">
          <name>Initiating Trickle ICE without an SDP Answer"
                 anchor="head-start"> Answer</name>
          <t>
            The ability to convey arbitrary candidates in INFO
            message bodies allows ICE Agents to initiate trickling
            without actually sending an Answer.
            Trickle ICE Agents can therefore respond to an INVITE request
            with provisional responses without an SDP Answer
            <xref target="RFC3261"/>. target="RFC3261" format="default"/>.
            Such provisional responses serve for establishing an early dialog.
          </t>
          <t>
            Agents that choose to establish the dialog in this way,
            MUST way
            <bcp14>MUST</bcp14> retransmit these responses
            with the exponential back-off backoff timers described in
            <xref target="RFC3262"/>. target="RFC3262" format="default"/>.
            These retransmissions MUST <bcp14>MUST</bcp14> cease on receipt
            of an INFO request carrying a 'trickle-ice' Info Package body,
            on receipt of any in-dialog request requests from the offerer offerer, or
            on transmission of the Answer in a 2xx response.
            The offerer cannot send in-dialog requests until it receives
            a response, so the arrival of such a request proves that
            the response has arrived.
            This is again similar to the procedure described in section
            6.1.1 of
            <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> target="RFC8839" sectionFormat="of" section="6.1.1"/>,
            except that an Answer is not yet provided.
          </t>
          <t>
[RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D.
 Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
          </t>
          <t>
              Note: The +SRFLX "+SRFLX" in
             <xref target="can-now-trickle-unrelprov"/> target="can-now-trickle-unrelprov" format="default"/>
             indicates that additionally additional newly learned server-reflexive candidates are included.
          </t>
          <t>
          <figure title="A anchor="can-now-trickle-unrelprov">
            <name>A SIP UA sends an unreliable provisional response without an Answer for establishing an early dialog"
                  anchor="can-now-trickle-unrelprov">
              <artwork><![CDATA[ dialog</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                Alice                      Bob
                  |                         |
                  |     INVITE (Offer)      |
                  |------------------------>|
                  |      183 (-)            |
                  |<------------------------|
                  |  INFO/OK (SRFLX Cand.)  |
                  |------------------------>|
                  |                         |
                  |               +----------------------+
                  |               |Bob:  Now I know again|
                  |               | that Alice is ready. |
                  |               | Send INFO!           |
                  |               +----------------------+
                  |  INFO/OK (SRFLX Cand.)  |
                  |<------------------------|
                  |    183 (Answer) opt.    |
                  |<------------------------|
                  |  INFO/OK (SRFLX Cand.)  |
                  |<------------------------|
                  |    200/ACK (Answer)     |
                  |<------------------------|

       Note: SRFLX "SRFLX" denotes server-reflexive candidates

               ]]></artwork> candidates]]></artwork>
          </figure>
          </t>
          <t>
        When sending the Answer, the agent MUST <bcp14>MUST</bcp14> repeat all currently
        known and used candidates, if any,
        and MAY <bcp14>MAY</bcp14> include all newly gathered candidates since the last INFO request was sent.
        However, if that Answer was already sent in a an unreliable provisional response,
        the Answerers MUST <bcp14>MUST</bcp14> repeat
        exactly the same Answer in the 200 OK response to the INVITE request
        in order to fulfill the corresponding requirements in
        <xref target="RFC3264"/>. target="RFC3264" format="default"/>.
        In case that trickling continued,
        an Offerer needs to be prepared for receiving fewer candidates
        in that repeated Answer than previously exchanged via trickling
        and MUST <bcp14>MUST</bcp14> ignore the candidate information in that 200 OK response.
          </t>
        </section>
      </section>
      <section title="Delivering anchor="info-sdp" numbered="true" toc="default">
        <name>Delivering Candidates in INFO Requests" anchor="info-sdp"> Requests</name>
        <t>
        Whenever new ICE candidates become available for sending,
        agents encode them in "a=candidate:" attributes as described
        by <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. target="RFC8839" format="default"/>. For example:
        </t>
        <t>
         <figure>
              <artwork>
<![CDATA[

  <sourcecode type="sdp"><![CDATA[
  a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host
]]>
            </artwork>
          </figure>
        </t> ]]></sourcecode>
        <t>
          The use of SIP INFO requests happens within the context of the
          Info Package as defined in <xref target="info-package"/>. target="info-package" format="default"/>.
          The  Media Type media type
          <xref target="RFC6838"/> target="RFC6838" format="default"/>
          for their payload MUST <bcp14>MUST</bcp14> be set to
          'application/trickle-ice-sdpfrag' as defined in
          <xref target="trickle_ice_sdpfrag_def"/>. target="trickle_ice_sdpfrag_def" format="default"/>.
          The Info INFO request body adheres to the grammar as specified in
          <xref target="trickle_ice_sdpfrag_grammar"/>. target="trickle_ice_sdpfrag_grammar" format="default"/>.
        </t>
        <t>
          Since neither the "a=candidate:" nor the "a=end-of-candidates"
          attributes contain information that would allow correlating them to
          a specific "m=" line,
          this
          it is handled through the use of
          pseudo "m=" lines.
        </t>
        <t>
          Pseudo "m=" lines follow the SDP syntax for "m=" lines as
          defined in
          <xref target="RFC4566"/> target="RFC4566" format="default"/> and are linked to the corresponding "m=" line
          in the SDP Offer or Answer via the identification tag
          in a "a=mid:" attribute
          <xref target="RFC5888"/>. target="RFC5888" format="default"/>.
          A pseudo  "m=" line does not provide semantics other
          than indicating to which "m=" line a candidate belongs.
          Consequently, the receiving agent MUST <bcp14>MUST</bcp14> ignore any remaining content of the pseudo "m=" line,
          which is not defined in this document.
          This guarantees that the  'application/trickle-ice-sdpfrag' bodies do not interfere with the Offer/Answer
          procedures as specified in <xref target="RFC3264"/>. target="RFC3264" format="default"/>.
        </t>
        <t>
        When sending the INFO request, the agent MAY, <bcp14>MAY</bcp14>,
        if already known to the  agent, include the same content into
        the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer.
        However, since Trickle-ICE Trickle ICE might be decoupled from the Offer/Answer negotiation this negotiation, the content might
        be unknown to the agent. In this case, the agent MUST <bcp14>MUST</bcp14> include the following default values. values:
        </t>
        <t>
          <list style="symbols">
            <t>
        <ul spacing="normal">
          <li>
              The media field is set to 'audio'.
            </t>
            <t>
            </li>
          <li>
              The port value is set to '9'.
            </t>
            <t>
            </li>
          <li>
              The proto value is set to 'RTP/AVP'.
            </t>
            <t>
            </li>
          <li>
              The fmt field MUST <bcp14>MUST</bcp14> appear only once and is set to '0'
            </t>
          </list>
        </t> '0'.
            </li>
        </ul>
        <t>
        Agents MUST <bcp14>MUST</bcp14> include  a pseudo "m=" line and an
          identification tag in a "a=mid:" attribute for every "m=" line
          whose candidate list they intend to update.
          Such "a=mid:" attributes MUST <bcp14>MUST</bcp14>
          immediately precede the list of candidates for that specific
          "m=" line.
        </t>
        <t>
          All "a=candidate:" or "a=end-of-candidates" attributes
          following an "a=mid:" attribute, up until (and excluding) the next
          occurrence of a pseudo "m=" line, pertain to the "m=" line
          identified by that identification tag.
        </t>
        <t>
          Note, that there is no requirement that the Info INFO request body
          contains as many pseudo m= "m=" lines as the Offer/Answer
          contains m=lines, "m=" lines, nor that the pseudo m= "m=" lines be in the same
          order as the m=lines "m=" lines that they pertain to.
          The correspondence can be made via the "a=mid:" attributes
          since candidates are grouped in sections headed
          by "pseudo" m=lines. "m=" lines.
          These sections contain "a=mid:" attribute values which that point
          back to the true m=line. "m=" line.
        </t>
        <t>
          An "a=end-of-candidates" attribute, preceding
          the first pseudo "m=" line, indicates the end of all trickling
          from that agent,
          as opposed to end of trickling for a specific "m=" line,
          which would be indicated by a media level media-level
          "a=end-of-candidates" attribute.
        </t>
        <t>
            Refer to
            <xref target="INFOexample"/> target="INFOexample" format="default"/>
            for an example of the INFO request content.
        </t>
        <t>
          The use of pseudo "m=" lines allows for a structure similar to
          the one in SDP Offers and Answers where
          separate media-level and session-level sections can be distinguished.
          In the current case, lines preceding the first
          pseudo "m=" line are considered to be session-level. session level.
          Lines appearing in between or after
          pseudo "m=" lines will be interpreted as media-level. media level.
        </t>
        <t>
          <list>
            <t>

    <ul empty="true" spacing="normal">
          <li>
              Note that while this specification uses the "a=mid:"
              attribute from <xref target="RFC5888"/>, target="RFC5888" format="default"/>, it does not
              define any grouping semantics.
            </t>
          </list>
        </t>
            </li>
        </ul>
        <t>
          All INFO requests MUST <bcp14>MUST</bcp14> carry the "a=ice-pwd:" and "a=ice-ufrag:"
          attributes that allow mapping them to a specific ICE generation.
          An agent MUST <bcp14>MUST</bcp14> discard any received INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:"
          attributes that do not match those of the current ICE Negotiation Session.
        </t>
        <t>
          The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST <bcp14>MUST</bcp14> appear at the same level
          as the ones in the Offer/Answer exchange.
          In other words, if they were present
          as session-level attributes, they will also appear
          at the beginning of all INFO request payloads, i.e. i.e., preceding
          the first pseudo "m=" line.
          If they were originally exchanged as media
          level media-level
          attributes, potentially overriding session-level values,
          then they will also be included in INFO request payloads
          following the corresponding pseudo "m=" lines.
        </t>
        <t>
          Note that <xref target="I-D.ietf-ice-trickle"/> requires that
          when candidates are trickled, <xref target="RFC8838" format="default"/>
          requires that each candidate must be delivered
          to the receiving Trickle ICE implementation not more than once
          and in the same order as it was conveyed.
          If the signaling protocol provides any candidate retransmissions,
          they need to be hidden from the ICE implementation.
          This requirement is fulfilled as follows.
        </t>
        <t>
          Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer peer,
          it MUST <bcp14>MUST</bcp14> include all currently known and used local candidates in every INFO request.
          I.e.
          That is, the agent MUST <bcp14>MUST</bcp14> repeat in the INFO request body
          all candidates that were previously sent under the same
          combination of "a=ice-pwd:" and "a=ice-ufrag:"
          in the same order as they were sent before.
          In other words, the sequence of a previously sent
          list of candidates MUST NOT <bcp14>MUST NOT</bcp14> change in subsequent INFO requests requests,
          and newly gathered candidates MUST <bcp14>MUST</bcp14> be added
          at the end of that list.
          Although repeating all candidates creates some overhead, it also allows easier handling of problems
          that could arise from unreliable transports, like e.g. transports like, e.g., loss of messages and reordering,
          which can be detected through the CSeq: header field in the INFO request.
        </t>
        <t>
          In addition, an ICE agent needs to adhere to
          section 17 of
          <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" sectionFormat="of" section="17"/>
          on preserving candidate order while trickling.
        </t>
        <t>
          When receiving INFO requests carrying any candidates, agents
          MUST therefore
          <bcp14>MUST</bcp14> first identify and discard the attribute lines
          containing candidates they have already received in previous
          INFO requests or in the Offer/Answer exchange preceding them.
        </t>
        <t> Such candidates are considered to be equal if their IP address
          port, transport transport, and component ID are the same.
          After identifying and discarding the known candidates,
          the agents MUST <bcp14>MUST</bcp14> forward the actually actual new candidates to the ICE Agents
          in the same order as they were received in the INFO request body.
          The ICE Agents will then process the new candidates
          according to the rules described in <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
        </t>
        <t> Receiving an "a=end-of-candidates" attribute in an INFO request body
        -
        -- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - --
        is an indication from the peer agent that it will not send any further candidates.
        When included at the session level, i.e. i.e., before any pseudo "m=" line,
        this indication applies to the whole session;
        when included at the media level level, the indication applies
        only to the corresponding "m=" line.
        Handling of such end-of-candidates indications is defined in
        <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
        </t>
        <t>
          The example in <xref target="INFOexample"/> target="INFOexample" format="default"/> shows the content
           of a candidate delivering INFO request. In the example example, the
           "a=end-of-candidates" attributes indicate that
           the candidate gathering is finished and
           that no further INFO requests follow.
        </t>
        <t>
        <figure title="An anchor="INFOexample">
          <name>An Example for the Content of an INFO Request"
                  anchor="INFOexample">
            <artwork>
<![CDATA[ Request</name>

<sourcecode><![CDATA[
  INFO sip:alice@example.com SIP/2.0
  ...
  Info-Package: trickle-ice
  Content-type: application/trickle-ice-sdpfrag
  Content-Disposition: Info-Package
  Content-length: 862

  a=ice-pwd:asd88fgpdd777uzjYhagZg
  a=ice-ufrag:8hhY
  m=audio 9 RTP/AVP 0
  a=mid:1
  a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
  a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
  a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
  a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
  a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
     raddr 192.0.2.1 rport 8998
  a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
     raddr 192.0.2.1 rport 8998
  a=end-of-candidates
  m=audio 9 RTP/AVP 0
  a=mid:2
  a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
  a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
  a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
  a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
  a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
     raddr 192.0.2.1 rport 9998
  a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
     raddr 192.0.2.1 rport 9998
  a=end-of-candidates

      Note: In a real INFO request request, there will be no line breaks
            in the a=candidate: "a=candidate:" attributes
]]>
            </artwork> ]]></sourcecode>
        </figure>
        </t>
      </section>
    </section>
    <section title="Initial anchor="disco" numbered="true" toc="default">
      <name>Initial Discovery of Trickle ICE Support"  anchor="disco"> Support</name>
      <t>
         SIP User Agents (UAs) that support and intend to use trickle
          ICE UAs are required by <xref target="I-D.ietf-ice-trickle"/> target="RFC8838" format="default"/> to indicate
          that their support of and intent to use Trickle ICE in their Offers and Answers by using the attribute
          "a=ice-options:trickle" "a=ice-options:trickle", and MUST they <bcp14>MUST</bcp14> include the SIP option-tag "trickle-ice" in
          a SIP Supported: or Require: header field.
          This makes discovery
          fairly straightforward for Answerers or for cases where
          Offers need to be generated within existing dialogs (i.e.,
          when sending UPDATE or re-INVITE requests).
          In both scenarios scenarios, prior
          SDP bodies will have provided the necessary information.
      </t>
      <t>
          Obviously, such information is not available at the time a first
          Offer is being constructed constructed, and it is therefore impossible
          for ICE Agents to determine support for incremental
          provisioning that way. The following options are suggested as
          ways of addressing this issue.
      </t>
      <section title="Provisioning anchor="disco-prov" numbered="true" toc="default">
        <name>Provisioning Support for Trickle ICE"
                 anchor="disco-prov"> ICE</name>
        <t>
            In certain situations situations, it may be possible for integrators
            deploying Trickle ICE to know in advance that some or all
            endpoints reachable from within the deployment will support
            Trickle ICE.
            This is the case, for example, if Session Border Controllers
            (SBC)
            (SBCs) with support for this specification are used
            to connect to UAs that do not support Trickle ICE.
        </t>
        <t>
            While the exact mechanism for allowing such  provisioning
            is out of scope here, this specification encourages trickle
            ICE implementations to allow the option in the way they find
            most appropriate.
        </t>
        <t>
            However, an Offerer assuming Trickle ICE support MUST <bcp14>MUST</bcp14>
            include a SIP Require: trickle-ice header field.
            That way, if the provisioned assumption of Trickle ICE support
            ends up being incorrect, the failure is (a) operationally
            easy to track down, down and (b) recoverable by the client,
            i.e., they can re-send resend the request without the
            SIP Require: header field and without
            the assumption of Trickle ICE support.
        </t>
      </section>
      <section title="Trickle anchor="disco-gruu" numbered="true" toc="default">
        <name>Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU)"
                 anchor="disco-gruu"> (GRUUs)</name>
        <t>
            <xref target="RFC3840"/> target="RFC3840" format="default"/> provides a way for SIP User Agents UAs
            to query for support of specific capabilities using, among
            others, OPTIONS requests. Support On the other hand, support for
            GRUU according to
            <xref target="RFC5627"/> on the other hand target="RFC5627" format="default"/>
            allows SIP requests to be addressed to specific UAs (as
            opposed to arbitrary instances of an address of record).
            Combining the two and using the "trickle-ice" option tag
            defined in <xref target="option-tag"/> target="option-tag" format="default"/> provides SIP UAs with
            a way of learning the capabilities of specific SIP UA instances
            and then addressing them directly with INVITE requests that
            require Trickle ICE support.
        </t>
        <t>
            Such learning of capabilities may happen in different ways.
            One option for a SIP UA is to learn the
            GRUU instance ID of a peer through presence and then to query
            its capabilities with an OPTIONS request.
            Alternatively, it can also just send an OPTIONS request to
            the Address of Record (AOR) it intends to contact and then inspect the returned
            response(s) for support of both GRUU and Trickle ICE
            (<xref target="options-gruu"/>). target="options-gruu" format="default"/>).
            It is noted that using the GRUU means that the INVITE request
            can go only to that particular device.
            This prevents the use of forking for that request.
        </t>
          <t>
        <figure title="Trickle anchor="options-gruu">
          <name>Trickle ICE support discovery Support Discovery with OPTIONS and
                           GRUU"
                  anchor="options-gruu">
              <artwork><![CDATA[ GRUU</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
         Alice                                                Bob
           |                                                   |
           |        OPTIONS sip:b1@example.com SIP/2.0         |
           |-------------------------------------------------->|
           |                                                   |
           |                      200 OK                       |
           |    Contact: sip:b1@example.com;gr=hha9s8d-999a    |
           |            ;audio;video|;trickle-ice;...          |
           |<--------------------------------------------------|
           |                                                   |
           | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
           |             Supported: trickle-ice                |
           |                      (Offer)                      |
           |-------------------------------------------------->|
           |                                                   |
           |                  183 (Answer)                     |
           |<--------------------------------------------------|
           |                INFO/OK (Trickling)                |
           |<------------------------------------------------->|
           |                                                   |
           |                      ...                          |
           |                                                   |

              ]]></artwork>                                                   |]]></artwork>
        </figure>
          </t>
        <t>
            Confirming support for Trickle ICE through
            <xref target="RFC3840"/> target="RFC3840" format="default"/> gives SIP UAs the options option to engage
            in Full Trickle negotiation (as opposed to the more lengthy
            Half Trickle) from the very first Offer they send.
        </t>
      </section>
      <section title="Fall-back anchor="half-full-trickle" numbered="true" toc="default">
        <name>Fall Back to Half Trickle"
             anchor="half-full-trickle"> Trickle</name>
        <t>
            In cases where none of the other mechanisms in this section
            are acceptable, SIP UAs should use the Half Trickle mode
            defined in <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
            With Half Trickle, agents initiate sessions the same way
            they would when using ICE for SIP
            <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. target="RFC8839" format="default"/>.
            This means that, prior to actually sending an Offer, agents
            first gather ICE candidates in a blocking way and then
            send them all in that Offer. The blocking nature of the
            process implies that some amount of latency will
            be accumulated accumulated, and it is advised that agents try to
            anticipate it where possible, for example, when user
            actions indicate a high likelihood for an imminent call
            (e.g., activity on a keypad or a phone going off-hook). off hook).
        </t>
        <t>
            Using Half Trickle results in Offers that are
            compatible with both
<!--[rfced] Will "legacy [RFC3264] endpoints" be clear to the
reader? (Is the citation being used as an adjective? If so, we
suggest using words instead of or in addition to the citation.)
Does "ICE SIP endpoints" refer to RFC-to-be 8839?

Original:
   Using Half Trickle results in Offers that are compatible with both
   ICE SIP endpoints and legacy [RFC3264] endpoints.

Perhaps:
   Using Half Trickle results in Offers that are compatible with both
   ICE SIP endpoints [RFC8839] and legacy SDP endpoints [RFC3264].
-->
            Using Half Trickle results in Offers that are
            compatible with both ICE SIP endpoints and legacy
            <xref target="RFC3264"/> target="RFC3264" format="default"/> endpoints.
        </t>
          <t>
        <figure title="Example - A typical anchor="fig-half-trickle">
          <name>Example of a Typical (Half) Trickle ICE exchange Exchange with SIP " anchor="fig-half-trickle">
              <artwork>
  <![CDATA[
STUN/Turn SIP</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
STUN/TURN                                                STUN/TURN
Servers          Alice                      Bob          Servers
   |               |                             |               |
   |<--------------|                             |               |
   |               |                             |               |
   |               |                             |               |
   |   Candidate   |                             |               |
   |               |                             |               |
   |               |                             |               |
   |   Discovery   |                             |               |
   |               |                             |               |
   |               |                             |               |
   |-------------->|       INVITE (Offer)        |               |
   |               |---------------------------->|               |
   |               |        183 (Answer)         |-------------->|
   |               |<----------------------------|               |
   |               |  INFO (repeated candidates) |               |
   |               |---------------------------->|               |
   |               |                             |               |
   |               |    INFO (more candidates)   |   Candidate   |
   |               |<----------------------------|               |
   |               |    Connectivity Checks      |               |
   |               |<===========================>|   Discovery   |
   |               |   INFO (more candidates)    |               |
   |               |<----------------------------|               |
   |               |    Connectivity Checks      |<--------------|
   |               |<===========================>|               |
   |               |                             |               |
   |               |          200 OK             |               |
   |               |<----------------------------|               |
   |               |                             |               |
   |               |<======= MEDIA FLOWS =======>|               |
   |               |                             |               |
]]>
            </artwork> ]]></artwork>
        </figure>
        </t>
        <t>
          It is worth reminding that

          As a reminder, once a single Offer or Answer had has
          been exchanged within a specific dialog, support for
          Trickle ICE will have been determined.
          No further use of Half Trickle will therefore be necessary
          within that same dialog dialog,
          and all subsequent exchanges can use the Full Trickle mode
          of operation.
        </t>
      </section>
    </section>
    <section title="Considerations anchor="rtcp-cons" numbered="true" toc="default">
      <name>Considerations for RTP and RTCP Multiplexing" anchor="rtcp-cons"> Multiplexing</name>
      <t>
        The following consideration describe describes options for Trickle-ICE Trickle ICE
        in order to give some guidance to implementors implementers on how trickling
        can be optimized with respect to providing RTCP candidates.
      </t>
      <t>
        Handling of the "a=rtcp" attribute <xref target="RFC3605"/> target="RFC3605" format="default"/>
        and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing <xref target="RFC5761"/> target="RFC5761" format="default"/>
        is already considered in section 5.1.1.1.
        of
        <xref target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445" sectionFormat="of" section="5.1.1.1"/> and
        as well
        in <xref target="RFC5761"/> itself. target="RFC5761" format="default"/>.
        These considerations are still valid for Trickle ICE, ICE; however,
        trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.
      </t>
      <t>
[RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct for version 17 of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
</t>
        <t>
        If the Offerer supports RTP/RTCP multiplexing exclusively as specified
        in <xref target="I-D.ietf-mmusic-mux-exclusive"/>, target="RFC8858" format="default"/>,
        the procedures in that document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" "a=rtcp", and the "a=rtcp-mux" attributes.
      </t>
      <t>
        While a Half Trickle Offerer has to send an Offer compliant to
        <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> target="RFC8839" format="default"/> and <xref target="RFC5761"/> target="RFC5761" format="default"/> including candidates for all components, the flexibility of a Full Trickle Offerer allows
        to send
        the sending of only RTP candidates (component 1) in the initial Offer
        assuming that RTCP multiplexing is supported by the Answerer.
        A Full Trickle Offerer would need to start gathering and trickling
        RTCP candidates (component 2)
        only after having received an indication in the Answer that
        the Answerer unexpectedly does not support RTCP multiplexing.
      </t>
      <t>
        A Trickle Answerer MAY <bcp14>MAY</bcp14> include an "a=rtcp-mux" attribute
        <xref target="RFC5761"/> target="RFC5761" format="default"/> in the application/trickle-ice-sdpfrag 'application/trickle-ice-sdpfrag' body
        if it supports and uses RTP and RTCP multiplexing.
        The Trickle Answerer needs to follow the guidance on the usage of the "a=rtcp" attribute as given in
         <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> target="RFC8839" format="default"/> and
         <xref target="RFC3605"/>. target="RFC3605" format="default"/>.
        Receipt of this attribute at the Offerer in an INFO request prior to the Answer
        indicates that the Answerer supports and uses RTP and RTCP multiplexing.
        The Offerer can use this information e.g. information, e.g., for stopping the gathering of RTCP candidates
        and/or for freeing corresponding resources.
      </t>
      <t>
        This behavior is illustrated by the following example Offer that indicates support for RTP and RTCP multiplexing.
      </t>
        <t>
          <figure>
            <artwork>
<![CDATA[

<sourcecode type="sdp"><![CDATA[
  v=0
  o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
  s=
  c=IN IP6 2001:db8:a0b:12f0::3
  t=0 0
  a=ice-pwd:777uzjYhagZgasd88fgpdd
  a=ice-ufrag:Yhh8
  m=audio 5000 RTP/AVP 0
  a=mid:1
  a=rtcp-mux
  a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
]]>
            </artwork>
          </figure>
        </t> host]]></sourcecode>
      <t>
        Once the dialog is established as described in section <xref target="dialog-est"/> target="dialog-est" format="default"/>, the Answerer
        sends the following INFO request.
      </t>
        <t>
          <figure>
            <artwork>
<![CDATA[

<sourcecode><![CDATA[
  INFO sip:alice@example.com SIP/2.0
  ...
  Info-Package: trickle-ice
  Content-type: application/trickle-ice-sdpfrag
  Content-Disposition: Info-Package
  Content-length: 161

  a=ice-pwd:asd88fgpdd777uzjYhagZg
  a=ice-ufrag:8hhY
  m=audio 9 RTP/AVP 0
  a=mid:1
  a=rtcp-mux
  a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host
]]>
            </artwork>
          </figure>
        </t> ]]></sourcecode>
      <t>
        This INFO request indicates that the Answerer supports and uses
        RTP and RTCP multiplexing as well.
        It allows the Offerer to omit gathering of RTCP candidates or
        releasing already gathered RTCP candidates.
        If the INFO request did not contain the a=rtcp-mux "a=rtcp-mux" attribute,
        the Offerer has to gather RTCP candidates
        unless it wants to wait until receipt of an Answer that eventually confirms
        support or non-support for RTP and RTCP multiplexing.
        In case the Offerer had already sent RTCP candidates in a previous INFO request,
        it still needs to repeat them in subsequent INFO requests,
        even in case when that support for RTCP multiplexing was confirmed
        by the Answerer and the Offerer has released its RTCP candidates.
      </t>
    </section>
    <section title="Considerations anchor="bundle-cons" numbered="true" toc="default">
      <name>Considerations for Media Multiplexing" anchor="bundle-cons"> Multiplexing</name>
      <t>
        The following considerations describe options for Trickle-ICE Trickle ICE
        in order to give some guidance to implementors implementers on how trickling
        can be optimized with respect to providing candidates in case of Media Multiplexing
        <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. target="RFC8843" format="default"/>.
        It is assumed that the reader is familiar with <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. target="RFC8843" format="default"/>.
      </t>
      <t>
<!--[rfced] Is Section 11 ("DTLS Considerations") the correct section
number in the text below?  It does not mention ICE
candidate exchange; please let us know how it may be updated.

Original:
   ICE candidate exchange is already considered in section 11 of
   [I-D.ietf-mmusic-sdp-bundle-negotiation].

Note: [I-D.ietf-mmusic-sdp-bundle-negotiation] is RFC-to-be 8843
available from https://www.rfc-editor.org/authors/rfc8843.html
-->

        ICE candidate exchange is already considered in
        <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. target="RFC8843" sectionFormat="of" section="11"/>.
        These considerations are still valid for Trickle ICE, ICE; however,
        trickling provides more flexibility for the sequence of candidate exchange,
        especially in Full Trickle mode.
      </t>
      <t>
        Except for bundle-only "m=" lines, a Half Trickle Offerer has to
        send an Offer with candidates for all bundled "m=" lines.
        The additional flexibility, however, allows a Full Trickle Offerer
        to initially send only candidates for the "m=" line with the
        suggested Offerer BUNDLE address.
      </t>
      <t>
        On receipt of the Answer, the Offerer will detect
        if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected.
        In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle.
        However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates
        for the remaining "m=" lines as necessary.
        If the Answerer selects an Offerer BUNDLE address that is different from the suggested Offerer BUNDLE address,
        the  Full Trickle Offerer needs to gather and trickle candidates
        for the "m=" line that carries the selected Offerer BUNDLE address.
      </t>
      <t>
        A Trickle Answerer SHOULD <bcp14>SHOULD</bcp14> include an "a=group:BUNDLE" attribute
        <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> target="RFC8843" format="default"/>
        at session level in the application/trickle-ice-sdpfrag 'application/trickle-ice-sdpfrag' body
        if it supports and uses bundling.
        When doing so, the Answerer MUST <bcp14>MUST</bcp14> include all identification-tags in the same order that is used or will be used in the Answer.
      </t>
      <t>
        Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer
        supports and uses bundling.
        The Offerer can use this information e.g. information, e.g., for stopping the gathering of candidates
        for the remaining "m=" lines in a bundle and/or for freeing corresponding resources.
      </t>
      <t>
        This behaviour behavior is illustrated by the following example Offer that indicates support for Media Multiplexing.
      </t>
      <t>
        In case
        If the Offerer had sent already sent candidates for "m="-lines "m=" lines
        in a bundle in a previous INFO request,
        it still needs to repeat them in subsequent INFO requests,
        even in case when that support for bundling was confirmed
        by the Answerer and the Offerer has released candidates that are no longer needed candidates. needed.
      </t>
        <t>
          <figure>
            <artwork>
<![CDATA[

<sourcecode type="sdp"><![CDATA[
   v=0
   o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
   s=
   c=IN IP6 2001:db8:a0b:12f0::3
   t=0 0
   a=group:BUNDLE foo bar
   a=ice-pwd:777uzjYhagZgasd88fgpdd
   a=ice-ufrag:Yhh8
   m=audio 10000 RTP/AVP 0
   a=mid:foo
   a=rtcp-mux
   a=rtpmap:0 PCMU/8000
   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
   a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
   m=video 10002 RTP/AVP 31
   a=mid:bar
   a=rtcp-mux
   a=rtpmap:31 H261/90000
   a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid]]>
            </artwork>
          </figure>
        </t> urn:ietf:params:rtp-hdrext:sdes:mid]]></sourcecode>
      <t>
        The example Offer indicates support for RTP and RTCP multiplexing
        and contains a an "a=candidate:" attribute only for the "m="-line "m=" line
        with the suggested Offerer bundle address.
        Once the dialog is established as described in  <xref target="dialog-est"/> target="dialog-est" format="default"/>, the Answerer
        sends the following INFO request.
      </t>
        <t>
          <figure>
            <artwork>
<![CDATA[

<sourcecode><![CDATA[
   INFO sip:alice@example.com SIP/2.0
   ...
   Info-Package: trickle-ice
   Content-type: application/trickle-ice-sdpfrag
   Content-Disposition: Info-Package
   Content-length: 219

   a=group:BUNDLE foo bar
   a=ice-pwd:asd88fgpdd777uzjYhagZg
   a=ice-ufrag:8hhY
   m=audio 9 RTP/AVP 0
   a=mid:foo
   a=rtcp-mux
   a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host

]]>
            </artwork>
          </figure>
        </t> ]]></sourcecode>
      <t>
        This INFO request indicates that the Answerer supports and uses Media Multiplexing as well.
        Note that the Answerer only includes a single pseudo "m="-line "m=" line since candidates
         matching those from the second "m="-line "m=" line in the offer are not needed from the Answerer.
      </t>
      <t>
        The INFO request also indicates that the Answerer accepted the suggested Offerer Bundle Address.
        This allows the Offerer to omit gathering of RTP and RTCP candidates for the other "m=" lines
        or releasing already gathered candidates.
        If the INFO request did not contain the a=group:BUNDLE "a=group:BUNDLE" attribute, the Offerer has to gather
        RTP and RTCP  candidates for the other "m=" lines  unless it wants to wait until receipt
        of an Answer that eventually confirms
        support or non-support for Media Multiplexing.
      </t>
      <t>
        Independent of using Full Trickle or Half Trickle mode, the rules from
         <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> target="RFC8859" format="default"/> apply to both, Offerer and Answerer,
        when putting attributes as specified in
        <xref target="trickle_ice_sdpfrag_grammar"/> target="trickle_ice_sdpfrag_grammar" format="default"/>
         in the application/trickle-ice-sdpfrag 'application/trickle-ice-sdpfrag' body.
      </t>
    </section>
    <section anchor="sec-eoc" title="SDP toc="default" numbered="true">
      <name>SDP 'end-of-candidates' Attribute" toc="default"> Attribute</name>
      <section title="Definition" anchor="eoc-def"> anchor="eoc-def" numbered="true" toc="default">
        <name>Definition</name>
        <t>
      This section defines a the new SDP media-level and session-level attribute
      <xref target="RFC4566" pageno="false" format="default"/>
      'end-of-candidates'. 'end-of-candidates' is a property attribute
      <xref target="RFC4566" pageno="false" format="default"/>, and hence format="default"/>; hence, it has no value.
      By including this attribute in an Offer or Answer Answer, the sending agent indicates
      that it will not trickle further candidates.
      When included at the session level level, this indication applies to the whole session, session;
      when included at the media level level, the indication applies only to the corresponding media description.
        </t>

        <t>
        <list style="none">
            <t>
            Name: end-of-candidates
            </t>
            <t>
            Value: N/A
            </t>
            <t>
            Usage Level: media
        <ul empty="true">
          <li>
        <dl spacing="normal">
            <dt>Name:</dt><dd>end-of-candidates</dd>

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

            <dt>Usage Level:</dt><dd>media and session-level
            </t>
            <t>
            Charset Dependent: no
            </t>
            <t>
            Mux Category: IDENTICAL
            </t>
            <t>
            Example: a=end-of-candidates
            </t>
        </list>
        </t> session level</dd>

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

            <dt>Mux Category:</dt><dd>IDENTICAL</dd>

            <dt>Example:</dt>
	    <dd>a=end-of-candidates</dd>
       	</dl>
        </li>
        </ul>
      </section>
      <section title="Offer/Answer Procedures" anchor="eoc-ind"> anchor="eoc-ind" numbered="true" toc="default">
        <name>Offer/Answer Procedures</name>
        <t>The Offerer or Answerer MAY <bcp14>MAY</bcp14> include an "a=end-of-candidates" attribute
          in case candidate discovery has ended
          and no further candidates are to be trickled.
          The Offerer or Answerer MUST <bcp14>MUST</bcp14> provide the "a=end-of-candidates" attribute
          together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the current
          ICE generation as required by
          <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
          When included at the session level level,
          this indication applies to the whole session;
          when included at the media level level, the indication applies
          only to the corresponding media description.
        </t>
        <t>
          Receipt of an "a=end-of-candidates" attribute at an
          Offerer or Answerer
          -
          -- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - --
          indicates that the gathering of candidates
          has ended at the peer, either for either the session or only for the
          corresponding media description as specified above.
          The receiving agent forwards an end-of-candidates indication
          to the ICE Agent, which in turn acts as specified in
          <xref target="I-D.ietf-ice-trickle"/>. target="RFC8838" format="default"/>.
        </t>
      </section>
    </section>
    <section title="Content anchor="trickle_ice_sdpfrag_def" numbered="true" toc="default">
      <name>Content Type 'application/trickle-ice-sdpfrag'" anchor="trickle_ice_sdpfrag_def"> 'application/trickle-ice-sdpfrag'</name>
      <section title="Overall Description"> numbered="true" toc="default">
        <name>Overall Description</name>
        <t>
        A application/trickle-ice-sdpfrag
        An 'application/trickle-ice-sdpfrag' body is used exclusively by the 'trickle-ice' Info Package.
        Other SDP related SDP-related applications need to define their own media type.
        The INFO request body uses a subset of the possible SDP lines
        as defined by the grammar defined in <xref target="RFC4566"/>. target="RFC4566" format="default"/>.
        A valid body uses only pseudo "m=" lines and certain attributes
        that are needed and/or useful for trickling candidates.
        The content adheres to the following grammar.
        </t>
      </section>
      <section title="Grammar" anchor="trickle_ice_sdpfrag_grammar"> anchor="trickle_ice_sdpfrag_grammar" numbered="true" toc="default">
        <name>Grammar</name>
        <t>
           The grammar of an 'application/trickle-ice-sdpfrag' body is
           based on the following ABNF <xref target="RFC5234"/>. target="RFC5234" format="default"/>.
           It specifies the subset of existing SDP attributes, attributes
           that is needed or useful for trickling candidates.
           The grammar uses the indicator for case-sensitivity %s case-sensitive %s,
           as defined in <xref target="RFC7405"/>, target="RFC7405" format="default"/>,
           but it also imports grammars grammar for other SDP attributes that
           precede the production of <xref target="RFC7405"/>. target="RFC7405" format="default"/>.
           A sender SHOULD <bcp14>SHOULD</bcp14> use lower-case lower case for attributes
           from such earlier grammars, grammar, but a receiver MUST <bcp14>MUST</bcp14> treat
           them case-insensitively. as case insensitive.
        </t>

         <t>
         <figure><artwork align="left">
        <sourcecode type="abnf"><![CDATA[
   ;  Syntax
   trickle-ice-sdpfrag =   session-level-fields
                     pseudo-media-descriptions
   session-level-fields = *(session-level-field CRLF)

   session-level-field =  ice-lite-attribute /
                     ice-pwd-attribute /
                     ice-ufrag-attribute /
                     ice-options-attribute /
                     ice-pacing-attribute /
                     end-of-candidates-attribute /
                     bundle-group-attribute /
                     extension-attribute-fields
                                         ; for future extensions

   ice-lite-attribute     = %s"a" "=" ice-lite
   ice-pwd-attribute      = %s"a" "=" ice-pwd-att
   ice-ufrag-attribute    = %s"a" "=" ice-ufrag-att
   ice-pacing-attribute   = %s"a" "=" ice-pacing-att
   ice-options-attribute  = %s"a" "=" ice-options
   end-of-candidates-attribute  = %s"a" "=" end-of-candidates
   end-of-candidates            = %s"end-of-candidates"
   bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
                              *(SP identification-tag)
   bundle-semantics = "BUNDLE"
   extension-attribute-fields   = attribute-fields

   pseudo-media-descriptions    =  *( media-field
                              trickle-ice-attribute-fields )
   trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
   trickle-ice-attribute-field = mid-attribute /
                           candidate-attributes /
                           ice-pwd-attribute  /
                           ice-ufrag-attribute /
                           remote-candidate-attribute /
                           end-of-candidates-attribute /
                           rtcp-attribute /
                           rtcp-mux-attribute /
                           rtcp-mux-only-attribute /
                           extension-attribute-fields
                                           ; for future extensions

   rtcp-attribute                = %s"a" "=" %s"rtcp"
   rtcp-mux-attribute            = %s"a" "=" %s"rtcp-mux"
   rtcp-mux-only-attribute       = %s"a" "=" %s"rtcp-mux-only"
   candidate-attributes          = %s"a" "=" candidate-attribute
   remote-candidate-attribute    = %s"a" "=" remote-candidate-att

         </artwork></figure>
         </t> ]]></sourcecode>
        <t>
         with
   ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att,
   ice-options, candidate-attribute candidate-attribute, and remote-candidate-att are from <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>,
         identification-tag,
   target="RFC8839"/>; identification-tag and mid-attribute ; are from <xref target="RFC5888"/>,
         media-field,
   target="RFC5888"/>; and media-field and attribute-fields are from <xref
   target="RFC4566"/>.  The "a=rtcp" attribute is defined in <xref target="RFC3605"/>,
   target="RFC3605" format="default"/>, the "a=rtcp-mux" attribute is defined
   in <xref target="RFC5761"/> target="RFC5761" format="default"/>, and the "a=rtcp-mux-only"
   attribute is defined in <xref target="I-D.ietf-mmusic-mux-exclusive"/>. target="RFC8858" format="default"/>.  The
   latter attributes lack a formal grammar in their corresponding RFC RFCs and are
   reproduced here.
        </t>
        <t>
          The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST <bcp14>MUST</bcp14> appear at the
          same level as the ones in the Offer/Answer exchange.  In other words,
          if they were present as session-level attributes, they will also
          appear at the beginning of all INFO request payloads, i.e. i.e., preceding
          all pseudo "m=" lines.  If they were originally exchanged as media
          level media-level
          attributes, potentially overriding session-level values, then
          they will also be included in INFO request payloads following the
          corresponding pseudo "m=" lines.
        </t>
        <t>
         An Agent MUST <bcp14>MUST</bcp14> ignore any received unknown extension-attribute-fields.
        </t>
      </section>
    </section>
    <section title="Info Package" anchor="info-package"> anchor="info-package" numbered="true" toc="default">
      <name>Info Package</name>
      <section title="Rationale - anchor="rationale" numbered="true" toc="default">
        <name>Rationale -- Why INFO?" anchor="rationale"> INFO?</name>
        <t>
          The decision to use SIP INFO requests as a candidate transport
          method is based primarily on their lightweight nature. Once a
          dialog has been established, INFO requests can be exchanged
          both ways with no restrictions on timing and frequency and no
          risk of collision.
        </t>
        <t> A critical fact is that the sending of Trickle ICE candidates
        in one direction is entirely uncoupled from sending candidates
        in the other direction.
        Thus, the sending of candidates in each direction can be
        done by a stream of INFO requests that is not correlated with
        the stream of INFO requests in the other direction.
        And since each INFO request cumulatively includes
        the contents of all previous INFO requests in that direction,
        the ordering between INFO requests need not be preserved.
        All of this permits using largely-independent largely independent INFO requests.
        </t>
        <t>
            Contrarily, UPDATE or other offer/answer mechanisms assume
            that the messages in each direction are tightly coupled
            with messages in the other direction.
            Using Offer/Answer and UPDATE requests
          <xref target="RFC3311"/> target="RFC3311" format="default"/>
          would introduce the following complications:
        </t>
        <t>
          <list style="hanging">
            <t hangText="Blocking
        <dl newline="false" spacing="normal">
          <dt>Blocking of messages: ">
              <xref target="RFC3264"/> defines </dt>
          <dd>
              Offer/Answer is defined as a
              strictly sequential mechanism. mechanism in <xref target="RFC3264" format="default"/>.
              There can only be a maximum of one active exchange
              at any point of time.
              Both sides cannot simultaneously send Offers nor
              can they generate multiple Offers prior to
              receiving an Answer.
              Using UPDATE requests for
              candidate transport would therefore imply the
              implementation of a candidate pool at every agent where
              candidates can be stored until it is once again that
              agent's "turn" to emit an Answer or a new Offer.
              Such an approach would introduce non-negligible
              complexity for no additional value.
            </t>
            <t hangText="Elevated
            </dd>
          <dt>Elevated risk of glare: "> </dt>
          <dd>
              The sequential nature of Offer/Answer also makes it
              impossible for both sides to send Offers simultaneously.
              What's worse is that there are no mechanisms in SIP to
              actually prevent that. <xref target="RFC3261"/>, target="RFC3261" format="default"/>, where
              the situation of Offers crossing on the wire is described
              as "glare", only defines a procedure for addressing the
              issue after it has occurred. According to that procedure procedure,
              both Offers are invalidated and both sides need to retry
              the negotiation after a period between 0 and 4 seconds.

              The high likelihood for glare to occur and the average two
              second back-off two-second
              backoff intervals to occur implies that the duration of
              Trickle ICE processing would not only fail to improve but
              actually exceed those of regular ICE.
            </t>
          </list>
        </t>
            </dd>
        </dl>
        <t>
          INFO messages decouple the exchange of candidates from the
          Offer/Answer negotiation
          and are subject to none of the glare issues described above,
          which makes them a very convenient and lightweight mechanism
          for asynchronous delivery of candidates.
        </t>
        <t>
          Using in-dialog INFO messages also provides a way of
          guaranteeing that candidates are delivered end-to-end, end to end, between
          the same entities that are actually in the process of
          initiating a session. Out-of-dialog alternatives would have implied
          requiring support for Globally Routable UA URI (GRUU) GRUU
          <xref target="RFC5627"/> which, target="RFC5627" format="default"/> that, given GRUUs relatively low
          adoption levels, would have constituted too strong of a
          constraint to the adoption of Trickle ICE.
        </t>
      </section>
      <section title="Overall Description"> numbered="true" toc="default">
        <name>Overall Description</name>
        <t>
          This specification defines an Info Package for use by
          SIP User Agents UAs implementing Trickle ICE.
          INFO requests carry ICE candidates discovered after the peer user
          agents UAs have confirmed mutual support for Trickle ICE.
        </t>
      </section>
      <section title="Applicability"> numbered="true" toc="default">
        <name>Applicability</name>
        <t>
          The purpose of the ICE protocol is to establish a media path
          in the presence of NAT and firewalls.
          The candidates are transported in INFO requests and are
           part of this establishment.
        </t>
        <t>
          Candidates sent by a Trickle ICE Agent after the Offer, Offer
          follow the same signaling path and reach the same
          entity as the Offer itself. While it is true that GRUUs can
          be used to achieve this, one of the goals of this
          specification is to allow operation of Trickle ICE in as many
          environments as possible including those without GRUU support.
          Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
          satisfy this goal.
        </t>
      </section>
      <section title="Info numbered="true" toc="default">
        <name>Info Package Name"> Name</name>
        <t>
          This document defines a SIP Info Package as per
          <xref target="RFC6086"/>. target="RFC6086" format="default"/>. The Info Package token name for this
          package is "trickle-ice" "trickle-ice".
        </t>
      </section>
      <section title="Info numbered="true" toc="default">
        <name>Info Package Parameters"> Parameters</name>
        <t>
          This document does not define any Info Package parameters.
        </t>
      </section>
      <section title="SIP anchor="option-tag" numbered="true" toc="default">
        <name>SIP Option Tags" anchor="option-tag"> Tags</name>
        <t>
          <xref target="RFC6086"/> target="RFC6086" format="default"/> allows Info Package specifications to
          define SIP option-tags. This specification extends the option-tag
          construct of the SIP grammar as follows:
        </t>
        <t>
           <figure><artwork align="left">
        <artwork align="left" name="" type="" alt=""><![CDATA[
 option-tag /= "trickle-ice"
           </artwork></figure>
        </t> ]]></artwork>
        <t>
         SIP entities that support this
          specification MUST <bcp14>MUST</bcp14> place the 'trickle-ice' option-tag in a SIP
          Supported: or Require: header field within
          all SIP INVITE requests and responses.
        </t>
        <t>
          When responding to, or generating generating, a SIP OPTIONS request request, a SIP
          entity MUST <bcp14>MUST</bcp14> also include the 'trickle-ice' option-tag in a SIP
          Supported: or Require: header field.
        </t>
      </section>
      <section title="Info numbered="true" toc="default">
        <name>INFO Request Body Parts"> Parts</name>
        <t>
          Entities implementing this specification MUST <bcp14>MUST</bcp14> include a
          payload of type 'application/trickle-ice-sdpfrag' in SIP INFO requests as defined
          in <xref target="trickle_ice_sdpfrag_grammar"/>
          in SIP INFO requests. target="trickle_ice_sdpfrag_grammar" format="default"/>.
          The payload is used to convey SDP-encoded ICE candidates.
        </t>
      </section>
      <section title="Info numbered="true" toc="default">
        <name>Info Package Usage Restrictions"> Restrictions</name>
        <t>
           This document does not define any Info Package Usage Restrictions.
        </t>
      </section>
      <section title="Rate numbered="true" toc="default">
        <name>Rate of INFO Requests"> Requests</name>
        <t>
           Given that IP addresses may be gathered rapidly rapidly, a
           Trickle ICE Agent with many network interfaces might create a
           high rate of INFO requests if every newly
           detected candidate is trickled individually without aggregation.
          An implementation MUST <bcp14>MUST</bcp14> aggregate ICE candidates in case that an
          unreliable transport protocol such as UDP is used.
          A Trickle ICE agent MUST NOT <bcp14>MUST NOT</bcp14> have more than one INFO request
          pending at any one time.
          When INFO messages are sent over an unreliable transport,
          they are retransmitted according to the rules specified in
          <xref target="RFC3261" pageno="false" format="default"/> section 17.1.2.1." sectionFormat="comma" section="17.1.2.1"/>.
        </t>
        <t>
        If the INFO requests are sent on top of TCP,
        which is probably the standard way,
        this
        it is not an issue for the network anymore,
        but it can remain one for SIP proxies and other intermediaries
        forwarding the SIP INFO messages.
        Also, an endpoint may not be able to tell that it has congestion
        controlled transport all the way.
        </t>
      </section>
      <section title="Info numbered="true" toc="default">
        <name>Info Package Security Considerations"> Considerations</name>
        <t>
           See <xref target="sec-cons"/> target="sec-cons" format="default"/>.
        </t>
      </section>
    </section>
    <section title="Deployment Considerations" anchor="deploy-cons"> anchor="deploy-cons" numbered="true" toc="default">
      <name>Deployment Considerations</name>
      <t>
        Trickle ICE uses two mechanisms for the exchange of candidate information.
        This imposes new requirements to certain middleboxes
        that are used in some networks, e.g. e.g., for monitoring purposes.
        While the first mechanism, SDP Offers and Answers,
         is already used by regular ICE and is assumed to be supported,
          the second mechanism, INFO request bodies,
          needs to be considered by such middleboxes as well when
         trickle ICE is used.
         Such middleboxes need to make sure that they remain
         in the signaling path of the INFO requests and
         need to
         understand the INFO request body.
      </t>
    </section>
    <section title="IANA Considerations" anchor="IANA">
      <t>
      [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. ]
      </t> anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="sec-eoc-iana" title="SDP toc="default" numbered="true">
        <name>SDP 'end-of-candidates' Attribute" toc="default"> Attribute</name>
        <t>
      This section defines a new SDP media-level and session-level attribute
      <xref target="RFC4566" pageno="false" format="default"/>
      , 'end-of-candidates'. 'end-of-candidates' 'end-of-candidates', which is a property attribute
      <xref target="RFC4566" pageno="false" format="default"/>
      , and hence has no value.
        </t>
      <figure>
      <preamble/>
      <artwork>
      <![CDATA[
  Name: end-of-candidates

   Value: N/A

   Usage Level: media and session

   Charset Dependent: no

   Purpose: The
      <ul empty="true"><li>
   <dl newline="false" spacing="normal">

   <dt>Name:</dt><dd>end-of-candidates</dd>

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

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

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

   <dt>Purpose:</dt><dd>The sender indicates that it will not trickle
            further ICE candidates.

   O/A Procedures: RFCXXX candidates.</dd>

   <dt>O/A Procedures:</dt><dd>RFC 8840 defines the detailed
                   SDP Offer/Answer procedures for
                   the 'end-of-candidates' attribute.

   Mux Category: IDENTICAL

   Reference: RFCXXXX

   Example:

   a=end-of-candidates
      ]]>
      </artwork>
      </figure> attribute.</dd>

   <dt>Mux Category:</dt><dd>IDENTICAL</dd>

   <dt>Reference:</dt><dd>RFC 8840</dd>

   <dt>Example:</dt><dd>a=end-of-candidates</dd>
 </dl></li></ul>

      </section>
      <section title="Media anchor="sdpfrag-reg" numbered="true" toc="default">
        <name>Media Type 'application/trickle-ice-sdpfrag' " anchor="sdpfrag-reg"> 'application/trickle-ice-sdpfrag'</name>
        <t>
      This document defines a the new Media Type media type 'application/trickle-ice-sdpfrag'
      in accordance with <xref target="RFC6838"/>. target="RFC6838" format="default"/>.
        </t>
       <t>
      <list style="none">
        <t> Type name: application</t>
        <t> Subtype name: trickle-ice-sdpfrag</t>
        <t> Required parameters: None.</t>
        <t> Optional parameters: None. </t>
        <t> Encoding considerations:</t>
        <t><list style="none">
            <t>

          <ul empty="true"><li>
          <dl spacing="normal">
          <dt>Type name:</dt><dd>application</dd>
          <dt>Subtype name:</dt><dd>trickle-ice-sdpfrag</dd>
          <dt>Required parameters:</dt><dd>None.</dd>
          <dt>Optional parameters:</dt><dd>None.</dd>
          <dt>Encoding considerations:</dt><dd><t>
            The media contents follow the same rules as SDP,
            except as noted in this document.
            The media contents are text, with the grammar specified
            in <xref target="trickle_ice_sdpfrag_grammar"/>.
            </t>
            <t> target="trickle_ice_sdpfrag_grammar" format="default"/>.
          </t><t>
            Although the initially defined content of a trickle-ice-sdpfrag body
            does only include ASCII characters,
            UTF-8 encoded
            UTF-8-encoded content might be introduced via extension attributes.
            The "a=charset:" attribute may be used to signal the presence of other
            character sets in certain parts of a trickle-ice-sdpfrag body (see
            <xref target="RFC4566"/>). target="RFC4566" format="default"/>).
            Arbitrary binary content cannot be directly represented
            in SDP or a trickle-ice-sdpfrag body.
            </t>
        </list></t>
        <t> Security considerations: </t>
        <t><list style="none">
            <t>
            See
          </t></dd>

          <dt>Security considerations:</dt><dd>See <xref target="RFC4566"/> target="RFC4566" format="default"/> and RFCXXXX
            </t>
        </list></t>
        <t> Interoperability considerations:</t>
        <t><list style="none">
            <t>
            See RFCXXXX
            </t>
        </list></t>
        <t> Published specification:</t>
        <t><list style="none">
            <t>
            See RFCXXXX
            </t>
        </list></t>
        <t> Applications RFC 8840</dd>
          <dt>Interoperability considerations:</dt><dd>See RFC 8840</dd>
          <dt>Published specification:</dt><dd>See RFC 8840</dd>
          <dt>Applications which use this Media Type:</t>
        <t><list style="none">
            <t>
            Trickle-ICE
            </t>
        </list></t>
         <t>    Fragment Type:</dt><dd>Trickle ICE</dd>
          <dt>Fragment identifier considerations: N/A</t>
         <t> Additional information: </t>
            <t><list style="none">
                 <t> Deprecated considerations:</dt><dd>N/A</dd>
	  </dl>
	  </li>
          </ul>

          <ul empty="true">
	    <li>
	    <t>Additional information:</t>
          <ul empty="true">
            <li>
              <dl newline="false" spacing="normal" indent="9">
              <dt>Deprecated alias names for this type: N/A </t>
                 <t> Magic number(s):   N/A</t>
                 <t>File extension(s): N/A</t>
                 <t>Macintosh type:</dt><dd>N/A</dd>
              <dt>Magic number(s):</dt><dd>N/A</dd>
              <dt>File extension(s):</dt><dd>N/A</dd>
              <dt>Macintosh File Type Code(s): N/A</t>
            </list></t>
        <t> Person Code(s):</dt><dd>N/A</dd>
              </dl>
	    </li>
	  </ul>
	    </li>
	  </ul>

        <ul empty="true"><li>
        <dl newline="false" spacing="normal">
          <dt>Person and email address to contact for further information:</t>
        <t><list style="none">
            <t>
            The information:</dt>
            <dd>The IESG (iesg@ietf.org)
            </t>
        </list></t>
        <t> Intended usage: </t>
        <t><list style="none">
        <t>
            Trickle-ICE (iesg@ietf.org)</dd>

          <dt>Intended usage:</dt>
            <dd>Trickle ICE for SIP as specified in RFCXXXX.
        </t>
        </list></t>
        <t> Restrictions RFC 8840.</dd>

          <dt>Restrictions on usage: N/A</t>
        <t> Author/Change controller:</t>
        <t><list style="none">
            <t>
            The usage:</dt><dd>N/A</dd>
          <dt>Author/Change controller:</dt><dd>The IESG (iesg@ietf.org)
            </t>
        </list></t>
        <t> Provisional (iesg@ietf.org)</dd>
          <dt>Provisional registration? (standards tree only): N/A </t>

      </list>
      </t> only):</dt><dd>N/A</dd>
       </dl>
    </li>
   </ul>

      </section>
      <section title="SIP anchor="package-reg" numbered="true" toc="default">
        <name>SIP Info Package 'trickle-ice' " anchor="package-reg"> 'trickle-ice'</name>
        <t>
              This document defines a new SIP Info Package named 'trickle-ice'
              and updates the Info "Info Packages Registry Registry" with the following entry.
        </t>
              <t>
              <figure><artwork
<table anchor="table_1" align="left">
    +-------------+-----------+
    | Name        | Reference |
    +-------------+-----------+
    | trickle-ice | [RFCXXXX] |
    |             |           |
    +-------------+-----------+
              </artwork></figure>
              </t>
 <thead>
   <tr>
    <th align='center'>Name</th>
    <th align='center'>Reference</th>
   </tr>
  </thead>
  <tbody>
 <tr>
    <td>trickle-ice</td>
    <td>RFC 8840</td>
   </tr>
</tbody>
</table>
      </section>

      <section title="SIP anchor="optag-reg" numbered="true" toc="default">
        <name>SIP Option Tag 'trickle-ice'" anchor="optag-reg"> 'trickle-ice'</name>
        <t>
              This specification registers a new SIP option tag 'trickle-ice'
              as per the guidelines in Section 27.1 of <xref target="RFC3261"/> target="RFC3261" sectionFormat="of" section="27.1"/>
              and updates the "Option Tags" section subregistry of the
              SIP Parameter Registry Parameters registry  with the following entry:
        </t>
              <t>
           <figure><artwork

<table anchor="table_2" align="left">
    +-------------+-------------------------------------+-----------+
    | Name        | Description                         | Reference |
    +-------------+-------------------------------------+-----------+
    | trickle-ice | This
 <thead>
   <tr>
    <th align='center'>Name</th>
    <th align='center'>Description</th>
    <th align='center'>Reference</th>
   </tr>
  </thead>
  <tbody>
 <tr>
    <td>trickle&nbhy;ice</td>
    <td>This option tag is used to indicate | [RFCXXXX] |
    |             | that a UA supports and understands  |           |
    |             | Trickle-ICE.                        |           |
    +-------------+-------------------------------------+-----------+
                </artwork></figure>
              </t> Trickle ICE.</td>
    <td>RFC 8840</td>
   </tr>
</tbody>
</table>

      </section>
    </section>
    <section title='Security Considerations' anchor="sec-cons"> anchor="sec-cons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        The Security Considerations of
        <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>, target="RFC6086" format="default"/>,  <xref target="RFC6086"/> target="RFC8838" format="default"/>, and
        <xref target="I-D.ietf-ice-trickle"/> target="RFC8839" format="default"/> apply.
        This document clarifies how the above specifications are used together for trickling
        candidates and does not create additional security risks.
      </t>
      <t>
      The new Info Package 'trickle-ice' and
      the new Media Type media type 'application/trickle-ice-sdpfrag'
      do not introduce additional security considerations
      when used in the context of Trickle ICE.
      Both are not intended to be used for other applications,
      so any security considerations for its use in other contexts
      is out of the scope of this document
      </t>
    </section>
  </middle>
  <back>

    <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.3261.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.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.3605.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.5234.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.5888.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6086.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

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

<!--draft-ietf-mmusic-ice-sip-sdp-39; C238 companion doc-->
<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='May' year='2020' />
</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>

<!--draft-ietf-ice-trickle-21; C238; RFC 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='May' year='2020' />
</front>
<seriesInfo name="RFC" value="8838"/>
<seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>

<!--draft-ietf-mmusic-sdp-bundle-negotiation-54; C238; RFC 8843 -->
<reference anchor='RFC8843' target="https://www.rfc-editor.org/info/rfc8843">
<front>
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>
<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />
</author>
<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
    <organization />
</author>
<date month='May' year='2020' />
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>

<!--draft-ietf-mmusic-sdp-mux-attributes-17; C238; RFC 8859-->
<reference anchor='RFC8859' target="https://www.rfc-editor.org/info/rfc8859">
<front>
<title>A Framework for Session Description Protocol (SDP) Attributes When Multiplexing</title>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
    <organization />
</author>
<date month='May' year='2020' />
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
</reference>

<!--draft-ietf-mmusic-mux-exclusive-12; C238; RFC 8858 -->
<reference anchor='RFC8858' target="https://www.rfc-editor.org/info/rfc8858">
<front>
<title>Indicating Exclusive Support of RTP/RTCP Multiplexing Using the Session
 Description Protocol (SDP)</title>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>
<date month='May' year='2020' />
</front>
<seriesInfo name="RFC" value="8858"/>
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3311.xml"/>

 <!-- [rfced] The following references are not cited in the text.  Please let
us know where they should be cited or if these references should be deleted.

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
              <https://www.rfc-editor.org/info/rfc3725>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
 -->

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3725.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3840.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5389.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5627.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5766.xml"/>
      </references>
    </references>

 <section title='Acknowledgements'> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        The authors like to thank
        Flemming Andreasen,
        Ayush Jain,
        Paul Kyzivat,
        Jonathan Lennox,
        Simon Perreault,
        Roman Shpount
        and
        Martin Thomson
        <contact fullname="Flemming Andreasen"/>,
        <contact fullname="Ayush Jain"/>,
        <contact fullname="Paul Kyzivat"/>,
        <contact fullname="Jonathan Lennox"/>,
        <contact fullname="Simon Perreault"/>,
        <contact fullname="Roman Shpount"/>,
        and
        <contact fullname="Martin Thomson"/>
        for reviewing and/or making various suggestions for
        improvements and optimizations.
      </t>
      <t>
        The authors also like to thank
        Flemming Andreasen
        <contact fullname="Flemming Andreasen"/> for shepherding this document and
        Ben Campbell
        <contact fullname="Ben Campbell"/> for his AD review and suggestions.
        In addition, the author like to authors thank
        Benjamin Kaduk,
        Adam Roach,
        Mirja Kühlewind and
        Eric Rescorla
        <contact fullname="Benjamin Kaduk"/>,
        <contact fullname="Adam Roach"/>,
        <contact fullname="Mirja Kühlewind"/>, and
        <contact fullname="Eric Rescorla"/>
        for their comments and/or text proposals for improving
        the document during IESG review.
      </t>
      <t>
        Many thanks to Dale Worley <contact fullname="Dale Worley"/> for the Gen-Art review and proposed
        enhancements for several sections.
      </t>
      <t>
        Many thanks to  Joerg Ott <contact fullname="Joerg Ott"/> for the TSV-Art review and suggested improvements.
      </t>
      <t>
          The authors thank Shawn Emery <contact fullname="Shawn Emery"/> for the Security Directorate review.
      </t>
    </section>
        <section title='Change Log'>
      <t>
       [RFC EDITOR NOTE: Please remove this section when publishing].
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-01
      <list style="symbols">
        <t> Editorial Clean up</t>
        <t> IANA Consideration added</t>
        <t> Security  Consideration added</t>
        <t> RTCP and BUNDLE  Consideration added with rules for including "a=rtcp-mux" and "a=group: BUNDLLE" attributes </t>
        <t> 3PCC Consideration added</t>
        <t> Clarified that 18x w/o answer is sufficient to create a dialog that allows for trickling to start </t>
        <t> Added remaining Info Package definition sections as outlined in section 10 of   <xref target="RFC6086"/></t>
        <t> Added definition of application/sdpfrag making draft-ivov-mmusic-sdpfrag obsolete</t>
        <t> Added pseudo m-lines as additional separator in sdpfrag bodies for Trickle ICE </t>
        <t> Added ABNF for sdp-frag bodies and Trickle-ICE package </t>
      </list>

      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-02
      <list style="symbols">
        <t> Removed definition of application/sdpfrag </t>
        <t> Replaced with new type application/trickle-ice-sdpfrag </t>
        <t> RTCP and BUNDLE  Consideration enhanced with some examples </t>
        <t> draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to normative reference </t>
        <t> Removed reference to 4566bis </t>
        <t> Addressed review comment from Simon Perreault </t>
      </list>

      </t>
     <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-03
      <list style="symbols">
        <t> replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and draft-ietf-mmusic-ice-sip-sdp  </t>
        <t> Corrected Figure 10, credits to Ayush Jain for finding the bug  </t>
        <t> Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-ice-sip-sdp </t>
        <t> Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-mux-exclusive, enhanced ABNF to support  a=rtcp-mux-exclusive </t>
        <t> Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the application/trickle-ice-sdpfrag body </t>
      </list>

      </t>
     <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-04
      <list style="symbols">
        <t> considered comments from Christer Holmberg </t>
        <t> corrected grammar for INFO package, such that ice-ufrag/pwd are also allowed on media-level as specified in <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> </t>
        <t> Added new ice-pacing-attribute fom <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> </t>
        <t> Added formal definition for the end-of-candidates attribute </t>

      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-05
      <list style="symbols">
        <t> considered further comments from Christer Holmberg </t>
        <t> editorial comments on section 3 addressed </t>
        <t> moved section 3.1 to section 10.1 and applied some edits</t>
        <t> replaced the term "previously sent candidates" with "currently known and used candidates".</t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-06
      <list style="symbols">
        <t> editorial fixes</t>
        <t> additional text on the content of the INFO messages.</t>
        <t> recommendation on what to  do if a previously sent candidate is unexpectedly missing in a subsequent INFO </t>
        <t> terminology alignment with draft-ietf-ice-trickle-07 </t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-07
      <list style="symbols">
        <t> editorial fixes</t>
        <t> clarification on ordering of candidates for alignment with draft-ietf-ice-trickle-12 </t>
        <t> O/A procedures for end-of-candidates attribute described here after corresponding procedures
            have been removed from draft-ietf-ice-trickle-11</t>
        <t> using IPv6 addresses in examples         </t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-08
      <list style="symbols">
        <t> editorial fixes/clarification based on Flemmings review</t>
        <t> Description of Trickle specifics in O/A procedures for initial O/A exchange and specification of ICE mismatch exception</t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-09
      <list style="symbols">
        <t> editorial fixes/correction of references</t>
        <t>  adding missing Ref to RFC3605 in section 6, 5th para</t>
        <t> replaced remaining IPv4 adresses with IPv6 </t>
        <t>
            Added text for handling a=rtcp in case of default RTP address 0.0.0.0:9 based on comment from Roman Shpount.
        </t>

      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-10
      <list style="symbols">
        <t> editorial fixes due to idnits output</t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-11
      <list style="symbols">
        <t> addressing comments from Ben Campell's AD review and Christer's review
        </t>
      <t>
          Numerous editorial improvements/corrections
        </t>
      <t>
      Added [RFC8174] boiler plate and adapted usage of normative language
      </t>
      <t>
        Clarified terminology ICE modules .vs. ICE agent
      </t>
      <t>
          Added more detailed OA procedures
      </t>
      <t>
          Corrected default values in m-line
          and usage of "a=mid:" attribute explicitly mentioned for offer/answer
      </t>
      <t>    Removed explicit mentioning of XMPP
      </t>
      <t>
          Added Deployment Considerations section
      </t>
      <t>
      Fixed ref for rfc5245bis
      </t>
      </list>
      </t>
            <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-12
      <list style="symbols">
        <t> addressing comments from Gen-Art review, TSV-Art review and
        Security Directorate review
        </t>
      <t>
        Numerous editorial improvements/corrections/clarifications
        </t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-13
      <list style="symbols">
        <t> added expansions for SDP,GRUU, AOR, STUN, TURN
        </t>
      <t>
        some editorial corrections
        </t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-14
        </t>
      <t>
        Addressing comments from IESG review
      <list style="symbols">
        <t>
           Clarification/enhancement in section 5 and Fig. 10 based on comments from Benjamin Kaduk
        </t>

        <t>
          Clarification on sequence for sending candidates,
          definition of pseudo m-lines,
          usage of a=mid attribute,
          usage of INFO as ACK for receipt of 18x based on comments from Eric Rescorla
        </t>
        <t>
        Removal of 3PCC Section 3.4,
        removal of NATted IPv6 addresses,
        adding more flexibility to in the grammar,
        explicit mentioning of Require: header field,
        usage of Require: header field in case of provisioning,
        text on repetition of candidates in case of RTCP mux and Bundle,
        various other editorial improvements/corrections
        based on comments from Adam Roach
        </t>
        <t>
        Modified text on rate limitation of INFO requests based on
        comments of Mirja Kühlewind, Adam Roach and Roman Shpount
        </t>
        <t>
        some editorial corrections
        </t>
      </list>
 </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-15
        <list style="symbols">
      <t>
        Corrections in section 7 on Media Multiplexing
      </t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-16
      <list style="symbols">
        <t>
        some editorial corrections
        </t>
      </list>
      </t>
      <t>
      Changes from draft-ietf-mmusic-trickle-ice-sip-16
      <list style="symbols">
        <t>
        Changed IPv6 candidate example from srflx to host
        </t>
      </list>
      </t>

    </section>
  </middle>
  <back>
    <references title='Normative References'>
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.3261"?>
      <?rfc include="reference.RFC.3262"?>
      <?rfc include="reference.RFC.3264"?>
      <?rfc include="reference.RFC.3605"?>
      <?rfc include="reference.RFC.4566"?>
      <?rfc include="reference.RFC.5234"?>
      <?rfc include="reference.RFC.5761"?>
      <?rfc include="reference.RFC.5888"?>
      <?rfc include="reference.RFC.6086"?>
      <?rfc include="reference.RFC.6838"?>
      <?rfc include="reference.RFC.7405"?>
      <?rfc include="reference.RFC.8085"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.I-D.ietf-ice-rfc5245bis"?>
      <?rfc include="reference.I-D.ietf-mmusic-ice-sip-sdp"?>
      <?rfc include="reference.I-D.ietf-ice-trickle"?>
      <?rfc include="reference.I-D.ietf-mmusic-sdp-bundle-negotiation"?>
      <?rfc include="reference.I-D.ietf-mmusic-sdp-mux-attributes"?>
      <?rfc include="reference.I-D.ietf-mmusic-mux-exclusive"?>
      </references>
    <references title='Informative References'>
      <?rfc include="reference.RFC.3311"?>
      <?rfc include="reference.RFC.3725"?>
      <?rfc include="reference.RFC.3840"?>
      <?rfc include="reference.RFC.5389"?>
      <?rfc include="reference.RFC.5627"?>
      <?rfc include="reference.RFC.5766"?>
     </references>

  </back>
</rfc>