Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Obiettivo

Elementi non coperti

Caratteristiche del traffico di rete del video

Misurazione della qualità video

Controlli agli endpoint

Elementi visibili

SLA della rete di trasporto per la qualità video

Controlli nella rete di trasporto

Varietà video

Codec del traffico video

Meccanismi QoS per video

Garanzia larghezza di banda

Accodamento

Compressione header

Frammentazione dei collegamenti e interfoliazione

Prevenzione delle congestioni

Burst

Quanta larghezza di banda?

Risoluzione

Frequenza fotogrammi

Calcolo della larghezza di banda

Classificazione/contrassegno del traffico video

Configurazione

Gestione larghezza di banda CUBE

Tipi di payload codec video

Monitoraggio/misurazione

Video sugli SLA IP

VQM CUBO

Riferimento

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

[1] Basato sulla massima frequenza audio udibile dall'uomo di circa 4000 Hz. Rif.: Teorema di Nyquist.

[2] Con il video è possibile realizzare schemi di trasmissione CBR (Constant Bit Rate), ma questi compromettono la qualità per mantenere la CBR.

[3] Per la compressione inter-frame

[4] Si noti che il contratto di servizio è più rigoroso per l'TP.

[5] Immagini realistiche e audio di alta qualità

[6] Il valore predefinito per questo parametro è 200 ms di traffico con priorità larghezza di banda. L'algoritmo Cisco LLQ è stato implementato per includere un parametro burst predefinito equivalente a 200 ms di traffico. I test hanno mostrato che questo parametro burst non richiede ulteriore sintonizzazione per un singolo flusso di videoconferenza IP (IP/VC). Per flussi multipli, questo parametro di frammentazione può essere aumentato in base alle esigenze.

[7] Uno streaming video ausiliario è un canale video a 5 fps per la condivisione di presentazioni o altro materiale collaterale tramite il proiettore dati.

[8] Notare che alcuni sistemi utilizzano il modificatore "AS" (Application Specific) per trasmettere la massima larghezza di banda.  L'interpretazione di questo attributo dipende dal concetto di larghezza di banda massima dell'applicazione.

CUBE è agnostico riguardo al modificatore di larghezza di banda specifico (TIAS o AS).

[9] Mediatrace è una funzionalità software di IOS che rileva i router e gli switch lungo il percorso di un flusso IP.

StartSelection:0000000199 EndSelection:000000538