Почему MixMonitor оставляет пустой файл и как это проверить

Пустой файл MixMonitor сам по себе не доказывает, что виноваты кодек или RTP. Сначала выясните, запускалась ли запись на нужном канале, куда Asterisk открывает файл и поступало ли аудио. Я покажу порядок проверок, который помогает отделить ошибку диалплана от проблемы каталога и не раскручивать сервер наугад.

Убедитесь, что MixMonitor запускается на нужном канале

Сначала я проверяю сам факт вызова MixMonitor и место, где он стоит в маршруте. Команда записывает аудио текущего канала; она не запускает запись «на всю АТС» по одному лишь желанию администратора. Если нужная ветка диалплана не исполняется, приложение не запустится. Если оно запущено на канале, который не несёт ожидаемое аудио, файл не расскажет, что происходило на другом канале. У записи нет телепатии, даже если от неё этого ждут.

Посмотреть загруженный маршрут можно из командной строки сервера: asterisk -rx "dialplan show имя-контекста". Подставьте реальное имя контекста, затем проследите, проходит ли вызов через строку MixMonitor и не уходит ли раньше в другую ветку. Проверьте также имя файла и используемые переменные. ${UNIQUEID} — переменная канала, но сначала убедитесь, что итоговый путь получается непустым и указывает туда, куда вы рассчитываете. При разборе логики поможет основа диалплана Asterisk. Для настройки телефонии и записи мы также можем провести аудит Asterisk.

Синтаксис приложения в документации выглядит как MixMonitor(filename.extension,[options,[command]]). Первый аргумент — имя и формат файла, остальные аргументы необязательны. Относительный путь разрешается относительно каталога мониторинга, заданного в конфигурации Asterisk; абсолютный путь указывает конкретное место. Поэтому искать файл следует не только в привычном /var/calls: сначала установите, какой путь передан приложению и какой каталог настроен именно на этом сервере. Само наличие файла ещё не подтверждает, что запись получила полезный аудиопоток.

Есть ещё важная тонкость: MixMonitor не отвечает на вызов автоматически. Если логика рассчитывает на ответ внутри этой команды, она ошибочна; состояние вызова задают другие приложения диалплана. Для проверки смотрю журнал конкретного тестового звонка и сверяю канал, контекст, расширение и уникальный идентификатор. Событие MixMonitorStart существует как событие AMI, но это не строка, которую надо искать в обычном CLI. Если AMI не настроен, отсутствие этого события в просмотре CLI ничего не доказывает.

• Найдите вызов MixMonitor в фактической ветке
• Сверьте канал, переменные и итоговый путь
• Проверьте, где начинается и заканчивается запись

Проверьте путь, права процесса и место на диске

Когда запуск подтверждён, выясняю, где Asterisk пытается создать запись. У MixMonitor относительное имя использует настроенный каталог мониторинга, а абсолютное — указанный полный путь. Откройте конфигурацию Asterisk и сопоставьте её с именем из диалплана. Путь может отличаться в пакетной установке, сборке из исходников или готовом решении. Утверждение, что записи по умолчанию обязаны лежать в /var/calls, неверно: в этом каталоге они окажутся лишь при соответствующей настройке или явном пути.

Далее проверяю существование каталога и права пользователя, от которого работает служба. Например, ls -ld /путь/к/каталогу покажет владельца и режим доступа, а df -h /путь/к/каталогу — свободное место на файловой системе. Не применяйте наугад chown или chmod 755: режим 755 может быть как избыточным, так и недостаточным, если запись должна идти в отдельную группу. Правило простое: у рабочего пользователя Asterisk должны быть права пройти по родительским каталогам и создать файл в целевом каталоге.

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

Полный раздел или исчерпанные inode тоже мешают созданию и росту файла. df -h показывает ёмкость, но для inode используйте df -i. Если файловая система заполнена, сначала найдите, что именно заняло место, и проверьте срок хранения записей. Удалять старые разговоры вслепую — плохой способ диагностики: сначала сохраните нужные данные и согласуйте правила хранения. Сам факт почти заполненного диска не доказывает причину конкретного пустого файла; это одна проверка в цепочке, а не универсальный диагноз.

• Сверьте фактический путь с настройкой мониторинга
• Проверьте права пользователя Asterisk на запись
• Проверьте свободное место и inode

Разберитесь, какой звук должен попасть в файл

