WebRTC - TURN和ICE功能

Question

我正在尝试理解WebRTC的概念。正如我在一些描述中所发现的那样（例如http://www.innoarchitech.com/content/images/2015/02/webrtc-complete-diagram.png），有这样一种连接方式：

1. 调用STUN，获取您的IP：端口地址。
2. 从TURN获取一些频道 - 通过该频道，您可以将信息发送给其他同行。
3. 发送给其他ICE候选人。
4. 与其他同伴接受ICE候选人 - 开始通话。

问题是，我们需要ICE候选人做什么？我们知道我们的IP，我们可以将它发送给TURN，因此也可以发送给其他同行，并且在TURN上我们与其他同行有很好的联系 - 所以我们不必担心NAT。为什么除了我们发送ICE候选人（为什么很多？），以及为什么我们需要使用它们？

Answer 1

我们在这里有3个主要概念：

• ICE
• TURN
• STUN

ICE谈判并不那么简单...... 为了执行ICE，UA必须识别所有地址候选者，传输地址。传输地址是特定传输协议的IP地址和端口的组合。候选人有三种类型：

• 主机候选人 - 与UA本地接口关联的传输地址
• Relayed Candidate - 与TURN服务器关联的传输地址（只能从TURN服务器获取）
• Server Reflexive Candidate - NAT公共端的翻译地址（从STUN服务器或TURN服务器获取）

在UA1收集了所有候选人之后，它按照从最高到最低的优先级顺序排列它们，并将它们发送到SDP提供消息中的属性中的UA2。 UA2执行相同的候选人聚会并发送SDP响应及其候选人列表。每个UA取两个候选列表并将它们配对以形成候选对。每个UA将这些收集到检查列表中并安排连接检查，STUN请求/响应事务，以查看哪些对工作。图3显示了构成UA检查列表的候选对的组成部分。

ICE将其中一个代理分配为“控制代理”，另一个代理分配为“受控代理”。控制代理使用有效候选对来指定一对用于媒体。有两种提名方法可以使用：

• 定期提名检查一直持续到至少有一个有效候选对。控制代理从有​​效对中挑选，并在该对上发送第二个STUN请求，并带有一个标志，告诉对等方这是一个被提名使用的请求。
• 积极提名提名标志随每个STUN请求一起发送，一旦第一次检查成功，该媒体流的ICE处理结束，不需要第二次STUN请求。

清单中的每个候选对都有一个与之关联的状态。一旦计算了检查清单，就由UA分配状态。有五种可能的状态：

• 冻结此对只能在处于等待状态后进行检查。要进入等待状态，其他一些检查必须先成功。
• 等待一旦这是检查表中的最高优先级对，就会执行检查。
• 正在进行已为此对发送了一项检查并且交易正在进行中
• 成功检查成功结果。
• 对检查失败的结果失败。

以下链接包含ICE流程的更多信息和图表。

参考：

• http://www.vocal.com/networking/ice-interactive-connectivity-establishment/
• RFC https://tools.ietf.org/html/rfc5245#page-9

Answer 2

当无法建立直接对等连接时，TURN通常仅用作后备。后者是困难的部分，也是ICE的用途。

总是使用TURN，这是一个选项，但有点边缘情况。