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.

[Zhi Huang]

Hello,

The merge request have been approved and but this CL needs to be LGTMed by a full committer. 

Can anyone help with it?

Thanks,

Zhi

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

I have taken care of it, thanks for pinging! Also feel free ping people directly when review is slow, via chat, carrier pigeon, etc.

[Stian Halseth]

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

I represent several organizations currently depending on Asterisk, where removal of the negotiate policy from rtcpMuxPolicy would break functionality.
 
We became aware of the issue after the stable release of M57 which broke functionality with Asterisk. The quick fix was using "negotiate".
I fully support the change, and I also believe that "negotiate" should be deprecated, but as it stands right now, deprecation in M60, august, would impose a significant challenge.

Asterisk installations, depending on the configuration and level of customization, can be quite complex.
Even after the patches are applied to current Asterisk, upgrading production systems to current release in that timeframe is far from ideal.

After the release of M57, anyone relying on "negotiate" have been made aware of the problem and will have to find a way to solve this long term, but I believe they should be given more time.

To summarize, I support the deprecation of "negotiate", but I would strongly encourage considering not removing it before the end of 2017.
It would give the Asterisk community time for testing and deploying new releases.

[Philip Jägenstedt]

Hi Stian, and thanks for reaching out. Just to confirm, this is http://www.asterisk.org/?

Is Asterisk a pure software project, or is there also a hardware component? Do you have a link to a project bug that describes how to adapt to this change?

Zhi, Taylor, is rtcpMuxPolicy a maintenance burden, is there refactoring or removal (binary size reduction) blocked by the rtcpMuxPolicy removal alone?

Judging by https://www.chromium.org/developers/calendar the first release that isn't in 2017 will be M64. If there was some margin for error included in this timeline, another option is to set a more optimistic removal date, say M62, and push it if we're getting close and Asterisk (or anyone else) needs more time.

On Fri, Apr 7, 2017 at 2:43 PM Stian Halseth <stian.hal...@gmail.com> wrote:

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

I represent several organizations currently depending on Asterisk where removal of the rtcpMuxPolicy would break functionality.

 
We became aware of the issue after the stable release of M57 which broke functionality with Asterisk. The quick fix was using "negotiate".
I fully support the change, and I also believe that "negotiate" should be deprecated, but as it stands right now, deprecation in M60, august, would impose a significant challenge.

Asterisk installations, depending on the configuration and level of customization, can be quite complex.
Even after the patches are applied to current Asterisk, upgrading production systems to current release in that timeframe is far from ideal.

After the release of M57, anyone relying on "negotiate" have been made aware of the problem and will have to find a way to solve this long term, but I believe they should be given more time.

To summarize, I support the deprecation of "negotiate", but I would strongly encourage you to consider not removing it before the end of 2017.

[Stian Halseth]

Hi Philip, yes, this is http://www.asterisk.org.

Asterisk is a software project. I don't see any issues related to any of the hardware components that are typically be used in an Asterisk installation.

The problem is described very well here: https://nimblea.pe/monkey-business/2017/01/19/webrtc-asterisk-and-chrome-57/
Asterisk issue: https://issues.asterisk.org/jira/browse/ASTERISK-26846

The issue was marked as resolved 18/Mar and is targeted for Asterisk 13.15.0 / 14.4.0 which is currently in release candidate state.

The fix itself  is not in, my personal opinion, sufficiently tested. I'm not yet confident that the fix is production ready.

As of now there are no stable releases of Asterisk that will work without "negotiate".   This will hopefully soon change, but even then, upgrading to latest version requires a lot of testing.

For our production systems we've had to run extensive stress tests for weeks and months to detect rare timing related issues etc. Not specifically related to WebRTC, but for the platform as a whole.

We are looking into various option, even using a SIP Proxy like https://www.kamailio.org/ .

I'm a true supporter of advancements in technology, and I believe this is change in inevitable. 
Solutions are out there, even today by using third party SIP proxy, and this will be fixed and tested in Asterisk as well, but the timeframe of August is my concern here.

[Philip Jägenstedt]

OK, so in https://issues.asterisk.org/jira/browse/ASTERISK-26846 I see there's a bunch of new C code to support muxed RTCP, and certainly that's something one would want to roll out in a controlled manner.

When do you expect a stable release with this fix to be available, and do you have any idea about how long people usually take to upgrade Asterisk? Would you be able to know when enough (90%?) people have upgraded, or would that be guesswork?

