Intent to Deprecate: WebRTC's Plan B SDP semantics

1390 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 AMJan 5
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 AMJan 5
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 AMJan 5
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 AMJan 6
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 AMJan 7
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 PMJan 7
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 PMJan 7
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 PMJan 8
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 PMJan 11
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 PMJan 11
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 AMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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 PMJan 12
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.

Emil Ivov

unread,
Jan 12, 2021, 9:54:06 PMJan 12
to Chris Harrelson, 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 17:42 Chris Harrelson <chri...@chromium.org> wrote:


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.

I understand the intent. However, given a default of “unified” I am not exactly sure what “accidental” use of Plan B looks like.

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.

So let me get this straight. The people who already follow developer channels like this one will hear about the ROT, then register and start listening to one more channel.

The people who don’t, won’t know about the ROT and will get the hard cut off, whenever it happens.

Here again it is not entirely clear to me how anything gets better.

Please, just give people however many more months you are willing to spend maintaining the two plans.

Jan-Ivar Bruaroey

unread,
Jan 12, 2021, 10:32:16 PMJan 12
to Emil Ivov, Chris Harrelson, Harald Alvestrand, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, Philipp Hancke, Tantek Celik, blink-dev, yo...@yoav.ws
Hi Emil, I think looking at this as a cost issue for Google is a mistake. It's not a cost issue, but a migration strategy.

We at Mozilla are grateful to Google for taking this difficult but important step for web compat.

The old strategy wasn't working; an ROT is what unstuck it. The dates are arbitrary: E.g. If you think people not following dev channels need twice the time, ask to double the time ahead of ROT. It's not an argument against ROT. That's a zero-sum argument.

Presumably, press and console warnings will include the necessary information: that A) plan-b support will end at date X, and B) an ROT will be available for a limited time past that (date Y).

Devs who see neither will suffer outage. However, they'll likely be glad to learn about the ROT option at that point, rather than having to transition to unified-plan overnight.



You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/IY2amIigFFs/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPvvaa%2BA8CEoeZX_xnAkXXOY_Kc-KA3L6tcEPh%3D3Lg4wZ%3D64_A%40mail.gmail.com.

Philipp Hancke

unread,
Jan 13, 2021, 1:49:44 AMJan 13
to Yoav Weiss, Chris Harrelson, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik
Am Di., 12. Jan. 2021 um 23:48 Uhr schrieb Yoav Weiss <yo...@yoav.ws>:
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)

The compability issues are probably not related to the SDP format. See
which has aged remarkably well.

Henrik Boström

unread,
Jan 13, 2021, 6:34:22 AMJan 13
to blink-dev, philipp...@googlemail.com, Chris Harrelson, Henrik Boström, blink-dev, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
Google Meet is still on Plan B with an ongoing experiment to migrate to Unified Plan. Most other Google products I could think of are already on Unified Plan AFAIK.
Here's a list of non-Google services that I could think of and which SDP format they use, to the best of my knowledge:

Screenshot 2021-01-13 at 12.25.24.png

Part of the deprecation process will be to get and analyze UKM metrics to get a better sense of which services need to migrate so that we can keep track of that and get in contact if needed.

Philipp Hancke

unread,
Jan 13, 2021, 7:00:56 AMJan 13
to Henrik Boström, blink-dev, Chris Harrelson, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
Am Mi., 13. Jan. 2021 um 12:34 Uhr schrieb Henrik Boström <hb...@chromium.org>:
Google Meet is still on Plan B with an ongoing experiment to migrate to Unified Plan. Most other Google products I could think of are already on Unified Plan AFAIK.

Thank you for giving the elephant in the room a name. As long as Google Meet wasn't migrating, plan-b was ok, now it isn't?
(cf getDisplayMedia and the continued usage of the extension API through the thunk extension which allows things the spec does not)

Here's a list of non-Google services that I could think of and which SDP format they use, to the best of my knowledge:

Screenshot 2021-01-13 at 12.25.24.png

Zoom only uses datachannel, no?
Chime is using plan-b.
appear.in uses a mix of plan-b and unified-plan, see way above for the reason.
As an additional datapoint: pornhub uses unified-plan, see https://mediasoup.discourse.group/t/pornhub-uses-mediasoup/685

