Intent to Deprecate: The RTCConfiguration rtcpMuxPolicy of “negotiate”

[Zhi Huang]

Primary eng (and PM) emails

Eng: zhih...@chromium.org, dead...@chromium.org

Summary

The rtcpMuxPolicy is used by the application to specify its preferred policy regarding use of  RTP/RTCP multiplexing.

If the rtcpMuxPolicy “negotiate” is used, a deprecation message will be returned when creating the webkitRTCPeerConnection.

After monitoring the feature usage, we plan to remove the support of “negotiate” in a later release. We don’t have a concrete milestone for this yet.

Motivation

In M57, we have changed the default rtcpMuxPolicy to "require".  "negotiate" should be deprecated for following reasons:

• Non-muxed RTCP uses extra network resources.

• Removing it will make the API surface simpler, since an "RtpSender"/"RtpReceiver" will then only ever have a single transport.

• According the UMA stats, the usage of rtcpMuxPolicy “negotiate” is very low.

Compatibility And Interoperability Risk

Firefox: Talked the Mozilla developers, we believe that they plan to remove it as well. Still waiting for their final plan.

Web developers: Some web developers are using a gateway that doesn't yet support RTCP muxing. For example, Asterisk(https://issues.asterisk.org/jira/browse/ASTERISK-26732). We will pay attention to the usage numbers before actually removing it.

This is not a breaking change.  The user will get a deprecation message and the webkitRTCPeerConnection can still be created successfully.

Alternative implementation suggestion for web developers

The user can only use the rtcpMuxPolicy “require” if this feature goes away, and those who don’t support RTCP multiplexing will be broken.

Usage information from UseCounter

WebRTC.PeerConnection.RtcpMux counter.

https://uma.googleplex.com/timeline_v2?sid=27b7ea169051103baedde32b700be4b5

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=685727

Entry on the feature dashboard

This change is small and it’s not a breaking change.

None.

Requesting approval to remove too?

No.

If possible, we plan to remove it in M59 after monitoring the usage numbers.

[d...@nimblea.pe]

Not sure I'd agree that this isn't a breaking change. From what I understand, the flag you can pass in when creating the peer connection wasn't available before or at least isn't widely used and the browser just figured out what to do. For those who aren't using the flag and are using a gateway such as Asterisk - things will break for sure (I saw it break first hand); as you have to go and add in that flag. Wording this as "This is not a breaking change" isn't right - once you add in the flag you get a depreciation notice.

Or maybe I'm missing something? I'd more than happily rename things if I'm wrong but on my testing on 57 upwards - without manually adding in the flag; things definitely break :)

[Philip Jägenstedt]

"negotiate" remains as an enum value in the spec:

https://w3c.github.io/webrtc-pc/#idl-def-rtcrtcpmuxpolicy

Is there a spec discussion around doing away with the entirely?

I take it that removing this would amount to some simplification of the libwebrtc, and that this is the underlying motivation?

It's a bit hard to reason about UMA stats and how they relate to page views, and they're also not public. Now that the default has changed, could you add a use counter in RTCPeerConnection.cpp that measures how often "negotiate" is explicitly requested?

+Harald Alvestrand, any thoughts?

[Taylor Brandstetter]

Not sure I'd agree that this isn't a breaking change

This is meant to communicate that the deprecation notice itself is not a breaking change. Removing it completely would be.

Is there a spec discussion around doing away with the entirely?

At IETF94, Chrome and Firefox developers both expressed interest in doing away with it, which is how it became optional to implement. It recently was marked as "at risk" in webrtc-pc: https://github.com/w3c/webrtc-pc/pull/1018/files

Now that the default has changed, could you add a use counter in RTCPeerConnection.cpp that measures how often "negotiate" is explicitly requested?

That's being added in M58. 

[PhistucK]

You only mentioned webkitRTCPeerConnection, what about RTCPeerConnection? Does it also support it at the moment?

Please, do add an entry as soon as possible. Like you mentioned - if you remove it, it will cause some pain. An entry makes it (more) sure it is mentioned in a beta blog post and makes it visible to those searching for future deprecations and removals in advance.

☆PhistucK

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

[Zhi Huang]

You only mentioned webkitRTCPeerConnection, what about RTCPeerConnection? Does it also support it at the moment?

I didn't noticed webkitRTCPeerConnection has been un-prefixed already. RTCPeerConnection should have the same behavior.

 

Please, do add an entry as soon as possible. Like you mentioned - if you remove it, it will cause some pain. An entry makes it (more) sure it is mentioned in a beta blog post and makes it visible to those searching for future deprecations and removals in advance.

Sure, I'll add one.

FYI, I have pending CL that addresses some concerns here. 

https://codereview.webrtc.org/2679093006/

