3.5. Algoritmo di scheduling RTCP AVPF (AVPF RTCP Scheduling Algorithm)

Sia S0 un mittente attivo (tra S mittenti) e N il numero di ricevitori, con R uno di essi.

Si suppone che R abbia verificato che l'uso di meccanismi di feedback sia ragionevole nella costellazione attuale (fortemente dipendente dall'applicazione e quindi non specificata qui).

Si suppone inoltre che T_rr_interval sia 0 se non si impone un intervallo minimo tra RTCP regolari, oppure che sia impostato a un valore significativo dall'applicazione, che rappresenta l'intervallo minimo tra RTCP regolari.

Con ciò, un ricevitore R MUST applicare le seguenti regole per trasmettere uno o più messaggi FB come pacchetto RTCP composto minimale o completo.

3.5.1. Inizializzazione

Inizialmente, R MUST impostare allow_early = TRUE e t_rr_last = NaN (Not-a-Number, valore non valido distinguibile da un tempo valido).

Si applica anche l'inizializzazione delle variabili RTCP di [1], salvo il valore iniziale di Tmin. Per sessione punto-punto, Tmin iniziale è 0. Per sessione multipunto, Tmin è inizializzato a 1,0 secondi.

3.5.2. Trasmissione di feedback anticipato

Supponiamo che R abbia pianificato l'ultimo RR RTCP regolare per tp (inviato o soppresso a tp) e la prossima trasmissione (con possibile reconsideration [1]) per tn = tp + T_rr, e che l'ultimo RTCP regolare sia avvenuto a t_rr_last.

L'algoritmo di feedback anticipato comprende:

1. All'istante t0, R rileva la necessità di trasmettere uno o più messaggi FB (es. unità multimediali da ACKare/NACKare) e ritiene utile fornire il feedback al mittente.

2. R verifica prima se esiste già un RTCP composto con uno o più FB pianificato (anticipato o regolare).

   2a) Se sì, il nuovo FB MUST essere incluso nel pacchetto pianificato; la pianificazione MUST restare invariata. Le informazioni di feedback disponibili SHOULD essere unite per minimizzare i messaggi FB. Fine azioni immediate.

   2b) Se no, MUST creare un nuovo RTCP composto (minimale o completo) e MUST scegliere l'intervallo minimo per T_dither_max così:

   i) Sessione punto-punto: T_dither_max = 0.

   ii) Sessione multipoint: T_dither_max = l * T_rr con l=0,5.

   T_dither_max MAY essere calcolato diversamente (es. su RTT), MUST allora essere specificato in un documento futuro che MUST garantire lo stesso meccanismo per tutti i ricevitori RTP. I valori sopra sono minimi; l'implementatore può aumentarli per esigenze applicative.

3. R MUST verificare se il prossimo RTCP regolare cadrebbe entro i limiti temporali del RTCP anticipato scatenato a t0, cioè se t0 + T_dither_max > tn.

   3a) Se sì, MUST NOT pianificare RTCP anticipato; i FB MUST essere memorizzati per il RTCP regolare a tn. Fine azioni immediate.

   3b) Altrimenti proseguire.

4. R MUST verificare se è consentito RTCP anticipato: allow_early == TRUE.

   4a) Se FALSE, R MUST controllare il prossimo RTCP regolare:

   1. Se tn - t0 < T_max_fb_delay, il feedback può essere ancora utile; R MAY creare un FB da includere nel RTCP regolare a tn.

   2. Altrimenti R MUST scartare il FB.

   Fine azioni immediate.

   4b) Se TRUE, R MUST pianificare RTCP anticipato per te = t0 + RND * T_dither_max, RND uniforme tra 0 e 1.

