Как найти причину отказа PJSIP без гадания по статусу

Если Asterisk или телефон не проходит SIP-регистрацию, сначала выясните, кто отправляет REGISTER и кому: телефону в Asterisk или Asterisk провайдеру. Затем сопоставьте статус с SIP-трассой и объектами конфигурации. Ниже — рабочий порядок проверки, условный пример и исправления без гадания по одному коду ответа.

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

Перед первой правкой я задаю простой вопрос: кто отправляет REGISTER? В одном сценарии телефон регистрируется на Asterisk, и PBX принимает его запрос. В другом Asterisk сам регистрируется у SIP-провайдера как клиент. Это два разных процесса, и команда для исходящей регистрации не докажет, что телефон успешно вошёл на внутреннюю АТС. Если нужна помощь с самой телефонной инфраструктурой, я начинаю с ИТ-аутсорсинга и проверки конфигурации, а не с замены оборудования.

Для исходящей регистрации транка в CLI выполните pjsip show registrations. Команда показывает именно регистрации, которые Asterisk отправляет на внешние серверы. В норме вы увидите один из статусов Unregistered, Registered, Rejected или Stopped; надписи REGISTERED FAILED в этом перечне нет. Для конкретной записи есть команда pjsip show registration <имя-регистрации> — она раскрывает параметры объекта. Если регистрируется внутренний телефон, смотрите его endpoint и сообщения CLI во время новой попытки: не переносите на этот сценарий статус транка. Если транк не отображается, проверьте, что подключились к нужному экземпляру Asterisk и смотрите нужную запись: пустой список сам по себе не говорит, доступен ли оператор. Внутренний телефон проверяют в его сценарии, а не по списку исходящих регистраций.

Чтобы увидеть сам обмен, в консоли Asterisk включите core set verbose 4, core set debug 4 и pjsip set logger on, затем повторите одну попытку регистрации. В трассе найдите исходящий REGISTER, адрес назначения, ответ и следующий запрос клиента. Один 401 Unauthorized часто является нормальным запросом учётных данных: клиент должен повторить REGISTER с авторизацией. 403 Forbidden означает отказ сервера, но сам по себе не доказывает, что пароль неверный. Я сохраняю фрагмент диалога и после проверки выключаю трассу командой pjsip set logger off; в логах могут оказаться номера, имена учётных записей и сетевые адреса. На загруженной АТС я держу трассировку включённой только на время одной проверки: иначе в лог попадут параллельные диалоги и разбор станет сложнее. Перед передачей фрагмента уберите номера и другие данные, которые не нужны для диагностики.

Не путайте отсутствие ответа с отказом. Если запрос ушёл, но ответ не пришёл, ищите проблему в разрешении имени, выборе транспорта, маршруте или сетевой фильтрации; если пришёл SIP-код, сначала разбирайте содержание ответа и то, какой запрос Asterisk отправил следом. Это разные ветки поиска, и простое изменение пароля не заставит ответ появиться на линии.

• Уточните направление REGISTER
• Для транка проверьте pjsip show registrations
• Смотрите ответ и повторный запрос
• После диагностики выключите SIP-трассу

Как разобрать отказ регистрации транка

Возьмём условный пример из поля компании: ООО «Тополь-М», небольшая АТС на 12 рабочих мест, и утром транк перестал регистрироваться. Это модельный сценарий, а не описание реального клиента. Я сначала открываю строку регистрации и сверяю server_uri, client_uri, транспорт и ссылку outbound_auth. Затем смотрю имя связанного объекта auth, его username, realm и пароль. Пароль здесь не показываю и в общий чат не копирую: отладочный лог нужен для SIP-заголовков и ответов, а не для распространения секретов. Я записываю время попытки и точное имя объекта, чтобы не смешать две похожие записи. Если у компании несколько транков, проверка «первого попавшегося» результата часто создаёт ложное ощущение, что найден именно тот маршрут, который отказал. Если АТС управляется через FreePBX и проблема проявляется как невидимый в интерфейсе транк, смотрите проверку FreePBX-транка; здесь я разбираю диагностику через CLI и связи объектов res_pjsip.

Проверьте также, что server_uri содержит адрес регистратора в формате SIP URI, а client_uri — идентификатор, который выдал оператор. Они могут отличаться: подставлять в оба поля один и тот же логин без документации провайдера не надо. Если ответ 401 повторяется после запроса с авторизацией, проверьте логин, пароль, realm и привязанный объект outbound_auth. Если приходит 403, выясните у оператора, разрешены ли этот аккаунт, адрес источника и нужная услуга. Не делайте вывод «провайдер заблокировал за частые запросы», пока журнал и условия оператора этого не подтверждают.

