9. Subsequent Offer/Answer Exchanges (Scambi successivi di offerta/risposta)

Entrambi gli agenti MAY generare un'offerta successiva in qualsiasi momento consentito dalla RFC 3264 [RFC3264]. Le regole nella Sezione 8 faranno sì che l'agente di controllo invii un'offerta aggiornata alla conclusione dell'elaborazione ICE quando ICE ha selezionato coppie di candidati diverse dalle coppie predefinite. Questa sezione definisce le regole per la costruzione di offerte e risposte successive.

Se un'offerta successiva viene rifiutata, l'elaborazione ICE continua come se l'offerta successiva non fosse mai stata fatta.

9.1. Generating the Offer (Generazione dell'offerta)

9.1.1. Procedures for All Implementations (Procedure per tutte le implementazioni)

9.1.1.1. ICE Restarts (Riavvi ICE)

Un agente MAY riavviare l'elaborazione ICE per un flusso multimediale esistente. Un riavvio ICE, come suggerisce il nome, causerà lo svuotamento di tutti gli stati precedenti dell'elaborazione ICE e l'inizio di nuovi controlli. L'unica differenza tra un riavvio ICE e una sessione multimediale completamente nuova è che, durante il riavvio, i media possono continuare a essere inviati alla coppia precedentemente convalidata.

Un agente MUST riavviare ICE per un flusso multimediale se:

• L'offerta viene generata allo scopo di modificare la destinazione del flusso multimediale. In altre parole, se un agente desidera generare un'offerta aggiornata che, se ICE non fosse stato in uso, comporterebbe un nuovo valore per la destinazione di un componente multimediale.

• Un agente sta modificando il suo livello di implementazione. Questo in genere accade solo nei casi d'uso di controllo delle chiamate di terze parti, in cui l'entità che esegue la segnalazione non è l'entità che riceve i media e ha modificato la destinazione dei media a metà sessione verso un'altra entità che ha un'implementazione ICE diversa.

Queste regole implicano che l'impostazione dell'indirizzo IP nella riga c su 0.0.0.0 causerà un riavvio ICE. Di conseguenza, le implementazioni ICE MUST NOT utilizzare questo meccanismo per la sospensione della chiamata e MUST utilizzare invece a=inactive e a=sendonly come descritto in [RFC3264].

Per riavviare ICE, un agente MUST modificare sia ice-pwd che ice-ufrag per il flusso multimediale in un'offerta. Si noti che è consentito utilizzare un attributo a livello di sessione in un'offerta, ma fornire lo stesso ice-pwd o ice-ufrag come attributo a livello di media in un'offerta successiva. Questo non è un cambio di password, solo un cambiamento nella sua rappresentazione, e non causa un riavvio ICE.

Un agente imposta il resto dei campi nell'SDP per questo flusso multimediale come farebbe in un'offerta iniziale di questo flusso multimediale (vedere la Sezione 4.3). Di conseguenza, l'insieme di candidati MAY includere alcuni, nessuno o tutti i candidati precedenti per quel flusso e MAY includere un insieme completamente nuovo di candidati raccolti come descritto nella Sezione 4.1.1.

9.1.1.2. Removing a Media Stream (Rimozione di un flusso multimediale)

Se un agente rimuove un flusso multimediale impostando la sua porta su zero, MUST NOT includere alcun attributo candidato per quel flusso multimediale e SHOULD NOT includere altri attributi relativi a ICE definiti nella Sezione 15 per quel flusso multimediale.

9.1.1.3. Adding a Media Stream (Aggiunta di un flusso multimediale)

Se un agente desidera aggiungere un nuovo flusso multimediale, imposta i campi nell'SDP per questo flusso multimediale come se fosse un'offerta iniziale per quel flusso multimediale (vedere la Sezione 4.3). Ciò causerà l'inizio dell'elaborazione ICE per questo flusso multimediale.

9.1.2. Procedures for Full Implementations (Procedure per implementazioni complete)

Questa sezione descrive procedure aggiuntive per le implementazioni complete, che coprono i flussi multimediali esistenti.

I frammenti di nome utente, la password e il livello di implementazione MUST rimanere gli stessi utilizzati in precedenza. Se un agente deve modificare uno di questi, MUST riavviare ICE per quel flusso multimediale.

Il comportamento aggiuntivo dipende dallo stato dell'elaborazione ICE per quel flusso multimediale.

9.1.2.1. Existing Media Streams with ICE Running (Flussi multimediali esistenti con ICE in esecuzione)

Se un agente genera un'offerta aggiornata che include un flusso multimediale precedentemente stabilito e per il quale i controlli ICE sono nello stato Running, l'agente segue le procedure definite qui.

Un agente MUST includere gli attributi candidato per tutti i candidati locali che aveva segnalato in precedenza per quel flusso multimediale. Le proprietà di quel candidato come segnalate in SDP -- la priorità, la fondazione, il tipo e l'indirizzo di trasporto correlato -- SHOULD rimanere le stesse. L'indirizzo IP, la porta e il protocollo di trasporto, che identificano fondamentalmente quel candidato, MUST rimanere gli stessi (se cambiano, sarebbe un nuovo candidato). L'ID componente MUST rimanere lo stesso. L'agente MAY includere candidati aggiuntivi che non aveva offerto in precedenza, ma che ha raccolto dall'ultimo scambio di offerta/risposta, inclusi i candidati peer reflexive.

L'agente MAY modificare la destinazione predefinita per i media. Come per le offerte iniziali, MUST esserci un insieme di attributi candidato nell'offerta corrispondenti a questa destinazione predefinita.

9.1.2.2. Existing Media Streams with ICE Completed (Flussi multimediali esistenti con ICE completato)

Se un agente genera un'offerta aggiornata che include un flusso multimediale precedentemente stabilito e per il quale i controlli ICE sono nello stato Completed, l'agente segue le procedure definite qui.

La destinazione predefinita per i media (ovvero, i valori degli indirizzi IP e delle porte nelle righe m e c utilizzate per quel flusso multimediale) MUST essere il candidato locale dalla coppia nominata con la priorità più alta nell'elenco valido per ciascun componente. Questo "fissa" la destinazione predefinita per i media in modo che sia uguale alla destinazione che ICE ha selezionato per i media.

L'agente MUST includere attributi candidato per i candidati che corrispondono alla destinazione predefinita per ciascun componente del flusso multimediale e MUST NOT includere altri candidati.

Inoltre, se l'agente è di controllo, MUST includere l'attributo a=remote-candidates per ciascun flusso multimediale il cui elenco di controllo è nello stato Completed. L'attributo contiene i candidati remoti dalla coppia nominata con la priorità più alta nell'elenco valido per ciascun componente di quel flusso multimediale. È necessario per evitare una race condition in cui l'agente di controllo sceglie le sue coppie, ma l'offerta aggiornata batte i controlli di connettività verso l'agente controllato, che non sa nemmeno che queste coppie sono valide, tanto meno selezionate. Vedere l'Appendice B.6 per l'elaborazione su questa race condition.

9.1.3. Procedures for Lite Implementations (Procedure per implementazioni Lite)

9.1.3.1. Existing Media Streams with ICE Running (Flussi multimediali esistenti con ICE in esecuzione)

Questa sezione descrive le procedure per le implementazioni lite per i flussi esistenti per i quali ICE è in esecuzione.

Un'implementazione lite MUST includere tutti i suoi candidati per ciascun componente di ciascun flusso multimediale in un attributo a=candidate in qualsiasi offerta successiva. Questi candidati sono formati in modo identico alle procedure per le offerte iniziali, come descritto nella Sezione 4.2.

Un'implementazione lite MUST NOT aggiungere candidati host aggiuntivi in un'offerta successiva. Se un agente deve offrire candidati aggiuntivi, MUST riavviare ICE.

I frammenti di nome utente, la password e il livello di implementazione MUST rimanere gli stessi utilizzati in precedenza. Se un agente deve modificare uno di questi, MUST riavviare ICE per quel flusso multimediale.

9.1.3.2. Existing Media Streams with ICE Completed (Flussi multimediali esistenti con ICE completato)

Se ICE è stato completato per un flusso multimediale, la destinazione predefinita per quel flusso multimediale MUST essere impostata sul candidato remoto della coppia di candidati per quel componente nell'elenco valido. Per un'implementazione lite, c'è sempre solo una singola coppia di candidati nell'elenco valido per ciascun componente di un flusso multimediale. Inoltre, l'agente MUST includere un attributo candidato per ciascuna destinazione predefinita.

Inoltre, se l'agente è di controllo (cosa che accade solo quando entrambi gli agenti sono lite), l'agente MUST includere l'attributo a=remote-candidates per ciascun flusso multimediale. L'attributo contiene i candidati remoti dalle coppie di candidati nell'elenco valido (una coppia per ciascun componente di ciascun flusso multimediale).

9.2. Receiving the Offer and Generating an Answer (Ricezione dell'offerta e generazione di una risposta)

9.2.1. Procedures for All Implementations (Procedure per tutte le implementazioni)

Quando riceve un'offerta successiva all'interno di una sessione esistente, un agente MUST riapplicare le procedure di verifica nella Sezione 5.1 senza tener conto dei risultati della verifica da eventuali scambi di offerta/risposta precedenti. In effetti, è possibile che un precedente scambio di offerta/risposta abbia comportato il mancato utilizzo di ICE, ma che venga utilizzato come conseguenza di uno scambio successivo.

9.2.1.1. Detecting ICE Restart (Rilevamento del riavvio ICE)

Se l'offerta conteneva una modifica negli attributi a=ice-ufrag o a=ice-pwd rispetto al precedente SDP dal peer, indica che ICE si sta riavviando per questo flusso multimediale. Se tutti i flussi multimediali si stanno riavviando, allora ICE si sta riavviando complessivamente.

Se ICE si sta riavviando per un flusso multimediale:

• L'agente MUST modificare gli attributi a=ice-ufrag e a=ice-pwd nella risposta.

• L'agente MAY modificare il suo livello di implementazione nella risposta.

Un agente imposta il resto dei campi nell'SDP per questo flusso multimediale come farebbe in una risposta iniziale a questo flusso multimediale (vedere la Sezione 4.3). Di conseguenza, l'insieme di candidati MAY includere alcuni, nessuno o tutti i candidati precedenti per quel flusso e MAY includere un insieme completamente nuovo di candidati raccolti come descritto nella Sezione 4.1.1.

9.2.1.2. New Media Stream (Nuovo flusso multimediale)

Se l'offerta contiene un nuovo flusso multimediale, l'agente imposta i campi nella risposta come se avesse ricevuto un'offerta iniziale contenente quel flusso multimediale (vedere la Sezione 4.3). Ciò causerà l'inizio dell'elaborazione ICE per questo flusso multimediale.

9.2.1.3. Removed Media Stream (Flusso multimediale rimosso)

Se un'offerta contiene un flusso multimediale la cui porta è zero, l'agente MUST NOT includere alcun attributo candidato per quel flusso multimediale nella sua risposta e SHOULD NOT includere altri attributi relativi a ICE definiti nella Sezione 15 per quel flusso multimediale.

9.2.2. Procedures for Full Implementations (Procedure per implementazioni complete)

A meno che l'agente non abbia rilevato un riavvio ICE dall'offerta, i frammenti di nome utente, la password e il livello di implementazione MUST rimanere gli stessi utilizzati in precedenza. Se un agente deve modificare uno di questi, MUST riavviare ICE per quel flusso multimediale generando un'offerta; ICE non può essere riavviato in una risposta.

I comportamenti aggiuntivi dipendono dallo stato dell'elaborazione ICE per quel flusso multimediale.

9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates (Flussi multimediali esistenti con ICE in esecuzione e nessun remote-candidates)

Se ICE è in esecuzione per un flusso multimediale e l'offerta per quel flusso multimediale non aveva l'attributo remote-candidates, le regole per la costruzione della risposta sono identiche a quelle per l'offerente come descritto nella Sezione 9.1.2.1.

9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates (Flussi multimediali esistenti con ICE completato e nessun remote-candidates)

Se ICE è completato per un flusso multimediale e l'offerta per quel flusso multimediale non aveva l'attributo remote-candidates, le regole per la costruzione della risposta sono identiche a quelle per l'offerente come descritto nella Sezione 9.1.2.2, tranne che il rispondente MUST NOT includere l'attributo a=remote-candidates nella risposta.

9.2.2.3. Existing Media Streams and remote-candidates (Flussi multimediali esistenti e remote-candidates)

Un agente controllato riceverà un'offerta con l'attributo a=remote-candidates per un flusso multimediale quando il suo peer ha concluso l'elaborazione ICE per quel flusso multimediale. Questo attributo è presente nell'offerta per gestire una race condition tra la ricezione dell'offerta e la ricezione della risposta Binding che dice al rispondente il candidato che verrà selezionato da ICE. Vedere l'Appendice B.6 per una spiegazione di questa race condition. Di conseguenza, l'elaborazione di un'offerta con questo attributo dipende dal vincitore della gara.

L'agente forma una coppia di candidati per ciascun componente del flusso multimediale:

• Impostando il candidato remoto uguale alla destinazione predefinita dell'offerente per quel componente (ad esempio, il contenuto delle righe m e c per RTP e l'attributo a=rtcp per RTCP)

• Impostando il candidato locale uguale all'indirizzo di trasporto per quello stesso componente nell'attributo a=remote-candidates nell'offerta.

L'agente vede quindi se ciascuna di queste coppie di candidati è presente nell'elenco valido. Se una particolare coppia non è nell'elenco valido, il controllo ha "perso" la gara. Chiamiamo tale coppia una "coppia perdente".

L'agente trova tutte le coppie nell'elenco di controllo i cui candidati remoti sono uguali al candidato remoto nella coppia perdente:

• Se nessuna delle coppie è In-Progress e almeno una è Failed, è molto probabile che si sia verificato un guasto di rete, come una partizione di rete o una grave perdita di pacchetti. L'agente SHOULD generare una risposta per questo flusso multimediale come se l'attributo remote-candidates non fosse stato presente, e quindi riavviare ICE per questo flusso.

• Se almeno una delle coppie è In-Progress, l'agente SHOULD attendere il completamento di tali controlli e, man mano che ciascuno viene completato, rifare l'elaborazione in questa sezione fino a quando non ci sono coppie perdenti.

Una volta che non ci sono coppie perdenti, l'agente può generare la risposta. MUST impostare la destinazione predefinita per i media sui candidati nell'attributo remote-candidates dall'offerta (ognuno dei quali sarà ora il candidato locale di una coppia di candidati nell'elenco valido). MUST includere un attributo candidato nella risposta per ciascun candidato nell'attributo remote-candidates nell'offerta.

