[...] using STUN. I'm convinced no one actually knows what STUN is. I always see these references to STUN in P2P contexts. STUN is just a shitty protocol that

[...] using STUN. I'm convinced no one actually knows what STUN is. I always see these references to STUN in P2P contexts. STUN is just a shitty protocol that shows what your external IP and port is. That's literally it. You can't use it by itself to do any kind of NAT traversal. There is an RFC that lists how to use STUN lookups to enumerate a NAT (but its far from definitive) and anything useful requires looking at other papers about NATs to apply the results. This is what you would need to do before you did hole punching. [...] webrtc. See, the thing about webrtc is: its a vague, low-quality spec. It uses over-simplified descriptions of peers, NATs, and hole punching algorithms, over a design that would provide better reachability. But the approach that webrtc takes is to just fallback to TURN for edge-cases (TURN is a proxy protocol.) The problem with that is it's likely that TURN will be used significantly for things like mobile devices due to symmetric NATs. This means maintaining infrastructure for your 'p2p' system when you don't have to. Overall, I am a fan of the fact that webrtc is in the browser and its 'standardized' but I think that the actual implementation of what its trying to achieve doesn't work well for the real Internet.