9. Gathering and Conveying Newly Gathered Local Candidates (Sammeln und Übermitteln neu gesammelter lokaler Kandidaten)
Nachdem Trickle-ICE-Agents anfängliche ICE-Beschreibungen und anfängliche ICE-Antworten übermittelt haben, werden sie höchstwahrscheinlich weiterhin neue lokale Kandidaten sammeln, da STUN-, TURN- und andere Nicht-Host-Kandidatensammelmechanismen Ergebnisse zu liefern beginnen. Immer wenn ein Agent einen solchen neuen Kandidaten entdeckt, berechnet er seine Priorität, seinen Typ, seine Foundation und seine Komponenten-ID gemäß den regulären ICE-Verfahren.
Der neue Kandidat wird dann auf Redundanz gegenüber der vorhandenen Liste lokaler Kandidaten überprüft. Wenn seine Transportadresse und Basis mit denen eines vorhandenen Kandidaten übereinstimmen, wird er als redundant betrachtet und ignoriert. Dies würde häufig bei serverreflexiven Kandidaten vorkommen, die mit den Hostadressen übereinstimmen, von denen sie erhalten wurden (z. B. wenn letztere öffentliche IPv4-Adressen sind). Im Gegensatz zu regulärem ICE werden Trickle-ICE-Agents den neuen Kandidaten unabhängig von seiner Priorität als redundant betrachten.
Als Nächstes „tricklet" der Agent den/die neu entdeckten Kandidaten zum entfernten Agent. Die tatsächliche Zustellung der neuen Kandidaten wird von einem verwendenden Protokoll wie SIP oder XMPP gehandhabt. Trickle ICE legt keine Einschränkungen fest, wie dies geschieht (z. B. könnten sich einige verwendende Protokolle dafür entscheiden, keine Updates für serverreflexive Kandidaten zu tricklen, sondern sich stattdessen auf die Entdeckung von peer-reflexiven Kandidaten zu verlassen).
Wenn Kandidaten getricklet werden, muss (MUST) das verwendende Protokoll jeden Kandidaten (und jede End-of-Candidates-Anzeige, wie in Abschnitt 13 beschrieben) der empfangenden Trickle-ICE-Implementierung genau einmal und in derselben Reihenfolge zustellen, in der er übermittelt wurde. Wenn das verwendende Protokoll Kandidatenretransmissionen bereitstellt, müssen diese vor der ICE-Implementierung verborgen werden.
Außerdem muss das Kandidaten-Trickling mit einer bestimmten ICE-Sitzung korreliert werden, damit im Falle eines ICE-Neustarts verzögerte Updates für eine vorherige Sitzung als solche erkannt und von der empfangenden Partei ignoriert werden können. Zum Beispiel könnten verwendende Protokolle, die Kandidaten über SDP signalisieren, einen Username-Fragment-Wert in der entsprechenden a=candidate-Zeile enthalten, wie z. B.:
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
Oder, als ein weiteres Beispiel, könnten WebRTC-Implementierungen ein Username-Fragment in die JavaScript-Objekte aufnehmen, die Kandidaten darstellen.
Hinweis: Das verwendende Protokoll muss einen Mechanismus bereitstellen, mit dem beide Parteien die gültige ICE-Sitzung (identifiziert durch die Kombination aus Username-Fragment und Passwort) angeben und darüber einig werden können, damit sie eine konsistente Ansicht darüber haben, welche Kandidaten gepaart werden sollen. Dies ist besonders wichtig im Falle von ICE-Neustarts (siehe Abschnitt 15).
Hinweis: Ein verwendendes Protokoll könnte es vorziehen, serverreflexive Kandidaten nicht an Entitäten zu tricklen, von denen bekannt ist, dass sie öffentlich zugänglich sind und bei denen das Senden einer direkten STUN-Binding-Anfrage das Ziel wahrscheinlich schneller erreicht als das Trickle-Update, das über den Signalisierungspfad läuft.