Не путайте срок действия регистрации с паузой между повторными попытками. В res_pjsip для исходящей регистрации используются, в частности, expiration и retry_interval: первый задаёт срок регистрации, второй — паузу перед повтором неудачной попытки. В документации Asterisk для expiration указан default 3600 секунд, для retry_interval — 60 секунд. Значение 60 в поле повтора не означает, что успешную регистрацию надо обновлять каждые 60 секунд, и не является само по себе причиной блокировки. Если оператор требует другие значения, сверяйте его требования с документацией именно вашей версии Asterisk.

В SIP-сообщении отдельно видны адреса участников, Request-URI и заголовки авторизации; имя пользователя для Digest не обязано совпадать с номером телефона или адресом регистратора. Сравните каждое поле с данными оператора, а не только логин на экране настройки. Для транка с несколькими доменами дополнительно уточните, какой realm ожидает registrar, и используйте именно его, если он задан в конфигурации.

• Сверьте server_uri и client_uri
• Проверьте связанный outbound_auth
• Отделите expiration от retry_interval
• Сверьте требования с оператором

Проверьте связи объектов в pjsip.conf

Файл pjsip.conf — набор объектов с типами, а не шесть обязательных секций с названиями из старого шаблона. У исходящего транка обычно есть объект type=registration с server_uri и client_uri, а при аутентификации — ссылка outbound_auth на объект type=auth. Сам объект учётных данных называется типом auth, не authentication. У endpoint отдельно задаются параметры вызовов и ссылка на один или несколько AOR; endpoint и registration не обязаны ссылаться друг на друга так, как это описывал черновик.

AOR отвечает за контакты, к которым направляются вызовы, а endpoint задаёт профиль SIP-связи и связывается с AOR через параметр aors. Для входящих запросов от провайдера объект type=identify может сопоставить источник из match нужному endpoint. Это определение входящего SIP-трафика; оно не выбирает исходящий Caller ID. Исходящая регистрация у провайдера — отдельный объект, и путать его с регистрацией телефона на нашей АТС опасно: в результате можно чинить правильный пароль в совершенно не том месте. У входящего запроса должна сложиться непрерывная цепочка: адрес источника сопоставился через identify, запрос попал на ожидаемый endpoint, а ссылка ведёт к нужным данным. Ошибка на любом шаге даёт другой ответ и другой участок для проверки. Пароль проверяйте только после того, как уверены, что запрос попал в правильный объект.

Я иду по ссылкам в конфигурации от конкретного запроса, а не переименовываю всё подряд. Входящий REGISTER от телефона требует понять, как Asterisk сопоставляет его с endpoint и какие данные ожидает в auth; исходящий REGISTER к оператору требует проверить registration, server_uri, client_uri и outbound_auth. Ошибку в имени ссылки видно быстрее, если читать весь связанный фрагмент, а не только секцию с паролем. Для базовой структуры объектов пригодится разбор настройки res_pjsip. Перед правкой я сохраняю исходный файл и отмечаю изменённые строки, чтобы откат не превратился в археологию. Не заменяйте outbound_auth параметром auth: первое имя относится к ответу на challenge при исходящей регистрации, второе в endpoint связывает учётные данные для входящего сценария. Похожее название не делает эти ссылки взаимозаменяемыми. Если в конфигурации несколько учётных записей, в записи ошибки сразу укажите конкретные имена секций.

Связи исходящей регистрации в упрощённом виде выглядят так:

[provider-registration]
type=registration
server_uri=sip:registrar.example.com
client_uri=sip:account@example.com
outbound_auth=provider-auth

[provider-auth]
type=auth
auth_type=userpass
username=account-name

Это схема связей, а не готовый конфиг для конкретного оператора: его URI, логин, пароль, транспорт и прочие поля берите из его инструкции. Пароль в пример не помещаю. Здесь важно другое: outbound_auth указывает на объект auth, а не на endpoint.

• У registration проверьте server_uri и client_uri
• У registration проверьте outbound_auth
• У endpoint проверьте ссылку aors
• Для входящих запросов проверьте identify и match

Отделите отказ регистрации от проблем NAT и звука

Если REGISTER проходит, но звонок не устанавливается или пропадает звук, это уже отдельная часть диагностики. SIP-сигнализация и RTP-медиа используют разные настройки и маршруты. Для Asterisk за NAT в транспортной конфигурации проверьте local_net, external_signaling_address для SIP и external_media_address для адреса RTP в SDP. Это реальные названия параметров PJSIP; external_media_ip и external_rtp_ip из прежнего текста Asterisk не распознаёт как эти настройки. Значения должны соответствовать схеме NAT и тому, какой адрес доступен другой стороне.

