7. Performing Connectivity Checks (Esecuzione dei controlli di connettività)

Questa sezione descrive come vengono eseguiti i controlli di connettività. Tutte le implementazioni ICE devono essere conformi a [RFC5389], al contrario della vecchia [RFC3489]. Tuttavia, mentre un'implementazione completa genererà sia controlli (agendo come client STUN) che li riceverà (agendo come server STUN), un'implementazione Lite riceverà solo controlli, e quindi agirà solo come server STUN.

7.1. STUN Client Procedures (Procedure client STUN)

Queste procedure definiscono come un agente invia un controllo di connettività, sia che si tratti di un controllo ordinario o attivato. Queste procedure sono applicabili solo alle implementazioni complete.

7.1.1. Creating Permissions for Relayed Candidates (Creazione di permessi per candidati inoltrati)

Se il controllo di connettività viene inviato utilizzando un candidato locale inoltrato, il client MUST creare un permesso prima se non ne ha già creato uno in precedenza. Ne avrebbe creato uno in precedenza se avesse detto al server TURN di creare un permesso per il dato candidato inoltrato verso l'indirizzo IP del candidato remoto. Per creare il permesso, l'agente segue le procedure definite in [RFC5766]. Il permesso MUST essere creato verso l'indirizzo IP del candidato remoto. È RECOMMENDED che l'agente differisca la creazione di un canale TURN fino al completamento di ICE, nel qual caso i permessi per i controlli di connettività vengono normalmente creati utilizzando una richiesta CreatePermission. Una volta stabilito, l'agente MUST mantenere il permesso attivo fino alla conclusione di ICE.

7.1.2. Sending the Request (Invio della richiesta)

Il controllo viene generato inviando una richiesta Binding da un candidato locale a un candidato remoto. [RFC5389] descrive come vengono costruite e generate le richieste Binding. Un controllo di connettività MUST utilizzare il meccanismo delle credenziali a breve termine STUN. Il supporto per la retrocompatibilità con RFC 3489 MUST NOT essere utilizzato o assunto con i controlli di connettività. Il meccanismo FINGERPRINT MUST essere utilizzato per i controlli di connettività.

ICE estende STUN definendo diversi nuovi attributi, tra cui PRIORITY, USE-CANDIDATE, ICE-CONTROLLED e ICE-CONTROLLING. Questi nuovi attributi sono definiti formalmente nella Sezione 19.1 e il loro utilizzo è descritto nelle sottosezioni seguenti. Queste estensioni STUN sono applicabili solo ai controlli di connettività utilizzati per ICE.

7.1.2.1. PRIORITY and USE-CANDIDATE (PRIORITY e USE-CANDIDATE)

Un agente MUST includere l'attributo PRIORITY nella sua richiesta Binding. L'attributo MUST essere impostato uguale alla priorità che verrebbe assegnata, in base all'algoritmo nella Sezione 4.1.2, a un candidato peer reflexive, se ne venisse appreso uno come conseguenza di questo controllo (vedere la Sezione 7.1.3.2.1 per come vengono appresi i candidati peer reflexive). Questo valore di priorità sarà calcolato in modo identico a come è stata calcolata la priorità per il candidato locale della coppia, tranne che la preferenza di tipo è impostata sul valore per i tipi di candidati peer reflexive.

L'agente di controllo MAY includere l'attributo USE-CANDIDATE nella richiesta Binding. L'agente controllato MUST NOT includerlo nella sua richiesta Binding. Questo attributo segnala che l'agente di controllo desidera cessare i controlli per questo componente e utilizzare la coppia di candidati risultante dal controllo per questo componente. La Sezione 8.1.1 fornisce indicazioni su quando includerlo.

7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING (ICE-CONTROLLED e ICE-CONTROLLING)

L'agente MUST includere l'attributo ICE-CONTROLLED nella richiesta se è nel ruolo controllato, e MUST includere l'attributo ICE-CONTROLLING nella richiesta se è nel ruolo di controllo. Il contenuto di entrambi gli attributi MUST essere il tie-breaker che è stato determinato nella Sezione 5.2. Questi attributi sono definiti completamente nella Sezione 19.1.

