Skip to main content

11. Receiving Trickled Candidates (接收渐进式候选地址)

🇨🇳 中文​

在ICE会话期间的任何时间，Trickle ICE代理都可能从远程代理接收新候选地址，并尝试从中形成候选地址对；这按照ICE规范 [RFC8445] 中的描述工作，但有以下附加条件：

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

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

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

  4. 代理按照下面的描述修剪冗余候选地址对，但仅检查处于等待 (Waiting) 或冻结 (Frozen) 状态的现有候选地址对；这避免了移除正在进行连接性检查的候选地址对（进行中 (In-Progress) 状态）或已经产生明确结果的候选地址对（成功 (Succeeded) 或失败 (Failed) 状态）。

    A. 如果代理在两个候选地址对之间发现冗余，并且其中一个候选地址对包含类型为对等反射 (peer-reflexive) 的新接收远程候选地址，代理应该 (SHOULD) 丢弃包含该候选地址的候选地址对，将现有候选地址对的优先级设置为被丢弃候选地址对的优先级，并重新排序检查列表。（此策略有助于消除在候选地址的信令被渐进式交换到接收代理之前收到STUN绑定请求的远程对等反射候选地址的问题，例如本地代理和远程代理之间对候选地址对优先级的不同视图，因为同一候选地址可能被一个代理视为对等反射，而被另一个代理视为服务器反射。）

    B. 然后，代理应用 [RFC8445] 第6.1.2.4节中定义的规则。

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

🇬🇧 English​

At any time during an ICE session, a Trickle ICE agent might receive new candidates from the remote agent, from which it will attempt to form a candidate pair; this works as described in the ICE specification [RFC8445], with the following provisos:

  1. The agent checks if any local candidates are currently known for this same stream and component. If not, the agent merely adds the new candidate to the list of remote candidates (without pairing it).

  2. Otherwise, if the agent has already gathered one or more local candidates for this stream and component, it attempts to pair the new remote candidate as described in the ICE specification [RFC8445].

  3. If a newly formed pair has a local candidate whose type is server-reflexive, the agent MUST replace the local candidate with its base before completing the redundancy check in the next step.

  4. The agent prunes redundant pairs as described below but checks existing pairs only if they have a state of Waiting or Frozen; this avoids removal of pairs for which connectivity checks are in flight (a state of In-Progress) or for which connectivity checks have already yielded a definitive result (a state of Succeeded or Failed).

    A. If the agent finds a redundancy between two pairs and one of those pairs contains a newly received remote candidate whose type is peer-reflexive, the agent SHOULD discard the pair containing that candidate, set the priority of the existing pair to the priority of the discarded pair, and re-sort the checklist. (This policy helps to eliminate problems with remote peer-reflexive candidates for which a STUN Binding request is received before signaling of the candidate is trickled to the receiving agent, such as a different view of pair priorities between the local agent and the remote agent, because the same candidate could be perceived as peer-reflexive by one agent and as server-reflexive by the other agent.)

    B. The agent then applies the rules defined in Section 6.1.2.4 of [RFC8445].

  5. If, after completing the relevant redundancy tests, the checklist where the pair is to be added already contains the maximum number of candidate pairs (100 by default as per [RFC8445]), the agent SHOULD discard any pairs in the Failed state to make room for the new pair. If there are no such pairs, the agent SHOULD discard a pair with a lower priority than the new pair in order to make room for the new pair, until the number of pairs is equal to the maximum number of pairs. This processing is consistent with Section 6.1.2.5 of [RFC8445].

🇯🇵 日本語​

ICEセッション中のいつでも、Trickle ICEエージェントはリモートエージェントから新しい候補を受信し、そこから候補ペアを形成しようとする場合があります。これはICE仕様 [RFC8445] に記載されているとおりに機能しますが、次の条件があります：

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

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

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

  4. エージェントは以下に説明するように冗長ペアを整理しますが、待機中 (Waiting) または凍結 (Frozen) 状態の既存のペアのみをチェックします。これにより、接続性チェックが進行中（進行中 (In-Progress) 状態）または接続性チェックがすでに決定的な結果をもたらした（成功 (Succeeded) または失敗 (Failed) 状態）ペアの削除が回避されます。

    A. エージェントが2つのペア間で冗長性を見つけ、それらのペアの1つにタイプがピア反射 (peer-reflexive) の新しく受信されたリモート候補が含まれている場合、エージェントはその候補を含むペアを破棄し、既存のペアの優先度を破棄されたペアの優先度に設定し、チェックリストを再ソートすべきです (SHOULD)。（このポリシーは、候補のシグナリングが受信エージェントにトリクルされる前にSTUNバインディングリクエストが受信されるリモートピア反射候補の問題を排除するのに役立ちます。たとえば、ローカルエージェントとリモートエージェント間のペア優先度の異なるビューなどです。同じ候補が、あるエージェントによってピア反射と認識され、別のエージェントによってサーバー反射と認識される可能性があるためです。）

    B. 次に、エージェントは [RFC8445] の第6.1.2.4節で定義された規則を適用します。

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

🇫🇷 Français​

