Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Diretrizes para projetos de QoS para VoIP em enlaces PPP

Prioridade estrita para tráfego de voz (prioridade de RTP de IP ou LLQ)

Diretrizes de configuração de LLQ

Diretrizes de configuração de prioridade RTP de IP

LFI (Fragmentação e Intercalação de Links) Multilink PPP

Compressed Real-time Protocol (cRTP)

Outras dicas de redução de largura de banda

Diagrama de Rede

Configurações

Comandos de Verificação e Troubleshooting

Exemplo de saída dos comandos show e debug

Informações Relacionadas

Introduction

Esse exemplo de configuração estuda um VoIP com Point to Point Protocol (PPP) por configuração de linha em uso com pouca largura de banda. Este documento inclui informações técnicas de fundo sobre recursos configurados, diretrizes de projeto e verificação básica e estratégias de Troubleshooting.

Observação: é importante observar que na configuração abaixo, os dois roteadores estão conectados back-to-back em uma linha alugada. Na maioria das topologias, no entanto, os roteadores ativados por voz podem existir em todos os locais. Em geral, os roteadores de voz usam conectividade de LAN com outros roteadores que estão conectados à WAN (em outras palavras, uma linha alugada). Isso é importante porque, se os roteadores de voz não estiverem diretamente conectados via PPP em uma linha concedida, todos os comandos de configuração da WAN devem ser configurados em tais roteadores conectados à WAN e não nos roteadores de voz, conforme demonstrado nas configurações abaixo.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As configurações apresentadas neste documento foram testadas com este equipamento:

- Dois Cisco 3640s com Cisco IOS® Software Versão 12.2.6a (IP Plus)

- A prioridade de RTP de IP foi apresentada na versão 12.0(5)T do Cisco IOS.

- O LLQ foi introduzido no Cisco IOS versão 12.0(7)T.

- O recurso LFI foi introduzido no Cisco IOS versão 11.3.

- As versões do Cisco IOS além de 12.0.5T contêm melhorias significativas de desempenho para cRTP.

Conventions

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

Diretrizes para projetos de QoS para VoIP em enlaces PPP

Esta seção fornece diretrizes de projeto para configurar linhas alugadas VoIP sobre PPP (com ênfase em links de baixa velocidade). Há dois requisitos básicos para uma boa qualidade de voz:

- Retardo ponto-a-ponto mínimo e prevenção de tremulação (variação de retardo).

- Requisitos de enlace de largura de banda otimizados e corretamente executados.

Para garantir os requisitos acima referidos, há várias diretrizes importantes que devem ser seguidas:

Diretriz

Descrição

Prioridade estrita para tráfego de voz (prioridade de RTP de IP ou LLQ)

Método para dar prioridade máxima para tráfego de voz.

Fragmentação e Intercalação de Link (LFI)

Pode ser um requisito obrigatório para enlaces de baixa velocidade.

Compactação RTP

Não é necessário para fornecer boa qualidade de voz, mas reduz o consumo de largura de banda para chamadas. A recomendação geral sobre a compactação RTP é aplicá-la depois de ter uma configuração funcional com boa qualidade de voz (simplifica a solução de problemas).

Controle CAC

Não incluído neste documento. O CAC é usado para controlar o número de chamadas que podem ser estabelecidas sobre o enlace. Por exemplo, se o enlace de WAN entre os dois gateways tiver a largura de banda para transportar apenas duas chamadas VoIP, a admissão de uma terceira chamada pode prejudicar a qualidade de voz de todas as três chamadas. Para obter mais informações, consulte: Controle de admissão de chamada VoIP.

Para resumir, para o enlace PPP de baixa velocidade com roteador/gateways como apenas fontes de tráfego de voz, dois recursos são obrigatórios:

1. Prioridade estrita para tráfego de voz

2. Fragmentação e Intercalação de Link (LFI)

Prioridade estrita para tráfego de voz (prioridade de RTP de IP ou LLQ)

A partir do Cisco IOS Software Release 12.2, há dois métodos principais para fornecer prioridade estrita para o tráfego de voz:

- IP RTP Priority (também chamada de PQ/WFQ: Fila de prioridade/Weighted Fair Queuing )

- Enfileiramento de baixa latência (também chamado de PQ/CBWFQ: Priority Queue / Class Based Weighted Fair Queuing).

IP RTP Priority

A Prioridade de RTP de IP cria uma fila de prioridade estrita para um conjunto de fluxos de pacote de RTP que pertencem a um intervalo de portas de destino UDP (User Datagram Protocol). Enquanto as portas reais utilizadas são negociadas dinamicamente entre os dispositivos de ponta ou gateways, todos os produtos Cisco VoIP utilizam a mesma faixa de porta de UDP (16384-32767). Assim que o roteador reconhecer o tráfego VoIP, ele o colocará na estrita fila de prioridade. Quando a fila de prioridade está vazia, as outras filas são processadas de acordo com o WFQ (Weighted Fair Queuing) padrão. A prioridade de RTP IP não se torna ativa até que haja congestionamento na interface. Esta imagem ilustra a operação da Prioridade RTP IP:

