RTCP 接收报告包后额外字节的含义？

Question

如果我在 SFU 中收到来自 Chrome 的 RTCP.RR 数据包（接收报告），则该数据包后会有额外的 14 个字节。例如：

[-128, 0, 8, 87, -5, -2, -10, 113, -74, -9, -2, 110, -83, 92]

完整的数据包是：

[-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]

这个额外的字节似乎不是一个有效的复合数据包。我仅从 Chrome 浏览器收到它。不是来自 Edge，也不是来自 Brave。知道这些数据意味着什么吗？我应该如何处理这些额外的字节？

*.pcap 文件以及一些示例

PS：这个问题似乎只发生在 ssrc=1 时

Answer 1

将 pcap 中的第一个数据包视为十六进制转储：

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解释了格式。 接收报告计数设置为 1，这意味着随后有一个报告块。

但是之后第二个报告的有效负载类型字段为0，这是不寻常的。您获得 14 个字节表明您正在查看加密的 SRTCP 数据包，该数据包（对于 AES_CM_128_HMAC_SHA1_80 密码套件）的长度为 4（对于 SRTCP 索引）+ 10 字节。请参阅https://www.rfc-editor.org/rfc/rfc3711#section-3.4。

您需要在 SFU 中解密该数据包。