Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
enobufs opened this issue Apr 4, 2024 · 6 comments
Open

Comments

@enobufs
Copy link
Member

enobufs commented Apr 4, 2024

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 Sean-Der transferred this issue from pion/ice Apr 4, 2024
@Sean-Der
Copy link
Member

Sean-Der commented Apr 4, 2024

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

@enobufs enobufs self-assigned this Apr 4, 2024
@sirzooro
Copy link
Contributor

sirzooro commented Apr 4, 2024

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
Copy link
Member Author

enobufs commented Apr 4, 2024

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
Copy link
Contributor

sirzooro commented Apr 5, 2024

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
Copy link
Member Author

enobufs commented Apr 5, 2024

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
Copy link
Contributor

sirzooro commented Apr 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants