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

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

В этой статье разбираем архитектуру Frisbee Meet и рассказываем, какие решения мы приняли по ходу разработки: почему остановились на WebRTC и SFU, как устроены control plane и media plane, зачем понадобился агентский фреймворк, как работают запись и ИИ-обработка встреч, каким образом мы встроили SIP, модерацию и вебинарный режим и что делаем, когда у пользователя внезапно пропадает звук или ухудшается качество связи.

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

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

Есть и другая сторона — инфраструктура, которую разработчик не контролирует полностью. Сотрудник может подключиться из офиса через корпоративный firewall, из дома через Wi-Fi, через мобильную сеть или VPN. В одном случае соединение будет стабильным, в другом — начнутся потери пакетов, высокий jitter или временное отключение сети.

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

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

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

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

Control plane. Это управляющая часть платформы. Она отвечает за жизненный цикл конференции:

• создание комнаты;
• подключение и отключение участников;
• роли и права;
• синхронизацию состояния;
• восстановление соединения;
• обработку пропущенных вызовов;
• бизнес-логику конференции.

Media plane. Этот слой работает непосредственно с медиаданными:

• устанавливает WebRTC-соединения;
• передает аудио и видео;
• маршрутизирует медиапотоки;
• адаптируется к условиям сети;
• учитывает сетевые ограничения.

Такое разделение оказалось принципиальным. Пользовательские функции можно развивать независимо от real-time-инфраструктуры, не превращая каждое изменение интерфейса или бизнес-логики в доработку медиаконтура.

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

Следующий вопрос — как именно распределять медиапотоки между участниками.

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

Другой вариант — MCU. В такой архитектуре сервер принимает медиапотоки, декодирует их, смешивает и заново кодирует. Управлять такой системой удобно, но постоянная обработка видео требует значительных вычислительных ресурсов.

Мы остановились на SFU — Selective Forwarding Unit. В этой модели участник публикует свой аудио- или видеопоток в конференцию, а остальные клиенты подписываются только на необходимые им потоки. Сервер при этом не занимается постоянным перекодированием видео, а фактически выполняет роль маршрутизатора. Это дает несколько важных преимуществ:

• конференции проще масштабировать;
• можно управлять потоками независимо друг от друга;
• для разных участников можно использовать разные параметры качества;
• аудио можно приоритизировать относительно видео;
• демонстрацию экрана можно обрабатывать отдельно.

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

На тестовом стенде ВКС обычно работает предсказуемо. В реальной компании все гораздо сложнее. Один сотрудник сидит за офисным firewall, другой использует VPN, третий подключился с телефона, четвертый работает через домашний роутер. Поэтому поддержку ICE, STUN и TURN мы закладывали в архитектуру изначально.

Отдельное внимание пришлось уделить reconnect. Если сотрудник на несколько секунд потерял сеть, переключился с Wi-Fi на мобильный интернет или свернул приложение, конференция не должна для него заканчиваться. С точки зрения пользователя связь должна восстановиться автоматически.

Еще один важный элемент — observability. Для диагностики недостаточно знать, что человек был участником встречи. Нужно видеть техническую картину:

• сколько заняло подключение;
• какой маршрут выбрал ICE;
• были ли потери пакетов;
• какой был RTT и jitter;
• происходило ли восстановление соединения;
• на каком этапе возникла проблема.

Поэтому сбор технических метрик и событий стал частью архитектуры с самого начала.
В итоге базовая модель Frisbee Meet выглядит так: control plane управляет состоянием конференции, media plane отвечает за медиаданные, а SFU распределяет потоки между участниками.

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

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

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

• подключением агента к комнате;
• получением задания;
• управлением состоянием;
• служебным обменом событиями;
• публикацией результатов обратно в сессию.

Разработчику при этом не приходится каждый раз заново решать низкоуровневые задачи интеграции с ВКС. Можно сосредоточиться на логике конкретного сценария.

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

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

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

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

В результате система получает два типа данных:

• сам медиаматериал;
• контекст разговора с временной разметкой.

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

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

ИИ-ассистент Frisbee анализирует запись и формирует структурированный результат: основные темы, решения, договоренности и полную расшифровку, к которой можно вернуться при необходимости.

После завершения конференции начинается последовательная обработка. Сначала отдельный сервис преобразует аудио в текст. Затем другой сервис анализирует транскрипцию и формирует итоговый отчет с помощью языковой модели. Обе стадии выполняются на GPU-инфраструктуре с моделями, развернутыми внутри нашей среды.

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

Есть и проблема непосредственно языковых моделей. Разные модели по-разному справляются с задачей: одна лучше соблюдает заданную структуру, другая лучше понимает смысл, но может хуже следовать формату. Кроме того, LLM способны добавлять недостоверные детали.

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

Для масштабирования используется параллельная обработка: задачи распределяются между GPU-узлами с учетом их текущей загрузки. Это позволяет не создавать лишнюю очередь и сокращать время ожидания готового результата.

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

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

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

