Google 計劃在接下來的幾季內，將 Chrome 的 WebRTC 實作從目前的 SDP 格式 (稱為「方案 B」) 轉換為標準法規遵循格式 (「整合計劃」，草案 -tf-rtcweb-jsep)。
這個方案包含 5 個階段和一個暫時性 API 功能。
受影響的對象
如果使用者在單一音軌中使用多個音軌或擁有多個視訊軌，就必須在統一方案中測試產品，並據此調整方式。如果呼叫是從非 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 階段之前，最好使用「–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: Default Use Unified Plan SDP Semantics」這項功能。
階段 3：切換預設值
切換日期是 M72（2018 年 12 月 Beta，2019 年 1 月穩定）。
在這個階段中，我們將 sdpSemantics 標記的預設值為「unified-plan」。因此，如果應用程式發現需要更多時間進行轉換，請將 sdpSemantics 標記明確設定為「plan-b」，以便復原先前的行為。
第 4 階段：以「B 方案」宣傳
在這個階段中，將 sdpSemantics 標記設為「plan-b」會導致例外狀況出現。從 M93 版開始，自 M96 起，所有例外 包括所有穩定版
在這個階段，我們可以使用淘汰版，讓方案 B 可以正常使用，但試用已在 2022 年 5 月 25 日停止運作。
第 5 階段：將「Plan B」從 Chromium 中移除
試用期結束後，方案 B 將會從 Chrome 中移除。此時，系統會移除 sdpSemantics 標記。嘗試將其設定為「plan-b」(方案 b) 並不會造成例外，但將不再有任何影響。
計畫 B 仍可在特殊旗標或特殊版本後方使用，但完整程式碼將於 2022 年下半年推出。
第 6 階段：淘汰 WebRTC 中的「Plan B」並將其移除
已在 BRTC 中將方案 B 標示為已淘汰，但仍可以繼續使用。 系統將於 2023 年移除相關內容。
應用程式使用統一計劃的準備作業
如要進一步瞭解方案 B 與統一方案的差異，以及更新您的應用程式時需要更新哪些項目，請參閱「統合計劃」轉換指南 (JavaScript)。
如果是原生 (C++) 應用程式，請參閱「將原生/行動應用程式遷移至統一企劃書」文件。