Asterisk MixMonitor: graba cada lado de la llamada

MixMonitor es el aplicativo de Asterisk que graba el audio de un canal en un archivo. Por defecto mezcla ambas direcciones de la llamada — lo que el canal escucha y lo que dice — en un único archivo mono. Eso basta para una grabación simple de un operador hablando con un cliente. Pero en cuanto la grabación pasa a reconocimiento de voz, análisis de tono o QA scoring, un archivo mezclado estorba: ya no se sabe quién dijo qué.

Este artículo explica cómo grabar cada lado de una llamada de Asterisk en su propio archivo con las opciones r() y t(), cuándo conviene más la opción estéreo D y a qué hay que prestar atención.

Llamada básica

MixMonitor(filename.extension,[options,[command]])

La extensión define el formato de audio (.wav, .gsm, .sln, etc.). Un nombre de archivo relativo acaba en el directorio de grabaciones de Asterisk, por defecto /var/spool/asterisk/monitor.

El canal debe estar contestado (Answer o Progress) antes de ejecutar MixMonitor, que no lo hace por sí mismo. Si necesitas el archivo dentro de la misma ejecución del plan de marcado, por ejemplo para procesarlo de inmediato, cierra la grabación con StopMixMonitor. Eso garantiza que el archivo esté completamente escrito y disponible en disco.

Conviene conocer dos opciones antes de dividir:

• a añade al archivo existente en lugar de sobrescribirlo;
• b guarda el audio solo mientras el canal está en puente, así que el tono de llamada y el tiempo en el IVR quedan fuera de la grabación.

Cómo grabar cada lado de la llamada por separado: r() y t()

Dos opciones escriben cada dirección del audio en su propio archivo, de forma independiente:

• r(file) — el flujo receive: lo que el canal escucha;
• t(file) — el flujo transmit: lo que el canal dice.

MixMonitor(call.wav,r(call-in.wav)t(call-out.wav))

call.wav sigue siendo el archivo mezclado de siempre, porque el argumento del nombre de archivo es obligatorio. Los otros dos son flujos independientes que se escriben al mismo tiempo. No es posprocesamiento de un solo archivo, sino tres grabaciones hechas en paralelo.

En un plan de marcado AEL se ve así:

context incoming {
  s => {
    Answer();
    MixMonitor(${UNIQUEID}.wav,r(${UNIQUEID}-in.wav)t(${UNIQUEID}-out.wav));
    Dial(PJSIP/operator);
    StopMixMonitor();
  }
}

Usar ${UNIQUEID} en los nombres da a cada llamada su propio juego de archivos y facilita relacionarlos después con una fila del CDR.

Cuando se usa r() o t(), MixMonitor inserta silencio en ambos archivos para mantenerlos sincronizados entre sí. La opción n lo desactiva cuando no hace falta sincronizar.

Un solo archivo estéreo: la opción D

La opción D hace algo distinto: entrelaza ambas direcciones en un único archivo estéreo, una dirección por canal (izquierdo y derecho). La elección es entre «dos archivos separados» y «un archivo con dos canales de audio».

La mayoría de los servicios de reconocimiento de voz aceptan estéreo y tratan cada canal como un hablante distinto, así que D suele ser el camino más corto. Si tu pipeline espera un archivo por hablante, usa r() y t().

Por qué importan los canales separados en reconocimiento de voz y analítica

Cuando operador y cliente ya están en pistas distintas, el servicio de reconocimiento no tiene que separar a los hablantes (diarización) en un flujo mezclado. Cada pista entra al reconocimiento por sí sola, con una respuesta garantizada a «quién dijo esto». Lo mismo vale para el análisis de tono o el QA scoring: cuando la entrada ya viene dividida por rol, la precisión no depende de lo bien que funcione una diarización de terceros.

También permite métricas simples sin IA: proporción de tiempo de habla, cuántas veces el operador interrumpe al cliente y el silencio al inicio de la llamada.

Grabación en PearlPBX2

PearlPBX2 inicia las grabaciones desde su manejador FastAGI. Para cada llamada revisa las reglas de grabación (forzar activación o desactivación por número de origen o destino), fija la variable de canal MIXMONITOR en 1 o 0, crea el registro en la base de datos y el directorio YYYY/MM/DD, y luego ejecuta MixMonitor sobre un archivo .wav con la opción a. El resultado es un archivo mezclado por llamada, indexado por origen, destino y uniqueid del CDR, y descargable con GET /api/v1/recordings/<uniqueid>/ con soporte de HTTP Range. Las llamadas de cola las graba el propio app_queue, que PearlPBX2 configura con monitor-type = MixMonitor.

Es decir, de fábrica PearlPBX2 no divide los canales. Si quieres flujos separados, MixMonitor está en la lista blanca de aplicaciones del editor AEL, así que puedes llamarlo con r() y t() desde tu propio plan de marcado. Ten en cuenta que una grabación iniciada así queda bajo tu responsabilidad: el registro en la base de datos lo crea el manejador FastAGI.

Qué vigilar

• Espacio en disco. Un WAV mono de 8 kHz ocupa aproximadamente 1 MB por minuto. Con r() y t() obtienes el archivo mezclado más dos, así que calcula unas tres veces más. Convertir las grabaciones terminadas a MP3 lo reduce.
• Primero Answer. MixMonitor sobre un canal sin contestar no graba nada útil.
• Lee el archivo solo después de StopMixMonitor si lo usas en la misma ejecución del plan de marcado.
• Consentimiento. Las reglas de grabación varían según el país. Averigua qué debes decir al llamante antes de activar la grabación.

Resumen

Para la lista completa de opciones, consulta la página de MixMonitor en la documentación de Asterisk.