9. Gathering and Conveying Newly Gathered Local Candidates (Raccolta e trasmissione dei candidati locali appena raccolti)
Dopo che gli agenti Trickle ICE hanno trasmesso le descrizioni ICE iniziali e le risposte ICE iniziali, molto probabilmente continueranno a raccogliere nuovi candidati locali man mano che i meccanismi di raccolta dei candidati STUN, TURN e altri candidati non-host iniziano a produrre risultati. Ogni volta che un agente scopre un tale nuovo candidato, calcolerà la sua priorità, tipo, fondazione (Foundation) e ID di componente secondo le procedure ICE regolari.
Il nuovo candidato viene quindi verificato per la ridondanza rispetto all'elenco esistente di candidati locali. Se il suo indirizzo di trasporto e la sua base corrispondono a quelli di un candidato esistente, sarà considerato ridondante e sarà ignorato. Questo accadrebbe spesso per i candidati riflessivi del server che corrispondono agli indirizzi host da cui sono stati ottenuti (ad esempio, quando questi ultimi sono indirizzi IPv4 pubblici). A differenza di ICE regolare, gli agenti Trickle ICE considereranno il nuovo candidato come ridondante indipendentemente dalla sua priorità.
Successivamente, l'agente "trickle" il/i candidato/i appena scoperto/i verso l'agente remoto. La consegna effettiva dei nuovi candidati è gestita da un protocollo di utilizzo come SIP o XMPP. Trickle ICE non impone alcuna restrizione su come questo viene fatto (ad esempio, alcuni protocolli di utilizzo possono scegliere di non trickle gli aggiornamenti per i candidati riflessivi del server e affidarsi invece alla scoperta di candidati riflessivi del peer).
Quando i candidati vengono trickled, il protocollo di utilizzo deve (MUST) consegnare ogni candidato (e qualsiasi indicazione di fine dei candidati come descritto nella Sezione 13) all'implementazione Trickle ICE ricevente esattamente una volta e nello stesso ordine in cui è stato trasmesso. Se il protocollo di utilizzo fornisce ritrasmissioni di candidati, devono essere nascoste dall'implementazione ICE.
Inoltre, il trickling dei candidati deve essere correlato a una sessione ICE specifica, in modo che se c'è un riavvio ICE, tutti gli aggiornamenti ritardati per una sessione precedente possano essere riconosciuti come tali e ignorati dalla parte ricevente. Ad esempio, i protocolli di utilizzo che segnalano i candidati tramite SDP possono includere un valore di Username Fragment nella corrispondente riga a=candidate, come:
a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY
Oppure, come altro esempio, le implementazioni WebRTC possono includere un Username Fragment negli oggetti JavaScript che rappresentano i candidati.
Nota: Il protocollo di utilizzo deve fornire un meccanismo per entrambe le parti per indicare e concordare sulla sessione ICE in vigore (identificata dalla combinazione Username Fragment e Password), in modo che abbiano una vista coerente dei candidati da accoppiare. Questo è particolarmente importante nel caso di riavvii ICE (vedere Sezione 15).
Nota: Un protocollo di utilizzo potrebbe preferire di non trickle i candidati riflessivi del server verso entità che sono note per essere pubblicamente accessibili e dove l'invio di una richiesta di binding STUN diretto è probabile che raggiunga la destinazione più velocemente dell'aggiornamento trickle che viaggia attraverso il percorso di segnalazione.