Voz : Protocolos de gateway

Conceitos Básicos de Solução de Problemas e de Depuração de Chamadas VoIP

7 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (11 Outubro 2005) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Fluxo de Chamadas na Rede
Fluxo de Chamadas do Roteador
Arquitetura de Interface de Telefonia
Verificar a Sinalização Digital e Analógica (Segmento de Chamada POTS)
     show controllers T1 / E1 (digital)
     show voice port
     debug vpm (voice processor module)
Verificar Dígitos Recebidos e Enviados (Segmento de Chamada POTS)
     show dialplan number
     debug vtsp session
Verificar a Sinalização VoIP Ponto a Ponto (Segmento de Chamada VOIP)
     debug voip ccapi inout
Entender Problemas de Quality of Service (QoS)
Detalhes de Códigos de Causa e Valores de Depuração para VoIP
     Causas de Desconexão de Chamadas Q.931 (cause_codes from debug voip ccapi inout)
     Valores de Negociação Codec (de debug voip ccapi inout)
     Tipos de Tom
     Valores de Taxa de FAX e Recursos VAD
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Este documento demonstra técnicas e comandos básicos para solucionar problemas e depurar redes VoIP. Uma visão geral do Fluxo de Chamadas de Voz e Arquitetura de Telefonia em um Roteador Cisco é apresentada, seguida por uma abordagem de solução de problemas de VoIP etapa por etapa, apresentada nestes itens:

  1. Verificar a sinalização digital e analógica.

  2. Verificar os dígitos recebidos e enviados das portas de voz analógicas e digitais.

  3. Verificar a sinalização de VoIP de ponta a ponta.

  4. Entender problemas de Quality of Service (QoS) do VoIP.

  5. Entender detalhes dos códigos de causa e valores de depuração para VoIP.

Observação: Este documento não explica todas as facetas da arquitetura do Cisco IOS® utilizadas nos gateways e gatekeepers do Cisco VoIP. Em vez disso, pretende mostrar quais comandos podem ser utilizados e quais campos das saídas de comando podem ser mais valiosos.

cuidado Cuidado: A depuração do Cisco IOS pode ser intensiva no processador. Tenha muito cuidado ao utilizar as depurações listadas neste documento. Para obter mais informações, consulte Informações Importantes sobre os Comandos de Depuração.

As depurações precisam ser executadas com marcações de data e hora ativadas no log. Ative a marcação de data e hora incluindo os comandos: service timestamps debug datetime msec , service timestamps log datetime msec no modo ativado. As marcações de data e hora ajudam a determinar o intervalo de tempo entre as alterações de estado.

Pré-requisitos

Requisitos

Este documento é direcionado ao pessoal de rede envolvido no desenho e implementação das redes VoIP. Os leitores deste documento devem ter conhecimento destes tópicos:

  • Configuração de VoIP

  • QoS de Voz

Componentes Usados

Este documento não está restrito às versões específicas de software e de hardware. No entanto, as saídas mostradas são baseadas no Cisco IOS® Software Release 12.3(8).

As informações apresentadas neste documento foram criadas a partir dos dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste documento foram iniciados com uma configuração vazia (padrão). Caso esteja trabalhando em uma rede ativa, certifique-se de ter compreendido o possível impacto dos comandos antes de utilizá-los.

Convenções

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

Fluxo de Chamadas na Rede

Um fator importante a ser considerado antes de iniciar a solução de problemas ou depuração do VoIP é que as chamadas de VoIP são feitas de três segmentos de chamadas. Esses segmentos de chamadas são Plain Old Telephone Systems (POTS) na origem, VoIP e POTS no destino. Isso é mostrado neste diagrama. A solução de problemas e a depuração precisam primeiro focalizar em cada segmento individualmente e, em seguida, na chamada VoIP como um todo.

call-legs.gif

Fluxo de Chamadas do Roteador

call-flow.gif

Essas definições explicam a função dos componentes principais exibidos no diagrama de fluxo de chamadas do roteador.

