mediasoup中RTC::RTCP::FeedbackRtpTransport::AddPacket()断言失败问题分析

问题背景

在mediasoup 3.13.19版本中，出现了一个关于RTC传输控制的关键断言失败问题。具体表现为系统在运行过程中突然崩溃，错误日志显示"RTC::RTCP::FeedbackRtpTransport::AddPacket() | failed assertion `baseSet': base not set"。

问题现象

系统崩溃时产生的核心转储显示，程序在FeedbackRtpTransportPacket::AddPacket()方法中触发了断言失败，导致进程收到SIGABRT信号而终止。从调用栈可以看出，问题发生在TransportCongestionControlServer处理传输拥塞控制反馈的过程中。

技术原理

在mediasoup的RTC传输拥塞控制机制中，FeedbackRtpTransportPacket类用于构建和发送传输层拥塞控制反馈包。这类反馈包需要设置一个基础序列号(base sequence number)和参考时间(reference time)，然后才能添加具体的包信息。

关键的设计要点是：

1. 必须先调用SetBase()方法设置基础信息
2. 然后才能调用AddPacket()方法添加包信息
3. 类内部通过baseSet标志位来确保这一顺序

问题根源

经过深入分析，发现问题出在TransportCongestionControlServer类的实现逻辑上。虽然正常情况下FillAndSendTransportCcFeedback()方法会先调用SetBase()再调用AddPacket()，但在某些异常处理路径中，代码会重新创建FeedbackRtpTransportPacket实例，却没有正确处理状态。

具体来说，在以下两种情况下会重置反馈包：

1. 当反馈包大小超过最大限制时(MAX_SIZE_EXCEEDED)
2. 当发生严重错误时(CRITICAL)

在这两种情况下，代码会创建一个新的FeedbackRtpTransportPacket实例，但之后可能直接进入AddPacket()调用，而没有先调用SetBase()。由于新创建的实例baseSet标志位为false，导致断言失败。

解决方案

正确的修复方式应该是在重置反馈包后，确保在调用AddPacket()之前先调用SetBase()。具体可以采取以下两种方式之一：

1. 在重置反馈包后立即设置基础信息
2. 或者在调用AddPacket()前检查baseSet状态，必要时重新设置基础信息

此外，还需要考虑TransportDisconnected()方法中重置反馈包的情况，虽然当前因为停止了定时器不会立即导致问题，但从代码健壮性角度也应该保持一致处理。

经验教训

这个问题的出现提醒我们：

1. 状态机设计时要考虑所有可能的转换路径
2. 断言失败通常意味着程序逻辑存在缺陷，而不仅仅是数据问题
3. 对象重置操作需要特别小心，确保所有相关状态都被正确初始化
4. 异常处理路径需要与正常路径一样严谨

总结

mediasoup中的这个断言失败问题揭示了RTC传输拥塞控制反馈机制中的一个状态管理缺陷。通过深入分析调用流程和状态转换，我们不仅找到了问题根源，也提出了合理的解决方案。这类问题的修复不仅需要解决表面现象，更需要理解背后的设计原理，确保系统在各种边界条件下都能保持稳定。