Harald Alvestrand

unread,
Jan 13, 2021, 7:06:51 AMJan 13
to Philipp Hancke, Henrik Boström, blink-dev, Chris Harrelson, Emil Ivov, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
Plan B stopped being OK the day IETF adopted Unified Plan (2013, https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00).


Emil Ivov

unread,
Jan 13, 2021, 8:02:45 AMJan 13
to Harald Alvestrand, Philipp Hancke, Henrik Boström, blink-dev, Chris Harrelson, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
On Wed, Jan 13, 2021 at 6:06 AM Harald Alvestrand <h...@google.com> wrote:
Plan B stopped being OK the day IETF adopted Unified Plan (2013, https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00).

Well, that's a bit harsh isn't it?

Approval by a handful of engineers (should we be generous and say 200? although arguably the number of people with meaningful contribution to the discussions was probably around 20 at best, and half of those had serious reservations) is indeed one way to look at this. 

Another, would be to look at the number of people out there who are able to solve their daily communication needs through Plan B ( I suppose a conservative estimate would put us in the hundreds of millions) and to ask ourselves how many of them would be excited about the transition to Unified. 

It is useful to remind ourselves that, ultimately, standardization is not a goal in and of itself. It is supposed to bring value to users. If you remove that, then we have ...

I mean I don't know .... what would be the best word for a set of beliefs and rules that people continue to follow even when they demonstrably no longer serve the reason for which they were put in place? 

Emil

Yoav Weiss

unread,
Jan 13, 2021, 8:21:05 AMJan 13
to Emil Ivov, Harald Alvestrand, Philipp Hancke, Henrik Boström, blink-dev, Chris Harrelson, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik
On Wed, Jan 13, 2021 at 2:02 PM Emil Ivov <em...@sip-communicator.org> wrote:
On Wed, Jan 13, 2021 at 6:06 AM Harald Alvestrand <h...@google.com> wrote:
Plan B stopped being OK the day IETF adopted Unified Plan (2013, https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00).

Well, that's a bit harsh isn't it?

Approval by a handful of engineers (should we be generous and say 200? although arguably the number of people with meaningful contribution to the discussions was probably around 20 at best, and half of those had serious reservations) is indeed one way to look at this. 

Another, would be to look at the number of people out there who are able to solve their daily communication needs through Plan B ( I suppose a conservative estimate would put us in the hundreds of millions) and to ask ourselves how many of them would be excited about the transition to Unified. 

It is useful to remind ourselves that, ultimately, standardization is not a goal in and of itself. It is supposed to bring value to users.

Indeed, the goal here is to bring value to users. The continued use of plan B is hurting users of some browsers, who can't fully use services that do so.
The plan here is to make sure changes are made so that those services would move to the more standard and more broadly supported alternative.
 
If you remove that, then we have ...

I mean I don't know .... what would be the best word for a set of beliefs and rules that people continue to follow even when they demonstrably no longer serve the reason for which they were put in place? 

I sense this discussion is sliding towards not-so-productive territory. I suggest we'd stop it from doing so.

Emil Ivov

unread,
Jan 13, 2021, 9:38:53 AMJan 13
to Yoav Weiss, Harald Alvestrand, Philipp Hancke, Henrik Boström, blink-dev, Chris Harrelson, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik
On Wed, Jan 13, 2021 at 7:20 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Jan 13, 2021 at 2:02 PM Emil Ivov <em...@sip-communicator.org> wrote:
On Wed, Jan 13, 2021 at 6:06 AM Harald Alvestrand <h...@google.com> wrote:
Plan B stopped being OK the day IETF adopted Unified Plan (2013, https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00).

Well, that's a bit harsh isn't it?

Approval by a handful of engineers (should we be generous and say 200? although arguably the number of people with meaningful contribution to the discussions was probably around 20 at best, and half of those had serious reservations) is indeed one way to look at this. 

Another, would be to look at the number of people out there who are able to solve their daily communication needs through Plan B ( I suppose a conservative estimate would put us in the hundreds of millions) and to ask ourselves how many of them would be excited about the transition to Unified. 

