Intent to Remove: The RTCConfiguration rtcpMuxPolicy of “negotiate”

[Taylor Brandstetter]

Primary eng (and PM) emails

zhih...@chromium.org, dead...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/OP2SGSWF5lo/v7GOaWt_CQAJ

Summary

The rtcpMuxPolicy is used by the application to specify its preferred policy regarding use of RTP/RTCP multiplexing. The two possible values are "require" or "negotiate". Removing "negotiate" as an option means non-multiplexed RTCP will no longer be supported.

We currently plan to make this change in M62, which we hope should give most affected application developers time to upgrade to software that supports RTCP muxing. See the "intent to deprecate" thread linked above for more context.

Motivation

We want to remove support for non-multiplexed RTCP for the following reasons:

• It will make the API surface simpler, since an "RtpSender"/"RtpReceiver" will then only ever have a single transport.
  
• Non-muxed RTCP uses extra network resources.
  
• The usage is very low, and it carries a slight maintenance burden.

Interoperability and Compatibility Risk

The interoperability risk is low. The specification now has well-defined behavior for how a browser that doesn't support RTCP muxing should behave: throwing a NotSupportedError on RTCPeerConnection construction.

The compatibility risk is relatively high. Applications that don't support RTCP muxing will stop working when this change rolls out. We may need to revert it once the change reaches stable in response to feedback.

Edge: Not supported, positive to removal

Firefox: Supported, positive to removal

Safari: Not supported, no public signals about this feature specifically

Alternative implementation suggestion for web developers

None. After this removal, non-WebRTC endpoints will need to support RTCP muxing to connect to Chrome through WebRTC.

Usage information from UseCounter

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

OWP launch tracking bug

https://crbug.com/713445

Entry on the feature dashboard

None.

[Philip Jägenstedt]

LGTM1 with one caveat.

AFAICT, Gecko doesn't have "rtcpMuxPolicy" anywhere in their source code, if they support this it's by having "negotiate" as the default and only policy.

This means that Gecko does not throw for any value of rtcpMuxPolicy. Edge also doesn't throw for `new RTCPeerConnection({ iceServers:[], rtcpMuxPolicy: "negotiate" }) in particular. I think we should match Gecko and Edge in not throwing, and just remove all knowledge of rtcpMuxPolicy. Can you file a spec issue to remove rtcpMuxPolicy completely from the spec once it's gone from enough implementations?

[Taylor Brandstetter]

Given that existing apps may be using "negotiate" with Chrome, it seems preferable to fail as early as possible, with a specific error, rather than later when "setRemoteDescription" is called, with a more vague error.

As for the spec issue, we've already marked the feature as "at risk", so if rtcpMuxPolicy needs to be removed I think that will happen naturally through the "Call for Implementations" process.

[PhistucK]

On Thu, Apr 20, 2017 at 11:39 AM, 'Taylor Brandstetter' via blink-dev <blin...@chromium.org> wrote:

rather than later when "setRemoteDescription" is called, with a more vague error.

​But can you catch that specific case and return a clearer error?​

☆PhistucK

[Philip Jägenstedt]

Those existing apps would already get past the RTCPeerConnection constructor in Edge and Firefox and fail in some way later, right? If that's the case, then any problem would have to be with Chromium-specific code, which certainly does exist for WebRTC, but hopefully it's still a minority of the usage.

If we think that ignoring rtcpMuxPolicy is the right thing to converge on long term, then we need not wait for the spec to change. Some things have been removed from Blink on the expectation that successful removal will be a data point in favor of removing it from the spec.

You're the domain expert here and I'll take your judgement over my own, but whatever the behavior is, I think it should be one that all implementation can plausibly converge on. Asking the Edge and Gecko implementers is probably the best way to gauge that.

[Taylor Brandstetter]

Question for Bernard (for Edge) and Eric/Byron (for Gecko): Do you think we can converge on throwing a "NotSupportedError" on RTCPeerConnection construction if non-muxed RTCP isn't supported, and the application passes in `{rtcpMuxPolicy: "negotiate"}`? Or should a browser that doesn't support non-muxed RTCP just ignore rtcpMuxPolicy altogether, and fail when a remote description without "a=rtcp-mux" is applied?

 

But can you catch that specific case and return a clearer error?​

Sure, but it would still occur later in the PeerConnection life-cycle.

Those existing apps would already get past the RTCPeerConnection constructor in Edge and Firefox and fail in some way later, right?

For Firefox they wouldn't fail; Firefox supports non-muxed RTCP.

If we think that ignoring rtcpMuxPolicy is the right thing to converge on long term, then we need not wait for the spec to change.

True, though having an error at RTCPeerConnection construction time seems more valuable to developers right now. Even if RTCRtcpMuxPolicy is removed from the spec, keeping around the NotSupportedError doesn't seem like it would hurt.

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

On Fri, Apr 21, 2017 at 2:52 AM Taylor Brandstetter <dead...@google.com> wrote:

Question for Bernard (for Edge) and Eric/Byron (for Gecko): Do you think we can converge on throwing a "NotSupportedError" on RTCPeerConnection construction if non-muxed RTCP isn't supported, and the application passes in `{rtcpMuxPolicy: "negotiate"}`? Or should a browser that doesn't support non-muxed RTCP just ignore rtcpMuxPolicy altogether, and fail when a remote description without "a=rtcp-mux" is applied?

 

