Почему FreePBX не звонит и где искать сбой

Когда FreePBX не звонит, я сначала выясняю, где обрывается цепочка: телефон зарегистрирован, вызов дошёл до Asterisk, найден маршрут, а аудио проходит в обе стороны? Эти проверки отделяют сбой учётных данных от ошибки dialplan, AMI или NAT. Ни одна галочка не чинит всё сразу.

1. Телефон не зарегистрирован: проверьте endpoint и учётные данные

Первым делом я разделяю два состояния: телефон не зарегистрирован и зарегистрирован, но не может дозвониться. Это разные неисправности. В Asterisk CLI выполните pjsip show endpoints, затем проверьте контакты нужного endpoint командой pjsip show contacts. В системе на chan_sip команды будут другими; не копируйте выводы одного драйвера на другой. В FreePBX найдите соответствующий внутренний номер и сверьте имя аутентификации, пароль и выбранный драйвер с настройками самого телефона. Секреты не вставляйте в тикеты и скриншоты: для диагностики достаточно проверить совпадение, а не публиковать значение.

Если PJSIP не видит контакт, смотрите сообщения в журнале Asterisk и уточняйте, доходит ли запрос регистрации до сервера. Ошибка пароля — лишь один вариант: неверный auth username, транспорт, адрес/порт, сетевой фильтр или конфликт настроек тоже могут сорвать регистрацию. Фраза No matching peer found не универсальная диагностика для всех версий и драйверов; ищите точную строку в своём журнале и учитывайте, какая технология обслуживает номер. В типовой установке полный журнал часто находится в /var/log/asterisk/full, но путь и состав логов зависят от системы. Я не перезапускаю весь Asterisk после каждой правки: сначала проверяю конфигурацию, применяю изменения FreePBX и повторяю регистрацию. Полезно записать время контрольной попытки и внутренний номер, а затем смотреть журнал именно за этот интервал. Сначала установите, появился ли запрос на стороне Asterisk; если записи нет, ищите причину до PBX — в телефоне, сети или адресе назначения. Если запрос есть, сохраните несколько строк до и после ошибки: одиночное сообщение часто теряет важный контекст. Такая короткая фиксация экономит время при повторной проверке.

• Проверьте `pjsip show endpoints` и `pjsip show contacts`.
• Сверьте auth username, пароль и драйвер у номера и телефона.
• Изучите точное сообщение в журнале и сетевой путь.
• После правки примените конфигурацию FreePBX.

2. AMI не отвечает: отличите управление от маршрута звонка

Asterisk Manager Interface (AMI) — интерфейс управления Asterisk. Через него приложение может получать события, запрашивать состояние каналов или инициировать действия. Обычный вызов между абонентами проходит через каналы и dialplan; он не обязан «залипнуть в Ringing» из-за любой ошибки AMI. Поэтому я проверяю AMI, когда не работают функции панели или интеграция, а не объявляю его причиной каждого неудачного звонка. Если сбой проявляется только при нажатии кнопки вызова в интеграции, AMI становится одним из первых подозреваемых.

Пользователи AMI и их полномочия задаются в конфигурации менеджера; в обычном Asterisk это manager.conf, а FreePBX может генерировать связанные файлы и настройки. Документация Asterisk описывает права чтения для событий и права записи для действий. Проверяйте, что учётная запись включена, пароль совпадает на обеих сторонах, разрешён адрес клиента и запрошены только нужные классы доступа. Не выдавайте широкие права по принципу «лишь бы заработало» и не открывайте AMI всему интернету. После согласованного изменения FreePBX примените конфигурацию, например fwconsole reload в поддерживаемой системе, и посмотрите статус менеджера в CLI. Не перезапускайте модуль наугад: сначала выясните, какой именно клиент теряет соединение и что сообщает журнал. У AMI-событий и SIP-вызова разные признаки отказа. Проверьте подключение интеграции отдельно от звонка с самого телефона: если телефон звонит, а кнопка CRM — нет, сравните журнал подключения менеджера и действие приложения. Если не работают оба способа, возвращайтесь к endpoint и dialplan. При публикации адреса AMI оставьте доступ лишь необходимому источнику и проверьте ACL. Пароль меняйте в обоих местах согласованно, сохраняя запись в защищённом хранилище.

• Уточните, какая функция приложения зависит от AMI.
• Сверьте учётную запись, пароль, адрес клиента и права.
• Ограничьте доступ к AMI доверенными адресами.
• Примените изменения способом, предусмотренным вашей сборкой FreePBX.

3. Звонок есть, звука нет: проверьте NAT и RTP

Если вызов устанавливается, но слышно только одну сторону или нет звука вовсе, исследуйте медиатрафик RTP отдельно от SIP-сигнализации. При работе за NAT Asterisk должен сообщать удалённой стороне достижимые адреса, а сетевой экран должен пропускать согласованный диапазон RTP. Для PJSIP официальная документация описывает параметры local_net, external_media_address и external_signaling_address в объекте транспорта; настройки зависят от топологии и версии. В FreePBX обычно задают внешние и локальные сети в системных SIP-параметрах, а затем применяют конфигурацию. Не вписывайте случайный адрес из примера документации и не дублируйте настройки в генерируемом файле: сначала определите реальную схему маршрутизации.

