- Дата публикации
Как оживить SIP-телефонию на Android: реальный опыт с push-уведомлениями
Что появилось / что изменилось
Мобильные ОС давно научились агрессивно экономить батарею. Android приостанавливает неактивные приложения, рвёт их постоянные TCP-сессии и не даёт будить себя таймерами или входящим трафиком. Для классического SIP-клиента это критично: смартфон заблокирован — входящий INVITE не доезжает, звонок просто не приходит.
RFC 3261, который описывает SIP, вышел ещё в 2002 году. Тогда никто не думал о том, что клиент может жить в «замороженном» состоянии. Рынок это догнал только в мае 2019 года, когда появился RFC 8599 (SIP PUSH). Он формализовал работу SIP-клиентов через сервисы push-уведомлений (Push Notification Service, PNS).
Что изменилось по факту:
- SIP-клиент больше не держит постоянное TCP-подключение, когда Android его «усыпляет».
- Для пробуждения приложения и приёма звонка используется PNS.
- Push-уведомление может не только разбудить приложение, но и передать полезные данные.
- Для Android и iOS используются закрытые PNS: Firebase Cloud Messaging (FCM) и Apple Push Notification service (APNs).
- Для открытых сценариев есть стандарт по RFC 8030, но массовые мобильные клиенты на Android и iOS всё равно завязаны на FCM и APNs.
Автор материала построил тестовую архитектуру телефонии под Android с использованием push-уведомлений и проверил, что SIP-клиент может стабильно принимать вызовы, даже когда система его приостанавливает.
Как это работает
Логика теперь такая: между SIP-сервером и телефоном появляется ещё один обязательный участник — PNS.
- Регистрация. SIP-клиент на Android регистрируется на SIP-сервере и параллельно получает токен от FCM.
- Связка SIP и PNS. Клиент передаёт на SIP-сервер информацию о своём PNS-токене. Сервер понимает, через какой PNS и на какой токен нужно стучаться.
- Смартфон засыпает. Android приостанавливает приложение, рвёт постоянные TCP-сессии. Прямой приём INVITE уже не работает.
- Входящий звонок. Когда на номер прилетает вызов, SIP-сервер по RFC 8599 генерирует push-запрос и отправляет его в PNS (для Android — в FCM).
- Push доезжает до устройства. FCM доставляет уведомление на смартфон, Android будит приложение телефонии.
- Приложение поднимается и забирает звонок. Клиент просыпается, устанавливает SIP-сессию с сервером и уже по нормальному SIP-потоку обрабатывает INVITE и медиа.
PNS тут выполняет одну ключевую функцию — гарантированно разбудить приложение, которое само не может инициировать сетевую активность из спящего режима. В push-пакет можно положить минимум данных (например, идентификатор звонка), а уже после пробуждения клиент дотянет остальное по SIP.
Что это значит для вас
Если вы делаете корпоративную телефонию или контакт-центр с мобильными клиентами на Android, жить без push-уведомлений уже не получится. Постоянные TCP-сессии в фоне Android просто не даст держать — входящие звонки будут теряться.
Когда имеет смысл внедрять PNS:
- У вас есть SIP-клиент под Android, который должен принимать звонки при заблокированном экране.
- Сотрудники работают вне офиса: курьеры, выездные инженеры, продажи в полях.
- Вы хотите, чтобы смартфон не разряжался за полдня из-за постоянного SIP-подключения.
Где PNS не нужен:
- Настольные SIP-телефоны и софтфоны на ПК, которые работают в онлайне и не «замораживаются» ОС.
- Внутренние тестовые стенды, где устройство постоянно подключено к питанию и не уходит в глубокий сон.
С чем придётся смириться:
- Вы становитесь зависимы от FCM (для Android) или APNs (для iOS). Без доступа к этим сервисам нормальная работа мобильной телефонии невозможна.
- Придётся доработать и сервер, и клиент. SIP-сервер должен уметь хранить PNS-токены и отправлять push-запросы по RFC 8599.
- Архитектура усложняется: появляется ещё одна критичная точка отказа — PNS.
Если ваш продукт ориентирован на Россию, нужно учитывать возможные ограничения доступа к FCM и APNs. Для корпоративных сценариев это часто решают через VPN или прокси-инфраструктуру. Без такого обхода push-уведомления могут работать нестабильно или не работать вообще.
Место на рынке
SIP с push-уведомлениями — это не отдельный коммерческий продукт, а архитектурный паттерн, который привязан к стандартам RFC 3261, RFC 8030 и RFC 8599.
Реальные альтернативы для Android-клиентов немногочисленны:
- Чистый SIP без PNS. Проще в реализации, но на Android не выдерживает требований к надёжности входящих звонков и к расходу батареи.
- Проприетарные VoIP-решения без SIP, где клиент и сервер контролируются одной компанией. Там push-уведомления тоже используются, но протоколы закрыты.
По сравнению с «голым» SIP-стеком архитектура с PNS даёт:
- Приём вызовов в спящем режиме смартфона, что невозможно без push.
- Меньший расход батареи за счёт отказа от постоянных TCP-сессий.
Обратная сторона — зависимость от FCM и APNs и необходимость поддерживать ещё один протоколный слой. Для тех, кто строит телефонию вокруг открытых стандартов и хочет контролировать архитектуру, связка SIP + PNS по RFC 8599 сейчас фактически стала базовой опцией для Android-клиентов.