Пять проверок, если FreePBX теряет SIP-транк

Если SIP-транк в FreePBX не регистрируется, сначала выясняю, отправляет ли Asterisk REGISTER и какой ответ возвращает сервер провайдера. Затем сверяю transport, учётные данные, адрес и сетевые правила. Так ошибка превращается из гадания в короткий список проверок; ниже разбираю порядок, который использую сам.

Сначала выясняю, что именно означает статус транка

В FreePBX открываю Connectivity → Trunks и смотрю состояние нужного транка. Надпись в веб-интерфейсе — ориентир, не диагноз: она зависит от типа транка, версии модулей и того, настроена ли регистрация вообще. Транк по IP-адресу может работать без REGISTER, поэтому требовать от него состояния Registered бессмысленно. Сначала выясняю у оператора, должна ли АТС регистрироваться по логину и паролю или оператор ждёт подключения с известного адреса.

Для PJSIP проверяю список регистраций в CLI Asterisk командой pjsip show registrations. Состояния Registered, Unregistered и Rejected говорят о разных этапах: регистрации может ещё не быть, она может быть снята или сервер уже ответил отказом. Если нужной записи нет, проверяю, создал ли FreePBX объект регистрации и применена ли конфигурация. Само отсутствие строки не доказывает, что запрос потерялся в сети. А вот статус Rejected — повод смотреть конкретный ответ и журнал, а не угадывать пароль.

Когда причина не видна, включаю подробный журнал PJSIP на короткое время, воспроизвожу одну попытку и затем выключаю трассировку: в ней могут оказаться номера и другие данные звонков. Сопоставляю время попытки, адрес назначения и SIP-ответ. Первый REGISTER может получить 401 или 407 как штатный вызов digest-аутентификации; важно, что последовало после ответа. Запись «401 значит пароль неверный» часто отправляет диагностику не туда. Важны последовательность запросов и финальное состояние.

• Уточнить у оператора: REGISTER или транк по IP.
• Выполнить `pjsip show registrations`.
• Сопоставить попытку и ответ в журнале.

Транспорт выбираю по требованиям оператора

SIP может идти по UDP, TCP или TLS, если обе стороны поддерживают выбранный транспорт. Я сверяю его с карточкой подключения оператора: протокол, имя регистратора и порт. Не переключаю транспорт наугад и не начинаю с TCP «для надёжности». Если FreePBX отправляет REGISTER по UDP, а удалённая сторона слушает TCP, согласования не будет; но сама по себе смена транспорта не чинит неверное имя узла, учётные данные или фильтрацию.

В FreePBX параметры транспорта находятся в настройках PJSIP-транка; точные подписи и доступные значения зависят от версии модуля и настроек Asterisk. Изменение общего транспорта может затронуть другие объекты PJSIP, поэтому до правки проверяю, какой именно transport привязан к регистрации и совпадает ли он с требованиями оператора. После Submit и Apply Config снова смотрю состояние регистрации и журнал. Перезапускать службу целиком без необходимости не нужно: это оборвёт текущие звонки, а причину всё равно не покажет.

В практической диагностике я не объявляю причину по одной строке журнала. Сначала проверяю, отправлен ли запрос, на какой транспорт и адрес, затем сопоставляю его с ответом регистратора. Меняю только подтверждённое расхождение. Если оператор не указал транспорт, задаю вопрос его поддержке. У разных операторов и узлов настройки отличаются; универсального «правильного UDP» или «правильного TCP» нет. Документация провайдера полезнее уверенного совета из случайной инструкции. Иначе можно бодро исправлять параметр, который изначально был настроен верно.

• Сверить UDP/TCP/TLS и порт с параметрами оператора.
• Проверить transport именно у регистрации.
• После применения конфигурации повторить одну попытку.

Разделяю SIP-сигнализацию и RTP-медиа

Регистрация — это SIP-обмен с регистратором. RTP обычно передаёт звук уже во время вызова. Поэтому диапазон RTP не является универсальным условием, чтобы отправить REGISTER; если транк зарегистрирован, но собеседники не слышат друг друга, тогда исследую медиатрафик отдельно. И наоборот: отказ регистрации проверяю по SIP-запросу и ответу. Совет «откройте 5060 и весь RTP» без направления, протокола и адресов — не диагностика, а приглашение расширить доступ лишним узлам.

Порт 5060 часто используют для SIP, но это не обязательный порт каждой установки: FreePBX может слушать на другом порту, а исходящее подключение к оператору может использовать свой адрес и порт. Сверяю фактические значения в настройках и документации оператора, затем смотрю правила на самом сервере, маршрутизаторе и внешнем фильтре. Разрешаю только требуемый трафик между нужными адресами. Открывать входящий доступ из всего интернета «на всякий случай» не требуется и может ухудшить безопасность АТС.

Для наблюдения за сетью использую tcpdump с фильтром по фактическому адресу и порту регистратора; параметры захвата выбираю на установленной системе. Проверяю, виден ли исходящий запрос и возвращается ли ответ. Если запрос покидает сервер, но ответа нет, это сужает поиск до маршрута, фильтрации или удалённой стороны, но само по себе не доказывает вину роутера. Проверяю счётчики правил и уточняю у оператора, видит ли он попытку. При NAT отдельно сверяю адреса сигнализации и медиа, когда проблема относится к звонкам.

• REGISTER: адрес, порт, транспорт и ответ.
• RTP: отдельно проверять при проблемах со звуком.
• Сетевые правила ограничить нужными адресами.

Проверяю логин, секрет и режим регистрации

В FreePBX сверяю имя пользователя, Auth Username, секрет и домен From с данными оператора. Эти поля могут отличаться друг от друга: номер линии не всегда равен имени для аутентификации, а registrar может быть не тем же узлом, что прокси. Копирую значения из актуальной карточки подключения, убираю пробелы по краям и проверяю, не подставил ли браузер пароль от самой панели. Секрет не вставляю в письмо или общий журнал; если он попал в снимок экрана, меняю его у оператора.

Важно не смешивать Authentication и Registration: в интерфейсе FreePBX это разные настройки. Значение None может быть нормальным для транка по IP, где оператор идентифицирует сторону по адресу, и неправильным там, где требуется исходящая регистрация с digest-аутентификацией. Я не советую всем выставлять None или наоборот включать авторизацию: сверяю ожидаемую схему оператора с ответами в журнале. 401/407 может быть частью обычного вызова аутентификации; повторный отказ после передачи credentials уже требует проверки пользователя, секрета, realm и способа сопоставления.

Срок действия регистрации тоже не задаю по слухам. В PJSIP за регистрацию отвечает отдельный объект, у которого параметр expiration задаёт срок, а retry_interval — паузу между неудачными попытками. Значения согласую с сервером оператора и не подменяю их мифической парой «60 против 300 секунд». Повторные попытки при недоступном регистраторе и истечение уже принятой регистрации — разные события. Если связь периодически пропадает, фиксирую точный статус, ответ и время следующей попытки, прежде чем менять интервалы.

• Сверить Username, Auth Username, Secret и realm.
• Уточнить схему: регистрация или доверие по IP.
• Проверить expiration и retry_interval по документации оператора.

Сверяю адрес регистратора и DNS

Проверяю, что в SIP Server или соответствующем поле PJSIP указан актуальный адрес регистратора и нужный порт. Старый IP может перестать обслуживать оператора; доменное имя может разрешаться иначе, чем ожидалось. Но вывод «домен не работает, потому что DNS не настроен» без проверки — преждевременный. Сначала проверяю разрешение имени средствами ОС и уточняю у оператора, используется ли SRV или обычная A/AAAA-запись. SRV Lookup не является обязательным флажком для каждого SIP-транка.

Если оператор использует несколько узлов или SRV-записи, смотрю, что реально вернул DNS-резолвер сервера, и совпадают ли приоритеты/адреса с документацией подключения. Учитываю кэш и локальный DNS, особенно после смены площадки или маршрутизатора. Если DNS выдаёт ожидаемый адрес, но пакет уходит в другую сторону, продолжаю проверку маршрута и фильтра. Если адрес не разрешается, это уже отдельная DNS-проблема. Не заменяю доменное имя случайным IP из старой заметки: у оператора адреса могут меняться.

Затем сверяю настройки NAT, если Asterisk находится за маршрутизатором. Для регистрации важны достижимость регистратора и корректный возврат ответов; для входящих вызовов и звука могут понадобиться дополнительные настройки внешнего адреса и медиапути. Это связанные, но не тождественные задачи. В PJSIP документация Asterisk отдельно описывает transport, регистрацию и NAT-параметры endpoint. Я проверяю конкретный объект, который обслуживает транк, а не копирую настройки телефонного аппарата на транк: похожие слова в интерфейсе не означают одинаковую роль.

• Проверить адрес, порт и разрешение имени.
• Включать SRV только при соответствующей схеме оператора.
• При NAT отдельно проверить сигнализацию и медиа.

Проверяю параллельную регистрацию и входящие вызовы отдельно

Во время миграции старый сервер действительно может продолжать отправлять REGISTER с теми же данными. Но утверждение «две регистрации всегда блокируют друг друга» неверно: поведение зависит от оператора, параметра контактов и его политики. Я проверяю, не осталась ли старая АТС включённой, уточняю у оператора допустимое число контактов и смотрю, какой контакт отображается у него. Отключаю старый узел только после согласованного переключения, чтобы не потерять связь посреди рабочего дня.

Если REGISTER успешен, а входящие вызовы не приходят, перехожу к другой ветке. Проверяю, принимает ли Asterisk INVITE от адресов оператора, сопоставляется ли источник с нужным endpoint и настроен ли входящий маршрут FreePBX. У PJSIP это может зависеть от identify/match; запрос из неизвестного источника и отказ регистрации — не один симптом. Для исходящих вызовов отдельно проверяю outbound route и формат набираемого номера. Зарегистрированный транк ещё не гарантирует, что маршрутизация в FreePBX выберет именно его.

После исправления фиксирую исходное состояние, одну внесённую правку и результат повторной проверки: статус регистрации, входящий тест, исходящий тест и звук в обе стороны. Если оператор подтверждает REGISTER, но FreePBX показывает отказ, прикладываю время попытки и очищенный от секретов фрагмент SIP-журнала. Если оператор не видит пакет, передаю ему адрес назначения, транспорт и время. Такой короткий отчёт быстрее общего «ничего не работает». И да, перезапуск в конце не заменяет диагностику — даже если иногда помогает случайно.

• Уточнить у оператора лимит контактов.
• При успешной регистрации проверить INVITE и маршруты.
• Зафиксировать результат входящего и исходящего теста.

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