Needing or not needing a TURN server relies only on the network connection. Mobile app or no mobile app, audio only or audio+video has no effect on that.

Or simply put – yes. You will need STUN/TURN for mobile app with audio only calls.

Do you think Turn/Stun is needed if it is a mobile app and the traffic is an audio call only?

DW,

As with everything, it is a matter of priorities, needs and your clients.

For the most part, you will have ~5% of your users connected via TCP – simply because their network will block UDP traffic. For that alone, you need to either use TURN/TCP or ICE-TCP on your server.

Then there are those with a nasty firewall that actually validates that data is sent over TLS (ie – is being encrypted using TLS) or that just forces traffic over port 443. In such cases, you may need to have TURN/TLS – and this can happen to ~0.5% of your users.

Your userbase will be different. It might have MORE users behind such nasty firewalls. Or there might be less.

If you don’t care about these users, then by all means – don’t use TURN servers. If your users don’t complain – ask yourself first if that’s because they just move on to other services or because there are no issues at all.

The easiest way to add TURN is by purchasing it from Xirsys or Twilio as a service. You’ll immediately know if it is being used or not…

We currently have TURN/STUN setup and I don’t think ANY sessions are being proxied via TURN. There isn’t enough bandwidth being consumed to indicate that is happening.

The developer of the SFU we are using, MediaSoup, repeatedly tells users that STUN isn’t required as the software uses ice-lite. And I can’t see any evidence that TURN is being used so I’m thinking about removing both.

If there are only one or two clients that cannot connect to our service, I don’t want to maintain TURN for just rare cases. It is sufficient to blame their firewall and say that they are unsupported. (If we are talking about 0.01% of users…. and I think this may be the case unless our TURN service is not configured properly….. there is simply no bandwidth being used and we are not having any complaints either.)

So before telling everyone that they absolutely, positively need TURN, I think you should point out that cost vs benefit needs to be considered, or add the caveat that you are only talking about p2p, and maybe p2p involving corporate networks with strict firewalls. We provide a free service on the web to consumers, where home routers are generally more permissive I guess, and it is not cost effective for us to pay for TURN bandwidth or worth adding complexity for such rare cases….. (if it was even necessary… because as I said, we provide it now and it isn’t being used.)

Because of your post here, I have to spend time trying to figure out if I am missing something or if our TURN is not configured properly to explain the lack of usage. But I am pretty sure that we would be hearing from our users if a TURN was critical and not working. So I am highly inclined to think that our case breaks your logic here.

Amgaa,

Such technical questions are more suitable for the discuss-webrtc group and less on this article. You might want to check there.

That said, you must at least make sure and verify that your TURN server has public access and a public IP associated with it.

Alex, you need to use turns: instead of using turn: in that same line where you use ?transport=tcp

Jai,

Such a specific case should be workable without STUN and TURN.

For WebRTC multi party screen, voice share functionality with in intranet (assuming all devices connected to same switch and no NAT) still we need STUN and TURN?