9. Gathering and Conveying Newly Gathered Local Candidates (收集并传递新收集的本地候选地址)
🇨🇳 中文
在Trickle ICE代理传递初始ICE描述和初始ICE响应之后，随着STUN、TURN和其他非主机候选地址收集机制开始产生结果，它们很可能会继续收集新的本地候选地址。每当代理发现这样一个新候选地址时，它将根据常规ICE过程计算其优先级、类型、基础 (Foundation) 和组件ID。
然后，将针对现有本地候选地址列表检查新候选地址的冗余性。如果其传输地址和基地址与现有候选地址的传输地址和基地址匹配，则将其视为冗余并被忽略。这通常会发生在与获得它们的主机地址匹配的服务器反射候选地址上（例如，当后者是公共IPv4地址时）。与常规ICE相反，Trickle ICE代理将认为新候选地址是冗余的，而不管其优先级如何。
接下来，代理将新发现的候选地址"渐进式交换"到远程代理。新候选地址的实际传递由SIP或XMPP等使用协议处理。Trickle ICE对此操作的执行方式不施加任何限制（例如，某些使用协议可能选择不对服务器反射候选地址进行渐进式更新，而是依赖于对等反射候选地址的发现）。
当候选地址进行渐进式交换时，使用协议必须 (MUST) 将每个候选地址（以及如第13节所述的任何候选地址结束指示）准确传递一次给接收的Trickle ICE实现，并且顺序与传递时相同。如果使用协议提供任何候选地址重传，则需要对ICE实现隐藏这些重传。
此外，候选地址渐进式交换需要与特定的ICE会话相关联，以便如果发生ICE重启，可以识别先前会话的任何延迟更新并被接收方忽略。例如，通过SDP发信令候选地址的使用协议可能在相应的a=candidate行中包含用户名片段 (Username Fragment) 值，例如：
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
或者，作为另一个示例，WebRTC实现可能在表示候选地址的JavaScript对象中包含用户名片段。
注意：使用协议需要提供一种机制，让双方指示并同意生效的ICE会话（由用户名片段和密码组合标识），以便它们对哪些候选地址将被配对具有一致的视图。这在ICE重启的情况下尤其重要（参见第15节）。
注意：使用协议可能更倾向于不将服务器反射候选地址渐进式交换到已知公开可访问的实体，在这种情况下，发送直接STUN绑定请求可能比通过信令路径传输的渐进式更新更快到达目的地。
🇬🇧 English
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.
🇯🇵 日本語
Trickle ICEエージェントが初期ICE記述と初期ICE応答を伝達した後、STUN、TURN、およびその他の非ホスト候補収集メカニズムが結果を生み出し始めると、新しいローカル候補の収集を継続する可能性が高くなります。エージェントがそのような新しい候補を発見するたびに、通常のICE手順に従って、その優先度、タイプ、基礎 (Foundation)、およびコンポーネントIDを計算します。
次に、新しい候補は、既存のローカル候補のリストに対して冗長性がチェックされます。そのトランスポートアドレスとベースアドレスが既存の候補のものと一致する場合、冗長とみなされ、無視されます。これは、取得元のホストアドレスと一致するサーバー反射候補でよく発生します（たとえば、後者がパブリックIPv4アドレスの場合）。通常のICEとは対照的に、Trickle ICEエージェントは、優先度に関係なく、新しい候補を冗長とみなします。
次に、エージェントは新しく発見された候補をリモートエージェントに「トリクル」します。新しい候補の実際の配信は、SIPやXMPPなどの使用プロトコルによって処理されます。Trickle ICEは、これが行われる方法に制限を課しません（たとえば、一部の使用プロトコルは、サーバー反射候補の更新をトリクルしないことを選択し、代わりにピア反射候補の発見に依存する場合があります）。
候補がトリクルされる場合、使用プロトコルは、各候補（および第13節で説明されている候補終了表示）を、受信するTrickle ICE実装に正確に1回、伝達された順序と同じ順序で配信しなければなりません (MUST)。使用プロトコルが候補の再送信を提供する場合、それらはICE実装から隠す必要があります。
また、候補のトリクルは特定のICEセッションに関連付けられる必要があるため、ICE再起動がある場合、以前のセッションの遅延更新をそのようなものとして認識し、受信側が無視できます。たとえば、SDPを介して候補をシグナリングする使用プロトコルは、対応するa=candidate行にユーザー名フラグメント (Username Fragment) 値を含める場合があります。次のようになります：
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
または、別の例として、WebRTC実装は、候補を表すJavaScriptオブジェクトにユーザー名フラグメントを含める場合があります。
注：使用プロトコルは、両当事者が有効なICEセッション（ユーザー名フラグメントとパスワードの組み合わせで識別される）を示し、同意するためのメカニズムを提供する必要があります。これにより、どの候補がペアリングされるかについて一貫したビューを持つことができます。これは、ICE再起動の場合に特に重要です（第15節を参照）。
注：使用プロトコルは、公開アクセス可能であることがわかっているエンティティにサーバー反射候補をトリクルしないことを好む場合があります。この場合、直接STUNバインディングリクエストを送信する方が、シグナリングパスを通過するトリクル更新よりも速く宛先に到達する可能性があります。
🇫🇷 Français
Après que les agents Trickle ICE ont transmis les descriptions ICE initiales et les réponses ICE initiales, ils continueront très probablement à collecter de nouveaux candidats locaux à mesure que les mécanismes de collecte de candidats STUN, TURN et autres candidats non-hôtes commencent à produire des résultats. Chaque fois qu'un agent découvre un tel nouveau candidat, il calculera sa priorité, son type, sa fondation (Foundation) et son ID de composant selon les procédures ICE régulières.
Le nouveau candidat est ensuite vérifié pour la redondance par rapport à la liste existante de candidats locaux. Si son adresse de transport et sa base correspondent à celles d'un candidat existant, il sera considéré comme redondant et sera ignoré. Cela se produirait souvent pour les candidats réflexifs de serveur qui correspondent aux adresses d'hôte à partir desquelles ils ont été obtenus (par exemple, lorsque ces dernières sont des adresses IPv4 publiques). Contrairement à l'ICE régulier, les agents Trickle ICE considéreront le nouveau candidat comme redondant quelle que soit sa priorité.
Ensuite, l'agent « trickle » le(s) candidat(s) nouvellement découvert(s) vers l'agent distant. La livraison réelle des nouveaux candidats est gérée par un protocole d'utilisation tel que SIP ou XMPP. Trickle ICE n'impose aucune restriction sur la façon dont cela est fait (par exemple, certains protocoles d'utilisation peuvent choisir de ne pas trickle les mises à jour pour les candidats réflexifs de serveur et s'appuyer plutôt sur la découverte de candidats réflexifs de pair).
Lorsque les candidats sont trickle, le protocole d'utilisation doit (MUST) livrer chaque candidat (et toute indication de fin de candidats comme décrit dans la section 13) à l'implémentation Trickle ICE réceptrice exactement une fois et dans le même ordre qu'il a été transmis. Si le protocole d'utilisation fournit des retransmissions de candidats, elles doivent être cachées de l'implémentation ICE.
De plus, le trickling de candidats doit être corrélé à une session ICE spécifique, de sorte que s'il y a un redémarrage ICE, toutes les mises à jour retardées pour une session précédente peuvent être reconnues comme telles et ignorées par la partie réceptrice. Par exemple, les protocoles d'utilisation qui signalent les candidats via SDP peuvent inclure une valeur de fragment de nom d'utilisateur (Username Fragment) dans la ligne a=candidate correspondante, telle que :
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
Ou, comme autre exemple, les implémentations WebRTC peuvent inclure un fragment de nom d'utilisateur dans les objets JavaScript qui représentent les candidats.
Remarque : Le protocole d'utilisation doit fournir un mécanisme permettant aux deux parties d'indiquer et de s'accorder sur la session ICE en vigueur (identifiée par la combinaison fragment de nom d'utilisateur et mot de passe), afin qu'elles aient une vue cohérente des candidats à apparier. Ceci est particulièrement important dans le cas des redémarrages ICE (voir section 15).
Remarque : Un protocole d'utilisation peut préférer ne pas trickle les candidats réflexifs de serveur vers des entités dont on sait qu'elles sont publiquement accessibles et où l'envoi d'une demande de liaison STUN directe est susceptible d'atteindre la destination plus rapidement que la mise à jour trickle qui transite par le chemin de signalisation.
🇩🇪 Deutsch
Nachdem Trickle-ICE-Agents anfängliche ICE-Beschreibungen und anfängliche ICE-Antworten übermittelt haben, werden sie höchstwahrscheinlich weiterhin neue lokale Kandidaten sammeln, während STUN, TURN und andere Nicht-Host-Kandidatensammlungsmechanismen Ergebnisse liefern. Wann immer ein Agent einen solchen neuen Kandidaten entdeckt, berechnet er dessen Priorität, Typ, Foundation und Komponenten-ID gemäß den regulären ICE-Verfahren.
Der neue Kandidat wird dann auf Redundanz gegenüber der vorhandenen Liste lokaler Kandidaten überprüft. Wenn seine Transportadresse und Basis mit denen eines vorhandenen Kandidaten übereinstimmen, wird er als redundant betrachtet und ignoriert. Dies würde häufig bei serverreflexiven Kandidaten geschehen, die mit den Hostadressen übereinstimmen, von denen sie erhalten wurden (z. B. wenn letztere öffentliche IPv4-Adressen sind). Im Gegensatz zu regulärem ICE betrachten Trickle-ICE-Agents den neuen Kandidaten unabhängig von seiner Priorität als redundant.
Als nächstes „tricklet" der Agent die neu entdeckten Kandidaten zum entfernten Agent. Die tatsächliche Zustellung der neuen Kandidaten wird von einem verwendenden Protokoll wie SIP oder XMPP behandelt. Trickle ICE stellt keine Einschränkungen an die Art und Weise, wie dies geschieht (z. B. könnten einige verwendende Protokolle wählen, keine Updates für serverreflexive Kandidaten zu tricklen und stattdessen auf die Entdeckung von peer-reflexiven zu vertrauen).
Wenn Kandidaten getricklet werden, muss (MUST) das verwendende Protokoll jeden Kandidaten (und jede End-of-Candidates-Anzeige, wie in Abschnitt 13 beschrieben) genau einmal und in derselben Reihenfolge, in der er übermittelt wurde, an die empfangende Trickle-ICE-Implementierung liefern. Wenn das verwendende Protokoll Kandidatenwiederholungen bereitstellt, müssen diese vor der ICE-Implementierung verborgen werden.
Außerdem muss das Kandidaten-Trickling mit einer bestimmten ICE-Sitzung korreliert werden, sodass im Falle eines ICE-Neustarts verspätete Updates für eine vorherige Sitzung als solche erkannt und von der empfangenden Partei ignoriert werden können. Beispielsweise könnten verwendende Protokolle, die Kandidaten über SDP signalisieren, einen Username-Fragment-Wert in der entsprechenden a=candidate-Zeile enthalten, wie:
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
Oder als weiteres Beispiel könnten WebRTC-Implementierungen ein Username Fragment in den JavaScript-Objekten enthalten, die Kandidaten darstellen.
Hinweis: Das verwendende Protokoll muss einen Mechanismus bereitstellen, mit dem beide Parteien die gültige ICE-Sitzung (identifiziert durch die Kombination aus Username Fragment und Passwort) angeben und sich darauf einigen können, sodass sie eine konsistente Sicht darauf haben, welche Kandidaten gepaart werden sollen. Dies ist besonders wichtig im Fall von ICE-Neustarts (siehe Abschnitt 15).
Hinweis: Ein verwendendes Protokoll könnte es vorziehen, serverreflexive Kandidaten nicht an Entitäten zu tricklen, von denen bekannt ist, dass sie öffentlich zugänglich sind und bei denen das Senden einer direkten STUN-Bindungsanfrage das Ziel wahrscheinlich schneller erreicht als das Trickle-Update, das über den Signalisierungspfad läuft.
🇮🇹 Italiano
Dopo che gli agenti Trickle ICE hanno trasmesso le descrizioni ICE iniziali e le risposte ICE iniziali, molto probabilmente continueranno a raccogliere nuovi candidati locali man mano che i meccanismi di raccolta candidati STUN, TURN e altri candidati non-host iniziano a produrre risultati. Ogni volta che un agente scopre un tale nuovo candidato, calcolerà la sua priorità, tipo, fondazione (Foundation) e ID componente secondo le procedure ICE regolari.
Il nuovo candidato viene quindi verificato per la ridondanza rispetto all'elenco esistente di candidati locali. Se il suo indirizzo di trasporto e la base corrispondono a quelli di un candidato esistente, sarà considerato ridondante e sarà ignorato. Questo accadrebbe spesso per i candidati riflessivi del server che corrispondono agli indirizzi host da cui sono stati ottenuti (ad esempio, quando questi ultimi sono indirizzi IPv4 pubblici). Contrariamente all'ICE regolare, gli agenti Trickle ICE considereranno il nuovo candidato ridondante indipendentemente dalla sua priorità.
Successivamente, l'agente "trickle" i candidati appena scoperti all'agente remoto. La consegna effettiva dei nuovi candidati è gestita da un protocollo di utilizzo come SIP o XMPP. Trickle ICE non impone restrizioni sul modo in cui ciò viene fatto (ad esempio, alcuni protocolli di utilizzo potrebbero scegliere di non trickle gli aggiornamenti per i candidati riflessivi del server e fare affidamento invece sulla scoperta di quelli riflessivi del peer).
Quando i candidati vengono trickle, il protocollo di utilizzo deve (MUST) consegnare ogni candidato (e qualsiasi indicazione di fine candidati come descritto nella sezione 13) all'implementazione Trickle ICE ricevente esattamente una volta e nello stesso ordine in cui è stato trasmesso. Se il protocollo di utilizzo fornisce ritrasmissioni di candidati, queste devono essere nascoste all'implementazione ICE.
Inoltre, il trickling dei candidati deve essere correlato a una sessione ICE specifica, in modo che se c'è un riavvio ICE, eventuali aggiornamenti ritardati per una sessione precedente possano essere riconosciuti come tali e ignorati dalla parte ricevente. Ad esempio, i protocolli di utilizzo che segnalano i candidati tramite SDP potrebbero includere un valore di frammento nome utente (Username Fragment) nella riga a=candidate corrispondente, come:
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
Oppure, come altro esempio, le implementazioni WebRTC potrebbero includere un frammento nome utente negli oggetti JavaScript che rappresentano i candidati.
Nota: Il protocollo di utilizzo deve fornire un meccanismo affinché entrambe le parti indichino e concordino sulla sessione ICE in vigore (identificata dalla combinazione di frammento nome utente e password), in modo che abbiano una visione coerente di quali candidati devono essere accoppiati. Questo è particolarmente importante nel caso di riavvii ICE (vedere sezione 15).
Nota: Un protocollo di utilizzo potrebbe preferire non trickle i candidati riflessivi del server a entità che sono note per essere pubblicamente accessibili e dove l'invio di una richiesta di binding STUN diretta è probabile che raggiunga la destinazione più velocemente dell'aggiornamento trickle che viaggia attraverso il percorso di segnalazione.