Passa al contenuto principale

16. Setting Ta and RTO (Impostazione di Ta e RTO)

Durante la fase di raccolta di ICE (Sezione 4.1.1) e mentre ICE sta eseguendo i controlli di connettività (Sezione 7), un agente invia transazioni STUN e TURN. Queste transazioni sono ritmate a una velocità di una ogni Ta millisecondi e utilizzano uno specifico RTO. Questa sezione descrive come vengono calcolati i valori di Ta e RTO. Questo calcolo dipende dal fatto che ICE venga utilizzato con un flusso multimediale in tempo reale (come RTP) o qualcos'altro. Quando ICE viene utilizzato per un flusso con una larghezza di banda massima nota, il calcolo nella Sezione 16.1 MAY essere seguito per controllare la velocità degli scambi ICE. Per tutti gli altri flussi, il calcolo nella Sezione 16.2 MUST essere seguito.

16.1. RTP Media Streams (Flussi multimediali RTP)​

I valori di RTO e Ta cambiano durante la durata dell'elaborazione ICE. Un insieme di valori si applica durante la fase di raccolta e l'altro per i controlli di connettività.

Il valore di Ta SHOULD essere configurabile e SHOULD avere un valore predefinito di:

Per ogni flusso multimediale i:

Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime

                       1
 Ta = MAX (20ms, ------------------- )
                       k
                     ----
                     \        1
                      >    ------
                     /       Ta_i
                     ----
                      i=1

dove k è il numero di flussi multimediali. Durante la fase di raccolta, Ta viene calcolato in base al numero di flussi multimediali che l'agente ha indicato nella sua offerta o risposta, e la dimensione del pacchetto RTP e rtp_ptime sono quelli del codec più preferito per ciascun flusso multimediale. Una volta che un'offerta e una risposta sono state scambiate, l'agente ricalcola Ta per ritmare i controlli di connettività. In tal caso, il valore di Ta si basa sul numero di flussi multimediali che verranno effettivamente utilizzati nella sessione, e la dimensione del pacchetto RTP e rtp_ptime sono quelli del codec più preferito con cui l'agente invierà.

Inoltre, il timer di ritrasmissione per le transazioni STUN, RTO, definito in [RFC5389], SHOULD essere configurabile e durante la fase di raccolta, SHOULD avere un valore predefinito di:

RTO = MAX (100ms, Ta * (number of pairs))

dove number of pairs si riferisce al numero di coppie di candidati con server STUN o TURN.

Per i controlli di connettività, RTO SHOULD essere configurabile e SHOULD avere un valore predefinito di:

RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))

dove Num-Waiting è il numero di controlli nell'elenco di controllo nello stato Waiting e Num-In-Progress è il numero di controlli nello stato In-Progress. Si noti che l'RTO sarà diverso per ogni transazione man mano che cambia il numero di controlli negli stati Waiting e In-Progress.

Queste formule hanno lo scopo di far sì che le transazioni STUN siano ritmate alla stessa velocità dei media. Ciò garantisce che ICE funzioni correttamente nelle stesse condizioni di rete necessarie per supportare anche i media. Vedere l'Appendice B.1 per ulteriori discussioni e motivazioni. A causa di questo ritmo, ci vorrà una certa quantità di tempo per ottenere tutti i candidati server reflexive e relayed. Le implementazioni dovrebbero essere consapevoli del tempo necessario per fare ciò e, se l'applicazione richiede un budget temporale, limitare il numero di candidati raccolti.

Le formule determinano un comportamento per cui un agente invierà il suo primo pacchetto per ogni singolo controllo di connettività prima di eseguire una ritrasmissione. Questo può essere visto nelle formule per l'RTO (che rappresenta l'intervallo di ritrasmissione). Tali formule scalano con N, il numero di controlli da eseguire. Di conseguenza, ICE mantiene una velocità piacevolmente costante, ma diventa più sensibile alla perdita di pacchetti. È probabile che la perdita del primo singolo pacchetto per qualsiasi controllo di connettività faccia sì che quella coppia impieghi molto tempo per essere convalidata e, invece, è molto più probabile che un controllo a priorità inferiore (ma per il quale non c'è stata perdita di pacchetti) venga completato per primo. Ciò fa sì che ICE funzioni in modo non ottimale, scegliendo coppie a priorità inferiore rispetto a coppie a priorità superiore. Gli implementatori dovrebbero essere consapevoli di questa conseguenza, ma dovrebbero comunque utilizzare i valori del timer descritti qui.

16.2. Non-RTP Sessions (Sessioni non RTP)​

Nei casi in cui ICE viene utilizzato per stabilire un tipo di sessione che non è in tempo reale e non ha una velocità fissa associata che è nota per funzionare sulla rete in cui è distribuito ICE, Ta e RTO tornano a valori più conservativi. Ta SHOULD essere configurabile, SHOULD avere un valore predefinito di 500 ms e MUST NOT essere configurabile per essere inferiore a 500 ms.

Inoltre, il timer di ritrasmissione per le transazioni STUN, RTO, SHOULD essere configurabile e durante la fase di raccolta, SHOULD avere un valore predefinito di:

RTO = MAX (500ms, Ta * (number of pairs))

dove number of pairs si riferisce al numero di coppie di candidati con server STUN o TURN.

Per i controlli di connettività, RTO SHOULD essere configurabile e SHOULD avere un valore predefinito di:

RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
Ultimo aggiornamento il