RTCP接收报告（RR）包后额外14字节含义及处理咨询

额外数据的可能性质 #

你提到的这14字节额外数据（十进制：[-128, 0, 8, 87, -5, -2, -10, 113, -74, -9, -2, 110, -83, 92]，十六进制：0x80 0x00 0x08 0x57 0xFB 0xFE 0xF6 0x71 0xB6 0xF7 0xFE 0x6E 0xAD 0x5C），结合仅Chrome、仅ssrc=1触发的场景，大概率是Chrome的实现bug：

• 不符合RTCP规范：RTCP要求所有包必须4字节对齐，14字节不是4的倍数，不可能是合法的复合RTCP包片段；
• 首字节对应的RTCP类型为0，不属于任何标准RTCP包类型（标准类型如RR是201、SR是200），也未注册为私有扩展类型；
• 仅在特定SSRC下触发，说明是Chrome处理特定流标识时的逻辑错误，可能是内存溢出、包拼接残留数据或未清理的内部调试字段。

具体处理方案 #

针对这个异常情况，SFU侧可以采取以下两种可靠处理方式：

• 严格按RTCP规范截断：RTCP头部的长度字段表示32位字的数量减1，合法包总字节数为(长度字段值 + 1) * 4。你提供的完整包中，RTCP头部长度字段为0x0007，因此合法包长度为(7+1)*4=32字节，直接丢弃32字节之后的所有额外数据即可，完全不影响正常RTCP RR的解析。
• 针对性兼容适配：如果需要更精准的适配，可以在SFU中增加判断逻辑：当检测到来自Chrome的RTCP包总长度超过计算出的合法长度，且SSRC为1时，自动截断到合法长度。这种方式可避免误截断其他合法场景下的包。

另外，你可以将这个问题提交到Chrome官方bug跟踪系统，配合相关样本帮助团队定位修复该异常行为。

内容的提问来源于stack exchange，提问作者Horcrux7