Técnicas básicas para resolver problemas y depurar llamadas VoIP

Introducción

En este documento se muestran técnicas y comandos básicos de Troubleshooting y debug de redes VoIP. Se incluye una introducción a la arquitectura de telefonía y flujo de llamadas de voz en un router Cisco, seguida de un enfoque de Troubleshooting de VoIP paso a paso presentado en los pasos siguientes:

1. Verificar la señalización digital y analógica

2. Verificar los dígitos recibidos y enviados desde puertos de voz analógicos y digitales

3. Verificar la señalización de VoIP de extremo a extremo

4. Comprender los problemas de calidad de servicio (QoS) de VoIP

5. Comprender los detalles de códigos de causas y valores de depuración de VoIP

Nota: Este documento no explica todas las facetas de la arquitectura Cisco IOS® utilizada en gateways y gatekeepers VoIP de Cisco. sino que tiene como objetivo mostrar qué comandos se pueden utilizar y qué campos de los resultados de los comandos son más valiosos.

Precaución: La depuración del IOS de Cisco puede requerir un uso intensivo del procesador. Sea precavido a la hora de utilizar las depuraciones indicadas en este documento. Para obtener más información, consulte Información importante sobre comandos de depuración.

Las depuraciones deben ejecutarse con la indicación de fecha y hora en el registro. Active la indicación de fecha y hora agregando los comandos: service timestamps debug datetime msec , service timestamps log datetime msec en modo activado. Las indicaciones de fecha y hora ayudan a determinar el intervalo de tiempo entre cambios de estado.

Prerequisites

Requirements

Este documento está dirigido al personal especializado en redes que participa en el diseño y despliegue de redes VoIP. Quienes lean este documento deben tener conocimiento de los siguientes temas:

• Configuración de VoIP

• QoS de voz

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware. No obstante, los resultados mostrados se basan en Cisco IOS® versión 12.3(8).

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

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

Flujo de llamadas en la red

Un factor importante que hay que tener en cuenta antes de empezar a solucionar problemas de VoIP o a depurar VoIP es que las llamadas VoIP están compuestas por tres tramos de llamada. Dichos tramos de llamada son los sistemas telefónicos convencionales de origen (POTS), VoIP y POTS de destino. Esto se ilustra en el diagrama siguiente: La resolución de problemas y la depuración primero tienen que centrarse independientemente en cada tramo y luego en la llamada VoIP en general.

Flujo de llamadas del router

Las definiciones siguientes explican la función de los principales componentes que se muestran en el diagrama de flujo de la llamada del router:

API de control de llamadas (interfaz de programación de aplicaciones): Tres clientes utilizan la API de control de llamadas. Los tres clientes son: la CLI, el agente del protocolo de administración de red simple (SNMP) y la aplicación de sesión. Las funciones principales de la API de control de llamadas (también conocida como CCAPI) son:

• Identificar los tramos de llamadas (por ejemplo, ¿qué par de marcado es? ¿de dónde procede?).

• Decidir qué aplicación de sesión acepta la llamada (por ejemplo, ¿quién la maneja?).

• Invocar el administrador del paquete.

• Poner juntos en conferencia los tramos de llamada.

• Empezar a registrar las estadísticas de llamadas.

Aplicación de sesión y mapeador del plan de marcado: La aplicación de sesión utiliza el mapeador del plan de marcado para asociar un número a un par de marcado (POTS local o VoIP remoto) El Mapeador del plan de marcado utiliza la Tabla de par de marcado para buscar pares de marcado activos.

Interfaz del proveedor de servicios (SPI) de telefonía y de VoIP — La SPI de telefonía se comunica con POTS (analógico: fxs, fxo, e&m digital: isdn, qsig, e&m, etc). VoIP SPI es la interfaz específica para los pares de VoIP. Los controladores Telephony/DSP prestan servicios al SPI de telefonía mientras el SPI de VoIP cuenta con los protocolos de sesión.

Arquitectura de interfaz de telefonía

Este diagrama muestra la arquitectura de los bloques de construcción del router de Cisco Telephony y cómo interactúan entre sí.

La lista siguiente describe las funciones y definiciones de los principales componentes del diagrama:

• Interfaz de programación de aplicaciones de control de llamadas (CCAPI) — Entidad de software que establece, finaliza y conecta en puente los segmentos de llamada.

• Proveedor de servicio de telefonía de voz (VTSP) — Proceso IOS que da servicio a las solicitudes de la API de control de llamadas y le formula solicitudes adecuadas al procesador de señal digital (DSP) o el VPM.

• Módulo del procesador de voz (VPM): — El VPM se encarga de conectar en puente y coordinar los procesos de señalización entre la máquina de estado de señalización (SSM) de los puertos de telefonía, el administrador de recursos de DSP y el VTSP.

• Administrador de recursos de DSP — El DSPRM proporciona interfaces a través de las cuales el VTSP puede enviar mensajes a los DSP y recibir mensajes de éstos.

• Administrador de paquetes — El administrador de paquetes reenvía paquetes entre los DSP y los segmentos de llamadas de pares.

• Par de llamada — El par de llamada es el segmento de llamada opuesto. Puede tratarse de otra conexión de voz de telefonía (POTS), VoFR, VoATM o una conexión VoIP.

Verificar la señalización digital y analógica (tramo de llamada de POTS)

Los objetivos de la verificación de la señalización digital y analógica son:

• Determinar que se reciba la señalización digital o analógica activada o desactivada adecuada.

• Determinar que esté configurada la señalización E&M, FXO y FXS apropiada en ambos lados del router y del switch (CO o PBX).

• Verifique que los DSP estén en el modo de recolección de dígitos.

Los comandos indicados en estas secciones se pueden utilizar para verificar la señalización.

show controllers T1 / E1 (digital)

show controllers t1 [slot/port] — Utilice este comando primero. Muestra si la conexión T1 digital entre el router y el switch (CO o PBX) está activada o desactivada y si funciona correctamente. El resultado de este comando es como se indica a continuación:

router# show controllers T1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is 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

Si utiliza E1, use el comando show controllers e1. Para obtener más información, consulte:

• Resolución de problemas de capa 1 de T1

• Diagrama de flujo de resolución de problemas de T1

• Resolución de problemas de línea serial

show voice port

show voice port slot-number/port — Ejecute este comando para visualizar el estado del puerto y los parámetros configurados en el puerto de voz de las tarjetas de interfaz de voz (VIC) de Cisco. Al igual que todos los comandos IOS, los valores predeterminados no se muestran en show running-config, pero sí se muestran con este comando.

A continuación, mostramos un resultado de ejemplo de un puerto 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 is E&M 
Operation State is DORMANT
Administrative State is 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 is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal
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:
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal (could be trunk or 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 is wink-start
Operation Type is 2-wire
E&M Type is 1
Dial Type is dtmf
In Seizure is inactive
Out Seizure is inactive
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 (módulo del procesador de voz)

Los comandos siguientes se utilizan para depurar la interfaz de telefonía VPM:

• debug vpm signal — Este comando se utiliza para recopilar información de depuración de eventos de señalización y puede ser útil para resolver problemas con la señalización a un PBX.

• debug vpm spi — Este comando hace un seguimiento del modo en que la interfaz del proveedor de servicios (SPI) del módulo del puerto de voz interactúa con la API de control de llamadas. Este comando depurador muestra información sobre cómo es manejada cada indicación de red y petición de aplicación.

• debug vpm dsp — Este comando muestra mensajes del DSP, en el VPM, al router. Además, puede ser útil si sospecha que el VPM no es funcional. Es una forma sencilla de comprobar si el VPM responde a las indicaciones de descolgar y para evaluar el tiempo de los mensajes de señalización desde la interfaz.

• debug vpm all — El comando EXEC habilita todos los comandos debug vpm: debug vpm spi, debug vpm signal y debug vpm dsp.

• debug vpm port — Este comando sirve para limitar el resultado de la depuración a un puerto concreto. Por ejemplo, este resultado muestra los mensajes de debug vpm dsp del puerto 1/0/0 únicamente:

  debug vpm dsp 
  
  debug vpm port 1/0/0 

  Para obtener más información, consulte Comandos de depuración de VoIP.

Modelo de resultado del comando debug vpm signal

maui-voip-austin#debug vpm signal


!--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state.

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] 


