Distribution de vidéo et de contenu : Cisco TelePresence Codec C40

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

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (23 juillet 2015) | Commentaires

Introduction

Ce document explique certaines des questions communes d'échec d'appel confrontées aux points finaux des codecs de Tandberg (comité technique) enregistrés au Cisco CallManager et aux solutions suggérées.

Contribué par Ankita Kanyal, Devasayee Gopalan, et Ishan Sambhi, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

Comment capturer H.323 mettez au point les logs

Remarque: Assurez sécurisent la sortie de session d'hôte de socket (SSH) est capturé.

  1. Le SSH dans les codecs CLI et sélectionnent ces commandes :
    • le ctx H.323Packet de log mettent au point 9
    • sortie de log sur (ceci sort tous les logs à l'écran de session de travail de session de SSH.)
  2. Commencez un appel et recréez le problème.
  3. Entrez dans le log sorti hors fonction et le ctx H.323Packet de log mettent au point outre des commandes.

Comment capturer le Protocole SIP (Session Initiation Protocol) mettez au point les logs

Remarque: Assurez que sortie de session de SSH est capturé.

  1. Le SSH dans les codecs CLI et sélectionnent ces commandes :
    • le ctx SIPPacket de log mettent au point 9
    • sortie de log sur (ceci sort tous les logs à l'écran de session de travail de session de SSH.)
  2. Commencez un appel et recréez le problème.
  3. Entrez dans le log sorti hors fonction et le ctx SIPPacket de log mettent au point outre des commandes.

Comment collecter le point final de saisie de paquet se connecte des points finaux comité technique

  1. Du GUI de Web choisissez les diagnostics > les fichiers journal et l'enable se connecter étendu avec la pleine capture de paquet.
  2. Commencez un appel et recréez le problème. Notez que la capture de paquet peut seulement être activée pendant 3 minutes.
  3. Du GUI de Web choisissez les diagnostics > les fichiers journal et téléchargez la capture complète d'archives et de paquet de log.

D'autres informations requises

  • Écoulement complet d'appel avec tous les périphériques impliqués
  • Numéro appelé et d'appel
  • La date et l'heure de la question se sont produites

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Problème : Échecs d'appel devant appeler la question de l'espace de recherche (CSS) /Partition sur le CallManager

Les appels entre deux points finaux enregistrés à Cisco Unified Communications Manager (CUCM) pourraient échouer en raison d'une question CSS/Partition sur le CUCM.

Capturez les logs appelants de SIP de point final. Ce » message "404 non trouvé apparaît sur les logs de SIP de point final qui proviennent le 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

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

Vous pouvez assigner un CSS au périphérique et niveau à corde sur le point final :

  1. Choisissez le Device > Phone, sélectionnez le point final et cliquez sur en fonction la ligne, et vérifiez l'espace de recherche appelant (CSS) à niveau à corde. Dans cet exemple, aucun CSS n'est configuré à niveau à corde. Cependant s'il y a un CSS au niveau de nombre de répertoire, l'un ou l'autre des CSS doit avoir le partiton du numéro appelé :

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

  3. Vérifiez la partition du numéro appelé. Choisissez le Device > Phone, sélectionnez le périphérique appelé, cliquez sur en fonction la ligne, et vérifiez l'artère Partion :

  4. Après que vous vérifiiez le Partiton et le CSS sur les deux points finaux, vérifiez si le CSS du périphérique appelant a la partition du périphérique appelé :

    Sinon, ceci a pu être la cause de la » erreur "404 non trouvée.

Problème : Baisse d'appel de SIP après 15 minutes (ou après toute heure précise)

Généralement les baisses d'appel à intervalles heure précise sont provoqué par par des sip timer ou le délai d'attente de TCP configuré sur des Pare-feu, des Routeurs, et ainsi de suite.

Solution

Quand les débranchements d'appel à exactement 15 minutes, le problème courant vu est le délai d'attente de TCP configuré sur le réseau (Pare-feu, Routeurs) est moins que la session de SIP expire temporisateur. Par défaut sur le CallManager, la session de SIP expirent temporisateur est placée à 1800 secondes.

Afin de vérifier ceci, choisissez la gestion de Cisco Unified CM > le système > les paramètres de service > le service de Cisco Call managerrecherchent - la session de SIP expire temporisateur.

Tous les points finaux enregistrés à CUCM utilisent ce temporisateur. Quand le point final est à l'appel avec un autre point final distant, un des interlocuteurs doit régénérer la session et envoie une re-INVITATION ou une MISE À JOUR. Ceci régénèrent doit être envoyé avant que la moitié de la session expire 15minutes du temporisateur (1800/2 = 900 secondes =). S'il y a aucun régénérez le message reçu, l'appel est déconnecté.

Vérifiez le temporisateur de session dans l'initiale INVITENT. Une régénération (INVITEZ/MISE À JOUR) devrait être reçue avant que cette fois expire :

|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

Basé sur la négociation initiale du serveur d'agent de /User de client d'agent d'utilisateur (UAC/UAS), un des points finaux régénère la session quand il envoie une Re-INVITATION. Si le rafraîchissement est UAC, le demandeur de l'appel a la responsabilité de régénérer la session. Si le rafraîchissement est UAS, le serveur doit régénérer la session. Collectez le SIP mettent au point des logs des deux points finaux et vérifient ces éléments :

Exemple : Appel passé de l'interlocuteur A à CUCM pour faire la fête le B. Si le rafraîchissement est UAC sur l'interlocuteur A et UAS sur l'interlocuteur B :

  1. Faites la fête A doit envoyer la re-INVITATION/MISE À JOUR au CUCM.
  2. CUCM doit envoyer une re-INVITATION/MISE À JOUR pour faire la fête le B.
  3. L'interlocuteur B reçoit la re-INVITATION et répond à ce message avec un OK 200.
  4. CUCM doit envoyer l'OK 200 pour faire la fête le R.

Si un point final envoie le message de re-INVITATION au CUCM, CUCM envoie une re-INVITATION à l'autre interlocuteur. Cependant, si ceci n'est pas reçu par le côté distant puis ceci pourrait être en raison de quelques périphériques de réseau dans l'intervalle. Il est fortement possible que la re-INVITATION/réponse n'obtienne pas à un des côtés devant SIROTER l'inspection ou les paramètres réseau.

Si les points finaux n'initient pas la re-INVITATION, ce pourrait être un problème avec le point final. Impliquez le centre d'assistance technique Cisco (TAC) afin d'étudier plus plus loin.

Problème : H.323 baisses d'appel après toute heure précise

Comme avec le SIP, dans H.323 des baisses d'appel d'appels à un intervalle heure précise produisez-vous habituellement en raison de la configuration de délai d'attente de réseau ou de Pare-feu.

Solution

Dans H.323 des appels, un message de la demande de délai d'aller-retour (RTDR) est envoyé toutes les 30 secondes entre les points finaux avec des numéros de séquence. Pour chaque demande, une réponse est prévue.

Le point final de Cisco utilise le message de réponse de temps de propagation RTDR/Round, qui est une partie du système de multimédia H.245 de message de contrôle. Ce keps la session TCP H.245 active pendant l'appel qui est utilisé pour la Gestion d'appel actif. Si le point final reçoit une réponse pour RTDR au commencement et aucune réponse n'est reçue pendant l'appel, le point final termine l'appel.

Dans ce scénario, collectez H.323 les logs de débogage et la commande de logins de point final pour isoler la question. H.323 des logs de débogage, vérifiez les messages de demande et de réponse RTDR et découvrez s'il relâche.

Dans cet exemple de sortie, le point final envoie une demande RTDR au point final distant et il ne reçoit pas une réponse 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 dépistées avec des sequenceNumbers.

Cet exemple des logs de point final affiche la cause pour 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 d'appel dû à la panne d'allocation de ressources de medias

Dans le cas des appels vidéos, des appels qui échouent en raison d'une panne d'alocation de ressource en medias sont vus. Par exemple, si appeler et le point final appelé ne prennent en charge pas un codec commun puis un transcodeur est exigé, parce que une non-concordance multi de la fréquence de double tonalité (DTMF) par Media Termination Point (MTP) est exigée sur le gestionnaire d'appel.

Solution

Pour le transcodage visuel, un transcodeur du processeur de signaux numériques du module de Digital de voix par paquets (PVDM3) (DSP) est exigé car les transcodeurs sur le PVDM2 ne prennent en charge pas le vidéo. Si un transcoder/MTP n'est pas disponible, un message indisponible de 503 services serait envoyé au point final :

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 ceci, vérifier la configuration de la liste de groupe de ressources de medias/groupe de ressources de medias (MRG/MRGL) et assurer le vidéo transcoder/MTP est disponible. Un MRGL peut être assigné à un périphérique au niveau de téléphone ou au niveau de Pool d'appareils :

  1. Sur le CallManger choisissez le Device > Phone et sélectionnez le périphérique qui a le problème et vérifiez le Pool d'appareils et les configurations MRGL :

  2. Si la configuration MRGL au téléphone n'en est aucune, alors vous devez vérifier les configurations de Pool d'appareils pour s'assurer qu'il y a un transcodeur.
  3. Choisissez le System > Device Pool et sélectionnez le Pool d'appareils assigné au périphérique :

  4. Choisissez les ressources en medias > la liste de groupe de ressources de medias et sélectionnez le MRGL assigné au niveau de niveau de téléphone/Pool d'appareils et vérifiez le MRGs :

  5. Notez le MRGs et choisissez les ressources en medias > le groupe de ressources de medias et sélectionnez le MRGs remarquable. Assurez que vous faites ajouter PVDM3 un matériel transcoder/MTP.

Problème : Échecs d'appel dus à la bande passante insuffisante

Le plus souvent il y a des scénarios où un appel obtient déconnecté en raison de la configuration insuffisante de bande passante dans la région/emplacement sur le périphérique dans CUCM. Quand la région est placée à une faible bande passante que le point final ne peut pas prendre en charge, le CallManager envoie un support "488 non acceptable » avec la cause 125 qui signifie « hors de la bande passante » ou « de la bande passante insuffisante » après que la négociation de support de SIP se produise.

Vous avez besoin de caputure que le SIP ouvre une session le point final comme décrit et recherchez 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 cette question se produit, vérifiez la région configurée sur les les deux les points finaux et vérifiez les relations de région entre eux :

  1. Choisissez le Device > Phone et sélectionnez les deux périphériques. Vérifiez le Pool d'appareils assigné aux périphériques :

  2. Une fois que vous vérifiez le Pool d'appareils, choisissez le System > Device Pool sur le CUCM et vérifiez la région configurée sur les deux Pools d'appareils :

  3. Choisissez le système > les informations > les régions de région et vérifiez les relations de région. Vérifiez la largeur de bande vidéo sonore sur la région et assurez-vous que le point final peut fonctionner à l'audio/à largeur de bande vidéo comme sélectionnée :

Dans les captures d'écran ci-dessus on le suppose qu'un point final est dans la région « région de joncteur réseau » et l'autre est dans « la région locale de points finaux ».

Un autre contournement est d'essayer l'appel vidéo comme appel sonore si la bande passante pour la bande passante d'appel vidéo est insuffisante. Employez cette procédure afin de vérifier et configurer :

  1. Choisissez le Device > Phone et sélectionnez le périphérique appelant avec le problème. Vérifiez si le paramètre dans ce tir d'écran est vérifié. S'il est décoché, vérifiez-le de sorte qu'un appel vidéo retombe à l'audio en cas de questions de bande passante :

    Cette question a pu se produire en raison des configurations d'emplacement sur le CallManager.

    Des emplacements peuvent être assignés au niveau de téléphone ou au niveau de Pool d'appareils (le niveau de téléphone prend la haute priorité).

  2. Afin de vérifier les configurations de niveau d'emplacement de téléphone, choisir des périphériques > des téléphones et vérifier l'emplacement sur chacun des deux appelant et le point final appelé :

    L'emplacement peut également être appliqué au niveau de Pool d'appareils. Par conséquent, vérifiez d'abord le Pool d'appareils des deux points finaux :

  3. Choisissez le System > Device Pool. Sur le Pool d'appareils, vérifiez l'emplacement assigné sur chacun des deux appeler et les points finaux appelés. Dans cet exemple aucun emplacement n'est assigné au niveau de Pool d'appareils. La configuration d'emplacement de téléphone est utilisée :

  4. Vérifiez si la bande passante suffisante est configurée entre appeler et l'emplacement appelé de points finaux. Dans cet exemple un on assume que le point final est dans l'emplacement local de points finaux et l'autre est dans l'emplacement de Hub_None et la bande passante pour des appels tous d'audio/vidéo et d'immersif sont configurées comme illimitée :

Il a pu y avoir d'autres raisons pour la déconnexion. Voir la page 178 du guide de gestion des dossiers de détail d'appel de Cisco Unified Communications Manager, sortez 10.0(1) pour codes de cause de déconnexion.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 119207