Google 計劃將 Chrome 的 WebRTC 實作從 目前的 SDP 格式 (稱為「Plan B」) 符合標準格式 「統合計畫」和「草稿-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 格式，則 除了第一組音軌和第 1 個音軌外，其他所有音訊都會被忽略。
此外還有指令列標記 (–enable-features=RTCUnifiedPlanByDefault in Chrome M71 以上版本，-enable-blink-features=RTCUnifiedPlanByDefault )，允許將這個標記的預設值設為 「統一方案」
階段
第 1 階段：實作統合計畫
在這個階段，我們開發統一計畫，是以實驗標記為基礎開發而成 自 M65 起，我們就支援 3D 此功能在階段 2 之前，使用 Chrome Canary 進行測試最聰明 使用「–enable-blink-features=RTCUnifiedPlan」提醒
第 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 標記的預設值變更為 「統一方案」我們發現應用程式需要較多時間 將 sdpSemantics 旗標明確設為「plan-b」 先前的行為
第 4 階段：擲回「Plan B」
在此階段中，將 sdpSemantics 旗標設為「plan-b」會導致例外狀況 可能會發生的問題它已從 M93 擲回 Canary 中。自 M96 起，例外狀況 包括穩定版
在這個階段，系統會淘汰試用期 使用 Plan B 時允許存取，而不會擲回例外狀況 試用期已於 2022 年 5 月 25 日停止運作。
階段 5：將「Plan B」從 Chromium 中移除
試用期結束後，方案 B 就會從 Chrome 中移除。到目前為止 sdpSemantics 標記則會移除正在嘗試將其設為「plan-b」不會 擲回例外狀況，但不會再有任何效果。
特殊標記或特殊版本仍可提供方案 B，但完整的元件仍可使用 程式碼移除功能將於 2022 下半年生效。
第 6 階段：淘汰並移除 WebRTC 中的「方案 B」
方案 B 在 WebRTC 中已標示為已淘汰，但仍可供使用。 移除作業預計會在 2023 年生效。
為統合計畫準備應用程式
如要進一步瞭解方案 B 與統合方案的差異，以及 應用程式可能需要更新才能做好統合計畫的準備。詳情請參閱 「統合計畫」轉換指南 (JavaScript)
如果是原生 (C++) 應用程式，請參閱「將原生/行動應用程式遷移至整合計畫」文件