Процесс перемещения описан ниже. Для Wcs3 он автоматический, для WCS2 нужно будет написать письмо в техподдержку.
Вопросы и ответы
Как переместить лицензию WCS с одного сервера на другой?
Планирую организовать потоковое вещание с низкой задержкой. Каким будет значение задержки? На сколько слушателей?
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 миллисекунд.
Что касается количества зрителей, ограничением будет пропускная способность сетей от сервера к конечным пользователям. Если по какому-либо направлению произойдет «затор» и скорость упадет,
то качество потока может ухудшиться. Другое ограничение — ресурсы процессора сервера. Но пропускная полоса здесь более важна.
Если установлен Flash-SIP звонок, может ли SIP пользователь инициировать конференцию и пригласить третьего участника?
Flash телефон может участвовать в конференции, которую поддерживает confbridge или PBX
Можно ли установить коннект к SIP и организовать вещание через Wowza сервер?
Похожий случай уже реализован в master ветке репозитория клиента: https://github.com/flashphoner/flashphoner_client/tree/master
Как работает autologin? Насколько его использование безопасно?
Путь аутентификации при autologin: WebRTC Client — WCS — Authentication server
Не работают WebRTC звонки с Android Chrome браузера. В чем может быть проблема?
Подсистема безопасности Android Chrome браузера требует действительных SSL сертификатов, подписанных центром сертификации.
RTP пакеты не уходят каждые 20ms от RTMP SIP Gateway. Можно ли уменьшить джиттер?
Flash отправляет аудио данные через TCP соединение в случае RTMP SIP Gateway + Wowza.
