1. Introduction (简介)
🇨🇳 中文
交互式连接建立 (Interactive Connectivity Establishment, ICE) 协议 [RFC8445] 描述了ICE代理如何收集候选地址 (Candidates)、与对等ICE代理交换候选地址以及创建候选地址对 (Candidate Pairs)。一旦候选地址对收集完成，ICE代理将执行连接性检查 (Connectivity Checks)，并最终提名和选择将用于在通信会话中发送和接收数据的候选地址对。
遵循 [RFC8445] 中的过程可能导致通信会话的建立时间较长，因为候选地址收集通常涉及查询NAT会话穿越实用程序 (Session Traversal Utilities for NAT, STUN) 服务器 [RFC5389] 以及在中继NAT穿越 (Traversal Using Relay NAT, TURN) 服务器 [RFC5766] 上分配中继候选地址。尽管许多ICE过程可以并行完成，但仍需遵循 [RFC8445] 中的节奏要求 (Pacing Requirements)。
本文档定义了"Trickle ICE"，这是ICE操作的一种补充模式，其中候选地址可以在可用时立即增量交换（同时收集其他候选地址）。连接性检查也可以在候选地址对创建后立即开始。由于Trickle ICE使候选地址收集和连接性检查能够并行进行，该方法可以显著加速通信会话的建立过程。
本文档还定义了如何发现对Trickle ICE的支持，如何在使用Trickle ICE时修改或补充 [RFC8445] 中的过程，以及Trickle ICE代理如何与符合 [RFC8445] 的ICE代理互操作。
本文档不定义任何特定于协议的Trickle ICE使用方法。相反，Trickle ICE的特定于协议的细节在单独的使用文档中定义。此类文档的示例包括 [RFC8840]（定义了与会话发起协议 (Session Initiation Protocol, SIP) [RFC3261] 和会话描述协议 (Session Description Protocol, SDP) [RFC4566] 的使用）和 [XEP-0176]（定义了与可扩展消息和出席协议 (Extensible Messaging and Presence Protocol, XMPP) [RFC6120] 的使用）。然而，文档中的一些示例使用SDP和提供/应答模型 (Offer/Answer Model) [RFC3264] 来解释基本概念。
以下图表说明了使用遵循提供/应答模型的协议进行的成功Trickle ICE交换：
Alice Bob
| Offer |
|---------------------------------------------->|
| Additional Candidates |
|---------------------------------------------->|
| Answer |
|<----------------------------------------------|
| Additional Candidates |
|<----------------------------------------------|
| Additional Candidates and Connectivity Checks |
|<--------------------------------------------->|
|<========== CONNECTION ESTABLISHED ===========>|
图1: 流程 (Flow)
本文档的主体部分按照ICE会话期间操作和交互的大致顺序描述Trickle ICE代理的行为：
- 确定对Trickle ICE的支持
- 生成初始ICE描述
- 处理初始ICE描述并生成初始ICE响应
- 处理初始ICE响应
- 形成检查列表、修剪候选地址、执行连接性检查等
- 在初始ICE描述和响应之后收集并传递候选地址
- 处理入站渐进式候选地址
- 生成和处理候选地址结束指示
- 处理ICE重启
Trickle ICE背后的技术有相当多的操作经验，可以追溯到2005年（当时XMPP Jingle扩展定义了"dribble mode"，如 [XEP-0176] 中所述）；本文档纳入了多年来实现和部署该技术的人员的反馈。
🇬🇧 English
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:
- Determining support for Trickle ICE
- Generating the initial ICE description
- Handling the initial ICE description and generating the initial ICE response
- Handling the initial ICE response
- Forming checklists, pruning candidates, performing connectivity checks, etc.
- Gathering and conveying candidates after the initial ICE description and response
- Handling inbound trickled candidates
- Generating and handling the end-of-candidates indication
- 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.
🇯🇵 日本語
インタラクティブ接続確立 (Interactive Connectivity Establishment, ICE) プロトコル [RFC8445] は、ICEエージェントが候補 (Candidates) を収集し、ピアICEエージェントと候補を交換し、候補ペア (Candidate Pairs) を作成する方法を説明しています。ペアが収集されると、ICEエージェントは接続性チェック (Connectivity Checks) を実行し、最終的に通信セッション内でデータの送受信に使用されるペアを指名して選択します。
[RFC8445] の手順に従うと、通信セッションの確立時間がやや長くなる可能性があります。これは、候補の収集がNATセッショントラバーサルユーティリティ (Session Traversal Utilities for NAT, STUN) サーバー [RFC5389] への問い合わせや、リレーNATトラバーサル (Traversal Using Relay NAT, TURN) サーバー [RFC5766] でのリレー候補の割り当てを伴うことが多いためです。多くのICE手順は並行して完了できますが、[RFC8445] のペーシング要件 (Pacing Requirements) に従う必要があります。
本文書は、「Trickle ICE」を定義します。これは、候補が利用可能になり次第増分的に交換できる（他の候補の収集と同時に）ICE動作の補足モードです。接続性チェックも、候補ペアが作成され次第開始できます。Trickle ICEは候補の収集と接続性チェックを並行して行うことを可能にするため、この方法は通信セッションの確立プロセスを大幅に高速化できます。
本文書はまた、Trickle ICEのサポートを発見する方法、Trickle ICE使用時に [RFC8445] の手順をどのように変更または補完するか、およびTrickle ICEエージェントが [RFC8445] 準拠のICEエージェントとどのように相互運用するかを定義します。
本文書は、プロトコル固有のTrickle ICE使用方法を定義しません。代わりに、Trickle ICEのプロトコル固有の詳細は、個別の使用文書で定義されます。そのような文書の例には、[RFC8840]（セッション開始プロトコル (Session Initiation Protocol, SIP) [RFC3261] およびセッション記述プロトコル (Session Description Protocol, SDP) [RFC4566] との使用を定義）および [XEP-0176]（拡張可能なメッセージングおよびプレゼンスプロトコル (Extensible Messaging and Presence Protocol, XMPP) [RFC6120] との使用を定義）があります。ただし、文書内のいくつかの例では、基本概念を説明するためにSDPとオファー/アンサーモデル (Offer/Answer Model) [RFC3264] を使用しています。
次の図は、オファー/アンサーモデルに従うプロトコルを使用した成功したTrickle ICE交換を示しています：
Alice Bob
| Offer |
|---------------------------------------------->|
| Additional Candidates |
|---------------------------------------------->|
| Answer |
|<----------------------------------------------|
| Additional Candidates |
|<----------------------------------------------|
| Additional Candidates and Connectivity Checks |
|<--------------------------------------------->|
|<========== CONNECTION ESTABLISHED ===========>|
図1: フロー (Flow)
本文書の本体は、ICEセッション中の操作と相互作用のおおよその順序でTrickle ICEエージェントの動作を説明するように構成されています：
- Trickle ICEのサポートの確認
- 初期ICE記述の生成
- 初期ICE記述の処理と初期ICE応答の生成
- 初期ICE応答の処理
- チェックリストの形成、候補の整理、接続性チェックの実行など
- 初期ICE記述と応答の後の候補の収集と伝達
- インバウンドトリクル候補の処理
- 候補終了表示の生成と処理
- ICE再起動の処理
Trickle ICEの背後にある技術には、2005年まで遡るかなりの運用経験があります（XMPP Jingle拡張が [XEP-0176] で指定されている「dribble mode」を定義したとき）。本文書は、長年にわたってこの技術を実装し展開してきた人々からのフィードバックを取り入れています。
🇫🇷 Français
Le protocole ICE (Interactive Connectivity Establishment) [RFC8445] décrit comment un agent ICE collecte des candidats, échange des candidats avec un agent ICE pair et crée des paires de candidats. Une fois les paires collectées, l'agent ICE effectuera des vérifications de connectivité et finira par nommer et sélectionner les paires qui seront utilisées pour envoyer et recevoir des données dans une session de communication.
Le respect des procédures dans [RFC8445] peut entraîner des temps d'établissement quelque peu longs pour les sessions de communication, car la collecte de candidats implique souvent l'interrogation de serveurs STUN (Session Traversal Utilities for NAT) [RFC5389] et l'allocation de candidats relayés sur des serveurs TURN (Traversal Using Relay NAT) [RFC5766]. Bien que de nombreuses procédures ICE puissent être effectuées en parallèle, les exigences de rythme de [RFC8445] doivent toujours être respectées.
Ce document définit « Trickle ICE », un mode d'opération supplémentaire d'ICE dans lequel les candidats peuvent être échangés de manière incrémentale dès qu'ils deviennent disponibles (et simultanément avec la collecte d'autres candidats). Les vérifications de connectivité peuvent également commencer dès que les paires de candidats ont été créées. Comme Trickle ICE permet d'effectuer la collecte de candidats et les vérifications de connectivité en parallèle, la méthode peut considérablement accélérer le processus d'établissement d'une session de communication.
Ce document définit également comment découvrir le support de Trickle ICE, comment les procédures dans [RFC8445] sont modifiées ou complétées lors de l'utilisation de Trickle ICE, et comment un agent Trickle ICE peut interopérer avec un agent ICE conforme à [RFC8445].
Ce document ne définit aucune utilisation spécifique au protocole de Trickle ICE. Au lieu de cela, les détails spécifiques au protocole pour Trickle ICE sont définis dans des documents d'utilisation séparés. Des exemples de tels documents sont [RFC8840] (qui définit l'utilisation avec le protocole SIP (Session Initiation Protocol) [RFC3261] et le protocole SDP (Session Description Protocol) [RFC4566]) et [XEP-0176] (qui définit l'utilisation avec le protocole XMPP (Extensible Messaging and Presence Protocol) [RFC6120]). Cependant, certains des exemples dans le document utilisent SDP et le modèle Offre/Réponse (Offer/Answer) [RFC3264] pour expliquer les concepts sous-jacents.
Le diagramme suivant illustre un échange Trickle ICE réussi avec un protocole d'utilisation qui suit le modèle Offre/Réponse :
Alice Bob
| Offre |
|---------------------------------------------->|
| Candidats supplémentaires |
|---------------------------------------------->|
| Réponse |
|<----------------------------------------------|
| Candidats supplémentaires |
|<----------------------------------------------|
| Candidats supplémentaires et vérifications |
|<--------------------------------------------->|
|<========== CONNEXION ÉTABLIE ================>|
Figure 1 : Flux (Flow)
Le corps principal de ce document est structuré pour décrire le comportement des agents Trickle ICE dans l'ordre approximatif des opérations et des interactions lors d'une session ICE :
- Détermination du support de Trickle ICE
- Génération de la description ICE initiale
- Traitement de la description ICE initiale et génération de la réponse ICE initiale
- Traitement de la réponse ICE initiale
- Formation de listes de vérification, élagage des candidats, exécution des vérifications de connectivité, etc.
- Collecte et transmission des candidats après la description ICE initiale et la réponse
- Traitement des candidats trickle entrants
- Génération et traitement de l'indication de fin de candidats
- Traitement des redémarrages ICE
Il existe une expérience opérationnelle considérable avec la technique derrière Trickle ICE, remontant à 2005 (lorsque l'extension XMPP Jingle a défini un « dribble mode » tel que spécifié dans [XEP-0176]) ; ce document intègre les retours de ceux qui ont implémenté et déployé la technique au fil des ans.
🇩🇪 Deutsch
Das Interactive Connectivity Establishment (ICE)-Protokoll [RFC8445] beschreibt, wie ein ICE-Agent Kandidaten sammelt, Kandidaten mit einem Peer-ICE-Agent austauscht und Kandidatenpaare erstellt. Sobald die Paare gesammelt wurden, führt der ICE-Agent Konnektivitätsprüfungen durch und nominiert und wählt schließlich Paare aus, die zum Senden und Empfangen von Daten innerhalb einer Kommunikationssitzung verwendet werden.
Das Befolgen der Verfahren in [RFC8445] kann zu etwas längeren Aufbauzeiten für Kommunikationssitzungen führen, da das Sammeln von Kandidaten häufig das Abfragen von Session Traversal Utilities for NAT (STUN)-Servern [RFC5389] und das Zuweisen von Relay-Kandidaten auf Traversal Using Relay NAT (TURN)-Servern [RFC5766] umfasst. Obwohl viele ICE-Verfahren parallel durchgeführt werden können, müssen die Taktanforderungen (Pacing Requirements) aus [RFC8445] weiterhin befolgt werden.
Dieses Dokument definiert „Trickle ICE", einen ergänzenden Betriebsmodus von ICE, bei dem Kandidaten schrittweise ausgetauscht werden können, sobald sie verfügbar werden (und gleichzeitig mit dem Sammeln anderer Kandidaten). Konnektivitätsprüfungen können auch beginnen, sobald Kandidatenpaare erstellt wurden. Da Trickle ICE das Sammeln von Kandidaten und Konnektivitätsprüfungen parallel ermöglicht, kann die Methode den Prozess des Aufbaus einer Kommunikationssitzung erheblich beschleunigen.
Dieses Dokument definiert auch, wie die Unterstützung für Trickle ICE erkannt wird, wie die Verfahren in [RFC8445] bei Verwendung von Trickle ICE geändert oder ergänzt werden und wie ein Trickle-ICE-Agent mit einem [RFC8445]-konformen ICE-Agent interoperieren kann.
Dieses Dokument definiert keine protokollspezifische Verwendung von Trickle ICE. Stattdessen werden protokollspezifische Details für Trickle ICE in separaten Verwendungsdokumenten definiert. Beispiele für solche Dokumente sind [RFC8840] (das die Verwendung mit dem Session Initiation Protocol (SIP) [RFC3261] und dem Session Description Protocol (SDP) [RFC4566] definiert) und [XEP-0176] (das die Verwendung mit dem Extensible Messaging and Presence Protocol (XMPP) [RFC6120] definiert). Einige der Beispiele im Dokument verwenden jedoch SDP und das Angebot/Antwort-Modell (Offer/Answer Model) [RFC3264], um die zugrunde liegenden Konzepte zu erklären.
Das folgende Diagramm veranschaulicht einen erfolgreichen Trickle-ICE-Austausch mit einem verwendenden Protokoll, das dem Angebot/Antwort-Modell folgt:
Alice Bob
| Angebot |
|---------------------------------------------->|
| Zusätzliche Kandidaten |
|---------------------------------------------->|
| Antwort |
|<----------------------------------------------|
| Zusätzliche Kandidaten |
|<----------------------------------------------|
| Zusätzliche Kandidaten und Konnektivitätsprüfungen |
|<--------------------------------------------->|
|<========== VERBINDUNG HERGESTELLT ============>|
Abbildung 1: Ablauf (Flow)
Der Hauptteil dieses Dokuments ist so strukturiert, dass das Verhalten von Trickle-ICE-Agents in ungefähr der Reihenfolge der Operationen und Interaktionen während einer ICE-Sitzung beschrieben wird:
- Bestimmung der Unterstützung für Trickle ICE
- Generierung der anfänglichen ICE-Beschreibung
- Verarbeitung der anfänglichen ICE-Beschreibung und Generierung der anfänglichen ICE-Antwort
- Verarbeitung der anfänglichen ICE-Antwort
- Bildung von Checklisten, Beschneiden von Kandidaten, Durchführung von Konnektivitätsprüfungen usw.
- Sammeln und Übermitteln von Kandidaten nach der anfänglichen ICE-Beschreibung und -Antwort
- Verarbeitung eingehender Trickle-Kandidaten
- Generierung und Verarbeitung der End-of-Candidates-Anzeige
- Verarbeitung von ICE-Neustarts
Es gibt beträchtliche Betriebserfahrung mit der Technik hinter Trickle ICE, die bis ins Jahr 2005 zurückreicht (als die XMPP-Jingle-Erweiterung einen „dribble mode" definierte, wie in [XEP-0176] spezifiziert); dieses Dokument enthält Feedback von denen, die die Technik über die Jahre hinweg implementiert und eingesetzt haben.
🇮🇹 Italiano
Il protocollo ICE (Interactive Connectivity Establishment) [RFC8445] descrive come un agente ICE raccoglie candidati, scambia candidati con un agente ICE peer e crea coppie di candidati. Una volta raccolte le coppie, l'agente ICE eseguirà controlli di connettività e alla fine nominerà e selezionerà le coppie che verranno utilizzate per inviare e ricevere dati all'interno di una sessione di comunicazione.
Seguire le procedure in [RFC8445] può portare a tempi di stabilimento piuttosto lunghi per le sessioni di comunicazione, perché la raccolta di candidati spesso comporta l'interrogazione di server STUN (Session Traversal Utilities for NAT) [RFC5389] e l'allocazione di candidati relay su server TURN (Traversal Using Relay NAT) [RFC5766]. Sebbene molte procedure ICE possano essere completate in parallelo, i requisiti di pacing da [RFC8445] devono ancora essere seguiti.
Questo documento definisce "Trickle ICE", una modalità di operazione supplementare di ICE in cui i candidati possono essere scambiati in modo incrementale non appena diventano disponibili (e simultaneamente con la raccolta di altri candidati). I controlli di connettività possono anche iniziare non appena sono state create le coppie di candidati. Poiché Trickle ICE consente di eseguire la raccolta di candidati e i controlli di connettività in parallelo, il metodo può accelerare considerevolmente il processo di stabilimento di una sessione di comunicazione.
Questo documento definisce anche come scoprire il supporto per Trickle ICE, come le procedure in [RFC8445] vengono modificate o integrate quando si utilizza Trickle ICE e come un agente Trickle ICE può interoperare con un agente ICE conforme a [RFC8445].
Questo documento non definisce alcun utilizzo specifico del protocollo di Trickle ICE. Invece, i dettagli specifici del protocollo per Trickle ICE sono definiti in documenti di utilizzo separati. Esempi di tali documenti sono [RFC8840] (che definisce l'utilizzo con il Session Initiation Protocol (SIP) [RFC3261] e il Session Description Protocol (SDP) [RFC4566]) e [XEP-0176] (che definisce l'utilizzo con l'Extensible Messaging and Presence Protocol (XMPP) [RFC6120]). Tuttavia, alcuni degli esempi nel documento utilizzano SDP e il modello Offerta/Risposta (Offer/Answer) [RFC3264] per spiegare i concetti sottostanti.
Il seguente diagramma illustra uno scambio Trickle ICE riuscito con un protocollo di utilizzo che segue il modello Offerta/Risposta:
Alice Bob
| Offerta |
|---------------------------------------------->|
| Candidati aggiuntivi |
|---------------------------------------------->|
| Risposta |
|<----------------------------------------------|
| Candidati aggiuntivi |
|<----------------------------------------------|
| Candidati aggiuntivi e controlli di connettività |
|<--------------------------------------------->|
|<========== CONNESSIONE STABILITA =============>|
Figura 1: Flusso (Flow)
Il corpo principale di questo documento è strutturato per descrivere il comportamento degli agenti Trickle ICE approssimativamente nell'ordine delle operazioni e delle interazioni durante una sessione ICE:
- Determinazione del supporto per Trickle ICE
- Generazione della descrizione ICE iniziale
- Gestione della descrizione ICE iniziale e generazione della risposta ICE iniziale
- Gestione della risposta ICE iniziale
- Formazione di checklist, eliminazione di candidati, esecuzione di controlli di connettività, ecc.
- Raccolta e trasmissione di candidati dopo la descrizione ICE iniziale e la risposta
- Gestione dei candidati trickle in entrata
- Generazione e gestione dell'indicazione di fine candidati
- Gestione dei riavvii ICE
C'è una notevole esperienza operativa con la tecnica dietro Trickle ICE, risalente al 2005 (quando l'estensione XMPP Jingle ha definito una "dribble mode" come specificato in [XEP-0176]); questo documento incorpora feedback da coloro che hanno implementato e distribuito la tecnica nel corso degli anni.