Call Control API (Application Programming Interface) — Três clientes usam a API de controle de chamadas. Os três clientes são a CLI, o agente SNMP (Simple Network Management Protocol (SNMP) e o Aplicativo de Sessão. As principais funções da Call Control API (também referida como CCAPI) são:

  • Identificar os segmentos de chamadas (por exemplo, qual é o correspondente de discagem? de onde vem?).

  • Decidir qual aplicativo de sessão atende a chamada (por exemplo, quem manipula a chamada?).

  • Chamar o manipulador do pacote.

  • Colocar os segmentos de chamada em conferência.

  • Começar a registrar as estatísticas de chamadas

Aplicativo de Sessão e Mapeador de Plano de Discagem — O aplicativo de sessão usa o mapeador de plano de discagem para mapear um número a um correspondente de discagem (POTS local ou VoIP remoto). O mapeador de plano de discagem usa a tabela de correspondente de discagem para localizar os correspondentes de discagem ativos.

Service Provider Interface (SPI) para Telefonia e VoIP — A SPI de telefonia se comunica com os correspondentes de discagem POTS (Analógico: fxs, fxo, e&m Digital: isdn, qsig, e&m entre outros). A SPI VoIP é uma interface específica para os correspondentes de VoIP. Drivers de telefonia/DSP entregam serviços para o SPI de telefonia, enquanto o SPI de VoIP conta com protocolos de sessão.

Arquitetura de Interface de Telefonia

Este diagrama mostra a arquitetura dos blocos de construção de telefonia do roteador Cisco e como eles interagem uns com os outros.

telephony-int.gif

Esta lista descreve as funções e definições dos principais componentes do diagrama:

  • Call Control Application Programming Interface (CCAPI) — Entidade de software que estabelece, termina e conecta segmentos de chamada.

  • Voice Telephony Service Provider (VTSP) — Um processo IOS que lida com solicitações da Call Control API e formula as solicitações apropriadas ao Digital Signal Processor (DSP) ou ao VPM.

  • Voice Processor Module (VPM) — O VPM fica encarregado de conectar e coordenar processos de sinalização entre a Signaling State Machine (SSM) das portas de telefonia, o DSP Resource Manager e o VTSP.

  • DSP Resource Manager — O DSPRM fornece interfaces através das quais o VTSP pode enviar mensagens dos DSPs e para os DSPs.

  • Packet Handler — O Packet Handler encaminha pacotes entre os DSPs e os segmentos de chamada de correspondente.

  • Call Peer — O Call Peer consiste no segmento de chamada oposto. Ele pode ser outra conexão de voz de telefonia (POTS), VoFR, VoATM ou uma conexão VoIP.

Verificar a Sinalização Digital e Analógica (Segmento de Chamada POTS)

Os objetivos para a verificação da sinalização digital e analógica são para:

  • Determinar se a sinalização digital ou analógica no gancho ou fora do gancho apropriada é recebida.

  • Determinar se a sinalização E&M, FXO e FXS apropriada está configurada no roteador e no switch (CO ou PBX).

  • Verificar se os DSPs estão no modo de coleta de dígitos.

Os comandos descritos nessas seções podem ser usados para verificar a sinalização.

show controllers T1 / E1 (digital)

show controllers t1 [slot/port] — Use este comando primeiro. Ele mostra se a conexão digital T1 entre o roteador e o switch (CO ou PBX) está ativa ou inativa e se está funcionando adequadamente. A saída deste comando é semelhante a:

router# show controllers T1 1/0
                  T1 1/0 está ativo.
Applique type is Channelized T1
Cablelength is short 133
Nenhum alarme detectado.
O Framing é is ESF, Line Code é B8ZS, Clock Source é Line
Primary.
Data in current interval (6 seconds elapsed):

	0 Line Code Violations, 0 Path Code Violations
	0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs,
  0 Degraded Mins
	0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
  0 Unavail Secs

Se estiver usando E1, use o comando show controllers e1 . Para obter mais informações, consulte:

show voice port

show voice port slot-number/port — Use este comando para exibir o estado da porta e os parâmetros configurados na porta de voz das placas de interface de voz (VIC) Cisco. Como todos os comandos de IOS, os padrões não são exibidos em show running-config, mas os são com este comando.

Este é o exemplo de saída de uma porta de voz E&M.

router# show voice port 1/0:1
recEive and transMit Slot is 1, Sub-unit is 0, Port is 1
Type of VoicePort é E&M
Operation State é DORMANT
Administrative State é UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Music On Hold Threshold is Set to -38 dBm
In Gain está definido como 0 dB
Out Attenuation está definido como 0 dB
Echo Cancellation está ativado
Echo Cancel Coverage está definido como 16 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out está definido como 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone está definido como US

Voice card specific Info Follows:
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode está normal (poderia ser trunk ou plar)
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Signal Type é wink-start
Operation Type é 2-wire
E&M Type é 1
Dial Type é dtmf
In Seizure está inativo
Out Seizure está inativo
Digit Duration Timing is set to 100 ms

InterDigit Duration Timing is set to 100 ms
Pulse Rate Timing is set to 10 pulses/second
InterDigit Pulse Duration Timing is set to 500 ms
Clear Wait Duration Timing is set to 400 ms
Wink Wait Duration Timing is set to 200 ms
Wink Duration Timing is set to 200 ms
Delay Start Timing is set to 300 ms
Delay Duration Timing is set to 2000 ms
Dial Pulse Min. Delay is set to 140 ms

debug vpm (voice processor module)

Estes comandos são usados para depurar a interface de telefonia VTM:

  • debug vpm signal — Este comando é usado para coletar informações sobre depuração para eventos de sinalização e podem ser úteis para a solução de problemas com a sinalização para um PBX.

  • debug vpm spi — Este comando rastreia a forma na qual a interface de provedor de serviço (SPI) de módulo de porta se conecta à API de controle de chamada. Este comando debug exibe informações sobre como cada indicação de rede e solicitação de aplicativo é manipulada.

  • debug vpm dsp — Este comando exibe mensagens do DSP no VPM para o roteador e pode ser útil caso você suspeite que o VPM não esteja funcionado. É uma maneira simples de verificar se o VPM responde às indicações fora do gancho e para avaliar a duração das mensagens de sinalização provenientes da interface.

  • debug vpm all — Este comando EXEC habilita todos os comandos debug vpm: debug vpm spi, debug vpm signal e debug vpm dsp.

  • debug vpm port — Use este comando para limitar a saída de depuração a uma porta específica. Por exemplo. Esta saída mostra mensagens debug vpm dsp apenas para a porta 1/0/0:

    debug vpm dsp
    
    debug vpm port 1/0/0 

    Para obter mais informações, consulte Comandos de Depuração VoIP.

Saída de Exemplo Para o Comando debug vpm signal

maui-voip-austin#debug vpm signal

                  
                     !--- Porta port 1/0/0 FXS vai do estado "on-hook" para
!--- "off-hook".
                  
htsp_process_event: [1/0/0, 1.2 , 36]
fxsls_onhook_offhook htsp_setup_ind
*Mar 10 16:08:55.958: htsp_process_event:
[1/0/0, 1.3 , 8]


                     !--- Envia um alerta de toque no telefone chamado.
                  
*Mar 10 16:09:02.410: htsp_process_event:
[1/0/0, 1.3 , 10] htsp_alert_notify
*Mar 10 16:09:03.378: htsp_process_event:
[1/0/0, 1.3 , 11]


                     !--- Fim da ligação, a porta vai para "on-hook".
                  
*Mar 10 16:09:11.966: htsp_process_event:
[1/0/0, 1.3 , 6]
*Mar 10 16:09:17.218: htsp_process_event:
[1/0/0, 1.3 , 28] fxsls_offhook_onhook
*Mar 10 16:09:17.370: htsp_process_event:
[1/0/0, 1.3 , 41] fxsls_offhook_timer
*Mar 10 16:09:17.382: htsp_process_event:
[1/0/0, 1.2 , 7] fxsls_onhook_release
               

Se on-hook e off-hook não estiverem sinalizando apropriadamente, verifique estes itens:

  • Verifique se o cabeamento está correto.

  • Verifique se tanto o roteador quanto o switch (CO ou PBX) estão apropriadamente aterrados.

  • Verifique se as duas extremidades da conexão têm configurações equivalentes de sinalização. Configurações incorretas podem fazer com que a sinalização não funcione em um sentido.

Para obter mais informações sobre a solução de problemas de E&M, consulte Entendendo e Solucionando Problemas de Tipos de Interface E & M Analógicas e Instalações de Cabeamento.

Saída de Exemplo Para o Comando debug vpm spi

maui-voip-austin#debug vpm spi
Voice Port Module Session debugging is enabled


                     !--- O DSP é inserido no modo de coleta de dígitos.
                  
*Mar 10 16:48:55.710: dsp_digit_collect_on:
[1/0/0] packet_len=20 channel_id=128
 packet_id=35 min_inter_delay=290
 max_inter_delay=3200 mim_make_time=18 max_make
_time=75 min_brake_time=18 max_brake_time=75

Verificar Dígitos Recebidos e Enviados (Segmento de Chamada POTS)

Quando a sinalização on-hook e off-hook tiver sido verificada e estiver funcionando corretamente, verifique se os dígitos corretos foram recebidos na porta de voz (digital ou analógica). Um correspondente de discagem não é comparado ou o switch (CO ou PBX) não consegue tocar na estação correta se dígitos incompletos ou incorretos forem enviados ou recebidos. Alguns comandos que podem ser utilizados para verificar os dígitos recebidos/enviados são:

  • show dialplan number — Este comando é usado para mostrar qual correspondente de discagem foi alcançado e quando um número telefônico específico é discado.

  • debug vtsp session — Este comando exibe informações sobre como cada indicação de rede e solicitação de aplicativo é processado, indicações de sinalização e mensagens de controle de DSP.

  • debug vtsp dsp — Antes ao Cisco IOS Software Release 12.3, este comando exibia os dígitos conforme são recebidos pela porta de voz. No entanto, no Cisco IOS Software Release 12.3 e mais recente, a saída do comando debug não exibe mais os dígitos. A combinação do debug hpi detail e do debug hpi notification pode ser usada para ver os dígitos de entrada.

  • debug vtsp all — Este comando habilita estes comandos de Voice Telephony Service Provider (VTSP) de depuração: debug vtsp session, debug vtsp error e debug vtsp dsp.

Para obter mais informações, consulte Comandos de Depuração VoIP.

show dialplan number

show dialplan number <digit_string> — Este comando exibe o correspondentes de discagem comparado por uma seqüência de dígitos. Se vários correspondentes de discagem forem encontrados, eles serão todos mostrados na ordem de correspondência.

Observação: Você precisa usar o sinal # no final dos números telefônicos em correspondentes de discagem com comprimento variável para comparação em padrões de destino que terminem com T.

A saída deste comando é semelhante a:

maui-voip-austin#show dialplan number 5000
Dial string terminator: #
Macro Exp.: 5000

VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state está ativado, Operation
        state está ativado,
        incoming called-number = `',
        connections/maximum = 0/unlimited,
        application associated:
        type = voip, session-target =
        `ipv4:192.168.10.2',
        technology prefix:
        ip precedence = 5, UDP checksum =
        disabled, session-protocol = cisco,
        req-qos = best-effort,
        acc-qos = best-effort,
        dtmf-relay = cisco-rtp,
        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 = 25630, Charged Units = 0,
        Successful Calls = 25, Failed Calls = 0,
        Accepted Calls = 25, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call
        clearing.",
        Last Setup Time = 84427934.
        Matched: 5000   Digits: 4
        Target: ipv4:192.168.10.2
               

debug vtsp session

O comando debug vtsp session mostra as informações sobre como o roteador interage com o DSP baseado nas indicações da sinalização da pilha de sinalização e solicitações do aplicativo. Este comando debug exibe informações sobre como cada indicação de rede e solicitação de aplicativo é manipulada, indicações de sinalização e mensagens de controle de DSP.

maui-voip-austin#debug vtsp session
Voice telephony call control session debugging is on


                     !--- Saída é suprimida.
!--- ACTION: Chamador retirou o gancho.
!--- O DSP está alocado, buffers de variação de sinal, limiares
!--- VAD e níveis de sinal estão definidos.
                  

*Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)]
packet_len=18 channel_id=1 packet_id=76 mode=1
initial=60 min=4 max=200 fax_nom=300
*Mar 10 18:14:22.865: dsp_echo_canceller_control:
[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66
flags=0x0
*Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)]
packet_len=12 channel_id=1 packet_id=91
in_gain=0 out_gain=65506
*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)]
packet_len=10 channel_id=1 packet_id=78
thresh=-38act_setup_ind_ack
*Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)]
packet_len=24 channel_id=1 packet_id=73 coding_type=1
 voice_field_size=80
