Is everyone switching to Unified Plan?

The KrankyGeek event in San Francisco last month was, as always, quite interesting. Make sure to watch the videos!

The Google session however, made me shake my head. Not the part on Stadia which was great and will be fun to look into in the future. The following slide was presented about the adoption of the unified plan SDP format:

You will find it at 1:16 into the session. The numbers seem to be taken (in part) taken from the Chrome issue about deprecating Plan B.

As a refresher, WebRTC utilizes a 20-year old text-based format known as Session Description Protocol (SDP) for describing the various media and network parameters of a RTC session. Check out our SDP Anatomy post to see an example. SDP has had to evolve to handle the increasing complexity of communications. Unified Plan is an updated SDP specification that has been implemented by WebRTC browsers, but not without some turmoil.

The Plan Wars

Unified Plan support has been a topic since the early days of WebRTC. Surprisingly, webrtcHacks never got around to writing up the differences here (2020 resolution: post more often). If you are looking for more background on this topic, the callstats.io folks do have a great blog post on covering Unified Plan vs. what Google had previously implemented, known as Plan B. The key issue here is how to format SDP when handling multiple audio and video tracks in the same session:

In Plan B, one “m=” section of SDP is used for video and audio respectively. If an application sends or receives multiple media tracks of the same media type, multiple “a=ssrc” lines are listed in the same “m=” section.
In contrast, with Unified Plan every single media track is assigned to a separate “m=” section. If you use multiple media tracks, multiple “m=” sections are created.
[…] Because of the way they each handle multiple media tracks, Unified Plan and Plan B are incompatible if you are using multiple media tracks of the same kind.

Google implemented Plan B in Chrome very early (before WebRTC landed in Chrome even), but the standard ended up with a different variant, called Unified Plan.

Chrome Migrates to Unified Plan

It took Google until 2018 to actually implement Unified Plan. The Google WebRTC team provided an excellent migration guide for both web and native applications that you should have already read on the webrtc.org site.

One of the key points for a smooth migration was providing a flag in the RTCPeerConnection  constructor for choosing the SDP variant by specifying  sdpSemantics: "unified-plan" or sdpSemantics: "plan-b". While this flag is not in the W3C specs, it did allow experimentation and controlled rollouts. (For more background, I described whereby’s Unified Plan rollout procedure here, just note this has since been partially rolled back due to a number of issues). The actual change of the default sdpSemantics  in Chrome 72 went surprisingly smooth. There were no major issues being reported at that time.

Metrics vs. Reality

But that does not mean all is well and this is a huge success as the slide suggests. Unified Plan matters most for use cases when you are connecting to a media server, not another peer, since it does a better job of handling advanced media scenarios like simulcast that utilize multiple tracks of the same type.  Most peer-to-peer implementations use only one audio and one video track – in those situations there is little difference between Plan B and Unified Plan and the different SDP formats are essentially compatible with each other.

None of the Largest WebRTC Services are on Unified Plan

Goign back to Google’s report above, 86% of reported peer connections were not making a plan selection. This means they let Chrome choose – which was switched to Unified Plan. 11% of peer connections using Unified Plan was not matching my experience in developing WebRTC. This also didn’t seem to match what I have observed other big services doing via occasional snooping. Gustavo Garcia pointed out the same after looking at Google Hangouts, Facebook Messenger, Discord, Amazon Chime and HouseParty:

WebRTC is big, but it seems very likely that these largest WebRTC services account for more than 3% of usage combined… which means something is wrong with Google’s stats above. Mozilla’s Nils Ohlmeier asked for clarification as well and we got updated numbers in response which were even more confusing and quite different from the ones presented at Kranky Geek:

• Unified Plan 95.4%, 26% asking for unified-plan  via SDP semantics and 70% using the default
• 4.6% plan-b

I still refused to believe this so continued to insist those were wrong. In the end, that resulted in a different set of numbers:

• • 4% plan-b
  • 2.9% unified-plan

This is still surprising given the ubiquity of Plan B in servers. At least it is clear deprecation is not going to happen anytime soon.

Refinement

That mystery was solved a couple of days later when another Googler found a metric describing the “SDP remote offers which use more than one audio track or more than one video track”. The refinement to look just at multi-track offers finally made this data relevant. Those numbers show that plan-b  was used by 90% of those offers. Which finally matches the real-world experience. At the same time, a 10% adoption of Unified Plan is still quite high given it hasn’t been around for that long.

What went wrong is not quite clear. Most likely the original numbers were for all peer connections and may have included the ones that are never connected. We’ve seen this mistake before with the failed attempt to deprecate DTLS 1.0.

WebRTC project governance

Maybe the WebRTC team at Google can consider this mishap of presenting completely wrong numbers along with the implied threat of deprecation as an opportunity to rethink their overall strategy on developer relations and how decisions that affect users of the project are made. In my (strong) opinion, what has been missing in the Unified Plan migration (and other issues) is talking to the vendors and developers that are using those APIs.

If after a decade its Google and only Google involved in those decisions something went wrong with the projects governance. WebRTC developers – continue to be involved so we can all make sure WebRTC continues to be a community effort!

{“author”: “Philipp Hancke“}