2016-01-28 5 views
4

Можно ли подключить TCP-туннельное (TLS) соединение с WebRTC?Force TCP для WebRTC PeerConnections

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

Дело в том, что, как я уже говорил выше, наш входящий UDP-трафик не работает здесь надежным способом (заикание, очень плохое качество изображения, очень низкий fps). Достаточно дать Браузеру впечатление, что WebRTC может использовать его для PeerConnection (s), но фактический результат очень плохой по UDP.

Если я блокирую все исходящие и входящие UDP-потоки, я вижу (в Wireshark), что WebRTC возвращается к TCP-трафику с помощью нашего сервера очереди.

С TCP-соединениями мы получаем очень хорошие результаты (с высокой частотой кадров и очень хорошим качеством изображения).

Я уже пробовал несколько вещей, чтобы заставить TCP:

  1. Я удалил часть UDP в м = видео линии

    м = видео TLS/RTP/SAVPF 100 116 117 96

  2. Я исключил каждый кандидат UDP из моего списка кандидатов

в е Я даже не смог установить соединение.

Есть ли что-нибудь, что я могу сделать, чтобы заставить TCP в WebRTC или мы действительно полностью зависеть от браузера?

ответ

3

Настройте соединение peerconnection с сервером TURN/TCP и установите ограничение iceTransports на реле. См. http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ Обратите внимание, что качество обычно хуже, чем у UDP.

ICE-TCP не поддерживается для соединений браузера и браузера. Только если у вас есть SFU/MCU/Gateway.

+0

Это то, что я сделал. IceTransportPolicy настроен на «ретрансляцию», а адрес сервера очереди заканчивается на: transport = tcp. Единственными кандидатами, которых я получил, являются «реле UDP». Я тоже тестировал другие (общедоступные серверы очереди) - тот же результат. Получаете ли вы кандидатов на ретрансляцию TCP на примере просачивания льда? –

+1

«udp» в этих кандидатах указывает, что сервер очереди открыл порт udp на адресе ретрансляции. Соединение с клиентом на сервере TURN должно быть TCP.Вы должны увидеть это в поле «приоритет»: 1 | 30 | 255 1 указывает, что вы используете TCP в качестве транспорта для TURN. Или вы можете использовать wirehark для проверки этого. –

+1

Я могу подтвердить, что также если кандидаты содержат udp, устанавливается tcp-соединение. Вы также можете использовать nettop для проверки этого. – wackazong

2

Вы не можете получить TCP-ретранслированных кандидатов, поскольку ICE-TCP не поддерживается, но для RFC-5766 существует резервный механизм соединения TCP-соединения между клиентом и сервером TURN. Для этого требуется сервер TCP TURN, который поддерживает этот резервный механизм, в соответствии с этим механизмом клиент будет подключаться к серверу TURN с использованием транспортного протокола TCP и в качестве части запроса на распределение запрашивает у кандидата UDP, поэтому канал похож на TCP-UDP. Поэтому, если одноранговый узел делает то же самое, и вы принудительно выполняете соединение Relay-Relay, то оба клиента будут использовать TCP-соединение с сервером TURN. Этот резервный механизм также поддерживает соединение TLS, которое входит в изображение, если оба сервера UDP и TCP TURN не настроены, но TLS.