If I receive a RTCP.RR packet (Receive Report) from Chrome in my SFU then there are additional 14 bytes after the packet. For example:
[-128, 0, 8, 87, -5, -2, -10, 113, -74, -9, -2, 110, -83, 92]
The complete packet was:
[-127, -55, 0, 7, 0, 0, 0, 1, 61, -95, 64, -8, 87, 81, -74, -113, -73, -75, 96, 34, -101, -1, -75, -125, -88, 40, -117, -49, -18, 20, -60, -56, -128, 0, 8, 87, -5, -2, -10, 113, -74, -9, -2, 110, -83, 92]
This extra bytes does not seems a valid compound packet. I receive it only from Chrome browser. Not from Edge and not from Brave. Any idea what this data are meaning? What should I do with this extra bytes?
PS: The problem seems only to occur with ssrc=1
Looking at the first packet from the pcap as a hexdump:
https://www.rfc-editor.org/rfc/rfc3550#section-6.4.2 explains the format. The reception report count is set to 1 which means that one report block follows.
But after that the field of the payload type for the second report is 0 which is unusual. That you get fourteen bytes suggests you are looking at an encrypted SRTCP packet which (for the AES_CM_128_HMAC_SHA1_80 ciphersuite) has a length of 4 (for the SRTCP index) + 10 bytes. See https://www.rfc-editor.org/rfc/rfc3711#section-3.4.
You will need to decrypt that packet in your SFU.