Dépannez les échecs d'appel sur des points finaux comité technique enregistrés au Cisco CallManager

Introduction

Ce document explique certains des problèmes courants d'échec d'appel rencontrés avec les terminaux Tandberg Codec (TC) enregistrés auprès de Cisco CallManager et propose des solutions.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

Comment capturer les journaux de débogage H.323

Note: Assurez-vous que la sortie de session SSH (Secure Socket Host) est capturée.

1. SSH dans l’interface de ligne de commande du codec et entrez ces commandes :
   • log ctx H.323Packet debug 9
   • sortie du journal sur (tous les journaux sont affichés sur l'écran de session du terminal de session SSH.)
2. Démarrer un appel et recréer le problème.
3. Entrez les commandes log off et log ctx H.323Packet debug off.

Comment capturer les journaux de débogage SIP (Session Initiation Protocol)

Note: Assurez-vous que la sortie de session SSH est capturée.

1. SSH dans l’interface de ligne de commande du codec et entrez ces commandes :
   • log ctx SIPPacket debug 9
   • sortie du journal sur (tous les journaux sont affichés sur l'écran de session du terminal de session SSH.)
2. Démarrer un appel et recréer le problème.
3. Entrez les commandes log off et log ctx SIPPacket debug off.

Comment collecter des journaux de capture de paquets/points de terminaison à partir des points de terminaison TC

1. Dans l'interface utilisateur Web, sélectionnez Diagnostics > Fichiers journaux et activez la journalisation étendue avec la capture complète des paquets.
2. Démarrer un appel et recréer le problème. Notez que la capture de paquets ne peut être activée que pendant 3 minutes.
3. À partir de l'interface utilisateur Web, sélectionnez Diagnostics > Fichiers journaux et téléchargez l'archive de journal complète et la capture de paquets.

Autres informations requises

• Flux d'appels complet avec tous les périphériques concernés
• Numéro appelé et numéro appelant
• Date et heure du problème

Components Used

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problème : Échecs d'appel dus à un problème d'espace de recherche d'appels (CSS)/de partition sur CallManager

Les appels entre deux terminaux enregistrés dans Cisco Unified Communications Manager (CUCM) risquent d'échouer en raison d'un problème de CSS/Partition sur CUCM.

Capturez les journaux SIP du point d'extrémité appelant. Ce message « 404 Not Found » apparaît dans les journaux SIP du point de terminaison qui proviennent de CUCM :

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

Solution

Complétez ces étapes afin de vérifier le CSS du point de terminaison appelant et la partition du point de terminaison appelé. Assurez-vous que le CSS du point de terminaison appelant a la partition du point de terminaison appelé.

Vous pouvez affecter un CSS au niveau du périphérique et de la ligne sur le point d'extrémité :

1. Choisissez Device > Phone, sélectionnez le point de terminaison et cliquez sur la ligne, puis cochez la case Calling Search Space (CSS) au niveau de la ligne. Dans cet exemple, aucun CSS n'est configuré au niveau de la ligne. Cependant, s'il existe un CSS au niveau du numéro de répertoire, l'un ou l'autre des CSS doit avoir une partie du numéro appelé :

   

2. Vérifiez le CSS affecté au niveau du téléphone. Choisissez Device > Phone et sélectionnez le point de terminaison appelant en question :

   

3. Vérifiez la partition du numéro appelé. Choisissez Device > Phone, sélectionnez le périphérique appelé, cliquez sur la ligne et vérifiez la section Route :

   

4. Après avoir vérifié la partition et le CSS sur les deux points d'extrémité, vérifiez si le CSS du périphérique appelant a la partition du périphérique appelé :

   

   Sinon, cela pourrait être la cause de l'erreur « 404 Not Found ».

Problème : Abandon d'appel SIP après 15 minutes (ou après une heure spécifique)

Généralement, les abandons d'appels à intervalles de temps spécifiques sont provoqués par les temporisateurs SIP ou le dépassement du délai TCP configuré sur les pare-feu, les routeurs, etc.

Solution

Lorsque l'appel se déconnecte à exactement 15 minutes, le problème le plus fréquent est que le délai d'attente TCP configuré sur le réseau (pare-feu, routeurs) est inférieur au délai d'expiration de la session SIP. Par défaut sur CallManager, SIP Session Expire Timer est défini sur 1800 secondes.

Afin de vérifier cela, choisissez Cisco Unified CM Administration > System > Service Parameters > Cisco Call Manager Service > Look for - SIP Session Expires Timer.

Tous les terminaux enregistrés dans CUCM utilisent ce compteur. Lorsque le point de terminaison est en appel avec un autre point de terminaison distant, l'une des parties doit actualiser la session et envoyer une invitation ou une mise à jour. Cette actualisation doit être envoyée avant la moitié du minuteur d'expiration de session (1800/2 = 900 secondes = 15 minutes). Si aucun message d'actualisation n'est reçu, l'appel est déconnecté.

Recherchez le minuteur de session dans l'invitation initiale. Une actualisation (INVITE / UPDATE) doit être reçue avant l'expiration de ce délai :

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

En fonction de la négociation initiale User Agent Client/User Agent Server (UAC/UAS), l'un des points de terminaison actualise la session lorsqu'il envoie une invitation à nouveau. Si l'actualisation est UAC, l'initiateur de l'appel a la responsabilité d'actualiser la session. Si l'actualisation est UAS, le serveur doit actualiser la session. Collectez les journaux de débogage SIP à partir des deux points d'extrémité et vérifiez ces éléments :

Exemple : Appel passé de la Partie A à CUCM à la Partie B. Si l'actualisation est UAC sur la Partie A et UAS sur la Partie B :

1. La partie A doit envoyer le message de nouvelle invitation / MISE À JOUR au CUCM.
2. CUCM doit envoyer une nouvelle invitation / MISE À JOUR à la Partie B.
3. La Partie B reçoit le message de nouvelle invitation et répond à ce message par 200 OK.
4. CUCM doit envoyer 200 OK à la Partie A.

Si un point de terminaison envoie le message de nouvelle invitation au CUCM, CUCM envoie un message de nouvelle invitation à l'autre partie. Cependant, si cela n'est pas reçu par le côté distant, cela peut être dû à certains périphériques réseau situés entre les deux. Il est très possible que le message de réinvitation/réponse ne parvienne pas à l'un des côtés en raison de l'inspection SIP ou des paramètres réseau.

Si les points de terminaison ne lancent pas le message INVITE, cela peut poser problème avec le point de terminaison. Impliquez le centre d'assistance technique (TAC) de Cisco afin d'approfondir vos recherches.

Problème : Abandon d'appel H.323 après une heure spécifique

Comme avec SIP, dans H.323, les appels abandonnent à un intervalle de temps spécifique, généralement en raison de la configuration du délai d'attente du réseau ou du pare-feu.

Solution

Dans les appels H.323, un message RTDR (Round Trip Delay Request) est envoyé toutes les 30 secondes entre les points de terminaison, ainsi que les numéros de séquence . Pour chaque demande, une réponse est attendue.

Cisco Endpoint utilise le message RTDR/Round Trip Delay Response, qui fait partie du message H.245 Multimedia System Control. Cela permet de maintenir la session TCP H.245 en vie pendant l'appel qui est utilisé pour la gestion active des appels. Si le point de terminaison reçoit initialement une réponse pour RTDR et qu'aucune réponse n'est reçue pendant l'appel, le point de terminaison met fin à l'appel.

Dans ce scénario, collectez les journaux de débogage H.323 et les journaux de point de terminaison afin d'isoler le problème. À partir des journaux de débogage H.323, recherchez les messages de requête et de réponse RTDR et découvrez s'il est abandonné.

Dans cet exemple de sortie, le point de terminaison envoie une requête RTDR au point de terminaison distant et ne reçoit pas de réponse de la part de l'extrémité distante. Il déconnecte donc l'appel :

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

Les demandes et les réponses peuvent être suivies avec des numéros de séquence.

Cet exemple des journaux des points de terminaison montre la cause de la déconnexion :

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

Problème : Échec de l'appel en raison d'une défaillance d'allocation des ressources multimédias

Dans le cas d'appels vidéo, les appels qui échouent en raison d'une défaillance d'allocation de ressources multimédias sont visibles. Par exemple, si l'appelant et le point de terminaison appelé ne prennent pas en charge un codec commun, un transcodeur est requis , pour une incompatibilité DTMF (Dual Tone Multi Frequency), un point de terminaison de support (MTP) est requis sur le Call Manager.

Solution

Pour le transcodage vidéo, un transcodeur DSP (Digital Signal Processor) PVDM3 (Packet Voice Digital Module) est requis car les transcodeurs sur PVDM2 ne prennent pas en charge la vidéo. Si aucun transcodeur/MTP n'est disponible, un message 503 Service non disponible est envoyé au point de terminaison :

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

Afin de résoudre ce problème, vérifiez la configuration MRG/MRGL (Media Resource Group/Media Resource Group List) et assurez-vous que le transcodeur vidéo/MTP est disponible. Un MRGL peut être affecté à un périphérique au niveau du téléphone ou du pool de périphériques :

1. Sur CallManager, choisissez Device > Phone et sélectionnez le périphérique qui présente le problème et vérifiez le pool de périphériques et les paramètres MRGL :

   

2. Si le paramètre MRGL du téléphone est Aucun, vous devez vérifier les paramètres du pool de périphériques pour vous assurer qu'il existe un transcodeur.
3. Choisissez System > Device Pool et sélectionnez le pool de périphériques attribué au périphérique :

   

4. Choisissez Media Resources > Media Resource Group List et sélectionnez le MRGL affecté au niveau du téléphone / du pool de périphériques et cochez les MRG :

   

5. Notez les MRG et sélectionnez Media Resources > Media Resource Group et sélectionnez les MRG notés. Vérifiez que vous avez ajouté un transcodeur matériel PVDM3/MTP.

   

Problème : Échecs d'appel en raison d'une bande passante insuffisante

Le plus souvent, il existe des scénarios dans lesquels un appel est déconnecté en raison d'une configuration insuffisante de la bande passante dans Région/Emplacement sur le périphérique dans CUCM. Lorsque la région est définie sur une faible bande passante que le point de terminaison ne peut pas prendre en charge, CallManager envoie un « 488 support non acceptable » avec la cause 125, ce qui signifie « bande passante insuffisante » ou « bande passante insuffisante » après la négociation du support SIP.

Vous devez capturer les journaux SIP sur le point de terminaison comme décrit et rechercher ce message :

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

Solution

Si ce problème se produit, vérifiez la région configurée sur les deux points d'extrémité et vérifiez la relation Région entre eux :

1. Choisissez Device > Phone et sélectionnez les deux périphériques. Vérifiez le pool de périphériques attribué aux périphériques :

   

2. Une fois que vous avez vérifié le pool de périphériques, choisissez System > Device Pool sur CUCM et vérifiez la région configurée sur les deux pools de périphériques :

   

3. Choisissez Système > Informations sur la région > Régions et cochez la case Relation de la région. Vérifiez la bande passante vidéo audio de la région et assurez-vous que le point d'extrémité peut fonctionner à la bande passante audio/vidéo sélectionnée :

   

Dans les captures d'écran ci-dessus, il est supposé qu'un point de terminaison se trouve dans la région « Région de liaison » et l'autre dans la région « Terminaux locaux ».

Une autre solution consiste à tester l'appel vidéo en tant qu'appel audio si la bande passante de l'appel vidéo est insuffisante. Utilisez cette procédure afin de vérifier et configurer :

1. Choisissez Device > Phone et sélectionnez le périphérique appelant qui présente le problème. Vérifiez si le paramètre de cette capture d'écran est coché. Si cette case n'est pas cochée, vérifiez-la pour qu'un appel vidéo revienne à l'audio en cas de problème de bande passante :

   

   Ce problème peut se produire en raison des paramètres d'emplacement sur CallManager .

   Les emplacements peuvent être attribués au niveau du téléphone ou au niveau du pool de périphériques (le niveau du téléphone est prioritaire).

2. Afin de vérifier les paramètres de l'emplacement au niveau du téléphone, choisissez Périphériques > Téléphones et vérifiez l'emplacement sur le point de terminaison appelant et appelé :

   

   L'emplacement peut également être appliqué au niveau du pool de périphériques. Par conséquent, vérifiez d'abord le pool de périphériques des deux points d'extrémité :

   

3. Choisissez System > Device Pool. Dans le pool de périphériques, vérifiez l'emplacement attribué aux points de terminaison appelants et appelés. Dans cet exemple, aucun emplacement n'est attribué au niveau du pool de périphériques. La configuration de l'emplacement du téléphone est utilisée :

   

4. Vérifiez si une bande passante suffisante est configurée entre l'emplacement des points d'extrémité appelants et appelés. Dans cet exemple, un point d'extrémité est supposé se trouver à l'emplacement des points d'extrémité locaux et l'autre à l'emplacement Hub_None et la bande passante pour les appels audio/vidéo et immersifs sont tous configurés comme illimités :

   

Il pourrait y avoir d'autres raisons de déconnexion. Voir la page 178 du Guide d'administration des enregistrements détaillés des appels de Cisco Unified Communications Manager, version 10.0(1) pour les codes de cause de déconnexion.