Implementación de Soluciones QoS para Videoconferencia H.323 sobre IP

Introducción

H.323 es el estándar con aceptación global para conferencias multimedia en una red 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.

Prerequisites

Requirements

Quienes lean este documento deben tener conocimiento de los siguientes temas:

• Los componentes de un sistema compatible con H.323. Los componentes incluyen, entre otros, terminales, gateways, gatekeepers, controladores multipunto (MC), procesadores multipunto (MP) y unidades de control multipunto (MCU). Consulte el informe técnico: Implementación de Aplicaciones H.323 en Redes de Cisco para obtener más información.

• Soluciones de videoconferencia Cisco H.323, que incluyen MCU y gateways, así como el gatekeeper y proxy de Multimedia Conference Manager (MCM). Consulte la sección "Información Relacionada" de este documento para obtener enlaces a información sobre las soluciones de videoconferencia de Cisco.

• Diseños de zonas H.323. El grupo de terminales H.323 se produce en zonas, que son comodidades administrativas similares a un sistema de nombres de dominio (DNS). Cada zona tiene un gatekeeper que administra todos los extremos.

• Planes de marcación. Consulte el capítulo 5: Arquitectura de plan de marcación y configuración de la solución Cisco AVVID, telefonía IP: Cisco CallManager versión 3.0(5) para obtener más información.

• Técnicas de control de admisión de llamadas (CAC), que incluyen la señalización de los requisitos de recursos mediante el protocolo de reserva de recursos (RSVP).

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Antecedentes

La mayoría de las redes actuales admiten uno o varios de estos tipos de tráfico de vídeo:

Al mismo tiempo, muchas empresas examinan las infraestructuras de red de datos, voz y vídeo existentes y a menudo independientes para determinar las formas más eficientes de unirlas en una infraestructura IP. En estas redes convergentes, la QoS es obligatoria en cualquier punto de congestión potencial de la red. La QoS garantiza que el tráfico sensible a los retrasos y a las caídas, el vídeo en tiempo real y la voz pasan sin impedimentos, en relación con las aplicaciones de datos tolerantes a las caídas. En particular, la QoS es crucial en el router de extremo de la WAN. Allí, cientos de megabits de tráfico potencial se agregan en enlaces de menor velocidad en los kilobits o en el rango de megabits bajos por segundo.

H.323

Muchas aplicaciones de videoconferencia IP utilizan el conjunto H.323 de protocolos. La Unión Internacional de Telecomunicaciones (ITU) H.323 define un estándar internacional para multimedia sobre IP. La UIT aprobó la primera versión de la norma H.323 en 1996. La versión actual es 4. Muchas aplicaciones ahora suelen implementar sistemas de vídeo H.323 basados en LAN. Una aplicación de ejemplo es Microsoft NetMeeting, que utiliza H.323 para videoconferencias y colaboración compartida.

Anteriormente, los sistemas de videoconferencia con H.320 como base eran comunes. Cada sistema tenía su propia conexión de red telefónica pública conmutada (PSTN). Como se muestra en la parte izquierda de la figura de esta sección, hoy puede utilizar gateways de vídeo para la comunicación entre la red H.323 convergente y la red de vídeo antigua. El lado derecho de la figura muestra cómo puede utilizar adaptadores de terminal de vídeo para vincular terminales H.320 individuales sin problemas en una red H.323.

Caracterización del tráfico de videoconferencia

A diferencia de la voz, el vídeo tiene una velocidad de paquetes muy alta y extremadamente variable con una unidad máxima de transmisión (MTU) de un promedio mucho mayor. Esta figura ilustra un desglose típico del tamaño del paquete del tráfico de videoconferencia:

Una secuencia de tráfico de videoconferencia consta de dos tipos de tramas, como ilustra esta figura:

La trama "I" es una muestra completa del vídeo. Las tramas "P" y "B" utilizan la cuantificación a través de vectores de movimiento y algoritmos de predicción.

Planificación de capacidad

