Разработка мобильного WhiteLabel-софтфона для операторов связи

Доклад посвящен опыту команды разработки компании «Видисофт» в создании мобильного white-label софтфона. На предыдущих конференциях неоднократно звучал вопрос: почему у компании нет мобильного приложения для звонков. Сейчас можно с уверенностью сказать — работа над ним ведется, и уже есть результаты.

Команда разработки сосредоточилась на создании мобильного софтфона, ориентированного на корпоративных пользователей, в том числе для использования в колл-центрах. Существуют бесплатные решения, такие как MicroSIP, однако они не покрывают сценарии, требующие интеграции с CRM, отображения карточек клиентов и прочего функционала, необходимого бизнесу. Более того, важно обеспечить наличие документации, базы знаний, технической поддержки — тех элементов, которые позволяют продукту быть полноценным и востребованным.

Одной из причин начала разработки стал постоянный интерес со стороны клиентов к комплексному решению — как для десктопа, так и для мобильных устройств. При этом нередко поступали запросы на кастомизацию с фирменным стилем заказчика. Концепция white-label здесь становится очевидным выбором.

White-label в телеком-приложениях

White-label предполагает, что одна и та же технологическая основа (в данном случае — софтфон) может быть переупакована под бренд клиента. Это аналогично тому, как один и тот же автомобиль продается под разными марками или как одно и то же моторное масло — под разными этикетками. В нашем случае — основа одна, интерфейс и брендинг подстраиваются под заказчика.

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

Архитектура и выбор технологий

Перед командой стояло несколько ключевых вопросов:

• На чем реализовать приложение?
• Какие библиотеки использовать?
• Как решить проблему усыпления процесса?

Ранее в «Видисофт» уже был опыт разработки кроссплатформенного десктоп-приложения с использованием Qt, единая кодовая база поддерживалась для Windows, macOS и с недавнего времени — Linux. Возникла идея перенести этот опыт в мобильную разработку.

В рамках исследования были изучены решения, применяемые в популярных мессенджерах и VoIP-клиентах. Так, Telegram использует фрагменты WebRTC, WhatsApp — набор open-source библиотек, включая PJSIP. В ряде других приложений прослеживается смешанная архитектура: часть кода пишется с нуля, часть заимствуется из открытых решений.

Изучались также языки программирования: Telegram и WhatsApp используют Java/Kotlin для Android и Swift для iOS. В случае с ZoiPer и Crank — архитектура менее очевидна, но прослеживаются нативные подходы.

Были протестированы различные варианты реализации:

• Кроссплатформенные фреймворки: React Native, Flutter, Qt.
• Нативные решения: Kotlin (Android), Swift (iOS).

React Native был отброшен — несмотря на возможность собрать работающий прототип, он оказался громоздким по зависимостям и требовал значительных усилий на доведение до приемлемого уровня. Flutter показал себя нестабильно, особенно при интеграции с SIP-стеком, что также не соответствовало требованиям проекта.

Вариант с Qt был ближе по духу и опыту команды, однако даже при схожем объеме трудозатрат по сравнению с Kotlin результат выглядел менее зрелым. Разработка интерфейсов требовала большего количества правок, и кроссплатформенность не дала ощутимого выигрыша — напротив, выросли накладные расходы на поддержку специфических кейсов.

Push Proxy как решение проблемы усыпления

Одна из ключевых архитектурных задач — обеспечение стабильной SIP-регистрации и прием входящих вызовов, даже когда приложение выгружается системой. Для этого было принято решение использовать push-proxy — промежуточный сервер, который держит SIP-регистрацию от имени клиента. При поступлении входящего вызова прокси генерирует push-уведомление, приложение пробуждается и обрабатывает звонок.

Это решение позволяет обходить системные ограничения платформы, снижает нагрузку на батарею устройства и обеспечивает надежную доставку звонков.

Промежуточные итоги

На текущий момент:

• Реализован рабочий прототип мобильного SIP-клиента.
• Внедрен push-прокси для устойчивой регистрации.
• Приложение обрабатывает входящие и исходящие вызовы.
• Идет работа над интерфейсом, контакт-листом, историей вызовов.

Цифры проекта

Разработка велась с начала года. Потрачено более 5000 человеко-часов. Примерно половина времени ушла на исследование технологий и выбор архитектурных решений. Для сравнения, первая версия десктопного клиента потребовала в три раза больше ресурсов. Работа над мобильным клиентом еще не завершена, но есть уверенность, что итоговые трудозатраты будут сопоставимы.