17. Preserving Candidate Order While Trickling (Préservation de l'ordre des candidats pendant le trickling)

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 les pare-feu ou NAT devant les agents mettent sur liste blanche les deux points de terminaison et permettent à tous les paquets sauf le premier (« suicide ») de passer. Ceci est également important pour dégeler les candidats au bon moment. Bien que cela ne soit pas 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, en suivant 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 de 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 de serveur RTP serait transmis avec ou avant le candidat réflexif de serveur RTCP.

---