Observação: a prioridade RTP de IP permite a intermitência da fila de prioridade (PQ) quando há largura de banda disponível na fila padrão (WFQ), mas policia rigorosamente o conteúdo da fila de prioridade quando há congestionamento na interface.

Enfileiramento de latência baixa

LLQ é um recurso que fornece um PQ estrito para o CBWFQ (Class-Based Weighted Fair Queuing). O LLQ habilita um único PQ estrito dentro do CBWFQ no nível de classe. Com o LLQ, os dados sensíveis a retardo (no PQ) são retirados da fila e enviados primeiro. Em um VoIP com implementação LLQ, o tráfego de voz é colocado no PQ estrito.

O PQ é vigiado para garantir que as filas justas não tenham necessidade de largura de banda. Ao configurar o PQ, você especifica em Kbps a quantidade máxima de largura de banda disponível para o PQ. Quando a interface estiver congestionada, o PQ receberá o serviço até que a carga atinja o valor de Kbps configurado na declaração da prioridade. O tráfego excedente é descartado para evitar problemas com o recurso de enfraquecimento das filas de menor prioridade do grupo de prioridade herdado da Cisco.

Este método é mais complexo e flexível que a prioridade de RTP de IP. A opção entre os métodos deve ter como base os padrões de tráfego na sua rede real e nas suas necessidades reais.

Comparação entre o LLQ e a prioridade RTP de IP

Esta tabela resume as principais diferenças entre LLQ e IP RTP Priority e fornece algumas diretrizes de quando usar cada método.

Enfileiramento de baixa latência (LLQ - Low Latency Queuing)

IP RTP Priority

Comparar tráfego de voz com base em:

- Listas de acesso (para faixa de portas UDP, endereços de hosts, campos ToS de cabeçalho de IP): Precedência de IP, DSCP e mais)

- Intervalo de porta IP RTP

- Campos ToS (Type of Service) de IP: DCSP e/ou precedência do IP

- Protocolos e interfaces de entrada

- Todos os critérios válidos de verificação de repetição de dados usados no CBWFQ

Vantagens:

- Mais flexibilidade em como o tráfego é correspondido e direcionado para PQ e CBWFQ estritos

- Pode configurar classes adicionais para garantir largura de banda para outro tráfego, como: Sinalização e vídeo de VoIP.

Desvantagens:

- Configuração complexa

Comparar tráfego de voz com base em:

- Com base no intervalo de portas UDP RTP: 16384-32767

Vantagens:

- Configuração simples

Desvantagens:

- Tráfego RTCP (Sinalização VoIP) atendido na fila WFQ
Observação: o protocolo RTP usa RTCP (Real Time Control Protocol) para controlar a entrega de pacotes RTP. Embora as portas RTP usem números pares, as portas RTCP usam números ímpares no intervalo de 16384-32767. A IP RTP Priority coloca portas RTP no PQ, enquanto as portas RTCP são atendidas no WFQ (Weighted Fair Queuing) padrão.

- Serve o tráfego VoIP no PQ, mas qualquer outro tráfego que precise de tratamento preferencial e garantia de largura de banda é atendido no WFQ. Enquanto o WFQ pode diferenciar fluxos com pesos (com base na precedência IP), ele não pode garantir que a largura de banda para qualquer fluxo.

Diretrizes

- A escolha entre eles deve ser baseada nos padrões de tráfego na rede real e nas necessidades verdadeiras.

- Se você precisar fornecer prioridade estrita ao tráfego de voz e outro tráfego puder ser tratado como um único tipo (dados), a Prioridade RTP de IP fará um bom trabalho para sua rede com uma configuração simples.

- Se você planeja priorizar o tráfego de voz com base em critérios diferentes das portas UDP (por exemplo, PHB de DiffServ), o LLQ é necessário.

Para obter mais informações sobre a correlação e as diferenças dos métodos de enfileiramento, consulte a Visão geral do gerenciamento de congestionamento.

Diretrizes de configuração de LLQ

Siga estas instruções para configurar o LLQ:

1. Crie um mapa de classe para tráfego VoIP e defina critérios de correspondência

Estes comandos explicam como concluir esta tarefa:

maui-voip-sj(config)#class-map ?

WORD  class-map name

match-all  Logical-AND all matching statements under this classmap

match-any  Logical-OR all matching statements under this classmap

maui-voip-sj(config)#class-map match-all voice-traffic

!-- Choose a descriptive class_name.

maui-voip-sj(config-cmap)#match ?

access-group         Access group

any                  Any packets

class-map            Class map

cos                  IEEE 802.1Q/ISL class of service/user priority values

destination-address  Destination address

input-interface      Select an input interface to match

ip                   IP specific values

mpls                 Multi Protocol Label Switching specific values

not                  Negate this match result

protocol             Protocol

qos-group            Qos-group

source-address       Source address

!-- In this example, the access-group matching option is used for its !-- flexibility (it uses an access-list)

maui-voip-sj(config-cmap)#match access-group ?

<1-2699>  Access list index  name      Named Access List

