Дружим VoIP инфраструктуру и мобильное приложение для iOS

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

Жизненный цикл iOS-приложений и проблема SIP-регистрации

iOS жёстко контролирует работу приложений в фоне. Приложение может находиться в нескольких состояниях: не запущено, активно, в фоне или в состоянии suspend. В последнем случае код приложения полностью перестаёт выполняться.
Для SIP-клиента это критично. Чтобы входящий вызов дошёл до пользователя, клиент должен поддерживать SIP-регистрацию. Однако после перехода приложения в suspend регистрация «протухает», и сервер больше не знает, куда отправлять INVITE.
Ранее Apple предоставляла механизм VoIP-сокетов, при котором операционная система сама поддерживала сетевое соединение за приложение. Но начиная с iOS 8 этот механизм был признан устаревшим, и ему на смену пришёл PushKit.

PushKit и VoIP Push как основа решения

PushKit добавил в iOS специальный тип уведомлений — VoIP Push. В отличие от обычных push-уведомлений, такие сообщения:

• не отображаются пользователю
• могут разбудить устройство или вывести приложение из suspend
• доставляются с высоким приоритетом
• позволяют передавать полезную нагрузку большего размера

Однако у этого подхода есть принципиальное отличие от VoIP-сокетов: теперь серверная часть обязана участвовать в процессе пробуждения приложения. SIP-клиент больше не может существовать полностью автономно — ему требуется дополнительная логика на бэкенде.

PushKit и VoIP Push как основа решения

На рынке существует ряд готовых SIP-gateway, которые берут на себя работу с push-уведомлениями. В такой схеме мобильное приложение регистрируется не напрямую в SIP-инфраструктуре, а на gateway, который уже дальше взаимодействует с Asterisk или Kamailio.
Однако у этого подхода обнаружились существенные недостатки:

• закрытая реализация и отсутствие прозрачности
• сложности с масштабированием
• необходимость хранения SIP-логинов и паролей в стороннем сервисе
• невозможность гибко управлять логикой работы приложения в зависимости от передаваемых данных

В результате было принято решение реализовать собственную схему, полностью контролируемую внутри инфраструктуры.

Архитектура собственного решения

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

1. Вызов поступает в Kamailio и передаётся в Asterisk.
2. Asterisk проверяет наличие актуальной регистрации в Redis.
3. Если регистрация есть — вызов маршрутизируется напрямую.
4. Если регистрации нет — Asterisk отправляет запрос в HTTP-бэкенд.
5. Бэкенд решает, поддерживает ли клиент push-уведомления, и при необходимости отправляет VoIP Push через Apple Push Notification Service.
6. Приложение пробуждается, регистрируется в Kamailio, информация появляется в Redis.
7. После этого вызов доставляется на устройство.

Вся процедура регистрации после пробуждения в среднем занимает 2–2,5 секунды, но в отдельных случаях может растягиваться до 10 секунд. Чтобы звонящий не слышал тишину, ему в это время проигрываются гудки вызова.
Для ожидания регистрации используется AGI-скрипт, который через механизм publish/subscribe Redis отслеживает появление нужной информации о клиенте. Как только регистрация обнаружена, вызов продолжается.

Преимущества выбранного подхода

Реализованная схема дала сразу несколько важных преимуществ:

• возможность передавать в push-уведомлениях произвольные данные и управлять логикой приложения
• отсутствие единой точки отказа в виде отдельного gateway
• хорошая масштабируемость — каждая нода инфраструктуры поддерживает необходимую логику
• полная прозрачность происходящего: все этапы можно отследить по логам Kamailio, Asterisk, Redis и AGI-скриптов

В отличие от «чёрных ящиков», система остаётся полностью управляемой и диагностируемой.