Force TCP for WebRTC PeerConnections

Question

Is it possible to force a TCP tunneled (TLS) connection with WebRTC?

We are developing a WebRTC application for our business, but we are experiencing some major issues with incoming UDP streams caused by our internal network. We are already using a TURN server and we are getting a bunch of ICE candidates (even relay UDP ones).

The thing is, as I stated above, that our incoming UDP traffic does not work reliable here (stuttering, very bad image quality, very low fps). It's enough to give the Browser the impression, that WebRTC can use it for it's PeerConnection(s), but the actual result is very bad over UDP.

If I block all outgoing and incoming UDP streams, I can see (in Wireshark) that WebRTC falls back to TCP traffic by using our turn server.

With TCP connections, we are getting very good results (with high frame rates and a very good image quality).

I've already tried several things to force TCP:

1. I deleted the UDP part in the m=video line

   m=video TLS/RTP/SAVPF 100 116 117 96

2. I've excluded every single UDP candidate from my candidate list

In each case I was not even able to establish a connection.

Is there anything I can do to force TCP in WebRTC or do we really depend completely on the browser here?

Praetor

Answer 1

Configure the peerconnection with a TURN/TCP server and set the iceTransports constraint to relay. See http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ Note that quality is typically worse than over UDP.

ICE-TCP is not supported for browser-to-browser connections. Only if you have a SFU/MCU/Gateway thing.

Krys

That's what I did. IceTransportPolicy is set to 'relay' and the turn server address ended with ?transport=tcp. The only candidates I got are "UDP relay" ones . I have tested other (public turn servers), too - same result. Do you get TCP relay candidates on the trickle-ice example? – Praetor

the 'udp' in those candidates indicates that the turn server has opened a udp port at the relay address.The connection from the client to the TURN server should still be TCP. You should see this in the "priority" field: 1 | 30 | 255 The 1 indicates that you are using TCP as transport for TURN. Or you can use wireshark to verify this. – Krys

I can confirm that also if the candidates contain udp, a tcp connection is established. You can also use nettop to verify this. – Parulis

Answer 2

You can not get TCP relayed candidates as ICE-TCP is not supported, but as for RFC-5766 there is a fallback mechanism to TCP control connection between the client and TURN server. That requires TCP TURN server which supports this fallback mechanism, per this mechanism the client will connect with the TURN server using TCP transport protocol and as a part of allocation request it will request for a UDP candidate, so the channel is like TCP-UDP. So if the peer does same thing and you force to happen Relay-Relay connection then both client will use TCP connection to TURN server. That fallback mechanism also supports for the TLS connection as well which comes into picture if both UDP and TCP TURN server is not configured but TLS is.

Morality

As per this answer, is ICE-TCP supported? – Halvorson