Antes de colocar el tráfico de vídeo en una red, asegúrese de que exista un ancho de banda adecuado para todas las aplicaciones necesarias. En primer lugar, calcule los requisitos mínimos de ancho de banda para cada aplicación principal, por ejemplo, voz, vídeo y datos. La suma representa el requisito de ancho de banda mínimo para cualquier link específico. Esta cantidad no debe consumir más del 75% del ancho de banda total disponible en ese link. Esta regla del 75% supone que se necesita cierto ancho de banda para el tráfico de sobrecarga. Entre los ejemplos de tráfico general se incluyen las actualizaciones de protocolo de ruteo y keepalives de capa 2, así como aplicaciones adicionales, como el tráfico de correo electrónico y HTTP. El tráfico de voz y vídeo no ocupa más del 33% de la capacidad de enlace. Este escenario de ejemplo explica la planificación de capacidad en una red convergente.

Situación de ejemplo

Un sitio tiene una capacidad de enlace de 1.544 Mbps y contiene dos terminales de vídeo que admiten una velocidad de datos máxima de 256 kbps cada uno. Aunque la velocidad de las dos videollamadas es igual a 512 kbps, añada un 20% a la velocidad de datos de la llamada para tener en cuenta la sobrecarga. El 20% es un porcentaje conservador que garantiza una planificación de capacidad adecuada en la mayoría de los entornos. Puede comenzar con un 20% adicional para gastos generales y luego ajustar este valor, mayor o menor, con los resultados de su monitor como base.

Aprovisione la cola de prioridad para que el ancho de banda suficiente permita que ambos terminales de vídeo tengan una llamada activa a través de la WAN simultáneamente sin la posibilidad de una saturación de la cola de prioridad. En este escenario de ejemplo, si agrega un tercer terminal de vídeo, debe implementar alguna forma de CAC.

Determinar el consumo de ancho de banda por llamada

Con la planificación de la capacidad, uno de los conceptos más importantes que hay que comprender es el ancho de banda que se utiliza para cada llamada. Esta sección enumera el ancho de banda que utiliza cada codificador-descodificador (códec). Consulte Voz sobre IP - Consumo de ancho de banda por llamada para obtener más información.

H.323 Audio

Las señales de audio contienen sonido digitalizado y comprimido (normalmente, voz). H.323 admite algoritmos de códec de audio estándar de ITU probados. Los algoritmos compatibles incluyen:

• G.711: 3,1 kilohercios (kHz) a 48, 56 y 64 kbps (telefonía normal)

• G.722: 7 kHz a 48, 56 y 64 kbps

• G.728: 3,1 kHz a 16 kbps

• G.723: modos de 5,3 y 6,3 kbps

La selección del códec correcto refleja las disyuntivas entre la calidad de voz, la velocidad de bits, la potencia informática y el retraso de la señal.

H.323 Video

Según el estándar H.323, las capacidades de vídeo en los terminales H.323 son opcionales. Sin embargo, cuando implementa los terminales H.323, los terminales deben soportar el códec H.261, con soporte opcional para el estándar H.263.

• H.261: códec de vídeo para servicios audiovisuales a múltiplos de 64 kbps. Los dispositivos compatibles con H.261 codifican completamente las tramas iniciales. Los dispositivos luego codifican solamente las diferencias entre las tramas inicial y subsiguientes para las transmisiones mínimas de paquetes. La compensación de movimiento opcional mejora la calidad de la imagen.

• H.263: códec de vídeo para el servicio telefónico antiguo (POTS) de vídeo sencillo. El estándar H.263 es una actualización compatible con versiones anteriores del estándar H.261. H.263 mejora significativamente la calidad de la imagen con una técnica de estimación de movimiento de medio píxel, que es un requisito. Las mejoras también provienen de las tramas previstas y de una tabla de código Huffman, con optimización para transmisiones de baja velocidad de bits. La norma H.263 define cinco formatos de imagen estándar, como se muestra en la tabla 1 del documento Informe técnico: Implementación de Aplicaciones H.323 en Redes de Cisco.

Clasificación

Para proporcionar las garantías de QoS adecuadas al tráfico de vídeo, los dispositivos de red deben poder identificar dicho tráfico.

El modelo de servicios diferenciados (DiffServ) de QoS utiliza valores de punto de código DiffServ (DSCP) para separar el tráfico en clases. DiffServ define estos dos conjuntos de valores DSCP:

