Dépannez le téléphone IP Unregistration - Une étude de cas

Introduction

Ce document décrit les informations qui peuvent utilisé afin de dépanner votre configuration.

Le téléphone IP de Cisco utilise le mécanisme de keep-alive de niveau application en plus le du mécanisme de keepalive de TCP de niveau du réseau. Le mécanisme de keep-alive pour des périphériques de Protocole SCCP (Skinny Call Control Protocol) et de Protocole SIP (Session Initiation Protocol) s'assure que les séjours de périphérique se sont inscrits au Contrôle d'appel. Ils sont également censés pour rétablir la connexion des périphériques avec le Contrôle d'appel.

Conditions préalables 

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Keeps-alive de SCCP et mécanisme de Basculement

Le SCCP utilise le protocole TCP pour le transport et il emploie le port 2000 et 2443 (pour sécurisé) pour établir le rapport au gestionnaire d'appel. Les téléphones SCCP devraient établir une connexion TCP avec Cisco Unified Communications Manager (CUCM) avant l'enregistrement à elle. Suivant qui, une prise de contact de manière du TCP 3 s'avérera justement sur le port 2000 établir une voie de transmission. Le téléphone initie cette connexion en envoyant une synchronisation (synchronisez) à CUCM et à CUCM répond avec la synchronisation, ACK (accusé de réception). Le téléphone répond consécutivement avec un ACK et la connexion TCP obtient établi.

Keeps-alive

Il y a deux méthodes de keep-alive : Niveau application (keep-alive MAIGRE) et niveau du réseau (keep-alive de TCP)

Basculement

Dans un scénario idéal, un téléphone SCCP maintient une connexion TCP établie au CUCM primaire et à la première sauvegarde CUCM. Le téléphone SCCP envoie la keep-alive à tout le CUCM auquel elle a établi une connexion TCP. Le serveur primaire répond alors à la keep-alive de SCCP. L'intervalle de temps est de 30 secondes au serveur primaire et de 60 secondes au serveur de sauvegarde.

Le CUCM primaire répond de retour avec la keepalive ACK de SCCP qui reconnaît le SCCP et la connexion TCP. La sauvegarde CUCM envoie juste un TCP ACK à la keep-alive envoyée par le téléphone. Quand le téléphone échoue la sauvegarde CUCM parce que le service de gestionnaire d'appel n'est pas disponible ou la connexion TCP lui-même est indisponible avec le CUCM primaire, il emploie deux genres de mécanismes pour détecter la panne primaire cm et ils sont normaux et retardés.

Basculement normal

Cette méthode emploie un algorithme pour calculer la moyenne du temps pris par le CUCM pour reconnaître les keeps-alive précédentes.

Par exemple, si la durée moyenne prise par CUCM est des secondes X à répondre pour les 10000 keeps-alive passées, le téléphone attendra des secondes X avant qu'il détecte la panne de CUCM. Suivant qui, il essayera de s'enregistrer à la sauvegarde CUCM.

Basculement retardé

Dans ce mécanisme, le téléphone attend les 3 intervalles de keep-alive pour détecter la panne du CUCM primaire.

Inconvénient

Les réseaux où le temps de transit des paquets flottent, des aides retardées de Basculement évitent l'unregistration inutile. 

Exemple de fluctuation de temps de transit (notez le retard pour la réponse 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

Avantage

Ce mécanisme peut être utilisé dans les réseaux sensibles de retard.

  

Keep-alive de SIP

Le téléphone SIP s'enregistre au CUCM et envoie à keep-alive toutes les 120 secondes selon les configurations dans CUCM. Quand le téléphone envoie le registre initial à CUCM primaire, il place expire temporisateur à 3600 secondes (ensemble par défaut dans le profil de SIP appliqué au téléphone). CUCM envoie un ACK en modifiant le temporisateur à 120 secondes selon la valeur réglée dans le paramètre de service.

Par conséquent, le téléphone envoie à la keep-alive toutes les 120 secondes (réellement 115 secondes qui est 120 sans la valeur de delta configurée dans le profil de SIP, qui est de 5 secondes par défaut). Dans ce cas, le téléphone envoie à keep-alive toutes les 115 secondes.

Le téléphone SIP permute la sauvegarde CUCM de message de registre avec expire champ réglé à 0.

À primaire

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

À secondaire

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

Logs requis

Afin d'identifier pourquoi l'unregistration de téléphone s'est produit, collectez les informations tracées les grandes lignes :

• Application d'affichage d'événements et logs système - Fournit l'alarme/codes d'erreur pour l'unregistration de téléphone et utilisation cette nous pouvons poursuivre le dépannage.

• Capture de paquet de téléphone et les aides CUCM (primaire et de sauvegarde) en même temps - en isolant le point de vue de réseau de question.

• Suivis de Cisco Call manager.

Liens appropriés

Collecter des captures de paquet de CUCM

Collecter la capture du téléphone IP

Collecter des suivis CUCM

Analyse des logs et des captures de paquet

• Le journal de l'observateur d'événements imprime le message d'EndPointUnregistered et aussi codes de raison relatifs.

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

Codes de raison pour EndPointUnregistration peuvent être trouvés dans la documentation de messages d'erreur de système.

Lecture des logs de Wireshark

Quand des captures de chacun des deux extrémité sont collectées, pour vérifier que la keepalive envoyée par le téléphone atteint réellement le CUCM ou pas.

Le numéro de séquence du paquet TCP aidera facilement à dépister le trafic TCP entre le téléphone et le CUCM dans la capture de renifleur.

Capture de téléphone

Le téléphone envoie un paquet avec le numéro de séquence 2991996107, vérifient que ce paquet atteint le CUCM.

Capture de CUCM

Le numéro de séquence qui est vu dans la capture de renifleur de téléphone devrait être vu dans la capture CUCM.

Étude de cas 1.2

Description du problème

Les téléphones SCCP continuent à redémarrer à intervalles réguliers.

Dépannez

Le journal de l'observateur d'événements indique que les téléphones ont maintenu redémarrer dû aux keepalives manquantes avec code d'erreur de 13.

Event Viewer Message.

Collectez la capture de paquet du téléphone IP et du CUCM.  Dans ce scénario, la dernière keep-alive envoyée du téléphone IP n'a pas atteint CUCM.

Image.

La keep-alive obtient a relâché pour cette raison :

Quand le téléphone a envoyé un ARP pour obtenir l'adresse MAC de CUCM, la réponse est entrée du proxy d'ARP avec le mac-address ASA. Clairement, la première réponse n'était pas de CUCM. Cependant, puisque le téléphone le reçoit d'abord, il envoie la trame au commutateur avec l'adresse MAC de l'autre périphérique.

Ceci se produit en grande partie quand l'ARP-proxy est activé sur l'ASA.

Résolution

Désactivez le proxy d'ARP sur l'ASA pour aborder le problème.

Étude de cas 2.

Description du problème

Le model 8961 de téléphone IP de Cisco téléphone a remis à l'état initial tous les 16 minutes et registres à CUCM secondaire. Après 2 minute les chutes de téléphone de nouveau à CUCM primaire et ce cycle continue.

Dépannez

Collectez les captures de paquet du téléphone et des suivis CUCM. L'unregistration devait SIROTER la keep-alive manquée par le téléphone IP.

Analyse

Le téléphone SIP s'enregistre au CUCM et il envoie à keep-alive toutes les 120 secondes selon les configurations dans CUCM.

Quand le téléphone envoie le registre initial il place expire temporisateur à 3600 secondes (ensemble par défaut dans le profil de SIP appliqué au téléphone). CUCM le reconnaît en modifiant le temporisateur à 120 secondes selon la valeur réglée dans le paramètre de service.

Le téléphone envoie à keepalive toutes les 120 secondes (l'intervalle de keep-alive est de 115 secondes qui est 120 sans la valeur de delta configurée dans le profil de SIP, qui est de 5 secondes par défaut). Dans ce cas le téléphone envoie à keepalive toutes les 115 secondes.

Dans ce scénario de problème le téléphone envoie la première keepalive à 115 seconde et il obtient relâché dans le réseau. Ceci a comme conséquence le téléphone retransmettant la keepalive dans .01 ms seconds(100). Il obtient une réponse de CUCM pour la demande de REGISTRE.

Maintenant le téléphone envoie la deuxième keepalive à 115 secondes et il obtient relâché dans le réseau. Maintenant le téléphone l'augmente est retry interval de REGISTRE à .02 seconde (200 millisecondes).

Chaque fois le téléphone envoie la keepalive après 115, il obtient relâché dans le réseau et ceci fait le téléphone pour retransmettre le paquet. Également le téléphone l'augmente exponentiellement est retry interval. Après peu de telles keeps-alive les téléphones relancent des augmentations à 14 secondes.

Le téléphone le retransmet après 14 secondes et il obtient un ACK du CUCM.

La prochaine fois que quand le téléphone envoie la keep-alive, il est perdu et alors le téléphone retransmet la demande de REGISTRE après 28 secondes. Le CUCM ne peut pas attendre 28 secondes, il attend seulement 15 secondes (après le 115s) alors qu'il envoie le signal d'unregister.

Le temps de keep-alive et le RTO résume à 16 minutes et à quelques secondes.

Après 16 minutes de dû au signal d'unregister de CUCM, les téléphones s'enregistrent à CUCM secondaire et après 2 minutes ils s'enregistrent de nouveau à primaire et ceci continue.

Cause pour les baisses de keep-alive

Quand le port de commutateur a été configuré avec la Sécurité de port, le vieillissement de port a été configuré avec le temporisateur inactif. Le temporisateur a été placé à une minute qui est moins que le temporisateur de keep-alive de SIP. Ceci a eu comme conséquence le port de commutateur vidant le MAC de téléphone chacun minute. Les paquets continuent à être lâchés car l'intervalle de keep-alive de SIP est toutes les 2 minutes.