draft-ietf-mmusic-trickle-ice-sip-18xml2.original.xml   draft-ietf-mmusic-trickle-ice-sip-18.xml 
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<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="0000">
<!-- xml2rfc v2v3 conversion 2.34.0 -->
<!-- [rfced] updated by KC 11/07/19 -->
<front>
<title abbrev="Trickle ICE for SIP">
A Session Initiation Protocol (SIP) Usage for
Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (Trickle ICE)
</title>
<seriesInfo name="RFC" value="0000"/>
<author initials="E." surname="Ivov" fullname="Emil Ivov">
<organization abbrev="Jitsi">Jitsi</organization>
<address>
<postal>
<street/>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<phone>+33 6 72 81 15 55</phone>
<email>emcho@jitsi.org</email>
</address>
</author>
<author initials="T." surname="Stach" fullname="Thomas Stach">
<organization>Unaffiliated</organization>
<address>
<postal>
<street/>
<city>Vienna</city>
<region/>
<code>1130</code>
<country>Austria</country>
</postal>
<email>thomass.stach@gmail.com</email>
</address>
</author>
<author initials="E." surname="Marocco" fullname="Enrico Marocco">
<organization>Telecom Italia</organization>
<address>
<postal>
<street>Via G. Reiss Romoli, 274</street>
<city>Turin</city>
<code>10148</code>
<country>Italy</country>
</postal>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date month="November" year="2019"/>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<abstract>
<t>
The Interactive Connectivity Establishment (ICE) protocol
describes a Network Address Translator (NAT) traversal mechanism
for UDP-based multimedia sessions established with the
Offer/Answer model. The ICE extension for Incremental
Provisioning of Candidates (Trickle ICE) defines a mechanism
that allows ICE Agents to shorten session establishment delays
by making the candidate gathering and connectivity checking
phases of ICE non-blocking and executing them in parallel.
</t>
<t>
This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP).
The document also defines
a new SIP Info Package to support this usage
together with the corresponding media type.
Additionally, a new Session Description Protocol (SDP) "end-of-candidate
s" attribute and
a new SIP Option Tag 'trickle-ice' are defined.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>
The Interactive Connectivity Establishment (ICE) protocol
<xref target="RFC8445" format="default"/> describes
a mechanism for Network Address Translator (NAT) traversal
that consists of three main phases.
</t>
<t>
During the first phase, an agent gathers a set of candidate
transport addresses (source IP, port, and transport
protocol).
This is followed by a second phase
where these candidates are sent to a
remote agent within
the Session Description Protocol (SDP) body of a SIP message.
At the remote agent, the gathering procedure is repeated and
candidates are sent to the first agent.
Once the candidate information is available, a third phase
starts in parallel where connectivity between all candidates
in both sets is checked (connectivity checks).
Once these phases
have been completed, and only then, both agents can begin
communication.
</t>
<t>
According to <xref target="RFC8445" format="default"/>,
the three phases above happen consecutively, in a blocking way,
which can introduce undesirable setup delay during session
establishment.
The Trickle ICE extension
<xref target="I-D.ietf-ice-trickle" format="default"/> defines generic
semantics required for these ICE phases to happen
in a parallel, non-blocking way and hence speed up session
establishment.
</t>
<t>
This specification defines a usage of Trickle ICE with
the Session Initiation Protocol (SIP)<xref target="RFC3261" format="defa
ult"/>.
It describes how ICE
candidates are to be exchanged incrementally using SIP INFO
requests <xref target="RFC6086" format="default"/>
and how the Half Trickle and Full Trickle modes defined in
<xref target="I-D.ietf-ice-trickle" format="default"/> are to be used by
SIP User Agents (UAs) depending on their expectations for
support of Trickle ICE by a remote agent.
</t>
<t>
This document defines a new Info Package as specified in
<xref target="RFC6086" format="default"/> for use with Trickle ICE toget
her
with the corresponding media type,
SDP attribute, and SIP option tag.
</t>
</section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
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>
This specification makes use of terminology defined by the
ICE protocol in
<xref target="RFC8445" format="default"/> and by its Trickle ICE extensi
on in
<xref target="I-D.ietf-ice-trickle" format="default"/>. It is assumed th
at
the reader is familiar with the terminology from both documents.
</t>
<!--[rfced] Fyi, we updated the expansion of NAT to be 'Traversal
Using Relays around NAT (TURN)' (instead of 'Traversal Using
Relay NAT (TURN)') to match RFC 5766 and the companion documents.
Updated:
[RFC8445] also describes how ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol [RFC5389] and its
extension Traversal Using Relay NAT (TURN) [RFC5766].
-->
<t> <xref target="RFC8445" format="default"/> also describes
how ICE makes use of the
Session Traversal Utilities for NAT (STUN) protocol
<xref target="RFC5389" format="default"/> and its extension
Traversal Using Relays around NAT (TURN) <xref target="RFC5766" format=
"default"/>.
</t>
</section>
<section anchor="overview" numbered="true" toc="default">
<name>Protocol Overview</name>
<t>
When using ICE for SIP according to
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>,
the ICE candidates are exchanged solely via
SDP Offer/Answer as per <xref target="RFC3264" format="default"/>.
This specification defines an additional mechanism
where candidates can be exchanged using SIP INFO messages
and a newly defined Info Package <xref target="RFC6086" format="default"
/>.
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.
</t>
<t>
Typically, in cases where Trickle ICE is fully supported,
the Offerer sends an INVITE request
containing a subset of candidates.
Once an early dialog is established,
the Offerer can continue sending
candidates in INFO requests within that dialog.
</t>
<t>
Similarly, an Answerer can send
ICE candidates using INFO requests within
the dialog established by its 18x provisional response.
<xref target="fig-intro-example" format="default"/> shows such a sample
exchange:
</t>
<!--[rfced] We believe 'Turn' should be 'TURN' in Figures 1 and 9. We made
the updates; if this is not correct, please let us know.
Original:
STUN/Turn
Servers
Updated:
STUN/TURN
Servers
-->
<figure anchor="fig-intro-example">
<name>Sample Trickle ICE Scenario with SIP</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
| STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->|
|-------------->| INFO/OK (SRFLX Cand.) | |
| |------------------------>| TURN Alloc Resp|
| | INFO/OK (Relay Cand.) |<---------------|
| |<------------------------| |
| | | |
| | More Cands & ConnChecks| |
| |<=======================>| |
| | | |
| | 200 OK | |
| |<------------------------| |
| | ACK | |
| |------------------------>| |
| | | |
| |<===== MEDIA FLOWS =====>| |
| | | |
Note: SRFLX denotes server-reflexive candidates ]]></artwork>
</figure>
<section anchor="disco-issues" numbered="true" toc="default">
<name>Discovery Issues</name>
<t>
In order to benefit from Trickle ICE's full potential and
reduce session establishment latency to a minimum, Trickle ICE
agents need to generate SDP Offers and Answers that contain
incomplete and potentially empty sets of candidates. Such Offers
and Answers can only be handled meaningfully by agents that
actually support incremental candidate provisioning, which
implies the need to confirm such support before using
it.
</t>
<t>
Contrary to other protocols,
where "in advance" capability
discovery is widely implemented, the mechanisms that allow this
for SIP (i.e., a combination of UA capabilities
<xref target="RFC3840" format="default"/> and Globally Routable User A
gent URIs (GRUUs) <xref target="RFC5627" format="default"/>)
have only seen low levels of adoption.
This presents an issue
for Trickle ICE implementations as SIP UAs do not have an
obvious means of verifying that their peer will support
incremental candidate provisioning.
</t>
<t>
The Half Trickle mode of operation defined in the Trickle
ICE specification <xref target="I-D.ietf-ice-trickle" format="default"
/>
provides one way around this, by requiring the first Offer to
contain a complete set of local ICE candidates
and using only
incremental provisioning of remote candidates
for the rest of the session.
</t>
<t>
While using Half Trickle does provide a working solution, it
also comes at the price of increased latency. Therefore,
<xref target="disco" format="default"/> makes several alternative
suggestions that enable SIP UAs to engage in Full Trickle
right from their first Offer: <xref target="disco-prov" format="defaul
t"/>
discusses the use of online provisioning as a means of
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
support GRUU and UA capabilities and
<xref target="half-full-trickle" format="default"/> discusses the impl
ementation
and use of Half Trickle by SIP UAs where none of the above
are an option.
</t>
</section>
<section numbered="true" toc="default">
<name>Relationship with the Offer/Answer Model</name>
<t>
From the perspective of SIP middleboxes and proxies,
the Offer/Answer exchange for
Trickle ICE looks partly similar to the Offer/Answer exchange
for regular ICE for SIP
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>.
However, in order to have the full picture of the candidate
exchange, the newly introduced INFO messages
need to be considered as well.
</t>
<figure anchor="fig-oa-and-trickle">
<name>Distinguishing between Trickle ICE and Traditional Signaling</na
me>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | |
| +--------+ | Module | | | | Module | +--------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | |
| | Module | | | | | | Module | |
| +--------+ | | | | +--------+ |
+-------------------------------+ +-------------------------------+
| | | |
| | INVITE (Offer) | |
| |--------------------->| |
| | 183 (Answer) | |
| |<---------------------| |
| | | |
| |
| SIP INFO (more candidates) |
|----------------------------------------------------->|
| SIP INFO (more candidates) |
|<-----------------------------------------------------|
| |
| STUN Binding Requests/Responses |
|----------------------------------------------------->|
| STUN Binding Requests/Responses |
|<-----------------------------------------------------|
| |]]></artwork>
</figure>
<t>
From an architectural viewpoint, as displayed in
<xref target="fig-oa-and-trickle" format="default"/>, exchanging candi
dates
through SIP INFO requests could be represented as signaling
between ICE modules and not between Offer/Answer modules of
SIP UAs. Then, such INFO requests
do not impact the state of the Offer/Answer transaction other
than providing additional candidates.
Consequently, INFO requests are not considered Offers or Answers.
Nevertheless, candidates that have been exchanged
using INFO requests
<bcp14>SHALL</bcp14> be included in subsequent Offers or Answers.
The version number in the "o=" line of that subsequent Offer
needs to be incremented by 1 per the rules
in <xref target="RFC3264" format="default"/>.
</t>
</section>
</section>
<section anchor="OAproc" numbered="true" toc="default">
<name>Incremental Signaling of ICE Candidates</name>
<t>
Trickle ICE Agents will exchange
ICE descriptions compliant to
<xref target="I-D.ietf-ice-trickle" format="default"/>
via Offer/Answer procedures and/or INFO request bodies.
This requires the following SIP-specific extensions:
</t>
<ol spacing="normal" type="1">
<li>
Trickle ICE Agents <bcp14>MUST</bcp14> indicate support for Trickle
ICE by
including the SIP option-tag 'trickle-ice' in a SIP Supported: heade
r field
within all SIP INVITE requests and responses.
</li>
<li>
Trickle ICE Agents <bcp14>MUST</bcp14> indicate support for Trickle
ICE by
including the ice-option 'trickle'
within all SDP Offers and Answers in accordance to
<xref target="I-D.ietf-ice-trickle" format="default"/>.
</li>
<li>
Trickle ICE Agents <bcp14>MAY</bcp14> include any number of ICE candid
ates,
i.e., from zero to the complete set of candidates,
in their initial Offer or Answer.
If the complete candidate set is already included
in the initial Offer, it is called Half Trickle.
</li>
<li>
Trickle ICE Agents <bcp14>MAY</bcp14> exchange additional ICE candid
ates using INFO requests
within an existing INVITE dialog usage (including an early dialog)
as specified in <xref target="RFC6086" format="default"/>.
The INFO requests carry an Info-Package: trickle-ice.
Trickle ICE Agents <bcp14>MUST</bcp14> be prepared to receive INFO r
equests
within that same dialog usage,
containing additional candidates and/or
an indication that trickling of such candidates has ended.
</li>
<li>
Trickle ICE Agents <bcp14>MAY</bcp14> exchange additional ICE candid
ates
before the Answerer has sent the Answer provided that
an invite dialog usage is established at both Trickle ICE Agents.
Note that in case of forking, multiple early dialogs may exist.
</li>
</ol>
<t>
The following sections provide further details on how
Trickle ICE Agents perform the initial Offer/Answer exchange
(<xref target="InitialOA" format="default"/>),
perform subsequent Offer/Answer exchanges
(<xref target="subsOA" format="default"/>),
and establish the INVITE dialog usage
(<xref target="dialog-est" format="default"/>)
such that they can incrementally trickle candidates
(<xref target="info-sdp" format="default"/>).
</t>
<section anchor="InitialOA" numbered="true" toc="default">
<name>Initial Offer/Answer Exchange</name>
<section anchor="IniOS" numbered="true" toc="default">
<name>Sending the Initial Offer</name>
<t>
If the Offerer includes candidates in its initial Offer,
it <bcp14>MUST</bcp14> encode these candidates as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>.
</t>
<t>If the Offerer wants to send its initial Offer
before knowing any candidate for one or more 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
host IP address in the corresponding c-line,
e.g., due to privacy reasons,
it <bcp14>SHOULD</bcp14> include a default address in the c-lin
e,
which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::.
</t>
<t>
In this case, the Offerer obviously cannot know the RTP Control
Protocol (RTCP) transport address and,
thus, <bcp14>MUST NOT</bcp14> include the "a=rtcp" attribute <
xref target="RFC6086" format="default"/>.
This avoids potential ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default
"/>) for the RTCP transport address.
</t>
<t>
If the Offerer wants to use RTCP multiplexing
<xref target="RFC5761" format="default"/>
and/or exclusive RTCP multiplexing
<xref target="I-D.ietf-mmusic-mux-exclusive" format="default"/>
,
it still will include the "a=rtcp-mux" and/or
"a=rctp-mux-only" attribute
in the initial Offer.
</t>
<t>
In any case, the Offerer <bcp14>MUST</bcp14> include
the attribute "a=ice-options:trickle" in accordance to
<xref target="I-D.ietf-ice-trickle" format="default"/> and
<bcp14>MUST</bcp14> include in each "m=" line a "a=mid:" attribu
te
in accordance to <xref target="RFC5888" format="default"/>.
The "a=mid:" attribute identifies the "m=" line
to which a candidate belongs and
helps in case of multiple "m=" lines,
when candidate gathering could occur in a order different
from the order of the "m=" lines.
</t>
</section>
<section anchor="IniOR" numbered="true" toc="default">
<name>Receiving the Initial Offer</name>
<t>
If the initial Offer included candidates,
the Answerer uses these candidates to start ICE processing
as specified in <xref target="I-D.ietf-ice-trickle" format="def
ault"/>.
</t>
<t>
If the initial Offer included the attribute "a=ice-options:tric
kle",
the Answerer <bcp14>MUST</bcp14> be prepared for receiving tric
kled candidates later on.
</t>
<t>
In case of a "m/c=" line with default values,
none of the eventually trickled candidates
will match the default destination.
This situation <bcp14>MUST NOT</bcp14> cause an ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default
"/>).
</t>
</section>
<section anchor="IniAS" numbered="true" toc="default">
<name>Sending the Initial Answer</name>
<t>
If the Answerer includes candidates in its initial Answer,
it <bcp14>MUST</bcp14> encode these candidates as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>.
</t>
<t>If the Answerer wants to send its initial Answer
before knowing any candidate for one or more 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
host IP address in the corresponding c-line,
e.g., due to privacy reasons,
it <bcp14>SHOULD</bcp14> include a default address in the c-lin
e,
which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::.
</t>
<t>
In this case, the Answerer obviously cannot know the RTCP trans
port address and,
thus, <bcp14>MUST NOT</bcp14> include the "a=rtcp" attribute <
xref target="RFC6086" format="default"/>.
This avoids potential ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default
"/>) for the RTCP transport address.
</t>
<t>
If the Answerer accepts the use of RTCP multiplexing
<xref target="RFC5761" format="default"/>
and/or exclusive RTCP multiplexing
<xref target="I-D.ietf-mmusic-mux-exclusive" format="default"/>
,
it will include the "a=rtcp-mux" attribute
in the initial Answer.
</t>
<t>
In any case, the Answerer <bcp14>MUST</bcp14> include
the attribute "a=ice-options:trickle" in accordance to
<xref target="I-D.ietf-ice-trickle" format="default"/> and
<bcp14>MUST</bcp14> include in each "m=" line
a "a=mid:" attribute in accordance to
<xref target="RFC5888" format="default"/>.
</t>
</section>
<section anchor="IniAR" numbered="true" toc="default">
<name>Receiving the Initial Answer</name>
<t>
If the initial Answer included candidates,
the Offerer uses these candidates to start ICE processing
as specified in <xref target="I-D.ietf-ice-trickle" format="def
ault"/>.
</t>
<t>
In case of a "m/c=" line with default values,
none of the eventually trickled candidates
will match the default destination.
This situation <bcp14>MUST NOT</bcp14> cause an ICE mismatch
(see <xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default
"/>).
</t>
</section>
</section>
<section anchor="subsOA" numbered="true" toc="default">
<name>Subsequent Offer/Answer Exchanges</name>
<t>
Subsequent Offer/Answer exchanges are handled
the same as regular ICE (see <xref target="I-D.ietf-mmusic-ice-sip-s
dp" sectionFormat="of" section="4.2"/>).
</t>
<t> If an Offer or Answer needs to be sent while the ICE agents
are in the middle of trickling,
<xref target="I-D.ietf-mmusic-ice-sip-sdp" sectionFormat="of" sectio
n="3.2"/> applies.
This means that an ICE agent includes candidate attributes
for all local candidates it had trickled previously
for a specific media stream.
</t>
<t>
[RFC EDITOR NOTE: The section 3.2 in above sentence is correct for version 20 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 anchor="dialog-est" numbered="true" toc="default">
<name>Establishing the Dialog</name>
<t>
In order to be able to start trickling, the
following two conditions need to be satisfied at the SIP UAs:
</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>
<xref target="disco" format="default"/> discusses in detail the variou
s options
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
ICE once an Offer and an Answer have been exchanged,
which also allows for ICE processing to commence
(see <xref target="offerer-can-trickle" format="default"/>).
</t>
<section anchor="relprov" numbered="true" toc="default">
<name>Establishing Dialog State through Reliable Offer/Answer Delivery
</name>
<figure anchor="offerer-can-trickle">
<name>A SIP Offerer can freely trickle as soon as it receives an Ans
wer</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| PRACK/OK |
|------------------------>|
| |
+----------------------------------------+
|Alice and Bob know that both can trickle|
|and know that the dialog is in the early|
|state. Send INFO! |
+----------------------------------------+
| |
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
Note: SRFLX denotes server-reflexive candidates]]></artwork>
</figure>
<t>
As shown in <xref target="offerer-can-trickle" format="default"/>,
satisfying both conditions is relatively trivial for
ICE Agents that have sent an Offer in an INVITE and that have
received an Answer in a reliable provisional response.
It is guaranteed to have confirmed support (or lack thereof) for
Trickle ICE at the Answerer and to have
fully initialized the SIP dialog at both ends.
Offerers and Answerers (after receipt of the PRACK request)
in the above situation can therefore
freely commence trickling within the newly established dialog.
</t>
</section>
<section anchor="unrelprov" numbered="true" toc="default">
<name>Establishing Dialog State through Unreliable Offer/Answer Delive
ry</name>
<t>
The situation is a bit more delicate for agents that have
received an Offer in an INVITE request and have sent an Answer
in an unreliable provisional response because, once the
response has been sent, the Answerer does not
know when or if it has been received
(<xref target="answerer-cant-trickle" format="default"/>).
</t>
<figure anchor="answerer-cant-trickle">
<name>A SIP UA that sent an Answer in an unreliable provisional resp
onse does not know if it was received or if the dialog at the side of the Offere
r has entered the early state</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| |
| +----------------------+
| |Bob: I don't know if |
| |Alice got my 183 or if|
| |her dialog is already |
| |in the early state. |
| | Can I send INFO??? |
| +----------------------+
| | ]]></artwork>
</figure>
<t>
In order to clear this ambiguity as soon as possible,
the Answerer needs to retransmit the provisional response
with the exponential backoff timers described in
<xref target="RFC3262" format="default"/>.
These retransmissions <bcp14>MUST</bcp14> cease on receipt
of an INFO request carrying a 'trickle-ice' Info Package body,
on receipt of any other in-dialog request from the offerer, or
on transmission of the Answer in a 2xx response.
The offerer cannot send in-dialog requests until it receives
a response, so the arrival of such a request proves that
the response has arrived.
Using the INFO request for dialog confirmation
is similar to the procedure described in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" sectionFormat="of" sectio
n="6.1.1"/>, except that
the STUN binding Request is replaced by the INFO request.
</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>
The Offerer <bcp14>MUST</bcp14> send a Trickle ICE INFO request as s
oon as
it receives an SDP Answer in an unreliable provisional
response. This INFO request <bcp14>MUST</bcp14> repeat the candidate
s
that were already provided in the Offer (as would be the case
when Half Trickle is performed or when new candidates have not
been learned since then).
The first case could happen when Half Trickle is used and
all candidate are already in the initial offer.
The second case could happen when Full Trickle is used and
the offerer is currently gathering additional candidates
but did not yet get them.
Also, if the initial Offer did not contain any candidates,
depending on how the Offerer gathers its candidates and
how long it takes to do so, this INFO could still contain no candida
tes.
</t>
<t>
When Full Trickle is used and if newly learned candidates
are available, the Offerer <bcp14>SHOULD</bcp14> also deliver
these candidates in said INFO request,
unless it wants to hold back some candidates in reserve,
e.g., in case these candidates
are expensive to use and would only be trickled
if all other candidates failed.
</t>
<t>
The Offerer <bcp14>SHOULD</bcp14> include an end-of-candidates attri
bute
in case candidate discovery has ended in the meantime
and no further candidates are to be trickled.
</t>
<t>
As soon as an Answerer has received such an INFO request,
the Answerer has an indication that a dialog is established
at both ends and can begin trickling
(<xref target="answerer-can-now-trickle" format="default"/>).
</t>
<t>
Note: The +SRFLX in
<xref target="answerer-can-now-trickle" format="default"/>
indicates that additionally newly learned server-reflexive candidat
es are included.
</t>
<figure anchor="answerer-can-now-trickle">
<name>A SIP UA that received an INFO request after sending an unreli
able provisional response knows that the dialog at th
e side of the receiver has entered the early state</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know Alice|
| | is ready. Send INFO! |
| +----------------------+
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
| 200/ACK (Answer) |
|<------------------------|
Note: SRFLX denotes server-reflexive candidates ]]></artwork>
</figure>
<t>
When sending the Answer in the 200 OK response to the INVITE request,
the Answerer needs to repeat
exactly the same Answer that was previously sent
in the unreliable provisional
response in order to fulfill the corresponding requirements in
<xref target="RFC3264" format="default"/>.
Thus, the Offerer needs to be prepared
for receiving a different number of candidates
in that repeated Answer than previously exchanged via trickling
and <bcp14>MUST</bcp14> ignore the candidate information
in that 200 OK response.
</t>
</section>
<section anchor="head-start" numbered="true" toc="default">
<name>Initiating Trickle ICE without an SDP Answer</name>
<t>
The ability to convey arbitrary candidates in INFO
message bodies allows ICE Agents to initiate trickling
without actually sending an Answer.
Trickle ICE Agents can therefore respond to an INVITE request
with provisional responses without an SDP Answer
<xref target="RFC3261" format="default"/>.
Such provisional responses serve for establishing an early dialog.
</t>
<t>
Agents that choose to establish the dialog in this way
<bcp14>MUST</bcp14> retransmit these responses
with the exponential backoff timers described in
<xref target="RFC3262" format="default"/>.
These retransmissions <bcp14>MUST</bcp14> cease on receipt
of an INFO request carrying a 'trickle-ice' Info Package body,
on receipt of any in-dialog request from the offerer, or
on transmission of the Answer in a 2xx response.
The offerer cannot send in-dialog requests until it receives
a response, so the arrival of such a request proves that
the response has arrived.
This is again similar to the procedure described in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" sectionFormat="of" sectio
n="6.1.1"/>,
except that an Answer is not yet provided.
</t>
<t>
[RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20
of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in t
he meantime.]
</t>
<t>
Note: The +SRFLX in
<xref target="can-now-trickle-unrelprov" format="default"/>
indicates that additional newly learned server-reflexive candidates
are included.
</t>
<figure anchor="can-now-trickle-unrelprov">
<name>A SIP UA sends an unreliable provisional response without an
Answer for establishing an early dialog</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (-) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know again|
| | that Alice is ready. |
| | Send INFO! |
| +----------------------+
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 183 (Answer) opt. |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 200/ACK (Answer) |
|<------------------------|
Note: SRFLX denotes server-reflexive candidates]]></artwork>
</figure>
<t>
When sending the Answer, the agent <bcp14>MUST</bcp14> repeat all curren
tly
known and used candidates, if any,
and <bcp14>MAY</bcp14> include all newly gathered candidates since the l
ast INFO request was sent.
However, if that Answer was already sent in a unreliable provisional res
ponse,
the Answerers <bcp14>MUST</bcp14> repeat
exactly the same Answer in the 200 OK response to the INVITE request
in order to fulfill the corresponding requirements in
<xref target="RFC3264" format="default"/>.
In case that trickling continued,
an Offerer needs to be prepared for receiving fewer candidates
in that repeated Answer than previously exchanged via trickling
and <bcp14>MUST</bcp14> ignore the candidate information in that 200 OK
response.
</t>
</section>
</section>
<section anchor="info-sdp" numbered="true" toc="default">
<name>Delivering Candidates in INFO Requests</name>
<t>
Whenever new ICE candidates become available for sending,
agents encode them in "a=candidate:" attributes as described
by <xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>. For ex
ample:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host ]]></artwork>
<t>
The use of SIP INFO requests happens within the context of the
Info Package as defined in <xref target="info-package" format="default
"/>.
The media type
<xref target="RFC6838" format="default"/>
for their payload <bcp14>MUST</bcp14> be set to
'application/trickle-ice-sdpfrag' as defined in
<xref target="trickle_ice_sdpfrag_def" format="default"/>.
The Info request body adheres to the grammar as specified in
<xref target="trickle_ice_sdpfrag_grammar" format="default"/>.
</t>
<t>
Since neither the "a=candidate:" nor the "a=end-of-candidates"
attributes contain information that would allow correlating them to
a specific "m=" line,
it is handled through the use of
pseudo "m=" lines.
</t>
<t>
Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in
<xref target="RFC4566" format="default"/> and are linked to the corres
ponding "m=" line
in the SDP Offer or Answer via the identification tag
in a "a=mid:" attribute
<xref target="RFC5888" format="default"/>.
A pseudo "m=" line does not provide semantics other
than indicating to which "m=" line a candidate belongs.
Consequently, the receiving agent <bcp14>MUST</bcp14> ignore any remai
ning content of the pseudo "m=" line,
which is not defined in this document.
This guarantees that the 'application/trickle-ice-sdpfrag' bodies do
not interfere with the Offer/Answer
procedures as specified in <xref target="RFC3264" format="default"/>.
</t>
<t>
When sending the INFO request, the agent <bcp14>MAY</bcp14>,
if already known to the agent, include the same content into
the pseudo "m=" line as for the "m=" line in the corresponding Offer or
Answer.
However, since Trickle-ICE might be decoupled from the Offer/Answer nego
tiation, the content might
be unknown to the agent. In this case, the agent <bcp14>MUST</bcp14> inc
lude the following default values:
</t>
<ul spacing="normal">
<li>
The media field is set to 'audio'.
</li>
<li>
The port value is set to '9'.
</li>
<li>
The proto value is set to 'RTP/AVP'.
</li>
<li>
The fmt field <bcp14>MUST</bcp14> appear only once and is set to '
0'.
</li>
</ul>
<t>
Agents <bcp14>MUST</bcp14> include a pseudo "m=" line and an
identification tag in a "a=mid:" attribute for every "m=" line
whose candidate list they intend to update.
Such "a=mid:" attributes <bcp14>MUST</bcp14>
immediately precede the list of candidates for that specific
"m=" line.
</t>
<t>
All "a=candidate:" or "a=end-of-candidates" attributes
following an "a=mid:" attribute, up until (and excluding) the next
occurrence of a pseudo "m=" line, pertain to the "m=" line
identified by that identification tag.
</t>
<t>
Note, that there is no requirement that the Info request body
contains as many pseudo "m=" lines as the Offer/Answer
contains "m=" lines, nor that the pseudo "m=" lines be in the same
order as the "m=" lines that they pertain to.
The correspondence can be made via the "a=mid:" attributes
since candidates are grouped in sections headed
by "pseudo" "m=" lines.
These sections contain "a=mid:" attribute values that point
back to the true "m=" line.
</t>
<t>
An "a=end-of-candidates" attribute, preceding
the first pseudo "m=" line, indicates the end of all trickling
from that agent,
as opposed to end of trickling for a specific "m=" line,
which would be indicated by a media-level
"a=end-of-candidates" attribute.
</t>
<t>
Refer to
<xref target="INFOexample" format="default"/>
for an example of the INFO request content.
</t>
<t>
The use of pseudo "m=" lines allows for a structure similar to
the one in SDP Offers and Answers where
separate media-level and session-level sections can be distinguished.
In the current case, lines preceding the first
pseudo "m=" line are considered to be session level.
Lines appearing in between or after
pseudo "m=" lines will be interpreted as media level.
</t>
<aside><t>Note that while this specification uses the "a=mid:"
attribute from <xref target="RFC5888" format="default"/>, it does
not
define any grouping semantics.</t></aside>
<!--Note: I marked the above text as an aside; if that's not ideal, you can reve
rt to the coding below-->
<!-- <ul empty="true" spacing="normal">
<li>
Note that while this specification uses the "a=mid:"
attribute from <xref target="RFC5888" format="default"/>, it does
not
define any grouping semantics.
</li>
</ul>-->
<t>
All INFO requests <bcp14>MUST</bcp14> carry the "a=ice-pwd:" and "a=ic
e-ufrag:"
attributes that allow mapping them to a specific ICE generation.
An agent <bcp14>MUST</bcp14> discard any received INFO requests contai
ning "a=ice-pwd:" and "a=ice-ufrag:"
attributes that do not match those of the current ICE Negotiation Sess
ion.
</t>
<t>
The "a=ice-pwd:" and "a=ice-ufrag:" attributes <bcp14>MUST</bcp14> app
ear at the same level
as the ones in the Offer/Answer exchange.
In other words, if they were present
as session-level attributes, they will also appear
at the beginning of all INFO request payloads, i.e., preceding
the first pseudo "m=" line.
If they were originally exchanged as media-level
attributes, potentially overriding session-level values,
then they will also be included in INFO request payloads
following the corresponding pseudo "m=" lines.
</t>
<t>
Note that <xref target="I-D.ietf-ice-trickle" format="default"/> requi
res that
when candidates are trickled, each candidate must be delivered
to the receiving Trickle ICE implementation not more than once
and in the same order as it was conveyed.
If the signaling protocol provides any candidate retransmissions,
they need to be hidden from the ICE implementation.
This requirement is fulfilled as follows.
</t>
<t>
Since the agent is not fully aware of the state of the ICE Negotiation
Session at its peer,
it <bcp14>MUST</bcp14> include all currently known and used local cand
idates in every INFO request.
That is, the agent <bcp14>MUST</bcp14> repeat in the INFO request body
all candidates that were previously sent under the same
combination of "a=ice-pwd:" and "a=ice-ufrag:"
in the same order as they were sent before.
In other words, the sequence of a previously sent
list of candidates <bcp14>MUST NOT</bcp14> change in subsequent INFO r
equests,
and newly gathered candidates <bcp14>MUST</bcp14> be added
at the end of that list.
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 messag
es and reordering,
which can be detected through the CSeq: header field in the INFO reque
st.
</t>
<t>
In addition, an ICE agent needs to adhere to
<xref target="I-D.ietf-ice-trickle" sectionFormat="of" section="17"/>
on preserving candidate order while trickling.
</t>
<t>
When receiving INFO requests carrying any candidates, agents
<bcp14>MUST</bcp14> first identify and discard the attribute lines
containing candidates they have already received in previous
INFO requests or in the Offer/Answer exchange preceding them.
</t>
<t> Such candidates are considered to be equal if their IP address
port, transport, and component ID are the same.
After identifying and discarding the known candidates,
the agents <bcp14>MUST</bcp14> forward the actually new candidates to
the ICE Agents
in the same order as they were received in the INFO request body.
The ICE Agents will then process the new candidates
according to the rules described in <xref target="I-D.ietf-ice-trickle
" format="default"/>.
</t>
<t> Receiving an "a=end-of-candidates" attribute in an INFO request body
-- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the curren
t ICE generation --
is an indication from the peer agent that it will not send any further c
andidates.
When included at the session level, i.e., before any pseudo "m=" line,
this indication applies to the whole session;
when included at the media level, the indication applies
only to the corresponding "m=" line.
Handling of such end-of-candidates indications is defined in
<xref target="I-D.ietf-ice-trickle" format="default"/>.
</t>
<t>
The example in <xref target="INFOexample" format="default"/> shows the
content
of a candidate delivering INFO request. In the example, the
"a=end-of-candidates" attributes indicate that
the candidate gathering is finished and
that no further INFO requests follow.
</t>
<figure anchor="INFOexample">
<name>An Example for the Content of an INFO Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 862
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
raddr 192.0.2.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
raddr 192.0.2.1 rport 8998
a=end-of-candidates
m=audio 9 RTP/AVP 0
a=mid:2
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
raddr 192.0.2.1 rport 9998
a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
raddr 192.0.2.1 rport 9998
a=end-of-candidates
Note: In a real INFO request, there will be no line breaks
in the "a=candidate:" attributes ]]></artwork>
</figure>
</section>
</section>
<section anchor="disco" numbered="true" toc="default">
<name>Initial Discovery of Trickle ICE Support</name>
<t>
SIP UAs are required by <xref target="I-D.ietf-ice-trickle" format="def
ault"/> to indicate their support of and intent to use Trickle ICE in their Offe
rs and Answers using the atrribute "a=ice-options:trickle", and they <bcp14>MUST
</bcp14> include the SIP option-tag "trickle-ice" in
a SIP Supported: or Require: header field.
This makes discovery
fairly straightforward for Answerers or for cases where
Offers need to be generated within existing dialogs (i.e.,
when sending UPDATE or re-INVITE requests).
In both scenarios, prior
SDP bodies will have provided the necessary information.
</t>
<t>
Obviously, such information is not available at the time a first
Offer is being constructed and it is therefore impossible
for ICE Agents to determine support for incremental
provisioning that way. The following options are suggested as
ways of addressing this issue.
</t>
<section anchor="disco-prov" numbered="true" toc="default">
<name>Provisioning Support for Trickle ICE</name>
<t>
In certain situations, it may be possible for integrators
deploying Trickle ICE to know in advance that some or all
endpoints reachable from within the deployment will support
Trickle ICE.
This is the case, for example, if Session Border Controllers
(SBCs) with support for this specification are used
to connect to UAs that do not support Trickle ICE.
</t>
<t>
While the exact mechanism for allowing such provisioning
is out of scope here, this specification encourages trickle
ICE implementations to allow the option in the way they find
most appropriate.
</t>
<t>
However, an Offerer assuming Trickle ICE support <bcp14>MUST</bcp14>
include a SIP Require: trickle-ice header field.
That way, if the provisioned assumption of Trickle ICE support
ends up being incorrect, the failure is (a) operationally
easy to track down, and (b) recoverable by the client,
i.e., they can re-send the request without the
SIP Require: header field and without
the assumption of Trickle ICE support.
</t>
</section>
<section anchor="disco-gruu" numbered="true" toc="default">
<name>Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU
s)</name>
<t>
<xref target="RFC3840" format="default"/> provides a way for SIP UAs
to query for support of specific capabilities using, among
others, OPTIONS requests. On the other hand, support for
GRUU according to
<xref target="RFC5627" format="default"/>
allows SIP requests to be addressed to specific UAs (as
opposed to arbitrary instances of an address of record).
Combining the two and using the "trickle-ice" option tag
defined in <xref target="option-tag" format="default"/> provides SIP
UAs with
a way of learning the capabilities of specific SIP UA instances
and then addressing them directly with INVITE requests that
require Trickle ICE support.
</t>
<t>
Such learning of capabilities may happen in different ways.
One option for a SIP UA is to learn the
GRUU instance ID of a peer through presence and then to query
its capabilities with an OPTIONS request.
Alternatively, it can also just send an OPTIONS request to
the Address of Record (AOR) it intends to contact and then inspect t
he returned
response(s) for support of both GRUU and Trickle ICE
(<xref target="options-gruu" format="default"/>).
It is noted that using the GRUU means that the INVITE request
can go only to that particular device.
This prevents the use of forking for that request.
</t>
<figure anchor="options-gruu">
<name>Trickle ICE Support Discovery with OPTIONS and GRUU</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Alice Bob
| |
| OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->|
| |
| 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... |
|<--------------------------------------------------|
| |
| INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
| Supported: trickle-ice |
| (Offer) |
|-------------------------------------------------->|
| |
| 183 (Answer) |
|<--------------------------------------------------|
| INFO/OK (Trickling) |
|<------------------------------------------------->|
| |
| ... |
| |]]></artwork>
</figure>
<t>
Confirming support for Trickle ICE through
<xref target="RFC3840" format="default"/> gives SIP UAs the option t
o engage
in Full Trickle negotiation (as opposed to the more lengthy
Half Trickle) from the very first Offer they send.
</t>
</section>
<section anchor="half-full-trickle" numbered="true" toc="default">
<name>Fallback to Half Trickle</name>
<t>
In cases where none of the other mechanisms in this section
are acceptable, SIP UAs should use the Half Trickle mode
defined in <xref target="I-D.ietf-ice-trickle" format="default"/>.
With Half Trickle, agents initiate sessions the same way
they would when using ICE for SIP
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>.
This means that, prior to actually sending an Offer, agents
first gather ICE candidates in a blocking way and then
send them all in that Offer. The blocking nature of the
process implies that some amount of latency will
be accumulated, and it is advised that agents try to
anticipate it where possible, for example, when user
actions indicate a high likelihood for an imminent call
(e.g., activity on a keypad or a phone going off hook).
</t>
<t>
Using Half Trickle results in Offers that are
compatible with both ICE SIP endpoints and legacy
<xref target="RFC3264" format="default"/> endpoints.
</t>
<figure anchor="fig-half-trickle">
<name>Example of a Typical (Half) Trickle ICE Exchange with SIP</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
|<--------------| | |
| | | |
| | | |
| Candidate | | |
| | | |
| | | |
| Discovery | | |
| | | |
| | | |
|-------------->| INVITE (Offer) | |
| |---------------------------->| |
| | 183 (Answer) |-------------->|
| |<----------------------------| |
| | INFO (repeated candidates) | |
| |---------------------------->| |
| | | |
| | INFO (more candidates) | Candidate |
| |<----------------------------| |
| | Connectivity Checks | |
| |<===========================>| Discovery |
| | INFO (more candidates) | |
| |<----------------------------| |
| | Connectivity Checks |<--------------|
| |<===========================>| |
| | | |
| | 200 OK | |
| |<----------------------------| |
| | | |
| |<======= MEDIA FLOWS =======>| |
| | | | ]]></artwork>
</figure>
<t>
As a reminder, once a single Offer or Answer has
been exchanged within a specific dialog, support for
Trickle ICE will have been determined.
No further use of Half Trickle will therefore be necessary
within that same dialog,
and all subsequent exchanges can use the Full Trickle mode
of operation.
</t>
</section>
</section>
<section anchor="rtcp-cons" numbered="true" toc="default">
<name>Considerations for RTP and RTCP Multiplexing</name>
<t>
The following consideration describes options for Trickle ICE
in order to give some guidance to implementers on how trickling
can be optimized with respect to providing RTCP candidates.
</t>
<t>
Handling of the "a=rtcp" attribute <xref target="RFC3605" format="defaul
t"/>
and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing <xref target="R
FC5761" format="default"/>
is already considered in
<xref target="RFC8445" sectionFormat="of" section="5.1.1.1"/> and
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.
</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
in <xref target="I-D.ietf-mmusic-mux-exclusive" format="default"/>,
the procedures in that document apply for the handling of the "a=rtcp-mu
x-only", "a=rtcp", and "a=rtcp-mux" attributes.
</t>
<t>
While a Half Trickle Offerer has to send an Offer compliant to
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> and <xref
target="RFC5761" format="default"/> including candidates for all components,
the flexibility of a Full Trickle Offerer allows
to send only RTP candidates (component 1) in the initial Offer
assuming that RTCP multiplexing is supported by the Answerer.
A Full Trickle Offerer would need to start gathering and trickling
RTCP candidates (component 2)
only after having received an indication in the Answer that
the Answerer unexpectedly does not support RTCP multiplexing.
</t>
<t>
A Trickle Answerer <bcp14>MAY</bcp14> include an "a=rtcp-mux" attribute
<xref target="RFC5761" format="default"/> in the application/trickle-ice
-sdpfrag body
if it supports and uses RTP and RTCP multiplexing.
The Trickle Answerer needs to follow the guidance on the usage of the "a
=rtcp" attribute as given in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> and
<xref target="RFC3605" format="default"/>.
Receipt of this attribute at the Offerer in an INFO request prior to the
Answer
indicates that the Answerer supports and uses RTP and RTCP multiplexing.
The Offerer can use this information, e.g., for stopping the gathering o
f RTCP candidates
and/or for freeing corresponding resources.
</t>
<t>
This behavior is illustrated by the following example Offer that indicat
es support for RTP and RTCP multiplexing.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 2001:db8:a0b:12f0::3
t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 5000 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host]]></artw
ork>
<t>
Once the dialog is established as described in <xref target="dialog-est"
format="default"/>, the Answerer
sends the following INFO request.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 161
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host ]]></art
work>
<t>
This INFO request indicates that the Answerer supports and uses
RTP and RTCP multiplexing as well.
It allows the Offerer to omit gathering RTCP candidates or
releasing already gathered RTCP candidates.
If the INFO request did not contain the "a=rtcp-mux" attribute,
the Offerer has to gather RTCP candidates
unless it wants to wait until receipt of an Answer that eventually confi
rms
support or non-support for RTP and RTCP multiplexing.
In casethe Offerer had sent RTCP candidates in a previous INFO request,
it still needs to repeat them in subsequent INFO requests,
even when that support for RTCP multiplexing was confirmed
by the Answerer and the Offerer has released its RTCP candidates.
</t>
</section>
<section anchor="bundle-cons" numbered="true" toc="default">
<name>Considerations for Media Multiplexing</name>
<t>
The following considerations describe options for Trickle ICE
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
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default"/>
.
It is assumed that the reader is familiar with <xref target="I-D.ietf-mm
usic-sdp-bundle-negotiation" format="default"/>.
</t>
<t>
ICE candidate exchange is already considered
in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" sectionFormat="of"
section="11"/>.
These considerations are still valid for Trickle ICE; however,
trickling provides more flexibility for the sequence of candidate exchan
ge,
especially in Full Trickle mode.
</t>
<t>
Except for bundle-only "m=" lines, a Half Trickle Offerer has to
send an Offer with candidates for all bundled "m=" lines.
The additional flexibility, however, allows a Full Trickle Offerer
to initially send only candidates for the "m=" line with the
suggested Offerer BUNDLE address.
</t>
<t>
On receipt of the Answer, the Offerer will detect
if BUNDLE is supported by the Answerer and if the suggested Offerer 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.
However, if BUNDLE is not supported, the Full Trickle Offerer needs to g
ather and trickle candidates
for the remaining "m=" lines as necessary.
If the Answerer selects an Offerer BUNDLE address that is different from
the suggested Offerer BUNDLE address,
the Full Trickle Offerer needs to gather and trickle candidates
for the "m=" line that carries the selected Offerer BUNDLE address.
</t>
<t>
A Trickle Answerer <bcp14>SHOULD</bcp14> include an "a=group:BUNDLE" att
ribute
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default"/>
at session level in the application/trickle-ice-sdpfrag body
if it supports and uses bundling.
When doing so, the Answerer <bcp14>MUST</bcp14> include all identificati
on-tags in the same order that is used or will be used in the Answer.
</t>
<t>
Receipt of this attribute at the Offerer in an INFO request prior to the
Answer indicates that the Answerer
supports and uses bundling.
The Offerer can use this information, e.g., for stopping the gathering o
f candidates
for the remaining "m=" lines in a bundle and/or for freeing correspondin
g resources.
</t>
<t>
This behavior is illustrated by the following example Offer that indicat
es support for Media Multiplexing.
</t>
<t>
If the Offerer had already sent candidates for "m=" lines
in a bundle in a previous INFO request,
it still needs to repeat them in subsequent INFO requests,
even when that support for bundling was confirmed
by the Answerer, and the Offerer has released candiates that are no long
er needed.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 2001:db8:a0b:12f0::3
t=0 0
a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
m=video 10002 RTP/AVP 31
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid]]></artwork>
<t>
The example Offer indicates support for RTP and RTCP multiplexing
and contains an "a=candidate:" attribute only for the "m=" line
with the suggested Offerer bundle address.
Once the dialog is established as described in <xref target="dialog-est
" format="default"/>, the Answerer
sends the following INFO request.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 219
a=group:BUNDLE foo bar
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host ]]></art
work>
<t>
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
didates
matching those from the second "m=" line in the offer are not needed fr
om the Answerer.
</t>
<t>
The INFO request also indicates that the Answerer accepted the suggested
Offerer Bundle Address.
This allows the Offerer to omit gathering RTP and RTCP candidates for th
e other "m=" lines
or releasing already gathered candidates.
If the INFO request did not contain the "a=group:BUNDLE" attribute, the
Offerer has to gather
RTP and RTCP candidates for the other "m=" lines unless it wants to wa
it until receipt
of an Answer that eventually confirms
support or non-support for Media Multiplexing.
</t>
<t>
Independent of using Full Trickle or Half Trickle mode, the rules from
<xref target="I-D.ietf-mmusic-sdp-mux-attributes" format="default"/> ap
ply to both, Offerer and Answerer,
when putting attributes as specified in
<xref target="trickle_ice_sdpfrag_grammar" format="default"/>
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 attribute
<xref target="RFC4566" format="default"/>
"end-of-candidates". "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 session level, this indication applies to the whole sessi
on;
when included at the media level, the indication applies only to the corre
sponding media description.
</t>
<ul empty="true">
<li>
<dl spacing="normal">
<dt>Name:</dt><dd>end-of-candidates</dd>
<dt>Value:</dt><dd>N/A</dd>
<dt>Usage Level:</dt><dd>media and session level</dd>
<dt>Charset Dependent:</dt><dd>no</dd>
<dt>Mux Category:</dt><dd>IDENTICAL</dd>
<dt>Example:</dt><dd>a=end-of-candidates</dd>
</dl>
</li>
</ul>
</section>
<section anchor="eoc-ind" numbered="true" toc="default">
<name>Offer/Answer Procedures</name>
<t>The Offerer or Answerer <bcp14>MAY</bcp14> include an "a=end-of-candi
dates" attribute
in case candidate discovery has ended
and no further candidates are to be trickled.
The Offerer or Answerer <bcp14>MUST</bcp14> provide the "a=end-of-cand
idates" attribute
together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the curr
ent
ICE generation as required by
<xref target="I-D.ietf-ice-trickle" format="default"/>.
When included at the session level,
this indication applies to the whole session;
when included at the media level, the indication applies
only to the corresponding media description.
</t>
<t>
Receipt of an "a=end-of-candidates" attribute at an
Offerer or Answerer
-- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the curr
ent ICE generation --
indicates that the gathering of candidates
has ended at the peer, for either the session or only the
corresponding media description as specified above.
The receiving agent forwards an end-of-candidates indication
to the ICE Agent, which in turn acts as specified in
<xref target="I-D.ietf-ice-trickle" format="default"/>.
</t>
</section>
</section>
<section anchor="trickle_ice_sdpfrag_def" numbered="true" toc="default">
<name>Content Type 'application/trickle-ice-sdpfrag'</name>
<section numbered="true" toc="default">
<name>Overall Description</name>
<t>
An application/trickle-ice-sdpfrag body is used exclusively by the 'tric
kle-ice' Info Package.
Other SDP-related applications need to define their own media type.
The INFO request body uses a subset of the possible SDP lines
as defined by the grammar in <xref target="RFC4566" format="default"/>.
A valid body uses only pseudo "m=" lines and certain attributes
that are needed and/or useful for trickling candidates.
The content adheres to the following grammar.
</t>
</section>
<section anchor="trickle_ice_sdpfrag_grammar" numbered="true" toc="default
">
<name>Grammar</name>
<t>
The grammar of an 'application/trickle-ice-sdpfrag' body is
based on the following ABNF <xref target="RFC5234" format="default"/>
.
It specifies the subset of existing SDP attributes
that is needed or useful for trickling candidates.
The grammar uses the indicator for case-sensitive %s,
as defined in <xref target="RFC7405" format="default"/>,
but it also imports grammar for other SDP attributes that
precede the production of <xref target="RFC7405" format="default"/>.
A sender <bcp14>SHOULD</bcp14> use lower case for attributes
from such earlier grammar, but a receiver <bcp14>MUST</bcp14> treat
them as case insensitive.
</t>
<sourcecode type="abnf"><![CDATA[
; Syntax
trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = *(session-level-field CRLF)
session-level-field = ice-lite-attribute /
ice-pwd-attribute /
ice-ufrag-attribute /
ice-options-attribute /
ice-pacing-attribute /
end-of-candidates-attribute /
bundle-group-attribute /
extension-attribute-fields
; for future extensions
ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a" "=" ice-options
end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = %s"end-of-candidates"
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(SP identification-tag)
bundle-semantics = "BUNDLE"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields )
trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
trickle-ice-attribute-field = mid-attribute /
candidate-attributes /
ice-pwd-attribute /
ice-ufrag-attribute /
remote-candidate-attribute /
end-of-candidates-attribute /
rtcp-attribute /
rtcp-mux-attribute /
rtcp-mux-only-attribute /
extension-attribute-fields
; for future extensions
rtcp-attribute = %s"a" "=" %s"rtcp"
rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux"
rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only"
candidate-attributes = %s"a" "=" candidate-attribute
remote-candidate-attribute = %s"a" "=" remote-candidate-att ]]></source
code>
<t>
<!--[rfced] For easier readability, may we update the text as follows?
Please let us know if this is agreeable or if you prefer
otherwise.
Original:
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
pacing-att, ice-options, candidate-attribute remote-candidate-att
from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute
; from [RFC5888], media-field, attribute-fields from [RFC4566].
Perhaps:
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
pacing-att, ice-options, candidate-attribute, and remote-candidate-att
from [RFCYYY1]; identification-tag and mid-attribute
from [RFC5888]; and media-field and attribute-fields from [RFC4566].
-->
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att,
ice-pacing-att, ice-options, candidate-attribute remote-candidate-att
from <xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>,
identification-tag, mid-attribute; from <xref target="RFC5888" format="
default"/>;
media-field, attribute-fields from <xref target="RFC4566" format="defau
lt"/>.
The "a=rtcp" attribute is defined in <xref target="RFC3605" format="def
ault"/>,
the "a=rtcp-mux" attribute is defined in <xref target="RFC5761" format
="default"/>, and
the "a=rtcp-mux-only" attribute is defined in <xref target="I-D.ietf-mm
usic-mux-exclusive" format="default"/>.
The latter attributes lack formal grammar in their corresponding RFC an
d are reproduced here.
</t>
<t>
The "a=ice-pwd:" and "a=ice-ufrag:" attributes <bcp14>MUST</bcp14> app
ear at the
same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes, they will also
appear at the beginning of all INFO request payloads, i.e., preceding
all pseudo "m=" lines. If they were originally exchanged as media-lev
el
attributes, potentially overriding session-level values, then
they will also be included in INFO request payloads following the
corresponding pseudo "m=" lines.
</t>
<t>
An Agent <bcp14>MUST</bcp14> ignore any received unknown extension-attr
ibute-fields.
</t>
</section>
</section>
<section anchor="info-package" numbered="true" toc="default">
<name>Info Package</name>
<section anchor="rationale" numbered="true" toc="default">
<name>Rationale -- Why INFO?</name>
<t>
The decision to use SIP INFO requests as a candidate transport
method is based primarily on their lightweight nature. Once a
dialog has been established, INFO requests can be exchanged
both ways with no restrictions on timing and frequency and no
risk of collision.
</t>
<t> A critical fact is that the sending of Trickle ICE candidates
in one direction is entirely uncoupled from sending candidates
in the other direction.
Thus, the sending of candidates in each direction can be
done by a stream of INFO requests that is not correlated with
the stream of INFO requests in the other direction.
And since each INFO request cumulatively includes
the contents of all previous INFO requests in that direction,
the ordering between INFO requests need not be preserved.
All of this permits using largely independent INFO requests.
</t>
<t>
Contrarily, UPDATE or other offer/answer mechanisms assume
that the messages in each direction are tightly coupled
with messages in the other direction.
Using Offer/Answer and UPDATE requests
<xref target="RFC3311" format="default"/>
would introduce the following complications:
</t>
<dl newline="false" spacing="normal">
<dt>Blocking of messages: </dt>
<dd>
Offer/Answer is defined as a
strictly sequential mechanism in <xref target="RFC3264" format="de
fault"/>.
There can only be a maximum of one active exchange
at any point of time.
Both sides cannot simultaneously send Offers nor
can they generate multiple Offers prior to
receiving an Answer.
Using UPDATE requests for
candidate transport would therefore imply the
implementation of a candidate pool at every agent where
candidates can be stored until it is once again that
agent's "turn" to emit an Answer or a new Offer.
Such an approach would introduce non-negligible
complexity for no additional value.
</dd>
<dt>Elevated risk of glare: </dt>
<dd>
The sequential nature of Offer/Answer also makes it
impossible for both sides to send Offers simultaneously.
What's worse is that there are no mechanisms in SIP to
actually prevent that. <xref target="RFC3261" format="default"/>,
where
the situation of Offers crossing on the wire is described
as "glare", only defines a procedure for addressing the
issue after it has occurred. According to that procedure,
both Offers are invalidated and both sides need to retry
the negotiation after a period between 0 and 4 seconds.
The high likelihood for glare and the average two-second
backoff intervals to occur implies that the duration of
Trickle ICE processing would not only fail to improve but
actually exceed those of regular ICE.
</dd>
</dl>
<t>
INFO messages decouple the exchange of candidates from the
Offer/Answer negotiation
and are subject to none of the glare issues described above,
which makes them a very convenient and lightweight mechanism
for asynchronous delivery of candidates.
</t>
<t>
Using in-dialog INFO messages also provides a way of
guaranteeing that candidates are delivered end to end, between
the same entities that are actually in the process of
initiating a session. Out-of-dialog alternatives would have implied
requiring support for GRUU
<xref target="RFC5627" format="default"/> that, given GRUUs relatively
low
adoption levels, would have constituted too strong of a
constraint to the adoption of Trickle ICE.
</t>
</section>
<section numbered="true" toc="default">
<name>Overall Description</name>
<t>
This specification defines an Info Package for use by
SIP UAs implementing Trickle ICE.
INFO requests carry ICE candidates discovered after the peer UAs have
confirmed mutual support for Trickle ICE.
</t>
</section>
<section numbered="true" toc="default">
<name>Applicability</name>
<t>
The purpose of the ICE protocol is to establish a media path
in the presence of NAT and firewalls.
The candidates are transported in INFO requests and are
part of this establishment.
</t>
<t>
Candidates sent by a Trickle ICE Agent after the Offer
follow the same signaling path and reach the same
entity as the Offer itself. While it is true that GRUUs can
be used to achieve this, one of the goals of this
specification is to allow operation of Trickle ICE in as many
environments as possible including those without GRUU support.
Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
satisfy this goal.
</t>
</section>
<section numbered="true" toc="default">
<name>Info Package Name</name>
<t>
This document defines a SIP Info Package as per
<xref target="RFC6086" format="default"/>. The Info Package token name
for this
package is "trickle-ice".
</t>
</section>
<section numbered="true" toc="default">
<name>Info Package Parameters</name>
<t>
This document does not define any Info Package parameters.
</t>
</section>
<section anchor="option-tag" numbered="true" toc="default">
<name>SIP Option Tags</name>
<t>
<xref target="RFC6086" format="default"/> allows Info Package specific
ations to
define SIP option-tags. This specification extends the option-tag
construct of the SIP grammar as follows:
</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
option-tag /= "trickle-ice" ]]></artwork>
<t>
SIP entities that support this
specification <bcp14>MUST</bcp14> place the 'trickle-ice' option-tag i
n a SIP
Supported: or Require: header field within
all SIP INVITE requests and responses.
</t>
<t>
When responding to, or generating, a SIP OPTIONS request, a SIP
entity <bcp14>MUST</bcp14> also include the 'trickle-ice' option-tag i
n a SIP
Supported: or Require: header field.
</t>
</section>
<section numbered="true" toc="default">
<name>Info Request Body Parts</name>
<t>
Entities implementing this specification <bcp14>MUST</bcp14> include a
payload of type 'application/trickle-ice-sdpfrag' as defined
in <xref target="trickle_ice_sdpfrag_grammar" format="default"/>
in SIP INFO requests.
The payload is used to convey SDP-encoded ICE candidates.
</t>
</section>
<section numbered="true" toc="default">
<name>Info Package Usage Restrictions</name>
<t>
This document does not define any Info Package Usage Restrictions.
</t>
</section>
<section numbered="true" toc="default">
<name>Rate of INFO Requests</name>
<t>
Given that IP addresses may be gathered rapidly, a
Trickle ICE Agent with many network interfaces might create a
high rate of INFO requests if every newly
detected candidate is trickled individually without aggregation.
An implementation <bcp14>MUST</bcp14> aggregate ICE candidates in case
an
unreliable transport protocol such as UDP is used.
A Trickle ICE agent <bcp14>MUST NOT</bcp14> have more than one INFO re
quest
pending at any one time.
When INFO messages are sent over an unreliable transport,
they are retransmitted according to the rules specified in
<xref target="RFC3261" sectionFormat="comma" section="17.1.2.1"/>.
</t>
<t>
If the INFO requests are sent on top of TCP,
which is probably the standard way,
it is not an issue for the network anymore,
but it can remain one for SIP proxies and other intermediaries
forwarding the SIP INFO messages.
Also, an endpoint may not be able to tell that it has congestion
controlled transport all the way.
</t>
</section>
<section numbered="true" toc="default">
<name>Info Package Security Considerations</name>
<t>
See <xref target="sec-cons" format="default"/>.
</t>
</section>
</section>
<section anchor="deploy-cons" numbered="true" toc="default">
<name>Deployment Considerations</name>
<t>
Trickle ICE uses two mechanisms for the exchange of candidate informatio
n.
This imposes new requirements to certain middleboxes
that are used in some networks, e.g., for monitoring purposes.
While the first mechanism, SDP Offers and Answers,
is already used by regular ICE and is assumed to be supported,
the second mechanism, INFO request bodies,
needs to be considered by such middleboxes as well when
trickle ICE is used.
Such middleboxes need to make sure that they remain
in the signaling path of the INFO requests and
understand the INFO request body.
</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="sec-eoc-iana" toc="default" numbered="true">
<name>SDP "end-of-candidates" Attribute</name>
<t>
This section defines a new SDP media-level and session-level attribute
<xref target="RFC4566" format="default"/> "end-of-candidates". "end-of-can
didates" is a property attribute
<xref target="RFC4566" format="default"/> and hence has no value.
</t>
<ul empty="true"><li>
<dl newline="false" spacing="normal">
<dt>Name:</dt><dd>end-of-candidates</dd>
<dt>Value:</dt><dd>N/A</dd>
<dt>Usage Level:</dt><dd>media and session</dd>
<dt>Charset Dependent:</dt><dd>no</dd>
<dt>Purpose:</dt><dd>The sender indicates that it will not trickle
further ICE candidates.</dd>
<dt>O/A Procedures:</dt><dd>RFC XXXX defines the detailed
SDP Offer/Answer procedures for
the "end-of-candidates" attribute.</dd>
<dt>Mux Category:</dt><dd>IDENTICAL</dd>
<dt>Reference:</dt><dd>RFC XXXX</dd>
<dt>Example:</dt><dd>a=end-of-candidates</dd>
</dl></li></ul>
</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>
<ul empty="true"><li>
<dl spacing="normal">
<dt>Type name:</dt><dd>application</dd>
<dt>Subtype name:</dt><dd>trickle-ice-sdpfrag</dd>
<dt>Required parameters:</dt><dd>None.</dd>
<dt>Optional parameters:</dt><dd>None.</dd>
<dt>Encoding considerations:</dt><dd><t>
The media contents follow the same rules as SDP,
except as noted in this document.
The media contents are text, with the grammar specified
in <xref target="trickle_ice_sdpfrag_grammar" format="default"/>.
</t><t>
Although the initially defined content of a trickle-ice-sdpfrag body
does only include ASCII characters,
UTF-8-encoded content might be introduced via extension attributes.
The "a=charset:" attribute may be used to signal the presence of oth
er
character sets in certain parts of a trickle-ice-sdpfrag body (see
<xref target="RFC4566" format="default"/>).
Arbitrary binary content cannot be directly represented
in SDP or a trickle-ice-sdpfrag body.
</t></dd>
<dt>Security considerations:</dt><dd>See <xref target="RFC4566" format
="default"/> and RFC XXXX</dd>
<dt>Interoperability considerations:</dt><dd>See RFC XXXX</dd>
<dt>Published specification:</dt><dd>See RFC XXXX</dd>
<dt>Applications which use this Media Type:</dt><dd>Trickle ICE</dd>
<dt>Fragment identifier considerations:</dt><dd>N/A</dd>
</dl>
</li>
</ul>
<ul empty="true"><li>
<dl spacing="normal">
<dt>Additional information:</dt><dd><t></t>
<dl newline="false" spacing="normal" indent="6">
<dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
<dt> Magic number(s):</dt><dd>N/A</dd>
<dt>File extension(s):</dt><dd>N/A</dd>
<dt>Macintosh File Type Code(s):</dt><dd>N/A</dd>
</dl></dd></dl></li></ul>
<ul empty="true"><li>
<dl newline="false" spacing="normal">
<dt>Person and email address to contact for further information:</dt>
<dd>The IESG (iesg@ietf.org)</dd>
<dt>Intended usage:</dt>
<dd>Trickle-ICE for SIP as specified in RFC XXXX.</dd>
<dt>Restrictions on usage:</dt><dd>N/A</dd>
<dt>Author/Change controller:</dt><dd>The IESG (iesg@ietf.org)</dd>
<dt>Provisional registration? (standards tree only):</dt><dd>N/A</dd>
</dl>
</li>
</ul>
</section>
<section anchor="package-reg" numbered="true" toc="default">
<name>SIP Info Package 'trickle-ice'</name>
<t>
This document defines a new SIP Info Package named 'trickle-ice'
and updates the Info Packages Registry with the following entry.
</t>
<table anchor="table_1" align="left">
<thead>
<tr>
<th align='center'>Name</th>
<th align='center'>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>trickle-ice</td>
<td>[RFCXXXX]</td>
</tr>
</tbody>
</table>
</section>
<section anchor="optag-reg" numbered="true" toc="default">
<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" section of the
SIP Parameter Registry with the following entry:
</t>
<table anchor="table_2" align="left">
<thead>
<tr>
<th align='center'>Name</th>
<th align='center'>Description</th>
<th align='center'>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>trickle&nbhy;ice</td>
<td>This option tag is used to indicate that a UA supports and understands T
rickle ICE</td>
<td>[RFCXXXX]</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="sec-cons" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The Security Considerations of
<xref target="RFC6086" format="default"/>, <xref target="I-D.ietf-mmusi
c-ice-sip-sdp" format="default"/>, and
<xref target="I-D.ietf-ice-trickle" format="default"/> apply.
This document clarifies how the above specifications are used together f
or trickling
candidates and does not create additional security risks.
</t>
<t>
The new Info Package 'trickle-ice' and
the new Media Type 'application/trickle-ice-sdpfrag'
do not introduce additional security considerations
when used in the context of Trickle ICE.
Both are not intended to be used for other applications,
so any security considerations for its use in other contexts
is out of the scope of this document
</t>
</section>
<section numbered="true" toc="default">
<name>Acknowledgements</name>
<t>
The authors like to thank
Flemming Andreasen,
Ayush Jain,
Paul Kyzivat,
Jonathan Lennox,
Simon Perreault,
Roman Shpount,
and
Martin Thomson
for reviewing and/or making various suggestions for
improvements and optimizations.
</t>
<t>
The authors also like to thank
Flemming Andreasen for shepherding this document and
Ben Campbell for his AD review and suggestions.
In addition, the authors thank
Benjamin Kaduk,
Adam Roach,
Mirja Kuehlewind, and
Eric Rescorla
for their comments and/or text proposals for improving
the document during IESG review.
</t>
<t>
Many thanks to Dale Worley for the Gen-Art review and proposed
enhancements for several sections.
</t>
<t>
Many thanks to Joerg Ott for the TSV-Art review and suggested improvemen
ts.
</t>
<t>
The authors thank Shawn Emery for the Security Directorate review.
</t>
</section>
<section numbered="true" toc="default">
<name>Change Log</name>
<t>
[RFC EDITOR NOTE: Please remove this section when publishing].
</t>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-01
</t>
<ul spacing="normal">
<li> Editorial Clean up</li>
<li> IANA Consideration added</li>
<li> Security Consideration added</li>
<li> RTCP and BUNDLE Consideration added with rules for including "a=rt
cp-mux" and "a=group: BUNDLLE" attributes </li>
<li> 3PCC Consideration added</li>
<li> Clarified that 18x w/o answer is sufficient to create a dialog that
allows for trickling to start </li>
<li> Added remaining Info Package definition sections as outlined in <xr
ef target="RFC6086" sectionFormat="of" section="10"/></li>
<li> Added definition of application/sdpfrag making draft-ivov-mmusic-sd
pfrag obsolete</li>
<li> Added pseudo m-lines as additional separator in sdpfrag bodies for
Trickle ICE </li>
<li> Added ABNF for sdp-frag bodies and Trickle-ICE package </li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-02
</t>
<ul spacing="normal">
<li> Removed definition of application/sdpfrag </li>
<li> Replaced with new type application/trickle-ice-sdpfrag </li>
<li> RTCP and BUNDLE Consideration enhanced with some examples </li>
<li> draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to nor
mative reference </li>
<li> Removed reference to 4566bis </li>
<li> Addressed review comment from Simon Perreault </li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-03
</t>
<ul spacing="normal">
<li> replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and
draft-ietf-mmusic-ice-sip-sdp </li>
<li> Corrected Figure 10, credits to Ayush Jain for finding the bug </l
i>
<li> Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-i
ce-sip-sdp </li>
<li> Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-mu
x-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive </li>
<li> Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for th
e application/trickle-ice-sdpfrag body </li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-04
</t>
<ul spacing="normal">
<li> considered comments from Christer Holmberg </li>
<li> corrected grammar for INFO package, such that ice-ufrag/pwd are als
o allowed on media-level as specified in <xref target="I-D.ietf-mmusic-ice-sip-s
dp" format="default"/> </li>
<li> Added new ice-pacing-attribute fom <xref target="I-D.ietf-mmusic-ic
e-sip-sdp" format="default"/> </li>
<li> Added formal definition for the end-of-candidates attribute </li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-05
</t>
<ul spacing="normal">
<li> considered further comments from Christer Holmberg </li>
<li> editorial comments on section 3 addressed </li>
<li> moved section 3.1 to section 10.1 and applied some edits</li>
<li> replaced the term "previously sent candidates" with "currently know
n and used candidates".</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-06
</t>
<ul spacing="normal">
<li> editorial fixes</li>
<li> additional text on the content of the INFO messages.</li>
<li> recommendation on what to do if a previously sent candidate is une
xpectedly missing in a subsequent INFO </li>
<li> terminology alignment with draft-ietf-ice-trickle-07 </li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-07
</t>
<ul spacing="normal">
<li> editorial fixes</li>
<li> clarification on ordering of candidates for alignment with draft-ie
tf-ice-trickle-12 </li>
<li> O/A procedures for end-of-candidates attribute described here after
corresponding procedures
have been removed from draft-ietf-ice-trickle-11</li>
<li> using IPv6 addresses in examples </li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-08
</t>
<ul spacing="normal">
<li> editorial fixes/clarification based on Flemmings review</li>
<li> Description of Trickle specifics in O/A procedures for initial O/A
exchange and specification of ICE mismatch exception</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-09
</t>
<ul spacing="normal">
<li> editorial fixes/correction of references</li>
<li> adding missing Ref to RFC3605 in section 6, 5th para</li>
<li> replaced remaining IPv4 adresses with IPv6 </li>
<li>
Added text for handling a=rtcp in case of default RTP address 0.0.0.
0:9 based on comment from Roman Shpount.
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-10
</t>
<ul spacing="normal">
<li> editorial fixes due to idnits output</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-11
</t>
<ul spacing="normal">
<li> addressing comments from Ben Campell's AD review and Christer's rev
iew
</li>
<li>
Numerous editorial improvements/corrections
</li>
<li>
Added [RFC8174] boiler plate and adapted usage of normative language
</li>
<li>
Clarified terminology ICE modules .vs. ICE agent
</li>
<li>
Added more detailed OA procedures
</li>
<li>
Corrected default values in m-line
and usage of "a=mid:" attribute explicitly mentioned for offer/answer
</li>
<li> Removed explicit mentioning of XMPP
</li>
<li>
Added Deployment Considerations section
</li>
<li>
Fixed ref for rfc5245bis
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-12
</t>
<ul spacing="normal">
<li> addressing comments from Gen-Art review, TSV-Art review and
Security Directorate review
</li>
<li>
Numerous editorial improvements/corrections/clarifications
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-13
</t>
<ul spacing="normal">
<li> added expansions for SDP,GRUU, AOR, STUN, TURN
</li>
<li>
some editorial corrections
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-14
</t>
<t>
Addressing comments from IESG review
</t>
<ul spacing="normal">
<li>
Clarification/enhancement in section 5 and Fig. 10 based on comments
from Benjamin Kaduk
</li>
<li>
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
</li>
<li>
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
</li>
<li>
Modified text on rate limitation of INFO requests based on
comments of Mirja Kuehlewind, Adam Roach and Roman Shpount
</li>
<li>
some editorial corrections
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-15
</t>
<ul spacing="normal">
<li>
Corrections in section 7 on Media Multiplexing
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-16
</t>
<ul spacing="normal">
<li>
some editorial corrections
</li>
</ul>
<t>
Changes from draft-ietf-mmusic-trickle-ice-sip-16
</t>
<ul spacing="normal">
<li>
Changed IPv6 candidate example from srflx to host
</li>
</ul>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-mmusic-ice-sip-sdp" to="RFCYYY1"/>
<displayreference target="I-D.ietf-ice-trickle" to="RFCYYY2"/>
<displayreference target="I-D.ietf-mmusic-sdp-bundle-negotiation" to="RFCYYY3"/>
<displayreference target="I-D.ietf-mmusic-sdp-mux-attributes" to="RFCYYY4"/>
<displayreference target="I-D.ietf-mmusic-mux-exclusive" to="RFCYYY5"/>
<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.8085.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"/>
<!--I-D.ietf-mmusic-ice-sip-sdp-39; C238 companion doc-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-ietf-mmusic-ice-sip-sdp-39.xml"/>
<!--I-D.ietf-ice-trickle-21; C238 companion doc-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-ietf-ice-trickle-21.xml"/>
<!--I-D.ietf-mmusic-sdp-bundle-negotiation-54; C238 companion doc-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-54.xml"/>
<!--I-D.ietf-mmusic-sdp-mux-attributes-17; C238 companion doc-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-ietf-mmusic-sdp-mux-attributes-17.xml"/>
<!--I-D.ietf-mmusic-mux-exclusive-12; C238 companion doc-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-ietf-mmusic-mux-exclusive-12.xml"/>
</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.3725.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>
</back>
</rfc>
 End of changes. 1 change blocks. 
lines changed or deleted lines changed or added

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