4. Sending the Initial Offer (Invio dell'offerta iniziale)

Per inviare l'offerta iniziale in uno scambio offerta/risposta, un agente deve (1) raccogliere i candidati, (2) assegnare loro una priorità, (3) eliminare i candidati ridondanti, (4) scegliere i candidati predefiniti e quindi (5) formulare e inviare l'offerta SDP. Tutti questi cinque passaggi, tranne l'ultimo, differiscono per le implementazioni complete e Lite.

4.1. Full Implementation Requirements (Requisiti per l'implementazione completa)

4.1.1. Gathering Candidates (Raccolta dei candidati)

Un agente raccoglie i candidati quando ritiene che la comunicazione sia imminente. Un offerente può farlo in base a un segnale dell'interfaccia utente o in base a una richiesta esplicita di avviare una sessione. Ogni candidato è un indirizzo di trasporto. Ha anche un tipo e una base. Quattro tipi sono definiti e raccolti da questa specifica: candidati host, candidati riflessivi del server, candidati riflessivi del peer e candidati inoltrati. I candidati riflessivi del server vengono raccolti utilizzando STUN o TURN e i candidati inoltrati vengono ottenuti tramite TURN. I candidati riflessivi del peer vengono ottenuti nelle fasi successive di ICE, come conseguenza dei controlli di connettività. La base di un candidato è il candidato da cui un agente deve inviare quando utilizza quel candidato.

4.1.1.1. Host Candidates (Candidati host)

Il primo passo è raccogliere i candidati host. I candidati host si ottengono legandosi a porte (tipicamente effimere) su un indirizzo IP collegato a un'interfaccia (fisica o virtuale, comprese le interfacce VPN) sull'host.

Per ogni flusso multimediale UDP che l'agente desidera utilizzare, l'agente SHOULD (dovrebbe) ottenere un candidato per ogni componente del flusso multimediale su ogni indirizzo IP che l'host possiede. Ottiene ogni candidato legandosi a una porta UDP sullo specifico indirizzo IP. Un candidato host (e in effetti ogni candidato) è sempre associato a un componente specifico per il quale è un candidato. A ogni componente è assegnato un ID, chiamato ID componente. Per i flussi multimediali basati su RTP, l'RTP stesso ha un ID componente di 1 e l'RTCP un ID componente di 2. Se un agente utilizza RTCP, MUST (deve) ottenere un candidato per esso. Se un agente utilizza sia RTP che RTCP, finirebbe con 2*K candidati host se un agente ha K indirizzi IP.

La base per ogni candidato host è impostata sul candidato stesso.

4.1.1.2. Server Reflexive and Relayed Candidates (Candidati riflessivi del server e inoltrati)

Gli agenti SHOULD (dovrebbero) ottenere candidati inoltrati e SHOULD (dovrebbero) ottenere candidati riflessivi del server. Questi requisiti sono di forza SHOULD per consentire variazioni del provider. L'uso di server STUN e TURN potrebbe non essere necessario nelle reti chiuse in cui gli agenti non sono mai collegati alla rete Internet pubblica o a endpoint al di fuori della rete chiusa. In tali casi, verrebbe utilizzata un'implementazione completa per gli agenti che sono dual stack o multihomed, per selezionare un candidato host. L'uso dei server TURN è costoso e, quando viene utilizzato ICE, verranno utilizzati solo quando entrambi gli endpoint si trovano dietro NAT che eseguono la mappatura dipendente dall'indirizzo e dalla porta. Di conseguenza, alcune implementazioni potrebbero considerare questo caso d'uso marginale e scegliere di non utilizzare i server TURN. Se un agente non raccoglie candidati riflessivi del server o inoltrati, è RECOMMENDED (raccomandato) che la funzionalità sia implementata e semplicemente disabilitata tramite configurazione, in modo che possa essere riabilitata tramite configurazione se le condizioni cambiano in futuro.

Se un agente sta raccogliendo sia candidati inoltrati che riflessivi del server, utilizza un server TURN. Se sta raccogliendo solo candidati riflessivi del server, utilizza un server STUN.

L'agente accoppia quindi ogni candidato host con il server STUN o TURN con cui è configurato o che ha scoperto in qualche modo. Se è configurato un server STUN o TURN, è RECOMMENDED (raccomandato) configurare un nome di dominio e utilizzare le procedure DNS in [RFC5389] (utilizzando i record SRV con il servizio "stun") per scoprire il server STUN e le procedure DNS in [RFC5766] (utilizzando i record SRV con il servizio "turn") per scoprire il server TURN.

Questa specifica considera solo l'utilizzo di un singolo server STUN o TURN. Quando ci sono più scelte per quel singolo server STUN o TURN (quando, ad esempio, vengono apprese tramite record DNS e vengono restituiti più risultati), un agente SHOULD (dovrebbe) utilizzare un singolo server STUN o TURN (in base al suo indirizzo IP) per tutti i candidati per una particolare sessione. Ciò migliora le prestazioni di ICE. Il risultato è un insieme di coppie di candidati host con server STUN o TURN. L'agente sceglie quindi una coppia e invia una richiesta Binding o Allocate al server da quel candidato host. Le richieste Binding a un server STUN non sono autenticate e qualsiasi attributo ALTERNATE-SERVER in una risposta viene ignorato. Gli agenti MUST (devono) supportare la modalità di compatibilità con le versioni precedenti per la richiesta Binding definita in [RFC5389]. Le richieste Allocate SHOULD (dovrebbero) essere autenticate utilizzando una credenziale a lungo termine ottenuta dal client tramite altri mezzi.

Ogni Ta millisecondi successivi, l'agente può generare un'altra nuova transazione STUN o TURN. Questa transazione può essere un nuovo tentativo di una transazione precedente fallita con un errore recuperabile (come un errore di autenticazione) o una transazione per un nuovo candidato host e una coppia di server STUN o TURN. L'agente SHOULD NOT (non dovrebbe) generare transazioni più frequentemente di una ogni Ta millisecondi. Vedere la Sezione 16 per indicazioni su come impostare Ta e il timer di ritrasmissione STUN, RTO.

L'agente riceverà una risposta Binding o Allocate. Una risposta Allocate riuscita fornirà all'agente un candidato riflessivo del server (ottenuto dall'indirizzo mappato) e un candidato inoltrato nell'attributo XOR-RELAYED-ADDRESS. Se la richiesta Allocate viene rifiutata perché il server non dispone di risorse per soddisfarla, l'agente SHOULD (dovrebbe) inviare invece una richiesta Binding per ottenere un candidato riflessivo del server. Una risposta Binding fornirà all'agente solo un candidato riflessivo del server (ottenuto anche dall'indirizzo mappato). La base del candidato riflessivo del server è il candidato host da cui è stata inviata la richiesta Allocate o Binding. La base di un candidato inoltrato è quel candidato stesso. Se un candidato inoltrato è identico a un candidato host (cosa che può accadere in rari casi), il candidato inoltrato MUST (deve) essere scartato.

4.1.1.3. Computing Foundations (Calcolo delle fondazioni)

Infine, l'agente assegna a ciascun candidato una fondazione. La fondazione è un identificatore, con ambito all'interno di una sessione. Due candidati MUST (devono) avere lo stesso ID di fondazione quando sono vere tutte le seguenti condizioni:

• sono dello stesso tipo (host, inoltrato, riflessivo del server o riflessivo del peer).
• le loro basi hanno lo stesso indirizzo IP (le porte possono essere diverse).
• per i candidati riflessivi e inoltrati, i server STUN o TURN utilizzati per ottenerli hanno lo stesso indirizzo IP.
• sono stati ottenuti utilizzando lo stesso protocollo di trasporto (TCP, UDP, ecc.).

Allo stesso modo, due candidati MUST (devono) avere fondazioni diverse se i loro tipi sono diversi, le loro basi hanno indirizzi IP diversi, i server STUN o TURN utilizzati per ottenerli hanno indirizzi IP diversi o i loro protocolli di trasporto sono diversi.

4.1.1.4. Keeping Candidates Alive (Mantenere i candidati in vita)

Una volta allocati i candidati riflessivi del server e inoltrati, MUST (devono) essere mantenuti in vita fino al completamento dell'elaborazione ICE, come descritto nella Sezione 8.3. Per i candidati riflessivi del server appresi tramite una richiesta Binding, le associazioni MUST (devono) essere mantenute in vita da ulteriori richieste Binding al server. Gli aggiornamenti per le allocazioni vengono eseguiti utilizzando la transazione Refresh, come descritto in [RFC5766]. Le richieste Refresh aggiorneranno anche il candidato riflessivo del server.

4.1.2. Prioritizing Candidates (Assegnazione delle priorità ai candidati)

Il processo di assegnazione delle priorità comporta l'assegnazione di una priorità a ciascun candidato. Ogni candidato per un flusso multimediale MUST (deve) avere una priorità univoca che MUST (deve) essere un numero intero positivo compreso tra 1 e (2**31 - 1). Questa priorità verrà utilizzata da ICE per determinare l'ordine dei controlli di connettività e la preferenza relativa per i candidati.

Un agente SHOULD (dovrebbe) calcolare questa priorità utilizzando la formula nella Sezione 4.1.2.1 e scegliere i suoi parametri utilizzando le linee guida nella Sezione 4.1.2.2. Se un agente sceglie di utilizzare una formula diversa, ICE impiegherà più tempo per convergere poiché entrambi gli agenti non saranno coordinati nei loro controlli.

4.1.2.1. Recommended Formula (Formula consigliata)

Quando si utilizza la formula, un agente calcola la priorità determinando una preferenza per ogni tipo di candidato (riflessivo del server, riflessivo del peer, inoltrato e host) e, quando l'agente è multihomed, scegliendo una preferenza per i suoi indirizzi IP. Queste due preferenze vengono quindi combinate per calcolare la priorità per un candidato. Tale priorità viene calcolata utilizzando la seguente formula:

priority = (2^24)*(type preference) +
           (2^8)*(local preference) +
           (2^0)*(256 - component ID)

La preferenza del tipo (type preference) MUST (deve) essere un numero intero compreso tra 0 e 126 incluso e rappresenta la preferenza per il tipo del candidato (dove i tipi sono locale, riflessivo del server, riflessivo del peer e inoltrato). 126 è la preferenza più alta e 0 è la più bassa. Impostare il valore su 0 significa che i candidati di questo tipo verranno utilizzati solo come ultima risorsa. La preferenza del tipo MUST (deve) essere identica per tutti i candidati dello stesso tipo e MUST (deve) essere diversa per i candidati di tipi diversi. La preferenza del tipo per i candidati riflessivi del peer MUST (deve) essere superiore a quella dei candidati riflessivi del server. Si noti che i candidati raccolti in base alle procedure della Sezione 4.1.1 non saranno mai candidati riflessivi del peer; i candidati di questo tipo vengono appresi dai controlli di connettività eseguiti da ICE.

La preferenza locale (local preference) MUST (deve) essere un numero intero compreso tra 0 e 65535 incluso. Rappresenta una preferenza per il particolare indirizzo IP da cui è stato ottenuto il candidato, nei casi in cui un agente è multihomed. 65535 rappresenta la preferenza più alta e zero la più bassa. Quando c'è un solo indirizzo IP, questo valore SHOULD (dovrebbe) essere impostato su 65535. Più in generale, se ci sono più candidati per un particolare componente per un particolare flusso multimediale che hanno lo stesso tipo, la preferenza locale MUST (deve) essere univoca per ognuno. In questa specifica, ciò accade solo per gli host multihomed. Se un host è multihomed perché è dual stack, la preferenza locale SHOULD (dovrebbe) essere impostata uguale al valore di precedenza per gli indirizzi IP descritto in RFC 3484 [RFC3484].

L'ID componente è l'ID componente per il candidato e MUST (deve) essere compreso tra 1 e 256 inclusi.

4.1.2.2. Guidelines for Choosing Type and Local Preferences (Linee guida per la scelta del tipo e delle preferenze locali)

Un criterio per la selezione dei valori di tipo e preferenza locale è l'uso di un intermediario multimediale, come un server TURN, un server VPN o NAT. Con un intermediario multimediale, se i media vengono inviati a quel candidato, transiteranno prima attraverso l'intermediario multimediale prima di essere ricevuti. I candidati inoltrati sono un tipo di candidato che coinvolge un intermediario multimediale. Un altro sono i candidati host ottenuti da un'interfaccia VPN. Quando i media transitano attraverso un intermediario multimediale, ciò può aumentare la latenza tra trasmissione e ricezione. Può aumentare le perdite di pacchetti, a causa dei salti del router aggiuntivi che possono essere effettuati. Può aumentare il costo della fornitura del servizio, poiché i media verranno instradati dentro e fuori da un intermediario multimediale gestito da un provider. Se queste preoccupazioni sono importanti, la preferenza del tipo per i candidati inoltrati SHOULD (dovrebbe) essere inferiore ai candidati host. I valori RECOMMENDED (raccomandati) sono 126 per i candidati host, 100 per i candidati riflessivi del server, 110 per i candidati riflessivi del peer e 0 per i candidati inoltrati. Inoltre, se un agente è multihomed e ha più indirizzi IP, la preferenza locale per i candidati host da un'interfaccia VPN SHOULD (dovrebbe) avere una priorità pari a 0.

Un altro criterio per la selezione delle preferenze è la famiglia di indirizzi IP. ICE funziona sia con IPv4 che con IPv6. Fornisce quindi un meccanismo di transizione che consente agli host dual-stack di preferire la connettività su IPv6, ma di ripiegare su IPv4 nel caso in cui le reti v6 siano disconnesse (a causa, ad esempio, di un guasto in un relay 6to4) [RFC3056]. Può anche aiutare con gli host che hanno sia un indirizzo IPv6 nativo che un indirizzo 6to4. In tal caso, potrebbero essere assegnate preferenze locali più elevate agli indirizzi v6, seguiti dagli indirizzi 6to4, seguiti dagli indirizzi v4. Ciò consente a un sito di ottenere e iniziare a utilizzare immediatamente indirizzi v6 nativi, ma di ripiegare comunque sugli indirizzi 6to4 quando comunica con agenti in altri siti che non dispongono ancora di connettività v6 nativa.

Un altro criterio per la selezione delle preferenze è la sicurezza. Se un utente è un telelavoratore e quindi connesso a una rete aziendale e a una rete domestica locale, l'utente potrebbe preferire che il proprio traffico vocale venga instradato sulla VPN per mantenerlo sulla rete aziendale quando comunica all'interno dell'azienda, ma utilizzare la rete locale quando comunica con utenti esterni all'azienda. In tal caso, un indirizzo VPN avrebbe una preferenza locale maggiore rispetto a qualsiasi altro indirizzo.

Un altro criterio per la selezione delle preferenze è la consapevolezza topologica. Questo è più utile per i candidati che fanno uso di intermediari. In questi casi, se un agente ha una conoscenza preconfigurata o scoperta dinamicamente della vicinanza topologica degli intermediari a se stesso, può utilizzarla per assegnare preferenze locali più elevate ai candidati ottenuti da intermediari più vicini.

4.1.3. Eliminating Redundant Candidates (Eliminazione dei candidati ridondanti)

Successivamente, l'agente elimina i candidati ridondanti. Un candidato è ridondante se il suo indirizzo di trasporto è uguale a un altro candidato e la sua base è uguale alla base di quell'altro candidato. Si noti che due candidati possono avere lo stesso indirizzo di trasporto ma basi diverse e questi non sarebbero considerati ridondanti. Spesso, un candidato riflessivo del server e un candidato host saranno ridondanti quando l'agente non è dietro un NAT. L'agente SHOULD (dovrebbe) eliminare il candidato ridondante con la priorità più bassa.

4.1.4. Choosing Default Candidates (Scelta dei candidati predefiniti)

Si dice che un candidato è predefinito se sarebbe la destinazione dei media da un peer non ICE; tale destinazione è chiamata DESTINAZIONE PREDEFINITA (DEFAULT DESTINATION). Se i candidati predefiniti non vengono selezionati dall'algoritmo ICE durante la comunicazione con un peer compatibile con ICE, sarà necessaria un'offerta/risposta aggiornata dopo il completamento dell'elaborazione ICE per "correggere" l'SDP in modo che la destinazione predefinita per i media corrisponda ai candidati selezionati da ICE. Se ICE seleziona casualmente i candidati predefiniti, non è richiesta alcuna offerta/risposta aggiornata.

Un agente MUST (deve) scegliere un insieme di candidati, uno per ogni componente di ciascun flusso multimediale in uso, come predefinito. Un flusso multimediale è in uso se non ha una porta pari a zero (che viene utilizzata in RFC 3264 per rifiutare un flusso multimediale). Di conseguenza, un flusso multimediale è in uso anche se è contrassegnato come a=inactive [RFC4566] o ha un valore di larghezza di banda pari a zero.

È RECOMMENDED (raccomandato) che i candidati predefiniti vengano scelti in base alla probabilità che tali candidati funzionino con il peer contattato. È RECOMMENDED (raccomandato) che i candidati predefiniti siano i candidati inoltrati (se sono disponibili candidati inoltrati), i candidati riflessivi del server (se sono disponibili candidati riflessivi del server) e infine i candidati host.

4.2. Lite Implementation Requirements (Requisiti per l'implementazione Lite)

Le implementazioni Lite utilizzano solo candidati host. Un'implementazione Lite MUST (deve), per ogni componente di ogni flusso multimediale, allocare zero o un candidato IPv4. MAY (può) allocare zero o più candidati IPv6, ma non più di uno per ogni indirizzo IPv6 utilizzato dall'host. Poiché non può esserci più di un candidato IPv4 per componente di ogni flusso multimediale, se un agente ha più indirizzi IPv4, MUST (deve) sceglierne uno per l'allocazione del candidato. Se un host è dual stack, è RECOMMENDED (raccomandato) che allochi un candidato IPv4 e un indirizzo IPv6 globale. Con l'implementazione Lite, ICE non può essere utilizzato per scegliere dinamicamente tra i candidati. Pertanto, l'inclusione di più di un candidato da un particolare ambito è NOT RECOMMENDED (non raccomandata), poiché solo un controllo di connettività può determinare veramente se utilizzare un indirizzo o l'altro.

A ogni componente è assegnato un ID, chiamato ID componente. Per i flussi multimediali basati su RTP, l'RTP stesso ha un ID componente di 1 e l'RTCP un ID componente di 2. Se un agente utilizza RTCP, MUST (deve) ottenere candidati per esso.

A ogni candidato viene assegnata una fondazione. La fondazione MUST (deve) essere diversa per due candidati allocati da indirizzi IP diversi e MUST (deve) essere la stessa altrimenti. Sarà sufficiente un semplice numero intero che incrementa per ogni indirizzo IP. Inoltre, a ogni candidato MUST (deve) essere assegnata una priorità univoca tra tutti i candidati per lo stesso flusso multimediale. Questa priorità SHOULD (dovrebbe) essere uguale a:

priority = (2^24)*(126) +
           (2^8)*(IP precedence) +
           (2^0)*(256 - component ID)

Se un host è solo v4, SHOULD (dovrebbe) impostare la precedenza IP su 65535. Se un host è v6 o dual stack, la precedenza IP SHOULD (dovrebbe) essere il valore di precedenza per gli indirizzi IP descritto in RFC 3484 [RFC3484].

Successivamente, un agente sceglie un candidato predefinito per ogni componente di ogni flusso multimediale. Se un host è solo IPv4, ci sarebbe un solo candidato per ogni componente di ogni flusso multimediale e quindi quel candidato è il predefinito. Se un host è IPv6 o dual stack, la selezione del predefinito è una questione di politica locale. Questo predefinito SHOULD (dovrebbe) essere scelto in modo tale che sia il candidato con maggiori probabilità di essere utilizzato con un peer. Per gli host solo IPv6, questo sarebbe tipicamente un indirizzo IPv6 con ambito globale. Per gli host dual-stack, l'indirizzo IPv4 è RECOMMENDED (raccomandato).

4.3. Encoding the SDP (Codifica dell'SDP)

Il processo di codifica dell'SDP è identico tra le implementazioni complete e Lite.

L'agente includerà una riga m per ogni flusso multimediale che desidera utilizzare. L'ordinamento dei flussi multimediali nell'SDP è rilevante per ICE. ICE eseguirà prima i controlli di connettività per la prima riga m e di conseguenza i media potranno fluire prima per quel flusso. Gli agenti SHOULD (dovrebbero) posizionare il loro flusso multimediale più importante, se ce n'è uno, per primo nell'SDP.

Ci sarà un attributo candidato per ogni candidato per un particolare flusso multimediale. La Sezione 15 fornisce regole dettagliate per la costruzione di questo attributo. L'attributo trasporta l'indirizzo IP, la porta e il protocollo di trasporto per il candidato, oltre alle sue proprietà che devono essere segnalate al peer affinché ICE funzioni: priorità, fondazione e ID componente. L'attributo candidato trasporta anche informazioni sul candidato utili per la diagnostica e altre funzioni: il suo tipo e gli indirizzi di trasporto correlati.

I controlli di connettività STUN tra agenti sono autenticati utilizzando il meccanismo delle credenziali a breve termine definito per STUN [RFC5389]. Questo meccanismo si basa su un nome utente e una password che vengono scambiati tramite un meccanismo di protocollo tra client e server. Con ICE, lo scambio offerta/risposta viene utilizzato per scambiarli. La parte del nome utente di questa credenziale è formata concatenando un frammento di nome utente da ciascun agente, separato da due punti. Ogni agente fornisce anche una password, utilizzata per calcolare l'integrità del messaggio per le richieste che riceve. Il frammento di nome utente e la password vengono scambiati rispettivamente negli attributi ice-ufrag e ice-pwd. Oltre a fornire sicurezza, il nome utente fornisce la disambiguazione e la correlazione dei controlli ai flussi multimediali. Vedere l'Appendice B.4 per la motivazione.

Se un agente è un'implementazione Lite, MUST (deve) includere un attributo a livello di sessione "a=ice-lite" nel suo SDP. Se un agente è un'implementazione completa, MUST NOT (non deve) includere questo attributo.

I candidati predefiniti vengono aggiunti all'SDP come destinazione predefinita per i media. Per i flussi basati su RTP, ciò viene fatto posizionando l'indirizzo IP e la porta del candidato RTP rispettivamente nelle righe c e m. Se l'agente utilizza RTCP, MUST (deve) codificare il candidato RTCP utilizzando l'attributo a=rtcp come definito in RFC 3605 [RFC3605]. Se RTCP non è in uso, l'agente MUST (deve) segnalarlo utilizzando b=RS:0 e b=RR:0 come definito in RFC 3556 [RFC3556].

Gli indirizzi di trasporto che saranno la destinazione predefinita per i media quando si comunica con peer non ICE MUST (devono) essere presenti anche come candidati in una o più righe a=candidate.

ICE fornisce estensibilità consentendo a un'offerta o a una risposta di contenere una serie di token che identificano le estensioni ICE utilizzate da quell'agente. Se un agente supporta un'estensione ICE, MUST (deve) includere il token definito per tale estensione nell'attributo ice-options.

Di seguito è riportato un esempio di messaggio SDP che include attributi ICE (righe a capo per leggibilità):

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
    s=
    c=IN IP4 192.0.2.3
    t=0 0
    a=ice-pwd:asd88fgpdd777uzjYhagZg
    a=ice-ufrag:8hhY
    m=audio 45664 RTP/AVP 0
    b=RS:0
    b=RR:0
    a=rtpmap:0 PCMU/8000
    a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
    a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998

Una volta che un agente ha inviato la sua offerta o la sua risposta, quell'agente MUST (deve) essere preparato a ricevere sia pacchetti STUN che pacchetti multimediali su ciascun candidato. Come discusso nella Sezione 11.1, i pacchetti multimediali possono essere inviati a un candidato prima che appaia come destinazione predefinita per i media in un'offerta o una risposta.