Почему в записи FreePBX нет звука и как проверить тракт

Если звонок проходит, а запись пустая, сначала проверьте сам файл и правило записи, затем путь до MixMonitor, а уже после — RTP и NAT. Успешный SIP-вызов не доказывает, что обе стороны слышали друг друга и что аудио попало в запись. Ниже — порядок проверок, который отделяет эти причины.

Что именно означает пустая запись FreePBX

Пустой файл и отсутствие ссылки на запись в CDR — разные неисправности. В первом случае файл найден, но в нём нет полезного аудио или он не завершён. Во втором звонок мог записаться, а интерфейс не связал файл с записью вызова. Проверьте размер, время изменения и возможность открыть файл; затем сопоставьте имя и время с конкретным звонком. Один только статус «Answered» подтверждает ответ на вызов, но не наличие слышимого аудио.

В FreePBX за записью стоит несколько звеньев: настройка записи на маршруте или внутреннем номере, вызов приложения записи в диалплане, аудио на каналах, каталог сохранения и отображение данных в CDR. В базе знаний отдельно подтверждены включение Call Recording для входящих и исходящих маршрутов и стандартный путь хранения /var/spool/asterisk/monitor/. Это полезные ориентиры, а не обещание, что каждый сервер использует ровно их: настройки каталога можно менять, а старые и новые сборки отличаются.

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

Сначала проверьте правило записи и сам файл

Откройте в FreePBX раздел Call Recording и проверьте, какое правило применяется к нужному внутреннему номеру или маршруту. Запись может включаться отдельно для входящих и исходящих вызовов, а режим модуля определяет, как это правило влияет на обработку вызова. Проверьте также, не переопределяет ли правило настройки конкретного номера или маршрута. Названия полей могут различаться между версиями модулей; сверяйтесь с установленным интерфейсом, а не с инструкцией для чужой сборки.

Затем убедитесь, что приложение записи действительно вызывается на нужном участке диалплана. Asterisk документирует MixMonitor как приложение для записи и сведения аудио текущего канала; оно работает как audiohook. Если путь задан относительным, приложение использует каталог мониторинга из конфигурации Asterisk, а абсолютный путь указывает место напрямую. Поэтому одинаковый экран FreePBX не гарантирует одинаковый физический путь на двух серверах. Не делайте вывод по знакомому имени каталога, пока не проверили настройки этой установки.

Посмотрите размер файла после завершения вызова и прослушайте его локально через доверенный аудиоплеер. WAV с заголовком и без звуковых данных может выглядеть как существующая запись, хотя слушать там нечего. В текущем коде CDR-модуля FreePBX записи ищутся в каталоге MIXMON_DIR либо в подкаталоге monitor каталога spool, с датированными подпапками; CDR также отбрасывает отсутствующие или слишком короткие файлы. Это объясняет, почему файл может лежать не прямо в корне monitor и почему ссылка в отчёте не всегда появляется.

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

Как проверить аудио и RTP без выдуманных команд

Подключитесь к консоли Asterisk и включайте только ту отладку, которая отвечает на вопрос. В официальной документации команда core set debug <уровень> управляет уровнем debug; для сбора SIP-трассы PJSIP предусмотрена pjsip set logger on, а RTP отлаживается через rtp set debug on. Команда core set debug 1 не является специальной проверкой RTP, а rtp show не следует выдавать за универсальный просмотр активных медиасессий. Для чтения состояния используйте доступные в вашей версии команды pjsip show channelstats или core show channels и проверяйте их вывод в контексте конкретного вызова.

Отладка RTP может быстро засыпать консоль сообщениями и раскрывать адреса участников звонка в логах. Включите её на короткое время, воспроизведите один тестовый звонок и выключите командой rtp set debug off. Для PJSIP выключите трассировку командой pjsip set logger off. Сравните время вызова и адреса/порты отправителя и получателя в SDP и RTP. Не публикуйте полный дамп: в нём могут быть внутренние адреса и служебные данные. Логи — инструмент диагностики, не украшение постоянной консоли.

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

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

Кодеки и NAT: исправляйте только подтверждённое

Сверьте согласованный кодек в SIP/SDP и состояние каналов Asterisk. G.711 и G.729 — разные кодеки, но их несовпадение в настройках предложения не означает автоматически, что файл станет пустым: если стороны согласовали общий кодек, вызов может работать; если общего кодека нет, проблема проявится при установлении или передаче медиа. Транскодирование зависит от доступных в данной сборке кодеков и модулей. Не ставьте G.711 первым «на всякий случай» и не обещайте, что список должен быть одинаковым у всех сторон.

Утверждение про обязательную лицензию на G.729 в каждой версии Asterisk слишком широкое и здесь не нужно. Проверьте поддержку кодека именно установленной сборкой и лицензионные условия конкретного дистрибутива или модуля. Важный вопрос для пустой записи — что согласовали стороны и что Asterisk реально получает на канале. Проблему нельзя объяснить словом «кодеки», пока нет SDP или состояния канала, которые это подтверждают. Иначе получится дорогое гадание с настройками.

NAT проверяйте, если сервер или телефон находится за преобразованием адресов либо трасса показывает, что SDP объявляет недоступный адрес. Для PJSIP Asterisk документирует отдельные параметры local_net, external_media_address, rtp_symmetric, force_rport и rewrite_contact; их назначение различается. Для старого chan_sip параметр nat=yes встречается в исторической конфигурации, но переносить его в PJSIP нельзя. Нет обязательной настройки nat=yes для любого транка: включайте конкретные параметры только по схеме сети и наблюдаемой проблеме.

Проверьте, что настроенный в Asterisk диапазон RTP совпадает с правилами межсетевого экрана и трансляцией портов на маршрутизаторе. База знаний приводит UDP 10000–20000 как типовой пример; официальное руководство по NAT тоже показывает этот диапазон в примере, а не как незыблемое значение для любой установки. Фактические значения зависят от конфигурации rtp.conf и способа развёртывания. Открывать «весь RTP» без проверки диапазона и источников — плохая привычка; сначала найдите фактические значения на своём сервере.

Проверьте CDR, путь и старые установки

Если файл есть и звучит, а в CDR его нет, это уже задача связи записи вызова с файлом. Проверьте поле recordingfile и путь, который отображает CDR-модуль. Для старых систем в базе знаний есть отдельная оговорка: в FreePBX 2.9 и ниже могло требоваться поле recordingfile в таблице CDR. Не переносите эту инструкцию на современную систему и не меняйте схему базы данных вручную по старой заметке — сначала установите версию и проверьте структуру, которую ожидает ваш модуль.

В официальном исходном коде CDR-модуля FreePBX 17 видно, что имя записи берётся из поля recordingfile, затем модуль строит путь через MIXMON_DIR или ASTSPOOLDIR/monitor с подпапками даты и проверяет существование/читаемость файла. Значит, отсутствие ссылки в отчёте может означать не только «запись не включилась», но и несовпадение пути либо пропажу файла. Сопоставьте строку CDR с реальным именем и каталогом. Это конкретнее, чем вручную добавлять столбцы в базу наугад.

Не удаляйте записи, чтобы «проверить заново», и не воспроизводите звонки на рабочем номере без согласования с теми, кто отвечает за запись разговоров. Сначала сохраните копию затронутого файла и конфигурации, зафиксируйте один проблемный вызов, затем меняйте одну настройку за раз. После каждого изменения сделайте тестовый вызов по тому же маршруту и сравните результат. Так сохраняется возможность откатить неудачную правку и понять, что изменилось.

Порядок восстановления и профилактика

Мой порядок такой: выбрать конкретный пустой файл; проверить размер, воспроизведение и каталог; сверить правило записи для типа вызова; выяснить, вызывается ли MixMonitor; затем посмотреть аудио каналов, RTP и SDP; после этого проверять NAT, кодеки и сетевые правила. Если файл звучит, а отчёт его не показывает, сразу перейти к CDR и пути. Такая развилка экономит время: она не позволяет спутать сбой записи с проблемой отображения или односторонней слышимостью.

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

Плановое обновление Asterisk или FreePBX может исправлять ошибки конкретных версий, но обновление не является универсальным лечением пустого аудио. Перед ним зафиксируйте версии и модули, сделайте проверяемую резервную копию и отдельно проверьте сценарии записи после изменения. Не обновляйте продуктивную телефонию только потому, что файл пустой: сначала выясните, на каком участке исчезает звук. Иначе неисправность останется, а к ней добавится новая переменная.

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

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