VAD_flag=0 echo_length=64 comfort_noise=1
inband_detect=1 digit_relay=2
AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mod
e()act_setup_ind_ack: passthru_mode = 0,
no_auto_switchover = 0dsp_dtmf_mode
(VTSP_TONE_DTMF_MODE)


                     !--- O DSP é inserido no modo de voz e o tom de discagem é
!--- gerado.
                  

*Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)]
packet_len=30 channel_id=1 packet_id=72 tone_id=4
n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=
4000 amp_of_second=4000 direction=1 on_time_first=65535
off_time_first=0 on_time
_second=65535 off_time_second=0

Se for determinado que os dígitos não estão sendo enviados ou recebidos apropriadamente, então possivelmente será necessário usar um captor de dígitos (ferramenta de teste) ou o testador T1 para verificar os dígitos que estão sendo enviados no intervalo de freqüência e de tempo corretos. Se estiverem sendo enviados "incorretamente" ao switch (CO ou PBX), alguns valores no roteador ou no switch (CO ou PBX) podem possivelmente de ajuste para que correspondam e possam interoperar. Esses valores são geralmente de duração de dígito e interdígito. Outro item a ser examinado se os dígitos parecerem estar sendo enviados corretamente são as tabelas de tradução de números no switch (CO ou PBX) que podem adicionar ou remover dígitos.

