Web Call Server поддерживает технологию WebRTC. Это означает что каждый клиент-браузер установит WebRTC соединение с сервером.
WebRTC использует SRTP протокол, свободный от каких-либо TCP-подобных повторных отправок, которые являются причиной растущей задержки. Таким образом значение задержки будет зависеть от джиттер буфера на стороне браузера и от RTT. Достаточно сложно предсказать точные значения задержки, но можно сказать что они будут очень малы. На сегодняшний день WebRTC дает минимальное значение задержки в сравнении со всеми остальными технологиями потокового видео в web, такими как HTML5 HTTP или Flash.RTMFP.
Выше вы можете увидеть диаграмму, на которой показано как складываются задержки.
Рассмотрим среднюю по показателям сеть с RTT 100 мс. Например если вы пингуете сервер в Германии из Сибири, вы можете получить подобные значения RTT.
На диаграмме:
- Первый сегмент Публикующий — Web Call Server внесет задержку около 50 мс.
- Второй сегмент Web Call Server — Subscriber добавит те же самые 50 мс, если мы предполагаем что подписчик или зритель находится в той же сети где и Публикующий по отношению к Web Call Server с RTT около 100 мс.
- Третий сегмент это джиттер буфер на браузере зрителя, который принимает поток. Размер внесенной задержки здесь будет зависеть от качества сети. Если качество достаточно хорошее, эта дополнительная задержка будет минимальной, т.к. задача adaptive jitter buffer — на сколько это возможно минимизировать задержку если позволяет отсутствие потерь. Если же в сети много потерь, джиттер буфер будет автоматически увеличен чтобы сохранить соотношение задержка/качество на приемлемом уровне. При этом он не будет достигать больших значений как в случае воспроизведения потока по TCP и будет сбрасывать пакеты по необходимости, что может повлиять в худшую сторону на качество, но сохранит задержку низкой.
WebRTC предназначена для коммуникаций с низкой задержкой, не для видео по запросу, поэтому низкая задержка имеет более высокий приоритет над качеством в случае WebRTC и это нужно иметь ввиду.
Кроме того, WebRTC использует VP8 видео кодек чтобы сохранить хорошее соотношение качество/задержка при передаче видео по сети.
В итоге, среднюю задержку можно вычислить как 2*RTT, где RTT это Round Trip Time — время путешествия пакета до сервера и обратно или просто ping. Для нашего примера с Германией и Сибирью это около 200 миллисекунд.
Что касается количества зрителей, ограничением будет пропускная способность сетей от сервера к конечным пользователям. Если по какому-либо направлению произойдет «затор» и скорость упадет,
то качество потока может ухудшиться. Другое ограничение — ресурсы процессора сервера. Но пропускная полоса здесь более важна.
