Best way to host a TURN server with Coturn

[Alecsandru Neculai Andrei]

We are researching into what would be the best way to host several Coturn servers, around 3 instances for availability reasons. We need them because we are using WebRTC.

We thought of hosting the servers inside a process/container orchestration platform like Service Fabric or Kubernetes.

But from what I have in most tutorials and in some practical examples, people prefer dedicated machines or virtual machines for the turn server. We would want to host the TURN server on docker containers, if possible, in some orchestrator like Service Fabric from Azure or Kubernetes.

From what I have seen, a TURN server uses a lot of ports and it should not also be behind a normal load balancer like you would use for http traffic.

[Warren McDonald]

Hi,

your assessment is correct in terms of high port use and firewall needs. You need to avoid any scenario where the port range is being restricted or set arbitrarily and there is insertion of dynamic port forwarding, by the infrastructure or orchestration tools.

The TURN allocation process uses IP addresses which it resolves from the RTC configuration host names, so it is easiest to use round robin DNS to share load amongst several servers on different external IP addresses. The Co-TURN  config allows you to statically map internal IPs to their respective external Internet facing IPs if you need. For very busy services, dedicated network adapter time is important as well, which could potentially be an issue with docker. 

You can certainly use containers to simplify deployment of the servers, but you should ensure they deploy to dedicated host servers with consistent port configs and make sure the turnserver.conf files or command lines have the correct runtime config for the allocated internal and external network addresses. 

The network forwarding must allow UDP and the running servers must be able to reach each others external IP addresses (i.e. no blocking of hairpin routing) 

You also need to ensure that a high ulimit for nofiles (max sockets) is in effect for the host and containers.

Cheers,

Warren   

[Alex C]

For WebRTC, if you have RTP engine (RTPE @ https://github.com/sipwise/rtpengine) or similar running behind TURN server - make sure that RTPE always have DTLS = passive, ie "Instructs rtpengine to prefer the passive (i.e. server) role for the DTLS handshake" with "a=setup:passive" in SDP. That will save you a lot of troubles in a way that only "external" clients will start DTLS handshake ( client -> TURN -> RTPE -> ... ). Without that settings RTPE (or any other application behind TURN server) would try to start DTLS that will fail and result in enormous delays.