Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Deprecate: WebRTC's Plan B SDP semantics

2,977 views
Skip to first unread message

Henrik Boström

unread,
Dec 22, 2020, 8:03:21 AM12/22/20
to blink-dev

Primary eng (and PM) emails

hb...@chromium.org, h...@chromium.org

Summary

WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.

In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.

The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.

In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.

The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.

Motivation

Explain why this feature should be deprecated (and eventually removed).

Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.

We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.

There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.

2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.

Interoperability and Compatibility Risk

Describe the degree of interoperability and compatibility risk. For a feature that is also supported in some other engine, do they support eventual removal?

Interoperability risks is discussed above about why we want to get rid of Plan B.
For more nitty gritty details about Plan B vs Unified Plan, see migration guide.

But to clarify, an app opting-in to Plan B but suddenly getting Unified Plan is likely to break. Removal cannot happen until usage goes down more. Hoping a deprecating warning will motivate people to migrate.

Edge: Supports both Unified Plan (default) and Plan B (opt-in), positive towards removal of Plan B.

Firefox: Supports Unified Plan only, positive towards removal of Plan B.

Safari: Supports Unified Plan only, positive towards removal of Plan B.


Alternative implementation suggestion for web developers

If this feature goes away, what other techniques can developers use to achieve the same effects?

Unified Plan. Don't specify anything in the RTCPeerConnection constructor.

Usage information from UseCounter

How much of the web are you going to break? How seriously would the removal break sites?

In terms of sdpSemantics usage, 55.22% don't specify which defaults to Unified Plan, 42.71% explicitly specify Unified Plan and just 2.06% overwrite this to explicitly ask for Plan B.

However those numbers can be misleading. What would "break" are the "complex" use cases of SDP. Comparing Plan B vs Unified Plan for complex use cases tells a different story:

Numbers in September:

  • SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
Numbers today (December):

  • SDPFormatReceived's Complex SDP usage: 58% Plan B, 42% Unified Plan.

Removal would likely break major conferencing websites. So let's deprecate before removing.


If possible, please link to usage details on chromestatus.com/metrics (example link)

If you haven’t instrumented this feature yet, say so.

We use UMA counters WebRTC.PeerConnection.SdpSemanticRequested and  SDPFormatReceived. See https://crbug.com/857004.

Entry on the feature dashboard

The original Unified Plan feature is here: https://chromestatus.com/feature/5723303167655936

Does "deprecate sdpSemantics" need a separate feature?

The feature dashboard is used to keep track of web-facing changes in Blink (and V8) that matter to developers. Make sure your change has an entry if you think it merits outreach to developers (e.g inclusion in the Chromium Blog Beta posts). If there’s no entry, please explain why you think this change doesn’t need one (e.g. “small change”, “fits under an existing entry”). You may be asked to create one.

