Ripping off the band-aid: Chrome’s shift to “unified plan”
Posted On March 18, 2019 by Zed Tan in Blog, Ecosystem, SkylinkJS
Google released the Chrome 72 update earlier on 29th January this year, which switched the browser’s default SDP (Session Description Protocol) format from “plan-b” to “unified plan”. This meant that developers, whose applications worked with multiple media tracks and didn’t use the “unified plan” SDP format, found their applications breaking.
The Chrome 72 update doesn’t force you to switch to the “unified plan” just yet; you can set a
sdpSemantics = "plan-b"). This explicitly tells Chrome to continue expecting SDP messages to be sent in “plan-b”, buying you and your codebase some time to make the pivot to “unified plan”. Google will eventually remove “plan-b” from Chrome completely, forcing all developers to use“unified plan” SDP messages. But meanwhile, they’re monitoring the use of the
sdpSemantics = “plan-b” flag — from there, Google will determine a date when they’ll execute phase 4 of the “unified plan” transition where they’ll remove “plan-b” from Chrome altogether.
But why the change?
Compliance with standards
This means that to be compliant with the WebRTC specification, we should be using the “unified plan” SDP format when writing WebRTC implementations.
But Chrome — the world’s most-used browser — didn’t support the “unified plan” until late 2018 when they released Chrome 69. Firefox, on the other hand, has supported it since mid-2015. (Apple adds experimental support to Safari in 12.1.) Web development shops building WebRTC applications have to build for Chrome first, which means that to adopt the “unified plan” they had to use a tool like sdp-interop to coerce their SDP messages into “plan-b” format if they wanted their WebRTC implementation to work with Chrome browsers.
Difference between “plan-b” and “unified plan”
SDP [RFC 4566] is a specification for how an application should describe media being sent from point to point across a network. SDP messages for WebRTC sessions contain information that describes individual media tracks (video, audio, data channels etc.) that we want to stream from one WebRTC peer to another.
Media tracks are described by “m= lines”, a part of an SDP-formatted message that starts with “m=” to describe the type of media being transmitted, its format, and how it is transmitted (what transport is used). What this ends up doing is that it assigns a separate transport (and hence, a separate connection) for each media track being streamed, which becomes a problem because the number of connections created during a session can quickly get out of control.
Both “plan-b” and “unified plan” try to solve this problem by extending the SDP specification to allow a session to use one transport (and hence one peer connection) for a group of media tracks instead of one transport per track.
Where “plan-b” and the “unified” differ is how this grouping is done.
Grouping media descriptors
“Plan-b” assumes all media tracks that share a media type also share a single transport, and hence shovels them into a single m= line. This means that with “plan-b”, you’ll end up with one connection per media type being streamed.
“Unified plan”, on the other hand, uses another extension to the SDP specification called BUNDLE (which, despite how it’s stylized, doesn’t stand for anything except the word “bundle”) which allows you to group m= lines in BUNDLE groups, which are then assigned a single transport.
Problems with interoperability
This becomes a problem when you have an endpoint expecting a “unified-plan” SDP-formatted message, but receives a “plan-b” SDP-formatted message, e.g. when a peer on a Chrome 71 browser connects to a peer on any Firefox browser updated since 2015. In this case, the peer using Firefox would only be able to see the first tracks of each m= line in a “plan-b” formatted SDP message; Firefox ignores the rest of the tracks in the m= line because it expects to find only one media track in it.
Why not just keep both?
Allowing developers to switch between the two SDP formats is the surest way to keep the WebRTC development community fragmented. Pulling off the band-aid now by forcing web developers who want their web applications to work on Chrome to comply with JSEP, and removes one more obstacle on the road toward moving everyone toward WebRTC 1.0.
What’s Temasys doing about it?
At Temasys, we’ve built the Skylink Platform which provides an API layer on top of vanilla WebRTC. When you use our SDKs, this layer gives you a stable API on which you can build your WebRTC applications, while taking advantage of our proprietary signaling solution and NAT traversal services (STUN and TURN servers).
At the moment, our WebRTC stack is still using the “plan-b” SDP format. We’re currently testing an update to the Skylink Platform and our SDKs which, among other improvements, switches the SDP format we use to “unified plan”. If you use our SDKs, you will need to import the updated libraries; you’re not likely to need to change your code beyond that.