Проверяйте звонок с двух сторон: что Asterisk получил при установлении вызова и какие адреса/порты указаны для медиа, затем подтвердите прохождение RTP на сетевом экране или захвате трафика. Наличие rport само по себе не доказывает, что NAT настроен неверно. SRV Lookup не является обязательным переключателем для любого соединения: он нужен там, где выбор SIP-сервера зависит от DNS SRV-записей или соответствующей настройки транка. Кодек выбирают по возможностям обеих сторон и требованиям провайдера; G.711 часто совместим, но не «предпочтителен всегда». H.264 — видеокодек, и его включение не является типовым лечением отсутствующего голосового RTP. Сначала проверяйте сеть и SDP, потом меняйте параметры. Не меняйте сразу внешний адрес, кодеки и диапазон портов: тогда станет непонятно, какая правка повлияла на результат. Сравните SDP на входящем и исходящем направлениях и отметьте адрес назначения для аудио. Если сигнализация дошла, но медиа нет, проверить RTP можно на сетевом экране или кратким захватом пакетов в пределах принятой процедуры. Учитывайте, что отображаемый Asterisk адрес не заменяет проверку маршрута и правил фильтрации между площадками.

• Зафиксируйте, устанавливается ли вызов и в каком направлении нет аудио.
• Сверьте `local_net` и внешние адреса с реальной схемой NAT.
• Проверьте SDP и прохождение RTP на сетевом экране.
• Используйте SRV и кодеки только по требованиям конкретного транка.

4. Ошибка прав: не меняйте владельца Apache вслепую

Неприменённые настройки, ошибки записи в файлы или недоступность панели могут указывать на права, но сами по себе не доказывают, что Apache запущен «не тем» пользователем. Сборки FreePBX различаются, а веб-сервер, PHP и процессы Asterisk взаимодействуют через набор каталогов и механизмов запуска. Утверждения «по умолчанию это www-data» и «везде надо поставить asterisk» нельзя переносить на любой сервер. Я сначала читаю точную ошибку, проверяю пользователя процессов, владельца затронутого файла и документацию для конкретного дистрибутива. Отдельно выясняю, какие конфиги генерирует FreePBX: ручное редактирование сгенерированных файлов может быть перезаписано при следующем применении настроек.

Не запускайте chmod -R 777 и не переводите веб-сервер на root ради быстрого результата. Это ломает границы доступа и не исправляет причину. Если проблема действительно в владельцах файлов FreePBX, штатная команда fwconsole chown предусмотрена для исправления прав в поддерживаемых версиях; сначала прочитайте справку команды и проверьте её применимость к своей установке. После исправления прав заново примените конфигурацию и проверьте журнал веб-приложения и Asterisk. Если падает только запись конкретного модуля, корректируйте конкретный путь согласно официальной инструкции, а не меняйте владельца всего дерева. Права доступа должны объяснять конкретную ошибку, а не служить универсальным ритуалом. Сверка владельца имеет смысл только для пути, на который указывает ошибка. Посмотрите учётную запись процесса и права конкретного каталога штатными системными средствами; не публикуйте вывод, если в нём есть внутренние имена или адреса. До исправления сохраните текущие владельца и режим доступа, чтобы понимать исходное состояние и при необходимости вернуть его. После команды восстановления проверьте запись именно той операции, которая падала, а не только успешный вход в веб-интерфейс.

• Найдите точное сообщение об отказе в записи или доступе.
• Сверьте процессы и права только затронутых каталогов.
• Учитывайте тип установки и документацию своей версии FreePBX.
• Не используйте рекурсивные широкие права и root для Apache.

5. Вызов не найден: проверьте контекст и маршрут dialplan

Когда Asterisk принимает вызов, но не находит набранный номер, проверьте контекст, в который попал endpoint или транк, и существует ли в нём подходящее расширение. Контекст задаёт канал, а include позволяет искать совпадение в подключённых контекстах. Это не означает, что в любой конфигурации надо вручную добавлять include => from-internal: внутренний контекст FreePBX и контекст входящего транка решают разные задачи. В CLI выполните dialplan show ИМЯ_КОНТЕКСТА, подставив фактическое имя из сообщения Asterisk. Официальная документация советует сверять контекст и набранное расширение; если совпадения нет, вызов будет отклонён.

Не считайте 404 Not Found универсальным ответом на ошибку dialplan. В сообщениях Asterisk важна конкретная причина: endpoint обращается к неизвестному контексту, расширение отсутствует или маршрут FreePBX не сгенерирован. Сверьте направление вызова, номер, контекст endpoint/транка и журналы на момент набора. Изменения маршрутов делайте в интерфейсе FreePBX и нажимайте Apply Config либо применяйте fwconsole reload; так перегенерируется конфигурация платформы. Не редактируйте extensions_additional.conf и другие генерируемые файлы напрямую. Для пользовательских дополнений используйте предусмотренные FreePBX include-файлы и сначала сделайте копию. После reload повторите контрольный вызов и сравните фактический контекст с ожидаемым. Если маршрут всё ещё не найден, сохраните CLI-вывод и точную строку журнала: они сузят проблему быстрее, чем ещё один перезапуск. При проверке маршрута важно понять, входящий это вызов или исходящий: точка входа и контекст у них могут различаться. Сначала сверяйте направление, затем endpoint или транк, контекст и набранный номер. Если используется шаблон номера, проверьте его совпадение с конкретной последовательностью. После исправления сравните CLI-вывод до и после применения конфигурации. Не отправляйте в публичный чат полный дамп: удалите номера абонентов, адреса, имена пользователей и секреты.

• Возьмите имя контекста и номер из сообщения о вызове.
• Проверьте контекст командой `dialplan show ИМЯ_КОНТЕКСТА`.
• Исправьте маршрут в FreePBX, не в сгенерированном файле.
• Примените конфигурацию и повторите контрольный вызов.

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