maui-voip-sj(config-cmap)#match access-group 102

!-- Now, create the access-list to match the class-map access-group:

maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776

!-- Safest and easiest way is to match with UDP port range 16384-32767 !-- This is the port range Cisco IOS H.323 products utilize to transmit !-- VoIP packets.

Essas listas de acesso também podem ser usadas para corresponder o tráfego de voz com o comando match access-group:

access-list 102 permit udp any any precedence critical

!-- This list filters traffic based on the IP packet TOS: Precedence field.

!-- Note: Ensure that other non-voice traffic does NOT uses the

!-- same precedence value.

access-list 102 permit udp any any dscp ef

!-- In order for this list to work, ensure that VoIP packets are tagged with

!-- the dscp ef code before they exit on the LLQ WAN interface.

!-- For more information on DSCP refer to:

!-- Implementing Quality of Service Policies with DSCP

!-- Note: If endpoints are not trusted on their packet marking, you can mark

!-- incoming traffic by applying an inbound service policy on an inbound

!-- interface. This procedure is out of the scope of this doc.

Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1

!-- This access-list can be used in cases where the VoIP devices cannot !-- do precedence or dscp marking and you cannot determine the !-- VoIP UDP port range.

Estes são outros métodos correspondentes que podem ser usados em vez de grupos de acesso:

- A funcionalidade IP RTP Priority passou a ser implementada para LLQ a partir da Versão 12.1.2.T do Cisco IOS. Este recurso corresponde ao conteúdo de classe de prioridade, ao observar as portas UDP configuradas, e está sujeito à limitação de servir somente as portas pares da PQ.

class-map voice

match ip rtp 16384 16383

- Esses dois métodos operam sob o pressuposto de que os pacotes VoIP são marcados nos hosts de origem, ou correspondem e são marcados no roteador antes de aplicar a operação LLQ de saída.

class-map voice

match ip precedence 5

or

class-map voice

match ip dscp ef

Observação: começando com o IOS versão 12.2.2T, os peers de discagem VoIP podem marcar o portador de voz e os pacotes de sinalização antes da operação de LLQ. Isto permite uma maneira escalável de marcar e corresponder pacotes VoIP por meio de valores de código DHCP para LLQ.

2. Crie um mapa de classe para sinalização de VoIP e defina critérios de verificação de repetição de dados (Opcional)

Estes comandos explicam como concluir esta tarefa:

class-map voice-signaling

match access-group 103

!

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

Observação: as chamadas VoIP podem ser estabelecidas usando H.323, SIP, MGCP ou Skinny (Protocolo proprietário usado pelo Cisco Call Manager). O exemplo acima pressupõe o H.323 Fast Connect. Esta lista serve como referência para as portas usadas pelos canais de sinalização/controle de VoIP:

- H.323/H.225 = TCP 1720

- H.323/H.245 = TCP 11xxx (conexão padrão)

- H.323/H.245 = TCP 1720 (Fast Connect)

- H.323/H.225 RAS = TCP 1719

- Skinny = TCP 2000-2002 (CM Encore)

- ICCP = TCP 8001-8002 (CM Encore)

- MGCP = UDP 2427, TCP 2428 (CM Encore)

- SIP= UDP 5060, TCP 5060 (configurável)

3. Crie um mapa de política e associe-se aos mapas de classe VoIP

A finalidade do mapa de política é definir como os recursos de link são compartilhados ou atribuídos às diferentes classes de mapa. Estes comandos explicam como concluir esta tarefa:

maui-voip-sj(config)#policy-map VOICE-POLICY

!-- Choose a descriptive policy_map_name.

maui-voip-sj(config-pmap)#class voice-traffic

maui-voip-sj(config-pmap-c)#priority ?

<8-2000000>  Kilo Bits per second

!-- Configure the voice-traffic class to the strict priority !-- Queue (priority command) and assign the bandwidth.

maui-voip-sj(config-pmap)#class voice-signaling

maui-voip-sj(config-pmap-c)#bandwidth 8

!-- Assign 8 Kbps to the voice-signaling class

maui-voip-sj(config-pmap)#class class-default

maui-voip-sj(config-pmap-c)#fair-queue

!-- The remaining data traffic is treated as Weighted Fair Queue

Observação: embora seja possível enfileirar vários tipos de tráfego em tempo real para o PQ, a Cisco recomenda que você direcione apenas o tráfego de voz para ele. O tráfego em tempo real, como o vídeo, pode introduzir variação no atraso (o PQ é um FIFO - First In First Out - queue). O tráfego de voz exige que o atraso não seja variável para evitar tremulação.

Observação: a soma dos valores das instruções priority e bandwidth precisa ser menor ou igual a 75% da largura de banda do link. Do contrário, a política de serviço não pode ser atribuída ao link (para visualizar as mensagens de erro, certifique-se de que o console de registro esteja habilitado para acesso ao console e o monitor terminal esteja habilitado para acesso telnet).

Observação: ao configurar VoIP em um link de 64 Kbps para suportar duas chamadas de voz, é comum alocar mais de 75% (48 Kbps) da largura de banda do link para o PQ. Nesses casos, você pode usar o comando max-reserved-bandwidth 80 para aumentar a largura de banda disponível para 80% (51 Kbps).

