Как настроить запись разговоров в Asterisk без мифов

Для записи разговора в Asterisk обычно достаточно MixMonitor: он пишет аудио текущего канала и может сводить звук в файл. Сам по себе MixMonitor не «убивает» диск, а AsyncRecord не является штатным приложением Asterisk. Покажу, что проверить в диалплане, кодеках и хранилище, прежде чем менять оборудование.

Что именно делает MixMonitor

MixMonitor — приложение диалплана Asterisk, которое записывает аудио текущего канала. Документация называет его работу audiohook: приложение подключается к аудио канала и сохраняет поток в указанный файл. Оно не подменяет маршрутизацию звонка, не записывает «весь сервер» и само не отвечает на вызов. Если требуется гарантировать, что файл доступен для дальнейшей обработки внутри диалплана, после записи вызывают StopMixMonitor. Для сопровождения самой телефонии полезен и аудит конфигурации Asterisk: запись стоит проверять вместе с маршрутом вызова, правами и местом хранения.

Базовый синтаксис из документации: MixMonitor(filename.extension,[options,[command]]). Имя файла задаётся явно; относительный путь ведёт в каталог записей, настроенный в Asterisk. Приложение не делает Answer автоматически — перед ним должен быть подходящий шаг диалплана, например Answer или Progress(), если этого требует сценарий вызова. Важна и безопасность: в параметры и команду нельзя без фильтра подставлять недоверенные строки Caller ID. Это уже не вопрос качества звука: неосторожная подстановка может привести к выполнению нежелательной команды.

У MixMonitor есть практичные режимы. Опции r(filename) и t(filename) позволяют сохранять входящее и исходящее аудио отдельно; без них приложение обычно пишет смешанный поток. Это полезно, если при разборе разговора нужно различать стороны или обрабатывать их отдельно. Не называйте раздельную запись новым «асинхронным приложением»: функции надо проверять по документации именно той ветки Asterisk, которая установлена. Названия похожи на обещание, но в телефонии обещание не компилируется.

• MixMonitor пишет аудио текущего канала
• StopMixMonitor освобождает файловый дескриптор
• r() и t() задают отдельные дорожки

AsyncRecord — не штатная замена MixMonitor

В официальном списке приложений Asterisk есть MixMonitor и Record, но нет штатного приложения AsyncRecord. Поэтому конструкция AsyncRecord(${UNIQUEID}.wav) из исходного черновика не является рабочей командой диалплана Asterisk. Record — другое приложение с собственным сценарием записи, включая параметры длительности и тишины; его нельзя объявлять заменой записи обеих сторон звонка без разбора задачи. Если в конкретной сборке или стороннем модуле встречается похожее имя, сначала установите, какой пакет его добавляет и где описан его интерфейс.

Я убрал из сравнения обещания, будто AsyncRecord «копирует RTP-пакеты», автоматически легче для диска, гарантирует целостность или подходит для 90 % задач. На эти тезисы нет опоры в экспертной базе и документации Asterisk. К тому же запись аудио на канале — не равна копированию сетевых RTP-пакетов: кодек, мост и выбранная точка подключения влияют на полученный звук. Для двух отдельных файлов у MixMonitor есть документированные опции r() и t(). Для стороннего решения нужна документация его разработчика и проверка на вашей схеме вызова.

Если требуется единый файл, разные дорожки или последующая обработка, сформулируйте сначала результат: какие стороны должны попасть в запись, с какого момента, в каком формате и когда файл должен стать доступен. Затем сделайте контрольный звонок с реальными направлениями и кодеками. Я отдельно проверяю короткий вызов, перевод, удержание и завершение со стороны каждого участника. Это звучит менее эффектно, чем «переехать на новый метод», зато показывает, где именно пропадает звук или не закрывается файл.

Когда проект использует отдельную систему записи или собственный модуль, это нужно оценивать как отдельный компонент: кто его сопровождает, где лежат аудиофайлы, как контролируется заполнение хранилища и что происходит при рестарте. Само слово «асинхронный» не гарантирует ни меньшую нагрузку, ни меньшую задержку, ни сохранность. Плохой ярлык в конфигурации — не архитектура. В моём разборе я оставляю только штатные функции Asterisk и проверяемые свойства конкретной установки.

• В штатном диалплане используйте документированные приложения
• Для отдельных дорожек проверьте r() и t()
• Сторонний модуль сверяйте с его документацией

Что означает опция b и когда нужен StopMixMonitor

Опция b у MixMonitor означает: сохранять аудио в файл только пока канал находится в мосту с другим каналом. Это не «фоновый режим» и не способ выполнять запись без блокировки. Если добавить b не понимая состояния вызова, можно получить файл без раннего аудио до установления моста — это поведение опции, а не свидетельство поломки диска. Определите, нужны ли приветствие, гудки или только разговор после соединения, и выберите опцию под требуемую запись.

StopMixMonitor останавливает запись и освобождает файловый дескриптор. В документации прямо сказано, что его вызов нужен, чтобы гарантировать доступность аудиофайла для обработки во время выполнения диалплана. Это конкретная причина поместить остановку в корректный участок сценария и проверить все выходы из него: нормальное завершение, отказ, перевод и сброс. Отсутствие StopMixMonitor само по себе не создаёт «зомби-файл», который бесконечно пишет после звонка; исходный текст приписывал приложению такое поведение без подтверждения.

Имена и переменные следует задавать без коллизий. Например, используйте уникальный идентификатор вызова в имени файла, проверьте фактический путь и права процесса Asterisk, а затем убедитесь, что файл можно прочитать после StopMixMonitor. Если постобработку запускает третий параметр MixMonitor, не вставляйте туда непроверенные данные вызывающего абонента. Так защищают и корректность имени, и сам сервер.

