# Possible to disable RTCP-XR in producer? **URL:** \ **Category:** mediasoup libraries\ **Created:** [November 29, 2019, 6:24pm UTC](https://mediasoup.discourse.group/t/possible-to-disable-rtcp-xr-in-producer/432 "2019-11-29T18:24:24Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\ **Post date:** [December 2, 2019, 7:08pm UTC](https://mediasoup.discourse.group/t/possible-to-disable-rtcp-xr-in-producer/432/8 "2019-12-02T19:08:56Z")
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](https://tools.ietf.org/html/rfc5506#section-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: - [RFC 3611 - RTP Control Protocol Extended Reports (RTCP XR)](https://tools.ietf.org/html/rfc3611#section-4.4) - [RFC 3611 - RTP Control Protocol Extended Reports (RTCP XR)](https://tools.ietf.org/html/rfc3611#section-4.5) 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](https://mediasoup.org/documentation/v3/mediasoup/rtc-statistics/#Producer-Statistics) 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”: - [6301 - webrtc - Web-based real-time communication - Monorail](https://bugs.chromium.org/p/webrtc/issues/detail?id=6301) We are not doing that at all and we ignore RTCP XR packets with types different than 4 (RTT) and 5 (DLRR). --- _[View the full topic](https://mediasoup.discourse.group/t/possible-to-disable-rtcp-xr-in-producer/432)._