Реализация Push и Midregistrar для новичков

В течение длительного времени основное внимание в работе уделялось Asterisk, при этом опыт работы с Kamailio был ограниченным. Ситуация изменилась, когда возникла задача обеспечить связку мобильного приложения с произвольными АТС. Необходимо было реализовать схему доставки вызовов, при этом в исходном задании не оговаривалось, будет ли использоваться Kamailio, OpenSIPS или иное решение.

Проблематика Push-уведомлений в SIP-телефонии

При использовании мобильных приложений одним из ключевых ресурсов является энергия устройства. Современные мобильные операционные системы (iOS и Android) активно останавливают приложения, не позволяя им работать в фоновом режиме и поддерживать постоянное соединение по SIP. Это приводит к тому, что без механизма Push-уведомлений входящий звонок в мобильный клиент доставить невозможно.

Бесплатные мобильные софтфоны, как правило, не имеют встроенной поддержки корректного приёма входящих вызовов именно по этой причине. Для доставки Push необходима внешняя инфраструктура, которая взаимодействует с сервисами Google или Apple и пробуждает клиентское приложение.

Традиционная схема SIP-регистрации усложняется: трафик от мобильного клиента обрабатывается только в момент его пробуждения, а постоянное поддержание NAT-сессий становится ненужным.

Базовая схема работы

В типовом сценарии входящий вызов поступает на Kamailio. Платформа определяет, что вызов должен быть направлен в мобильный клиент, который в данный момент не зарегистрирован. В этом случае отправляется Push-уведомление, после чего Kamailio ожидает SIP-регистрацию от клиента. Как только регистрация получена, вызывается INVITE на устройство.

В рассматриваемой задаче требовалось обеспечить:

• Надёжную доставку вызовов в мобильное приложение.
• Возможность регистрации за одним номером нескольких устройств (мобильных и стационарных).
• Подключение к АТС, конфигурация которой недоступна для изменения.
• Реализацию всей логики на своей стороне, включая форк вызова и обработку Push.

Рассмотренные варианты

Первый вариант предполагал использование UAC на FreeSWITCH. Мобильный клиент регистрировался на Kamailio, который в свою очередь регистрировал UAC на внешней АТС. При отключении клиента регистрация снималась. Однако из-за особенностей работы UAC (разрегистрация и регистрация выполняются асинхронно по таймеру) этот вариант показал нестабильность и был отклонён.

В итоге была реализована схема, отчасти похожая на mid-registrar OpenSIPS с модулем AOR throttling, но с существенными отличиями.

Реализация на Kamailio

Обработка регистрации:

• Регистрация от клиента принимается Kamailio.
• Контакт заменяется на единообразный и отправляется на АТС.
• Контакт сохраняется только после успешного ответа 200 OK от АТС.
• Если устройство определяется как мобильное, информация об этом фиксируется.
• При наличии хотя бы одного мобильного устройства за данным AOR отправляется Push всем связанным клиентам.

Поддержка регистрации
Когда мобильное устройство «засыпает», SIP-регистрация перестаёт обновляться. Push-данные при этом живут дольше SIP-сессии. Для сохранения работоспособности Kamailio самостоятельно формирует и отправляет запросы на регистрацию от своего имени, пока не определит, что устройство больше не требуется обслуживать.

Схема вызова:

• АТС отправляет INVITE на Kamailio.
• Kamailio формирует ветви (branches) для всех зарегистрированных устройств.
• Если среди них есть мобильное — отправляется HTTP-запрос в Push-сервис.
• Одновременно вызовы направляются на активные устройства.
• После получения новых регистраций запускаются дополнительные ветви вызова.

Используемые модули Kamailio

Для реализации логики использовался модуль tsilo (Transaction Storage and Invocation Logic Operations), добавленный в Kamailio около 10 лет назад.
Ключевые функции:

• ts_store — сохраняет текущую транзакцию в хэш.
• ts_append — добавляет новые ветви в активную транзакцию при поступлении регистрации.

Из модуля tmx:

• t_suspend — приостанавливает транзакцию, если в момент вызова нет доступных клиентов.
• t_continue — возобновляет транзакцию при появлении регистрации.

Пример работы

Сценарий с уснувшими мобильными клиентами:

1. Приходит INVITE от АТС.
2. Клиентов нет — транзакция приостанавливается (t_suspend).
3. Отправляется запрос в Push-сервер.
4. Софтфоны пробуждаются и регистрируются.
5. При регистрации вызывается t_continue, отправляется INVITE.

Сценарий с активными устройствами:

1. INVITE от АТС немедленно отправляется на активные устройства.
2. Параллельно отправляется Push на случай появления дополнительных клиентов.
3. При регистрации новых устройств — добавление ветви вызова (ts_append).

В тестовой среде без реального Push-сервера время от получения INVITE до поступления вызова на конечное устройство составляет 4–5 секунд.