Passa al contenuto principale

4. Estensioni dei rapporti ricevitore RTCP

Il presente memo specifica sei nuovi messaggi di feedback. Full Intra Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Trade-off Notification (TSTN) e Video Back Channel Message (VBCM) sono "Payload Specific Feedback Messages" come definiti nella sezione 6.3 di AVPF [RFC4585]. Temporary Maximum Media Stream Bit Rate Request (TMMBR) e Temporary Maximum Media Stream Bit Rate Notification (TMMBN) sono "Transport Layer Feedback Messages" come definiti nella sezione 6.2 di AVPF.

I nuovi messaggi di feedback sono definiti nelle sottosezioni seguenti, seguendo una struttura simile a quella delle sezioni 6.2 e 6.3 della specifica AVPF [RFC4585].

4.1. Principi di progettazione del meccanismo di estensione​

RTCP è stato introdotto originariamente come canale per trasmettere presenza, statistiche sulla qualità di ricezione e indicazioni sulla codifica media desiderata. Un insieme limitato di meccanismi di controllo media è stato introdotto nei primi formati di payload RTP per formati video, ad esempio in RFC 2032 [RFC2032] (sostituito da RFC 4587 [RFC4587]). Tuttavia, questa specifica, per la prima volta, propone un handshake bidirezionale per alcuni dei suoi messaggi. C'è il rischio che tale introduzione sia fraintesa come precedente per l'uso di RTCP come protocollo di controllo di sessione RTP. Per prevenire tale fraintendimento, la presente sottosezione tenta di chiarire l'ambito delle estensioni specificate in questo memo, e suggerisce fortemente che le estensioni future seguano la logica qui esposta, o spieghino in modo convincente perché se ne discostano.

In questo memo, e in AVPF [RFC4585], sono stati inclusi solo messaggi che:

a) hanno vincoli di tempo real-time relativamente rigidi, che impediscono l'uso di meccanismi come un SIP re-invite nella maggior parte degli scenari applicativi (i vincoli di tempo real-time sono spiegati separatamente per ciascun messaggio ove necessario);

b) sono sicuri per il multicast nel senso che la reazione a messaggi di feedback potenzialmente contraddittori è specificata, come necessario per ciascun messaggio; e

c) sono direttamente correlati alle attività di un certo codec media, classe di codec media (ad es., codec video), o di un dato flusso di pacchetti RTP.

In questo memo, un handshake bidirezionale è introdotto solo per messaggi per i quali:

a) è richiesta una notifica o un acknowledgement a causa della loro natura. Un'analisi per determinare se tale requisito esiste è stata effettuata separatamente per ciascun messaggio.

b) la notifica o l'acknowledgement non può essere facilmente derivato dal bit stream media.

Tutti i messaggi in AVPF [RFC4585] e in questo memo presentano i loro contenuti in un formato binario semplice e fisso. Ciò consente ai ricevitori media che non hanno implementato funzionalità di protocollo di controllo di livello superiore (SDP, parser XML, e simili) nel loro percorso media.

I messaggi che non rispettano i principi di progettazione appena descritti non costituiscono un uso appropriato di RTCP o del Codec Control Framework definito in questo documento.

4.2. Messaggi di feedback a livello di trasporto​

Come specificato nella sezione 6.1 di RFC 4585 [RFC4585], i messaggi di feedback a livello di trasporto sono identificati dal valore di tipo di pacchetto RTCP RTPFB (205).

In AVPF era stato definito un messaggio di questa categoria. Questo memo ne specifica altri due. Sono identificati mediante il parametro feedback message type (FMT) come segue:

Assegnato in AVPF [RFC4585]:

  • 1: Generic NACK
  • 31: riservato per futura espansione dello spazio dei numeri identificativi

Assegnato in questo memo:

  • 2: riservato (vedi nota sotto)

  • 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)

  • 4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

    Nota: le prime versioni di AVPF [RFC4585] riservavano FMT=2 per un code point successivamente rimosso. È stato osservato che possono esistere implementazioni sul campo che usano questo valore in conformità al documento scaduto. Poiché vi è spazio di numerazione sufficiente, si marca FMT=2 come riservato per evitare possibili problemi di interoperabilità con tali implementazioni precoci.

Disponibile per assegnazione:

  • 0: non assegnato
  • 5-30: non assegnato

La sottosezione seguente definisce i formati delle voci Feedback Control Information (FCI) rispettivamente per i messaggi TMMBR e TMMBN, e specifica il comportamento associato presso il mittente e il ricevitore media.

4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)​

Temporary Maximum Media Stream Bit Rate Request è identificata dal valore di tipo di pacchetto RTCP PT=RTPFB e FMT=3.

Il campo FCI di un messaggio Temporary Maximum Media Stream Bit Rate Request (TMMBR) SHALL contenere una o più voci FCI.

4.2.1.1. Formato del messaggio​

La Feedback Control Information (FCI) consiste in una o più voci FCI TMMBR con la sintassi seguente:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 - Syntax of an FCI Entry in the TMMBR Message

  • SSRC (32 bit): Il valore SSRC del mittente media al quale si richiede di rispettare il nuovo bit rate massimo.

  • MxTBR Exp (6 bit): La scala esponenziale della mantissa per il valore del bit rate media totale massimo. Il valore è un intero senza segno [0..63].

  • MxTBR Mantissa (17 bit): La mantissa del valore del bit rate media totale massimo come intero senza segno.

  • Measured Overhead (9 bit): Il valore medio misurato dell'overhead del pacchetto in byte. La misurazione SHALL essere effettuata secondo la descrizione nella sezione 4.2.1.2. Il valore è un intero senza segno [0..511].

