Solucionar problemas de cancelamento de registro do telefone IP - Um estudo de caso

Introduction

Este documento descreve as informações que podem ser usadas para solucionar problemas de sua configuração.

O telefone IP da Cisco usa o mecanismo de manutenção de atividade no nível do aplicativo além do mecanismo de manutenção de atividade TCP no nível da rede. O mecanismo Keep-Alive para dispositivos Skinny Call Control Protocol (SCCP) e Session Initiation Protocol (SIP) garante que o dispositivo permaneça registrado com o controle de chamadas. Eles também devem restabelecer a conexão de dispositivos com controle de chamadas.

Prerequisites 

Requirements

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

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Manutenção de atividade e mecanismo de failover do SCCP

O SCCP usa o protocolo TCP para Transporte e usa a porta 2000 e 2443 (para segurança) para fazer a conexão com o Call Manager. Os telefones SCCP devem fazer uma conexão TCP com o Cisco Unified Communications Manager (CUCM) antes de se registrar nele. Em seguida, um handshake triplo TCP acontecerá na porta 2000 para estabelecer um canal de comunicação. O telefone inicia essa conexão enviando um SYN (sincronizar) para o CUCM e o CUCM responde com SYN, ACK (confirmação). O telefone, por sua vez, responde com um ACK e a conexão TCP é estabelecida.

Keep-alives

Há dois métodos de manutenção de atividade: Nível de aplicação (manutenção de atividade SKINNY) e nível de rede (manutenção de atividade do TCP)

Failover

Em um cenário ideal, um telefone SCCP mantém uma conexão TCP estabelecida para o CUCM principal e o primeiro CUCM de backup. O telefone SCCP envia keep-alive para todo o CUCM ao qual ele estabeleceu uma conexão TCP. O servidor primário responde então à manutenção de atividade do SCCP. O intervalo de tempo é de 30 segundos para o servidor primário e de 60 segundos para o servidor de backup.

O CUCM principal responde com o SCCP keepalive ACK, que confirma a conexão SCCP e TCP. O CUCM de backup apenas envia um TCP ACK para a manutenção de atividade enviada pelo telefone. Quando o telefone falha ao fazer backup do CUCM porque o serviço Call Manager não está disponível ou a própria conexão TCP não está disponível com o CUCM principal, ele usa dois tipos de mecanismos para detectar a falha primária do CM e eles são normais e atrasados.

Failover normal

Esse método usa um algoritmo para calcular a média do tempo gasto pelo CUCM para confirmar as manutenções de atividade anteriores.

Por exemplo, se o tempo médio gasto pelo CUCM for de X segundos para responder pelos últimos 10.000 keep-alives, o telefone aguardará X segundos antes de detectar a falha do CUCM. Em seguida, ele tentará se registrar no CUCM de backup.

Failover atrasado

Neste mecanismo, o telefone espera pelos 3 intervalos de manutenção de atividade para detectar a falha do CUCM principal.

Desvantagem

Redes onde o tempo de trânsito dos pacotes oscila, o failover atrasado ajuda a evitar o cancelamento de registro desnecessário. 

Exemplo de Flutuação de tempo de trânsito (observe o atraso de tempo para resposta 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]

Vantagem

Esse mecanismo pode ser usado em redes sensíveis a retardo.

  

Manutenção de atividade do SIP

O telefone SIP se registra no CUCM e envia o tipo de atividade a cada 120 segundos de acordo com as configurações no CUCM. Quando o telefone envia o registro inicial para o CUCM principal, ele define o temporizador Expira para 3600 segundos (padrão definido no perfil SIP aplicado no telefone). O CUCM envia um ACK modificando o temporizador para 120 segundos de acordo com o valor definido no parâmetro Serviço.

Portanto, o telefone envia keep-alive a cada 120 segundos (na verdade, 115 segundos, o que é 120 menos o valor delta configurado no perfil SIP, que é 5 segundos por padrão). Nesse caso, o telefone envia a manutenção de atividade a cada 115 segundos.

O telefone SIP troca a mensagem Register para Backup CUCM with Expires (Fazer backup do CUCM com expira) definida como 0.

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

Para Secundário

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 necessários

Para identificar por que ocorreu o cancelamento de registro do telefone, reúna as informações descritas:

• Event Viewer Application and System Logs (Aplicativo do Visualizador de Eventos e Logs do Sistema) - Fornece códigos de alarme/erro para o cancelamento do registro do telefone e o uso que podemos prosseguir com a solução de problemas.

• Captura de pacotes do telefone e do CUCM (principal e de backup) ao mesmo tempo - Ajuda a isolar a perspectiva de rede do problema.

• Cisco Call Manager Traces.

Links relevantes

Coleta de capturas de pacotes do CUCM

Coletando captura do Telefone IP

Coletando rastreamentos do CUCM

Análise dos registros e das capturas de pacotes

