Implementar soluções QoS para videoconferências H.323 sobre IP

Introduction

H.323 é o padrão com aceitação global para conferências multimídia em uma rede IP. Este documento discute as ferramentas para implementar a Qualidade de Serviço (QoS) para as videoconferências H.323 em uma WAN empresarial com links de baixa velocidade.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

• Os componentes de um sistema compatível com H.323. Os componentes incluem, entre outros, terminais, gateways, gatekeepers, controladores multiponto (MCs), processadores multiponto (MPs) e unidades de controle multiponto (MCUs). Consulte o white paper: Implantação de aplicativos H.323 em redes Cisco para obter mais informações.

• Soluções de videoconferência Cisco H.323, que incluem MCUs e gateways, bem como o gatekeeper e o proxy do Multimedia Conference Manager (MCM). Consulte a seção "Informações relacionadas" deste documento para obter links para informações sobre as soluções de videoconferência da Cisco.

• Designs de zona H.323. O grupo de endpoints H.323 ocorre em zonas, que são conveniências administrativas semelhantes a um DNS (Domain Name System). Cada zona tem um gatekeeper que gerencia todos os endpoints.

• Planos de discagem. Consulte o Capítulo 5: Arquitetura do plano de discagem e configuração da solução Cisco AVVID, telefonia IP: Cisco CallManager Release 3.0(5) para obter mais informações.

• Técnicas de Controle de Admissão de Chamada (CAC - Call Admission Control), que incluem a sinalização dos requisitos de recursos através do Protocolo de Reserva de Recursos (RSVP - Resource Reservation Protocol).

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

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

Informações de Apoio

A maioria das redes atuais suporta um ou mais destes tipos de tráfego de vídeo:

Ao mesmo tempo, muitas empresas examinam a infraestrutura de rede de dados, voz e vídeo existente e muitas vezes separada para determinar as maneiras mais eficientes de reunir essas redes em uma infraestrutura IP. Nessas redes convergidas, a QoS é obrigatória em qualquer ponto de congestionamento potencial na rede. A QoS garante que o tráfego sensível a retardo e queda, o vídeo em tempo real e a voz passem desimpedidos em relação aos aplicativos de dados tolerantes a descarte. Em particular, a QoS é crucial no roteador de borda da WAN. Lá, centenas de megabits de tráfego potencial se agregam em links de velocidade mais lenta na faixa de quilobits ou megabits por segundo.

H.323

Muitos aplicativos de videoconferência IP usam o conjunto de protocolos H.323. A International Telecommunications Union (ITU) H.323 define um padrão internacional para multimídia sobre IP. A ITU aprovou a primeira versão do padrão H.323 em 1996. A versão atual é 4. Muitos aplicativos agora geralmente implantam sistemas de vídeo H.323 baseados em LAN. Um exemplo de aplicativo é o Microsoft NetMeeting, que utiliza o H.323 para videoconferência e colaboração compartilhada.

Anteriormente, os sistemas de videoconferência com H.320 como base eram comuns. Cada sistema tinha sua própria conexão PSTN (Public Switched Telephone Network, rede de telefonia pública comutada). Como mostra o lado esquerdo da figura nesta seção, hoje você pode usar gateways de vídeo para comunicação entre a rede H.323 convergida e a rede de vídeo legada. O lado direito da figura mostra como você pode usar adaptadores de terminal de vídeo para vincular endpoints H.320 individuais perfeitamente em uma rede H.323.

Caracterização do tráfego de videoconferência

Diferentemente da voz, o vídeo tem uma taxa de pacote muito alta e extremamente variável com uma MTU (Maximum Transmission Unit, unidade máxima de transmissão) média muito mais alta. Esta figura ilustra uma típica divisão de tamanho de pacote do tráfego de videoconferência:

Um fluxo de tráfego de videoconferência consiste em dois tipos de quadros, como ilustra esta figura:

O quadro "I" é um exemplo completo do vídeo. Os quadros "P" e "B" usam a quantificação por meio de vetores de movimento e algoritmos de previsão.

Planejamento de capacidade

