Closed Bug 1339203 Opened 7 years ago Closed 2 years ago

RTCPeerConnection does not support setting rtcpMuxPolicy parameter


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

51 Branch





(Reporter: juandebravo, Unassigned)


(Blocks 2 open bugs)


(Whiteboard: [spec-compliance])

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"})


// 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:
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
backlog: --- → webrtc/webaudio+
Rank: 25
Ever confirmed: true
Priority: -- → P2
Whiteboard: [spec-compliance]
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Depends on: 1402221
Blocks: 1533017

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.

Closed: 2 years ago
Resolution: --- → DUPLICATE

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.

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.

You need to log in before you can comment on or make changes to this bug.