Skip to main content

10. Pairing Newly Gathered Local Candidates (配对新收集的本地候选地址)

🇨🇳 中文​

当Trickle ICE代理收集本地候选地址时，它需要形成候选地址对；这按照ICE规范 [RFC8445] 中的描述工作，但有以下附加条件：

  1. Trickle ICE代理禁止 (MUST NOT) 在本地候选地址被渐进式交换到远程方之前对其进行配对。

  2. 一旦代理将本地候选地址传递给远程方，代理将检查当前是否已知该相同流和组件的任何远程候选地址。如果没有，代理仅将新候选地址添加到本地候选地址列表（而不对其进行配对）。

  3. 否则，如果代理已经了解到该流和组件的一个或多个远程候选地址，它将尝试按照ICE规范 [RFC8445] 中的描述配对新的本地候选地址。

  4. 如果新形成的候选地址对具有类型为服务器反射 (server-reflexive) 的本地候选地址，代理必须 (MUST) 在完成相关冗余测试之前用其基地址替换该本地候选地址。

  5. 代理通过遵循 [RFC8445] 第6.1.2.4节中的规则修剪冗余候选地址对，但仅检查处于等待 (Waiting) 或冻结 (Frozen) 状态的现有候选地址对；这避免了移除正在进行连接性检查的候选地址对（进行中 (In-Progress) 状态）或已经产生明确结果的候选地址对（成功 (Succeeded) 或失败 (Failed) 状态）。

  6. 如果在完成相关冗余测试后，要添加候选地址对的检查列表已包含最大数量的候选地址对（根据 [RFC8445] 默认为100个），代理应该 (SHOULD) 丢弃处于失败状态的任何候选地址对以为新候选地址对腾出空间。如果没有此类候选地址对，代理应该 (SHOULD) 丢弃优先级低于新候选地址对的候选地址对，以便为新候选地址对腾出空间，直到候选地址对数量等于最大候选地址对数量。此处理与 [RFC8445] 的第6.1.2.5节一致。

🇬🇧 English​

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].

🇯🇵 日本語​

Trickle ICEエージェントがローカル候補を収集する際、候補ペアを形成する必要があります。これはICE仕様 [RFC8445] に記載されているとおりに機能しますが、次の条件があります：

  1. Trickle ICEエージェントは、ローカル候補がリモート側にトリクルされるまで、そのローカル候補をペアリングしてはなりません (MUST NOT)。

  2. エージェントがローカル候補をリモート側に伝達すると、エージェントは、この同じストリームとコンポーネントについて現在既知のリモート候補があるかどうかをチェックします。ない場合、エージェントは新しい候補をローカル候補のリストに追加するだけです（ペアリングせずに）。

  3. それ以外の場合、エージェントがこのストリームとコンポーネントについて1つ以上のリモート候補をすでに学習している場合、ICE仕様 [RFC8445] に記載されているとおりに新しいローカル候補をペアリングしようとします。

  4. 新しく形成されたペアにタイプがサーバー反射 (server-reflexive) のローカル候補がある場合、エージェントは関連する冗長性テストを完了する前に、そのローカル候補をそのベースで置き換えなければなりません (MUST)。

  5. エージェントは [RFC8445] の第6.1.2.4節の規則に従って冗長ペアを整理しますが、待機中 (Waiting) または凍結 (Frozen) 状態の既存のペアのみをチェックします。これにより、接続性チェックが進行中（進行中 (In-Progress) 状態）または接続性チェックがすでに決定的な結果をもたらした（成功 (Succeeded) または失敗 (Failed) 状態）ペアの削除が回避されます。

  6. 関連する冗長性テストを完了した後、ペアが追加されるチェックリストにすでに最大数の候補ペア（[RFC8445] によるとデフォルトで100個）が含まれている場合、エージェントは失敗状態のペアを破棄して新しいペアのためのスペースを作るべきです (SHOULD)。そのようなペアがない場合、エージェントはペアの数が最大ペア数に等しくなるまで、新しいペアよりも優先度が低いペアを破棄して新しいペアのためのスペースを作るべきです (SHOULD)。この処理は [RFC8445] の第6.1.2.5節と一致しています。

🇫🇷 Français​

