Медиа и устойчивость¶

Устойчивый медиа-транспорт VideoGrace

WebRTC, RTC-ноды и WSM fallback¶

Браузерный клиент в нормальном режиме использует WebRTC до RTC-ноды. RTC-нода принимает browser media, преобразует его в серверный RTP-путь и отдает входящие RTP-потоки обратно в WebRTC для браузера.

Если WebRTC временно недоступен, клиент может перейти на WSM fallback. WSM — это резервный медиа-транспорт поверх WebSocket, который важен для совместимости и аварийных сценариев. При появлении рабочей RTC-ноды сервер пушит клиентам актуальные RTC routes, и клиенты с WSM-сессиями пробуют перейти обратно на RTC без разрыва текущего WSM-потока до успешного подключения.

Практический результат: WSM не является тупиком. Это временный безопасный режим, из которого клиент автоматически возвращается в RTC, когда появляется рабочий путь.

Непрерывность связи при отказах транспорта¶

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

Если текущая RTC-сессия деградировала или оборвалась, клиент в автоматическом режиме пробует восстановить RTC-путь. Если доступный RTC-маршрут не поднимается, клиент переключает конкретный медиа-поток на WSM fallback. При этом конференция, участники, чат и состояние управления сохраняются.

Когда сервер видит появление рабочей RTC-ноды, он отправляет клиентам обновленные RTC routes. Клиенты, которые временно работают через WSM, пробуют вернуться на RTC без ручного действия пользователя. WSM-поток не разрывается до успешного подключения RTC, поэтому переключение происходит безопасно для текущей связи.

Такой механизм дает операторский уровень устойчивости: основной WebRTC-путь используется там, где он доступен, но сбой RTC не превращается в “перезайдите в звонок”. Система сохраняет связь и возвращается к оптимальному транспорту при первой возможности.

Роль plain RTP внутри системы¶

Внутри серверного контура медиа передается как RTP. Это сознательный выбор:

нет лишнего транскодирования, если оно не нужно;
низкая нагрузка CPU;
проще подключать recorder, consolidator, rtc-translator и другие сервисы;
проще контролировать качество и fanout;
серверные ноды можно масштабировать горизонтально.

Хрупкое место plain RTP — сеть между серверными компонентами, если она проходит через нестабильный интернет или неверно настроенный firewall/NAT. Поэтому RTC translator передает через CAN телеметрию: количество RTP-пакетов в обе стороны, ошибки отправки, битый RTP, последние timestamps и per-peer состояние. Это позволяет быстро понять, где именно оборвался медиа-путь.

Для крупных инсталляций отдельную роль получает RTP translator. Он позволяет строить “кусты” RTP-трафика: не гнать каждый поток через один центральный узел, а распределять media fanout между несколькими нодами и площадками. Это дает горизонтальное масштабирование media plane без обязательного транскодирования.

Запись и транскрипция¶

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

Это снижает ценность прямого browser-to-browser P2P даже для 1-to-1: если параллельно отправлять поток на сервер для записи, клиент тратит больше исходящего канала и батареи, а система получает больше состояний для отладки. Серверно-центричная модель проще и надежнее: один контролируемый медиа-путь сразу подходит для разговора, записи, транскрипции, модерации и диагностики.

Дальше читать¶

RTC translator: WebRTC edge и failover RTC-ноды.
RTP translator: межнодовая маршрутизация и “кусты” RTP-трафика.
Recorder: запись через серверный media path.
Transcriber: транскрипция и последующая обработка речи.