Intent to Deprecate: WebRTC's Plan B SDP semantics

[Henrik Boström]

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]

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]

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?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJsbaofgMv33KfGUU%3DvWTQ%3De0Z93PhbriED%2Buf3h1BcFA%40mail.gmail.com.

[Harald Alvestrand]

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:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJsbaofgMv33KfGUU%3DvWTQ%3De0Z93PhbriED%2Buf3h1BcFA%40mail.gmail.com.

[Henrik Boström]

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]

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:

https://bugs.chromium.org/p/webrtc/issues/detail?id=10641

(ironically one of the few arguments for unified plan was that you can apply per-mline bandwidth limits)

https://bugs.chromium.org/p/chromium/issues/detail?id=996666

(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

  https://jsfiddle.net/fippo/hwug4a8m/1/

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]

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.

https://bugs.chromium.org/p/webrtc/issues/detail?id=10641

(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.

 

https://bugs.chromium.org/p/chromium/issues/detail?id=996666

(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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8010f2dc-2b17-4dd1-be42-a69b613e82c7n%40chromium.org.

[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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c1bb547-87b2-466c-bc25-d36546003afen%40chromium.org.

[Henrik Boström]

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]

Typo alert! M90 is Stable on April 6, 2021

[Emil Ivov]

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]

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]

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]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c0ea26a-0dd3-4121-afbc-16e84475ba77n%40chromium.org.

[Philipp Hancke]

How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?

[Chris Harrelson]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKa8ZL8np%2B-jnj-h6EjdYgE9%3D9GQK5unstSFfU2wUzi1g%40mail.gmail.com.

[Philipp Hancke]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJxsvg%2Bbx50SyfgE9yVqPjROAW9i8zxnDTpjuO%3DE3Jx-A%40mail.gmail.com.

[Yoav Weiss]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPvvaaKw626xRyw6N7F9gmgv2gTr_VJ%2Bt%3D4uJrzkkft1E4CBdQ%40mail.gmail.com.

[Emil Ivov]

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]

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]

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

https://hacks.mozilla.org/2015/06/firefox-multistream-and-renegotiation-for-jitsi-videobridge/

which has aged remarkably well.

[Henrik Boström]

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:

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]

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:

Zoom only uses datachannel, no?

Chime is using plan-b.

Twilio is using unified plan, see https://bugs.chromium.org/p/chromium/issues/detail?id=1127625

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]

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]

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]

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]

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]

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]

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:

  https://bugs.chromium.org/p/chromium/issues/detail?id=804275

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é]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6ea7ef0-03f2-4fca-b2eb-f214ea0ff0b2n%40chromium.org.

[Emil Ivov]

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]

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]

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]

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]

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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPvvaaLs6QZC5Hzvg4%3DtCWgOwsNsbXTBxv2RuFEdaUo5wRiPeQ%40mail.gmail.com.

[Emil Ivov]

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]

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]

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.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/48d71de7-1699-427a-8564-8072166ac078n%40chromium.org.

[Nils Ohlmeier]

On Wednesday, January 13, 2021 at 10:51:59 AM UTC-8 Emil Ivov wrote:

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.

Actually no. The goal from my point of view, as I don't have customers stuck on Plan B, is to get as many users across different browsers (and non-browser end points) onto calls on all services. That is is currently prevented as shown by Hendrik's and Fippo's lists by some service which only support Plan B as of now.

It is likely a safe bet that, with or without Jitsi, this number would be always decreasing and never really quite get to 0.

Agreed.

So, if it were up to us, the Jitsi devs, we would love a decision for Chrome to never disable Plan B. 

I don't think that is an option as you are basically putting your customers interests over the agreed on working group decision and an open and standardized web. As others have said before: the discussion here is not about undoing a rough consensus from years ago.

If I understand you correctly from Jitsi's perspective Plan B is good enough, because it works. So what is needed from Jitsi's point of view to make Unified Plan in Chrome a good enough alternative?

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 ).

No. It is about a standardized web, as much as possible. And Plan B is not standardized.

 

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.

Can you explain how 12 months will help to migrate more Jitsi users to Unified Plan?

I understood from your previous emails that you don't know the users and have no way to communicate to them directly. So how are these additional 6 months going to help convert more to Unified Plan?

Best

  Nils

[Nils Ohlmeier]

On Wednesday, January 13, 2021 at 7:39:32 AM UTC-8 philipp...@googlemail.com wrote:

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:

Indeed some services run in dual headed mode: they are using Plan B for Chrome, and Unified Plan for Firefox and Safari. Google Meet is probably a good example.

gmeet: yes

Zoom: datachannel, so no relevant?

Correct. Works in all browser with data channels.

Messenger: dropped recently

Actually it works in Firefox for 1:1 calls. There is an issue between Firefox and FB Portal devices.

Group calls never worked on Firefox because of Plan B support only on FB side.

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

Partially supported I would say. No video yet.

But yes to summarize it: the list of big services which don't work in Firefox because of Plan B only are Facebook group calls, Slack, MS Teams, Skype for Web.

Best

  Nils Ohlmeier

[Emil Ivov]

Hey Nils,

On Wed, Jan 13, 2021 at 7:26 PM Nils Ohlmeier <nohl...@mozilla.com> wrote:

So, if it were up to us, the Jitsi devs, we would love a decision for Chrome to never disable Plan B. 

I don't think that is an option as you are basically putting your customers interests over the agreed on working group decision and an open and standardized web.

You made my day! :)

Yes, I am, 100%,! Always! Our users and customers are who I represent in this discussion.

Back to the topic. This isn't a discussion on ideologies or an attempt to reopen the plan discussions. We are discussing the minimization of friction for users on the path to migration. In our case we get most of the friction by delaying the cut off for as much as possible so that a maximum number of people can update their Jitsi installations. And we do recognize that this cutoff will absolutely happen eventually

So here's what I suggest. Jitsi master will switch to  Plan B for chrome within a quarter of Google Meet switching. 

We then ask for as much time as possible so that a maximum number people will have time to properly update their installations. 

Does this make sense to everyone?

Emil

[Saúl Ibarra Corretgé]

If the deprecation note will come in a form of something in DevTools, I think not many will see it, at least that’s my experience supporting users of self-hosted Jitsi Meet installations.

Not having the ROT would give us more time to push an update and hopefully they do update in time.

A way to make things more obvious could be with some sort of UI for a “stronger” deprecation message. Something like the banner that shows up when you enable one of the —insecure- flags. This could be shown just a few times per domain using plan B.

--
Saúl

[Philip Jägenstedt]

There's a lot to take in in this thread, but since I'll try to summarize my understanding so that I'm not missing anything.

As a web-exposed web platform feature with a replacement (unified plan) implemented in Firefox and Safari, the benefits of getting rid of plan B for long term browser interoperability are very clear. Plan B should go away at some point, and that hasn't really been in question in this thread, the debate is over when and how it happens. During this process, it's likely that some of the final users of plan B will discover things that don't yet work with unified plan, and that's a good thing, then we will figure out how to make those things work with unified plan, cross-browser.

The timeline that Chris summarized upthread makes sense to me. There's a question about why we should have a reverse origin trial, since using the API already requires an opt-in. The effect of that will be that people who don't know about the upcoming change will have their sites broken when that version of Chrome is released, and some will only notice when it reaches stable. They will then have the ability to opt in to the origin trial to quickfix the problem, but there will be some user impact. While the user impact is unfortunate, this breakage a year ahead of final removal is very important, as without it these sites would only learn about it after the final removal, at which time they would have no time to migrate to unified plan, rather than 12 months.

LGTM3 to the proposed timeline.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8CFE8CC8-C682-461E-B660-D5C85034BAC5%408x8.com.

[Harald Alvestrand]

Emil, I hope you mean "Jitsi master will switch to Unified Plan for Chrome within a quarter of Google Meet switching to Unified Plan".

That's a perfectly reasonable plan seen from where I'm sitting. Let's do it!

[Emil Ivov]

On Thu, Jan 14, 2021 at 10:45 AM Harald Alvestrand <h...@google.com> wrote:

Emil, I hope you mean "Jitsi master will switch to Unified Plan for Chrome within a quarter of Google Meet switching to Unified Plan".

I am sorry, yes, that's exactly what I meant. I will still ask for some grace after that so that people have time to upgrade. 

That's a perfectly reasonable plan seen from where I'm sitting. Let's do it!

You're on!

Emil 

On Thu, Jan 14, 2021 at 4:08 PM Emil Ivov <em...@sip-communicator.org> wrote:

Hey Nils,

On Wed, Jan 13, 2021 at 7:26 PM Nils Ohlmeier <nohl...@mozilla.com> wrote:

So, if it were up to us, the Jitsi devs, we would love a decision for Chrome to never disable Plan B. 

I don't think that is an option as you are basically putting your customers interests over the agreed on working group decision and an open and standardized web.

You made my day! :)

Yes, I am, 100%,! Always! Our users and customers are who I represent in this discussion.

Back to the topic. This isn't a discussion on ideologies or an attempt to reopen the plan discussions. We are discussing the minimization of friction for users on the path to migration. In our case we get most of the friction by delaying the cut off for as much as possible so that a maximum number of people can update their Jitsi installations. And we do recognize that this cutoff will absolutely happen eventually

So here's what I suggest. Jitsi master will switch to  Plan B for chrome within a quarter of Google Meet switching. 

We then ask for as much time as possible so that a maximum number people will have time to properly update their installations. 

Does this make sense to everyone?

Emil

[Philipp Hancke]

great! Can you please *also* show SDES out?

[Philip Jägenstedt]

Chris pointed out that I misread the timeline, the final removal is Jan 2022, not July 2022 as I read it. So from the time that the last holdouts will discover the problem (Aug 24, 2021) and the time it will be removed (Jan 18, 2022) there are 5 months.

The initial deprecation message won't mention the final date of removal, so we will be able to adjust this later if needed.

[Philip Jägenstedt]

Another correction. The initial deprecation should mention the final date of removal. But as with other tricky removals, seeing how usage reacts to the deprecation message and later the reverse origin trial might change the details.

[Michael Fröhlich]

From the LogMeIn/GoToMeeting perspective: We're one of the remaining Plan B users. Primary driver really being reliability. We've tried to switch to Unified Plan a number of times in the past and have always experienced issues that stopped the migration efforts (most of these issues were already in tickets, we did file a few others.) I'm willing to give this another try.

With regards to this proposal: I'm in favour of deprecation and establishing a reverse origin trial. We'll likely take part in the reverse origin trial. I'd like to ask, however, that if the third party vendors do see problems and file tickets with respect to the Unified Plan transition -  that these tickets are prioritised or extend the duration of the reverse origin trial until said vendors have fixed their side of things or Google has fixed the problems in libwebrtc/Chrome.

I'll schedule the respective work to pursue the migration to Unified Plan.

-- Michael

Sr. Manager, RTC Platform Engineering

Henrik Boström schrieb am Dienstag, 22. Dezember 2020 um 14:03:21 UTC+1:

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).

?

[Henrik Boström]

Hi Michael, I believe our PM has reached out to you and other companies today via email, let's follow up there about issues impacting migration.

[Henrik Boström]

An update from the Chrome side is that the Deprecation Trial is ramping up in M96: https://groups.google.com/u/1/g/discuss-webrtc/c/zRIgxG18D80.