9. Gathering and Conveying Newly Gathered Local Candidates (Collecte et transmission des candidats locaux nouvellement collectés)
Après que les agents Trickle ICE ont transmis les descriptions ICE initiales et les réponses ICE initiales, ils continueront très probablement à collecter de nouveaux candidats locaux à mesure que les mécanismes de collecte de candidats STUN, TURN et autres candidats non-hôtes commencent à produire des résultats. Chaque fois qu'un agent découvre un tel nouveau candidat, il calculera sa priorité, son type, sa fondation (Foundation) et son ID de composant selon les procédures ICE régulières.
Le nouveau candidat est ensuite vérifié pour la redondance par rapport à la liste existante de candidats locaux. Si son adresse de transport et sa base correspondent à celles d'un candidat existant, il sera considéré comme redondant et sera ignoré. Cela se produirait souvent pour les candidats réflexifs de serveur qui correspondent aux adresses d'hôte à partir desquelles ils ont été obtenus (par exemple, lorsque ces dernières sont des adresses IPv4 publiques). Contrairement à l'ICE régulier, les agents Trickle ICE considéreront le nouveau candidat comme redondant quelle que soit sa priorité.
Ensuite, l'agent « trickle » le(s) candidat(s) nouvellement découvert(s) vers l'agent distant. La livraison réelle des nouveaux candidats est gérée par un protocole d'utilisation tel que SIP ou XMPP. Trickle ICE n'impose aucune restriction sur la façon dont cela est fait (par exemple, certains protocoles d'utilisation peuvent choisir de ne pas trickle les mises à jour pour les candidats réflexifs de serveur et s'appuyer plutôt sur la découverte de candidats réflexifs de pair).
Lorsque les candidats sont trickle, le protocole d'utilisation doit (MUST) livrer chaque candidat (et toute indication de fin de candidats comme décrit dans la section 13) à l'implémentation Trickle ICE réceptrice exactement une fois et dans le même ordre qu'il a été transmis. Si le protocole d'utilisation fournit des retransmissions de candidats, elles doivent être cachées de l'implémentation ICE.
De plus, le trickling de candidats doit être corrélé à une session ICE spécifique, de sorte que s'il y a un redémarrage ICE, toutes les mises à jour retardées pour une session précédente peuvent être reconnues comme telles et ignorées par la partie réceptrice. Par exemple, les protocoles d'utilisation qui signalent les candidats via SDP peuvent inclure une valeur de fragment de nom d'utilisateur (Username Fragment) dans la ligne a=candidate correspondante, telle que :
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
Ou, comme autre exemple, les implémentations WebRTC peuvent inclure un fragment de nom d'utilisateur dans les objets JavaScript qui représentent les candidats.
Remarque : Le protocole d'utilisation doit fournir un mécanisme permettant aux deux parties d'indiquer et de s'accorder sur la session ICE en vigueur (identifiée par la combinaison fragment de nom d'utilisateur et mot de passe), afin qu'elles aient une vue cohérente des candidats à apparier. Ceci est particulièrement important dans le cas des redémarrages ICE (voir section 15).
Remarque : Un protocole d'utilisation pourrait préférer ne pas trickle les candidats réflexifs de serveur vers des entités dont on sait qu'elles sont publiquement accessibles et où l'envoi d'une demande de liaison STUN directe est susceptible d'atteindre la destination plus rapidement que la mise à jour trickle qui voyage par le chemin de signalisation.