Решение проблем с маршрутизацией
Когда вызов обрывается короткими гудками или фразой «all circuits are busy», в системе происходит разрыв логической цепочки. В Asterisk это классифицируется как ошибка маршрутизации. Ядро системы не может сопоставить набранный номер с правилами в текущем контексте.
В отличие от проблем с регистрацией, здесь SIP-сигнализация работает, но логика диалплана заводит вызов в тупик. Чтобы найти точку разрыва, нужно использовать CLI (Command Line Interface) и понимать, как FreePBX формирует маршруты.
Инструментарий: CLI для диагностики
Чтобы увидеть прохождение вызова «глазами» Asterisk, используйте команду:
dialplan set debug on
Она выводит в консоль каждый шаг: через какие контексты и приложения проходит звонок.
Для проверки маршрута без совершения звонка используйте:
dialplan show [номер]@[контекст]
Так вы мгновенно узнаете, существует ли подходящий шаблон (Pattern Matching) для номера в конкретном контексте.
Как показано в Схеме 1, диагностика всегда начинается с определения «точки входа» — контекста, в который попал вызов.
Сценарий 1: Неправильный контекст
Неправильный контекст — это ситуация, когда вызов попадает в группу правил, где нужный номер не описан. Во FreePBX это часто случается при настройке PJSIP-транков.
Например, если входящий вызов от провайдера попадает в контекст from-internal (внутренний) вместо from-pstn (внешний), Asterisk будет искать городской номер среди внутренних номеров сотрудников. Не найдя совпадения, система сбросит звонок.
Вызов от провайдера приходит на PJSIP-транк. В настройках транка указан context=default.
В консоли:
[2026-05-20] NOTICE: Executing [74951234567@default:1] Hangup("PJSIP/Provider-00001", "")
Проблема: В контексте default нет правил для обработки городских номеров.
Решение: Укажите верный контекст в настройках транка во FreePBX (Connectivity -> Trunks -> PJSIP Settings).
context=from-pstn
Теперь Asterisk направит вызов в логику обработки входящих маршрутов.
Сценарий 2: Отсутствие маршрута и ошибки шаблонов
Отсутствие маршрута обычно связано с ошибками в шаблонах (Pattern Matching). Чаще всего это касается префиксов 8, 7 и +7.
Если сотрудник набирает номер через 8, а в исходящем маршруте (Outbound Routes) прописан только шаблон 7XXXXXXXXXX, Asterisk выдаст ошибку.
Проверьте маршрут для мобильного номера в CLI:
dialplan show 89161234567@from-internal
Если система ответит Could not find extension, значит, шаблон для префикса «8» отсутствует.
Сценарий 3: Блокировка в диалплане
Бывает, что маршрут найден и контекст верен, но вызов прерывается. Это происходит из-за логики приложений. Во FreePBX за это часто отвечают модули ограничений (Extension Routing или Custom Contexts).
В логах вы увидите успешный старт, который внезапно прерывается приложением Congestion или Hangup с кодом причины (Cause Code).
Практика: Анализ лога
При поиске ошибки фильтруйте вывод по Call ID (уникальному идентификатору вызова), чтобы не отвлекаться на фоновые процессы.
Анализ ошибки в консоли (asterisk -rvvv):
-- Executing [89001112233@from-internal:1] ResetCDR("PJSIP/101-0000a", "") in new stack
-- Executing [89001112233@from-internal:2] NoOp("PJSIP/101-0000a", "Outbound Call") in new stack
-- Executing [89001112233@from-internal:3] Dial("PJSIP/101-0000a", "PJSIP/89001112233@Provider,30") in new stack
-- PJSIP/Provider-0000b is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
-- Executing [89001112233@from-internal:4] Hangup("PJSIP/101-0000a", "") in new stackЗдесь маршрутизация внутри Asterisk сработала (выполнена команда Dial), но внешний провайдер вернул circuit-busy. Нужно проверить авторизацию транка или баланс у оператора.
Мы разобрали, как вызов проходит через диалплан и где возникают затыки. Однако открытые порты и работающая маршрутизация делают АТС мишенью для атак. Чтобы ваши линии не использовали для платных звонков в другие страны, в следующем уроке мы займемся защитой периметра: настроим Fail2Ban и правила файрвола.
Понравился урок?
Сохраните прогресс и получите персональный курс по любой теме — без форм и паролей
Продолжить в Telegram