!--- Sends ringing alert to the called phone.

*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] 


!--- End of phone call, port goes "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

Si el estado desactivado y activado no señalizan correctamente, compruebe los elementos siguientes:

• Verifique que el cableado sea correcto.

• Verifique que tanto el router como el switch (CO o PBX) estén correctamente conectados a tierra.

• Verifique que ambos extremos de la conexión cuenten con configuraciones de señalización coincidentes. Las configuraciones que no sean coincidentes pueden producir una señalización incompleta o unidireccional.

Para obtener más información acerca de la resolución de problemas E&M, consulte Comprensión y solución de problemas de tipos de interfaces E&M analógicas y disposición del cableado.

Salida de muestra del comando debug vpm spi

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


!--- The DSP is put into digit collection mode.

*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 los dígitos recibidos y los enviados (tramo de llamada POTS)

Una vez que se haya verificado la señalización del estado desactivado y el estado activado (off-hook y on-hook) y se sabe que éstos funcionan correctamente, verifique que se hayan recibido o enviado los dígitos correctos en el puerto de voz (digital o analógico). No se podrá asociar un par de marcado o un switch (CO o PBX) no podrá llamar a la estación correcta si se envían o reciben dígitos incorrectos. Algunos comandos que se pueden utilizar para verificar los dígitos recibidos/enviados son:

• show dialplan number — Este comando se utiliza para mostrar qué par de marcado se alcanza al marcar un número de teléfono concreto.

• debug vtsp session — Este comando muestra información acerca de cómo se procesa cada aplicación e indicación de red, las indicaciones de señalización y los mensajes de control de DSP.

• debug vtsp dsp — En las versiones anteriores a la versión del software Cisco IOS 12.3, este comando mostraba los dígitos a medida que el puerto de voz los recibía. No obstante, en la versión del software Cisco IOS 12.3 y posteriores, el resultado del comando debug ya no muestra los dígitos. La combinación dedebug hpi detail y debug hpi notification puede utilizarse para ver los dígitos entrantes.

• debug vtsp all : Este comando habilita los siguientes comandos de depuración del proveedor de servicios de telefonía de voz (VTSP): debug vtsp session, debug vtsp error y debug vtsp dsp.

Para obtener más información, consulte Comandos de depuración de VoIP.

show dialplan number

show dialplan number <digit_string> — Este comando muestra el par de marcado que una cadena de dígitos asocia. Si se pueden asociar varios pares de marcado, se mostrarán todos en el orden en el que se asocian.

Nota: Debe utilizar el signo # al final de los números de teléfono para pares de marcado con longitud variable para que coincidan en patrones de destino que terminen con T.

El resultado de este comando es como se indica a continuación:

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 is up, Operation
        state is up,
        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

El comando debug vtsp session muestra información sobre cómo el router interactúa con el DSP basándose en las indicaciones de señalización de la pila de señalización y las solicitudes de la aplicación. El comando debug muestra información acerca de cómo se manejan las solicitudes de aplicación y de indicación de red, las indicaciones de señalización y los mensajes de control de DSP.

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


!--- Output is suppressed. !--- ACTION: Caller picked up handset. !--- The DSP is allocated, jitter buffers, VAD !--- thresholds, and signal levels are set.


*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)


!--- The DSP is put into "voice mode" and dial-tone is !--- generated.


*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

