RtpMapping实现Simulcast精准路由

在Simulcast场景下，基于RtpMapping的SSRC重写机制是实现多流精准路由与选择的基石。该机制通过为客户端协商的每一路编码层（Spatial Layer）分配唯一的服务端内部SSRC，并结合frame-marking等扩展头信息，使SimulcastConsumer能够基于分层策略（如分辨率、帧率）进行智能的流选择与转发。整个过程涉及从客户端原始SSRC到服务端映射SSRC的转换、分层信息的解析与维护，以及最终基于路由决策的SSRC再映射。

一、SSRC重写的核心逻辑与数据结构

在Simulcast协商中，客户端可能通过rid（RTP Stream Identifier）或ssrc标识多个编码层。为了统一处理并避免兼容性问题，mediasoup在服务端为每一路独立的流分配一个内部SSRC。

1. 映射生成阶段
在创建Producer时，服务端通过getProducerRtpParametersMapping函数生成RtpMapping，其中encodings数组为客户端协商的每个encoding分配一个唯一的mappedSsrc。

// 摘自博客内容：getProducerRtpParametersMapping 函数逻辑 export function getProducerRtpParametersMapping( params: RtpParameters, caps: RtpCapabilities ): RtpMapping { ... // 遍历客户端协商的 encodings for (const encoding of params.encodings!) { const mappedEncoding: any = {}; // 客户端协商的每个 encoding 都对应一个服务器 SSRC mappedEncoding.mappedSsrc = mappedSsrc++; // 分配递增的内部SSRC ... rtpMapping.encodings.push(mappedEncoding); } return rtpMapping; }

假设客户端协商了3个Simulcast层（低、中、高分辨率），服务端可能生成如下映射：

客户端编码层标识 (rid/ssrc) -> 服务端内部 mappedSsrc rid: low -> mappedSsrc: 1000001 rid: mid -> mappedSsrc: 1000002 rid: high -> mappedSsrc: 1000003

2. 报文重写阶段
Producer在MangleRtpPacket函数中，会使用mapRtpStreamMappedSsrc这个映射表（由rtpMapping.encodings构建），将接收到的RTP报文中的原始SSRC替换为对应的服务端内部SSRC。

// 摘自博客内容：Producer::MangleRtpPacket 中的SSRC转换代码 bool Producer::MangleRtpPacket(RTC::RtpPacket* packet, RTC::RtpStreamRecv* rtpStream) const { ... // SSRC 转换 { const uint32_t mappedSsrc = this->mapRtpStreamMappedSsrc.at(rtpStream); packet->SetSsrc(mappedSsrc); // 将客户端SSRC重写为服务端内部SSRC } ... }

经过此步骤，无论客户端原始SSRC为何，进入Router的所有Simulcast层流都拥有了唯一且稳定的内部SSRC标识（1000001, 1000002, 1000003）。Router内部的订阅与转发逻辑完全基于这些内部SSRC运作。

二、SimulcastConsumer的精准路由与选择

SimulcastConsumer的核心职责是：从Producer发布的多个内部SSRC流中，根据当前网络状况、订阅策略或手动指令，选择最合适的一路流（或一个特定的空域层和时域层组合）转发给接收端。其精准路由依赖于以下几个关键机制：

1. 分层信息的识别与关联
SimulcastConsumer需要知道每个内部SSRC（如1000001）对应哪个Simulcast层（如rid: low）。这个关联关系在创建Consumer时，通过RtpParameters中的encodings配置建立。Consumer会维护一个从内部SSRC到层标识/分层属性的映射，以便进行选择决策。

2. 基于frame-marking的分层过滤
WebRTC使用frame-markingRTP扩展头来标识视频报文的时间层（TID）和空间层（LID）。Producer在接收端会解析此信息。当SimulcastConsumer从Router收到一个RTP报文时，它可以检查frame-marking头中的TID和LID。

• 如果当前订阅策略是“只接收低分辨率（LID=0）”，那么Consumer会丢弃所有LID != 0的报文。
• 如果策略是“接收中分辨率（LID=1），且时间层为0或1（TID <=1）”，那么Consumer会检查每个报文的TID和LID，只转发符合条件的报文。

3. 动态切换与状态同步
当需要切换分辨率（如从“低”切换到“中”）时，SimulcastConsumer需要：

• 停止转发旧的内部SSRC（1000001）的流。
• 开始转发新的内部SSRC（1000002）的流，并从关键帧（I帧）开始，以避免接收端解码错误。
• 在切换瞬间，需要进行时间戳（Timestamp）的校准，因为不同Simulcast层的RTP时间戳基准可能不同。如博客所述，SimulcastConsumer会转换timestamp，使用NTP时间进行校准，以保证接收端时间戳连续，避免跳帧。

4. 出站SSRC的再映射
SimulcastConsumer选定了要转发的内部SSRC流（例如1000002）后，在发送给接收端前，需要将SSRC再次重写。这次重写是将服务端内部SSRC替换为接收端在SDP Answer中期望的SSRC（该SSRC由接收端在setLocalDescription时分配）。这是通过Consumer的rtpParameters.encodings[0].ssrc字段完成的。

// 摘自博客内容：SimulcastConsumer::SendRtpPacket 中的SSRC重写 void SimulcastConsumer::SendRtpPacket( RTC::RtpPacket* packet, std::shared_ptr<RTC::RtpPacket>& sharedPacket) { ... // 将内部SSRC重写为接收端期望的SSRC packet->SetSsrc(this->rtpParameters.encodings[0].ssrc); ... }

三、完整数据流与路由决策表

下表梳理了一个典型的Simulcast流从客户端A发送，经服务端路由，最终到达客户端B的完整过程中，SSRC与分层标识的变换逻辑，以及关键的路由决策点：

四、技术优势与设计意义

1. 路由决策与转发解耦：Router仅负责简单的、基于内部SSRC的复制分发，复杂度极低。而精细的分层选择逻辑（基于LID/TID、关键帧检测、时间戳同步）封装在SimulcastConsumer内部，符合单一职责原则。
2. 状态隔离：每个Consumer独立维护自己的序列号管理器(rtpSeqManager)和时间戳同步状态。这使得同一Producer的不同订阅者可以独立选择不同的Simulcast层，且互不干扰。
3. 支持动态自适应：基于frame-marking的实时解析，使得服务端（或通过信令控制）可以根据接收端的网络带宽估算，动态指示Consumer切换LID和TID，实现平滑的码率自适应。
4. 协议兼容性保障：通过SSRC重写，将客户端可能使用的复杂或非标准的Simulcast信令（如rid）转换为一套服务端内部统一的、基于SSRC的标识体系，简化了核心转发逻辑，并提高了对不同客户端实现的兼容性。

综上所述，RtpMapping的SSRC重写机制为Simulcast多流选择提供了精准的“寻址”基础。它将客户端的多层流标识转化为服务端内部唯一的SSRC，使得后续的Router复制和Consumer选择逻辑可以基于这些稳定的标识进行。而SimulcastConsumer则在此基础上，结合报文内的分层元数据（frame-marking）和外部控制指令，实现了对特定空域层和时域层的精准筛选与转发，最终通过出站SSRC重写完成端到端的正确交付。这一整套机制是mediasoup高效、灵活支持Simulcast等高级视频功能的关键 。

参考来源

• 深入浅出mediasoup—媒体处理