• Reenvío acelerado (EF): proporciona un único valor DSCP (101110) que proporciona a los paquetes marcados el mayor nivel de servicio de la red. Cisco implementa el servicio EF mediante la colocación en cola de baja latencia (LLQ). Por lo general, EF mantiene la cola de alta prioridad muy pequeña para controlar el retraso y evitar la inanición del tráfico de menor prioridad. Como resultado, los paquetes pueden caer si la cola está llena. Normalmente, EF es el más apropiado para VoIP.

• Reenvío garantizado (AF): proporciona cuatro clases, cada una con tres niveles de precedencia de descarte.

Para obtener más información sobre DSCP, consulte Implementación de políticas de calidad de servicio con DSCP.

En general, las guías de diseño de Cisco recomiendan AF41 (valor DSCP 100010) para vídeo. No hay ninguna ventaja si se trata la parte de audio de las transmisiones de vídeo mejor que los paquetes de vídeo en una aplicación de videoconferencia IP. Por lo tanto, utilice AF41 como valor DSCP para medios de voz y vídeo en una videoconferencia.

En la capa 2, puede utilizar los 3 bits de clase de servicio (CoS) del campo IEEE 802.1p, que forma parte de la etiqueta IEEE 802.1Q.

Actualmente, no hay estándares que describan qué valor es más apropiado para la videoconferencia IP. Sin embargo, Cisco normalmente recomienda este esquema de marcación para redes multiservicio:

¹ RTP = Protocolo de transporte en tiempo real

Esta tabla asigna valores de clasificación y marcación independientes de transmisión de vídeo y videoconferencia. La transmisión de vídeo ofrece una mejor capacidad para almacenar en búfer las secuencias y hacer frente a los retrasos y las fluctuaciones. Por lo tanto, la transmisión de vídeo requiere diferentes niveles de QoS.

Además, puede separar las porciones de control y datos de las transmisiones de videoconferencia. Para separar estas dos partes de los flujos, marque el control con AF31 y los datos con AF41. Sin embargo, este diseño no es el mejor. No todos los terminales permiten marcar el portador y controlar el tráfico de forma diferente, y un proxy de Cisco marca todo el tráfico de videoconferencia con un valor. Además, las tasas de bits del tráfico de control son insignificantes en relación con las tasas de bits de videollamada.

Realice la clasificación lo más cerca posible del origen. Los partners de vídeo de terceros VCON, PictureTel y Polycom pueden establecer los bits de precedencia IP. Si su terminal H.323 no establece ningún valor de encabezado, puede marcar los paquetes en estos puntos de la red:

• Puerto de switch de capa 3

  Consulte Configuración de QoS para obtener más información.

• ¿Un Cisco IOS? router que utiliza marcado basado en clase

  Refiérase a Configuración de la Marcación de Paquetes Basada en Clase para obtener más información.

• Un router Cisco IOS que utiliza la función Cisco MCM

• Un gatekeeper/proxy H.323 que se ejecuta en un router WAN remoto

Seleccione un mecanismo de cola de espera

Cisco IOS Software ahora incluye varios mecanismos de colocación en cola. Estos mecanismos satisfacen las necesidades del tipo de tráfico que entra en la red y los medios de área extensa que atraviesa el tráfico. En el campus o en la WAN, siempre que haya un punto de congestión potencial en la red, es necesario aplicar las técnicas de colocación en cola adecuadas. La cola garantiza que el tráfico sensible a los retrasos y a las caídas, como la voz y el vídeo en tiempo real, pase sin obstáculos en relación con las aplicaciones de datos tolerantes a las caídas. Una interrupción es típica en el router de extremo de la WAN. Allí, cientos de megabits de tráfico potencial se agregan en enlaces de menor velocidad en los kilobits o en el rango de megabits bajos por segundo.

Configure los métodos de cola más recientes con los comandos de la interfaz de línea de comandos (CLI) de QoS modular (MQC). Con el MQC, especifique una garantía de ancho de banda mínimo con el comando bandwidth. Especifique la eliminación de cola de prioridad estricta a la cola de nivel de interfaz con el comando priority. El comando bandwidth implementa la colocación en cola equilibrada ponderada basada en clases (CBWFQ) y el comando priority implementa la LLQ. Refiérase a Comparación de los Comandos bandwidth y priority de una Política de Servicio QoS para obtener más información.

Modelo/esquema de priorización

Cisco recomienda este modelo o esquema de priorización en una red multiservicio:

¹ LFI = Fragmentación y entrelazado de link

² MLP = PPP de links múltiples

³ CIR = tasa de información comprometida

Esta lista explica algunos puntos clave del esquema de modelo/priorización.

• La voz entra en una cola con funciones de cola de prioridad (PQ) y recibe un ancho de banda de 48 kbps. El criterio de entrada de esta cola es el valor DSCP de EF o un valor de precedencia IP de 5. El tráfico en exceso de 48 kbps cae 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 exceda este valor.

• El tráfico de videoconferencia entra en una cola con funciones PQ y recibe un ancho de banda de la velocidad de datos de llamadas más un 20%. El criterio de entrada a esta cola es un valor DSCP de AF41 o un valor de precedencia IP de 4. El tráfico que excede la velocidad de datos de llamada se descarta si hay congestión de la interfaz. Por lo tanto, como en el caso de la voz, debe utilizar un mecanismo de control de admisión para asegurarse de que el tráfico no exceda este valor. Utilice el proxy para el acceso a la cola, especialmente si no ha configurado la confianza en cada puerto del switch. Para acceder a la cola en sitios pequeños con sólo unos pocos terminales de vídeo, utilice listas de control de acceso (ACL) con la dirección IP del terminal de vídeo como base. El uso de las ACL protege contra los usuarios de router que marcan el tráfico con precedencia IP 4. Esta marca omite el control de acceso o CAC y afecta a todo el vídeo de la PQ.

  Nota: El tráfico de vídeo unidireccional, como IP/TV, debe utilizar CBWFQ a través del comando bandwidth. Las tolerancias de demora son mayores.

• La congestión de los links WAN puede provocar que los protocolos de señalización de control de voz queden completamente vacíos. En este caso, los teléfonos IP no pueden realizar llamadas a través de la WAN IP. El tráfico del protocolo de control de voz, como H.323 y Skinny Client Control Protocol, requiere su propia cola equilibrada ponderada basada en clase con un ancho de banda configurable mínimo igual a un valor DSCP de AF31. Este valor DSCP se correlaciona con un valor de precedencia IP de 3.

• El tráfico de la arquitectura de red de sistemas (SNA) entra en una cola con un ancho de banda especificado de 56 kbps. La operación de colocación en cola dentro de esta clase es FIFO, con una asignación mínima de ancho de banda de 56 kbps. El tráfico en esta clase que excede los 56 kbps ingresa a la cola predeterminada. El criterio de entrada a esta cola puede ser números de puerto TCP, una dirección de Capa 3, precedencia IP o un DSCP.

Todo el tráfico que queda puede ingresar a una cola predeterminada. Si especifica un ancho de banda, la operación de colocación en cola es FIFO. De manera alternativa, si especifica la palabra clave fair, la operación se realiza en cola equilibrada ponderada (WFQ).

Además, no realice videoconferencias con velocidades de enlace inferiores a 768 kbps. En los links de baja velocidad de bits, el uso de RTP comprimidos (cRTP) y LFI puede reducir los efectos de la serialización y el retraso en la cola.

No utilice cRTP con videoconferencias IP. Esta lista proporciona las mejores prácticas para cRTP:

• Utilice cRTP solamente con códecs de voz de baja velocidad de bits, como G.729. Si utiliza G.711 como códec de audio para una llamada de conferencia de voz o de vídeo, las ganancias de rendimiento estadístico que logra con cRTP no son lo suficientemente significativas como para merecer el uso de cRTP.

• Utilice cRTP solamente cuando la voz de baja velocidad de bits sea un porcentaje significativo de la carga ofrecida. En general, esta función solo es beneficiosa cuando la voz de baja velocidad de bits es superior al 30 por ciento de la carga ofrecida en un circuito.

• cRTP puede afectar el rendimiento de reenvío. Controle el uso de la CPU cuando haya habilitado la función.

¿Voz y Video deben compartir LLQ?

Una consideración frecuente con las políticas de servicio QoS multiservicio es si se debe configurar el tráfico de conferencia de voz y vídeo como clases prioritarias. Esta consideración surge del hecho de que LLQ actualmente soporta una sola cola de prioridad estricta, incluso cuando usted ha configurado varias clases para la priorización. Cuando configura las clases de VoIP y vídeo con prioridad, el tráfico de ambas clases pasa a una sola cola. Por lo tanto, estas razones pueden hacer que elija no colocar el vídeo en la cola de prioridad:

