Intend to ship: Change the default RtcpMuxPolicy to "require".

[Zhi Huang]

Intent to Ship:

Change the default RtcpMuxPolicy to "require".

According to WebRTC 1.0 standard, the default multiplexing policy is "require".

Contact emails

webrtc-...@google.com

zhih...@webrtc.org

Spec

Link to spec:

WebRTC 1.0 standard:  https://www.w3.org/TR/webrtc/#dom-rtcconfiguration-rtcpmuxpolicy

Link to a tag review or a description about why the tag review process is being skipped:

https://github.com/w3ctag/spec-reviews/issues/14

Summary

Change the default value of RtcpMuxPolicy to "require"

The connection to an endpoint that doesn't support RTCP multiplexing will fail by default.

Link to “Intent to Implement” blink-dev discussion

Skipped.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

N/A

Debuggability

N/A

Interoperability and Compatibility Risk

The potential risk is that those users who uses the current default RtcpMuxPolicy ("negotiate") but don't support rtcp multiplexing would be affected by this change.

There are two UMA histograms to gauge the risk of this change. According to the UMA data in 28 days, 99.9% users choose the default value of RtcpMuxPolicy which means nearly all the users who are using don't support rtc multiplexing would be affected by this change since they don't specified the RtcpMuxPolicy to be "negotiate". However, among all the users with media, only 3% don't support the rtcp multiplexing, so it's not risky to make this change.

For those users who are affected, they can get the old behavior by specifically setting the RtcpMuxPolicy to be "negotiate"(use { rtcpMuxPolicy:"negotiate" }).

The current default rtcpMuxPolicy for FireFox is also "require." https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary

OWP launch tracking bug

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

Entry on the feature dashboard

Doesn't need one because it's a simple change.

[Chris Harrelson]

Hi,

Trying to understand that statement...does it mean that 3% of existingWebRTC sessions would start failing?

 

For those users who are affected, they can get the old behavior by specifically setting the RtcpMuxPolicy to be "negotiate"(use { rtcpMuxPolicy:"negotiate" }).

The current default rtcpMuxPolicy for FireFox is also "require." https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary

OWP launch tracking bug

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

Entry on the feature dashboard

Doesn't need one because it's a simple change.

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

Hi Chris,

Since nearly all the users are using the default rtcpMuxPolicy, we can assume all the users who doesn't support rtcp-mux will be broken.

However, according to the histograms, roughly 90% of the user doesn't have media. Among the 10% of the users with media,  3% doesn't support rtcp-mux.

In conclusion, roughly 0.3% session will fail. 

Sorry for not making this clear.

Thanks

Zhi

[Philip Jägenstedt]

(I have added this intent to https://bit.ly/blinkintents, a typo in title fooled the script.)

Given that no rtcpMuxPolicy (WebRTC.PeerConnection.SelectedRtcpMuxPolicy's Default) is given in 99.9% of cases, the maximum risk ought to roughly be the usage of RTCPeerConnection itself. The constructor its exactly one of these counters:

https://www.chromestatus.com/metrics/feature/timeline/popularity/1041

https://www.chromestatus.com/metrics/feature/timeline/popularity/1042

Adding them together gives something like 0.5%.

However, as I understand it after talking to hta@, "negotiate" doesn't mean that non-multiplexed RTCP is likely, multiplexed RTCP is the norm and what is likely to be negotiated. Certain gateways (things that translate between WebRTC and some other set of protocols) may not support multiplexed RTCP, but you know if you have one of these on your network.

We could measure how often the negotiated behavior will change, but that still won't mean that all of those cases will break. So, given how easy the mitigation is, new RTCPeerConnection({ rtcpMuxPolicy: "negotiate" }), I think it's worth attempting this change now.

LGTM1, but be prepared to revert at the first sight of trouble. Changing the default in the spec should be an option if there's breakage in the wild.

Hi,

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

[Chris Harrelson]

LGTM2

Hi,

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.

[TAMURA, Kent]

LGTM3

--

TAMURA Kent
Software Engineer, Google