Para obter mais informações sobre os comandos bandwidth e priority, consulte Comparando os comandos bandwidth e priority de uma política de serviços de QoS.

4. Habilitar LLQ: Aplicar o mapa de política à interface WAN externa

Estes comandos explicam como concluir esta tarefa:

maui-voip-sj(config)#interface multilink 1

maui-voip-sj(config-if)#service-policy output VOICE-POLICY

!-- In this scenario (MLPPP LFI), the service policy is applied to !-- the Multilink interface.

Diretrizes de configuração de prioridade RTP de IP

Para configurar a Prioridade RTP IP, use estas diretrizes:

- Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth

Comando

Descrição

starting-rtp-port-number

Limite inferior da porta UDP. O número de porta mais baixo para o qual os pacotes são enviados. Para VoIP, defina esse valor como 16384.

port-number-range

O intervalo de portas de destino UDP. Um número, que foi adicionado ao número de porta de início-rtp, resulta no maior número de porta UDP. Para VoIP, defina esse valor como 16383 (32767 - 16384 = 16383)

bandwidth

Largura de banda máxima permitida (kbps) na fila de prioridade. Defina esse número de acordo com o número de chamadas simultâneas suportadas pelo sistema.

Configuração de exemplo:

interface Multilink1

!--- Some output omitted

bandwidth 64

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression

fair-queue

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

ip rtp priority 16384 16383 45

LFI (Fragmentação e Intercalação de Links) Multilink PPP

Enquanto 1500 bytes é um tamanho comum para os pacotes de dados, um pacote VoIP típico (carregando estruturas de vozes G.729) pode ser de aproximadamente 66 bytes (virulência de voz de 20 bytes, cabeçalho de camada 2 de 6 bytes, cabeçalho RTP & UDP de 20 bytes e cabeçalho IP de 20 bytes).

Agora, imagine um link de linha em uso 56Kbps no qual coexistem tráfego de dados e de voz. Se um pacote de voz estiver pronto para ser serializado apenas quando um pacote de dados começar a ser transmitido no enlace, há um problema. O pacote de voz sensível a retardo deve aguardar 214 ms antes de ser transmitido (leva 214 ms para serializar um pacote de 1.500 bytes em um link de 56 Kbps).

Como você pode ver, os pacotes grandes de dados podem atrasar a entrega de pequenos pacotes de voz, reduzindo a qualidade do discurso. Fragmentar esses grandes pacotes de dados em pacotes menores e intercalar pacotes de voz entre os fragmentos reduz o atraso e o jitter. O recurso LFI (Fragmentação e intercalação de link) do Cisco IOS ajuda a atender os requisitos de entrega em tempo real de VoIP. Esta imagem ilustra a operação do LFI:

Conforme indicado na Tabela 1, a quantidade de atrasos de serialização (o tempo necessário para colocar de fato os bits na interface) introduzidos nos enlaces WAN de baixa velocidade pode ser significativa, considerando que a meta do atraso unidirecional de ponta a ponta não deve exceder 150 ms. (Recomendação ITU-T G.114 especifica um máximo de 150 ms de ponta a ponta.)

Tabela 1. Atraso de serialização para vários tamanhos de quadro em atraso de serialização de links de baixa velocidade = tamanho do quadro (bits)/largura de banda do link (bps)

1 Byte

64 bytes

128 Bytes

256 Bytes

512 Bytes

1024 bytes

1500 Bytes

56 Kbps

143 us

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 kbps

125 us

8 ms

16 ms

32 ms

64 ms

126 ms

187 ms

128 Kbps

62.5 us

4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 kbps

31 us

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 Kbps

15.5 us

1 ms

2 ms

4 ms

8 ms

16 ms

32 ms

768 Kbps

10 us

640 us

1,28 ms

2,56 ms

5,12 ms

10,24 ms

15 ms

1536 Kbps

5 us

320 us

640 us

1,28 ms

2,56 ms

5,12 ms

7,5 ms

Observação: para aplicativos de voz, o retardo de serialização recomendado (por salto) é de 10 ms e não deve exceder 20 ms.

O tamanho do fragmento do enlace é configurável em medições de tempo de milissegundos (ms) com o comando ppp multilink fragment-delay. LFI requer que o multilink ppp seja configurado na interface com a intercalação de multilink ppp ativada. Para obter mais informações sobre como configurar o LFI, consulte a seção deste documento.

Observação: nos casos em que você tem mais de uma conexão T1 metade dedicada (768 Kbps), você não precisa de um recurso de fragmentação. (No entanto, você ainda precisa de um mecanismo de QoS, como LLQ ou IP RTP Priority). O half T1 oferece largura de banda suficiente para permitir que os pacotes de voz entrem e saiam da fila sem problemas de atraso. Além disso, talvez não seja necessário usar o Compression for Real-time Protocol (cRTP), que ajuda a conservar a largura de banda por meio da compactação de cabeçalhos RTP IP, no caso de uma metade de T1.

Compressed Real-time Protocol (cRTP)

Observação: cRTP não é necessário para garantir boa qualidade de voz. É um recurso que reduz o consumo de largura de banda. Configure cRTP depois de todas as outras condições serem atendidas e a qualidade de voz ser boa. Esse procedimento pode economizar tempo no Troubleshooting, isolando os problemas potenciais de cRTP.

Com base no RFC 2508, o recurso de compactação de cabeçalho RTP compacta o cabeçalho IP/UDP/RTP de 40 bytes para 2 ou 4 bytes, reduzindo o consumo desnecessário de largura de banda. É um esquema de compressão salto a salto; portanto, o cRTP deve ser configurado nas duas extremidades do link (a menos que a opção passiva esteja configurada). Para configurar o cRTP, use este comando no nível da interface:

- Router(config-if)#ip rtp header-compression [passive]

Como o processo de compressão pode ser de CPU intenso, a compressão do cabeçalho de RTP é implementada nos caminhos de switching rápida e de switching de CEF, como na versão 12.0.(7)T do Cisco IOS. Às vezes, essas implementações são interrompidas e, em seguida, a única maneira de funcionar será processada comutada. A Cisco recomenda o uso de cRTP somente com enlaces menores que 768 Kbps, a menos que o roteador esteja executando em baixa taxa de utilização da CPU. Monitore a utilização da CPU dos roteadores e desabilite o cRTP, se ela estiver acima de 75%.

Observação: quando você configura o comando ip rtp header-compression, o roteador adiciona o comando ip tcp header-compression à configuração por padrão. Isso é usado para compactar os pacotes TCP/IP dos cabeçalhos. A compactação de cabeçalho é particularmente útil em redes com uma grande porcentagem de pacotes pequenos, como aqueles que suportam muitas conexões Telnet. A técnica de compactação de cabeçalho TCP, descrita totalmente na RFC 1144, é suportada em linhas seriais usando encapsulamento HDLC ou PPP.

Para compactar os cabeçalhos TCP sem habilitar o cRTP, use este comando:

- Router(config-if)#ip tcp header-compression [passive]

Para obter mais informações: Protocolo de Transporte em Tempo Real Compactado

Outras dicas de redução de largura de banda

- Usar codec (low-bit-rate coder/decoders) nos trechos de chamada VoIP; G.729 (8 Kbps) é recomendado. (Este é o codec padrão nos peers de discagem VoIP). Para configurar codecs diferentes, use o comando router(config-dial-peer)#codec no peer de discagem voip desejado.

- Embora DTMF (Dual Tone Multifrequency) seja normalmente transportada com precisão ao usar high-bit-rate voice codecs como G.711, low-bit-rate codecs (como G.729 e G.723.1) são altamente otimizados para padrões de voz e tendem a distorcer tons DTMF. Esta abordagem pode resultar em problemas durante o acessar a sistemas de Resposta de Voz Interativa (IVR). O comando dtmf relay resolve o problema da distorção DTMF transportando os tons de DTMF para "fora da banda" ou separados do fluxo de voz codificado. Se codecs de taxa de bits baixa (G.729, G.723) forem usados, ative o relay dtmf no peer de discagem VoIP.

- Uma conversação típica pode conter de 35 a 50 por cento de silêncio. Com VAD (Voice Activity Detection), os pacotes de silêncio são suprimidos. Para o planejamento de largura de banda de VoIP, suponha que o VAD reduza a largura de banda em 35%. VAD é configurado por padrão nos correspondentes de discagem VoIP. Para habilitar ou desabilitar o VAD, use os comandos router(config-dial-peer)#vad e router(config-dial-peer)# no vad nos peers de discagem voip desejados.

Diagrama de Rede

Configurações

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec

!-- < Some output omitted >

!

hostname maui-voip-sj

!

ip subnet-zero

!

no ip domain-lookup

!

!-- Definition of the voice signaling and traffic class maps !-- "voice-traffic" class uses access-list 102 for its matching criteria. !-- "voice-signaling" class uses access-list 103 for its matching criteria.

Class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

!-- The policy-map defines how the link resources are assigned !-- to the different map classes. In this configuration, strict priority !-- queue is assigned to "voice-traffic" class with (based on ACL in !-- class voice) with max bandwidth = 45 Kbps.

policy-map VOICE-POLICY

class voice-traffic

priority 48

class voice-signaling

bandwidth 8

!-- Assigns a queue for "voice-signaling" traffic that ensures 8 Kbps. !-- Note that this is optional and has nothing to do with good voice !-- quality, but rather a way to secure signaling.

class class-default

fair-queue

!-- The class-default class is used to classify traffic that does !-- not fall into one of the defined classes. !-- The fair-queue command associates the default class WFQ queueing.

!

call rsvp-sync

!

!-- Note that MLPPP is strictly an LFI mechanism. It does not !-- bundle multiple serial interfaces to the same virtual interface as !-- the name stands (This bundling is done for data and NOT recommended !-- for voice). The end result may manifest itself as jitter and no audio.

interface Multilink1