Il valore del bit rate media totale massimo (MxTBR) in bit al secondo è calcolato dall'esponente MxTBR (exp) e dalla mantissa nel modo seguente:

MxTBR = mantissa * 2^exp

Ciò consente 17 bit di risoluzione nell'intervallo da 0 a 1310722^63 (circa 1,210^24).

La lunghezza del messaggio di feedback TMMBR SHALL essere impostata a 2+2*N dove N è il numero di voci FCI TMMBR.

4.2.1.2. Semantica​

Comportamento al ricevitore media (mittente del TMMBR)

TMMBR è usato per indicare una limitazione legata al trasporto presso l'entità che riporta agendo come ricevitore media. TMMBR ha la forma di una tupla contenente due componenti. Il primo valore è il bit rate massimo per mittente di un flusso media, disponibile a un livello di protocollo scelto dal ricevitore, che il ricevitore attualmente supporta in questa sessione RTP. Il secondo valore è l'overhead dell'intestazione misurato in byte come definito nella sezione 2.2 e misurato al livello di protocollo scelto nei pacchetti ricevuti per il flusso. La misurazione dell'overhead è una media mobile aggiornata per ogni pacchetto ricevuto per questa particolare sorgente media (SSRC), usando la formula seguente:

avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,

dove avg_OH è la media mobile (esponenzialmente smussata) e pckt_OH è l'overhead osservato nell'ultimo pacchetto.

Se un bit rate massimo è stato negoziato tramite segnalazione, il bit rate media totale massimo che il ricevitore riporta in un messaggio TMMBR MUST NOT superare il valore negoziato convertito in una base comune (cioè con overhead adeguati per portarlo allo stesso livello di protocollo di riferimento).

Nell'intestazione comune del pacchetto per i messaggi di feedback (come definita nella sezione 6.1 di [RFC4585]), il campo "SSRC of packet sender" indica la sorgente della richiesta, e "SSRC of media source" non è usato e SHALL essere impostato a 0. All'interno di una particolare voce FCI TMMBR, "SSRC of media source" nel campo FCI denota il mittente media a cui la tupla si applica. Ciò è utile nelle topologie multicast o traduttore dove l'entità che riporta può rivolgersi a tutti i mittenti media in un singolo messaggio TMMBR usando più voci FCI.

Il ricevitore media SHALL salvare il contenuto dell'ultimo messaggio TMMBN ricevuto da ciascun mittente media.

Il ricevitore media MAY inviare una voce FCI TMMBR a un particolare mittente media nelle circostanze seguenti:

  • prima che sia stato ricevuto alcun messaggio TMMBN da quel mittente media;

  • quando il ricevitore media è stato identificato come sorgente di una tupla di confine nell'ultimo messaggio TMMBN ricevuto da quel mittente media, e il valore del bit rate media totale massimo o l'overhead relativo a quel mittente media è cambiato;

  • quando il ricevitore media non è stato identificato come sorgente di una tupla di confine nell'ultimo messaggio TMMBN ricevuto da quel mittente media, e, dopo che il ricevitore media applica l'algoritmo incrementale dalla sezione 3.5.4.2 o un equivalente più rigoroso, la tupla del ricevitore media relativa a quel mittente media è determinata come appartenente all'insieme di confine.

Una voce FCI TMMBR MAY essere ripetuta in messaggi TMMBR successivi se nessuna FCI Temporary Maximum Media Stream Bit Rate Notification (TMMBN) è stata ricevuta dal mittente media al momento della trasmissione del prossimo pacchetto RTCP. Il valore di bit rate di una voce FCI TMMBR MAY essere cambiato da un messaggio TMMBR al successivo. La misurazione dell'overhead SHALL essere aggiornata al valore corrente di avg_OH ogni volta che la voce è inviata.

Se il valore impostato da un messaggio TMMBR è atteso come permanente, la parte che imposta TMMBR SHOULD rinegoziare i parametri di sessione per rifletterlo usando la segnalazione di setup di sessione, ad es. un SIP re-invite.

Comportamento al mittente media (ricevitore del TMMBR)

Quando riceve un messaggio TMMBR contenente una voce FCI relativa a sé, il mittente media SHALL usare un algoritmo iniziale o incrementale come applicabile per determinare l'insieme di confine di tuple sulla base delle nuove informazioni. L'algoritmo usato SHALL essere almeno così rigoroso come l'algoritmo corrispondente definito nella sezione 3.5.4.2. Il mittente media MAY accumulare TMMBR su un piccolo intervallo (relativo all'intervallo di invio RTCP) prima di effettuare questo calcolo.

Una volta determinato l'insieme di confine di tuple, il mittente media MAY usare qualsiasi combinazione di packet rate e bit rate media netto nella regione fattibile che queste tuple descrivono per produrre un bit rate totale del flusso media inferiore, poiché può dover affrontare una situazione di congestione o altri fattori limitanti. Vedere la sezione 5 (controllo della congestione) per ulteriore discussione.

Se il mittente media conclude di poter aumentare il valore del bit rate media totale massimo, SHALL attendere prima di farlo effettivamente, per un periodo sufficientemente lungo da consentire a un ricevitore media di rispondere al TMMBN se determina che la sua tupla appartiene all'insieme di confine. Questo periodo di ritardo è stimato dalla formula:

2 * RTT + T_Dither_Max,

dove RTT è il round trip time massimo noto al mittente media e T_Dither_Max è definito nella sezione 3.4 di [RFC4585]. Anche in sessioni punto-punto, un mittente media MUST rispettare la regola sopra citata, poiché non è garantito che un partecipante sia in grado di determinare correttamente se tutte le sorgenti sono collocate in un singolo nodo, e siano coordinate.

