Generate host candidates with component 1 only when a=rtcp-mux is present

[enobufs]

Your environment.

• Version: 3.2.32
• Browser: n/a

What did you do?

Try to connect from Chrome browser to a Pion application.

What did you expect?

I see two a=candidate lines for the same transport address even though it uses a=rtcp-mux (RTP/RTCP multiplexing)
According to RFC 8445 Section 5.1.1.1:

   Each component has an ID assigned to it, called the "component ID".
   For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed
   in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a
   component ID of 1, and RTCP has a component ID of 2.  In case of RTP/
   RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP.

I believe we could drop the component 2. In fact, Chrome generates one candidate for a transport with component set to 1.

What happened?

Pion generates SDP with the following candidates:

a=candidate:196456620 1 udp 2130706431 2601:646:c201:f4d0:412e:749c:6e30:47cc 50897 typ host
a=candidate:196456620 2 udp 2130706431 2601:646:c201:f4d0:412e:749c:6e30:47cc 50897 typ host
a=candidate:302805250 1 udp 2130706431 10.0.0.238 50897 typ host
a=candidate:302805250 2 udp 2130706431 10.0.0.238 50897 typ host
  :

[Sean-Der]

I don't think this will be that hard either @enobufs! You interested in taking it?

[sirzooro]

Make sure you do not break backward compatibility with agents who do not support multiplexing. Next paragraph of mentioned RFC's section clearly states this:

When candidates are obtained, unless the agent knows for sure that
RTP/RTCP multiplexing will be used (i.e., the agent knows that the
other agent also supports, and is willing to use, RTP/RTCP
multiplexing), or unless the agent only supports RTP/RTCP
multiplexing, the agent MUST obtain a separate candidate for RTCP.

[enobufs]

My plan is to remove the RTCP candidate in the answer only when a=rtcp-mux is present in the offer as mentioned in the title (my project uses pion as an answerer always).

For the offer, we will need to take RTCPMuxPolicy into consideration. W3C's RTCPMuxPolicy only has require. Also, Chrome, in fact, does not add RTCP candidate in the offer. MDN spec has both options but require is the default. So, what Chrome does conforms with W3C. We could potentially drop the component 2 candidate also. FireFox sends both components in the offer SDP, but it does not support RTCPMuxPolicy... lol. Any thoughts?

[sirzooro]

Sounds good to me. I was a bit worried to disable 2nd component completely, but presence of RTCPMuxPolicy configuration option resolves this.

BTW, it would be good to also send a=rtcp-mux-only in offer when mux policy is set to require. Currently pion does not support this attribute at all.

[enobufs]

it would be good to also send a=rtcp-mux-only in offer when mux policy is set to require.

I am a bit worried about it... Both Chrome and FireFox, though require is supposed to be default and it is the only value in W3C, send a=rtcp-mux not a=rtcp-mux-only in my observation. There may be WebRTC implementations that do not understand *-only ...

[sirzooro]

You need to generate both attributes in offer. This may not be clear in section 5.2 of JSEP, but is in section 5.8.3 of that document:

If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. If an m= section contains an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute.

Answer can contain a=rtcp-mux attribute only.