Possible to disable RTCP-XR in producer?

mediasoup libraries
8

Hi! So two subjects here:

Regarding rtcp-size and NACK:

Correct me if I’m wrong but AFAIU, if rtcp-rsize is not supported by the endpoint then mediasoup cannot send separate separate NACK feedbacks but just full RTCP compound packets that also contain NACK feedbacks (in addition to the mandatory Sender Report and Receiver Report entries), am I right?

If so, I’m pretty sure that having to generate a full compound packet when sending a NACK feedback cannot be good. From RFC 5506 section 3.3:

3.3. Benefits of Reduced-Size RTCP

As mentioned in the introduction, most advantages of using Reduced- Size RTCP packets exist in cases when the available RTCP bitrate is limited. This is because they can become substantially smaller than compound packets. A compound packet is forced to contain both an RR or an SR and the CNAME SDES item. The RR containing a report block for a single source is 32 bytes, an SR is 52 bytes. Both may be larger if they contain report blocks for multiple sources. The SDES packet containing a CNAME item will be 10 bytes plus the CNAME string length. Here, it is reasonable that the CNAME string is at least 10 bytes to get a decent collision resistance. If the recommended form of user@host is used, then most strings will be longer than 20 characters. Thus, a Reduced-Size RTCP can become at least 70-80 bytes smaller than the compound packet.

Being completely honest we don’t want to send NACK feedbacks within RTCP compound packets. IMHO it’s a complete no-sense (it would be a CPU and network killer) and any RTP endpoint supporting NACK is supposed to also support reduced-size.

Regarding RTCP XR:

I don’t know what those “XR reports with a type=42” are. In mediasoup we just implement the super standard TRR and DLRR XR types:

Those types are needed to calculate the RTT in a Producer (so mediasoup can calculate the RTT of a RTP stream received from an endpoint) and include an roundTripTime field in Producer stats. Note that for Consumer stats we don’t need any XR to calculate its RTT.

The type=42 RTCP XR you mention is, indeed, a hack or custom stuff used by Chromium to signal “the encoder target bitrate via RTCP”:

We are not doing that at all and we ignore RTCP XR packets with types different than 4 (RTT) and 5 (DLRR).