Antes de colocar o tráfego de vídeo em uma rede, verifique se há largura de banda adequada para todos os aplicativos necessários. Primeiro, calcule os requisitos mínimos de largura de banda para cada aplicativo principal, por exemplo, voz, vídeo e dados. A soma representa o requisito mínimo de largura de banda para qualquer link específico. Essa quantidade não deve consumir mais de 75% da largura de banda total disponível nesse link. Essa regra de 75% pressupõe que alguma largura de banda é necessária para o tráfego de sobrecarga. Exemplos de tráfego de sobrecarga incluem atualizações do protocolo de roteamento e keepalives da Camada 2, bem como aplicativos adicionais, como e-mail e tráfego HTTP. O tráfego de voz e vídeo não ocupa mais de 33% da capacidade do link. Este cenário de exemplo explica o planejamento de capacidade em uma rede convergida.

Cenário de exemplo

Um local tem uma capacidade de link de 1,544 Mbps e contém dois terminais de vídeo que suportam uma taxa de dados máxima de 256 kbps cada. Embora a taxa das duas chamadas de vídeo seja igual a 512 kbps, adicione 20% à taxa de dados da chamada para considerar a sobrecarga. Vinte por cento é uma porcentagem conservadora que garante o planejamento adequado da capacidade na maioria dos ambientes. Você pode começar com 20% a mais para sobrecarga e depois ajustar esse valor, maior ou menor, com os resultados do seu monitor como base.

Provisione a fila de prioridade para largura de banda suficiente para permitir que ambos os terminais de vídeo tenham uma chamada ativa na WAN simultaneamente, sem a possibilidade de uma saturação da fila de prioridade. Neste cenário de exemplo, se você adicionar um terceiro terminal de vídeo, precisará implementar alguma forma de CAC.

Determinar o consumo de largura de banda por chamada

Com o planejamento de capacidade, um dos conceitos mais importantes a entender é a quantidade de largura de banda usada para cada chamada. Esta seção lista a largura de banda que cada coder-decoder (codec) usa. Consulte Voz sobre IP - Consumo de Largura de Banda por Chamada para obter mais informações.

Áudio H.323

Os sinais de áudio contêm som digitalizado e comprimido (normalmente fala). O H.323 suporta algoritmos de codec de áudio padrão ITU. Os algoritmos com suporte incluem:

• G.711—3,1 kilohertz (kHz) a 48, 56 e 64 kbps (telefonia normal)

• G.722—7 kHz a 48, 56 e 64 kbps

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

• G.723—modos 5.3 e 6.3 kbps

A seleção do codec correto reflete as compensações entre a qualidade da fala, a taxa de bits, a potência de computação e o atraso do sinal.

Vídeo H.323

De acordo com o padrão H.323, os recursos de vídeo em terminais H.323 são opcionais. Entretanto, quando você implementa os terminais H.323, os terminais devem suportar o codec H.261, com suporte opcional para o padrão H.263.

• H.261—Codec de vídeo para serviços audiovisuais em múltiplos de 64 kbps. Os dispositivos compatíveis com H.261 codificam totalmente os quadros iniciais. Em seguida, os dispositivos codificam apenas as diferenças entre os quadros inicial e subsequente para transmissões mínimas de pacotes. A compensação de movimento opcional melhora a qualidade da imagem.

• H.263—Codec de vídeo para POTS (Plain Old Telephone Service) de vídeo. O padrão H.263 é uma atualização compatível com versões anteriores do padrão H.261. O H.263 melhora significativamente a qualidade da imagem com uma técnica de estimativa de movimento de meio pixel, que é um requisito. As melhorias também vêm de quadros previstos e de uma tabela de códigos Huffman, com otimização para transmissões de baixa taxa de bits. O padrão H.263 define cinco formatos de imagem padrão, como mostra a Tabela 1 no documento White Paper: Implantação de aplicativos H.323 em redes Cisco.

Classificação

Para fornecer as garantias de QoS apropriadas para o tráfego de vídeo, os dispositivos de rede precisam ser capazes de identificar esse tráfego.

O modelo de serviços diferenciados (DiffServ) de QoS usa valores de ponto de código (DSCP) do DiffServ para separar o tráfego em classes. O DiffServ define estes dois conjuntos de valores de DSCP:

• Encaminhamento Expedido (EF - Expedited Forwarding)—Fornece um único valor de DSCP (101110) que fornece aos pacotes marcados o mais alto nível de serviço da rede. A Cisco implementa o serviço EF via LLQ (Low Latency Queueing, enfileiramento de baixa latência). Geralmente, o EF mantém a fila de alta prioridade muito pequena para controlar o atraso e evitar a inanição do tráfego de prioridade mais baixa. Como resultado, os pacotes podem cair, se a fila estiver cheia. Geralmente, EF é mais apropriado para VoIP.

• Encaminhamento garantido (AF)—Fornece quatro classes, cada uma com três níveis de precedência de queda.

Para obter informações adicionais sobre DSCP, consulte Implementando a qualidade das políticas de serviço com o DSCP.

Geralmente, os guias de design da Cisco recomendam AF41 (valor DSCP 100010) para vídeo. Não há vantagem se você tratar a parte de áudio dos fluxos de vídeo melhor do que os pacotes de vídeo em um aplicativo de videoconferência IP. Portanto, use AF41 como valor de DSCP para mídia de voz e vídeo em uma videoconferência.

Na camada 2, você pode usar os 3 bits de classe de serviço (CoS) no campo IEEE 802.1p, que faz parte da marca IEEE 802.1Q.

Atualmente, não há padrões que descrevam qual valor é mais apropriado para videoconferência IP. No entanto, a Cisco normalmente recomenda este esquema de marcação para redes multisserviço:

¹ RTP = Protocolo de Transporte em Tempo Real

Esta tabela atribui valores separados de classificação e marcação de streaming de vídeo e videoconferência. O fluxo de vídeo tem uma melhor capacidade de armazenar em buffer fluxos e lidar com retardo e jitter. Portanto, a transmissão de vídeo exige níveis de QoS diferentes.

Além disso, você pode separar as partes de controle e de dados dos fluxos de videoconferência. Para separar estas duas partes dos fluxos, marque o controle com AF31 e os dados com AF41. No entanto, esse projeto não é o melhor. Nem todos os endpoints permitem marcar o portador e controlar o tráfego de forma diferente, e um Cisco Proxy marca todo o tráfego de videoconferência com um valor. Além disso, as taxas de bits de tráfego de controle são insignificantes em relação às taxas de bits da chamada de vídeo.

Realize a classificação o mais perto possível da origem. Parceiros de vídeo de terceiros VCON, PictureTel e Polycom podem definir os bits de precedência de IP. Se o terminal H.323 não definir nenhum valor de cabeçalho, você poderá marcar os pacotes nestes pontos na rede:

• Uma porta de switch de Camada 3

  Consulte Configuração de QoS para obter mais informações.

• Um Cisco IOS? roteador que usa marcação baseada em classe

  Consulte Configuração da Marcação de Pacotes Baseada em Classe para obter mais informações.

• Um roteador Cisco IOS que usa o recurso Cisco MCM

• Um gatekeeper/proxy H.323 executado em um roteador WAN remoto

Selecione um mecanismo de enfileiramento sofisticado

O Cisco IOS Software agora inclui vários mecanismos de enfileiramento. Esses mecanismos atendem às necessidades do tipo de tráfego que entra na rede e dos meios de longa distância que o tráfego atravessa. No campus ou na WAN, sempre que houver um ponto de congestionamento potencial na rede, a aplicação de técnicas de enfileiramento adequadas é necessária. A fila garante que o tráfego sensível a retardo e descarte, como voz e vídeo em tempo real, passe desimpedido em relação aos aplicativos de dados tolerantes a descarte. Uma interrupção é típica no roteador de borda da WAN. Lá, centenas de megabits de tráfego potencial se agregam em links de velocidade mais lenta na faixa de quilobits ou megabits por segundo.

Configure os métodos de fila mais recentes com os comandos da interface de linha de comando (CLI) (CLI) de QoS modular. Com o MQC, especifique uma garantia de largura de banda mínima com o comando bandwidth. Especifique o desenfileiramento de prioridade estrita para a fila de nível de interface com o comando priority. O comando bandwidth implementa CBWFQ (Class-Based Weighted Fair Queueing) e o comando priority implementa LLQ. Consulte Comparando os Comandos de largura de banda e prioridade de uma Política de Serviço de QoS para obter mais informações.