Un messaggio TMMBN SHALL essere inviato dal mittente media al più presto possibile, in risposta a qualsiasi messaggio TMMBR ricevuto dall'ultimo invio di TMMBN. Il messaggio TMMBN indica l'insieme calcolato di tuple di confine e i proprietari di quelle tuple al momento della trasmissione del messaggio.

Un SSRC può scadere secondo le regole predefinite per i partecipanti alla sessione RTP, cioè il mittente media non ha ricevuto alcun pacchetto RTP o RTCP dal proprietario per gli ultimi cinque intervalli di reporting regolari. Un SSRC può anche lasciare esplicitamente la sessione, con il partecipante che lo indica tramite la trasmissione di un pacchetto RTCP BYE o usando un canale di segnalazione esterno. Se il mittente media determina che il proprietario di una tupla nell'insieme di confine ha lasciato la sessione, il mittente media SHALL trasmettere un nuovo TMMBN contenente l'insieme precedentemente determinato di tuple di confine ma con la tupla appartenente al proprietario partito rimossa.

Un mittente media MAY avviare proattivamente l'equivalente di un messaggio TMMBR verso sé stesso, quando è consapevole che il suo percorso di trasmissione è più restrittivo delle limitazioni attuali. Di conseguenza, viene inviato un TMMBN che indica la sorgente media stessa come proprietario di una tupla, evitando così messaggi TMMBR non necessari da altri partecipanti. Tuttavia, come qualsiasi altro partecipante, quando il mittente media diventa consapevole di limitazioni cambiate, è tenuto a cambiare la tupla, e a inviare un TMMBN corrispondente.

Discussione

A causa della natura inaffidabile del trasporto di TMMBR e TMMBN, le regole sopra possono portare all'invio di messaggi TMMBR che sembrano disobbedire a tali regole. Inoltre, in scenari multicast può accadere che più di un partecipante alla sessione "non proprietario" determini, giustamente o meno, che la sua tupla appartiene all'insieme di confine. Ciò non è critico per una serie di motivi:

a) Se un messaggio TMMBR si perde in trasmissione, o il mittente media invia un nuovo messaggio TMMBN in risposta a qualche altro ricevitore media oppure non invia affatto un nuovo messaggio TMMBN. Nel primo caso, il ricevitore media applica l'algoritmo incrementale e, se determina che la sua tupla dovrebbe far parte dell'insieme di confine, invia un altro TMMBR. Nel secondo caso, ripete l'invio di un TMMBR incondizionatamente. In ogni caso, il mittente media ottiene eventualmente le informazioni necessarie.

b) Analogamente, se un messaggio TMMBN si perde, il ricevitore media che ha inviato il TMMBR corrispondente non riceve la notifica e si attende che rinvii la richiesta e attivi la trasmissione di un altro TMMBN.

c) Se messaggi TMMBR concorrenti multipli sono inviati da diversi partecipanti alla sessione, allora l'algoritmo può essere applicato tenendo conto di tutti questi messaggi, e il TMMBN risultante fornisce ai partecipanti una vista aggiornata di come le loro tuple si confrontano con l'insieme di confine.

d) Se più di un partecipante alla sessione invia messaggi TMMBR contemporaneamente e con gli stessi valori dei componenti della tupla, non importa quale di quelle tuple sia presa nell'insieme di confine. Il partecipante perdente determinerà, dopo aver applicato l'algoritmo, che la sua tupla non entra nell'insieme di confine, e quindi smetterà di inviare il suo TMMBR.

È importante considerare i rischi di sicurezza legati a TMMBR falsi. Vedere le considerazioni sulla sicurezza nella sezione 6.

Come già indicato, i messaggi di feedback possono essere usati sia in sessioni multicast che unicast in una qualsiasi delle topologie specificate. Tuttavia, per sessioni con un gran numero di partecipanti, usare il minimo comune denominatore, come richiesto da questo meccanismo, potrebbe non essere la linea d'azione più adatta. Le sessioni di grandi dimensioni potrebbero dover considerare altri modi per adattare il bit rate alle capacità dei partecipanti, come partizionare la sessione in diversi livelli di qualità o usare qualche altro metodo per ottenere scalabilità del bit rate.

4.2.1.3. Regole di temporizzazione​

La prima trasmissione del messaggio TMMBR MAY usare feedback anticipato o immediato nei casi in cui la tempestività è desiderabile. Qualsiasi ripetizione di un messaggio di richiesta SHOULD usare la modalità RTCP regolare per la sua temporizzazione di trasmissione.

4.2.1.4. Gestione in traduttori e mixer​

I traduttori e mixer media dovranno ricevere e rispondere ai messaggi TMMBR poiché fanno parte della catena che fornisce un certo flusso media al ricevitore. Il mixer o traduttore può agire localmente sul TMMBR e quindi generare un TMMBN per indicare di averlo fatto. In alternativa, nel caso di un traduttore media può inoltrare la richiesta, o nel caso di un mixer generarne una propria e passarla avanti. In quest'ultimo caso, il mixer dovrà inviare un TMMBN indietro al richiedente originale per indicare che sta gestendo la richiesta.

4.2.2. Temporary Maximum Media Stream Bit Rate Notification (TMMBN)​

Temporary Maximum Media Stream Bit Rate Notification è identificata dal valore di tipo di pacchetto RTCP PT=RTPFB e FMT=4.

Il campo FCI del messaggio di feedback TMMBN può contenere zero, una o più voci FCI TMMBN.

4.2.2.1. Formato del messaggio​

