Asterisk MixMonitor: запис кожної сторони розмови окремо

MixMonitor — застосунок Asterisk, який записує аудіо каналу у файл. За замовчуванням він зводить обидва напрямки розмови — те, що канал чує, і те, що канал говорить, — в один змішаний моно-файл. Для звичайного запису розмови оператора з клієнтом цього достатньо. Але щойно запис іде далі — на розпізнавання мовлення, аналіз тональності чи QA-скоринг, — змішаний файл починає заважати: уже не зрозуміло, хто що сказав.

У цій статті — як записати кожну сторону розмови Asterisk в окремий файл за допомогою опцій r() і t(), коли краще підходить стерео-опція D і на що звернути увагу.

Базовий виклик

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

Розширення задає аудіоформат (.wav, .gsm, .sln тощо). Відносне ім’я файлу потрапляє в каталог записів Asterisk, за замовчуванням /var/spool/asterisk/monitor.

Перед викликом канал має бути відповіданий (Answer або Progress) — сам MixMonitor цього не робить. Якщо файл потрібен у межах того самого проходу діалплану, наприклад щоб одразу його обробити, запис завершують через StopMixMonitor. Саме це гарантує, що файл повністю записаний і доступний на диску.

Дві опції варто знати ще до розділення:

• a дописує в наявний файл замість перезапису;
• b зберігає аудіо лише поки канал у бріджі, тож дзвінок, що ще лунає, і час в IVR у запис не потрапляють.

Як записати кожну сторону розмови окремо: r() і t()

Дві опції пишуть кожен напрямок аудіо у власний файл, незалежно один від одного:

• r(file) — потік receive: те, що канал чує;
• t(file) — потік transmit: те, що канал говорить.

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

call.wav — як і раніше звичайний змішаний файл, адже аргумент з іменем файлу обов’язковий. Решта два — незалежні потоки, що пишуться одночасно. Це не постобробка одного файлу, а три записи, які ведуться паралельно.

У діалплані AEL це виглядає так:

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

${UNIQUEID} в іменах дає кожному дзвінку власний набір файлів і дозволяє потім легко зіставити їх із рядком CDR.

Коли використано r() або t(), MixMonitor додає в обидва файли тишу, щоб вони лишалися синхронізованими між собою. Опція n вимикає це, коли синхронізація не потрібна.

Один стерео-файл замість двох: опція D

Опція D робить інше: вона вкладає обидва напрямки в один стерео-файл, по одному напрямку на канал (лівий і правий). Вибір зводиться до «два окремі файли» проти «один файл із двома аудіо- каналами».

Більшість сервісів розпізнавання мовлення приймають стерео й трактують кожен канал як окремого мовця, тому D часто найкоротший шлях. Якщо ваш конвеєр чекає один файл на мовця, беріть r() і t().

Чому окремі канали важливі для розпізнавання мовлення й аналітики

Коли оператор і клієнт уже на різних доріжках, сервісу розпізнавання не треба розділяти мовців (діаризація) на змішаному потоці. Кожна доріжка йде в розпізнавання окремо, із гарантованою відповіддю на питання «хто це сказав». Те саме для аналізу тональності чи QA-скорингу: коли вхід уже розділений за ролями, точність не залежить від того, наскільки добре працює стороння діаризація.

Це також дає прості метрики без жодного ШІ: співвідношення часу мовлення, як часто оператор перебиває клієнта і тиша на початку розмови.

Запис у PearlPBX2

PearlPBX2 запускає запис зі свого FastAGI-обробника. Для кожного дзвінка він дивиться на правила запису (примусове вмикання чи вимикання за номером абонента або призначення), виставляє змінну каналу MIXMONITOR у 1 або 0, створює запис у базі та каталог YYYY/MM/DD, а потім виконує MixMonitor для .wav-файлу з опцією a. У результаті на дзвінок виходить один змішаний файл, проіндексований за джерелом, призначенням і uniqueid з CDR, який можна завантажити через GET /api/v1/recordings/<uniqueid>/ з підтримкою HTTP Range. Дзвінки черг записує сам app_queue, який PearlPBX2 налаштовує з monitor-type = MixMonitor.

Тобто з коробки PearlPBX2 канали не розділяє. Якщо потрібні окремі потоки, MixMonitor є в білому списку застосунків редактора AEL, тож його можна викликати з r() і t() у власному діалплані. Майте на увазі: запис, запущений так, лишається на вашій відповідальності, бо запис у базі для запису створює саме FastAGI-обробник.

На що звернути увагу

• Місце на диску. Моно-WAV 8 кГц займає приблизно 1 МБ на хвилину. З r() і t() виходить змішаний файл плюс ще два, тож закладайте приблизно втричі більше. Конвертація готових записів в MP3 це зменшує.
• Спочатку Answer. MixMonitor на невідповіданому каналі нічого корисного не запише.
• Читайте файл лише після StopMixMonitor, якщо використовуєте його в тому самому проході діалплану.
• Згода. Правила запису розмов різняться за країнами. З’ясуйте, що ви зобов’язані сказати абонентові, перш ніж вмикати запис.

Підсумок

Повний список опцій дивіться на сторінці MixMonitor у документації Asterisk.