If we believed that Asterix accounted for the majority of { rtcpMuxPolicy: "negotiate" } then we could track the usage with use counters, but that's probably not a safe assumption to make.

[Stian Halseth]

Hi Philip,

I'm probably the wrong to person to ask about when a stable release with the fix will be available, but as a patch is out now, I would expect anyone relying on this functionality to start testing, or find alternative solutions outside of Asterisk.

If there are issues with the patch, it will probably get priority from the Asterisk developers as soon as people start experiencing problems.  As it stands now, the patch requires testing before any more work will be done in Asterisk.

How long people usually take to upgrade will be guesswork.  I know several Asterisk installations that are using very old stable versions, rarely upgrade at all, but I would assume that those relying on the WebRTC functionality will have a faster adoption rate of newer releases.

I think that from the first warning in M47, till complete removal of "negotiate", at least six months should be allowed to pass.

As to whether Asterisk accounts for a majority of { rtcpMuxPolicy: "negotiate" } I cannot give you much more information, so no, probably not a safe assumption to make.

Postponing the removal until M62 would be a good start, and provide a more realistic upgrade path for Asterisk users. Up to that point more data could be collected, and more Asterisk users might be able to provide input on the state of the issue.

Thank you very much for swift response!

[d...@nimblea.pe]

Its not the patch in that issue that is the actual change that got merged in - its this PR in gerrit - https://gerrit.asterisk.org/#/c/5245/

There are currently release candidates (rc3 https://twitter.com/AsteriskDev/status/849635649137332224 ) out that have the rtcpmux support in them so probably in the next 2 weeks or so if nothing is found (just going based on past experience)

How long do people usually take to upgrade Asterisk - that is a really good question - the right answer is people don't upgrade Asterisk unless they need to (be it a feature, security that impacts them or bug) - so from once every 3 years to "every release"

But yes, people that do upgrade, take a fair amount of time to upgrade usually... because things do pop up and do break things which can take down entire Contact Centres etc.

Also, not forgetting - there are a lot of people still using Asterisk 11 for WebRTC (they shouldn't be but they are) and so getting them to migrate over to 13 is a battle in itself - something that shouldn't really be taken into consideration here but might need to be.

[d...@nimblea.pe]

Oh I forgot to say - the Asterisk Core team are a very friendly bunch of people - who could probably give you better answers to these questions than us, I can help connect you if you would like.

[Taylor Brandstetter]

Zhi, Taylor, is rtcpMuxPolicy a maintenance burden, is there refactoring or removal (binary size reduction) blocked by the rtcpMuxPolicy removal alone?

It's a slight maintenance burden, but nothing significant is being blocked by its removal. So Stian's request (or Philip's suggestion) sound reasonable to me. I wouldn't want to just break this entire subset of the WebRTC ecosystem.

[Philip Jägenstedt]

It would be great if you could poke someone representing Asterisk to comment on this thread, since we're trying to make plans around their release schedule.

[ma...@fredricknet.net]

Hey Philip,

I can comment for the Asterisk development team.

With regards to the discussion here, the latest release versions of Asterisk (as of four days ago), Asterisk 13.15.0 and Asterisk 14.4.0, support rtcp-mux capabilities with Asterisk.  As mentioned in this thread, there are some people who keep very up to date with Asterisk versions, and others who are slow to update.

In my mind are two general categories of affected users:

1.) Those still on old branches that no longer receive bug fixes, and that did not receive the rtcp-mux fix (essentially those on Asterisk 11.x.x still), and will try to remain on it as long as possible.

2.) Those who are on modern branches such as 13.x.x and 14.x.x that are still receive bug fixes, and who received the rtcp-mux fix, but only upgrade when they have to.

Those who are in the first category (on Asterisk 11) will probably be hit by deprecation the hardest, as for them to upgrade they will need to rejigger their configuration and infrastructure for a new major version of Asterisk (13 or 14).  Requalification will be necessary, and probably will yield some difference pains for these people.

I'm less worried about those in the second category, since upgrading between minor Asterisk versions is less of a change.  Doing a requalification is probably important, but likely will not find anything earth shattering.

I understand Stian and others' concerns about how fresh the rtcp-mux changes are, and perhaps that there may be some bake time that's needed in release branches before all the kinks are worked out.  They have been tested, but inevitably with new software, there is some time that is spent shaking out bugs.  I would estimate 2-3 minor releases of Asterisk for that time, which would mean approximately 2-4 months.  Generally we try to release once a month, but stuff happens.  For those running older major versions of Asterisk, like 11, not deprecating rtcp-mux in the 2017 timeframe would be the greatest kindness, but I definitely would give them at *least* 6-8 months.

Data driven approaches are great, but what threshold causes you to cut off the pinky finger :-) ?  2-3% of what number is also interesting - if we're talking about 2-3% of 1,000,000,000 calls last year, we're still talking about 20,000,000-30,000,000 calls still using rtcp-mux - that's still quite a large number. 