Lorsqu'un agent Trickle ICE collecte des candidats locaux, il doit former des paires de candidats ; cela fonctionne comme décrit dans la spécification ICE [RFC8445], avec les conditions suivantes :

  1. Un agent Trickle ICE ne doit pas (MUST NOT) apparier un candidat local tant qu'il n'a pas été trickle vers la partie distante.

  2. Une fois que l'agent a transmis le candidat local à la partie distante, l'agent vérifie si des candidats distants sont actuellement connus pour ce même flux et composant. Si ce n'est pas le cas, l'agent ajoute simplement le nouveau candidat à la liste des candidats locaux (sans l'apparier).

  3. Sinon, si l'agent a déjà appris un ou plusieurs candidats distants pour ce flux et ce composant, il tente d'apparier le nouveau candidat local comme décrit dans la spécification ICE [RFC8445].

  4. Si une paire nouvellement formée a un candidat local dont le type est réflexif de serveur (server-reflexive), l'agent doit (MUST) remplacer le candidat local par sa base avant de terminer les tests de redondance pertinents.

  5. L'agent élague les paires redondantes en suivant les règles de la section 6.1.2.4 de [RFC8445] mais vérifie les paires existantes uniquement si elles ont un état En attente (Waiting) ou Gelé (Frozen) ; cela évite la suppression de paires pour lesquelles des vérifications de connectivité sont en cours (un état En cours (In-Progress)) ou pour lesquelles les vérifications de connectivité ont déjà donné un résultat définitif (un état Réussi (Succeeded) ou Échec (Failed)).

  6. Si, après avoir terminé les tests de redondance pertinents, la liste de vérification où la paire doit être ajoutée contient déjà le nombre maximum de paires de candidats (100 par défaut selon [RFC8445]), l'agent devrait (SHOULD) rejeter toutes les paires dans l'état Échec pour faire de la place à la nouvelle paire. S'il n'y a pas de telles paires, l'agent devrait (SHOULD) rejeter une paire avec une priorité inférieure à la nouvelle paire afin de faire de la place pour la nouvelle paire, jusqu'à ce que le nombre de paires soit égal au nombre maximum de paires. Ce traitement est cohérent avec la section 6.1.2.5 de [RFC8445].

🇩🇪 Deutsch​

Wenn ein Trickle-ICE-Agent lokale Kandidaten sammelt, muss er Kandidatenpaare bilden; dies funktioniert wie in der ICE-Spezifikation [RFC8445] beschrieben, mit den folgenden Bedingungen:

  1. Ein Trickle-ICE-Agent darf nicht (MUST NOT) einen lokalen Kandidaten paaren, bis er zur entfernten Partei getricklet wurde.

  2. Sobald der Agent den lokalen Kandidaten zur entfernten Partei übermittelt hat, überprüft der Agent, ob derzeit entfernte Kandidaten für denselben Stream und dieselbe Komponente bekannt sind. Wenn nicht, fügt der Agent den neuen Kandidaten lediglich zur Liste der lokalen Kandidaten hinzu (ohne ihn zu paaren).

  3. Andernfalls, wenn der Agent bereits von einem oder mehreren entfernten Kandidaten für diesen Stream und diese Komponente erfahren hat, versucht er, den neuen lokalen Kandidaten zu paaren, wie in der ICE-Spezifikation [RFC8445] beschrieben.

  4. Wenn ein neu gebildetes Paar einen lokalen Kandidaten hat, dessen Typ serverreflexiv (server-reflexive) ist, muss (MUST) der Agent den lokalen Kandidaten durch seine Basis ersetzen, bevor er die relevanten Redundanztests abschließt.

  5. Der Agent beschneidet redundante Paare, indem er den Regeln in Abschnitt 6.1.2.4 von [RFC8445] folgt, überprüft jedoch vorhandene Paare nur, wenn sie einen Zustand Wartend (Waiting) oder Eingefroren (Frozen) haben; dies vermeidet das Entfernen von Paaren, für die Konnektivitätsprüfungen laufen (ein Zustand In Bearbeitung (In-Progress)) oder für die Konnektivitätsprüfungen bereits ein eindeutiges Ergebnis erbracht haben (ein Zustand Erfolgreich (Succeeded) oder Fehlgeschlagen (Failed)).

  6. Wenn nach Abschluss der relevanten Redundanztests die Checkliste, zu der das Paar hinzugefügt werden soll, bereits die maximale Anzahl von Kandidatenpaaren enthält (standardmäßig 100 gemäß [RFC8445]), sollte (SHOULD) der Agent alle Paare im Zustand Fehlgeschlagen verwerfen, um Platz für das neue Paar zu schaffen. Wenn es keine solchen Paare gibt, sollte (SHOULD) der Agent ein Paar mit niedrigerer Priorität als das neue Paar verwerfen, um Platz für das neue Paar zu schaffen, bis die Anzahl der Paare gleich der maximalen Anzahl von Paaren ist. Diese Verarbeitung ist konsistent mit Abschnitt 6.1.2.5 von [RFC8445].

🇮🇹 Italiano​

Quando un agente Trickle ICE raccoglie candidati locali, deve formare coppie di candidati; questo funziona come descritto nella specifica ICE [RFC8445], con le seguenti condizioni:

  1. Un agente Trickle ICE non deve (MUST NOT) accoppiare un candidato locale finché non è stato trickle alla parte remota.

  2. Una volta che l'agente ha trasmesso il candidato locale alla parte remota, l'agente verifica se sono attualmente noti candidati remoti per questo stesso flusso e componente. In caso contrario, l'agente aggiunge semplicemente il nuovo candidato all'elenco dei candidati locali (senza accoppiarlo).

  3. Altrimenti, se l'agente ha già appreso di uno o più candidati remoti per questo flusso e componente, tenta di accoppiare il nuovo candidato locale come descritto nella specifica ICE [RFC8445].

  4. Se una coppia appena formata ha un candidato locale il cui tipo è riflessivo del server (server-reflexive), l'agente deve (MUST) sostituire il candidato locale con la sua base prima di completare i test di ridondanza pertinenti.

  5. L'agente elimina le coppie ridondanti seguendo le regole nella sezione 6.1.2.4 di [RFC8445] ma verifica le coppie esistenti solo se hanno uno stato In attesa (Waiting) o Congelato (Frozen); questo evita la rimozione di coppie per le quali i controlli di connettività sono in corso (uno stato In corso (In-Progress)) o per le quali i controlli di connettività hanno già prodotto un risultato definitivo (uno stato Riuscito (Succeeded) o Fallito (Failed)).

  6. Se, dopo aver completato i test di ridondanza pertinenti, la checklist in cui deve essere aggiunta la coppia contiene già il numero massimo di coppie di candidati (100 per impostazione predefinita secondo [RFC8445]), l'agente dovrebbe (SHOULD) scartare tutte le coppie nello stato Fallito per fare spazio alla nuova coppia. Se non ci sono tali coppie, l'agente dovrebbe (SHOULD) scartare una coppia con priorità inferiore rispetto alla nuova coppia per fare spazio alla nuova coppia, fino a quando il numero di coppie è uguale al numero massimo di coppie. Questa elaborazione è coerente con la sezione 6.1.2.5 di [RFC8445].

Last updated on