Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este los documentos revisa el tema de la calidad de la llamada video y proporcionan una guía en las cosas para tener presente mientras que el Calidad de Servicio (QoS) se configura en una frontera unificada Cisco Element(CUBE) o un gateway del Time-Division Multiplexing (TDM).
Contribuido por Baktha Muralidharan, ingeniero de Cisco TAC, editado por Anoop Kumar.
Este documento es el más beneficioso para los ingenieros familiares con la voz sobre IP (VoIP), aunque otros pudieran encontrarla útil.
No hay soporte físico o software específico usado para escribir este documento.
El audio digitalizado en su forma más simple es un conjunto de las muestras audios, cada muestra que describe la presión sonora durante ese período. El audio conversacional se puede capturar y reproducir a un nivel alto de exactitud, con apenas 8000 muestras por second[1]. Esto entonces significa que mientras la red pueda transportar las muestras sin el Retraso excesivo, el jitter y la pérdida del paquete, audio se puede reproducir fielmente en el otro extremo.
En cambio la presentación, el proceso y el transporte del vídeo es mucho más complejos. El brillo, el contraste, la saturación de color, la sensibilidad (indicar) y la sincronización audio/video son apenas algunos de los atributos que determinan la calidad del vídeo. Las muestras video requieren generalmente un espacio mucho más grande. Naturalmente, el vídeo pone una demanda mucho más grande en el ancho de banda de la red, en la red de transporte. La calidad del audio se determina por: El Presidente del micrófono en la calidad de la llamada video de la red de transporte de la compresión de códec de las auriculares se afecta por: Compatibilidad/Interoperabilidad de la red de transporte de los códec de video del Dispositivo de visualización de la cámara
Nota: Es importante entender eso audio desemejante, un bit continúa muy en los punto final de video, cuando se trata de ajustar la calidad.
QoS en general es un extenso y el tema complejo que requiere la consideración de los requisitos de tráfico totales (bastante que apenas el tráfico que usted desea mejorar la calidad de) y de las necesidades de ser comprobado cada componente de la red a lo largo de la trayectoria de los media fluye. La realización del calidad del video en un Video conferencia. es aún más compleja pues implica además de los componentes de la red, del estudio y del examen de la configuración y de ajustar en los puntos finales. Ampliamente, el calidad del video exige esto:
El foco específico en este documento será las consideraciones de QoS en el gateway del IOS o el CUBO al manejar el vídeo llama.
El ajustar en los puntos finales implicaría ajusta un conjunto de parámetros en los punto final de video. Esto por supuesto depende del producto pero aquí es algunos “botones generales”:
Ajustar la red para el vídeo implica generalmente el siguiente:
La Interoperabilidad entra en el juego cuando es heterogéneo (telefonía con video así como el TelePresence (el TP)) los sistemas participan en una llamada en conferencia. La experiencia proporcionada por un sistema TP y de teléfono con video es fundamental diferente. La Interoperabilidad entre ellos es alcanzada generalmente interligandolos usando un proceso conocido como conexión en cascada.
Esto no es un documento de diseño y no un documento video completo de QoS cualquiera. Este documento no cubre específicamente estos temas:
El vídeo, como el audio es en tiempo real. Las transmisiones de audio están Velocidad de bits constante (CBR). En cambio, el tráfico de video tiende a ser bursty y se refiere como siendo la Velocidad de bits variable (el VBR.) Por lo tanto la velocidad de bits para el transmisión de video no será necesariamente constante, si necesitamos mantener cierto quality[2].
Imagen 1
La determinación del ancho de banda y de repartir requeridos para el vídeo es también implicada. Esto se discute más adelante en este documento.
¿Por qué es el vídeo bursty?
Las mentiras de la respuesta en el vídeo de la manera son comprimidas. Recuerde que el vídeo es una secuencia de imágenes (tramas) jugadas para proporcionar un efecto visual del movimiento. Las técnicas de compresión usadas por el codecs video utilizan un acercamiento llamado Delta encoding[3], que trabaja salvando los valores de los bytes como diferencias (deltas) entre los valores secuenciales (de las muestras) bastante que los valores ellos mismos. El vídeo se codifica (y se transmite por consiguiente) como tramas consecutivas que llevan apenas las “piezas móviles” bastante que los toda la trama.
¿Usted se está preguntando probablemente porqué, el audio cambia ampliado también? Bien, verdad bastantes, pero el “movimiento” (o las dinámicas) no afecta el audio casi tanto como hace el vídeo. Las muestras audios de 8 bits no comprimen mejor cuando lo hace el delta codificado, las muestras video (tramas). El cambio relativo de la muestra (trama a enmarcar) a muestrear es video es mucho más pequeño que ése en el audio. Dependiendo de la naturaleza y del grado de movimiento, las muestras video pueden variar grandemente de tamaño. La imagen 2 ilustra la compresión video
Imagen 2
Una trama del ‑ I es una imagen Intra-cifrada, en efecto una imagen completamente especificada, como un archivo de imagen estático convencional.
Una trama del ‑ P (imagen prevista) lleva a cabo solamente los cambios en la imagen de la trama anterior. El codificador no necesita salvar los pixeles constantes del fondo en la trama del ‑ P, así el espacio del ahorro. Las tramas del ‑ P también se conocen como tramas del ‑ del delta.
Una trama del ‑ B (imagen BI-profética) guarda aún más espacio usando las diferencias entre la trama actual y las tramas anteriores y de siguientes para especificar su contenido.
El engranaje del video de Cisco no mide ni señala sobre el calidad del video como tal, así que el calidad del video se percibe bastante que medido. Hay los algoritmos estandardizados que miden la calidad mediante un MOS (Mean Opinion Score). Sin embargo, si los problemas señalados sobre la calidad del audio son cualquier indicación, los casos del calidad del video (TAC) son más probables ser abiertos porque el usuario percibió los problemas de calidad bastante que los informes por una herramienta.
Los factores que afectan al calidad del video incluyen:
Cada uno del antedicho es generalmente a elección/controlable en los puntos finales.
El acolchar, el peinarse y el vendaje se acostumbran a estos términos, la taxonomía video de la debilitación de la parte de.
El SLA de red recomendado para video[4] es como sigue:
A propósito el SLA de red recomendado para transportar el audio está:
Nota: Claramente video es más sensible a la pérdida del paquete que la Voz. Esto debe ser esperada una vez que usted entiende que los interframes requieren la información de las tramas anteriores, así que significa que la pérdida de interframes puede ser devastadora al proceso de reconstruir el imagen de video.
SLA para el transporte video se puede entregar generalmente usando las directivas de QoS que son muy similares a ésas usadas para el transporte audio. Hay algunas diferencias sin embargo debido a la naturaleza del tráfico de video.
Nota: Aunque el alcance de este documento se limite al componente del CUBO, recuerde que QoS es de punta a punta.
¿Es todo el vídeo lo mismo? Bien, no muy. Las variaciones del vídeo como media incluyen:
Nota: En interés de la brevedad, los ejemplos no se proporcionan extensivamente para cada tipo de vídeo enumerado arriba.
Nota: El vídeo, como el audio, es adentro llevado (RTP) en tiempo real del protocolo
En principio los mecanismos de Calidad de servicio (QoS) empleados para entregar los SLA para una red de transporte video son sobre todo lo mismo que ésos para el audio. Hay algunas diferencias sin embargo, sobre todo debido a la naturaleza de congestión del vídeo y de la transmisión VBR.
Hay dos acercamientos a QoS, a saber Interated Services(intserv) y Services(diffserv) distinguido.
Piense en Intserv como actuando en el nivel y el DiffServ de señalización en el media-nivel. Es decir el modelo del intserv asegura la calidad actuando en el avión del control; el DiffServ apunta asegurar la calidad oeprating en el nivel del avión de la fecha.
En arquitectura intserv los dispositivos de red haga los pedidos las reservas de ancho de banda estáticas y mantenga el estado de todos los flujos reservados mientras que realiza la clasificación, marca y los Datos en espera mantienen estos flujos; arquitectura intserv actuar-e integrar-ambo el avión del control y el avión de los datos, y pues tal ha sido en gran parte abandonado debido a las limitaciones de ampliación inherentes. El protocolo usado para hacer las reservas de ancho de banda es RSVP (Resource Reservation Protocol).
Hay también el modelo de IntServ/del DiffServ, que es clase de una mezcla. Este modelo separa las operaciones planas del control de las operaciones del avión de los datos. La Operación RSVP se limita al control de admisión solamente; con los mecanismos del DiffServ que manejan la clasificación, marca, policing y programando las operaciones. Como tal, el modelo de IntServ/del DiffServ es altamente scalable y flexible.
Nota: Este documento se centra solamente en el apprach del DiffServ (viz-uno-viz esquema de priorización, LLQ).
El ancho de banda es obviamente el parámetro más fundamental de los qos. Esto depende de varios parámetros, especialmente:
El viejo truco del ancho de banda que lanza en el problema no es siempre la solución. Esto es especialmente verdad para el calidad del video. Por ejemplo, con CUVA (Cisco Unified Video Advantage) no hay mecanismo de sincronización entre los dos dispositivos (teléfono y PC) implicados. Así QoS se debe configurar para minimizar el jitter, el tiempo de espera, los paquetes fragmentados, y los paquetes defectuosos.
Nota: El vídeo interactivo tiene los mismos requisitos de nivel de servicio que el VoIP porque una llamada de voz se integra dentro del secuencia de video. El vídeo de flujo continuo tiene requisitos mucho más flojos, debido a la gran cantidad de mitigar eso se ha incorporado a las aplicaciones.
Finalmente es importante entender que el VoIP desemejante allí no es ninguna fórmula limpia para calcular el ancho de banda ampliado requerido. Ésta es porque los tamaños y las velocidades de paquetes de paquete de video varían perceptiblemente y es en gran parte una función del grado de movimiento dentro de los imagen de video que son transmitidos. Más en esto más adelante.
El Low Latency Queuing (LLQ) es la política de colocación encola preferida para el audio VoIP. Dado el retardo/el jitter rigurosos los requisitos sensibles del TP y la necesidad de sincronizar audio y video para CUVA, los Datos en espera de la prioridad (LLQ) es recomendados para todo el tráfico de video también. Observe que, para el vídeo, el ancho de banda prioritario es eludido generalmente para arriba por el 20% para explicar los gastos indirectos.
No recomendado para el vídeo.
El LFI es un mecanismo popular a asegurarse que el jitter no sale del control en los links lentos, donde los retrasos de serialización pueden ser altos.
Sin embargo el Interactivo-vídeo no se recomienda para los links lentos. Esto es porque el LLQ al cual el tráfico de video se asigna, no está conforme a la fragmentación. Esto significa que los paquetes grandes del Interactivo-vídeo (tales como Yo-tramas del FULL-movimiento 1500-byte) podrían causar los retrasos de serialización para paquetes más pequeños del Interactivo-vídeo.
Rechazo selectivo basado en el RTCP
Este mecanismo de Calidad de servicio (QoS) es un importante para el tráfico de video, que, según lo mencionado anterior, es bursty.
El parámetro de ráfaga opcional se puede configurar como parte de la prioridad command[6].
Con H.264, la explosión a lo peor sería la pantalla completa del vídeo (espacial-comprimido). De acuerdo con las pruebas en profundidad en los sistemas TP, éste se encuentra para ser 64 KB. Por lo tanto el parámetro de ráfaga LLQ se debe configurar para permitir hasta 64 KB de la explosión por la trama por la pantalla. Así el sistema del CTS-1000 que se ejecuta en 1080p-Best (con el soporte opcional de un vídeo auxiliar stream[7]) sería configurado con un LLQ con un parámetro de ráfaga óptimo de 128 (2x64) KB.
¿Así pues, cuánto ancho de banda se requiere para transportar una llamada video fielmente? Antes de que consigamos abajo a los cálculos, es importante entender los conceptos siguientes, que son únicos al vídeo.
Esto refiere básicamente al tamaño de la imagen. Otros términos de uso general para esto incluyen el formato y el tamaño de la pantalla video. Los formatos video de uso general se muestran abajo.
Formato |
Resolución de vídeo (pixeles) |
||
SQCIF |
128x96 |
||
QCIF |
176x144 |
||
SCIF |
256x192 |
||
SIF |
352x240 |
||
CIF |
352x288 |
||
DCIF |
528x384 |
||
|
704x576 |
||
16CIF |
1408x1152 |
Amplia mayoría de equipo de la videoconferencia funcionado con en los formatos CIF o 4CIF.
Referencia: http://en.wikipedia.org/wiki/Common_Intermediate_Format
Nota: No hay equivalencia para la resolución (video) en el mundo audio
Esto refiere a la tarifa en la cual un dispositivo de proyección de imagen produce las imágenes consecutivas únicas llamadas las tramas. La velocidad de tramas se expresa como tramas por segundo (fps).
Nota: El equivalente métrico en el mundo audio está muestreando el tiempo. E.g. 8000 para g.711ulaw.
Los cálculos del ancho de banda para los sistemas del telefonía con video y otros sistemas de videoconferencia tradicionales tienden a ser más simples.
Como un ejemplo, considere una llamada TP con la resolución de 1080 x1920. El ancho de banda requerido se calcula como sigue
2,073,600 pixeles por la trama
colores x3 por el pixel
byte x1 (8 bits) por el color
x 30 tramas por segundo
= 1.5Gbps por la pantalla. ¡Sin comprimir!
¡Con la compresión, un ancho de banda de 4Mbps por la pantalla (el > 99% comprimido) es bastante para transportar la trama antedicha!
La tabla siguiente enumera algunas de las combinaciones
Imagen |
Luminancia |
Luminancia |
Sin comprimir |
|||
10 frames/s |
30 frames/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 |
4CIF |
704 |
576 |
32.4 |
48.7 |
97.3 |
146.0 |
16CIF |
1408 |
1152 |
129.8 |
194.6 |
389.3 |
583.9 |
Observe eso sobre los cálculos están para un monopantella. Una llamada TP podría implicar a las pantallas múltiples y por eso, el ancho de banda total para la llamada sería un múltiplo del ancho de banda de la por-pantalla.
Refiera a https://supportforums.cisco.com/thread/311604 para una buena calculadora del ancho de banda para los sistemas de Cisco TP.
¿Cómo el tráfico de video identificado/se distingue? Una manera de clasificar los paquetes en el CUBO está utilizando las marcas DSCP.
La tabla siguiente ilustra las marcas DSCP por la línea de fondo así como el RFC 4594 de Cisco QoS.
Tráfico |
Capa 3 PHB |
Capa 3 DSCP |
Señalización de llamada |
CS3 |
24 |
Voice |
EF |
46 |
Video conferencia. |
AF41 |
34 |
TelePresence |
CS4 |
32 |
El fluir de las multimedias |
AF31 |
26 |
Video de broadcast |
CS5 |
40 |
PHB - Per Hop Behavior. Se refiere hasta a lo que hace el router clasificación de paquetes y funciones de condicionamiento del tráfico, tales como medición, marcado, formar, y vigilancia.
Por abandono, antes de la versión 9.0 CUCM (administrador de llamada unificado Cisco) marcó cualquiera y todo el tráfico de video (TelePresence incluyendo) al AF41. A partir de la versión 9.0, CUCM preconfigura los valores siguientes DSCP:
El configurar a ajustar para la calidad del audio exige el ancho de banda prioritario calculador y implementar la directiva LLQ en un link WAN. Esto se basa generalmente en el volumen de llamada y los códecs de audio anticipados usados.
Mientras que los principios son lo mismo, el ancho de banda video a través de un CUBO no es tan fácilmente calculable. Esto es debido a varios factores, incluyendo:
Por lo tanto, el aprovisionamiento del ancho de banda para los sistema de video sucede a veces en la cantidad de la orden reversa es decir de ancho de banda que una red de transporte puede entregar, con la directiva LLQ, se determina primero y basado en ese, se configura el punto final. ¡Los sistema de video del punto final son bastante elegantes ajustar los diversos parámetros video para que haya el tamaño del tubo! Por consiguiente, los puntos finales señalan la llamada.
¿Así pues, cómo el CUBO maneja el ancho de banda en su oferta/respuestas (del SORBO) al señalar el vídeo llama? El CUBO puebla los campos video del ancho de banda en el SDP como sigue
1. Del atributo del ancho de banda en el SDP entrante. En el SDP, existe un atributo del ancho de banda, que tiene un modificante usado para especificar qué tipo de velocidad de transmición de bites refiere el valor. El atributo tiene la forma siguiente: b=<modifier>: <value>
2. Del ancho de banda video configurado en el CUBO. Por ejemplo, el ancho de banda máximo estimado se calcula sobre la base de las características usadas por el usuario CTS y el ancho de banda estimado se preconfigura en el CUBO, usando el CLI
3. Ancho de banda video predeterminado (384 kbps)
El flujo de llamada mostrado abajo ilustra cómo el CUBO puebla el ancho de banda en los mensajes de señalización de llamada
Específicamente, el CUBO utiliza la lógica siguiente:
En el nivel de la sesión SDP, el valor TIAS es la cantidad máxima de ancho de banda necesaria cuando todas las secuencias de medios declaradas son used[8].
Ésta es otra área en la cual el vídeo diferencia del audio. El Códecs de audio utiliza los tipos de carga útil estáticos. El codecs video, en cambio, utiliza los tipos de carga útil dinámicos RTP, que utilizan el rango 96 a 127.
La razón del uso del tipo de carga útil dinámico tiene que hacer con la aplicabilidad amplia del codecs video. El codecs video tiene parámetros que proporcionen un receptor con las propiedades de la secuencia que será enviada. Definen a los tipos de carga útil video en el SDP, usando el parámetro del a=rtpmap. Además, el “a=fmtp: ” atribuya PUEDE ser utilizado para especificar los parámetros del formato. La cadena del fmtp es opaca y apenas se pasa al otro lado.
Aquí está 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
Observe que los dos puntos finales implicados en una llamada pudieron utilizar diverso tipo de carga útil para el mismo codificador-decodificador. El CUBO responde a cada lado con la línea del a=rtpmap recibida en la otra pierna. Esto significa que el config “payload asimétrico” es por completo necesario para que las llamadas video trabajen.
Ancho de banda L2
A diferencia de la Voz, el tráfico de video en tiempo real IP en general es un algo bursty, secuencia de la Velocidad de bits variable. Por lo tanto el vídeo, a diferencia de la Voz, no tiene fórmulas claras para la tara de red calculadora porque los tamaños y las tarifas de paquete de video varían proporcional al grado de movimiento dentro del imagen de video sí mismo. Desde el punto de vista de un administrador de la red, el ancho de banda es siempre aprovisionado en la capa 2, pero la variabilidad en los tamaños de paquetes y la variedad de media de la capa 2 que los paquetes puedan atravesar de punta a punta hacen difícil calcular el ancho de banda real que debe ser aprovisionado en la capa 2. Sin embargo, la regla conservadora que ha sido probada a conciencia y el ampliamente utilizado está al ancho de banda video de la sobreasignación por el 20%. Esto acomoda el 10% repartido y la tara de red de la capa 2 para acodar 4.
Como punto final de video anteriores mencionados no señale un MOS como tal. Sin embargo las herramientas siguientes podían ser medir usada/monitor el funcionamiento de red de transporte, y monitorear el calidad del video.
Una característica integrada en el IOS, IP SLA (Service Level Agreements) realiza la supervisión activa del rendimiento de la red. La operación video IP SLA diferencia de otras operaciones IP SLA en que todo el tráfico es una manera solamente, con un respondedor requerido procesar los números de secuencia y los sellos de fecha/hora localmente y esperar una petición de la fuente antes de devolver los datos calculados.
La fuente envía una petición al respondedor cuando se hace la operación video actual. Señales de esta petición el respondedor que llegarán no más de paquetes, y que la función video del fregadero en la operación video se puede apagar. Cuando la respuesta del respondedor llega la fuente, las estadísticas se leen en el mensaje, y los campos relevantes en la operación son actualizados.
Sonda IP SLA de las aplicaciones de los CiscoWorks IPM (monitor de rendimiento IOS) y MediaTrace[9] para medir el funcionamiento y los informes del tráfico de usuarios.
La característica VQM (monitor del calidad del video), disponible en el CUBO, es una gran herramienta para monitorear el calidad del video entre dos puntas del interés. Los resultados se presentan como MOS.
Éste es disponible desde IOS 15.2(1)T y arriba. Observe que VQM utiliza a los recursos DSP.
[1] basado en la frecuencia humano-audible audio más alta de aproximadamente 4000Hz. Referencia: Teorema de Nyquist.
[2] Velocidad de bits constante (CBR) los esquemas de la transmisión son posibles con el vídeo, pero ellos calidad del equilibrio mantener el CBR.
[3] para las compresiones de la Inter-trama
[4] observe que SLA es más riguroso para el TP.
Imágenes [5] de tamaño natural y audio de alta calidad
[6] el valor predeterminado para este parámetro es 200ms del tráfico en el ancho de banda prioritario. El algoritmo de Cisco LLQ se ha implementado para incluir un parámetro de ráfaga predeterminado equivalente al valor de 200 ms del tráfico. La prueba ha mostrado que este parámetro de ráfaga no requiere ajustar adicional para una sola secuencia de la Videoconferencia IP (IP/VC). Para las secuencias múltiples, este parámetro de ráfaga se puede aumentar como sea necesario.
[7] un secuencia de video auxiliar es un canal video del fps 5 para compartir las presentaciones o el otro frasco colateral el proyector de los datos.
[8] observe que algunos sistemas utilizan “COMO” modificante (específico a la aplicación) para transportar el ancho de banda máximo. La interpretación de este atributo es dependiente en la noción de la aplicación del ancho de banda máximo.
El CUBO es agnóstico en cuanto al modificador de ancho de banda específico (TIAS o COMO).
[9] Mediatrace es una característica del software IOS que descubre que fluyen el Routers y el Switches a lo largo de la trayectoria de un IP.
StartSelection:0000000199 EndSelection:0000000538