Colaboración : Cisco MediaSense

Troubleshooting del error de la grabación de la llamada CUCM MediaSense

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

Introducción

Este documento describe cómo resolver problemas MediaSense cuando un error aparece en la grabación de la llamada para un Bridge incorporado.

Contribuido por la pavana Dave y Guillermo Ryan Bennett, ingenieros de Cisco TAC.

Flujo de llamada básico de MediaSense con el Bridge incorporado

Esta imagen ilustra el flujo de llamada básico de MediaSense cuando se utiliza un Bridge incorporado: 

Nota: El teléfono del IP A tiene grabación habilitada.

Estos pasos describen el flujo de llamada:

  1. El teléfono del IP a la derecha llama el teléfono del IP a la izquierda e inicia la llamada vía el administrador de las Comunicaciones unificadas de Cisco (CUCM).

  2. El CUCM envía una señal al teléfono de destino y completa la configuración de la llamada.

  3. La conexión entre el teléfono del IP A y el teléfono del IP B ahora se configura.

  4. El perfil de la grabación en el teléfono del IP A dice que tan pronto como reciba una llamada, el CUCM debe configurar una sesión con MediaSense. Esto se completa los milisegundos después de que el paso 3 comience.

  5. La llamada ahora se configura entre los dos teléfonos, la llamada bifurca vía el Bridge incorporado, y el Bridge incorporado envía dos secuencias del Real-Time Transport Protocol (RTP) al servidor de MediaSense.

Ninguna grabación en MediaSense

Si usted recibe un error que indique que no hay grabación en MediaSense, después usted debe ver los registros y buscar para este ID de sesión:

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

El size="0" en esta salida indica que hay no audio registrado en el servidor para esa llamada. Esto significa típicamente que la secuencia RTP no consiguió al servidor de MediaSense del teléfono. Cuando ocurre esto, el siguiente paso es verificar que el teléfono envía el tráfico RTP.

Verifique el teléfono del IP envía el tráfico

Un modo rápido de verificar que el teléfono del IP envíe el tráfico RTP es ver la página web del teléfono del IP. Esto se habilita en CUCM manualmente dentro de la página de la Configuración del teléfono o vía el bulto Admin.

La secuencia 1 es la llamada principal con la dirección remota del otro teléfono del IP o gateway. Esto consiste en dos secuencias: el primer es el audio que se recibe en el teléfono del IP y el segundo es el audio que se envía al otro extremo.

Para verificar que MediaSense registre ambos tramos de llamada, haga clic en la secuencia 2 y la secuencia 3 para verificar que los paquetes del remitente incrementan cuando la página se restaura las épocas múltiples. La dirección remota debe mostrar el servidor de MediaSense para la secuencia 2 y la secuencia 3. La razón que hay dos secuencias al servidor de MediaSense es porque una de ellas es el audio recibido en la secuencia 1 (paquetes del receptor) y el otro es el audio enviado (los paquetes del remitente) al otro extremo en la secuencia 1.

Nota: En referencia al diagrama de flujo de llamadas que se describe previamente, el paso 3 es la secuencia 1, y cada pierna del paso 5 refiere a la secuencia 2 y a la secuencia 3.

Esta captura muestra la secuencia 1:

Esta captura muestra la secuencia 2:

Nota: Es importante notar la dirección IP y el puerto en la sección de dirección remota de la página. Esto es muy importante cuando usted toma a las capturas de paquetes para las llamadas de teléfono de prueba.

Esta captura muestra la secuencia 3:

Cuando usted verifica los datos para la secuencia 2 y la secuencia 3, las cosas dominantes a buscar son:

  • La dirección remota es la dirección IP del servidor de MediaSense.

  • El número del puerto en cada secuencia es único.

  • Cuando usted restaura la página, el número de paquetes del remitente aumenta.

Esto indica que los paquetes RTP son enviados por el teléfono del IP.

Realice a las capturas de paquetes

Si usted es todavía inseguro si el teléfono del IP envía los paquetes RTP, la línea de acción siguiente es realizar a una captura de paquetes y jugar de nuevo las secuencias.

Antes de que usted realice a las capturas de paquetes, asegúrese de que estas configuraciones en Configuración del teléfono IP para CUCM estén habilitadas:

  • Palmo al puerto de PC
  • Acceso de VLAN de la Voz PC
  • Puerto de PC

Entonces, aplique la configuración y reajuste el teléfono del IP. Después de que esto sea completo, Wireshark abierto y toma a una captura de paquetes con una duración 30-second. Asegúrese de que usted registre la dirección remota así como el puerto para la secuencia 2 y la secuencia 3 del teléfono del IP en la pregunta. Por ejemplo:

  • Secuencia 2 - 10.201.227.147/40676
  • Secuencia 3 - 10.201.227.147/33358

Una vez que las capturas de paquetes son completas, abra a la captura de paquetes y complete estos pasos para cada secuencia:

  1. Filtre por el == 40676 del && udp.port de 10.201.227.147 del == ip.addr.

  2. Navegue para analizar > decodifican como.

  3. En la ventana emergente, seleccione el RTP una AUTORIZACIÓN del tecleo.

  4. Navegue a la telefonía > al RTP > al análisis de la secuencia.

  5. En el análisis de la secuencia RTP, navegue al jugador > decodifican > juego, y verifican que ambas piernas de la llamada están oídas.

  6. Relance los pasos 1 a 4 para la otra secuencia y vire hacia el lado de babor.

Troubleshooting

Después de que usted realice a la captura de paquetes y le verifique que MediaSense está configurado correctamente y que el teléfono del IP envía una secuencia válida RTP al servidor de MediaSense, y continúe encontrando los problemas, después la trayectoria entre el servidor y el teléfono del IP debe ser marcada.

Asegúrese de que la trayectoria no tenga ningún Listas de control de acceso (ACL) y de que no bloquea ni filtra el tráfico RTP.

Notas importantes

Si la llamada que se configura con CUCM está en la pregunta, después la mirada en el CUCM detallado registra, y abre al MediaSense abre una sesión la orden para encontrar el ID de llamada. Esto se puede encontrar del ID de sesión, y parece similar a esto en los registros del Control de llamadas:

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

Puesto que el teléfono del IP configura dos secuencias con MediaSense, uno para cada pierna de las llamadas telefónicas originales, busca los registros CUCM con uno de los ID de llamadas para verificar si la sesión de MediaSense está configurada correctamente.


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: 117788