2. Overview of ICE (Panoramica di ICE)

In una distribuzione ICE tipica, ci sono due endpoint (agenti ICE, ICE agents) che desiderano comunicare. Si noti che ICE non è destinato all'attraversamento NAT per il protocollo di segnalazione (signaling protocol), che si presume sia fornito tramite un altro meccanismo. ICE presume che gli agenti siano in grado di stabilire una connessione di segnalazione tra loro.

Inizialmente, gli agenti non conoscono le proprie topologie. In particolare, gli agenti possono o meno trovarsi dietro NAT (o più livelli di NAT). ICE consente agli agenti di scoprire informazioni sufficienti sulle loro topologie per trovare potenzialmente uno o più percorsi attraverso i quali possono stabilire una sessione dati.

La figura 1 mostra una distribuzione ICE tipica. Gli agenti sono etichettati L e R. Sia L che R sono dietro i rispettivi NAT, anche se potrebbero non esserne consapevoli. Anche il tipo di NAT e le sue proprietà sono sconosciuti. L e R sono capaci di impegnarsi in un processo di scambio di candidati (candidate exchange), il cui scopo è configurare una sessione dati tra L e R. Tipicamente, questo scambio avverrà tramite un server di segnalazione (ad esempio, un proxy SIP).

Oltre agli agenti, a un server di segnalazione e ai NAT, ICE viene tipicamente utilizzato in concerto con server STUN o TURN nella rete. Ogni agente può avere il proprio server STUN o TURN, oppure possono essere gli stessi.

                           +---------+
         +--------+        |Signaling|         +--------+
         | STUN   |        |Server   |         | STUN   |
         | Server |        +---------+         | Server |
         +--------+       /           \        +--------+
                         /             \
                        /               \
                       / <- Signaling -> \
                      /                   \
               +--------+               +--------+
               |  NAT   |               |  NAT   |
               +--------+               +--------+
                  /                             \
                 /                               \
             +-------+                       +-------+
             | Agent |                       | Agent |
             |   L   |                       |   R   |
             +-------+                       +-------+

                 Figura 1: Scenario di distribuzione ICE

L'idea di base dietro ICE è la seguente: ogni agente dispone di una varietà di indirizzi di trasporto candidati (candidate transport addresses) (combinazione di indirizzo IP e porta per un particolare protocollo di trasporto, che è sempre UDP in questa specifica) che potrebbe utilizzare per comunicare con l'altro agente. Questi potrebbero includere:

• Un indirizzo di trasporto su un'interfaccia di rete direttamente connessa
• Un indirizzo di trasporto tradotto sul lato pubblico di un NAT (un "indirizzo server-reflexive (server-reflexive address)")
• Un indirizzo di trasporto allocato da un server TURN (un "indirizzo relayed (relayed address)")

Potenzialmente, qualsiasi indirizzo di trasporto candidato di L può essere utilizzato per comunicare con qualsiasi indirizzo di trasporto candidato di R. In pratica, tuttavia, molte combinazioni non funzioneranno. Ad esempio, se sia L che R sono entrambi dietro NAT, è improbabile che i loro indirizzi di interfaccia direttamente connessi siano in grado di comunicare direttamente (questo è il motivo per cui ICE è necessario, dopotutto!). Lo scopo di ICE è scoprire quali coppie di indirizzi funzioneranno. Il modo in cui ICE lo fa è provare sistematicamente tutte le coppie possibili (in un ordine attentamente ordinato) fino a quando non ne trova una o più che funzionano.

2.1. Gathering Candidates (Raccolta di candidati)

Per eseguire ICE, un agente ICE identifica e raccoglie uno o più candidati di indirizzo. Un candidato ha un indirizzo di trasporto -- una combinazione di indirizzo IP e porta per un particolare protocollo di trasporto (con solo UDP specificato qui).

2.2. Connectivity Checks (Controlli di connettività)

Una volta che L ha raccolto tutti i suoi candidati, li ordina per priorità decrescente e li invia a R tramite il canale di segnalazione. I controlli di connettività vengono quindi eseguiti sistematicamente.

2.3. Nominating Candidate Pairs and Concluding ICE (Nomina di coppie di candidati e conclusione di ICE)

ICE assegna a uno degli agenti ICE il ruolo di agente controllante (controlling agent), e all'altro il ruolo di agente controllato (controlled agent). Per ogni componente di un flusso di dati, l'agente controllante nomina una coppia valida da utilizzare per i dati.

2.4. ICE Restart (Riavvio ICE)

Una volta concluso ICE, può essere riavviato in qualsiasi momento per uno o tutti i flussi di dati da uno dei due agenti ICE.

2.5. Lite Implementations (Implementazioni Lite)

Alcuni agenti ICE saranno sempre connessi all'Internet pubblico e avranno un indirizzo IP pubblico. ICE definisce un tipo speciale di implementazione chiamato "lite". Gli agenti Lite utilizzano solo candidati host e non generano controlli di connettività.

---