WebRTC - How many STUN/TURN servers do I need to specify?

Question

I'm having trouble with NAT traversal and WebRTC. Videostreaming works with some people, but not with someone who's behind a student dorm router.

I think this should be solved by using a TURN server. I've done that, it still isn't working, and now I'm wondering if the TURN server is working at all. In consequence I wonder if I can or should set several TURN servers, and if yes, how.

I found this list of STUN/TURN servers in another thread. Right now I'm setting them like this

var STUN = {
    'url': 'stun:stun.l.google.com:19302',
};

var TURN = {
    url: 'turn:[email protected]:80',
    credential: 'homeo'
};

var iceServers = 
{
    iceServers: [STUN, TURN]
};

var pc = new RTCPeerConnection(iceServers);

So my question is basically: Is it possible to set several STUN/TURN servers? Should I do it if possible, and what would that code look like?

Solution 1

A STUN server is used to get an external network address.
TURN servers are used to relay traffic if direct (peer to peer) connection fails.

URLs for STUN and/or TURN servers are (optionally) specified by a WebRTC app in the iceServers configuration object that is the first argument to the RTCPeerConnection constructor.

example of using more that server:

var ICE_config= {
  'iceServers': [
    {
      'url': 'stun:stun.l.google.com:19302'
    },
    {
      'url': 'turn:192.158.29.39:3478?transport=udp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    },
    {
      'url': 'turn:192.158.29.39:3478?transport=tcp',
      'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
      'username': '28224511:1379330808'
    }
  ]
}
pc = new RTCPeerConnection(ICE_config);

Once RTCPeerConnection has that information, the ICE magic happens automatically: RTCPeerConnection uses the ICE framework to work out the best path between peers, working with STUN and TURN servers as necessary.

STUN: STUN servers live on the public internet and have one simple task: check the IP:port address of an incoming request (from an application running behind a NAT) and send that address back as a response. In other words, the application uses a STUN server to discover its IP:port from a public perspective. This process enables a WebRTC peer to get a publicly accessible address for itself, and then pass that on to another peer via a signaling mechanism, in order to set up a direct link. (In practice, different NATs work in different ways, and there may be multiple NAT layers, but the principle is still the same.)

TURN: TURN RTCPeerConnection tries to set up direct communication between peers over UDP. If that fails, RTCPeerConnection resorts to TCP. If that fails, TURN servers can be used as a fallback, relaying data between endpoints.

Just to reiterate: TURN is used to relay audio/video/data streaming between peers, not signaling data!

TURN servers have public addresses, so they can be contacted by peers even if the peers are behind firewalls or proxies. TURN servers have a conceptually simple task — to relay a stream — but, unlike STUN servers, they inherently consume a lot of bandwidth. In other words, TURN servers need to be beefier.

see this

Solution 2

Regarding STUN, WebRTC will send Binding Requests to all, and results are merged. (Note that in older versions of the WebRTC code, only the first STUN server seems to be used)

I would recommend using more than one STUN server, as you will reduce your connection time, on average. The exact number depends on the reliability of your STUN servers. Generally 2 are enough.

Regarding TURN, the problem is more complex because these servers will relay your traffic when P2P connections are not possible. If you have many clients, a single TURN server will probably reach its maximum bandwidth. In this case, setting multiple TURN servers will help.

How? During the connectivity checking phase, WebRTC will choose the TURN relay with the lowest round-trip time. Thus, setting multiple TURN servers allows your application to scale-up in terms of bandwidth and number of users.

If you're not developing a large scale application, 1 or 2 TURN servers are generally enough.

You can browse the WebRTC code at https://chromium.googlesource.com/external/webrtc/+/master

I recommend looking inside: webrtc/p2p/client/basicportallocator.cc, webrtc/p2p/base/stunport.cc and webrtc/p2p/base/turnport.cc

Solution 3

The problem is likely that the universities firewall is blocking port 19302. Public wifi firewalls typically allow traffic only on port 80 and 443. In other words, do not use google's STUN server because it tries to use port 19302 and that port is blocked by the schools firewall.