Intent to deprecate and remove: RTCConfiguration.offerExtmapAllowMixed

[Philipp Hancke]

Primary eng (and PM) emails

philipp...@googlemail.com, h...@chromium.org, 

Summary

RTCConfiguration.offerExtmapAllowMixed is a non-standard option in the RTCPeerConnection’s RTCConfiguration. It was added as transitional property in order to enable a SDP feature that caused breakages with older versions of the WebRTC library (<M70).

Old intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/7z3uvp0-ZAc/m/-4s8ps2pBAAJ

That feature shipped default on in Chrome 89, see the PSA on discuss-webrtc:

https://groups.google.com/g/discuss-webrtc/c/24LiX06HwpM

Motivation

It is a non-standard feature and the agreement back then was to remove it.

Interoperability and Compatibility Risk

Since Chrome 89 shipped the usage of offerExtmapAllowMixed: false has become non-zero on March 17. See here for some numbers:

https://bugs.chromium.org/p/webrtc/issues/detail?id=9985#c25

and essentially static usage since then.

This usage pattern suggests a single vendor who started using this recently.

The goal is to deprecate the feature before it sticks.

Alternative implementation suggestion for web developers

This is still required for interoperability with outdated (and vulnerable) versions of WebRTC <M70, e.g. Safari 12.0.

If this option is removed, developers can still modify the SDP and remove the ‘a=extmap-allow-mixed\r\n’ line during signalling which is allowed by the specification.

The adapter.js polyfill has been providing an implementation of this on the receiving end for a while:

  https://github.com/webrtcHacks/adapter/blob/master/src/js/common_shim.js#L319

Usage information from UseCounter

n/a, see above for UMA stats.

Entry on the feature dashboard

the original one is here:

https://www.chromestatus.com/feature/6269234631933952

Does the deprecation need a separate one?

[Mike Taylor]

On 4/7/21 7:07 AM, 'Philipp Hancke' via blink-dev wrote:
> Interoperability and Compatibility Risk
>
> Since Chrome 89 shipped the usage of offerExtmapAllowMixed: false has
> become non-zero on March 17. See here for some numbers:
>
> https://bugs.chromium.org/p/webrtc/issues/detail?id=9985#c25
> <https://bugs.chromium.org/p/webrtc/issues/detail?id=9985#c25>
>
> and essentially static usage since then.
>
>
> This usage pattern suggests a single vendor who started using this recently.
>
> The goal is to deprecate the feature before it sticks.

Here's a few interesting GitHub issues:

In https://github.com/twilio/twilio-video.js/issues/1409#issue-822773709
its recommended to use `offerExtmapAllowMixed: false` as a workaround
for SDP interop issues (see comment for more on that), and there's an
additional comment later that the fix was rolled out on March 5th.

Bluejeans also added that in
https://github.com/bluejeans/sdk-webrtc-meetings/commit/1c1e5a7377049815ce0c31fa9a10dedef7e7beee#diff-8c33cb46595c8aa1663dd1e4ec6f024a2340df7708d7e2649fdc264f036fd3dfR34765
on March 6th.

It's probably worth opening issues on both of these repos to give them a
heads up, if we don't have better contacts with Twilio and Bluejeans.

thanks,
Mike

[Philipp Hancke]

Hey Mike,

Bluejeans has been poked and Twilio has eliminated need for (though I need to check if also their use of) that constraint in favor of SDP munging during signalling (which for a cpaas vendor is much easier since they don't need their customers to upgrade).

Neither matches the March 17th date and the combination of "late to notice" and "large" is odd.

Driving down the numbers again by talking to vendors would be much preferred of course but so far nobody has said "yes, that was us".

thanks,
Mike

[Harald Alvestrand]

The first purpose of the deprecation is to get the deprecation notice in, so that the people who are using the workaround can find other ways to do it (or be warned not to try this when they attempt it based on the net-visible advice).

The original reason for the workaround was for interworking with people who had branched the webrtc library prior to M71; we really really hope that people are beyond that point now.

Usage is still very low (0.0000x% range), and we'd like to get the deprecation notice in before it grows any larger.

Harald

--
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/CADxkKiLrW8SA_zGy_SFUPj5sX5%2Bye7P8KmxeUPYqEjS60hvV7g%40mail.gmail.com.

[Alex Russell]

Thanks for the clarification Harald,

I'm a little unclear as to the request's timelines. Is the goal here to land a deprecation notice ASAP and follow up later with an intent to remove? Has there been consideration of a reverse-origin-trial to help set a cap on use?

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Harald Alvestrand]

