Представьте: гость нажимает кнопку домофона, и ваш телефон мгновенно звонит, показывая видео с камеры. Одним тапом вы открываете дверь. За этой простотой — сложный инженерный пазл: WebRTC или SIP-стек, протокол ONVIF, push-уведомления с задержкой менее секунды при закрытом приложении, управление реле замка через API устройства и запись событий. Мы разрабатываем мобильные приложения для домофонов «под ключ», от выбора архитектуры до публикации в App Store и Google Play. Типичный проект занимает от 4 до 12 недель в зависимости от совместимости оборудования и требований к мультиквартирности.
Рассмотрим типовую ситуацию: в многоквартирном доме требуется единое приложение для жильцов, которое маршрутизирует звонок от домофона конкретного подъезда к нужной квартире. При этом важно обеспечить видеозапись событий, поддержку гостевых QR-кодов и интеграцию с существующей системой контроля доступа. Наша команда имеет 10+ лет опыта в разработке embedded и мобильных решений, поэтому мы гарантируем сжатые сроки и прозрачную отчётность.
Почему выбор протокола важен?
Первый вопрос при проектировании — тип домофонного оборудования. От него зависит, какой протокол видеосвязи использовать.
Готовые IP-домофоны с SIP — разработка мобильного приложения
Устройства вроде Hikvision DS-KV6113, Grandstream GDS3710, Beward DS06M поддерживают SIP и ONVIF. Телефон регистрируется на Asterisk/FreeSWITCH как SIP-клиент. Входящий вызов с домофона → SIP INVITE → сервер → push на телефон → CallKit (iOS) / ConnectionService (Android).
Кастомный домофон на одноплатнике
Используем Raspberry Pi, ESP32-S3 или NXP i.MX — стек выбираем сами. WebRTC через Pion (Go) или aiortc (Python) на устройстве, сигнализация через WebSocket на наш сервер, затем мобильный клиент.
Облачный домофон
Проприетарные решения (Ring, Dahua, Hikvision EZVIZ) предоставляют P2P SDK. Интеграция быстрая, но ведёт к vendor lock-in.
Как обеспечить доставку звонка за доли секунды?
Задержка уведомления критична: гость у двери. На iOS правильный путь — APNs VoIP push с PKPushRegistry и PKPushType.voIP. Система будит приложение немедленно, даже при Force Quit, и через CXProvider показывает нативный интерфейс звонка. Согласно документации CallKit, это стандартный подход для VoIP-приложений.
let update = CXCallUpdate() update.remoteHandle = CXHandle(type: .generic, value: "Дверь подъезда") update.hasVideo = true update.localizedCallerName = "Домофон" provider.reportNewIncomingCall(with: callUUID, update: update) { error in ... } APNs VoIP-сертификат отдельный от push-сертификата. Не забудьте voip в UIBackgroundModes в Info.plist.
На Android используется ConnectionService + FCM с высоким приоритетом (priority: high). TelecomManager.addNewIncomingCall() показывает системный звонок. Проблема: на Xiaomi, Huawei, OPPO агрессивные battery optimisations убивают FCM-соединение. Решение — JobScheduler keepalive + инструкция пользователю добавить приложение в исключения. Для Huawei используем HMS Push.
Для кроссплатформенных проектов (Flutter) применяем flutter_callkit_incoming и firebase_messaging — нативные биндинги к CallKit и ConnectionService.
WebRTC-видеосвязь
После ответа на звонок устанавливается WebRTC peer connection. Сигнализация: обмен SDP через наш WebSocket-сервер (или Asterisk с WebSocket транспортом для SIP/WebRTC). ICE кандидаты собираются через STUN, для NAT traversal — TURN (Coturn). Видео с камеры домофона рендерится в RTCMTLVideoView (Metal, iOS) или SurfaceViewRenderer (Android). Аудио — RTCAudioTrack. AEC (echo cancellation) встроен в WebRTC — критично, чтобы не было эха через колонку домофона. Задержка видео: 150-400 мс на Wi-Fi, 400-800 мс на 4G — приемлемо для принятия решения «открыть/не открыть».
Сравнение протоколов: SIP-стек подходит для стандартных IP-домофонов, но WebRTC обеспечивает в 3-5 раз меньшую задержку видео благодаря прямому P2P-соединению.
Управление замком
HTTP или MQTT запрос к устройству или серверу: POST /api/unlock или publish("home/door/unlock", "1"). Подтверждение открытия через сенсор двери (опционально): событие OPEN отображается в приложении. Кнопка «Открыть» активна только во время звонка — после завершения скрывается. Лог событий: каждый звонок, открытие, отказ пишутся в БД с timestamp и userId.
Видеозапись событий
Запись видео при каждом звонке (ringback recording): медиасервер (Janus record plugin, Ant Media) пишет поток в WebM/MP4. Хранение в S3/MinIO с ретенцией последних 30 событий или 7 дней (lifecycle rule). Мобильный клиент показывает историю: timeline с превью первого кадра, длительностью и кнопкой воспроизведения через AVPlayer / ExoPlayer из S3 presigned URL.
Мультиквартирный дом
Несколько подъездов, несколько квартир. Маршрутизация: домофон подъезда 3 звонит только жильцам квартир в подъезде 3. В Asterisk: dialplan с Dial(SIP/apartment_${EXTEN}). Каждая квартира — отдельный SIP-аккаунт. В приложении пользователь привязан к аккаунту своей квартиры. Гостевой доступ: владелец выдаёт временный QR-код с ограниченным сроком действия.
Как работает маршрутизация в многоквартирном доме
Каждый домофон подъезда имеет уникальный SIP-номер. При нажатии кнопки вызова домофон отправляет INVITE с номером квартиры (DTMF). Asterisk преобразует DTMF в номер SIP-аккаунта квартиры. Если звонок не принят, включается переадресация на мобильное приложение через VoIP push. В случае неудачи записывается видео и отправляется уведомление.Пошаговый процесс интеграции домофона
- Аудит оборудования — анализ протоколов домофона, поддержка ONVIF/SIP, возможности релейного выхода.
- Проектирование архитектуры — выбор стека (SIP vs WebRTC), серверной части, СУБД.
- Разработка серверной части — Asterisk/WebRTC-сервер, REST API для приложения, MQTT-брокер.
- Разработка мобильного клиента — iOS (Swift + CallKit) и Android (Kotlin + ConnectionService) с видео, управлением замком, историей.
- Интеграция и тестирование — стенд с реальным домофоном, проверка задержек, сценариев ошибок.
- Публикация в App Store и Google Play — настройка provisioning profiles, code signing, push-сертификатов.
Этапы разработки
| Этап | Содержание | Срок |
|---|---|---|
| Аудит оборудования и архитектура | Протоколы устройства, выбор стека | 3-5 дней |
| Серверная часть | Asterisk/WebRTC-сервер, API | 1-2 недели |
| Мобильный клиент iOS + Android | CallKit, видео, управление замком | 2-3 недели |
| Запись событий и история | S3, плеер, лог | 1 неделя |
| Тестирование на железе | QA на реальном домофоне | 1 неделя |
Итого от 1 до 3 месяцев в зависимости от сложности и мультиквартирности.
Сравнение вариантов оборудования
| Тип | Протокол | Сложность | Задержка видео | Vendor lock-in |
|---|---|---|---|---|
| SIP-домофон | SIP + ONVIF | Средняя | 200-500 мс | Нет |
| Кастомный (RPi) | WebRTC | Высокая | 150-400 мс | Нет |
| Облачный (Ring/Dahua) | P2P SDK | Низкая | 300-600 мс | Да |
Что входит в работу
По завершению проекта вы получаете:
- Исходный код мобильного приложения (iOS/Android) с комментариями
- Собранные IPA/APK и настройки для публикации
- Серверную часть (если требуется) в Docker-контейнерах
- Документацию API и инструкцию по развёртыванию
- 1 месяц технической поддержки после сдачи
- Код выложен в приватный Git-репозиторий
Если вы хотите оценить свой проект, напишите нам — мы подготовим предварительную архитектуру и смету в течение 2 рабочих дней.