Colaboração : Cisco MediaSense

Áudio ou informação de chamada de falta de MediaSense

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve dois emite-o pôde encontrar com Cisco MediaSense e fornece a informação de Troubleshooting sobre eles. MediaSense é uma plataforma da gravação do atendimento que escute e grave todas as comunicações dirigidas nele. Se essa informação, que pode ser Voz ou dados, não é recebida nem é recebida corretamente, não pôde aparecer em MediaSense como desejada ou esperada. Contudo, é frequentemente uma configuração ou um problema relacionado à rede.

Contribuído pelo Pavan Dave, engenheiro de TAC da Cisco.

Áudio faltante

O primeiro tipo de atendimento é onde o áudio não está atual mas os dados são recebidos. Nestas situações, o problema é tipicamente com uma configuração ou o problema relacionado à rede com Access Control Lists (ACLs), Cisco unificou o gerente de Communcations (CUCM), ou o Cisco Unified Border Element (CUBO).

A melhor maneira de verificar este tipo de edição é certificar-se de que os logs do Controle de chamadas estão permitidos, puxa os logs através da ferramenta do monitoramento em tempo real de Cisco (RTMT), e tem o ID de sessão do log audio faltante do atendimento a procurar.

Depois que você recolhe o Controle de chamadas registra, abre-os, procura-os pelo ID de sessão, e verifica-os que o tamanho sob o diskusage não é 0. Se os logs mostram size="0", MediaSense provavelmente não recebeu o áudio e é por isso não está lá.

Exemplo

Neste exemplo, o ID de sessão é 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

Quando você procura, examine as linhas que mencionam o diskusage para a sessão particular ID. Nesta área, você observa que há um tamanho nos atributos da gravação. Este exemplo mostra que size="0", que significa MediaSense não recebeu o áudio de CUCM ou de CUBO.

Para dicas de Troubleshooting mais adicionais no áudio de falta, Troubleshooting do erro da gravação do atendimento da referência CUCM MediaSense.

Informação de chamada faltante ou incorreta

O segundo tipo de atendimento é onde os dados são não atuais ou alterados. Nestas encenações, o problema é devido às configurações no CUBO ou no CUCM.

A melhor maneira de verificar este tipo de edição é certificar-se de que os logs do Controle de chamadas estão permitidos e alcançar aqueles através do RTMT. Assegure-se de que youd para ter o ID de sessão do log audio faltante do atendimento a procurar.

Procure por um bloco de texto sob CCBU_CALL_CONTROL-6-BORDER_MESSAGE que contém toda a informação de chamada que MediaSense recebe, a que inclui mas não é limitado:

  • O lugar de origem do atendimento
  • Os números de diretório (DN) do atendimento
  • O codec e muito mais informação

Se algo aqui não combina o que se deve ser, você pôde precisar de analisar o fluxo de chamadas em CUCM ou em CUBO a fim determinar onde a informação é alterada.

Estes dois exemplos mostram estas duas edições diferentes com falta ou informação de chamada incorreta.

Exemplo 1 - Número de telefone grampeado

Neste exemplo, o valor esperado para as mostras 19725551234 do ID de sessão 5148fb9543011, mas MediaSense mostra somente 197255512 na busca & no jogo.

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

Nesta situação, observe que MediaSense recebeu o número 19725551234 com os últimos dois dígitos está descascado. Desde que esta informação vem de CUCM, aquele é o lugar seguinte a olhar a fim determinar se CUCM igualmente recebe um número grampeado de um ascendente mais adicional o fluxo de chamadas ou se este acontece em CUCM próprio.

Um Troubleshooting mais adicional determinou que, nesta encenação, CUCM causou a edição, que é descrita na identificação 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.

Exemplo 2 - Nenhum número de telefone

Neste exemplo, o DN é completamente ausente de um dispositivo chamado 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"
}
],

Nesta encenação, os logs mostram que não há nenhuma informação DN enviada a MediaSense, que é muito similar ao exemplo anterior. A fim pesquisar defeitos mais, você deve verificar que CUCM recebe a informação corretamente, e verifica então o CUBO.



Document ID: 118600