Well now, this proves where, once again, this unfortunate combined Spreed/Talk category is a major mess. It really would make things much easier for everybody if the devs could finally extricate the two from each other. This mangled mix, sometimes containing conflicting instructions, sows utter confusion.
With just a couple of caveats, yes, unfortunately every internet-facing installation needs not just STUN but also TURN.
This would presumably be firewalls/routers that don’t enable UPnP hole-punching. Since that’s enabled on most consumer routers by default, you’re probably right that it doesn’t apply to your case. It’s worth checking for if any of your users are on a business network, though.
If you are running an internet-facing installation that isn’t exclusively IPv6, this most likely applies to you. Regardless of whether your server is behind NAT, nearly all of your users will be. WebRTC is supposed to let the clients connect directly to each-other, but with NAT in front of each user, that’s pretty tough to do.
See this excellent how-to on the forums for more information. If you’re using the Nextcloud VM, there’s also the script they mention in the README you linked.
Indeed, the excellent how-to is excellent. But only for those who need to set-up TURN & STUN. I’m still not convinced that I must.
In spite of the documentation stating that this “works out of the box” I suppose that eventually I may have to take your word for this, even though it currently seems dubious in light of what the devs have haphazardly written. What would make me much more confident in your advice is if the author of “works out of the box” can chime in and tell us exactly what “working out of the box” means.
To me, “works out of the box” suggests that one doesn’t have to create another box to get this working! Does this not mean the same to you?
It works out of the box if you want texting, or if you want video chat between people that aren’t behind NAT, or are on the same internal network. It’s potentially a single-box solution, unlike services that require some sort of video mixing server-side, but you’re right that it’s a quite misleading statement that it “works out of the box”, since it doesn’t for most uses.
I don’t know who the author of that statement is, but various people have filed issues and posted comments that agree with me that TURN is quite often required. A quick search turns up these:
It works out of the box within local networks, but if your Nextcloud Talk server is used throughout www, a TURN server is the only way to assure that video chat works with every participant from any location (including e.g. mobile internet etc).
If there is only a small number of potential participants with a fixed location (and network setup), then you can simply try if the default STUN is sufficient in all these cases, but I tried many different cases and indeed in every single case I tested, where a NAT was between the peers, TURN was required.
Setting up the server is much more daunting than I had anticipated. The instructions posted by various people (particularly @mactrent) are much appreciated. However, most seem to be disjointed and “works in progress” which make them very difficult to follow. I’d be happy to help clean things up if I can eventually resolve my particular problem. However, for now, the headaches and frustration simply aren’t worth the pain; I’ll continue to rely on Signal.