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.
Who will be affected
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.
The API feature
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”.
The Phases
Phase 1: Implement 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”.
Phase 2: Make the API feature generally available
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”.
Phase 3: Switch the 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.
Phase 4: Make “Plan B” throw
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 was throwing in all channels, including Stable.
During this phase, a Deprecation Trial was available that allowed using Plan B without the exception throwing but the trial stopped working on May 25, 2022.
Phase 5: Remove “Plan B” from Chromium
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.
Plan B is still available behind special flags or special builds but the full code removal will happen in H2, 2022.
Phase 6: Deprecate and remove ”Plan B” from WebRTC
Plan B is already marked as deprecated in WebRTC, but it is still available. Removal should happen in 2023.
Preparing Your Application For Unified Plan
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”