Dépannage de la désinscription d'un téléphone IP - Étude de cas

Introduction

Ce document décrit les informations qui peuvent être utilisées pour dépanner votre configuration.

Le téléphone IP Cisco utilise un mécanisme de maintien en vie au niveau des applications en plus du mécanisme de maintien en vie TCP au niveau du réseau. Le mécanisme Keep-Alive pour les périphériques SCCP (Skinny Call Control Protocol) et SIP (Session Initiation Protocol) garantit que le périphérique reste enregistré avec le contrôle des appels. Ils sont également destinés à rétablir la connexion des périphériques avec le contrôle des appels.

Conditions préalables 

Conditions requises

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

Components Used

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

Mécanisme de maintien et de basculement SCCP

SCCP utilise le protocole TCP pour le transport et utilise les ports 2000 et 2443 (pour sécurisés) pour établir la connexion au Call Manager. Les téléphones SCCP doivent établir une connexion TCP avec Cisco Unified Communications Manager (CUCM) avant de s'y inscrire. Ensuite, une connexion TCP en trois étapes se produit sur le port 2000 pour établir un canal de communication. Le téléphone initie cette connexion en envoyant un SYN (synchroniser) à CUCM et CUCM répond avec SYN, ACK (accusé de réception). Le téléphone répond à son tour par un ACK et la connexion TCP est établie.

Garder-vie

Il existe deux méthodes de conservation : Niveau application (SKINNY keep-alive) et niveau réseau (TCP keep-alive)

Basculement

Dans un scénario idéal, un téléphone SCCP conserve une connexion TCP établie au CUCM principal et au CUCM de première sauvegarde. Le téléphone SCCP envoie le message keep-alive à tous les CUCM auxquels il a établi une connexion TCP. Le serveur principal répond ensuite au maintien en vie SCCP. L'intervalle de temps est de 30 secondes pour le serveur principal et de 60 secondes pour le serveur de sauvegarde.

Le CUCM principal répond avec l'ACK de keepalive SCCP qui reconnaît à la fois la connexion SCCP et TCP. Le CUCM de sauvegarde envoie simplement un ACK TCP au message de maintien en vie envoyé par le téléphone. Lorsque le téléphone ne parvient pas à sauvegarder CUCM parce que le service Call Manager n'est pas disponible ou que la connexion TCP elle-même n'est pas disponible avec le CUCM principal, il utilise deux types de mécanismes pour détecter la défaillance du CM principal et ils sont normaux et retardés.

Basculement normal

Cette méthode utilise un algorithme pour calculer la moyenne du temps que le CUCM prend pour accuser réception de la conservation précédente.

Par exemple, si CUCM prend en moyenne X secondes pour répondre aux 10 000 dernières keepalives, le téléphone attend X secondes avant de détecter la défaillance de CUCM. Ensuite, il tentera de s'inscrire au CUCM de sauvegarde.

Basculement retardé

Dans ce mécanisme, le téléphone attend les 3 intervalles de maintien en vie pour détecter la défaillance du CUCM principal.

Retard

Les réseaux où le temps de transit des paquets fluctue, le basculement différé permet d'éviter les désinscriptions inutiles. 

Exemple de variation du temps de transit (notez le délai de 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

[an error occurred while processing this directive]

Avantage

Ce mécanisme peut être utilisé dans les réseaux sensibles au délai.

  

Maintien en vie du SIP

Le téléphone SIP s'enregistre auprès de CUCM et envoie le message de maintien en vie toutes les 120 secondes, conformément aux paramètres de CUCM. Lorsque le téléphone envoie le registre initial au CUCM principal, il définit le compteur Expire à 3600 secondes (valeur par défaut définie dans le profil SIP appliqué sur le téléphone). CUCM envoie un accusé de réception en modifiant le temporisateur à 120 secondes selon la valeur définie dans le paramètre Service.

Par conséquent, le téléphone envoie le maintien en vie toutes les 120 secondes (en fait, 115 secondes, soit 120 moins la valeur delta configurée dans le profil SIP, qui est de 5 secondes par défaut). Dans ce cas, le téléphone envoie le message keep-alive toutes les 115 secondes.

Le téléphone SIP échange le message Register dans le champ Backup CUCM with Expires défini sur 0.

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

Vers 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

[an error occurred while processing this directive]

Journaux requis 

Afin d'identifier les raisons de la désinscription du téléphone, collectez les informations suivantes :

• Event Viewer Application and System Logs - Fournit des codes d'alarme/d'erreur pour la désinscription du téléphone et l'utilisation que nous pouvons poursuivre le dépannage.

• La capture de paquets à partir du téléphone et de CUCM (principal et de secours) en même temps : aide à isoler la perspective du problème du réseau.

• Suivi de Cisco Call Manager.

Liens pertinents

Collecte de captures de paquets à partir de CUCM

Collecte de la capture à partir du téléphone IP

Collecte de traces CUCM

Analyse des journaux et des captures de paquets

• Le journal de l'application de l'Observateur d'événements imprime le message EndPointUnregistered ainsi qu'un code raison associé.

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]

