2. Overview of ICE (Panoramica di ICE)
In una tipica distribuzione ICE, abbiamo due endpoint (noti come AGENTS (agenti) nella terminologia RFC 3264) che vogliono comunicare. Sono in grado di comunicare indirettamente tramite un protocollo di segnalazione (come SIP), attraverso il quale possono eseguire uno scambio di offerta/risposta di messaggi SDP [RFC3264]. Si noti che ICE non è destinato all'attraversamento NAT per SIP, che si presume sia fornito tramite un altro meccanismo [RFC5626]. All'inizio del processo ICE, gli agenti ignorano le proprie topologie. In particolare, potrebbero o non potrebbero trovarsi dietro un 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 comunicare.
La Figura 1 mostra un ambiente tipico per la distribuzione ICE. I due endpoint sono etichettati L e R (per sinistra e destra, il che aiuta a visualizzare i flussi di chiamata). 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. Gli agenti L e R sono in grado di impegnarsi in uno scambio di offerta/risposta attraverso il quale possono scambiare messaggi SDP, il cui scopo è impostare una sessione multimediale tra L e R. In genere, questo scambio avverrà tramite un server SIP.
Oltre agli agenti, a un server SIP e ai NAT, ICE viene generalmente utilizzato di concerto con server STUN o TURN nella rete. Ogni agente può avere il proprio server STUN o TURN, oppure possono essere gli stessi.
+-------+
| SIP |
+-------+ | Srvr | +-------+
| STUN | | | | STUN |
| Srvr | +-------+ | Srvr |
| | / \ | |
+-------+ / \ +-------+
/ \
/ \
/ \
/ \
/ <- Signaling -> \
/ \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
/ \
+-------+ +-------+
| Agent | | Agent |
| L | | R |
| | | |
+-------+ +-------+
Figure 1: ICE Deployment Scenario
L'idea di base alla base di ICE è la seguente: ogni agente ha una varietà di TRANSPORT ADDRESSES (indirizzi di trasporto) candidati (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 collegata direttamente
- Un indirizzo di trasporto tradotto sul lato pubblico di un NAT (un indirizzo "server reflexive" (riflessivo del server))
- Un indirizzo di trasporto allocato da un server TURN (un indirizzo "relayed" (inoltrato)).
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 L e R sono entrambi dietro NAT, è improbabile che i loro indirizzi di interfaccia collegati direttamente siano in grado di comunicare direttamente (questo è il motivo per cui è necessario ICE, dopo tutto!). Lo scopo di ICE è scoprire quali coppie di indirizzi funzioneranno. Il modo in cui ICE fa questo è provare sistematicamente tutte le coppie possibili (in un ordine accuratamente ordinato) finché non ne trova una o più che funzionano.
2.1. Gathering Candidate Addresses (Raccolta di indirizzi candidati)
Per eseguire ICE, un agente deve identificare tutti i suoi candidati indirizzo. Un CANDIDATE (candidato) è un indirizzo di trasporto -- una combinazione di indirizzo IP e porta per un particolare protocollo di trasporto (con solo UDP specificato qui). Questo documento definisce tre tipi di candidati, alcuni derivati da interfacce di rete fisiche o logiche, altri rilevabili tramite STUN e TURN. Naturalmente, un candidato praticabile è un indirizzo di trasporto ottenuto direttamente da un'interfaccia locale. Tale candidato è chiamato HOST CANDIDATE (candidato host). L'interfaccia locale potrebbe essere ethernet o WiFi, oppure potrebbe essere una ottenuta tramite un meccanismo tunnel, come una Virtual Private Network (VPN) o Mobile IP (MIP). In tutti i casi, tale interfaccia di rete appare all'agente come un'interfaccia locale da cui possono essere allocate porte (e quindi candidati).
Se un agente è multihomed, ottiene un candidato da ciascun indirizzo IP. A seconda della posizione del PEER (pari) (l'altro agente nella sessione) sulla rete IP rispetto all'agente, l'agente potrebbe essere raggiungibile dal pari attraverso uno o più di tali indirizzi IP. Consideriamo, ad esempio, un agente che ha un indirizzo IP locale su una rete privata net 10 (I1) e un secondo connesso a Internet pubblico (I2). Un candidato da I1 sarà direttamente raggiungibile quando si comunica con un pari sulla stessa rete privata net 10, mentre un candidato da I2 sarà direttamente raggiungibile quando si comunica con un pari su Internet pubblico. Invece di provare a indovinare quale indirizzo IP funzionerà prima di inviare un'offerta, l'agente offerente include entrambi i candidati nella sua offerta.
Successivamente, l'agente utilizza STUN o TURN per ottenere candidati aggiuntivi. Questi sono disponibili in due varianti: indirizzi tradotti sul lato pubblico di un NAT (SERVER REFLEXIVE CANDIDATES (candidati riflessivi del server)) e indirizzi su server TURN (RELAYED CANDIDATES (candidati inoltrati)). Quando vengono utilizzati i server TURN, entrambi i tipi di candidati vengono ottenuti dal server TURN. Se vengono utilizzati solo server STUN, da essi vengono ottenuti solo candidati riflessivi del server. La relazione di questi candidati con il candidato host è mostrata nella Figura 2. In questa figura, entrambi i tipi di candidati vengono scoperti utilizzando TURN. Nella figura, la notazione X:x indica l'indirizzo IP X e la porta UDP x.
To Internet
|
|
| /------------ Relayed
Y:y | / Address
+--------+
| |
| TURN |
| Server |
| |
+--------+
|
|
| /------------ Server
X1':x1'|/ Reflexive
+------------+ Address
| NAT |
+------------+
|
| /------------ Local
X:x |/ Address
+--------+
| |
| Agent |
| |
+--------+
Figure 2: Candidate Relationships
Quando l'agente invia la richiesta TURN Allocate dall'indirizzo IP e dalla porta X:x, il NAT (supponendo che ce ne sia uno) creerà un binding X1':x1', mappando questo candidato riflessivo del server al candidato host X:x. I pacchetti in uscita inviati dal candidato host verranno tradotti dal NAT nel candidato riflessivo del server. I pacchetti in arrivo inviati al candidato riflessivo del server verranno tradotti dal NAT nel candidato host e inoltrati all'agente. Chiamiamo il candidato host associato a un determinato candidato riflessivo del server la BASE (base).
Nota: "Base" si riferisce all'indirizzo da cui un agente invia per un particolare candidato. Pertanto, come caso degenere, anche i candidati host hanno una base, ma è la stessa del candidato host.
Quando ci sono più NAT tra l'agente e il server TURN, la richiesta TURN creerà un binding su ciascun NAT, ma solo il candidato riflessivo del server più esterno (quello più vicino al server TURN) verrà scoperto dall'agente. Se l'agente non è dietro un NAT, il candidato base sarà lo stesso del candidato riflessivo del server e il candidato riflessivo del server è ridondante e verrà eliminato.
La richiesta Allocate arriva quindi al server TURN. Il server TURN alloca una porta y dal suo indirizzo IP locale Y e genera una risposta Allocate, informando l'agente di questo candidato inoltrato. Il server TURN informa anche l'agente del candidato riflessivo del server, X1':x1' copiando l'indirizzo di trasporto sorgente della richiesta Allocate nella risposta Allocate. Il server TURN agisce come un relè di pacchetti, inoltrando il traffico tra L e R. Per inviare traffico a L, R invia traffico al server TURN a Y:y e il server TURN lo inoltra a X1':x1', che passa attraverso il NAT dove viene mappato a X:x e consegnato a L.
Quando vengono utilizzati solo server STUN, l'agente invia una richiesta STUN Binding [RFC5389] al proprio server STUN. Il server STUN informerà l'agente del candidato riflessivo del server X1':x1' copiando l'indirizzo di trasporto sorgente della richiesta Binding nella risposta Binding.
2.2. Connectivity Checks (Controlli di connettività)
Una volta che L ha raccolto tutti i suoi candidati, li ordina dalla priorità più alta a quella più bassa e li invia a R sul canale di segnalazione. I candidati sono trasportati in attributi nell'offerta SDP. Quando R riceve l'offerta, esegue lo stesso processo di raccolta e risponde con il proprio elenco di candidati. Alla fine di questo processo, ogni agente ha un elenco completo sia dei propri candidati che dei candidati del proprio pari. Li accoppia, ottenendo CANDIDATE PAIRS (coppie di candidati). Per vedere quali coppie funzionano, ogni agente pianifica una serie di CHECKS (controlli). Ogni controllo è una transazione richiesta/risposta STUN che il client eseguirà su una particolare coppia di candidati inviando una richiesta STUN dal candidato locale al candidato remoto.
Il principio di base dei controlli di connettività è semplice:
- Ordinare le coppie di candidati in ordine di priorità.
- Inviare controlli su ciascuna coppia di candidati in ordine di priorità.
- Riconoscere i controlli ricevuti dall'altro agente.
Con entrambi gli agenti che eseguono un controllo su una coppia di candidati, il risultato è una stretta di mano a 4 vie:
L R
- -
STUN request -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
Figure 3: Basic Connectivity Check
È importante notare che le richieste STUN vengono inviate e ricevute dagli stessi identici indirizzi IP e porte che verranno utilizzati per i media (ad esempio, RTP e RTCP). Di conseguenza, gli agenti demultiplexano STUN e RTP/RTCP utilizzando il contenuto dei pacchetti, anziché la porta su cui vengono ricevuti. Fortunatamente, questo demultiplexing è facile da eseguire, specialmente per RTP e RTCP.
Poiché una richiesta STUN Binding viene utilizzata per il controllo di connettività, la risposta STUN Binding conterrà l'indirizzo di trasporto tradotto dell'agente sul lato pubblico di qualsiasi NAT tra l'agente e il suo pari. Se questo indirizzo di trasporto è diverso dagli altri candidati che l'agente ha già appreso, rappresenta un nuovo candidato, chiamato PEER REFLEXIVE CANDIDATE (candidato riflessivo del pari), che viene quindi testato da ICE proprio come qualsiasi altro candidato.
Come ottimizzazione, non appena R riceve il messaggio di controllo di L, R pianifica l'invio di un messaggio di controllo di connettività a L sulla stessa coppia di candidati. Questo accelera il processo di ricerca di un candidato valido ed è chiamato TRIGGERED CHECK (controllo attivato).
Alla fine di questa stretta di mano, sia L che R sanno di poter inviare (e ricevere) messaggi end-to-end in entrambe le direzioni.
2.3. Sorting Candidates (Ordinamento dei candidati)
Poiché l'algoritmo sopra cerca tutte le coppie di candidati, se esiste una coppia funzionante alla fine la troverà indipendentemente dall'ordine in cui vengono provati i candidati. Per produrre risultati più rapidi (e migliori), i candidati vengono ordinati in un ordine specificato. L'elenco risultante di coppie di candidati ordinate è chiamato CHECK LIST (lista di controllo). L'algoritmo è descritto nella Sezione 4.1.2 ma segue due principi generali:
- Ogni agente assegna ai propri candidati una priorità numerica, che viene inviata insieme al candidato al pari.
- Le priorità locali e remote vengono combinate in modo che ogni agente abbia lo stesso ordinamento per le coppie di candidati.
La seconda proprietà è importante per far funzionare ICE quando ci sono NAT davanti a L e R. Spesso, i NAT non consentiranno pacchetti in ingresso da un host finché l'agente dietro il NAT non avrà inviato un pacchetto verso quell'host. Di conseguenza, i controlli ICE in ciascuna direzione non avranno successo finché entrambe le parti non avranno inviato un controllo attraverso i rispettivi NAT.
L'agente elabora questa lista di controllo inviando periodicamente una richiesta STUN per la coppia di candidati successiva nell'elenco. Questi sono chiamati ORDINARY CHECKS (controlli ordinari).
In generale, l'algoritmo di priorità è progettato in modo che i candidati di tipo simile ottengano priorità simili e che i percorsi più diretti (ovvero, attraverso meno relè multimediali e attraverso meno NAT) siano preferiti a quelli indiretti (quelli con più relè multimediali e più NAT). All'interno di tali linee guida, tuttavia, gli agenti hanno una discreta discrezione su come mettere a punto i propri algoritmi.
2.4. Frozen Candidates (Candidati congelati)
La descrizione precedente affronta solo il caso in cui gli agenti desiderano stabilire una sessione multimediale con un COMPONENT (componente) (un pezzo di un flusso multimediale che richiede un singolo indirizzo di trasporto; un flusso multimediale può richiedere più componenti, ognuno dei quali deve funzionare affinché il flusso multimediale nel suo insieme funzioni). Tipicamente (ad esempio, con RTP e RTCP), gli agenti devono effettivamente stabilire la connettività per più di un flusso.
È probabile che le proprietà di rete siano molto simili per ciascun componente (soprattutto perché RTP e RTCP vengono inviati e ricevuti dallo stesso indirizzo IP). Di solito è possibile sfruttare le informazioni di un componente multimediale per determinare i migliori candidati per un altro. ICE lo fa con un meccanismo chiamato "frozen candidates" (candidati congelati).
Ogni candidato è associato a una proprietà chiamata la sua FOUNDATION (fondazione). Due candidati hanno la stessa fondazione quando sono "simili" -- dello stesso tipo e ottenuti dallo stesso candidato host e server STUN utilizzando lo stesso protocollo. Altrimenti, la loro fondazione è diversa. Anche una coppia di candidati ha una fondazione, che è solo la concatenazione delle fondazioni dei suoi due candidati. Inizialmente, vengono testate solo le coppie di candidati con fondazioni uniche. Le altre coppie di candidati sono contrassegnate come "frozen" (congelate). Quando i controlli di connettività per una coppia di candidati hanno successo, le altre coppie di candidati con la stessa fondazione vengono scongelate. Ciò evita il controllo ripetuto di componenti che sono superficialmente più attraenti ma che di fatto è probabile che falliscano.
Sebbene abbiamo descritto "congelato" qui come un meccanismo separato per scopi espositivi, di fatto è parte integrante di ICE e l'algoritmo di prioritizzazione ICE garantisce automaticamente che i candidati giusti vengano scongelati e controllati nell'ordine giusto.
2.5. Security for Checks (Sicurezza per i controlli)
Poiché ICE viene utilizzato per scoprire quali indirizzi possono essere utilizzati per inviare media tra due agenti, è importante garantire che il processo non possa essere dirottato per inviare media alla posizione sbagliata. Ogni controllo di connettività STUN è coperto da un codice di autenticazione del messaggio (MAC) calcolato utilizzando una chiave scambiata nel canale di segnalazione. Questo MAC fornisce l'integrità del messaggio e l'autenticazione dell'origine dei dati, impedendo così a un utente malintenzionato di falsificare o modificare i messaggi di controllo di connettività. Inoltre, se il chiamante SIP [RFC3261] sta utilizzando ICE e la sua chiamata si biforca (forks), gli scambi ICE avvengono indipendentemente con ciascun destinatario biforcato. In tal caso, le chiavi scambiate nella segnalazione aiutano ad associare ogni scambio ICE a ciascun destinatario biforcato.
2.6. Concluding ICE (Conclusione di ICE)
I controlli ICE vengono eseguiti in una sequenza specifica, in modo che le coppie di candidati ad alta priorità vengano controllate per prime, seguite da quelle a priorità inferiore. Un modo per concludere ICE è dichiarare vittoria non appena un controllo per ciascun componente di ciascun flusso multimediale viene completato con successo. In effetti, questo è un algoritmo ragionevole e i dettagli per esso sono forniti di seguito. Tuttavia, è possibile che una perdita di pacchetti faccia sì che un controllo a priorità più alta richieda più tempo per essere completato. In tal caso, consentire a ICE di funzionare un po' più a lungo potrebbe produrre risultati migliori. Più fondamentalmente, tuttavia, la prioritizzazione definita da questa specifica potrebbe non produrre risultati "ottimali". Ad esempio, se l'obiettivo è selezionare percorsi multimediali a bassa latenza, l'utilizzo di un relè è un suggerimento che le latenze potrebbero essere più elevate, ma non è altro che un suggerimento. Potrebbe essere effettuata una misurazione effettiva del tempo di andata e ritorno (RTT) e potrebbe dimostrare che una coppia con priorità inferiore è in realtà migliore di una con priorità più alta.
Di conseguenza, ICE assegna uno degli agenti nel ruolo di CONTROLLING AGENT (agente di controllo) e l'altro di CONTROLLED AGENT (agente controllato). L'agente di controllo può nominare quali coppie di candidati verranno utilizzate per i media tra quelle valide. Può farlo in uno dei due modi -- utilizzando la REGULAR NOMINATION (nomina regolare) o la AGGRESSIVE NOMINATION (nomina aggressiva).
Con la nomina regolare, l'agente di controllo lascia che i controlli continuino finché non viene trovata almeno una coppia di candidati valida per ciascun flusso multimediale. Quindi, sceglie tra quelle valide e invia una seconda richiesta STUN sulla sua coppia di candidati NOMINATED (nominata), ma questa volta con un flag impostato per dire al pari che questa coppia è stata nominata per l'uso. Questo è mostrato nella Figura 4.
L R
- -
STUN request -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
STUN request + flag -> \ L's
<- STUN response / check
Figure 4: Regular Nomination
Una volta completata la transazione STUN con il flag, entrambe le parti annullano qualsiasi controllo futuro per quel flusso multimediale. ICE invierà ora media utilizzando questa coppia. La coppia che un agente ICE sta utilizzando per i media è chiamata SELECTED PAIR (coppia selezionata).
Nella nomina aggressiva, l'agente di controllo inserisce il flag in ogni richiesta STUN che invia. In questo modo, una volta che il primo controllo ha successo, l'elaborazione ICE è completa per quel flusso multimediale e l'agente di controllo non deve inviare una seconda richiesta STUN. La coppia selezionata sarà la coppia valida con la priorità più alta il cui controllo ha avuto successo. La nomina aggressiva è più veloce della nomina regolare, ma offre meno flessibilità. La nomina aggressiva è mostrata nella Figura 5.
L R
- -
STUN request + flag -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
Figure 5: Aggressive Nomination
Una volta completati tutti i flussi multimediali, l'endpoint di controllo invia un'offerta aggiornata se i candidati nelle righe m e c per il flusso multimediale (chiamati DEFAULT CANDIDATES (candidati predefiniti)) non corrispondono ai SELECTED CANDIDATES (candidati selezionati) di ICE.
Una volta concluso ICE, può essere riavviato in qualsiasi momento per uno o tutti i flussi multimediali da uno degli agenti. Questo viene fatto inviando un'offerta aggiornata che indica un riavvio.
2.7. Lite Implementations (Implementazioni Lite)
Affinché ICE possa essere utilizzato in una chiamata, entrambi gli agenti devono supportarlo. Tuttavia, alcuni agenti saranno sempre connessi a Internet pubblico e avranno un indirizzo IP pubblico al quale possono ricevere pacchetti da qualsiasi corrispondente. Per rendere più facile per questi dispositivi supportare ICE, ICE definisce un tipo speciale di implementazione chiamata LITE (in contrasto con la normale implementazione FULL (completa)). Un'implementazione lite non raccoglie candidati; include solo candidati host per qualsiasi flusso multimediale. Gli agenti lite non generano controlli di connettività né eseguono le macchine a stati, sebbene debbano essere in grado di rispondere ai controlli di connettività. Quando un'implementazione lite si connette con un'implementazione completa, l'agente completo assume il ruolo di agente di controllo e l'agente lite assume il ruolo controllato. Quando due implementazioni lite si connettono, non vengono inviati controlli.
Per indicazioni su quando un'implementazione lite è appropriata, vedere la discussione nell'Appendice A.
È importante notare che l'implementazione lite è stata aggiunta a questa specifica per fornire un trampolino di lancio verso l'implementazione completa. Anche per i dispositivi che sono sempre connessi a Internet pubblico, un'implementazione completa è preferibile se realizzabile.