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.
Motivation
Explain why this feature should be deprecated (and eventually removed).
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?
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:
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.
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).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:
Numbers today (December):
- SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
- 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).?
--
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.
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.
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.
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.
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?
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.
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:
Numbers today (December):
- SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
- 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#c31As 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?
(ironically one of the few arguments for unified plan was that you can apply per-mline bandwidth limits)
(arguably part of this is related to not using bundle) and last but not least
https://bugs.chromium.org/p/chromium/issues/detail?id=944821 (browser-specific SDP solves this but...)
--
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.
--
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.
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.
How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?
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.
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.
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 ;-)
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.
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.
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.
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?
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.
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.
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.
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)
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:
Plan B stopped being OK the day IETF adopted Unified Plan (2013, https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00).
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?
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.
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.
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.
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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPvvaaLs6QZC5Hzvg4%3DtCWgOwsNsbXTBxv2RuFEdaUo5wRiPeQ%40mail.gmail.com.
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.
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.
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.
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: yesZoom: datachannel, so no relevant?
Messenger: dropped recently
Chime: supported according to their docsJitsi: yesTwilio: yesDiscord: supported according to their docsslack: nowhereby: yesgotomeeting: nopeer5: datachannel, so no relevant?webex: yesskype: noteams: no
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.
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.
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!
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 eventuallySo 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
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:
Numbers today (December):
- SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
- 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).?