Given that M91 branch cut is today, a reasonable schedule would be to land the deprecation notice in M92 and remove the option in M94; I don't see a reason to drag it out for more than 2 milestones, given the low usage.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yoav Weiss]

On Fri, Apr 9, 2021 at 12:07 AM 'Harald Alvestrand' via blink-dev <blin...@chromium.org> wrote:

Given that M91 branch cut is today, a reasonable schedule would be to land the deprecation notice in M92 and remove the option in M94; I don't see a reason to drag it out for more than 2 milestones, given the low usage.

I'd expect a deprecation notice to be something you can easily merge back, if y'all wish to take that route.

Otherwise, you mention low usage, but the bug says there's been a recent jump from 0 to 0.2%. I wouldn't consider the latter low. Can y'all use UKM to try and find the source for that recent jump in usage?

Can it be explained by the GH links Mike posted here?

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

[Yoav Weiss]

Friendly ping!

Harald - can you help out Philipp with the above digging?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

--
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+unsubscribe@chromium.org.

[Harald Alvestrand]

I'm on chat with Philipp about this. All the most obvious candidates have been queried and said "not us".

The 0.2% is 0.2% of peerconnections, not 0.2% of pageloads (I think peerconnection usage is ~9%, including trackers), so that would be 0.0001% of pageloads.

Yes, we should backmerge the warning to M91. Even if we don't expedite removal, early warning has no downsides.

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/CADxkKiLrW8SA_zGy_SFUPj5sX5%2Bye7P8KmxeUPYqEjS60hvV7g%40mail.gmail.com.

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

[Yoav Weiss]

LGTM1 to deprecate in M91, and attempt to remove in M93, assuming usage doesn't get higher. If it does, please come back to this thread.

Can you also expose the related usecounters as UKM, so that we'd be able to know who's using it, instead of guessing?

[Daniel Bratell]

LGTM2

> The 0.2% is 0.2% of peerconnections, not 0.2% of pageloads (I think peerconnection usage is ~9%, including trackers), so that would be 0.0001% of pageloads.

I don't understand this math. Seems to be x100 off? It doesn't change my LGTM2, but you need to keep an eye on that usage (as Yoav said)

/Daniel

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

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc4cc53f-83cc-70bd-bfb9-4d90742a98db%40gmail.com.

[Philipp Hancke]

Am Do., 22. Apr. 2021 um 18:15 Uhr schrieb Daniel Bratell <brat...@gmail.com>:

LGTM2

> The 0.2% is 0.2% of peerconnections, not 0.2% of pageloads (I think peerconnection usage is ~9%, including trackers), so that would be 0.0001% of pageloads.

I don't understand this math. Seems to be x100 off? It doesn't change my LGTM2, but you need to keep an eye on that usage (as Yoav said)

WebRTC numbers are *terribly* hard to interpret due to the noise from the (hopefully in vain) attempts to gather a clients IP (which is the reason for the 9% of pageloads)

Before the pandemic we had https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c13 where a seemingly safe removal of DTLS 1.0 would have affected 0.15% of peerconnections.

Turned out to affect services the size of webex and then took a *long* time to actually ship (only recently).

The increase in WebRTC usage in the last year means all numbers are through the roof and it is very hard to get a good baseline :-|

I hope the console warning will be enough will be enough to drive the numbers down again.

Thanks

Philipp

[Philipp Hancke]

removed in https://chromiumdash.appspot.com/commit/9749ed1096b468117523dcfea7a11e48230912b7

The source of the big jump agreed they don't actually need it \o/