Для диагностики я прохожу цепочку целиком: приложение стартовало, ожидаемый канал записывался, диалог вошёл в мост, запись остановилась, файл закрылся и обработчик его увидел. Если аудио нужно сохранять до ответа, опция b может быть неуместна. Если важен только разговор, она ограничивает запись участком соединения. В базе знаний это как раз один из наиболее конкретных пунктов по MixMonitor: b ограничивает сохранение аудио состоянием моста.

• b — писать только при соединении в мосту
• StopMixMonitor — завершить запись и закрыть файл
• Проверьте все ветви выхода из диалплана

Кодеки, нагрузка и история с Asterisk 22.5.0-rc2

В ChangeLog Asterisk 22.5.0-rc2 действительно описана ошибка: MixMonitor мог создавать повреждённые записи в мостовых вызовах с асимметричными кодеками; в примере указаны alaw и G.722. Исправление меняло логику сопоставления кадров в audiohook_read_frame_both(). Это конкретный дефект обработки аудио, а не доказательство того, что MixMonitor в целом ломает диски или что любой звонок с G.711 и Opus вызывает отказ. Перед обновлением сопоставьте точную версию и патчи вашей ветки с ChangeLog и протестируйте типовые вызовы.

Изменение находилось в предварительном ChangeLog версии-кандидата. Поэтому совет «обновитесь до 22.5+» слишком грубый: номер релиза сам по себе не сообщает, какой пакет собран дистрибутивом и какие изменения в него внесены. На момент проверки официальный индекс релизов содержит более поздние обновления ветки 22; выбирайте поддерживаемую сборку с нужным исправлением, учитывая инструкции поставщика и собственный регламент. Не переносите в статью вывод «патч доступен месяцами» как универсальную рекомендацию для всех веток.

Диск нагружают объём записываемого аудио, число одновременных вызовов, формат и кодек, действия постобработки, файловая система и конкурирующие задачи. Но из этих факторов не следует, что MixMonitor запускает отдельный процесс для каждого вызова или что общий каталог приводит к записи всех вызовов в один дескриптор. В исходнике это было выдумано. Измеряйте фактические байты в секунду, задержки записи, заполнение тома и ошибки хранилища под ожидаемой нагрузкой. Именно измерения, а не слово «пиковый», дают основание выбирать носитель.

Для очередей Asterisk база знаний указывает отдельную настройку monitor-type = MixMonitor; документация приложения Queue подтверждает, что тип записи очереди настраивается отдельно от ручного вызова MixMonitor в диалплане. Если записи пропадают только в очереди, проверьте эту настройку и маршрут очереди до экспериментов с SSD. Я также сверяю, какой канал записывает приложение: при переводах участники и каналы меняются, а ожидание «один запуск — вся беседа» часто не совпадает с реальным диалпланом.

• Сверьте версию и применённые изменения по ChangeLog
• Проверьте мост, кодеки и точку запуска записи
• Измерьте I/O и ошибки хранилища при нагрузке

Практический разбор и выбор схемы записи

Разберу условную ситуацию ООО «Берест-Плюс» из исходных данных статьи. В ней записи оказались с дефектом на фоне звонков с разными кодеками, а команда связала это с версией Asterisk и нагрузкой хранилища. Цифры о SMART, сроке в неделю, снижении нагрузки на 40 % и количестве исчезнувших записей документами и измерениями не подтверждены, поэтому я их удалил. Я не буду выдавать красивую метрику за замер. Рабочий план здесь — воспроизвести звонок с теми же кодеками, подтвердить версию Asterisk, проверить ChangeLog и сверить результат записи до и после исправления.

В таком разборе я сначала фиксирую один контрольный сценарий: входящий вызов, ответ, разговор в обе стороны, перевод и завершение. Сохраняю точные сведения о сборке Asterisk, конфигурации записи, кодеках каждого плеча и пути файла. Затем сравниваю звук и журналы на том же тестовом маршруте после установки подтверждённого исправления. Если дефект исчез — есть связь с исправлением; если нет — возвращаюсь к каналу, мосту, файловым правам и дисковым метрикам. Контейнер при этом не магический слой: он не исправляет дефект приложения и не отменяет проверку примонтированного хранилища.

Перед запуском в работу я дополнительно проверяю объём хранения: сколько разговоров записывается, сколько дней их держат, какой средний размер файла и как часто выполняется очистка или перенос. Для нагрузки важны свободное место, пропускная способность и задержки записи, а также резервное копирование. На одном физическом диске нельзя считать запись и резервную копию двумя независимыми копиями. Для соседней темы полезен материал про диски и резервные копии, а если хранилище собрано на ZFS — о размере сектора ashift.

Выбор зависит не от модного названия. Если нужна запись разговора в одном смешанном файле, начните с MixMonitor и проверьте его работу на своих каналах. Если нужны отдельные стороны, изучите r() и t(), согласуйте формат с обработчиками и хранением. Если используется очередь, проверьте monitor-type. Если звук испорчен на асимметричных кодеках, сверяйте ветку Asterisk с описанным исправлением. Для эксплуатации в контейнере проверьте постоянный том, права и поведение после перезапуска; подробнее — в статье про Asterisk в Docker.

• Воспроизведите проблему на контрольном вызове
• Сверьте ветку, патчи, кодеки и файл
• Подбирайте хранилище по измеренной нагрузке

Частые вопросы