Google 计划在接下来的几个季度内，将 Chrome 的 WebRTC 实现从当前的 SDP 格式（称为“方案 B”）过渡到符合标准的格式（称为“统一方案”，即 draft-ietf-rtcweb-jsep）。
该计划涉及 5 个阶段和 1 项暂时性 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 格式，则除了第一个音轨和第一个视频轨之外，所有其他轨道都会被忽略。
此外，还有一个命令行标志（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 的操作即可。
您可以在“chrome://flags”中更改 sdpSemantics 标志的默认值；找到“WebRTC：默认使用统一方案 SDP 语义”功能。
第 3 阶段：切换默认设置
切换日期为 M72（2018 年 12 月为 Beta 版，2019 年 1 月为稳定版）。
在此阶段，我们将 sdpSemantics 标志的默认值更改为“unified-plan”。如果应用发现自己需要更多时间进行转换，则会将 sdpSemantics 标志明确设置为“plan-b”，以恢复之前的行为。
第 4 阶段：让“Plan B”抛出
在此阶段，将 sdpSemantics 标志设置为“plan-b”会导致抛出异常。从 M93 开始，它一直在 Canary 中抛出。从 M96 开始，此异常会在所有渠道（包括稳定版）中抛出。
在此阶段，我们提供了弃用试用版，让您可以在不抛出异常的情况下使用备用方案，但该试用版已于 2022 年 5 月 25 日停用。
第 5 阶段：从 Chromium 中移除“Plan B”
试用期结束后，Chrome 将移除“备用方案”。此时，sdpSemantics 标志将被移除。尝试将其设置为“plan-b”不会抛出异常，但将不再有任何影响。
通过特殊标志或特殊 build 仍可使用备用方案 B，但我们将于 2022 年下半年完全移除该代码。
第 6 阶段：从 WebRTC 中弃用并移除“Plan B”
在 WebRTC 中，方案 B 已被标记为已废弃，但仍可用。 该功能应该会在 2023 年移除。
为统一方案准备应用
如需详细了解“方案 B”和“统一方案”之间的差异，以及为准备好采用“统一方案”可能需要更新应用的方式，请参阅“统一方案”过渡指南 (JavaScript)
对于原生 (C++) 应用，请参阅文档“将原生/移动应用迁移到统一方案”