MixMonitor подключается к текущему каналу как аудионаблюдатель. Поэтому сравниваю, какой канал записывается, когда запускается приложение и что слышно в тестовом разговоре. Запись может быть короткой или без ожидаемой стороны, если вызов рано завершился, нужный канал не был записан или полезный аудиопоток не дошёл до этого участка вызова. Сначала воспроизведите сценарий с двумя тестовыми абонентами и отметьте момент ответа и завершения, а уже потом меняйте параметры медиа.

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

Не отключайте аудио выдуманным толкованием v(0). В официальном описании MixMonitor v(x) меняет уровень принимаемого звука в заданном диапазоне, а V(x) относится к передаваемому звуку; это настройки уровня, а не флаг «не записывать». Если после чужого примера громкость стала странной, проверьте все параметры приложения и временно вернитесь к минимальной конфигурации без необязательных опций. Для понимания реальной проблемы с медиапотоком пригодится материал о кодеках в Asterisk.

Формат файла задаёт расширение и доступность соответствующего драйвера формата. WAV в Asterisk использует форматный модуль format_wav; его не следует путать с кодеком gsm. Модуль codec_gsm занимается кодированием и декодированием GSM, а для файла GSM WAV применяется отдельный драйвер формата. Поэтому команда module load gsm не является общим рецептом для пустой WAV-записи. Если подозреваете отсутствие формата, проверьте фактически установленные и загруженные модули форматирования в своей сборке и сообщение при открытии файла.

• Уточните, какой канал подключён к записи
• Сверьте опции `b`, `a` и регулировки громкости
• Отличайте кодек от драйвера формата файла

Включите диагностику точечно и читайте сообщения

Для начала смотрю журнал Asterisk во время одного контрольного звонка. Файл full в /var/log/asterisk/ часто используют для таких проверок, но наличие и состав канала зависят от настроек logger.conf. Команда asterisk -rx "logger show channels" покажет активные каналы логирования. Если нужных сообщений нет, настройте отдельный канал или временно добавьте подходящие уровни notice, warning, error и debug в соответствии с документацией вашей версии.

Постоянно держать подробный debug на загруженной АТС не нужно: он создаёт дополнительный поток сообщений и может быстро разрастить журналы. Включаю его на короткое окно диагностики, воспроизвожу один сценарий, сохраняю нужные строки и возвращаю обычный уровень. В документации есть CLI-команды core set debug и core set verbose; они управляют уровнями вывода, а не заменяют корректную конфигурацию канала в logger.conf. Уровень и состав журналов — разные настройки, их не стоит смешивать.

Ищите конкретную ошибку открытия файла, путь, название модуля и состояние канала вокруг вызова MixMonitor. Сообщение об отказе доступа ведёт к проверке пути и прав; ошибка формата — к драйверу формата и сборке; отсутствие ожидаемой записи без ошибки требует вернуться к маршруту и аудио текущего канала. Не приписывайте любой нулевой WAV сетевому экрану или NAT: эти компоненты проверяют, когда есть признаки проблемы RTP, а не по одному размеру файла.

Команды SIP-диагностики тоже зависят от используемого драйвера. sip set debug on относится к старому chan_sip, а системы на PJSIP используют другие команды и журналы. Включать SIP-трассировку «на всякий случай» нет смысла, если вопрос касается открытия файла или прохождения диалплана. Сначала выясните драйвер канала, затем включайте только соответствующий отладочный вывод и выключайте его после теста. Иначе журнал станет шумнее, а ответ не приблизится.

• Снимите журнал одного тестового вызова
• Сопоставьте ошибку, канал и путь файла
• Отключите временный debug после проверки

Закройте запись и подтвердите результат тестом

После исправления провожу несколько тестовых звонков по обычным маршрутам, а не один вызов из удобного внутреннего контекста. Проверяю, что файл появляется там, где его ожидает процесс хранения, что размер растёт во время разговора и что обе стороны слышны при воспроизведении. Для быстрой проверки размера подойдёт stat /путь/к/файлу; фиксированный порог вроде «10 КБ означает успех» некорректен без длительности звонка и формата. Две секунды речи и двадцать минут разговора не обязаны давать одинаковый результат.

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

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

Для ООО «Юнона-Строй» я бы зафиксировал результат как небольшой сценарий приёмки: тест с ответом и разговором в обе стороны, проверка имени и каталога файла, воспроизведение готовой записи и повтор после штатного завершения. Условный пример не заменяет аудит конкретной схемы: версии Asterisk, драйвер канала, настройки каталога и диалплан на площадке могут различаться. Если сбой воспроизводится только на очереди или при переводе, проверяйте именно этот маршрут; общий внутренний тест может его не затронуть.

• Проверьте файл после остановки MixMonitor
• Прослушайте обе стороны разговора
• Повторите тест на проблемном маршруте

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