Cómo verificar problemas de MGCP con ISDN?

Pablo Daniel Gonzalez Jimenez · ‎01-31-2012

Hola,

En este blog estaré explicando cómo verificar y solucionar problemas comunes que nos enfrentamos en el ámbito de VoIP. Uno de los primeros temas que trataré serán los gateways MGCP configurados con ISDN. Espero que les ayude en caso de que se enfrenten algun problema de este tipo.

En esta sección mostraré los comandos más útiles para verificar cuando un Gateway de MGCP con PRI ISDN no se encuentra funcionando correctamente. Debido a que MGCP es un protocolo Master/Slave tendrá que contactar al CUCM (Cisco Unified Communicaitons Manager) para su funcionamiento.

Uno de los problemas más comunes es el registro de dicho Gateway. Para verificar que el Gateway se encuentra correctamente registrado con el CUCM se puede utilizar el siguiente comando:

show ccm-manager

#show ccm-manager

MGCP Domain Name: MGCP.domain.com

Priority Status Host

============================================================

Primary Registered 192.168.1.45

First Backup None

Second Backup None

Current active Call Manager: 192.168.1.45

Backhaul/Redundant link port: 2428

Failover Interval: 30 seconds

Keepalive Interval: 15 seconds

Last keepalive sent: 07:25:47 PST Jan 31 2012 (elapsed time: 00:00:10)

Last MGCP traffic time: 07:25:47 PST Jan 31 2012 (elapsed time: 00:00:10)

Last failover time: 16:32:30 PST Jan 29 2012 from (192.168.1.45)

Last switchback time: 16:33:15 PST Jan 29 2012 from (192.168.1.44)

Switchback mode: Graceful

MGCP Fallback mode: Not Selected

Last MGCP Fallback start time: None

Last MGCP Fallback end time: None

MGCP Download Tones: Disabled

TFTP retry count to shut Ports: 2

Backhaul Link info:

Link Protocol: TCP

Remote Port Number: 2428

Remote IP Address: 192.168.1.45

Current Link State: OPEN

Statistics:

Packets recvd: 55

Recv failures: 0

Packets xmitted: 55

Xmit failures: 0

PRI Ports being backhauled:

Slot 1, VIC 0, port 0

FAX mode: disable

Configuration Error History:

Si el gateway no se encuentra registrado hay que verificar que la configuración sea la correcta. Debido a que MGCP es Master/Slave hay que verificar que la interfaz se encuentra enlazada con CUCM a nivel de capa 3:

interface Serial1/0:23

no ip address

isdn switch-type primary-ni

isdn incoming-voice voice

isdn bind-l3 ccm-manager

Otro comando que nos ayudará a verficar esto será:

show ccm-manager backhaul

#show ccm-manager backhaul

Backhaul Link info:

Link Protocol: TCP

Remote Port Number: 2428

Remote IP Address: 192.168.1.45

Current Link State: OPEN

Statistics:

Packets recvd: 55

Recv failures: 0

Packets xmitted: 55

Xmit failures: 0

PRI Ports being backhauled:

Slot 1, VIC 0, port 0

La configuración básica dentro del gateway de MGCP deberá ser la siguiente:

ccm-manager redundant-host <Dirección IP del servidor secundario>

!

ccm-manager mgcp

!

controller T1 1/0

framing esf

linecode b8zs

pri-group timeslots 1-24 service mgcp

!

voice-port 1/0:23

!

mgcp

mgcp call-agent <Dirección IP del servidor primario> service-type mgcp version 0.1

Debido a su reliación con CUCM, también se puede obtener la configuración directamente de CUCM con los siguientes comandos:

ccm-manager config

ccm-manager config server <Dirección IP del servidor TFTP>

Este comando permitirá al gateway obtener su configuración y todos los paquetes de default a través del CUCM.

Si ya se verificó la configuración y aun así el gateway tiene problemas para registrarse se puede verificar que el modelo correcto de Gateway haya sido agregado en la página de configuración de CUCM. Para verificar que modelo de router y de tarjeta a utilizar se puede verificar desde el inventario:

show inventory

#show inventory

NAME: "2811 chassis", DESCR: "2811 chassis"

PID: CISCO2811 , VID: V04 , SN:

NAME: "WAN Interface Card - Serial (1T) on Slot 0 SubSlot 0", DESCR: "WAN Interface Card - Serial (1T)"

PID: WIC-1T= , VID: 1.0, SN:

NAME: "High Density Voice2 Network module with on board one port interface on Slot 1", DESCR: "High Density Voice2 Network module with on board one port interface "

PID: NM-HDV2-1T1/E1 , VID: V02 , SN:

NAME: "One port T1 voice interface daughtercard on Slot 1 SubSlot 0", DESCR: "One port T1 voice interface daughtercard"