[Chris Harrelson]

Hi,

A comment inline below.

On Mon, Feb 13, 2017 at 4:27 PM, 'Zhi Huang' via blink-dev <blin...@chromium.org> wrote:

Primary eng (and PM) emails

Eng: zhih...@chromium.org, dead...@chromium.org

Summary

The rtcpMuxPolicy is used by the application to specify its preferred policy regarding use of  RTP/RTCP multiplexing.

If the rtcpMuxPolicy “negotiate” is used, a deprecation message will be returned when creating the webkitRTCPeerConnection.

After monitoring the feature usage, we plan to remove the support of “negotiate” in a later release. We don’t have a concrete milestone for this yet.

Motivation

In M57, we have changed the default rtcpMuxPolicy to "require".  "negotiate" should be deprecated for following reasons:

• Non-muxed RTCP uses extra network resources.

• Removing it will make the API surface simpler, since an "RtpSender"/"RtpReceiver" will then only ever have a single transport.

• According the UMA stats, the usage of rtcpMuxPolicy “negotiate” is very low.

Compatibility And Interoperability Risk

Firefox: Talked the Mozilla developers, we believe that they plan to remove it as well. Still waiting for their final plan.

Web developers: Some web developers are using a gateway that doesn't yet support RTCP muxing. For example, Asterisk(https://issues.asterisk.org/jira/browse/ASTERISK-26732). We will pay attention to the usage numbers before actually removing it.

This is not a breaking change.  The user will get a deprecation message and the webkitRTCPeerConnection can still be created successfully.

Alternative implementation suggestion for web developers

The user can only use the rtcpMuxPolicy “require” if this feature goes away, and those who don’t support RTCP multiplexing will be broken.

Usage information from UseCounter

WebRTC.PeerConnection.RtcpMux counter.

https://uma.googleplex.com/timeline_v2?sid=27b7ea169051103baedde32b700be4b5

This is a Google-internal URL. Please don't post it on blink-dev. Instead please post a summary of what the data says.

 

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=685727

Entry on the feature dashboard

This change is small and it’s not a breaking change.

None.

Requesting approval to remove too?

No.

If possible, we plan to remove it in M59 after monitoring the usage numbers.

--

[Philip Jägenstedt]

On Wed, Feb 15, 2017 at 5:22 AM 'Zhi Huang' via blink-dev <blin...@chromium.org> wrote:

You only mentioned webkitRTCPeerConnection, what about RTCPeerConnection? Does it also support it at the moment?

I didn't noticed webkitRTCPeerConnection has been un-prefixed already. RTCPeerConnection should have the same behavior.

Right, window.RTCPeerConnection === window.webkitRTCPeerConnection, so we can now mostly ignore that webkitRTCPeerConnection exists except that we should still strive towards its eventual standardization or removal.

I've commented on https://codereview.webrtc.org/2679093006/ and the easiest thing would be to wait until we have some data from that.

However, can we reasonably say something about the likely breakage without waiting for that use counter data? If the "negotiate" behavior goes away, what would the worst case breakage look like, and what kinds of WebRTC-using sites will be affected?

[Taylor Brandstetter]

 Instead please post a summary of what the data says.

Summary of the data: roughly 2% of PeerConnections result in RTCP muxing not being used.

If the "negotiate" behavior goes away, what would the worst case breakage look like, and what kinds of WebRTC-using sites will be affected?

The breakage case would be that WebRTC doesn't work at all. The affected sites would be any that connect to a middlebox or other non-browser endpoint that doesn't yet support RTCP muxing.

Our hope was that, after the "require" policy becomes the default in M57, and a deprecation notice starts being displayed in M58, there would be more motivation for these endpoints to support RTCP muxing, and that 2% number would go down. Is that the right approach? 

--

[Zhi Huang]

This is an updated proposal.

Primary eng (and PM) emails

Eng: zhih...@chromium.org, dead...@chromium.org

Summary

The rtcpMuxPolicy is used by the application to specify its preferred policy regarding use of  RTP/RTCP multiplexing.

If the rtcpMuxPolicy “negotiate” is used, a deprecation message will be returned when creating the RTCPeerConnection.

After monitoring the feature usage, we plan to remove the support of “negotiate” in a later release. We don’t have a concrete milestone for this yet.

Motivation

In M57, we have changed the default rtcpMuxPolicy to "require".  "negotiate" should be deprecated for following reasons:

• Non-muxed RTCP uses extra network resources.

• Removing it will make the API surface simpler, since an "RtpSender"/"RtpReceiver" will then only ever have a single transport.

• According the the UMA counter, the usage of rtcpMuxPolicy “negotiate” is very low.

Compatibility And Interoperability Risk

Firefox: Talked the Mozilla developers, we believe that they plan to remove it as well. Still waiting for their final plan.

