12. Inserting Trickled Candidate Pairs into a Checklist (将渐进式候选地址对插入检查列表)
🇨🇳 中文
在本地代理渐进式交换候选地址并从该本地候选地址形成候选地址对之后（第9节），或者在远程代理接收到渐进式候选地址并从该远程候选地址形成候选地址对之后（第11节），Trickle ICE代理按照本节定义的方式将新候选地址对添加到检查列表中。
为了帮助理解本节中定义的过程，请考虑代理中所有检查列表的以下表格表示（请注意，最初对于其中一个基础 (foundation)，即f5，没有候选地址对）：
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
表1: 检查列表状态示例
表中的每一行代表给定数据流的一个组件（例如，s1和s2可能是音频的RTP和RTP控制协议 (RTCP) 组件），因此是检查列表集中的单个检查列表。每一列代表一个基础。每个单元格代表一个候选地址对。在本节显示的表中，"F"代表"冻结 (frozen)"，"W"代表"等待 (waiting)"，"S"代表"成功 (succeeded)"；此外，"^^"用于标记新添加的候选地址对。
当代理按照 [RFC8445] 的第6.1.2.6节开始ICE处理时，对于每个基础，它将解冻具有最低组件ID的候选地址对，如果组件ID相等，则解冻具有最高优先级的候选地址对（这是每列中最顶部的候选地址对）。此初始状态如下表所示。
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | W | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
表2: 初始检查列表状态
然后，随着检查的进行（参见 [RFC8445] 的第7.2.5.4节），对于每个进入成功状态的候选地址对（此处用"S"表示），代理将解冻具有相同基础的所有数据流的所有候选地址对（例如，如果第1列第1行的候选地址对成功，则代理将解冻第1列第2、3和4行的候选地址对）。
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | S | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+----+
表3: 具有成功候选地址对的检查列表状态
Trickle ICE保留所有这些规则，因为它们适用于"静态"检查列表集。这意味着如果Trickle ICE代理在所有候选地址对已经存在的情况下开始连接性检查，候选地址对状态的变化方式与常规ICE代理无法区分。
当然，Trickle ICE的主要区别在于检查列表集可以动态更新，因为候选地址可以在连接性检查开始后到达。当这种情况发生时，代理按照下面的描述设置新形成的候选地址对的状态。
规则1： 如果新形成的候选地址对具有该基础的所有候选地址对中最低的组件ID，如果组件ID相等则具有最高优先级（即，如果它是列中最顶部的候选地址对），则将状态设置为等待 (Waiting)。例如，如果新形成的候选地址对被放置在第5列第1行，就会是这种情况。此规则与 [RFC8445] 的第6.1.2.6节一致。
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
表4: 具有新形成候选地址对的检查列表状态，规则1
规则2： 如果该基础至少有一个候选地址对处于成功状态，则将状态设置为等待 (Waiting)。例如，如果第5列第1行的候选地址对成功并且新形成的候选地址对被放置在第5列第2行，就会是这种情况。此规则与 [RFC8445] 的第7.2.5.3.3节一致。
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
表5: 具有新形成候选地址对的检查列表状态，规则2
规则3： 在所有其他情况下，将状态设置为冻结 (Frozen)。例如，如果新形成的候选地址对被放置在第3列第3行，就会是这种情况。
+=================+====+====+=====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+=====+====+====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+-----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+----+----+-----+----+----+
| s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+----+----+-----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+-----+----+----+
表6: 具有新形成候选地址对的检查列表状态，规则3
🇬🇧 English
After a local agent has trickled a candidate and formed a candidate pair from that local candidate (Section 9), or after a remote agent has received a trickled candidate and formed a candidate pair from that remote candidate (Section 11), a Trickle ICE agent adds the new candidate pair to a checklist as 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 agent (note that initially for one of the foundations, i.e., f5, there are no candidate pairs):
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Table 1: Example of Checklist State
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) components for audio) and thus a single checklist in the checklist set. Each column represents one foundation. Each cell represents one candidate pair. In the tables shown in this section, "F" stands for "frozen", "W" stands for "waiting", and "S" stands for "succeeded"; in addition, "^^" is used to notate newly added candidate pairs.
When an agent commences ICE processing, in accordance with Section 6.1.2.6 of [RFC8445], for each foundation it will unfreeze the pair with the lowest component ID and, if the component IDs are equal, with the highest priority (this is the topmost candidate pair in every column). This initial state is shown in the following table.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | W | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Table 2: Initial Checklist State
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 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 agent will unfreeze the pairs in column 1, rows 2, 3, and 4).
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | S | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+----+
Table 3: Checklist State with Succeeded Candidate Pair
Trickle ICE preserves all of these rules as they apply to "static" checklist sets. This implies that if a Trickle ICE agent were to begin connectivity checks with all of its pairs already present, the way that pair states change is indistinguishable from that of a regular ICE agent.
Of course, the major difference with Trickle ICE is that checklist sets can be dynamically updated because candidates can arrive after connectivity checks have started. When this happens, an agent sets the state of the newly formed pair as described below.
Rule 1: If the newly formed pair has the lowest component ID and, if the component IDs are equal, the highest priority of any candidate pair for this foundation (i.e., if it is the topmost pair in the column), set the state to Waiting. For example, this would be the case if the newly formed pair were placed in column 5, row 1. This rule is consistent with Section 6.1.2.6 of [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Table 4: Checklist State with Newly Formed Pair, Rule 1
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 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 Section 7.2.5.3.3 of [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Table 5: Checklist State with Newly Formed Pair, Rule 2
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 3, row 3.
+=================+====+====+=====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+=====+====+====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+-----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+----+----+-----+----+----+
| s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+----+----+-----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+-----+----+----+
Table 6: Checklist State with Newly Formed Pair, Rule 3
🇯🇵 日本語
ローカルエージェントが候補をトリクルし、そのローカル候補から候補ペアを形成した後（第9節）、またはリモートエージェントがトリクルされた候補を受信し、そのリモート候補から候補ペアを形成した後（第11節）、Trickle ICEエージェントは本節で定義されているように新しい候補ペアをチェックリストに追加します。
本節で定義されている手順を理解するのに役立つように、エージェント内のすべてのチェックリストの次の表形式の表現を検討してください（最初、基礎（foundation）の1つ、つまりf5には候補ペアがないことに注意してください）：
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
表1: チェックリスト状態の例
表の各行は、特定のデータストリームのコンポーネント（たとえば、s1とs2はオーディオのRTPおよびRTP制御プロトコル（RTCP）コンポーネントである可能性があります）を表し、したがってチェックリストセット内の単一のチェックリストを表します。各列は1つの基礎を表します。各セルは1つの候補ペアを表します。本節に示されている表では、「F」は「凍結（frozen）」、「W」は「待機中（waiting）」、「S」は「成功（succeeded）」を表します。さらに、「^^」は新しく追加された候補ペアを示すために使用されます。
エージェントが [RFC8445] の第6.1.2.6節に従ってICE処理を開始すると、各基礎について、最小のコンポーネントIDを持つペアを解凍し、コンポーネントIDが等しい場合は最高の優先度を持つペアを解凍します（これは各列の最上位の候補ペアです）。この初期状態を次の表に示します。
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | W | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
表2: 初期チェックリスト状態
次に、チェックが進行するにつれて（[RFC8445] の第7.2.5.4節を参照）、成功状態に入る各ペア（ここでは「S」で示されます）について、エージェントは同じ基礎を持つすべてのデータストリームのすべてのペアを解凍します（たとえば、列1、行1のペアが成功した場合、エージェントは列1、行2、3、および4のペアを解凍します）。
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | S | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+----+
表3: 成功した候補ペアを含むチェックリスト状態
Trickle ICEは、「静的」チェックリストセットに適用されるこれらのすべての規則を保持します。これは、Trickle ICEエージェントがすべてのペアがすでに存在する状態で接続性チェックを開始する場合、ペア状態が変化する方法は通常のICEエージェントと区別がつかないことを意味します。
もちろん、Trickle ICEの主な違いは、接続性チェックが開始された後に候補が到着する可能性があるため、チェックリストセットを動的に更新できることです。これが発生すると、エージェントは以下に説明するように新しく形成されたペアの状態を設定します。
規則1： 新しく形成されたペアが、この基礎の任意の候補ペアの中で最も低いコンポーネントIDを持ち、コンポーネントIDが等しい場合は最も高い優先度を持つ場合（つまり、列の最上位のペアである場合）、状態を待機中（Waiting）に設定します。たとえば、新しく形成されたペアが列5、行1に配置される場合がこれに該当します。この規則は [RFC8445] の第6.1.2.6節と一致しています。
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
表4: 新しく形成されたペアを含むチェックリスト状態、規則1
規則2： この基礎について成功状態のペアが少なくとも1つある場合、状態を待機中（Waiting）に設定します。たとえば、列5、行1のペアが成功し、新しく形成されたペアが列5、行2に配置される場合がこれに該当します。この規則は [RFC8445] の第7.2.5.3.3節と一致しています。
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
表5: 新しく形成されたペアを含むチェックリスト状態、規則2
規則3： 他のすべての場合、状態を凍結（Frozen）に設定します。たとえば、新しく形成されたペアが列3、行3に配置される場合がこれに該当します。
+=================+====+====+=====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+=====+====+====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+-----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+----+----+-----+----+----+
| s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+----+----+-----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+-----+----+----+
表6: 新しく形成されたペアを含むチェックリスト状態、規則3
🇫🇷 Français
Après qu'un agent local a trickle un candidat et formé une paire de candidats à partir de ce candidat local (Section 9), ou après qu'un agent distant a reçu un candidat trickle et formé une paire de candidats à partir de ce candidat distant (Section 11), un agent Trickle ICE ajoute la nouvelle paire de candidats à une liste de vérification comme défini dans cette section.
Pour aider à comprendre les procédures définies dans cette section, considérez la représentation tabulaire suivante de toutes les listes de vérification dans un agent (notez qu'initialement pour l'une des fondations, c'est-à-dire f5, il n'y a pas de paires de candidats) :
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Tableau 1 : Exemple d'état de liste de vérification
Chaque ligne du tableau représente un composant pour un flux de données donné (par exemple, s1 et s2 pourraient être les composants RTP et RTCP pour l'audio) et donc une seule liste de vérification dans l'ensemble de listes de vérification. Chaque colonne représente une fondation. Chaque cellule représente une paire de candidats. Dans les tableaux de cette section, « F » signifie « gelé (frozen) », « W » signifie « en attente (waiting) » et « S » signifie « réussi (succeeded) » ; de plus, « ^^ » est utilisé pour noter les paires de candidats nouvellement ajoutées.
Lorsqu'un agent commence le traitement ICE, conformément à la section 6.1.2.6 de [RFC8445], pour chaque fondation, il dégelera la paire avec l'ID de composant le plus bas et, si les ID de composant sont égaux, avec la priorité la plus élevée. Cet état initial est montré dans le tableau suivant.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | W | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Tableau 2 : État initial de la liste de vérification
Ensuite, au fur et à mesure que les vérifications progressent (voir section 7.2.5.4 de [RFC8445]), pour chaque paire qui entre dans l'état Réussi (noté ici par « S »), l'agent dégelera toutes les paires pour tous les flux de données avec la même fondation.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | S | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+----+
Tableau 3 : État de liste de vérification avec paire de candidats réussie
Trickle ICE préserve toutes ces règles car elles s'appliquent aux ensembles de listes de vérification « statiques ». Cela implique que si un agent Trickle ICE devait commencer les vérifications de connectivité avec toutes ses paires déjà présentes, la façon dont les états de paire changent est indiscernable de celle d'un agent ICE régulier.
Bien sûr, la principale différence avec Trickle ICE est que les ensembles de listes de vérification peuvent être mis à jour dynamiquement car les candidats peuvent arriver après le début des vérifications de connectivité. Lorsque cela se produit, un agent définit l'état de la paire nouvellement formée comme décrit ci-dessous.
Règle 1 : Si la paire nouvellement formée a l'ID de composant le plus bas et, si les ID de composant sont égaux, la priorité la plus élevée de toute paire de candidats pour cette fondation (c'est-à-dire si c'est la paire la plus haute dans la colonne), définir l'état sur En attente (Waiting). Cette règle est cohérente avec la section 6.1.2.6 de [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Tableau 4 : État de liste de vérification avec paire nouvellement formée, Règle 1
Règle 2 : S'il y a au moins une paire dans l'état Réussi pour cette fondation, définir l'état sur En attente (Waiting). Cette règle est cohérente avec la section 7.2.5.3.3 de [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Tableau 5 : État de liste de vérification avec paire nouvellement formée, Règle 2
Règle 3 : Dans tous les autres cas, définir l'état sur Gelé (Frozen).
+=================+====+====+=====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+=====+====+====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+-----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+----+----+-----+----+----+
| s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+----+----+-----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+-----+----+----+
Tableau 6 : État de liste de vérification avec paire nouvellement formée, Règle 3
🇩🇪 Deutsch
Nachdem ein lokaler Agent einen Kandidaten getricklet und ein Kandidatenpaar aus diesem lokalen Kandidaten gebildet hat (Abschnitt 9), oder nachdem ein entfernter Agent einen getrickleten Kandidaten empfangen und ein Kandidatenpaar aus diesem entfernten Kandidaten gebildet hat (Abschnitt 11), fügt ein Trickle-ICE-Agent das neue Kandidatenpaar zu einer Checkliste hinzu, wie in diesem Abschnitt definiert.
Um das Verständnis der in diesem Abschnitt definierten Verfahren zu erleichtern, betrachten Sie die folgende tabellarische Darstellung aller Checklisten in einem Agent (beachten Sie, dass zunächst für eine der Foundations, d. h. f5, keine Kandidatenpaare vorhanden sind):
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Tabelle 1: Beispiel für Checklistenzustand
Jede Zeile in der Tabelle repräsentiert eine Komponente für einen gegebenen Datenstrom und somit eine einzelne Checkliste im Checklistensatz. Jede Spalte repräsentiert eine Foundation. Jede Zelle repräsentiert ein Kandidatenpaar. In den in diesem Abschnitt gezeigten Tabellen steht „F" für „eingefroren (frozen)", „W" für „wartend (waiting)" und „S" für „erfolgreich (succeeded)"; außerdem wird „^^" verwendet, um neu hinzugefügte Kandidatenpaare zu kennzeichnen.
Wenn ein Agent die ICE-Verarbeitung beginnt, gemäß Abschnitt 6.1.2.6 von [RFC8445], friert er für jede Foundation das Paar mit der niedrigsten Komponenten-ID auf, und wenn die Komponenten-IDs gleich sind, mit der höchsten Priorität. Dieser Anfangszustand wird in der folgenden Tabelle gezeigt.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | W | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Tabelle 2: Anfänglicher Checklistenzustand
Dann, während die Prüfungen fortschreiten (siehe Abschnitt 7.2.5.4 von [RFC8445]), friert der Agent für jedes Paar, das in den Zustand Erfolgreich eintritt (hier mit „S" bezeichnet), alle Paare für alle Datenströme mit derselben Foundation auf.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | S | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+----+
Tabelle 3: Checklistenzustand mit erfolgreichem Kandidatenpaar
Trickle ICE bewahrt alle diese Regeln, da sie für „statische" Checklistensätze gelten. Dies bedeutet, dass wenn ein Trickle-ICE-Agent Konnektivitätsprüfungen mit allen seinen bereits vorhandenen Paaren beginnen würde, die Art und Weise, wie sich Paarzustände ändern, von der eines regulären ICE-Agents nicht zu unterscheiden ist.
Natürlich besteht der Hauptunterschied bei Trickle ICE darin, dass Checklistensätze dynamisch aktualisiert werden können, da Kandidaten nach Beginn der Konnektivitätsprüfungen ankommen können. Wenn dies geschieht, setzt ein Agent den Zustand des neu gebildeten Paars wie unten beschrieben.
Regel 1: Wenn das neu gebildete Paar die niedrigste Komponenten-ID und, wenn die Komponenten-IDs gleich sind, die höchste Priorität eines Kandidatenpaares für diese Foundation hat (d. h. wenn es das oberste Paar in der Spalte ist), setzen Sie den Zustand auf Wartend (Waiting). Diese Regel ist konsistent mit Abschnitt 6.1.2.6 von [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Tabelle 4: Checklistenzustand mit neu gebildetem Paar, Regel 1
Regel 2: Wenn es mindestens ein Paar im Zustand Erfolgreich für diese Foundation gibt, setzen Sie den Zustand auf Wartend (Waiting). Diese Regel ist konsistent mit Abschnitt 7.2.5.3.3 von [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Tabelle 5: Checklistenzustand mit neu gebildetem Paar, Regel 2
Regel 3: In allen anderen Fällen setzen Sie den Zustand auf Eingefroren (Frozen).
+=================+====+====+=====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+=====+====+====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+-----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+----+----+-----+----+----+
| s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+----+----+-----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+-----+----+----+
Tabelle 6: Checklistenzustand mit neu gebildetem Paar, Regel 3
🇮🇹 Italiano
Dopo che un agente locale ha trickle un candidato e formato una coppia di candidati da quel candidato locale (Sezione 9), o dopo che un agente remoto ha ricevuto un candidato trickle e formato una coppia di candidati da quel candidato remoto (Sezione 11), un agente Trickle ICE aggiunge la nuova coppia di candidati a una checklist come definito in questa sezione.
Per aiutare a comprendere le procedure definite in questa sezione, considerare la seguente rappresentazione tabulare di tutte le checklist in un agente (notare che inizialmente per una delle fondazioni, cioè f5, non ci sono coppie di candidati):
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | F | F | F | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | F | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Tabella 1: Esempio di stato checklist
Ogni riga nella tabella rappresenta un componente per un dato flusso di dati e quindi una singola checklist nell'insieme di checklist. Ogni colonna rappresenta una fondazione. Ogni cella rappresenta una coppia di candidati. Nelle tabelle mostrate in questa sezione, "F" sta per "congelato (frozen)", "W" sta per "in attesa (waiting)" e "S" sta per "riuscito (succeeded)"; inoltre, "^^" è usato per annotare le coppie di candidati appena aggiunte.
Quando un agente inizia l'elaborazione ICE, in conformità con la Sezione 6.1.2.6 di [RFC8445], per ogni fondazione scongelerà la coppia con l'ID componente più basso e, se gli ID componente sono uguali, con la priorità più alta. Questo stato iniziale è mostrato nella tabella seguente.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | W | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | F | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | F | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | F | | | | |
+-----------------+----+----+----+----+----+
Tabella 2: Stato checklist iniziale
Quindi, man mano che i controlli procedono (vedere Sezione 7.2.5.4 di [RFC8445]), per ogni coppia che entra nello stato Riuscito (indicato qui da "S"), l'agente scongelerà tutte le coppie per tutti i flussi di dati con la stessa fondazione.
+=================+====+====+====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
| s1 (Audio.RTP) | S | W | W | | |
+-----------------+----+----+----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+----+
Tabella 3: Stato checklist con coppia di candidati riuscita
Trickle ICE preserva tutte queste regole poiché si applicano agli insiemi di checklist "statiche". Questo implica che se un agente Trickle ICE dovesse iniziare i controlli di connettività con tutte le sue coppie già presenti, il modo in cui gli stati delle coppie cambiano è indistinguibile da quello di un agente ICE regolare.
Naturalmente, la differenza principale con Trickle ICE è che gli insiemi di checklist possono essere aggiornati dinamicamente perché i candidati possono arrivare dopo l'inizio dei controlli di connettività. Quando ciò accade, un agente imposta lo stato della coppia appena formata come descritto di seguito.
Regola 1: Se la coppia appena formata ha l'ID componente più basso e, se gli ID componente sono uguali, la priorità più alta di qualsiasi coppia di candidati per questa fondazione (cioè se è la coppia più alta nella colonna), impostare lo stato su In attesa (Waiting). Questa regola è coerente con la Sezione 6.1.2.6 di [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | ^W^ |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Tabella 4: Stato checklist con coppia appena formata, Regola 1
Regola 2: Se c'è almeno una coppia nello stato Riuscito per questa fondazione, impostare lo stato su In attesa (Waiting). Questa regola è coerente con la Sezione 7.2.5.3.3 di [RFC8445].
+=================+====+====+====+====+=====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+=====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+----+----+-----+
| s2 (Audio.RTCP) | W | F | F | W | ^W^ |
+-----------------+----+----+----+----+-----+
| s3 (Video.RTP) | W | | | | |
+-----------------+----+----+----+----+-----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+----+----+-----+
Tabella 5: Stato checklist con coppia appena formata, Regola 2
Regola 3: In tutti gli altri casi, impostare lo stato su Congelato (Frozen).
+=================+====+====+=====+====+====+
| | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+=====+====+====+
| s1 (Audio.RTP) | S | W | W | | S |
+-----------------+----+----+-----+----+----+
| s2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+----+----+-----+----+----+
| s3 (Video.RTP) | W | | ^F^ | | |
+-----------------+----+----+-----+----+----+
| s4 (Video.RTCP) | W | | | | |
+-----------------+----+----+-----+----+----+
Tabella 6: Stato checklist con coppia appena formata, Regola 3