Do we need a control API for RTCP feedback mechanisms?

[alvestrand]

When hunting an unrelated problem, I came across the need to check whether or not certain RTCP feedback mechanisms (nack, rrtr, transport-cc) were turned on.
It turned out that in order to do this, I had to do SDP inspection or C++ APIs; I would have to do the same thing to affect them.

Do we have an use case where it makes sense to expose an API to turn these mechanisms on and off?

(For extra credit: turn on and off feedback mechanisms that are transport-wide rather than codec-dependent)

[bdrtc]

As webrtc app developer, it's easy to see whether or not certain RTCP were turned on/off by analize default sdp.
But when the user want to turn on or off a certain rtcp feature, it is inconvenient (sdp munging),
so to add a control api is more convenient, then, what level api will you want?
maybe we should consider

1)media type level
user may want disable audio tcc/others but open for video.
2)media direction
user may want use remb rtcp in media send direction but use tcc in media receive direction.

[aboba]

In ORTC, we had rtcpFeedback included in RTCRtpCodecCapability (for discovery) as well as in RTCRtpCodecParameters (for configuration).

[dontcallmedom-bot]

This issue was mentioned in WEBRTCWG-2023-05-16 (Page 25)