Esercitazione su QOS (Video Quality of Service)

Introduzione

Questo documento esamina il tema della qualità delle videochiamate e offre un'esercitazione sugli elementi da tenere a mente quando la qualità del servizio (QoS) è configurata su un CUBE (Cisco Unified Border Element) o su un gateway TDM (Time-Division Multiplexing).

Contributo di Baktha Muralidharan, Cisco TAC Engineer, a cura di Anoop Kumar.

Prerequisiti

Requisiti

Questo documento è particolarmente utile per i tecnici che hanno familiarità con il VoIP (Voice over IP), anche se altri possono trovarlo utile.

Componenti usati

Non è stato usato hardware o software specifico per scrivere questo documento.

Premesse

L'audio digitalizzato nella sua forma più semplice è un insieme di campioni audio, ognuno dei quali descrive la pressione sonora durante quel periodo.  L'audio di conversazione può essere acquisito e riprodotto con un elevato grado di precisione, con solo 8000 campioni al secondo[1].  Se la rete è in grado di trasportare i campioni senza eccessivi ritardi, jitter e perdite di pacchetti, l'audio può essere fedelmente riprodotto sull'altra estremità.

Al contrario, la presentazione, l'elaborazione e il trasporto dei video sono molto più complessi. Luminosità, contrasto, saturazione del colore, reattività (al movimento) e sincronizzazione labiale sono solo alcune delle caratteristiche che determinano la qualità del video. I campioni video in genere richiedono uno spazio maggiore. Non sorprende che il video imponga una domanda molto maggiore sulla larghezza di banda della rete, sulla rete di trasporto. La qualità audio è determinata da :Microfono Speaker nel codec cuffie - compressione trasporto la qualità della videochiamata è influenzata da: Dispositivo di visualizzazione della telecamera Codec video Compatibilità/Interoperabilità della rete di trasporto

Nota:  È importante capire che, a differenza dell'audio, la qualità del tuning è molto più elevata quando si tratta di endpoint video.

Obiettivo

QoS in generale è un argomento vasto e complesso che richiede una considerazione dei requisiti generali del traffico (piuttosto che solo del traffico di cui si desidera migliorare la qualità) e deve essere controllato su ogni componente di rete nel percorso del flusso multimediale. Raggiungere la qualità video in una videoconferenza è ancora più complesso in quanto, oltre ai componenti di rete, comporta anche l'esame della configurazione e della sintonizzazione degli endpoint. In generale, la qualità video implica quanto segue:

• Ottimizzazione degli endpoint: ottimizzazione della configurazione degli endpoint (ad esempio risoluzione, frame al secondo)
• Ottimizzazione del trasporto: ottimizzazione della rete per il trasporto del traffico video per SLA di rete.
• Considerazioni sull'interoperabilità: molto spesso le videochiamate coinvolgono endpoint con capacità diverse. La progettazione e la configurazione dei sistemi per massimizzare l'interoperabilità può avere un impatto sulla qualità video.

In questo documento, l'attenzione specifica sarà rivolta alle considerazioni QoS sul gateway IOS o sul CUBE quando si gestiscono le videochiamate.

La sintonizzazione sugli endpoint implica la regolazione di un set di parametri sugli endpoint video. Dipende naturalmente dal prodotto, ma ecco alcune "manopole" generali:

• Risoluzione (ad es. dimensioni dell'immagine)
• Frame rate (sensibilità/realtà del movimento)
• Etichettatura (cioè marcatura ToS)

La sintonizzazione della rete per il video in genere comporta le seguenti operazioni:

• Comprensione della composizione del traffico che scorre attraverso il CUBE, ad esempio il volume di picco [chiamata], ecc.
• Analisi della capacità dei collegamenti/pipe di rete
• Progettazione di policy QoS appropriate per garantire il rispetto degli SLA per ogni classe di traffico

L'interoperabilità entra in gioco quando sistemi eterogenei (videotelefonia e telepresenza) partecipano ad una conferenza telefonica. L'esperienza fornita da un TP e da un sistema di telefonia video è fondamentalmente diversa. L'interoperabilità tra di essi si ottiene generalmente collegandoli mediante un processo noto come cascading.

Elementi non coperti

Non si tratta di un documento di progettazione né di un documento QoS video completo. In particolare, il presente documento non tratta i seguenti argomenti:

• Segnalazione [protocolli] di videochiamate, oltre a quanto necessario per illustrare aspetti relativi al qos.
• Configurazione/configurazione degli endpoint video
• Revisione completa dei meccanismi QoS, tra cui Policing, Queuing, Shaping e Burst
• Revisione della configurazione QoS sugli switch di layer 2 o considerazioni sui limiti di attendibilità.

Caratteristiche del traffico di rete del video

Video, come l'audio, è in tempo reale.  Le trasmissioni audio sono a bit rate costante (CBR). Al contrario, il traffico video tende ad essere bursty e viene definito come variabile-bit-rate(VBR). Di conseguenza, il bit rate per la trasmissione video non sarà necessariamente costante, se si ha bisogno di mantenere una certa qualità[2].

Immagine 1

Inoltre, è necessario determinare l'ampiezza di banda e la frammentazione richieste per il video. La questione viene discussa più avanti in questo documento.

• Il traffico video è bursty.
• I pacchetti video possono essere molto grandi.
• L'audio è sempre CBR. Il video è in genere VBR. 

Perché i video esplodono?

La risposta sta nel modo in cui il video viene compresso. Ricordate che il video è una sequenza di immagini (fotogrammi) riprodotte per fornire un effetto di movimento visivo. Le tecniche di compressione utilizzate dai codec video utilizzano un approccio chiamato codifica Delta[3], che funziona memorizzando i valori dei byte come differenze (delta) tra i valori sequenziali (campioni) anziché i valori stessi. Di conseguenza, il video viene codificato (e trasmesso) come frame consecutivi che trasportano solo le "parti mobili" anziché i frame completi.

Probabilmente vi state chiedendo perché, l'audio cambia in modo incrementale? Beh, è vero, ma il "movimento" (o la dinamica) non ha un impatto sull'audio paragonabile a quello del video. I campioni audio a 8 bit non vengono compressi meglio se codificati con delta, come i campioni video (fotogrammi). La variazione relativa da campione (fotogramma a fotogramma) a campione è molto più piccola di quella nell'audio. A seconda della natura e del grado del movimento, i campioni video possono avere dimensioni molto diverse. L'immagine 2 illustra la compressione video

Immagine 2

Un I-frame è un'immagine intra-codificata, in effetti un'immagine completamente specificata, come un convenzionale file di immagine statica.

Un P-frame (immagine prevista) contiene solo le modifiche dell'immagine rispetto al frame precedente. Il codificatore non deve memorizzare i pixel di sfondo invariati nel fotogramma P, risparmiando così spazio. I P-frame sono anche noti come delta-frame.

Un fotogramma B (immagine bidirezionale) consente di risparmiare ancora più spazio utilizzando le differenze tra il fotogramma corrente e i fotogrammi precedenti e successivi per specificarne il contenuto.

Misurazione della qualità video

I dispositivi video Cisco non misurano né riferiscono la qualità video in quanto tale, quindi la qualità video viene percepita piuttosto che misurata. Ci sono algoritmi standardizzati che misurano la qualità tramite un MOS (Mean Opinion Score). Tuttavia, se i problemi relativi alla qualità audio sono un'indicazione, è più probabile che vengano aperti i casi TAC (Video Quality), in quanto gli utenti hanno percepito i problemi di qualità piuttosto che segnalarli tramite uno strumento.

Controlli agli endpoint

I fattori che influiscono sulla qualità video includono:

• codec video (MPEG4, H261, H263, H264 e H265)
• dimensioni (1/8° schermo, 1/4 schermo, schermo intero)
• frame rate (da 1 a 30 frame al secondo, 6 valori predefiniti)
• l'impostazione relativa alla qualità della compressione (bassa, media, alta)

In genere, quanto sopra descritto è selezionabile/controllabile a livello di endpoint.

Elementi visibili

Quilting, Combing & Banding vengono utilizzati per questi termini, parte della tassonomia di menomazione video. Per ulteriori informazioni sui problemi comuni relativi ai video, consultare il documento:

Rif.: 

http://www.estadistica.cl/public_disk/Programas/DeTodo/Manejo y pegado de subtitulos/VirtualDub-1.6.14/help/p-artifacts.html

  

SLA della rete di trasporto per la qualità video

SLA di rete consigliato per il video[4] è il seguente:

• Latenza ≤ 150-300 ms
• Jitter ≤ 10 ms-50 ms
• Perdita ≤ 0,5%

Tra l'altro, gli SLA di rete consigliati per il trasporto dell'audio sono:

• Latenza ≤ 150-300 ms
• Jitter ≤ 20 ms-50 ms
• Perdita ≤ 1%

Nota:  Chiaramente il video è più sensibile alla perdita di pacchetti che alla voce.  Questo si dovrebbe verificare quando si capisce che i fotogrammi intermedi richiedono informazioni dai fotogrammi precedenti, il che significa che la perdita di fotogrammi intermedi può avere conseguenze devastanti sul processo di ricostruzione dell'immagine video.

Controlli nella rete di trasporto

In genere, lo SLA per il trasporto video può essere fornito utilizzando criteri QoS molto simili a quelli utilizzati per il trasporto audio. Esistono tuttavia alcune differenze dovute alla natura del traffico video.

  

Nota:  Sebbene l'ambito di questo documento sia limitato al componente CUBE, tenere presente che QoS è un'operazione end-to-end.

Varietà video

Tutti i video sono uguali? Beh, non proprio. Le variazioni del video come mezzo includono:

• Videoconferenza/telefonia
• Interattivo in tempo reale
• Larghezza di banda relativamente ridotta. Fino a circa 1 Mbps
• TelePresence
• Interattivo in tempo reale
• Esperienza immersiva
• Richiede una larghezza di banda molto elevata
• Streaming
• In tempo reale, unidirezionale
• Può essere unicast o multicast
• Larghezza di banda elevata
• Sensibile al ritardo (la coda del video può richiedere diversi secondi)
• Ampiamente insensibile al jitter (a causa del buffering delle applicazioni)
• La perdita non dovrebbe essere superiore al 5%.
• La latenza non deve superare i 4-5 secondi (a seconda delle capacità di memorizzazione dell'applicazione video)
• Alcuni video (ad esempio l'intrattenimento) potrebbero essere presi in considerazione per il servizio Scavenger.

Nota:  Per motivi di brevità, le illustrazioni non sono fornite in modo esteso per ogni tipo di video sopra elencato.

Codec del traffico video

• • Il codec H.261 è stato originariamente progettato per la trasmissione su linee ISDN. Con l'uso del video bonding, i bit rate video sono multipli di 64 Kbit/s.
  • H.263 - Il codec viene utilizzato nelle videoconferenze basate su IP e nelle reti ISDN. H.263 richiede metà della larghezza di banda per ottenere la stessa qualità video di H.261. Di conseguenza, H.263 ha ampiamente sostituito H.261. H.263 è stato ottimizzato per un'ampia gamma di bit rate e non solo 64K bit/s come con H.261.
  • H.264/MPEG-4 - Cs è uno dei formati più utilizzati e utilizza metà o meno del bit rate di MPEG-2, H.263, o MPEG-4 parte 2.
  • H265 - Uno dei potenziali successori dell'H.264, ampiamente utilizzato, basato sull'estensione degli stessi concetti. Supporta risoluzioni fino a 8192×4320, incluso UHD 8K.

Nota:  Il video, come l'audio, viene trasportato nel Realtime Protocol (RTP)

Meccanismi QoS per video

In linea di principio, i meccanismi QoS utilizzati per fornire gli SLA per una rete di trasporto video sono perlopiù gli stessi utilizzati per l'audio. Ci sono tuttavia alcune differenze, soprattutto a causa della natura a scatti della trasmissione video e VBR.

Esistono due approcci alla QoS, ovvero Interated Services (intserv) e differenziated Services (diffserv).

Intserv può essere paragonato al funzionamento a livello di segnalazione e diffserv a livello di supporto. In altre parole, il modello interserv garantisce la qualità operando sul piano di controllo; diffserv mira a garantire la qualità operando a livello di data plane.

Nei dispositivi di rete dell'architettura IntServ le richieste di prenotazioni statiche della larghezza di banda e mantengono lo stato di tutti i flussi riservati durante l'esecuzione dei servizi di classificazione, contrassegno e accodamento di tali flussi; l'architettura IntServ funziona e si integra sia con il control plane che con il data plane, e come tale è stata abbandonata a causa di limitazioni di scalabilità intrinseche. Il protocollo utilizzato per effettuare le prenotazioni della larghezza di banda è RSVP (Resource Server Vation Protocol).

C'è anche il modello IntServ/DiffServ, che è una sorta di mix. Questo modello separa le operazioni del piano di controllo dalle operazioni del piano dati. il funzionamento della RSVP è limitato al solo controllo dell'ammissione; con meccanismi DiffServ che gestiscono le operazioni di classificazione, marcatura, applicazione di policy e programmazione. Il modello IntServ/DiffServ è quindi altamente scalabile e flessibile.

Nota:  Questo documento si concentra solo sull'approccio diffserv (viz-a-viz prioritization scheme, LLQ).

Garanzia larghezza di banda

La larghezza di banda è ovviamente il parametro qos più fondamentale.  Ciò dipende da diversi parametri, in particolare:

• Codec utilizzato
• Frequenza fotogrammi
• Dimensioni immagine
• Volume chiamata (picco e media)

Il vecchio trucco di mettere la larghezza di banda al centro del problema non è sempre la soluzione. Ciò è particolarmente vero per la qualità video. Ad esempio, con CUVA (Cisco Unified Video Advantage) non esiste alcun meccanismo di sincronizzazione tra i due dispositivi (telefono e PC) coinvolti. Pertanto, QoS deve essere configurato in modo da ridurre al minimo le vibrazioni, la latenza, i pacchetti frammentati e i pacchetti non ordinati.

Nota:  Interactive Video ha gli stessi requisiti di livello di servizio del VoIP perché una chiamata vocale è incorporata nel flusso video.Streaming Video ha requisiti molto più lenti, a causa dell'alta quantità di buffer che è stata integrata nelle applicazioni.

Infine è importante comprendere che, a differenza del VoIP, non esistono formule pulite per il calcolo della larghezza di banda incrementale richiesta. Questo accade perché le dimensioni dei pacchetti video e i frame rate variano notevolmente e dipendono dal grado di movimento delle immagini trasmesse. Più avanti verranno fornite ulteriori informazioni al riguardo.

Accodamento

LLQ (Low-Latency Queuing) è il criterio di accodamento preferito per l'audio VoIP. Considerati i rigorosi requisiti di ritardo/jitter sensibili di TP e la necessità di sincronizzare audio e video per CUVA, le code LLQ (priority) sono consigliate anche per tutto il traffico video. Notare che, per il video, la larghezza di banda con priorità è generalmente aumentata del 20% per tenere conto del sovraccarico.

Compressione header

Non consigliato per il video.

Frammentazione dei collegamenti e interfoliazione

LFI è un meccanismo popolare per garantire che l'instabilità non sfugga al controllo sui collegamenti lenti, dove i ritardi di serializzazione possono essere elevati.

Tuttavia, Interactive-Video non è consigliato per i collegamenti lenti. Infatti, i pacchetti LLQ a cui è assegnato il traffico video non sono soggetti a frammentazione. Ciò significa che i pacchetti video interattivi di grandi dimensioni (ad esempio i frame I full motion da 1500 byte) potrebbero causare ritardi di serializzazione per i pacchetti video interattivi più piccoli.

Prevenzione delle congestioni

Eliminazione selettiva basata su RTCP

Burst

Questo meccanismo QoS è importante per il traffico video che, come accennato in precedenza, è bursty.

Il parametro opzionale burst può essere configurato come parte del comando priority[6].

In H.264, lo burst peggiore sarebbe lo schermo intero di video (compressi nello spazio). In base a test approfonditi eseguiti sui sistemi TCP, questa dimensione è di 64 KB. Pertanto, il parametro LLQ burst deve essere configurato in modo da consentire fino a 64 KB di burst per frame per schermo. In questo modo il sistema CTS-1000 in esecuzione a 1080p-Best (con il supporto opzionale di un flusso video ausiliario[7]) sarebbe configurato con un LLQ con un parametro di burst ottimale di 128 (2x64) KB.

Quanta larghezza di banda?

Quanta larghezza di banda è necessaria per trasportare fedelmente una videochiamata? Prima di passare ai calcoli, è importante comprendere i seguenti concetti, che sono specifici dei video.

Risoluzione

Questo si riferisce fondamentalmente alle dimensioni dell'immagine.  Altri termini comunemente usati includono il formato video e le dimensioni dello schermo.  Di seguito sono riportati i formati video più comuni.

Formato	Risoluzione video (pixel)
SQCIF	128 x 96
QCIF	176 x 144
SCIF	256 x 192
SIF	352 x 240
CIF	352 x 288
DCIF	528 x 384
4CIF	704 x 576
16CIF	1.408 x 1.152

La maggior parte delle apparecchiature per videoconferenze funziona nei formati CIF o 4CIF.

Rif.: http://en.wikipedia.org/wiki/Common_Intermediate_Format

Nota:  Non esiste equivalenza per la risoluzione (video) nel mondo audio

Frequenza fotogrammi

Questo valore si riferisce alla frequenza con cui un dispositivo di acquisizione immagini produce immagini consecutive univoche denominate fotogrammi. La frequenza dei fotogrammi viene espressa in fotogrammi al secondo (fps).

Nota:  La metrica equivalente nel mondo audio è il tempo di campionamento. Ad esempio, 8000 per g.711ulaw.

Calcolo della larghezza di banda

Il calcolo della larghezza di banda per i sistemi di videotelefonia e per altri sistemi di videoconferenza tradizionali tende ad essere più semplice.

Ad esempio, si consideri una chiamata TCP con risoluzione di 1080 x1920.  La larghezza di banda richiesta viene calcolata nel modo seguente:

     2.073.600 pixel per frame

        x3 colori per pixel

        x1 Byte (8 bit) per colore

        x 30 frame al secondo

        = 1,5 Gb/s per schermo. Non compresso

Grazie alla compressione, una larghezza di banda di 4 Mbps per schermo (compressa > 99%) è sufficiente per trasportare il frame indicato!

Nella tabella seguente vengono elencate alcune delle combinazioni

Immagine formato	Luminanza pixel	Luminanza linee	Non compresso velocità in bit (Mbit/s)
			10 frame/s		30 frame/s
			Grigio	Colore	Grigio	Colore
SQCIF	128	96	1.0	1.5	3.0	4.4
QCIF	176	144	2.0	3.0	6.1	9.1
CIF	352	288	8.1	12.2	24.3	36.5
4CIF	704	576	32.4	48.7	97.3	146.0
16CIF	1408	1152	129.8	194.6	389.3	583.9

Si noti che i calcoli riportati sopra sono relativi a una schermata singola. Una chiamata TCP potrebbe interessare più schermate, quindi la larghezza di banda totale per la chiamata sarebbe un multiplo della larghezza di banda per schermo.

Fare riferimento a https://supportforums.cisco.com/thread/311604 per un buon calcolo della larghezza di banda per i sistemi Cisco TCP.

Classificazione/contrassegno del traffico video

Come viene identificato/distinto il traffico video? Un modo per classificare i pacchetti su CUBE è l'uso dei contrassegni DSCP.

Nella tabella seguente vengono illustrati i contrassegni DSCP per linea di base QoS Cisco e per RFC 4594.

Traffico	Livello 3 PHB	DSCP layer 3
Segnalazione chiamata	CS3	24
Voce	EF	46
Videoconferenza	AF41	34
TelePresence	CS4	32
Streaming multimediale	AF31	26
Trasmetti video	CS5	40

PHB - Comportamento per hop. Si riferisce alle attività del router per quanto riguarda la classificazione dei pacchetti e le funzioni di condizionamento del traffico, come la misurazione, la marcatura, il shaping e l'applicazione di policy.

Per impostazione predefinita, prima della versione 9.0 CUCM (Cisco Unified Call Manager) contrassegnava qualsiasi traffico video (incluso TelePresence) su AF41. A partire dalla versione 9.0, CUCM preconfigura i seguenti valori DSCP:

• Chiamate TelePresence (video immersivo) al CS4 e
• Videochiamate (videotelefonia IP) a AF41

Configurazione

La configurazione per l'ottimizzazione della qualità audio comporta il calcolo della larghezza di banda prioritaria e l'implementazione della policy LLQ su un collegamento WAN. Questo si basa generalmente sul volume delle chiamate previsto e sul codec audio utilizzato.

Anche se i principi sono gli stessi, la larghezza di banda video attraverso un CUBE non è così facilmente calcolabile. Ciò è dovuto a una serie di fattori, tra cui:

• Come si calcola la larghezza di banda totale richiesta in base alle diverse chiamate TCP (che passano attraverso il CUBE) che potrebbero richiedere un numero diverso di schermate e risoluzioni diverse?
• La natura a scatti e VBR
• Un'altra dimensione della complessità [nel calcolo della larghezza di banda] ha a che fare con le "chiamate di interoperabilità"?  Le chiamate di interoperabilità utilizzano TIP. TIP è l'acronimo di Telepresence Interoperability Protocol. TIP viene utilizzato per multiplex di schermi multipli, flussi audio multipli e una schermata di dati ausiliari in due flussi RTP, uno per video e audio. Permette di realizzare sessioni punto-punto e multipunto, oltre a una combinazione di endpoint multi-schermo e singolo schermo. TIP è un protocollo proprietario di Cisco. Il protocollo TIP si basa su RTCP.

Di conseguenza, il provisioning della larghezza di banda per i sistemi video talvolta avviene in ordine inverso, ovvero la quantità di larghezza di banda che una rete di trasporto può fornire, con la policy LLQ, viene determinata per prima e in base a ciò l'endpoint viene configurato. I sistemi video endpoint sono abbastanza intelligenti da regolare i vari parametri video per le dimensioni del tubo! Di conseguenza, gli endpoint segnalano la chiamata.

Gestione larghezza di banda CUBE

In che modo CUBE gestisce la larghezza di banda nelle sue offerte/risposte (SIP) quando segnala una videochiamata? CUBE popola i campi della larghezza di banda video in SDP nel modo seguente:

  1. Dall'attributo larghezza di banda nell'SDP in ingresso. In SDP esiste un attributo di larghezza di banda, che ha un modificatore usato per specificare il tipo di velocità in bit a cui il valore fa riferimento.  L'attributo ha il seguente formato: b=<modificatore>:<valore>

  2. Dalla larghezza di banda video configurata sul CUBE. Ad esempio, la larghezza di banda massima stimata viene calcolata in base alle funzionalità utilizzate dall'utente CTS e la larghezza di banda stimata è preconfigurata su CUBE, utilizzando la CLI-

• <modificatore di tag video larghezza di banda> o
• <modificatore larghezza di banda video>

  3. Larghezza di banda video predefinita (384 Kbps)

Il flusso di chiamata mostrato di seguito illustra come CUBE popola la larghezza di banda nei messaggi di segnalazione di chiamata:

In particolare, il CUBE utilizza la logica seguente:

• Nelle offerte (chiamate da fare), CUBE utilizza la larghezza di banda configurata.
• On (risponde alle richieste di EO), CUBE invia la larghezza di banda il cui valore è il minimo dell'offerta e della configurazione locale.

A livello di sessione SDP, il valore TIAS è la quantità massima di larghezza di banda necessaria quando vengono utilizzati tutti i flussi multimediali dichiarati[8].

Tipi di payload codec video

Questa è un'altra area in cui il video differisce dall'audio.  I codec audio utilizzano tipi di payload statici. I codec video, al contrario, usano tipi di payload RTP dinamici, che usano l'intervallo da 96 a 127.

Il motivo per l'uso del tipo di payload dinamico ha a che fare con l'ampia applicabilità dei codec video. I codec video dispongono di parametri che forniscono a un ricevitore le proprietà del flusso che verrà inviato. I tipi di payload video sono definiti in SDP, utilizzando il parametro a=rtpmap. È inoltre POSSIBILE utilizzare l'attributo "a=fmtp:" per specificare i parametri di formato. La stringa fmtp è opaca e viene passata sull'altro lato.

Di seguito è riportato un esempio-

m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

Si noti che i due endpoint coinvolti in una chiamata potrebbero utilizzare un tipo di payload diverso per lo stesso codec. CUBE risponde su entrambi i lati con una riga=rtpmap ricevuta sull'altro lato. Ciò significa che la configurazione "payload asimmetrico pieno" è necessaria per il funzionamento delle videochiamate.

Larghezza di banda L2

A differenza della voce, il traffico video IP in tempo reale è un flusso a bit rate variabile. Pertanto, a differenza della voce, il video non dispone di formule chiare per il calcolo dell'overhead della rete, in quanto le dimensioni e le frequenze dei pacchetti video variano proporzionalmente al grado di movimento all'interno dell'immagine video stessa. Dal punto di vista di un amministratore di rete, la larghezza di banda viene sempre predisposta al layer 2, ma la variabilità delle dimensioni dei pacchetti e la varietà dei supporti di layer 2 che i pacchetti possono attraversare da estremità a estremità rendono difficile calcolare la larghezza di banda effettiva da assegnare al layer 2. Tuttavia, la regola conservativa che è stata accuratamente testata e largamente utilizzata è quella di predisporre una larghezza di banda video superiore del 20%. In questo modo si evita lo burst del 10% e il sovraccarico di rete dal layer 2 al layer 4.

Monitoraggio/misurazione

Come accennato in precedenza, gli endpoint video non riportano un MOS in quanto tale. Tuttavia, i seguenti strumenti possono essere utilizzati per misurare/monitorare le prestazioni della rete di trasporto e per monitorare la qualità video.

Video sugli SLA IP

Una funzione integrata in IOS, gli SLA IP (Service Level Agreements) eseguono il monitoraggio attivo delle prestazioni della rete. Il funzionamento video degli SLA IP si differenzia dalle altre operazioni degli SLA IP in quanto tutto il traffico è unidirezionale, con un risponditore che deve elaborare i numeri di sequenza e i timestamp localmente e attendere una richiesta dall'origine prima di inviare i dati calcolati.

Al termine dell'operazione video corrente, l'origine invia una richiesta al responder. Questa richiesta segnala al responder che non arriveranno altri pacchetti e che la funzione di sink video può essere disattivata. Quando la risposta del risponditore arriva all'origine, le statistiche vengono lette dal messaggio e i campi rilevanti dell'operazione vengono aggiornati.

L'IPM (IOS Performance Monitor) di CiscoWorks utilizza il probe SLA IP e MediaTrace[9] per misurare le prestazioni del traffico degli utenti e i rapporti.

VQM CUBO

La funzione VQM (Video Quality Monitor), disponibile sul CUBE, è un ottimo strumento per monitorare la qualità video tra due punti di interesse. I risultati sono presentati come MOS.

Disponibile da IOS 15.2(1)T e versioni successive. VQM utilizza risorse DSP.

Riferimento

• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
• http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
• http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
• SRND per videofonia IP -
• http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
• http://www.encoding.com/do_you_have_any_information_on_h.264_levels
• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
• http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
• http://en.wikipedia.org/wiki/Video_compression_picture_types
• http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
• http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
• http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
• http://www.networkworld.com/news/tech/2002/0923tech.html
• http://www.javvin.com/protocolH263.html
• http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0

 StartSelection:0000000199 EndSelection:000000538