Skip to content

Требования к сети для проведения видеоконференций

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

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

Модель трафика

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

Базовая расчетная модель:

N = количество участников
V = количество участников с включенным видео
A = аудио-битрейт одного участника, обычно 32 кбит/с
B = видео-битрейт одного участника, обычно 1.0-1.5 Мбит/с

Входящий канал сервера ~= V * B + N * A
Исходящий канал сервера ~= V * (N - 1) * B + N * (N - 1) * A

Для камер и демонстрации экрана в WebRTC основным путем является UDP/DTLS/SRTP. Если UDP недоступен, web-клиент может перейти на WSS/WSMedia fallback, но это резервный путь: задержка и нагрузка на TCP выше, а качество хуже при потерях.

Ориентировочная таблица

Расчеты ниже даны для B = 1.5 Мбит/с на один активный видеопоток и A = 32 кбит/с на аудио. Это не лимит продукта, а ориентир для проектирования канала. Фактические цифры зависят от разрешения, FPS, активности камер, демонстрации экрана и политики конференции.

Сценарий Участники Видео включено Входящий канал сервера Исходящий канал сервера Типичный входящий канал клиента Комментарий
Звонок 1:1 2 100% ~3.1 Мбит/с ~3.1 Мбит/с ~1.5 Мбит/с Минимальный WebRTC-сценарий
Небольшое совещание 8 100% ~12.3 Мбит/с ~85.8 Мбит/с ~10.7 Мбит/с Все видят всех
Команда 16 100% ~24.5 Мбит/с ~367.7 Мбит/с ~23.0 Мбит/с Требуется уверенный uplink сервера
Большая встреча 32 20% ~11.5 Мбит/с ~357.2 Мбит/с ~11.5 Мбит/с Выгодно ограничивать число камер
Большая группа 50 20% ~16.6 Мбит/с ~813.4 Мбит/с ~16.6 Мбит/с На 1G uplink уже близко к пределу
Канал / вебинар 100 5% ~10.7 Мбит/с ~757.4 Мбит/с ~10.7 Мбит/с Мало отправителей, много получателей
Аудиоконференция 100 0% ~3.2 Мбит/с ~316.8 Мбит/с ~3.2 Мбит/с Видео выключено, но аудио все равно мультиплицируется

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

Режимы масштабирования

Режим Когда использовать Что происходит с трафиком
Все видят всех Малые и средние совещания Исходящий канал сервера растет примерно как V * (N - 1)
Асимметричная конференция Большие группы, где говорят не все Видео включено только у части участников, остальные принимают
Консолидатор Очень большие группы и слабые клиентские сети Клиент получает один агрегированный видеопоток вместо набора отдельных потоков
Канал / вебинар Один или несколько ведущих и много зрителей Минимальное число отправителей, высокая предсказуемость нагрузки

Сетевые порты

Для production-сервера должны быть открыты:

Назначение Протокол По умолчанию Комментарий
Web-клиент, админка, API, WebSocket/WSS TCP 443 Один публичный HTTPS/WSS endpoint сервера
Translator / media core UDP 5060 или диапазон из vgserver.conf Native-клиенты, WSMedia fallback, recorder и внутренняя RTP/RTCP-маршрутизация
WebRTC ICE/DTLS/SRTP UDP 43000-43999 Основной media path браузерных клиентов

Если сервер находится за NAT, пробросьте TCP-порт сервера, UDP-порты трансляторов и весь UDP-диапазон WebRTC на тот же внутренний адрес. Номера UDP-портов желательно сохранять без трансляции.

Практические рекомендации

  • Для публичного сервера используйте доверенный TLS-сертификат и доменное имя, совпадающее с адресом в настройках сервера.
  • Для стабильного WebRTC откройте UDP-диапазон WebRTC.PortRangeBegin / WebRTC.PortRangeEnd из vgserver.conf.
  • Для 1G uplink не планируйте режим "все видят всех" на большие группы. Ограничивайте число активных камер или используйте консолидатор.
  • Для больших публичных мероприятий используйте режим канала или асимметричной конференции.
  • Для точной оценки используйте калькулятор нагрузки ВКС, а после пилота сверяйте расчет с мониторингом сервера.

Система сохраняет связность речи при умеренных потерях UDP, но потери и jitter ухудшают видео быстрее, чем аудио. Если участники жалуются на зависания видео, сначала проверяйте UDP-доступность, потери, NAT и реальный исходящий канал сервера.