Verificar a Sinalização VoIP Ponto a Ponto (Segmento de Chamada VOIP)

Após verificar se a sinalização de porta de voz está funcionando corretamente e os dígitos certos são recebidos, passe para a solução de problemas e depuração do controle de chamada VoIP. Estes fatores explicam o motivo pelo qual a depuração pode tornar-se um trabalho complexo:

  • Gateways VoIP da Cisco utilizam sinalização H.323 para completar chamadas. O H.323 é composto de três camadas de negociação de chamada e estabelecimento de chamada: H.225, H.245 e H.323. Esses protocolos usam uma combinação de TCP e UDP para configurar e estabelecer uma chamada.

  • A depuração VoIP de ponto a ponto mostra um número de máquinas de estado IOS. Problemas com máquinas de estado podem fazer com que uma chamada falhe.

  • A depuração VoIP de ponto a ponto pode ser muito detalhada e criar uma grande quantidade de resultados de depuração.

debug voip ccapi inout

O principal comando para depurar chamadas VoIP de ponto a ponto é debug voip ccapi inout . A saída de uma depuração de chamada é mostrada nesta saída.

                  
                     !--- Ação: Uma chamada VoIP é originada através da
!--- SPI de telefonia (segmento pots) para o ramal 5000.
!--- Parte da saída foi omitida.
                  