7.1.2.3. Forming Credentials (Formazione delle credenziali)

Una richiesta Binding che funge da controllo di connettività MUST utilizzare il meccanismo delle credenziali a breve termine STUN. Il nome utente per le credenziali è formato concatenando il frammento di nome utente fornito dal peer con il frammento di nome utente dell'agente che invia la richiesta, separati da due punti (":"). La password è uguale alla password fornita dal peer. Ad esempio, si consideri il caso in cui l'agente L è l'offerente e l'agente R è il rispondente. L'agente L ha incluso un frammento di nome utente di LFRAG per i suoi candidati e una password di LPASS. L'agente R ha fornito un frammento di nome utente di RFRAG e una password di RPASS. Un controllo di connettività da L a R utilizza il nome utente RFRAG:LFRAG e una password di RPASS. Un controllo di connettività da R a L utilizza il nome utente LFRAG:RFRAG e una password di LPASS. Le risposte utilizzano gli stessi nomi utente e password delle richieste (si noti che l'attributo USERNAME non è presente nella risposta).

7.1.2.4. DiffServ Treatment (Trattamento DiffServ)

Se l'agente utilizza i contrassegni Diffserv Codepoint [RFC2475] nei suoi pacchetti multimediali, SHOULD applicare gli stessi contrassegni ai suoi controlli di connettività.

7.1.3. Processing the Response (Elaborazione della risposta)

Quando viene ricevuta una risposta Binding, essa viene correlata alla sua richiesta Binding utilizzando l'ID transazione, come definito in [RFC5389], che poi la lega alla coppia di candidati per la quale è stata inviata la richiesta Binding. Questa sezione definisce procedure aggiuntive per l'elaborazione delle risposte Binding specifiche per questo utilizzo di STUN.

7.1.3.1. Failure Cases (Casi di fallimento)

Se la transazione STUN genera una risposta di errore 487 (Role Conflict), l'agente controlla se ha incluso l'attributo ICE-CONTROLLED o ICE-CONTROLLING nella richiesta Binding. Se la richiesta conteneva l'attributo ICE-CONTROLLED, l'agente MUST passare al ruolo di controllo se non lo ha già fatto. Se la richiesta conteneva l'attributo ICE-CONTROLLING, l'agente MUST passare al ruolo controllato se non lo ha già fatto. Una volta cambiato, l'agente MUST accodare la coppia di candidati il cui controllo ha generato il 487 nella coda dei controlli attivati. Lo stato di quella coppia è impostato su Waiting. Quando viene inviato il controllo attivato, conterrà un attributo ICE-CONTROLLING o ICE-CONTROLLED che riflette il suo nuovo ruolo. Si noti, tuttavia, che il valore di tie-breaker MUST NOT essere riselezionato.

Un cambiamento di ruoli richiederà a un agente di ricalcolare le priorità delle coppie (Sezione 5.7.2), poiché tali priorità sono una funzione dei ruoli di controllo e controllato. Il cambiamento di ruolo influenzerà anche se l'agente è responsabile della selezione delle coppie nominate e della generazione di offerte aggiornate alla conclusione di ICE.

Gli agenti MAY supportare la ricezione di errori ICMP per i controlli di connettività. Se la transazione STUN genera un errore ICMP, l'agente imposta lo stato della coppia su Failed. Se la transazione STUN genera una risposta di errore STUN irrecuperabile (come definito in [RFC5389]) o scade, l'agente imposta lo stato della coppia su Failed.

L'agente MUST controllare che l'indirizzo IP e la porta di origine della risposta siano uguali all'indirizzo IP e alla porta di destinazione a cui è stata inviata la richiesta Binding, e che l'indirizzo IP e la porta di destinazione della risposta corrispondano all'indirizzo IP e alla porta di origine da cui è stata inviata la richiesta Binding. In altre parole, gli indirizzi di trasporto di origine e destinazione nella richiesta e nelle risposte sono simmetrici. Se non sono simmetrici, l'agente imposta lo stato della coppia su Failed.

7.1.3.2. Success Cases (Casi di successo)

Un controllo è considerato riuscito se tutte le seguenti condizioni sono vere:

• La transazione STUN ha generato una risposta di successo.
• L'indirizzo IP e la porta di origine della risposta sono uguali all'indirizzo IP e alla porta di destinazione a cui è stata inviata la richiesta Binding.
• L'indirizzo IP e la porta di destinazione della risposta corrispondono all'indirizzo IP e alla porta di origine da cui è stata inviata la richiesta Binding.

7.1.3.2.1. Discovering Peer Reflexive Candidates (Scoperta di candidati peer reflexive)

L'agente controlla l'indirizzo mappato dalla risposta STUN. Se l'indirizzo di trasporto non corrisponde a nessuno dei candidati locali che l'agente conosce, l'indirizzo mappato rappresenta un nuovo candidato -- un candidato peer reflexive. Come altri candidati, ha un tipo, una base, una priorità e una fondazione. Sono calcolati come segue:

• Il suo tipo è uguale a peer reflexive.
• La sua base è impostata uguale al candidato locale della coppia di candidati da cui è stato inviato il controllo STUN.
• La sua priorità è impostata uguale al valore dell'attributo PRIORITY nella richiesta Binding.
• La sua fondazione è selezionata come descritto nella Sezione 4.1.1.3.

Questo candidato peer reflexive viene quindi aggiunto all'elenco dei candidati locali per il flusso multimediale. Il suo frammento di nome utente e la password sono gli stessi di tutti gli altri candidati locali per quel flusso multimediale.

Tuttavia, il candidato peer reflexive non è accoppiato con altri candidati remoti. Questo non è necessario; una coppia valida verrà generata da esso momentaneamente in base alle procedure nella Sezione 7.1.3.2.2. Se un agente desidera accoppiare il candidato peer reflexive con altri candidati remoti oltre a quello nella coppia valida che verrà generata, l'agente MAY generare un'offerta aggiornata che include il candidato peer reflexive. Ciò farà sì che venga accoppiato con tutti gli altri candidati remoti.

7.1.3.2.2. Constructing a Valid Pair (Costruzione di una coppia valida)

L'agente costruisce una coppia di candidati il cui candidato locale è uguale all'indirizzo mappato della risposta, e il cui candidato remoto è uguale all'indirizzo di destinazione a cui è stata inviata la richiesta. Questa è chiamata coppia valida, poiché è stata convalidata da un controllo di connettività STUN. La coppia valida può essere uguale alla coppia che ha generato il controllo, può essere uguale a una coppia diversa nell'elenco di controllo, o può essere una coppia non attualmente in alcun elenco di controllo. Se la coppia è uguale alla coppia che ha generato il controllo o è in un elenco di controllo attualmente, viene anche aggiunta alla VALID LIST, che è mantenuta dall'agente per ciascun flusso multimediale. Questo elenco è vuoto all'inizio dell'elaborazione ICE e si riempie man mano che vengono eseguiti i controlli, risultando in coppie di candidati valide.

Sarà molto comune che la coppia non sia in alcun elenco di controllo. Ricordiamo che l'elenco di controllo ha coppie i cui candidati locali non sono mai server reflexive; quelle coppie hanno avuto i loro candidati locali convertiti alla base dei candidati server reflexive, e poi potati se erano ridondanti. Quando arriva la risposta al controllo STUN, l'indirizzo mappato sarà riflessivo se c'è un NAT tra i due. In tal caso, la coppia valida avrà un candidato locale che non corrisponde a nessuna delle coppie nell'elenco di controllo.

Se la coppia non è in alcun elenco di controllo, l'agente calcola la priorità per la coppia in base alla priorità di ciascun candidato, utilizzando l'algoritmo nella Sezione 5.7. La priorità del candidato locale dipende dal suo tipo. Se non è peer reflexive, è uguale alla priorità segnalata per quel candidato nell'SDP. Se è peer reflexive, è uguale all'attributo PRIORITY che l'agente ha inserito nella richiesta Binding appena completata. La priorità del candidato remoto è presa dall'SDP del peer. Se il candidato non appare lì, allora il controllo deve essere stato un controllo attivato verso un nuovo candidato remoto. In tal caso, la priorità è presa come il valore dell'attributo PRIORITY nella richiesta Binding che ha attivato il controllo appena completato. La coppia viene quindi aggiunta alla VALID LIST.

7.1.3.2.3. Updating Pair States (Aggiornamento degli stati delle coppie)

L'agente imposta lo stato della coppia che ha generato il controllo su Succeeded. Si noti che la coppia che ha generato il controllo può essere diversa dalla coppia valida costruita nella Sezione 7.1.3.2.2 come conseguenza della risposta. Il successo di questo controllo potrebbe anche causare il cambiamento dello stato di altri controlli. L'agente MUST eseguire i seguenti due passaggi:

1. L'agente cambia gli stati per tutte le altre coppie Frozen per lo stesso flusso multimediale e la stessa fondazione su Waiting. Tipicamente, ma non sempre, queste altre coppie avranno ID di componente diversi.

2. Se c'è una coppia nell'elenco valido per ogni componente di questo flusso multimediale (dove questo è il numero effettivo di componenti utilizzati, nei casi in cui il numero di componenti segnalati nell'SDP differisce da offerente a rispondente), il successo di questo controllo può sbloccare i controlli per altri flussi multimediali. Si noti che questo passaggio viene seguito non solo la prima volta che l'elenco valido in considerazione ha una coppia per ogni componente, ma ogni volta successiva che un controllo ha successo e aggiunge ancora un'altra coppia a quell'elenco valido. L'agente esamina l'elenco di controllo per ogni altro flusso multimediale a turno:

   • Se l'elenco di controllo è attivo, l'agente cambia lo stato di tutte le coppie Frozen in quell'elenco di controllo la cui fondazione corrisponde a una coppia nell'elenco valido in considerazione su Waiting.

   • Se l'elenco di controllo è congelato, e c'è almeno una coppia nell'elenco di controllo la cui fondazione corrisponde a una coppia nell'elenco valido in considerazione, lo stato di tutte le coppie nell'elenco di controllo la cui fondazione corrisponde a una coppia nell'elenco valido in considerazione è impostato su Waiting. Ciò farà sì che l'elenco di controllo diventi attivo e inizieranno i controlli ordinari per esso, come descritto nella Sezione 5.8.

   • Se l'elenco di controllo è congelato, e non ci sono coppie nell'elenco di controllo la cui fondazione corrisponde a una coppia nell'elenco valido in considerazione, l'agente

     • raggruppa tutte le coppie con la stessa fondazione, e

     • per ogni gruppo, imposta lo stato della coppia con l'ID componente più basso su Waiting. Se c'è più di una tale coppia, viene utilizzata quella con la priorità più alta.

7.1.3.2.4. Updating the Nominated Flag (Aggiornamento del flag nominato)

Se l'agente era un agente di controllo e aveva incluso un attributo USE-CANDIDATE nella richiesta Binding, la coppia valida generata da quel controllo ha il suo flag nominato impostato su true. Questo flag indica che questa coppia valida dovrebbe essere utilizzata per i media se è quella con la priorità più alta tra quelle il cui flag nominato è impostato. Ciò può concludere l'elaborazione ICE per questo flusso multimediale o per tutti i flussi multimediali; vedere la Sezione 8.

Se l'agente è l'agente controllato, la risposta può essere il risultato di un controllo attivato che è stato inviato in risposta a una richiesta che aveva essa stessa l'attributo USE-CANDIDATE. Questo caso è descritto nella Sezione 7.2.1.5 e può ora comportare l'impostazione del flag nominato per la coppia appresa dalla richiesta originale.

7.1.3.3. Check List and Timer State Updates (Aggiornamenti dell'elenco di controllo e dello stato del timer)

Indipendentemente dal fatto che il controllo sia riuscito o fallito, il completamento della transazione può richiedere l'aggiornamento degli stati dell'elenco di controllo e del timer.

Se tutte le coppie nell'elenco di controllo sono ora nello stato Failed o Succeeded:

• Se non c'è una coppia nell'elenco valido per ciascun componente del flusso multimediale, lo stato dell'elenco di controllo è impostato su Failed.

• Per ogni elenco di controllo congelato, l'agente

  • raggruppa tutte le coppie con la stessa fondazione, e

  • per ogni gruppo, imposta lo stato della coppia con l'ID componente più basso su Waiting. Se c'è più di una tale coppia, viene utilizzata quella con la priorità più alta.

Se nessuna delle coppie nell'elenco di controllo è nello stato Waiting o Frozen, l'elenco di controllo non è più considerato attivo e non conterà per il valore di N nel calcolo dei timer per i controlli ordinari come descritto nella Sezione 5.8.

7.2. STUN Server Procedures (Procedure server STUN)

Un agente MUST essere preparato a ricevere una richiesta Binding sulla base di ciascun candidato che ha incluso nella sua offerta o risposta più recente. Questo requisito vale anche se il peer è un'implementazione Lite.

L'agente MUST utilizzare una credenziale a breve termine per autenticare la richiesta ed eseguire un controllo di integrità del messaggio. L'agente MUST considerare valido il nome utente se è costituito da due valori separati da due punti, dove il primo valore è uguale al frammento di nome utente generato dall'agente in un'offerta o risposta per una sessione in corso. È possibile (e in effetti molto probabile) che un offerente riceva una richiesta Binding prima di ricevere la risposta dal suo peer. Se ciò accade, l'agente MUST generare immediatamente una risposta (incluso il calcolo dell'indirizzo mappato come descritto nella Sezione 7.2.1.2). L'agente dispone di informazioni sufficienti a questo punto per generare la risposta; la password dal peer non è richiesta. Una volta ricevuta la risposta, MUST procedere con i passaggi rimanenti richiesti, ovvero 7.2.1.3, 7.2.1.4 e 7.2.1.5 per le implementazioni complete. Nei casi in cui vengono ricevute più richieste STUN prima della risposta, ciò può causare l'accodamento di più coppie nella coda dei controlli attivati.

Un agente MUST NOT utilizzare il meccanismo ALTERNATE-SERVER e MUST NOT supportare i meccanismi di retrocompatibilità con RFC 3489. MUST utilizzare il meccanismo FINGERPRINT.

Se l'agente utilizza i contrassegni Diffserv Codepoint [RFC2475] nei suoi pacchetti multimediali, SHOULD applicare gli stessi contrassegni alle sue risposte alle richieste Binding. Lo stesso varrebbe per qualsiasi contrassegno di livello 2 che l'endpoint potrebbe applicare ai pacchetti multimediali.

7.2.1. Additional Procedures for Full Implementations (Procedure aggiuntive per implementazioni complete)

Questa sottosezione definisce le procedure server aggiuntive applicabili alle implementazioni complete.

7.2.1.1. Detecting and Repairing Role Conflicts (Rilevamento e riparazione dei conflitti di ruolo)

Normalmente, le regole per la selezione di un ruolo nella Sezione 5.2 comporteranno che ciascun agente selezioni un ruolo diverso -- uno di controllo e uno controllato. Tuttavia, in flussi di chiamata insoliti, che tipicamente utilizzano il controllo delle chiamate di terze parti, è possibile che entrambi gli agenti selezionino lo stesso ruolo. Questa sezione descrive le procedure per verificare questo caso e ripararlo.

Un agente MUST esaminare la richiesta Binding per l'attributo ICE-CONTROLLING o ICE-CONTROLLED. MUST seguire queste procedure:

• Se né ICE-CONTROLLING né ICE-CONTROLLED sono presenti nella richiesta, l'agente peer potrebbe aver implementato una versione precedente di questa specifica. Potrebbe esserci un conflitto, ma non può essere rilevato.

• Se l'agente è nel ruolo di controllo e l'attributo ICE-CONTROLLING è presente nella richiesta:

  • Se il tie-breaker dell'agente è maggiore o uguale al contenuto dell'attributo ICE-CONTROLLING, l'agente genera una risposta di errore Binding e include un attributo ERROR-CODE con un valore di 487 (Role Conflict) ma mantiene il suo ruolo.

  • Se il tie-breaker dell'agente è inferiore al contenuto dell'attributo ICE-CONTROLLING, l'agente passa al ruolo controllato.

• Se l'agente è nel ruolo controllato e l'attributo ICE-CONTROLLED è presente nella richiesta:

  • Se il tie-breaker dell'agente è maggiore o uguale al contenuto dell'attributo ICE-CONTROLLED, l'agente passa al ruolo di controllo.

  • Se il tie-breaker dell'agente è inferiore al contenuto dell'attributo ICE-CONTROLLED, l'agente genera una risposta di errore Binding e include un attributo ERROR-CODE con un valore di 487 (Role Conflict) ma mantiene il suo ruolo.

• Se l'agente è nel ruolo controllato e l'attributo ICE-CONTROLLING era presente nella richiesta, o l'agente era nel ruolo di controllo e l'attributo ICE-CONTROLLED era presente nella richiesta, non c'è conflitto.

Un cambiamento di ruoli richiederà a un agente di ricalcolare le priorità delle coppie (Sezione 5.7.2), poiché tali priorità sono una funzione dei ruoli di controllo e controllato. Il cambiamento di ruolo influenzerà anche se l'agente è responsabile della selezione delle coppie nominate e della generazione di offerte aggiornate alla conclusione di ICE.

Le sezioni rimanenti nella Sezione 7.2.1 vengono seguite se il server ha generato una risposta positiva alla richiesta Binding, anche se l'agente ha cambiato ruolo.

7.2.1.2. Computing Mapped Address (Calcolo dell'indirizzo mappato)

Per le richieste ricevute su un candidato inoltrato, l'indirizzo di trasporto di origine utilizzato per l'elaborazione STUN (ovvero, generazione dell'attributo XOR-MAPPED-ADDRESS) è l'indirizzo di trasporto visto dal server TURN. Quell'indirizzo di trasporto di origine sarà presente nell'attributo XOR-PEER-ADDRESS di un messaggio Data Indication, se la richiesta Binding è stata consegnata tramite un Data Indication. Se la richiesta Binding è stata consegnata tramite un messaggio ChannelData, l'indirizzo di trasporto di origine è quello che era legato al canale.

7.2.1.3. Learning Peer Reflexive Candidates (Apprendimento di candidati peer reflexive)

Se l'indirizzo di trasporto di origine della richiesta non corrisponde a nessun candidato remoto esistente, rappresenta un nuovo candidato remoto peer reflexive. Questo candidato è costruito come segue:

• La priorità del candidato è impostata sull'attributo PRIORITY dalla richiesta.
• Il tipo del candidato è impostato su peer reflexive.
• La fondazione del candidato è impostata su un valore arbitrario, diverso dalla fondazione per tutti gli altri candidati remoti. Se eventuali scambi successivi di offerta/risposta contengono questo candidato peer reflexive nell'SDP, segnalerà la fondazione effettiva per il candidato.
• L'ID componente di questo candidato è impostato sull'ID componente per il candidato locale a cui è stata inviata la richiesta.

Questo candidato viene aggiunto all'elenco dei candidati remoti. Tuttavia, l'agente non accoppia questo candidato con alcun candidato locale.

7.2.1.4. Triggered Checks (Controlli attivati)

Successivamente, l'agente costruisce una coppia il cui candidato locale è uguale all'indirizzo di trasporto su cui è stata ricevuta la richiesta STUN, e un candidato remoto uguale all'indirizzo di trasporto di origine da cui proveniva la richiesta (che potrebbe essere il candidato remoto peer reflexive appena appreso). Il candidato locale sarà un candidato host (per i casi in cui la richiesta non è stata ricevuta tramite un relay) o un candidato inoltrato (per i casi in cui viene ricevuta tramite un relay). Il candidato locale non può mai essere un candidato server reflexive. Poiché entrambi i candidati sono noti all'agente, esso può ottenere le loro priorità e calcolare la priorità della coppia di candidati. Questa coppia viene quindi cercata nell'elenco di controllo. Ci può essere uno dei diversi risultati:

• Se la coppia è già nell'elenco di controllo:

  • Se lo stato di quella coppia è Waiting o Frozen, un controllo per quella coppia viene accodato nella coda dei controlli attivati se non è già presente.

  • Se lo stato di quella coppia è In-Progress, l'agente annulla la transazione in corso. Annullamento significa che l'agente non ritrasmetterà la richiesta, non tratterà la mancanza di risposta come un fallimento, ma attenderà la durata del timeout della transazione per una risposta. Inoltre, l'agente MUST creare un nuovo controllo di connettività per quella coppia (che rappresenta una nuova transazione di richiesta Binding STUN) accodando la coppia nella coda dei controlli attivati. Lo stato della coppia viene quindi modificato in Waiting.

  • Se lo stato della coppia è Failed, viene modificato in Waiting e l'agente MUST creare un nuovo controllo di connettività per quella coppia (che rappresenta una nuova transazione di richiesta Binding STUN), accodando la coppia nella coda dei controlli attivati.

  • Se lo stato di quella coppia è Succeeded, non viene fatto nient'altro.

  Questi passaggi vengono eseguiti per facilitare il rapido completamento di ICE quando entrambi gli agenti sono dietro NAT.

• Se la coppia non è già nell'elenco di controllo:

  • La coppia viene inserita nell'elenco di controllo in base alla sua priorità.

  • Il suo stato è impostato su Waiting.

  • La coppia viene accodata nella coda dei controlli attivati.

Quando deve essere inviato un controllo attivato, viene costruito ed elaborato come descritto nella Sezione 7.1.2. Queste procedure richiedono che l'agente conosca l'indirizzo di trasporto, il frammento di nome utente e la password per il peer. Il frammento di nome utente per il candidato remoto è uguale alla parte dopo i due punti dello USERNAME nella richiesta Binding appena ricevuta. Utilizzando quel frammento di nome utente, l'agente può controllare i messaggi SDP ricevuti dal suo peer (potrebbe essercene più di uno in caso di forking) e trovare questo frammento di nome utente. Viene quindi selezionata la password corrispondente.

7.2.1.5. Updating the Nominated Flag (Aggiornamento del flag nominato)

Se la richiesta Binding ricevuta dall'agente aveva l'attributo USE-CANDIDATE impostato e l'agente è nel ruolo controllato, l'agente guarda lo stato della coppia calcolata nella Sezione 7.2.1.4:

• Se lo stato di questa coppia è Succeeded, significa che il controllo generato da questa coppia ha prodotto una risposta positiva. Ciò avrebbe causato all'agente di costruire una coppia valida quando è stata ricevuta quella risposta positiva (vedere la Sezione 7.1.3.2.2). L'agente ora imposta il flag nominato nella coppia valida su true. Ciò può terminare l'elaborazione ICE per questo flusso multimediale; vedere la Sezione 8.

• Se lo stato di questa coppia è In-Progress, se il suo controllo produce un risultato positivo, la coppia valida risultante ha il suo flag nominato impostato quando arriva la risposta. Ciò può terminare l'elaborazione ICE per questo flusso multimediale quando arriva; vedere la Sezione 8.

7.2.2. Additional Procedures for Lite Implementations (Procedure aggiuntive per implementazioni Lite)

Se il controllo appena ricevuto conteneva un attributo USE-CANDIDATE, l'agente costruisce una coppia di candidati il cui candidato locale è uguale all'indirizzo di trasporto su cui è stata ricevuta la richiesta, e il cui candidato remoto è uguale all'indirizzo di trasporto di origine della richiesta ricevuta. A questa coppia di candidati viene assegnata una priorità arbitraria e viene inserita in un elenco di candidati validi chiamato elenco valido. L'agente imposta il flag nominato per quella coppia su true. L'elaborazione ICE è considerata completa per un flusso multimediale se l'elenco valido contiene una coppia di candidati per ciascun componente.