1339203 - RTCPeerConnection does not support setting rtcpMuxPolicy parameter

Status: RESOLVED DUPLICATE of bug 1342206

(Core :: WebRTC: Networking, defect, P3)

Description

[Juan de Bravo]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.37 Safari/537.36

Steps to reproduce:

Create an RTCPeerConnection object configuring the rtcpMuxPolicy value:

// rtcp-mux is optional
new RTCPeerConnection({rtcpMuxPolicy: "negotiate"})

or

// rtcp-mux is mandatory
new RTCPeerConnection({rtcpMuxPolicy: "require"})


Actual results:

RTCP candidates are always gathered, no matter the rtcpMuxPolicy value


Expected results:

When rtcpMuxPolicy is "require", RTCP candidates should not be gathered, as rtcp-mux is mandated.

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

Comment 1

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

The spec here changed two years ago, and "negotiate" was dropped due to "lack of implementer interest". Even though it's what Firefox implements, this wasn't caught at TPAC 2019 because we didn't have the prerequisite WebIDL in place, we simply just implemented this by default, in spite of the spec at the time requiring that "require" be the default value. We also didn't implement any of the transport objects, and this would have required and extra one: rtcpTransport. Other browsers never supported this.

"require" remains the default, but is now also the sole option.

Comment 3

[Byron Campen [:bwc]]

I should point out that "require" straight-up violates the base SDP specifications, which require support for not using rtcp-mux. I can live with adding the policy value here, but having our JSEP engine violate the base spec is not something that makes a whole lot of sense unless maybe we're doing bundle-only.

Comment 4

[Byron Campen [:bwc]]

Ok, I see that the IETF has published a spec that allows "require" to work (RFC 8858), with an a=rtcp-mux-only attribute. This will still break when trying to interop with old endpoints though. The bundle spec avoided this problem by setting the m-section port to 0 when adding an a=bundle-only attribute; this ensured that endpoints that did not understand a=bundle-only would treat that m-section as disabled, but RFC 8858 does not do anything like this. I'm guessing this will just result in RTCP being sent to a port that will never receive it. Not really ideal, but maybe acceptable.

Mind you, nothing else seems to support a=rtcp-mux-only right now. What a mess.