Solución de problemas de cancelación del registro del teléfono IP - Un caso práctico

Introducción

Este documento describe la información que se puede utilizar para resolver problemas de su configuración.

El teléfono IP de Cisco utiliza el mecanismo de mantenimiento de nivel de aplicación además del mecanismo de mantenimiento de TCP de nivel de red. El mecanismo Keep-Alive para dispositivos Skinny Call Control Protocol (SCCP) y protocolo de inicio de sesión (SIP) garantiza que el dispositivo permanezca registrado con control de llamadas. También se pretende restablecer la conexión de dispositivos con control de llamadas.

Prerequisites 

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Mecanismo de conmutación por fallas y Keep-alives de SCCP

SCCP utiliza el protocolo TCP para el transporte y utiliza los puertos 2000 y 2443 (para asegurar) para realizar la conexión al Call Manager. Los teléfonos SCCP deben establecer una conexión TCP con Cisco Unified Communications Manager (CUCM) antes de registrarse. A continuación, se producirá un intercambio de señales TCP de 3 vías en el puerto 2000 para establecer un canal de comunicación. El teléfono inicia esta conexión enviando un SYN (sincronización) a CUCM y CUCM responde con SYN, ACK (confirmación). El teléfono a su vez responde con un ACK y se establece la conexión TCP.

Keep-alives

Hay dos métodos "keep-alive": Nivel de aplicación (SKINNY keep-alive) y nivel de red (TCP keep-alive)

Failover

En un escenario ideal, un teléfono SCCP mantiene una conexión TCP establecida con el CUCM primario y el primer CUCM de respaldo. El teléfono SCCP envía la señal de mantenimiento a todos los CUCM a los que ha establecido una conexión TCP. El servidor primario responde entonces al mantenimiento SCCP. El intervalo de tiempo es de 30 segundos para el servidor primario y 60 segundos para el servidor de respaldo.

El CUCM primario responde con el ACK de keepalive SCCP que reconoce tanto la conexión SCCP como la conexión TCP. La copia de seguridad de CUCM sólo envía un TCP ACK a la señal de mantenimiento enviada por el teléfono. Cuando el teléfono no puede realizar una copia de seguridad de CUCM porque el servicio Call Manager no está disponible o la conexión TCP en sí no está disponible con el CUCM primario, utiliza dos tipos de mecanismos para detectar la falla de CM principal y son normales y están retrasados.

Falla normal

Este método utiliza un algoritmo para calcular el promedio del tiempo que tarda CUCM en reconocer las señales de mantenimiento anteriores.

Por ejemplo, si el tiempo medio que CUCM tarda en responder durante los últimos 10000 keepalive, el teléfono esperará X segundos antes de detectar la falla de CUCM. A continuación, intentará registrarse en CUCM de respaldo.

Conmutación por fallas retrasada

En este mecanismo, el teléfono espera los 3 intervalos de mantenimiento para detectar la falla de CUCM principal.

Inconveniente

Redes en las que el tiempo de tránsito de los paquetes fluctúa, el failover demorado ayuda a evitar el desregistro innecesario. 

Ejemplo de Fluctuación del Tiempo de Tránsito (Observe el retardo de tiempo para la respuesta de ping):

64 bytes from 10.106.97.150: icmp_seq=1 ttl=63 time=0.100 ms
64 bytes from 10.106.97.150: icmp_seq=2 ttl=63 time=200 ms
64 bytes from 10.106.97.150: icmp_seq=3 ttl=63 time=0.180 ms
64 bytes from 10.106.97.150: icmp_seq=4 ttl=63 time=0.678 ms
64 bytes from 10.106.97.150: icmp_seq=5 ttl=63 time=590 ms
64 bytes from 10.106.97.150: icmp_seq=6 ttl=63 time=0.100 ms
64 bytes from 10.106.97.150: icmp_seq=7 ttl=63 time=345 ms
64 bytes from 10.106.97.150: icmp_seq=8 ttl=63 time=456 ms
64 bytes from 10.106.97.150: icmp_seq=9 ttl=63 time=0.345 ms

[an error occurred while processing this directive]

Ventaja

Este mecanismo se puede utilizar en las redes sensibles al retardo.

  

SIP Keep-alive

El teléfono SIP se registra en el CUCM y envía el mensaje de activación cada 120 segundos según la configuración de CUCM. Cuando el teléfono envía el registro inicial a CUCM principal, establece el temporizadorExpires en 3600 segundos (valor predeterminado establecido en el perfil SIP aplicado en el teléfono). CUCM envía un ACK modificando el temporizador a 120 segundos según el valor establecido en el parámetro Service.

Por lo tanto, el teléfono envía la señal de mantenimiento cada 120 segundos (en realidad, 115 segundos, que es 120 menos el valor delta configurado en el perfil SIP, que es de 5 segundos de forma predeterminada). En este caso, el teléfono envía la señal de mantenimiento cada 115 segundos.

El teléfono SIP intercambia el mensaje Register (Registro) al campo Backup CUCM with Expires (Copia de seguridad de CUCM con vencimiento) establecido en 0.

A principal

REGISTER sip:10.106.114.161 SIP/2.0

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

Max-Forwards: 70

Date: Wed, 15 Jul 2015 12:42:56 GMT

CSeq: 11435 REGISTER

User-Agent: Cisco-CP7975G/9.3.1

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1

Content-Length: 0

Expires: 3600



SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Content-Length: 0



SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>;tag=1708299782

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Expires: 120

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0

Content-Length: 0

[an error occurred while processing this directive]

A secundario

REGISTER sip:10.60.1.12:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.60.63.21:3784;rport;branch=z9hG4bKPjdcJ819aZtTCtmvr0VBheV6p0uL8aC.pG

Max-Forwards: 70

From: <sip:6836@10.60.1.12>;tag=5oI-ew53.DGjTDu5LB9orkdDpZlccNbv

To: <sip:6836@10.60.1.12>

Call-ID: HxTK.m6BH9qxjstVwexTbhVnUxNeuxle

CSeq: 18800 REGISTER

Expires: 0

Contact: <sip:e2b0f175-feae-d664-befa-b7cd0837fcc6@10.60.63.21:5060;transport=TCP>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-e0d1730ac1b1>";+u.sip!devicename.ccm.cisco.com="SEPE0D1730AC1B1";+u.sip!model.ccm.cisco.com="592";expires=0;cisco-keep-alive

Content-Length:  0

[an error occurred while processing this directive]

Registros necesarios

Para identificar el motivo por el que se ha producido la desinscripción del teléfono, recopile la información descrita:

• Event Viewer Application and System Logs - Proporciona códigos de alarma/error para la cancelación del registro del teléfono y con los que podemos continuar con la resolución de problemas.

• Captura de paquetes desde el teléfono y CUCM (tanto primaria como de copia de seguridad) al mismo tiempo. Ayuda a aislar la perspectiva de red del problema.

• Cisco Call Manager Traces.

Enlaces relevantes

Recolección de capturas de paquetes de CUCM

Recopilación de capturas del teléfono IP

Recopilación de rastros de CUCM

Análisis de Registros y Capturas de Paquetes

• El registro de la aplicación Visor de eventos imprime el mensaje EndPointUnregistered y también un código de motivo relacionado.

Example: 31 uc-ucm-01 local7 3 : 41679: uc-ucm-01.pcce.local Jul 02 2015 06:22:31 UTC :   %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEPE0D1730A8137][IPAddress=10.60.98.210][Protocol=SIP][DeviceType=592][Description=Phone][Reason=13][IPAddrAttributes=0][LastSignalReceived=SIPStationDPrimaryLineTimeout][AppID=Cisco CallManager][ClusterID=StandAloneCluster][NodeID=uc-ucm-01]: An endpoint has unregistered

[an error occurred while processing this directive]

Los Códigos de Motivo para EndPointUnregistration se pueden encontrar en la Documentación de Mensajes de Error del Sistema.

Lectura de registros de Wireshark

Cuando se recopilan capturas de ambos extremos, para verificar que la señal de mantenimiento enviada por teléfono está llegando o no a CUCM.

El número de secuencia del paquete TCP ayudará a realizar un seguimiento sencillo del tráfico TCP entre el teléfono y CUCM en la captura del sniffer.

Captura desde el teléfono

El teléfono envía un paquete con el número de secuencia 2991996107, verifique que este paquete alcance el CUCM.

Captura de CUCM

