Как SIP-домофония ломалась на переходе между Wi‑Fi и LTE

Интегрировали Asterisk в PDP Mobile для цифровой домофонии и просмотра камер жильцами: SIP-клиент регистрируется в приложении, вызовы проходят через Asterisk, видео с камер отдаётся HLS-стримом.

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

Проблемы начались там, где мобильная связь обычно напоминает о себе: телефон ушёл в фон, Wi‑Fi сменился на LTE, сеть пропала на несколько секунд и вернулась.

Что ломалось на тестах

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

Отдельно проверяли HLS. Поток камер нужен не для архива, а для текущей ситуации у подъезда или во дворе. Поэтому «картинка когда-нибудь догрузится» не подходит. Если соединение рвётся или телефон переключается между Wi‑Fi и LTE, плеер не должен зависать в состоянии вечной загрузки. Ему нужно понять, что поток надо переоткрыть.

С картой камер в админке был похожий риск, но уже для оператора. При инциденте важна скорость выбора ракурса: дом, подъезд, камера. Если поток зависает после сетевого сбоя, оператор видит старый кадр и думает, что камера работает. Это хуже явной ошибки.

Где сначала копали не туда

Первым подозреваемым стал Asterisk. Когда рядом SIP-регистрация, вызовы и сессии, рука сама тянется смотреть логи телефонии: REGISTER, INVITE, состояние диалога, таймауты. Там действительно есть что проверять, но часть кейсов не объяснялась только серверной стороной.

Потом смотрели на HLS отдельно: плейлист, сегменты, поведение плеера при обрыве. Тоже полезно, но картина всё ещё была рваной. SIP и HLS жили как две независимые подсистемы, хотя для жильца это один сценарий: ему звонят в домофон, он видит видео и принимает решение.

Живая деталь: один и тот же тест проходил на офисном Wi‑Fi и разваливался при выходе из здания, когда телефон перескакивал на LTE. В логах это выглядело не как «сломалась домофония», а как несколько маленьких событий в разное время: сеть сменилась, приложение получило другой lifecycle, плеер потерял поток, SIP-сессия осталась в старом состоянии.

Что оказалось причиной

Причина была на стыке мобильного lifecycle и сетевых сессий.

SIP-клиент, вызов и HLS-плеер нельзя вести так, будто сеть постоянная, а приложение всегда на экране. Для веб-интерфейса такая модель иногда терпима. Для мобильного домофона — нет: пользователь может свернуть приложение, принять другой звонок, выйти из лифта, потерять Wi‑Fi у подъезда и вернуться в LTE уже во время вызова.

Мы разделили состояния, которые раньше легко смешивались:

• регистрация SIP-клиента;
• активный вызов и его сессия;
• состояние приложения: активное, фон, возврат;
• состояние сети: есть соединение, потеря, смена Wi‑Fi/LTE;
• состояние HLS-потока: играет, буферизуется, требует переоткрытия.

После этого стало проще писать обработчики. Если меняется сеть — проверяем регистрацию SIP и состояние текущего вызова. Если приложение вернулось из фона — не считаем старую картинку живым видео, а валидируем поток заново. Если HLS завис на старом соединении — переоткрываем просмотр, вместо того чтобы ждать бесконечной буферизации.

Что поменяли в реализации

В интеграции Asterisk оставили явную работу с регистрацией SIP-клиента, управлением вызовами и сессиями. На мобильной стороне добавили обработку граничных сценариев: потеря связи, переход приложения в фон, возврат, переключение между Wi‑Fi и LTE.

Для камер закрепили отдельный сценарий восстановления HLS-стрима. Важно было не смешивать его с самим SIP-вызовом: видео может временно пропасть, но это не всегда значит, что надо ронять звонок. И наоборот: успешный SIP-вызов не гарантирует, что камера сейчас отдаёт живой поток.

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

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