1. Introduction (Introduzione)
L'Interactive Connectivity Establishment (ICE) [RFC8445] definisce un meccanismo che consente ai protocolli multimediali come il Real-time Transport Protocol (RTP) [RFC3550] di stabilire e mantenere sessioni IP tra peer in presenza di Network Address Translators (NAT) e altri elementi di rete intermedi. In ICE, i candidati (indirizzi di trasporto potenzialmente utilizzabili per la comunicazione) sono raccolti dagli agenti ICE e poi scambiati in modo completo prima che qualsiasi tentativo di stabilire una sessione di comunicazione possa avvenire effettivamente.
Quando è richiesta una rete IPv6, la latenza complessiva di questa procedura può essere significativa. È anche comune che uno o entrambi gli agenti dispongano di diverse interfacce di rete (ad esempio, wireless e cablate), più di un indirizzo su una singola interfaccia (ad esempio, IPv4 e IPv6), e siano configurati per utilizzare l'attraversamento STUN (Session Traversal Utilities for NAT) [RFC5389] o TURN (Traversal Using Relays around NAT) [RFC5766]. In simili scenari, la raccolta può richiedere un tempo sostanziale, rendendo l'intera chiamata lunga da stabilire dal punto di vista dell'utente e dall'applicazione.
Il protocollo "Trickle ICE", definito in questo documento, riduce la latenza di stabilimento delle sessioni estendendo ICE. Consente agli agenti ICE di trasmettere informazioni sui candidati quando divengono disponibili (quindi il termine "trickle", che significa "gocciolare" o "fluire gradualmente"). In questo modo, un agente ICE può iniziare immediatamente i controlli di connettività con i candidati ricevuti da un peer senza dover attendere che il peer raccolga tutti i candidati.
Trickle ICE specifica anche alcune modalità e le regole che governano il loro utilizzo. "Full Trickle" (Trickle completo) è il modello di funzionamento più comune, in cui gli agenti ICE possono scegliere di scambiare candidati incrementalmente o tutto in una volta. "Half Trickle" (Mezzo trickle) è una modalità in cui uno degli agenti scambia candidati in modo completo, mentre l'altro agente si impegna nello scambio incrementale dei candidati; questo modo è particolarmente utile in scenari dove non è chiaro se entrambe le parti supportano questo protocollo.
Questa specifica definisce solo il comportamento degli agenti ICE e lascia intatti i meccanismi di raccolta dei candidati, nonché i dettagli di come i candidati vengono trasmessi tra gli agenti ICE. Come per ICE in generale, questa specifica si concentra sul formato e la sémantique, non sui metodi di trasporto; tale uso specifico è definito separatamente (ad esempio, [RFC8840] definisce l'uso con SIP [RFC3261] e [XEP-0176] definisce l'uso con XMPP [RFC6120]).