17. Preserving Candidate Order While Trickling (渐进式交换时保持候选地址顺序)
🇨🇳 中文
常规ICE的一个重要方面是，两个代理同时尝试对特定基础和组件进行连接性检查，以便代理前面的任何防火墙或NAT将两个端点列入白名单，并允许除第一个（"自杀"）数据包之外的所有数据包通过。这对于在正确的时间解冻候选地址也很重要。虽然不是至关重要，但在Trickle ICE中保留此行为可能会提高ICE性能。
为了实现这一点，在渐进式交换候选地址时，代理应该 (SHOULD) 遵守由组件ID反映的组件顺序；也就是说，给定组件的候选地址不应 (SHOULD NOT) 在同一基础内具有较低ID编号的组件的候选地址之前传达。此外，候选地址应该 (SHOULD) 按照第12节中的程序，以它们被传达的相同顺序配对。
例如，以下SDP描述包含两个组件（RTP和RTCP）和两个基础（主机和服务器反射）：
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
raddr 10.0.1.1 rport 8998
对于此候选地址信息，RTCP主机候选地址不会在RTP主机候选地址之前传达。同样，RTP服务器反射候选地址将与RTCP服务器反射候选地址一起或在其之前传达。
🇬🇧 English
One important aspect of regular ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by both agents, so that any firewalls or NATs fronting the agents would whitelist both endpoints and allow all except for the first ("suicide") packets to go through. This is also important to unfreezing candidates at the right time. While not crucial, preserving this behavior in Trickle ICE is likely to improve ICE performance.
To achieve this, when trickling candidates, agents SHOULD respect the order of components as reflected by their component IDs; that is, candidates for a given component SHOULD NOT be conveyed prior to candidates for a component with a lower ID number within the same foundation. In addition, candidates SHOULD be paired, following the procedures in Section 12, in the same order they are conveyed.
For example, the following SDP description contains two components (RTP and RTCP) and two foundations (host and server-reflexive):
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
raddr 10.0.1.1 rport 8998
For this candidate information, the RTCP host candidate would not be conveyed prior to the RTP host candidate. Similarly, the RTP server-reflexive candidate would be conveyed together with or prior to the RTCP server-reflexive candidate.
🇯🇵 日本語
通常のICEの重要な側面の1つは、特定の基礎とコンポーネントの接続性チェックが両方のエージェントによって同時に試行されることです。これにより、エージェントの前にあるファイアウォールやNATが両方のエンドポイントをホワイトリストに登録し、最初の（「自殺」）パケットを除くすべてのパケットを通過させることができます。これは、適切なタイミングで候補を解凍するためにも重要です。重要ではありませんが、Trickle ICEでこの動作を保持すると、ICEのパフォーマンスが向上する可能性があります。
これを達成するために、候補をトリクルする際、エージェントはコンポーネントIDによって反映されるコンポーネントの順序を尊重すべきです (SHOULD)。つまり、特定のコンポーネントの候補は、同じ基礎内でより低いID番号を持つコンポーネントの候補よりも前に伝達すべきではありません (SHOULD NOT)。さらに、候補は第12節の手順に従って、伝達される順序と同じ順序でペアにすべきです (SHOULD)。
たとえば、次のSDP記述には2つのコンポーネント（RTPおよびRTCP）と2つの基礎（ホストおよびサーバー反射）が含まれています：
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
raddr 10.0.1.1 rport 8998
この候補情報の場合、RTCPホスト候補はRTPホスト候補の前に伝達されません。同様に、RTPサーバー反射候補は、RTCPサーバー反射候補と一緒に、またはその前に伝達されます。
🇫🇷 Français
Un aspect important de l'ICE régulier est que les vérifications de connectivité pour une fondation et un composant spécifiques sont tentées simultanément par les deux agents, de sorte que tous les pare-feu ou NAT devant les agents mettent en liste blanche les deux points de terminaison et permettent à tous les paquets, sauf le premier (paquet « suicide »), de passer. Ceci est également important pour dégeler les candidats au bon moment. Bien que non crucial, préserver ce comportement dans Trickle ICE est susceptible d'améliorer les performances ICE.
Pour y parvenir, lors du trickling de candidats, les agents DEVRAIENT (SHOULD) respecter l'ordre des composants tel que reflété par leurs ID de composant ; c'est-à-dire que les candidats pour un composant donné NE DEVRAIENT PAS (SHOULD NOT) être transmis avant les candidats pour un composant avec un numéro d'ID inférieur au sein de la même fondation. De plus, les candidats DEVRAIENT (SHOULD) être appariés, selon les procédures de la Section 12, dans le même ordre qu'ils sont transmis.
Par exemple, la description SDP suivante contient deux composants (RTP et RTCP) et deux fondations (hôte et réflexif au serveur) :
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
raddr 10.0.1.1 rport 8998
Pour ces informations de candidat, le candidat hôte RTCP ne serait pas transmis avant le candidat hôte RTP. De même, le candidat réflexif au serveur RTP serait transmis avec ou avant le candidat réflexif au serveur RTCP.
🇩🇪 Deutsch
Ein wichtiger Aspekt von regulärem ICE ist, dass Konnektivitätsprüfungen für eine bestimmte Foundation und Komponente gleichzeitig von beiden Agenten versucht werden, sodass alle Firewalls oder NATs vor den Agenten beide Endpunkte auf die Whitelist setzen und alle außer den ersten („Selbstmord"-)Paketen durchlassen würden. Dies ist auch wichtig, um Kandidaten zum richtigen Zeitpunkt aufzutauen. Obwohl nicht entscheidend, wird die Beibehaltung dieses Verhaltens in Trickle ICE wahrscheinlich die ICE-Leistung verbessern.
Um dies zu erreichen, SOLLTEN (SHOULD) Agenten beim Trickeln von Kandidaten die Reihenfolge der Komponenten respektieren, wie sie durch ihre Komponenten-IDs widergespiegelt wird; das heißt, Kandidaten für eine gegebene Komponente SOLLTEN NICHT (SHOULD NOT) vor Kandidaten für eine Komponente mit einer niedrigeren ID-Nummer innerhalb derselben Foundation übermittelt werden. Darüber hinaus SOLLTEN (SHOULD) Kandidaten gemäß den Verfahren in Abschnitt 12 in derselben Reihenfolge gepaart werden, in der sie übermittelt werden.
Die folgende SDP-Beschreibung enthält beispielsweise zwei Komponenten (RTP und RTCP) und zwei Foundations (Host und Server-reflexiv):
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
raddr 10.0.1.1 rport 8998
Für diese Kandidateninformationen würde der RTCP-Host-Kandidat nicht vor dem RTP-Host-Kandidaten übermittelt werden. Ebenso würde der RTP-Server-reflexive Kandidat zusammen mit oder vor dem RTCP-Server-reflexiven Kandidaten übermittelt werden.
🇮🇹 Italiano
Un aspetto importante dell'ICE regolare è che i controlli di connettività per una fondazione e un componente specifici vengono tentati simultaneamente da entrambi gli agenti, in modo che eventuali firewall o NAT davanti agli agenti inseriscano entrambi gli endpoint nella whitelist e consentano a tutti i pacchetti tranne il primo (pacchetto « suicida ») di passare. Questo è anche importante per scongelare i candidati al momento giusto. Sebbene non cruciale, preservare questo comportamento in Trickle ICE è probabile che migliori le prestazioni ICE.
Per raggiungere questo obiettivo, quando si effettua il trickle dei candidati, gli agenti DOVREBBERO (SHOULD) rispettare l'ordine dei componenti come riflesso dai loro ID componente; cioè, i candidati per un dato componente NON DOVREBBERO (SHOULD NOT) essere trasmessi prima dei candidati per un componente con un numero ID inferiore all'interno della stessa fondazione. Inoltre, i candidati DOVREBBERO (SHOULD) essere accoppiati, seguendo le procedure della Sezione 12, nello stesso ordine in cui vengono trasmessi.
Ad esempio, la seguente descrizione SDP contiene due componenti (RTP e RTCP) e due fondazioni (host e server-riflessivo):
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
raddr 10.0.1.1 rport 8998
Per queste informazioni sui candidati, il candidato host RTCP non verrebbe trasmesso prima del candidato host RTP. Allo stesso modo, il candidato server-riflessivo RTP verrebbe trasmesso insieme o prima del candidato server-riflessivo RTCP.