maui-voip-austin#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on


                     !--- Identificação do segmento de chamada, correspondente de origem: Chamada
!--- originada do correspondente de discagem 1 pots
!--- (ramal 4000).
                  

*Mar 15 22:07:11.959: cc_api_call_setup_ind
(vdbPtr=0x81B09EFC, callInfo={called=,
calling=4000, fdest=0 peer_tag=1}, callID=0x81B628F0)

                     !--- A CCAPI invoca o aplicativo da sessão.
                  

                  *Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"
*Mar 15 22:07:11.963: sess_appl:
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)


                     !--- Aloca identificadores de segmento de chamada "callid = 0x59"
                  

*Mar 15 22:07:11.963: ccCallSetContext
(callID=0x58, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck
(callID=0x58)


                     !--- Instrua o VTSP a gerar um tom de discagem
                  .

*Mar 15 22:07:11.963: ccGenerateTone
(callID=0x58 tone=8)


                     !--- O VTSP passa dígitos para a CCAPI.
                  

*Mar 15 22:07:20.275:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:20.279: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:20.279: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:20.279: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
*15 de mar 22:07:20.327: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=5
, duration=100)
*Mar 15 22:07:20.327: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:20.327: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.975:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=0,
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:21.979: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:21.979: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.979: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
*Mar 15 22:07:22.075: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:22.079: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:22.079: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.235: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, dgit=0,
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:23.239: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:23.239: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.239: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
*Mar 15 22:07:23.335: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:23.339: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:23.339: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:25.147: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, d
igit=0, flags=0x1, timestamp=0xC2E63BB7,
expiration=0x0)
*Mar 15 22:07:25.147: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:25.147: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:25.147: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
*Mar 15 22:07:25.255: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=160)
*Mar 15 22:07:25.259: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:25.259: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)


                     !--- voip de correspondente de discagem 2 comparado. Número de destino
