WebRTC к Node.JS серверу и поток как RTP

Question

Я хочу задать экспериментальный вопрос. Итак, у меня есть поток WebRTC, который должен проигрываться XBMC/Kodi. Я планировал это, и я думаю, что самая большая проблема заключается в преобразовании и отправке потока (обратите внимание, что это было без какого-либо кода прототипирования). Это план:

1. Получить поток (давайте проигнорируем это)
2. Отправить поток на Node.JS через WebSocket (не должно быть так сложно, пока это возможно, потому что я не уверен)
3. Получать поток через WebSockets в Node.JS
4. Преобразовать поток
5. Отправь это как что-то приемлемое XBMC/Kodi (скажем, RTP)

Последние 2 бита самые сложные, и я понятия не имею, как это сделать. Может ли кто-нибудь помочь мне?

Answer 1

Столько, сколько сказано о том, что WebRTC является одноранговым, есть некоторые менее известные факты. Одноранговая связь не всегда возможна из-за несогласованности архитектуры интернета, в частности симметричных NAT (трансляторов сетевых адресов), что обычно имеет место в мобильных сетях и некоторых сетях с "плохим поведением".

В большинстве других сетей с WebRTC вам не нужно отправлять данные через ваш сервер, поскольку он будет соединять одноранговый узел с помощью протокола STUN для получения сведений об общедоступных сокетах и пробивки отверстий для фактической передачи данных. Вам нужен сервер для настройки сигнальной части, так как он не является частью WebRTC. Для сигнализации вы можете использовать протоколы, такие как SIP, веб-сокеты и т. Д.

Сказав это, в качестве отказоустойчивого механизма, когда p2p невозможен, вы можете использовать подход для маршрутизации трафика через ваш сервер. Хорошая вещь заключается в том, что WebRTC обеспечивает поддержку этого подхода с использованием серверов TURN. ICE используется для определения наилучшего сценария (возможность p2p с использованием STUN или маршрутизации данных через сервер TURN). Следует отметить, что последний не является одноранговым, и для маршрутизации данных через сервер TURN требуется сервер TURN с высокой пропускной способностью, что приводит к непомерным расходам.

Теперь позвольте мне остановиться на некоторых неверных предположениях в ваших пунктах:

1. Вы можете справиться с этим, как вы заявили.

2. Этот шаг будет выполнен сервером TURN. Внутренне websockets не используется WebRTC. Он использует SRTP ( RTP через SSL) на прикладном уровне и TCP или UDP (в зависимости от прохождения брандмауэра и требований надежности). Таким образом, веб-сокеты не возможно с WebRTC. Это совершенно другой подход.

3. То же, что в пункте 2.

4. Как правило, преобразование "на лету" не рекомендуется и не рекомендуется (задержка преобразования приведет к удалению функции реального времени из окна). Любое такое преобразование должно быть сделано на шаге 1.

Перед началом сеанса SDP (протокол описания сеанса) передает кодеки для аудио и видео обоим клиентам на этапе сигнализации.

5. Еще раз отметим, что после инициализации сеанса, будь то p2p или через сервер TURN, данные должны непрерывно передаваться обоим клиентам. Это суть WebRTC.

Если вы хотите что-то еще, попробуйте веб-сокеты. Для этого не нужно ничего, кроме поддержки веб-сокетов на стороне клиента и сервера. Он использует всю архитектуру стека протоколов TCP-IP-HTTP, за исключением того, что он заменяет HTTP веб-сокетами на уровне приложений с запросом на обновление сервера. Это позволяет двунаправленный поток данных с сервера и клиентов, и вы можете более свободно выполнять вычисления на данных.

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

PS Из-за меньшей репутации я не могу опубликовать более 2 ссылок. Пожалуйста, используйте Википедию для ссылки на неясные для вас условия.