PROSAGA码农传奇-webrtc-两个对称NAT后面的对等体之间的ICE协商会导致需要两个TURN服务器吗？

<div class =“post-text”itemprop =“text”>
  
    它有点复杂......忍受我。只读TURN RFC是不够的，你需要上下文
    <a href="https://tools.ietf.org/html/rfc5245" rel="nofollow noreferrer">
      RFC 5245
    </A>
     在ICE上也是如此。
  
  
    以下场景是基线情况：
1）客户端A分配中继地址8.8.8.8:43739，将其发送给客户端B.
2）客户端B发送UDP包到8.8.8.8:43739
3）TURN服务器将数据包包装在一个眩晕消息中，并将其发送给客户端A.
  
  
    现在正如你所说，通常客户端B也会分配自己的中继地址并将其发送给A.为什么不是一直使用（或一半时间）？毕竟候选人的优先事项是平等的。
然而
    <a href="https://tools.ietf.org/html/rfc5245#section-5.7.2" rel="nofollow noreferrer">
      候选对优先级
    </A>
     决定选择哪一对包括一个作为决胜局的因素：
  
   <pre>
 <code>
 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.

</code>
 </pre>
  
    这意味着使用呼叫者（假设其控制代理）中继地址的对具有比具有被叫中继地址的对更高的优先级。
  
  
    此外，游戏中还有另一个候选人，用于端口客户端B用于发送到端口8.8.8.8:43739。这通常是来自本地候选人之一，并且TURN服务器看到（并且将数据指示）客户端B的公共（后置）ip。在客户端A上，这将显示为远程srflx候选者 - 其中具有比中继候选者更高的优先级，因此将被使用。
  
  
    现在，如果B落后于对称NAT（我
    
      认为
    
    ）TURN服务器将看到与客户端B不同的端口，而不是客户端A添加了权限的任何端口。这通常意味着TURN服务器将丢弃数据包，并且该对将不起作用。
  
  
    如果客户端A不在对称NAT之后，则基线过程将在另一个方向上重复。优先级略低，但在延迟方面却相同，因此用户不会注意到。
  
  
    如果两个客户端（现在我们终于遇到你要问的情况）都落后于对称NAT，那么它们都不会工作，并且将使用中继 - 中继对。这是相当罕见的（可能<1％），即使两个客户端都在不同的TURN服务器上，延迟影响通常也是微不足道的。
  
</DIV>