Google 计划在未来几个季度将 Chrome 的 WebRTC 实现从当前的 SDP 格式（称为“Plan B”）过渡到符合标准的格式（“Unified Plan”，并草拟 ietf-rtcweb-jsep）。
该计划包含 5 个阶段，且需要使用一个瞬时 API 功能。
谁会受到影响
在单个 ConnectionConnection 上使用多个音轨或多个视频轨道的用户必须在统一方案下测试其产品，并相应地做出调整。如果调用从非 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 采用统一计划格式；如果 SDP 采用旧版 Chrome 格式，则系统会忽略除第一个音轨和第一个视频轨道之外的所有音频。
此外，还有一个命令行标记（在 Chrome M71 及更高版本中为 -enable-features=RTCUnifiedPlanByDefault，在较低版本中为 –enable-blink-features=RTCUnifiedPlanByDefault），可用于将此标志的默认值设置为“unified-plan”。
阶段
第 1 阶段：实施统一计划
在此阶段，统一计划是在自 M65 开始推出的一个实验标志后面开发的。在第 2 阶段之前，最明智的做法是使用“–enable-blink-features=RTCUnifiedPlan”使用 Chrome Canary 版进行测试。
第 2 阶段：全面推出 API 功能
在 M69（2018 年 8 月 Beta 版，2018 年 9 月稳定版）中发布
在此阶段，sdpSemantics 标志的默认值为“plan-b”。在第 2 阶段中，具有依赖于 SDP 格式的实现的用户应运行测试，以查看其在应用使用统一计划时能否正常工作。对于支持 Firefox 的应用，我们希望这是非常简单的做法：就像使用 Firefox 一样。
sdpSemantics 标志的默认值可在“chrome://flags”中更改；查找“WebRTC：默认使用统一计划 SDP 语义”功能。
第 3 阶段：切换默认设置
改用 M72（Beta 版，2018 年 12 月，稳定，2019 年 1 月）这一天。
在此阶段，我们将 sdpSemantics 标志的默认值更改为“unified-plan”。发现应用需要更多时间来将 sdpSemantics 标志显式设置为“plan-b”才能恢复之前的行为。
第 4 阶段：抛出“Plan B”（计划 B）
在此阶段，将 sdpSemantics 标志设置为“plan-b”会导致抛出异常。从 M93 开始，它已在 Canary 中抛出异常。从 M96 开始，所有稳定版（包括稳定版）都会抛出异常。
在此阶段，我们提供了弃用试用，允许在未出现异常的情况下使用方案 B，但试用已于 2022 年 5 月 25 日停止运行。
第 5 阶段：从 Chromium 中移除“方案 B”
试用期结束后，方案 B 将从 Chrome 中移除。此时，sdpSemantics 标志会被移除。尝试将其设置为“plan-b”不会抛出异常，但不会再有任何效果。
计划 B 仍然适用于特殊标记或特殊 build，但完整的代码移除过程将于 2022 年下半年完成。
第 6 阶段：弃用并移除 WebRTC 的“方案 B”
方案 B 在 WebRTC 中已标记为已弃用，但仍可用。移除操作应该会在 2023 年生效。
针对统一计划准备应用
如需详细了解方案 B 和统一方案的差异，以及您的应用可能需要如何更新以准备统一方案，请参阅“统一方案”过渡指南 (JavaScript)
对于原生 (C++) 应用，请参阅“将您的原生/移动应用迁移到统一方案”一文