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

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

С чего начать, если FreePBX перестала проводить звонки

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

В условном разборе со студией «Шафран-Плюс» я бы не объявлял причиной ни память, ни NAT до проверки. У нас есть три направления: состояние процесса и ресурсов, регистрация и маршрутизация вызова, передача медиапотока RTP. Сначала сохраняю текущие журналы и конфигурацию, затем воспроизвожу проблему одним контрольным звонком. Перезапуск может временно вернуть сервис, но одновременно стирает часть признаков, по которым видно, что именно остановилось.

Проверяю, отвечает ли CLI Asterisk, что происходит с конкретным endpoint и появляется ли попытка вызова в логе. Для PJSIP полезны pjsip show endpoints и, на короткое время диагностики, pjsip set logger on; включённый протокольный журнал потом нужно выключить, чтобы не собирать лишние данные. В FreePBX модули управляют Asterisk, но обновление интерфейса не означает автоматическое обновление самого Asterisk. Это разные слои, и смотреть нужно на оба.

• Запишите время и направление контрольного вызова.
• Сохраните журналы до перезапуска.
• Отделите сигнализацию SIP от медиапотока RTP.

Память растёт: как проверить модули без гадания

Рост RSS у процесса Asterisk сам по себе ещё не доказывает утечку. Память может удерживаться аллокатором, расти из-за числа одновременных вызовов или быть следствием дефекта конкретного модуля. Сравниваю показатели в спокойном режиме и под повторяемой нагрузкой, отмечаю число активных каналов, время и установленную сборку. Если рост повторяется при одинаковом сценарии, собираю журналы и сведения о модулях, а не снимаю диагноз по одному снимку top.

В исходном тексте запись разговоров была объявлена виновником и системе приписывался точный срок до зависания. Подтверждения этому нет. Запись создаёт файлы и нагрузку на диск, поэтому проверяю свободное место, права и фактическое поведение конкретного вызова, но не называю её утечкой без воспроизводимого дефекта. Чтобы локализовать проблему, сравниваю результат с отключённой функцией только в согласованное окно и после резервной копии. Иначе эксперимент сам станет аварией.

Список активных компонентов и их версии снимаю штатными средствами FreePBX, затем сверяю доступные обновления и зависимости. Неизвестный модуль нельзя удалять наугад: он может отвечать за маршрутизацию, IVR или интеграцию. Отключение допустимо, если понятно, какую функцию оно затронет и есть план возврата. В базе знаний отмечена практическая проблема несогласованного обновления модулей; это хороший повод менять их комплектом и фиксировать исходное состояние, но не доказательство, что любой старый модуль обязательно течёт.

Документация Asterisk для расследования утечек просит приложить сведения об окружении, версии, сторонних модулях, сценарии вызова и журналы; для глубокой диагностики используется специальная сборка с MALLOC_DEBUG. Это работа для воспроизводимого теста и поддержки, а не команда, которую стоит запускать на боевой АТС без плана. На рабочей системе я сначала сохраняю журналы и описываю нагрузку. Только потом выбираю диагностический уровень, чтобы не добавить системе лишней нагрузки.

• Сравните память в простое и при одинаковых вызовах.
• Сверьте версии модулей и Asterisk.
• Проверьте диск, если включена запись.
• Перед экспериментом создайте и проверьте резервную копию.

NAT и RTP: почему звонок есть, а голоса нет

Если телефон звонит, но одна сторона не слышит другую, проверяю медиапоток отдельно от SIP-сигнализации. RTP может идти напрямую между абонентами или через Asterisk — в зависимости от конфигурации. Поэтому универсального совета «откройте всё» нет. Сверяю адреса в SDP, таблицу NAT, правила межсетевого экрана и фактический диапазон RTP, заданный в этой установке. Диапазон зависит от конфигурации; цифры из чужого примера нельзя без проверки переносить в firewall.

Практическую настройку PJSIP разбираю в материале о настройке PJSIP в Asterisk. Для PJSIP за NAT документация Asterisk описывает параметры local_net, external_media_address и external_signaling_address в секции транспорта, а также direct_media у endpoint. Они влияют на то, какие адреса Asterisk сообщает собеседнику и где ожидает медиатрафик. Это не означает, что нужно вручную править сгенерированные FreePBX файлы pjsip.conf: интерфейс может перезаписать изменения. Сначала проверяю настройки через поддерживаемый интерфейс FreePBX, затем убеждаюсь, что сгенерированная конфигурация отражает нужные значения.

В примере со «Шафран-Плюс» нельзя утверждать, будто RTP сначала шёл на внешний адрес, а возвращался на внутренний: для этого нужны захват трафика и содержимое SDP. Такая картина возможна при несогласованных адресах, но сама по себе жалоба на тишину её не доказывает. Я проверяю один вызов с обеих сторон, сверяю направление RTP и убеждаюсь, что маршрутизатор передаёт только нужный диапазон на АТС. Для удалённых телефонов также учитываю отдельные сети и NAT на стороне абонента.

Параметр SRV Lookup не является лекарством от любого неудачного звонка. DNS SRV может участвовать в поиске SIP-сервера, если это предусмотрено доменом и способом подключения провайдера; он не чинит неверный адрес в SDP и заблокированный RTP. Сначала проверяю регистрацию транка и его требования, затем DNS-ответ и маршрутизацию. Иначе получится типичная настройка «включили галочку — стало спокойнее», хотя звонок по-прежнему без звука.

• Сопоставьте SIP-сигнализацию и RTP в одном тестовом вызове.
• Проверьте адреса в SDP и NAT-правила.
• Открывайте только настроенный RTP-диапазон.