• Los paquetes de vídeo son mucho más grandes que los paquetes de voz. Los paquetes de vídeo suelen ser tan grandes como el tamaño máximo de MTU de link. Con la marca EF, los paquetes de vídeo pueden ingresar a la misma cola de prioridad que la voz. Si un paquete VoIP pequeño ingresa a la cola detrás de un paquete de video grande, o detrás de varios de estos paquetes, el retraso en el paquete VoIP aumenta. El retraso puede ser sustancial y afecta negativamente al rendimiento de las aplicaciones VoIP.

• Debido a que la mayoría de las colas EF son muy pequeñas, pueden provocar la caída de paquetes cuando las utiliza para el tráfico de vídeo.

Cisco ha realizado pruebas que colocaban el vídeo en la cola de prioridad. Las pruebas se realizaron con velocidades de enlace superiores a 768 kbps y con CAC adecuado para evitar la sobresuscripción. Cisco descubrió que la colocación del vídeo en la cola de prioridad no introducía un aumento notable de la demora en los paquetes de voz.

En general, puede seleccionar uno de estos modelos. Cisco ha probado ambos modelos:

• Voz, vídeo y audio en la cola de prioridad y aprovisionamiento adecuado

• Voz en cola prioritaria, con vídeo y audio en una cola de ancho de banda

Un tercer enfoque es separar el componente de audio de la videoconferencia. En otras palabras, coloque el componente de audio en la cola de prioridad y el componente de vídeo en una cola de ancho de banda. Sin embargo, los codificadores de vídeo tienden a tener retrasos de codificación más largos que los codificadores de voz. Por lo tanto, si da prioridad absoluta a las transmisiones de audio de una videoconferencia, las transmisiones de audio llegan temprano y se retienen para lograr la sincronización de los labios. Por lo tanto, no hay ninguna ventaja si coloca los paquetes de voz asociados a una videoconferencia en una cola con un mejor servicio que el servicio que reciben los paquetes de vídeo.

Si decide colocar el vídeo y la voz en la cola de prioridad, marque los tipos de tráfico con diferentes valores DSCP. Si marca los tipos de tráfico con diferentes valores DSCP, puede utilizar una sentencia de prioridad diferente en su política de servicio QoS para controlar el vídeo. En particular, el vídeo puede requerir un parámetro de ráfaga más grande.

CAC

La priorización del tráfico solo resuelve parte del desafío del aprovisionamiento de QoS para el vídeo sobre IP. Una solución completa requiere CAC.

CAC, o control de ancho de banda, es necesario para evitar la suscripción excesiva de los recursos de red. Con las videoconferencias, es necesario rechazar un terminal de vídeo que solicita recursos de red para mantener la calidad de las transmisiones de vídeo existentes si el nuevo terminal supera el ancho de banda disponible. En otras palabras, CAC protege el vídeo del vídeo.

En general, hay tres esquemas para la provisión de CAC para videollamadas:

• Limite el número de terminales de vídeo. En particular, en los sitios remotos sin un gatekeeper H.323, sólo hay una manera de controlar el uso del ancho de banda para el vídeo a través de un link determinado, como una WAN. En este caso, debe limitar físicamente el número de terminales de vídeo en sitios remotos. Aprovisionar ancho de banda suficiente en la cola de prioridad para admitir la velocidad máxima de datos de todos los terminales de vídeo en un sitio determinado.

  Nota: Aprovisione la cola de prioridad para la velocidad máxima de datos de los terminales de vídeo más el 20 por ciento. El 20% adicional permite la sobrecarga de IP y transporte.

• Utilice el CAC del gatekeeper para establecer límites de ancho de banda para las llamadas entre zonas e intrazona por sesión. Puede combinar el CAC del gatekeeper con un proxy, que proporciona un único punto de acceso a la cola de prioridad. Este único punto de acceso evita una sobresuscripción de la cola de prioridad por transmisiones de vídeo no autorizadas. Debe registrar los terminales de vídeo con el gatekeeper para obtener acceso al proxy. La configuración del gatekeeper permite un ancho de banda máximo de video fuera de la zona local. Este ancho de banda máximo debe coincidir con la provisión de ancho de banda de la cola de prioridad para garantizar la funcionalidad de colocación en cola adecuada. Estas directrices se aplican únicamente a los entornos radiales y de concentrador. Los gatekeepers utilizan el modo directo y no permiten que los gatekeepers intermedios deduzcan el ancho de banda de los links.

