STUN 绑定（ICE 连接检查）特定对等点失败

Question

我们有一个在 AWS 区域 US-EAST-1 和 US-WEST-2 中存在的 TURN 队列。

乌克兰的一个客户端正在尝试连接到英国的对等点。客户端和对等方都位于对称 NAT 之后。

客户端无权访问 TURN 凭据。 对等方确实有权访问 TURN 凭据。

结果是：

客户：

host
server reflexive

同行：

host
server reflexive
relay

我们的 TURN 队列仅在 IP 地址中创建权限，并忽略端口变化。

成功案例：客户通过US-EAST-1发起呼叫。

1. 客户端收集其主机和服务器反射候选。将它们发送给对等方。
2. Peer 接收客户端候选，并收集自己的主机、服务器反射和中继候选。将它们发送给客户端。
3. 客户端发送一个 STUN 绑定到中继传输地址。
4. TURN 中继看到请求，为其附加一个 XOR-PEER-ADDRESS 并通过 DATA 指示将其转发给客户端。
5. 客户端看到请求，生成响应，并通过 SEND 指示将其发送到中继。
6. 中继接受消息并将其转发给对等方。
7. 对等方解开 XOR-PEER-ADDRESS，确定它是 peer reflexive 候选并将活动对设置为 local: prflx | remote: relay。
8. 媒体流动，每个人都很开心。

失败案例：客户端通过 US-WEST-2 发起呼叫。

第 1 步到第 6 步的发生与上述相同。

7. 对等方永远不会收到来自 TURN 服务器的响应，其中包含 XOR-PEER-ADDRESS 中的对等方反身候选者。

8. 由于是对称 NAT，调用失败。

这只会发生在特定的对等点上，因为即使此时此刻，我们也看到 US-WEST-2 中发生了数千个 prflx/relay 调用。我没有任何理由相信 TURN 服务器未能发送响应。

用于传出的安全组是完全允许的（对于 IPv4/6）并且是相同的。

0.0.0.0/0
::/0

两个地区的配置文件是相同的。就我的详尽搜索而言，这两个调用之间的唯一区别是调用所通过的 AWS 区域。我可能会弄错，但我已经梳理了我能想到的每一个小细节。

我什至通过对称 NAT 自己测试了 US-EAST-1 和 US-WEST-2，并且能够建立 prflx-relay 调用。

有没有人遇到过这种情况？

---

绑定请求（peer -> TURN）

1094    5.262769    192.168.1.202   TURN_IP_ADDRESS STUN    
170 Binding Request user: 0kZJvRw4xieMyZWtgrfSvGh6EzfhRzxP:5Vi8

转向客户端数据指示：

3942    8.729590    TURN_IP_ADDRESS  192.168.1.202   STUN    
150 Binding Success Response XOR-MAPPED-ADDRESS: 1.2.3.4:9976 user: ttsEVBZnkpBftWENErHh+3HkiEj3xoU2:8/DZ

客户端收到消息：

3272    7.757723    TURN_IP_ADDRESS 192.168.88.108  STUN    
250 Data Indication XOR-PEER-ADDRESS: 1.2.3.4:9976

客户端创建权限：

CreatePermission Request XOR-PEER-ADDRESS: 1.2.3.4:9976 with nonce realm: amazonaws.com user: { USERNAME }

客户回应：

3358    7.930904    192.168.88.108  TURN_IP_ADDRESS STUN    
186 Send Indication XOR-PEER-ADDRESS: 1.2.3.4:9976

转向同行回应：

nothing received by the peer

客户端继续收到以下数据指示：

3272    7.757723    TURN_IP_ADDRESS 192.168.88.108  STUN    
250 Data Indication XOR-PEER-ADDRESS: 1.2.3.4:9976

并继续回复：

3358    7.930904    192.168.88.108  TURN_IP_ADDRESS STUN    
186 Send Indication XOR-PEER-ADDRESS: 1.2.3.4: 9976

最终调用超时。