TURN over TCP/443

[Nikos Argiropoulos]

Could someone give me the steps for enabling the usage of COTURN (STUN and TURN) from a webrtc client with open only the TCP/443 to the server ?

[Warren McDonald]

Hi,

First up, STUN is only useful if the WebRTC endpoints have UDP access and so there is only a UDP listener on CoTURN for STUN, for this reason. So TCP is only viable for TURN connections.

The first thing is to ensure you have configured the CoTURN server to listen on 443 for the protocols you want to support. This is done using the listener directives

    listening-port=443

    tls-listening-port=443

Second is to ensure the client's RTCPeerConnection configuration iceServers urls contains the correct expressions for TCP as follows 

    turn:<hostname>:443?transport=tcp

    turns:<hostname>:443?transport=tcp

See https://docs.w3cub.com/dom/rtcconfiguration.html and https://developer.mozilla.org/en-US/docs/Web/API/RTCIceServer/urls for full details.

Note: For turns (TLS) you will also need to procure, install and configure a valid certificate in the CoTURN config. This is worthwhile, as some corporate and institutional networks will drop traffic to port 443 if it is not TLS. The browser will try the urls in the order they are in the configuration object, so you can set it to try TCP first and then TLS, or vice versa.  

Hope this helps

Warren

[Nikos Argiropoulos]

Regarding the "there is only a UDP listener on CoTURN for STUN" 

• is a limitation of all versions of Coturn or of 4.5.0.7 I currently use ? 
• the TCP listener for STUN is a RFC spec that is not (yet) impelemented ?

Nikos

[Warren McDonald]

The rfc is 5389 and is not widely implemented. In any case, it would be a waste of time as most browsers so far have only implemented peer to peer connections over UDP.  So any browser NAT address returned by a STUN sever for WebRTC, has to accessible via UDP. 

This is where the TURN server comes in. When a connection can only be made to the TURN server via TCP,  it creates an allocation of a UDP port for the remote party to connect to and then relays the packets to the client's TCP connection. If both parties can only do TCP, then the each will have a UDP port allocated on the TURN server relay address and the packets will be relayed between those ports and then to the clients' TCP connections.

[Nikos Argiropoulos]

Regarding the "browsers so far have only implemented peer to peer connections over UDP" do you now the most appropriate places to find some fresh references to this?

Regarding the second part about the TURN server ports/relay I am not sure if I understand well , do you mean that TURN relays the packages via TCP connections with the two peers althtough has allocated UDP ports for this ?

[Warren McDonald]

I don't have any references at hand re Peer to Peer via TCP on browsers. You could check the discuss-webrtc group for mentions. 

On the second point, it is easier to explain it in two parts.

When a webrtc client uses a TURN server, regardless of the client protocol, the relay allocation creates a UDP port for the traffic to flow between the TURN client and the remote WebRTC user.

The most common scenario, is where two browsers cannot establish a NAT connection with the assistance STUN and then have to rely on the TURN relay. In this case the ICE negotiation provides the remote browser with the address of the TURN relay port. So instead of trying to contact my router for a NAT connection, it connects to the TURN server and port allocated. 

In the case that both browsers can not use STUN and will require TURN, often because they do not have UDP egress, there are relay ports created for each browser and these 2 ports end up connecting to each other, to complete the relay path. 

Cheers,

Warren