Web developers: Some web developers are using a gateway that doesn't yet support RTCP muxing. For example, Asterisk(https://issues.asterisk.org/jira/browse/ASTERISK-26732). We will pay attention to the usage numbers before actually removing it.

If this feature goes away, the endpoints which don't support RTCP mux will be broken.

The affected sites would be any that connect to a middlebox or other non-browser endpoint that doesn't yet support RTCP muxing.

Alternative implementation suggestion for web developers

The user can only use the rtcpMuxPolicy “require” if this feature goes away, and those who don’t support RTCP multiplexing will be broken.

Usage information from UseCounter

According to the WebRTC.PeerConnection.RtcpMux counter, less than 3% PeerConnections end up using non-rtcp mux.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=685727

Entry on the feature dashboard

https://www.chromestatus.com/features/5654810086866944

Requesting approval to remove too?

No.

If possible, we plan to remove it in M59 after monitoring the usage numbers.

On Tue, Feb 14, 2017 at 10:48 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

[Philip Jägenstedt]

On Thu, Feb 16, 2017 at 1:59 AM 'Taylor Brandstetter' via blink-dev <blin...@chromium.org> wrote:

 Instead please post a summary of what the data says.

Summary of the data: roughly 2% of PeerConnections result in RTCP muxing not being used.

Are these all cases where muxed RTCP definitely doesn't work, or could some proportion of these fall back to muxed RTCP and keep working?

 

If the "negotiate" behavior goes away, what would the worst case breakage look like, and what kinds of WebRTC-using sites will be affected?

The breakage case would be that WebRTC doesn't work at all. The affected sites would be any that connect to a middlebox or other non-browser endpoint that doesn't yet support RTCP muxing.

Our hope was that, after the "require" policy becomes the default in M57, and a deprecation notice starts being displayed in M58, there would be more motivation for these endpoints to support RTCP muxing, and that 2% number would go down. Is that the right approach?

It certainly makes intuitive sense that deprecation messages should cause usage to drop, but unfortunately we haven't found that to be the case in general. The things that we want to deprecate and remove typically have low usage to begin with, and my guess is that devs for most affected sites don't see the messages at all unless they happen to be debugging something else.

This doesn't mean that we shouldn't deprecate and remove, just that deprecation isn't an aid to removal, but rather a fair warning to web developers that we've already decided to remove.

So, should we remove this? I think the strongest argument in favor is that this would be interop, if this is an implementation burden and doesn't work the same in different browsers. Is that the case?

I asked in https://github.com/w3c/webrtc-pc/issues/997#issuecomment-280230101 if this will be supported in Edge when they ship RTCPeerConnection.

Assuming that removal looks like a good idea from an interop and/or code health perspective, it sounds like the breakage would still not be trivial, and fixing it might involve replacing actual hardware?

Do you have any way of identifying the sites that will most likely be affected, to reach out to them in advance? It could be, for example, that they are fine with removal but want 6 months to migrate, in which case a long deprecation might be in order. Or they might be able to migrate more easily if we only ship some other piece of API first.

If you do not already have a list of such sites, it's possible that an httparchive search could identify likely candidates. https://www.chromium.org/blink/platform-predictability/compat-tools has some tips for that, and I can help out if needed.

[Rick Byers]

On Wed, Feb 15, 2017 at 11:51 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Thu, Feb 16, 2017 at 1:59 AM 'Taylor Brandstetter' via blink-dev <blin...@chromium.org> wrote:

 Instead please post a summary of what the data says.

Summary of the data: roughly 2% of PeerConnections result in RTCP muxing not being used.

Are these all cases where muxed RTCP definitely doesn't work, or could some proportion of these fall back to muxed RTCP and keep working?

 

If the "negotiate" behavior goes away, what would the worst case breakage look like, and what kinds of WebRTC-using sites will be affected?

The breakage case would be that WebRTC doesn't work at all. The affected sites would be any that connect to a middlebox or other non-browser endpoint that doesn't yet support RTCP muxing.

Our hope was that, after the "require" policy becomes the default in M57, and a deprecation notice starts being displayed in M58, there would be more motivation for these endpoints to support RTCP muxing, and that 2% number would go down. Is that the right approach?

It certainly makes intuitive sense that deprecation messages should cause usage to drop, but unfortunately we haven't found that to be the case in general. The things that we want to deprecate and remove typically have low usage to begin with, and my guess is that devs for most affected sites don't see the messages at all unless they happen to be debugging something else.

We've also had several cases where we've generated deprecation warnings for something which, even after more than a year, wasn't removed.  So developers have been somewhat trained to ignore us when we make some vague claim about something being deprecated (they generally think we're crazy for making ANY intentional breaking changes).