9.2.3. Procedures for Lite Implementations (Procedure per implementazioni Lite)

Se l'offerta ricevuta contiene l'attributo remote-candidates per un flusso multimediale, l'agente forma una coppia di candidati per ciascun componente del flusso multimediale:

• Impostando il candidato remoto uguale alla destinazione predefinita dell'offerente per quel componente (ad esempio, il contenuto delle righe m e c per RTP e l'attributo a=rtcp per RTCP).

• Impostando il candidato locale uguale all'indirizzo di trasporto per quello stesso componente nell'attributo a=remote-candidates nell'offerta.

Quindi inserisce quei candidati nell'elenco Valid per il flusso multimediale. Lo stato dell'elaborazione ICE per quel flusso multimediale è impostato su Completed.

Inoltre, se l'agente credeva di essere di controllo, ma l'offerta conteneva l'attributo remote-candidates, entrambi gli agenti credono di essere di controllo. In questo caso, entrambi avrebbero inviato offerte aggiornate all'incirca nello stesso momento. Tuttavia, il protocollo di segnalazione che trasporta gli scambi di offerta/risposta avrà risolto questa condizione di bagliore, in modo che un agente sia sempre il 'vincitore' ricevendo la sua offerta prima che il suo peer abbia inviato un'offerta. Il vincitore assume il ruolo di controllato, in modo che il perdente (il rispondente in considerazione in questa sezione) MUST cambiare il suo ruolo in controllato. Di conseguenza, se l'agente stava per inviare un'offerta aggiornata poiché, in base alle regole nella Sezione 8.2.2, era di controllo, non ha più bisogno di farlo.

