Links de VoIP por PPP com qualidade de serviço (LLQ / prioridade IP RTP, LFI, crtp)

Links de VoIP por PPP com qualidade de serviço

(LLQ / prioridade IP RTP, LFI, cRTP)

Índice

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 IP RTP

Fragmentação e intercalação de link (LFI): Multilink PPP Protocolo de Tempo Real Compactado (cRTP)

Outras dicas de redução de largura de banda Diagrama de Rede

Configurações

Comandos de Verificação e Troubleshooting Exemplo de show e debug

Informações Relacionadas

Introdução

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.

Nota: É 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.

Pré-requisitos

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 liberações do Cisco IOS além de 12.0.5T contêm melhorias significativas de desempenho para o cRTP.

●

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Diretrizes para projetos de QoS para VoIP em enlaces PPP

Esta seção fornece diretrizes do projeto para configurar VoIP sobre linhas alugadas PPP (com uma ênfase em enlaces de velocidade baixa). 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 as exigências acima, há diversas diretrizes importantes que devem ser seguidas: Diretri z Descrição Priorid ade estrita para tráfego de voz (priorid ade de RTP de IP ou LLQ)

Método para dar prioridade máxima para tráfego de voz. Fragm entaçã o e interca lação de link (LFI)

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

Comp actaçã o RTP

Não é necessário para fornecer boa qualidade de voz, mas reduz o consumo de largura de banda para chamadas. Os comentários gerais relativos ao compactação RTP são aplicá-la em seguida que tem uma configuração em

funcionamento com boa qualidade de voz (simplifica o Troubleshooting).

Contro le 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 link MACILENTO entre os dois gateways tem a largura de banda para levar somente duas chamadas VoIP, admitir um terceiro atendimento pode danificar a Qualidade de voz de todos os três atendimentos. Para obter mais informações, consulte: Controle de admissão de chamada VoIP.

Para resumir, porque o enlace de PPP de velocidade baixa com o roteador/gateways como somente fontes de tráfego de voz duas características é imperativo:

Prioridade estrita para o tráfego de voz 1.

Fragmentação e intercalação de link (LFI) 2.

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

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

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

Enfileiramento da latência baixa (igualmente chamado PQ/CBWFQ: Priority Queue / Class Based Weighted Fair Queuing).

●

Prioridade de RTP de IP

O IP RTP Priority cria uma fila de prioridade estrita para um grupo de fluxos do pacote RTP que pertencem às portas do destino de uma faixa de protocolo de datagrama de usuário (UDP).

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 estão processadas de acordo com as filas "Standard Weighted Fair Queuing" (WFQ). A prioridade de RTP de IP não se torna ativa até que haja congestionamento na interface. Esta imagem ilustra a operação da prioridade de IP RTP:

Nota: O IP RTP Priority reserva estourar o priority queue (PQ) quando há uma largura de banda disponível na fila padrão (WFQ), mas policia restritamente os índices da fila de prioridade quando há uma congestão na relação.

O LLQ é uma característica que forneça um PQ restrito ao Class-Based Weighted Fair Queuing (CBWFQ). 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. Quando você configura o PQ, você especifica nos kbps a quantidade máxima de largura de banda disponível ao 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.

Prioridade LLQ versus IP RTP

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

Low Latency Queuing (LLQ) Prioridade de RTP de IP Comparar tráfego de voz com base em: Listas de acesso (para faixa de portas UDP, endereç os de hosts, campos ToS de cabeçalh o de IP): Precedê ncia de IP, DSCP e mais) ● Intervalo de porta IP RTP ● Campos ●

Comparar tráfego de voz com base em: Baseado no intervalo de porta RTP UDP: 16384-32767 ● Vantagens: Configuração simples ● Desvantagens:

Tráfego RTCP (Sinalização VoIP) atendido na fila WFQ Nota: O protocolo de RTP usa RTCP (protocolo real time control) para controlar a entrega de pacotes de RTP. Quando as portas RTP usarem números par, as portas RTCP usam números ímpares na escala 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 todo o outro tráfego que precisar o

tratamento preferencial e a garantia de largura de banda é servido no WFQ. Enquanto o WFQ pode diferenciar fluxos com pesos (com ●

ToS (Type of Service) de IP: DCSP e/ou precedê ncia do IP Protocol os e interface s de entrada ● Todos os critérios válidos de verificaç ão de repetiçã o de dados usados no CBWFQ ● Vantagens: Mais flexibilid ade em como o tráfego é correspo ndido e direciona do para PQ e CBWFQ estritos ● Pode configur ar classes adicionai s para garantir ●

base na precedência IP), ele não pode garantir que a largura de banda para qualquer fluxo.

a largura de banda para o outro tráfego como: Sinalizaç ão e vídeo de VoIP. Desvantagen s: Configur ação complex a ● Diretrizes

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

verdadeiras. ●

Se você precisa de fornecer a prioridade estrita a seu tráfego de voz, e o outro tráfego pode ser tratado como um único tipo (dados), a seguir o IP RTP Priority faz um bom trabalho para sua rede com uma configuração simples.

●

Se você planeia dar a prioridade ao tráfego de voz baseado em critérios diferentes das portas UDP (por exemplo DiffServ PHB), o LLQ é necessário.

●

Para obter mais informações sobre da correlação e das diferenças dos métodos de enfileiramento, refira a visão geral sobre Tratamento de Congestionamento.

Diretrizes de configuração de LLQ

Crie um mapa da classe para o tráfego voip e defina critérios de verificação de repetição de dadosEstes comandos explicam como terminar 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. Estas

listas de acesso podem igualmente ser usadas para combinar 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 dos 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 16383Estes dois métodos operam-se sob a suposição que

os pacotes voip estão marcados nos host de origem, ou combinados e marcados no roteador antes de aplicar a operação LLQ de saída.

class-map voice match ip precedence 5 ou

class-map voice match ip dscp ef Nota: A partir da Versão 12.2.2T do IOS, os peers de

discagem VoIP podem marcar portador de voz e 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.

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 terminar 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 Nota: As chamadas de VoIP podem ser

estabelecidas com o uso de H.323, SIP, MGCP ou Skinny (protocolo proprietário utilizado pelo Cisco Call Manager). O exemplo acima pressupõe o H.323 Fast Connect. Esta lista serve como a referência para as portas usadas pela sinalização voip/canais de

controle:H.323/H.225 = TCP 1720H.323/H.245 = TCP 11xxx (conexão padrão)H.323/H.245 = TCP 1720 (Fast Connect)H.323/H.225 RAS = TCP 1719Skinny = 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) 2.

Crie um mapa de política e associe a VoIP os mapas de classeA finalidade do mapa de política é definir como os recursos do link são compartilhados ou atribuídos às classes diferentes do mapa. Estes comandos explicam como terminar 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 Nota: Embora seja

possível enfileirar vários tipos de tráfego de tempo real ao PQ, Cisco recomenda que você lhe dirige somente o tráfego de voz. O tráfego de tempo real, tal como o vídeo, poderia introduzir a variação no atraso (o PQ é um FIFO - First In First Out - fila). O tráfego de voz exige que o atraso não seja variável para evitar tremulação.Nota: A soma dos valores para a 3.

prioridade e as instruções de largura de banda precisa de ser inferior ou igual a 75 por cento da largura de banda de enlace. 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).Nota: Ao configurar VoIP sobre um link de KBPS 64 para apoiar duas chamadas de voz, é comum atribuir mais de 75 por cento (48Kbps) da largura de banda de enlace ao PQ. Nesses casos, você pode usar o comando max-reserved-bandwidth 80 levantar a largura de banda disponível para 80 por cento (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.

Permita o LLQ: Aplicar o mapa de política à interface WAN externaEstes comandos explicam como terminar esta tarefa: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.

4.

Diretrizes de configuração de prioridade IP RTP

Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth 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

●

Fragmentação e intercalação de link (LFI): 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 da voz sensível a retardo tem que esperar 214 milissegundos antes de ser transmitido (toma 214 milissegundos para fabricar um pacote de bytes 1500 sobre um link 56Kbps).

Como você pode ver, os pacotes grandes de dados podem atrasar a entrega de pequenos pacotes de voz, reduzindo a qualidade do discurso. Fragmentar estes grandes pacotes de dados nos menores e intercalar pacotes de voz entre os fragmentos reduzem o tremor e o atraso. 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 do ITU-T o G.114 especifica 150 fim-a-fim de sentido único máximos da Senhora.)

retardo de serialização = do tamanho do frame dos enlaces de velocidade baixa (bit) /link (bps) 1 byte 64 byte s Bytes 128 Byte s 256 512 Byte s 1024 bytes 1500 bytes 56 kbps 143 us 9 ms Senhor a 18 36 ms 72 ms 144 ms Senhor a 214 64 kbps 125 us 8 ms 16 ms 32 ms 64 ms 126 ms Senhor a 187 kbps 128 62. 5 us 4 ms 8 ms 16 ms 32 ms 64 ms Senhor a 93 256 kbps 31 us 2 ms 4 ms 8 ms 16 ms 32 ms Senhor a 46 512 Kbp s 15. 5 nós 1 ms 2 ms 4 ms 8 ms 16 ms 32 ms 768 Kbp s 10 us 640 us 1,28 ms 2,56 ms 5,12 ms 10,2 4 ms 15 ms 1536 kbps 5 nós 320 us 640 us 1,28 ms 2,56 ms 5,12 ms 7,5 ms

Nota: Para Aplicações de voz, o retardo de serialização recomendado (pela base do salto) é a Senhora 10 e não deve exceder a Senhora 20.

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 de configurar o LFI, refira a seção deste documento.