La Feedback Control Information (FCI) consiste in zero, una o più voci FCI TMMBN con la sintassi seguente:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 - Syntax of an FCI Entry in the TMMBN Message

  • SSRC (32 bit): Il valore SSRC del "proprietario" di questa tupla.

  • MxTBR Exp (6 bit): La scala esponenziale della mantissa per il valore del bit rate media totale massimo. Il valore è un intero senza segno [0..63].

  • MxTBR Mantissa (17 bit): La mantissa del valore del bit rate media totale massimo come intero senza segno.

  • Measured Overhead (9 bit): Il valore medio misurato dell'overhead del pacchetto in byte rappresentato come intero senza segno [0..511].

Pertanto, la FCI all'interno del messaggio TMMBN contiene voci che indicano le tuple di confine. Per ciascuna tupla, la voce fornisce il proprietario tramite SSRC, seguito dal bit rate media totale massimo applicabile e dal valore di overhead.

La lunghezza del messaggio TMMBN SHALL essere impostata a 2+2*N dove N è il numero di voci FCI TMMBN.

4.2.2.2. Semantica​

Questo messaggio di feedback è usato per notificare ai mittenti di qualsiasi messaggio TMMBR che uno o più messaggi TMMBR sono stati ricevuti o che un proprietario ha lasciato la sessione. Indica a tutti i partecipanti l'insieme corrente di tuple di confine e i "proprietari" di quelle tuple.

Nell'intestazione comune del pacchetto per i messaggi di feedback (come definita nella sezione 6.1 di [RFC4585]), il campo "SSRC of packet sender" indica la sorgente della notifica. "SSRC of media source" non è usato e SHALL essere impostato a 0.

Un messaggio TMMBN SHALL essere programmato per la trasmissione dopo la ricezione di un messaggio TMMBR con una voce FCI che identifica questo mittente media. Solo un singolo TMMBN SHALL essere inviato, anche se più di un messaggio TMMBR è ricevuto tra la programmazione della trasmissione e la trasmissione effettiva del messaggio TMMBN. Il messaggio TMMBN indica le tuple di confine e i loro proprietari al momento della trasmissione del messaggio. Le tuple di confine incluse SHALL essere l'insieme ottenuto tramite applicazione dell'algoritmo applicabile della sezione 3.5.4.2 o un equivalente, applicato all'insieme di confine precedente, se presente, e alle tuple ricevute in messaggi TMMBR dall'ultima trasmissione di TMMBN.

La ricezione di un messaggio TMMBR SHALL comunque comportare la trasmissione di un messaggio TMMBN anche se, dopo applicazione dell'algoritmo, la tupla TMMBR appena riportata non è accettata nell'insieme di confine. In tal caso, le tuple di confine e i loro proprietari non sono cambiati, a meno che il TMMBR non provenisse da un proprietario di una tupla nell'insieme di confine precedentemente calcolato. Questa procedura consente ai partecipanti alla sessione che non hanno visto l'ultimo messaggio TMMBN di ottenere una vista corretta dello stato di questo mittente media.

Come indicato nella sezione 4.2.1.2, quando un mittente media determina che un "proprietario" di una tupla di confine ha lasciato la sessione, allora quella tupla è rimossa dall'insieme di confine, e il mittente media SHALL inviare un messaggio TMMBN che indica le tuple di confine rimanenti. Se non vi sono tuple di confine rimanenti, SHALL essere inviato un TMMBN senza alcuna FCI per indicarlo. Senza una tupla di confine rimanente, si applicano il bit rate media massimo e il packet rate massimo negoziati nella segnalazione di sessione, se presenti.

Nota: se restano ricevitori media nella sessione, quest'ultima sarà una situazione temporanea. Il TMMBN vuoto farà sì che ogni ricevitore media rimanente determini che la sua limitazione appartiene all'insieme di confine e invii di conseguenza un TMMBR.

In scenari unicast (cioè dove un singolo mittente parla con un singolo ricevitore), l'algoritmo sopra citato per determinare la proprietà degenera nel ricevitore media che diventa "proprietario" dell'unica tupla di confine non appena il ricevitore media ha emesso il primo messaggio TMMBR.

4.2.2.3. Regole di temporizzazione​

L'acknowledgement TMMBN SHOULD essere inviato non appena consentito dalle regole di temporizzazione applicate per la sessione. Per questi messaggi SHOULD essere usata la modalità di feedback immediato o anticipato.

4.2.2.4. Gestione da traduttori e mixer​

Come discusso nella sezione 4.2.1.4, mixer o traduttori potrebbero dover emettere messaggi TMMBN come risposte ai messaggi TMMBR per SSRC gestiti da essi.

4.3. Messaggi di feedback specifici del payload​

Come specificato dalla sezione 6.1 di RFC 4585 [RFC4585], i messaggi Payload-Specific FB sono identificati dal valore di tipo di pacchetto RTCP PSFB (206). AVPF [RFC4585] definisce tre messaggi di feedback specifici del payload e un messaggio di feedback a livello applicazione. Questo memo ne specifica quattro aggiuntivi. Tutti sono identificati mediante il parametro FMT come segue:

Assegnato in [RFC4585]:

  • 1: Picture Loss Indication (PLI)
  • 2: Slice Lost Indication (SLI)
  • 3: Reference Picture Selection Indication (RPSI)
  • 15: messaggio FB a livello applicazione
  • 31: riservato per futura espansione dello spazio numerico

Assegnato in questo memo:

  • 4: Full Intra Request (FIR) Command
  • 5: Temporal-Spatial Trade-off Request (TSTR)
  • 6: Temporal-Spatial Trade-off Notification (TSTN)
  • 7: Video Back Channel Message (VBCM)

Non assegnato:

  • 0: non assegnato
  • 8-14: non assegnato
  • 16-30: non assegnato

Le sottosezioni seguenti definiscono i nuovi formati FCI per i messaggi di feedback specifici del payload.

4.3.1. Full Intra Request (FIR)​

Il messaggio FIR è identificato dal valore di tipo di pacchetto RTCP PT=PSFB e FMT=4.

Il campo FCI MUST contenere una o più voci FIR. Ciascuna voce si applica a un diverso mittente media, identificato dal suo SSRC.

4.3.1.1. Formato del messaggio​

La Feedback Control Information (FCI) per Full Intra Request consiste in una o più voci FCI, il cui contenuto è rappresentato in Figure 4. La lunghezza del messaggio di feedback FIR MUST essere impostata a 2+2*N, dove N è il numero di voci FCI.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |    Reserved                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4 - Syntax of an FCI Entry in the FIR Message

  • SSRC (32 bit): Il valore SSRC del mittente media al quale si richiede di inviare un decoder refresh point.

  • Seq nr. (8 bit): Numero di sequenza del comando. Lo spazio dei numeri di sequenza è unico per ciascuna coppia di SSRC della sorgente del comando e SSRC del bersaglio del comando. Il numero di sequenza SHALL essere incrementato di 1 modulo 256 per ogni nuovo comando. Una ripetizione SHALL NOT incrementare il numero di sequenza. Il valore iniziale è arbitrario.

  • Reserved (24 bit): Tutti i bit SHALL essere impostati a 0 dal mittente e SHALL essere ignorati alla ricezione.

La semantica di questo messaggio di feedback è indipendente dal tipo di payload RTP.

4.3.1.2. Semantica​

Nell'intestazione comune del pacchetto per i messaggi di feedback (come definita nella sezione 6.1 di [RFC4585]), il campo "SSRC of packet sender" indica la sorgente della richiesta, e "SSRC of media source" non è usato e SHALL essere impostato a 0. Gli SSRC dei mittenti media a cui si applica il comando FIR sono nelle corrispondenti voci FCI. Un messaggio FIR MAY contenere richieste a più mittenti media, usando una voce FCI per ogni mittente media bersaglio.

Alla ricezione di FIR, l'encoder MUST inviare un decoder refresh point (vedere sezione 2.2) il prima possibile.

Il mittente MUST considerare il controllo della congestione come delineato nella sezione 5, che MAY limitare la sua capacità di inviare rapidamente un decoder refresh point.

FIR SHALL NOT essere inviato come reazione a perdite di immagine -- è RECOMMENDED usare PLI [RFC4585] invece. FIR SHOULD essere usato solo in situazioni in cui non inviare un decoder refresh point renderebbe il video inutilizzabile per gli utenti.

Un esempio tipico in cui inviare FIR è appropriato è quando, in una conferenza multipunto, un nuovo utente si unisce alla sessione e non è stabilito un intervallo regolare di decoder refresh point. Un altro esempio sarebbe un MCU di commutazione video che cambia flussi. Qui, normalmente, l'MCU emette un FIR al nuovo mittente per forzarlo a emettere un decoder refresh point. Il decoder refresh point include normalmente un Freeze Picture Release (definito fuori da questa specifica), che riavvia il processo di rendering dei ricevitori. Entrambe le tecniche menzionate sono comunemente usate in conferenze multipunto basate su MCU.

Altre specifiche di payload RTP come RFC 2032 [RFC2032] definiscono già un meccanismo di feedback per certi codec. Un'applicazione che supporta entrambi gli schemi MUST usare il meccanismo di feedback definito in questa specifica quando invia feedback. Per ragioni di retrocompatibilità, tale applicazione SHOULD anche essere capace di ricevere e reagire allo schema di feedback definito nel rispettivo formato di payload RTP, se richiesto da quel formato di payload.

4.3.1.3. Regole di temporizzazione​

La temporizzazione segue le regole delineate nella sezione 3 di [RFC4585]. I comandi FIR MAY essere usati con feedback anticipato o immediato. Il messaggio di feedback FIR MAY essere ripetuto. Se si usa la modalità di feedback immediato, la ripetizione SHOULD attendere almeno un RTT prima di essere inviata. In modalità RTCP anticipata o regolare, la ripetizione è inviata nel prossimo pacchetto RTCP regolare.

4.3.1.4. Gestione del messaggio FIR in mixer e traduttori​

Un traduttore media o un mixer che esegue la codifica media del contenuto per il quale il partecipante alla sessione ha emesso un FIR è responsabile di agire di conseguenza. Un mixer che agisce su un FIR SHOULD NOT inoltrare il messaggio inalterato; invece, SHOULD emettere un FIR esso stesso.

4.3.1.5. Osservazioni​

Attualmente, il video sembra essere l'unica applicazione utile per FIR, poiché sembra essere l'unico payload RTP ampiamente distribuito che si affida fortemente alla predizione media attraverso i confini dei pacchetti RTP. Tuttavia, l'uso di FIR potrebbe ragionevolmente essere previsto anche per altri tipi media che condividono proprietà essenziali con il video compresso, cioè predizione cross-frame (qualunque cosa sia un frame per quel tipo media). Un possibile esempio possono essere gli aggiornamenti dinamici delle descrizioni di scena MPEG-4. Si suggerisce che i formati di payload per tali tipi media facciano riferimento a FIR e ad altri tipi di messaggio definiti in questa specifica e in AVPF [RFC4585], invece di creare meccanismi simili nelle specifiche di payload. Le specifiche di payload potrebbero dover spiegare come le terminologie specifiche del payload si mappano alla terminologia centrata sul video usata qui.

