5. Receiving the Initial Offer (Ricezione dell'offerta iniziale)
Quando un agente riceve un'offerta iniziale, verificherà se l'offerente supporta ICE, determinerà il proprio ruolo, raccoglierà i candidati, assegnerà loro una priorità, sceglierà i candidati predefiniti, codificherà e invierà una risposta e, per le implementazioni complete, formerà le liste di controllo e inizierà i controlli di connettività.
5.1. Verifying ICE Support (Verifica del supporto ICE)
L'agente procederà con le procedure ICE definite in questa specifica se, per ogni flusso multimediale nell'SDP ricevuto, la destinazione predefinita per ogni componente di quel flusso multimediale appare in un attributo candidate. Ad esempio, nel caso di RTP, l'indirizzo IP e la porta nelle righe c e m, rispettivamente, appaiono in un attributo candidate e il valore nell'attributo rtcp appare in un attributo candidate.
Se questa condizione non viene soddisfatta, l'agente MUST (deve) elaborare l'SDP in base alle normali procedure RFC 3264, senza utilizzare alcuno dei meccanismi ICE descritti nel resto di questa specifica con le seguenti eccezioni:
-
L'agente MUST (deve) seguire le regole della Sezione 10, che descrivono le procedure di keepalive per tutti gli agenti.
-
Se l'agente non procede con ICE perché c'erano attributi a=candidate, ma nessuno corrispondeva alla destinazione predefinita del flusso multimediale, l'agente MUST (deve) includere un attributo a=ice-mismatch nella sua risposta.
-
Se i candidati predefiniti erano candidati inoltrati appresi tramite un server TURN, l'agente MUST (deve) creare autorizzazioni nel server TURN per gli indirizzi IP appresi dal suo peer nell'SDP appena ricevuto. Se ciò non viene fatto, i pacchetti iniziali nel flusso multimediale dal peer potrebbero andare persi.
5.2. Determining Role (Determinazione del ruolo)
Per ogni sessione, ogni agente assume un ruolo. Ci sono due ruoli: di controllo (controlling) e controllato (controlled). L'agente di controllo è responsabile della scelta delle coppie di candidati finali utilizzate per le comunicazioni. Per un agente completo, ciò significa nominare le coppie di candidati che possono essere utilizzate da ICE per ogni flusso multimediale e generare l'offerta aggiornata in base alla selezione di ICE, quando necessario. Per un'implementazione Lite, essere l'agente di controllo significa selezionare una coppia di candidati in base a quelle nell'offerta e nella risposta (per IPv4, c'è sempre una sola coppia), e quindi generare un'offerta aggiornata che rifletta tale selezione, quando necessario (non è mai necessario per un host solo IPv4). All'agente controllato viene detto quali coppie di candidati utilizzare per ogni flusso multimediale e non genera un'offerta aggiornata per segnalare queste informazioni. Le sezioni seguenti descrivono in dettaglio le procedure effettive seguite dai nodi di controllo e controllati.
Le regole per determinare il ruolo e l'impatto sul comportamento sono le seguenti:
-
Entrambi gli agenti sono completi: L'agente che ha generato l'offerta che ha avviato l'elaborazione ICE MUST (deve) assumere il ruolo di controllo e l'altro MUST (deve) assumere il ruolo controllato. Entrambi gli agenti formeranno liste di controllo, eseguiranno le macchine a stati ICE e genereranno controlli di connettività. L'agente di controllo eseguirà la logica nella Sezione 8.1 per nominare le coppie che verranno selezionate da ICE, quindi entrambi gli agenti termineranno ICE come descritto nella Sezione 8.1.2. In casi insoliti, descritti nell'Appendice B.11, è possibile che entrambi gli agenti credano erroneamente di essere controllati o di controllo. Per risolvere questo problema, ogni agente MUST (deve) selezionare un numero casuale, chiamato spareggio (tie-breaker), distribuito uniformemente tra 0 e (2**64) - 1 (ovvero un numero intero positivo a 64 bit). Questo numero viene utilizzato nei controlli di connettività per rilevare e riparare questo caso, come descritto nella Sezione 7.1.2.2.
-
Un agente completo, uno Lite: L'agente completo MUST (deve) assumere il ruolo di controllo e l'agente Lite MUST (deve) assumere il ruolo controllato. L'agente completo formerà liste di controllo, eseguirà le macchine a stati ICE e genererà controlli di connettività. Tale agente eseguirà la logica nella Sezione 8.1 per nominare le coppie che verranno selezionate da ICE e utilizzerà la logica nella Sezione 8.1.2 per terminare ICE. L'implementazione Lite ascolterà semplicemente i controlli di connettività, li riceverà e risponderà ad essi, quindi concluderà ICE come descritto nella Sezione 8.2. Per l'implementazione Lite, lo stato dell'elaborazione ICE per ogni flusso multimediale è considerato Running (In esecuzione) e lo stato di ICE nel complesso è Running.
-
Entrambi Lite: L'agente che ha generato l'offerta che ha avviato l'elaborazione ICE MUST (deve) assumere il ruolo di controllo e l'altro MUST (deve) assumere il ruolo controllato. In questo caso, non vengono mai inviati controlli di connettività. Piuttosto, una volta completato lo scambio offerta/risposta, ogni agente esegue l'elaborazione descritta nella Sezione 8 senza controlli di connettività. È possibile che entrambi gli agenti credano di essere controllati o di controllo. In quest'ultimo caso, il conflitto viene risolto tramite funzionalità di rilevamento dell'abbagliamento (glare) nel protocollo di segnalazione che trasporta lo scambio offerta/risposta. Lo stato dell'elaborazione ICE per ogni flusso multimediale è considerato Running e lo stato di ICE nel complesso è Running.
Una volta determinati i ruoli per una sessione, persistono a meno che ICE non venga riavviato. Un riavvio di ICE (Sezione 9.1) provoca una nuova selezione di ruoli e spareggi.
5.3. Gathering Candidates (Raccolta dei candidati)
Il processo per la raccolta dei candidati presso chi risponde è identico al processo per l'offerente come descritto nella Sezione 4.1.1 per le implementazioni complete e nella Sezione 4.2 per le implementazioni Lite. È RECOMMENDED (raccomandato) che questo processo inizi immediatamente alla ricezione dell'offerta, prima di avvisare l'utente. Tale raccolta MAY (può) iniziare all'avvio di un agente.
5.4. Prioritizing Candidates (Assegnazione delle priorità ai candidati)
Il processo per l'assegnazione delle priorità ai candidati presso chi risponde è identico al processo seguito dall'offerente, come descritto nella Sezione 4.1.2 per le implementazioni complete e nella Sezione 4.2 per le implementazioni Lite.
5.5. Choosing Default Candidates (Scelta dei candidati predefiniti)
Il processo per la selezione dei candidati predefiniti presso chi risponde è identico al processo seguito dall'offerente, come descritto nella Sezione 4.1.4 per le implementazioni complete e nella Sezione 4.2 per le implementazioni Lite.
5.6. Encoding the SDP (Codifica dell'SDP)
Il processo per la codifica dell'SDP presso chi risponde è identico al processo seguito dall'offerente sia per le implementazioni complete che per quelle Lite, come descritto nella Sezione 4.3.
5.7. Forming the Check Lists (Formazione delle liste di controllo)
La formazione delle liste di controllo viene eseguita solo da implementazioni complete. Le implementazioni Lite MUST (devono) saltare i passaggi definiti in questa sezione.
C'è una lista di controllo per flusso multimediale in uso risultante dallo scambio offerta/risposta. Per formare la lista di controllo per un flusso multimediale, l'agente forma coppie di candidati, calcola una priorità della coppia di candidati, ordina le coppie per priorità, le pota e imposta i loro stati. Questi passaggi sono descritti in questa sezione.
5.7.1. Forming Candidate Pairs (Formazione delle coppie di candidati)
Innanzitutto, l'agente prende ciascuno dei suoi candidati per un flusso multimediale (chiamati CANDIDATI LOCALI) e li accoppia con i candidati che ha ricevuto dal suo peer (chiamati CANDIDATI REMOTI) per quel flusso multimediale. Al fine di prevenire gli attacchi descritti nella Sezione 18.5.2, gli agenti MAY (possono) limitare il numero di candidati che accetteranno in un'offerta o una risposta. Un candidato locale è accoppiato con un candidato remoto se e solo se i due candidati hanno lo stesso ID componente e hanno la stessa versione dell'indirizzo IP. È possibile che alcuni dei candidati locali non vengano accoppiati con candidati remoti e che alcuni dei candidati remoti non vengano accoppiati con candidati locali. Ciò può accadere se un agente non include candidati per tutti i componenti di un flusso multimediale. Se ciò accade, il numero di componenti per quel flusso multimediale viene effettivamente ridotto e considerato uguale al minimo tra entrambi gli agenti dell'ID componente massimo fornito da ciascun agente tra tutti i componenti per il flusso multimediale.
Nel caso di RTP, ciò accadrebbe quando un agente fornisce candidati per RTCP e l'altro no. Come altro esempio, l'offerente può eseguire il multiplexing di RTP e RTCP sulla stessa porta e segnala che può farlo nell'SDP tramite un attributo SDP [RFC5761]. Tuttavia, poiché l'offerente non sa se chi risponde può eseguire tale multiplexing, l'offerente include candidati per RTP e RTCP su porte separate, in modo che l'offerta abbia due componenti per flusso multimediale. Se chi risponde può eseguire tale multiplexing, includerebbe solo un singolo componente per ogni candidato - per il mux combinato RTP/RTCP. ICE finirebbe per agire come se ci fosse solo un singolo componente per questo candidato.
Le coppie di candidati i cui candidati locali e remoti sono entrambi i candidati predefiniti per un particolare componente sono chiamate, senza sorpresa, la coppia di candidati predefinita per quel componente. Questa è la coppia che verrebbe utilizzata per trasmettere i media se entrambi gli agenti non fossero a conoscenza di ICE.
Per facilitare la comprensione, la Figura 6 mostra le relazioni tra diversi concetti chiave: indirizzi di trasporto, candidati, coppie di candidati e liste di controllo, oltre a indicare le proprietà principali dei candidati e delle coppie di candidati.
+------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +ComponentiD |
| | Transport | +RelatedAddr |
| | Addr | |
| +---------------------+ +Base |
| Candidate |
+------------------------------------------+
* *
* *************************************
* *
+-------------------------------+
.| |
| Local Remote |
| +----+ +----+ +default? |
| |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?|
| +State |
| |
| |
| Candidate Pair |
+-------------------------------+
* *
* ************
* *
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
Check
List
Figura 6: Diagramma concettuale di una lista di controllo
5.7.2. Computing Pair Priority and Ordering Pairs (Calcolo della priorità della coppia e ordinamento delle coppie)
Una volta formate le coppie, viene calcolata una priorità della coppia di candidati. Sia G la priorità per il candidato fornito dall'agente di controllo. Sia D la priorità per il candidato fornito dall'agente controllato. La priorità per una coppia è calcolata come:
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Dove G>D?1:0 è un'espressione il cui valore è 1 se G è maggiore di D, e 0 altrimenti. Una volta assegnata la priorità, l'agente ordina le coppie di candidati in ordine decrescente di priorità. Se due coppie hanno priorità identica, l'ordinamento tra loro è arbitrario.
5.7.3. Pruning the Pairs (Potatura delle coppie)
Questa lista ordinata di coppie di candidati viene utilizzata per determinare una sequenza di controlli di connettività che verranno eseguiti. Ogni controllo comporta l'invio di una richiesta da un candidato locale a un candidato remoto. Poiché un agente non può inviare richieste direttamente da un candidato riflessivo, ma solo dalla sua base, l'agente scorre successivamente la lista ordinata di coppie di candidati. Per ogni coppia in cui il candidato locale è riflessivo del server, il candidato riflessivo del server MUST (deve) essere sostituito dalla sua base. Una volta fatto ciò, l'agente MUST (deve) potare la lista. Questo viene fatto rimuovendo una coppia se i suoi candidati locali e remoti sono identici ai candidati locali e remoti di una coppia più in alto nella lista delle priorità. Il risultato è una sequenza di coppie di candidati ordinate, chiamata lista di controllo per quel flusso multimediale.
Inoltre, per limitare gli attacchi descritti nella Sezione 18.5.2, un agente MUST (deve) limitare il numero totale di controlli di connettività eseguiti dall'agente su tutte le liste di controllo a un valore specifico e questo valore MUST (deve) essere configurabile. Un valore predefinito di 100 è RECOMMENDED (raccomandato). Questo limite viene applicato scartando le coppie di candidati con priorità inferiore finché non ce ne sono meno di 100. È RECOMMENDED (raccomandato) utilizzare un valore inferiore quando possibile, impostato sul numero massimo di controlli plausibili che potrebbero essere visti in una configurazione di distribuzione reale. Il requisito per la configurazione è inteso a fornire uno strumento per correggere questo valore sul campo se, una volta distribuito, si scopre che è problematico.
5.7.4. Computing States (Calcolo degli stati)
Ogni coppia di candidati nella lista di controllo ha una fondazione e uno stato. La fondazione è la combinazione delle fondazioni dei candidati locali e remoti nella coppia. Lo stato viene assegnato una volta calcolata la lista di controllo per ogni flusso multimediale. Ci sono cinque valori potenziali che lo stato può avere:
-
Waiting (In attesa): Non è stato eseguito un controllo per questa coppia e può essere eseguito non appena è la coppia In attesa con la priorità più alta nella lista di controllo.
-
In-Progress (In corso): È stato inviato un controllo per questa coppia, ma la transazione è in corso.
-
Succeeded (Riuscito): Un controllo per questa coppia è già stato eseguito e ha prodotto un risultato positivo.
-
Failed (Fallito): Un controllo per questa coppia è già stato eseguito ed è fallito, non producendo mai alcuna risposta o producendo una risposta di errore irrecuperabile.
-
Frozen (Congelato): Un controllo per questa coppia non è stato eseguito e non può ancora essere eseguito finché non riesce qualche altro controllo, consentendo a questa coppia di sbloccarsi e passare allo stato In attesa.
Mentre ICE viene eseguito, le coppie si sposteranno tra gli stati come mostrato nella Figura 7.
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
|unfreeze
|
V
+-----------+ +-----------+
| | | |
| | perform | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
failure // |success
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+
Figura 7: FSM dello stato della coppia
Gli stati iniziali per ogni coppia in una lista di controllo vengono calcolati eseguendo la seguente sequenza di passaggi:
-
L'agente imposta tutte le coppie in ogni lista di controllo sullo stato Congelato.
-
L'agente esamina la lista di controllo per il primo flusso multimediale (un flusso multimediale è il primo flusso multimediale quando è descritto dalla prima riga m nell'offerta e nella risposta SDP). Per quel flusso multimediale:
- Per tutte le coppie con la stessa fondazione, imposta lo stato della coppia con l'ID componente più basso su In attesa. Se c'è più di una coppia di questo tipo, viene utilizzata quella con la priorità più alta.
Una delle liste di controllo avrà un certo numero di coppie nello stato In attesa e le altre liste di controllo avranno tutte le loro coppie nello stato Congelato. Una lista di controllo con almeno una coppia in attesa è chiamata lista di controllo attiva (active check list) e una lista di controllo con tutte le coppie congelate è chiamata lista di controllo congelata (frozen check list).
La lista di controllo stessa è associata a uno stato, che cattura lo stato dei controlli ICE per quel flusso multimediale. Ci sono tre stati:
-
Running (In esecuzione): In questo stato, i controlli ICE sono ancora in corso per questo flusso multimediale.
-
Completed (Completato): In questo stato, i controlli ICE hanno prodotto coppie nominate per ogni componente del flusso multimediale. Di conseguenza, ICE ha avuto successo e i media possono essere inviati.
-
Failed (Fallito): In questo stato, i controlli ICE non sono stati completati con successo per questo flusso multimediale.
Quando una lista di controllo viene costruita per la prima volta come conseguenza di uno scambio offerta/risposta, viene posta nello stato In esecuzione.
Anche l'elaborazione ICE su tutti i flussi multimediali ha uno stato associato ad essa. Questo stato è uguale a Running mentre l'elaborazione ICE è in corso. Lo stato è Completed quando l'elaborazione ICE è completa e Failed se è fallita senza successo. Le regole per la transizione tra gli stati sono descritte di seguito.
5.8. Scheduling Checks (Pianificazione dei controlli)
I controlli sono generati solo da implementazioni complete. Le implementazioni Lite MUST (devono) saltare i passaggi descritti in questa sezione.
Un agente esegue controlli ordinari e controlli attivati. La generazione di entrambi i controlli è regolata da un timer che scatta periodicamente per ogni flusso multimediale. L'agente mantiene una coda FIFO, chiamata coda dei controlli attivati (triggered check queue), che contiene coppie di candidati per le quali i controlli devono essere inviati alla prossima opportunità disponibile. Quando il timer scatta, l'agente rimuove la coppia superiore dalla coda dei controlli attivati, esegue un controllo di connettività su quella coppia e imposta lo stato della coppia di candidati su In-Progress. Se non ci sono coppie nella coda dei controlli attivati, viene inviato un controllo ordinario.
Una volta che l'agente ha calcolato le liste di controllo come descritto nella Sezione 5.7, imposta un timer per ogni lista di controllo attiva. Il timer scatta ogni Ta*N secondi, dove N è il numero di liste di controllo attive (inizialmente, c'è solo una lista di controllo attiva). Le implementazioni MAY (possono) impostare il timer in modo che scatti meno frequentemente di così. Le implementazioni SHOULD (dovrebbero) fare attenzione a distribuire questi timer in modo che non scattino contemporaneamente per ogni flusso multimediale. Ta e il timer di ritrasmissione RTO sono calcolati come descritto nella Sezione 16. Moltiplicando per N consente di suddividere questo throughput di controllo aggregato tra tutte le liste di controllo attive. Il primo timer scatta immediatamente, in modo che l'agente esegua un controllo di connettività nel momento in cui è stato effettuato lo scambio offerta/risposta, seguito dal controllo successivo Ta secondi dopo (poiché c'è solo una lista di controllo attiva).
Quando il timer scatta e non c'è alcun controllo attivato da inviare, l'agente MUST (deve) scegliere un controllo ordinario come segue:
-
Trova la coppia con la priorità più alta in quella lista di controllo che si trova nello stato In attesa.
-
Se esiste una coppia di questo tipo:
- Invia un controllo STUN dal candidato locale di quella coppia al candidato remoto di quella coppia. Le procedure per formare la richiesta STUN a questo scopo sono descritte nella Sezione 7.1.2.
- Imposta lo stato della coppia di candidati su In-Progress.
-
Se non esiste una coppia di questo tipo:
- Trova la coppia con la priorità più alta in quella lista di controllo che si trova nello stato Congelato.
- Se esiste una coppia di questo tipo:
- Scongela la coppia.
- Esegui un controllo per quella coppia, facendo passare il suo stato a In-Progress.
- Se non esiste una coppia di questo tipo:
- Termina il timer per quella lista di controllo.
Per calcolare l'integrità del messaggio per il controllo, l'agente utilizza il frammento di nome utente remoto e la password appresi dall'SDP dal suo peer. Il frammento di nome utente locale è noto direttamente dall'agente per il proprio candidato.