Esquema de modelo/priorização

A Cisco recomenda este modelo ou esquema de priorização em uma rede multisserviço:

¹ LFI = Fragmentação e intercalação de link

² MLP = PPP multilink

³ CIR = taxa de informação comprometida

Esta lista explica alguns pontos principais do modelo/esquema de priorização.

• A voz entra em uma fila com recursos de fila de prioridade (PQ) e recebe uma largura de banda de 48 kbps. O critério de entrada desta fila é o valor DSCP de EF ou um valor de precedência IP de 5. O tráfego acima de 48 kbps cairá se houver congestionamento na interface. Portanto, use um mecanismo de controle de admissão para garantir que o tráfego não exceda esse valor.

• O tráfego de videoconferência entra em uma fila com recursos PQ e recebe uma largura de banda da taxa de dados de chamada mais 20%. O critério de entrada para esta fila é um valor de DSCP AF41 ou um valor de precedência de IP de 4. O tráfego que excede a taxa de dados da chamada cairá se houver congestionamento na interface. Portanto, como no caso da voz, você deve usar um mecanismo de controle de admissão para garantir que o tráfego não exceda esse valor. Use o proxy para acesso à fila, especialmente se você não configurou a confiança em cada porta do switch. Para acesso à fila em locais pequenos com apenas alguns terminais de vídeo, use as ACLs (Access Control Lists, listas de controle de acesso) com o endereço IP do terminal de vídeo como base. O uso de ACLs protege contra usuários de roteamento que marcam o tráfego com precedência de IP 4. Essa marca ignora o gatekeeper, ou CAC, e afeta todo o vídeo no PQ.

  Observação: o tráfego de vídeo unidirecional, como IP/TV, deve usar CBWFQ através do comando bandwidth. As tolerâncias de atraso são mais elevadas.

• O congestionamento dos enlaces de WAN pode sobrecarregar completamente os protocolos de sinalização de controle de voz. Nesse caso, os telefones IP não podem concluir chamadas através da WAN IP. O tráfego do protocolo de controle de voz, como H.323 e o Skinny Client Control Protocol, exige sua própria fila ponderada baseada em classe com uma largura de banda mínima configurável igual a um valor de DSCP AF31. Esse valor de DSCP correlaciona-se a um valor de precedência de IP de 3.

• O tráfego de Arquitetura de Rede de Sistemas (SNA - Systems Network Architecture) entra em uma fila com uma largura de banda especificada de 56 kbps. A operação de enfileiramento dentro dessa classe é FIFO, com uma alocação de largura de banda mínima de 56 kbps. O tráfego nessa classe que excede 56 kbps entra na fila padrão. O critério de entrada para essa fila pode ser números de porta TCP, um endereço de Camada 3, precedência de IP ou um DSCP.

Todo o tráfego restante pode entrar em uma fila padrão. Se você especificar uma largura de banda, a operação de enfileiramento será FIFO. Como alternativa, se você especificar a palavra-chave fair, a operação será Weighted Fair Queuing (WFQ).

Além disso, não faça videoconferência em velocidades de link inferiores a 768 kbps. Em links de taxa de bits baixa, o uso de RTP (cRTP) compactado e LFI pode reduzir os efeitos da serialização e do atraso de enfileiramento.

Não use cRTP com videoconferências IP. Esta lista fornece as melhores práticas para cRTP:

• Use cRTP somente com codecs de voz de baixa taxa de bits, como G.729. Se você usar G.711 como codec de áudio para uma chamada de conferência de voz ou vídeo, os ganhos de rendimento estatístico que você obtém com cRTP não são significativos o suficiente para merecer o uso de cRTP.

• Use cRTP somente quando a voz de baixa taxa de bits for uma porcentagem significativa da carga oferecida. Em geral, esse recurso só é benéfico quando a voz de baixa taxa de bits é maior que 30% da carga oferecida a um circuito.

• cRTP pode afetar o desempenho de encaminhamento. Monitore a utilização da CPU quando tiver ativado o recurso.

A voz e o vídeo devem compartilhar o LLQ?