Please include a deeplink in your intent (e.g. https://www.chromestatus.com/features/5688366657961984).

?

Philipp Hancke

unread,
Dec 24, 2020, 3:58:14 AM12/24/20
to Henrik Boström, blink-dev
Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:

Primary eng (and PM) emails

hb...@chromium.org, h...@chromium.org

Summary

WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.

The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.

In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.

The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.

In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.

The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.

Motivation

Explain why this feature should be deprecated (and eventually removed).

Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.

We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.

I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.
Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.

There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.

2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.

I would find fixing the reported issues with unified plan much more encouraging than a warning.
It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.

Interoperability and Compatibility Risk

Describe the degree of interoperability and compatibility risk. For a feature that is also supported in some other engine, do they support eventual removal?

Interoperability risks is discussed above about why we want to get rid of Plan B.
For more nitty gritty details about Plan B vs Unified Plan, see migration guide.

But to clarify, an app opting-in to Plan B but suddenly getting Unified Plan is likely to break. Removal cannot happen until usage goes down more. Hoping a deprecating warning will motivate people to migrate.

Edge: Supports both Unified Plan (default) and Plan B (opt-in), positive towards removal of Plan B.

Firefox: Supports Unified Plan only, positive towards removal of Plan B.

Safari: Supports Unified Plan only, positive towards removal of Plan B.


Alternative implementation suggestion for web developers

If this feature goes away, what other techniques can developers use to achieve the same effects?

Unified Plan. Don't specify anything in the RTCPeerConnection constructor.

Usage information from UseCounter

How much of the web are you going to break? How seriously would the removal break sites?

In terms of sdpSemantics usage, 55.22% don't specify which defaults to Unified Plan, 42.71% explicitly specify Unified Plan and just 2.06% overwrite this to explicitly ask for Plan B.

However those numbers can be misleading. What would "break" are the "complex" use cases of SDP. Comparing Plan B vs Unified Plan for complex use cases tells a different story:

Numbers in September:

  • SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
Numbers today (December):

  • SDPFormatReceived's Complex SDP usage: 58% Plan B, 42% Unified Plan.

These numbers are based on the metrics from https://bugs.chromium.org/p/chromium/issues/detail?id=857004#c31
As I have pointed out in the bug, this is using the wrong baseline since it looks at the offers only and  ignores the rather common case of the complex answer SDP. This means your numbers ignore Google Meet, Jitsi Meet (and probably a couple of other meets)
Can you give ratios for SDPFormatReceivedAnswer as well as the ratio of SDPFormatReceived and SDPFormatReceivedAnswer?

Removal would likely break major conferencing websites. So let's deprecate before removing.


If possible, please link to usage details on chromestatus.com/metrics (example link)

If you haven’t instrumented this feature yet, say so.

We use UMA counters WebRTC.PeerConnection.SdpSemanticRequested and  SDPFormatReceived. See https://crbug.com/857004.

and  SDPFormatReceivedAnswer.

God jul!

Entry on the feature dashboard

The original Unified Plan feature is here: https://chromestatus.com/feature/5723303167655936

Does "deprecate sdpSemantics" need a separate feature?

The feature dashboard is used to keep track of web-facing changes in Blink (and V8) that matter to developers. Make sure your change has an entry if you think it merits outreach to developers (e.g inclusion in the Chromium Blog Beta posts). If there’s no entry, please explain why you think this change doesn’t need one (e.g. “small change”, “fits under an existing entry”). You may be asked to create one.

Please include a deeplink in your intent (e.g. https://www.chromestatus.com/features/5688366657961984).

?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8df09267-7cc2-46b5-88c7-239f9976dd41n%40chromium.org.

Yoav Weiss

unread,
Jan 5, 2021, 3:30:50 AM1/5/21
to Philipp Hancke, Henrik Boström, blink-dev
On Thu, Dec 24, 2020 at 9:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:

Primary eng (and PM) emails

hb...@chromium.org, h...@chromium.org

Summary

WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.

The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.

In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.

The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.

In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.

The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.

Motivation

Explain why this feature should be deprecated (and eventually removed).

Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.

We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.

I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.
Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.

Are non-browser endpoints using the unified plan or plan B?
 

There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.

2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.

I would find fixing the reported issues with unified plan much more encouraging than a warning.
It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.

That seems like a good point. Is there a list of issues currently blocking the migration to the unified plan?
 

Harald Alvestrand

unread,
Jan 5, 2021, 3:59:03 AM1/5/21
to Philipp Hancke, Henrik Boström, blink-dev
Philipp said:

"I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.
Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this."

Any server-based conferencing application (at least all the ones I've seen) is "complex", because it uses multiple video and/or audio tracks server -> browser.

On Thu, Dec 24, 2020 at 9:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:

Henrik Boström

unread,
Jan 5, 2021, 4:19:03 AM1/5/21
to blink-dev, yo...@yoav.ws, Henrik Boström, blink-dev, philipp...@googlemail.com, Harald Alvestrand
On Tuesday, January 5, 2021 at 9:30:50 AM UTC+1 yo...@yoav.ws wrote:
On Thu, Dec 24, 2020 at 9:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:

Primary eng (and PM) emails

hb...@chromium.org, h...@chromium.org

Summary

WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.

The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.

In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.

The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.

In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.

The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.

Motivation

Explain why this feature should be deprecated (and eventually removed).

Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.

We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.

I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.
Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.

Are non-browser endpoints using the unified plan or plan B?

It's a similar story there, most non-browser endpoints are using libwebrtc (the same library that chromium-based browsers are built on top of) which means they are free to choose what to use with sdp_semantics.
For historical reasons a lot of endpoints use Plan B, but endpoints that want to interoperate with browsers like Firefox or default-constructed peer connections on Chromium-browsers would either use Unified Plan directly or have the means to convert between SDP formats. Like Harald said, server-based conferencing applications would be "complex" and do care if its Plan B or Unified Plan.
 
 

There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.

2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.

I would find fixing the reported issues with unified plan much more encouraging than a warning.
It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.

That seems like a good point. Is there a list of issues currently blocking the migration to the unified plan?

There are no blocking issues that I'm aware of.

There are some discrepancies between Unified Plan and Plan B, e.g.
- Some which are inherent to the change in SDP: "removed" tracks don't fire the ended event, they fire the muted event. Re-adding tracks causes new m= sections, making the SDP "complex", etc. This is all working as intended.
- Neither Plan B or Unified Plan implement a feature called "end-of-candidates" which affects what ICE candidate state is reported (when not "connected", should it be "disconnected" or "failed"?). Plan B implemented a spec-breaking work-around to this issue where it reports "failed" based on a timeout. Philipp has been upset in the past that Unified Plan does not implement the same timeout-based workaround to the issue and instead reports "disconnected" (as is the correct thing to do if you don't know about "end-of-candidates", but arguably less useful than a heuristic "failed"). This has shown to cause confusion, but in my experience updating an app to be prepared for this was a one line change or a a few lines if you want the timeout. In either case, this is not a blocking issue to adding a deprecation warning in my opinion.

Philipp are you referring to anything else? Flat-out calling Unified Plan "broken" is not really helpful in an email thread like this, to aid conversation please be more specific.

Philipp Hancke

unread,
Jan 6, 2021, 1:28:39 AM1/6/21
to Henrik Boström, blink-dev, yo...@yoav.ws, Harald Alvestrand
Am Di., 5. Jan. 2021 um 10:19 Uhr schrieb Henrik Boström <hb...@chromium.org>:


On Tuesday, January 5, 2021 at 9:30:50 AM UTC+1 yo...@yoav.ws wrote:
On Thu, Dec 24, 2020 at 9:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:

Primary eng (and PM) emails

hb...@chromium.org, h...@chromium.org

Summary

WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.

The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.

In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.

The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.

In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.

The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.

Motivation

Explain why this feature should be deprecated (and eventually removed).

Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.

We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.

I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.
Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.

Are non-browser endpoints using the unified plan or plan B?

It's a similar story there, most non-browser endpoints are using libwebrtc (the same library that chromium-based browsers are built on top of) which means they are free to choose what to use with sdp_semantics.

It probably makes sense to differentiate between browsers, clients using the webrtc.org library and servers. From the metrics for setRemoteDescription (https://www.chromestatus.com/metrics/feature/timeline/popularity/3451 -- good proxy for peerconnections actually used) and simulcast (https://www.chromestatus.com/metrics/feature/timeline/popularity/3159 -- good proxy for talking to a multiparty server) it looks like 70% of connections go to a server -- which I still find rather surprising.

Servers can send different SDP to different user agents. Which servers have done for ages. Or they do not send SDP on the wire at all.
Mind you that at least for servers/services that do speak both dialects so a gradual rollout should be simple enough, yet it does not happen.
How is a deprecation warning (which is relatively inefficient as the mozilla variant of https://bugs.chromium.org/p/chromium/issues/detail?id=659133 shows) going to help?


For historical reasons a lot of endpoints use Plan B

Maybe plan-b just satisfies the requirements? I expect the bulk of the plan-b usage to be from a limited number of large services (and maybe some jitsi meet instances)

, but endpoints that want to interoperate with browsers like Firefox or default-constructed peer connections on Chromium-browsers would either use Unified Plan directly or have the means to convert between SDP formats. Like Harald said, server-based conferencing applications would be "complex" and do care if its Plan B or Unified Plan.
 
 

There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.

2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.

I would find fixing the reported issues with unified plan much more encouraging than a warning.
It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.

That seems like a good point. Is there a list of issues currently blocking the migration to the unified plan?

There are no blocking issues that I'm aware of.

my favorites:
(ironically one of the few arguments for unified plan was that you can apply per-mline bandwidth limits)
(arguably part of this is related to not using bundle) and last but not least
https://bugs.chromium.org/p/chromium/issues/detail?id=944821 (browser-specific SDP solves this but...)

A ton of bugs have been fixed thankfully.

There are some discrepancies between Unified Plan and Plan B, e.g.
- Some which are inherent to the change in SDP: "removed" tracks don't fire the ended event, they fire the muted event. Re-adding tracks causes new m= sections, making the SDP "complex", etc. This is all working as intended.
- Neither Plan B or Unified Plan implement a feature called "end-of-candidates" which affects what ICE candidate state is reported (when not "connected", should it be "disconnected" or "failed"?). Plan B implemented a spec-breaking work-around to this issue where it reports "failed" based on a timeout. Philipp has been upset in the past that Unified Plan does not implement the same timeout-based workaround to the issue and instead reports "disconnected" (as is the correct thing to do if you don't know about "end-of-candidates", but arguably less useful than a heuristic "failed"). This has shown to cause confusion, but in my experience updating an app to be prepared for this was a one line change or a a few lines if you want the timeout.

I've been (and remain) upset about coupling the iceConnectionState changes to the sdp semantics (and then not testing).
Also it looks like connectionState still uses the timeout as it goes to "failed" when being unable to connect for a while. See
where connectionState goes to failed despite the single ICE transport being in 'disconnected' state which isn't correct from my interpretation of the spec, no?

In either case, this is not a blocking issue to adding a deprecation warning in my opinion.
Philipp are you referring to anything else? Flat-out calling Unified Plan "broken" is not really helpful in an email thread like this, to aid conversation please be more specific.

I called it "broken" in the context of issue 944821 where
1/ webrtc.org incorrectly/unfortunately stripped a leading whitespace while parsing the sdp, leading to confusion between different semantics from different draft versions and
2/ the w3c spec had changed to a different behaviour which made webrtc.org non-compliant in its "spec compliant simulcast" implementation by the time chrome shipped this in stable.

From the top of my head I recall two bad regressions in unified-plan last year (one made it to stable sadly) and none in plan-b.
Chicken-egg problem, without a large deployment the hard bugs won't be found, without finding the bugs and demonstrating stability adoption is a risk for large deployments.

 

Interoperability and Compatibility Risk

Describe the degree of interoperability and compatibility risk. For a feature that is also supported in some other engine, do they support eventual removal?

Interoperability risks is discussed above about why we want to get rid of Plan B.
For more nitty gritty details about Plan B vs Unified Plan, see migration guide.

But to clarify, an app opting-in to Plan B but suddenly getting Unified Plan is likely to break. Removal cannot happen until usage goes down more. Hoping a deprecating warning will motivate people to migrate.

Edge: Supports both Unified Plan (default) and Plan B (opt-in), positive towards removal of Plan B.

Firefox: Supports Unified Plan only, positive towards removal of Plan B.

Safari: Supports Unified Plan only, positive towards removal of Plan B.


Alternative implementation suggestion for web developers

If this feature goes away, what other techniques can developers use to achieve the same effects?

Unified Plan. Don't specify anything in the RTCPeerConnection constructor.

Usage information from UseCounter

How much of the web are you going to break? How seriously would the removal break sites?

In terms of sdpSemantics usage, 55.22% don't specify which defaults to Unified Plan, 42.71% explicitly specify Unified Plan and just 2.06% overwrite this to explicitly ask for Plan B.

However those numbers can be misleading. What would "break" are the "complex" use cases of SDP. Comparing Plan B vs Unified Plan for complex use cases tells a different story:

Numbers in September:

  • SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
Numbers today (December):

  • SDPFormatReceived's Complex SDP usage: 58% Plan B, 42% Unified Plan.

These numbers are based on the metrics from https://bugs.chromium.org/p/chromium/issues/detail?id=857004#c31
As I have pointed out in the bug, this is using the wrong baseline since it looks at the offers only and  ignores the rather common case of the complex answer SDP. This means your numbers ignore Google Meet, Jitsi Meet (and probably a couple of other meets)
Can you give ratios for SDPFormatReceivedAnswer as well as the ratio of SDPFormatReceived and SDPFormatReceivedAnswer?

^ note that the additional metric landed in M88 which isn't even stable yet.

Henrik Boström

unread,
Jan 7, 2021, 7:08:29 AM1/7/21
to blink-dev, philipp...@googlemail.com, blink-dev, yo...@yoav.ws, Harald Alvestrand, Henrik Boström
The issues you are referencing relate to edge-case issues with new functionality provided in Unified Plan, but as far as I can tell, there is no Plan B behavior that would break?
All of these sound like issues with opt-in functionality not being polished? I'm not questioning the existence of issues in webrtc, but I am questioning the claim that these are blocking issues.

(ironically one of the few arguments for unified plan was that you can apply per-mline bandwidth limits)
 
How is this a blocking issue? You can't control bitrate constraints on a per-m= section in Plan B either, so there's no loss of functionality here.
 
(arguably part of this is related to not using bundle) and last but not least

Bundling is very rare and mostly used by legacy endpoints and this issue only happens in edge cases. Is this really blocking adding a discouraging message?

https://bugs.chromium.org/p/chromium/issues/detail?id=944821 (browser-specific SDP solves this but...)

This is an edge-case issue with the transceiver API. While the transceiver API is only available in Unified Plan, i.e. is something that you can opt-in to, if you want to enable simulcast without using this API you can do so in Unified Plan the same way you already do today in Plan B. So again, there's no loss in functionality here. Yes we should fix the issue, but is this really blocking discouraging usage?

Jan-Ivar Bruaroey

unread,
Jan 7, 2021, 5:15:15 PM1/7/21
to blink-dev, Henrik Boström, philipp...@googlemail.com, blink-dev, yo...@yoav.ws, Harald Alvestrand, Tantek Celik
Thanks for this! ❤️ Deprecating non-standard “plan-b" is timely with WebRTC 1.0 now being a Proposed Recommendation.

Deprecation warnings are probably most effective when they warn of a deadline people think is hard.

To that end, would it work to put Plan-B under a Reverse Origin Trial?
  • Any service which depends on Plan B would have to register for the Trial to be able to continue to use Plan B past the deadline.
  • It would be turned off for everyone else.
This would produce a finite list of services that struggle with migration. Any bugs these services identify as blocking could be targeted on a case by case basis.
Such a deadline might be more feasible than a turning this legacy feature off cold, thus more likely to happen as advertised.

Credit for this idea goes to Tantek Çelik.

Cheers!

Chris Harrelson

unread,
Jan 7, 2021, 7:36:05 PM1/7/21
to Jan-Ivar Bruaroey, blink-dev, Henrik Boström, philipp...@googlemail.com, yo...@yoav.ws, Harald Alvestrand, Tantek Celik
Hi,

The API owners met earlier today to discuss this intent. We are supportive of deprecating and removing plan B as soon as it is web compatible to do so. Thank you for making improvements to interop!

To that end, we also think it's a great idea to use a reverse origin trial for this feature. This was used successfully for the web components v0 APIs, and also for AppCache. We'd like to suggest you commit to two target dates as part of this deprecation, and include the dates in all deprecation outreach and messaging (e.g. in DevTools):

* Date #1: after this date, plan B support will be removed unless it is re-enabled in a reverse origin trial
* Date #2: reverse origin trial ends, and plan B is gone

And set up a reverse origin trial as soon as possible to help sites sign up and make sure everything is working properly. Since we've done it multiple times recently, it should be a smooth process.

How does that sound? Can you propose dates for #1 and #2?

Thanks,
Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Jan-Ivar Bruaroey

unread,
Jan 8, 2021, 12:39:31 PM1/8/21
to blink-dev, Chris Harrelson, blink-dev, Henrik Boström, philipp...@googlemail.com, yo...@yoav.ws, Harald Alvestrand, Tantek Celik, Jan-Ivar Bruaroey
Sounds great! - Proposing dates for #1 and #2 would probably be for Henrik or Harald I suspect, but glad to hear setting up a reverse origin trial as soon as possible is the next step.

Emil Ivov

unread,
Jan 11, 2021, 4:46:34 PM1/11/21
to blink-dev, Jan-Ivar Bruaroey, Henrik Boström, Philipp Hancke, blink-dev, yo...@yoav.ws, Harald Alvestrand, Tantek Celik
Just a quick note on the Reverse Origin Trial. 

This would be a rather problematic solution for Jitsi, where the same code is being downloaded and executed by a substantial number of parties and different domains.

For reference, the docker hub images alone list more than 10,000,000 downloads: https://hub.docker.com/r/jitsi/web . This is without counting direct downloads, github clones or downloads from our .deb repositories. 

Hopefully we would not go in that direction.

Emil

Chris Harrelson

unread,
Jan 11, 2021, 4:51:39 PM1/11/21
to Emil Ivov, blink-dev, Jan-Ivar Bruaroey, Henrik Boström, Philipp Hancke, yo...@yoav.ws, Harald Alvestrand, Tantek Celik
Hi Emil,

Thanks for the feedback.

Regarding the Reverse Origin Trial: Jitsi already supports Unified Plan right? (Or else it would not support Firefox or Safari.)

We do need to deprecate Plan B as it is non-standard; the Reverse Origin Trial simply locks in the existing sites that need Plan B a bit longer, and potentially gives them *more* time to migrate, not less. All customers of Jitsi would be notified that this is an option for them if they need that extra time. Is that unreasonable somehow?

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Henrik Boström

unread,
Jan 12, 2021, 3:48:28 AM1/12/21
to blink-dev, Chris Harrelson, blink-dev, Jan-Ivar Bruaroey, Henrik Boström, philipp...@googlemail.com, yo...@yoav.ws, Harald Alvestrand, Tantek Celik, Emil Ivov
Assuming Firefox/Safari are already supported (= Unified Plan), how difficult would it be to make Chrome and Edge also use Unified Plan instead of Plan B?

The dates we have discussed internally so far is to...
  • Add a deprecation warning in M89 (Canary: Jan 14, 2021; Stable: Feb 23, 2021).
  • Enable the Reverse Origin Trial in M90 (Canary: Feb 25, 2021; Stable: Aug 24, 2021) however don't make it mandatory just yet. Plan B continues to work without opting in to it. Update deprecation warning with Reverse Origin Trial info.
  • Require Reverse Origin Trial to continue to use Plan B, deprecate it for everybody else, in M93 (Canary: July 15, 2021; Stable: Aug 24, 2021).
  • Reverse Origin Trial ends, and Plan B goes away for everybody, in M96 (Canary: Nov 18, 2021; Stable: Jan 18, 2022).
This would give you more than half a year to stop using Plan B without the trial and up to a year if you need extended time using the Reverse Origin Trial. Does that sound realistic?

Henrik Boström

unread,
Jan 12, 2021, 5:03:18 AM1/12/21
to blink-dev, Henrik Boström, Chris Harrelson, blink-dev, Jan-Ivar Bruaroey, philipp...@googlemail.com, yo...@yoav.ws, Harald Alvestrand, Tantek Celik, Emil Ivov
Typo alert! M90 is Stable on April 6, 2021

Emil Ivov

unread,
Jan 12, 2021, 7:49:19 AM1/12/21
to Chris Harrelson, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
Hi Chris,

Jitsi is an open source video conferencing project that people download and run themselves. The 10M+ downloads I mentioned are by people who setup their own Jitsi servers and we have obviously no control or even awareness of these installations.

It is therefore not really clear to me what you mean when they say that these “customers” will be notified.

If Jitsi was to enable Unify support for Chrome tomorrow, this will change nothing for such users. They will have to download the new code and upgrade their servers. This tail takes years at times.

The origin trial isn’t really a big relief here. It requires for people to be aware (and as I said, we have no reliable way to reach all of them) and it requires them to make changes in Jitsi itself, which would be non-trivial for many of them.

Overall, the point I am making is that if the goal of the reverse origin trial is to avoid disrupting users who need to continue using Plan B, then it fails for this case since the code is not centrally controlled.

Cheers,
Emil
--
sent from my mobile

Henrik Boström

unread,
Jan 12, 2021, 8:24:12 AM1/12/21
to blink-dev, Emil Ivov, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, philipp...@googlemail.com, Tantek Celik, blink-dev, yo...@yoav.ws, Chris Harrelson
What about when Unified Plan became the default SDP semantic in Chrome? Back then, services depending on Plan B had to update their JS code in order to continue to get Plan B, and that rollout was successful. Removing Plan B is of course a much more challenging task than adding {sdpSemantics:"plan-b"} to the RTCPeerConnection constructor, but it is similar in that it was a need for WebRTC websites to update their JS library.

I'll do my best to compile a list of Plan B services using UKMs and HTTP archive queries to get a sense of how long the tail is.

Harald Alvestrand

unread,
Jan 12, 2021, 8:50:19 AM1/12/21
to Emil Ivov, Chris Harrelson, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
The hope is that there are folks that notice that warning messages have started popping up in the Chrome console between January and May, and that people will either take action (upgrade Jitsi, in this case?) or register themselves for the origin trial.

Once we remove the Plan B code, what they have will stop working; this is the kinder, gentler landing path, but some day, it has to end.

Emil Ivov

unread,
Jan 12, 2021, 10:45:51 AM1/12/21
to Harald Alvestrand, Chris Harrelson, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
Hey Harald,

I understand that that is the hope but the thing to consider here is that the people seeing who are generating the warning are not necessarily the ones that are in a position to do something about it. 

I also understand that maintaining two signaling mechanisms is not sustainable long term. 

That said, we obviously all agree that time is necessary for this transition which is why you folks are considering a Reverse Origin trial. I am simply commenting that this mitigation only works for some cases and isn't really great for many other people out there. 

I am not asking that Plan B be kept in code for longer that you were planning to. I am asking for a more generic mitigation solution.  

A decent alternative would be to simply stay at the warning and keep Plan B as a deprecated mechanism and show the warning but not require origin trials for using it.

Emil
--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi                              
em...@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

Philipp Hancke

unread,
Jan 12, 2021, 10:59:40 AM1/12/21
to Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws, Chris Harrelson
Henrik, jitsi is opensource and welcomes pull requests! Maybe actually *doing* that transition will make you understand why this is a bit more complicated than in a jsfiddle.
(the problem here is QA and metrics for large calls. Which, as you may know, is so hard it took more than two years to discover some of the performance issues)

Still looking for numbers I can quote :-)

Henrik Boström

unread,
Jan 12, 2021, 11:07:56 AM1/12/21
to blink-dev, philipp...@googlemail.com, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws, Chris Harrelson, Henrik Boström
I hear two alternative proposals:
  • Proposal A: Deprecation warning now, Plan B gone in half a year unless you opt in to Reverse Origin Trial, then you have a whole year.
  • Proposal B: Deprecation warning now, Plan B gone in one year for everyone. Skip the Reverse Origin Trial.

Chris Harrelson

unread,
Jan 12, 2021, 11:41:16 AM1/12/21
to Henrik Boström, blink-dev, philipp...@googlemail.com, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
Re Jitsi being open-source: yes, I recognize that. When I said to "notify your customers", what I meant is that hopefully you'd add a notice in your github repo, as well as an email/tweet if there is a discussion group, notifying everyone using the library that plan B will stop working in a year if they don't take action. And of course there is the deprecation message in DevTools. I hope you will (if it's not already the case) also change the default in your library to Unified Plan.

You mentioned that there are a lot of different sites using the library, and those will need to migrate. That is true, but it's true regardless of whether there is a Reverse Origin Trial. On a site-by-site-basis, users of your library can decide for themselves whether they want to participate in the Reverse Origin Trial or simply switch over to Unified Plan.

Experience has shown that regardless, the Reverse Origin Trial strictly adds value to the deprecation process, even from the point of view of users of the API. For example, if we get to the end of the stated deadlines and some sites are still not set up with Unified Plan, that site can get an extension by signing up to the Reverse Origin Trial. Further, we will likely be more flexible to extend an existing Reverse Origin Trial's deadline than the API itself, because at least we know which users to coordinate with on finishing the removal. Without the trial in place, the site would simply break.

Regarding timeline: Henrik, the times you suggested here (repeated below for clarity) LGTM1. You'll need two more LGTMs to finish enacting it.

- Add a deprecation warning in M89 (Canary: Jan 14, 2021; Stable: Feb 23, 2021).
- Enable the Reverse Origin Trial in M90 (Canary: Feb 25, 2021; Stable: Aug 24, 2021) however don't make it mandatory just yet. Plan B continues to work without opting in to it. Update deprecation warning with Reverse Origin Trial info.
- Require Reverse Origin Trial to continue to use Plan B, deprecate it for everybody else, in M93 (Canary: July 15, 2021; Stable: Aug 24, 2021).
- Reverse Origin Trial ends, and Plan B goes away for everybody, in M96 (Canary: Nov 18, 2021; Stable: Jan 18, 2022).

As we get to the 6-month point, please report back to the thread with the latest statistics about how much traffic is happening *outside* of the Reverse Origin Trial.

Chris

Philipp Hancke

unread,
Jan 12, 2021, 1:17:06 PM1/12/21
to Chris Harrelson, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?

Chris Harrelson

unread,
Jan 12, 2021, 1:27:35 PM1/12/21
to Philipp Hancke, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
On Tue, Jan 12, 2021 at 10:17 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?

We would not remove unless the numbers were low enough at time of removal. The team will have to come back to blink-dev to verify with the API owners that it's ok to actually remove the feature, based on data at that time (I mentioned this in my previous email). We'll know more in six months.

Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.

A good example to learn from is the v0 web components APIs, which we just finished removing. It took a long time to convince enough sites to migrate to the v1 APIs (non-Chromium browsers don't support v0), and the deprecation pressure as well as the Reverse Origin Trial were necessary components of accomplishing the goal of removing v0.

Chris

Philipp Hancke

unread,
Jan 12, 2021, 2:58:36 PM1/12/21
to Chris Harrelson, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
Am Di., 12. Jan. 2021 um 19:27 Uhr schrieb Chris Harrelson <chri...@chromium.org>:


On Tue, Jan 12, 2021 at 10:17 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?

We would not remove unless the numbers were low enough at time of removal. The team will have to come back to blink-dev to verify with the API owners that it's ok to actually remove the feature, based on data at that time (I mentioned this in my previous email). We'll know more in six months.

This assumes the data is representing the usage correctly. The numbers posted do not which is why I keep asking for the other half.

Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.

I disagree that unified-plan vs plan-b is the #1 reason for this when it comes to WebRTC. This is just a boring schism without much impact on quality.
WRT removal of plan-b good luck. My attempt to remove a seven year old "TODO: remove this" of some obsolete plan-b SDP bits was reverted because it broke a "downstream project". Go figure ;-)

Harald Alvestrand

unread,
Jan 12, 2021, 3:38:03 PM1/12/21
to Emil Ivov, Chris Harrelson, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
Emil, "staying with the warning" is exactly the strategy that we're planning to use until June.
Before the reverse origin trial was proposed, the alternative we saw was a hard cutoff in June.
Now we have a means to give people more time if they need it.


Chris Harrelson

unread,
Jan 12, 2021, 4:39:30 PM1/12/21
to Philipp Hancke, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
On Tue, Jan 12, 2021 at 11:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
Am Di., 12. Jan. 2021 um 19:27 Uhr schrieb Chris Harrelson <chri...@chromium.org>:


On Tue, Jan 12, 2021 at 10:17 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:
How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?

We would not remove unless the numbers were low enough at time of removal. The team will have to come back to blink-dev to verify with the API owners that it's ok to actually remove the feature, based on data at that time (I mentioned this in my previous email). We'll know more in six months.

This assumes the data is representing the usage correctly. The numbers posted do not which is why I keep asking for the other half.

There are indeed sites that opt out of metrics, including most enterprise sites. As part of the deprecation plan, the WebRTC team will need to reach out to enterprise customers to make them aware of the timeline and hear their feedback.
 
Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.

I disagree that unified-plan vs plan-b is the #1 reason for this when it comes to WebRTC. This is just a boring schism without much impact on quality.

I hear you. Nevertheless, we won't get to full compatibility unless we keep making progress on all of the parts that differ. Also, one other data point: I have heard directly from Mozilla that they consider the Plan B incompatibility problem significant.
 
WRT removal of plan-b good luck. My attempt to remove a seven year old "TODO: remove this" of some obsolete plan-b SDP bits was reverted because it broke a "downstream project". Go figure ;-)

Indeed - fixing bugs in a live ecosystem and platform can be hard. I appreciate everyone's work making progress, and am glad it's happening. These efforts make a real difference for the long-term health of the web.


Yoav Weiss

unread,
Jan 12, 2021, 5:48:15 PM1/12/21
to Chris Harrelson, Philipp Hancke, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik
LGTM2 to the timelines and plan outlined by Chris above.

A quick search online shows a bunch of folks complaining about Jitsi's compatibility issues with Firefox, so it seems important and impactful to push that ecosystem in the right direction there. (even if I don't know if this is the only issue)
While it's understandable that getting the long tail of users to upgrade their locally installed software may be hard, it seems important to try. Being vocal about the fact that this change is coming can be helpful in driving usage down and limit the eventual breakage once support is removed.

Nils Ohlmeier

unread,
Jan 12, 2021, 6:20:49 PM1/12/21
to blink-dev, Chris Harrelson, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws, philipp...@googlemail.com
On Tuesday, January 12, 2021 at 1:39:30 PM UTC-8 Chris Harrelson wrote:
 
Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.

I disagree that unified-plan vs plan-b is the #1 reason for this when it comes to WebRTC. This is just a boring schism without much impact on quality.

I hear you. Nevertheless, we won't get to full compatibility unless we keep making progress on all of the parts that differ. Also, one other data point: I have heard directly from Mozilla that they consider the Plan B incompatibility problem significant.

Yes. Plan B is hurting from a web compat perspective the browsers which don't support Plan B significantly in two ways:
1) There are several bigger services out there which still only work with Plan B. Our hope is that concrete dates, and potentially a Reverse Origin Trial, help getting these services off Plan B, hopefully this year.
2) I think it has been mentioned before that Unified support in libwebrtc, which Firefox uses partially, still has bugs, which should get resolved. Hopefully moving the bigger services off Plan B will result in getting higher priority for these issues to be addressed.

Best
  Nils Ohlmeier
  Firefox Media Engineering Manager

Emil Ivov

unread,
Jan 12, 2021, 6:37:41 PM1/12/21
to Harald Alvestrand, Chris Harrelson, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
Hey Harald,

On Tue, Jan 12, 2021 at 2:37 PM Harald Alvestrand <h...@google.com> wrote:
Emil, "staying with the warning" is exactly the strategy that we're planning to use until June.
Before the reverse origin trial was proposed, the alternative we saw was a hard cutoff in June.
Now we have a means to give people more time if they need it.

My point is this: if you feel your browser is unnecessarily encumbered by code that is costly to maintain and that isn’t solving problems for real people or addressing your business goals: remove it. 

As long as Plan B is still available to anyone however, then the code is still there and I don't really understand the rationale about only offering it to some folks. What's the point of having to jump through the reverse trial hoop? 

Emil

Chris Harrelson

unread,
Jan 12, 2021, 6:42:22 PM1/12/21
to Emil Ivov, Harald Alvestrand, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
On Tue, Jan 12, 2021 at 3:37 PM Emil Ivov <em...@sip-communicator.org> wrote:
Hey Harald,

On Tue, Jan 12, 2021 at 2:37 PM Harald Alvestrand <h...@google.com> wrote:
Emil, "staying with the warning" is exactly the strategy that we're planning to use until June.
Before the reverse origin trial was proposed, the alternative we saw was a hard cutoff in June.
Now we have a means to give people more time if they need it.

My point is this: if you feel your browser is unnecessarily encumbered by code that is costly to maintain and that isn’t solving problems for real people or addressing your business goals: remove it. 

As long as Plan B is still available to anyone however, then the code is still there and I don't really understand the rationale about only offering it to some folks. What's the point of having to jump through the reverse trial hoop? 

Let me try to explain with an example. Let's say it takes 12 months for site X to convert from Plan B to Unified Plan, because migrating code is hard. In addition, 8 months from now, site Y decides to start supporting WebRTC for a feature.  If we deprecate for 6 months and then Reverse Origin Trial for 6 months, site X still has their 12 months to migrate, but site Y is forced to use Unified Plan.

Without the Reverse Origin Trial, site Y might accidentally use Plan B and then not realize they are creating a problem by doing so. The Reverse Origin Trial also requires sites who participate to share an email contact with Google, which allows us to coordinate the deprecation more smoothly with them to avoid problems.