3.4. Definizioni e panoramica dell'algoritmo (Definitions and Algorithm Overview)

Le seguenti informazioni di stato devono essere mantenute per ricevitore (in gran parte da [1]). Tutte le variabili (tranne al punto h) sotto) sono calcolate indipendentemente in ogni ricevitore; i valori locali possono quindi differire in ogni istante.

a) Sia senders il numero di mittenti attivi nella sessione RTP.

b) Sia members la stima corrente del numero di ricevitori nella sessione RTP.

c) Siano tn e tp gli istanti della prossima (rispettivamente ultima) trasmissione RTCP RR pianificata prima del timer reconsideration.

d) Sia Tmin l'intervallo minimo tra pacchetti RTCP secondo [1]. A differenza di [1], il valore iniziale di Tmin è 1 secondo per consentire un campionamento della dimensione del gruppo prima del primo pacchetto RTCP. Dopo il primo invio, Tmin è impostato a 0.

e) Sia T_rr l'intervallo dopo il quale, avendo appena inviato un pacchetto RTCP regolare pianificato, un ricevitore pianificherebbe il successivo pacchetto RTCP regolare. Si ottiene con le regole di [1] ma con Tmin come in questo documento: T_rr = T («intervallo calcolato» in [1]) con tn = tp + T. T_rr si riferisce sempre all'ultimo T calcolato (reconsideration o determinazione di tn). In questo documento T_rr è anche detto intervallo RTCP regolare (Regular RTCP interval).

f) Sia t0 l'istante in cui un evento da segnalare è rilevato dal ricevitore.

g) Sia T_dither_max l'intervallo massimo per cui un pacchetto di feedback RTCP MAY essere ritardato ulteriormente per evitare implosioni in sessioni multipunto; il valore è calcolato dinamicamente da T_rr (o MAY essere derivato in futuro con un meccanismo comune a tutti i ricevitori RTP). Per sessioni punto-punto (esattamente due membri, nessun cambio atteso della dimensione del gruppo, es. streaming unicast), T_dither_max = 0.

h) Sia T_max_fb_delay il limite superiore entro cui il feedback relativo a un evento deve essere riportato al mittente per essere utile. Valore specifico dell'applicazione; questo documento non definisce valori.

i) Sia te l'istante per cui è pianificato un pacchetto di feedback.

j) Sia T_fd il ritardo effettivo (randomizzato) per la trasmissione di un messaggio FB in risposta a un evento a t0.

k) Sia allow_early una variabile booleana che indica se il ricevitore può trasmettere messaggi FB prima del prossimo intervallo RTCP regolare pianificato tn. Serve a limitare il feedback di un singolo ricevitore. Dopo un invio anticipato è FALSE; torna TRUE al successivo RTCP regolare.

l) Sia avg_rtcp_size la media mobile della dimensione dei pacchetti RTCP come in [1].

m) Sia T_rr_interval un intervallo minimo OPZIONALE tra pacchetti RTCP regolari. Se T_rr_interval == 0 non ha effetto. Se != 0, il prossimo RTCP regolare non è pianificato a tp+T_rr ma non prima di tp+T_rr_interval. Non altera il calcolo di T_rr e tp; i RTCP regolari prima di tp+T_rr_interval possono essere soppressi se non contengono FB. Non influenza la pianificazione dei RTCP anticipati.

Nota: T_rr_interval separato consente di ridurre il RTCP regolare (banda) pur mantenendo RTCP anticipati più frequenti; ridurre la banda RTCP complessiva non otterrebbe lo stesso effetto.

n) Sia t_rr_last l'istante in cui l'ultimo RTCP regolare è stato pianificato e inviato (non soppresso per T_rr_interval).

o) Sia T_retention la finestra in cui i messaggi FB passati sono memorizzati da un'entità AVPF, per la soppressione del feedback anche se altri FB arrivano prima dell'evento locale. T_retention MUST essere almeno 2 secondi.

p) Sia M*Td il timeout per considerare inattivo un ricevitore ([1]).

La situazione di feedback è illustrata nella figura 2. A t0 si rileva l'evento (es. perdita di pacchetto); il ricevitore decide che serve un FB al mittente.

Per evitare implosioni, il ricevitore MUST ritardare il RTCP di feedback di un tempo casuale T_fd uniforme in [0, T_dither_max]. La trasmissione del composto RTCP MUST essere pianificata per te = t0 + T_fd.

T_dither_max deriva da T_rr e dalla dimensione del gruppo. Documenti futuri MAY specificare altri calcoli (es. RTT) se tutti i ricevitori usano lo stesso meccanismo.

Il ricevitore MAY definire T_max_fb_delay; se T_dither_max può superarlo, MAY non inviare feedback.

Dopo un RTCP anticipato, MUST aggiornare tn=tp+2*T_rr e poi tp al precedente tn, per non superare a breve termine la banda RTCP media rispetto al caso senza anticipo.

            event to
            report
            detected
               |
               |  RTCP feedback range
               |   (T_max_fb_delay)
               vXXXXXXXXXXXXXXXXXXXXXXXXXXX     ) )
|---+--------+-------------+-----+------------| |--------+--->
    |        |             |     |            ( (        |
    |       t0            te                             |
    tp                                                   tn
              \_______  ________/
                      \/
                T_dither_max

     Figure 2: Event report and parameters for Early RTCP scheduling