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?

Dunno

I upvoted your answer because I thought it was helpful since you showed me how to build the array to set several STUN or TURN servers. But I already knew what a STUN and what a TURN server is. What I wanted to know is if it's useful to set several TURN servers, or several STUN servers (for performance reasons maybe, will my program pick the server with the lowest latency, will it be able to tell when a TURN server is offline and pick the next one, if yes how long does this take..). The lack of that information was why I didn't accept. Perhaps my question was simply too unspecific. – Dunno

these are actual credentials which you have posted, I am not sure how much harm it can do to you, but you should update it :P – Proceeding

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

Triaxial

Thank you. That array construct with the multiple turn servers was exactly what I was looking for. Is it useful to set several of them? – Dunno

@Dunno 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. yes its useful. each one used for a purpose – Triaxial

@Triaxial that doesn't directly answer spacecoyote's question which I think is a valid one - what are the merits of specifying more than one TURN server and how will the WebRTC implementation determine which to use? – Whereinto

@Whereinto the question "WebRTC - How many STUN/TURN servers do I need to specify?" not "how will the WebRTC implementation determine which to use?" we got another question here.. you can ask it if you want ,, or you can answer this question as you understand ^_^ – Triaxial

@Triaxial okay then #26343089 – Whereinto

To test ice servers' working check: webrtc.github.io/samples/src/content/peerconnection/trickle-ice – Lifesize

Answer 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

Intaglio

To check ICE servers' working check: webrtc.github.io/samples/src/content/peerconnection/trickle-ice – Lifesize

Where in the code does WebRTC check the RTT of each TURN candidate? – Pentose

There are warnings and errors on firefox, which permit using more than one stun/turn server. – Darondarooge

Answer 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.

Pegg

Moreover, would be better if you configured your own STUN or TURN server in which the primary port is binding on 443 or 80. It's a trick that I saw some signaling servers did. – Genny

Yes and there is open source libraries out there which make is easy to do. – Pegg

Please I need help. I am stuck. ICE Failed in all my requests. please can you help me out with turn ans stun urls?? – Solo

I could help. What do you need? – Pegg

here is my ICE config – Solo

export const ice = { iceServers: [ { urls: 'stun:stun.l.google.com:19302' }, { urls: 'turn:relay.backups.cz', credential: 'webrtc', username: 'webrtc' } ] }; – Solo

even { urls: "stun:stun.services.mozilla.com", username: "[email protected]", credential: "webrtcdemo" } fails too – Solo

Okay I'm a professional programmer, email me and I we talk about it? [email protected] – Pegg

Thanks Man, you are really a good person not just for yourself. – Solo

@kiwicomb123: sent you a mail regarding one of the turn configuration problem related to #65506392 – Selfhelp