Both clients send a packet to a server, server sends the remote IP to both parties, both parties try to send traffic to either’s remote IP. Unless their nat firewall is evil, this should work.
That doesn't work with "symmetric" NAT, which was specified by the person you are responding to: in that case, you can't rely on even a third party to figure out the port. To the extent to which this NAT paradigm is chosen for its efficient usage of ports, this is fixable using UPnP/NAT-PMP/PCP, but 1) I've (sadly) never seen a WebRTC implementation which takes advantage of these protocols, and 2) usually this isn't chosen for it's port efficiency: it is chosen because the NAT provider is incompetent (or even actively "evil", lol), and so they are almost certainly also not going to support a port mapping mechanism.
Regardless, I'll claim that the real disagreement is more over how common symmetric NAT is: I claim it is very rare, and that the vast majority of NAT isn't symmetric... however, in another thread, the user you are responding to claims that "in [their] country" they've never seen WebRTC work at all. I'd wager that's a pretty local issue, with what probably amounts to a local oligopoly built with similar limitations, but if you live in that world it must be brutal. However, that's not WebRTC's problem: we should implement port mapping in clients and ISPs should, to put it as kindly as feels fair, "fix their shit".
> A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port.
My understanding is that it's not "required", but most of the CGNAT routers I've encountered do symmetric NAT, and they force-randomize the source port for each new connection, then keep it fixed for one external ip:port for some "session" duration, defeating traditional hole-punching.
When I've tried to build WebRTC P2P stuff I've experienced this making direct P2P WebRTC connections between CGNAT users nearly impossible, always requiring at least one node with a re-usable hole-punched public udp port or a relay server.
Such CGNAT should also be more likely to support PCP than a normal NAT. It does suck that, AFAIK, no browser has integrated support for this into their WebRTC stacks :/.