ip address 172.22.130.1 255.255.255.252

ip tcp header-compression iphc-format

service-policy output VOICE-POLICY

!-- LLQ is an outbound operation and applied to the outbound WAN !-- interface.

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

!-- The configured value of 10 sets the fragment size such that !-- all fragments have a 10 ms maximum serialization delay.

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!

interface Ethernet0/0

ip address 172.22.113.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

!-- the bandwidth command needs to be set correctly for the !-- right fragment size to be calculated.

no ip address

encapsulation ppp

clockrate 128000

ppp multilink

multilink-group 1

!-- This command links the multilink interface to the physical !-- serial interface.

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

!-- access-list 102 matches VoIP traffic based on the UDP port range. !-- Both odd and even ports are put into the PQ. !-- access-list 103 is used to match VoIP signaling protocol. In this !-- case, H.323 V2 with fast start feature is used.

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 5000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 6000

session target ipv4:172.22.130.2

maui-voip-austin (Cisco 3640)

version 12.2

service timestamps debug datetime msec

!

hostname maui-voip-austin

!

boot system flash slot1:c3640-is-mz.122-6a.bin

!

ip subnet-zero

!

class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

policy-map voice-policy

class voice-signaling

bandwidth 8

class voice-traffic

priority 48

class class-default

fair-queue

!

interface Multilink1

bandwidth 128

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression iphc-format

service-policy output voice-policy

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!-- Configure cRTP after you have a working configuration. !-- This helps isolate potential cRTP issues.

!

Interface Ethernet0/0

ip address 172.22.112.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

no ip address

encapsulation ppp

no ip mroute-cache

ppp multilink

multilink-group 1

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 6000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 5000

session target ipv4:172.22.130.1

Comandos de Verificação e Troubleshooting

Antes de tentar qualquer comando debug, consulte Informações importantes sobre comandos debug. Para obter mais informações sobre os comandos listados aqui, consulte a seção Exemplo de saída de show e debug deste documento.

Comandos da interface:

- show interface [serial | multilink] — Use este comando para verificar o status da interface serial. Verifique se as interfaces serial e multilink estão ativas e abertas.

- Troubleshooting de Linhas Seriais

Comandos LFI:

- show ppp multilink — Esse comando exibe informações de pacote para os conjuntos de PPP multilink.

- debug ppp multilink fragments —Este comando debug exibe informações sobre fragmentos individuais de multilink e eventos de intercalação. Essa saída de comando também identifica o número de sequência do pacote e os tamanhos do fragmento.

Comandos de prioridade LLQ/IP RTP:

- show policy-map interface multilink interface# —Este comando é muito útil para ver a operação de LLQ e para ver qualquer queda no PQ. Para obter informações adicionais sobre os diversos campos nesse comando, consulte Entendendo os contadores de pacote na Saída show policy-map interface.

- show policy-map policy_map_name —Este comando exibe informações sobre a configuração do mapa de políticas.

- show queue interface-type interface-number —Este comando lista a configuração e as estatísticas de um enfileiramento justo para uma interface específica.

- Debug priority — Este comando debug exibe eventos de fila de prioridade e mostra se o descarte ocorre nessa fila. Consulte também Troubleshooting de Quedas de Saída com Priority Queuing.

- show class-map class_name —Este comando exibe informações sobre a configuração do mapa de classe.

- show call ative voice — Este comando é útil para verificar se há pacotes perdidos no nível de DSP.

Outros Comandos/Referências:

- show ip rtp header-compression — Este comando exibe estatísticas de compactação de cabeçalho RTP.

- Noções básicas sobre solução de problemas e depuração de chamadas VoIP

- Comandos de debug VoIP

Problemas conhecidos:

- CSCds43465: "LLQ, Policer, Shaper should Take CRTP Compression Feedback" Para exibir as notas de versão, consulte o Bug ToolKit (somente clientes registrados) .

Diretrizes:

Aqui estão algumas etapas básicas de solução de problemas, depois que o link ppp estiver ativo e em execução (MLPPP, Fragmentação, Intercalação):

1. show call ative voice — Use para verificar os pacotes perdidos no nível DSP.

2. show interface —Use para verificar se há problemas gerais de linha serial ou de interface. Quedas na interface não significam um problema ainda, mas é preferível derrubar o pacote na fila de prioridade baixa antes de atingir a fila da interface.

3. show policy-map interface —Use para verificar as quedas de LLQ e a configuração de enfileiramento. Não deve relatar quedas que violem a política.

4. show ip rtp header-compression — Use para verificar problemas específicos de cRTP.

Exemplo de saída dos comandos show e debug

!----------------------------------------------- !-----------------------------------------------  !---- To capture sections of this output, the LLQ PQ bandwidth !---- was lowered and large data traffic was placed !---- on the link to force some packets drops. !----------------------------------------------- !----------------------------------------------- !---- Packet Drop Verification (During an Active Call) !--- Assuming your ppp link is up and running, the first step of voice !--- quality problems verification is to check for lost packets !--- at the DSP. Note: Use the show call active voice command !--- NOT show call active voice brief

