doc: Add RFC documents

1 files changed, 1185 insertions, 0 deletions

diff --git a/doc/rfc/rfc8838.txt b/doc/rfc/rfc8838.txt
new file mode 100644
index 0000000..e4ce7e4
--- /dev/null
+++ b/doc/rfc/rfc8838.txt
@@ -0,0 +1,1185 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           E. Ivov
+Request for Comments: 8838                                   8x8 / Jitsi
+Category: Standards Track                                      J. Uberti
+ISSN: 2070-1721                                                   Google
+                                                          P. Saint-Andre
+                                                                 Mozilla
+                                                            January 2021
+
+
+Trickle ICE: Incremental Provisioning of Candidates for the Interactive
+               Connectivity Establishment (ICE) Protocol
+
+Abstract
+
+   This document describes "Trickle ICE", an extension to the
+   Interactive Connectivity Establishment (ICE) protocol that enables
+   ICE agents to begin connectivity checks while they are still
+   gathering candidates, by incrementally exchanging candidates over
+   time instead of all at once.  This method can considerably accelerate
+   the process of establishing a communication session.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8838.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Determining Support for Trickle ICE
+   4.  Generating the Initial ICE Description
+   5.  Handling the Initial ICE Description and Generating the Initial
+           ICE Response
+   6.  Handling the Initial ICE Response
+   7.  Forming Checklists
+   8.  Performing Connectivity Checks
+   9.  Gathering and Conveying Newly Gathered Local Candidates
+   10. Pairing Newly Gathered Local Candidates
+   11. Receiving Trickled Candidates
+   12. Inserting Trickled Candidate Pairs into a Checklist
+   13. Generating an End-of-Candidates Indication
+   14. Receiving an End-of-Candidates Indication
+   15. Subsequent Exchanges and ICE Restarts
+   16. Half Trickle
+   17. Preserving Candidate Order While Trickling
+   18. Requirements for Using Protocols
+   19. IANA Considerations
+   20. Security Considerations
+   21. References
+     21.1.  Normative References
+     21.2.  Informative References
+   Appendix A.  Interaction with Regular ICE
+   Appendix B.  Interaction with ICE-Lite
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The Interactive Connectivity Establishment (ICE) protocol [RFC8445]
+   describes how an ICE agent gathers candidates, exchanges candidates
+   with a peer ICE agent, and creates candidate pairs.  Once the pairs
+   have been gathered, the ICE agent will perform connectivity checks
+   and eventually nominate and select pairs that will be used for
+   sending and receiving data within a communication session.
+
+   Following the procedures in [RFC8445] can lead to somewhat lengthy
+   establishment times for communication sessions, because candidate
+   gathering often involves querying Session Traversal Utilities for NAT
+   (STUN) servers [RFC5389] and allocating relayed candidates on
+   Traversal Using Relay NAT (TURN) servers [RFC5766].  Although many
+   ICE procedures can be completed in parallel, the pacing requirements
+   from [RFC8445] still need to be followed.
+
+   This document defines "Trickle ICE", a supplementary mode of ICE
+   operation in which candidates can be exchanged incrementally as soon
+   as they become available (and simultaneously with the gathering of
+   other candidates).  Connectivity checks can also start as soon as
+   candidate pairs have been created.  Because Trickle ICE enables
+   candidate gathering and connectivity checks to be done in parallel,
+   the method can considerably accelerate the process of establishing a
+   communication session.
+
+   This document also defines how to discover support for Trickle ICE,
+   how the procedures in [RFC8445] are modified or supplemented when
+   using Trickle ICE, and how a Trickle ICE agent can interoperate with
+   an ICE agent compliant to [RFC8445].
+
+   This document does not define any protocol-specific usage of Trickle
+   ICE.  Instead, protocol-specific details for Trickle ICE are defined
+   in separate usage documents.  Examples of such documents are
+   [RFC8840] (which defines usage with the Session Initiation Protocol
+   (SIP) [RFC3261] and the Session Description Protocol (SDP) [RFC4566])
+   and [XEP-0176] (which defines usage with the Extensible Messaging and
+   Presence Protocol (XMPP) [RFC6120]).  However, some of the examples
+   in the document use SDP and the Offer/Answer model [RFC3264] to
+   explain the underlying concepts.
+
+   The following diagram illustrates a successful Trickle ICE exchange
+   with a using protocol that follows the Offer/Answer model:
+
+           Alice                                            Bob
+             |                     Offer                     |
+             |---------------------------------------------->|
+             |            Additional Candidates              |
+             |---------------------------------------------->|
+             |                     Answer                    |
+             |<----------------------------------------------|
+             |            Additional Candidates              |
+             |<----------------------------------------------|
+             | Additional Candidates and Connectivity Checks |
+             |<--------------------------------------------->|
+             |<========== CONNECTION ESTABLISHED ===========>|
+
+                               Figure 1: Flow
+
+   The main body of this document is structured to describe the behavior
+   of Trickle ICE agents in roughly the order of operations and
+   interactions during an ICE session:
+
+   1.  Determining support for Trickle ICE
+
+   2.  Generating the initial ICE description
+
+   3.  Handling the initial ICE description and generating the initial
+       ICE response
+
+   4.  Handling the initial ICE response
+
+   5.  Forming checklists, pruning candidates, performing connectivity
+       checks, etc.
+
+   6.  Gathering and conveying candidates after the initial ICE
+       description and response
+
+   7.  Handling inbound trickled candidates
+
+   8.  Generating and handling the end-of-candidates indication
+
+   9.  Handling ICE restarts
+
+   There is quite a bit of operational experience with the technique
+   behind Trickle ICE, going back as far as 2005 (when the XMPP Jingle
+   extension defined a "dribble mode" as specified in [XEP-0176]); this
+   document incorporates feedback from those who have implemented and
+   deployed the technique over the years.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This specification makes use of all terminology defined for
+   Interactive Connectivity Establishment in [RFC8445].  In addition, it
+   defines the following terms:
+
+   Empty Checklist:  A checklist that initially does not contain any
+      candidate pairs because they will be incrementally added as they
+      are trickled.  (This scenario does not arise with a regular ICE
+      agent, because all candidate pairs are known when the agent
+      creates the checklist set.)
+
+   Full Trickle:  The typical mode of operation for Trickle ICE agents,
+      in which the initial ICE description can include any number of
+      candidates (even zero candidates) and does not need to include a
+      full generation of candidates as in half trickle.
+
+   Generation:  All of the candidates conveyed within an ICE session
+      (correlated with a particular Username Fragment and Password
+      combination).
+
+   Half Trickle:  A Trickle ICE mode of operation in which the initiator
+      gathers a full generation of candidates strictly before creating
+      and conveying the initial ICE description.  Once conveyed, this
+      candidate information can be processed by regular ICE agents,
+      which do not require support for Trickle ICE.  It also allows
+      Trickle-ICE-capable responders to still gather candidates and
+      perform connectivity checks in a non-blocking way, thus providing
+      roughly "half" the advantages of Trickle ICE.  The half-trickle
+      mechanism is mostly meant for use when the responder's support for
+      Trickle ICE cannot be confirmed prior to conveying the initial ICE
+      description.
+
+   ICE Description:  Any attributes related to the ICE session (other
+      than candidates) required to configure an ICE agent.  These
+      include but are not limited to the Username Fragment, the
+      Password, and other attributes.
+
+   Trickled Candidates:  Candidates that a Trickle ICE agent conveys
+      after conveying or responding to the initial ICE description, but
+      within the same ICE session.  Trickled candidates can be conveyed
+      in parallel with candidate gathering and connectivity checks.
+
+   Trickling:  The act of incrementally conveying trickled candidates.
+
+3.  Determining Support for Trickle ICE
+
+   To fully support Trickle ICE, using protocols SHOULD incorporate one
+   of the following mechanisms so that implementations can determine
+   whether Trickle ICE is supported:
+
+   1.  Provide a capabilities discovery method so that agents can verify
+       support of Trickle ICE prior to initiating a session (XMPP's
+       Service Discovery [XEP-0030] is one such mechanism).
+
+   2.  Make support for Trickle ICE mandatory so that user agents can
+       assume support.
+
+   If a using protocol does not provide a method of determining ahead of
+   time whether Trickle ICE is supported, agents can make use of the
+   half-trickle procedure described in Section 16.
+
+   Prior to conveying the initial ICE description, agents that implement
+   using protocols that support capabilities discovery can attempt to
+   verify whether or not the remote party supports Trickle ICE.  If an
+   agent determines that the remote party does not support Trickle ICE,
+   it MUST fall back to using regular ICE or abandon the entire session.
+
+   Even if a using protocol does not include a capabilities discovery
+   method, a user agent can provide an indication within the ICE
+   description that it supports Trickle ICE by communicating an ICE
+   option of 'trickle'.  This token MUST be provided either at the
+   session level or, if at the data stream level, for every data stream
+   (an agent MUST NOT specify Trickle ICE support for some data streams
+   but not others).  Note: The encoding of the 'trickle' ICE option, and
+   the message(s) used to carry it to the peer, are protocol specific;
+   for instance, the encoding for SDP [RFC4566] is defined in [RFC8840].
+
+   Dedicated discovery semantics and half trickle are needed only prior
+   to initiation of an ICE session.  After an ICE session is established
+   and Trickle ICE support is confirmed for both parties, either agent
+   can use full trickle for subsequent exchanges (see also Section 15).
+
+4.  Generating the Initial ICE Description
+
+   An ICE agent can start gathering candidates as soon as it has an
+   indication that communication is imminent (e.g., a user-interface cue
+   or an explicit request to initiate a communication session).  Unlike
+   in regular ICE, in Trickle ICE implementations do not need to gather
+   candidates in a blocking manner.  Therefore, unless half trickle is
+   being used, the user experience is improved if the initiating agent
+   generates and transmits its initial ICE description as early as
+   possible (thus enabling the remote party to start gathering and
+   trickling candidates).
+
+   An initiator MAY include any mix of candidates when conveying the
+   initial ICE description.  This includes the possibility of conveying
+   all the candidates the initiator plans to use (as in half trickle),
+   conveying only a publicly reachable IP address (e.g., a candidate at
+   a data relay that is known to not be behind a firewall), or conveying
+   no candidates at all (in which case the initiator can obtain the
+   responder's initial candidate list sooner, and the responder can
+   begin candidate gathering more quickly).
+
+   For candidates included in the initial ICE description, the methods
+   for calculating priorities and foundations, determining redundancy of
+   candidates, and the like work just as in regular ICE [RFC8445].
+
+5.  Handling the Initial ICE Description and Generating the Initial ICE
+    Response
+
+   When a responder receives the initial ICE description, it will first
+   check if the ICE description or initiator indicates support for
+   Trickle ICE as explained in Section 3.  If not, the responder MUST
+   process the initial ICE description according to regular ICE
+   procedures [RFC8445] (or, if no ICE support is detected at all,
+   according to relevant processing rules for the using protocol, such
+   as Offer/Answer processing rules [RFC3264]).  However, if support for
+   Trickle ICE is confirmed, a responder will automatically assume
+   support for regular ICE as well.
+
+   If the initial ICE description indicates support for Trickle ICE, the
+   responder will determine its role and start gathering and
+   prioritizing candidates; while doing so, it will also respond by
+   conveying an initial ICE response, so that both the initiator and the
+   responder can form checklists and begin connectivity checks.
+
+   A responder can respond to the initial ICE description at any point
+   while gathering candidates.  The initial ICE response MAY contain any
+   set of candidates, including all candidates or no candidates.  (The
+   benefit of including no candidates is to convey the initial ICE
+   response as quickly as possible, so that both parties can consider
+   the ICE session to be under active negotiation as soon as possible.)
+
+   As noted in Section 3, in using protocols that use SDP, the initial
+   ICE response can indicate support for Trickle ICE by including a
+   token of 'trickle' in the ice-options attribute.
+
+6.  Handling the Initial ICE Response
+
+   When processing the initial ICE response, the initiator follows
+   regular ICE procedures to determine its role, after which it forms
+   checklists (Section 7) and performs connectivity checks (Section 8).
+
+7.  Forming Checklists
+
+   According to regular ICE procedures [RFC8445], in order for candidate
+   pairing to be possible and for redundant candidates to be pruned, the
+   candidates would need to be provided in the initial ICE description
+   and initial ICE response.  By contrast, under Trickle ICE, checklists
+   can be empty until candidates are conveyed or received.  Therefore, a
+   Trickle ICE agent handles checklist formation and candidate pairing
+   in a slightly different way than a regular ICE agent: the agent still
+   forms the checklists, but it populates a given checklist only after
+   it actually has candidate pairs for that checklist.  Every checklist
+   is initially placed in the Running state, even if the checklist is
+   empty (this is consistent with Section 6.1.2.1 of [RFC8445]).
+
+8.  Performing Connectivity Checks
+
+   As specified in [RFC8445], whenever timer Ta fires, only checklists
+   in the Running state will be picked when scheduling connectivity
+   checks for candidate pairs.  Therefore, a Trickle ICE agent MUST keep
+   each checklist in the Running state as long as it expects candidate
+   pairs to be incrementally added to the checklist.  After that, the
+   checklist state is set according to the procedures in [RFC8445].
+
+   Whenever timer Ta fires and an empty checklist is picked, no action
+   is performed for the list.  Without waiting for timer Ta to expire
+   again, the agent selects the next checklist in the Running state, in
+   accordance with Section 6.1.4.2 of [RFC8445].
+
+   Section 7.2.5.4 of [RFC8445] requires that agents update checklists
+   and timer states upon completing a connectivity check transaction.
+   During such an update, regular ICE agents would set the state of a
+   checklist to Failed if both of the following two conditions are
+   satisfied:
+
+   *  all of the pairs in the checklist are in either the Failed state
+      or the Succeeded state; and
+
+   *  there is not a pair in the valid list for each component of the
+      data stream.
+
+   With Trickle ICE, the above situation would often occur when
+   candidate gathering and trickling are still in progress, even though
+   it is quite possible that future checks will succeed.  For this
+   reason, Trickle ICE agents add the following conditions to the above
+   list:
+
+   *  all candidate gathering has completed, and the agent is not
+      expecting to discover any new local candidates; and
+
+   *  the remote agent has conveyed an end-of-candidates indication for
+      that checklist as described in Section 13.
+
+9.  Gathering and Conveying Newly Gathered Local Candidates
+
+   After Trickle ICE agents have conveyed initial ICE descriptions and
+   initial ICE responses, they will most likely continue gathering new
+   local candidates as STUN, TURN, and other non-host candidate
+   gathering mechanisms begin to yield results.  Whenever an agent
+   discovers such a new candidate, it will compute its priority, type,
+   foundation, and component ID according to regular ICE procedures.
+
+   The new candidate is then checked for redundancy against the existing
+   list of local candidates.  If its transport address and base match
+   those of an existing candidate, it will be considered redundant and
+   will be ignored.  This would often happen for server-reflexive
+   candidates that match the host addresses they were obtained from
+   (e.g., when the latter are public IPv4 addresses).  Contrary to
+   regular ICE, Trickle ICE agents will consider the new candidate
+   redundant regardless of its priority.
+
+   Next, the agent "trickles" the newly discovered candidate(s) to the
+   remote agent.  The actual delivery of the new candidates is handled
+   by a using protocol such as SIP or XMPP.  Trickle ICE imposes no
+   restrictions on the way this is done (e.g., some using protocols
+   might choose not to trickle updates for server-reflexive candidates
+   and instead rely on the discovery of peer-reflexive ones).
+
+   When candidates are trickled, the using protocol MUST deliver each
+   candidate (and any end-of-candidates indication as described in
+   Section 13) to the receiving Trickle ICE implementation exactly once
+   and in the same order it was conveyed.  If the using protocol
+   provides any candidate retransmissions, they need to be hidden from
+   the ICE implementation.
+
+   Also, candidate trickling needs to be correlated to a specific ICE
+   session, so that if there is an ICE restart, any delayed updates for
+   a previous session can be recognized as such and ignored by the
+   receiving party.  For example, using protocols that signal candidates
+   via SDP might include a Username Fragment value in the corresponding
+   a=candidate line, such as:
+
+     a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
+
+   Or, as another example, WebRTC implementations might include a
+   Username Fragment in the JavaScript objects that represent
+   candidates.
+
+   Note: The using protocol needs to provide a mechanism for both
+   parties to indicate and agree on the ICE session in force (as
+   identified by the Username Fragment and Password combination), so
+   that they have a consistent view of which candidates are to be
+   paired.  This is especially important in the case of ICE restarts
+   (see Section 15).
+
+   Note: A using protocol might prefer not to trickle server-reflexive
+   candidates to entities that are known to be publicly accessible and
+   where sending a direct STUN binding request is likely to reach the
+   destination faster than the trickle update that travels through the
+   signaling path.
+
+10.  Pairing Newly Gathered Local Candidates
+
+   As a Trickle ICE agent gathers local candidates, it needs to form
+   candidate pairs; this works as described in the ICE specification
+   [RFC8445], with the following provisos:
+
+   1.  A Trickle ICE agent MUST NOT pair a local candidate until it has
+       been trickled to the remote party.
+
+   2.  Once the agent has conveyed the local candidate to the remote
+       party, the agent checks if any remote candidates are currently
+       known for this same stream and component.  If not, the agent
+       merely adds the new candidate to the list of local candidates
+       (without pairing it).
+
+   3.  Otherwise, if the agent has already learned of one or more remote
+       candidates for this stream and component, it attempts to pair the
+       new local candidate as described in the ICE specification
+       [RFC8445].
+
+   4.  If a newly formed pair has a local candidate whose type is
+       server-reflexive, the agent MUST replace the local candidate with
+       its base before completing the relevant redundancy tests.
+
+   5.  The agent prunes redundant pairs by following the rules in
+       Section 6.1.2.4 of [RFC8445] but checks existing pairs only if
+       they have a state of Waiting or Frozen; this avoids removal of
+       pairs for which connectivity checks are in flight (a state of
+       In-Progress) or for which connectivity checks have already
+       yielded a definitive result (a state of Succeeded or Failed).
+
+   6.  If, after completing the relevant redundancy tests, the checklist
+       where the pair is to be added already contains the maximum number
+       of candidate pairs (100 by default as per [RFC8445]), the agent
+       SHOULD discard any pairs in the Failed state to make room for the
+       new pair.  If there are no such pairs, the agent SHOULD discard a
+       pair with a lower priority than the new pair in order to make
+       room for the new pair, until the number of pairs is equal to the
+       maximum number of pairs.  This processing is consistent with
+       Section 6.1.2.5 of [RFC8445].
+
+11.  Receiving Trickled Candidates
+
+   At any time during an ICE session, a Trickle ICE agent might receive
+   new candidates from the remote agent, from which it will attempt to
+   form a candidate pair; this works as described in the ICE
+   specification [RFC8445], with the following provisos:
+
+   1.  The agent checks if any local candidates are currently known for
+       this same stream and component.  If not, the agent merely adds
+       the new candidate to the list of remote candidates (without
+       pairing it).
+
+   2.  Otherwise, if the agent has already gathered one or more local
+       candidates for this stream and component, it attempts to pair the
+       new remote candidate as described in the ICE specification
+       [RFC8445].
+
+   3.  If a newly formed pair has a local candidate whose type is
+       server-reflexive, the agent MUST replace the local candidate with
+       its base before completing the redundancy check in the next step.
+
+   4.  The agent prunes redundant pairs as described below but checks
+       existing pairs only if they have a state of Waiting or Frozen;
+       this avoids removal of pairs for which connectivity checks are in
+       flight (a state of In-Progress) or for which connectivity checks
+       have already yielded a definitive result (a state of Succeeded or
+       Failed).
+
+       A.  If the agent finds a redundancy between two pairs and one of
+           those pairs contains a newly received remote candidate whose
+           type is peer-reflexive, the agent SHOULD discard the pair
+           containing that candidate, set the priority of the existing
+           pair to the priority of the discarded pair, and re-sort the
+           checklist.  (This policy helps to eliminate problems with
+           remote peer-reflexive candidates for which a STUN Binding
+           request is received before signaling of the candidate is
+           trickled to the receiving agent, such as a different view of
+           pair priorities between the local agent and the remote agent,
+           because the same candidate could be perceived as peer-
+           reflexive by one agent and as server-reflexive by the other
+           agent.)
+
+       B.  The agent then applies the rules defined in Section 6.1.2.4
+           of [RFC8445].
+
+   5.  If, after completing the relevant redundancy tests, the checklist
+       where the pair is to be added already contains the maximum number
+       of candidate pairs (100 by default as per [RFC8445]), the agent
+       SHOULD discard any pairs in the Failed state to make room for the
+       new pair.  If there are no such pairs, the agent SHOULD discard a
+       pair with a lower priority than the new pair in order to make
+       room for the new pair, until the number of pairs is equal to the
+       maximum number of pairs.  This processing is consistent with
+       Section 6.1.2.5 of [RFC8445].
+
+12.  Inserting Trickled Candidate Pairs into a Checklist
+
+   After a local agent has trickled a candidate and formed a candidate
+   pair from that local candidate (Section 9), or after a remote agent
+   has received a trickled candidate and formed a candidate pair from
+   that remote candidate (Section 11), a Trickle ICE agent adds the new
+   candidate pair to a checklist as defined in this section.
+
+   As an aid to understanding the procedures defined in this section,
+   consider the following tabular representation of all checklists in an
+   agent (note that initially for one of the foundations, i.e., f5,
+   there are no candidate pairs):
+
+               +=================+====+====+====+====+====+
+               |                 | f1 | f2 | f3 | f4 | f5 |
+               +=================+====+====+====+====+====+
+               | s1 (Audio.RTP)  | F  | F  | F  |    |    |
+               +-----------------+----+----+----+----+----+
+               | s2 (Audio.RTCP) | F  | F  | F  | F  |    |
+               +-----------------+----+----+----+----+----+
+               | s3 (Video.RTP)  | F  |    |    |    |    |
+               +-----------------+----+----+----+----+----+
+               | s4 (Video.RTCP) | F  |    |    |    |    |
+               +-----------------+----+----+----+----+----+
+
+                   Table 1: Example of Checklist State
+
+   Each row in the table represents a component for a given data stream
+   (e.g., s1 and s2 might be the RTP and RTP Control Protocol (RTCP)
+   components for audio) and thus a single checklist in the checklist
+   set.  Each column represents one foundation.  Each cell represents
+   one candidate pair.  In the tables shown in this section, "F" stands
+   for "frozen", "W" stands for "waiting", and "S" stands for
+   "succeeded"; in addition, "^^" is used to notate newly added
+   candidate pairs.
+
+   When an agent commences ICE processing, in accordance with
+   Section 6.1.2.6 of [RFC8445], for each foundation it will unfreeze
+   the pair with the lowest component ID and, if the component IDs are
+   equal, with the highest priority (this is the topmost candidate pair
+   in every column).  This initial state is shown in the following
+   table.
+
+               +=================+====+====+====+====+====+
+               |                 | f1 | f2 | f3 | f4 | f5 |
+               +=================+====+====+====+====+====+
+               | s1 (Audio.RTP)  | W  | W  | W  |    |    |
+               +-----------------+----+----+----+----+----+
+               | s2 (Audio.RTCP) | F  | F  | F  | W  |    |
+               +-----------------+----+----+----+----+----+
+               | s3 (Video.RTP)  | F  |    |    |    |    |
+               +-----------------+----+----+----+----+----+
+               | s4 (Video.RTCP) | F  |    |    |    |    |
+               +-----------------+----+----+----+----+----+
+
+                     Table 2: Initial Checklist State
+
+   Then, as the checks proceed (see Section 7.2.5.4 of [RFC8445]), for
+   each pair that enters the Succeeded state (denoted here by "S"), the
+   agent will unfreeze all pairs for all data streams with the same
+   foundation (e.g., if the pair in column 1, row 1 succeeds then the
+   agent will unfreeze the pairs in column 1, rows 2, 3, and 4).
+
+               +=================+====+====+====+====+====+
+               |                 | f1 | f2 | f3 | f4 | f5 |
+               +=================+====+====+====+====+====+
+               | s1 (Audio.RTP)  | S  | W  | W  |    |    |
+               +-----------------+----+----+----+----+----+
+               | s2 (Audio.RTCP) | W  | F  | F  | W  |    |
+               +-----------------+----+----+----+----+----+
+               | s3 (Video.RTP)  | W  |    |    |    |    |
+               +-----------------+----+----+----+----+----+
+               | s4 (Video.RTCP) | W  |    |    |    |    |
+               +-----------------+----+----+----+----+----+
+
+                 Table 3: Checklist State with Succeeded
+                              Candidate Pair
+
+   Trickle ICE preserves all of these rules as they apply to "static"
+   checklist sets.  This implies that if a Trickle ICE agent were to
+   begin connectivity checks with all of its pairs already present, the
+   way that pair states change is indistinguishable from that of a
+   regular ICE agent.
+
+   Of course, the major difference with Trickle ICE is that checklist
+   sets can be dynamically updated because candidates can arrive after
+   connectivity checks have started.  When this happens, an agent sets
+   the state of the newly formed pair as described below.
+
+   Rule 1: If the newly formed pair has the lowest component ID and, if
+   the component IDs are equal, the highest priority of any candidate
+   pair for this foundation (i.e., if it is the topmost pair in the
+   column), set the state to Waiting.  For example, this would be the
+   case if the newly formed pair were placed in column 5, row 1.  This
+   rule is consistent with Section 6.1.2.6 of [RFC8445].
+
+               +=================+====+====+====+====+=====+
+               |                 | f1 | f2 | f3 | f4 | f5  |
+               +=================+====+====+====+====+=====+
+               | s1 (Audio.RTP)  | S  | W  | W  |    | ^W^ |
+               +-----------------+----+----+----+----+-----+
+               | s2 (Audio.RTCP) | W  | F  | F  | W  |     |
+               +-----------------+----+----+----+----+-----+
+               | s3 (Video.RTP)  | W  |    |    |    |     |
+               +-----------------+----+----+----+----+-----+
+               | s4 (Video.RTCP) | W  |    |    |    |     |
+               +-----------------+----+----+----+----+-----+
+
+                    Table 4: Checklist State with Newly
+                            Formed Pair, Rule 1
+
+   Rule 2: If there is at least one pair in the Succeeded state for this
+   foundation, set the state to Waiting.  For example, this would be the
+   case if the pair in column 5, row 1 succeeded and the newly formed
+   pair were placed in column 5, row 2.  This rule is consistent with
+   Section 7.2.5.3.3 of [RFC8445].
+
+               +=================+====+====+====+====+=====+
+               |                 | f1 | f2 | f3 | f4 | f5  |
+               +=================+====+====+====+====+=====+
+               | s1 (Audio.RTP)  | S  | W  | W  |    | S   |
+               +-----------------+----+----+----+----+-----+
+               | s2 (Audio.RTCP) | W  | F  | F  | W  | ^W^ |
+               +-----------------+----+----+----+----+-----+
+               | s3 (Video.RTP)  | W  |    |    |    |     |
+               +-----------------+----+----+----+----+-----+
+               | s4 (Video.RTCP) | W  |    |    |    |     |
+               +-----------------+----+----+----+----+-----+
+
+                    Table 5: Checklist State with Newly
+                            Formed Pair, Rule 2
+
+   Rule 3: In all other cases, set the state to Frozen.  For example,
+   this would be the case if the newly formed pair were placed in column
+   3, row 3.
+
+               +=================+====+====+=====+====+====+
+               |                 | f1 | f2 | f3  | f4 | f5 |
+               +=================+====+====+=====+====+====+
+               | s1 (Audio.RTP)  | S  | W  | W   |    | S  |
+               +-----------------+----+----+-----+----+----+
+               | s2 (Audio.RTCP) | W  | F  | F   | W  | W  |
+               +-----------------+----+----+-----+----+----+
+               | s3 (Video.RTP)  | W  |    | ^F^ |    |    |
+               +-----------------+----+----+-----+----+----+
+               | s4 (Video.RTCP) | W  |    |     |    |    |
+               +-----------------+----+----+-----+----+----+
+
+                    Table 6: Checklist State with Newly
+                            Formed Pair, Rule 3
+
+13.  Generating an End-of-Candidates Indication
+
+   Once all candidate gathering is completed or expires for an ICE
+   session associated with a specific data stream, the agent will
+   generate an "end-of-candidates" indication for that session and
+   convey it to the remote agent via the signaling channel.  Although
+   the exact form of the indication depends on the using protocol, the
+   indication MUST specify the generation (Username Fragment and
+   Password combination), so that an agent can correlate the end-of-
+   candidates indication with a particular ICE session.  The indication
+   can be conveyed in the following ways:
+
+   *  As part of an initiation request (which would typically be the
+      case with the initial ICE description for half trickle)
+
+   *  Along with the last candidate an agent can send for a stream
+
+   *  As a standalone notification (e.g., after STUN Binding requests or
+      TURN Allocate requests to a server time out and the agent is no
+      longer actively gathering candidates)
+
+   Conveying an end-of-candidates indication in a timely manner is
+   important in order to avoid ambiguities and speed up the conclusion
+   of ICE processing.  In particular:
+
+   *  A controlled Trickle ICE agent SHOULD convey an end-of-candidates
+      indication after it has completed gathering for a data stream,
+      unless ICE processing terminates before the agent has had a chance
+      to complete gathering.
+
+   *  A controlling agent MAY conclude ICE processing prior to conveying
+      end-of-candidates indications for all streams.  However, it is
+      RECOMMENDED for a controlling agent to convey end-of-candidates
+      indications whenever possible for the sake of consistency and to
+      keep middleboxes and controlled agents up-to-date on the state of
+      ICE processing.
+
+   When conveying an end-of-candidates indication during trickling
+   (rather than as a part of the initial ICE description or a response
+   thereto), it is the responsibility of the using protocol to define
+   methods for associating the indication with one or more specific data
+   streams.
+
+   An agent MAY also choose to generate an end-of-candidates indication
+   before candidate gathering has actually completed, if the agent
+   determines that gathering has continued for more than an acceptable
+   period of time.  However, an agent MUST NOT convey any more
+   candidates after it has conveyed an end-of-candidates indication.
+
+   When performing half trickle, an agent SHOULD convey an end-of-
+   candidates indication together with its initial ICE description
+   unless it is planning to potentially trickle additional candidates
+   (e.g., in case the remote party turns out to support Trickle ICE).
+
+   After an agent conveys the end-of-candidates indication, it will
+   update the state of the corresponding checklist as explained in
+   Section 8.  Past that point, an agent MUST NOT trickle any new
+   candidates within this ICE session.  Therefore, adding new candidates
+   to the negotiation is possible only through an ICE restart (see
+   Section 15).
+
+   This specification does not override regular ICE semantics for
+   concluding ICE processing.  Therefore, even if end-of-candidates
+   indications are conveyed, an agent will still need to go through pair
+   nomination.  Also, if pairs have been nominated for components and
+   data streams, ICE processing MAY still conclude even if end-of-
+   candidates indications have not been received for all streams.  In
+   all cases, an agent MUST NOT trickle any new candidates within an ICE
+   session after nomination of a candidate pair as described in
+   Section 8.1.1 of [RFC8445].
+
+14.  Receiving an End-of-Candidates Indication
+
+   Receiving an end-of-candidates indication enables an agent to update
+   checklist states and, in case valid pairs do not exist for every
+   component in every data stream, determine that ICE processing has
+   failed.  It also enables an agent to speed up the conclusion of ICE
+   processing when a candidate pair has been validated but uses a lower-
+   preference transport such as TURN.  In such situations, an
+   implementation MAY choose to wait and see if higher-priority
+   candidates are received; in this case, the end-of-candidates
+   indication provides a notification that such candidates are not
+   forthcoming.
+
+   When an agent receives an end-of-candidates indication for a specific
+   data stream, it will update the state of the relevant checklist as
+   per Section 8 (which might lead to some checklists being marked as
+   Failed).  If the checklist is still in the Running state after the
+   update, the agent will note that an end-of-candidates indication has
+   been received and take it into account in future updates to the
+   checklist.
+
+   After an agent has received an end-of-candidates indication, it MUST
+   ignore any newly received candidates for that data stream or data
+   session.
+
+15.  Subsequent Exchanges and ICE Restarts
+
+   Before conveying an end-of-candidates indication, either agent MAY
+   convey subsequent candidate information at any time allowed by the
+   using protocol.  When this happens, agents will use semantics from
+   [RFC8445] (e.g., checking of the Username Fragment and Password
+   combination) to determine whether or not the new candidate
+   information requires an ICE restart.
+
+   If an ICE restart occurs, the agents can assume that Trickle ICE is
+   still supported if support was determined previously; thus, they can
+   engage in Trickle ICE behavior as they would in an initial exchange
+   of ICE descriptions where support was determined through a
+   capabilities discovery method.
+
+16.  Half Trickle
+
+   In half trickle, the initiator conveys the initial ICE description
+   with a usable but not necessarily full generation of candidates.
+   This ensures that the ICE description can be processed by a regular
+   ICE responder and is mostly meant for use in cases where support for
+   Trickle ICE cannot be confirmed prior to conveying the initial ICE
+   description.  The initial ICE description indicates support for
+   Trickle ICE, so that the responder can respond with something less
+   than a full generation of candidates and then trickle the rest.  The
+   initial ICE description for half trickle can contain an end-of-
+   candidates indication, although this is not mandatory because if
+   trickle support is confirmed, then the initiator can choose to
+   trickle additional candidates before it conveys an end-of-candidates
+   indication.
+
+   The half-trickle mechanism can be used in cases where there is no way
+   for an agent to verify in advance whether a remote party supports
+   Trickle ICE.  Because the initial ICE description contains a full
+   generation of candidates, it can thus be handled by a regular ICE
+   agent, while still allowing a Trickle ICE agent to use the
+   optimization defined in this specification.  This prevents
+   negotiation from failing in the former case while still giving
+   roughly half the Trickle ICE benefits in the latter.
+
+   Use of half trickle is only necessary during an initial exchange of
+   ICE descriptions.  After both parties have received an ICE
+   description from their peer, they can each reliably determine Trickle
+   ICE support and use it for all subsequent exchanges (see Section 15).
+
+   In some instances, using half trickle might bring more than just half
+   the improvement in terms of user experience.  This can happen when an
+   agent starts gathering candidates upon user-interface cues that the
+   user will soon be initiating an interaction, such as activity on a
+   keypad or the phone going off hook.  This would mean that some or all
+   of the candidate gathering could be completed before the agent
+   actually needs to convey the candidate information.  Because the
+   responder will be able to trickle candidates, both agents will be
+   able to start connectivity checks and complete ICE processing earlier
+   than with regular ICE and potentially even as early as with full
+   trickle.
+
+   However, such anticipation is not always possible.  For example, a
+   multipurpose user agent or a WebRTC web page where communication is a
+   non-central feature (e.g., calling a support line in case of a
+   problem with the main features) would not necessarily have a way of
+   distinguishing between call intentions and other user activity.  In
+   such cases, using full trickle is most likely to result in an ideal
+   user experience.  Even so, using half trickle would be an improvement
+   over regular ICE because it would result in a better experience for
+   responders.
+
+17.  Preserving Candidate Order While Trickling
+
+   One important aspect of regular ICE is that connectivity checks for a
+   specific foundation and component are attempted simultaneously by
+   both agents, so that any firewalls or NATs fronting the agents would
+   whitelist both endpoints and allow all except for the first
+   ("suicide") packets to go through.  This is also important to
+   unfreezing candidates at the right time.  While not crucial,
+   preserving this behavior in Trickle ICE is likely to improve ICE
+   performance.
+
+   To achieve this, when trickling candidates, agents SHOULD respect the
+   order of components as reflected by their component IDs; that is,
+   candidates for a given component SHOULD NOT be conveyed prior to
+   candidates for a component with a lower ID number within the same
+   foundation.  In addition, candidates SHOULD be paired, following the
+   procedures in Section 12, in the same order they are conveyed.
+
+   For example, the following SDP description contains two components
+   (RTP and RTCP) and two foundations (host and server-reflexive):
+
+     v=0
+     o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
+     s=
+     c=IN IP4 10.0.1.1
+     t=0 0
+     a=ice-pwd:asd88fgpdd777uzjYhagZg
+     a=ice-ufrag:8hhY
+     m=audio 5000 RTP/AVP 0
+     a=rtpmap:0 PCMU/8000
+     a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
+     a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
+     a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
+         raddr 10.0.1.1 rport 8998
+     a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
+         raddr 10.0.1.1 rport 8998
+
+   For this candidate information, the RTCP host candidate would not be
+   conveyed prior to the RTP host candidate.  Similarly, the RTP server-
+   reflexive candidate would be conveyed together with or prior to the
+   RTCP server-reflexive candidate.
+
+18.  Requirements for Using Protocols
+
+   In order to fully enable the use of Trickle ICE, this specification
+   defines the following requirements for using protocols.
+
+   *  A using protocol SHOULD provide a way for parties to advertise and
+      discover support for Trickle ICE before an ICE session begins (see
+      Section 3).
+
+   *  A using protocol MUST provide methods for incrementally conveying
+      (i.e., "trickling") additional candidates after conveying the
+      initial ICE description (see Section 9).
+
+   *  A using protocol MUST deliver each trickled candidate or end-of-
+      candidates indication exactly once and in the same order it was
+      conveyed (see Section 9).
+
+   *  A using protocol MUST provide a mechanism for both parties to
+      indicate and agree on the ICE session in force (see Section 9).
+
+   *  A using protocol MUST provide a way for parties to communicate the
+      end-of-candidates indication, which MUST specify the particular
+      ICE session to which the indication applies (see Section 13).
+
+19.  IANA Considerations
+
+   IANA has registered the following ICE option in the "ICE Options"
+   subregistry of the "Interactive Connectivity Establishment (ICE)
+   registry", following the procedures defined in [RFC6336].
+
+   ICE Option:  trickle
+
+   Contact:  IESG <iesg@ietf.org>
+
+   Change controller:  IESG
+
+   Description:  An ICE option of 'trickle' indicates support for
+      incremental communication of ICE candidates.
+
+   Reference:  RFC 8838
+
+20.  Security Considerations
+
+   This specification inherits most of its semantics from [RFC8445], and
+   as a result, all security considerations described there apply to
+   Trickle ICE.
+
+   If the privacy implications of revealing host addresses on an
+   endpoint device are a concern (see, for example, the discussion in
+   [RFC8828] and in Section 19 of [RFC8445]), agents can generate ICE
+   descriptions that contain no candidates and then only trickle
+   candidates that do not reveal host addresses (e.g., relayed
+   candidates).
+
+21.  References
+
+21.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
+              Connectivity Establishment (ICE): A Protocol for Network
+              Address Translator (NAT) Traversal", RFC 8445,
+              DOI 10.17487/RFC8445, July 2018,
+              <https://www.rfc-editor.org/info/rfc8445>.
+
+21.2.  Informative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
+              J., and E. Lear, "Address Allocation for Private
+              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
+              February 1996, <https://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <https://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
+              Translation (NAT) Behavioral Requirements for Unicast
+              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
+              2007, <https://www.rfc-editor.org/info/rfc4787>.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              DOI 10.17487/RFC5389, October 2008,
+              <https://www.rfc-editor.org/info/rfc5389>.
+
+   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+              Relays around NAT (TURN): Relay Extensions to Session
+              Traversal Utilities for NAT (STUN)", RFC 5766,
+              DOI 10.17487/RFC5766, April 2010,
+              <https://www.rfc-editor.org/info/rfc5766>.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+              March 2011, <https://www.rfc-editor.org/info/rfc6120>.
+
+   [RFC6336]  Westerlund, M. and C. Perkins, "IANA Registry for
+              Interactive Connectivity Establishment (ICE) Options",
+              RFC 6336, DOI 10.17487/RFC6336, July 2011,
+              <https://www.rfc-editor.org/info/rfc6336>.
+
+   [RFC8828]  Uberti, J. and G. Shieh, "WebRTC IP Address Handling
+              Requirements", RFC 8828, DOI 10.17487/RFC8828, January
+              2021, <https://www.rfc-editor.org/info/rfc8828>.
+
+   [RFC8840]  Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
+              Session Initiation Protocol (SIP) Usage for Incremental
+              Provisioning of Candidates for the Interactive
+              Connectivity Establishment (Trickle ICE)", RFC 8840,
+              DOI 10.17487/RFC8840, January 2021,
+              <https://www.rfc-editor.org/info/rfc8840>.
+
+   [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
+              Andre, "XEP-0030: Service Discovery", XMPP Standards
+              Foundation, XEP-0030, June 2008.
+
+   [XEP-0176] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J.,
+              Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP
+              Transport Method", XMPP Standards Foundation, XEP-0176,
+              June 2009.
+
+Appendix A.  Interaction with Regular ICE
+
+   The ICE protocol was designed to be flexible enough to work in and
+   adapt to as many network environments as possible.  Despite that
+   flexibility, ICE as specified in [RFC8445] does not by itself support
+   Trickle ICE.  This section describes how trickling of candidates
+   interacts with ICE.
+
+   [RFC8445] describes the conditions required to update checklists and
+   timer states while an ICE agent is in the Running state.  These
+   conditions are verified upon transaction completion, and one of them
+   stipulates that:
+
+   |  if there is not a valid pair in the valid list for each component
+   |  of the data stream associated with the checklist, the state of the
+   |  checklist is set to Failed.
+
+   This could be a problem and cause ICE processing to fail prematurely
+   in a number of scenarios.  Consider the following case:
+
+   1.  Alice and Bob are both located in different networks with Network
+       Address Translation (NAT).  Alice and Bob themselves have
+       different addresses, but both networks use the same private
+       internet block (e.g., the "20-bit block" 172.16/12 specified in
+       [RFC1918]).
+
+   2.  Alice conveys to Bob the candidate 172.16.0.1, which also happens
+       to correspond to an existing host on Bob's network.
+
+   3.  Bob creates a candidate pair from his host candidate and
+       172.16.0.1, puts this one pair into a checklist, and starts
+       checks.
+
+   4.  These checks reach the host at 172.16.0.1 in Bob's network, which
+       responds with an ICMP "port unreachable" error; per [RFC8445],
+       Bob marks the transaction as Failed.
+
+   At this point, the checklist only contains a Failed pair, and the
+   valid list is empty.  This causes the data stream and potentially all
+   ICE processing to fail, even though Trickle ICE agents can
+   subsequently convey candidates that could succeed.
+
+   A similar race condition would occur if the initial ICE description
+   from Alice contains only candidates that can be determined as
+   unreachable from any of the candidates that Bob has gathered (e.g.,
+   this would be the case if Bob's candidates only contain IPv4
+   addresses and the first candidate that he receives from Alice is an
+   IPv6 one).
+
+   Another potential problem could arise when a non-Trickle ICE
+   implementation initiates an interaction with a Trickle ICE
+   implementation.  Consider the following case:
+
+   1.  Alice's client has a non-Trickle ICE implementation.
+
+   2.  Bob's client has support for Trickle ICE.
+
+   3.  Alice and Bob are behind NATs with address-dependent filtering
+       [RFC4787].
+
+   4.  Bob has two STUN servers, but one of them is currently
+       unreachable.
+
+   After Bob's agent receives Alice's initial ICE description, it would
+   immediately start connectivity checks.  It would also start gathering
+   candidates, which would take a long time because of the unreachable
+   STUN server.  By the time Bob's answer is ready and conveyed to
+   Alice, Bob's connectivity checks might have failed: until Alice gets
+   Bob's answer, she won't be able to start connectivity checks and
+   punch holes in her NAT.  The NAT would hence be filtering Bob's
+   checks as originating from an unknown endpoint.
+
+Appendix B.  Interaction with ICE-Lite
+
+   The behavior of ICE-lite agents that are capable of Trickle ICE does
+   not require any particular rules other than those already defined in
+   this specification and [RFC8445].  This section is hence provided
+   only for informational purposes.
+
+   An ICE-lite agent would generate candidate information as per
+   [RFC8445] and would indicate support for Trickle ICE.  Given that the
+   candidate information will contain a full generation of candidates,
+   it would also be accompanied by an end-of-candidates indication.
+
+   When performing full trickle, a full ICE implementation could convey
+   the initial ICE description or response thereto with no candidates.
+   After receiving a response that identifies the remote agent as an
+   ICE-lite implementation, the initiator can choose to not trickle any
+   additional candidates.  The same is also true in the case when the
+   ICE-lite agent initiates the interaction and the full ICE agent is
+   the responder.  In these cases, the connectivity checks would be
+   enough for the ICE-lite implementation to discover all potentially
+   useful candidates as peer-reflexive.  The following example
+   illustrates one such ICE session using SDP syntax:
+
+           ICE-Lite                                          Bob
+            Agent
+              |   Offer (a=ice-lite a=ice-options:trickle)    |
+              |---------------------------------------------->|
+              |                                               |no cand
+              |         Answer (a=ice-options:trickle)        |trickling
+              |<----------------------------------------------|
+              |              Connectivity Checks              |
+              |<--------------------------------------------->|
+     peer rflx|                                               |
+    cand disco|                                               |
+              |<========== CONNECTION ESTABLISHED ===========>|
+
+                             Figure 2: Example
+
+   In addition to reducing signaling traffic, this approach also removes
+   the need to discover STUN Bindings or make TURN allocations, which
+   can considerably lighten ICE processing.
+
+Acknowledgements
+
+   The authors would like to thank Bernard Aboba, Flemming Andreasen,
+   Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer
+   Holmberg, Ari Keränen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco,
+   Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin
+   Thomson, Brandon Williams, and Dale Worley for their reviews and
+   suggestions on improving this document.  Sarah Banks, Roni Even, and
+   David Mandelberg completed OPSDIR, GenART, and security reviews,
+   respectively.  Thanks also to Ari Keränen and Peter Thatcher in their
+   role as chairs and Ben Campbell in his role as responsible Area
+   Director.
+
+Authors' Addresses
+
+   Emil Ivov
+   8x8, Inc. / Jitsi
+   675 Creekside Way
+   Campbell, CA 95008
+   United States of America
+
+   Phone: +1 512 420 6968
+   Email: emcho@jitsi.org
+
+
+   Justin Uberti
+   Google
+   747 6th Street S
+   Kirkland, WA 98033
+   United States of America
+
+   Phone: +1 857 288 8888
+   Email: justin@uberti.name
+
+
+   Peter Saint-Andre
+   Mozilla
+   P.O. Box 787
+   Parker, CO 80134
+   United States of America
+
+   Phone: +1 720 256 6756
+   Email: stpeter@mozilla.com
+   URI:   https://www.mozilla.com/