rfc8840xml2.original.xml   rfc8840.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category='std' ipr='trust200902' <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
docName='draft-ietf-mmusic-trickle-ice-sip-18'> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
docName="draft-ietf-mmusic-trickle-ice-sip-18" obsoletes="" updates="" submissi
onType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" ver
sion="3" consensus="true" number="8840">
<!-- xml2rfc v2v3 conversion 2.34.0 -->
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
<front> <front>
<title abbrev="Trickle ICE for SIP">
<title abbrev='Trickle ICE for SIP'>
A Session Initiation Protocol (SIP) Usage for A Session Initiation Protocol (SIP) Usage for
Incremental Provisioning of Candidates for Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (Trickle ICE) the Interactive Connectivity Establishment (Trickle ICE)
</title> </title>
<author initials='E.' surname='Ivov' <seriesInfo name="RFC" value="8840"/>
fullname='Emil Ivov'> <author initials="E." surname="Ivov" fullname="Emil Ivov">
<organization abbrev='Jitsi'>Jitsi</organization> <organization abbrev="Jitsi">Jitsi</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Strasbourg</city> <city>Strasbourg</city>
<code>67000</code> <code>67000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone>+33 6 72 81 15 55</phone> <phone>+33 6 72 81 15 55</phone>
<email>emcho@jitsi.org</email> <email>emcho@jitsi.org</email>
</address> </address>
</author> </author>
<author initials="T." surname="Stach" fullname="Thomas Stach" > <author initials="T." surname="Stach" fullname="Thomas Stach">
<organization>Unaffiliated</organization> <organization>Unaffiliated</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Vienna</city> <city>Vienna</city>
<region></region> <region/>
<code>1130</code> <code>1130</code>
<country>Austria</country> <country>Austria</country>
</postal> </postal>
<email>thomass.stach@gmail.com</email> <email>thomass.stach@gmail.com</email>
</address> </address>
</author> </author>
<author initials='E.' surname='Marocco' fullname='Enrico Marocco'> <author initials="E." surname="Marocco" fullname="Enrico Marocco">
<organization>Telecom Italia</organization> <organization>Telecom Italia</organization>
<address> <address>
<postal> <postal>
<street>Via G. Reiss Romoli, 274</street> <street>Via G. Reiss Romoli, 274</street>
<city>Turin</city> <city>Turin</city>
<code>10148</code> <code>10148</code>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>enrico.marocco@telecomitalia.it</email> <email>enrico.marocco@telecomitalia.it</email>
</address> </address>
</author> </author>
<author initials="C.H." surname="Holmberg" <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
fullname="Christer Holmberg">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<code>02420</code> <code>02420</code>
<city>Jorvas</city> <city>Jorvas</city>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>christer.holmberg@ericsson.com</email> <email>christer.holmberg@ericsson.com</email>
</address> </address>
</author> </author>
<date /> <date month="January" year="2021"/>
<abstract> <abstract>
<t> <t>
The Interactive Connectivity Establishment (ICE) protocol The Interactive Connectivity Establishment (ICE) protocol
describes a Network Address Translator (NAT) traversal mechanism describes a Network Address Translator (NAT) traversal mechanism
for UDP-based multimedia sessions established with the for UDP-based multimedia sessions established with the
Offer/Answer model. The ICE extension for Incremental Offer/Answer model. The ICE extension for Incremental
Provisioning of Candidates (Trickle ICE) defines a mechanism Provisioning of Candidates (Trickle ICE) defines a mechanism
that allows ICE Agents to shorten session establishment delays that allows ICE Agents to shorten session establishment delays
by making the candidate gathering and connectivity checking by making the candidate gathering and connectivity checking
phases of ICE non-blocking and by executing them in parallel. phases of ICE non-blocking and by executing them in parallel.
</t> </t>
<t> <t>
This document defines usage semantics for Trickle ICE with the This document defines usage semantics for Trickle ICE with the Session
Session Initiation Protocol (SIP). Initiation Protocol (SIP). The document also defines a new SIP Info
The document also defines Package to support this usage together with the corresponding media
a new SIP Info Package to support this usage type. Additionally, a new Session Description Protocol (SDP)
together with the corresponding media type. "end-of-candidates" attribute and a new SIP option tag "trickle-ice"
Additionally, a new SDP 'end-of-candidates' attribute and are defined.
a new SIP Option Tag 'trickle-ice' are defined.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
The Interactive Connectivity Establishment (ICE) protocol The Interactive Connectivity Establishment (ICE) protocol
<xref target="I-D.ietf-ice-rfc5245bis"/> describes <xref target="RFC8445" format="default"/> describes
a mechanism for Network Address Translator (NAT) traversal a mechanism for Network Address Translator (NAT) traversal
that consists of three main phases. that consists of three main phases.
</t> </t>
<t> <t>
During the first phase an agent gathers a set of candidate During the first phase, an agent gathers a set of candidate
transport addresses (source IP address, port and transport transport addresses (source IP, port, and transport
protocol). protocol).
This is followed by a second phase This is followed by a second phase
where these candidates are sent to a where these candidates are sent to a
remote agent within remote agent within
the Session Description Protocol (SDP) body of a SIP message. the Session Description Protocol (SDP) body of a SIP message.
At the remote agent the gathering procedure is repeated and At the remote agent, the gathering procedure is repeated and
candidates are sent to the first agent. candidates are sent to the first agent.
Once the candidate information is available, a third phase Once the candidate information is available, a third phase
starts in parallel where connectivity between all candidates starts in parallel where connectivity between all candidates
in both sets is checked (connectivity checks). in both sets is checked (connectivity checks).
Once these phases Once these phases
have been completed, and only then, both agents can begin have been completed, and only then, both agents can begin
communication. communication.
</t> </t>
<t> <t>
According to <xref target="I-D.ietf-ice-rfc5245bis"/> According to <xref target="RFC8445" format="default"/>,
the three phases above happen consecutively, in a blocking way, the three phases above happen consecutively, in a blocking way,
which can introduce undesirable setup delay during session which can introduce undesirable setup delay during session
establishment. establishment.
The Trickle ICE extension The Trickle ICE extension
<xref target="I-D.ietf-ice-trickle"/> defines generic <xref target="RFC8838" format="default"/> defines generic
semantics required for these ICE phases to happen semantics required for these ICE phases to happen
in a parallel, non-blocking way and hence speed up session in a parallel, non-blocking way and hence speeds up session
establishment. establishment.
</t> </t>
<t> <t>
This specification defines a usage of Trickle ICE with This specification defines a usage of Trickle ICE with
the Session Initiation Protocol (SIP)<xref target="RFC3261"/>. the Session Initiation Protocol (SIP)<xref target="RFC3261" format="defa ult"/>.
It describes how ICE It describes how ICE
candidates are to be exchanged incrementally using SIP INFO candidates are to be exchanged incrementally using SIP INFO
requests <xref target="RFC6086"/> requests <xref target="RFC6086" format="default"/>
and how the Half Trickle and Full Trickle modes defined in and how the Half Trickle and Full Trickle modes defined in
<xref target="I-D.ietf-ice-trickle"/> are to be used by <xref target="RFC8838" format="default"/> are to be used by
SIP User Agents (UAs) depending on their expectations for SIP User Agents (UAs) depending on their expectations for
support of Trickle ICE by a remote agent. support of Trickle ICE by a remote agent.
</t> </t>
<t> <t>
This document defines a new Info Package as specified in This document defines a new Info Package as specified in
<xref target="RFC6086"/> for use with Trickle ICE together <xref target="RFC6086" format="default"/> for use with Trickle ICE toget her
with the corresponding media type, with the corresponding media type,
SDP attribute and SIP option tag. SDP attribute, and SIP option tag.
</t> </t>
</section> </section>
<section title="Terminology"> <section numbered="true" toc="default">
<name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/>, "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC8174"/> when, and only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
appear in all capitals, as shown here. to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t> </t>
<t> <t>
This specification makes use of terminology defined by the This specification makes use of terminology defined by the
protocol for Interactive Connectivity Establishment in ICE protocol in
<xref target="I-D.ietf-ice-rfc5245bis"/> and its Trickle ICE extension <xref target="RFC8445" format="default"/> and by its Trickle ICE extensi
<xref target="I-D.ietf-ice-trickle"/>. It is assumed that on in
<xref target="RFC8838" format="default"/>. It is assumed that
the reader is familiar with the terminology from both documents. the reader is familiar with the terminology from both documents.
</t> </t>
<t> <xref target="I-D.ietf-ice-rfc5245bis"/> also describes <t> <xref target="RFC8445" format="default"/> also describes
how ICE makes use of the how ICE makes use of the
Session Traversal Utilities for NAT (STUN) protocol Session Traversal Utilities for NAT (STUN) protocol
<xref target="RFC5389"/> and its extension <xref target="RFC5389" format="default"/> and its extension
Traversal Using Relay NAT (TURN) <xref target="RFC5766"/>. Traversal Using Relays around NAT (TURN) <xref target="RFC5766" format=
"default"/>.
</t> </t>
</section> </section>
<section title="Protocol Overview" anchor='overview'> <section anchor="overview" numbered="true" toc="default">
<name>Protocol Overview</name>
<t> <t>
When using ICE for SIP according to When using ICE for SIP according to
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/> <xref target="RFC8839" format="default"/>,
the ICE candidates are exchanged solely via the ICE candidates are exchanged solely via
SDP Offer/Answer as per <xref target="RFC3264"/>. SDP Offer/Answer as per <xref target="RFC3264" format="default"/>.
This specification defines an additional mechanism This specification defines an additional mechanism
where candidates can be exchanged using SIP INFO messages where candidates can be exchanged using SIP INFO messages
and a newly defined Info Package <xref target="RFC6086"/>. and a newly defined Info Package <xref target="RFC6086" format="default"
This allows ICE />.
candidates also to be sent in parallel to an ongoing Offer/Answer This also allows ICE
candidates to be sent in parallel to an ongoing Offer/Answer
negotiation and/or after the completion of the Offer/Answer negotiation and/or after the completion of the Offer/Answer
negotiation. negotiation.
</t> </t>
<t> <t>
Typically, in cases where Trickle ICE is fully supported, Typically, in cases where Trickle ICE is fully supported,
the Offerer sends an INVITE request the Offerer sends an INVITE request
containing a subset of candidates. containing a subset of candidates.
Once an early dialog is established Once an early dialog is established,
the Offerer can continue sending the Offerer can continue sending
candidates in INFO requests within that dialog. candidates in INFO requests within that dialog.
</t> </t>
<t> <t>
Similarly, an Answerer can send Similarly, an Answerer can send
ICE candidates using INFO requests within ICE candidates using INFO requests within
the dialog established by its 18x provisional response. the dialog established by its 18x provisional response.
<xref target="fig-intro-example"/> shows such a sample <xref target="fig-intro-example" format="default"/> shows such a sample
exchange: exchange:
</t> </t>
<t>
<figure title="Sample Trickle ICE scenario with SIP" <figure anchor="fig-intro-example">
anchor="fig-intro-example"> <name>Sample Trickle ICE Scenario with SIP</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
STUN/Turn STUN/TURN STUN/TURN STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
| STUN Bi.Req. | INVITE (Offer) | | | STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| | |<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req | | | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->| | STUN Bi.Resp. |<------------------------|--------------->|
|-------------->| INFO/OK (SRFLX Cand.) | | |-------------->| INFO/OK (SRFLX Cand.) | |
| |------------------------>| TURN Alloc Resp| | |------------------------>| TURN Alloc Resp|
| | INFO/OK (Relay Cand.) |<---------------| | | INFO/OK (Relay Cand.) |<---------------|
| |<------------------------| | | |<------------------------| |
skipping to change at line 230 skipping to change at line 225
| |<=======================>| | | |<=======================>| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| |<------------------------| | | |<------------------------| |
| | ACK | | | | ACK | |
| |------------------------>| | | |------------------------>| |
| | | | | | | |
| |<===== MEDIA FLOWS =====>| | | |<===== MEDIA FLOWS =====>| |
| | | | | | | |
Note: SRFLX denotes server-reflexive candidates Note: "SRFLX" denotes server-reflexive candidates ]]></artwork>
]]></artwork> </figure>
</figure> <section anchor="disco-issues" numbered="true" toc="default">
</t> <name>Discovery Issues</name>
<section title="Discovery issues" anchor="disco-issues">
<t> <t>
In order to benefit from Trickle ICE's full potential and In order to benefit from Trickle ICE's full potential and
reduce session establishment latency to a minimum, Trickle ICE reduce session establishment latency to a minimum, Trickle ICE
agents need to generate SDP Offers and Answers that contain Agents need to generate SDP Offers and Answers that contain
incomplete, potentially empty sets of candidates. Such Offers incomplete and potentially empty sets of candidates. Such Offers
and Answers can only be handled meaningfully by agents that and Answers can only be handled meaningfully by agents that
actually support incremental candidate provisioning, which actually support incremental candidate provisioning, which
implies the need to confirm such support before using implies the need to confirm such support before using
it. it.
</t> </t>
<t> <t>
Contrary to other protocols, Contrary to other protocols,
where "in advance" capability where "in advance" capability
discovery is widely implemented, the mechanisms that allow this discovery is widely implemented, the mechanisms that allow this
for SIP (i.e., a combination of UA Capabilities for SIP (i.e., a combination of UA capabilities
<xref target="RFC3840"/> and Globally Routable User Agent URIs (GRUU) <xref target="RFC3840" format="default"/> and Globally Routable User A
<xref target="RFC5627"/>) gent URIs (GRUUs) <xref target="RFC5627" format="default"/>)
have only seen low levels of adoption. have only seen low levels of adoption.
This presents an issue This presents an issue
for Trickle ICE implementations as SIP UAs do not have an for Trickle ICE implementations as SIP UAs do not have an
obvious means of verifying that their peer will support obvious means of verifying that their peer will support
incremental candidate provisioning. incremental candidate provisioning.
</t> </t>
<t> <t>
The Half Trickle mode of operation defined in the Trickle The Half Trickle mode of operation defined in the Trickle
ICE specification <xref target="I-D.ietf-ice-trickle"/> ICE specification <xref target="RFC8838" format="default"/>
provides one way around this, by requiring the first Offer to provides one way around this, by requiring the first Offer to
contain a complete set of local ICE candidates contain a complete set of local ICE candidates
and only using and using only
incremental provisioning of remote candidates incremental provisioning of remote candidates
for the rest of the session. for the rest of the session.
</t> </t>
<t> <t>
While using Half Trickle does provide a working solution it While using Half Trickle does provide a working solution, it
also comes at the price of increased latency. also comes at the price of increased latency. Therefore,
<xref target="disco"/> therefore makes several alternative <xref target="disco" format="default"/> makes several alternative
suggestions that enable SIP UAs to engage in Full Trickle suggestions that enable SIP UAs to engage in Full Trickle
right from their first Offer: <xref target="disco-prov"/> right from their first Offer: <xref target="disco-prov" format="defaul
discusses the use of on-line provisioning as a means of t"/>
allowing use of Trickle ICE for all endpoints in controlled discusses the use of online provisioning as a means of
environments. <xref target="disco-gruu"/> describes allowing the use of Trickle ICE for all endpoints in controlled
environments. <xref target="disco-gruu" format="default"/> describes
anticipatory discovery for implementations that actually do anticipatory discovery for implementations that actually do
support GRUU and UA Capabilities and support GRUU and UA capabilities, and
<xref target="half-full-trickle"/> discusses the implementation <xref target="half-full-trickle" format="default"/> discusses the impl
ementation
and use of Half Trickle by SIP UAs where none of the above and use of Half Trickle by SIP UAs where none of the above
are an option. are an option.
</t> </t>
</section> </section>
<section title="Relationship with the Offer/Answer Model"> <section numbered="true" toc="default">
<name>Relationship with the Offer/Answer Model</name>
<t> <t>
From the perspective of SIP middle boxes and proxies From the perspective of SIP middleboxes and proxies,
the Offer/Answer exchange for the Offer/Answer exchange for
Trickle ICE looks partly similar to the Offer/Answer exchange Trickle ICE looks partly similar to the Offer/Answer exchange
for regular ICE for SIP for regular ICE for SIP
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. <xref target="RFC8839" format="default"/>.
However, in order to have the full picture of the candidate However, in order to have the full picture of the candidate
exchange, the newly introduced INFO messages exchange, the newly introduced INFO messages
need to be considered as well. need to be considered as well.
</t> </t>
<t> <figure anchor="fig-oa-and-trickle">
<figure title="Distinguishing between Trickle ICE and <name>Distinguishing between Trickle ICE and Traditional Signaling</na
traditional signaling." anchor="fig-oa-and-trickle"> me>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![CDATA[
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob | | Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | |
| +--------+ | Module | | | | Module | +--------+ | | +--------+ | Module | | | | Module | +--------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | | | | ICE | +--------------+ | | +--------------+ | ICE | |
| | Module | | | | | | Module | | | | Module | | | | | | Module | |
| +--------+ | | | | +--------+ | | +--------+ | | | | +--------+ |
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| | | | | | | |
| | INVITE (Offer) | | | | INVITE (Offer) | |
skipping to change at line 323 skipping to change at line 315
| | | |
| SIP INFO (more candidates) | | SIP INFO (more candidates) |
|----------------------------------------------------->| |----------------------------------------------------->|
| SIP INFO (more candidates) | | SIP INFO (more candidates) |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| STUN Binding Requests/Responses | | STUN Binding Requests/Responses |
|----------------------------------------------------->| |----------------------------------------------------->|
| STUN Binding Requests/Responses | | STUN Binding Requests/Responses |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |]]></artwork>
</figure>
]]>
</artwork>
</figure>
</t>
<t> <t>
From an architectural viewpoint, as displayed in From an architectural viewpoint, as displayed in
<xref target="fig-oa-and-trickle"/>, exchanging candidates <xref target="fig-oa-and-trickle" format="default"/>, exchanging candi dates
through SIP INFO requests could be represented as signaling through SIP INFO requests could be represented as signaling
between ICE modules and not between Offer/Answer modules of between ICE modules and not between Offer/Answer modules of
SIP User Agents. Then, such INFO requests SIP UAs. Then, such INFO requests
do not impact the state of the Offer/Answer transaction other do not impact the state of the Offer/Answer transaction other
than providing additional candidates. than providing additional candidates.
Consequently, INFO requests are not considered Offers or Answers. Consequently, INFO requests are not considered Offers or Answers.
Nevertheless, candidates that have been exchanged Nevertheless, candidates that have been exchanged
using INFO requests using INFO requests
SHALL be included in subsequent Offers or Answers. <bcp14>SHALL</bcp14> be included in subsequent Offers or Answers.
The version number in the "o=" line of that subsequent Offer The version number in the "o=" line of that subsequent Offer
needs to be incremented by 1 per the rules needs to be incremented by 1 per the rules
in <xref target="RFC3264"/>. in <xref target="RFC3264" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section title="Incremental Signaling of ICE candidates" anchor="OAproc"> <section anchor="OAproc" numbered="true" toc="default">
<t> <name>Incremental Signaling of ICE Candidates</name>
<t>
Trickle ICE Agents will exchange Trickle ICE Agents will exchange
ICE descriptions compliant to ICE descriptions compliant to
<xref target="I-D.ietf-ice-trickle"/> <xref target="RFC8838" format="default"/>
via Offer/Answer procedures and/or INFO request bodies. via Offer/Answer procedures and/or INFO request bodies.
This requires the following SIP-specific extensions: This requires the following SIP-specific extensions:
</t> </t>
<t> <ol spacing="normal" type="1">
<list style="numbers"> <li>
<t> Trickle ICE Agents <bcp14>MUST</bcp14> indicate support for Trickle
Trickle ICE Agents MUST indicate support for Trickle ICE by ICE by
including the SIP option-tag 'trickle-ice' in a SIP Supported: heade including the SIP option-tag "trickle-ice" in a SIP Supported: heade
r field r field
within all SIP INVITE requests and responses. within all SIP INVITE requests and responses.
</t> </li>
<t> <li>
Trickle ICE Agents MUST indicate support for Trickle ICE by Trickle ICE Agents <bcp14>MUST</bcp14> indicate support for Trickle
including the ice-option 'trickle' ICE by
including the ice-option "trickle"
within all SDP Offers and Answers in accordance to within all SDP Offers and Answers in accordance to
<xref target="I-D.ietf-ice-trickle"/>. <xref target="RFC8838" format="default"/>.
</t> </li>
<t> <li>
Trickle ICE Agents MAY include any number of ICE candidates, Trickle ICE Agents <bcp14>MAY</bcp14> include any number of ICE candid
i.e. from zero to the complete set of candidates, ates,
i.e., from zero to the complete set of candidates,
in their initial Offer or Answer. in their initial Offer or Answer.
If the complete candidate set is included already If the complete candidate set is already included
in the initial Offer, this is called Half-Trickle. in the initial Offer, it is called Half Trickle.
</t> </li>
<t> <li>
Trickle ICE Agents MAY exchange additional ICE candidates using INFO Trickle ICE Agents <bcp14>MAY</bcp14> exchange additional ICE candid
requests ates using INFO requests
within an existing INVITE dialog usage (including an early dialog) within an existing INVITE dialog usage (including an early dialog)
as specified in <xref target="RFC6086"/>. as specified in <xref target="RFC6086" format="default"/>.
The INFO requests carry an Info-Package: trickle-ice. The INFO requests carry an Info-Package: trickle-ice.
Trickle ICE Agents MUST be prepared to receive INFO requests Trickle ICE Agents <bcp14>MUST</bcp14> be prepared to receive INFO r equests
within that same dialog usage, within that same dialog usage,
containing additional candidates and/or containing additional candidates and/or
an indication that trickling of such candidates has ended. an indication that trickling of such candidates has ended.
</t> </li>
<t> <li>
Trickle ICE Agents MAY exchange additional ICE candidates Trickle ICE Agents <bcp14>MAY</bcp14> exchange additional ICE candid
ates
before the Answerer has sent the Answer provided that before the Answerer has sent the Answer provided that
an invite dialog usage is established at both Trickle ICE Agents. an invite dialog usage is established at both Trickle ICE Agents.
Note that in case of forking multiple early dialogs may exist. Note that in case of forking, multiple early dialogs may exist.
</t> </li>
</list> </ol>
</t>
<t> <t>
The following sections provide further details on how The following sections provide further details on how
Trickle ICE Agents perform the initial Offer/Answer exchange Trickle ICE Agents perform the initial Offer/Answer exchange
(<xref target="InitialOA"/>), (<xref target="InitialOA" format="default"/>),
perform subsequent Offer/Answer exchanges perform subsequent Offer/Answer exchanges
(<xref target="subsOA"/>) (<xref target="subsOA" format="default"/>),
and establish the INVITE dialog usage and establish the INVITE dialog usage
(<xref target="dialog-est"/>) (<xref target="dialog-est" format="default"/>)
such that they can incrementally trickle candidates such that they can incrementally trickle candidates
(<xref target="info-sdp"/>). (<xref target="info-sdp" format="default"/>).
</t> </t>
<section title="Initial Offer/Answer Exchange" anchor="InitialOA"> <section anchor="InitialOA" numbered="true" toc="default">
<section title="Sending the Initial Offer" anchor="IniOS"> <name>Initial Offer/Answer Exchange</name>
<t> <section anchor="IniOS" numbered="true" toc="default">
<name>Sending the Initial Offer</name>
<t>
If the Offerer includes candidates in its initial Offer, If the Offerer includes candidates in its initial Offer,
it MUST encode these candidates as specified in it <bcp14>MUST</bcp14> encode these candidates as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. <xref target="RFC8839" format="default"/>.
</t> </t>
<t>If the Offerer wants to send its initial Offer <t>If the Offerer wants to send its initial Offer
before knowing any candidate for one or more media descriptions , before knowing any candidate for one or more media descriptions ,
it MUST set the port to the default value '9' for these media descriptions. it <bcp14>MUST</bcp14> set the port to the default value '9' f or these media descriptions.
If the Offerer does not want to include the If the Offerer does not want to include the
host IP address in the corresponding c-line, host IP address in the corresponding "c="line,
e.g. due to privacy reasons, e.g., due to privacy reasons,
it SHOULD include a default address in the c-line, it <bcp14>SHOULD</bcp14> include a default address in the "c="l
ine,
which is set to the IPv4 address 0.0.0.0 or which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::. to the IPv6 equivalent ::.
</t> </t>
<t> <t>
In this case, the Offerer obviously cannot know the RTCP transp In this case, the Offerer obviously cannot know the
ort address and, RTP Control Protocol (RTCP) transport address;
thus, MUST NOT include the "a=rtcp" attribute <xref target="RF thus, it <bcp14>MUST NOT</bcp14> include the "rtcp" attribute <
C6086"/>. xref target="RFC3605" format="default"/>.
This avoids potential ICE mismatch This avoids potential ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>) for the RTCP (see <xref target="RFC8839" format="default"/>) for the RTCP tr
transport address. ansport address.
</t> </t>
<t> <t>
If the Offerer wants to use RTCP multiplexing If the Offerer wants to use RTCP multiplexing
<xref target="RFC5761"/> <xref target="RFC5761" format="default"/>
and/or exclusive RTCP multiplexing and/or exclusive RTCP multiplexing
<xref target="I-D.ietf-mmusic-mux-exclusive"/>, <xref target="RFC8858" format="default"/>,
it still will include the "a=rtcp-mux" and/or it still will include the "rtcp-mux" and/or
"a=rctp-mux-only" attribute "rctp-mux-only" attribute
in the initial Offer. in the initial Offer.
</t> </t>
<t> <t>
In any case, the Offerer MUST include In any case, the Offerer <bcp14>MUST</bcp14> include
the attribute "a=ice-options:trickle" in accordance to the "ice-options:trickle" attribute in accordance to
<xref target="I-D.ietf-ice-trickle"/> and <xref target="RFC8838" format="default"/> and
MUST include in each "m="-line a "a=mid:" attribute <bcp14>MUST</bcp14> include in each "m=" line a "mid" attribute
in accordance to <xref target="RFC5888"/>. in accordance to <xref target="RFC5888" format="default"/>.
The "a=mid:" attribute identifies the "m="-line The "mid" attribute identifies the "m=" line
to which a candidate belongs and to which a candidate belongs and
helps in case of multiple "m="-lines, helps in case of multiple "m=" lines,
when candidates gathering could occur in a order different when candidate gathering could occur in an order different
from the order of the "m="-lines. from the order of the "m=" lines.
</t> </t>
</section> </section>
<section title="Receiving the Initial Offer" anchor="IniOR"> <section anchor="IniOR" numbered="true" toc="default">
<t> <name>Receiving the Initial Offer</name>
<t>
If the initial Offer included candidates, If the initial Offer included candidates,
the Answerer uses these candidates to start ICE processing the Answerer uses these candidates to start ICE processing
as specified in <xref target="I-D.ietf-ice-trickle"/>. as specified in <xref target="RFC8838" format="default"/>.
</t> </t>
<t> <t>
If the initial Offer included the attribute a=ice-options:trick If the initial Offer included the "ice-options:trickle" attribu
le, te,
the Answerer MUST be prepared for receiving trickled candidates the Answerer <bcp14>MUST</bcp14> be prepared for receiving tric
later on. kled candidates later on.
</t> </t>
<t> <t>
In case of a "m/c=" line with default values In case of a "m/c=" line with default values,
none of the eventually trickled candidates none of the eventually trickled candidates
will match the default destination. will match the default destination.
This situation MUST NOT cause an ICE mismatch This situation <bcp14>MUST NOT</bcp14> cause an ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>). (see <xref target="RFC8839" format="default"/>).
</t> </t>
</section> </section>
<section title="Sending the Initial Answer" anchor="IniAS"> <section anchor="IniAS" numbered="true" toc="default">
<t> <name>Sending the Initial Answer</name>
<t>
If the Answerer includes candidates in its initial Answer, If the Answerer includes candidates in its initial Answer,
it MUST encode these candidates as specified in it <bcp14>MUST</bcp14> encode these candidates as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. <xref target="RFC8839" format="default"/>.
</t> </t>
<t>If the Answerer wants to send its initial Answer
<t>If the Answerer wants to send its initial Answer
before knowing any candidate for one or more media descriptions , before knowing any candidate for one or more media descriptions ,
it MUST set the port to the default value '9' for these media descriptions. it <bcp14>MUST</bcp14> set the port to the default value '9' f or these media descriptions.
If the Answerer does not want to include the If the Answerer does not want to include the
host IP address in the corresponding c-line, host IP address in the corresponding "c="line,
e.g. due to privacy reasons, e.g., due to privacy reasons,
it SHOULD include a default address in the c-line, it <bcp14>SHOULD</bcp14> include a default address in the "c="l
ine,
which is set to the IPv4 address 0.0.0.0 or which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::. to the IPv6 equivalent ::.
</t> </t>
<t> <t>
In this case, the Answerer obviously cannot know the RTCP trans In this case, the Answerer obviously cannot know the RTCP trans
port address and, port address; thus,
thus, MUST NOT include the "a=rtcp" attribute <xref target="RF it <bcp14>MUST NOT</bcp14> include the "rtcp" attribute <xref t
C6086"/>. arget="RFC6086" format="default"/>.
This avoids potential ICE mismatch This avoids potential ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>) for the RTCP (see <xref target="RFC8839" format="default"/>) for the RTCP tr
transport address. ansport address.
</t> </t>
<t> <t>
If the Answerer accepts to use RTCP multiplexing If the Answerer accepts the use of RTCP multiplexing
<xref target="RFC5761"/> <xref target="RFC5761" format="default"/>
and/or exclusive RTCP multiplexing and/or exclusive RTCP multiplexing
<xref target="I-D.ietf-mmusic-mux-exclusive"/>, <xref target="RFC8858" format="default"/>,
it will include the "a=rtcp-mux" attribute it will include the "rtcp-mux" attribute
in the initial Answer. in the initial Answer.
</t> </t>
<t> <t>
In any case, the Answerer MUST include In any case, the Answerer <bcp14>MUST</bcp14> include
the attribute "a=ice-options:trickle" in accordance to the "ice-options:trickle" attribute in accordance to
<xref target="I-D.ietf-ice-trickle"/> and <xref target="RFC8838" format="default"/> and
MUST include in each "m="-line <bcp14>MUST</bcp14> include in each "m=" line
a "a=mid:" attribute in accordance to a "mid" attribute in accordance to
<xref target="RFC5888"/>. <xref target="RFC5888" format="default"/>.
</t> </t>
</section>
</section> <section anchor="IniAR" numbered="true" toc="default">
<section title="Receiving the Initial Answer" anchor="IniAR"> <name>Receiving the Initial Answer</name>
<t> <t>
If the initial Answer included candidates, If the initial Answer included candidates,
the Offerer uses these candidates to start ICE processing the Offerer uses these candidates to start ICE processing
as specified in <xref target="I-D.ietf-ice-trickle"/>. as specified in <xref target="RFC8838" format="default"/>.
</t> </t>
<t> <t>
In case of a "m/c=" line with default values In case of a "m/c=" line with default values,
none of the eventually trickled candidates none of the eventually trickled candidates
will match the default destination. will match the default destination.
This situation MUST NOT cause an ICE mismatch This situation <bcp14>MUST NOT</bcp14> cause an ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>). (see <xref target="RFC8839" format="default"/>).
</t> </t>
</section>
</section> </section>
<section title="Subsequent Offer/Answer Exchanges" anchor="subsOA"> </section>
<section anchor="subsOA" numbered="true" toc="default">
<name>Subsequent Offer/Answer Exchanges</name>
<t> <t>
Subsequent Offer/Answer exchanges are handled Subsequent Offer/Answer exchanges are handled
as for regular ICE (see section 4.2 of the same as regular ICE (see <xref target="RFC8839" sectionFormat="o
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/>). f" section="4.4"/>).
</t> </t>
<t> If an Offer or Answer needs to be sent while the ICE agents <t> If an Offer or Answer needs to be sent while the ICE Agents
are in the middle of trickling are in the middle of trickling,
section 3.2 of <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>) applies <xref target="RFC8839" sectionFormat="of" section="4.4"/> applies.
. This means that an ICE Agent includes candidate attributes
This means that an ICE agent includes candidate attributes
for all local candidates it had trickled previously for all local candidates it had trickled previously
for a specific media stream. for a specific media stream.
</t>
<t>
[RFC EDITOR NOTE: The section 3.2 in above sentence is correct for version 20 o
f said I-D.
Authors need to cross-check during Auth48 since it could have have changed in t
he meantime.]
</t>
</section>
<section title="Establishing the Dialog" anchor="dialog-est">
<t>
In order to be able to start trickling, the
following two conditions need to be satisfied at the SIP UAs:
</t> </t>
</section>
<section anchor="dialog-est" numbered="true" toc="default">
<name>Establishing the Dialog</name>
<t> <t>
<list style="symbols"> In order to be able to start trickling, the
<t> following two conditions need to be satisfied at the SIP UAs:
Trickle ICE support at the peer agent MUST be confirmed.
</t>
<t>
A dialog MUST have been created between the peers.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
Trickle ICE support at the peer agent <bcp14>MUST</bcp14> be confi
rmed.
</li>
<li>
A dialog <bcp14>MUST</bcp14> have been created between the peers.
</li>
</ul>
<t> <t>
<xref target="disco"/> discusses in detail the various options <xref target="disco" format="default"/> discusses in detail the variou
for satisfying the first of the above conditions. Regardless s options
of those mechanisms, however, agents are certain to have a for satisfying the first of the above conditions. However, regardless
of those mechanisms, agents are certain to have a
clear understanding of whether their peers support trickle clear understanding of whether their peers support trickle
ICE once an Offer and an Answer have been exchanged, ICE once an Offer and an Answer have been exchanged,
which also allows for ICE processing to commence which also allows for ICE processing to commence
(see <xref target="offerer-can-trickle"/>). (see <xref target="offerer-can-trickle" format="default"/>).
</t> </t>
<section title="Establishing Dialog State through Reliable Offer/Answe <section anchor="relprov" numbered="true" toc="default">
r Delivery" anchor="relprov"> <name>Establishing Dialog State through Reliable Offer/Answer Delivery
<t> </name>
<figure title="SIP Offerer can freely trickle as soon as it <figure anchor="offerer-can-trickle">
receives an Answer." <name>A SIP Offerer can freely trickle as soon as it receives an Ans
anchor="offerer-can-trickle"> wer</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| PRACK/OK | | PRACK/OK |
|------------------------>| |------------------------>|
| | | |
+----------------------------------------+ +----------------------------------------+
skipping to change at line 594 skipping to change at line 578
|and know that the dialog is in the early| |and know that the dialog is in the early|
|state. Send INFO! | |state. Send INFO! |
+----------------------------------------+ +----------------------------------------+
| | | |
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|------------------------>| |------------------------>|
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
Note: SRFLX denotes server-reflexive candidates Note: "SRFLX" denotes server-reflexive candidates]]></artwork>
</figure>
]]></artwork>
</figure>
</t>
<t> <t>
As shown in <xref target="offerer-can-trickle"/> As shown in <xref target="offerer-can-trickle" format="default"/>,
satisfying both conditions is relatively trivial for satisfying both conditions is relatively trivial for
ICE Agents that have sent an Offer in an INVITE and that have ICE Agents that have sent an Offer in an INVITE and that have
received an Answer in a reliable provisional response. received an Answer in a reliable provisional response.
It is guaranteed to have confirmed support for It is guaranteed to have confirmed support (or lack thereof) for
Trickle ICE at the Answerer (or lack thereof) and to have Trickle ICE at the Answerer and to have
fully initialized the SIP dialog at both ends. fully initialized the SIP dialog at both ends.
Offerers and Answerers (after receipt of the PRACK request) Offerers and Answerers (after receipt of the PRACK request)
in the above situation can therefore in the above situation can therefore
freely commence trickling within the newly established dialog. freely commence trickling within the newly established dialog.
</t> </t>
</section> </section>
<section title="Establishing Dialog State through Unreliable Offer/Ans <section anchor="unrelprov" numbered="true" toc="default">
wer Delivery" anchor="unrelprov"> <name>Establishing Dialog State through Unreliable Offer/Answer Delive
ry</name>
<t> <t>
The situation is a bit more delicate for agents that have The situation is a bit more delicate for agents that have
received an Offer in an INVITE request and have sent an Answer received an Offer in an INVITE request and have sent an Answer
in an unreliable provisional response because, once the in an unreliable provisional response because, once the
response has been sent, the Answerer does not response has been sent, the Answerer does not
know when or if it has been received know when or if it has been received
(<xref target="answerer-cant-trickle"/>). (<xref target="answerer-cant-trickle" format="default"/>).
</t> </t>
<t> <figure anchor="answerer-cant-trickle">
<figure title="A SIP UA that sent an Answer in an unreliable <name>A SIP UA that sent an Answer in an unreliable provisional resp
provisional response does not know if onse does not know if it was received or if the dialog at the side of the Offere
it was received and if the dialog at the r has entered the early state</name>
side of the Offerer has entered the early <artwork name="" type="" align="left" alt=""><![CDATA[
state"
anchor="answerer-cant-trickle">
<artwork><![CDATA[
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| | | |
| +----------------------+ | +----------------------+
| |Bob: I don't know if | | |Bob: I don't know if |
| |Alice got my 183 or if| | |Alice got my 183 or if|
| |her dialog is already | | |her dialog is already |
| |in the early state. | | |in the early state. |
| | Can I send INFO??? | | | Can I send INFO??? |
| +----------------------+ | +----------------------+
| | | | ]]></artwork>
]]></artwork> </figure>
</figure>
</t>
<t> <t>
In order to clear this ambiguity as soon as possible, In order to clear this ambiguity as soon as possible,
the Answerer needs to retransmit the provisional response the Answerer needs to retransmit the provisional response
with the exponential back-off timers described in with the exponential backoff timers described in
<xref target="RFC3262"/>. <xref target="RFC3262" format="default"/>.
These retransmissions MUST cease on receipt These retransmissions <bcp14>MUST</bcp14> cease on receipt
of an INFO request carrying a 'trickle-ice' Info Package body, of an INFO request carrying a "trickle-ice" Info Package body,
on receipt of any other in-dialog request from the offerer or on receipt of any other in-dialog request from the Offerer, or
on transmission of the Answer in a 2xx response. on transmission of the Answer in a 2xx response.
The offerer cannot send in-dialog requests until it receives The Offerer cannot send in-dialog requests until it receives
a response, so the arrival of such a request proves that a response, so the arrival of such a request proves that
the response has arrived. the response has arrived.
Using the INFO request for dialog confirmation Using the INFO request for dialog confirmation
is similar to the procedure described in section is similar to the procedure described in
6.1.1 of <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> except that <xref target="RFC8839" sectionFormat="of" section="7.1.1"/>, except
the STUN binding Request is replaced by the INFO request. that
</t> the STUN binding request is replaced by the INFO request.
<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 t
he meantime.]
</t> </t>
<t> <t>
The Offerer MUST send a Trickle ICE INFO request as soon as The Offerer <bcp14>MUST</bcp14> send a Trickle ICE INFO request as s oon as
it receives an SDP Answer in an unreliable provisional it receives an SDP Answer in an unreliable provisional
response. This INFO request MUST repeat the candidates response. This INFO request <bcp14>MUST</bcp14> repeat the candidate s
that were already provided in the Offer (as would be the case that were already provided in the Offer (as would be the case
when Half Trickle is performed or when new candidates have not when Half Trickle is performed or when new candidates have not
been learned since then). been learned since then).
The first case could happen when Half Trickle is used and The first case could happen when Half Trickle is used and
all candidate are already in the initial offer. all candidates are already in the initial offer.
The second case could happen when Full Trickle is used and The second case could happen when Full Trickle is used and
the offerer is currently gathering additional candidates, the Offerer is currently gathering additional candidates
but did not yet get them. but did not yet get them.
Also, if the initial Offer did not contain any candidates, Also, if the initial Offer did not contain any candidates,
depending on how the Offerer gathers its candidates and depending on how the Offerer gathers its candidates and
how long it takes to do so, this INFO could still contain no candida tes. how long it takes to do so, this INFO could still contain no candida tes.
</t> </t>
<t> <t>
When Full Trickle is used and if newly learned candidates When Full Trickle is used and if newly learned candidates
are available, the Offerer SHOULD also deliver are available, the Offerer <bcp14>SHOULD</bcp14> also deliver
these candidates in said INFO request, these candidates in said INFO request,
unless it wants to hold back some candidates in reserve, unless it wants to hold back some candidates in reserve,
e.g. in case that these candidates e.g., in case these candidates
are expensive to use and would only be trickled are expensive to use and would only be trickled
if all other candidates failed. if all other candidates failed.
</t> </t>
<t> <t>
The Offerer SHOULD include an end-of-candidates attribute The Offerer <bcp14>SHOULD</bcp14> include an "end-of-candidates" att
in case candidate discovery has ended in the mean time ribute
in case candidate discovery has ended in the meantime
and no further candidates are to be trickled. and no further candidates are to be trickled.
</t> </t>
<t> <t>
As soon as an Answerer has received such an INFO request, As soon as an Answerer has received such an INFO request,
the Answerer has an indication that a dialog is established the Answerer has an indication that a dialog is established
at both ends and can begin trickling at both ends and trickling can begin
(<xref target="answerer-can-now-trickle"/>). (<xref target="answerer-can-now-trickle" format="default"/>).
</t> </t>
<t> <t>
Note: The +SRFLX in Note: The "+SRFLX" in
<xref target="answerer-can-now-trickle"/> <xref target="answerer-can-now-trickle" format="default"/>
indicates that additionally newly learned server-reflexive candidat indicates that additional newly learned server-reflexive candidates
es are included. are included.
</t> </t>
<t> <figure anchor="answerer-can-now-trickle">
<figure title="A SIP UA that received an INFO request <name>A SIP UA that received an INFO request after sending an unreli
after sending an unreliable able provisional response knows that the dialog at th
provisional response knows that the dialog at the e side of the receiver has entered the early state</name>
side of the receiver has entered the early <artwork name="" type="" align="left" alt=""><![CDATA[
state" anchor="answerer-can-now-trickle">
<artwork><![CDATA[
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|------------------------>| |------------------------>|
| | | |
| +----------------------+ | +----------------------+
| |Bob: Now I know Alice| | |Bob: Now I know Alice|
| | is ready. Send INFO! | | | is ready. Send INFO! |
| +----------------------+ | +----------------------+
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Note: SRFLX denotes server-reflexive candidates Note: "SRFLX" denotes server-reflexive candidates ]]></artwork>
</figure>
]]></artwork>
</figure>
</t>
<t> <t>
When sending the Answer in the 200 OK response to the INVITE request, When sending the Answer in the 200 OK response to the INVITE request,
the Answerer needs to repeat the Answerer needs to repeat
exactly the same Answer that was previously sent exactly the same Answer that was previously sent
in the unreliable provisional in the unreliable provisional
response in order to fulfill the corresponding requirements in response in order to fulfill the corresponding requirements in
<xref target="RFC3264"/>. <xref target="RFC3264" format="default"/>.
Thus, the Offerer needs to be prepared Thus, the Offerer needs to be prepared
for receiving a different number of candidates for receiving a different number of candidates
in that repeated Answer than previously exchanged via trickling in that repeated Answer than previously exchanged via trickling
and MUST ignore the candidate information and <bcp14>MUST</bcp14> ignore the candidate information
in that 200 OK response. in that 200 OK response.
</t> </t>
</section> </section>
<section title="Initiating Trickle ICE without an SDP Answer" <section anchor="head-start" numbered="true" toc="default">
anchor="head-start"> <name>Initiating Trickle ICE without an SDP Answer</name>
<t> <t>
The ability to convey arbitrary candidates in INFO The ability to convey arbitrary candidates in INFO
message bodies allows ICE Agents to initiate trickling message bodies allows ICE Agents to initiate trickling
without actually sending an Answer. without actually sending an Answer.
Trickle ICE Agents can therefore respond to an INVITE request Trickle ICE Agents can therefore respond to an INVITE request
with provisional responses without an SDP Answer with provisional responses without an SDP Answer
<xref target="RFC3261"/>. <xref target="RFC3261" format="default"/>.
Such provisional responses serve for establishing an early dialog. Such provisional responses serve for establishing an early dialog.
</t> </t>
<t> <t>
Agents that choose to establish the dialog in this way, Agents that choose to establish the dialog in this way
MUST retransmit these responses <bcp14>MUST</bcp14> retransmit these responses
with the exponential back-off timers described in with the exponential backoff timers described in
<xref target="RFC3262"/>. <xref target="RFC3262" format="default"/>.
These retransmissions MUST cease on receipt These retransmissions <bcp14>MUST</bcp14> cease on receipt
of an INFO request carrying a 'trickle-ice' Info Package body, of an INFO request carrying a "trickle-ice" Info Package body,
on receipt any in-dialog request from the offerer or on receipt of any in-dialog requests from the Offerer, or
on transmission of the Answer in a 2xx response. on transmission of the Answer in a 2xx response.
The offerer cannot send in-dialog requests until it receives The Offerer cannot send in-dialog requests until it receives
a response, so the arrival of such a request proves that a response, so the arrival of such a request proves that
the response has arrived. the response has arrived.
This is again similar to the procedure described in section This is again similar to the procedure described in
6.1.1 of <xref target="I-D.ietf-mmusic-ice-sip-sdp"/> <xref target="RFC8839" sectionFormat="of" section="6.1.1"/>,
except that an Answer is not yet provided. 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 t
he meantime.]
</t> </t>
<t> <t>
Note: The +SRFLX in Note: The "+SRFLX" in
<xref target="can-now-trickle-unrelprov"/> <xref target="can-now-trickle-unrelprov" format="default"/>
indicates that additionally newly learned server-reflexive candidat indicates that additional newly learned server-reflexive candidates
es are included. are included.
</t> </t>
<t> <figure anchor="can-now-trickle-unrelprov">
<figure title="A SIP UA sends an unreliable <name>A SIP UA sends an unreliable provisional response without an A
provisional response without an Answer for establishi nswer for establishing an early dialog</name>
ng an early dialog" <artwork name="" type="" align="left" alt=""><![CDATA[
anchor="can-now-trickle-unrelprov">
<artwork><![CDATA[
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|------------------------>| |------------------------>|
| | | |
| +----------------------+ | +----------------------+
skipping to change at line 818 skipping to change at line 776
| +----------------------+ | +----------------------+
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|<------------------------| |<------------------------|
| 183 (Answer) opt. | | 183 (Answer) opt. |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|<------------------------| |<------------------------|
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Note: SRFLX denotes server-reflexive candidates Note: "SRFLX" denotes server-reflexive candidates]]></artwork>
</figure>
]]></artwork> <t>
</figure> When sending the Answer, the agent <bcp14>MUST</bcp14> repeat all curren
</t> tly
<t>
When sending the Answer, the agent MUST repeat all currently
known and used candidates, if any, known and used candidates, if any,
and MAY include all newly gathered candidates since the last INFO reques and <bcp14>MAY</bcp14> include all newly gathered candidates since the l
t was sent. ast INFO request was sent.
However, if that Answer was already sent in a unreliable provisional res However, if that Answer was already sent in an unreliable provisional re
ponse, sponse,
the Answerers MUST repeat the Answerers <bcp14>MUST</bcp14> repeat
exactly the same Answer in the 200 OK response to the INVITE request exactly the same Answer in the 200 OK response to the INVITE request
in order to fulfill the corresponding requirements in in order to fulfill the corresponding requirements in
<xref target="RFC3264"/>. <xref target="RFC3264" format="default"/>.
In case that trickling continued, In case that trickling continued,
an Offerer needs to be prepared for receiving fewer candidates an Offerer needs to be prepared for receiving fewer candidates
in that repeated Answer than previously exchanged via trickling in that repeated Answer than previously exchanged via trickling
and MUST ignore the candidate information in that 200 OK response. and <bcp14>MUST</bcp14> ignore the candidate information in that 200 OK
</t> response.
</t>
</section> </section>
</section> </section>
<section title="Delivering Candidates in INFO Requests" anchor="info-sdp <section anchor="info-sdp" numbered="true" toc="default">
"> <name>Delivering Candidates in INFO Requests</name>
<t> <t>
Whenever new ICE candidates become available for sending, Whenever new ICE candidates become available for sending,
agents encode them in "a=candidate:" attributes as described agents encode them in "candidate" attributes as described
by <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. For example: by <xref target="RFC8839" format="default"/>. For example:
</t>
<t>
<figure>
<artwork>
<![CDATA[
a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host
]]>
</artwork>
</figure>
</t> </t>
<sourcecode type="sdp"><![CDATA[
a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host ]]></sourcecode>
<t> <t>
The use of SIP INFO requests happens within the context of the The use of SIP INFO requests happens within the context of the
Info Package as defined <xref target="info-package"/>. Info Package as defined in <xref target="info-package" format="default
"/>.
The Media Type The media type
<xref target="RFC6838"/> <xref target="RFC6838" format="default"/>
for their payload MUST be set to for their payload <bcp14>MUST</bcp14> be set to
'application/trickle-ice-sdpfrag' as defined in "application/trickle-ice-sdpfrag" as defined in
<xref target="trickle_ice_sdpfrag_def"/>. <xref target="trickle_ice_sdpfrag_def" format="default"/>.
The Info request body adheres to the grammar as specified in The INFO request body adheres to the grammar as specified in
<xref target="trickle_ice_sdpfrag_grammar"/>. <xref target="trickle_ice_sdpfrag_grammar" format="default"/>.
</t> </t>
<t> <t>
Since neither the "a=candidate:" nor the "a=end-of-candidates" Since neither the "candidate" nor the "end-of-candidates"
attributes contain information that would allow correlating them to attributes contain information that would allow correlating them to
a specific "m=" line, a specific "m=" line,
this is handled through the use of it is handled through the use of
pseudo "m=" lines. pseudo "m=" lines.
</t> </t>
<t> <t>
Pseudo "m=" lines follow the SDP syntax for "m=" lines as Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in defined in
<xref target="RFC4566"/> and are linked to the corresponding "m=" line <xref target="RFC4566" format="default"/> and are linked to the corres ponding "m=" line
in the SDP Offer or Answer via the identification tag in the SDP Offer or Answer via the identification tag
in a "a=mid:" attribute in a "mid" attribute
<xref target="RFC5888"/>. <xref target="RFC5888" format="default"/>.
A pseudo "m=" line does not provide semantics other A pseudo "m=" line does not provide semantics other
than indicating to which "m=" line a candidate belongs. than indicating to which "m=" line a candidate belongs.
Consequently, the receiving agent MUST ignore any remaining content of the pseudo "m=" line, Consequently, the receiving agent <bcp14>MUST</bcp14> ignore any remai ning content of the pseudo "m=" line,
which is not defined in this document. which is not defined in this document.
This guarantees that the 'application/trickle-ice-sdpfrag' bodies do This guarantees that the "application/trickle-ice-sdpfrag" bodies do
not interfere with the Offer/Answer not interfere with the Offer/Answer
procedures as specified in <xref target="RFC3264"/>. procedures as specified in <xref target="RFC3264" format="default"/>.
</t> </t>
<t> <t>
When sending the INFO request, the agent MAY, When sending the INFO request, the agent <bcp14>MAY</bcp14>,
if already known to the agent, include the same content into 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. the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer.
However, since Trickle-ICE might be decoupled from the Offer/Answer nego However, since Trickle ICE might be decoupled from the Offer/Answer nego
tiation this content might tiation, the content might
be unknown to the agent. In this case, the agent MUST include the follow be unknown to the agent. In this case, the agent <bcp14>MUST</bcp14> inc
ing default values. lude the following default values:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>
The media field is set to 'audio'. The media field is set to 'audio'.
</t> </li>
<t> <li>
The port value is set to '9'. The port value is set to '9'.
</t> </li>
<t> <li>
The proto value is set to 'RTP/AVP'. The proto value is set to 'RTP/AVP'.
</t> </li>
<t> <li>
The fmt field MUST appear only once and is set to '0' The fmt field <bcp14>MUST</bcp14> appear only once and is set to '
</t> 0'.
</list> </li>
</t> </ul>
<t> <t>
Agents MUST include a pseudo "m=" line and an Agents <bcp14>MUST</bcp14> include a pseudo "m=" line and an
identification tag in a "a=mid:" attribute for every "m=" line identification tag in a "mid" attribute for every "m=" line
whose candidate list they intend to update. whose candidate list they intend to update.
Such "a=mid:" attributes MUST Such "mid" attributes <bcp14>MUST</bcp14>
immediately precede the list of candidates for that specific immediately precede the list of candidates for that specific
"m=" line. "m=" line.
</t> </t>
<t> <t>
All "a=candidate:" or "a=end-of-candidates" attributes All "candidate" or "end-of-candidates" attributes
following an "a=mid:" attribute, up until (and excluding) the next following a "mid" attribute, up until (and excluding) the next
occurrence of a pseudo "m=" line, pertain to the "m=" line occurrence of a pseudo "m=" line, pertain to the "m=" line
identified by that identification tag. identified by that identification tag.
</t> </t>
<t> <t>
Note, that there is no requirement that the Info request body Note, that there is no requirement that the INFO request body
contains as many pseudo m= lines as the Offer/Answer contains as many pseudo "m=" lines as the Offer/Answer
contains m=lines, nor that the pseudo m= lines be in the same contains "m=" lines, nor that the pseudo "m=" lines be in the same
order as the m=lines that they pertain to. order as the "m=" lines that they pertain to.
The correspondence can be made via the "a=mid:" attributes The correspondence can be made via the "mid" attributes
since candidates are grouped in sections headed since candidates are grouped in sections headed
by "pseudo" m=lines. by "pseudo" "m=" lines.
These sections contain "a=mid:" attribute values which point These sections contain "mid" attribute values that point
back to the true m=line. back to the true "m=" line.
</t> </t>
<t> <t>
An "a=end-of-candidates" attribute, preceding An "end-of-candidates" attribute, preceding
the first pseudo "m=" line, indicates the end of all trickling the first pseudo "m=" line, indicates the end of all trickling
from that agent, from that agent,
as opposed to end of trickling for a specific "m=" line, as opposed to end of trickling for a specific "m=" line,
which would be indicated by a media level which would be indicated by a media-level
"a=end-of-candidates" attribute. "end-of-candidates" attribute.
</t> </t>
<t> <t>
Refer to Refer to
<xref target="INFOexample"/> <xref target="INFOexample" format="default"/>
for an example of the INFO request content. for an example of the INFO request content.
</t> </t>
<t> <t>
The use of pseudo "m=" lines allows for a structure similar to The use of pseudo "m=" lines allows for a structure similar to
the one in SDP Offers and Answers where the one in SDP Offers and Answers where
separate media-level and session-level sections can be distinguished. separate media-level and session-level sections can be distinguished.
In the current case, lines preceding the first In the current case, lines preceding the first
pseudo "m=" line are considered to be session-level. pseudo "m=" line are considered to be session level.
Lines appearing in between or after Lines appearing in between or after
pseudo "m=" lines will be interpreted as media-level. pseudo "m=" lines will be interpreted as media level.
</t> </t>
<t>
<list> <ul empty="true" spacing="normal">
<t> <li>
Note that while this specification uses the "a=mid:" Note that while this specification uses the "mid"
attribute from <xref target="RFC5888"/>, it does not attribute from <xref target="RFC5888" format="default"/>, it does
not
define any grouping semantics. define any grouping semantics.
</t> </li>
</list> </ul>
</t>
<t> <t>
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" All INFO requests <bcp14>MUST</bcp14> carry the "ice-pwd" and "ice-ufr ag"
attributes that allow mapping them to a specific ICE generation. attributes that allow mapping them to a specific ICE generation.
An agent MUST discard any received INFO requests containing "a=ice-pwd :" and "a=ice-ufrag:" An agent <bcp14>MUST</bcp14> discard any received INFO requests contai ning "ice-pwd" and "ice-ufrag"
attributes that do not match those of the current ICE Negotiation Sess ion. attributes that do not match those of the current ICE Negotiation Sess ion.
</t> </t>
<t> <t>
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level The "ice-pwd" and "ice-ufrag" attributes <bcp14>MUST</bcp14> appear at the same level
as the ones in the Offer/Answer exchange. as the ones in the Offer/Answer exchange.
In other words, if they were present In other words, if they were present
as session-level attributes, they will also appear as session-level attributes, they will also appear
at the beginning of all INFO request payloads, i.e. preceding at the beginning of all INFO request payloads, i.e., preceding
the first pseudo "m=" line. the first pseudo "m=" line.
If they were originally exchanged as media If they were originally exchanged as media-level
level attributes, potentially overriding session-level values, attributes, potentially overriding session-level values,
then they will also be included in INFO request payloads then they will also be included in INFO request payloads
following the corresponding pseudo "m=" lines. following the corresponding pseudo "m=" lines.
</t> </t>
<t> <t>
Note that <xref target="I-D.ietf-ice-trickle"/> requires that Note that
when candidates are trickled, each candidate must be delivered 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 to the receiving Trickle ICE implementation not more than once
and in the same order as it was conveyed. and in the same order as it was conveyed.
If the signaling protocol provides any candidate retransmissions, If the signaling protocol provides any candidate retransmissions,
they need to be hidden from the ICE implementation. they need to be hidden from the ICE implementation.
This requirement is fulfilled as follows. This requirement is fulfilled as follows.
</t> </t>
<t> <t>
Since the agent is not fully aware of the state of the ICE Negotiation Since the agent is not fully aware of the state of the ICE Negotiation
Session at its peer Session at its peer,
it MUST include all currently known and used local candidates in every it <bcp14>MUST</bcp14> include all currently known and used local cand
INFO request. idates in every INFO request.
I.e. the agent MUST repeat in the INFO request body That is, the agent <bcp14>MUST</bcp14> repeat in the INFO request body
all candidates that were previously sent under the same all candidates that were previously sent under the same
combination of "a=ice-pwd:" and "a=ice-ufrag:" combination of "ice-pwd" and "ice-ufrag"
in the same order as they were sent before. in the same order as they were sent before.
In other words, the sequence of a previously sent In other words, the sequence of a previously sent
list of candidates MUST NOT change in subsequent INFO requests list of candidates <bcp14>MUST NOT</bcp14> change in subsequent INFO r
and newly gathered candidates MUST be added equests,
and newly gathered candidates <bcp14>MUST</bcp14> be added
at the end of that list. at the end of that list.
Although repeating all candidates creates some overhead, it also allow s easier handling of problems Although repeating all candidates creates some overhead, it also allow s easier handling of problems
that could arise from unreliable transports, like e.g. loss of message s and reordering, that could arise from unreliable transports like, e.g., loss of messag es and reordering,
which can be detected through the CSeq: header field in the INFO reque st. which can be detected through the CSeq: header field in the INFO reque st.
</t> </t>
<t> <t>
In addition, an ICE agent needs to adhere to In addition, an ICE Agent needs to adhere to
section 17 of <xref target="I-D.ietf-ice-trickle"/> <xref target="RFC8838" sectionFormat="of" section="17"/>
on preserving candidate order while trickling. on preserving candidate order while trickling.
</t> </t>
<t> <t>
When receiving INFO requests carrying any candidates, agents When receiving INFO requests carrying any candidates, agents
MUST therefore first identify and discard the attribute lines <bcp14>MUST</bcp14> first identify and discard the attribute lines
containing candidates they have already received in previous containing candidates they have already received in previous
INFO requests or in the Offer/Answer exchange preceding them. INFO requests or in the Offer/Answer exchange preceding them.
</t> </t>
<t> Such candidates are considered to be equal if their IP address <t> Such candidates are considered to be equal if their IP address
port, transport and component ID are the same. port, transport, and component ID are the same.
After identifying and discarding the known candidates, After identifying and discarding the known candidates,
the agents MUST forward the actually new candidates to the ICE Agents the agents <bcp14>MUST</bcp14> forward the actual new candidates to th e ICE Agents
in the same order as they were received in the INFO request body. in the same order as they were received in the INFO request body.
The ICE Agents will then process the new candidates The ICE Agents will then process the new candidates
according to the rules described in <xref target="I-D.ietf-ice-trickle "/>. according to the rules described in <xref target="RFC8838" format="def ault"/>.
</t> </t>
<t> Receiving an "a=end-of-candidates" attribute in an INFO request body <t> Receiving an "end-of-candidates" attribute in an INFO request body
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current -- with the "ice-ufrag" and "ice-pwd" attributes matching the current IC
ICE generation - E generation --
is an indication from the peer agent that it will not send any further c andidates. is an indication from the peer agent that it will not send any further c andidates.
When included at session level, i.e. before any pseudo "m=" line, When included at the session level, i.e., before any pseudo "m=" line,
this indication applies to the whole session; this indication applies to the whole session;
when included at media level the indication applies when included at the media level, the indication applies
only to the corresponding "m=" line. only to the corresponding "m=" line.
Handling of such end-of-candidates indications is defined in Handling of such end-of-candidates indications is defined in
<xref target="I-D.ietf-ice-trickle"/>. <xref target="RFC8838" format="default"/>.
</t> </t>
<t> <t>
The example in <xref target="INFOexample"/> shows the content The example in <xref target="INFOexample" format="default"/> shows the
of a candidate delivering INFO request. In the example the content
"a=end-of-candidates" attributes indicate that of a candidate delivering INFO request. In the example, the
"end-of-candidates" attributes indicate that
the candidate gathering is finished and the candidate gathering is finished and
that no further INFO requests follow. that no further INFO requests follow.
</t> </t>
<t> <figure anchor="INFOexample">
<figure title="An Example for the Content of an INFO Request" <name>An Example for the Content of an INFO Request</name>
anchor="INFOexample">
<artwork>
<![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 <sourcecode><![CDATA[
a=ice-ufrag:8hhY INFO sip:alice@example.com SIP/2.0
m=audio 9 RTP/AVP 0 ...
a=mid:1 Info-Package: trickle-ice
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host Content-type: application/trickle-ice-sdpfrag
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host Content-Disposition: Info-Package
a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host Content-length: 862
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 there will be no line breaks a=ice-pwd:asd88fgpdd777uzjYhagZg
in the a=candidate: attributes a=ice-ufrag:8hhY
]]> m=audio 9 RTP/AVP 0
</artwork> a=mid:1
</figure> a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
</t> a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
</section> 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, there will be no line breaks
in the "candidate" attributes ]]></sourcecode>
</figure>
</section>
</section> </section>
<section title="Initial Discovery of Trickle ICE Support" anchor="disco"> <section anchor="disco" numbered="true" toc="default">
<t> <name>Initial Discovery of Trickle ICE Support</name>
SIP User Agents (UAs) that support and intend to use trickle <t>
ICE are required by SIP UAs are required by <xref target="RFC8838" format="default"/> to in
<xref target="I-D.ietf-ice-trickle"/> to indicate dicate their support of and intent to use Trickle ICE in their Offers and Answer
that in their Offers and Answers using the attribute s by using the "ice-options:trickle" attribute, and they <bcp14>MUST</bcp14> inc
"a=ice-options:trickle" lude the SIP option-tag "trickle-ice" in
and MUST include the SIP option-tag "trickle-ice" in
a SIP Supported: or Require: header field. a SIP Supported: or Require: header field.
This makes discovery This makes discovery
fairly straightforward for Answerers or for cases where fairly straightforward for Answerers or for cases where
Offers need to be generated within existing dialogs (i.e., Offers need to be generated within existing dialogs (i.e.,
when sending UPDATE or re-INVITE requests). when sending UPDATE or re-INVITE requests).
In both scenarios prior In both scenarios, prior
SDP bodies will have provided the necessary information. SDP bodies will have provided the necessary information.
</t> </t>
<t> <t>
Obviously, such information is not available at the time a first Obviously, such information is not available at the time a first
Offer is being constructed and it is therefore impossible Offer is being constructed, and it is therefore impossible
for ICE Agents to determine support for incremental for ICE Agents to determine support for incremental
provisioning that way. The following options are suggested as provisioning that way. The following options are suggested as
ways of addressing this issue. ways of addressing this issue.
</t> </t>
<section title="Provisioning Support for Trickle ICE" <section anchor="disco-prov" numbered="true" toc="default">
anchor="disco-prov"> <name>Provisioning Support for Trickle ICE</name>
<t> <t>
In certain situations it may be possible for integrators In certain situations, it may be possible for integrators
deploying Trickle ICE to know in advance that some or all deploying Trickle ICE to know in advance that some or all
endpoints reachable from within the deployment will support endpoints reachable from within the deployment will support
Trickle ICE. Trickle ICE.
This is the case, for example, if Session Border Controllers This is the case, for example, if Session Border Controllers
(SBC) with support for this specification are used (SBCs) with support for this specification are used
to connect to UAs that do not support Trickle ICE. to connect to UAs that do not support Trickle ICE.
</t> </t>
<t> <t>
While the exact mechanism for allowing such provisioning While the exact mechanism for allowing such provisioning
is out of scope here, this specification encourages trickle is out of scope here, this specification encourages trickle
ICE implementations to allow the option in the way they find ICE implementations to allow the option in the way they find
most appropriate. most appropriate.
</t> </t>
<t> <t>
However, an Offerer assuming Trickle ICE support MUST However, an Offerer assuming Trickle ICE support <bcp14>MUST</bcp14>
include a SIP Require: trickle-ice header field. include a SIP Require: trickle-ice header field.
That way, if the provisioned assumption of Trickle ICE support That way, if the provisioned assumption of Trickle ICE support
ends up being incorrect, the failure is (a) operationally ends up being incorrect, the failure is (a) operationally
easy to track down, and (b) recoverable by the client, easy to track down and (b) recoverable by the client,
i.e., they can re-send the request without the i.e., they can resend the request without the
SIP Require: header field and without SIP Require: header field and without
the assumption of Trickle ICE support. the assumption of Trickle ICE support.
</t> </t>
</section> </section>
<section title="Trickle ICE Discovery with Globally Routable User Agent <section anchor="disco-gruu" numbered="true" toc="default">
URIs (GRUU)" <name>Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU
anchor="disco-gruu"> s)</name>
<t> <t>
<xref target="RFC3840"/> provides a way for SIP User Agents <xref target="RFC3840" format="default"/> provides a way for SIP UAs
to query for support of specific capabilities using, among to query for support of specific capabilities using, among
others, OPTIONS requests. Support for others, OPTIONS requests. On the other hand, support for
GRUU according to GRUU according to
<xref target="RFC5627"/> on the other hand <xref target="RFC5627" format="default"/>
allows SIP requests to be addressed to specific UAs (as allows SIP requests to be addressed to specific UAs (as
opposed to arbitrary instances of an address of record). opposed to arbitrary instances of an address of record).
Combining the two and using the "trickle-ice" option tag Combining the two and using the "trickle-ice" option tag
defined in <xref target="option-tag"/> provides SIP UAs with defined in <xref target="option-tag" format="default"/> provides SIP UAs with
a way of learning the capabilities of specific SIP UA instances a way of learning the capabilities of specific SIP UA instances
and then addressing them directly with INVITE requests that and then addressing them directly with INVITE requests that
require Trickle ICE support. require Trickle ICE support.
</t> </t>
<t> <t>
Such learning of capabilities may happen in different ways. Such learning of capabilities may happen in different ways.
One option for a SIP UA is to learn the One option for a SIP UA is to learn the
GRUU instance ID of a peer through presence and then to query GRUU instance ID of a peer through presence and then to query
its capabilities with an OPTIONS request. its capabilities with an OPTIONS request.
Alternatively, it can also just send an OPTIONS request to Alternatively, it can also just send an OPTIONS request to
the Address of Record (AOR) it intends to contact and then inspect t he returned the Address of Record (AOR) it intends to contact and then inspect t he returned
response(s) for support of both GRUU and Trickle ICE response(s) for support of both GRUU and Trickle ICE
(<xref target="options-gruu"/>). (<xref target="options-gruu" format="default"/>).
It is noted that using the GRUU means that the INVITE request It is noted that using the GRUU means that the INVITE request
can go only to that particular device. can go only to that particular device.
This prevents the use of forking for that request. This prevents the use of forking for that request.
</t> </t>
<t> <figure anchor="options-gruu">
<figure title="Trickle ICE support discovery with OPTIONS and <name>Trickle ICE Support Discovery with OPTIONS and GRUU</name>
GRUU" <artwork name="" type="" align="left" alt=""><![CDATA[
anchor="options-gruu">
<artwork><![CDATA[
Alice Bob Alice Bob
| | | |
| OPTIONS sip:b1@example.com SIP/2.0 | | OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 200 OK | | 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a | | Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... | | ;audio;video|;trickle-ice;... |
|<--------------------------------------------------| |<--------------------------------------------------|
| | | |
skipping to change at line 1196 skipping to change at line 1132
| Supported: trickle-ice | | Supported: trickle-ice |
| (Offer) | | (Offer) |
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 183 (Answer) | | 183 (Answer) |
|<--------------------------------------------------| |<--------------------------------------------------|
| INFO/OK (Trickling) | | INFO/OK (Trickling) |
|<------------------------------------------------->| |<------------------------------------------------->|
| | | |
| ... | | ... |
| | | |]]></artwork>
</figure>
]]></artwork> <t>
</figure>
</t>
<t>
Confirming support for Trickle ICE through Confirming support for Trickle ICE through
<xref target="RFC3840"/> gives SIP UAs the options to engage <xref target="RFC3840" format="default"/> gives SIP UAs the option t o engage
in Full Trickle negotiation (as opposed to the more lengthy in Full Trickle negotiation (as opposed to the more lengthy
Half Trickle) from the very first Offer they send. Half Trickle) from the very first Offer they send.
</t> </t>
</section> </section>
<section title="Fall-back to Half Trickle" <section anchor="half-full-trickle" numbered="true" toc="default">
anchor="half-full-trickle"> <name>Fall Back to Half Trickle</name>
<t> <t>
In cases where none of the other mechanisms in this section In cases where none of the other mechanisms in this section
are acceptable, SIP UAs should use the Half Trickle mode are acceptable, SIP UAs should use the Half Trickle mode
defined in <xref target="I-D.ietf-ice-trickle"/>. defined in <xref target="RFC8838" format="default"/>.
With Half Trickle, agents initiate sessions the same way With Half Trickle, agents initiate sessions the same way
they would when using ICE for SIP they would when using ICE for SIP
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/>. <xref target="RFC8839" format="default"/>.
This means that, prior to actually sending an Offer, agents This means that, prior to actually sending an Offer, agents
first gather ICE candidates in a blocking way and then first gather ICE candidates in a blocking way and then
send them all in that Offer. The blocking nature of the send them all in that Offer. The blocking nature of the
process implies that some amount of latency will process implies that some amount of latency will
be accumulated and it is advised that agents try to be accumulated, and it is advised that agents try to
anticipate it where possible, for example, when user anticipate it where possible, for example, when user
actions indicate a high likelihood for an imminent call actions indicate a high likelihood for an imminent call
(e.g., activity on a keypad or a phone going off-hook). (e.g., activity on a keypad or a phone going off hook).
</t> </t>
<t> <t>
Using Half Trickle results in Offers that are Using Half Trickle results in Offers that are
compatible with both ICE SIP endpoints and legacy compatible with both ICE SIP endpoints <xref target="RFC8839" format
<xref target="RFC3264"/> endpoints. ="default"/> and legacy
</t> endpoints <xref target="RFC3264" format="default"/>.
<t> </t>
<figure title="Example - A typical (Half) Trickle ICE exchange with <figure anchor="fig-half-trickle">
SIP " anchor="fig-half-trickle"> <name>Example of a Typical (Half) Trickle ICE Exchange with SIP</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![CDATA[ STUN/TURN STUN/TURN
STUN/Turn STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
| | | | | | | |
| Candidate | | | | Candidate | | |
| | | | | | | |
| | | | | | | |
| Discovery | | | | Discovery | | |
| | | | | | | |
skipping to change at line 1267 skipping to change at line 1199
| |<===========================>| Discovery | | |<===========================>| Discovery |
| | INFO (more candidates) | | | | INFO (more candidates) | |
| |<----------------------------| | | |<----------------------------| |
| | Connectivity Checks |<--------------| | | Connectivity Checks |<--------------|
| |<===========================>| | | |<===========================>| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| |<----------------------------| | | |<----------------------------| |
| | | | | | | |
| |<======= MEDIA FLOWS =======>| | | |<======= MEDIA FLOWS =======>| |
| | | | | | | | ]]></artwork>
]]> </figure>
</artwork>
</figure>
</t>
<t> <t>
It is worth reminding that once a single Offer or Answer had
As a reminder, once a single Offer or Answer has
been exchanged within a specific dialog, support for been exchanged within a specific dialog, support for
Trickle ICE will have been determined. Trickle ICE will have been determined.
No further use of Half Trickle will therefore be necessary No further use of Half Trickle will therefore be necessary
within that same dialog within that same dialog,
and all subsequent exchanges can use the Full Trickle mode and all subsequent exchanges can use the Full Trickle mode
of operation. of operation.
</t> </t>
</section> </section>
</section> </section>
<section title="Considerations for RTP and RTCP Multiplexing" anchor="rtcp-c <section anchor="rtcp-cons" numbered="true" toc="default">
ons"> <name>Considerations for RTP and RTCP Multiplexing</name>
<t> <t>
The following consideration describe options for Trickle-ICE The following consideration describes options for Trickle ICE
in order to give some guidance to implementors on how trickling in order to give some guidance to implementers on how trickling
can be optimized with respect to providing RTCP candidates. can be optimized with respect to providing RTCP candidates.
</t> </t>
<t> <t>
Handling of the "a=rtcp" attribute <xref target="RFC3605"/> Handling of the "rtcp" attribute <xref target="RFC3605" format="default"
and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing <xref target="R />
FC5761"/> and the "rtcp-mux" attribute for RTP/RTCP multiplexing <xref target="RFC
is already considered in section 5.1.1.1. 5761" format="default"/>
of <xref target="I-D.ietf-ice-rfc5245bis"/> and is already considered in
as well in <xref target="RFC5761"/> itself. <xref target="RFC8445" sectionFormat="of" section="5.1.1.1"/> and
These considerations are still valid for Trickle ICE, however, in <xref target="RFC5761" format="default"/>.
These considerations are still valid for Trickle ICE; however,
trickling provides more flexibility for the sequence of candidate exchan ge in case of RTCP multiplexing. trickling provides more flexibility for the sequence of candidate exchan ge in case of RTCP multiplexing.
</t> </t>
<t> <t>
[RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct for version 1
7 of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in th
e meantime.]
</t>
<t>
If the Offerer supports RTP/RTCP multiplexing exclusively as specified If the Offerer supports RTP/RTCP multiplexing exclusively as specified
in <xref target="I-D.ietf-mmusic-mux-exclusive"/>, in <xref target="RFC8858" format="default"/>,
the procedures in that document apply for the handling of the "a=rtcp-mu the procedures in that document apply for the handling of the "rtcp-mux-
x-only", "a=rtcp" and the "a=rtcp-mux" attributes. only", "rtcp", and "rtcp-mux" attributes.
</t> </t>
<t> <t>
While a Half Trickle Offerer has to send an Offer compliant to While a Half Trickle Offerer has to send an Offer compliant to
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/> and <xref target="RFC5761"/ <xref target="RFC8839" format="default"/> and <xref target="RFC5761" for
> including candidates for all components, mat="default"/> including candidates for all components, the flexibility of a Fu
the flexibility of a Full Trickle Offerer allows ll Trickle Offerer allows
to send only RTP candidates (component 1) in the initial Offer the sending of only RTP candidates (component 1) in the initial Offer
assuming that RTCP multiplexing is supported by the Answerer. assuming that RTCP multiplexing is supported by the Answerer.
A Full Trickle Offerer would need to start gathering and trickling A Full Trickle Offerer would need to start gathering and trickling
RTCP candidates (component 2) RTCP candidates (component 2)
only after having received an indication in the Answer that only after having received an indication in the Answer that
the Answerer unexpectedly does not support RTCP multiplexing. the Answerer unexpectedly does not support RTCP multiplexing.
</t> </t>
<t> <t>
A Trickle Answerer MAY include an "a=rtcp-mux" attribute A Trickle Answerer <bcp14>MAY</bcp14> include an "rtcp-mux" attribute
<xref target="RFC5761"/> in the application/trickle-ice-sdpfrag body <xref target="RFC5761" format="default"/> in the "application/trickle-ic
e-sdpfrag" body
if it supports and uses RTP and RTCP multiplexing. if it supports and uses RTP and RTCP multiplexing.
The Trickle Answerer needs to follow the guidance on the usage of the "a The Trickle Answerer needs to follow the guidance on the usage of the "r
=rtcp" attribute as given in tcp" attribute as given in
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/> and <xref target="RFC8839" format="default"/> and
<xref target="RFC3605"/>. <xref target="RFC3605" format="default"/>.
Receipt of this attribute at the Offerer in an INFO request prior to the Answer 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. indicates that the Answerer supports and uses RTP and RTCP multiplexing.
The Offerer can use this information e.g. for stopping gathering of RTCP candidates The Offerer can use this information, e.g., for stopping the gathering o f RTCP candidates
and/or for freeing corresponding resources. and/or for freeing corresponding resources.
</t> </t>
<t> <t>
This behavior is illustrated by the following example Offer that indicat es support for RTP and RTCP multiplexing. This behavior is illustrated by the following example Offer that indicat es support for RTP and RTCP multiplexing.
</t> </t>
<t>
<figure> <sourcecode type="sdp"><![CDATA[
<artwork> v=0
<![CDATA[ o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
v=0 s=
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com c=IN IP6 2001:db8:a0b:12f0::3
s= t=0 0
c=IN IP6 2001:db8:a0b:12f0::3 a=ice-pwd:777uzjYhagZgasd88fgpdd
t=0 0 a=ice-ufrag:Yhh8
a=ice-pwd:777uzjYhagZgasd88fgpdd m=audio 5000 RTP/AVP 0
a=ice-ufrag:Yhh8 a=mid:1
m=audio 5000 RTP/AVP 0 a=rtcp-mux
a=mid:1 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host]]></sourceco
a=rtcp-mux de>
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host <t>
]]> Once the dialog is established as described in <xref target="dialog-est"
</artwork> format="default"/>, the Answerer
</figure>
</t>
<t>
Once the dialog is established as described in section <xref target="dia
log-est"/> the Answerer
sends the following INFO request. sends the following INFO request.
</t> </t>
<t>
<figure>
<artwork>
<![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 <sourcecode><![CDATA[
a=ice-ufrag:8hhY INFO sip:alice@example.com SIP/2.0
m=audio 9 RTP/AVP 0 ...
a=mid:1 Info-Package: trickle-ice
a=rtcp-mux Content-type: application/trickle-ice-sdpfrag
a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host Content-Disposition: Info-Package
]]> Content-length: 161
</artwork>
</figure> a=ice-pwd:asd88fgpdd777uzjYhagZg
</t> a=ice-ufrag:8hhY
<t> 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 ]]></sourcec
ode>
<t>
This INFO request indicates that the Answerer supports and uses This INFO request indicates that the Answerer supports and uses
RTP and RTCP multiplexing as well. RTP and RTCP multiplexing as well.
It allows the Offerer to omit gathering of RTCP candidates or It allows the Offerer to omit gathering RTCP candidates or
releasing already gathered RTCP candidates. releasing already gathered RTCP candidates.
If the INFO request did not contain the a=rtcp-mux attribute, If the INFO request did not contain the "rtcp-mux" attribute,
the Offerer has to gather RTCP candidates the Offerer has to gather RTCP candidates
unless it wants to wait until receipt of an Answer that eventually confi rms unless it wants to wait until receipt of an Answer that eventually confi rms
support or non-support for RTP and RTCP multiplexing. support or non-support for RTP and RTCP multiplexing.
In case the Offerer had sent RTCP candidates in a previous INFO request, In case the Offerer already sent RTCP candidates in a previous INFO requ est,
it still needs to repeat them in subsequent INFO requests, it still needs to repeat them in subsequent INFO requests,
even in case that support for RTCP multiplexing was confirmed even when that support for RTCP multiplexing was confirmed
by the Answerer and the Offerer has released its RTCP candidates. by the Answerer and the Offerer has released its RTCP candidates.
</t> </t>
</section>
</section> <section anchor="bundle-cons" numbered="true" toc="default">
<section title="Considerations for Media Multiplexing" anchor="bundle-cons"> <name>Considerations for Media Multiplexing</name>
<t> <t>
The following considerations describe options for Trickle-ICE The following considerations describe options for Trickle ICE
in order to give some guidance to implementors on how trickling in order to give some guidance to implementers on how trickling
can be optimized with respect to providing candidates in case of Media M ultiplexing can be optimized with respect to providing candidates in case of Media M ultiplexing
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. <xref target="RFC8843" format="default"/>.
It is assumed that the reader is familiar with <xref target="I-D.ietf-mm It is assumed that the reader is familiar with <xref target="RFC8843" fo
usic-sdp-bundle-negotiation"/>. rmat="default"/>.
</t> </t>
<t> <t>
ICE candidate exchange is already considered ICE candidate exchange is already considered in
in section 11 of <xref target="RFC8843" sectionFormat="of" section="10"/>.
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. These considerations are still valid for Trickle ICE; however,
These considerations are still valid for Trickle ICE, however,
trickling provides more flexibility for the sequence of candidate exchan ge, trickling provides more flexibility for the sequence of candidate exchan ge,
especially in Full Trickle mode. especially in Full Trickle mode.
</t> </t>
<t> <t>
Except for bundle-only "m=" lines, a Half Trickle Offerer has to Except for bundle-only "m=" lines, a Half Trickle Offerer has to
send an Offer with candidates for all bundled "m=" lines. send an Offer with candidates for all bundled "m=" lines.
The additional flexibility, however, allows a Full Trickle Offerer The additional flexibility, however, allows a Full Trickle Offerer
to initially send only candidates for the "m=" line with the to initially send only candidates for the "m=" line with the
suggested Offerer BUNDLE address. suggested Offerer BUNDLE address.
</t> </t>
<t> <t>
On receipt of the Answer, the Offerer will detect On receipt of the Answer, the Offerer will detect
if BUNDLE is supported by the Answerer and if the suggested Offerer BUND LE address was selected. if BUNDLE is supported by the Answerer and if the suggested Offerer BUND LE address was selected.
In this case, the Offerer does not need to trickle further candidates fo r the remaining "m=" lines in a bundle. In this case, the Offerer does not need to trickle further candidates fo r the remaining "m=" lines in a bundle.
However, if BUNDLE is not supported, the Full Trickle Offerer needs to g ather and trickle candidates However, if BUNDLE is not supported, the Full Trickle Offerer needs to g ather and trickle candidates
for the remaining "m=" lines as necessary. for the remaining "m=" lines as necessary.
If the Answerer selects an Offerer BUNDLE address different from the sug gested Offerer BUNDLE address, 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 the Full Trickle Offerer needs to gather and trickle candidates
for the "m=" line that carries the selected Offerer BUNDLE address. for the "m=" line that carries the selected Offerer BUNDLE address.
</t> </t>
<t> <t>
A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute A Trickle Answerer <bcp14>SHOULD</bcp14> include a "group:BUNDLE" attrib
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> ute
at session level in the application/trickle-ice-sdpfrag body <xref target="RFC8843" format="default"/>
at session level in the "application/trickle-ice-sdpfrag" body
if it supports and uses bundling. if it supports and uses bundling.
When doing so, the Answerer MUST include all identification-tags in the When doing so, the Answerer <bcp14>MUST</bcp14> include all identificati
same order that is used or will be used in the Answer. on-tags in the same order that is used or will be used in the Answer.
</t> </t>
<t> <t>
Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer
supports and uses bundling. supports and uses bundling.
The Offerer can use this information e.g. for stopping the gathering of candidates The Offerer can use this information, e.g., for stopping the gathering o f candidates
for the remaining "m=" lines in a bundle and/or for freeing correspondin g resources. for the remaining "m=" lines in a bundle and/or for freeing correspondin g resources.
</t> </t>
<t> <t>
This behaviour is illustrated by the following example Offer that indica This behavior is illustrated by the following example Offer that indicat
tes support for Media Multiplexing. es support for Media Multiplexing.
</t> </t>
<t> <t>
In case the Offerer had sent already candidates for "m="-lines If the Offerer already sent candidates for "m=" lines
in a bundle in a previous INFO request, in a bundle in a previous INFO request,
it still needs to repeat them in subsequent INFO requests, it still needs to repeat them in subsequent INFO requests,
even in case that support for bundling was confirmed even when that support for bundling was confirmed
by the Answerer and the Offerer has released no longer needed candidates by the Answerer and the Offerer has released candidates that are no long
. er needed.
</t> </t>
<t>
<figure> <sourcecode type="sdp"><![CDATA[
<artwork> v=0
<![CDATA[ o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
v=0 s=
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com c=IN IP6 2001:db8:a0b:12f0::3
s= t=0 0
c=IN IP6 2001:db8:a0b:12f0::3 a=group:BUNDLE foo bar
t=0 0 a=ice-pwd:777uzjYhagZgasd88fgpdd
a=group:BUNDLE foo bar a=ice-ufrag:Yhh8
a=ice-pwd:777uzjYhagZgasd88fgpdd m=audio 10000 RTP/AVP 0
a=ice-ufrag:Yhh8 a=mid:foo
m=audio 10000 RTP/AVP 0 a=rtcp-mux
a=mid:foo a=rtpmap:0 PCMU/8000
a=rtcp-mux a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host a=mid:bar
m=video 10002 RTP/AVP 31 a=rtcp-mux
a=mid:bar a=rtpmap:31 H261/90000
a=rtcp-mux a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid]]></sourcecode>
a=rtpmap:31 H261/90000 <t>
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid]]>
</artwork>
</figure>
</t>
<t>
The example Offer indicates support for RTP and RTCP multiplexing The example Offer indicates support for RTP and RTCP multiplexing
and contains a "a=candidate:" attribute only for the "m="-line and contains a "candidate" attribute only for the "m=" line
with the suggested Offerer bundle address. with the suggested Offerer BUNDLE address.
Once the dialog is established as described in <xref target="dialog-est Once the dialog is established as described in <xref target="dialog-est
"/> the Answerer " format="default"/>, the Answerer
sends the following INFO request. sends the following INFO request.
</t> </t>
<t>
<figure>
<artwork>
<![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 <sourcecode><![CDATA[
a=ice-pwd:asd88fgpdd777uzjYhagZg INFO sip:alice@example.com SIP/2.0
a=ice-ufrag:8hhY ...
m=audio 9 RTP/AVP 0 Info-Package: trickle-ice
a=mid:foo Content-type: application/trickle-ice-sdpfrag
a=rtcp-mux Content-Disposition: Info-Package
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host Content-length: 219
]]> a=group:BUNDLE foo bar
</artwork> a=ice-pwd:asd88fgpdd777uzjYhagZg
</figure> a=ice-ufrag:8hhY
</t> m=audio 9 RTP/AVP 0
<t> a=mid:foo
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host ]]></source
code>
<t>
This INFO request indicates that the Answerer supports and uses Media Mu ltiplexing as well. This INFO request indicates that the Answerer supports and uses Media Mu ltiplexing as well.
Note that the Answerer only includes a single pseudo "m="-line since can Note that the Answerer only includes a single pseudo "m=" line since can
didates didates
matching those from the second "m="-line in the offer are not needed fr matching those from the second "m=" line in the offer are not needed fr
om the Answerer. om the Answerer.
</t> </t>
<t> <t>
The INFO request also indicates that the Answerer accepted the suggested The INFO request also indicates that the Answerer accepted the suggested
Offerer Bundle Address. Offerer BUNDLE address.
This allows the Offerer to omit gathering of RTP and RTCP candidates for This allows the Offerer to omit gathering RTP and RTCP candidates for th
the other "m=" lines e other "m=" lines
or releasing already gathered candidates. or releasing already gathered candidates.
If the INFO request did not contain the a=group:BUNDLE attribute, the Of If the INFO request did not contain the "group:BUNDLE" attribute, the Of
ferer has to gather ferer has to gather
RTP and RTCP candidates for the other "m=" lines unless it wants to wa it until receipt RTP and RTCP candidates for the other "m=" lines unless it wants to wa it until receipt
of an Answer that eventually confirms of an Answer that eventually confirms
support or non-support for Media Multiplexing. support or non-support for Media Multiplexing.
</t> </t>
<t> <t>
Independent of using Full Trickle or Half Trickle mode, the rules from Independent of using Full Trickle or Half Trickle mode, the rules from
<xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> apply to both, Offe rer and Answerer, <xref target="RFC8859" format="default"/> apply to both, Offerer and An swerer,
when putting attributes as specified in when putting attributes as specified in
<xref target="trickle_ice_sdpfrag_grammar"/> <xref target="trickle_ice_sdpfrag_grammar" format="default"/>
in the application/trickle-ice-sdpfrag body. in the "application/trickle-ice-sdpfrag" body.
</t>
</section>
<section anchor="sec-eoc" toc="default" numbered="true">
<name>SDP "end-of-candidates" Attribute</name>
<section anchor="eoc-def" numbered="true" toc="default">
<name>Definition</name>
<t>
This section defines the new SDP media-level and session-level
<xref target="RFC4566" format="default"/>
"end-of-candidates" attribute. "end-of-candidates" is a property attribute
<xref target="RFC4566" format="default"/>; hence, it has no value.
By including this attribute in an Offer or Answer, the sending agent indic
ates
that it will not trickle further candidates.
When included at the session level, this indication applies to the whole s
ession;
when included at the media level, the indication applies only to the corre
sponding media description.
</t> </t>
</section> <ul empty="true">
<li>
<dl spacing="normal">
<dt>Name:</dt><dd>end-of-candidates</dd>
<section anchor="sec-eoc" title="SDP 'end-of-candidates' Attribute" toc="defa <dt>Value:</dt><dd>N/A</dd>
ult">
<section title="Definition" anchor="eoc-def">
<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' is a property attribute
<xref target="RFC4566" pageno="false" format="default"/>, and hence has no
value.
By including this attribute in an Offer or Answer the sending agent indica
tes
that it will not trickle further candidates.
When included at session level this indication applies to the whole sessio
n,
when included at media level the indication applies only to the correspond
ing media description.
</t> <dt>Usage Level:</dt><dd>media and session level</dd>
<t> <dt>Charset Dependent:</dt><dd>no</dd>
<list style="none">
<t>
Name: end-of-candidates
</t>
<t>
Value: N/A
</t>
<t>
Usage Level: media and session-level
</t>
<t>
Charset Dependent: no
</t>
<t>
Mux Category: IDENTICAL
</t>
<t>
Example: a=end-of-candidates
</t>
</list>
</t>
</section> <dt>Mux Category:</dt><dd>IDENTICAL</dd>
<section title="Offer/Answer Procedures" anchor="eoc-ind">
<t>The Offerer or Answerer MAY include an "a=end-of-candidates" attrib <dt>Example:</dt>
ute <dd>a=end-of-candidates</dd>
</dl>
</li>
</ul>
</section>
<section anchor="eoc-ind" numbered="true" toc="default">
<name>Offer/Answer Procedures</name>
<t>The Offerer or Answerer <bcp14>MAY</bcp14> include an "end-of-candida
tes" attribute
in case candidate discovery has ended in case candidate discovery has ended
and no further candidates are to be trickled. and no further candidates are to be trickled.
The Offerer or Answerer MUST provide the "a=end-of-candidates" attribu The Offerer or Answerer <bcp14>MUST</bcp14> provide the "end-of-candid
te ates" attribute
together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the curr together with the "ice-ufrag" and "ice-pwd" attributes of the current
ent
ICE generation as required by ICE generation as required by
<xref target="I-D.ietf-ice-trickle"/>. <xref target="RFC8838" format="default"/>.
When included at session level When included at the session level,
this indication applies to the whole session; this indication applies to the whole session;
when included at media level the indication applies when included at the media level, the indication applies
only to the corresponding media description. only to the corresponding media description.
</t> </t>
<t> <t>
Receipt of an "a=end-of-candidates" attribute at an Receipt of an "end-of-candidates" attribute at an
Offerer or Answerer Offerer or Answerer
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the curre -- with the "ice-ufrag" and "ice-pwd" attributes matching the current
nt ICE generation - ICE generation --
indicates that gathering of candidates indicates that the gathering of candidates
has ended at the peer, either for the session or only for the has ended at the peer, for either the session or only the
corresponding media description as specified above. corresponding media description as specified above.
The receiving agent forwards an end-of-candidates indication The receiving agent forwards an end-of-candidates indication
to the ICE Agent, which in turn acts as specified in to the ICE Agent, which in turn acts as specified in
<xref target="I-D.ietf-ice-trickle"/>. <xref target="RFC8838" format="default"/>.
</t> </t>
</section>
</section> </section>
</section>
<section title="Content Type 'application/trickle-ice-sdpfrag'" anchor="tric <section anchor="trickle_ice_sdpfrag_def" numbered="true" toc="default">
kle_ice_sdpfrag_def"> <name>Content Type "application/trickle-ice-sdpfrag"</name>
<section numbered="true" toc="default">
<section title="Overall Description"> <name>Overall Description</name>
<t> <t>
A application/trickle-ice-sdpfrag body is used exclusively by the 'trick An "application/trickle-ice-sdpfrag" body is used exclusively by the "tr
le-ice' Info Package. ickle-ice" Info Package.
Other SDP related applications need to define their own media type. Other SDP-related applications need to define their own media type.
The INFO request body uses a subset of the possible SDP lines The INFO request body uses a subset of the possible SDP lines
as defined by the grammar defined in <xref target="RFC4566"/>. as defined by the grammar in <xref target="RFC4566" format="default"/>.
A valid body uses only pseudo "m=" lines and certain attributes A valid body uses only pseudo "m=" lines and certain attributes
that are needed and/or useful for trickling candidates. that are needed and/or useful for trickling candidates.
The content adheres to the following grammar. The content adheres to the following grammar.
</t> </t>
</section> </section>
<section anchor="trickle_ice_sdpfrag_grammar" numbered="true" toc="default
<section title="Grammar" anchor="trickle_ice_sdpfrag_grammar"> ">
<name>Grammar</name>
<t> <t>
The grammar of an 'application/trickle-ice-sdpfrag' body is The grammar of an "application/trickle-ice-sdpfrag" body is
based on the following ABNF <xref target="RFC5234"/>. based on the following ABNF <xref target="RFC5234" format="default"/>
It specifies the subset of existing SDP attributes, .
It specifies the subset of existing SDP attributes
that is needed or useful for trickling candidates. that is needed or useful for trickling candidates.
The grammar uses the indicator for case-sensitivity %s The grammar uses the indicator for case-sensitive %s,
as defined in <xref target="RFC7405"/>, as defined in <xref target="RFC7405" format="default"/>,
but also imports grammars for other SDP attributes that but it also imports grammar for other SDP attributes that
precede the production of <xref target="RFC7405"/>. precede the production of <xref target="RFC7405" format="default"/>.
A sender SHOULD use lower-case for attributes A sender <bcp14>SHOULD</bcp14> use lower case for attributes
from such earlier grammars, but a receiver MUST treat from such earlier grammar, but a receiver <bcp14>MUST</bcp14> treat
them case-insensitively. them as case insensitive.
</t> </t>
<sourcecode type="abnf"><![CDATA[
<t> ; Syntax
<figure><artwork align="left"> trickle-ice-sdpfrag = session-level-fields
; Syntax pseudo-media-descriptions
trickle-ice-sdpfrag = session-level-fields session-level-fields = *(session-level-field CRLF)
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 session-level-field = ice-lite-attribute /
ice-pwd-attribute = %s"a" "=" ice-pwd-att ice-pwd-attribute /
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att ice-ufrag-attribute /
ice-pacing-attribute = %s"a" "=" ice-pacing-att ice-options-attribute /
ice-options-attribute = %s"a" "=" ice-options ice-pacing-attribute /
end-of-candidates-attribute = %s"a" "=" end-of-candidates end-of-candidates-attribute /
end-of-candidates = %s"end-of-candidates" bundle-group-attribute /
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics extension-attribute-fields
*(SP identification-tag) ; for future extensions
bundle-semantics = "BUNDLE"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field ice-lite-attribute = %s"a" "=" ice-lite
trickle-ice-attribute-fields ) ice-pwd-attribute = %s"a" "=" ice-pwd-att
trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF) ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
trickle-ice-attribute-field = mid-attribute / ice-pacing-attribute = %s"a" "=" ice-pacing-att
candidate-attributes / ice-options-attribute = %s"a" "=" ice-options
ice-pwd-attribute / end-of-candidates-attribute = %s"a" "=" end-of-candidates
ice-ufrag-attribute / end-of-candidates = %s"end-of-candidates"
remote-candidate-attribute / bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
end-of-candidates-attribute / *(SP identification-tag)
rtcp-attribute / bundle-semantics = "BUNDLE"
rtcp-mux-attribute / extension-attribute-fields = attribute-fields
rtcp-mux-only-attribute /
extension-attribute-fields
; for future extensions
rtcp-attribute = %s"a" "=" %s"rtcp" pseudo-media-descriptions = *( media-field
rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux" trickle-ice-attribute-fields )
rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only" trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
candidate-attributes = %s"a" "=" candidate-attribute trickle-ice-attribute-field = mid-attribute /
remote-candidate-attribute = %s"a" "=" remote-candidate-att 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
</artwork></figure> rtcp-attribute = %s"a" "=" %s"rtcp"
</t> rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux"
<t> rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only"
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, candidate-attributes = %s"a" "=" candidate-attribute
ice-pacing-att, ice-options, candidate-attribute remote-candidate-att remote-candidate-attribute = %s"a" "=" remote-candidate-att ]]></sourcecod
from <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>, e>
identification-tag, mid-attribute ; from <xref target="RFC5888"/>, <t>
media-field, attribute-fields from <xref target="RFC4566"/>. ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att,
The "a=rtcp" attribute is defined in <xref target="RFC3605"/>, ice-options, candidate-attribute, and remote-candidate-att are from <xref
the "a=rtcp-mux" attribute in <xref target="RFC5761"/> and target="RFC8839"/>; identification-tag and mid-attribute are from <xref
the "a=rtcp-mux-only" attribute in <xref target="I-D.ietf-mmusic-mux-ex target="RFC5888"/>; and media-field and attribute-fields are from <xref
clusive"/>. target="RFC4566"/>. The "rtcp" attribute is defined in <xref
The latter attributes lack a formal grammar in their corresponding RFC target="RFC3605" format="default"/>, the "rtcp-mux" attribute is defined
and are reproduced here. in <xref target="RFC5761" format="default"/>, and the "rtcp-mux-only"
</t> attribute is defined in <xref target="RFC8858" format="default"/>. The
<t> latter attributes lack formal grammar in their corresponding RFCs and are
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the reproduced here.
</t>
<t>
The "ice-pwd" and "ice-ufrag" attributes <bcp14>MUST</bcp14> appear at
the
same level as the ones in the Offer/Answer exchange. In other words, same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes, they will also if they were present as session-level attributes, they will also
appear at the beginning of all INFO request payloads, i.e. preceding appear at the beginning of all INFO request payloads, i.e., preceding
all pseudo "m=" lines. If they were originally exchanged as media all pseudo "m=" lines. If they were originally exchanged as media-lev
level attributes, potentially overriding session-level values, then el
attributes, potentially overriding session-level values, then
they will also be included in INFO request payloads following the they will also be included in INFO request payloads following the
corresponding pseudo "m=" lines. corresponding pseudo "m=" lines.
</t> </t>
<t> <t>
An Agent MUST ignore any received unknown extension-attribute-fields. An Agent <bcp14>MUST</bcp14> ignore any received unknown extension-attr
</t> ibute-fields.
</section> </t>
</section>
</section> </section>
<section anchor="info-package" numbered="true" toc="default">
<section title="Info Package" anchor="info-package"> <name>Info Package</name>
<section title="Rationale - Why INFO?" anchor="rationale"> <section anchor="rationale" numbered="true" toc="default">
<name>Rationale -- Why INFO?</name>
<t> <t>
The decision to use SIP INFO requests as a candidate transport The decision to use SIP INFO requests as a candidate transport
method is based primarily on their lightweight nature. Once a method is based primarily on their lightweight nature. Once a
dialog has been established, INFO requests can be exchanged dialog has been established, INFO requests can be exchanged
both ways with no restrictions on timing and frequency and no both ways with no restrictions on timing and frequency and no
risk of collision. risk of collision.
</t> </t>
<t> A critical fact is that the sending of Trickle ICE candidates <t> A critical fact is that the sending of Trickle ICE candidates
in one direction is entirely uncoupled from sending candidates in one direction is entirely uncoupled from sending candidates
in the other direction. in the other direction.
Thus, the sending of candidates in each direction can be Thus, the sending of candidates in each direction can be
done by a stream of INFO requests that is not correlated with done by a stream of INFO requests that is not correlated with
the stream of INFO requests in the other direction. the stream of INFO requests in the other direction.
And since each INFO request cumulatively includes And since each INFO request cumulatively includes
the contents of all previous INFO requests in that direction, the contents of all previous INFO requests in that direction,
ordering between INFO requests need not be preserved. the ordering between INFO requests need not be preserved.
All of this permits using largely-independent INFO requests. All of this permits using largely independent INFO requests.
</t> </t>
<t> <t>
Contrarily, UPDATE or other offer/answer mechanisms assume Contrarily, UPDATE or other Offer/Answer mechanisms assume
that the messages in each direction are tightly coupled that the messages in each direction are tightly coupled
with messages in the other direction. with messages in the other direction.
Using Offer/Answer and UPDATE requests Using Offer/Answer and UPDATE requests
<xref target="RFC3311"/> <xref target="RFC3311" format="default"/>
would introduce the following complications: would introduce the following complications:
</t> </t>
<t> <dl newline="false" spacing="normal">
<list style="hanging"> <dt>Blocking of messages: </dt>
<t hangText="Blocking of messages: "> <dd>
<xref target="RFC3264"/> defines Offer/Answer as a Offer/Answer is defined as a
strictly sequential mechanism. strictly sequential mechanism in <xref target="RFC3264" format="de
fault"/>.
There can only be a maximum of one active exchange There can only be a maximum of one active exchange
at any point of time. at any point of time.
Both sides cannot simultaneously send Offers nor Both sides cannot simultaneously send Offers nor
can they generate multiple Offers prior to can they generate multiple Offers prior to
receiving an Answer. receiving an Answer.
Using UPDATE requests for Using UPDATE requests for
candidate transport would therefore imply the candidate transport would therefore imply the
implementation of a candidate pool at every agent where implementation of a candidate pool at every agent where
candidates can be stored until it is once again that candidates can be stored until it is once again that
agent's "turn" to emit an Answer or a new Offer. agent's "turn" to emit an Answer or a new Offer.
Such an approach would introduce non-negligible Such an approach would introduce non-negligible
complexity for no additional value. complexity for no additional value.
</t> </dd>
<t hangText="Elevated risk of glare: "> <dt>Elevated risk of glare: </dt>
<dd>
The sequential nature of Offer/Answer also makes it The sequential nature of Offer/Answer also makes it
impossible for both sides to send Offers simultaneously. impossible for both sides to send Offers simultaneously.
What's worse is that there are no mechanisms in SIP to What's worse is that there are no mechanisms in SIP to
actually prevent that. <xref target="RFC3261"/>, where actually prevent that. <xref target="RFC3261" format="default"/>, where
the situation of Offers crossing on the wire is described the situation of Offers crossing on the wire is described
as "glare", only defines a procedure for addressing the as "glare", only defines a procedure for addressing the
issue after it has occurred. According to that procedure issue after it has occurred. According to that procedure,
both Offers are invalidated and both sides need to retry both Offers are invalidated and both sides need to retry
the negotiation after a period between 0 and 4 seconds. the negotiation after a period between 0 and 4 seconds.
The high likelihood for glare to occur and the average two
second back-off intervals implies that the duration of The high likelihood for glare and the average two-second
Trickle ICE processing would not only fail to improve but 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. actually exceed those of regular ICE.
</t> </dd>
</list> </dl>
</t>
<t> <t>
INFO messages decouple the exchange of candidates from the INFO messages decouple the exchange of candidates from the
Offer/Answer negotiation Offer/Answer negotiation
and are subject to none of the glare issues described above, and are subject to none of the glare issues described above,
which makes them a very convenient and lightweight mechanism which makes them a very convenient and lightweight mechanism
for asynchronous delivery of candidates. for asynchronous delivery of candidates.
</t> </t>
<t> <t>
Using in-dialog INFO messages also provides a way of Using in-dialog INFO messages also provides a way of
guaranteeing that candidates are delivered end-to-end, between guaranteeing that candidates are delivered end to end, between
the same entities that are actually in the process of the same entities that are actually in the process of
initiating a session. Out-of-dialog alternatives would have implied initiating a session. Out-of-dialog alternatives would have implied
requiring support for Globally Routable UA URI (GRUU) requiring support for GRUU
<xref target="RFC5627"/> which, given GRUUs relatively low <xref target="RFC5627" format="default"/> that, given GRUUs relatively
low
adoption levels, would have constituted too strong of a adoption levels, would have constituted too strong of a
constraint to the adoption of Trickle ICE. constraint to the adoption of Trickle ICE.
</t> </t>
</section> </section>
<section title="Overall Description"> <section numbered="true" toc="default">
<name>Overall Description</name>
<t> <t>
This specification defines an Info Package for use by This specification defines an Info Package for use by
SIP User Agents implementing Trickle ICE. SIP UAs implementing Trickle ICE.
INFO requests carry ICE candidates discovered after the peer user INFO requests carry ICE candidates discovered after the peer UAs have
agents have confirmed mutual support for Trickle ICE. confirmed mutual support for Trickle ICE.
</t> </t>
</section> </section>
<section title="Applicability"> <section numbered="true" toc="default">
<name>Applicability</name>
<t> <t>
The purpose of the ICE protocol is to establish a media path The purpose of the ICE protocol is to establish a media path
in the presence of NAT and firewalls. in the presence of NAT and firewalls.
The candidates are transported in INFO requests and are The candidates are transported in INFO requests and are
part of this establishment. part of this establishment.
</t> </t>
<t> <t>
Candidates sent by a Trickle ICE Agent after the Offer, Candidates sent by a Trickle ICE Agent after the Offer
follow the same signaling path and reach the same follow the same signaling path and reach the same
entity as the Offer itself. While it is true that GRUUs can entity as the Offer itself. While it is true that GRUUs can
be used to achieve this, one of the goals of this be used to achieve this, one of the goals of this
specification is to allow operation of Trickle ICE in as many specification is to allow operation of Trickle ICE in as many
environments as possible including those without GRUU support. environments as possible including those without GRUU support.
Using out-of-dialog SUBSCRIBE/NOTIFY requests would not Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
satisfy this goal. satisfy this goal.
</t> </t>
</section> </section>
<section title="Info Package Name"> <section numbered="true" toc="default">
<name>Info Package Name</name>
<t> <t>
This document defines a SIP Info Package as per This document defines a SIP Info Package as per
<xref target="RFC6086"/>. The Info Package token name for this <xref target="RFC6086" format="default"/>. The Info Package token name
package is "trickle-ice" for this
package is "trickle-ice".
</t> </t>
</section> </section>
<section title="Info Package Parameters"> <section numbered="true" toc="default">
<name>Info Package Parameters</name>
<t> <t>
This document does not define any Info Package parameters. This document does not define any Info Package parameters.
</t> </t>
</section> </section>
<section title="SIP Option Tags" anchor="option-tag"> <section anchor="option-tag" numbered="true" toc="default">
<name>SIP Option Tags</name>
<t> <t>
<xref target="RFC6086"/> allows Info Package specifications to <xref target="RFC6086" format="default"/> allows Info Package specific ations to
define SIP option-tags. This specification extends the option-tag define SIP option-tags. This specification extends the option-tag
construct of the SIP grammar as follows: construct of the SIP grammar as follows:
</t>
<t>
<figure><artwork align="left">
option-tag /= "trickle-ice"
</artwork></figure>
</t> </t>
<artwork align="left" name="" type="" alt=""><![CDATA[
option-tag /= "trickle-ice" ]]></artwork>
<t> <t>
SIP entities that support this SIP entities that support this
specification MUST place the 'trickle-ice' option-tag in a SIP specification <bcp14>MUST</bcp14> place the "trickle-ice" option-tag i n a SIP
Supported: or Require: header field within Supported: or Require: header field within
all SIP INVITE requests and responses. all SIP INVITE requests and responses.
</t> </t>
<t> <t>
When responding to, or generating a SIP OPTIONS request a SIP When responding to, or generating, a SIP OPTIONS request, a SIP
entity MUST also include the 'trickle-ice' option-tag in a SIP entity <bcp14>MUST</bcp14> also include the "trickle-ice" option-tag i
n a SIP
Supported: or Require: header field. Supported: or Require: header field.
</t> </t>
</section> </section>
<section title="Info Request Body Parts"> <section numbered="true" toc="default">
<name>INFO Request Body Parts</name>
<t> <t>
Entities implementing this specification MUST include a Entities implementing this specification <bcp14>MUST</bcp14> include a
payload of type 'application/trickle-ice-sdpfrag' as defined payload of type "application/trickle-ice-sdpfrag" in SIP INFO requests
in <xref target="trickle_ice_sdpfrag_grammar"/> as defined
in SIP INFO requests. in <xref target="trickle_ice_sdpfrag_grammar" format="default"/>.
The payload is used to convey SDP-encoded ICE candidates. The payload is used to convey SDP-encoded ICE candidates.
</t> </t>
</section> </section>
<section title="Info Package Usage Restrictions"> <section numbered="true" toc="default">
<name>Info Package Usage Restrictions</name>
<t> <t>
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
</t> </t>
</section> </section>
<section title="Rate of INFO Requests"> <section numbered="true" toc="default">
<name>Rate of INFO Requests</name>
<t> <t>
Given that IP addresses may be gathered rapidly a Given that IP addresses may be gathered rapidly, a
Trickle ICE Agent with many network interfaces might create a Trickle ICE Agent with many network interfaces might create a
high rate of INFO requests if every newly high rate of INFO requests if every newly
detected candidate is trickled individually without aggregation. detected candidate is trickled individually without aggregation.
An implementation MUST aggregate ICE candidates in case that an An implementation <bcp14>MUST</bcp14> aggregate ICE candidates in case an
unreliable transport protocol such as UDP is used. unreliable transport protocol such as UDP is used.
A Trickle ICE agent MUST NOT have more than one INFO request A Trickle ICE Agent <bcp14>MUST NOT</bcp14> have more than one INFO re quest
pending at any one time. pending at any one time.
When INFO messages are sent over an unreliable transport, When INFO messages are sent over an unreliable transport,
they are retransmitted according to the rules specified in they are retransmitted according to the rules specified in
<xref target="RFC3261" pageno="false" format="default"/> section 17.1. 2.1." <xref target="RFC3261" sectionFormat="comma" section="17.1.2.1"/>.
</t> </t>
<t> <t>
If the INFO requests are sent on top of TCP, If the INFO requests are sent on top of TCP,
which is probably the standard way, which is probably the standard way,
this is not an issue for the network anymore, it is not an issue for the network anymore,
but it can remain one for SIP proxies and other intermediaries but it can remain one for SIP proxies and other intermediaries
forwarding the SIP INFO messages. forwarding the SIP INFO messages.
Also, an endpoint may not be able to tell that it has congestion Also, an endpoint may not be able to tell that it has congestion
controlled transport all the way. controlled transport all the way.
</t> </t>
</section> </section>
<section title="Info Package Security Considerations"> <section numbered="true" toc="default">
<name>Info Package Security Considerations</name>
<t> <t>
See <xref target="sec-cons"/> See <xref target="sec-cons" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section title="Deployment Considerations" anchor="deploy-cons"> <section anchor="deploy-cons" numbered="true" toc="default">
<t> <name>Deployment Considerations</name>
Trickle ICE uses two mechanisms for exchange of candidate information. <t>
Trickle ICE uses two mechanisms for the exchange of candidate informatio
n.
This imposes new requirements to certain middleboxes This imposes new requirements to certain middleboxes
that are used in some networks, e.g. for monitoring purposes. that are used in some networks, e.g., for monitoring purposes.
While the first mechanism, SDP Offers and Answers, While the first mechanism, SDP Offers and Answers,
is already used by regular ICE and is assumed to be supported, is already used by regular ICE and is assumed to be supported,
the second mechanism, INFO request bodies, the second mechanism, INFO request bodies,
needs to be considered by such middleboxes as well when needs to be considered by such middleboxes as well when
trickle ICE is used. trickle ICE is used.
Such middleboxes need to make sure that they remain Such middleboxes need to make sure that they remain
in the signaling path of the INFO requests and in the signaling path of the INFO requests and
need to understand the INFO request body. 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 docum
ent. ]
</t>
<section anchor="sec-eoc-iana" title="SDP 'end-of-candidates' Attribute
" toc="default">
<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' is a property attribute
<xref target="RFC4566" pageno="false" format="default"/>
, and hence has no value.
</t> </t>
<figure> </section>
<preamble/> <section anchor="IANA" numbered="true" toc="default">
<artwork> <name>IANA Considerations</name>
<![CDATA[ <section anchor="sec-eoc-iana" toc="default" numbered="true">
Name: end-of-candidates <name>SDP "end-of-candidates" Attribute</name>
<t>
This section defines a new SDP media-level and session-level
<xref target="RFC4566" format="default"/> "end-of-candidates" attribute, w
hich is a property attribute
<xref target="RFC4566" format="default"/> and hence has no value.
</t>
<ul empty="true"><li>
<dl newline="false" spacing="normal">
Value: N/A <dt>Name:</dt><dd>end-of-candidates</dd>
Usage Level: media and session <dt>Value:</dt><dd>N/A</dd>
Charset Dependent: no <dt>Usage Level:</dt><dd>media and session</dd>
Purpose: The sender indicates that it will not trickle <dt>Charset Dependent:</dt><dd>no</dd>
further ICE candidates.
O/A Procedures: RFCXXX defines the detailed <dt>Purpose:</dt><dd>The sender indicates that it will not trickle
further ICE candidates.</dd>
<dt>O/A Procedures:</dt><dd>RFC 8840 defines the detailed
SDP Offer/Answer procedures for SDP Offer/Answer procedures for
the 'end-of-candidates' attribute. the "end-of-candidates" attribute.</dd>
Mux Category: IDENTICAL <dt>Mux Category:</dt><dd>IDENTICAL</dd>
Reference: RFCXXXX <dt>Reference:</dt><dd>RFC 8840</dd>
Example: <dt>Example:</dt><dd>a=end-of-candidates</dd>
</dl></li></ul>
a=end-of-candidates
]]>
</artwork>
</figure>
</section> </section>
<section anchor="sdpfrag-reg" numbered="true" toc="default">
<name>Media Type "application/trickle-ice-sdpfrag"</name>
<t>
This document defines the new media type "application/trickle-ice-sdpfrag"
in accordance with <xref target="RFC6838" format="default"/>.
</t>
<section title="Media Type 'application/trickle-ice-sdpfrag' " anchor="sdp <dl spacing="normal">
frag-reg"> <dt>Type name:</dt><dd>application</dd>
<t> <dt>Subtype name:</dt><dd>trickle-ice-sdpfrag</dd>
This document defines a new Media Type 'application/trickle-ice-sdpfrag' <dt>Required parameters:</dt><dd>None.</dd>
in accordance with <xref target="RFC6838"/>. <dt>Optional parameters:</dt><dd>None.</dd>
</t> <dt>Encoding considerations:</dt><dd><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>
The media contents follow the same rules as SDP, The media contents follow the same rules as SDP,
except as noted in this document. except as noted in this document.
The media contents are text, with the grammar specified The media contents are text, with the grammar specified
in <xref target="trickle_ice_sdpfrag_grammar"/>. in <xref target="trickle_ice_sdpfrag_grammar" format="default"/>.
</t> </t><t>
<t>
Although the initially defined content of a trickle-ice-sdpfrag body Although the initially defined content of a trickle-ice-sdpfrag body
does only include ASCII characters, does only include ASCII characters,
UTF-8 encoded content might be introduced via extension attributes. UTF-8-encoded content might be introduced via extension attributes.
The "a=charset:" attribute may be used to signal the presence of oth The "charset" attribute may be used to signal the presence of other
er
character sets in certain parts of a trickle-ice-sdpfrag body (see character sets in certain parts of a trickle-ice-sdpfrag body (see
<xref target="RFC4566"/>). <xref target="RFC4566" format="default"/>).
Arbitrary binary content cannot be directly represented Arbitrary binary content cannot be directly represented
in SDP or a trickle-ice-sdpfrag body. in SDP or a trickle-ice-sdpfrag body.
</t> </t></dd>
</list></t>
<t> Security considerations: </t> <dt>Security considerations:</dt><dd>See <xref target="RFC4566" format
<t><list style="none"> ="default"/> and RFC 8840</dd>
<t> <dt>Interoperability considerations:</dt><dd>See RFC 8840</dd>
See <xref target="RFC4566"/> and RFCXXXX <dt>Published specification:</dt><dd>See RFC 8840</dd>
</t> <dt>Applications that use this media type:</dt><dd>Trickle ICE</dd>
</list></t> <dt>Fragment identifier considerations:</dt><dd>N/A</dd>
<t> Interoperability considerations:</t>
<t><list style="none"> <dt>Additional information:</dt>
<t> <dd><t><br/></t>
See RFCXXXX <dl newline="false" spacing="compact">
</t> <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
</list></t> <dt>Magic number(s):</dt><dd>N/A</dd>
<t> Published specification:</t> <dt>File extension(s):</dt><dd>N/A</dd>
<t><list style="none"> <dt>Macintosh File Type Code(s):</dt><dd>N/A</dd>
<t> </dl>
See RFCXXXX </dd>
</t>
</list></t> <dt>Person and email address to contact for further information:</dt>
<t> Applications which use this Media Type:</t> <dd>The IESG (iesg@ietf.org)</dd>
<t><list style="none">
<t> <dt>Intended usage:</dt>
Trickle-ICE <dd>Trickle ICE for SIP as specified in RFC 8840.</dd>
</t>
</list></t> <dt>Restrictions on usage:</dt><dd>N/A</dd>
<t> Fragment identifier considerations: N/A</t> <dt>Author/Change controller:</dt><dd>The IESG (iesg@ietf.org)</dd>
<t> Additional information: </t> <dt>Provisional registration? (standards tree only):</dt><dd>N/A</dd>
<t><list style="none"> </dl>
<t> Deprecated alias names for this type: N/A </t>
<t> Magic number(s): N/A</t> </section>
<t>File extension(s): N/A</t> <section anchor="package-reg" numbered="true" toc="default">
<t>Macintosh File Type Code(s): N/A</t> <name>SIP Info Package "trickle-ice"</name>
</list></t>
<t> Person and email address to contact for further information:</t>
<t><list style="none">
<t>
The IESG (iesg@ietf.org)
</t>
</list></t>
<t> Intended usage: </t>
<t><list style="none">
<t> <t>
Trickle-ICE for SIP as specified in RFCXXXX. This document defines a new SIP Info Package named "trickle-ice"
and updates the "Info Packages Registry" with the following entry.
</t> </t>
</list></t> <table anchor="table_1" align="left">
<t> Restrictions on usage: N/A</t> <thead>
<t> Author/Change controller:</t> <tr>
<t><list style="none"> <th align='center'>Name</th>
<t> <th align='center'>Reference</th>
The IESG (iesg@ietf.org) </tr>
</t> </thead>
</list></t> <tbody>
<t> Provisional registration? (standards tree only): N/A </t> <tr>
<td>trickle-ice</td>
<td>RFC 8840</td>
</tr>
</tbody>
</table>
</section>
</list> <section anchor="optag-reg" numbered="true" toc="default">
</t> <name>SIP Option Tag "trickle-ice"</name>
<t>
This specification registers a new SIP option tag "trickle-ice"
as per the guidelines in <xref target="RFC3261" sectionFormat="of"
section="27.1"/>
and updates the "Option Tags" subregistry of the
SIP Parameters registry with the following entry:
</t>
</section> <table anchor="table_2" align="left">
<section title="SIP Info Package 'trickle-ice' " anchor="package-r <thead>
eg"> <tr>
<t> <th align='center'>Name</th>
This document defines a new SIP Info Package named 'trickle-ice' <th align='center'>Description</th>
and updates the Info Packages Registry with the following entry. <th align='center'>Reference</th>
</t> </tr>
<t> </thead>
<figure><artwork align="left"> <tbody>
+-------------+-----------+ <tr>
| Name | Reference | <td>trickle&nbhy;ice</td>
+-------------+-----------+ <td>This option tag is used to indicate that a UA supports and understands T
| trickle-ice | [RFCXXXX] | rickle ICE.</td>
| | | <td>RFC 8840</td>
+-------------+-----------+ </tr>
</artwork></figure> </tbody>
</t> </table>
</section>
<section title="SIP Option Tag 'trickle-ice'" anchor="optag-reg"> </section>
<t>
This specification registers a new SIP option tag 'trickle-ice'
as per the guidelines in Section 27.1 of <xref target="RFC3261"/>
and updates the "Option Tags" section of the
SIP Parameter Registry with the following entry:
</t>
<t>
<figure><artwork align="left">
+-------------+-------------------------------------+-----------+
| Name | Description | Reference |
+-------------+-------------------------------------+-----------+
| trickle-ice | This option tag is used to indicate | [RFCXXXX] |
| | that a UA supports and understands | |
| | Trickle-ICE. | |
+-------------+-------------------------------------+-----------+
</artwork></figure>
</t>
</section>
</section> </section>
<section title='Security Considerations' anchor="sec-cons"> <section anchor="sec-cons" numbered="true" toc="default">
<name>Security Considerations</name>
<t> <t>
The Security Considerations of The Security Considerations of
<xref target="I-D.ietf-mmusic-ice-sip-sdp"/>, <xref target="RFC6086" format="default"/>, <xref target="RFC8838" forma
<xref target="RFC6086"/> and t="default"/>, and
<xref target="I-D.ietf-ice-trickle"/> apply. <xref target="RFC8839" format="default"/> apply.
This document clarifies how the above specifications are used together f or trickling This document clarifies how the above specifications are used together f or trickling
candidates and does not create additional security risks. candidates and does not create additional security risks.
</t> </t>
<t> <t>
The new Info Package 'trickle-ice' and The new Info Package "trickle-ice" and
the new Media Type 'application/trickle-ice-sdpfrag' the new media type "application/trickle-ice-sdpfrag"
do not introduce additional security considerations do not introduce additional security considerations
when used in the context of Trickle ICE. when used in the context of Trickle ICE.
Both are not intended to be used for other applications, Both are not intended to be used for other applications,
so any security considerations for its use in other contexts so any security considerations for its use in other contexts
is out of the scope of this document is out of the scope of this document
</t> </t>
</section> </section>
<section title='Acknowledgements'> </middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3262.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3605.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5761.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5888.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6838.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7405.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.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/refer
ence.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 Interactiv
e Connectivity Establishment (ICE)</title>
<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
<organization />
</author>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<author initials='A' surname='Keränen' fullname='Ari Keränen'>
<organization />
</author>
<author initials='R' surname='Shpount' fullname='Roman Shpount'>
<organization />
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>
<!--draft-ietf-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="January" year="2021" />
</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 Prot
ocol (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="January" year="2021"/>
</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/rfc8
859">
<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="January" year="2021"/>
</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 and RTP Control Protocol (RTCP)
Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name='RFC' value='8858' />
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3311.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3840.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5389.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5627.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5766.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t> <t>
The authors like to thank The authors like to thank
Flemming Andreasen, <contact fullname="Flemming Andreasen"/>,
Ayush Jain, <contact fullname="Ayush Jain"/>,
Paul Kyzivat, <contact fullname="Paul Kyzivat"/>,
Jonathan Lennox, <contact fullname="Jonathan Lennox"/>,
Simon Perreault, <contact fullname="Simon Perreault"/>,
Roman Shpount <contact fullname="Roman Shpount"/>,
and and
Martin Thomson <contact fullname="Martin Thomson"/>
for reviewing and/or making various suggestions for for reviewing and/or making various suggestions for
improvements and optimizations. improvements and optimizations.
</t> </t>
<t> <t>
The authors also like to thank The authors also like to thank
Flemming Andreasen for shepherding this document and <contact fullname="Flemming Andreasen"/> for shepherding this document a
Ben Campbell for his AD review and suggestions. nd
In addition, the author like to thank <contact fullname="Ben Campbell"/> for his AD review and suggestions.
Benjamin Kaduk, In addition, the authors thank
Adam Roach, <contact fullname="Benjamin Kaduk"/>,
Mirja Kühlewind and <contact fullname="Adam Roach"/>,
Eric Rescorla <contact fullname="Mirja Kühlewind"/>, and
<contact fullname="Eric Rescorla"/>
for their comments and/or text proposals for improving for their comments and/or text proposals for improving
the document during IESG review. the document during IESG review.
</t> </t>
<t> <t>
Many thanks to Dale Worley for Gen-Art review and proposed Many thanks to <contact fullname="Dale Worley"/> for the Gen-Art review and proposed
enhancements for several sections. enhancements for several sections.
</t> </t>
<t> <t>
Many thanks to Joerg Ott for TSV-Art review and suggested improvements. Many thanks to <contact fullname="Joerg Ott"/> for the TSV-Art review an d suggested improvements.
</t> </t>
<t> <t>
The authors thank Shawn Emery for Security Directorate review. The authors thank <contact fullname="Shawn Emery"/> for the Security D irectorate review.
</t> </t>
</section> </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=rtc
p-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 sect
ion 10 of <xref target="RFC6086"/></t>
<t> Added definition of application/sdpfrag making draft-ivov-mmusic-sdp
frag obsolete</t>
<t> Added pseudo m-lines as additional separator in sdpfrag bodies for T
rickle 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 norm
ative 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-ic
e-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-sd
p"/> </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 unex
pectedly 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-iet
f-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 e
xchange 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 revi
ew
</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 Re
scorla
</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> </back>
</rfc> </rfc>
 End of changes. 342 change blocks. 
1503 lines changed or deleted 1293 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/