Uma consideração frequente com as políticas de serviço de QoS multisserviço é configurar o tráfego de conferência de voz e vídeo como classes de prioridade. Essa consideração vem do fato de que o LLQ atualmente suporta uma única fila de prioridade estrita, mesmo quando você configurou várias classes para priorização. Quando você configura as classes de VoIP e vídeo com prioridade, o tráfego dessas duas classes entra em uma única fila. Portanto, esses motivos podem fazer com que você escolha não colocar vídeo na fila de prioridade:

• Os pacotes de vídeo são muito maiores que os pacotes de voz. Em geral, os pacotes de vídeo são tão grandes quanto o tamanho máximo de MTU do link. Com a marca EF, os pacotes de vídeo podem entrar na mesma fila de prioridade que a voz. Se um pequeno pacote VoIP entrar na fila atrás de um grande pacote de vídeo, ou atrás de vários desses pacotes, o atraso no pacote VoIP aumenta. O atraso pode ser substancial e afeta adversamente o desempenho dos aplicativos VoIP.

• Como a maioria das filas EF é muito pequena, elas podem levar à queda de pacotes quando você as usa para tráfego de vídeo.

A Cisco realizou testes que colocaram o vídeo na fila de prioridade. Os testes foram com velocidades de link superiores a 768 kbps e com CAC apropriado para evitar excesso de assinaturas. A Cisco descobriu que a colocação de vídeo na fila de prioridade não apresentou um aumento notável no atraso dos pacotes de voz.

Em geral, você pode selecionar um desses modelos. A Cisco testou ambos os modelos:

• Voz, vídeo e áudio na fila prioritária e provisionamento adequado

• Voz na fila prioritária, com vídeo e áudio em uma fila de largura de banda

Uma terceira abordagem é separar o componente de áudio da videoconferência. Em outras palavras, coloque o componente de áudio na fila de prioridade e o componente de vídeo em uma fila de largura de banda. No entanto, os codificadores de vídeo tendem a ter atrasos de codificação mais longos do que os codificadores de voz. Portanto, se você der prioridade absoluta aos fluxos de áudio de uma videoconferência, os fluxos de áudio chegarão cedo e serão realizados para alcançar a sincronização labial. Portanto, não há vantagem se você colocar pacotes de voz associados a uma videoconferência em uma fila com um serviço melhor do que o serviço que os pacotes de vídeo recebem.

Se você optar por colocar vídeo e voz na fila de prioridade, marque os tipos de tráfego com valores de DSCP diferentes. Se você marcar os tipos de tráfego com valores de DSCP diferentes, poderá usar uma instrução de prioridade diferente em sua política de serviço de QoS para controlar o vídeo. Em particular, o vídeo pode exigir um parâmetro de intermitência maior.

CAC

A priorização do tráfego resolve apenas parte do desafio do provisionamento de QoS para vídeo sobre IP. Uma solução completa requer CAC.

CAC, ou controle de largura de banda, é necessário para evitar a sobreassinatura dos recursos de rede. Com a videoconferência, uma rejeição de um terminal de vídeo que solicita recursos de rede é necessária para manter a qualidade dos fluxos de vídeo existentes se o novo terminal exceder a largura de banda disponível. Em outras palavras, o CAC protege o vídeo do vídeo.

Em geral, há três esquemas de provisão CAC para chamadas de vídeo:

• Limite o número de terminais de vídeo. Em particular, em locais remotos sem um gatekeeper H.323, há apenas uma maneira de controlar o uso da largura de banda para vídeo através de um link específico, como uma WAN. Nesse caso, você precisa limitar fisicamente o número de terminais de vídeo em locais remotos. Provisione largura de banda suficiente na fila de prioridade para suportar a taxa máxima de dados de todos os endpoints de vídeo em um local específico.

  Nota: Provisione a fila de prioridade para a taxa máxima de dados dos terminais de vídeo mais 20%. Os 20% adicionais permitem a sobrecarga de IP e transporte.

• Use o gatekeeper CAC para definir limites de largura de banda para chamadas interzona e intrazona em uma base por sessão. Você pode combinar o gatekeeper CAC com um proxy, que fornece um único ponto de acesso na fila de prioridade. Este único ponto de acesso evita uma sobreassinatura da fila de prioridade por fluxos de vídeo não autorizados. Você deve registrar terminais de vídeo no gatekeeper para obter acesso ao proxy. A configuração do gatekeeper permite uma largura de banda de vídeo máxima fora da zona local. Essa largura de banda máxima precisa corresponder ao provisionamento de largura de banda da fila prioritária para garantir a funcionalidade adequada de enfileiramento. Essas diretrizes aplicam-se somente a ambientes de hub e spoke. Os gatekeepers usam o modo direto e não permitem que os gatekeepers intermediários deduzam a largura de banda dos links.

• Implemente endpoints para os quais você ativou o RSVP. Os endpoints usam mensagens RSVP para descrever o perfil de tráfego e solicitar o serviço necessário. Os dispositivos de rede com reconhecimento de RSVP ao longo do caminho de ponta a ponta leem essas mensagens de RSVP e decidem se devem conceder ou negar a solicitação de reserva. Os dispositivos comunicam sua decisão ao endpoint por meio de outra mensagem RSVP. O endpoint e seu aplicativo decidem se devem se adaptar às condições de rede disponíveis por meio da descontinuação da conferência ou da redução dos requisitos.

O apêndice II do padrão H.323 versão 4 descreve uma abordagem para o uso de RSVP. Os principais pontos são:

• Quando você faz uma chamada, um endpoint comunica a capacidade do endpoint de reservar recursos para o gatekeeper. O gatekeeper então indica se uma tentativa de reserva de recurso de endpoint é aconselhável.

• Durante a fase H.245, os endpoints indicam se podem sinalizar reservas de recursos. Com essas informações, os endpoints decidem se devem continuar a chamada.

• O envio de mensagens de reserva RSVP pode ocorrer após a abertura dos canais lógicos, mas antes do uso dos canais lógicos para pacotes de dados.

Modelagem de tráfego

O uso do Frame Relay para conectividade WAN introduz outro requisito de QoS. Especificamente, quando um site central de alta velocidade alimenta um ou mais locais remotos de baixa velocidade, o site central pode exceder a largura de banda física e a largura de banda CIR do local remoto. Para evitar o envio de muita largura de banda para um local remoto, implemente a modelagem de tráfego no roteador do local central. Consulte estes recursos para obter mais informações sobre a modelagem de tráfego do Frame Relay:

• Configuração da formatação de tráfego frame relay nos roteadores 7200 e nas plataformas inferiores

• VoIP por Frame Relay com qualidade de serviço (fragmentação, modelagem de tráfego, prioridade LLQ/IP RTP)

Interconexão com terminais H.323

As redes de videoconferência H.323 normalmente consistem em cinco componentes funcionais:

• Terminais de vídeo

• Gatekeepers

• Gateways

• MCUs

• Proxies

A Cisco oferece soluções de produto para todos esses componentes, exceto terminais de vídeo. A prova mostra que os produtos Cisco H.323 interoperam com terminais H.323 de terceiros.

Em alguns casos, esses terminais oferecem ferramentas de QoS para garantir a satisfação dos parâmetros de atraso e perda do tráfego de vídeo em face de fluxos de dados imprevisíveis. Por exemplo, a Polycom Viewstation controla todos os pacotes de vídeo após o estabelecimento de uma chamada. A Polycom Viewstation relata a latência média, bem como o número de pacotes de vídeo ou áudio perdidos. Esta ferramenta também suporta depurações com saída legível. Essas depurações podem ajudar a indicar a origem de um problema que não é detectável através da análise da saída de vídeo. Para obter mais informações, consulte o documento How to Configure Video over IP for Polycom Video Units.

Configuração de exemplo

Este exemplo de configuração demonstra como aplicar o LLQ ao tráfego de videoconferência que atravessa um link de 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

Depois de criar um mapa de política de QoS, aplique a política com o comando service-policy. O tipo de interface ao qual você aplica a política determina os locais de aplicação do comando. Aqui estão alguns exemplos:

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 = modelagem de tráfego distribuído

Informações Relacionadas

• Padrão ITU H.323
• Controle de admissão de chamada para gateways VoIP H.323
• Visão geral sobre a tecnologia de comunicação inter-redes Rede de qualidade de serviço
• página de suporte de QoS
• Suporte Técnico - Cisco Systems