Para parceiros
Este documento descreve como solucionar problemas do MediaSense quando um erro é exibido na gravação de chamada de uma bridge integrada.
Esta imagem ilustra o fluxo de chamada básico do MediaSense quando uma bridge interna é usada:
Estas etapas descrevem o fluxo de chamada:
Se você receber um erro que indica que não há gravação no MediaSense, você deverá exibir os logs e procurar a ID desta sessão:
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
O size="0" nesta saída indica que não há nenhum áudio gravado no servidor para essa chamada. Isso normalmente significa que o fluxo de RTP não chegou ao servidor MediaSense pelo telefone. Quando isso ocorre, a próxima etapa é verificar se o telefone envia o tráfego de RTP.
Uma maneira rápida de verificar se o telefone IP envia o tráfego RTP é visualizar a página da Web do telefone IP. Isso é ativado manualmente no CUCM na página de configuração do telefone ou pelo Bulk Admin.
O fluxo 1 é a chamada principal com o endereço remoto de outro telefone IP ou gateway. Isso consiste em dois fluxos: o primeiro é o áudio recebido no telefone IP e o segundo é o áudio enviado para a outra extremidade.
Para verificar se o MediaSense grava os dois segmentos da chamada, clique em Stream 2 e Stream 3 para verificar se os Pacotes do remetente aumentam quando a página é atualizada várias vezes. O endereço remoto deve mostrar o servidor MediaSense para o Stream 2 e o Stream 3. A razão pela qual há dois fluxos para o servidor MediaSense é que um deles é o áudio recebido no Stream 1 (Pacotes do Receptor) e o outro é o áudio enviado (Pacotes do Remetente) para a outra extremidade no Stream 1.
Esta captura mostra o Fluxo 1:
Esta captura mostra o Stream 2:
Esta captura mostra o Fluxo 3:
Quando você verifica os dados do Stream 2 e do Stream 3, os principais itens a serem procurados são:
Isso indica que os pacotes RTP são enviados pelo telefone IP.
Se você ainda não tiver certeza se o telefone IP envia os pacotes RTP, o próximo curso de ação é executar uma captura de pacote e reproduzir os fluxos.
Antes de executar as capturas de pacote, certifique-se de que essas configurações na configuração do telefone IP para CUCM estejam ativadas:
Em seguida, aplique a configuração e redefina o telefone IP. Depois que isso for concluído, abra o Wireshark e faça uma captura de pacote com uma duração de 30 segundos. Certifique-se de gravar o endereço remoto, bem como a porta para o Stream 2 e o Stream 3 do telefone IP em questão. Por exemplo:
Quando as capturas de pacote estiverem concluídas, abra a captura de pacote e conclua estas etapas para cada fluxo:
Depois de executar a captura de pacote e verificar se o MediaSense está configurado corretamente e se o telefone IP envia um fluxo RTP válido para o servidor MediaSense e se você continua a encontrar problemas, o caminho entre o servidor e o telefone IP deve ser verificado.
Certifique-se de que o caminho não tenha listas de controle de acesso (ACLs) e que não bloqueie ou filtre o tráfego RTP.
Se a chamada configurada com o CUCM estiver em questão, examine os registros detalhados do CUCM e abra os registros do MediaSense para encontrar a ID da chamada. Isso pode ser encontrado na ID da sessão e é parecido com isso nos registros de controle de chamadas:
CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241
Como o telefone IP configura dois fluxos com o MediaSense, um para cada trecho da chamada original, pesquise nos registros do CUCM com uma das IDs de chamada para verificar se a sessão do MediaSense está configurada corretamente.