Развитие крупного интернет-провайдера рано или поздно упирается в потолок: когда абонентская база переваливает за полмиллиона, классический доступ в интернет становится просто базовой услугой. Чтобы расти дальше, нужно внедрять цифровые сервисы, которые проникают в повседневную жизнь пользователя. Одним из самых удачных направлений в этом плане оказалась умная домофония. Казалось бы, что сложного в том, чтобы пробросить звонок с домофонной панели в мобильное приложение? Однако на практике путь от первого тестового звонка до системы, обслуживающей 22 тысячи панелей и сотни тысяч жильцов, оказался полон неочевидных технических проблем.

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

Почему Asterisk «из коробки» не подошел для масштабирования

В самом начале пути всё выглядело просто: взяли панель Beward, подключили её к Asterisk, настроили мобильное приложение и получили звонок. Всё работало идеально, пока речь шла об одном устройстве. Но как только встал вопрос о подключении тысяч домофонов, стало понятно, что классическая установка Asterisk с прописыванием каждого устройства в конфигурационных файлах — это путь в никуда. Конфиги раздуваются, система становится неповоротливой, а любая перезагрузка превращается в пытку.

Для решения проблемы масштабируемости пришлось разделить уровни управления. На роль фронтенда для обработки SIP-трафика был выбран Kamailio в связке с RTP Engine. Это позволило эффективно проксировать сигнализацию и медиапотоки, не нагружая сервер приложений лишними задачами. Но тут возникла новая проблема, связанная с мобильными устройствами — экономия заряда батареи. Если мобильное приложение будет постоянно держать активную регистрацию на SIP-сервере, смартфон «умрет» за несколько часов.

Решением стала разработка собственного push-сервера. Теперь схема работает так:

• Приложение на смартфоне не висит в памяти постоянно.
• При входящем звонке система отправляет пуш-пакет.
• Приложение «просыпается», за доли секунды регистрируется на сервере и принимает вызов.

Такой подход позволил сохранить автономность телефонов пользователей, но усложнил логику обработки звонка на стороне сервера.

Эволюция бизнес-логики: ARI, Python и переход на Node.js

Когда базовая связь была налажена, пришло время наращивать функционал. Компании требовалось не просто соединять панель с телефоном, а проверять права доступа жильцов, вести статистику, интегрироваться с CRM и записывать разговоры. Изначально всю эту логику пытались реализовать на Kamailio, но этот инструмент предназначен для маршрутизации пакетов, а не для сложного программирования.

В архитектуру вернулся Asterisk, но уже в роли сервера приложений, работающего через ARI (Asterisk REST Interface). Логика была написана на Python с использованием асинхронных библиотек. Система стала гибкой: Asterisk принимает звонок, «спрашивает» у внешней базы данных, в какую квартиру идет вызов и на какие смартфоны нужно отправить пуши, а затем соединяет каналы.

Однако с ростом нагрузки проявились слабые места Python. При плотном потоке звонков возникали задержки до 10 секунд — человек у домофона уже устал ждать, а приложение на телефоне только начинало звонить. Чтобы разобраться в таких тонкостях взаимодействия интерфейсов, инженерам часто требуются профильные курсы по Asterisk, где детально разбираются вопросы производительности ARI.

В итоге всю тяжелую логику переписали на Node.js, объединив разрозненные скрипты в один мощный сервис. Это позволило:

1. Снизить задержки практически до нуля.
2. Обрабатывать до 160 вызовов в секунду на одном сервере.
3. Оптимизировать взаимодействие с RabbitMQ для сбора аналитики в реальном времени.

Интеграция с экстренными службами: «Номерная карусель»

Одной из самых амбициозных задач стала интеграция домофонов с системой 112 (ЕДДС). Городские службы выставили требование: житель должен иметь возможность вызвать диспетчера прямо с домофонной панели, а диспетчер должен видеть точный адрес и иметь возможность перезвонить обратно на панель.

Главная проблема здесь — дефицит телефонных номеров. Панелей 22 тысячи, а свободных городских номеров в три раза меньше. Покупать по номеру на каждый подъезд — экономически нецелесообразно. Для решения этой задачи была придумана система динамического выделения номеров, которую разработчики назвали «номерной каруселью».

Как работает эта логика:

• Когда человек нажимает кнопку вызова 112, система определяет адрес (код ФИАС).
• Из пула свободных номеров выбирается один и на время звонка закрепляется за этим домофоном в базе Redis.
• Вызов уходит в ЕДДС с подставленным городским номером (CallerID).
• Диспетчер видит звонок и понимает, откуда он. Если связь оборвалась, диспетчер перезванивает на этот же номер.
• Система проверяет в Redis, за какой панелью сейчас закреплен этот номер, и мгновенно направляет звонок обратно на домофон.

Через некоторое время после завершения разговора номер освобождается и возвращается в общую «карусель». Это позволило обеспечить полную интеграцию с государственными системами безопасности, используя минимальный ресурс нумерации. При реализации таких схем критически важна защита IP-ATC, чтобы исключить возможность несанкционированного доступа к исходящим линиям и подмены номеров.

Контроль качества и «географические трубки»

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

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

Процесс тестирования выглядит так:

1. Скрипт мониторинга проверяет статус панели через API.
2. Если панель свободна, Asterisk совершает вызов в конкретную квартиру.
3. В SIP-заголовках передаются инструкции для панели: «позвони в квартиру №45».
4. Если жилец поднимает трубку, автоинформатор просит подтвердить качество связи.
5. Все данные (успех, сброс, занято) уходят в CRM.

Такая автоматизация позволила выявлять проблемные участки еще до того, как жители начнут массово жаловаться. Стабильность работы подобных систем во многом зависит от того, насколько качественно выполнен монтаж СКС в самих подъездах, так как плохая медь может свести на нет все преимущества умного софта.

Итоги и масштабы системы

На сегодняшний день проект умной домофонии превратился в огромную экосистему. Цифры говорят сами за себя:

• Обслуживается более 22 000 домофонных панелей.
• В системе зарегистрировано свыше 730 000 пользователей.
• Ежесуточно обрабатывается около 68 000 звонков.
• Пиковые нагрузки достигают 161 CPS (вызовов в секунду).

Весь этот массив данных постоянно анализируется через BigData. Компания видит, в какое время чаще всего возвращаются домой люди, как долго они ждут ответа и насколько стабильно работают мобильные приложения на разных моделях смартфонов. Для обеспечения бесперебойной работы такой распределенной сети требуется грамотное проектирование и настройка сети, учитывающая огромные объемы медиа-трафика.