!--- 5000
                  

                  *15 de mar 22:07:25.259: ssaSetupPeer cid(88)
peer list:tag(2) called number(5000)
*Mar 15 22:07:25.259: ssaSetupPeer cid(88),
destPat(5000), matched(4), prefix(),
peer(81C04A10)


                     !--- Continue a chamar uma interface e inicie o
!--- próximo segmento de chamada.
                  

                  *Mar 15 22:07:25.259: ccCallProceeding
(callID=0x58, prog_ind=0x0)
*Mar 15 22:07:25.259: ccCallSetupRequest
(Inbound call = 0x58, outbound peer =2,
dest=, params=0x81BAF168 mode=0,
*callID=0x81B6DE58)
*15 de mar 22:07:25.259: callingNumber=4000,
calledNumber=5000, redirectNumber=


                     !--- Configuração da chamada VoIP.
                  

                  *Mar 15 22:07:25.263: ccIFCallSetupRequest:
(vdbPtr=0x81A75558, dest=,
callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}, mode=0x0)
*Mar 15 22:07:25.263: ccCallSetContext
(callID=0x59, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert
(callID=0x58, prog_ind=0x8, sig_ind=0x1)


                     !--- Os segmentos de chamada POTS e VoIP são unidos.
                  

                  *Mar 15 22:07:25.375: ccConferenceCreate
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)
                  *Mar 15 22:07:25.375: cc_api_bridge_done
(confID=0x1E, srcIF=0x81B09EFC, srcCall
                  ID=0x58, dstCallID=0x59, disposition=0,
tag=0x0)


                     !--- Intercâmbio de máscaras de bits de capacidade com gateway VoIP
!--- remoto
!--- (Codec, VAD, VoIP ou FAX, FAX-rate, entre outros).
                  

                  *Mar 15 22:07:26.127: cc_api_caps_ind 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59,caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})

                  
                     !--- Ambos os gateways estão com os mesmos recursos.
                  
                  *Mar 15 22:07:26.127: cc_api_caps_ack 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
                  CallId=0x59,caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
                  *Mar 15 22:07:26.139: cc_api_caps_ack
(dstVdbPtr=0x81A75558, dstCallId=0x59, src
CallId=0x58, caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:35.259: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=T
, duration=0)
*Mar 15 22:07:35.259: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:35.259: ssaTraceSct:
cid(88)st(4)oldst(3)cfid(30)csize(0)in(1)
fDest(0)-cid2(89)st2(4)oldst2(1)
*Mar 15 22:07:35.399: cc_api_call_connected
(vdbPtr=0x81A75558, callID=0x59)
*Mar 15 22:07:35.399: sess_appl:
ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0)
*Mar 15 22:07:35.399: ssaTraceSct:
cid(89)st(4)oldst(1)cfid(30)csize(0)in(0)
fDest(0)-cid2(88)st2(4)oldst2(4)


                     !--- A chamada VoIP está conectada.
                  

                  *Mar 15 22:07:35.399: ccCallConnect
(callID=0x58)


                     !--- A chamada VoIP está desconectada. Cause = 0x10
                  

                  *Mar 15 23:29:39.530: ccCallDisconnect
