PJSIP для чайников

В рамках доклада рассматривался практический переход от ChanSIP к PJSIP в Asterisk — не с точки зрения «как переписать конфиг», а с точки зрения понимания архитектуры, логики работы и причин, по которым PJSIP устроен именно так. Основной акцент был сделан на регистрации у операторов связи, приёме и отправке вызовов, а также на том, как в PJSIP меняется сам подход к описанию SIP-сущностей.
ChanSIP и PJSIP решают одни и те же задачи: регистрация, приём входящих INVITE, отправка исходящих вызовов и маршрутизация звонков. Однако делают они это принципиально разными способами, и именно это различие чаще всего вызывает сложности при переходе.

Регистрация у оператора связи в ChanSIP

В ChanSIP регистрация у оператора связи выглядит достаточно просто и привычно. Как правило, она осуществляется либо через строку register в секции General, либо через механизм callback extension. В обоих случаях Asterisk отправляет REGISTER-запрос на указанный сервер, используя логин и пароль, а также номер (DID), который затем попадает в поле Contact.
С точки зрения ChanSIP, строка регистрации одновременно описывает сразу несколько вещей: адрес сервера, учётные данные и номер, на который оператор будет присылать входящие вызовы. Всё это находится в одном месте, что упрощает начальную настройку, но ограничивает гибкость.

Общий принцип PJSIP: разделение сущностей

Первое и самое важное отличие PJSIP заключается в том, что здесь отсутствует единая универсальная секция, описывающая всё сразу. Вместо этого каждая логическая сущность выносится в отдельную секцию, а связи между ними строятся через ссылки.

Это ключевая концепция PJSIP, и именно её необходимо принять, чтобы дальнейшая настройка стала понятной. Регистрация, транспорт, авторизация, адрес назначения, логика приёма входящих пакетов — всё это независимые сущности, которые могут переиспользоваться и комбинироваться.

Регистрация в PJSIP

Для регистрации у оператора в PJSIP создаётся отдельная секция с типом registration. Эта секция описывает только сам факт регистрации и больше ничего. В ней указывается, через какой транспорт отправлять REGISTER, какие авторизационные данные использовать, какой user подставлять в Contact и на какой сервер отправлять запрос.
Важно подчеркнуть, что регистрация в PJSIP не является сущностью, через которую совершаются звонки. Она выполняет единственную задачу — уведомить оператора о том, где находится Asterisk и куда ему присылать INVITE.

Транспорты как отдельная сущность

В ChanSIP параметры прослушивания SIP-трафика задавались глобально: bindaddr, bindport и связанные с ними настройки применялись ко всему модулю. В PJSIP транспорт выносится в отдельную секцию.
Это позволяет создавать несколько транспортов одновременно — например, UDP и TCP, разные интерфейсы, разные сценарии работы с NAT. Регистрация и endpoint просто ссылаются на нужный транспорт по имени. Такой подход значительно повышает гибкость и позволяет реализовывать сложные сетевые схемы без глобальных ограничений.

Авторизация как самостоятельный объект

Ещё одно важное отличие — работа с учётными данными. В ChanSIP логин и пароль указывались прямо в peer. В PJSIP авторизация выносится в отдельную секцию с типом auth.
Эта секция может использоваться сразу в нескольких местах: как при регистрации у оператора, так и при отправке исходящих вызовов через endpoint. Таким образом, авторизационные данные становятся переиспользуемым объектом, а не частью конкретной линии.

Параметр line и идентификация регистраций

В ChanSIP входящие INVITE от оператора идентифицируются, по сути, только по номеру, указанному в Contact. Это создаёт сложности при наличии нескольких регистраций с одинаковым DID.
PJSIP решает эту проблему через параметр line, который добавляется в Contact при регистрации. Значение этого параметра генерируется автоматически и возвращается оператором в каждом INVITE. Благодаря этому Asterisk может точно определить, к какой регистрации относится входящий вызов, даже если используется один и тот же номер.
Это открывает возможности для более сложной маршрутизации, использования нескольких регистраций и нестандартных сценариев работы с операторами связи.

Перезагрузка и диагностика

В отличие от ChanSIP, в PJSIP отсутствует команда «pjsip reload» в привычном виде. Для применения изменений требуется перезагрузка соответствующих модулей, причём не всегда одного. На практике это решается созданием alias с нужным набором reload-команд.
Для проверки состояния регистраций предусмотрены отдельные команды, позволяющие получить как краткий список, так и подробную информацию. Это упрощает мониторинг и диагностику.

Регистрация не равна возможности звонить

Отдельно подчёркивалось, что регистрация у оператора не даёт возможности совершать вызовы. Она лишь сообщает оператору, куда отправлять входящие INVITE. Для приёма и отправки вызовов в системе должна существовать сущность, через которую эти вызовы обрабатываются.
В ChanSIP такой сущностью был peer. В PJSIP её аналогом является endpoint.

Приём входящих вызовов

В ChanSIP для приёма INVITE от оператора связи обычно используется идентификация по IP-адресу с отключённой авторизацией. Это необходимо, поскольку оператор не ожидает, что его будут запрашивать на авторизацию.
В PJSIP эта логика реализуется через связку endpoint и identify. Секция identify определяет, какому endpoint относится входящий SIP-пакет, чаще всего на основе IP-адреса отправителя. Сам endpoint задаёт контекст диалплана, кодеки и другие параметры обработки вызова.
PJSIP предоставляет значительно больше вариантов сопоставления входящих INVITE: по IP, по имени, по заголовкам SIP, по параметру line, по полю From или через специальный anonymous endpoint. Это делает модуль заметно гибче по сравнению с ChanSIP.

Исходящие вызовы и роль AOR

Для отправки исходящих вызовов в PJSIP требуется дополнительная сущность — AOR (Address of Record). Она определяет адрес, на который будут отправляться INVITE при исходящем вызове.
В ChanSIP эту роль выполняло поле host. В PJSIP адрес назначения выносится в AOR, что снова подчёркивает общий принцип разделения ответственности. Endpoint определяет логику вызова, авторизацию и кодеки, а AOR — конкретный адрес доставки SIP-запросов.
Без AOR входящие вызовы могут работать, но исходящие — нет, так как системе просто некуда отправлять INVITE.

Архитектура PJSIP в целом

В центре всей схемы находится endpoint — основная сущность, через которую происходят вызовы. С ним связаны транспорт, авторизация, AOR и identify. Регистрация, в свою очередь, также использует транспорт и авторизацию, но не участвует напрямую в обработке звонков.
Такой подход может показаться сложным на старте, однако он даёт гораздо более прозрачную и расширяемую архитектуру, особенно в сложных и нагруженных системах.