À tout moment pendant une session ICE, un agent Trickle ICE peut recevoir de nouveaux candidats de l'agent distant, à partir desquels il tentera de former une paire de candidats ; cela fonctionne comme décrit dans la spécification ICE [RFC8445], avec les conditions suivantes :

  1. L'agent vérifie si des candidats locaux 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 distants (sans l'apparier).

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

  3. 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 la vérification de redondance à l'étape suivante.

  4. L'agent élague les paires redondantes comme décrit ci-dessous 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)).

    A. Si l'agent trouve une redondance entre deux paires et que l'une de ces paires contient un candidat distant nouvellement reçu dont le type est réflexif de pair (peer-reflexive), l'agent devrait (SHOULD) rejeter la paire contenant ce candidat, définir la priorité de la paire existante sur la priorité de la paire rejetée et retrier la liste de vérification. (Cette politique aide à éliminer les problèmes avec les candidats réflexifs de pair distants pour lesquels une demande de liaison STUN est reçue avant que la signalisation du candidat ne soit trickle vers l'agent récepteur, comme une vue différente des priorités de paire entre l'agent local et l'agent distant, car le même candidat pourrait être perçu comme réflexif de pair par un agent et comme réflexif de serveur par l'autre agent.)

    B. L'agent applique ensuite les règles définies dans la section 6.1.2.4 de [RFC8445].

  5. 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​

Zu jedem Zeitpunkt während einer ICE-Sitzung kann ein Trickle-ICE-Agent neue Kandidaten vom entfernten Agent empfangen, aus denen er versucht, ein Kandidatenpaar zu bilden; dies funktioniert wie in der ICE-Spezifikation [RFC8445] beschrieben, mit den folgenden Bedingungen:

  1. Der Agent überprüft, ob derzeit lokale Kandidaten für denselben Stream und dieselbe Komponente bekannt sind. Wenn nicht, fügt der Agent den neuen Kandidaten lediglich zur Liste der entfernten Kandidaten hinzu (ohne ihn zu paaren).

  2. Andernfalls, wenn der Agent bereits einen oder mehrere lokale Kandidaten für diesen Stream und diese Komponente gesammelt hat, versucht er, den neuen entfernten Kandidaten zu paaren, wie in der ICE-Spezifikation [RFC8445] beschrieben.

  3. 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 Redundanzprüfung im nächsten Schritt abschließt.

  4. Der Agent beschneidet redundante Paare wie unten beschrieben, ü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)).

    A. Wenn der Agent eine Redundanz zwischen zwei Paaren findet und eines dieser Paare einen neu empfangenen entfernten Kandidaten enthält, dessen Typ peer-reflexiv ist, sollte (SHOULD) der Agent das Paar mit diesem Kandidaten verwerfen, die Priorität des vorhandenen Paars auf die Priorität des verworfenen Paars setzen und die Checkliste neu sortieren. (Diese Richtlinie hilft, Probleme mit entfernten peer-reflexiven Kandidaten zu beseitigen, für die eine STUN-Bindungsanforderung empfangen wird, bevor die Signalisierung des Kandidaten zum empfangenden Agent getricklet wird, wie z. B. eine unterschiedliche Ansicht der Paarprioritäten zwischen dem lokalen Agent und dem entfernten Agent, da derselbe Kandidat von einem Agent als peer-reflexiv und vom anderen Agent als serverreflexiv wahrgenommen werden könnte.)

    B. Der Agent wendet dann die in Abschnitt 6.1.2.4 von [RFC8445] definierten Regeln an.

  5. 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​

In qualsiasi momento durante una sessione ICE, un agente Trickle ICE potrebbe ricevere nuovi candidati dall'agente remoto, da cui tenterà di formare una coppia di candidati; questo funziona come descritto nella specifica ICE [RFC8445], con le seguenti condizioni:

  1. L'agente verifica se sono attualmente noti candidati locali per questo stesso flusso e componente. In caso contrario, l'agente aggiunge semplicemente il nuovo candidato all'elenco dei candidati remoti (senza accoppiarlo).

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

  3. 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 il controllo di ridondanza nel passaggio successivo.

  4. L'agente elimina le coppie ridondanti come descritto di seguito 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)).

    A. Se l'agente trova una ridondanza tra due coppie e una di queste coppie contiene un candidato remoto appena ricevuto il cui tipo è riflessivo del peer (peer-reflexive), l'agente dovrebbe (SHOULD) scartare la coppia contenente quel candidato, impostare la priorità della coppia esistente sulla priorità della coppia scartata e riordinare la checklist. (Questa politica aiuta a eliminare i problemi con i candidati riflessivi del peer remoti per i quali viene ricevuta una richiesta di binding STUN prima che la segnalazione del candidato venga trickle all'agente ricevente, come una visione diversa delle priorità delle coppie tra l'agente locale e l'agente remoto, perché lo stesso candidato potrebbe essere percepito come riflessivo del peer da un agente e come riflessivo del server dall'altro agente.)

    B. L'agente applica quindi le regole definite nella sezione 6.1.2.4 di [RFC8445].

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