(callID=0x5B, cause=0x10 tag=0x0)
               

Se a chamada falhar e a causa pareça estar na parte VoIP da configuração de chamada, pode ser que você precise analisar a parte do TCP H.225 ou H.245 da configuração da chamada, em vez de apenas a parte UDP da configuração H.323. Os comandos que podem ser usados para depurar a configuração de chamada H.225 ou H.245 são:

  • debug ip tcp transactions e debug ip tcp packet — Estes comandos examinam a parte TCP da negociação H.225 e H.245. Elas retornam os endereços IP, portas TCP e estados das conexões TCP.

  • debug cch323 h225 — Este comando examina a parte H.225 da negociação de chamada e rastreia a transição de estado da máquina de estado H.225 no evento processado. Pense nele como a parte da Camada 1 da configuração de chamada H.323 de três partes.

  • debug ch323 h245 — Este comando examina a parte H.245 da negociação de chamada e rastreia a transição de estado da máquina de estado H.245 com base nos eventos processados. Pense nele como a parte da Camada 2 da configuração de chamada H.323 de três partes.

Entender Problemas de Quality of Service (QoS)

Quando chamadas de VoIP são apropriadamente estabelecidas, a próxima etapa é verificar se a qualidade da voz está boa. Embora a solução de problemas de QoS não seja abordada neste documento, estas diretrizes precisam ser consideradas para se alcançar uma boa qualidade de voz:

  • Entender quanta largura de banda uma chamada VoIP consome com cada codec. Isso inclui a Camada 2 e os cabeçalhos IP/UDP/RTP. Para obter mais informações, consulte Voz sobre IP – Consumo de Largura de Banda por Chamada.

  • Entenda as características da rede IP sobre a qual as chamadas trafegam. Por exemplo, a largura de banda de uma rede frame-relay na CIR é muito diferente daquela acima da CIR (ou intermitência), onde pacotes podem ser transmitidos ou enfileirados na nuvem de Frame-Relay. Certifique-se de que o retardo e a variação de sinal estejam controlados e eliminados ao máximo possível. O retardo de transmissão unidirecional não deverá ultrapassar 150 ms (por recomendação G.114).

  • Use uma técnica de enfileiramento que permita que o tráfego VoIP seja identificado e priorizado.

  • Ao transmitir enlaces de velocidade baixa sobre VoIP, considere usar técnicas de fragmentação de pacote de Camada 2, como o MLPPP com Link Fragmentation and Interleaving (LFI) em enlaces de ponto a ponto, ou FRF.12 em enlaces Frame-Relay. A fragmentação de pacotes de dados maiores permite retardo e variação de sinal menores na transmissão de tráfego VoIP porque os pacotes VoIP podem ser intercalados no link.

  • Tente usar um codec diferente e tente fazer a chamada com o VAD habilitado e desabilitado para possivelmente reduzir o problema ao DSP, em vez de mantê-lo na rede IP.

Com o VoIP, os principais itens que devem ser observados durante a solução dos problemas de QoS são os pacotes descartados e os gargalos de rede que podem causar atrasos e variação de sinal.

Procure:

  • desconexão de interfaces

  • quedas de buffer

  • congestionamento de interface

  • congestionamento de link

Cada interface no caminho da chamada VoIP precisa ser examinada. Além disso, elimine quedas e congestionamento. Também, retardos de round-trip precisam ser reduzidos o máximo possível. Pings entre as extremidades VoIP indicam o retardo de round trip de um enlace. O retardo de round trip não deverá ultrapassar 300 ms sempre que possível. Se o retardo precisar ultrapassar esse valor, são necessários esforços para garantir que ele seja constante, para não gerar variação de sinal ou retardo variável.

A verificação deve ser feita também para assegurar que o mecanismo de enfileiramento do IOS está inserindo pacotes VoIP nas filas adequadas. Comandos IOS, como o show queue interface ou show priority podem auxiliar na verificação de enfileiramento.

Detalhes de Códigos de Causa e Valores de Depuração para VoIP

Use estas tabelas ao ler depurações e valores associados em depurações.

