WebRTC Media Server: управление долгоживущими одноранговыми соединениями

Я начинаю с WebRTC, и это в основном вопрос дизайна. Ищем плюсы и минусы двух конкурирующих подходов.

Контекст

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

Вопрос

Как мне управлять одноранговыми соединениями с клиентами?

Обдуманные подходы

  1. Каждая пара (клиент, видеопоток) получает собственное одноранговое соединение. Итак, если клиент просматривает 5 видеопотоков, эта веб-страница будет иметь 5 одноранговых соединений. Каждое одноранговое соединение имеет одну дорожку. Это включает в себя создание / уничтожение одноранговых соединений каждый раз, когда клиент выполняет действие для просмотра / закрытия видеопотока.
  2. Каждый (клиент) получает одно одноранговое соединение. В зависимости от действий клиента мы либо добавляем треки, либо удаляем треки из однорангового соединения. Единственное соединение существует, пока клиент находится на нашей веб-странице.

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

Спасибо.


webrtc p2p rtcpeerconnection
person synchronice    schedule 02.10.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вариант 2, безусловно, более эффективен, поскольку позволяет избежать согласования ICE для каждого потока. Это также позволяет избежать траты UDP-портов, что может быть важно, если ваш сервер очень загружен. (Это также ограничивает количество состояний в блоках NAT, что, вероятно, больше не является проблемой в настоящее время.)

Однако вариант 1 может быть более производительным, поскольку использование разных транспортных потоков для каждого медиапотока (другого порта UDP) означает, что формирователи трафика и AQM будут различать разные потоки и могут обеспечить большую пропускную способность для вашего приложения.

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

person jch    schedule 04.10.2020