3.7. Simulcast (联播)

3.7. Simulcast (联播)

JSEP 支持 MediaStreamTrack 的联播传输, 其中源媒体的多个编码可以在单个 "m=" 段的上下文中传输。当前的 JSEP API 设计为允许应用程序发送联播媒体, 但仅接收单个编码。这允许多用户场景, 其中每个发送客户端向服务器发送多个编码, 然后服务器为每个接收客户端选择适当的编码进行转发。

应用程序通过在 RtpSender 上配置多个编码来请求对联播的支持。在生成 offer 或 answer 时, 这些编码通过相应 "m=" 段上的 SDP 标记来指示, 如下所述。理解联播并愿意接收它的接收方也将包括 SDP 标记以指示其支持, JSEP 端点将使用这些标记来确定是否允许给定 RtpSender 使用联播。如果未协商联播支持, RtpSender 将仅使用第一个配置的编码。

请注意, 确切的联播参数由发送应用程序决定。虽然提供上述 SDP 标记以确保远程端可以接收和解复用多个联播编码, 但用于每个编码的特定分辨率和比特率纯粹是 JSEP 中的发送端决策。

JSEP 目前不提供配置联播接收的机制。这意味着如果远程端点提供联播, 则 JSEP 端点生成的 answer 将不会指示支持接收联播, 因此远程端点将仅为每个 "m=" 段发送单个编码。

此外, JSEP 不提供处理来自 JSEP 端点请求联播的传入 offer 的机制。这意味着在 JSEP 端点接收初始 offer 的情况下设置联播需要带外信令或 SDP 检查。然而, 在 JSEP 端点在其初始 offer 中设置联播的情况下, 任何已建立的联播流将在收到传入的 re-offer 后继续工作。本规范的未来版本可能会添加其他 API 来处理传入初始 offer 场景。

当使用 JSEP 从 RtpSender 传输多个编码时, 使用 [RFC8853] 和 [RFC8851] 中的技术。具体来说, 当为 RtpSender 配置了多个编码时, RtpSender 的 "m=" 段将包括 "a=simulcast" 属性, 如 [RFC8853] 第 5.1 节中所定义, 具有列出每个所需编码的 "send" 联播流描述, 并且没有 "recv" 联播流描述。"m=" 段还将包括每个编码的 "a=rid" 属性, 如 [RFC8851] 第 4 节中所指定; 使用限制标识符 (RIDs, 也称为 rid-ids 或 RtpStreamIds) 允许各个编码被消除歧义, 即使它们都是同一 "m=" 段的一部分。