In general the best path we've found for removing something with non-trivial usage is to identify the impacted sites/code, ensure that there really is an good alternative and easy migration path for them, and reach out to the biggest users explicitly and try to help them move over.  Once we see usage drop to low levels from such efforts, then we can choose a removal date and do the final warning/outreach of a console message and blog post that cite a specific removal date.

[PhistucK]

I am not sure actual hardware must be replaced, it is more of a software problem (specifically, Asterisk).

Since the software does not have a bug in this case, but is simply missing a feature, the nicer (and perhaps the fastest) thing could be to help them (or implement for them) (well, they use Gerrit, not GitHub) support muxing. The team seems positive about it.

☆PhistucK

--

[Taylor Brandstetter]

Are these all cases where muxed RTCP definitely doesn't work

Since Chrome always prefers using it, yes: I think it's safe to assume these are cases where the remote endpoint doesn't support it.

I think the strongest argument in favor is that this would be interop, if this is an implementation burden and doesn't work the same in different browsers. Is that the case?

Interop shouldn't be difficult, though currently it appears that Firefox fails silently while Chrome doesn't. The motivation, as I understand it, is more about simplifying future APIs, simplifying implementations and using fewer ports.

fixing it might involve replacing actual hardware?

I'm not sure about replacing hardware, but in some cases it may involve updating SIP equipment. Though this equipment may already need to be updated to support DTLS-SRTP? Looking for someone who knows more about SIP equipment to chime in.

Do you have any way of identifying the sites that will most likely be affected, to reach out to them in advance?

 I'll look into this. It may be difficult however, since Chrome will have used the "negotiate" policy by default until M57.

[Philip Jägenstedt]

When it comes to finding affected sites, after the change to "require" as the default, might it be so simple as to find sites have the strings RTCPeerConnection and negotiate in double or single quotes? I can actually find only one such site in httparchive, http://www.ghanalive.tv/, and there it looks like the negotiate string is being used for something else.

Most likely some interesting cases just aren't in httparchive, and are perhaps behind a login where httparchive doesn't crawl.

For all sites that don't use { rtcpMuxPolicy: "negotiate" } explicitly, the change in default behavior in M57 should have already broken them. Would it be acceptable to wait until M57 has reached stable to look at the data again? Whatever then remains should be cases that will result in user-visible brekage.

☆PhistucK

--

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

[PhistucK]

Since the default change is not released to stable yet, there is very little chance you will find that string in HTTPArchive... Maybe this intent should wait a few months until HTTPArchive is up to date with sites employing the workaround.

Alternatively, perhaps cancel the default change in Chrome 57 and just warn that it is going away completely, instead of making the developers first modify their code for a workaround and only then change their backend software for a real solution.

☆PhistucK

☆PhistucK

--

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.

[Philip Jägenstedt]

In https://github.com/w3c/webrtc-pc/issues/997#issuecomment-282052223 Shinjun from the Edge team confirmed that Edge does not support non-muxed RTCP, and would be fine with its removal.

Given that, it looks like removal from Chromium and Gecko would be the fastest path to interop, if only the breakage is sufficiently contained.

I share PhistucK's concern, it would be a particularly embarrassing if sites adapt to the M57 change of default by adding { rtcpMuxPolicy: "negotiate" } and if we in the following releases deprecate and remove exactly that.

There's no risk that a deprecation message would be too noisy, but some risk that a removal actually won't work out. Although I think we haven't done it before, could we merge an honest deprecation message like this to M57?

The rtcpMuxPolicy option is being considered for removal and may be removed no earlier than M60, around August 2017. If you depend on it, please see $URL.

Then, check what the use counter data (a side effect of deprecation) from M57 looks like and possibly upgrade it to more definite language in M58.

Yes?

☆PhistucK

--

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.

[Taylor Brandstetter]

That plan sounds good to me.

☆PhistucK

--

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.

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

[Philip Jägenstedt]

The $URL would be a link to a chromestatus.com, and that entry should clearly say that removal is not a certaintly, and direct people to comment on the bug if they think it's a terrible idea.

Would another API owner LGTM this plan, given that we've recently tried quite hard to not do uncertain deprecations? If the change in behavior in M57 wasn't already on its way to stable I think making the whole change as one might have been better, but it's a bit late for that now.

☆PhistucK

--

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.

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

[Rick Byers]

Yep, this plan sounds reasonable to me, thanks!  LGTM.

☆PhistucK

--

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.

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

[Taylor Brandstetter]

Just to clarify: Can we merge the deprecation message/use counter into M57, or is it already too late for that?

[Philip Jägenstedt]

You can request a merge, but it'll be up to release managers, not sure how close to stable such changes are accepted. It would be great if you can merge!

☆PhistucK

--

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.

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