True, but the problem you're mentioning is solved, for the most part. STUN/TURN servers serve this purpose, there are open source ones[0][1] and you can can even use public STUN servers[2] (as you might expect free TURN servers aren't really a thing).

Solutions like Jitsi Meet[3], whereby (formerly appear.in)[4] use WebRTC to great success and are fantastic for quick meetings.

WebRTC these days is pretty mature and ready for primetime -- TURN servers are a last resort, but they're a small price to pay for something that might be free (to you the service provider) most of the time, if signaling succeeds.

[0]: https://github.com/jselbie/stunserver

[1]: https://github.com/enobufs/stun

[2]: https://gist.github.com/mondain/b0ec1cf5f60ae726202e

[3]: https://meet.jit.si

[4]: https://whereby.com

According to Tsahi Levent-Levi, some of your biggest customers (corporation wise) are behind firewalls and need TURN.

This “last resort” is about 10% he says

I do a significant amount of work with Hospitals and secure environments (Military, etc). TURN is needed 100% of the time. P2P traffic is not allowed. All IP addresses need to be known and kept static upfront for firewall whitelisting.

This means products which help alleviate WebRTC infrastructure such as AWS Kinesis are not allowed (due to how they allocate turn servers with unknown IP addresses) and a company needs to manage their own infrastructure / TURN servers (which allows you to cherry pick where server locations are (HIPAA, country legal for what is streamed)) or accept Twillio's, or their competitors etc, large IP ranges (and don't have server location flexibility / increased commercial and market growth restrictions).

Whichever route you go down it is quite an undertaking!

P.s. Tsahi Levent-Levi is truly exceptional in this area. I highly recommend reading his blog and training courses: https://bloggeek.me/, https://webrtccourse.com/, AND he runs an amazing testing product https://www.testrtc.com. if you build your own infrastructure testRTC is a must.

If you can't do P2P, you can have an SFU forwarding the call with more features than a "dumb" TURN relay.

And it would just be STUN between each participant and the SFU deployed in the internal network for example.

Nice suggestion, we do this for certain deployments. Amazing what magic you can do in Janus, etc, :)

Why even need STUN, the SFU can join as a WebRTC participant, right? Node.js maybe

STUN is only useful if you're trying to negotiate a P2P connection, which isn't the case when using an SFU. If everything you're doing is going through an SFU then you don't need STUN.

I think the most frustrating part is that people don't know what NAT they are behind. I wish WebRTC easily told people the attributes of their NAT. Not sure if it would help production deploys, but would make learning a lot easier.

Someone contributed a really cool tool to Pion stun-nat-behavior[0] that I use a lot. It prints out NAT details. It uses the modern/correct details. I see a lot of docs that still use symmetric NAT etc.. RFC 4787 [1] suggests against all that.

[0] https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi...

[1] https://tools.ietf.org/html/rfc4787#section-3

There is also pystun in pip, a comparatively old tool so it is probably much less sophisticated than newer options, but still nice to know about:

https://pypi.org/project/pystun/

After hand-rolling my own setups and working with a few libraries, I have found https://mediasoup.org/ v3 to be the easiest library to use that still gives me the freedom to work with the architecture I want. This of course you're not using WebRTC for its p2p capabilities and are willing to scale via SFUs which is a common approach these days.

mediasoup has a remarkably well considered API and architecture.

Not necessarily, TURN servers should only be required for strict NAT. It seems that 92%* for connections are not behind strict NATs.

*https://developers.google.com/talk/libjingle/important_conce...

STUN fails under symmetric NAT, not strict NAT. That google document makes no citations of that 92% figure, but I assume that's for desktop traffic only. Pretty much all mobile/cellular connections would require TURN too.

I haven't found Verizon or AT&T to need TURN, but maybe clients on them would if connecting to each other.

In my tests with 10 people 5 needed TURN, ISPs in my country are really something special.

for proof of concepts, twilio video was really nice, everything webrtc is abstracted away. built a demo with it in 2 weeks for a potential pivot.

Xirsys and Twilio offer affordable plug-and-play TURN/STUN options, I can recommend them both.

True but there are some open source TURN servers you can use for that.

And a wrong usage of "touch and go" to boot.