Les codes raison pour EndPointUnregister se trouvent dans la documentation des messages d'erreur système.

Lecture des journaux Wireshark

Lorsque des captures des deux extrémités sont collectées, pour vérifier que le keepalive envoyé par téléphone atteint ou non le CUCM.

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

Capture à partir du téléphone

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

Capture à partir de CUCM

Le numéro de séquence qui apparaît dans la capture de renifleur de téléphone doit être affiché dans la capture CUCM.

Étude de cas 1.2

Description du problème

Les téléphones SCCP redémarrent régulièrement.

Dépannage

Le journal d'application de l'Observateur d'événements indique que les téléphones ont continué à redémarrer en raison de l'absence de données de conservation avec le code d'erreur 13.

Event Viewer Message.

[an error occurred while processing this directive]

Collectez la capture de paquets à partir du téléphone IP et de CUCM.  Dans ce scénario, le dernier keepalive envoyé à partir du téléphone IP n'a pas atteint CUCM.

Image.

[an error occurred while processing this directive]

Keepalive est abandonné pour cette raison :

Lorsque le téléphone a envoyé un ARP pour obtenir l'adresse MAC de CUCM, la réponse est venue du proxy ARP avec l'adresse MAC ASA. De toute évidence, la première réponse n'a pas été celle du CUCM. Cependant, comme le téléphone le reçoit en premier, il envoie la trame au commutateur avec l’adresse MAC de l’autre périphérique.

Cela se produit principalement lorsque le proxy ARP est activé sur ASA.

Résolution

Désactivez le proxy ARP sur ASA pour résoudre le problème.

Étude de cas 2.

Description du problème

Les téléphones IP Cisco modèle 8961 réinitialisent toutes les 16 minutes et s'enregistrent sur CUCM secondaire. Après 2 minutes, le téléphone revient au CUCM principal et ce cycle se poursuit.

Dépannage

Collecter des captures de paquets à partir du téléphone et des traces CUCM. La désinscription est due au maintien de connexion SIP manqué par le téléphone IP.

Analyse

Le téléphone SIP s'enregistre auprès de CUCM et envoie Keep-alive toutes les 120 secondes, conformément aux paramètres de CUCM.

Lorsque le téléphone envoie le registre initial, il définit le compteur d'expiration à 3 600 secondes (valeur par défaut définie dans le profil SIP appliqué sur le téléphone). CUCM l'accuse réception en modifiant le temporisateur à 120 secondes selon la valeur définie dans le paramètre Service.

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

Dans ce scénario de problème, le téléphone envoie le premier keepalive à 115 secondes et il est abandonné sur le réseau. Cela entraîne la retransmission du keepalive par téléphone en 0,01 secondes (100 ms). Il obtient une réponse de CUCM pour la demande REGISTER.

Maintenant, le téléphone envoie le second keepalive à 115 secondes et il est abandonné dans le réseau. Maintenant, le téléphone passe à l'intervalle REGISTER de nouvelle tentative à 0,02 secondes (200 millisecondes).

Chaque fois que le téléphone envoie le keepalive après 115, il est abandonné sur le réseau et cela fait du téléphone le téléphone pour retransmettre le paquet. Le téléphone augmente également de manière exponentielle l'intervalle de tentatives. Après peu d'actions de maintien de l'activité, les téléphones recommencent à passer à 14 secondes.

Le téléphone retransmet après 14 secondes et reçoit un ACK du CUCM.

La prochaine fois que le téléphone envoie le message keep-alive, il est perdu, puis le téléphone retransmet la demande REGISTER après 28 secondes. Le CUCM ne peut pas attendre 28 secondes, il attend seulement 15 secondes (après les 115), puis il envoie le signal de désinscription.

Le temps de maintien en vie et le temps de récupération (RTO) totalisent jusqu'à 16 minutes et quelques secondes.

Après 16 minutes en raison du signal de désinscription de CUCM, les téléphones s'enregistrent sur CUCM secondaire et après 2 minutes, ils s'enregistrent à nouveau sur Primary et ceci continue.

Cause des pertes de maintien en vie

Lorsque le port du commutateur a été configuré avec la sécurité des ports, l'obsolescence des ports a été configurée avec le minuteur inactif. Le minuteur a été défini sur une minute, soit moins que le minuteur de maintien en vie SIP. Le port de commutateur a ainsi vidé l'adresse MAC du téléphone toutes les minutes. Les paquets continuent à être abandonnés car l'intervalle de maintien en vie du SIP est toutes les 2 minutes.