In congiunzione con codec video, i messaggi FIR tipicamente attivano l'invio di immagini intra complete o IDR. Entrambe sono diverse volte più grandi delle immagini predette (inter). La loro dimensione è indipendente dal momento in cui sono generate. Nella maggior parte degli ambienti, specialmente con collegamenti a banda limitata, l'uso di un'immagine intra implica un ritardo consentito che è un multiplo significativo della tipica durata del frame. Un esempio: se il frame rate di invio è 10 fps, e si assume che un'immagine intra sia 10 volte più grande di un'immagine inter, allora deve essere accettato un intero secondo di latenza. In tale ambiente, non c'è bisogno di un ritardo particolarmente breve nell'invio del messaggio FIR. Quindi, attendere la prossima finestra temporale consentita dalle regole di temporizzazione RTCP secondo [RFC4585] non dovrebbe avere un impatto eccessivamente negativo sulle prestazioni del sistema.

Imporre un ritardo massimo per completare l'invio di un decoder refresh point sarebbe desiderabile da un punto di vista applicativo, ma è problematico dal punto di vista del controllo della congestione. "Il prima possibile" come menzionato sopra sembra essere un compromesso ragionevole.

In ambienti in cui il mittente non ha controllo sul codec (ad es. quando si trasmette in streaming contenuto preregistrato e precodificato), la reazione a questo comando non può essere specificata. Una reazione adatta del mittente sarebbe saltare avanti nel bit stream video al prossimo decoder refresh point. In altri scenari, può essere preferibile non reagire affatto al comando, ad es. quando si trasmette in streaming a un grande gruppo multicast. Altre reazioni sono anche possibili. Nel decidere una strategia, un mittente potrebbe tenere conto di fattori come la dimensione del gruppo ricevente, l'"importanza" del mittente del messaggio FIR (come "importanza" possa essere definita in questa specifica applicazione), la frequenza dei decoder refresh point nel contenuto, e così via. Tuttavia, non ci si aspetta che una sessione che gestisce prevalentemente contenuto precodificato usi affatto FIR.

Il rapporto tra Picture Loss Indication e FIR è il seguente. Come discusso nella sezione 6.3.1 di AVPF [RFC4585], una Picture Loss Indication informa il decoder sulla perdita di un'immagine e quindi sulla probabilità di disallineamento delle immagini di riferimento tra encoder e decoder. Tale scenario è normalmente correlato a perdite in una connessione in corso. In scenari punto-punto, e senza la presenza di strumenti avanzati di resilienza agli errori, un'opzione possibile per un encoder consiste nell'inviare un decoder refresh point. Tuttavia, ci sono altre opzioni. Un esempio è che il mittente media ignora il PLI, perché la ridondanza incorporata nel flusso probabilmente ripulisce l'immagine riprodotta entro un tempo ragionevole. Il FIR, al contrario, non lascia a un encoder (in tempo reale) altra scelta che inviare un decoder refresh point. Non consente all'encoder di tenere conto di considerazioni come quelle menzionate sopra.

4.3.2. Temporal-Spatial Trade-off Request (TSTR)​

Il messaggio di feedback TSTR è identificato dal valore di tipo di pacchetto RTCP PT=PSFB e FMT=5.

Il campo FCI MUST contenere una o più voci FCI TSTR.

4.3.2.1. Formato del messaggio​

Il contenuto della voce FCI per Temporal-Spatial Trade-off Request è rappresentato in Figure 5. La lunghezza del messaggio di feedback MUST essere impostata a 2+2*N, dove N è il numero di voci FCI incluse.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5 - Syntax of an FCI Entry in the TSTR Message

  • SSRC (32 bit): Lo SSRC del mittente media al quale si richiede di applicare il valore di trade-off indicato in Index.

  • Seq nr. (8 bit): Numero di sequenza della richiesta. Lo spazio dei numeri di sequenza è unico per la coppia di SSRC della sorgente della richiesta e SSRC del bersaglio della richiesta. Il numero di sequenza SHALL essere incrementato di 1 modulo 256 per ogni nuovo comando. Una ripetizione SHALL NOT incrementare il numero di sequenza. Il valore iniziale è arbitrario.

  • Reserved (19 bit): Tutti i bit SHALL essere impostati a 0 dal mittente e SHALL essere ignorati alla ricezione.

  • Index (5 bit): Un valore intero tra 0 e 31 che indica il trade-off relativo richiesto. Un valore di indice 0 indica la massima qualità spaziale possibile, mentre 31 indica la massima risoluzione temporale possibile.

4.3.2.2. Semantica​

Un decoder può suggerire un livello di trade-off temporale-spaziale inviando un messaggio TSTR a un encoder. Se l'encoder è capace di regolare il suo trade-off temporale-spaziale, SHOULD tenere conto del messaggio TSTR ricevuto per la futura codifica delle immagini. Un valore 0 suggerisce alta qualità spaziale e un valore 31 suggerisce un alto frame rate. La progressione dei valori da 0 a 31 indica monotonicamente un desiderio di frame rate più elevato. I valori di indice non corrispondono a valori precisi di qualità spaziale o frame rate.

La reazione alla ricezione di più di un messaggio TSTR da un mittente media da diversi ricevitori media è lasciata all'implementazione. Il trade-off selezionato SHALL essere comunicato ai ricevitori media mediante il messaggio TSTN.

Nell'intestazione comune del pacchetto per i messaggi di feedback (come definita nella sezione 6.1 di [RFC4585]), il campo "SSRC of packet sender" indica la sorgente della richiesta, e "SSRC of media source" non è usato e SHALL essere impostato a 0. Gli SSRC dei mittenti media a cui si applica TSTR sono nelle corrispondenti voci FCI.

Un messaggio TSTR MAY contenere richieste a più mittenti media, usando una voce FCI per ogni mittente media bersaglio.

4.3.2.3. Regole di temporizzazione​

