16

If I am building a WebRTC app and using a Selective Forwarding Unit media server, does this mean that I will have no need for STUN / TURN servers?

From what I understand, STUN servers are used for clients to discover their public IP / port, and TURN servers are used to relay data between clients when they are unable to connect directly to each other via STUN.

My question is, if I deploy my SFU media server with a public address, does this eliminate the need for STUN and TURN servers? Since data will always be relayed through the SFU and the clients / peers will never actually talk to each other directly?

However, I noticed that the installation guide for Kurento (a popular media server with SFU functionality) contains a section about configuring STUN or TURN servers. Why would STUN or TURN servers be necessary?

shmth
  • 458
  • 3
  • 11

1 Answers1

21

You should still use a TURN server when running an SFU. To understand diving into ICE a little bit will help. All SFUs work a little differently, but this is true for most.

  • For each PeerConnection the SFU will listen on a random UDP (and sometimes TCP port)
  • This IP/Port combination is giving to each peer who then attempts to contact the SFU.
  • The SFU then checks the incoming packets if they contain a valid hash (determined by upwd). This ensures there is no attacker connecting to this port.

A TURN server works by

  • Provides a single allocation port that peers can connect to. You can use UDP, DTLS, TCP or TLS. You need a valid username/password.
  • Once authenticated you send packets via this connection and the TURN server relays them for you.
  • The TURN server will then listen on a random port so that others can then send stuff back to the Peer.

So a TURN server has a few nice things that an SFU doesn't

  • You only have to listen on a single public port. If you are communicating with a service not on the internet you can just have your clients only connect to the allocation
  • You can also make your service available via UDP, DTLS, TCP and TLS. Most ICE implementations only support UDP.

These two factors are really important in government/hospital situations. You have networks that only allow TLS traffic over port 443. So a TURN server is your only solution (you run your allocation on TLS 443)

So you need to design your system to your needs. But IMO you should always run a well configured TURN server in real world environments.

Sean DuBois
  • 3,972
  • 1
  • 11
  • 22
  • 1
    Thank you for the clarification. -- The structure would be something like this: Client-A <=> TURN <=> SFU <=> TURN <=> Client-B. Am I right? -- If so, Isn't it a bit inappropriate/uneven? Because the streams have to go through the TURN server and ALSO the SFU. – M. Rostami May 17 '20 at 17:34
  • I have tested pion/ion SFU and it's worked without any TURN implementation but the stream quality wasn't suitable. I didn't know that the pion/ion project has a mesh network type hence I searched for [peer-calls](https://github.com/peer-calls/peer-calls) which has created on pion/webrtc with the mesh network type feature. On the SFU, the quality is the same as pion/ion but when I configured to run a mesh network type, the peers couldn't connect (the peers' ISP have some problem with STUN and peer-to-peer/meth type of webrtc). -> – M. Rostami May 17 '20 at 17:48
  • <- Then I configured it with a TURN server and the quality was much better than SFU. Could you please explain why the quality is better on peer-to-peer/meth type? Is the problem with SFU's server performance/state? – M. Rostami May 17 '20 at 17:48
  • 3
    @M.Rostami if you are doing a p2p call with just two participants, then an SFU does not add much value, instead adds some latency (unless you want some server side intercept to record calls etc). On more than 3-4 peers, an SFU would probably show better results. The client can then work with establishing one connection (to the SFU), instead of many (to all peers) - thus saving upstream bandwidth, it only has to send video to one endpoint. – Animesh Jain Sep 23 '20 at 09:02
  • @AnimeshJain Yes! Thank you for the clarification. But we should consider about server's (which SFU staged) bandwidth. – M. Rostami Sep 23 '20 at 09:17