Tutorial sobre calidad de servicio (QOS) de vídeo

Introducción

Este documento revisa el tema de la calidad de las videollamadas y proporciona un tutorial sobre las cosas que se deben tener en cuenta mientras se configura la calidad del servicio (QoS) en un gateway Cisco Unified Border Element (CUBE) o Time-Division Multiplexing (TDM).

Colaborado por Baktha Muralidharan, Ingeniero del TAC de Cisco, editado por Anoop Kumar.

Prerequisites

Requirements

Este documento es más beneficioso para los ingenieros familiarizados con la voz sobre IP (VoIP), aunque a otros les puede resultar útil.

Componentes Utilizados

No se utiliza ningún hardware o software específico para escribir este documento.

Antecedentes

El audio digitalizado en su forma más sencilla es un conjunto de muestras de audio, cada una de las cuales describe la presión sonora durante ese período.  El audio de la conversación puede capturarse y reproducirse con un alto grado de precisión, con sólo 8000 muestras por segundo[1].  Esto significa que mientras la red pueda transportar las muestras sin demora excesiva, fluctuación y pérdida de paquetes, el audio puede reproducirse fielmente en el otro extremo.

Por el contrario, la presentación, el procesamiento y el transporte del vídeo son mucho más complejos. Brillo, contraste, saturación de color, capacidad de respuesta (al movimiento) y sincronización de labios son sólo algunos de los atributos que determinan la calidad del vídeo. Las muestras de vídeo generalmente requieren mucho más espacio. No es de extrañar que el vídeo plantee una demanda mucho mayor del ancho de banda de la red en la red de transporte. La calidad de audio la determina :Altavoz de micrófono en el códec de auriculares - la calidad de la videollamada de la red de transporte de compresión se ve afectada por: Dispositivo de visualización de la cámara Códec de vídeo Compatibilidad/interoperabilidad de la red de transporte

Nota: Es importante entender que, a diferencia del audio, pasa bastante tiempo en los terminales de vídeo cuando se trata de ajustar la calidad.

Objetivo

La QoS en general es un tema amplio y complejo que requiere consideración de los requisitos generales del tráfico (en lugar de sólo el tráfico que desea mejorar la calidad de) y debe verificarse en cada componente de red a lo largo de la trayectoria del flujo de medios. Lograr la calidad del vídeo en una videoconferencia es aún más complejo, ya que implica, además de los componentes de la red, la revisión y el examen de la configuración y el ajuste en los terminales. En general, la calidad del vídeo conlleva lo siguiente:

• Ajuste de terminales: optimización de la configuración de terminales (por ejemplo, resolución, trama por segundo)
• Optimización del transporte: optimización de la red para transportar el tráfico de vídeo por SLA de red.
• Consideraciones sobre interoperabilidad: muchas veces, las llamadas de vídeo involucran terminales de diversas capacidades. El diseño y la configuración de los sistemas para maximizar la interoperabilidad puede afectar a la calidad del vídeo.

El foco específico en este documento serán las consideraciones de QoS en el gateway IOS o CUBE al manejar videollamadas.

La adaptación a los terminales implicaría ajustar un conjunto de parámetros en los terminales de vídeo. Esto por supuesto depende del producto, pero aquí hay algunos "mandos" generales :

• Resolución (es decir, tamaño de imagen)
• Velocidad de imágenes (es decir, sensibilidad/realidad del movimiento)
• Etiquetado (es decir, marca ToS)

La adaptación de la red para vídeo generalmente implica lo siguiente:

• Comprensión de la composición del tráfico que fluye a través del CUBE; por ejemplo, volumen pico [llamada], etc.
• Revisión de la capacidad de link/canal de red
• Diseñar políticas de QoS adecuadas para garantizar que se cumple el SLA para cada clase de tráfico

La interoperabilidad entra en juego cuando los sistemas heterogéneos (telefonía de vídeo y telepresencia (TP) participan en una llamada de conferencia. La experiencia que proporcionan los sistemas de telefonía de vídeo y de transmisión de datos es fundamentalmente diferente. La interoperabilidad entre ellos se logra generalmente mediante la conexión en puente con un proceso conocido como cascada.

Lo que esto no cubre

Este no es un documento de diseño ni tampoco un documento de QoS de vídeo completo. Específicamente, este documento no cubre estos temas:

• Señalización [protocolos] de videollamadas, más allá de lo necesario para ilustrar aspectos relacionados con QoS.
• Configuración/configuración del terminal de vídeo
• Revisión completa de los mecanismos de QoS que incluyen la regulación, la colocación en cola, el modelado y la ráfaga
• Revisión de la configuración de QoS en los switches de Capa 2 o consideraciones de límites de confianza.

Características del tráfico de red de vídeo

Vídeo, como el audio en tiempo real.  Las transmisiones de audio son de velocidad de bits constante (CBR). Por el contrario, el tráfico de vídeo tiende a estar en ráfaga y se denomina velocidad de bits variable (VBR.) Por consiguiente, la velocidad de bits para la transmisión de vídeo no será necesariamente constante, si necesitamos mantener una cierta calidad[2].

Imagen 1

La determinación del ancho de banda y la ráfaga necesaria para el vídeo también está más implicada. Esto se analiza más adelante en este documento.

• El tráfico de vídeo está saturado.
• Los paquetes de vídeo pueden ser bastante grandes.
• El audio siempre es CBR. El vídeo suele ser VBR. 

¿Por qué se grava el vídeo?

La respuesta reside en la forma en que se comprime el vídeo. Recuerde que el vídeo es una secuencia de imágenes (fotogramas) reproducidas para proporcionar un efecto de movimiento visual. Las técnicas de compresión utilizadas por los códecs de vídeo utilizan un enfoque denominado codificación Delta [3], que funciona almacenando valores de bytes como diferencias (deltas) entre valores secuenciales (muestras) en lugar de los valores mismos. En consecuencia, el vídeo se codifica (y se transmite) como tramas consecutivas que llevan sólo las "partes móviles" en lugar de tramas enteras.

Probablemente se esté preguntando ¿Por qué, el audio también cambia gradualmente? Bueno, lo suficientemente cierto, pero el "movimiento" (o la dinámica) no afecta al audio tanto como al vídeo. Las muestras de audio de 8 bits no se comprimen mejor cuando se codifican delta, las muestras de vídeo (fotogramas) sí. El cambio relativo de la muestra (cuadro a cuadro) a la muestra es mucho menor que el de audio. Dependiendo de la naturaleza y el grado de movimiento, las muestras de vídeo pueden variar considerablemente en tamaño. La imagen 2 ilustra la compresión de vídeo

Imagen 2

Una trama I es una imagen Intra-codificada, de hecho una imagen completamente especificada, como un archivo de imagen estática convencional.

Una trama P (imagen predicha) contiene solamente los cambios en la imagen del marco anterior. El codificador no necesita almacenar los píxeles de fondo sin cambios en el marco P, lo que ahorra espacio. Las tramas P también se conocen como tramas delta.

Una trama B (imagen bipredictiva) ahorra aún más espacio al utilizar diferencias entre la trama actual y las tramas anterior y siguiente para especificar su contenido.

Medición de la calidad del vídeo

Los equipos de vídeo de Cisco no miden ni informan sobre la calidad del vídeo como tal, por lo que la calidad del vídeo se percibe en lugar de medirse. Existen algoritmos estandarizados que miden la calidad mediante un MOS (Media Opinion Score). Sin embargo, si los problemas notificados sobre la calidad del audio sirven para indicar algo, es más probable que se abran casos de calidad del vídeo (TAC) porque el usuario percibió problemas de calidad en lugar de informes de una herramienta.

Controles en los terminales

Los factores que afectan a la calidad del vídeo son:

• el códec de vídeo (MPEG4, H261, H263, H264 y H265)
• tamaño (pantalla 1/8, pantalla 1/4, pantalla completa)
• velocidad de trama (de 1 a 30 fotogramas por segundo, 6 predeterminados)
• el parámetro de calidad de compresión (bajo, medio, alto)

Por lo general, cada una de las opciones anteriores es seleccionable/controlable en los terminales.

Artefactos visibles

Quilting, Combing y Banding se acostumbran a estos términos, parte de la taxonomía de deterioro de video. Consulte este documento para obtener más información sobre las deficiencias de vídeo comunes:

Ref: 

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

  

SLA de red de transporte para calidad de vídeo

El SLA de red recomendado para vídeo [4] es el siguiente:

• Latencia ≤ 150-300 ms
• Jitter ≤ 10 ms-50 ms
• Pérdida ≤ 0,5%

Por cierto, el SLA de red recomendado para el transporte de audio es:

• Latencia ≤ 150-300 ms
• Jitter ≤ 20 ms-50 ms
• Pérdida ≤ 1%

Nota: Está claro que el vídeo es más sensible a la pérdida de paquetes que la voz.  Esto debe esperarse una vez que entienda que las tramas requieren información de tramas anteriores, lo que significa que la pérdida de tramas puede ser devastadora para el proceso de reconstrucción de la imagen de vídeo.

Controles en la red de transporte

Generalmente, el SLA para el transporte de vídeo se puede proporcionar mediante políticas de QoS muy similares a las que se utilizan para el transporte de audio. Sin embargo, hay algunas diferencias debido a la naturaleza del tráfico de vídeo.

  

Nota: Aunque el alcance de este documento se limita al componente CUBE, recuerde que QoS es integral.

Variedades de vídeo

¿Todos los vídeos son iguales? Bueno, no del todo. Las variaciones del vídeo como medio incluyen:

• Videotelefonía/Videoconferencia
• Interactivo en tiempo real
• Ancho de banda relativamente menor. Hasta aproximadamente 1 Mbps
• TelePresence
• Interactivo en tiempo real
• Experiencia inmersiva
• Requiere un ancho de banda muy alto
• Transmisión
• Unidireccional en tiempo real
• Puede ser unidifusión o multidifusión
• Ancho de banda alto
• No es sensible al retraso (el vídeo puede tardar varios segundos en ponerse en cola)
• En gran medida insensible a la fluctuación (debido a la creación de búferes en las aplicaciones)
• La pérdida no debe ser superior al 5%.
• La latencia no debe ser superior a 4 o 5 segundos (dependiendo de las capacidades de almacenamiento en búfer de la aplicación de vídeo)
• Algunos vídeos (por ejemplo, entretenimiento) podrían considerarse para el servicio Scavenger.

Nota: En aras de la brevedad, las ilustraciones no se proporcionan exhaustivamente para cada tipo de vídeo mencionado anteriormente.

Códecs de tráfico de vídeo

• • H.261- Codec se diseñó originalmente para la transmisión a través de líneas ISDN. Con el uso de la vinculación de vídeo, las velocidades de bits de vídeo son múltiplos de 64 Kbit/s.
  • H.263: el códec se utiliza tanto en las videoconferencias basadas en IP como en las redes ISDN. H.263 requiere la mitad del ancho de banda para lograr la misma calidad de vídeo que en H.261. Como resultado, H.263 ha reemplazado en gran medida a H.261. H.263 se ha optimizado para una amplia gama de velocidades de bits y no sólo 64K bits/s como con H.261.
  • H.264/MPEG-4 - Actualmente, Cs es uno de los formatos más utilizados y utiliza la mitad o menos de la velocidad de bits de MPEG-2, H.263 o MPEG-4 Parte 2.
  • H265 - Uno de los posibles sucesores del H.264 ampliamente utilizado y basado en la extensión de los mismos conceptos. Admite resoluciones de hasta 8192×4320, incluyendo 8000 UHD.

Nota: El vídeo, al igual que el audio, se transporta en el protocolo en tiempo real (RTP)

Mecanismos QoS para vídeo

En principio, los mecanismos de QoS empleados para ofrecer los SLA para una red de transporte de vídeo son mayormente los mismos que para el audio. Sin embargo, hay algunas diferencias, principalmente debido a la naturaleza agobiante de la transmisión de vídeo y VBR.

Hay dos enfoques para QoS, a saber Interated Services(intserv) y Diferfserv(diffserv).

Piense en Intserv como operando a nivel de señalización y diffserv a nivel de medios. En otras palabras, el modelo intserv garantiza la calidad al operar en el plano de control; diffserv se propone garantizar la calidad mediante el funcionamiento a nivel de plano de fecha.

En la arquitectura IntServ, los dispositivos de red realizan solicitudes de reservas de ancho de banda estático y mantienen el estado de todos los flujos reservados mientras realizan servicios de clasificación, marcado y colocación en cola para estos flujos; la arquitectura IntServ funciona (e integra) tanto el plano de control como el plano de datos y, como tal, se ha abandonado en gran medida debido a las limitaciones de escalabilidad inherentes. El protocolo utilizado para realizar las reservas de ancho de banda es RSVP (Resource reSerVation Protocol).

También existe el modelo IntServ/DiffServ, que es una especie de mezcla. Este modelo separa las operaciones del plano de control de las operaciones del plano de datos. La operación RSVP se limita únicamente al control de admisión; con los mecanismos DiffServ que gestionan las operaciones de clasificación, marcado, regulación y programación. Como tal, el modelo IntServ/DiffServ es muy escalable y flexible.

Nota: Este documento solo se centra en el enfoque diffserv (viz-a-viz priation esquema, LLQ).

Garantía de ancho de banda

El ancho de banda es obviamente el parámetro qos más fundamental.  Esto depende de varios parámetros, especialmente:

• Códec utilizado
• Velocidad de trama
• Tamaño de imagen
• Volumen de llamadas (pico y promedio)

El viejo truco de arrojar ancho de banda al problema no siempre es la solución. Esto es especialmente cierto en el caso de la calidad del vídeo. Por ejemplo, con CUVA (Cisco Unified Video Advantage) no hay un mecanismo de sincronización entre los dos dispositivos (teléfono y PC) involucrados. Por lo tanto, la QoS debe configurarse para minimizar la fluctuación, la latencia, los paquetes fragmentados y los paquetes desordenados.

Nota: El vídeo interactivo tiene los mismos requisitos de nivel de servicio que el VoIP porque una llamada de voz está integrada en la secuencia de vídeo.El streaming de vídeo tiene requisitos mucho más laxos, debido a la gran cantidad de almacenamiento en búfer que se ha integrado en las aplicaciones.

Por último, es importante comprender que, a diferencia de VoIP, no hay fórmulas limpias para calcular el ancho de banda incremental requerido. Esto se debe a que los tamaños de los paquetes de vídeo y las velocidades de los paquetes varían significativamente y son en gran medida una función del grado de movimiento dentro de las imágenes de vídeo que se transmiten. Más adelante.

Envío a cola

La cola de baja latencia (LLQ) es la política de colocación en cola preferida para el audio VoIP. Dados los estrictos requisitos sensibles al retardo/fluctuación de TP y la necesidad de sincronizar audio y vídeo para CUVA, la cola de prioridad (LLQ) es la recomendada para todo el tráfico de vídeo también. Tenga en cuenta que, en el caso del vídeo, el ancho de banda de prioridad suele incrementarse en un 20% para tener en cuenta la sobrecarga.

Compresión de encabezados

No se recomienda para vídeo.

Fragmentación y entrelazado de link

LFI es un mecanismo popular para garantizar que la fluctuación no se salga de control en links lentos, donde las demoras de serialización pueden ser altas.

Pero, de nuevo, no se recomienda el vídeo interactivo para los enlaces lentos. Esto se debe a que la LLQ a la que se asigna el tráfico de vídeo no está sujeta a fragmentación. Esto significa que los paquetes de vídeo interactivo de gran tamaño (como las tramas I de movimiento completo de 1500 bytes) podrían causar retrasos en la serialización de los paquetes de vídeo interactivo más pequeños.

Prevención de Congestión

Descarte selectivo basado en RTCP

Ráfaga

Este mecanismo de QoS es importante para el tráfico de vídeo, que, como se mencionó anteriormente, está saturado.

El parámetro de ráfaga opcional se puede configurar como parte del comando priority [6].

Con H.264, la peor ráfaga sería la pantalla completa de vídeo (con compresión espacial). Basado en pruebas exhaustivas en sistemas TP, se ha encontrado que esto es de 64 KB. Por lo tanto, el parámetro de ráfaga LLQ se debe configurar para permitir hasta 64 KB de ráfaga por trama por pantalla. Por lo tanto, el sistema CTS-1000 que se ejecuta a 1080p-Best (con la compatibilidad opcional de una secuencia de vídeo auxiliar[7]) se configuraría con un LLQ con un parámetro de ráfaga óptimo de 128 KB (2x64).

¿Cuánto ancho de banda?

Por lo tanto, ¿cuánto ancho de banda se necesita para transportar una videollamada fielmente? Antes de empezar a realizar los cálculos, es importante comprender los conceptos siguientes, que son exclusivos del vídeo.

Resolución

Esto se refiere básicamente al tamaño de la imagen.  Otros términos utilizados habitualmente para esto incluyen formato de video y tamaño de pantalla.  A continuación se muestran los formatos de vídeo utilizados habitualmente.

Formato	Resolución de vídeo (píxeles)
SQCIF	128 x 96
QCIF	176 x 144
SCIF	256 x 192
SIF	352 x 240
CIF	352 x 288
DCIF	528 x 384
4 CIF	704x576
16 CIF	1408x1152

La gran mayoría de los equipos de videoconferencia se ejecutan en formatos CIF o 4CIF.

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

Nota: No hay equivalencia para la resolución (de vídeo) en el mundo del audio

Velocidad de trama

Esto se refiere a la velocidad a la que un dispositivo de imagen produce imágenes consecutivas únicas llamadas fotogramas. La velocidad de trama se expresa como tramas por segundo (fps).

Nota: La métrica equivalente en el mundo del audio es el tiempo de muestreo. Por ejemplo, 8000 para g.711ulaw.

Cálculo del ancho de banda

Los cálculos del ancho de banda para sistemas de videotelefonía y otros sistemas de videoconferencia tradicionales tienden a ser más sencillos.

A modo de ejemplo, considere una llamada TP con una resolución de 1080 x 1920.  El ancho de banda necesario se calcula de la siguiente manera:

     2 073 600 píxeles por trama

        x3 colores por píxel

        x1 Byte (8 bits) por color

        x 30 fotogramas por segundo

        = 1,5 Gbps por pantalla. ¡No comprimido!

Con la compresión, un ancho de banda de 4 Mbps por pantalla ( > 99% comprimido) es suficiente para transportar la trama anterior.

En la tabla siguiente se enumeran algunas de las combinaciones:

Imagen formato	Luminancia píxeles	Luminancia líneas	Sin comprimir Velocidad de bits (Mbps)
			10 fotogramas/s		30 fotogramas/s
			Gris	Color	Gris	Color
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
4 CIF	704	576	32.4	48.7	97.3	146.0
16 CIF	1408	1152	129.8	194.6	389.3	583.9

Tenga en cuenta que los cálculos anteriores corresponden a una única pantalla. Una llamada TP podría implicar varias pantallas, por lo que el ancho de banda total para la llamada sería un múltiplo del ancho de banda por pantalla.

Consulte https://supportforums.cisco.com/thread/311604 para obtener una calculadora de ancho de banda adecuada para los sistemas Cisco TP.

Clasificación/marcación del tráfico de vídeo

¿Cómo se identifica/distingue el tráfico de vídeo? Una manera de clasificar los paquetes en CUBE es usando marcas DSCP.

La siguiente tabla ilustra las marcas DSCP por línea de base de QoS de Cisco así como RFC 4594.

Tráfico	PHB de capa 3	DSCP de capa 3
Señalización de llamada	CS3	24
Voice	EF	46
Videoconferencia	AF41	34
TelePresence	CS4	32
Transmisión multimedia	AF31	26
Vídeo de difusión	CS5	40

PHB - Comportamiento por salto. Se refiere a lo que hace el router en lo que respecta a las funciones de clasificación de paquetes y de condicionamiento del tráfico, como medición, marcado, modelado y regulación.

De forma predeterminada, antes de la versión 9.0 CUCM (Cisco Unified Call Manager) marcó todo el tráfico de vídeo (incluida TelePresence) a AF41. A partir de la versión 9.0, CUCM preconfigura los siguientes valores DSCP:

• Llamadas de TelePresence (vídeo inmersivo) en CS4 y
• Llamadas de vídeo (videotelefonía IP) en AF41

Configuración

La configuración para ajustar la calidad de audio implica calcular el ancho de banda de prioridad e implementar la política LLQ en un link WAN. Esto se basa generalmente en el volumen de llamada previsto y en el códec de audio utilizado.

Aunque los principios son los mismos, el ancho de banda de vídeo a través de un CUBE no es tan fácil de calcular. Esto se debe a varios factores, entre ellos:

• ¿Cómo se calcula el ancho de banda total requerido para las diferentes llamadas de TP (que fluyen a través del CUBE) podría implicar un número diferente de pantallas y de resoluciones diferentes?
• La naturaleza agobiante y el VBR
• Otra dimensión de la complejidad [en el cálculo del ancho de banda] tiene que ver con las "llamadas de interoperabilidad". Las llamadas de interoperabilidad utilizan TIP. TIP significa protocolo de interoperabilidad de telepresencia. TIP se utiliza para multiplexar varias pantallas, varias secuencias de audio, así como una pantalla de datos auxiliares en dos flujos RTP, uno para vídeo y audio cada uno. Permite sesiones de punto a punto y multipunto, así como una combinación de terminales de pantalla única y multipantalla. TIP es un protocolo propiedad de Cisco. TIP se basa en RTCP.

Por lo tanto, el aprovisionamiento de ancho de banda para los sistemas de vídeo a veces ocurre en el orden inverso, es decir, la cantidad de ancho de banda que una red de transporte puede ofrecer, con la política LLQ, se determina primero y en base a eso, se configura el terminal. Los sistemas de vídeo de terminales son lo suficientemente inteligentes como para ajustar los diversos parámetros de vídeo para el tamaño de la tubería. En consecuencia, los terminales señalan la llamada.

gestión de ancho de banda CUBE

Por lo tanto, ¿cómo gestiona CUBE el ancho de banda en su oferta/respuestas (SIP) al señalizar las videollamadas? CUBE rellena los campos de ancho de banda de vídeo en SDP de la siguiente manera-

  1. Desde el atributo bandwidth en el SDP entrante. En SDP, existe un atributo bandwidth, que tiene un modificador utilizado para especificar a qué tipo de velocidad de bits se refiere el valor.  El atributo tiene la siguiente forma: b=<modifier>:<value>

  2. Desde el ancho de banda de vídeo configurado en el CUBE. Por ejemplo, el ancho de banda máximo estimado se calcula en función de las funciones usadas por el usuario CTS y el ancho de banda estimado se configura previamente en CUBE, utilizando CLI-

• <bandwidth video tias-modifier> o
• <bandwidth video as-modifier>

  3. Ancho de banda de vídeo predeterminado (384 Kbps)

El flujo de llamadas que se muestra a continuación muestra cómo CUBE llena el ancho de banda en los mensajes de señalización de llamadas-

Específicamente, CUBE utiliza la siguiente lógica:

• En las ofertas (para realizar llamadas), CUBE utiliza el ancho de banda configurado.
• En (respuestas a EO), CUBE envía ancho de banda cuyo valor es el mínimo de oferta y configuración local.

En el nivel de sesión SDP, el valor TIAS es la cantidad máxima de ancho de banda necesaria cuando se utilizan todos los flujos de medios declarados [8].

Tipos de carga útil de códec de vídeo

Esta es otra área en la que el vídeo difiere del audio.  Los códecs de audio utilizan tipos estáticos de carga útil. Los códecs de vídeo, por el contrario, utilizan tipos de carga RTP dinámicos, que utilizan el rango de 96 a 127.

La razón del uso del tipo de carga útil dinámica tiene que ver con la amplia aplicabilidad de los códecs de video. Los códecs de vídeo tienen parámetros que proporcionan a un receptor las propiedades de la secuencia que se enviará. Los tipos de carga útil de vídeo se definen en SDP, utilizando el parámetro a=rtpmap. Además, el atributo "a=fmtp:" PUEDE utilizarse para especificar parámetros de formato. La cadena fmtp es opaca y acaba de pasar al otro lado.

Aquí tiene un ejemplo-

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

Tenga en cuenta que los dos extremos involucrados en una llamada pueden utilizar un tipo de carga diferente para el mismo códec. CUBE responde a cada lado con una línea a=rtpmap recibida en el otro tramo. Esto significa que la configuración "carga útil asimétrica llena" es necesaria para que las videollamadas funcionen.

ancho de banda L2

A diferencia de la voz, el tráfico de vídeo IP en tiempo real en general es un flujo de velocidad de bits variable y un tanto agobiante. Por lo tanto, el vídeo, a diferencia de la voz, no tiene fórmulas claras para calcular la sobrecarga de la red porque los tamaños y las velocidades de los paquetes de vídeo varían proporcionalmente al grado de movimiento dentro de la propia imagen de vídeo. Desde el punto de vista de un administrador de red, el ancho de banda siempre se aprovisiona en la Capa 2, pero la variabilidad en los tamaños de paquetes y la variedad de medios de Capa 2 que los paquetes pueden atravesar de extremo a extremo dificultan el cálculo del ancho de banda real que se debe aprovisionar en la Capa 2. Sin embargo, la regla conservadora que se ha probado a fondo y que se ha utilizado ampliamente es el exceso de aprovisionamiento del ancho de banda del vídeo en un 20%. Esto se adapta a la ráfaga del 10% y a la sobrecarga de la red de la capa 2 a la capa 4.

Supervisión/medición

Como se mencionó anteriormente, los terminales de vídeo no informan de un MOS como tal. Sin embargo, las siguientes herramientas podrían utilizarse para medir/monitorear el rendimiento de la red de transporte y para monitorear la calidad del vídeo.

Vídeo de IP SLAs

Una función integrada en IOS, IP SLAs (acuerdos de nivel de servicio) realiza la supervisión activa del rendimiento de la red. La operación de vídeo de IP SLAs difiere de otras operaciones de IP SLAs en que todo el tráfico es de una sola manera, con un respondedor necesario para procesar los números de secuencia y las marcas de tiempo localmente y para esperar una solicitud del origen antes de enviar los datos calculados de vuelta.

El origen envía una solicitud al respondedor cuando se realiza la operación de vídeo actual. Esta solicitud indica al respondedor que no llegarán más paquetes y que la función de receptor de vídeo en la operación de vídeo puede desactivarse. Cuando la respuesta del respondedor llega al origen, las estadísticas se leen del mensaje y se actualizan los campos relevantes de la operación.

CiscoWorks IPM (IOS Performance Monitor) utiliza la sonda IP SLA y MediaTrace[9] para medir el rendimiento del tráfico de los usuarios y los informes.

CUBE VQM

La función VQM (Monitor de calidad de vídeo), disponible en CUBE, es una excelente herramienta para supervisar la calidad de vídeo entre dos puntos de interés. Los resultados se presentan como MOS.

Esto está disponible en IOS 15.2(1)T y superiores. Tenga en cuenta que VQM utiliza recursos DSP.

Referencia

• 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 de videotelefonía 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:0000000538