3.5.3. ICE Candidate Policy (ICE 候选策略)

3.5.3. ICE Candidate Policy (ICE 候选策略)

通常, 在收集 ICE 候选时, JSEP 实现将收集所有可能形式的初始候选 -- 主机候选, 服务器反射候选和中继候选。然而, 在某些情况下, 由于隐私或相关问题, 应用程序可能希望对收集过程进行更具体的控制。例如, 可能希望仅使用中继候选, 以尽可能少地泄漏位置信息 (请记住, 此选择带来相应的运营成本)。为实现此目的, JSEP 允许应用程序限制会话中使用的 ICE 候选。请注意, 此过滤是在实现选择对应用程序允许的 IP 地址实施的任何限制之上应用的, 如 [RFC8828] 中所述。

还可能存在应用程序希望在会话处于活动状态时更改使用的候选类型的情况。一个主要示例是, 被呼叫方最初可能希望仅使用中继候选, 以避免向任意呼叫方泄漏位置信息, 但在用户表示他们想要接听呼叫后, 更改为使用所有候选 (以降低运营成本)。对于这种情况, JSEP 实现必须允许在会话中间更改候选策略, 但要受到上述与本地策略的交互的约束。

为了管理 ICE 候选策略, JSEP 实现将在每个收集阶段开始时确定当前设置。然后, 在收集阶段, 实现绝对不能将当前策略不允许的候选暴露给应用程序, 将它们用作连接性检查的来源, 或通过其他字段间接暴露它们, 例如其他 ICE 候选的 raddr/rport 属性。稍后, 如果应用程序指定了不同的策略, 应用程序可以通过 ICE 重启启动新的收集阶段来应用它。