在 mediasoup 的架构中，媒体流评分机制通过实时处理 RTCP 报文来动态评估传输通道的质量，其核心在于对接收端反馈的统计数据进行周期性的聚合与分析。该机制主要依据 RTCP 接收者报告（Receiver Report, RR）和发送者报告（Sender Report, SR）中携带的丢包率、延迟抖动、累计丢包数等关键指标，通过加权算法计算出代表当前流传输质量的 score 值。该评分体系被设计为一种归一化的评估模型，其数值范围通常设定在 0 至 10 之间，其中较高的分数表征更优的传输性能。
RTCP 报文在 mediasoup 中的处理流程始于 WebRtcTransport::OnPacketReceived 方法，该方法对传入的数据包进行协议类型鉴别。当识别出 RTCP 报文后，会将其路由至专门的 RTCP 处理器。RTCP 报文解析后，其内部的有效载荷数据会被提取并传递至评分计算模块。具体而言，mediasoup 会从 RTCP RR 报文中提取以下字段用于评分计算：
- 丢包率（Fraction Lost）：反映短期内的数据包丢失比例，是评估网络拥塞状况的直接指标。
- 累计丢包数（Cumulative Number of Packets Lost）：提供自会话开始以来的总体丢包情况，用于评估长期传输稳定性。
- 扩展的最高序列号（Extended Highest Sequence Number Received）：用于推导实际接收到的数据包数量，结合累计丢包数可计算总体丢包率。
- 抖动（Interarrival Jitter）：表示数据包到达时间的偏差，是衡量网络延迟波动的重要参数。
- 最后发送者报告时间戳（Last SR Timestamp, LSR）与延迟自最后发送者报告（Delay Since Last SR, DLSR）：这两个字段用于计算往返时间（RTT），但需注意，RTT 的计算需要发送端配合，并非所有实现都直接用于基础评分。
mediasoup 的评分算法并非简单的线性映射，而是基于上述多个维度构建的一个复合函数。其设计原则是：对网络损伤敏感，即当丢包率或抖动增加时，score 应显著下降；同时，算法需具备一定的惯性，避免因瞬时波动导致评分剧烈震荡，通常采用滑动窗口或指数加权移动平均（EWMA）对原始指标进行平滑处理。一个简化的、用于说明核心逻辑的评分计算伪代码如下所示（实际 mediasoup 实现更为复杂，且权重参数可能因版本或配置而异）：
cpp
// 伪代码：演示基于RTCP RR的评分计算核心逻辑
float calculateScoreFromRtcpReport(const RtcpReceiverReport& report) {
// 1. 提取关键指标
float fractionLost = report.fractionLost / 256.0f; // 转换为比例，范围[0,1]
uint32_t cumulativeLost = report.cumulativeLost;
uint32_t extendedHighSeq = report.extendedHighSeqNum;
uint32_t jitter = report.jitter; // 以时间戳单位表示
// 2. 计算衍生指标（示例）
float packetLossRate = fractionLost; // 短期丢包率
// 注意：实际长期丢包率可能由 cumulativeLost 和 extendedHighSeq 推导
float normalizedJitter = static_cast<float>(jitter) / kNormalizationFactor; // 归一化抖动
// 3. 应用权重计算基础分数（权重值W为示例）
const float W_LOSS = 0.6f;
const float W_JITTER = 0.3f;
const float W_OTHER = 0.1f; // 可能包含其他指标如RTT
float baseScore = 10.0f; // 起始满分
baseScore -= (packetLossRate * 10.0f * W_LOSS); // 丢包惩罚
baseScore -= (normalizedJitter * 10.0f * W_JITTER); // 抖动惩罚
// 其他指标惩罚...
// 4. 边界处理与平滑
baseScore = std::max(0.0f, std::min(10.0f, baseScore)); // 钳制在[0,10]
// 实际实现中，此处会与历史score进行平滑（如EWMA）
// currentSmoothedScore = alpha * baseScore + (1 - alpha) * previousSmoothedScore;
return baseScore;
}评分更新的触发时机与 RTCP 报文的接收频率直接相关。根据 RFC 3550，RTCP 报文的发送间隔应自适应地控制在会话带宽的 5% 左右，这意味着在稳定的视频会议中，评分会以大约每秒数次的频率进行更新。每次接收到有效的 RTCP RR 报文，便会触发一次评分重计算。更新后的 score 值会即时反馈给 mediasoup 的上层逻辑，用于决策，例如：
- 传输优化：当某条流的 score 持续低于阈值时，可能触发传输策略调整，如切换 ICE 候选对、调整 DSCP 标记或通知发送端调整编码比特率。
- 流切换：在 simulcast 或 SVC 场景中，接收端可能会基于各层/各流的 score 选择订阅质量最优的流。
- 质量监控与告警：服务端可聚合所有参与者的 score，形成全局视图，用于监控房间整体通话质量。
该评分机制是 mediasoup 实现智能传输控制的关键环节，它将低层次的网络统计信息转化为高层次的、可操作的质量度量，使得系统能够自适应网络变化，优化用户体验。