Версии PHP, Asterisk и FreePBX: где искать несовместимость

У FreePBX нет единственной вечной комбинации PHP, Asterisk и системных пакетов. Поддерживаемые версии зависят от ветки FreePBX и способа установки. Например, официальный сценарий установки FreePBX 17 рассчитан на Debian 12 и задаёт PHP 8.2; превращать этот частный пример в требование для всех старых систем тоже нельзя. Поэтому сначала выясняю точную версию FreePBX, Asterisk, ОС и способ установки, затем сверяю их с документацией конкретной ветки.

Список apache-base, apache-mod_php и прочих пакетов из исходной статьи не подтверждён как универсальный: названия зависят от дистрибутива, а официальный сценарий FreePBX 17 использует apache2 и набор зависимостей для выбранной платформы. Нельзя чинить продакшен установкой случайных пакетов из чужого руководства. Сверяю установленные пакеты со сценарием или образом, на котором развёрнута именно эта АТС, и проверяю журнал обновления при первом появлении ошибки.

Совет поставить PHP 5.6, потому что «FreePBX не совместим с PHP 7», устарел и относится к старой комбинации версий. Современный официальный установщик FreePBX 17 использует PHP 8.2. Это не значит, что любую старую FreePBX можно просто переключить на PHP 8.2: сначала требуется проверить требования её ветки и наличие миграционного пути. Обновление PHP в отрыве от приложения — отличный способ получить новую проблему вместо старой.

Перед изменениями экспортирую конфигурацию и резервную копию через Backup & Restore, проверяю, что архив доступен вне самого сервера, и фиксирую список версий. Sangoma рекомендует этот модуль как путь миграции к FreePBX 17, а не обновление наугад поверх старой установки. Пакеты, модули FreePBX и сам Asterisk обновляю по поддерживаемой процедуре для конкретной системы. После изменений проверяю внутренний вызов, входящий и исходящий маршруты и голос в обе стороны.

• Зафиксируйте версии ОС, FreePBX, PHP и Asterisk.
• Сверьте требования именно вашей ветки.
• Сделайте резервную копию до обновления.
• После обновления проверьте три направления звонка.

Порядок восстановления: журналы, проверка, затем перезапуск

Когда связь уже нарушена, фиксирую масштаб: не проходят все вызовы или только один маршрут; затронуты все телефоны или конкретные endpoints; есть ли односторонний звук. Записываю время проверки и сохраняю журналы Asterisk и системные сообщения. В зависимости от настроек основной журнал может находиться в /var/log/asterisk/full, но путь и состав каналов логирования проверяю на установленной системе. Команда asterisk -rx "core show channels" покажет активные каналы, а pjsip show endpoints — состояние PJSIP endpoints.

Затем повторяю один сценарий и наблюдаю CLI. Для краткой диагностики PJSIP можно включить pjsip set logger on, выполнить вызов и выключить pjsip set logger off. Протокольный вывод иногда содержит номера и другие служебные сведения, поэтому храню его ограниченное время и передаю только тем, кому он нужен для разбора. Для проверки медиапотока сопоставляю адреса в SDP и счётчики/захват трафика на нужных интерфейсах. Не делаю вывод о причине по одному сообщению «таймаут».

Если подтверждён сбой службы, планирую перезапуск в согласованное окно и заранее предупреждаю о кратком перерыве звонков. Название systemd-юнита зависит от дистрибутива и пакета; прежде чем выполнять команду перезапуска, проверяю реальное имя службы через systemctl list-units. После запуска проверяю регистрацию транка, внутренний вызов и оба направления медиапотока. Если симптомы возвращаются, перезапуск не считаю решением — он лишь восстановил работу до следующего проявления.

Изменения в firewall и NAT вношу по одному и сохраняю предыдущие правила, чтобы можно было откатиться. В интерфейсе FreePBX применяю конфигурацию и проверяю, не перегенерировались ли настройки. После устранения причины обновляю журнал инцидента: симптом, версия системы, обнаруженная причина, изменение и результат контрольных звонков. Такой короткий отчёт экономит часы при повторном сбое. Да, он скучнее магической команды. Зато работает в следующий раз.

• Определите масштаб сбоя и сохраните журналы.
• Воспроизведите проблему одним вызовом.
• Проверьте SIP и RTP раздельно.
• Перезапускайте только после фиксации исходного состояния.

Профилактика: резервная копия, контроль и проверочный звонок

План профилактики начинается с резервной копии конфигурации, записей и голосовой почты в нужном для компании объёме. В FreePBX есть модуль Backup & Restore, но наличие задания ещё не означает, что восстановление проверено. Проверяю расписание, место хранения и доступ к архиву, а восстановление пробую на отдельной системе или в согласованное окно. Резервная копия на том же диске защищает только от некоторых ошибок; при отказе носителя она уходит вместе с оригиналом.

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

В отдельном материале разобрал настройку SIP-транков FreePBX. Обновления планирую после проверки совместимости и наличия копии, сначала на тестовой системе, если она есть. Отдельно сохраняю версии модулей, FreePBX и Asterisk; после обновления прохожу один и тот же чек-лист: внутренний вызов, входящий, исходящий, двусторонний звук и запись, если она используется. Универсального графика «раз в месяц» для всех установок нет. Частота зависит от исправлений безопасности, поддержки платформы и окна, в которое компания может проверить телефонию.

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

• Храните копию отдельно и проверяйте восстановление.
• Контролируйте регистрации, место и тестовый вызов.
• Фиксируйте версии до каждого обновления.
• Проверяйте полный сценарий после изменений.

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