It is useful to remind ourselves that, ultimately, standardization is not a goal in and of itself. It is supposed to bring value to users.

Indeed, the goal here is to bring value to users. The continued use of plan B is hurting users of some browsers, who can't fully use services that do so.
The plan here is to make sure changes are made so that those services would move to the more standard and more broadly supported alternative.

If what you are saying is true, you should be able to back it up by showing evidence such as: all major comms services have already deployed unified support in order to stop the hemorrhage of users for whom lack of firefox support is a problem.

The stats that we have been presented certainly don't appear to back that claim. 

Emil

Henrik Boström

unread,
Jan 13, 2021, 10:37:27 AMJan 13
to blink-dev, Emil Ivov, Harald Alvestrand, philipp...@googlemail.com, Henrik Boström, blink-dev, Chris Harrelson, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
Stuff like this is bad: https://i.imgur.com/ebKrrbG.png
Found it by searching for Facebook messenger group calling support in Firefox. I don't know whether or not they've fixed that yet, but having all browsers behave the same is the goal.
This discussion should not be about whether or not Plan B should be deprecated, but how best to do so. I think 6-12 months is a good target.

Philipp Hancke

unread,
Jan 13, 2021, 10:39:32 AMJan 13
to Yoav Weiss, Emil Ivov, Harald Alvestrand, Henrik Boström, blink-dev, Chris Harrelson, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik
Am Mi., 13. Jan. 2021 um 14:20 Uhr schrieb Yoav Weiss <yo...@yoav.ws>:


On Wed, Jan 13, 2021 at 2:02 PM Emil Ivov <em...@sip-communicator.org> wrote:
On Wed, Jan 13, 2021 at 6:06 AM Harald Alvestrand <h...@google.com> wrote:
Plan B stopped being OK the day IETF adopted Unified Plan (2013, https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00).

Well, that's a bit harsh isn't it?

Approval by a handful of engineers (should we be generous and say 200? although arguably the number of people with meaningful contribution to the discussions was probably around 20 at best, and half of those had serious reservations) is indeed one way to look at this. 

Another, would be to look at the number of people out there who are able to solve their daily communication needs through Plan B ( I suppose a conservative estimate would put us in the hundreds of millions) and to ask ourselves how many of them would be excited about the transition to Unified. 

It is useful to remind ourselves that, ultimately, standardization is not a goal in and of itself. It is supposed to bring value to users.

Indeed, the goal here is to bring value to users. The continued use of plan B is hurting users of some browsers, who can't fully use services that do so.

Lets extend hbos' table by a Firefox support column:
gmeet: yes
Zoom: datachannel, so no relevant?
Messenger: dropped recently
Chime: supported according to their docs
Jitsi: yes
Twilio: yes
Discord: supported according to their docs
slack: no
whereby: yes
gotomeeting: no
peer5: datachannel, so no relevant?
webex: yes
skype: no
teams: no


One of the reasons for the lack of support in messenger (workplace actually), skype and teams (note that all three have a very large base of non-browser based clients, in the case of messenger using webrtc-org) is Mozilla honoring a MUST NOT IMPLEMENT that Chrome doesn't:

The plan here is to make sure changes are made so that those services would move to the more standard and more broadly supported alternative.
 How is removing plan-b going to make slack support Firefox? I never got an answer to this sadly.
Happy to do introductions to G2M folks but I do not think that is necessary.

Saúl Ibarra Corretgé