Порт 5060 — стандартное значение SIP для UDP и TCP по RFC, но провайдер или ваша конфигурация могут использовать другой порт и транспорт; для TLS стандартный порт — 5061. В transport сверяйте protocol и bind, а с оператором — адрес назначения и порт. Для RTP смотрите rtpstart и rtpend в rtp.conf: примерный файл Asterisk задаёт значения по умолчанию 5000 и 31000, хотя в образце отдельно приведена конфигурация 10000–20000. Поэтому открывать 10000–20000 как универсальный диапазон нельзя — сначала проверьте действующие настройки. Эти значения — не команда открыть всё подряд в обе стороны. Сначала выясните, какой транспорт слушает именно ваш Asterisk: 5060 является стандартным портом SIP для UDP и TCP, 5061 — для TLS, но transport можно настроить иначе. Внешний порт маршрутизатора также может отличаться от внутреннего, поэтому сверяйте опубликованный порт с bind и параметрами провайдера.

Правила межсетевого экрана должны пропускать только нужную сигнализацию и настроенный диапазон RTP с ожидаемых адресов, насколько это поддерживает ваша схема. Проверка того, что процесс слушает порт, не доказывает, что пакеты проходят через маршрутизатор или что обратный RTP возвращается тем же путём. Для удалённых телефонов за NAT могут понадобиться force_rport, rtp_symmetric или rewrite_contact на endpoint; включать их всем подряд не нужно. STUN тоже не универсальный параметр исходящей регистрации PJSIP: сначала проверьте транспорт, NAT и SDP. Отдельно про ICE для клиентов, которым он действительно нужен, можно прочитать в статье о PJSIP с ICE и STUN. Если регистрация уже успешна, но звук односторонний, сравните адрес в SDP с тем, куда реально отправляются RTP-пакеты, и проверьте обратное направление. Не исправляйте такую ситуацию сменой пароля: она не меняет маршрут медиа. Если же Asterisk вообще не получает ответа на REGISTER, сначала разберите signaling и только потом переходите к RTP.

Эти транспортные параметры отвечают за разные части сообщения: external_signaling_address влияет на SIP-сигнализацию, external_media_address — на адрес медиа в SDP. Указанный в SDP внутренний адрес может быть недоступен оператору за пределами локальной сети, а неверная настройка сигнального адреса мешает ответу вернуться к Asterisk. Поэтому я сравниваю адреса из трассы и SDP отдельно, а не добавляю NAT-параметры одним блоком по чужому рецепту.

• Разделите SIP и RTP
• Сверьте transport и bind
• Проверьте rtpstart и rtpend
• Сузьте правила межсетевого экрана

Закрепите порядок проверки и не теряйте диагностику

Перед изменением конфигурации сохраните копию pjsip.conf, зафиксируйте время сбоя и оставьте только нужный отрезок трассы. Я не публикую полные SIP-логи в тикетах с широким доступом: даже если пароль передан digest-ответом, в заголовках остаются учётные данные в виде имён, телефоны и сетевые адреса. Для разбора достаточно показать запрос, код ответа, заголовок challenge без секретов и то, что произошло при повторе. Это помогает сравнить не только текст ошибки, но и последовательность обмена.

После правки применяйте reload, который поддерживает ваша сборка. pjsip reload может быть CLI alias из cli_aliases.conf, поэтому проверьте, что alias загружен; для перечитывания исходящих регистраций документация Asterisk указывает module reload res_pjsip_outbound_registration.so. Изменённые параметры транспорта требуют полного перезапуска Asterisk, чтобы новые значения вступили в силу. Я заранее согласую окно, особенно если через эту АТС идут разговоры. Затем проверяю регистрацию ещё раз, выполняю контрольный входящий и исходящий вызов и отдельно слушаю обе стороны RTP. Один зелёный статус не подтверждает исправность всего звонка.

Чтобы сбой не повторялся, храните краткую схему: какой endpoint относится к телефону, какой AOR содержит его контакт, где лежит outbound registration и какой auth к ней привязан. После смены реквизитов оператора обновляйте только нужный объект и проверяйте статус после следующего REGISTER. В мониторинге полезно различать Registered и Rejected, а не сводить всё к одной красной лампе. Если регулярно меняются адреса, транспорт или правила NAT, зафиксируйте эти требования рядом с конфигурацией. Ирония тут простая: файл с комментарием «работает, не трогать» не объясняет, почему оно работает. Для проверки после изменения дождитесь новой попытки регистрации, а затем повторите контрольный вызов в обоих направлениях. Если провайдер прислал новый адрес, транспорт или отдельное требование к сроку регистрации, сохраните это рядом с объектом registration, чтобы следующий администратор видел причину, а не только текущее значение.

Если после reload конфигурация не перечиталась, проверьте результат команды и ошибки загрузки в CLI; не переходите сразу к перезапуску всей машины. Разные инсталляции включают разные CLI alias, поэтому сначала убедитесь, что команда существует. Перезапуск именно Asterisk планируйте для изменений транспорта, которые не могут примениться динамически. Снимок настроек до правки упрощает откат.

• Сохраните исходный конфиг и фрагмент трассы
• Перечитайте конфиг подходящим способом
• Для transport запланируйте перезапуск
• Проверьте регистрацию и оба направления звонка

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