Google is planning to transition Chrome’s WebRTC implementation from the current SDP format (called “Plan B”) to a standards conformant format (“Unified Plan”, draft-ietf-rtcweb-jsep) over the next couple of quarters.
The plan involves 5 phases, and one transient API feature.
谁会受到影响
People who use multiple audio tracks or multiple video tracks on a single PeerConnection will have to test their product under Unified Plan, and adapt accordingly. In the case where a call is initiated from a non-Chrome endpoint and replied to by Chrome, the form of the offer may have to change. People who do detailed SDP parsing and care about msid attributes will have to check that their parsing code picks up the new format (a=msid). The details on whether changes will be needed and how the apps need to change will be application dependent. We think that almost all applications that use only a single audio and a single video track per RTCPeerConnection will be unaffected by the change.
API 功能
We are adding one new feature to the RTCPeerConnection’s RTCConfiguration:
enum SdpSemantics {
"plan-b",
"unified-plan"
};
partial dictionary RTCConfiguration {
SdpSemantics sdpSemantics;
}
The RTCConfiguration can be passed to the constructor of an RTCPeerConnection, and all offers and answers constructed will be in the Unified Plan format. Calls to setLocalDescription and setRemoteDescription will also expect the SDP to be in the Unified Plan format; if it is in the legacy Chrome format, then all but the first audio track and the first video track will be ignored.
There’s also a command line flag (–enable-features=RTCUnifiedPlanByDefault in Chrome M71 and above, –enable-blink-features=RTCUnifiedPlanByDefault in earlier versions) that allows the default value of this flag to be set to “unified-plan”.
阶段
第一阶段：实施统一计划
In this phase, Unified Plan was being developed behind an experimentation flag available since M65. Until phase 2, it was wisest to test with Chrome Canary using “–enable-blink-features=RTCUnifiedPlan”.
第 2 阶段：使 API 功能普遍可用
Released in M69 (beta August 2018, stable September 2018)
In this phase, the default value of the sdpSemantics flag was “plan-b”. In Phase 2, people who had implementations that depended on the SDP format were expected to run tests to see if their applications work when Unified Plan is in use. For applications that support Firefox, we expect this to be a very simple exercise: just do as you would do for Firefox.
The default value of the sdpSemantics flag can be changed in “chrome://flags”; look for the feature “WebRTC: Use Unified Plan SDP Semantics by default”.
第三阶段：切换默认
The date for the switch was M72 (beta December 2018, stable January 2019).
In this phase, we changed the default value of the sdpSemantics flag to “unified-plan”. Applications that discovered that they needed more time to convert set the sdpSemantics flag explicitly to “plan-b” in order to recover previous behaviour.
第 4 阶段：制定“B 计划”
In this phase, setting the sdpSemantics flag to "plan-b" results in an exception being thrown. It has been throwing in Canary from M93. As of M96, the exception is throwing in both Canary and Beta. The plan is to make it throw in Stable as well. We are monitoring usage of Plan B.
During this phase, a Deprecation Trial is available that allows using Plan B without the exception throwing. This trial stops working on 29 December, 2021.
第 5 阶段：移除“B 计划”
After the trial has ended, Plan B will be removed from Chrome. At this point, the sdpSemantics flag will be removed. Attempting to set it to "plan-b" will not throw an exception, but it will no longer have any effect.
准备统一计划的申请
For detailed information about Plan B and Unified Plan differences and how your application may need to be updated in preparation for Unified plan, see the “Unified Plan” Transition Guide (JavaScript)
For native (C++) applications, see the document “Migrating your native/mobile application to Unified Plan”