unread,
Jan 13, 2021, 11:14:40 AMJan 13
to blink-dev, Jan-Ivar Bruaroey, Chris Harrelson, Harald Alvestrand, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, philipp...@googlemail.com, Tantek Celik, blink-dev, yo...@yoav.ws, Emil Ivov
The problem I see with the ROT approach (that I haven't seen mentioned before) is that "Jitsi" is not only "meet.jit.si", it's also the myriad self-hosted installations who may not know about any of this. We don't phone home so we can't know the number, but it's not insignificant. I assume other similar projects still on plan B may have the same problem.

By imposing the ROT the time those folks have to update to an updated version which uses unified would just be 6 months, vs a whole year if there is no ROT.

Christian Biesinger

unread,
Jan 13, 2021, 11:21:28 AMJan 13
to Saúl Ibarra Corretgé, blink-dev, Jan-Ivar Bruaroey, Chris Harrelson, Harald Alvestrand, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Emil Ivov
But if there's no ROT and they are unaware of anything going on, then they are out of luck, whereas with a ROT they can apply for one and keep things working.

Christian

Emil Ivov

unread,
Jan 13, 2021, 11:24:50 AMJan 13
to Henrik Boström, blink-dev, Harald Alvestrand, philipp...@googlemail.com, Chris Harrelson, Harald Alvestrand, Jan-Ivar Bruaroey, Tantek Celik, yo...@yoav.ws
On Wed, Jan 13, 2021 at 9:37 AM Henrik Boström <hb...@chromium.org> wrote:
Whether stuff like this is bad is between Facebook and their users. If FB felt it was bad, they have the means to fix that today. 

Disabling "Plan B" isn't going to help FB support Firefox. It is going to simply impose the decision on them. 

So, since you raise it, the question really is about whether or not you feel you are better placed than FB to decide what browsers FB should support.

Emil Ivov

unread,
Jan 13, 2021, 11:26:50 AMJan 13
to Christian Biesinger, Saúl Ibarra Corretgé, blink-dev, Jan-Ivar Bruaroey, Chris Harrelson, Harald Alvestrand, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws
I believe the only two alternatives we are discussing are:

1. 6 months to EoL + 6 of ROT
2. 12 months to EoL 

Saul's point is that 12 months to EoL gives people more time to upgrade their Jitsi installations, which they are more likely to do than go through the ROT process.

Emil

Jan-Ivar Bruaroey

unread,
Jan 13, 2021, 12:16:23 PMJan 13
to blink-dev, Emil Ivov, Saúl Ibarra Corretgé, blink-dev, Jan-Ivar Bruaroey, Chris Harrelson, Harald Alvestrand, Harald Alvestrand, Henrik Boström, Jan-Ivar Bruaroey, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Christian Biesinger
As has been pointed out before in this thread, this seems like a false dilemma. The isolated questions are: 1) To ROT or not? 2) Are dates agreeable?

Emil, can you clarify whether the issue is time or the ROT?

All other things being equal — meaning: we don't tie the presence of ROT to the false premise that NOT having one somehow buys us additional time against some time constant tied to Google maintenance cost — a ROT only helps ameliorate the tensions that normally causes deadlines to drift. Assuming we want the migration to succeed, what are the inherent arguments against it?

.: Jan-Ivar :.

Emil Ivov

unread,
Jan 13, 2021, 1:02:18 PMJan 13
to Jan-Ivar Bruaroey, blink-dev, Saúl Ibarra Corretgé, Jan-Ivar Bruaroey, Chris Harrelson, Harald Alvestrand, Harald Alvestrand, Henrik Boström, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Christian Biesinger
On Wed, Jan 13, 2021 at 11:16 AM Jan-Ivar Bruaroey <jbru...@mozilla.com> wrote:
As has been pointed out before in this thread, this seems like a false dilemma.
The isolated questions are: 1) To ROT or not? 2) Are dates agreeable?

Emil, can you clarify whether the issue is time or the ROT?

I think I am missing your point. It seems to me that time is the only problem and the discussion is about how much more time should people get and under what conditions.

What I am asking is that the conditions for giving people more time not be restricted to ROT. 

All other things being equal — meaning: we don't tie the presence of ROT to the false premise that NOT having one somehow buys us additional time against some time constant tied to Google maintenance cost — a ROT only helps ameliorate the tensions that normally causes deadlines to drift. Assuming we want the migration to succeed, what are the inherent arguments against it?

The only purpose of the ROT solution is to provide more time to people but with some added pressure. 

Why is a ROT extension acceptable? My understanding is that because we all acknowledge that not providing one may result in negative impact for many users. 

What I am pointing out is that ROT is not a great solution for avoiding that impact on users of software with distributed deployments, such as the Jitsi open source project.

Emil

Chris Harrelson

