4.1.1. Constructor (构造函数)

4.1.1. Constructor (构造函数)

PeerConnection 构造函数允许应用程序为媒体会话指定全局参数, 例如在收集候选者时要使用的 STUN/TURN 服务器和凭据, 以及初始 ICE 候选者策略和池大小, 还有要使用的捆绑策略。

如果指定了 ICE 候选者策略, 它将按照第 3.5.3 节中的描述运行, 导致 JSEP 实现仅向应用程序提供允许的候选者(包括任何实现内部过滤), 并且仅使用这些候选者进行连接检查。可用策略集如下:

all: 将收集和使用实现策略允许的所有候选者。

relay: 除中继候选者外的所有候选者都将被过滤掉。这会模糊远程对等方可能从接收到的候选者中确定的位置信息。根据应用程序部署和选择中继服务器的方式, 这可能会将位置模糊到城市级别甚至全球级别。

默认 ICE 候选者策略必须设置为 "all", 因为这通常是所需的策略, 并且通常也会显著减少应用程序 TURN 服务器资源的使用。

如果为 ICE 候选者池指定了大小, 这表示要为其预收集候选者的 ICE 组件数量。由于预收集会导致在可能很长的时间内利用 STUN/TURN 服务器资源, 因此这必须仅在应用程序请求时发生, 因此默认候选者池大小必须为零。

应用程序可以指定其关于使用捆绑的首选策略, 捆绑是在 [RFC8843] 中定义的多路复用机制。无论策略如何, 应用程序将始终尝试将捆绑协商到单个传输上, 并将在所有 "m=" 部分提供单个捆绑组; 使用此单个传输取决于应答者接受捆绑。但是, 通过从下面的列表中指定策略, 应用程序可以精确控制它将如何积极地尝试将媒体流捆绑在一起, 这会影响它如何与不支持捆绑的端点互操作。在与不支持捆绑的端点协商时, 只有未标记为仅捆绑的流才会建立。

可用策略集如下:

balanced: 每种类型(音频, 视频或应用程序)的第一个 "m=" 部分将包含传输参数, 这将允许应答者解绑该部分。每种类型的第二个和任何后续 "m=" 部分将被标记为仅捆绑。结果是, 如果有 N 个不同的媒体类型, 则将为 N 个媒体流收集候选者。此策略平衡了多路复用的愿望与确保基本音频和视频仍然可以在传统情况下协商的需求。当作为应答者时, 如果 offer 中没有捆绑组, 实现将拒绝除每种类型的第一个 "m=" 部分之外的所有部分。

max-compat: 所有 "m=" 部分都将包含传输参数; 没有部分将被标记为仅捆绑。此策略将允许所有流被不支持捆绑的端点接收, 但需要为每个媒体流收集单独的候选者。

max-bundle: 只有第一个 "m=" 部分将包含传输参数; 除第一个流之外的所有流都将被标记为仅捆绑。此策略旨在最小化候选者收集并最大化多路复用, 但代价是与传统端点的兼容性较低。当作为应答者时, 实现将拒绝除第一个 "m=" 部分之外的任何 "m=" 部分, 除非它们与该 "m=" 部分在同一个捆绑组中。

由于它在性能和与传统端点的兼容性之间提供了最佳权衡, 默认捆绑策略必须设置为 "balanced"。

应用程序可以使用以下策略之一指定其关于使用 RTP/RTCP 多路复用 [RFC5761] 的首选策略:

negotiate: JSEP 实现将收集 RTP 和 RTCP 候选者, 但也会提供 "a=rtcp-mux", 从而允许与多路复用或非多路复用端点兼容。

require: JSEP 实现将仅收集 RTP 候选者, 并将在其生成的 offer 中的任何新 "m=" 部分插入 "a=rtcp-mux-only" 指示。这会使 offerer 需要收集的候选者数量减半。应用不包含 "a=rtcp-mux" 属性的 "m=" 部分的描述将导致返回错误。

默认多路复用策略必须设置为 "require"。实现可以选择拒绝应用程序将多路复用策略设置为 "negotiate" 的尝试。