Pesquise defeitos o telefone IP Unregistration - Uns Casos Práticos

Introdução

Este documento descreve a informação que pode usado a fim pesquisar defeitos sua configuração.

Mecanismo de manutenção de atividade do nível do aplicativo dos usos do Cisco IP Phone além do que o o mecanismo da manutenção de atividade do nível de rede TCP. O mecanismo de manutenção de atividade para dispositivos do Skinny Call Control Protocol (SCCP) e do Session Initiation Protocol (SIP) assegura-se de que as estadas do dispositivo se registrem com Controle de chamadas. São significados igualmente restabelecer a conexão de dispositivos com Controle de chamadas.

Pré-requisitos 

Requisitos

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ções de atividade SCCP e mecanismo do Failover

O SCCP usa o protocolo de TCP para o transporte e usa a porta 2000 e 2443 (para fixado) para fazer a conexão ao gerenciador de chamada. Os telefones SCCP devem fazer uma conexão de TCP com o gerente das comunicações unificadas de Cisco (CUCM) antes de registrar-se a ele. Seguindo que, um reconhecimento de sentido TCP 3 acontecerá na porta 2000 estabelecer um canal de comunicação. O telefone inicia esta conexão enviando um SYN (sincronizar) a CUCM e a CUCM responde com SYN, ACK (reconhecimento). O telefone responde por sua vez com um ACK e a conexão de TCP obtém estabelecida.

Manutenções de atividade

Há dois métodos da manutenção de atividade: Aplicativo em nível (manutenção de atividade MAGRO) e nível de rede (manutenção de atividade TCP)

Failover

Em um cenário ideal, um telefone SCCP mantém uma conexão de TCP estabelecida ao CUCM preliminar e ao primeiro backup CUCM. O telefone SCCP envia a manutenção de atividade a todo o CUCM a que tem estabelecido uma conexão de TCP. O servidor primário responde então à manutenção de atividade SCCP. O intervalo de tempo é 30 segundos ao servidor primário e 60 segundos ao servidor de backup.

O CUCM preliminar responde para trás com keepalive ACK SCCP que reconhece o SCCP e a conexão de TCP. O backup CUCM apenas envia um TCP ACK à manutenção de atividade enviada pelo telefone. Quando o telefone falha o backup CUCM porque o serviço do gerenciador de chamada não é disponível ou a conexão de TCP próprio é não disponível com o CUCM preliminar, usa dois tipos dos mecanismos para detectar a falha preliminar CM e são normais e atrasados.

Failover normal

Este método usa um algoritmo para calcular a média do tempo tomado pelo CUCM para reconhecer as manutenções de atividade precedentes.

Por exemplo, se o tempo médio tomado por CUCM é segundos X a responder para as 10000 manutenções de atividade passadas, o telefone esperará segundos X antes que detecte a falha de CUCM. Seguindo que, ele tentará se registrar ao backup CUCM.

Failover atrasado

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

Desvantagem

As redes onde o tempo de trânsito dos pacotes flutua, ajudas atrasadas do Failover evitam o unregistration desnecessário. 

Exemplo da flutuação do tempo de trânsito (note a demora de tempo para a resposta de ping):

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

Vantagem

Este mecanismo pode ser usado nas redes sensíveis do atraso.

Manutenção de atividade do SORVO

O telefone do SORVO registra-se ao CUCM e envia-se a manutenção de atividade cada 120 segundos conforme os ajustes em CUCM. Quando o telefone envia o registro inicial a CUCM preliminar, ajusta-se expira temporizador a 3600 segundos (grupo do padrão no perfil do SORVO aplicado no telefone). CUCM envia um ACK alterando o temporizador a 120 segundos conforme o conjunto de valores no parâmetro de serviço.

Consequentemente, o telefone envia à manutenção de atividade cada 120 segundos (realmente 115 segundos que é 120 menos o valor do delta configurado no perfil do SORVO, que é os segundos 5 à revelia). Neste caso, o telefone envia a manutenção de atividade cada 115 segundos.

O telefone do SORVO troca o backup CUCM da mensagem do registro com expira conjunto de campo a 0.

A preliminar

REGISTER sip:10.106.114.161 SIP/2.0Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4faFrom: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795aTo: <sip:5678@10.106.114.161>Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185Max-Forwards: 70Date: Wed, 15 Jul 2015 12:42:56 GMTCSeq: 11435 REGISTERUser-Agent: Cisco-CP7975G/9.3.1Contact: <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.1Content-Length: 0Expires: 3600SIP/2.0 100 TryingVia: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4faFrom: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795aTo: <sip:5678@10.106.114.161>Date: Wed, 15 Jul 2015 12:42:59 GMTCall-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185CSeq: 11435 REGISTERContent-Length: 0SIP/2.0 200 OKVia: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4faFrom: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795aTo: <sip:5678@10.106.114.161>;tag=1708299782Date: Wed, 15 Jul 2015 12:42:59 GMTCall-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185CSeq: 11435 REGISTERExpires: 120Contact: <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.0Content-Length: 0

A secundário

REGISTER sip:10.60.1.12:5060;transport=tcp SIP/2.0Via: SIP/2.0/TCP 10.60.63.21:3784;rport;branch=z9hG4bKPjdcJ819aZtTCtmvr0VBheV6p0uL8aC.pGMax-Forwards: 70From: <sip:6836@10.60.1.12>;tag=5oI-ew53.DGjTDu5LB9orkdDpZlccNbvTo: <sip:6836@10.60.1.12>Call-ID: HxTK.m6BH9qxjstVwexTbhVnUxNeuxleCSeq: 18800 REGISTERExpires: 0Contact: <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-aliveContent-Length:  0

