draft-ietf-ice-trickle-21auth48.txt   rfc8838.txt 
Internet Engineering Task Force (IETF) E. Ivov Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 8452 Atlassian Request for Comments: 8838 Atlassian
Category: Standards Track J. Uberti Category: Standards Track J. Uberti
ISSN: 2070-1721 Google ISSN: 2070-1721 Google
P. Saint-Andre P. Saint-Andre
Mozilla Mozilla
February 2019 May 2020
Trickle ICE: Incremental Provisioning of Candidates Trickle ICE: Incremental Provisioning of Candidates for the Interactive
for the Interactive Connectivity Establishment (ICE) Protocol Connectivity Establishment (ICE) Protocol
Abstract Abstract
This document describes "Trickle ICE", an extension to the This document describes "Trickle ICE", an extension to the
Interactive Connectivity Establishment (ICE) protocol that enables Interactive Connectivity Establishment (ICE) protocol that enables
ICE agents to begin connectivity checks while they are still ICE agents to begin connectivity checks while they are still
gathering candidates, by incrementally exchanging candidates over gathering candidates, by incrementally exchanging candidates over
time instead of all at once. This method can considerably accelerate time instead of all at once. This method can considerably accelerate
the process of establishing a communication session. the process of establishing a communication session.
skipping to change at page 1, line 35 skipping to change at line 34
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8452. https://www.rfc-editor.org/info/rfc8838.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Determining Support for Trickle ICE . . . . . . . . . . . . . 5 3. Determining Support for Trickle ICE
4. Generating the Initial ICE Description . . . . . . . . . . . 6 4. Generating the Initial ICE Description
5. Handling the Initial ICE Description and Generating the 5. Handling the Initial ICE Description and Generating the Initial
Initial ICE Response . . . . . . . . . . . . . . . . . . . . 7 ICE Response
6. Handling the Initial ICE Response . . . . . . . . . . . . . . 7 6. Handling the Initial ICE Response
7. Forming Checklists . . . . . . . . . . . . . . . . . . . . . 7 7. Forming Checklists
8. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 8. Performing Connectivity Checks
9. Gathering and Conveying Newly Gathered Local Candidates . . . 9 9. Gathering and Conveying Newly Gathered Local Candidates
10. Pairing Newly Gathered Local Candidates . . . . . . . . . . . 10 10. Pairing Newly Gathered Local Candidates
11. Receiving Trickled Candidates . . . . . . . . . . . . . . . . 11 11. Receiving Trickled Candidates
12. Inserting Trickled Candidate Pairs into a Checklist . . . . . 12 12. Inserting Trickled Candidate Pairs into a Checklist
13. Generating an End-of-Candidates Indication . . . . . . . . . 15 13. Generating an End-of-Candidates Indication
14. Receiving an End-of-Candidates Indication . . . . . . . . . . 17 14. Receiving an End-of-Candidates Indication
15. Subsequent Exchanges and ICE Restarts . . . . . . . . . . . . 17 15. Subsequent Exchanges and ICE Restarts
16. Half Trickle . . . . . . . . . . . . . . . . . . . . . . . . 18 16. Half Trickle
17. Preserving Candidate Order While Trickling . . . . . . . . . 19 17. Preserving Candidate Order While Trickling
18. Requirements for Using Protocols . . . . . . . . . . . . . . 20 18. Requirements for Using Protocols
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 19. IANA Considerations
20. Security Considerations . . . . . . . . . . . . . . . . . . . 21 20. Security Considerations
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 21. References
21.1. Normative References . . . . . . . . . . . . . . . . . . 21 21.1. Normative References
21.2. Informative References . . . . . . . . . . . . . . . . . 21 21.2. Informative References
Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 23 Appendix A. Interaction with Regular ICE
Appendix B. Interaction with ICE-Lite . . . . . . . . . . . . . 24 Appendix B. Interaction with ICE-Lite
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses
1. Introduction 1. Introduction
The Interactive Connectivity Establishment (ICE) protocol [RFC8445] The Interactive Connectivity Establishment (ICE) protocol [RFC8445]
describes how an ICE agent gathers candidates, exchanges candidates describes how an ICE agent gathers candidates, exchanges candidates
with a peer ICE agent, and creates candidate pairs. Once the pairs with a peer ICE agent, and creates candidate pairs. Once the pairs
have been gathered, the ICE agent will perform connectivity checks have been gathered, the ICE agent will perform connectivity checks
and eventually nominate and select pairs that will be used for and eventually nominate and select pairs that will be used for
sending and receiving data within a communication session. sending and receiving data within a communication session.
skipping to change at page 3, line 24 skipping to change at line 116
communication session. communication session.
This document also defines how to discover support for Trickle ICE, This document also defines how to discover support for Trickle ICE,
how the procedures in [RFC8445] are modified or supplemented when how the procedures in [RFC8445] are modified or supplemented when
using Trickle ICE, and how a Trickle ICE agent can interoperate with using Trickle ICE, and how a Trickle ICE agent can interoperate with
an ICE agent compliant to [RFC8445]. an ICE agent compliant to [RFC8445].
This document does not define any protocol-specific usage of Trickle This document does not define any protocol-specific usage of Trickle
ICE. Instead, protocol-specific details for Trickle ICE are defined ICE. Instead, protocol-specific details for Trickle ICE are defined
in separate usage documents. Examples of such documents are in separate usage documents. Examples of such documents are
[SIP-TRICKLE-ICE] (which defines usage with the Session Initiation [RFC8840] (which defines usage with the Session Initiation Protocol
Protocol (SIP) [RFC3261] and the Session Description Protocol (SDP) (SIP) [RFC3261] and the Session Description Protocol (SDP) [RFC4566])
[RFC4566]) and [XEP-0176] (which defines usage with the Extensible and [XEP-0176] (which defines usage with the Extensible Messaging and
Messaging and Presence Protocol (XMPP) [RFC6120]). However, some of Presence Protocol (XMPP) [RFC6120]). However, some of the examples
the examples in the document use SDP and the Offer/Answer model in the document use SDP and the Offer/Answer model [RFC3264] to
[RFC3264] to explain the underlying concepts. explain the underlying concepts.
The following diagram illustrates a successful Trickle ICE exchange The following diagram illustrates a successful Trickle ICE exchange
with a using protocol that follows the Offer/Answer model: with a using protocol that follows the Offer/Answer model:
Alice Bob Alice Bob
| Offer | | Offer |
|---------------------------------------------->| |---------------------------------------------->|
| Additional Candidates | | Additional Candidates |
|---------------------------------------------->| |---------------------------------------------->|
| Answer | | Answer |
|<----------------------------------------------| |<----------------------------------------------|
| Additional Candidates | | Additional Candidates |
|<----------------------------------------------| |<----------------------------------------------|
| Additional Candidates and Connectivity Checks | | Additional Candidates and Connectivity Checks |
|<--------------------------------------------->| |<--------------------------------------------->|
|<========== CONNECTION ESTABLISHED ===========>| |<========== CONNECTION ESTABLISHED ===========>|
Figure 1: Flow Figure 1: Flow
The main body of this document is structured to describe the behavior The main body of this document is structured to describe the behavior
of Trickle ICE agents in roughly the order of operations and of Trickle ICE agents in roughly the order of operations and
interactions during an ICE session: interactions during an ICE session:
1. Determining support for Trickle ICE 1. Determining support for Trickle ICE
2. Generating the initial ICE description 2. Generating the initial ICE description
3. Handling the initial ICE description and generating the initial 3. Handling the initial ICE description and generating the initial
skipping to change at page 4, line 40 skipping to change at line 176
There is quite a bit of operational experience with the technique There is quite a bit of operational experience with the technique
behind Trickle ICE, going back as far as 2005 (when the XMPP Jingle behind Trickle ICE, going back as far as 2005 (when the XMPP Jingle
extension defined a "dribble mode" as specified in [XEP-0176]); this extension defined a "dribble mode" as specified in [XEP-0176]); this
document incorporates feedback from those who have implemented and document incorporates feedback from those who have implemented and
deployed the technique over the years. deployed the technique over the years.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification makes use of all terminology defined for This specification makes use of all terminology defined for
Interactive Connectivity Establishment in [RFC8445]. In addition, it Interactive Connectivity Establishment in [RFC8445]. In addition, it
defines the following terms: defines the following terms:
Empty Checklist: A checklist that initially does not contain any Empty Checklist: A checklist that initially does not contain any
candidate pairs because they will be incrementally added as they candidate pairs because they will be incrementally added as they
are trickled. (This scenario does not arise with a regular ICE are trickled. (This scenario does not arise with a regular ICE
agent, because all candidate pairs are known when the agent agent, because all candidate pairs are known when the agent
skipping to change at page 6, line 23 skipping to change at line 254
it MUST fall back to using regular ICE or abandon the entire session. it MUST fall back to using regular ICE or abandon the entire session.
Even if a using protocol does not include a capabilities discovery Even if a using protocol does not include a capabilities discovery
method, a user agent can provide an indication within the ICE method, a user agent can provide an indication within the ICE
description that it supports Trickle ICE by communicating an ICE description that it supports Trickle ICE by communicating an ICE
option of 'trickle'. This token MUST be provided either at the option of 'trickle'. This token MUST be provided either at the
session level or, if at the data stream level, for every data stream 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 (an agent MUST NOT specify Trickle ICE support for some data streams
but not others). Note: The encoding of the 'trickle' ICE option, and 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; the message(s) used to carry it to the peer, are protocol specific;
for instance, the encoding for SDP [RFC4566] is defined in for instance, the encoding for SDP [RFC4566] is defined in [RFC8840].
[SIP-TRICKLE-ICE].
Dedicated discovery semantics and half trickle are needed only prior Dedicated discovery semantics and half trickle are needed only prior
to initiation of an ICE session. After an ICE session is established to initiation of an ICE session. After an ICE session is established
and Trickle ICE support is confirmed for both parties, either agent and Trickle ICE support is confirmed for both parties, either agent
can use full trickle for subsequent exchanges (see also Section 15). can use full trickle for subsequent exchanges (see also Section 15).
4. Generating the Initial ICE Description 4. Generating the Initial ICE Description
An ICE agent can start gathering candidates as soon as it has an An ICE agent can start gathering candidates as soon as it has an
indication that communication is imminent (e.g., a user-interface cue indication that communication is imminent (e.g., a user-interface cue
skipping to change at page 8, line 30 skipping to change at line 356
is performed for the list. Without waiting for timer Ta to expire is performed for the list. Without waiting for timer Ta to expire
again, the agent selects the next checklist in the Running state, in again, the agent selects the next checklist in the Running state, in
accordance with Section 6.1.4.2 of [RFC8445]. accordance with Section 6.1.4.2 of [RFC8445].
Section 7.2.5.4 of [RFC8445] requires that agents update checklists Section 7.2.5.4 of [RFC8445] requires that agents update checklists
and timer states upon completing a connectivity check transaction. and timer states upon completing a connectivity check transaction.
During such an update, regular ICE agents would set the state of a During such an update, regular ICE agents would set the state of a
checklist to Failed if both of the following two conditions are checklist to Failed if both of the following two conditions are
satisfied: satisfied:
o all of the pairs in the checklist are in either the Failed state * all of the pairs in the checklist are in either the Failed state
or the Succeeded state; and or the Succeeded state; and
o there is not a pair in the valid list for each component of the * there is not a pair in the valid list for each component of the
data stream. data stream.
With Trickle ICE, the above situation would often occur when With Trickle ICE, the above situation would often occur when
candidate gathering and trickling are still in progress, even though candidate gathering and trickling are still in progress, even though
it is quite possible that future checks will succeed. For this it is quite possible that future checks will succeed. For this
reason, Trickle ICE agents add the following conditions to the above reason, Trickle ICE agents add the following conditions to the above
list: list:
o all candidate gathering has completed, and the agent is not * all candidate gathering has completed, and the agent is not
expecting to discover any new local candidates; and expecting to discover any new local candidates; and
o the remote agent has conveyed an end-of-candidates indication for * the remote agent has conveyed an end-of-candidates indication for
that checklist as described in Section 13. that checklist as described in Section 13.
9. Gathering and Conveying Newly Gathered Local Candidates 9. Gathering and Conveying Newly Gathered Local Candidates
After Trickle ICE agents have conveyed initial ICE descriptions and After Trickle ICE agents have conveyed initial ICE descriptions and
initial ICE responses, they will most likely continue gathering new initial ICE responses, they will most likely continue gathering new
local candidates as STUN, TURN, and other non-host candidate local candidates as STUN, TURN, and other non-host candidate
gathering mechanisms begin to yield results. Whenever an agent gathering mechanisms begin to yield results. Whenever an agent
discovers such a new candidate, it will compute its priority, type, discovers such a new candidate, it will compute its priority, type,
foundation, and component ID according to regular ICE procedures. foundation, and component ID according to regular ICE procedures.
skipping to change at page 12, line 31 skipping to change at line 541
pair from that local candidate (Section 9), or after a remote agent pair from that local candidate (Section 9), or after a remote agent
has received a trickled candidate and formed a candidate pair from has received a trickled candidate and formed a candidate pair from
that remote candidate (Section 11), a Trickle ICE agent adds the new that remote candidate (Section 11), a Trickle ICE agent adds the new
candidate pair to a checklist as defined in this section. candidate pair to a checklist as defined in this section.
As an aid to understanding the procedures 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 consider the following tabular representation of all checklists in an
agent (note that initially for one of the foundations, i.e., f5, agent (note that initially for one of the foundations, i.e., f5,
there are no candidate pairs): there are no candidate pairs):
+-----------------+------+------+------+------+------+ +-----------------+----+----+----+----+----+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | | | s1 (Audio.RTP) | F | F | F | | |
+-----------------+------+------+------+------+------+ +-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | | | s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+------+------+------+------+------+ +-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | | | s3 (Video.RTP) | F | | | | |
+-----------------+------+------+------+------+------+ +-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | | | s4 (Video.RTCP) | F | | | | |
+-----------------+------+------+------+------+------+ +-----------------+----+----+----+----+----+
Figure 2: Example of Checklist State Table 1: TESTING: Example of Checklist State
Each row in the table represents a component for a given data stream 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) (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 components for audio) and thus a single checklist in the checklist
set. Each column represents one foundation. Each cell represents set. Each column represents one foundation. Each cell represents
one candidate pair. In the tables shown in this section, "F" stands one candidate pair. In the tables shown in this section, "F" stands
for "frozen", "W" stands for "waiting", and "S" stands for for "frozen", "W" stands for "waiting", and "S" stands for
"succeeded"; in addition, "^^" is used to notate newly added "succeeded"; in addition, "^^" is used to notate newly added
candidate pairs. candidate pairs.
skipping to change at page 13, line 26 skipping to change at line 583
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s1 (Audio.RTP) | W | W | W | | | | s1 (Audio.RTP) | W | W | W | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s2 (Audio.RTCP) | F | F | F | W | | | s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s3 (Video.RTP) | F | | | | | | s3 (Video.RTP) | F | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s4 (Video.RTCP) | F | | | | | | s4 (Video.RTCP) | F | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 3: Initial Checklist State Figure 2: Initial Checklist State
Then, as the checks proceed (see Section 7.2.5.4 of [RFC8445]), for 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 each pair that enters the Succeeded state (denoted here by "S"), the
agent will unfreeze all pairs for all data streams with the same 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 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). agent will unfreeze the pairs in column 1, rows 2, 3, and 4).
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s1 (Audio.RTP) | S | W | W | | | | s1 (Audio.RTP) | S | W | W | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s2 (Audio.RTCP) | W | F | F | W | | | s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s3 (Video.RTP) | W | | | | | | s3 (Video.RTP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s4 (Video.RTCP) | W | | | | | | s4 (Video.RTCP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 4: Checklist State with Succeeded Candidate Pair Figure 3: Checklist State with Succeeded Candidate Pair
Trickle ICE preserves all of these rules as they apply to "static" Trickle ICE preserves all of these rules as they apply to "static"
checklist sets. This implies that if a Trickle ICE agent were to checklist sets. This implies that if a Trickle ICE agent were to
begin connectivity checks with all of its pairs already present, the begin connectivity checks with all of its pairs already present, the
way that pair states change is indistinguishable from that of a way that pair states change is indistinguishable from that of a
regular ICE agent. regular ICE agent.
Of course, the major difference with Trickle ICE is that checklist Of course, the major difference with Trickle ICE is that checklist
sets can be dynamically updated because candidates can arrive after sets can be dynamically updated because candidates can arrive after
connectivity checks have started. When this happens, an agent sets connectivity checks have started. When this happens, an agent sets
skipping to change at page 14, line 35 skipping to change at line 635
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s1 (Audio.RTP) | S | W | W | | ^W^ | | s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s2 (Audio.RTCP) | W | F | F | W | | | s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s3 (Video.RTP) | W | | | | | | s3 (Video.RTP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s4 (Video.RTCP) | W | | | | | | s4 (Video.RTCP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 5: Checklist State with Newly Formed Pair, Rule 1 Figure 4: Checklist State with Newly Formed Pair, Rule 1
Rule 2: If there is at least one pair in the Succeeded state for this 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 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 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 pair were placed in column 5, row 2. This rule is consistent with
Section 7.2.5.3.3 of [RFC8445]. Section 7.2.5.3.3 of [RFC8445].
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s1 (Audio.RTP) | S | W | W | | S | | s1 (Audio.RTP) | S | W | W | | S |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ | | s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s3 (Video.RTP) | W | | | | | | s3 (Video.RTP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s4 (Video.RTCP) | W | | | | | | s4 (Video.RTCP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 6: Checklist State with Newly Formed Pair, Rule 2 Figure 5: Checklist State with Newly Formed Pair, Rule 2
Rule 3: In all other cases, set the state to Frozen. For example, 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 this would be the case if the newly formed pair were placed in column
3, row 3. 3, row 3.
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s1 (Audio.RTP) | S | W | W | | S | | s1 (Audio.RTP) | S | W | W | | S |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s2 (Audio.RTCP) | W | F | F | W | W | | s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s3 (Video.RTP) | W | | ^F^ | | | | s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| s4 (Video.RTCP) | W | | | | | | s4 (Video.RTCP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 7: Checklist State with Newly Formed Pair, Rule 3 Figure 6: Checklist State with Newly Formed Pair, Rule 3
13. Generating an End-of-Candidates Indication 13. Generating an End-of-Candidates Indication
Once all candidate gathering is completed or expires for an ICE Once all candidate gathering is completed or expires for an ICE
session associated with a specific data stream, the agent will session associated with a specific data stream, the agent will
generate an "end-of-candidates" indication for that session and generate an "end-of-candidates" indication for that session and
convey it to the remote agent via the signaling channel. Although convey it to the remote agent via the signaling channel. Although
the exact form of the indication depends on the using protocol, the the exact form of the indication depends on the using protocol, the
indication MUST specify the generation (Username Fragment and indication MUST specify the generation (Username Fragment and
Password combination), so that an agent can correlate the end-of- Password combination), so that an agent can correlate the end-of-
candidates indication with a particular ICE session. The indication candidates indication with a particular ICE session. The indication
can be conveyed in the following ways: can be conveyed in the following ways:
o As part of an initiation request (which would typically be the * As part of an initiation request (which would typically be the
case with the initial ICE description for half trickle) case with the initial ICE description for half trickle)
o Along with the last candidate an agent can send for a stream * Along with the last candidate an agent can send for a stream
o As a standalone notification (e.g., after STUN Binding requests or * As a standalone notification (e.g., after STUN Binding requests or
TURN Allocate requests to a server time out and the agent is no TURN Allocate requests to a server time out and the agent is no
longer actively gathering candidates) longer actively gathering candidates)
Conveying an end-of-candidates indication in a timely manner is Conveying an end-of-candidates indication in a timely manner is
important in order to avoid ambiguities and speed up the conclusion important in order to avoid ambiguities and speed up the conclusion
of ICE processing. In particular: of ICE processing. In particular:
o A controlled Trickle ICE agent SHOULD convey an end-of-candidates * A controlled Trickle ICE agent SHOULD convey an end-of-candidates
indication after it has completed gathering for a data stream, indication after it has completed gathering for a data stream,
unless ICE processing terminates before the agent has had a chance unless ICE processing terminates before the agent has had a chance
to complete gathering. to complete gathering.
o A controlling agent MAY conclude ICE processing prior to conveying * A controlling agent MAY conclude ICE processing prior to conveying
end-of-candidates indications for all streams. However, it is end-of-candidates indications for all streams. However, it is
RECOMMENDED for a controlling agent to convey end-of-candidates RECOMMENDED for a controlling agent to convey end-of-candidates
indications whenever possible for the sake of consistency and to indications whenever possible for the sake of consistency and to
keep middleboxes and controlled agents up-to-date on the state of keep middleboxes and controlled agents up-to-date on the state of
ICE processing. ICE processing.
When conveying an end-of-candidates indication during trickling When conveying an end-of-candidates indication during trickling
(rather than as a part of the initial ICE description or a response (rather than as a part of the initial ICE description or a response
thereto), it is the responsibility of the using protocol to define thereto), it is the responsibility of the using protocol to define
methods for associating the indication with one or more specific data methods for associating the indication with one or more specific data
skipping to change at page 20, line 12 skipping to change at line 885
For this candidate information, the RTCP host candidate would not be For this candidate information, the RTCP host candidate would not be
conveyed prior to the RTP host candidate. Similarly, the RTP server- conveyed prior to the RTP host candidate. Similarly, the RTP server-
reflexive candidate would be conveyed together with or prior to the reflexive candidate would be conveyed together with or prior to the
RTCP server-reflexive candidate. RTCP server-reflexive candidate.
18. Requirements for Using Protocols 18. Requirements for Using Protocols
In order to fully enable the use of Trickle ICE, this specification In order to fully enable the use of Trickle ICE, this specification
defines the following requirements for using protocols. defines the following requirements for using protocols.
o A using protocol SHOULD provide a way for parties to advertise and * A using protocol SHOULD provide a way for parties to advertise and
discover support for Trickle ICE before an ICE session begins (see discover support for Trickle ICE before an ICE session begins (see
Section 3). Section 3).
o A using protocol MUST provide methods for incrementally conveying * A using protocol MUST provide methods for incrementally conveying
(i.e., "trickling") additional candidates after conveying the (i.e., "trickling") additional candidates after conveying the
initial ICE description (see Section 9). initial ICE description (see Section 9).
o A using protocol MUST deliver each trickled candidate or end-of- * A using protocol MUST deliver each trickled candidate or end-of-
candidates indication exactly once and in the same order it was candidates indication exactly once and in the same order it was
conveyed (see Section 9). conveyed (see Section 9).
o A using protocol MUST provide a mechanism for both parties to * A using protocol MUST provide a mechanism for both parties to
indicate and agree on the ICE session in force (see Section 9). indicate and agree on the ICE session in force (see Section 9).
o A using protocol MUST provide a way for parties to communicate the * A using protocol MUST provide a way for parties to communicate the
end-of-candidates indication, which MUST specify the particular end-of-candidates indication, which MUST specify the particular
ICE session to which the indication applies (see Section 13). ICE session to which the indication applies (see Section 13).
19. IANA Considerations 19. IANA Considerations
IANA has registered the following ICE option in the "ICE Options" IANA has registered the following ICE option in the "ICE Options"
subregistry of the "Interactive Connectivity Establishment (ICE) subregistry of the "Interactive Connectivity Establishment (ICE)
registry", following the procedures defined in [RFC6336]. registry", following the procedures defined in [RFC6336].
ICE Option: trickle ICE Option: trickle
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Change controller: IESG Change controller: IESG
Description: An ICE option of 'trickle' indicates support for Description: An ICE option of 'trickle' indicates support for
incremental communication of ICE candidates. incremental communication of ICE candidates.
Reference: RFC 8452 Reference: RFC 8838
20. Security Considerations 20. Security Considerations
This specification inherits most of its semantics from [RFC8445], and This specification inherits most of its semantics from [RFC8445], and
as a result, all security considerations described there apply to as a result, all security considerations described there apply to
Trickle ICE. Trickle ICE.
If the privacy implications of revealing host addresses on an If the privacy implications of revealing host addresses on an
endpoint device are a concern (see, for example, the discussion in endpoint device are a concern (see, for example, the discussion in
[WebRTC-IP-HANDLING] and in Section 19 of [RFC8445]), agents can [RFC8828] and in Section 19 of [RFC8445]), agents can generate ICE
generate ICE descriptions that contain no candidates and then only descriptions that contain no candidates and then only trickle
trickle candidates that do not reveal host addresses (e.g., relayed candidates that do not reveal host addresses (e.g., relayed
candidates). candidates).
21. References 21. References
21.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 21, line 39 skipping to change at line 955
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
21.2. Informative References 21.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets", J., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
<https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
skipping to change at page 22, line 39 skipping to change at line 1000
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
RFC 6336, DOI 10.17487/RFC6336, July 2011, RFC 6336, DOI 10.17487/RFC6336, July 2011,
<https://www.rfc-editor.org/info/rfc6336>. <https://www.rfc-editor.org/info/rfc6336>.
[SIP-TRICKLE-ICE] [RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Requirements", DOI 10.17487/RFC8828, RFC 8828, May 2020,
<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 Session Initiation Protocol (SIP) Usage for Incremental
Provisioning of Candidates for the Interactive Provisioning of Candidates for the Interactive
Connectivity Establishment (Trickle ICE)", Work in Connectivity Establishment (Trickle ICE)",
Progress, draft-ietf-mmusic-trickle-ice-sip-18, June 2018. DOI 10.17487/RFC8840, RFC 8840, June 2018,
<https://www.rfc-editor.org/info/rfc8840>.
[WebRTC-IP-HANDLING] [RFC8851] Roach, A.B., Ed., "RTP Payload Format Restrictions",
Uberti, J. and G. Shieh, "WebRTC IP Address Handling DOI 10.17487/RFC8851, RFC 8851, April 2020,
Requirements", Work in Progress, draft-ietf-rtcweb-ip- <https://www.rfc-editor.org/info/rfc8851>.
handling-09, June 2018.
[XEP-0030] [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
Andre, "XEP-0030: Service Discovery", XMPP Standards Andre, "XEP-0030: Service Discovery", XMPP Standards
Foundation, XEP-0030, June 2008. Foundation, XEP-0030, June 2008.
[XEP-0176] [XEP-0176] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J.,
Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J.,
Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP
Transport Method", XMPP Standards Foundation, XEP-0176, Transport Method", XMPP Standards Foundation, XEP-0176,
June 2009. June 2009.
Appendix A. Interaction with Regular ICE Appendix A. Interaction with Regular ICE
The ICE protocol was designed to be flexible enough to work in and The ICE protocol was designed to be flexible enough to work in and
adapt to as many network environments as possible. Despite that adapt to as many network environments as possible. Despite that
flexibility, ICE as specified in [RFC8445] does not by itself support flexibility, ICE as specified in [RFC8445] does not by itself support
Trickle ICE. This section describes how trickling of candidates Trickle ICE. This section describes how trickling of candidates
skipping to change at page 25, line 29 skipping to change at line 1131
|---------------------------------------------->| |---------------------------------------------->|
| |no cand | |no cand
| Answer (a=ice-options:trickle) |trickling | Answer (a=ice-options:trickle) |trickling
|<----------------------------------------------| |<----------------------------------------------|
| Connectivity Checks | | Connectivity Checks |
|<--------------------------------------------->| |<--------------------------------------------->|
peer rflx| | peer rflx| |
cand disco| | cand disco| |
|<========== CONNECTION ESTABLISHED ===========>| |<========== CONNECTION ESTABLISHED ===========>|
Figure 8: Example Figure 7: Example
In addition to reducing signaling traffic, this approach also removes In addition to reducing signaling traffic, this approach also removes
the need to discover STUN Bindings or make TURN allocations, which the need to discover STUN Bindings or make TURN allocations, which
can considerably lighten ICE processing. can considerably lighten ICE processing.
Acknowledgements Acknowledgements
The authors would like to thank Bernard Aboba, Flemming Andreasen, The authors would like to thank Bernard Aboba, Flemming Andreasen,
Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer
Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, Holmberg, Ari Kerรคnen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco,
Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin
Thomson, Brandon Williams, and Dale Worley for their reviews and Thomson, Brandon Williams, and Dale Worley for their reviews and
suggestions on improving this document. Sarah Banks, Roni Even, and suggestions on improving this document. Sarah Banks, Roni Even, and
David Mandelberg completed OPSDIR, GenART, and security reviews, David Mandelberg completed OPSDIR, GenART, and security reviews,
respectively. Thanks also to Ari Keranen and Peter Thatcher in their respectively. Thanks also to Ari Keranen and Peter Thatcher in their
role as chairs and Ben Campbell in his role as responsible Area role as chairs and Ben Campbell in his role as responsible Area
Director. Director.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Atlassian Atlassian
303 Colorado Street, #1600 303 Colorado Street, #1600
Austin, TX 78701 Austin, TX 78701
United States of America United States of America
Phone: +1 512 640 3000 Phone: +1 512 640 3000
Email: emcho@jitsi.org Email: emcho@jitsi.org
Justin Uberti Justin Uberti
Google Google
747 6th Street S 747 6th Street S
Kirkland, WA 98033 Kirkland, WA 98033
United States of America United States of America
Phone: +1 857 288 8888 Phone: +1 857 288 8888
Email: justin@uberti.name Email: justin@uberti.name
Peter Saint-Andre Peter Saint-Andre
Mozilla Mozilla
P.O. Box 787 P.O. Box 787
Parker, CO 80134 Parker, CO 80134
United States of America United States of America
Phone: +1 720 256 6756 Phone: +1 720 256 6756
Email: stpeter@mozilla.com Email: stpeter@mozilla.com
URI: https://www.mozilla.com/ URI: https://www.mozilla.com/
 End of changes. 44 change blocks. 
101 lines changed or deleted 101 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/