But can you catch that specific case and return a clearer error?​

Sure, but it would still occur later in the PeerConnection life-cycle.

Those existing apps would already get past the RTCPeerConnection constructor in Edge and Firefox and fail in some way later, right?

For Firefox they wouldn't fail; Firefox supports non-muxed RTCP.

This bit confuses me. Does it mean that "negotiate" is their default and only behavior?

If we think that ignoring rtcpMuxPolicy is the right thing to converge on long term, then we need not wait for the spec to change.

True, though having an error at RTCPeerConnection construction time seems more valuable to developers right now. Even if RTCRtcpMuxPolicy is removed from the spec, keeping around the NotSupportedError doesn't seem like it would hurt.

It's a bit of a stretch, but different browsers throwing in different situations can hurt. For example, we had a problem with the number of required arguments for CSSStyleSheet.insertRule where it worked fine for Gecko to require two arguments, but an attempt to align Blink with the spec didn't work out. (The spec was finally changed.)

For every case like that we have a bucketload of minor differences between engines that haven't been a problem, but the more we align on the details the better. Another way to say it is that we should want to have shared web-platform-tests covering as much as possible of our implementation, and for other engines to pass the same tests as we do.

What the Edge and Gecko folks say is most important, though.

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

[Taylor Brandstetter]

This bit confuses me. Does it mean that "negotiate" is their default and only behavior?

It appears so. I just tried setting a "require" policy and applying a remote offer without "a=rtcp-mux" and it succeeded. 

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

[Philipp Hancke]

see https://bugzilla.mozilla.org/show_bug.cgi?id=1339203

I doubt Edge supports non-muxed RTCP given the interop note on http://internaut.com:8080/~baboba/ms/msortc.html#rtcrtpsender-operation* but Bernard will know for sure.

[Chris Harrelson]

I approve of this intent also, if there can be agreement on the error handing among browsers.

[Bernard Aboba]

Edge ORTC supports RTP/RTCP non-mux when SRTP/SDES transport is used, but not when DTLS transport is selected.  So in a 1.0 shim it would not make sense to throw a "NotSupportedError" on RTCPeerConnection construction when `{rtcpMuxPolicy: "negotiate"}` is passed, since RTP/RTCP non-mux isn't illegal in all situations. Failing on application of the remote description would be better since then we would know whether an unsupported combination (e.g. RTP/RTCP non-mux with DTLS) is being requested.

On Thu, Apr 20, 2017 at 9:46 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

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

[dk...@google.com]

Is this intent blocked on API owner feedback or are we waiting on additional information about standardizing error handling?

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

[Taylor Brandstetter]

Still need feedback from the Firefox side regarding error handling. To reiterate, the question is: what should happen if a browser doesn't support non-muxed RTCP, and the application calls "new RTCPeerConnection({rtcpMuxPolicy: 'negotiate'})"?

Should the constructor throw a NotSupportedError (which is what I added in this PR), or just ignore the "rtcpMuxPolicy" field altogether?

One potential problem with the latter choice is that JSEP says:

   Implementations MAY choose to reject attempts by the application to
   set the multiplexing policy to "negotiate".

Key word being "reject," rather than "ignore". So, would ignoring the rtcpMuxPolicy altogether go against JSEP?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38c2080a-b316-4f60-a560-132b9463da1d%40chromium.org.

[Philip Jägenstedt]

Where did you reach out to Firefox devs? If there's no reaction in a reasonable time frame, then we shouldn't block on that. I do think we should eventually remove rtcpMuxPolicy entirely as opposed to keeping it only to throw exceptions, but it's not important enough to delay this, so take a pick :)

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

[Taylor Brandstetter]

If I'm picking: I'd still prefer throwing an error on construction, since I believe it would save application developers some confusion, and it's what's currently described in the spec.

This intent does still need more API owner LGTMs, though.

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

[Rick Byers]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK35n0Z-iEOCMTgMHmo1dg7hMoX5%2BpPcJ4Los4X0BCLs3rGT3Q%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_cx82WJXXS9hQjiQvTMWhPTmdc2dWAKmKRdSPWeEizXg%40mail.gmail.com.

[PhistucK]

It would be great if you created a ChromeStatus entry for this.

Thank you!

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-Y44P0yeqjDqsE7pdx5_ytRDWCSzD9C08%3Do-6oWQsa0A%40mail.gmail.com.

[Taylor Brandstetter]

Just forgot to link it: https://www.chromestatus.com/feature/5654810086866944

[PhistucK]

No, one specifically for the removal of "negotiate" (or of rtcpMuxPolicy in general? I mean, if there is only one value, why is it needed at all?). The link you mentioned has already been marked as enabled by default in an old release (45).

☆PhistucK

[Taylor Brandstetter]

This is the feature entry we created for the "intent to deprecate", after you requested it here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/OP2SGSWF5lo/kjYPPxm5CQAJ

Can't we just update this entry, changing the status to "removed" when it's removed? 

[PhistucK]

Then I guess I did not notice that later (or assumed that the previous intent of changing the default had its own separate entry). Sorry.

I think the right thing to do is to have two entries - one for changing the default mux policy to "require" (so starting with Chrome X, the protocol implication of "require" is enabled by default) and one for removing the option to choose it altogether (starting with Chrome Y, support for even specifying rtcpMuxPolicy is removed).

Sort of like an entry per intent, each with its own timeline.

☆PhistucK