Colaboración : Cisco MediaSense

Audio o información de la llamada perdido de MediaSense

23 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe dos le publica pudo encontrar con Cisco MediaSense y proporciona la información de Troubleshooting sobre ellos. MediaSense es una plataforma de la grabación de la llamada que está atentas y registra todas las comunicaciones dirigidas en él. Si esa información, que puede ser Voz o datos, no se recibe ni se recibe correctamente, puede ser que no aparezca en MediaSense según lo deseada o esperada. Sin embargo, es a menudo una configuración o un problema relacionado con la red.

Contribuido por la pavana Dave, ingeniero de Cisco TAC.

Audio que falta

El primer tipo de llamada es donde no está presente el audio pero se reciben los datos. En estas situaciones, el problema está típicamente con una configuración o el problema relacionado con la red con el Listas de control de acceso (ACL), Cisco unificó el administrador de Communcations (CUCM), o el Cisco Unified Border Element (CUBO).

La mejor manera de verificar este tipo de problema es aseegurarse que los registros del Control de llamadas están habilitados, tira de los registros vía la herramienta del monitoreo en tiempo real de Cisco (RTMT), y tiene el ID de sesión del registro audio que falta de la llamada a buscar.

Después de que usted recoja el Control de llamadas registra, los abre, busca para el ID de sesión, y los verifica que los tamaños bajo el diskusage no son 0. Si los registros muestran el size="0", MediaSense no recibió probablemente el audio y por eso no está allí.

Ejemplo:

En este ejemplo, el ID de sesión es 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

Cuando usted busca, examine las líneas que mencionan el diskusage para la sesión específica ID. En esta área, usted nota que hay tamaños en los atributos de la grabación. Este ejemplo muestra que el size="0", que significa MediaSense no recibieron el audio de CUCM o del CUBO.

Para otros consejos de Troubleshooting en el audio perdido, troubleshooting del error de la grabación de la llamada de la referencia CUCM MediaSense.

Información de la llamada que falta o incorrecta

El segundo tipo de llamada es donde están no presentes o alterados los datos. En estos escenarios, el problema es debido a las configuraciones en el CUBO o el CUCM.

La mejor manera de verificar este tipo de problema es aseegurar que los registros del Control de llamadas están habilitados y acceder ésos vía RTMT. Asegure ese youd para tener el ID de sesión del registro audio que falta de la llamada a buscar.

Busque para un bloque de texto bajo CCBU_CALL_CONTROL-6-BORDER_MESSAGE que contenga toda la información de la llamada que MediaSense reciba, al cual incluye pero no se limita:

  • La ubicación que origina de la llamada
  • Los números de directorio (DN) de la llamada
  • El codificador-decodificador y mucho más información

Si algo aquí no corresponde con lo que debe ser, usted puede ser que necesite analizar el flujo de llamada en CUCM o el CUBO para determinar donde se altera la información.

Estos dos ejemplos muestran estos dos diversos problemas con la falta o la información de la llamada incorrecta.

Ejemplo 1 - Número de teléfono acortado

En este ejemplo, el valor esperado para las demostraciones 19725551234 del ID de sesión 5148fb9543011, pero MediaSense muestra solamente 197255512 en la búsqueda y el juego.

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

En esta situación, note que MediaSense recibió el número 19725551234 con los dos dígitos más recientes está pelado. Puesto que esta información viene de CUCM, ése es el lugar siguiente a mirar para determinar si CUCM también recibe un número acortado de ascendente adicional el flujo de llamada o si éste sucede en CUCM sí mismo.

El troubleshooting adicional determinó que, en este escenario, CUCM causó el problema, que se describe en el Id. de bug 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.

Ejemplo 2 - Ningún número de teléfono

En este ejemplo, el DN está totalmente ausente de un dispositivo llamado 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"
}
],

En este escenario, los registros muestran que no hay información DN enviada a MediaSense, que es muy similar al ejemplo anterior. Para resolver problemas más lejos, usted debe verificar que CUCM recibe la información correctamente, y después marca el CUBO.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118600