Causas de Desconexão de Chamadas Q.931 (cause_codes from debug voip ccapi inout)

Para obter mais informações sobre Códigos e Valores de Causa Q.931, consulte Tipos de Switch ISDN, Códigos e Valores

Valor de causa de desconexão de chamada (em hex)

Significado e Número (em Decimais)

CC_CAUSE_UANUM = 0x1

número não-atribuído. (1)

CC_CAUSE_NO_ROUTE = 0x3

sem rota para o destino. (3)

CC_CAUSE_NORM = 0x10

esclarecimento de chamada normal. (16)

CC_CAUSE_BUSY = 0x11

usuário ocupado. (17)

CC_CAUSE_NORS = 0x12

nenhuma resposta de usuário. (18)

CC_CAUSE_NOAN = 0x13

nenhuma resposta do usuário. (19)

CC_CAUSE_REJECT = 0x15

chamada rejeitada. (21)

CC_CAUSE_INVALID_NUMBER = 0x1C

número inválido. (28)

CC_CAUSE_UNSP = 0x1F

normal, não especificado. (31)

CC_CAUSE_NO_CIRCUIT = 0x22

sem circuito. (34)

CC_CAUSE_NO_REQ_CIRCUIT = 0x2C

nenhum circuito foi solicitado. (44)

CC_CAUSE_NO_RESOURCE = 0x2F

sem recurso. (47)

CC_CAUSE_NOSV = 0x3F

serviço ou opção não disponível ou não especificado. (63)

Valores de Negociação Codec (de debug voip ccapi inout)

Para obter mais informações sobre CODECs, consulte VoIP – Entendendo Codecs: Complexidade, Suporte, MOS e Negociação.

Valor de negociação

Significado

codec=0x00000001

G711 ULAW 64K PCM

codec=0x00000002

G711 ALAW 64K PCM

codec=0x00000004

G729

codec=0x00000004

G729IETF

codec=0x00000008

G729a

codec=0x00000010

G726r16

codec=0x00000020

G726r24

codec=0x00000040

G726r32

codec=0x00000080

G728

codec=0x00000100

G723r63

codec=0x00000200

G723r53

codec=0x00000400

GSMFR

codec=0x00000800

G729b

codec=0x00001000

G729ab

codec=0x00002000

G723ar63

codec=0x00004000

G723ar53

codec=0x00008000

CLEAR_CHANNEL

Tipos de Tom

Tipos de Tom

Significado

CC_TONE_RINGBACK 0x1

Tom de Toque

CC_TONE_FAX 0x2

Tom de Fax

CC_TONE_BUSY 0x4

Tom de Ocupado

CC_TONE_DIALTONE 0x8

Tom de Discagem

CC_TONE_OOS 0x10

Tom de Sem Serviço

CC_TONE_ADDR_ACK 0x20

Tom de Reconhecimento de Endereço

CC_TONE_DISCONNECT 0x40

Tom de Desconectado

CC_TONE_OFF_HOOK_NOTICE 0x80

Tom que indica que o telefone foi deixado fora do gancho

CC_TONE_OFF_HOOK_ALERT 0x100

Uma versão mais urgente de CC_TONE_OFF_HOOK_NOTICE

CC_TONE_CUSTOM 0x200

Tom Personalizado – usado ao especificar um tom personalizado

CC_TONE_NULL 0x0

Tom Nulo

Valores de Taxa de FAX e Recursos VAD

Valores

Significado

CC_CAP_FAX_NONE 0x1

Fax desativado ou não disponível

CC_CAP_FAX_VOICE 0x2

Chamada de Voz

CC_CAP_FAX_144 0x4

14.400 de baud

CC_CAP_FAX_96 0x8

9.600 de baud

CC_CAP_FAX_72 0x10

7.200 de baud

CC_CAP_FAX_48 0x20

4.800 de baud

CC_CAP_FAX_24 0x40

2.400 de baud

CC_CAP_VAD_OFF 0x1

VAD Desabilitado

CC_CAP_VAD_ON 0x2

VAD Habilitado


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.


Informações Relacionadas


Document ID: 14081