PSA: Default RTCRtpMuxPolicy is now "require"

[Taylor Brandstetter]

As of the most recent Chrome Canary build, the default RTCP multiplexing policy is "require", instead of "negotiate". This will affect the next Chrome release, M57.

This means that offer/answer negotiation with an endpoint that doesn't support RTCP multiplexing will fail, resulting in the error: "ERROR_CONTENT. Session error description: Failed to setup RTCP mux filter." We can probably make this error more descriptive, but the bottom line is that setRemoteDescription will fail if the SDP does not contain "a=rtcp-mux".

For any application that doesn't yet support RTCP multiplexing, you can get the old behavior by explicitly setting the RTCRtpMuxPolicy to "negotiate" in the RTCConfiguration. For example:

pc = new RTCPeerConnection({rtcpMuxPolicy: "negotiate"})

Here are the related webrtc/chromium bug entries, for more background:

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

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

[Dan Jenkins]

Any idea on how long this flag will hang around for? Asterisk doesn't support rtcp multiplexing and so it'll be a while before we won't have a need for this flag - https://issues.asterisk.org/jira/browse/ASTERISK-26732

[PhistucK]

If you mean the {rtcpMuxPolicy: "negotiate"} flag, it should stay indefinitely, it is in the specification, so not a temporary solution -

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

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

It is just a default change, not a removal of a feature.

(But there are no guarantees, anyway)

☆PhistucK

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1a4c04a8-0515-4127-909c-8cb4fc442a98%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Taylor Brandstetter]

While M57 only changes the default value, we also plan to deprecate the "negotiate" option in a later release. See JSEP section 4.1.1:

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

The reasoning is that multiplexed RTCP is simpler from an API and implementation perspective, and consumes less resources. Firefox developers have expressed willingness to drop support for non-muxed RTCP as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CABc02_%2BNhYDPeKC%3DCpuF%3DoUZ7%2BwB_wicuJFG0KB5n2Yxha8W2Q%40mail.gmail.com.

[PhistucK]

Huh, can you mark it "At risk" in the specification then?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0Y8A-Si1e32oQh6Am8uST45gjCscLSWFS2-NoJqrttr%3DQ%40mail.gmail.com.

[Taylor Brandstetter]

Should that happen now, or when WebRTC advances beyond the "Working Draft" stage? (just a question about W3C process)

I'll also make sure we follow the Blink deprecation process, by the way: https://www.chromium.org/blink/deprecating-features 

On Thu, Jan 19, 2017 at 9:46 PM, PhistucK <phis...@gmail.com> wrote:

Huh, can you mark it "At risk" in the specification then?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CABc02_JCc%2BRHL%3DZmpQmmFVbFRZZrzfFt8T5-2jy%3DhnriFXts3Q%40mail.gmail.com.

[PhistucK]

No real idea, but if you already know the feature is at a high risk, I suspect sooner is better than later.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0bkqmHMQRk1Kf0bjJR8Ea6M6r8zHoiomrDEe66urBH-Xg%40mail.gmail.com.

[Basar Daldal]

Hi,

How can we follow the decision process about the deprecation of negotiate option? Is this the final decision, when it is going to be implemented, how much time we will have to get ready before the change is in the stable version etc. Any information on that is much appreciated.

Thanks,

On Saturday, January 21, 2017 at 11:31:38 PM UTC+3, PhistucK wrote:

No real idea, but if you already know the feature is at a high risk, I suspect sooner is better than later.

☆PhistucK

On Fri, Jan 20, 2017 at 8:08 AM, 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com> wrote:

Should that happen now, or when WebRTC advances beyond the "Working Draft" stage? (just a question about W3C process)

I'll also make sure we follow the Blink deprecation process, by the way: https://www.chromium.org/blink/deprecating-features 

On Thu, Jan 19, 2017 at 9:46 PM, PhistucK <phis...@gmail.com> wrote:

Huh, can you mark it "At risk" in the specification then?

☆PhistucK

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1a4c04a8-0515-4127-909c-8cb4fc442a98%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CABc02_%2BNhYDPeKC%3DCpuF%3DoUZ7%2BwB_wicuJFG0KB5n2Yxha8W2Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0Y8A-Si1e32oQh6Am8uST45gjCscLSWFS2-NoJqrttr%3DQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CABc02_JCc%2BRHL%3DZmpQmmFVbFRZZrzfFt8T5-2jy%3DhnriFXts3Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[PhistucK]

(This is a general answer, not specific to this feature, because the process is the same)