Oltre al potenziale cambio di ruolo, al cambiamento nell'elenco Valid e ai cambiamenti di stato, la costruzione della risposta viene eseguita in modo identico alla costruzione di un'offerta come descritto nella Sezione 9.1.3.

9.3. Updating the Check and Valid Lists (Aggiornamento degli elenchi di controllo e validi)

9.3.1. Procedures for Full Implementations (Procedure per implementazioni complete)

9.3.1.1. ICE Restarts (Riavvi ICE)

L'agente MUST ricordare le coppie nominate con la priorità più alta nell'elenco Valid per ciascun componente del flusso multimediale, chiamate coppie selezionate precedenti, prima del riavvio. L'agente continuerà a inviare media utilizzando queste coppie, come descritto nella Sezione 11.1. Una volta annotate queste destinazioni, l'agente MUST svuotare gli elenchi validi e di controllo, e quindi ricalcolare l'elenco di controllo e i suoi stati come descritto nella Sezione 5.7.

9.3.1.2. New Media Stream (Nuovo flusso multimediale)

Se lo scambio di offerta/risposta ha aggiunto un nuovo flusso multimediale, l'agente MUST creare un nuovo elenco di controllo per esso (e ovviamente un elenco Valid vuoto per iniziare), come descritto nella Sezione 5.7.

