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.
On Monday, January 18, 2021 at 3:42:37 PM UTC+1 Henrik Boström wrote:
> 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.
>
> On Friday, January 15, 2021 at 5:03:00 PM UTC+1 michael....@logmein.com
> wrote:
>
>> 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
>>> <https://sites.google.com/a/chromium.org/dev/blink?pli=1#TOC-Policy-for-shipping-and-removing-web-platform-API-features>.
>>>
>>> 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
>>> <https://docs.google.com/document/d/1-ZfikoUtoJa9k-GZG1daN0BU3IjIanQ_JSscHxQesvU/edit?usp=sharing>
>>> .
>>>
>>> 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
>>> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
>>>
>>> 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
>>> <http://www.chromestatus.com/metrics/feature/timeline/popularity/199>)
>>>
>>> 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 <https://www.chromestatus.com/>
>>>
>>> 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
>>> <http://blog.chromium.org/2014/04/chrome-35-beta-more-developer-control.html>).
>>>
>>> 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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cbd918cd-758f-4c53-8d51-69b71c612932n%40chromium.org.
