Voz : Qualidade de voz

Links VoIP sobre PPP com Qualidade de Serviço (prioridade de RTP de IP/LLQ, LFI, cRTP)

24 Maio 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (2 Fevereiro 2006) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Diretrizes de Desenho de QoS para Links VoIP Sobre PPP
     Prioridade Estrita para Tráfego de Voz (Prioridade de RTP IP ou LLQ)
     Diretrizes de Configuração do LLQ
     Diretrizes de Configuração de Prioridade de IP RTP
     Como funcionam a Fragmentação e a Intercalação de Links (LFI): PPP Multilink
     Protocolo de Transporte em Tempo Real Compactado (cRTP)
     Outras Dicas de Redução de Largura de Banda
Diagrama de Rede
Configurações
Comandos de Verificação e Solução de Problemas
Exibição de amostra e Saída de depuração
Discussões relacionadas da comunidade de suporte da Cisco

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 background sobre os recursos configurados, diretrizes de desenho e estratégias de solução de problemas e verificação básica.

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 habilitados 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 nesses roteadores conectados à WAN e não nos roteadores de voz, conforme demonstrado nas configurações abaixo.

Pré-requisitos

Requisitos

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

Componentes Usados

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.

  • O Software Cisco IOS versões posteriores a 12.0.5T possuem aprimoramentos significativos de desempenho para cRTP.

Convenções

Para obter mais informações sobre convenções de documentos, consulte Convenções e Dicas Técnicas da Cisco.

Diretrizes de Desenho de QoS para Links VoIP Sobre PPP

Esta seção oferece diretrizes de desenho 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:

Para garantir os requisitos acima, há diversas diretrizes importantes que devem ser seguidas:

Diretriz

Descrição

Prioridade Estrita para Tráfego de Voz (Prioridade de RTP IP ou LLQ)

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

Como funcionam a Fragmentação e a Intercalação de Links (LFI)?

Pode ser um requisito obrigatório para os links 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. Um conselho geral em relação a compactação RTP é aplicá-la depois de ter uma configuração ativa com boa qualidade de voz (simplifica a solução de problemas).

Controle de Admissão de Chamada (CAC)

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

Resumindo, para um link PPP de baixa velocidade com o roteador/gateways como as únicas fontes de tráfego de voz, dois recursos são obrigatórios:

  1. Prioridade Estrita para Tráfego de Voz

  2. Como funcionam a Fragmentação e a Intercalação de Links (LFI)?

Prioridade Estrita para Tráfego de Voz (Prioridade de RTP IP ou LLQ)

Em relação ao Cisco IOS Software Release 12.2, há dois métodos principais para fornecimento de prioridade estrita ao tráfego de voz:

  • IP RTP Priority (também chamada de PQ/WFQ: Priority Queue / Weighted Fair Queuing)

  • Low Latency Queuing (também chamada PQ/CBWFQ: Priority Queue / Class Based Weighted Fair Queuing).

Prioridade IP RTP