My assumption is that interoperating equipment is going to be hit the hardest by deprecation.  Traditional telecom equipment has long, sometimes 3-5 year upgrade/qualification cycles - quite the opposite of the "move fast, break things" approach.  Deprecating an HTML element is one thing, but a website's ability to react to it is fairly easy since the deployed user base is upgradeable/work-aroundable as soon as they refresh the browser page.  What we're talking about is deprecating functionality that completely breaks phone calls with other equipment/hardware/infrastructure (not just older versions of Asterisk) potentially forever with completely different upgrade schedules - a browser page refresh isn't going to fix that.  Perhaps another way to look at it, and perhaps one that validates giving it a healthy window of time before deprecation.

Best wishes,

Matthew Fredrickson

[Philip Jägenstedt]

Thanks Matt, that's very helpful.

It sounds like there's a segment of Asterisk deployments that will upgrade as slowly as possible, and that to patiently wait that out would be a multi-year wait. The least bad approach, I think, is to decide on a removal date fairly far in the future, and then make sure this is known far in advance. The hardest part is making it known, I wouldn't count on deprecation messages reaching everyone who needs to know. Do you have a communication channel with your users that you think would be effective?

As for the date, that's a tradeoff I think is best made by Zhi and Taylor, since it has to be balanced against the maintenance burden. WDYT? M62, M64, or something else?

[cre...@digium.com]

I wish we had a great communication channel that would get to our entire user base.  Unfortunately, the best we can do is communicate via our public forums, mailing lists, and website and hope it sticks with some people.

Thanks for trying to get us in the loop on this.  If you guys have any questions like this in the future, feel free to reach out to me and I'd be glad to offer my assistance.

Best wishes,

Matthew Fredrickson

[cre...@digium.com]

Ooops, meant to reply from my personal email/gmail account.  Well, in any case, this is my work email.  Sorry about any confusion.

[Philip Jägenstedt]

Hmm, the people that need to be reached are those that deploy and then avoid upgrading for as long as possible, and they seem to be the least likely to be engaged on forums, mailing lists, or to visit the website. I think we should expect that even if the removal is a year from now, some people will not know until then, and then it'll be urgent and painful.

If a longer deprecation period isn't solving this problem, then I think we should aim for removal in M62, estimated to reach stable on Oct 24th, 2017. That's 6 months from now. If we hear back from people that they need more time, or if there's hard-to-fix breakage once it reached stable, then we revert and delay to M64 or later.

Could everyone live with that?

[Matthew Fredrickson]

Unfortunately, I do not properly represent the class of users that
will be affected by it the most (those who are running Asterisk 11
still), since we keep most of our equipment on current versions. The
date conveniently is very close to the date where Asterisk 11 goes
completely EOL, which is October 25 of this year. The 11 branch is in
the last stage of life right now, security fix mode only, no bug
fixes. If anybody's running it after October 25, they're pretty much
on their own anyways. So yes, it sounds as good as any other date.

I'd love to hear other people's feedback as well.

Matthew Fredrickson

[Dan Jenkins]

This sounds fair to me (from an asterisk user/developer point of view)

[Philip Jägenstedt]

Zhi, Taylor, do you want to go ahead and deprecate? Since this was an Intent to Deprecate, please send a separate Intent to Remove later to complete stack of the paperwork. (It's OK to send Intent to Deprecate and Remove at the outset as well.)

[Taylor Brandstetter]

Will do. We already added a deprecation message, but I'll change it from "no earlier than M60" to "no earlier than M62".

[brett.cr...@gmail.com]

The current message still states "no earlier than M62".  Is this deprecation included in M62?  If not, has a new target release been identified for the deprecation effort?

On Monday, February 13, 2017 at 5:27:40 PM UTC-7, Zhi Huang 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

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.

[Zhi Huang]

The deprecation is not included in M62 and we don't have a specific target yet. We'll start some experiments soon.

[brett.cr...@gmail.com]

Excellent, thank you for the update.  

Since M63 is already in the Canary Channel, is it safe to assume that this deprecation will not happen until at least M64?