我阅读了RFC6577和RFC8445，但我觉得TURN 的使用方式与ICE的使用方式之间有些脱节 实际上 使用了relay candidates。
TURN RFC描述了使用单个TURN服务器在客户端和对等方之间传送数据。 TURN服务器上的transport address通过TURN消息接受来自客户端的数据流，而relayed transport address通过UDP接受来自对等方的数据流。这听起来很棒-一台TURN服务器和双向数据流。
但是，在阅读有关ICE的文章时，我觉得这从未发生过。主叫方和被叫方都在潜在的两个TURN服务器上独立分配，然后分别发送各自的relayed transport addresses。更像是I can be reached via this relayed transport address之类的东西。然后进行连通性检查，因此最终在这里使用了两个TURN服务器，其中数据仅沿一个方向流经分配给每个TURN服务器的每个参与者的relayed transport address。
这是真的吗？
在TURN RFC中，它表示以下内容：
客户端可以安排服务器与来回中继数据包 其他某些主机（称为对等主机），可以控制 中继已完成。客户端通过获取IP地址来实现此目的，并且 服务器上的端口，称为中继传输地址。当同龄人 将数据包发送到中继的传输地址，服务器中继 数据包到客户端。当客户端发送数据包到 服务器，服务器使用中继的服务器将其中继到适当的对等方 运输地址作为来源。
但是，我看不到通过ICE协商，数据将一直通过从客户端到对等方的传输地址的情况。呼叫者和被呼叫者都在TURN服务器上独立分配，并互相发送relayed transport addresses。
基本上，TURN 可以进行双向数据流，但是在两个对称NAT之间使用ICE，它 不会 。这是正确的吗？
答案 0 :(得分：2)
有点复杂...。仅阅读TURN RFC是不够的，您还需要ICE上RFC 5245的上下文。
以下情况是基准情况： 1）客户端A分配一个中继地址8.8.8.8:43739，发送给客户端B 2）客户端B向8.8.8.8:43739发送UDP数据包 3）TURN服务器将数据包包装成一条电击消息，并将其发送到客户端A
现在，正如您所说，客户端B通常还会分配其自己的中继地址，并将其发送给A。为什么不一直使用该地址（或一半时间）？候选人的优先权毕竟是平等的。 但是，candidate pair priority（决定选择哪对）中包含一个因素，可以决定平局：
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G>D?1:0 is an expression whose value is 1 if G is greater than
D, and 0 otherwise.
这意味着使用呼叫者（假设是控制代理）中继地址的那对的优先级高于具有被呼叫者中继地址的那对。
此外，这里游戏中还有另一个候选者，客户端B用来将其发送到端口8.8.8.8:43739的端口。这通常来自本地候选者之一，而TURN服务器会看到（并将其放入数据指示中）客户端B的公开IP（后NAT）。在客户端A上，这将显示为远程srflx候选者-具有比中继候选人更高的优先级，因此将被使用。
现在，如果B在对称NAT（我认为）之后，那么TURN服务器将看到与客户端B不同的端口，而不是客户端A添加了权限的端口。通常，这将意味着TURN服务器将丢弃该数据包，而该对将无法工作。
如果客户端A不在对称NAT之后，则将在另一个方向上重复基准过程。优先级稍低，但在延迟方面相同，因此用户不会注意到。
如果两个客户端（现在我们终于要问您所要解决的问题）都在对称NAT的后面，则两者都不起作用，并且将使用中继中继对。这相当罕见（可能<1％），并且即使两个客户端都位于不同的TURN服务器上，对延迟的影响通常也很小。