A prioridade IP RTP cria uma fila de prioridade estrita para um conjunto de fluxos de pacotes RTP pertencentes a um intervalo de portas de destino de protocolo de datagrama de usuários (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 fica vazia, as outras filas são processadas de acordo com o Weighted Fair Queuing (WFQ) padrão. A prioridade IP RTP não fica ativa até haver congestionamento na interface. Esta imagem ilustra a operação da prioridade IP RTP:

pq-wfq.gif

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

Low Latency Queuing

O LLQ é um recurso que fornece uma PQ estrita ao Class-Based Weighted Fair Queuing (CBWFQ). O LLQ permite uma PQ dentro de CBWFQ no nível da classe. Com LLQ, dados sensíveis a atraso (na PQ) são tirados da fila e enviados primeiro. Em VoIP com implementação LLQ, o tráfego de voz é colocado na PQ padrão.

A PQ é policiada para garantir que filas justas não fiquem sem largura de banda. Ao configurar o PQ, especifique a quantidade máxima, em Kbps, de largura de banda disponível para o PQ. Quando a interface fica congestionada, a PQ recebe atenção até a carga atingir o valor configurado em Kbps na instrução de prioridade. O tráfego em excesso é descartado para evitar o problema com o recurso de grupos de prioridade em produtos Cisco anteriores em que as filas de prioridade de nível inferior ficam sem atividade.

llq.gif

Este método é mais complexo e flexível que Prioridade IP RTP. 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.

LLQ x Prioridade IP RTP

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

Low Latency Queuing (LLQ)

Prioridade IP RTP

Correspondência de Tráfego de Voz com Base em:

  • Listas de acesso (para faixa de portas UDP, endereços de hosts, campos ToS de cabeçalho 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

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

Desvantagens:

  • Configuração complexa

Correspondência de 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

    Observação: O protocolo RTP usa RTCP (Real Time Control Protocol) para controlar a entrega de pacotes RTP. Enquanto as portas RTP utilizam números pares, as portas RTCP utilizam números ímpares no intervalo de 16384 a 32767. A prioridade IP RTP coloca portas RTP no PQ, enquanto as portas RTCP são tratadas no WFQ padrão.

  • Atende o tráfego VoIP na PQ, mas o tráfego restante que necessita de tratamento preferencial e garantia de largura de banda é tratado pelo WFQ. Apesar de WFQ diferenciar fluxos com pesos (com base na Precedência de IP), ele não garante largura de banda para nenhum 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 prioridades estritas ao tráfego de voz e o tráfego restante puder ser tratado como tipo simples (dados), a Prioridade IP RTP funciona bem para a sua rede com uma configuração simples.

  • Se você planeja priorizar o tráfego de voz com base em outros critérios que não sejam portas UDP (por exemplo, DiffServ PHB), é necessário usar LLQ.

Para obter mais informações sobre a correlação e diferenças entre métodos de enfileiramento, consulte Visão Geral sobre Gerenciamento de Congestionamento.

Diretrizes de Configuração do LLQ

Siga estas diretrizes para configurar 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
                      
                         !-- Escolha um nome descritivo de classe. 
                      
    
    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
    
                         !-- Neste exemplo, a opção de correspondência de grupo de acesso é usada devido a sua
    !-- flexibilidade (utiliza uma lista de acesso)
                      
    
    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
    
                      
                         !-- Agora, crie a lista de acesso para corresponder com o grupo de acesso do mapa de classes:
                      
    maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776
    
                      
                         !-- Formas mais fáceis e seguras de correspondência com portas UDP de 16384 a 32767.
    !-- Este é o intervalo de portas que os produtos Cisco IOS H.323 utilizam para transmitir
    
    !-- pacotes VoIP.
                      
                   

    Estas listas de acesso também podem ser usadas para correspondência de 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:
    !-- Implementando Políticas de Qualidade de Serviço com o DSCP
    !-- Observação: 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
                      
                         !-- Esta lista de acesso pode ser utilizada em casos em que os dispositivos VoIP não possam
    !-- fazer marcação dcsp ou precedência e você não puder determinar o
    !-- intervalo de portas VoIP UDP. 
                      
                   

    Estes são os outros métodos de correspondência que podem ser utilizados em vez de grupo 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
      
                           
    • Estes dois métodos funcionam sob a premissa de que os pacotes VoIP são marcados nos hosts de origem ou combinados e marcados no roteador antes de aplicar a operação de LLQ de saída.

                              class-map voice
        match ip precedence 5 
                           

      ou

                              class-map voice
        match ip dscp ef 
                           

      Observação: 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.

  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 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 funciona como referência das portas usadas pela Sinalização VoIP/Canais de Controle:

    • H.323/H.225 = TCP 1720

    • H.323/H.245 = TCP 11xxx (Standard Connect)

    • 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-o aos Mapas de Classe VoIP.

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

    maui-voip-sj(config)#policy-map VOICE-POLICY
                      
                         !-- Escolha um nome descritivo de mapa de política.
                      
    
    maui-voip-sj(config-pmap)#class voice-traffic
    maui-voip-sj(config-pmap-c)#priority ?
    <8-2000000>  Kilo Bits per second
    
                         !-- Configure a classe de tráfego de voz para a fila de prioridade estrita
    !-- (comando de prioridade) e atribua a largura de banda.
                      
    
    maui-voip-sj(config-pmap)#class voice-signaling
    maui-voip-sj(config-pmap-c)#bandwidth 8
                      
                         !-- Atribua 8 Kbps à classe de sinalização de voz
                      
    
    maui-voip-sj(config-pmap)#class class-default
    maui-voip-sj(config-pmap-c)#fair-queue 
                      
                         !-- O tráfego de dados restante é tratado como Weighted Fair Queue
                      
                   

    Observação: Apesar de ser possível colocar em fila vários tipos de tráfego em tempo real para o PQ, a Cisco recomenda que você direcione apenas tráfego de voz para ele. O tráfego em tempo real, como vídeo, pode introduzir variação no atraso (o PQ é uma fila FIFO – First In First Out). O tráfego de voz requer que o atraso não varie para evitar problemas de variação.

    Observação: A soma dos valores de instruções priority e bandwidth deve ser menor ou igual a 75 por cento da largura de banda do link. Do contrário, service-policy não pode ser atribuído ao link (para exibir as mensagens de erro, certifique-se de que o comando logging console esteja habilitado para acesso pelo console e o comando terminal monitor esteja habilitado para acesso Telnet).

    Observação: Ao configurar VoIP sobre um link de 64 Kbps para dar suporte a duas chamadas de voz, é comum alocar mais de 75 por cento (48Kbps) da largura de banda do link para a PQ. Em casos assim, você pode usar o comando max-reserved-bandwidth 80 para aumentar 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ço de QoS.

  4. Ativar 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
                      
                         !-- Neste cenário (MLPPP LFI), a política de serviço é aplicada á
    !-- interface Multilink.
    
                      
                   

Diretrizes de Configuração de Prioridade de IP RTP

Use estas diretrizes para configurar Prioridade IP RTP:

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

    version

    Descrição

                            starting-rtp-port-number
                         

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

                            port-number-range
                         

    O intervalo de portas UDP de destino. Um número que, adicionado a starting-rtp-port-number, resulta no número mais alto 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 este número de acordo com o número de chamadas simultâneas suportadas pelo sistema.

    Exemplo de Configuração:

    interface Multilink1
    
                            !--- Algumas saídas omitidas:
                      
       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
                   

Como funcionam a Fragmentação e a Intercalação de Links (LFI): PPP Multilink

Enquanto 1500 bytes é um tamanho comum para os pacotes de dados, um pacote VoIP típico (carregando quadros 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 link, há um problema. O pacote de voz sensível a atraso precisa aguardar 214 mseg para poder ser transmitido (demora 214 mseg para serializar um pacote de 1500 bytes em 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. A fragmentação desses pacotes de dados grandes em pacotes menores e intercalação de pacotes de voz entre os fragmentos reduz atrasos e variações. O recurso Link Fragmentation and Interleaving (LFI) do Cisco IOS ajuda a atender os requisitos de entrega em tempo real de VoIP. Esta imagem ilustra a operação do LFI:

lfi.gif

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 links WAN de baixa velocidade pode ser significativa, considerando que a meta do atraso unidirecional de ponta a ponta não deve exceder 150 ms. (a recomendação ITU-T G.114 especifica 150 ms no máximo, em sentido único de ponta a ponta.)

Tabela 1. Atraso de Serialização para Diversos Tamanhos de Quadro a Baixa Velocidade Atraso de Serialização de Links = 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 atraso de serialização recomendado (base por salto) é de 10 ms e não deve exceder 20 ms.

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

Observação: Nos casos em que há mais que uma conexão semi-T1 dedicada (768 Kbps), não é necessário um recurso de fragmentação. (Entretanto, você ainda precisa de um mecanismo de QoS, como Prioridade IP RTP ou LLQ). 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 Transporte em Tempo Real Compactado (cRTP)

Observação: O cRTP não é necessário para garantir uma boa qualidade de voz. Ele é um recurso que reduz o consumo de largura de banda. Configure o cRTP após atender a todas as outras condições e a qualidade de voz estar boa. Esse procedimento pode economizar tempo na solução de problemas, isolando os problemas potenciais de cRTP.

Com base no RFC 2508, o recurso RTP de compressão de cabeçalho compacta o cabeçalho do pacote IP/UDP/RTP de 40 bytes para 2 ou 4 bytes, reduzindo consumo desnecessário de largura de banda. É um esquema de compressão de nó a nó, portanto, o cRTP deve ser configurado nas duas extremidades do link (a menos que a opção passiva esteja configurada). Para configurar 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ápido e de switching de CEF, como na versão 12.0.(7)T do Cisco IOS. Ás vezes, essas implementações são quebradas, e então o único caminho que funciona será processado ativado. A Cisco recomenda o uso de cRTP somente com links 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: Ao configurar 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/pacotes IP. A compactação do cabeçalho é especialmente útil em redes com uma grande porcentagem de pacotes pequenos, como as redes que suportam muitas conexões Telnet. A técnica de compactação de cabeçalho TCP, descrita em detalhes em RFC 1144, é suportada em linhas seriais que usam encapsulamento HDLC ou PPP.

Para compactar os cabeçalhos TCP sem ativar 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 codificador/decodificadores (codec) de taxa baixa de bits nos segmentos de chamada VoIP; recomendamos G.729 (8 Kbps). (Esse é o codec padrão nos correspondentes de discagem de VoIP). Para configurar codecs diferentes, use o comando router(config-dial-peer)#codec sob o correspondente de discagem de 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 no acesso a sistemas interativos de resposta de voz (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 você utilizar codecs de taxa baixa de bits (G.729, G.723) acione o comando dtmf relay no correspondente de discagem de VoIP.

  • Uma conversa comum 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 para VoIP, pressuponha que o VAD reduz a largura de banda em 35 por cento. O VAD está configurado por padrão sob os peers de discagem de VoIP. Para ativar ou desativar o VAD, use os comandos router(config-dial-peer)#vad e router(config-dial-peer)# no vad nos correspondentes de discagem de VoIP desejados.

Diagrama de Rede

mlppp.gif

Configurações

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec

                     !-- < Algumas saídas omitidas >
                  
!
nome de host maui-voip-sj
!
ip subnet-zero
!
no ip domain-lookup
!

                     !-- Definição da sinalização de voz e de mapas de classe de tráfego
!-- a classe de "tráfego de voz" utiliza a lista de acesso 102 para seus critérios de correspondência.
!-- a classe de "sinalização de voz" utiliza a lista de acesso 103 para seus critérios de correspondência.

                  
                  Class-map match-all voice-signaling
  match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

                     !-- O mapa de políticas define como os recursos de link são atribuídos
!-- às diferentes classes de mapa. Nesta configuração, PQ estrito
!-- está atribuído à classe de "tráfego de voz" com (com base no ACL em
!-- classe de voz) com largura de banda máxima de 45 Kbps. 
                  
                  policy-map VOICE-POLICY
  classe de tráfego de voz
    prioridade 48
 classe de sinalização de voz
   largura de banda 8
                  
                         !-- Atribui uma fila para tráfego de "sinalização de voz" que garante 8 Kbps.
    !-- Observe que isto é opcional e não tem nada a ver com uma boa qualidade
    !-- de voz, mas sim um modo de assegurar a sinalização.
                  
  class class-default
   fair-queue

                     !-- A classe class-default é utilizada para classificar o tráfego que
    !-- não está dentro de uma das classes definidas.
    !-- O comando fair-queue associa as filas WFQ de classe padrão.
                  
!
call rsvp-sync
!

                     !-- Observe que MLPPP é um mecanismo estritamente LFI. Ele não
!-- agrupa diversas interfaces seriais em uma mesma interface virtual que
!-- os stands de nome (Esse agrupamento é feito para dados e NÃO é recomendado
!-- para voz). O resultado final pode se manifestar sem variação e nenhum áudio.
                  
                  interface Multilink1
 ip address 172.22.130.1 255.255.255.252
 ip tcp header-compression iphc-format
 service-policy output VOICE-POLICY
                  
                       !-- LLQ é uma operação de saída aplicada à interface WAN
  !de saída.
                  
 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
                  
                     !-- O valor configurado de 10 define o tamanho do fragmento de modo que
  !-- todos os fragmentos tenham um atraso máximo de serialização de 10 ms.
                  
                   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
 largura de banda 128
                  
                       !—o comando bandwidth precisa estar configurado corretamente para que
  !-- o tamanho correto do fragmento seja calculado.
                  
 no ip address
 encapsulation ppp
 clockrate 128000
 ppp multilink
 multilink-group 1
                  
                       !-- Este comando vincula a interface multilink à
  !-- interface serial física.
                  
!
router eigrp 69
 network 172.22.0.0
 auto-summary
 no eigrp log-neighbor-changes
!

                     !-- A lista de acesso 102 corresponde ao tráfego VoIP com base no intervalo de portas UDP.
!-- Portas pares e ímpares são colocadas no PQ.
!-- A lista de acesso 103 é usada para corresponder o protocolo de sinalização VoIP. Nesse
!-- caso, é usado H.323 V2 com recurso de inicialização rápida.
                  
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 depois de ter uma configuração ativa.
 !-- Isso ajuda a isolar potenciais problemas de cRTP.
                  
!
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 Solução de Problemas

Antes de tentar comandos de depuração, consulte Informações Importantes sobre Comandos de Depuração. Para obter mais informações sobre os comandos listados aqui, consulte a seção Saída de depuração e exibição de amostra deste documento.

Comandos da Interface:

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

  • Solução de Problemas de Linhas Seriais

Comandos do LFI:

  • show ppp multilink - Esse comando exibe as informações de pacote para os pacotes Multilink PPP.

  • debug ppp multilink fragments - Este comando debug exibe informações sobre fragmentos de multilink individual e eventos intercalados. Esta saída de comando também identifica o número seqüencial do pacote e os tamanhos dos fragmentos.

Comandos de Prioridade LLQ / IP RTP:

  • show policy-map interface multilink interface# - Este comando é muito útil para exibir a operação de LLQ e descartes no PQ. Para obter mais informações sobre os diversos campos deste comando, consulte Entendendo os contadores de pacotes na saída de show policy-map interface.

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

  • show queue interface-type interface-number - Este comando lista a configuração de enfileiramento e as estatísticas consideráveis para uma determinada interface.

  • Debug priority - Este comando debug exibe eventos de fila de prioridade e se ocorreram descartes nesta fila. Consulte também Solucionando Problemas de Descartes de Saída com Filas de Prioridade.

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

  • show call active voice - Este comando é útil para verificar pacotes perdidos e o nível de DSP.

Outros Comandos/Referências:

Problemas Conhecidos:

  • CSCds43465: "LLQ, Policer, Shaper Should Take CRTP Compression Feedback" Para consultar Release Notes, consulte Bug ToolKit (clientes registrados somente) .

Diretrizes:

Estes são alguns passos básicos de solução de problemas, assim que o link ppp estiver ativo e funcionando (MLPPP, Fragmentação, Intercalação):

  1. show call active voice - Use para verificar a existência de pacotes perdidos no nível de DSP.

  2. show interface - Use esse comando para verificar problemas de interface ou linha serial. Quedas na interface não significam um problema ainda, mas é preferível descartar o pacote na fila de prioridade baixa antes de atingir a fila da interface.

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

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

Exibição de amostra e Saída de depuração

 
                  
                     !-----------------------------------------------
 !-----------------------------------------------
 !--- Para capturar seções desta saída, a largura de banda de LLQ PQ
 !---- foi diminuída e o tráfego de dados maiores foi colocado
 !---- no link para forçar alguns descartes de pacotes.
 !-----------------------------------------------
 !-----------------------------------------------

 !---- Verificação de Descartes de Pacotes (Durante uma Chamada Ativa)

 !--- Pressupondo que seu link ppp esteja ativo e funcionando, o primeiro passo da verificação de
 !--- problemas de qualidade de voz é verificar pacotes perdidos
 !--- no DSP. Observação: Use o comando show call active voice
 !--- NÃO o comando show call active voice brief
                     
                  
 maui-voip-austin#show call active voice
                  Total de segmentos de chamada: 2
                  
                     
                         !--- Indica que a conexão foi estabelecida e ambos os segmentos existem
                     
                  
 GENERIC:
          SetupTime=155218260 ms
          Index=1
          PeerAddress=5000
          PeerSubAddress=
          PeerId=2
          PeerIfIndex=13
          LogicalIfIndex=0
          ConnectTime=155218364
          CallDuration=00:00:27
          CallState=4
                  
                      !--- indica que é a chamada ativa
 !--- (#define D_callActiveCallState_active 4).
                            CallOrigin=2
          ChargedUnits=0
          InfoType=2
          TransmitPackets=365
          TransmitBytes=7300
          ReceivePackets=229
          ReceiveBytes=4580

 VOIP:

                      !--- Para esta chamada, este foi o gateway de terminação.
 !--- Neste gateway, a chamada começou no segmento VoIP.
                  
          ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          RemoteIPAddress=172.22.130.1
                  
                      !--- Indica em qual endereço IP o fluxo RTP tem origem.
                  
                            RemoteUDPPort=18778
          RemoteSignallingIPAddress=172.22.130.1
                  
                      !--- Indica de qual endereço IP as mensagens de sinalização estão vindo.
                  
          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
                  
                      !--- Indica a presença de variação, pacotes perdidos, ou
 !--- pacotes corrompidos.
                  
 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



                      !----------------------------------------------------------
 !--- Verificação de Interface

 !--- Verifique se você está vendo isso:
 !--- LCP Open, multilink Open: Link control protocol (LCP) open statement
 !--- indica que a conexão foi estabelecida.
 !--- Open:IPCP. Indica que o tráfego de IP pode ser transmitido via link PPP.
                  

 maui-voip-sj#show interface multilink 1

                  Multilink1 está funcionando, o protocolo de linha está funcionando
   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
----------------------------------------------------------------

                     !-- Observação: Não há descartes no nível da interface.
!-- Todo o tráfego que é descartado devido à vigilância é
!-- descartado antes de chegar à fila da interface.
                  

maui-voip-austin#show interface
                  serial 0/0Serial0/0 está funcionando, o protocolo de linha está funcionando
  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 de descartes de saída: 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


                     !-----------------------------------
!--- Verificação de LLQ
                     
                  

maui-voip-austin#show policy-map int multilink 1
 Multilink1
 Service-policy output: voice-policy

                   Class-map: voice-signaling (match-all)
                  
                     !--- Esta é a classe do tráfego de sinalização de voz.
                  
         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)
         (pacotes correspondidos/bytes correspondidos) 10/744
          (depth/total drops/no-buffer drops) 0/0/0

                  Class-map: voice-traffic (match-all)
                  
                     !--- Esta é a classe de PQ do tráfego de voz.
                  
         458 packets, 32064 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 102
         Weighted Fair Queueing
         Prioridade Estrita
         Output Queue: Conversation 40
         Largura de banda 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

                     !---------------------------------------------
                  
                  
                     !--- Verificar a configuração de mapa de classes
                  
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


                     !--- Verificar as listas de acesso dos mapas de classe
                  
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)


                     !--- Verificar a configuração do mapa de políticas
                  
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
            Prioridade Estrita
            Largura de banda 50 (kbps) Intermitência 1250 (Bytes)
    Class class-default
      Weighted Fair Queueing
            Flow based Fair Queueing Max Threshold 64 (packets)
---------------------------

                     !--- O comando Debug priority fornece feedback imediato em caso
!--- de descartes de pacotes VoIP.
!--- A saída abaixo mostra a mensagem de erro quando pacotes de VoIP
!--- estão sendo descartados da fila de prioridade estrita. 
                  
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

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


                     
                        !--- Verificação de Fragmentação e a Intercalação (LFI)de Links
                     
                  

maui-voip-sj#show ppp multilink
                  
                     !--- Verificar o multilink e o tamanho da fragmentação
                  
                  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

                       !--- Observe que o tamanho da fragmentação é 160 Bytes. O link está configurado com uma
  !--- largura de banda de 128 Kbps e atraso de serialização de 10 mseg.
  !--- Tamanho do Fragmento (em bits) = largura de banda * atraso de serialização.
  !--- Observação: Há 8 bits em um byte.
                  

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

                     
                        !--- Verificação de Fragmentação e a Intercalação (LFI)de Links

!--- Testando Multilink PPP Link LFI
!--- Esta saída exibe informações sobre fragmentação e intercalação.
!--- quando o link PPP de 128 Kbps estiver carregado com muitos dados e pacotes VoIP.
                  

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: Pacote intercalado da fila 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
-------------------------------------------------------------------


                     !--- exemplo do comando show ip rtp header-compression
                     
                  
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

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


                     !--- Este comando exibe informações sobre o comando voip dial-peers.
                  
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:
        tipo= 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.

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

                     !---A utilização de CPU do roteador não deve exceder 50-60 por cento
!--- em qualquer intervalo de cinco minutos.
                  
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



Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 7111