Nota: Nos casos em que há mais que uma conexão semi-T1 dedicada (768 Kbps), não é

necessário um recurso de fragmentação. (Você ainda, contudo, precisa um mecanismo de QoS, tal como o LLQ ou o 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.

Protocolo de Tempo Real Compactado (cRTP)

Nota: cRTP não é necessário para garantir uma 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.

Baseado no RFC 2508, a característica RTP Header Compression comprime o encabeçamento IP/UDP/RTP de 40 bytes a 2 ou 4 bytes, reduzindo o consumo de largura de banda

desnecessário. É um esquema de compressão de 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 a nível de 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 estas aplicações são quebradas, e então a única maneira que os trabalhos estarão processados comutou. 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%.

Nota: Quando você configura o comando ip rtp header-compression, o roteador adiciona o comando ip tcp header-compression à configuração à revelia. Isto é usado para comprimir os pacotes TCP/IP dos encabeçamentos. A compressão de cabeçalhos é particularmente útil em redes com um percentual alto de pacotes pequenos, tais como aqueles que apoiam muitas conexões Telnet. A técnica TCP Header Compression, descrita inteiramente no RFC 1144, é apoiada em linhas de série usando o HDLC ou o encapsulamento PPP.

Para comprimir os cabeçalhos de TCP sem permitir 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

Use o codificador do low-bit-rate/decodificadores (codec) nos pés da chamada VoIP; G.729 (8 kbps) é recomendado. (Este é o codec do padrão nos VoIP dial-peer). Para configurar codecs diferentes use o comando router(config-dial-peer)-codec sob o dial-peer do 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 os codecs do low-bit-rate (G.729, G.723) são usados, gire sobre o relé DMTF sob o VoIP dial-peer.

●

Uma conversação típica pode conter o percentual de silêncio 35-50. Com VAD (Voice Activity Detection), os pacotes de silêncio são suprimidos. Para o planeamento da largura de banda voip, supõe que o VAD reduz a largura de banda por 35 por cento. VAD é configurado por padrão nos correspondentes de discagem VoIP. Para permitir ou desabilitar o VAD, use os comandos router(config-dial-peer)-vad e router(config-dial-peer)- no vad sob o dial peers do voip desejado.

●

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-voice-port 1/0/1 ! voice-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

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 algum comando debug, refira a informação importante em comandos Debug. Para obter mais informações sobre dos comandos alistados aqui, veja a seção do exemplo de show e debug deste documento.

Comandos da interface:

mostre a relação [série | multilink] — use este comando verificar esse estado da interface serial. Certifique-se que a série e a interface multilink estão ascendentes 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 indica a informação sobre fragmentos de multilink individual e eventos de intercalação. Este comando output igualmente identifica o número de sequência do pacote e dos tamanhos do fragmento.

●

Comandos da prioridade RTP LLQ/IP:

interface# do show policy-map interface multilink — Este comando é muito útil considerar a operação de LLQ e considerar todas as gotas 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 indica a informação sobre a configuração de mapa de política.

●

show queue interface-type interface-number — Estas configuração e estatísticas do enfileiramento considerável das lista de comando para uma interface particular. ●

Debugar a prioridade — Este comando debug indica eventos das filas de prioridade e mostra se deixar cair ocorre nesta fila. Igualmente refira gotas das saídas de Troubleshooting com ●

filas de prioridade.

show class-map class_name — Este comando indica a informação sobre a configuração de mapa de classe.

●

mostre a voz ativa do atendimento — Este comando é útil de verificar para ver se há pacotes perdidos a nível DSP.

●

Outros Comandos/Referências:

mostre a compressão de cabeçalhos do RTP IP — Este comando indica estatísticas RTP Header Compression.

●

Troubleshooting & fundamentos de chamada voip da eliminação de erros ●

Comandos de debug VoIP ●

Problemas conhecidos:

CSCds43465: O “LLQ, vigilante, shaper deve tomar o Feedback de Compactação CRTP” para ver Release Note, refere o Bug Toolkit (clientes registrados somente).

●

Diretrizes:

Estão aqui algumas etapas de Troubleshooting básicas, uma vez que o link de PPP é em serviço (MLPPP, fragmentação, intercalando):

mostre a voz ativa do atendimento — Use para verificar para ver se há os pacotes perdidos a nível DSP.

1.

relação da mostra — Use para verificar para ver se há os problemas da linha serial geral ou da relação. 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. 2.

mostre a relação do mapa de política — Use para verificar para ver se há as gotas e a configuração de enfileiramento LLQ. Não deve relatar nenhuma gotas que violam a política. 3.

mostre a compressão de cabeçalhos do RTP IP — Use para verificar para ver se há os problemas do específico do cRTP.

4.

Exemplo de 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

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: 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 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

policy Policy Map 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 de Produtos de Comunicação de Voz e de IP ●

Troubleshooting da Telefonia IP Cisco ●

Suporte Técnico - Cisco Systems ●