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?

Answer 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