没有具有公共IP的ICE候选人，但WebRTC有时仍然可以工作

我们正在A、B和C三个位置测试WebRTC

A和C是ADSL，一个在家，一个在办公楼。B是一个公司的静态IP直连，带有公司防火墙和一些端口过滤规则

结果是：A可以与两者连接，但B和C只能与A连接

所以我们检查了他们的浏览器控制台输出。A和C可以获得内部和公共IPv4候选（192.168.1.xxx和123.34.xxx.xxx）。B可以找到4个ICE候选、2个内部IPv4候选（10.0.xxx.xxx）和2个IPv6候选（不确定IPv6地址是内部的还是公共的）

因此，问题是：

是什么阻止B从STUN服务器获取公共IP候选？是某个被公司防火墙阻止的端口吗

B永远无法获得公共IP候选人，A如何与他联系？A和B可以一直使用WebRTC

为什么C不能与B连接？或者A和C之间有什么不同？他们都使用ADSL，光纤调制解调器到TPLINK路由器（PPPOE拨号+默认DHCP）到计算机，完全相同

---

谢谢

经过进一步研究，C没有使用ADSL。它实际上是一个带有防火墙的办公楼。这就是为什么C不能和B连接，但A可以

对于这个错误，客户“认为”他们知道自己的网络细节

多亏了泰勒，你才是对的。只有一个开放的网络才能使WebRTC工作

经过数小时的研究，我发现唯一的解决办法是使用TURN服务器。所以我想这个问题现在可以结束了。

第2题的一个可能答案是A可以从B接收数据包，因为B有A的公共地址。然后，从接收到的数据包中，A生成一个“对等自反”候选，并且能够将数据包发送回它从中接收数据包的相同地址。你可以登记一下chrome://webrtc-internals （“对等自反”表示“prflx”远程候选类型）。