17. Preserving Candidate Order While Trickling (Bewahrung der Kandidatenreihenfolge beim Trickling)

Ein wichtiger Aspekt von regulärem ICE ist, dass Konnektivitätsprüfungen für eine bestimmte Foundation und Komponente von beiden Agents gleichzeitig versucht werden, sodass alle Firewalls oder NATs vor den Agents beide Endpunkte auf die Whitelist setzen und alle außer dem ersten („Suizid"-)Paket durchlassen würden. Dies ist auch wichtig, um Kandidaten zur richtigen Zeit aufzutauen. Obwohl es nicht entscheidend ist, wird die Beibehaltung dieses Verhaltens in Trickle ICE wahrscheinlich die ICE-Leistung verbessern.

Um dies zu erreichen, sollten (SHOULD) Agents beim Trickeln von Kandidaten die Reihenfolge der Komponenten respektieren, wie sie durch ihre Komponenten-IDs widergespiegelt wird; das heißt, Kandidaten für eine bestimmte 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.

Zum Beispiel enthält die folgende SDP-Beschreibung zwei Komponenten (RTP und RTCP) und zwei Foundations (Host und serverreflexiv):

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-serverreflexive Kandidat zusammen mit oder vor dem RTCP-serverreflexiven Kandidaten übermittelt werden.