PID: VWIC-1MFT-T1= , VID: , SN:

NAME: "PVDMII DSP SIMM with one DSP on Slot 1 SubSlot 3", DESCR: "PVDMII DSP SIMM with one DSP"

PID: PVDM2-16 , VID: NA , SN:

Otro punto importante a verificar será el hostname y dominio del gateway dentro de la página de CUCM. Si el gateway tiene un dominio se tendrá que introducir el hostname.dominio como nombre en la página de configuración de CUCM para que este pueda registrarse. En caso de no tener dominio solamente se tendrá que poner el hostname.

Estos son los problemas más comunes que hay que verificar cuando un gateway de MGCP no logra registrarse correctamente. Si los puntos anteriores han sidos verificados y el gateway aún no logra registrase, recomiendo que utilicen el siguiente debug para verificar que es lo que esta sucediendo: debug mgcp packets

Con dicho debug ustedes podrán verficar la comunicación e intercambio de paquetes entre CUCM y MGCP. El regsitro básico de un gateway MGCP es el siguiente:

Una conexión TCP se abre entre el gateway y el CUCM.
El gateway envía un mensaje RSIP hacia CUCM para informar que entrará en servicio.
CUCM regresa un mensaje de AUEP por endpoint. Este mensaje solicita los atributos y capabilidades de cada endpoint. CUCM enviará el mensaje para cada DS0 en un enlace PRI.
El gateway reconoce el mensaje con un ACK que contendrá la información de dicho endpoint.
CUCM responde con un mensaje de RQNT por endpoint, listando los eventos que requiera ser notificado.
Nuevamente el gateway reconocera los mensajes. Finalmente el gateway y sus endpoints se registran con CUCM.

En la siguiente liga se explica el registro y algunas causas probables:

MGCP Gateway Registration Failure with Cisco CallManager

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00805a316c.shtml

Y en la siguiente liga encontrarán un ejemplo de cómo se observa el debug mgcp packets:

Sample of Debug MGCP Packets

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_tech_note09186a0080174804.shtml

Para verificar que nuestros endponints se encuentran activos podemos verificar con el siguiente comando:

show mgcp endpoint

#show mgcp endpoint

Interface T1 1/0/0

ENDPOINT-NAME V-PORT SIG-TYPE ADMIN

S1/SU0/ds1-0/1@MGCP 1/0/0:23 none up

S1/SU0/ds1-0/2@MGCP 1/0/0:23 none up

S1/SU0/ds1-0/3@MGCP 1/0/0:23 none up

S1/SU0/ds1-0/4@MGCP 1/0/0:23 none up

S1/SU0/ds1-0/5@MGCP 1/0/0:23 none up

S1/SU0/ds1-0/6@MGCP 1/0/0:23 none up ...

Ahora bien, cómo podemos verificar el estado del servicio de ISDN? Los puntos más importantes a verificar para que nuestro servicio funcione correctamente son:

Tener configurado el reloj
Tener el servicio adecuado de isdn
Verificar que la controladora tenga el servicio de pri mgcp junto con el linecode y framing correcto
Verificar que la interfaz y el puerto de voz no se encuentren en estado de shut

Los comandos más útiles para verificar que nuestras capas están funcionando correctamente será el siguiente y deberá mostrar que la capa 2 se encuentre en el estado de MULTIPLE_FRAME_ESTABLISHED:

show isdn status

#show isdn status

Global ISDN Switchtype = primary-ni

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial1/0/0:23 interface

dsl 0, interface ISDN Switchtype = primary-ni

L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask: 0x8000003F

Number of L2 Discards = 0, L2 Session ID = 9

Total Allocated ISDN CCBs = 0

El lincode y framing se pueden verificar directamente desde la controladora:

show controller <t1/e1>

#show controller t1

T1 1/0/0 is up.

Applique type is Channelized T1

Cablelength is long gain36 0db

No alarms detected.

alarm-trigger is not set

Soaking time: 3, Clearance time: 10

AIS State:Clear LOS State:Clear LOF State:Clear

Version info Firmware: 20090113, FPGA: 20, spm_count = 0

Framing is ESF, Line Code is B8ZS, Clock Source is Line.

Current port master clock:recovered from backplane

Data in current interval (326 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

Total Data (last 24 hours)

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

Además hay que verificar que no se tenga ningún error de Slip, de lo contrario hay que estar seguros que tenemos el reloj configurado con los siguientes comandos:

network-clock-participate <Wic/Slot>

network-clock-select <prioridad> <controladora>

Si aún así las llamadas fallan recomiendo obtener una traza detallada de CUCM junto con el debug isdn q931 para poder verificar cuál es la causa de desconexión: