Intent to Remove: Support for optional error handler in RTCPeerConnection's createOffer() and createAnswer()

[Guido]

Primary eng (and PM) emails

Eng: gui...@chromium.org, h...@chromium.org

PM: bl...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/deptrcate$20rtcpeerconnection/blink-dev/WderCH-rAaY/-xuEhLCMBwAJ

Summary

Make the failureCallback parameter mandatory in RTCPeerConnection.createOffer() and RTCPeerConnection.createAnswer().

Motivation

The latest version of the WebRTC spec introduces new promise-based versions of the following methods:

• createOffer

• setLocalDescription

• createAnswer

• setRemoteDescription

• addIceCandidate

The spec also maintains support for the legacy callback versions of these.

Blink currently supports the legacy version of these methods, but admits some uses that are not compliant with the spec. In the particular case of createOffer and createAnswer, some of these uses prevent us from adding the new promise-based versions due to overloading issues.

For example, the spec versions of createOffer are:

• Promise<RTCSessionDescription> createOffer (optional RTCOfferOptions options);

• void createOffer (RTCSessionDescriptionCallback successCallback, RTCPeerConnectionErrorCallback failureCallback, optional RTCOfferOptions options);

while the current Blink version is

• void createOffer (RTCSessionDescriptionCallback successCallback, optional RTCErrorCallback failureCallback, optional Dictionary options);

It can be seen that having the failureCallback parameter as optional makes it impossible to add the promise-based version since RTCOfferOptions (a dictionary) and RTCSessionDescriptionCallback (a callback) are indistinguishable types in IDL.

Existing calls that only provide the successCallback argument would become ambiguous if we added the promise-based overload.

Our plan is to remove support to failureCallback as an optional parameter, and make it mandatory instead in both createOffer and createAnswer.

Compatibility Risk

With regards to existing Web sites, making the failureCallback parameter mandatory represents a minor compatibility risk. UseCounter data shows that createOffer and createAnswer calls that provide a failureCallback argument vastly outnumber calls without a failureCallback.

With regards to compatibility with other browsers, this change will make Chromium more compatible with Firefox, which supports a more recent version of the spec than Chromium, including the new promise-based methods.

Usage information from UseCounter

How much of the web are you going to break?

createOffer with failure callback

createOffer without failure callback

createAnswer with failure callback

createAnswer without failure callback

Note that these counters were introduced in M49, so they include Beta, Dev and Canary channels only.

OWP launch tracking bug

https://crbug.com/579476

Entry on the feature dashboard

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

[Philip Jägenstedt]

Cool, fixing this will be great! Given that the use counters haven't reached stable yet, can you check what the numbers look like for the beta channel only? Many use counters are flat before reaching stable, even when they end up reaching (say) 0.1% or so.

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

[Guido]

I looked at the internal counters and most of the data comes from the dev channel. Perhaps we should give it a few more days so that more data from the beta channel becomes available.

Nevertheless, the numbers look quite good so far.

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

[Rick Byers]

Yeah, we know DEV channel has pretty skewed usage patterns, where BETA appears to be relatively representative.  So we probably shouldn't be making removal decisions based on dev channel metrics.  Probably best to wait for 49 beta to finish rolling out.

Here's the concrete numbers from dev channel:  0.0008% of page loads on Android 0.00008% on Windows.  Certainly looks promising.

Rick

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

[Philip Jägenstedt]

In the Intent to Implement and Ship: Promise-based RTCPeerConnection's setLocalDescription, setRemoteDescription and addIceCandidate methods, Guido wrote:

We believe it is a good idea to let these changes in the legacy API stabilize during one release cycle, giving developers some time to update their applications, if necessary. After this, the addition of the promise-based createAnswer() and createOffer() can be done without causing any unexpected incompatibilities with existing code.

This is an important point, shipping promise-based createOffer() and createAnswer() is blocked on making the error callbacks non-optional, plus bake time on stable for people to not accidentally end up with the promise-based variant.

Down the line is the promise of unprefixing RTCPeerConnection as a whole, which I think is an important goal, not to be delayed more than necessary.

The numbers from dev look promising, when will the numbers from 49 beta be in? If we can get them before the next branch point that's good, but if not I think that going ahead with removal anyway could still be the best option on the table.

[Guido Urdaneta]

The beta numbers for Windows are starting to arrive:

CreateOffer with error callback: 0.015%

CreateOffer without error callback: 0.000004%

CreateAnswer with error callback: 0.00067%

CreateOffer without error callback: 0.000002%

Still waiting for Android numbers, but it looks like we should proceed with removal in a couple of days.

[Philip Jägenstedt]

Those numbers looks very encouraging indeed. LGTM1, but please continue to monitor the usage, and ping this thread if it rises significantly. Anything below 0.0001% (the granularity on chromestatus.com) really should be fine.

[Dimitri Glazkov]

LGTM2.

:DG<

[Chris Harrelson]

LGTM3

[Rick Byers]

LGTM3 - assuming the Android beta numbers look similarly very low.

[Guido Urdaneta]

Now we have some beta android data.

CreateOffer with error callback: 0.049%

CreateOffer without error callback: 0.0000035%

CreateAnswer with error callback: 0.000085%

CreateOffer without error callback: 0.0000023%

Beta windows data has not changed significantly, so I'll proceed with removal shortly.

LGTM2.

:DG<

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.