A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
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.
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)
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.
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.
Neste mecanismo, o telefone espera os 3 intervalos da manutenção de atividade para detectar a falha do CUCM preliminar.
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 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
Este mecanismo pode ser usado nas redes sensíveis do atraso.
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.
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
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
A fim identificar porque o unregistration do telefone ocorreu, recolha a informação esboçada:
Recolhendo capturas de pacote de informação de CUCM
Recolhendo a captação do telefone IP
Analisando os logs e as capturas de pacote de informação
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.
O telefone envia um pacote com número de sequência 2991996107, verifica que este pacote alcança o CUCM.
O número de sequência que é visto na captação do sniffer do telefone deve ser visto na captação CUCM.
Os telefones SCCP mantêm-se reiniciar em intervalos regulares.
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.
Desabilite o proxy ARP no ASA para endereçar o 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.
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.
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.
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.