Colaboração : Cisco MediaSense

Troubleshooting do erro da gravação do atendimento CUCM MediaSense

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

Introdução

Este documento descreve como pesquisar defeitos MediaSense quando um erro aparece na gravação do atendimento para uma ponte incorporado.

Contribuído pelo Pavan Dave e William Ryan Bennett, engenheiros de TAC da Cisco.

Fluxo de chamadas básico de MediaSense com ponte incorporado

Esta imagem ilustra o fluxo de chamadas básico de MediaSense quando uma ponte incorporado é usada: 

Nota: O telefone IP A tem a gravação permitida.

Estas etapas descrevem o fluxo de chamadas:

  1. O telefone IP à direita chama o telefone IP à esquerda e inicia o atendimento através do gerente das comunicações unificadas de Cisco (CUCM).

  2. O CUCM envia um sinal ao telefone de destino e termina a configuração de chamada.

  3. A conexão entre o telefone IP A e o telefone IP B estabelece-se agora.

  4. O perfil da gravação no telefone IP A diz que assim que receber um atendimento, o CUCM deve estabelecer uma sessão com MediaSense. Isto está terminado milissegundos depois que etapa 3 começa.

  5. O atendimento estabelece-se agora entre os dois telefones, o atendimento bifurca-se através da ponte incorporado, e a ponte incorporado envia dois córregos do Real-Time Transport Protocol (RTP) ao server de MediaSense.

Nenhuma gravação em MediaSense

Se você recebe um erro que indique que não há nenhuma gravação em MediaSense, a seguir você deve ver os logs e procurá-los por este ID de 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 há não um áudio gravado no server para esse atendimento. Isto significa tipicamente que o córrego RTP não obteve ao server de MediaSense do telefone. Quando isto ocorre, a próxima etapa é verificar que o telefone envia o tráfego RTP.

Verifique que o telefone IP envia o tráfego

Uma maneira rápida verificar que o telefone IP envia o tráfego RTP é ver o página da web do telefone IP. Isto é permitido em CUCM manualmente dentro da página da configuração telefônica ou através do volume Admin.

O córrego 1 é o atendimento principal com o endereço remoto do outro telefone IP ou gateway. Isto consiste em dois córregos: o primeiro é o áudio que é recebido no telefone IP e o segundo é o áudio que é enviado à outra extremidade.

A fim verificar que MediaSense grava ambos os trechos de chamada, clique sobre o córrego 2 e o córrego 3 a fim verificar que os pacotes do remetente incrementam quando a página é refrescada épocas múltiplas. O endereço remoto deve mostrar o server de MediaSense para o córrego 2 e o córrego 3. A razão que há dois córregos ao server de MediaSense é porque um deles é o áudio recebido no córrego 1 (pacotes do receptor) e o outro é o áudio enviado (pacotes do remetente) à outra extremidade no córrego 1.

Nota: Na referência ao diagrama de fluxo de chamadas que é descrito previamente, etapa 3 é o córrego 1, e cada pé da etapa 5 consulta para fluir 2 e córrego 3.

Esta captação mostra o córrego 1:

Esta captação mostra o córrego 2:

Nota: É importante observar o endereço IP de Um ou Mais Servidores Cisco ICM NT e a porta na seção de endereço remoto da página. Isto é muito importante quando você toma capturas de pacote de informação para atendimentos de telefone de teste.

Esta captação mostra o córrego 3:

Quando você verifica os dados para o córrego 2 e o córrego 3, as coisas chaves a procurar são:

  • O endereço remoto é o endereço IP de Um ou Mais Servidores Cisco ICM NT do server de MediaSense.

  • O número de porta em cada córrego é original.

  • Quando você refresca a página, o número de pacotes do remetente aumenta.

Isto indica que os pacotes RTP estão enviados pelo telefone IP.

Execute capturas de pacote de informação

Se você é ainda incerto se o telefone IP envia os pacotes RTP, o curso de ação seguinte é executar uma captura de pacote de informação e uma repetição os córregos.

Antes que você execute as capturas de pacote de informação, assegure-se de que estes ajustes na configuração de telefone IP para CUCM estejam permitidos:

  • Período à porta de PC
  • Acesso de vlan da Voz PC
  • Porta de PC

Então, aplique a configuração e restaure o telefone IP. Depois que isto está completo, Wireshark aberto e toma uma captura de pacote de informação com uma duração 30-second. Assegure-se de que você grave o endereço remoto assim como a porta para o córrego 2 e o córrego 3 do telefone IP na pergunta. Por exemplo:

  • Córrego 2 - 10.201.227.147/40676
  • Córrego 3 - 10.201.227.147/33358

Uma vez que as capturas de pacote de informação estão completas, abra a captura de pacote de informação e termine estas etapas para cada córrego:

  1. Filtre pelo == 40676 do && udp.port de 10.201.227.147 do == ip.addr.

  2. Navegue para analisar > descodificam como.

  3. Na janela pop-up, selecione o RTP uma APROVAÇÃO do clique.

  4. Navegue à telefonia > ao RTP > à análise do córrego.

  5. Na análise do córrego RTP, navegue ao jogador > descodificam > jogo, e verificam que ambos os pés do atendimento estão ouvidos.

  6. Repita etapas 1 a 4 para o outro córrego e porta.

Troubleshooting

Depois que você executa a captura de pacote de informação e o verifica que MediaSense está configurado corretamente e que o telefone IP envia um córrego válido RTP ao server de MediaSense, e continua a encontrar edições, a seguir o trajeto entre o server e o telefone IP deve ser verificado.

Assegure-se de que o trajeto não tenha nenhum Access Control Lists (ACLs) e que não obstrui nem filtra o tráfego RTP.

Notas importantes

Se o atendimento que se estabelece com CUCM está na pergunta, a seguir o olhar no CUCM detalhado registra, e abre o MediaSense entra a ordem para encontrar a identidade da chamada. Isto pode ser encontrado do ID de sessão, e olha similar a este nos logs do Controle de chamadas:

CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241

Desde os grupos de telefone IP - acima de dois córregos com MediaSense, um para cada pé da chamada telefônica original, procura os logs CUCM com uma das identidades da chamada a fim verificar se a sessão de MediaSense se estabelece corretamente.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 117788