• Implemente los terminales para los que ha activado RSVP. Los terminales utilizan mensajes RSVP para describir el perfil de tráfico y solicitar el servicio necesario. Los dispositivos de red que reconocen RSVP a lo largo de la ruta de extremo a extremo leen estos mensajes RSVP y deciden si se concede o no la solicitud de reserva. Los dispositivos comunican su decisión al terminal a través de otro mensaje RSVP. A continuación, el terminal y su aplicación deciden si se adaptan a las condiciones de red disponibles mediante la interrupción de la conferencia o una reducción de los requisitos.

En el apéndice II de la versión estándar H.323 se describe un enfoque para el uso de RSVP. Los principales puntos son:

• Cuando se realiza una llamada, un punto final comunica la capacidad del punto final para reservar recursos al control de acceso. A continuación, el gatekeeper indica si es aconsejable un intento de reserva de recursos de punto final.

• Durante la fase H.245, los terminales indican si pueden indicar reservas de recursos. Con esta información, los terminales deciden si continuar con la llamada.

• El envío de mensajes de reserva RSVP puede ocurrir después de la apertura 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 de Frame Relay para la conectividad WAN introduce otro requisito de QoS. Específicamente, cuando un sitio central de mayor velocidad alimenta uno o más sitios remotos de menor velocidad, el sitio central puede saturar tanto el ancho de banda físico como el ancho de banda CIR del sitio remoto. Para evitar el envío de demasiado ancho de banda a un sitio remoto, implemente el modelado del tráfico en el router del sitio central. Consulte estos recursos para obtener más información sobre el modelado del tráfico de Frame Relay:

• Configuración del modelado del tráfico de retransmisión de tramas 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 H.323 suelen constar de cinco componentes funcionales:

• Terminales de vídeo

• Gatekeepers

• Gateways

• MCU

• Proxies

Cisco ofrece soluciones de productos para todos estos componentes, excepto terminales de vídeo. La prueba muestra que los productos H.323 de Cisco interoperan con terminales H.323 de terceros.

En algunos casos, estos terminales ofrecen herramientas de QoS para garantizar la satisfacción de los parámetros de demora y pérdida del tráfico de vídeo frente a flujos de datos impredecibles. Por ejemplo, Polycom Viewstation realiza un seguimiento de todos los paquetes de vídeo después del establecimiento de una llamada. Polycom Viewstation informa de latencia media, así como del número de paquetes de audio o vídeo perdidos. Esta herramienta también admite depuraciones con salida legible. Estas depuraciones pueden ayudar a indicar el origen de un problema que no se puede detectar mediante el análisis de la salida de vídeo. Para obtener más información, consulte el documento Cómo configurar el vídeo sobre IP para las unidades de vídeo de Polycom.

Configuración de muestra:

Esta configuración de ejemplo muestra cómo aplicar LLQ al tráfico de videoconferencia que atraviesa un link WAN:

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 any any dscp cs4 
access-list 102 permit ip any any dscp af41 
! 
! -- Streaming Traffic 
access-list 103 permit ip any any dscp cs1 
access-list 103 permit ip any any dscp af13

Después de crear un policy map de QoS, aplique la política con el comando service-policy. El tipo de interfaz a la que se aplica la política determina los lugares de aplicación del comando. A continuación, se incluyen algunos ejemplos:

line interface multilink1 
  service-policy output QoS-Policy 

interface atm 1/0.1 point 
  pvc 1/50 
    service-policy output QoS-Policy

map-class frame-relay vcofr 
  frame cir 128000 
  frame mincir 64000 
  frame bc 1000 
  frame frag 160 
  service-policy output QoS-policy 

¹ PVC = circuito virtual permanente

² VC = circuito virtual

³ DTS = modelado de tráfico distribuido

Información Relacionada

• ITU H.323 Standard
• Control de admisión de llamadas para gateways VoIP H.323
• Descripción de la tecnología de conexión entre redes: Redes de calidad de servicio
• Página de Soporte de Qos (Calidad de Servicio)
• Soporte Técnico - Cisco Systems