maui-voip-austin#show call active voice

Total call-legs: 2

!--- Indicates that the connection is established and both legs exist

GENERIC:

SetupTime=155218260 ms

Index=1

PeerAddress=5000

PeerSubAddress=

PeerId=2

PeerIfIndex=13

LogicalIfIndex=0

ConnectTime=155218364

CallDuration=00:00:27

CallState=4

!--- indicates that it is the active call !--- (#define D_callActiveCallState_active 4).

CallOrigin=2

ChargedUnits=0

InfoType=2

TransmitPackets=365

TransmitBytes=7300

ReceivePackets=229

ReceiveBytes=4580

VOIP:

!--- For this call, this was the terminating gateway. !--- At this gateway, the call started at the VoIP leg.

ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

RemoteIPAddress=172.22.130.1

!--- Indicates from which IP address the RTP stream is originating.

RemoteUDPPort=18778

RemoteSignallingIPAddress=172.22.130.1

!--- Indicates from which IP address signaling messages are coming.

RemoteSignallingPort=11010

RemoteMediaIPAddress=172.22.130.1

RemoteMediaPort=18778

RoundTripDelay=50 ms

SelectedQoS=best-effort

tx_DtmfRelay=inband-voice

FastConnect=TRUE

Separate H245 Connection=FALSE

H245 Tunneling=FALSE

SessionProtocol=cisco

SessionTarget=

OnTimeRvPlayout=4570

GapFillWithSilence=20 ms

GapFillWithPrediction=1840 ms

GapFillWithInterpolation=0 ms

GapFillWithRedundancy=0 ms

HiWaterPlayoutDelay=70 ms

LoWaterPlayoutDelay=51 ms

ReceiveDelay=51 ms

LostPackets=90

EarlyPackets=1

LatePackets=0

!--- Indicates the precense of jitter, lost packets, or !--- corrupted packets.

VAD = enabled

CoderTypeRate=g729r8

CodecBytes=20

GENERIC:

SetupTime=155218260 ms

Index=2

PeerAddress=6000

PeerSubAddress=

PeerId=1

PeerIfIndex=12

LogicalIfIndex=6

ConnectTime=155218364

CallDuration=00:00:34

CallState=4

CallOrigin=1

ChargedUnits=0

InfoType=2

TransmitPackets=229

TransmitBytes=4580

ReceivePackets=365

ReceiveBytes=7300

TELE:

ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

TxDuration=35360 ms

VoiceTxDuration=730 ms

FaxTxDuration=0 ms

CoderTypeRate=g729r8

NoiseLevel=-46

ACOMLevel=2

OutSignalLevel=-58

InSignalLevel=-42

InfoActivity=2

ERLLevel=7

SessionTarget=

ImgPages=0Total call-legs: 2

!---------------------------------------------------------- !--- Interface Verification !--- Make sure you see this: !--- LCP Open, multilink Open: Link control protocol (LCP) open statement !--- indicates that the connection is establish. !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link.

maui-voip-sj#show interface multilink 1

Multilink1 is up, line protocol is up

Hardware is multilink group interface

Internet address is 172.22.130.1/30

MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 2 seconds on reset

LCP Open, multilink Open

Open: IPCP

Last input 00:00:01, output never, output hang never

Last clearing of "show interface" counters 00:25:20

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91

Queueing strategy: weighted fair

Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves)

Conversations  0/3/32 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 38 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

8217 packets input, 967680 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

13091 packets output, 1254194 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

----------------------------------------------------------------

!-- Note: There are no drops at the interface level. !-- All traffic that is dropped due to policing, is !-- dropped before it gets to the interface queue.

maui-voip-austin#show interface

serial 0/0Serial0/0 is up, line protocol is up

Hardware is QUICC Serial

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

reliability 255/255, txload 49/255, rxload 47/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Open, multilink Open

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:22:08

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair  [suspended, using FIFO]

FIFO output queue 0/40, 0 drops

5 minute input rate 24000 bits/sec, 20 packets/sec

5 minute output rate 25000 bits/sec, 20 packets/sec     4851 packets input, 668983 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4586 packets output, 657902 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

!----------------------------------- !--- LLQ Verification

maui-voip-austin#show policy-map int multilink 1

Multilink1

Service-policy output: voice-policy

Class-map: voice-signaling (match-all)

!--- This is the class for the voice signaling traffic.

10 packets, 744 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 103

Weighted Fair Queueing

Output Queue: Conversation 42

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 10/744

(depth/total drops/no-buffer drops) 0/0/0

Class-map: voice-traffic (match-all)

!--- This is PQ class for the voice traffic.

458 packets, 32064 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 102

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 15 (kbps) Burst 375 (Bytes)

!--- Notice that the PQ bandwidth was lowered to force packet drops.

(pkts matched/bytes matched) 458/29647

(total drops/bytes drops) 91/5890

!--- Some packets were dropped. In a well designed link,

!--- there should be no (or few) drops of the PQ class.

Class-map: class-default (match-any)

814 packets, 731341 bytes

5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

(total queued/total drops/no-buffer drops) 0/0/0

