Корпоративный видеозвонок выглядит как один клик, но за ним стоит сложная инженерная конструкция. Внутри мессенджера ВКС должна жить рядом с ролями, правами доступа, push-уведомлениями, историями сообщений и интеграциями, а еще — нормально работать в сетях с NAT, firewall и нестабильным качеством соединения.

1. История инцидента

В материале Frisbee* команда описывает не аварийную ситуацию, а путь от простой идеи к полноценной платформе коммуникаций. Сначала разработчики думали, что главная трудность — передача аудио и видео, но быстро увидели, что звонок в корпоративном продукте зависит от десятков соседних механизмов.

Оказалось, что одной видеосвязи мало. Нужны создание комнаты, приглашения, восстановление соединения, контроль прав, масштабирование, запись, расшифровка, вебинары, SIP-телефония и отдельные сценарии для ИИ-агентов. Именно поэтому ВКС пришлось проектировать как часть большой экосистемы, а не как отдельную кнопку «создать встречу».

2. Что пошло не так в защите

Точнее было бы сказать: что ломается, если строить ВКС как монолит. WebRTC* сам по себе решает только транспорт — как передать медиапоток с минимальной задержкой. Но если смешать в одном слое и бизнес-логику, и маршрутизацию медиа, система быстро превращается в трудный для поддержки клубок зависимостей.

Команда разделила архитектуру на два уровня. Control plane управляет жизненным циклом звонка: создает конференцию, подключает и отключает участников, следит за ролями и состояниями. Media plane отвечает за медиапотоки, качество связи и работу с сетевыми ограничениями. Такое разделение помогает менять одну часть системы, не ломая другую.

Дальше встал вопрос масштабирования. P2P хорош для звонка один на один, но плохо выдерживает группу: каждый клиент отправляет поток каждому участнику отдельно, а это бьет по процессору, сети и батарее. MCU снимает часть нагрузки, но сам постоянно декодирует и перекодирует видео, а значит быстро дорожает в эксплуатации.

Финальным выбором стал SFU — Selective Forwarding Unit, то есть узел, который не перекодирует видео, а просто маршрутизирует потоки. Участник публикует свой поток, остальные подписываются только на нужные. Для корпоративной ВКС это разумный компромисс между ценой, скоростью и гибкостью.

Отдельный риск — реальные сети. Пользователь может сидеть в офисе, дома, в поезде или в аэропорту; соединение рвется, сеть меняется, приложение уходит в фон. Поэтому компания сразу заложила поддержку ICE, STUN, TURN и обязательный reconnect, чтобы звонок не падал из-за краткой потери связи.

Не менее важна наблюдаемость. Если система просто говорит, что пользователь «был в звонке», это почти бесполезно. Нужны метрики подключения, маршрут ICE, packet loss, jitter, RTT, факты reconnect и этап, на котором возникла проблема. Без такой диагностики любая ВКС слепнет, а служба поддержки гадает вслепую. О том, как похожие механизмы помогают ловить вредоносную активность и точечно разбирать инциденты, мы уже писали в материале про атаки на аккаунты с passkey через малварь.

3. Уроки для читателя

Главный вывод прост: корпоративная связь — это не только звук и картинка. Это сценарии отказоустойчивости, маршрутизация трафика, контроль доступа, диагностика и готовность к плохим сетям.

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

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

4. Практические выводы и чек-лист

Если у вас корпоративный мессенджер, ВКС или внутренний сервис связи, проверьте базовые вещи уже сейчас:

  • Разделите бизнес-логику и передачу медиа на разные слои.
  • Используйте SFU для групповых созвонов, если важны масштабирование и предсказуемая стоимость.
  • Заранее настройте ICE, STUN и TURN для сложных сетей.
  • Добавьте reconnect как штатный сценарий, а не как аварийный костыль.
  • Сохраняйте технические метрики звонка: задержку, потери, джиттер, маршрут и время подключения.
  • Выносите запись встреч в отдельный модуль с внешним хранилищем.
  • Планируйте агентные сценарии отдельно от ядра ВКС, если нужны расшифровка, модерация или ИИ-помощники.
  • Для сотрудников, которые работают вне офиса, заранее продумайте защиту данных в чужих сетях; для этого может пригодиться инструмент для приватной работы вне офиса.

Итог у этой истории один: хорошая ВКС — это не только про кодек и задержку. Это про архитектуру, которая переживет сбой сети, рост аудитории и новые сценарии бизнеса.

Поделиться: