PSA: Unified Plan SDP testing flag is now available on Canary

1,068 views
Skip to first unread message

Harald Alvestrand

unread,
May 15, 2018, 4:14:53 AM5/15/18
to WebRTC-discuss
As of today's tip-of-tree, there is a new flag available in RTCConfiguration for Chrome:

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


partial dictionary RTCConfiguration {
   SdpSemantics sdpSemantics;
}

Invoke as "new RTCPeerConnection({sdpSemantics: "unified-plan"})

The default is "plan-b", which is what Chrome is currently sending.
At some point in the future (date to be determined), we'll switch the default to "unified-plan", which will make Chrome send SDP that is conformant to the JSEP specification.

You can also change the default to "unified-plan" by a command line switch:

–enable-blink-features=RTCUnifiedPlanByDefault

Details of the transition plan are here:

Note that the date of transition has NOT been set - we're actively searching for input on when it's reasonable to throw the switch.

Interoperability and Compatibility

There is limited compatibility between the old and the new SDP format. Applications with a single audio and video stream are expected to function as before, but applications that need multiple audio and video streams on the same PC are likely to need modification.

Applications that previously supported Firefox may detect the new behavior as Firefox, and therefore continue working with no changes.


Applications that need more time to convert once the changeover date is announced may use "sdpSemantics='plan-b'" to get the older behavior for some time still, but note that this flag will be removed again at some point.


We encourage all applications to test with the new SDP format, and to file bugs on behavior that does not conform with the standard's specification.

Harald, for the developers

PhistucK

unread,
May 15, 2018, 5:19:59 AM5/15/18
to WebRTC-discuss
Congratulations for the milestone!
I hope things will go smoothly and transition quickly.

PhistucK


--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVGdEOiHuUGPXVABvMOiSh%2BACmOK4A4fCDnTro4o1qxvkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Philipp Hancke

unread,
May 15, 2018, 12:47:54 PM5/15/18
to WebRTC-discuss
is there a chance you can remove the a=ssrc msid lines before the branch cut?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

Harald Alvestrand

unread,
May 15, 2018, 5:44:43 PM5/15/18
to WebRTC-discuss
In the initial offer? Do they do any harm?

These enable plan B browsers to reply to Unfiied Plan offers in a parseable manner for the single-track-per-media-type case; I was thinking that they would stay in until we remove Plan B support entirely.


On Tue, May 15, 2018 at 6:47 PM, 'Philipp Hancke' via discuss-webrtc <discuss...@googlegroups.com> wrote:
is there a chance you can remove the a=ssrc msid lines before the branch cut?

Philipp Hancke

unread,
May 16, 2018, 2:29:47 AM5/16/18
to WebRTC-discuss
Not sending them would be a clear indicator that an incoming SDP is not "plan B". Chrome has been parsing a=msid for more than a year.
Arguably this is only an indicator when there is a stream.

What logic is Chrome using to decide whether it is talking to something unified-plan enabled?


2018-05-15 23:44 GMT+02:00 'Harald Alvestrand' via discuss-webrtc <discuss-webrtc@googlegroups.com>:
In the initial offer? Do they do any harm?

These enable plan B browsers to reply to Unfiied Plan offers in a parseable manner for the single-track-per-media-type case; I was thinking that they would stay in until we remove Plan B support entirely.

Andreas Smas

unread,
May 16, 2018, 2:32:16 AM5/16/18
to discuss-webrtc
Hi,

Is there a reliable established way of auto detecting which type of SDP you received based on just the SDP itself?

I can think of a number of way of doing this, just want to check if there is some prior art in this area.

best,
Andreas

Harald Alvestrand

unread,
May 16, 2018, 2:46:33 AM5/16/18
to WebRTC-discuss
One detection we're using is based on counting media lines.
The resulting metric is the one defined here:


What it's trying to count is the ability to tell how often we're receiving something that can only be parsed under a single plan (ComplexPlanB and ComplexUnifiedPlan).

The detection code is here:


The other detection we're using is based on counting MSID lines.
The reporting code is here:


What it's trying to report is the number of cases where we'll be replying with a=msid, a=ssrc:msid or both.



--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

Basar Daldal

unread,
Aug 10, 2018, 8:33:01 AM8/10/18
to discuss-webrtc
Hi,

I see the transition plan is given here (https://webrtc.org/web-apis/chrome/unified-plan/), but do not see a timeline for Phase 3. I just want to understand when the default will be changed to Unified Plan so that we can plan ourselves for this.

Can anyone provide that, at least a draft plan?

Thanks,
Basar

pablo

unread,
Aug 31, 2018, 12:38:50 PM8/31/18
to discuss-webrtc
I also vote to remove the a=ssrc msid lines.
I'm asking Chrome to give me unified-plan sdp so I'm expecting unified-plan without invalid lines with custom syntax.
Now SFUs need to filter Chrome's specific sdp lines.
Message has been deleted

SEFA ODUNCUOĞLU

unread,
Sep 13, 2018, 9:52:36 AM9/13/18
to discuss-webrtc
Hi,

We would like to report three issues that about crashing of the Google Chrome Canary, and One-way speech path and video stream below:

1. Google Chrome Canary is crashing:
When Unified Plan is activated that using command "–enable-blink-features=RTCUnifiedPlanByDefault" and open the canonical video chat app appr.tc to test P2P communication between "Plan B and Unified Plan" on Canary, it crashed after a while.
 
2. One-way speech path problem:
When doing test with our local clients to see incompatibility between Plan B and Unified Plan, one-way speech path problem that Unified Plan side couldn't hear the Plan B's voice occurred. Also this problem is occurring on talky.io which is WebRTC test client.
 
3. One-way video stream problem:
 Similar issue with one-way speech path. Unified Plan side couldn't show the Plan B's video.
 
P.S. The bytesReceived and bytesSent transmissions for Audio/Video are displayed on chrome://webrtc-internals as expected.


We tried to understand the problems that mentioned above, but could't find any observed issue on the our side. We supposed that the problems related with Canary client

Could you please check these problems and share us an information about progress?

If you need the problematic scenario logs, we would like to send logs you.


Thanks
Sefa Oduncuoglu

On Tuesday, May 15, 2018 at 11:14:53 AM UTC+3, Harald Alvestrand wrote:

Philipp Hancke

unread,
Sep 13, 2018, 11:42:51 AM9/13/18
to WebRTC-discuss
file bugs from chrome://crashes which allows correlating this with crash ids -- mentioning webrtc in the subject makes this easier to triage.
Adding detailed steps to reproduce typically helps alot too and testing in Canary ensures this is not already fixed.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages