The first weeks of 2019 are shaping up to be very interesting for the WebRTC community. Google announced Unified Plan default support in Chrome M72, slated for mid-January release, and the W3C recently issued the First Public Working Draft for WebRTC Next Version Use Cases.

Support for Unified Plan in Chrome has been in the works for several years now. Unified Plan was an outcome of the plan wars of 2013 and is a compromise between several proprietary extensions to signal multiple media streams within an m-section of an SDP. The compromise is documented in the Unified Plan proposal from the summer of 2013, and was absorbed as part of the WebRTC Javascript Establishment Protocol (JSEP). This was implemented by Firefox in 2015, and ever since there has been an interoperability issue when signaling multiple media streams between Chrome and Firefox. A mismatch in SDP (between Plan B and Unified Plan) usually results in only the first audio and video media tracks to be played out, while the rest are just ignored. This can be a problem with large scale media conferencing solutions.

With support for Unified Plan replacing Plan B coming to a head in Google Chrome, it is important that you have a clear understanding of what Unified Plan is and that you start to update your applications.

Please note, applications that send a single audio and video track are not expected to need any changes. However, any application that sends multiple audio and video tracks over a single PeerConnection will need to change. Applications that fiddle with the MediaStream Identifier (MSID) fields will need to take note of the SDP changes as well.

Pay special attention to ensuring your applications stay up and running during the transition so you don’t affect your customer experience.

If you have more questions about how to maintain the best user experience during transitions like these, chat with our sales team.

What is Unified Plan?

Unified Plan is an IETF draft proposal for signaling multiple media sources in Session Description Protocol (SDP). It was hotly debated in the summer of 2013 and unified plan was the compromise solution. In 2013, Google had already implemented its proposal, known as Plan B. Google recently decided to transition from Plan B to the Unified Plan. As part of the transition plan, both formats will be available in Chrome, but support for Plan B will be removed at some point in the future.

In order to simultaneously send a camera feed and screen share (both are video tracks), it’s necessary to signal multiple video sources to the remote party. This may also occur when there are several participants in a call and the network topology uses one or more SFUs to route multiple tracks from several participants to a particular end user.

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.

Incompatibility and Backwards Compatibility Issues with Unified Plan and Plan B

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.

If a Unified Plan client receives an offer generated by a Plan B client, the Unified Plan client must reject the offer with a failed setRemoteDescription() error.

Similarly, if a Plan B client receives an offer generated by a Unified Plan client, it may only create tracks and fire the PeerConnection ontrack event for the first track in every “m=” section, while other tracks will be dropped from the session. This leads to missing significant portions of the media that may be on different tracks.

Changes to WebRTC Application Behavior Due to the Unified Plan Transition

Unified Plan brings about several important, yet subtle changes in application behavior.

A transceiver represents a single “m=” section in SDP and is identified by a “mid” attribute inside the “m=” section. Since a transceiver consists of both a sender and a receiver, when addTrack() or addTransceiver() is called, a receiver track is also created, but it’s muted by default. In a similar way, if a remote SDP is applied, transceivers may be created or updated and ontrack event can be fired for each remote track that can be used for receiving.

Furthermore, in Unified Plan tracks are never “truly” removed. When an application calls removeTrack(), only direction of a transceiver is changed and a sender’s track is nulled. The direct consequence of not removing tracks is that Media Stream Track’s onended event is not fired anymore.

Since transceivers are bidirectional, an answerer can use a transceiver to send early media if “sendrecv” direction has been set in the offer. This is a significant difference in comparison to Plan B, in which the offerer does not have a receiver until an answer is available.

Unified Plan Transition Guide

In order to help application developers transition smoothly, the Chrome team started supporting Unified Plan behind the flag starting from Chrome release M69.

Google is adding one new feature to the RTCPeerConnection’s RTCConfiguration:

enum SdpSemantics { "plan-b", "unified-plan" };  

partial dictionary RTCConfiguration { SdpSemantics sdpSemantics; }  

To enable Unified Plan, use this flag when you create a peer connection:

let peer = new RTCPeerConnection ({ sdpSemantics : "unified-plan" });

This won’t be needed from Chrome M72, as Unified Plan will be applied by default.

If you want to learn more, check out the detailed Unified Plan Transition Guide for application developers.

Additionally, it might be useful to have a look at this npm module, which is able to convert between a Unified Plan SDP to Plan B and vice versa.

If your application mimics Google’s Simulcast implementation, you will need to stay on Plan B until API semantics for Unified Plan are implemented. In the meantime, you can continue to use the Plan B SDP in Chrome:

let peer = new RTCPeerConnection ({ sdpSemantics : "plan-b" });

How Can callstats.io Help with the Transition to Unified Plan?

Figure 1: The callstats.io dashboard.

When you integrate callstats.io into your application, you are able to do two very important things related to this transition. First, you are able to track negotiation errors. Second, you can access content of SDPs that trigger negotiation errors and use that as input when fixing errors in your application.

Making the switch to Unified Plan can be hard. It doesn't have to be. Try out the callstats.io hassle-free demo to see how we can help you achieve your real-time communications goals.