La temporizzazione segue le regole delineate nella sezione 3 di [RFC4585]. Questo messaggio di richiesta non è critico nel tempo e SHOULD essere inviato usando la temporizzazione RTCP regolare. Solo se è noto che l'interfaccia utente richiede feedback rapido, il messaggio MAY essere inviato con temporizzazione di feedback anticipata o immediata.

4.3.2.4. Gestione del messaggio in mixer e traduttori​

Un mixer o traduttore media che codifica il contenuto inviato al partecipante alla sessione che ha emesso TSTR SHALL considerare la richiesta per determinare se può soddisfarla cambiando i propri parametri di codifica. Un traduttore media incapace di soddisfare la richiesta MAY inoltrare la richiesta inalterata verso il mittente media. Un mixer che codifica per più partecipanti alla sessione dovrà considerare le esigenze congiunte di questi partecipanti prima di generare un TSTR per proprio conto verso il mittente media. Vedere anche la discussione nella sezione 3.5.2.

4.3.2.5. Osservazioni​

Il termine "qualità spaziale" non si riferisce necessariamente alla risoluzione misurata dal numero di pixel che il video ricostruito sta usando. Infatti, nella maggior parte degli scenari la risoluzione video resta costante durante la durata della sessione. Tuttavia, tutti gli standard di compressione video hanno mezzi per regolare la qualità spaziale a una data risoluzione, spesso influenzati dal Quantizer Parameter o QP. Un QP numericamente basso produce una buona qualità dell'immagine ricostruita, mentre un QP numericamente alto produce un'immagine grossolana. La tipica reazione di un encoder a questa richiesta è cambiare i parametri del rate control per usare un frame rate più basso e un QP numericamente più basso (in media), o viceversa. La mappatura precisa del valore Index a frame rate e QP è intenzionalmente lasciata aperta qui, poiché dipende da fattori come lo standard di compressione impiegato, risoluzione spaziale, contenuto, bit rate, e così via.

4.3.3. Temporal-Spatial Trade-off Notification (TSTN)​

Il messaggio TSTN è identificato dal valore di tipo di pacchetto RTCP PT=PSFB e FMT=6.

Il campo FCI SHALL contenere una o più voci FCI TSTN.

4.3.3.1. Formato del messaggio​

Il contenuto di una voce FCI per Temporal-Spatial Trade-off Notification è rappresentato in Figure 6. La lunghezza del messaggio TSTN MUST essere impostata a 2+2*N, dove N è il numero di voci FCI.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6 - Syntax of the TSTN

  • SSRC (32 bit): Lo SSRC della sorgente del TSTR che ha portato a questa Notification.

  • Seq nr. (8 bit): Il valore del numero di sequenza del TSTR a cui si risponde.

  • Reserved (19 bit): Tutti i bit SHALL essere impostati a 0 dal mittente e SHALL essere ignorati alla ricezione.

  • Index (5 bit): Il valore di trade-off che il mittente media userà d'ora in poi.

Nota informativa: Il valore di trade-off restituito (Index) può differire da quello richiesto, ad esempio nei casi in cui un encoder media non possa regolare il suo trade-off, o quando si usa contenuto preregistrato.

4.3.3.2. Semantica​

Questo messaggio di feedback è usato per confermare la ricezione di un TSTR. Per ogni TSTR ricevuto rivolto al partecipante alla sessione, SHALL essere inviata una voce FCI TSTN in un messaggio di feedback TSTN. Un singolo messaggio TSTN MAY confermare più richieste usando più voci FCI. Il valore di indice incluso SHALL essere lo stesso in tutte le voci FCI del messaggio TSTN. Includere una FCI per ciascun richiedente consente a ciascuna entità richiedente di determinare che il mittente media ha ricevuto la richiesta. La Notification SHALL essere inviata anche in risposta a ripetizioni TSTR ricevute. Se il ricevitore della richiesta ha ricevuto TSTR con diversi numeri di sequenza da un singolo richiedente, SHALL rispondere solo alla richiesta con il numero di sequenza più alto (modulo 256). Notare che il numero di sequenza più alto può essere un valore intero più piccolo a causa del wrapping del campo. L'Appendice A.1 di [RFC3550] ha un algoritmo per tenere traccia del numero di sequenza più alto ricevuto per i pacchetti RTP; potrebbe essere adattato per questo uso.

Il TSTN SHALL includere l'indice Temporal-Spatial Trade-off che sarà usato come risultato della richiesta. Non è necessariamente lo stesso indice richiesto, poiché il mittente media potrebbe dover aggregare richieste da diversi partecipanti alla sessione richiedenti. Può anche avere altre policy o regole che limitano la selezione.

Nell'intestazione comune del pacchetto per i messaggi di feedback (come definita nella sezione 6.1 di [RFC4585]), il campo "SSRC of packet sender" indica la sorgente della Notification, e "SSRC of media source" non è usato e SHALL essere impostato a 0. Gli SSRC delle entità richiedenti a cui si applica la Notification sono nelle corrispondenti voci FCI.

4.3.3.3. Regole di temporizzazione​

La temporizzazione segue le regole delineate nella sezione 3 di [RFC4585]. Questo messaggio di acknowledgement non è estremamente critico nel tempo e SHOULD essere inviato usando la temporizzazione RTCP regolare.

4.3.3.4. Gestione di TSTN in mixer e traduttori​

Un mixer o traduttore che agisce su un TSTR SHALL inviare anche il corrispondente TSTN. Nei casi in cui debba inoltrare un TSTR esso stesso, il messaggio di notifica MAY dover essere ritardato finché il TSTR non è stato risposto.

4.3.3.5. Osservazioni​

Nessuna.

4.3.4. H.271 Video Back Channel Message (VBCM)​

