Just for completeness sake this is what docs [1] state:
"For most WebRTC applications to function a server is required for relaying the traffic between peers, since a direct socket is often not possible between the clients (unless they reside on the same local network). <...>"
STUN is just for punching holes in your NAT router, and also discovering what is your public IP address. Both things will be needed for the other peer to know where to reach you. And the other way around.
Once this NAT thing has been done by both parts, and the actual communication has started directly P2P, STUN is not needed any more.
That is partially incorrect, STUN can punch a hole through even when both sides uses NAT in many cases. That is what I would classify as STUN’s main feature.
Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.
You send outgoing packets simultaneously from both sides. Causing both sides to add nat translation entry’s to their nat tables. When the packets arrive both sides already have nat translation entries and the packets go right through the nat.
Punching holes doesn't work only when network devices in between are broken or are actively preventing it.
From the network point of view it looks the same as two hosts starting an outgoing TCP connection through nat - if that works then hole punching should work too.
Not TCP. UDP - there are no connection in UDP, so the routers / firewalls don't really differentiate between a new connection and packets that happen to have the correct ip+port.
Some are trickier than others, as there are 2 IPs and 2 ports in a packet (at any point), and it can be hard to match all of them for the stricter devices, esp. on NATs that do source port randomization.
If we are still in the 90's that definition of "true p2p" would be: two computers with both having public IPs and transferring packets via TCP. But nowadays we are always behind NATs so we became less strict with the definition of what is true p2p
IPv6 is slowly taking over, hopefully in the near future being behind a NAT will be considered abnormal (just like happened with Unicode, we're around 35% = "Unicode 2009", popularity-wise).
Your p2p nodes might not be behind NAT. In a lot of populations you can rely on everyone having working v6 for example.
I think the question of what's "pure" p2p is somewhat academic. If your app uses DNS, is it p2p, isn't DNS just a distributed p2p database? Does p2p require that every aspect of your app right down to discovery is distributed among nodes running your app? Is it cheating to use an existing DHT? etc.
Careful! P2P streaming video is a (completely non obvious, according to the courts) infringement of the VirNetX patent that for example
Apple just had to pay a few billions of dollars for.
If you implement p2p video streaming chances are no company will want to touch it with a ten foot pole.
