Google 正计划将 Chrome 的 WebRTC 实现从 将当前的 SDP 格式(称为“Plan B”)转换为符合标准格式的 (“统一方案”, draft-ietf-rtcweb-jsep)。
该计划涉及 5 个阶段,以及一项暂时性的 API 功能。
谁会受到影响
在一个曲目上使用了多个音轨或多个视频轨道的用户 PeerConnection 将必须在统一方案下测试其产品, 。从非 Chrome 端点发起通话时 且已由 Chrome 回复,则优惠形式可能需要更改。用户 进行详细的 SDP 解析,并注意 msid 属性 其解析代码会采用新格式 (a=msid)。有关 以及需要更改的应用将如何 依赖项。我们认为,几乎所有只使用一个音频的应用 每个 RTCPeerConnection 一个视频轨道不会受此更改的影响。
API 功能
我们将在 RTCPeerConnection 的 RTCConfiguration 中添加一项新功能:
enum SdpSemantics {
"plan-b",
"unified-plan"
};
partial dictionary RTCConfiguration {
SdpSemantics sdpSemantics;
}
RTCConfiguration 可以传递给 RTCPeerConnection 的构造函数, 并且构建的所有优惠和应答都将采用统一计划格式。 调用 setLocalDescription 和 setRemoteDescription 也会收到 SDP 采用统一方案格式;如果采用的是旧版 Chrome 格式 除了第一个音轨和第一个视频轨道之外,其他所有轨道都将被忽略。
此外,还有一个命令行标记 (–enable-features=RTCUnifiedPlanByDefault Chrome M71 及更高版本,-enable-blink-features=RTCUnifiedPlanByDefault 早期版本),其允许将此标记的默认值设置为 “unified-plan”。
阶段
第 1 阶段:实施统一方案
在此阶段,统一方案是在实验标志下开发的 从 M65 开始提供。在第 2 阶段之前,使用 Chrome Canary 进行测试是明智之举 使用“–enable-blink-features=RTCUnifiedPlan”。
第 2 阶段:正式发布 API 功能
M69 中发布(2018 年 8 月 Beta 版,2018 年 9 月稳定版)
在此阶段,sdpSemantics 标志的默认值为“plan-b”。在 第 2 阶段:实施依赖于 SDP 格式的员工 预计会在启用统一方案的情况下运行测试,看看其应用能否正常运行 。对于支持 Firefox 的应用程序,我们希望这能成为一个非常简单的 练习:就像在 Firefox 中执行的操作一样。
可以在“chrome://flags”中更改 sdpSemantics 标志的默认值; 找到“WebRTC:默认使用统一方案 SDP 语义”功能。
第 3 阶段:切换默认设置
改用日期为 M72(2018 年 12 月推出 Beta 版,2019 年 1 月稳定版)。
在此阶段,我们将 sdpSemantics 标志的默认值更改为 “unified-plan”。发现需要更多时间 conversion,将 sdpSemantics 标志明确设置为“plan-b”,以便恢复 之前的行为
第 4 阶段:制定“计划 B”
在此阶段,将 sdpSemantics 标志设置为“plan-b”会导致异常 错误。从 M93 开始,Canary 已抛出。从 M96 开始, 在包括稳定渠道在内的所有渠道中均有展示
在此阶段,弃用试用 支持使用 Plan B 而不会出现异常,但 已于 2022 年 5 月 25 日停止运行。
第 5 阶段:从 Chromium 中移除“Plan B”
试用期结束后,系统将从 Chrome 中移除方案 B。此时, sdpSemantics 标志将被移除。尝试将其设置为“plan-b”不会 则会抛出异常,但它不会再产生任何影响。
在特殊标志或特殊 build 之后,方案 B 仍然可用,但完整的 代码移除计划将于 2022 年下半年完成。
第 6 阶段:从 WebRTC 中弃用并移除“Plan B”
Plan B 在 WebRTC 中已被标记为已弃用,但仍然可用。 移除应该在 2023 年进行。
针对统一方案准备您的应用
如需详细了解 Plan B 和统一方案的差异,以及 为实施统一计划做好准备,可能需要更新应用,请参阅 “统一方案”转换指南 (JavaScript)
对于原生 (C++) 应用,请参阅将原生/移动应用迁移到统一方案文档