In case this has a use counter (it does not :(), you can check every once in a while to see whether the usage is low. If it is low, chances are that it will be deprecated and removed soon.

Also, ChromeStatus usually has an entry for every deprecation, usually including data about the version in which it will be deprecated (and a deprecation shows up upon usage in the console, stating the removal version).

The usual minimal period for deprecation is a single release (deprecated in N, removed in N + 1). It might be outright removed at once (without any deprecation period) if the usage is extremely low (0.00000...% of the page views), but usually no one is in such a hurry anyway.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b6e3b2ec-3d10-4659-a588-fc9090641f03%40googlegroups.com.

[Taylor Brandstetter]

I created this bug for the deprecation, FYI: https://bugs.chromium.org/p/chromium/issues/detail?id=685727

Our current plan is to add the use counter and deprecation message in M58, which means the earliest it could be removed is M59 (estimated stable date June 6th).

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CABc02_KMpWce78nnp%3DOa_mCLBhqTW9nsJFcTWE9JdsXiFR3Vag%40mail.gmail.com.

[Basar Daldal]

Thanks for the answers. So, with the removal of this option, it means RTCP Multiplexing is becoming mandatory and if any endpoint (like a WebRTC Gateway) does not support RTCP Multiplexing, it won't be able to talk to a WebRTC application running on Chrome, right?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b6e3b2ec-3d10-4659-a588-fc9090641f03%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

That's correct. Though of course, we'll do this thoughtfully and pay attention to usage numbers.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/da8766d6-eb24-40af-a36a-7cfcee9265dc%40googlegroups.com.

[Basar Daldal]

Thanks, One more question (that I actually hesitate to ask): Any similar change planned for Bundling?

[Taylor Brandstetter]

No; from what I recall, there are certain enterprise network environments that require sending audio and video from separate ports, for QoS reasons. So, "non-bundled" support will stay around.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/bf908fca-50c8-4333-b202-3d7a14e19194%40googlegroups.com.

[Basar Daldal]

I see in the comments section of the issue record (https://bugs.chromium.org/p/chromium/issues/detail?id=685727)  that there is an intention to deliver the deprecation to M57. Does this mean the removal will be done in M58? I don't think it is a correct approach, it is too aggressive. The usage statistics should be observed first after M57 becomes stable. This is when the real usage of negotiate can be seen. After that deprecation at M58 and removal at M59 or later is a better and fair approach. This is a very important change and should be handled carefully. 

[Taylor Brandstetter]

Does this mean the removal will be done in M58?

No; the deprecation message itself will say it won't be removed any earlier than M60. And it could be removed later depending on statistics.

We just wanted to add the deprecation message at the same time as the default is changing, so that if developers need to start explicitly specifying the "negotiate" policy, they're also made aware that there's an intent to deprecate it.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ce5c1134-fc10-4cb4-82df-37d73bcd305d%40googlegroups.com.

[Andy Hutton]

I am rather surprised to see this proposal at this stage.  

As already mentioned in this thread the WebRTC API Spec does not say anything about this being optional to implement and I have not seen any W3C discussion on this subject.

Andy

[Philipp Hancke]

hey Andy,

this was discussed and decided upon a while back:

https://www.ietf.org/mail-archive/web/rtcweb/current/msg15334.html 

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ce4d9f15-b946-44c5-99ec-1074c5726249%40googlegroups.com.

[Andy Hutton]

That was a discussion in the IETF about the default setting which is a different issue.

As far as I know there has been no W3C discussion on deprecating the "negotiate" option in the API.

[Peter Thatcher]

The W3C Spec section 4.2.6 defers definition of RTCRtcpMuxPolicy Enum to JSEP Section 4.1.1, which Taylor referenced.  The reason it wasn't discussed in the W3C is because the discussion happened in the IETF.    

[Peter Thatcher]

And the discussion in the IETF was not just about the default, it was about whether "negotiate" was optional or not.  As you can see from the spec, it was decided that it would be optional.

[Andy Hutton]

Hi Peter,

I understand what is in JSEP but I don't believe the reference to JSEP in the W3C Spec is sufficient and I personally only interpreted it as a reference to the description on what the policy means for ICE candidate gathering as it states: "As described in [JSEP] (section 4.1.1.), the RtcpMuxPolicy affects what ICE candidates are gathered to support non-multiplexed RTCP."

It does not, at least in my interpretation, defer to JSEP for what policies need to be implemented surely the API specification needs to clearly state what API options are mandatory or optional to implement.

Could you clarify whether https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 be supported for the "require" option?

The issues around the exclusive option are also discussed in draft-ietf-mmusic-mux-exclusive which for example includes the text below:

Some newer applications that do not require backward compatibility
   with peers that cannot multiplex RTCP might choose to not implement
   separation of RTP and RTCP.  Examples of such applications are W3C
   WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required
   to interoperate with non-WEBRTC clients.

I understand the desire for simplification but as already stated in this conversations some platforms/apps are reliant on this at present so please be cautious about removing this.

Regards

Andy

[Taylor Brandstetter]

surely the API specification needs to clearly state what API options are mandatory or optional to implement

From what I've gathered, unimplemented features would simply be removed from the standard as it matures. Recently it was marked as "at risk" at PhistucK's request.

But if it's not removed, I agree the WebRTC specification needs to be updated. It would need to at least describe what error is thrown if the PeerConnection is constructed with an unsupported policy. Here's an issue: https://github.com/w3c/webrtc-pc/issues/1065

Could you clarify whether https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 be supported for the "require" option?

Yes, though we haven't implemented this in Chrome yet. 

I understand the desire for simplification but as already stated in this conversations some platforms/apps are reliant on this at present so please be cautious about removing this.

We'll definitely do this cautiously. Also, if you have specific examples of platforms/apps that are affected, let us know so we can reach out to them.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3e03ebba-30f7-4c66-9088-f4608c0ae6c4%40googlegroups.com.

[Peter Thatcher]

On Wed, Mar 8, 2017 at 10:30 AM Andy Hutton <andyhu...@gmail.com> wrote:

Hi Peter,

I understand what is in JSEP but I don't believe the reference to JSEP in the W3C Spec is sufficient and I personally only interpreted it as a reference to the description on what the policy means for ICE candidate gathering as it states: "As described in [JSEP] (section 4.1.1.), the RtcpMuxPolicy affects what ICE candidates are gathered to support non-multiplexed RTCP."

It does not, at least in my interpretation, defer to JSEP for what policies need to be implemented surely the API specification needs to clearly state what API options are mandatory or optional to implement.

 

Perhaps you're right that the spec could be easier to read for someone unfamiliar with the relationship between the WebRTC and JSEP documents.  The documents aren't done yet, so we can still make it more clear before they are published.  Taylor's issue he filed will probably be sufficient to make that happen.

Could you clarify whether https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-11 be supported for the "require" option?

The issues around the exclusive option are also discussed in draft-ietf-mmusic-mux-exclusive which for example includes the text below:

Some newer applications that do not require backward compatibility
   with peers that cannot multiplex RTCP might choose to not implement
   separation of RTP and RTCP.  Examples of such applications are W3C
   WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required
   to interoperate with non-WEBRTC clients.

I understand the desire for simplification but as already stated in this conversations some platforms/apps are reliant on this at present so please be cautious about removing this.

We take possibly breaking changes seriously and are very careful about it.   

Are you concerned with this for web apps or native apps?  For web apps, some browsers (Edge, I believe) already do not support non-muxed RTCP.  I don't know what the timeline for other browsers (such as Firefox), but I think it's only a matter of time before all browsers drop support for non-muxed RTCP.  I would recommend updating any endpoints that don't do muxed RTCP as soon as possible.

You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/eM57DEy89MY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3e03ebba-30f7-4c66-9088-f4608c0ae6c4%40googlegroups.com.

[Andy Hutton]

Thanks Peter & Taylor for responding so quickly and raising the issue in github as long as the API spec is clear and you don't rush in to this I think all is good.

Andy

[Padma Prasad Dharmaraja]

When is rtcpmuxPolicy:negotiate offically getting deprecated.

Any time lines or any specific Chrome version after which the rtcpMuxPolicy:require is mandatory.

[Taylor Brandstetter]

We've updated the console message to say "may be removed no earlier than M62, around October 2017"; see this thread for the motivation.

We don't have any more specific plans than that, since we're waiting to see how the usage statistics change. But if they're something that's preventing you from implementing muxed RTCP, let us know so we can help (if possible).

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/823faa2d-0cfe-4e8c-ac90-f4f272206963%40googlegroups.com.

[Basar Daldal]

Hi,

Any update on the removal plans? 

Thanks,

Basar

On Friday, June 30, 2017 at 3:33:22 PM UTC+3, Taylor Brandstetter wrote:

We've updated the console message to say "may be removed no earlier than M62, around October 2017"; see this thread for the motivation.

We don't have any more specific plans than that, since we're waiting to see how the usage statistics change. But if they're something that's preventing you from implementing muxed RTCP, let us know so we can help (if possible).

On Fri, Jun 30, 2017 at 4:19 AM, Padma Prasad Dharmaraja <prasa...@gmail.com> wrote:

When is rtcpmuxPolicy:negotiate offically getting deprecated.

Any time lines or any specific Chrome version after which the rtcpMuxPolicy:require is mandatory.

On Friday, 23 December 2016 10:47:36 UTC+5:30, Taylor Brandstetter wrote:

As of the most recent Chrome Canary build, the default RTCP multiplexing policy is "require", instead of "negotiate". This will affect the next Chrome release, M57.

This means that offer/answer negotiation with an endpoint that doesn't support RTCP multiplexing will fail, resulting in the error: "ERROR_CONTENT. Session error description: Failed to setup RTCP mux filter." We can probably make this error more descriptive, but the bottom line is that setRemoteDescription will fail if the SDP does not contain "a=rtcp-mux".

For any application that doesn't yet support RTCP multiplexing, you can get the old behavior by explicitly setting the RTCRtpMuxPolicy to "negotiate" in the RTCConfiguration. For example:

pc = new RTCPeerConnection({rtcpMuxPolicy: "negotiate"})

Here are the related webrtc/chromium bug entries, for more background:

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

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

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

Since the last update, we've heard from other developers that would be affected, and need to update their hardware/firmware. So in order to give them a fair amount of time, we likely won't end up removing support until Q1 2018.

Also, usage stats have still not moved much from 2% (of PeerConnections). So I'm not sure we can justify removing it when that many connections will be broken. foolip@ and hta@, any thoughts?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/54e1e873-7bab-4cf6-ae1a-73013b4faade%40googlegroups.com.