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++) 应用，请参阅将原生/移动应用迁移到统一方案文档