Logs exigidos

A fim identificar porque o unregistration do telefone ocorreu, recolha a informação esboçada:

• Aplicativo e log de sistema do visualizador de eventos - Fornece o alarme/códigos de erro para o unregistration do telefone e usar-se essa nós podemos continuar com Troubleshooting.

• Captura de pacote de informação do telefone e as ajudas CUCM (preliminar e alternativo) ao mesmo tempo - em isolar a perspectiva de rede da edição.

• Traços do Cisco Call Manager.

Links relevantes

Recolhendo capturas de pacote de informação de CUCM

Recolhendo a captação do telefone IP

Recolhendo traços CUCM

Analisando os logs e as capturas de pacote de informação

• O log de aplicativo event viewer imprime a mensagem de EndPointUnregistered e também códigos de motivo 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

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

Lendo logs de Wireshark

Quando as captações de ambos extremidade forem recolhidas, para verificar que o keepalive enviado pelo telefone está alcançando realmente o CUCM ou não.

O número de sequência de pacote de TCP ajudará facilmente a seguir o tráfego TCP entre o telefone e o CUCM no sniffer para capturar.

Captação do telefone

O telefone envia um pacote com número de sequência 2991996107, verifica que este pacote alcança o CUCM.

Captação de CUCM

O número de sequência que é visto na captação do sniffer do telefone deve ser visto na captação CUCM.

Casos Práticos 1.2

Descrição do problema

Os telefones SCCP mantêm-se reiniciar em intervalos regulares.

Troubleshooting

O log de aplicativo event viewer indica que os telefones mantiveram o reinício devido às manutenções de atividade faltantes com código de erro de 13.

Event Viewer Message.

Recolha a captura de pacote de informação do telefone IP e do CUCM.  Nesta encenação, a última manutenção de atividade enviada do telefone IP não alcançou CUCM.

Image.

A manutenção de atividade está obtendo deixada cair devido a esta razão:

Quando o telefone enviou um ARP para obter o endereço MAC de CUCM, a resposta veio dentro do proxy ARP com endereço MAC ASA. Claramente, a primeira resposta não era de CUCM. Contudo, desde que o telefone a recebe primeiramente, envia o quadro ao interruptor com o MAC address do outro dispositivo.

Isto acontece na maior parte quando o ARP-proxy é permitido no ASA.

Resolução

Desabilite o proxy ARP no ASA para endereçar o problema.

Casos Práticos 2.

Descrição do problema

O modelo 8961 do Cisco IP Phone telefona restaurou cada 16 minutos e registros a CUCM secundário. Após 2 minuto as quedas do telefone de volta a CUCM preliminar e este ciclo continua.

Troubleshooting

Recolha capturas de pacote de informação do telefone e dos traços CUCM. O unregistration era devido SORVER a manutenção de atividade faltada pelo telefone IP.

Análise

O telefone do SORVO registra-se ao CUCM e envia a manutenção de atividade cada 120 segundos conforme os ajustes em CUCM.

Quando o telefone envia o registro inicial ajusta-se expira temporizador a 3600 segundos (grupo do padrão no perfil do SORVO aplicado no telefone). CUCM reconhece-o alterando o temporizador a 120 segundos conforme o conjunto de valores no parâmetro de serviço.

O telefone envia a Keepalive cada 120 segundos (o intervalo da manutenção de atividade é 115 segundos que é 120 menos o valor do delta configurado no perfil do SORVO, que é os segundos 5 à revelia). Neste caso o telefone envia a keepalive cada 115 segundos.

Neste cenário do problema o telefone envia o primeiro keepalive em 115 segundo e obtém deixado cair na rede. Isto conduz ao telefone que retransmite o keepalive em .01 Senhora seconds(100). Obtém uma resposta de CUCM para o pedido do REGISTRO.

Agora o telefone envia o segundo keepalive em 115 segundos e obtém deixado cair na rede. Agora o telefone aumenta-o é intervalo de nova tentativa do REGISTRO a .02 segundo (200 milissegundos).

Cada vez que o telefone envia o keepalive após 115, obtém deixado cair na rede e este faz o telefone para retransmitir o pacote. Igualmente o telefone aumenta-o exponencialmente é intervalo de nova tentativa. Após poucas tais manutenções de atividade os telefones experimentam de novo aumentos a 14 segundos.

O telefone retransmite após 14 segundos e obtém um ACK do CUCM.

A próxima vez que quando o telefone envia a manutenção de atividade, é perdido e então o telefone retransmite o pedido do REGISTRO após 28 segundos. O CUCM não pode esperar 28 segundos, ele espera somente 15 segundos (após o 115s) então que ele envia o sinal remover registro.

O tempo da manutenção de atividade e o RTO resumem a 16 minutos e a alguns segundos.

Após 16 minutos devido ao sinal remover registro de CUCM, os telefones registram-se a CUCM secundário e após 2 minutos registram-se de volta a preliminar e este continua.

Causa para as gotas da manutenção de atividade

Quando a porta de switch foi configurada com Segurança de portas, o envelhecimento da porta foi configurado com temporizador inativo. O temporizador foi ajustado a um minuto que é menos do que o temporizador da manutenção de atividade do SORVO. Isto conduziu à porta de switch que nivela o telefone MAC cada um minuto. Os pacotes mantêm-se ser deixados cair porque o intervalo da manutenção de atividade do SORVO é cada 2 minutos.