I agree that WebRTC is super exciting, but if you want to deploy it into production, you need to have a STUN server and a TURN server.
Until/unless we've all moved to IPv6 without any NAT, we'll be stuck needing STUN and TURN to make it work.
Until/unless we've all moved to IPv6 without any NAT, we'll be stuck needing STUN and TURN to make it work.
TURN is of course an entirely different beast because it's proxying all the data between clients. It's also where some more complex video stuff happens potentially. The good news is that there are solid, open source TURN servers available to run on your own hardware. The downside is that running those servers for non-trivial amounts of clients gets pretty resource intensive pretty quick.
It's typically when ICE can't determine the first few steps (eg your public address) that you need STUN to help you out.
TURN tends to be needed in hostile networking situations like double NAT'd networks or very restricted networks like hospitals.
And the problem isn’t with WebRTC, it’s with the current infrastructure of the net that prevents some clients from just communicating directly without some element of centralization. And some of it’s our own fault.
A cynical way of looking at it might be that WebRTC is being allowed because it helps scale the web while still being dependent on a central weak link of control.
But it is what it is.
For peer to peer, you'd have a tough time avoiding STUN/TURN anyhow.
hell will freeze before that happens.
This is the bread and butter of ISP. Without NAT they lose too many revenue sources.
They will hold to their NATs forever, claiming something like user security. While pushing for IPv6 to reduce their operating costs (those IPv4 costs add up)