0

我们有一个 TURN 队列，它在 AWS 区域US-EAST-1和US-WEST-2.

乌克兰的客户正在尝试连接到英国的对等方。客户端和对等方都位于对称 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 与上面一样发生。

  1. 对等方永远不会收到来自 TURN 服务器的响应，该响应包含XOR-PEER-ADDRESS.

  2. 由于是对称 NAT，因此呼叫失败。

这只发生在特定的对等点上，因为我们看到US-WEST-2即使在这一刻也发生了数千个 prflx / 中继调用。我没有任何理由相信 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

最终通话超时。

4

0 回答 0