假设我们有两个对等体-A&B-试图通过对称NAT建立WebRTC对等连接。他们通过信令交换ICE候选。
A的公共地址：IP_A:Port_A
B的公共地址
首先，A尝试连接到B
IP_A:Port_A--->IP_B:端口_B
然而，该请求被B的NAT拒绝。只有B的STUN服务器可以在该地址连接B。
接下来轮到B了
IP_B:Port_B--->IP_A:Port_A
但在这里，难道不应该建立联系吗？因为，当A第一次向B发送请求时，对等体A的NAT表应该已经注册了对等体B的地址。因此，必须接受来自B的任何响应。但当然，这似乎并不奏效。那么，我错在哪里了？
我想我自己找到了答案。对称NAT比我想象的还要严格。看看维基百科的解释，
对称NAT
- 从相同的内部IP地址和端口到特定目标IP地址和港口的每个请求都映射到一个唯一的外部源IP地址和端口；如果同一内部主机发送数据包，即使具有相同的源地址和端口，但发送到不同的目的地，则使用不同的映射
- 只有从内部主机接收数据包的外部主机才能发回数据包
问题是，对称NAT在向对等端B发送请求时，将使用与STUN提供的IP_a:Port_a组合不同的IP:Port_a组合。但是对等端B的远程描述仍然指向IP_A:Port_A。所以，地址不匹配，连接永远不会发生。也许港口预测系统仍然可以做到这一点，我想：D
如果从映射/过滤的角度考虑，它会更有意义。其他NAT术语不能很好地描述事物的实际工作方式。我的答案来自RFC 4787和好奇者的WebRTC：连接
映射是指NAT为出站数据包分配IP/端口。远程对等方可以向该映射发送流量。筛选是关于谁可以使用这些映射的规则。
过滤和映射可以是地址相关和独立的。如果映射依赖于地址，则意味着每次联系新的IP/端口时都会创建一个新的映射。如果映射与地址无关，则意味着无论您将流量发送到哪里，它都会被重复使用。这些规则同样适用于筛选。
对于您最初的问题，似乎是地址相关映射+过滤导致了问题！
我仍然希望在你描述的设置中工作。WebRTC具有Peer Reflexive Candidates。WebRTC可以在ICE连接检查期间发现新的候选者。由于ICE经过身份验证，我们可以接受来自尚未交换的IP/端口的流量，我们只需要断言ICE用户片段和密码就是我们所期望的。