Collaboration : Cisco MediaSense

Audio ou informations d'appel manquant de MediaSense

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit deux vous émet pourrait rencontrer avec le Cisco MediaSense et fournit l'information de dépannage au sujet de eux. MediaSense est une plate-forme d'enregistrement d'appels qui écoute et enregistre toutes les transmissions dirigées à lui. Si ces informations, qui peuvent être Voix ou données, ne sont pas reçues ou sont reçues correctement, elles ne pourraient pas apparaître dans MediaSense comme désirées ou prévues. Cependant, c'est souvent une configuration ou une question liée au réseau.

Contribué par Pavan Dave, ingénieur TAC Cisco.

Audio manquant

Le premier type d'appel est où l'audio n'est pas présent mais les données sont reçues. Dans ces situations, le problème est typiquement avec une configuration ou une question liée au réseau avec le Listes de contrôle d'accès (ACL), le gestionnaire de Cisco Unified Communcations (CUCM), ou le Logiciel Cisco Unified Border Element (CUBE).

La meilleure manière de vérifier ce type de question est de s'assurer que les logs de Contrôle d'appel sont activés, tirent les logs par l'intermédiaire de l'outil de suivi en temps réel de Cisco (RTMT), et ont l'ID de session du journal d'appels sonore manquant au rechercher.

Après que vous collectiez le Contrôle d'appel se connecte, les ouvre, recherche l'ID de session, et le vérifie que la taille sous le diskusage n'est pas 0. Si les logs affichent size="0", MediaSense n'a pas reçu probablement l'audio et c'est pourquoi il n'est pas là.

Exemple

Dans cet exemple, l'ID de session est 78e146437088a93.

0000049583: 10.201.227.136: May 28 2014 11:27:09.022 -0400: %CCBU_COMMON-6-VSMS
HTTP Info: {Thrd=Pool-capture-thread-2800} %[HTTP Response Body=<Session>
<diskusage>
<recording name="78e146437088a93-TRACK0" size="0" repository="/
recordedMedia" />
<recording name="78e146437088a93-TRACK1" size="0"repository="/
recordedMedia" />
</diskusage>
</Session>][HTTP Response Content Type=application/xml][HTTP Response Status
Code=200][logId=close-25668]: VSMS Received HTTP Response

Quand vous recherchez, examinez les lignes qui mentionnent le diskusage pour l'ID de session particulier. Dans cette zone, vous notez qu'il y a une taille dans les attributs d'enregistrement. Cet exemple prouve que size="0", qui signifie MediaSense n'a pas reçu l'audio de CUCM ou de CUBE.

Pour d'autres conseils de dépannage sur l'audio manquant, dépannage des erreurs d'enregistrement d'appels de la référence CUCM MediaSense.

Les informations d'appel manquantes ou incorrectes

Le deuxième type d'appel est où les données sont non présentes ou modifiées. Dans ces scénarios, le problème est dû aux configurations sur le CUBE ou le CUCM.

La meilleure manière de vérifier ce type de question est de s'assurer que les logs de Contrôle d'appel sont activés et d'accéder à ceux par l'intermédiaire du RTMT. Assurez ce youd pour avoir l'ID de session du journal d'appels sonore manquant au rechercher.

Recherchez un bloc de texte sous CCBU_CALL_CONTROL-6-BORDER_MESSAGE qui contient toutes les informations d'appel que MediaSense reçoit, au lequel inclut mais n'est pas limité :

  • L'emplacement d'origine de l'appel
  • Les nombres de répertoire (dn) de l'appel
  • Les codecs et beaucoup plus d'informations

Si quelque chose ici n'apparie pas ce qu'être il devrait, vous pourriez devoir analyser l'écoulement d'appel à CUCM ou à CUBE afin de déterminer où les informations sont modifiées.

Ces deux exemples affichent ces deux questions différentes avec des disparus ou des informations d'appel incorrectes.

Exemple 1 - Numéro de téléphone coupé

