1. Introduction (Introduzione)

La RFC 3264 [RFC3264] definisce uno scambio in due fasi di messaggi SDP (Session Description Protocol) [RFC4566] ai fini dell'istituzione di sessioni multimediali. Questo meccanismo di offerta/risposta è utilizzato da protocolli come il Session Initiation Protocol (SIP) [RFC3261].

I protocolli che utilizzano offerta/risposta sono difficili da far funzionare attraverso i Network Address Translator (NAT). Poiché il loro scopo è stabilire un flusso di pacchetti multimediali, tendono a trasportare gli indirizzi IP e le porte delle sorgenti e delle destinazioni multimediali all'interno dei loro messaggi, il che è noto per essere problematico attraverso NAT [RFC3235]. I protocolli cercano anche di creare un flusso multimediale direttamente tra i partecipanti, in modo che non vi sia alcun intermediario a livello di applicazione tra di loro. Questo viene fatto per ridurre la latenza dei media, diminuire la perdita di pacchetti e ridurre i costi operativi di distribuzione dell'applicazione. Tuttavia, questo è difficile da realizzare attraverso NAT. Una trattazione completa delle ragioni di ciò esula dallo scopo di questa specifica.

Sono state definite numerose soluzioni per consentire a questi protocolli di funzionare attraverso NAT. Queste includono Application Layer Gateways (ALG), il Middlebox Control Protocol [RFC3303], la specifica originale Simple Traversal of UDP Through NAT (STUN) [RFC3489] e Realm Specific IP [RFC3102] [RFC3103] insieme alle estensioni di descrizione della sessione necessarie per farle funzionare, come l'attributo SDP (Session Description Protocol) [RFC4566] per il Real Time Control Protocol (RTCP) [RFC3605]. Sfortunatamente, queste tecniche hanno tutte pro e contro che rendono ciascuna ottimale in alcune topologie di rete, ma una scelta scadente in altre. Il risultato è che gli amministratori e gli implementatori stanno facendo ipotesi sulle topologie delle reti in cui verranno distribuite le loro soluzioni. Ciò introduce complessità e fragilità nel sistema. Ciò che è necessario è un'unica soluzione sufficientemente flessibile per funzionare bene in tutte le situazioni.

Questa specifica definisce Interactive Connectivity Establishment (ICE) come una tecnica per l'attraversamento NAT per flussi multimediali basati su UDP (sebbene ICE possa essere esteso per gestire altri protocolli di trasporto, come TCP [ICE-TCP]) stabiliti dal modello offerta/risposta. ICE è un'estensione del modello offerta/risposta e funziona includendo una molteplicità di indirizzi IP e porte nelle offerte e risposte SDP, che vengono quindi testati per la connettività tramite controlli di connettività peer-to-peer. Gli indirizzi IP e le porte inclusi nell'SDP e i controlli di connettività vengono eseguiti utilizzando la specifica STUN rivista [RFC5389], ora rinominata Session Traversal Utilities for NAT. Il nuovo nome e la nuova specifica riflettono il suo nuovo ruolo di strumento utilizzato con altre tecniche di attraversamento NAT (vale a dire ICE) piuttosto che una soluzione di attraversamento NAT autonoma, come lo era la specifica STUN originale. ICE fa anche uso di Traversal Using Relays around NAT (TURN) [RFC5766], un'estensione di STUN. Poiché ICE scambia una molteplicità di indirizzi IP e porte per ogni flusso multimediale, consente anche la selezione dell'indirizzo per host multihomed e dual-stack, e per questo motivo depreca RFC 4091 [RFC4091] e [RFC4092].