9.3.1.3. Removed Media Stream (Flusso multimediale rimosso)

Se lo scambio di offerta/risposta ha rimosso un flusso multimediale o una risposta ha rifiutato un flusso multimediale offerto, un agente MUST svuotare l'elenco Valid per quel flusso multimediale. MUST terminare qualsiasi transazione STUN in corso per quel flusso multimediale. Un agente MUST rimuovere l'elenco di controllo per quel flusso multimediale e annullare qualsiasi controllo ordinario in sospeso per esso.

9.3.1.4. ICE Continuing for Existing Media Stream (ICE continua per il flusso multimediale esistente)

L'elenco valido non è influenzato da uno scambio di offerta/risposta aggiornato a meno che ICE non si stia riavviando.

Se un agente è nello stato Running per quel flusso multimediale, l'elenco di controllo viene aggiornato (l'elenco di controllo è irrilevante se lo stato è completato). Per fare ciò, l'agente ricalcola l'elenco di controllo utilizzando le procedure descritte nella Sezione 5.7. Se una coppia nel nuovo elenco di controllo era anche nel precedente elenco di controllo e il suo stato era Waiting, In-Progress, Succeeded o Failed, il suo stato viene copiato. Altrimenti, il suo stato è impostato su Frozen.

Se nessuno degli elenchi di controllo è attivo (il che significa che le coppie in ciascun elenco di controllo sono Frozen), l'agente in modalità completa imposta la prima coppia nell'elenco di controllo per il primo flusso multimediale su Waiting, e quindi imposta anche lo stato di tutte le altre coppie in quell'elenco di controllo per lo stesso ID componente e con la stessa fondazione su Waiting.

Successivamente, l'agente scorre ciascun elenco di controllo, iniziando con la coppia con la priorità più alta. Se una coppia ha uno stato di Succeeded e ha un ID componente di 1, allora tutte le coppie Frozen nello stesso elenco di controllo con la stessa fondazione i cui ID componente non sono 1 hanno il loro stato impostato su Waiting. Se, per un particolare elenco di controllo, ci sono coppie per ciascun componente di quel flusso multimediale nello stato Succeeded, l'agente sposta lo stato di tutte le coppie Frozen per il primo componente di tutti gli altri flussi multimediali (e quindi in diversi elenchi di controllo) con la stessa fondazione su Waiting.

9.3.2. Procedures for Lite Implementations (Procedure per implementazioni Lite)

Se ICE si sta riavviando per un flusso multimediale, l'agente MUST avviare un nuovo elenco Valid per quel flusso multimediale. MUST ricordare le coppie nel precedente elenco Valid per ciascun componente del flusso multimediale, chiamate coppie selezionate precedenti, e continuare a inviare media lì come descritto nella Sezione 11.1. Lo stato dell'elaborazione ICE per ciascun flusso multimediale MUST cambiare in Running e lo stato dell'elaborazione ICE MUST cambiare in Running.