3. Motivazione

Questa sezione discute la motivazione e l'uso dei diversi messaggi di controllo video e media. I messaggi di controllo video sono stati a lungo oggetto di discussione, ed è stato redatto un documento di requisiti [Basso]. Tale documento è scaduto; tuttavia, citiamo sezioni pertinenti per fornire motivazione e requisiti.

3.1. Casi d'uso

Vi sono diverse possibili utilizzazioni per i messaggi di feedback proposti. Iniziamo esaminando i casi d'uso proposti da Basso et al. [Basso]. Alcuni casi d'uso sono stati riformulati e sono stati aggiunti commenti.

1. Un mixer video RTP compone più sorgenti video codificate in un unico flusso video codificato. Ogni volta che si aggiunge una sorgente video, il mixer RTP deve richiedere un decoder refresh point dalla sorgente video, per avviare una catena di predizione non corrotta sull'area spaziale dell'immagine mista occupata dai dati della nuova sorgente video.

2. Un mixer video RTP riceve più flussi video RTP codificati dai partecipanti alla conferenza e seleziona dinamicamente uno di essi da includere nel suo flusso RTP in uscita. Al momento di un cambio di bitstream (determinato con mezzi quali attivazione vocale o interfaccia utente), il mixer richiede un decoder refresh point dalla sorgente remota, per evitare di usare contenuto non correlato come dati di riferimento per la predizione inter-immagine. Dopo aver richiesto il decoder refresh point, il mixer video interrompe l'invio del flusso RTP corrente e monitora il flusso RTP dalla nuova sorgente fino a rilevare dati appartenenti al decoder refresh point. A quel punto, il mixer RTP inizia a inoltrare il flusso appena selezionato al ricevente o ai riceventi.

3. Un'applicazione deve segnalare all'encoder remoto che il compromesso desiderato tra risoluzione temporale e spaziale è cambiato. Ad esempio, un utente può preferire un frame rate più alto e una qualità spaziale inferiore, e un altro il contrario. Tale scelta dipende anche fortemente dal contenuto. Molti sistemi di videoconferenza attuali offrono nell'interfaccia utente un meccanismo per effettuare questa selezione, di solito sotto forma di slider. Il meccanismo è utile in uso punto-punto, multipunto centralizzato e multipunto non centralizzato.

4. Il caso d'uso 4 del documento Basso si applica solo a Picture Loss Indication (PLI) come definito in AVPF [RFC4585] e non è riprodotto qui.

5. Il caso d'uso 5 del documento Basso riguarda un meccanismo noto come "freeze picture request". L'invio di freeze picture request su un canale RTCP in avanti non affidabile è stato identificato come problematico. Pertanto, nessun freeze picture request è stato incluso in questo memo, e la discussione del caso d'uso non è riprodotta qui.

6. Un mixer video seleziona dinamicamente uno dei flussi video ricevuti da inviare ai partecipanti e cerca di fornire il bit rate più alto possibile a tutti i partecipanti, minimizzando il trans-rating del flusso. Un modo per ottenere ciò è impostare sessioni con endpoint usando il bit rate massimo accettato da ciascun endpoint e accettato dal metodo di call admission usato dal mixer. Mediante comandi che riducono il bit rate massimo del flusso media al di sotto di quanto negoziato durante l'impostazione della sessione, il mixer può ridurre il bit rate massimo inviato dagli endpoint al minimo tra tutti i bit rate accettati. Man mano che il bit rate accettato più basso cambia per endpoint che entrano o escono o per congestione di rete, il mixer può regolare i limiti entro cui gli endpoint possono inviare i loro flussi per allinearsi al nuovo valore. Il mixer richiede quindi un nuovo bit rate massimo, uguale o inferiore al bit rate massimo negoziato all'impostazione della sessione per un determinato flusso media, e l'endpoint remoto può rispondere con il bit rate effettivo che può supportare.

Il quadro che Basso et al. delineano copre la maggior parte delle applicazioni che prevediamo. Tuttavia, vorremmo estendere l'elenco con due casi d'uso aggiuntivi:

7. Gli algoritmi di congestion control attualmente dispiegati (AIMD e TCP Friendly Rate Control (TFRC) [RFC3448]) sondano capacità aggiuntiva disponibile finché c'è qualcosa da inviare. Con algoritmi che usano la perdita di pacchetti come indicazione di congestione, tale sondaggio in genere riduce la qualità media (spesso fino a rendere il media inutilizzabile), a causa della perdita di pacchetti e dell'aumento del ritardo.

   In diversi scenari di dispiegamento, in particolare cellulari, il collo di bottiglia è spesso l'ultimo hop. Tale link cellulare ha spesso anche qualche forma di negoziazione QoS che consente al dispositivo cellulare di conoscere il bit rate massimo disponibile su quell'ultimo hop. Un ricevente media dietro tale link può, nella maggior parte (se non tutti) dei casi, calcolare almeno un limite superiore per il bit rate disponibile per ciascun flusso media che attualmente riceve. Come ciò sia fatto è un dettaglio di implementazione e non è discusso qui. Indicare il bit rate massimo disponibile alla parte trasmittente per i vari flussi media può essere utile per impedire a tale parte di sondare banda per tale flusso oltre un limite rigido noto. Per dispositivi cellulari o altri mobili, il bit rate disponibile noto per ciascun flusso (dedotto dal bit rate del link) può cambiare rapidamente, a causa di handover verso un'altra tecnologia di trasmissione, rinegoziazione QoS per congestione, ecc. Per minimizzare l'interruzione del servizio, è necessaria una convergenza rapida, e quindi è desiderabile la segnalazione sul percorso media.

8. Di solito, in una sessione punto-punto, è responsabilità del mittente media configurare il flusso media per restare entro i limiti della banda disponibile sul percorso. Tuttavia, in alcuni scenari video punto-punto, è vantaggioso consentire al ricevente di restringere ulteriormente il bit rate massimo del media. Un esempio è il degrado della capacità di rendering del ricevente (ad esempio per scarsità di risorse CPU). In tal caso, il ricevente può voler segnalare al mittente di ridurre il bit rate del media a un livello gestibile. Un altro esempio è un ricevente che vuole registrare la sessione. In tal caso, il ricevente può voler limitare il rate del media per non superare velocità di scrittura affidabili sul dispositivo di storage.

3.2. Uso del percorso media

Per supportare i casi d'uso sopra, si può usare il canale di segnalazione (ad esempio SIP) e rinegoziare la definizione dei flussi media. Tuttavia, ciò ha diversi svantaggi.

In primo luogo, la rinegoziazione dei parametri via canale di segnalazione può essere lenta. In alcuni protocolli di controllo (come H.323), le fasi di smantellamento di un canale esistente e di creazione di uno nuovo sono distinte, e può verificarsi un "buco" nella riproduzione media.

In secondo luogo, il canale di controllo usa protocolli diversi (spesso TCP) rispetto al percorso media (spesso UDP/RTP). In molte topologie, il "percorso" del canale di segnalazione è distinto dal percorso dei media. Se è presente una middlebox come NAT-fw, il canale di controllo potrebbe non reagire ai cambiamenti delle caratteristiche del percorso media, o non essere nemmeno consapevole del percorso media.

In terzo luogo, usare il canale di segnalazione per rinegoziare i parametri media è spesso pesante.

Pertanto, è vantaggioso effettuare il controllo dei media sul percorso media, in modo leggero e quindi rapido.

3.3. Uso di AVPF

Per i messaggi di feedback usiamo il profilo AVPF [RFC4585]. (Vedere [RFC4585] per la motivazione dell'uso di RTCP per i messaggi di feedback.) AVPF fornisce tipi di pacchetto RTCP validi e modalità operative per trasmettere i messaggi di feedback.

3.3.1. Affidabilità

AVPF non fornisce affidabilità integrata. Pacchetti di acknowledgement, ritrasmissione e altri meccanismi di affidabilità sono difficili da implementare e usare con multicast.

Per i messaggi definiti in questo documento, abbiamo scelto una progettazione che si affida al mittente del messaggio di feedback per monitorare il flusso che riceve. Se il messaggio di feedback è andato perso, o il mittente media non vi ha ancora reagito, il mittente del messaggio di feedback (ad esempio il ricevente media) non vedrà la reazione attesa sotto forma di flusso RTP modificato. In tal caso, il mittente del messaggio di feedback dovrebbe reinviare il messaggio. L'intervallo per tali ritrasmissioni dovrebbe rispettare le regole di timing AVPF. Tuttavia, alcuni messaggi non richiedono affidabilità (notifiche), e per altri l'affidabilità è risolta ripetendo il messaggio.

3.4. Multicast

I messaggi di feedback definiti in questo documento sono principalmente destinati a scenari punto-punto e multipunto centralizzato. Tuttavia, il loro uso in scenari multicast non centralizzati non è proibito. Ma, usando i messaggi in tali scenari, i loro effetti devono essere ben compresi.

In multicast, il mittente media invia lo stesso bitstream a tutti i riceventi. Se un ricevente invia una richiesta di bit rate inferiore o per un intra picture, soddisfare tale richiesta influenza tutti gli altri riceventi nella sessione. Ciò può non essere desiderabile.

Inoltre, AVPF richiede che tutti i pacchetti RTCP in una sessione multicast siano inviati a tutti i partecipanti. Ciò significa che un messaggio di feedback inviato da un ricevente è visto da tutti gli altri riceventi. Ciò può causare un'alluvione di messaggi di feedback se molti riceventi inviano lo stesso messaggio contemporaneamente. Le regole di timing AVPF sono progettate per prevenire tali alluvioni, ma non sono perfette.

3.5. Messaggi di feedback

Questa sezione fornisce una descrizione ad alto livello dei messaggi di feedback definiti in questa specifica. La definizione formale dei messaggi è nella sezione 4.

3.5.1. Full Intra Request Command

Un comando Full Intra Request (FIR) indica al mittente media che deve inviare un decoder refresh point (per video, un'immagine Intra) il prima possibile. I casi d'uso 1 e 2 nella sezione 3.1 sono i principali motori di questo messaggio.

Il messaggio FIR è simile al messaggio Picture Loss Indication (PLI) definito in [RFC4585]. Tuttavia, c'è una sottile differenza. PLI è usato quando il ricevente ha perso alcuni dati e vuole ripristinare l'immagine. Il mittente può scegliere di inviare un'immagine Intra, o può usare altri mezzi per ripristinare l'immagine (ad esempio, se sa quali dati ha il ricevente, può inviare dati differenza). FIR, invece, è un comando che forza il mittente a inviare un decoder refresh point. Ciò è necessario quando il ricevente non ha alcuna immagine di riferimento valida, ad esempio quando si cambiano flussi in un mixer.

3.5.1.1. Affidabilità

Il messaggio FIR è un comando. Se va perso, il video resta corrotto (o vuoto). Pertanto, il mittente del messaggio FIR tipicamente ripete il messaggio finché non vede un decoder refresh point nel flusso ricevuto. Le regole di timing AVPF si applicano a tali ripetizioni.

3.5.2. Temporal-Spatial Trade-off Request and Notification

I messaggi Temporal-Spatial Trade-off Request (TSTR) e Notification (TSTN) consentono a un ricevente media di segnalare la propria preferenza per il compromesso tra risoluzione temporale (frame rate) e risoluzione spaziale (qualità immagine). Ciò affronta il caso d'uso 3.

Il compromesso è espresso come valore intero da 0 a 31, dove 0 rappresenta la qualità spaziale più alta (e potenzialmente il frame rate più basso) e 31 rappresenta il frame rate più alto (e potenzialmente la qualità spaziale più bassa).

Il messaggio TSTR è inviato da un ricevente per richiedere un compromesso specifico. Il messaggio TSTN è inviato dal mittente per notificare ai riceventi l'impostazione attuale del compromesso, o per confermare un TSTR.

3.5.2.1. Punto-punto

In uno scenario punto-punto, il ricevente invia un TSTR. Il mittente presumibilmente regola la codifica e invia un TSTN per confermare.

3.5.2.2. Punto-multipunto con multicast o translator

In tali scenari, più riceventi possono inviare messaggi TSTR conflittuali. Il mittente deve decidere come reagire. Potrebbe, ad esempio, onorare la richiesta per il frame rate più alto, o la qualità spaziale più alta, o una media. Il mittente invia quindi un TSTN per informare tutti i riceventi dell'impostazione effettiva.

3.5.2.3. Punto-multipunto con RTP Mixer

Un mixer può gestire messaggi TSTR da più riceventi e potenzialmente generare flussi diversi per riceventi diversi, o aggregare le richieste e inviare un singolo TSTR al mittente originale.

3.5.2.4. Affidabilità

TSTR e TSTN sono richieste e notifiche. Se un TSTR va perso, il mittente non cambierà il compromesso. Il ricevente può rilevarlo (non ricevendo TSTN o vedendo un cambio nel flusso) e reinviare il TSTR.

3.5.3. H.271 Video Back Channel Message

Questo messaggio consente di trasportare messaggi ITU-T H.271 video back channel in RTCP. Ciò è utile per codec video consolidati che usano H.271 per il feedback.

3.5.3.1. Affidabilità

L'affidabilità per VBCM dipende dall'applicazione. Alcuni messaggi H.271 possono richiedere affidabilità, altri no. Il meccanismo descritto in questo documento non fornisce affidabilità a livello RTCP; spetta all'applicazione gestire le ritrasmissioni se necessario.

3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification

I messaggi Temporary Maximum Media Stream Bit Rate Request (TMMBR, pronunciato "timber") e Notification (TMMBN, pronunciato "tim-ben") sono usati per controllare il bit rate del flusso media. Ciò affronta i casi d'uso 6, 7 e 8.

TMMBR è una richiesta da un ricevente a un mittente di limitare il bit rate del flusso media a un certo valore. TMMBN è una notifica dal mittente al ricevente o ai riceventi che indica il bit rate massimo che il mittente sta attualmente rispettando.

3.5.4.1. Comportamento per riceventi media che usano TMMBR

Un ricevente stima il bit rate massimo che può gestire (ad esempio in base alla capacità del link) e invia un messaggio TMMBR contenente tale valore.

3.5.4.2. Algoritmo per stabilire le limitazioni attuali

Un mittente può ricevere messaggi TMMBR da più riceventi. Deve calcolare il "bounding set" di tali richieste. In sostanza, deve trovare il bit rate minimo richiesto tra tutti i riceventi (o almeno l'insieme di riceventi a cui tiene) e limitare il proprio tasso di invio a tale valore. L'algoritmo descrive come mantenere lo stato dei messaggi TMMBR ricevuti e calcolare il limite attuale.

3.5.4.3. Uso di TMMBR in operazione multipunto basata su mixer

Un mixer agisce come ricevente per gli endpoint che gli inviano, e come mittente per gli endpoint che ricevono da lui. Può usare TMMBR per limitare il tasso dei flussi in ingresso, e deve rispettare i messaggi TMMBR ricevuti dagli endpoint a cui invia.

3.5.4.4. Uso di TMMBR in punto-multipunto con multicast o translator

In multicast, il mittente deve rispettare il bit rate richiesto più basso dal gruppo di riceventi (o usare un'altra policy).

3.5.4.5. Uso di TMMBR in operazione punto-punto

Caso semplice: il ricevente richiede un limite, il mittente lo rispetta.

3.5.4.6. Affidabilità

TMMBR è una richiesta. TMMBN è una notifica che funge da acknowledgement. Se un ricevente invia TMMBR e non riceve una TMMBN corrispondente (o non vede una riduzione del rate), reinvia il TMMBR.