unread,
Jan 13, 2021, 1:10:53 PMJan 13
to Emil Ivov, Jan-Ivar Bruaroey, blink-dev, Saúl Ibarra Corretgé, Jan-Ivar Bruaroey, Harald Alvestrand, Harald Alvestrand, Henrik Boström, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Christian Biesinger
HI Emil,

Let me ask a different question: do you think 6 months suffice for the sites you're concerned about to migrate? 12? And if so, could you tell us more about the challenges you expect that would lead to longer times?

Emil Ivov

unread,
Jan 13, 2021, 1:51:59 PMJan 13
to Chris Harrelson, Jan-Ivar Bruaroey, blink-dev, Saúl Ibarra Corretgé, Jan-Ivar Bruaroey, Harald Alvestrand, Harald Alvestrand, Henrik Boström, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Christian Biesinger
Hey Chris,

The answer to that would be: we'd like to have as much time as we can get.

The goal, I am sure we would agree, would be to minimize the number of users who cannot get onto a call because of the Plan switch. It is likely a safe bet that, with or without Jitsi, this number would be always decreasing and never really quite get to 0. So, if it were up to us, the Jitsi devs, we would love a decision for Chrome to never disable Plan B. 

It was my understanding that the main reason against such a decision is the cost of maintenance of double the necessary signaling code. (Or at least that's the only sensical and pragmatic I have heard articulated ). 

So therefore my answer to your question is: for however long you can afford to keep that code in webrtc and Chromium, please keep access to it unrestricted by a ROT. 

If you can keep the code alive for 12 months, then fine, 12 it is. However please don't restrict the second 6 months by the ROT.

Does this make sense?

Emil

Jan-Ivar Bruaroey

unread,
Jan 13, 2021, 3:36:57 PMJan 13
to blink-dev, Emil Ivov, Jan-Ivar Bruaroey, blink-dev, Saúl Ibarra Corretgé, Jan-Ivar Bruaroey, Harald Alvestrand, Harald Alvestrand, Henrik Boström, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Christian Biesinger, Chris Harrelson
I see, working backwards from a perceived internal deadline. For argument's sake, say you're right and costs are the main issue, which deadline approach does Google think is least likely to slip (cold vs. ROT)?

If this is a negotiation, I'd point out Google hasn't offered 12 months without a ROT. The deadline offered is July, two months after taxes are due in the US. Persons in the US can file for a 6-month extension, but that application for extension is still due April 15th. Why doesn't the US Government simply give everyone until October? This is hopefully obvious: because people would then be begging for an extension in October.

ROT = extension.

Unlike the US Government, I'm assuming Google will have some grace period where people past the deadline can still sign up for the ROT, so they aren't stranded.

.: Jan-Ivar :.

Chris Harrelson

unread,
Jan 13, 2021, 3:55:23 PMJan 13
to Jan-Ivar Bruaroey, blink-dev, Emil Ivov, Saúl Ibarra Corretgé, Jan-Ivar Bruaroey, Harald Alvestrand, Harald Alvestrand, Henrik Boström, philipp...@googlemail.com, Tantek Celik, yo...@yoav.ws, Christian Biesinger
On Wed, Jan 13, 2021 at 12:36 PM Jan-Ivar Bruaroey <jbru...@mozilla.com> wrote:
I see, working backwards from a perceived internal deadline. For argument's sake, say you're right and costs are the main issue, which deadline approach does Google think is least likely to slip (cold vs. ROT)?

If this is a negotiation, I'd point out Google hasn't offered 12 months without a ROT. The deadline offered is July, two months after taxes are due in the US. Persons in the US can file for a 6-month extension, but that application for extension is still due April 15th. Why doesn't the US Government simply give everyone until October? This is hopefully obvious: because people would then be begging for an extension in October.

ROT = extension.

Unlike the US Government, I'm assuming Google will have some grace period where people past the deadline can still sign up for the ROT, so they aren't stranded.

Yes - our policy with all OTs, ROTs included, is that developers may sign up for them at any time during the duration of the trial.
 

Nils Ohlmeier

unread,
Jan 14, 2021, 12:37:12 AMJan 14