Intent to deprecate and remove: RTCConfiguration.offerExtmapAllowMixed

310 views
Skip to first unread message

Philipp Hancke

unread,
Apr 7, 2021, 8:07:21 AMApr 7
to blink-dev

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

unread,
Apr 7, 2021, 5:24:57 PMApr 7
to Philipp Hancke, blink-dev
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

unread,
Apr 8, 2021, 2:12:10 AMApr 8
to Mike Taylor, blink-dev
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

unread,
Apr 8, 2021, 3:45:37 PMApr 8
to Philipp Hancke, Mike Taylor, blink-dev
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

unread,
Apr 8, 2021, 3:56:54 PMApr 8
to blink-dev, Harald Alvestrand, Mike Taylor, blink-dev, philipp...@googlemail.com
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

unread,
Apr 8, 2021, 6:07:50 PMApr 8
to Alex Russell, blink-dev, Mike Taylor, philipp...@googlemail.com
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

unread,
Apr 9, 2021, 4:39:25 AMApr 9
to Harald Alvestrand, Alex Russell, blink-dev, Mike Taylor, philipp...@googlemail.com
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?

Yoav Weiss

unread,
Apr 15, 2021, 3:23:16 PMApr 15
to blink-dev, Yoav Weiss, Alex Russell, blink-dev, Mike Taylor, philipp...@googlemail.com, Harald Alvestrand
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.

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

unread,
Apr 16, 2021, 3:27:37 AMApr 16
to Yoav Weiss, blink-dev, Alex Russell, Mike Taylor, philipp...@googlemail.com
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.

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

unread,
Apr 16, 2021, 3:34:05 AMApr 16
to Harald Alvestrand, blink-dev, Alex Russell, Mike Taylor, philipp...@googlemail.com
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

unread,
Apr 22, 2021, 12:15:20 PMApr 22
to Yoav Weiss, Harald Alvestrand, blink-dev, Alex Russell, Mike Taylor, philipp...@googlemail.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)

/Daniel

Chris Harrelson

unread,
Apr 22, 2021, 12:25:36 PMApr 22
to Daniel Bratell, Yoav Weiss, Harald Alvestrand, blink-dev, Alex Russell, Mike Taylor, philipp...@googlemail.com

Philipp Hancke

unread,
Apr 22, 2021, 3:12:02 PMApr 22
to Daniel Bratell, Yoav Weiss, Harald Alvestrand, blink-dev, Alex Russell, Mike Taylor
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

unread,
Aug 6, 2021, 3:26:17 AMAug 6
to blink-dev
The source of the big jump agreed they don't actually need it \o/
Reply all
Reply to author
Forward
0 new messages