Implementación de Soluciones QoS para Videoconferencia

Implementación de Soluciones QoS para Videoconferencia H.323
sobre IP
Contenido
Introducción
prerrequisitos
Requisitos
Componentes Utilizados
Convenciones
Antecedentes
H.323
Caracterización del tráfico de la videoconferencia
Planificación de capacidad
Situación de ejemplo
Determine el consumo de ancho de banda de por llamada
H.323 Audio
H.323 Video
Clasificación
Seleccione un Mecanismo de envío a cola elaborado
Modelo/esquema de priorización
¿Voz y Video deben compartir LLQ?
CAC
Modelado de tráfico
Interconexión con los terminales H.323
Configuración de muestra:
Información Relacionada
Introducción
H.323 es el estándar con la aceptación global de conferencias multimedia en una red del IP. Este documento describe las herramientas para
implementar la Calidad de Servicio (QoS) para las video conferencias H.323 sobre una WAN de empresa con links de velocidad relativamente
baja.
prerrequisitos
Requisitos
Quienes lean este documento deben tener conocimiento de los siguientes temas:
Los componentes de un sistema H.323-compliant. Los componentes incluyen, pero no se limitan a, las terminales, los gatewayes, los
porteros, los controladores multipuntos (MC), los procesadores multipuntos (MP), y las unidades de control multipunto (MCU). Refiera al
White Paper: Aplicaciones de H.323 que despliegan en las redes de Cisco para más información.
Soluciones de videoconferencia de Cisco H.323, que incluyen los MCU y los gatewayes así como el portero y proxy del Multimedia
Conference Manager (MCM). Vea la sección de la “información relacionada” de este documento para los links a la información sobre las
soluciones de videoconferencia de Cisco.
Diseños de la zona de H.323. El grupo de puntos finales de H.323 ocurre en las zonas, que son conveniencias administrativas similares a un
Domain Name System (DNS). Cada zona tiene un portero que maneje todos los puntos finales.
Planes de marcación. Refiera al capítulo 5: Arquitectura del Plan de marcado y configuración de la solución del Cisco AVVID, Telefonía
IP: Versión del CallManager de Cisco 3.0(5) para más información.
Técnicas del control de admisión de llamadas (CAC), que incluyen la señalización de los requerimientos de recurso vía el Resource
Reservation Protocol (RSVP).
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Convenciones
Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.
Antecedentes
La mayoría de las redes apoyan hoy a uno o más de estos tipos del tráfico de video:
Tipo video
Características de tráfico
Video conferencia.
Ancho de banda vivo, bidireccional, pequeño de los grupos:
Una o más secuencias por el usuario
Video on Demand
Una forma, (ancho de banda de punto a punto del modelo de
la extracción): Una secuencia por el usuario
Video de broadcast
(programado)
Una forma, uno-a-mucha (ancho de banda del modelo del
empuje): Una secuencia a los usuarios ilimitados (Multicast
IP)
Al mismo tiempo, muchas empresas examinan la existencia y a menudo los datos aparte, la Voz, y los infraestructura de red de video para
determinar la mayoría de las formas eficientes de traer estas redes juntas a través de una infraestructura IP. En estas redes con convergencia, QoS
es obligatorio en cualquier punta de la congestión potencial en la red. QoS se asegura de que retraso y tráfico sensible a las caídas, video en
tiempo real, y paso de la Voz con sin obstáculo, en relación con las aplicaciones de datos resistentes a las caídas. Particularmente, QoS es crucial
en el router de borde de WAN. Allí, cientos de megabits del agregado del tráfico potencial en links más despacio en los kilobites o rango bajo del
Megabits-per-second.
H.323
Muchas aplicaciones de videoconferencia IP utilizan al conjunto de protocolos de H.323. El International Telecommunications Union (ITU)
H.323 define una Norma internacional para las multimedias sobre el IP. El ITU aprobó la primera versión del estándar de H.323 en 1996. La
versión actual es 4. Muchas aplicaciones ahora despliegan comúnmente los sistema de video basados en LAN de H.323. Una aplicación de
ejemplo es el NetMeeting de Microsoft, que utiliza H.323 para el Video conferencia. y la colaboración compartida.
Previamente, sistemas de videoconferencia con el H.320 como a como base son comunes. Cada sistema tenía su propia conexión del Public
Switched Telephone Network (PSTN). Mientras que el lado izquierdo de la figura en esta sección muestra, usted puede utilizar hoy los gateway
de video para comunicación entre la red convergida de H.323 y el red de video heredada. El lado derecho de la figura muestra cómo usted puede
utilizar los adaptador de terminal de video para conectar el seamlessly individual de los puntos finales H.320 en una red de H.323.
Caracterización del tráfico de la videoconferencia
A diferencia de la Voz, el vídeo tiene una velocidad de paquetes muy alta y sumamente variable con una Unidad máxima de transmisión (MTU)
media mucho más alta (MTU). Esta figura ilustra una ruptura del tamaño de paquete típico del tráfico de la videoconferencia:
Una secuencia del tráfico de la videoconferencia consiste en dos tipos de bastidores, pues esta figura ilustra:
“” Enmarco soy una muestra llena del vídeo. Las tramas “P” y “B” utilizan la cuantificación vía los vectores y los algoritmos de predicción del
movimiento.
Planificación de capacidad
Antes de que usted ponga el tráfico de video en una red, asegúrese de que el ancho de banda adecuado exista para todas las aplicaciones
necesarias. Primero, calcule los requisitos de ancho de banda mínimo para cada aplicación importante, por ejemplo, la Voz, el vídeo, y los datos.
La suma representa el requisito de ancho de banda mínimo para cualquier link específico. Esta cantidad debe consumir el no más que 75 por
ciento del ancho de banda total disponible en ese link. Esta regla del 75 por ciento asume que un cierto ancho de banda es necesario para el
tráfico de arriba. Los ejemplos del tráfico de arriba incluyen las actualizaciones del Routing Protocol y acodan 2 Keepalives, así como las
aplicaciones adicionales, tales como email y tráfico HTTP. Haga que la Voz y el tráfico de video ocupen el no más que 33 por ciento de
capacidad del link. Este ejemplo de escenario explica la planificación de capacidad en una red con convergencia.
Situación de ejemplo
Un sitio tiene una capacidad del link del 1.544 Mbps y contiene dos terminal de video que soporten una velocidad de datos máxima 256 del kbps
cada uno. Aunque el índice de los dos kbps video de los iguales 512 de las llamadas, agregue el 20 por ciento a la velocidad de datos de la
llamada para explicar los gastos indirectos. El veinte por ciento es un porcentaje conservador que asegura la planificación de capacidad apropiada
en la mayoría de los entornos. Usted puede comenzar con un suplemento el 20 por ciento para los gastos indirectos y entonces ajustar este valor,
más arriba o bajar, con los resultados de su monitor como base.
Provision el priority queue para que el ancho de banda suficiente permita que ambos terminal de video tengan una llamada activa a través de
WAN simultáneamente sin la posibilidad de un overrun del priority queue. En este ejemplo de escenario, si usted agrega un tercer terminal de
video, usted necesita implementar una cierta forma de CAC.
Determine el consumo de ancho de banda de por llamada
Con la planificación de capacidad, uno de la mayoría de los conceptos críticos a entender es cuánto utiliza el ancho de banda usted para cada
llamada. Esta sección enumera el ancho de banda que cada decodificador del codificador (codificador-decodificador) utiliza. Refiera a la voz
sobre IP - Por el consumo de ancho de banda de la llamada para más información.
H.323 Audio
Las señales de audio contienen digitalizado, sonido comprimido (generalmente discurso). Algoritmos de códec de audio probados soportes del
estándar de ITU de H.323. Los algoritmos con el soporte incluyen:
G.711 — 3.1 kilociclos (kHz) en 48, 56, y 64 kbps (telefonía normal)
G.722 — 7 kHz en 48, 56, y 64 kbps
G.728 — 3.1 kHz en 16 kbps
G.723 — 5.3 y 6.3 modos del kbps
La selección del codificador-decodificador correcto refleja los equilibrios entre la calidad vocal, la velocidad de bits, el poder del cálculo, y el
retraso de la señal.
H.323 Video
Según el estándar de H.323, los capacidad de video en los Terminales H.323 son opcionales. Sin embargo, cuando usted implementa los
Terminales H.323, las terminales deben soportar el codificador-decodificador H.261, con el soporte opcional para el estándar H.263.
H.261 — Códec de video para los servicios audiovisuales en los múltiplos de 64 kbps. Los dispositivos H.261-compliant codifican
completamente las tramas iniciales. Los dispositivos entonces cifran solamente las diferencias entre las tramas iniciales y subsiguientes
para las transmisiones de paquetes mínimas. La compensación de movimiento opcional mejora la calidad de la imagen.
H.263 — Códec de video para el Servicio telefónico sencillo antiguo (POTS) video. El estándar H.263 es una actualización compatible con
versiones anteriores al estándar H.261. El H.263 aumenta perceptiblemente la calidad de la imagen con una técnica de la valoración del
movimiento del mitad-pixel, que es un requisito. Las mejoras también vienen de las tramas previstas y de una Tabla de códigos de
Huffman, con la optimización para las transmisiones del Low Bit Rate. El estándar H.263 define cinco formatos de imagen estándar, como
demostraciones del cuadro 1 en el White Paper del documento: Aplicaciones de H.323 que despliegan en las redes de Cisco.
Clasificación
Para proporcionar las garantías apropiadas de QoS al tráfico de video, necesidad de los dispositivos de red de poder identificar tal tráfico.
El modelo de los Servicios diferenciados (DiffServ) de QoS utiliza los valores del DiffServ Code Point (DSCP) para separar el tráfico en las
clases. El DiffServ define estos dos conjuntos de los valores DSCP:
Expedited forwarding (EF) — Proporciona un solo valor DSCP (101110) que den a paquetes marcados el del más alto nivel del servicio de
la red. Cisco implementa el servicio EF vía el low latency queueing (LLQ). Generalmente, el EF mantiene la cola de alta prioridad muy
pequeña para controlar el retardo y para prevenir el hambre del tráfico de prioridad inferior. Como consecuencia, los paquetes pueden caer,
si la cola es llena. Generalmente, el EF es el más apropiado para el VoIP.
Assured Forwarding (AF) — Proporciona cuatro clases, cada uno con tres Niveles de precedencia del descenso.
Para obtener más información sobre DSCP, consulte Implementación de políticas de calidad de servicio con DSCP.
Generalmente, las guías de diseño de Cisco recomiendan AF41 (valor 100010 DSCP) para el vídeo. No hay ventaja si usted trata la porción audio
de los secuencia de video mejor que los paquete de video en una aplicación de videoconferencia IP. Por lo tanto, utilice el AF41 como el valor
DSCP para ambos medio de video y de voz en un Video conferencia.
En la capa 2, usted puede utilizar los 3 bits del Clase de Servicio (CoS) en el campo del IEEE 802.1P, que es parte de la etiqueta del IEEE
802.1Q.
Actualmente, no hay estándares que describen qué valor es el más apropiado para el Video conferencia. IP. Sin embargo, Cisco recomienda
normalmente este esquema de la marca para las redes multiservicios:
Capa 2
CoS
‘Tipo de tráfico’
Prioridad IP de la capa
3
Capa 3
DSCP
Voz RTP1
5
5
EF
Control de la Voz
3
3
AF31
Video conferencia.
4
4
AF41
Vídeo de flujo continuo
(IP/TV)
1
1
AF13
Datos
0-2
0-2
0-AF23
1
RTP = protocolo Real-Time Transport
Esta tabla asigna el vídeo de flujo continuo y el Video conferencia. los valores separados de la Clasificación y marcado. El vídeo de flujo
continuo tiene una mejor capacidad de mitigar las secuencias y de ocuparse de la fluctuación y retraso. Por lo tanto, el vídeo de flujo continuo
requiere diversos niveles de QoS.
Además, usted puede separar el control y las porciones de datos de las secuencias del Video conferencia. Para separar estas dos porciones de las
secuencias, marque el control con el AF31 y los datos con el AF41. Sin embargo, este diseño no es el mejor diseño. No todos los puntos finales le
permiten a Mark Bearer y al tráfico de control diferentemente, y un proxy de Cisco marca todo el tráfico de la videoconferencia con un valor.
Además, las velocidades de bits del tráfico de control son insignificantes, en relación con las velocidades de bits video de la llamada.
Realice la clasificación tan cerca a la fuente como sea posible. Los Partners video de tercera persona VCON, PictureTel, y Polycom pueden fijar
los bits de precedencia IP. Si su terminal de H.323 no fija ninguna valores de encabezado, usted puede marcar los paquetes en estas puntas en la
red:
Un puerto del switch de la capa 3
Refiera a configurar QoS para más información.
Un router del ½ del ¿Â de Cisco IOSï que utiliza el Marcado basado en clases
Refiera a configurar la marca del paquete en base a la clase para más información.
Un router del Cisco IOS que utiliza la característica de Cisco MCM
Un portero/proxy de H.323 que se ejecuta en un router de WAN remoto
Seleccione un Mecanismo de envío a cola elaborado
El Cisco IOS Software ahora incluye varios Mecanismos para formar la cola. Estos mecanismos cubren las necesidades del tipo de tráfico que
ingresa la red y los media de la área ancha que el tráfico atraviesa. En el campus o WAN, cualquier momento hay una punta de la congestión
potencial en la red, la aplicación de las técnicas de almacenamiento en cola adecuada es necesaria. La cola se asegura de que el retraso y el tráfico
sensible a las caídas, tal como Voz y video en tiempo real, pasen con sin obstáculo, en relación con las aplicaciones de datos resistentes a las
caídas. Una interrupción es típica en el router de borde de WAN. Allí, cientos de megabits del agregado del tráfico potencial en links más
despacio en los kilobites o rango bajo del Megabits-per-second.
Configure los más nuevos métodos de la cola con los comandos del comando line interface(cli) de la Calidad del servicio (QoS) modular (MQC).
Con el MQC, especifique una garantía mínima del ancho de banda con el comando bandwidth. Especifique la prioridad estricta de descenso en
la cola a la cola del nivel de la interfaz con el comando priority. El comando bandwidth implementa el Mecanismo de cola de espera equitativo
y ponderado basado en clases (CBWFQ), y el comando priority implementa el LLQ. Refiera a comparar los comandos bandwidth and priority
de una política de servicio de QoS para más información.
Modelo/esquema de priorización
Cisco recomienda este modelo o esquema de priorización en una red multiservicio:
Tipo del
link de
datos
Versión
mínima
de Cisco
IOS
Software
Clasificación
Priorización
LFI1
Modelado
de tráfico
Líneas
seriales
DSCP = EF para la
Voz; DSCP = AF41
para todo el tráfico de
Cisco IOS
la videoconferencia;
Software
LLQ con el
DSCP = AF31 para el
Release
CBWFQ
tráfico de control de la
12.0(7)T
Voz; otras clases de
tráfico tienen una
clasificación única.
MLP2
Frame
Relay
DSCP = EF para la
Voz; DSCP = AF41
Cisco IOS para el vídeo; DSCP =
Software AF31 para el tráfico
LLQ con el
Release
de control de la Voz; CBWFQ
12.1(2)T otras clases de tráfico
tienen una
clasificación única.
Tráfico de la
dimensión de
FRF.12
una variable
al CIR3.
ATM
DSCP = EF para la
Voz; DSCP = AF41
Cisco IOS para el vídeo; DSCP =
Software AF31 para el tráfico
LLQ con el
Release
de control de la Voz; CBWFQ
12.1(5)T otras clases de tráfico
tienen una
clasificación única.
Tráfico de la
dimensión de
una variable
a la porción
garantizada
de ancho de
banda.
DSCP = EF para la
Voz; DSCP = AF41
MLP
over
ATM
MLP
Forme el
tráfico a la
Cisco IOS
Atmósfera
Software
y Frame
Release
Relay
12.1(5)T
para el vídeo; DSCP =
AF31 para el tráfico
LLQ con el
de control de la Voz; CBWFQ
otras clases de tráfico
tienen una
clasificación única.
1
LFI = fragmentación de link e interpolación
2
MLP = Multilink PPP
3
CIR = committed information rate
porción
over
garantizada
ATM y
de ancho de
Frame
banda en el
Relay
link más
lento.
Esta lista explica algunos puntos claves del esquema de modelo/otorgamiento de prioridad.
Exprese ingresa una cola con las capacidades del Asignación de colas de prioridad (PQ) y recibe un ancho de banda de 48 kbps. El criterio
de entrada de esta cola es el valor DSCP del EF, o un valor de precedencia IP del tráfico 5. superior a 48 descensos del kbps si hay
congestión de la interfaz. Por lo tanto, utilice un mecanismo de control de admisión para asegurarse de que el tráfico no excede este valor.
El tráfico de la videoconferencia ingresa una cola con las capacidades PQ y recibe un ancho de banda de la tarifa de informaciones sobre la
llamada más el 20 por ciento. El criterio de entrada a esta cola es un valor DSCP del AF41, o un valor de precedencia IP del tráfico 4.
superior a la tarifa de informaciones sobre la llamada cae si hay congestión de la interfaz. Por lo tanto, como en el caso de la Voz, usted
debe utilizar un mecanismo de control de admisión para asegurarse de que el tráfico no excede este valor. Utilice el proxy para el acceso de
la cola, determinado si usted no ha configurado la confianza en cada puerto del switch. Para el acceso de la cola en los pequeños sitios con
solamente algunos terminal de video, utilice el Listas de control de acceso (ACL) con la dirección IP del terminal de video como base. El
uso de los ACL protege contra los usuarios del colorete que marcan el tráfico con la Prioridad IP 4. Esta marca desvía el portero, o el CAC,
y afecta a todo el vídeo en el PQ.
Nota: El tráfico de video unidireccional, tal como IP/TV, debe utilizar el CBWFQ vía el comando bandwidth. Las tolerancias de retraso
son más altas.
La congestión de los links PÁLIDOS puede morir de hambre totalmente los protocolos de señalización de control de la Voz. En este caso,
los Teléfonos IP no pueden completar las llamadas a través del IP WAN. El tráfico de protocolo del control de voz, tal como H.323 y el
protocolo skinny client control, requiere sus los propio ponderada de asignación justa de ancho de banda en función de clase cola con un
ancho de banda configurable mínimo igual a un valor DSCP del AF31. Este valor DSCP correlaciona a un valor de precedencia IP de 3.
El tráfico de la Arquitectura de red de sistemas (SNA) ingresa una cola con un ancho de banda especificado de 56 kbps. El funcionamiento
de envío a cola dentro de esta clase es (Primero en Entrar, Primero en Salir FIFO), con una asignación de ancho de banda mínimo de 56
kbps. Trafique en esta clase que exceda 56 kbps ingrese la cola predeterminada. El criterio de entrada a esta cola puede cualquier ser
números del puerto TCP, un direccionamiento de la capa 3, Prioridad IP, o un DSCP.
Todo el tráfico que sigue habiendo puede ingresar una cola predeterminada. Si usted especifica un ancho de banda, el funcionamiento de envío a
cola es (Primero en Entrar, Primero en Salir FIFO). Alternativamente, si usted especifica la palabra clave fair, la operación es Espera equitativa
ponderada (WFQ).
Además, no hace el Video conferencia. sobre las velocidades del link de menos de 768 kbps. En los links del Low Bit Rate, el uso del
Compressed RTP (cRTP) y el LFI pueden reducir los efectos de la serialización y del retardo de colocación en cola.
No utilice el cRTP con los Video conferencia. IP. Esta lista proporciona las mejores prácticas para el cRTP:
Utilice el cRTP solamente con el codecs de la Voz del Low Bit Rate, tal como G.729. Si usted utiliza G.711 pues los códecs de audio para
una llamada de la Voz o de Video conferencia., los aumentos estadísticos de la producción que usted alcanza con el cRTP no son bastante
significativos merecer el uso del cRTP.
Utilice el cRTP solamente cuando la Voz del Low Bit Rate es un porcentaje significativo de la carga ofrecida. Esta característica es
generalmente solamente beneficiosa cuando la Voz del Low Bit Rate es mayor del de 30 por ciento una carga ofrecida a un circuito.
el cRTP puede afectar al rendimiento de reenvío. Monitoree la utilización de la CPU cuando usted ha habilitado la característica.
¿Voz y Video deben compartir LLQ?
Una consideración frecuente con las políticas de servicio multiservicios de QoS es si configurar la Voz y el tráfico de la videoconferencia como
clases de prioridad. Esta consideración viene del hecho de que el LLQ soporta actualmente una sola cola de prioridad estricta, incluso cuando
usted ha configurado las clases múltiples para el priorización. Cuando usted configura el VoIP y las clases video con la prioridad, el tráfico de
ambas clases entra una cola única. Por lo tanto, estas razones pueden hacerle elegir no poner el vídeo en el priority queue:
Los paquete de video son mucho más grandes que los paquetes de voz. Los paquete de video son generalmente tan grandes como la talla
del MTU del link máximo. Con la marca EF, los paquete de video pueden ingresar el mismo priority queue que la Voz. Si un pequeño
paquete de VoIP ingresa la cola detrás de un paquete de video grande, o detrás de varios tales paquetes, el retardo en el paquete de VoIP
aumenta. El retardo puede ser sustancial, y afecta al contrario al rendimiento de las aplicaciones VoIP.
Porque la mayoría de las colas de administración del tráfico EF son muy pequeñas, pueden llevar a la caída de paquetes cuando usted las
utiliza para el tráfico de video.
Cisco ha realizado las pruebas que pusieron el vídeo en el priority queue. Las pruebas estaban con kbps de las velocidades del link mayor de 768
y con el CAC apropiado para evitar el oversubscription. Cisco encontró que el colocación de video en el priority queue no introdujo un notable
aumento en el retardo a los paquetes de voz.
Usted puede seleccionar generalmente uno de estos modelos. Cisco ha probado ambos modelos:
La Voz, el vídeo, y el audio en el priority queue y provision apropiadamente
Voz en el priority queue, con el vídeo y el audio en una cola de ancho de banda
Un tercer acercamiento es separar al componente de audio del Video conferencia. Es decir ponga el componente de audio en el priority queue y el
componente de video en una cola de ancho de banda. Sin embargo, los codificador de video tienden a tener retardos más largos de la codificación
que expresar a los codificadores. Por lo tanto, si usted da las secuencias de audio de una prioridad absoluta del Video conferencia., las secuencias
de audio llegan temprano y se sostienen para alcanzar la sincronización audio/video. Así pues, no hay ventaja si usted coloca los paquetes de voz
asociados a un Video conferencia. en una cola con un mejor servicio que el servicio que los paquete de video reciben.
Si usted elige poner el vídeo y la Voz en el priority queue, marque los tipos de tráfico con diversos valores DSCP. Si usted marca los tipos de
tráfico con diversos valores DSCP, usted puede utilizar una diversa sentencia de prioridad en su política de servicio de QoS para controlar el
vídeo. Particularmente, el vídeo puede requerir un parámetro de ráfaga más grande.
CAC
El priorización del tráfico soluciona solamente a la parte del desafío provisión de Calidad de servicio (QoS) para video encima del IP. Una
solución completa requiere el CAC.
El CAC, o el Control del ancho de banda, es necesarios evitar el oversubscription de los recursos de red. Con la videoconferencia, un rechazo de
un terminal de video que pida a los recursos de red es necesario mantener la calidad de los secuencia de video existentes si la nueva terminal
excede el ancho de banda disponible. Es decir el CAC protege el vídeo contra el vídeo.
Hay generalmente tres esquemas para la disposición CAC para las llamadas video:
Limite el número de terminal de video. Particularmente, en los sitios remotos sin un portero de H.323, hay solamente una manera de
controlar el uso del ancho de banda para video a través de un link determinado, tal como WAN. En este caso, usted necesita limitar
físicamente el número de terminal de video en los sitios remotos. Provision el ancho de banda suficiente en el priority queue para soportar
la velocidad de datos máxima de todos los punto final de video en un sitio particular.
Nota: Provision el priority queue para la velocidad de datos máxima de los terminal de video más el 20 por ciento. El 20 por ciento
adicional permite el IP y el Transport Overhead.
Utilice al portero CAC para fijar los límites del ancho de banda para el interzone y las llamadas del intrazone sobre una base del por
session. Usted puede combinar al portero CAC con un proxy, que proporciona un solo Punto de acceso en el priority queue. Este solo
Punto de acceso previene un oversubscription del priority queue por los secuencia de video desautorizados. Usted debe registrar los
terminal de video con el portero para obtener el acceso al proxy. La configuración de control de acceso permite un ancho de banda de video
máxima fuera de la zona local. Este ancho de banda máximo necesita hacer juego la disposición del ancho de banda del priority queue de
asegurar las funciones de espera apropiadas. Estas guías de consulta se aplican solamente a los entornos del hub and spoke. El modo
directo del uso de los porteros y no permite que los gatekeeperes intermedios deduzcan el ancho de banda de los links.
Implemente los puntos finales para los cuales usted ha habilitado el RSVP. Los puntos finales utilizan los mensajes RSVP para describir el
perfil del tráfico y para pedir el servicio necesario. Los dispositivos de red que reconoce RSVP a lo largo del trayecto de extremo a extremo
leen estos mensajes RSVP y deciden a si conceder o negar la solicitud de reserva. Los dispositivos comunican su decisión al punto final vía
otro mensaje RSVP. El punto final y su aplicación entonces deciden a si adaptarse a los estados de la red disponibles con una
discontinuación de la conferencia o una reducción de los requisitos.
El apéndice II del estándar de la versión 4 de H.323 delinea un acercamiento para el uso del RSVP. Los puntos principales son:
Cuando usted pone una llamada, un punto final comunica la capacidad del punto final de reservar los recursos al portero. El portero
entonces indica si una tentativa de la reserva de recursos del punto final es recomendable.
Durante la fase H.245, los puntos finales indican si pueden señalar las reservas de recursos. Con esta información, los puntos finales
deciden a si proceder con la llamada.
El envío de los mensajes de la Reservación RSVP puede ocurrir después del abierto de los canales lógicos pero antes del uso de los canales
lógicos para los paquetes de datos.
Modelado de tráfico
El uso del Frame Relay para la conectividad WAN introduce otro requisito de QoS. Específicamente, cuando un sitio central más de alta
velocidad alimenta uno o más sitios remotos de velocidad menor, el sitio central puede sobrar el ancho de banda físico y el ancho de banda CIR
del sitio remoto. Para prevenir el envío de demasiado ancho de banda a un sitio remoto, implemente el modelado de tráfico en el router del sitio
central. Refiera a estos recursos para más información sobre el Control de tráfico de Frame Relay:
Configuración del modelado del tráfico de Frame Relay en routers 7200 y plataformas inferiores
VoIP sobre Frame Relay con calidad de servicio (fragmentación, diseño de tráfico y prioridad LLQ / IP RTP)
Interconexión con los terminales H.323
Las redes de videoconferencia de H.323 consisten en típicamente cinco componentes funcionales:
Terminal de video
Porteros
Gateways
MCU
Proxys
Soluciones de producto de las ofertas de Cisco para todos estos componentes, excepto los terminal de video. La prueba muestra que los Productos
de Cisco H.323 interoperan con los Terminales H.323 de tercera persona.
En algunos casos, estas terminales ofrecen las herramientas de QoS para asegurar la satisfacción del retardo y de los parámetros de pérdida del
tráfico de video frente a los flujos de datos imprevisibles. Por ejemplo, el Polycom Viewstation no pierde de vista todos los paquete de video
después del establecimiento de una llamada. El Polycom Viewstation señala latencia promedio así como el número de vídeo o de Paquetes de
audio perdidos. Esta herramienta también soporta los debugs con la salida legible. Estos debugs pueden ayudar a indicar la fuente de un problema
que no sea perceptible con el análisis del salida de video. Para más información, refiera al documento cómo configurar el vídeo sobre el IP para
los unidad de video Polycom.
Configuración de muestra:
Esta configuración de muestra demuestra cómo aplicar el LLQ al tráfico de la videoconferencia que atraviesa un link PÁLIDO:
Configuración de muestra:
Sample Configuration
class-map Video-Conf
match access-group 102
class-map Streaming-Video
match access-group 103
!
policy-map QoS-Policy
class Video-Conf
priority 450 30000
class Streaming-Video
bandwidth 150
class class-default
fair-queue
!
! -- Video-Conf Traffic
access-list 102 permit ip
access-list 102 permit ip
!
! -- Streaming Traffic
access-list 103 permit ip
access-list 103 permit ip
any any dscp cs4
any any dscp af41
any any dscp cs1
any any dscp af13
Después de que usted cree política de calidad de servicio (QoS) una correspondencia, aplique la directiva con el comando service-policy. El tipo
de interfaz a quien usted aplica la directiva determina los lugares de la aplicación del comando. A continuación, se incluyen algunos ejemplos:
Tipo de
interfaz
Ejemplo de configuración
Línea arrendada line interface multilink1
service-policy output QoS-Policy
ATMÓSFERA interface atm 1/0.1 point
pvc 1/50
PVC1
service-policy output QoS-Policy
VC de Frame
Relay2
map-class frame-relay vcofr
frame cir 128000
frame mincir 64000
frame bc 1000
frame frag 160
service-policy output QoS-policy
Nota: En las Cisco 7500 Series con el calidad del servicio (QoS)
distribuida, utilice los comandos DTS3. Refiera al Control de
tráfico de Frame Relay con el calidad del servicio (QoS) distribuida
en las Cisco 7500 Series.
1
PVC = circuito virtual permanente
2
VCS = circuitos virtuales
3
DTS = Distributed Traffic Shaping
Información Relacionada
Estándar ITU H.323
Notas Técnicas de Troubleshooting
© 1992-2016 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generación del PDF: 17 Octubre 2016
http://www.cisco.com/cisco/web/support/LA/102/1026/1026685_video-qos.html