Si se determina que los dígitos no se envían o reciben correctamente, es posible que sea necesario utilizar un captador de dígitos (herramienta de prueba) o un probador de T1 para verificar que los dígitos se envíen con una frecuencia y tiempo correctos. Si se envían "incorrectamente" para el switch (CO o PBX), es posible que algunos valores del router o el conmutador (CO o PBX) necesiten un ajuste de modo que puedan asociarse e interactuar. En general, estos son valores de duración de dígitos y de duración de interdígitos. Otro elemento que debe examinarse si parece que los dígitos se envían correctamente son las tablas de traducción del switch (CO o PBX) que pueden agregar o eliminar dígitos.

Verificación de principio a fin de la señalización de VoIP (Tramo de llamada VOIP)

Después de verificar que la señalización del puerto de voz funciona correctamente y que se reciben los dígitos correctos, pase a la resolución de problemas y depuración del control de llamadas de VoIP. Los factores siguientes explican por qué la depuración del control de llamadas puede convertirse en una tarea compleja:

• los gateways de VoIP de Cisco utilizan señalización H.323 para completar las llamadas. H.323 está formado por tres capas de negociación y de establecimiento de llamadas: H.225, H.245 y H.323. Estos protocolos utilizan una combinación de TCP y UDP para configurar y establecer una llamada.

• La depuración VoIP de extremo a extremo muestra un número de máquinas de estado IOS. Si se producen problemas con alguna máquina de estado, una llamada puede fallar.

• La depuración VoIP de extremo a extremo puede ser muy verbosa y crear un resultado de depuración de gran volumen.

debug voip ccapi inout

El principal comando de depuración de llamadas VoIP de extremo a extremo es debug voip ccapi inout. A continuación, mostramos el resultado de una depuración de llamada.

!--- Action: A VoIP call is originated through the !--- Telephony SPI (pots leg) to extension 5000. !--- Some output is omitted.


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


!--- Call leg identification, source peer: Call !--- originated from dial-peer 1 pots !--- (extension 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)

!--- CCAPI invokes the session application.


*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)


!--- Allocate call leg identifiers "callid = 0x59"


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


!--- Instruct VTSP to generate dialtone
. 

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


!--- VTSP passes digits to 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)
*Mar 15 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)


!--- Matched dial-peer 2 voip. Destination number !--- 5000


*Mar 15 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 to call an interface and start the !--- next call leg.


*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)
*Mar 15 22:07:25.259: callingNumber=4000, 
calledNumber=5000, redirectNumber=


!--- VoIP call setup.


*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)


!--- POTS and VoIP call legs are tied together.


*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)


!--- Exchange capability bitmasks with remote !--- the VoIP gateway !--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth).


*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})


!--- Both gateways agree on capabilities.

*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)


!--- VoIP call is connected.


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


!--- VoIP call is disconnected. Cause = 0x10
 

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

Si la llamada falla y la causa parece radicar en la parte correspondiente a VoIP de la configuración de la llamada, posiblemente tendrá que mirar la parte de H.225 o H.245 TCP de la configuración de la llamada, en oposición a sólo la parte de UDP de la configuración de H.323. Los comandos que pueden usarse para depurar la configuración de llamada H.225 o H.245 son:

• debug ip tcp transactions and debug ip tcp packet — Estos comandos examinan la parte de TCP de la negociación de H.225 y H.245. Devuelven las direcciones IP, los puertos TCP y los estados de las conexiones TCP.

• debug cch323 h225 — Este comando examina la parte de H.225 de la negociación de la llamada y rastrea la transición de estado de la máquina de estado H.225 en función del evento procesado. Considérelo como la parte de la capa 1 de la configuración de llamada H.323 de tres partes.

• debug cch323 h245 — Este comando examina la parte de H.245 de la negociación de la llamada y rastrea la transición de estado de la máquina de estado H.245 en función de los eventos procesados. Considérelo como la parte de la capa 2 de la configuración de la llamada H.323 de tres partes.

Comprender los problemas de calidad del servicio (QoS) de voz sobre IP

Cuando las llamadas VolP se establecen adecuadamente, el paso siguiente consiste en verificar que la calidad de voz sea buena. Aunque en este documento no se cubre la resolución de problemas de QoS, tenga en cuenta las directrices que exponemos a continuación para conseguir una buena calidad de voz:

• Comprenda cuánto ancho de banda consume una llamada VoIP con cada códec. Esto incluye la capa 2 y los encabezados IP/UDP/RTP. Para obtener más información, consulte Voz sobre IP – Consumo de ancho de banda por llamada.

• Comprenda las características de la red IP sobre la que viajan las llamadas. Por ejemplo, el ancho de banda de una red de retransmisión de tramas en CIR es muy diferente del que está por encima de CIR (o ráfaga), en el que los paquetes se pueden abandonar o poner en cola en la nube de Frame Relay. Asegúrese de que el retraso y las fluctuaciones estén controlados y eliminados en lo máximo posible. El retraso de transmisión unidireccional no debe sobrepasar los 150 ms (por recomendación de G.114).

• Utilice una técnica de colocación en cola que permita identificar el tráfico de VoIP y darle prioridad.

• Cuando transmita VoIP en enlaces de baja velocidad, piense en utilizar técnicas de fragmentación de paquetes de la capa 2 como MLPPP con fragmentación y entrelazado de enlace (LFI) en los enlaces de punto a punto, o FRF.12 en los enlaces de retransmisión de tramas. La fragmentación de paquetes de datos más grandes permite una menor fluctuación y menos retraso en la transmisión de tráfico VoIP debido a que los paquetes VoIP pueden ser entrelazados en el link.

• Pruebe con otro códec e intente llamar con VAD habilitado e inhabilitado para en lo posible acotar el problema al DSP, en contraposición con la red IP.

En la resolución de problemas de la Calidad de servicio (QoS), deben tenerse en cuenta principalmente los paquetes descartados y los embotellamientos de red que pueden causar retrasos e inestabilidad.

Busque:

• caídas de la interfaz

• caídas del búfer

• congestión de la interfaz

• congestión de link

Debe examinar cada interfaz del trayecto de la llamada VoIP. Asimismo, elimine los paquetes abandonados y la congestión. Además, el retraso de ida y vuelta debe reducirse lo máximo posible. Los pings entre los puntos finales de VoIP proporcionan una indicación del retraso de ida y vuelta de un enlace. Siempre que sea posible, el retraso de ida y vuelva no debe superar los 300 ms. Si es preciso que el retraso supere este valor, deberán realizarse esfuerzos para asegurarse de que dicho retraso sea constante, de modo que no se introduzca ninguna fluctuación ni retraso variable.

Se deberá hacer la verificación para asegurarse de que el mecanismo de envío a cola del IOS coloque los paquetes VoIP dentro de las colas adecuadas. Los comandos de IOS, como show queue interface o show priority pueden ayudar a verificar la colocación en cola.

Detalles de códigos de causas y valores de depuración para VoIP

Use estas tablas cuando lea las depuraciones y los valores asociados de las depuraciones.

Causas de desconexión de llamada Q.931 (cause_codes from debug voip ccapi inout)

Para obtener más información sobre los códigos de causa Q.931 y los valores, consulte Tipos de switches ISDN, códigos y valores.

^{1 Este problema puede ocurrir debido a una incompatibilidad de códec dentro de la configuración H323, por lo que el primer paso para la solución de problemas es codificar los pares de marcado VoIP para utilizar el códec correcto.}

Valores de negociación de codec (desde el comando debug voip ccapi inout)

Para obtener más información acerca de los CODEC, consulte VoIP: Introducción a los códecs. Complejidad, soporte, MOS y negociación.

‘Tipos de tonos’

Valores de capacidades FAX-Rate y VAD

Información Relacionada

• Configuración de planes de marcado, pares de marcado y manipulación de dígitos
• Comandos de depuración de VoIP
• Resolución de problemas de capa 1 de T1
• Diagrama de flujo de resolución de problemas de T1
• Resolución de problemas de línea serial
• Soporte de tecnología de voz
• Soporte de Productos de Voice and Unified Communications
• Troubleshooting de Cisco IP Telephony
• Soporte Técnico - Cisco Systems

Historial de revisiones