Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Understanding SFU's, TURN servers in WebRTC

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?

like image 709
shmth Avatar asked Apr 18 '20 09:04

shmth


People also ask

What is turn server WebRTC?

The term stands for Traversal Using Relay NAT, and it is a protocol for relaying network traffic. There are currently several options for TURN servers available online, both as self-hosted applications (like the open-source COTURN project) and as cloud provided services.

What is the use of STUN server in WebRTC?

Session Traversal Utilities for NAT (STUN) is a protocol to discover your public address and determine any restrictions in your router that would prevent a direct connection with a peer.

Do I need a STUN server for WebRTC?

Before establishing a peer-to-peer connection, it is essential for servers to identify the IP address for each participant. WebRTC applications use STUN servers most of the time.

What is SFU and MCU?

The main difference between an MCU and an SFU is how they handle media streams. MCUs broadcast media to all parties, while SFUs decide which streams should be forwarded to other parties.


1 Answers

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.

like image 111
Sean DuBois Avatar answered Oct 20 '22 17:10

Sean DuBois