!---------------------------------------------

!--- Verify the class-map configuration

maui-voip-austin#show class-map

Class Map match-all voice-signaling (id 2)

Match access-group  103

Class Map match-any class-default (id 0)

Match any

Class Map match-all voice-traffic(id 3)

Match access-group 102

!--- Verify the access-lists of the class-maps

maui-voip-austin#show access-lists

Extended IP access list 102

permit udp any any range 16384 32767 (34947 matches)

Extended IP access list 103

permit tcp any eq 1720 any (187 matches)

permit tcp any any eq 1720 (86 matches)

!--- Verify the policy-pap configuration

maui-voip-austin#show policy-map voice-policy

Policy Map voice-policy

Class voice-signaling

Weighted Fair Queueing

Bandwidth 8 (kbps) Max Threshold 64 (packets)

Class voice-traffic

Weighted Fair Queueing

Strict Priority

Bandwidth 50 (kbps) Burst 1250 (Bytes)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing Max Threshold 64 (packets)

---------------------------

!--- Debug priority command provides immediate feedback in case !--- of VoIP packet drops. !--- The output below shows the error message when VoIP packets !--- are being dropped from the strict priority queue.

maui-voip-sj#debug priority

priority output queueing debugging is on

maui-voip-sj#

Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0

-------------------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification

maui-voip-sj#show ppp multilink

!--- Verify the fragmentation size and multilink

Multilink1, bundle name is maui-voip-austin

Bundle up for 00:08:04

0 lost fragments, 0 reordered, 0 unassigned

0 discarded, 0 lost received, 1/255 load

0x6D received sequence, 0x6E sent sequence

Member links: 1 active, 0 inactive (max not set, min not set)

Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight

!--- Notice the fragmentation size is 160 Bytes. The link is configured with a !--- bandwidth of 128 kbps and a serialization delay of 10 msec. !--- Fragment Size (in bits) = bandwidth * serialization delay. !--- Note: There are 8 bits in one byte.

-------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification !--- Testing Multilink PPP Link LFI !--- This output displays fragmentation and interleaving information !--- when the the 128kbps PPP link is loaded with big data and VoIP packets.

maui-voip-sj#debug ppp multilink fragments

Multilink fragments debugging is on

1w3d: Se0/0 MLP: O frag 800004CF size 160

1w3d: Se0/0 MLP: O frag 000004D0 size 160

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Mu1 MLP: Packet interleaved from queue 40

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O frag 400004D1 size 106

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct

1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

-------------------------------------------------------------------

!--- Sample output of show ip rtp header-compression command

maui-voip-sj#show ip tcp header-compression

TCP/IP header compression statistics:  Interface Multilink1:

Rcvd:    10 total, 6 compressed, 0 errors

0 dropped, 0 buffer copies, 0 buffer failures

Sent:    10 total, 7 compressed,

230 bytes saved, 99 bytes sent

3.32 efficiency improvement factor

Connect: 16 rx slots, 16 tx slots,

2 long searches, 1 misses 0 collisions, 0 negative cache hits

90% hit ratio, five minute miss rate 0 misses/sec, 0 max

----------------------------------------------------------------------

!--- This command displays information of the voip dial-peers command.

maui-voip-sj#show dial-peer voice 2

VoiceOverIpPeer2

information type = voice,

tag = 2, destination-pattern = `6000',

answer-address = `', preference=0,

group = 2, Admin state is up, Operation state is up,

incoming called-number = `', connections/maximum = 0/unlimited,

application associated:

type = voip, session-tMarget = `ipv4:172.22.130.2',

technology prefix:

ip precedence = 0, UDP checksum = disabled,

session-protocol = cisco, req-qos = best-effort,

acc-qos = best-effort,

fax-rate = voice,   payload size =  20 bytes

codec = g729r8,   payload size =  20 bytes,

Expect factor = 10, Icpif = 30,signaling-type = cas,

VAD = enabled, Poor QOV Trap = disabled,

Connect Time = 283, Charged Units = 0,

Successful Calls = 1, Failed Calls = 0,

Accepted Calls = 1, Refused Calls = 0,

Last Disconnect Cause is "10  ",

Last Disconnect Text is "normal call clearing.",

Last Setup Time = 93793451.

-------------------------------------------------------------------------

!---The CPU utilization of the router should not exceed the 50-60 percent !--- during any five-minute interval.

maui-voip-austin#show processes cpu

CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9%

PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

1         148    310794          0  0.00%  0.00%  0.00%   0 Load Meter

2          76        23       3304  0.81%  0.07%  0.01%   0 Exec

Informações Relacionadas

- Enfileiramento de latência baixa

- Visão geral do gerenciamento de congestionamentos

- Implementando QoS

- Voz sobre IP - Consumo de largura de banda por chamada

- Qualidade de serviço de voz sobre IP

- Configurando voz sobre IP

- Suporte à Tecnologia de Voz

- Suporte aos produtos de Voz e Comunicação por IP

- Troubleshooting da Telefonia IP Cisco

- Suporte Técnico - Cisco Systems