5. R MUST rilevare sovrapposizioni tra FB ricevuti da altri membri e FB che R intende inviare. Da membro della sessione, R MUST monitorare l'arrivo di RTCP composti (minimali) e memorizzare ogni FB per almeno T_retention. Pianificando il proprio FB dopo i passi 1–4, R MUST esaminare FB memorizzati e nuovi nell'intervallo [t0 - T_retention ; te]:

   5a) Se R capisce la semantica e il contenuto è sovrainsieme del feedback desiderato, MUST scartare il proprio FB e MUST ripianificare il prossimo RTCP regolare per tn.

   5b) Se capisce ma non è sovrainsieme, SHOULD inviare il proprio FB come pianificato; in caso di sovrapposizione R MAY lasciare invariato o MAY ridurre ridondanza.

   5c) Se non capisce, MAY mantenere FB anticipato o MAY ripianificare RTCP regolare per tn e MAY accodare il FB al messaggio regolare.

   Nota: con 5c), FB sconosciuti possono impedire la soppressione; un evento può generare M tipi di FB, partizionando i ricevitori in al più M gruppi; soppressione intra-gruppo ma non tra gruppi; O(M) messaggi al mittente; implosione limitata; M di solito piccolo.

   Distribuiti casualmente su T_dither_max, i pacchetti extra non dovrebbero sovraccaricare il mittente e contengono informazioni complementari.

6. Se i FB di R non sono stati soppressi dal passo 5, a te R MUST trasmettere il RTCP composto (minimale) con i FB. Poi MUST allow_early = FALSE, tn = tp + 2*T_rr, tp al precedente tn. Raggiunto il nuovo tn, che R invii o sopprima il RTCP regolare, MUST allow_early = TRUE.

3.5.3. Trasmissione RTCP regolare

I pacchetti RTCP composti completi MUST essere inviati a intervalli regolari. Tali pacchetti MAY contenere uno o più messaggi FB. La trasmissione dei RTCP regolari è pianificata come segue.

Se T_rr_interval == 0, la trasmissione MUST seguire le regole delle sezioni 3.2 e 3.4 di questo documento e MUST rispettare gli aggiustamenti di tn della sezione 3.5.2 (cioè saltare una trasmissione regolare se è avvenuta una trasmissione anticipata). La reconsideration del timer avviene al raggiungimento di tn secondo [1]. Il RTCP regolare viene trasmesso dopo la reconsideration. Ogni volta che un RTCP regolare viene inviato o soppresso, allow_early MUST essere TRUE e tp, tn MUST essere aggiornati secondo [1]. Dopo la prima trasmissione di un RTCP regolare, Tmin MUST essere 0.

Se T_rr_interval != 0, il calcolo degli istanti MUST seguire le sezioni 3.2 e 3.4 e gli aggiustamenti di tn della sezione 3.5.2. La reconsideration avviene a tn secondo [1]. Dopo la reconsideration:

1. Se non è mai stato inviato un RTCP regolare (t_rr_last == NaN), MUST pianificare un RTCP regolare. I FB memorizzati MAY essere inclusi. Dopo l'invio, t_rr_last MUST essere tn. Tmin MUST essere 0.

2. Altrimenti si calcola T_rr_current_interval = RND*T_rr_interval con RND pseudo-casuale uniforme tra 0,5 e 1,5. Da questo valore dithered:

   2a) Se t_rr_last + T_rr_current_interval <= tn, MUST pianificare un RTCP regolare. I FB RTCP memorizzati MAY essere inclusi. Dopo l'invio, t_rr_last MUST essere tn.

   2b) Se t_rr_last + T_rr_current_interval > tn e ci sono FB RTCP memorizzati in attesa, MUST pianificare un pacchetto RTCP per tn. Il pacchetto MAY essere minimale o regolare (a discrezione dell'implementatore) e il composto MUST includere i FB memorizzati. t_rr_last MUST restare invariato.

   2c) Altrimenti (stessa disuguaglianza ma nessun FB in attesa), il composto MUST essere soppresso (non pianificato). t_rr_last MUST restare invariato.

Nei quattro casi (1, 2a, 2b, 2c), allow_early MUST essere TRUE (eventualmente dopo l'invio) e tp, tn MUST essere aggiornati secondo [1], salvo il minimo di cinque secondi.

3.5.4. Altre considerazioni

Se T_rr_interval != 0, il timeout per entità RTP/AVPF (sezione 6.3.5 di [1]) MUST usare T_rr_interval al posto di Tmin per Td e M*Td.

Ogni invio o ricezione di RTCP composto (minimale o completo, anticipato o regolare), MUST aggiornare avg_rtcp_size [1] e i calcoli successivi di tn MUST usare il nuovo valore.