Il VBCM è identificato dal valore di tipo di pacchetto RTCP PT=PSFB e FMT=7.

Il campo FCI MUST contenere una o più voci FCI VBCM.

4.3.4.1. Formato del messaggio​

La sintassi di una voce FCI nell'indicazione VBCM è rappresentata in Figure 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |0| Payload Type| Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    VBCM Octet String....      |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7 - Syntax of an FCI Entry in the VBCM

  • SSRC (32 bit): Il valore SSRC del mittente media al quale si richiede di istruire il suo encoder a reagire al VBCM.

  • Seq nr. (8 bit): Numero di sequenza del comando. Lo spazio dei numeri di sequenza è unico per la coppia di SSRC della sorgente del comando e SSRC del bersaglio del comando. Il numero di sequenza SHALL essere incrementato di 1 modulo 256 per ogni nuovo comando. Una ripetizione SHALL NOT incrementare il numero di sequenza. Il valore iniziale è arbitrario.

  • 0: Deve essere impostato a 0 dal mittente e non dovrebbe essere attuato dal ricevitore del messaggio.

  • Payload Type (7 bit): Il tipo di payload RTP per il quale il bit stream VBCM deve essere interpretato.

  • Length (16 bit): La lunghezza della stringa di ottetti VBCM in ottetti esclusi eventuali ottetti di padding.

  • VBCM Octet String (lunghezza variabile): Questa è la stringa di ottetti generata dal decoder che trasporta un specifico sotto-messaggio di feedback.

  • Padding (lunghezza variabile): Bit impostati a 0 per completare un confine a 32 bit.

4.3.4.2. Semantica​

Il "payload" dell'indicazione VBCM trasporta diversi tipi di informazioni di feedback specifiche del codec. Il tipo di informazione di feedback può essere classificato come "status report" (come un'indicazione che un bit stream è stato ricevuto senza errori, o che un'immagine o blocco parziale o completo è stato perso) o "update requests" (come refresh completo del bit stream).

Nota: Ci sono possibili sovrapposizioni tra i sotto-messaggi VBCM e i messaggi di feedback CCM/AVPF, come FIR. Vedere la sezione 3.5.3 per ulteriore discussione.

I diversi tipi di sotto-messaggi di feedback trasportati nel VBCM sono indicati dal "payloadType" come definito in [H.271]. Questi tipi di sotto-messaggio sono riprodotti sotto per comodità. "payloadType", nella terminologia ITU-T Rec. H.271, si riferisce al sotto-tipo del messaggio H.271 e non deve essere confuso con un tipo di payload RTP.

Table 2: H.271 message types ("payloadTypes")

Tipo di payloadContenuto del messaggio
0Una o più immagini senza mismatch di errore del bit stream rilevato
1Una o più immagini interamente o parzialmente perse
2Un insieme di blocchi di un'immagine interamente o parzialmente persa
3CRC per un parameter set
4CRC per tutti i parameter set di un certo tipo
5Una richiesta "reset" che indica che il mittente dovrebbe refreshare completamente il bit stream video come se non fossero stati ricevuti dati di bit stream precedenti
> 5Riservato per uso futuro da ITU-T

La stringa di bit o il "payload" di un VBCM è di lunghezza variabile ed è autocontenuta e codificata in un formato binario a lunghezza variabile. Il mittente media deve necessariamente essere in grado di analizzare questo formato binario ottimizzato per usare i VBCM.

Ciascuno dei diversi tipi di sotto-messaggi (indicati da payloadType) può avere semantica diversa a seconda del codec usato.

Nell'intestazione comune del pacchetto per i messaggi di feedback (come definita nella sezione 6.1 di [RFC4585]), il campo "SSRC of packet sender" indica la sorgente della richiesta, e "SSRC of media source" non è usato e SHALL essere impostato a 0. Gli SSRC dei mittenti media a cui si applica VBCM sono nelle corrispondenti voci FCI. Il mittente del VBCM MAY inviare messaggi H.271 a più mittenti media e MAY inviare più di un messaggio H.271 allo stesso mittente media all'interno dello stesso VBCM.

4.3.4.3. Regole di temporizzazione​

La temporizzazione segue le regole delineate nella sezione 3 di [RFC4585]. I diversi tipi di sotto-messaggio possono avere proprietà diverse riguardo alla temporizzazione dei messaggi da usare. Se diversi tipi sono inclusi nello stesso pacchetto di feedback, allora si dovrebbero seguire i requisiti per il tipo di sotto-messaggio con i requisiti più stringenti.

4.3.4.4. Gestione del messaggio in mixer o traduttori​

La gestione di un VBCM in un mixer o traduttore dipende dal tipo di sotto-messaggio.

4.3.4.5. Osservazioni​

Vedere la sezione 3.5.3 per una discussione sull'uso dei messaggi H.271 e dei messaggi definiti in AVPF [RFC4585] e in questo memo con funzionalità simile.

Nota: C'è stata qualche discussione se il campo tipo di payload RTP in questo messaggio sia necessario. Sarà necessario se c'è potenzialmente più di un tipo di payload RTP capace di VBCM nella stessa sessione, e la semantica di un dato VBCM cambia tra i tipi di payload. Ad esempio, il meccanismo di identificazione dell'immagine nei messaggi di tipo H.271 0 è fondamentalmente diverso tra H.263 e H.264 (sebbene entrambi usino la stessa sintassi). Pertanto, il campo payload è giustificato qui. C'è stato un ulteriore commento che per TSTR e FIR tale necessità non esiste, perché la semantica di TSTR e FIR è sufficientemente lasca o generica da applicarsi a tutti i payload video attualmente esistenti/previsti.

Ultimo aggiornamento il