Режим модератора мы тоже не стали реализовывать в виде отдельного сервиса. С архитектурной точки зрения модерация — это еще одно состояние конференции.

Для распространения событий между клиентами используется Data Channel поверх WebRTC, а текущее состояние комнаты хранится в общей metadata. Там находятся сведения о модераторах, режиме работы конференции и других параметрах, которые должны одинаково отображаться на Web, Desktop, Android и iOS.

Когда организатор назначает нового модератора, клиент отправляет событие через Data Channel. Сервер изменяет metadata комнаты, после чего обновленное состояние распространяется среди участников.

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

На этом месте возникает неочевидная проблема — параллельные изменения. Серверная часть написана на Java и работает в нескольких экземплярах. Если два администратора одновременно изменяют состав модераторов, одно изменение потенциально может перезаписать другое.
Чтобы избежать такой гонки, мы используем распределенные блокировки на базе Redis. Перед изменением metadata сервер получает блокировку, обновляет состояние и только затем публикует новую версию. В результате состояние списка модераторов остается согласованным независимо от того, какой экземпляр сервера обрабатывал запрос.

Главное здесь то, что нам не пришлось создавать отдельный канал для управления ролями. Модераторские права остаются частью общего состояния комнаты.

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

При включении режима в metadata фиксируется:

• кто может публиковать аудио;
• кто может публиковать видео;
• какие ограничения действуют на остальных участников;
• кто получает права управления.

Изменения распространяются через Data Channel, поэтому клиенты практически одновременно получают новое состояние.

Дальше именно metadata определяет поведение интерфейса. Если участнику запрещено включать микрофон или камеру, соответствующие элементы управления блокируются, а попытка изменить состояние не приводит к публикации медиапотока. При этом сам SFU продолжает работать по прежней модели publish/subscribe. То есть нам не понадобилось создавать отдельный медиаконтур для вебинаров. Меняются правила публикации потоков, а базовая архитектура остается прежней.

Команда Frisbee уже использовала этот подход для открытого вебинара о переходе с Telegram на корпоративный мессенджер. Сейчас функциональность вебинаров продолжает развиваться.

Важно различать два сценария: ограничение возможностей уже вошедшего участника и контроль самого входа в комнату.

Вебинар определяет, что пользователь может делать после подключения. Запрос доступа отвечает на другой вопрос: можно ли пользователю вообще войти в конференцию?
Если такая настройка включена, пользователь по ссылке сначала попадает в очередь ожидания. Он еще не считается участником конференции и не устанавливает WebRTC-соединение. Поэтому Data Channel для него тоже недоступен.

Для уведомления модераторов мы снова использовали metadata комнаты. Новый запрос добавляется в состояние конференции, после чего модераторы получают обновление через существующий механизм синхронизации. А вот ожидающий пользователь находится в другой ситуации: он еще не подключен к комнате и не может получать события через WebRTC. Для него используется long polling. После создания запроса сервер выдает идентификатор ожидания, а клиент периодически проверяет его состояние: доступ разрешен, отклонен или решение еще не принято.

В процессе разработки обнаружился еще один нюанс. Пользователь мог закрыть вкладку или обновить страницу, не отправив серверу явного сообщения об отмене запроса. В результате в очереди оставались «призрачные» заявки. Для их корректного завершения используется keepalive fetch, который позволяет отправить финальный HTTP-запрос даже при закрытии страницы.

Осталась еще одна проблема — совместимость старых клиентов. Прежние версии приложения не знали о механизме ожидания разрешения и воспринимали закрытую комнату как обычную ошибку подключения. Поэтому API пришлось версионировать. Новый endpoint поддерживает сценарий ожидания через long polling, а старый сохраняет прежнее поведение и предлагает обновить приложение. Так новую функцию удалось внедрить постепенно, не ломая уже работающие версии клиентов.

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

На качество связи влияют NAT, firewall, прокси, потери пакетов, jitter, характеристики канала и выбранный сетевой маршрут. И универсального исправления для всех таких ситуаций не существует. Поэтому мы предусмотрели отдельный сценарий диагностики — troubleshooting.
Проблемного участника можно динамически перевести в изолированный диагностический контур на отдельной машине и исследовать его поведение отдельно от основной конференции. Это позволяет смотреть:

• телеметрию;
• служебные события;
• состояние медиапотоков;
• сетевые параметры;
• особенности маршрутизации.

При этом эксперименты с транспортными настройками или другими низкоуровневыми параметрами не затрагивают остальных участников встречи.

Так troubleshooting превращается из попытки «починить что-нибудь прямо в проде» в управляемый диагностический процесс: проблему можно локализовать, проверить гипотезы и подобрать решение, не рискуя всей конференцией.

Если посмотреть на Frisbee Meet целиком, становится понятно, что собственно передача аудио и видео — лишь одна часть большой системы. Основная инженерная сложность корпоративной ВКС находится вокруг медиапотока:

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

Именно поэтому мы строили Frisbee Meet не как отдельный сервис видеозвонков, а как часть единой платформы коммуникаций.

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

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

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