• O registro de aplicação do Visualizador de Eventos imprime mensagem EndPointUnregistered e também Códigos de razão relacionados.

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]

Os códigos de razão para o EndPointUnregistration podem ser encontrados na documentação de mensagens de erro do sistema.

Leitura de logs do Wireshark

Quando Capturas de ambas as extremidades são coletadas, para verificar se a manutenção de atividade enviada pelo telefone está realmente chegando ao CUCM ou não.

O Sequence Number do pacote TCP ajudará a rastrear facilmente o tráfego TCP entre o telefone e o CUCM na captura do farejador.

Capturar do telefone

O telefone envia um pacote com o número de sequência 2991996107, verifique se esse pacote chega ao CUCM.

Captura do CUCM

O número de sequência visto na captura do farejador do telefone deve ser visto na captura do CUCM.

Casos Práticos 1.2

Descrição do problema

Os telefones SCCP continuam reiniciando em intervalos regulares.

Troubleshoot

O registro de aplicação do Visualizador de Eventos indica que os telefones continuaram a reiniciar devido à falta de keep alives com o código de erro 13.

Event Viewer Message.

[an error occurred while processing this directive]

Colete a captura de pacotes do telefone IP e do CUCM.  Neste cenário, a última manutenção de atividade enviada do telefone IP não alcançou o CUCM.

Image.

[an error occurred while processing this directive]

A manutenção de atividade está sendo removida por este motivo:

Quando o telefone enviou um ARP para obter o endereço MAC do CUCM, a resposta veio do Proxy ARP com o endereço MAC do ASA. Claramente, a primeira resposta não foi do CUCM. No entanto, como o telefone o recebe primeiro, ele envia o quadro ao switch com o endereço MAC do outro dispositivo.

Isso acontece principalmente quando o proxy ARP está habilitado no ASA.

Resolução

Desative o proxy ARP no ASA para resolver o problema.

Casos Práticos 2.

Descrição do problema

Os telefones Cisco IP Phone modelo 8961 são redefinidos a cada 16 minutos e são registrados no CUCM secundário. Após 2 minutos, o telefone volta para o CUCM principal e esse ciclo continua.

Troubleshoot

Coletar capturas de pacote do telefone e rastreamentos do CUCM. O cancelamento do registro foi devido à falta de manutenção de atividade do SIP pelo telefone IP.

Análise

O telefone SIP se registra no CUCM e envia Keep-alive a cada 120 segundos de acordo com as configurações no CUCM.

Quando o telefone envia o registro inicial, ele define o temporizador de expiração como 3600 segundos (padrão definido no perfil SIP aplicado no telefone). O CUCM reconhece isso modificando o temporizador para 120 segundos de acordo com o valor definido no parâmetro Serviço.

O telefone envia o Keepalive a cada 120 segundos (o intervalo de manutenção de atividade é de 115 segundos, o que é 120 menos o valor delta configurado no perfil SIP, que é de 5 segundos por padrão). Nesse caso, o telefone envia keepalive a cada 115 segundos.

Neste cenário de problema, o telefone envia a primeira manutenção de atividade em 115 segundos e é descartado na rede. Isso resulta na retransmissão do keepalive pelo telefone em 0,01 segundos (100 ms). Ele recebe uma resposta do CUCM para a solicitação REGISTER.

Agora, o telefone envia a segunda manutenção de atividade em 115 segundos e é descartado na rede. Agora, o telefone aumenta o intervalo de nova tentativa do REGISTRO para 0,02 segundos (200 milissegundos).

Toda vez que o telefone envia o keepalive após 115, ele é descartado na rede e isso faz com que o telefone retransmita o pacote. Além disso, o telefone aumenta exponencialmente o intervalo de novas tentativas. Depois de alguns keepalives, a repetição do telefone aumenta para 14 segundos.

O telefone é retransmitido após 14 segundos e recebe um ACK do CUCM.

Na próxima vez em que o telefone enviar keep-alive, ele será perdido e o telefone retransmitirá a solicitação REGISTER após 28 segundos. O CUCM não pode esperar 28 segundos, ele espera apenas 15 segundos (após os 115s) e envia o sinal de cancelamento de registro.

O tempo de manutenção de atividade e o RTO somam até 16 minutos e alguns segundos.

Após 16 minutos devido ao sinal de cancelamento de registro do CUCM, os telefones se registram para o CUCM secundário e depois de 2 minutos eles se registram de volta para o Primário, e isso continua.

Causa das quedas de manutenção de atividade

Quando a porta do Switch foi configurada com segurança de porta, o envelhecimento da porta foi configurado com temporizador inativo. O temporizador foi definido para um minuto, o que é menor que o temporizador de manutenção de atividade SIP. Isso resultou na descarga da porta do switch no MAC do telefone a cada minuto. Os pacotes continuam sendo descartados, pois o intervalo de manutenção de atividade do SIP é a cada 2 minutos.