El número de secuencia que se ve en la captura del sabueso del teléfono debe verse en la captura de CUCM.

Caso Práctico 1.2

Descripción de problemas

Los teléfonos SCCP se reinician a intervalos regulares.

Troubleshoot

El registro de la aplicación Visor de eventos indica que los teléfonos siguieron reiniciándose debido a que faltaban señales de mantenimiento con el código de error 13.

Event Viewer Message.

[an error occurred while processing this directive]

Recopile la captura de paquetes del teléfono IP y CUCM.  En este escenario, el último keepalive enviado desde el teléfono IP no llegó a CUCM.

Image.

[an error occurred while processing this directive]

Keep-alive se está descartando debido a esta razón:

Cuando el teléfono envió un ARP para obtener la dirección MAC de CUCM, la respuesta vino del Proxy ARP con la dirección MAC de ASA. Claramente, la primera respuesta no fue de CUCM. Sin embargo, dado que el teléfono lo recibe primero, envía la trama al switch con la dirección MAC del otro dispositivo.

Esto sucede principalmente cuando ARP-proxy está habilitado en ASA.

Resolución

Inhabilite ARP Proxy en ASA para solucionar el problema.

Caso Práctico 2.

Descripción de problemas

Los teléfonos Cisco IP Phone modelo 8961 se restablecen cada 16 minutos y se registran en CUCM secundario. Después de 2 minutos, el teléfono vuelve al CUCM principal y este ciclo continúa.

Troubleshoot

Recopile capturas de paquetes del teléfono y de los rastros de CUCM. La anulación del registro se debió a que el teléfono IP no pudo realizar el registro de SIP.

Análisis

El teléfono SIP se registra en CUCM y envía Keep-alive cada 120 segundos según la configuración de CUCM.

Cuando el teléfono envía el registro inicial, establece el temporizador de vencimiento en 3600 segundos (valor predeterminado establecido en el perfil SIP aplicado en el teléfono). CUCM lo reconoce modificando el temporizador a 120 segundos según el valor establecido en el parámetro Service.

El teléfono envía Keepalive cada 120 segundos (el intervalo de señal de mantenimiento es de 115 segundos, lo que equivale a 120 menos el valor delta configurado en el perfil SIP, que es de 5 segundos de forma predeterminada). En este caso, el teléfono envía keepalive cada 115 segundos.

En esta situación de problema, el teléfono envía la primera señal de mantenimiento a 115 segundos y se deja caer en la red. Esto hace que el teléfono vuelva a transmitir la señal de mantenimiento en 0,01 segundos (100 ms). Recibe una respuesta de CUCM para la solicitud de REGISTRO.

Ahora el teléfono envía la segunda señal de mantenimiento a los 115 segundos y se pierde en la red. Ahora el teléfono aumenta su intervalo de reintento REGISTER a 0,02 segundos (200 milisegundos).

Cada vez que el teléfono envía la señal de mantenimiento después de 115, se descarta en la red y esto hace que el teléfono retransmita el paquete. Además, el teléfono aumenta exponencialmente su intervalo de reintento. Después de unos pocos "keep-alives", los reintentos de los teléfonos aumentan a 14 segundos.

El teléfono se retransmite después de 14 segundos y obtiene una ACK del CUCM.

La próxima vez que el teléfono envíe el mensaje de señal de mantenimiento, se perderá y el teléfono retransmitirá la solicitud de REGISTRO después de 28 segundos. El CUCM no puede esperar 28 segundos, sólo espera 15 segundos (después de los 115) y luego envía la señal de anulación del registro.

El tiempo de espera y el RTO suman hasta 16 minutos y unos segundos.

Después de 16 minutos debido a la señal de cancelación de registro de CUCM, los teléfonos se registran en CUCM secundario y después de 2 minutos vuelven a registrarse en Primario y esto continúa.

Causa de las caídas de señal de mantenimiento

Cuando el puerto del switch se configuró con seguridad de puerto, el envejecimiento del puerto se configuró con temporizador inactivo. El temporizador se configuró en un minuto, que es menor que el temporizador de señal de mantenimiento SIP. Esto provocó que el puerto del switch vaciara la MAC del teléfono cada minuto. Los paquetes se siguen descartando, ya que el intervalo de señal de mantenimiento SIP se produce cada 2 minutos.