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.