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:
0x81, 0xc9, 0x00, 0x07,
0x00, 0x00, 0x00, 0x01,
0x0c, 0xf7, 0x2a, 0x29,
0x0e, 0xfd, 0x7e, 0xee,
0x42, 0x1b, 0x9a, 0xf3,
0x7a, 0x10, 0x22, 0xbe,
0x1c, 0xb2, 0xe7, 0xe4,
0xb8, 0xa7, 0xeb, 0x90,
// End of first compound packet
0x80, 0x00, 0x00, 0x01,
0x6a, 0x18, 0xa8, 0x2d,
0x90, 0x60, 0x08, 0x64,
0x6f, 0xe3
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.