sip2go: open-source шлюз, который заводит звонки с Android в CRM и АТС

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Мобильная телефония перестаёт требовать VPN и публичного SIP — офисные звонки с личных телефонов сотрудников можно писать и складывать в CRM без сложной инфраструктуры.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Что случилось

На Хабре появился открытый проект Sip2Go: шлюз Sip2Go Gateway плюс Android-клиент Sip2Go. Автор под ником MegaCrash выложил его в хабы Asterisk, Open source и Звук. Охват на момент выдачи сигнала — 46K, заявленное время на прочтение — 6 минут.

Если коротко: смартфон перестаёт быть SIP-клиентом. Он держит WSS/WebSocket-соединение со шлюзом, а шлюз уже подключается к вашей АТС как обычный SIP-endpoint. Всё.

Звучит как техническая мелочь. На деле это ответ на вопрос, который рано или поздно задаёт любой собственник, чьи менеджеры звонят клиентам с личных телефонов: почему эти разговоры не попадают в CRM и не записываются?

Откуда взялась задача

Всё началось с прямого запроса заказчика, которому автор разворачивал офисную телефонию:

А можно нашим сотрудникам поставить на телефоны SIP клиенты, чтобы их разговоры с клиентами проходили через офис, попадали в CRM и записывались?

Логика заказчика прозрачна: поставить софтфон на мобильник, настроить на свой сервер и получить все звонки в контуре компании. Проблема в том, что в реальности это работает откровенно плохо, и автор перечисляет почему.

• Софтфону нужно разрешить постоянную фоновую работу, иначе входящие не приходят. Батарея садится быстро.
• SIP не любит клиентов, у которых внезапно меняется IP. Мобильный телефон меняет его постоянно.
• SIP за NAT — отдельный вид мазохизма. Звук может динамически пропадать на любой из сторон при каждом отдельном вызове.
• Светить SIP-сервер в мир без SBC нехорошо: сканы, брутфорс ботами, а fail2ban вместо защитника порой работает как вредитель.
• Обходной путь через OpenVPN тоже не спасение: туннель регулярно отваливается, а через мобильный интернет иногда вообще отказывается работать.

Знакомая картина для тех, кто пробовал завести мобильную телефонию в SMB. Именно на этом этапе большинство проектов «звонки с личных телефонов в CRM» тихо умирает: технически возможно, эксплуатационно — боль.

Что именно придумали

Идея проекта сформулирована прямо:

Суть задумки была в том, чтобы избавиться сразу от всех проблем SIPа на смартфоне, заставив голосовую связь работать точно так же, как она работает у мессенджеров. В Sip2Go телефон вообще не является SIP‑клиентом.

Схема выглядит так. Android-приложение соединяется с Sip2Go Gateway по WSS/TLS. Шлюз, в свою очередь, общается с АТС по обычному SIP/RTP. SIP-стек целиком остаётся на сервере, где он гарантированно работает. Мобильное устройство разговаривает с сервером защищённым WebSocket-соединением.

Почему именно WebSocket, а не что-то ещё? Автор перечисляет требования к транспорту: работать сквозь NAT, обходить кривые хелперы вроде SIP ALG, выглядеть как обычный HTTPS, стабильно удерживать двустороннее соединение, одинаково годиться и для управляющих сообщений, и для аудио. WebSocket закрывает всё это разом. Он работает через любой веб-сервер в режиме реверс-прокси, вплоть до Cloudflare.

Для АТС шлюз — просто ещё один SIP-endpoint. Никаких специфических настроек на её стороне не требуется. Это ключевой момент: Sip2Go не превращает вашу PBX в экспериментальную лабораторию, а добавляется отдельным слоем поверх существующей телефонии.

Как это работает на практике

Исходящий звонок

Пользователь жмёт «позвонить» в приложении. Android отправляет запрос через WebSocket на шлюз. Шлюз сам формирует SIP INVITE в сторону PBX. Дальше всё как обычно.

Входящий звонок

Тут интереснее. Когда на номер приходит вызов, PBX передаёт его шлюзу как своему абоненту. Шлюз отправляет в PBX прогресс звонка, а параллельно будит приложение push-уведомлением через FCM и ждёт, пока клиент подключится. Приложение не обязано постоянно висеть на сессии и ждать звонка: шлюз держит статус RINGING до тех пор, пока клиент не примет вызов или не наступит таймаут. Механика как у мобильных операторов.

Кодеки

На стороне PBX всё остаётся в привычном мире SIP: PCMU/PCMA (ulaw/alaw). На стороне мобильного устройства аудио кодируется в Opus и идёт через WebSocket. Шлюз работает транскодером между этими двумя мирами. Мобильному приложению не нужно реализовывать весь зоопарк SIP/RTP/NAT traversal — достаточно собственного небольшого протокола общения со шлюзом.

Восстановление связи

Разрыв может случиться по любой причине: смена IP при переключении между сетями, полное закрытие приложения. Если связь потеряна в момент, когда звонок уже поступил, приложение не считает, что ничего не было. После рестарта, как только оно снова подключится к шлюзу, тот сообщит о наличии активной сессии и попытается её возобновить, не роняя вызов. Время на попытки восстановления настраивается на стороне шлюза. Если восстановить связь не удалось — шлюз отправляет в АТС Bye.

Чем отличается от того, что было раньше

Сравним сценарии, которые SMB пробует до Sip2Go.

Отдельно про настройку. Автор сделал подключение по аналогии с eSIM: отсканировал одноразовый QR или кликнул одноразовую ссылку — и ты в сети. Это моментально снимает необходимость сопровождать каждого пользователя руками. Для компании с десятком менеджеров это разница между «раскатали за час» и «неделю объясняли, куда вводить пароль».

Кому это нужно

Первый и главный сценарий — тот самый запрос из начала статьи. У вас есть офисная АТС, есть CRM, и есть сотрудники, которые звонят клиентам с личных телефонов. Вы хотите, чтобы эти разговоры шли через офис, писались и падали в CRM. Sip2Go закрывает именно эту задачу.

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

Третий — руководитель, которому нужна связь с офисом с личного телефона. У автора такой пользователь был одним из первых: руководитель предприятия, которое он обслуживает. До этого использовалась схема SIP-клиент поверх OpenVPN, и периодическая диагностика глюков этой связки, по признанию автора, однажды прилично достала.

Что нужно на стороне инфраструктуры: FreePBX, Asterisk, проприетарная коробка или SIP-провайдер — шлюзу без разницы. Он подключается как обычный SIP-клиент.

Где подвох

Честно о том, что стоит знать до того, как бежать разворачивать.

• Множественной регистрации нет. Если работать через регистрацию, получится прокинуть только один endpoint. Для нескольких абонентов шлюз нужно подключать в режиме транка с авторизацией по IP и маршрутизировать в его сторону вызовы на номера всех подопечных. Удобный вариант — выделить мобильным клиентам отдельный пул внутренних номеров, например 7XXX.
• Push-пробуждение через FCM. Это значит, что приложение завязано на Firebase-аккаунт. Для самостоятельной сборки нужно привязать свой.
• Android. Клиент под Android. Про iOS в материале речи нет.
• Сборка и развёртывание — на вас. Это open-source, а не коробочный продукт с поддержкой по SLA. Если у вас нет человека, который умеет это собрать и обслуживать, придётся его найти или нанять.

Про цену:

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

То есть бесплатно — да, но при условии, что вы сами собираете приложение под свой Firebase. Это не «скачал из маркета и забыл».

Вердикт за 30 секунд

• Брать, если у вас есть офисная АТС и задача завести звонки с мобильных в CRM и на запись, а также есть человек, способный собрать и обслуживать шлюз.
• Подождать, если вам нужен коробочный продукт с поддержкой, iOS-клиенты или несколько абонентов на одной регистрации без возни с транком.
• Не подходит, если у вас нет ни инфраструктуры телефонии, ни технического ресурса на самостоятельную сборку.

FAQ

Нужно ли что-то менять в моей АТС?

Нет. Шлюз подключается как обычный SIP-endpoint. Подходит для FreePBX, Asterisk, проприетарных коробок и SIP-провайдеров.

Нужен ли VPN?

Нет. Транспорт — WSS/TLS через WebSocket, работает за реверс-прокси, вплоть до Cloudflare, и выглядит как обычный HTTPS.

Что с батареей телефона?

Приложение не обязано постоянно висеть на сессии. Шлюз держит вызов в статусе RINGING и будит приложение push-уведомлением через FCM.

Что будет, если связь пропала во время звонка?

После повторного подключения шлюз сообщит о наличии активной сессии и попытается её возобновить, не роняя вызов. Время на попытки настраивается на стороне шлюза. Если восстановить не удалось — шлюз отправляет в АТС Bye.

Сколько это стоит?

Весь функционал бесплатен при самостоятельной сборке приложения с привязкой к своему аккаунту Firebase.

Можно подключить несколько сотрудников?

Да, но не через множественную регистрацию. Шлюз подключается транком с авторизацией по IP, вызовы на номера сотрудников маршрутизируются в его сторону. Удобно выделить отдельный пул внутренних номеров, например 7XXX.

Что делать дальше

Если задача «звонки с мобильных в CRM и на запись» у вас в списке — Sip2Go стоит как минимум изучить. Он снимает главную боль мобильной телефонии: необходимость держать SIP-клиент на телефоне, воевать с NAT и светить SIP-сервер в интернет.

Но трезво оцените ресурс. Это open-source-проект, а не готовый сервис. Сборка, развёртывание, настройка транка, свой Firebase-аккаунт — всё это на вас. Если внутри компании есть человек, который это потянет, — попробуйте на одном отделе, прежде чем раскатывать на всех. Если нет — сначала найдите такого человека, потом возвращайтесь к проекту.