Dans cet exemple, la valeur prévue pour les expositions 19725551234 de l'ID de session 5148fb9543011, mais MediaSense affiche seulement 197255512 sur la recherche et le jeu.

0000030499: 10.201.227.36: Oct 10 2014 15:42:16.512 -0400: %CCBU_CALL_CONTROL-6-
BORDER_MESSAGE: {Thrd=Pool-ams-thread-9} %[message_string=HttpPostClient-9:
executing POST http://10.201.227.36:8640/ora/SipAdaptorService/SipAdaptor/
addOrUpdateSession HTTP/1.1
{"sessionData": {
"callControllerIP": "10.201.227.33",
"callControllerType": "Cisco-CUCM",
"endPoints": [
{
"clusterid": "StandAloneCluster",
"conference": false,
"device": "SEP123456ABCDEF",
"displayName": "Agent 2102",
"dn": "2102",
"startDate": 1412970136508,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1412970136508,
"track": 0,
"type": "AUDIO"
}],
"type": "NEAR_END",
"xRefci": "37328298"
},
{
"clusterid": "StandAloneCluster",
"conference": false,
"device": "S0/SU1/DS1-1@PAVAN-2811",
"dn": "197255512",
"startDate": 1412970136508,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1412970136508,
"track": 1,
"type": "AUDIO"
}],
"type": "FAR_END",
"xRefci": "37328299"
}
],
"operationType": "ADD",
"recordingServer": "10.201.227.36",
"rtspUrl": "rtsp://10.201.227.36/5148fb9543011",
"sessionName": "5148fb9543011",
"sipServer": "10.201.227.36",
"startDate": 1412970136508,
"state": "ACTIVE",
"version": 7

Dans cette situation, notez que MediaSense a reçu le numéro 19725551234 avec les deux derniers chiffres sont décollés. Puisque ces informations proviennent CUCM, c'est le prochain endroit à regarder afin de déterminer si CUCM reçoit également un nombre coupé davantage de d'haut l'écoulement d'appel ou si ceci se produit sur CUCM lui-même.

Davantage de dépannage a déterminé que, dans ce scénario, CUCM a entraîné la question, qui est décrite dans l'ID de bogue Cisco CSCuq20108 :

If the From header sent to a recording server exceeds 231 characters, the header
will get truncated if escaped characters are found. if the From header contains
escaped characters "@", (i.e. %40), the dynamic buffer allocation doesn't account
for this resulting in characters getting truncated.

Exemple 2 - Aucun numéro de téléphone

Dans cet exemple, le DN est complètement absent d'un périphérique appelé le SIP_TRUNK_CVP.

0014107576: 10.201.227.136: Sep 02 2014 16:50:30.484 -0500: %CCBU_CALL_CONTROL-6-
BORDER_MESSAGE: {Thrd=Pool-ams-thread-222081} %[message_string=HttpPostClient-222082:
executing POST http://10.201.227.136:8640/ora/SipAdaptorService/SipAdaptor/
addOrUpdateSession HTTP/1.1
{"sessionData": {
"callControllerIP": "10.201.227.133",
"callControllerType": "Cisco-CUCM",
"endPoints": [
{
"conference": false,
"device": "SEP12356ABCDEF",
"displayName": "Agent 3102",
"dn": "3102",
"startDate": 1409694630483,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1409694630483,
"track": 0,
"type": "AUDIO"
}],
"type": "NEAR_END",
"xRefci": "65826764"
},
{
"conference": false,
"device": "SIP_TRUNK_CVP",
"dn": "",
"startDate": 1409694630483,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1409694630483,
"track": 1,
"type": "AUDIO"
}],
"type": "FAR_END",
"xRefci": "65826763"
}
],

Dans ce scénario, les logs prouvent qu'il n'y a aucune informations de DN envoyée à MediaSense, qui est très semblable à l'exemple précédent. Afin de dépanner plus loin, vous devriez vérifier que CUCM reçoit les informations correctement, et puis vérifiez le CUBE.



Document ID: 118600