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 谈判没那么简单…… 为了执行 ICE，UA 必须识别所有候选地址，即传输地址。传输地址是特定传输协议的 IP 地址和端口的组合。候选人分为三类：

• Host Candidate – 与 UA 本地接口关联的传输地址
• 中继候选 – 与 TURN 服务器关联的传输地址（只能从 TURN 服务器获取）
• Server Reflexive Candidate – NAT 公共端的转换地址（从 STUN 服务器或 TURN 服务器获得）

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

ICE 指定其中一名代理人为“控制代理人”，另一名代理人为“受控代理人”。控制代理使用有效的候选对来提名一对用于媒体。有两种提名方式可供选择：

• 常规提名 继续进行检查，直到至少有一对有效的候选人。控制代理从有​​效对中挑选，并在该对上发送第二个 STUN 请求，并带有一个标志，告诉对等方这是指定使用的那个。
• Aggressive Nomination 一旦第一次检查成功，该媒体流的 ICE 处理完成并且不需要第二次 STUN 请求，每次 STUN 请求都会发送提名标志。

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

• Frozen 这对只能在处于等待状态后才能检查。要进入等待状态，必须先通过其他一些检查。
• 等待 一旦这是检查列表中优先级最高的对，就会执行检查。
• In-Progress 已为该货币对发送支票，交易正在进行中
• Succeed 配对检查的成功结果。
• Failed 配对检查的失败结果。

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

参考：

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

Answer 2

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

始终使用 TURN，是一种选择，但有点极端。