企业官网建设流程全解析

最近在给团队搭一套基于WebRTC的实时音视频服务，核心选型就是mediasoup。调试过程中发现很多同事对"RTP流类型"这个概念比较模糊：明明同一个Producer，为什么在服务端看到一堆不同的SSRC？RTX和FEC到底是干什么的？Simulcast为什么会有多路RTP？如果你也有类似的困惑，这篇文章应该能帮你把整条链路彻底捋清楚。我会从mediasoup实际决策的角度，把支持的RTP流类型拆开来讲，包括它们各自的作用、在SDP里长什么样、代码层如何配置，以及我踩过的几个坑。

这篇文章适合正在使用、或准备上手mediasoup做SFU的服务端开发者，也适合想搞懂WebRTC媒体传输细节的前端工程师。理解了这些流类型，你在排查丢包、卡顿、花屏问题时会少走很多弯路。

1. 一张图看懂mediasoup眼中的RTP流世界

1.1 为什么要区分这么多流类型

先说结论：mediasoup把RTP流类型分得很细，完全是实用主义驱动的。一个WebRTC会话里的RTP包，并不都是在传"真正的画面和声音"——有些包是用来重传丢失数据的，有些是用于前向纠错的冗余包，有些是探测网络带宽的空包，还有些是同一个视频源的多个质量版本。如果不把这些包区分开，服务器就无法做精细化控制，比如丢包时该触发什么策略、带宽足够时该请求哪一层数据。

从协议角度，RTP流靠 SSRC(Synchronization Source Identifier)、PT(Payload Type)、RID(RTP Stream ID) 等字段标识。mediasoup在内部把流类型抽象成了几类：普通媒体流、RTX重传流、FEC流、Simulcast/SVC分层流、探测流等。下面这张表是我根据源码和实际抓包整理的分类，你先有个整体印象，后面逐个展开。

1.2 从SDP协商到RTP收流的完整链路

mediasoup并不直接解析你浏览器里的SDP字符串，它把WebRTC的SDP协商抽象成了两套参数：Router级别有rtpCapabilities（表示这个服务端支持的RTP能力），Producer/Consumer级别有rtpParameters（表示一条具体流收发时用的编码、SSRC、RTX等细节）。

实际流程是：浏览器先把本地能力通过scalabilityMode之类的信息上报，服务端调用router.rtpCapabilities去匹配，然后通过信令把服务端能接受的能力推回给浏览器，最终浏览器创建PeerConnection时以这些参数为准。整个过程里"流类型"的差异就体现在rtpParameters中encodings数组的形态：

• 普通视频流：encodings只有一个元素，不带rid，不写scalabilityMode。
• Simulcast视频流：encodings有多个元素，每个元素带rid（r0/r1/r2）和不同的maxBitrate。
• SVC流：encodings通常一个元素，但scalabilityMode为L1T3或L3T3这类。
• 音频流：encodings只有一个元素，可以带rtx（实际上大多不带，音频走RED+FEC）。

理解了这层映射关系，后面看代码和抓包就会豁然开朗。

2. 媒体流：编码支持清单与rtpParameters映射规则

2.1 音频RTP流：opus一统天下的背后逻辑

音频是WebRTC里最"简单"也最"容易忽略"的部分。mediasoup官方默认支持的音频编码就是opus，payload type 通常协商为111，clockRate 48000，声道数由SDP里的useinbandfec=1这类参数体现。除了opus，服务端也允许你通过router.createWorker传入的rtpCapabilities里补充PCMU、PCMA这类古老编码。

我自己的项目里保留了PCMU和PCMA的支持，主要是为了对接传统电话网关。配置方式很直白，就是在创建Router前把codec列表写进RtpCapabilities：

const mediaCodecs: RtpCodecCapability[] = [ { kind: 'audio', mimeType: 'audio/opus', clockRate: 48000, channels: 2, parameters: { useinbandfec: 1, usedtx: 1 } }, { kind: 'audio', mimeType: 'audio/PCMU', clockRate: 8000, channels: 1 }, { kind: 'audio', mimeType: 'audio/PCMA', clockRate: 8000, channels: 1 } ];

这里有个关键点容易被忽视：channels必须写对。opus协商成2声道、PCMU固定1声道，如果你把PCMU的channels写成2，浏览器虽然也能协商成功，但实际收发时会出现解码器参数不匹配，表现就是单向无声或者噪声。之前有同事遇到过，查了半天结果就是这里多写了个2。

音频流里还有一类特殊的RTP流叫RED（Redundant Encoding），它把opus的多个冗余版本打包进一个RTP流里，PT通常协商为63。mediasoup对RED的支持在audio方向是可选的——实际上如果你配置了RED，浏览器发送端会同时建立一条去往RED SSRC的流和一条普通opus SSRC的流，接收端根据丢包情况从RED包里恢复数据。不过在绝大多数纯WebRTC场景下，音频走opus + inband FEC就够了，RED的收益不明显，还平白增加带宽开销。

2.2 视频RTP流：VP8/VP9/H264/H265/AV1的支持现状

视频编码这边，mediasoup的官方配置默认开VP8，几乎所有浏览器都能兼容。VP9在Chromium系支持不错，H264则需要看浏览器授权情况。值得注意的是，H265和AV1在mediasoup代码里是允许注册的，但浏览器端的支持情况差异极大。

各编码的关键参数如下表，这是我在rtpCapabilities里实际用过的配置：

H264的profile-level-id是必须认真对待的。比如浏览器是Chrome，通常协商的是profile-level-id=42001f（Constrained Baseline），但你服务端声明成640c1f（High Profile），浏览器过滤后会拒绝这个codec，表现为视频始终没有流上来。我踩过这个坑，那次是设备厂商要求High Profile，服务端和端侧对不齐，最后统一在能力集里写Baseline才解决。

视频流的rtpParameters里另一个高频字段是video/VP8的x-google-start-bitrate这类扩展参数。有些传输优化场景，你会希望服务端在转发时给消费端指定一个初始码率，这个值可以直接写在Consumer的params里，不需要在全局rtpCapabilities中声明。

2.3 PT与SSRC：别被抓包里的数字吓到

很多新手用Wireshark抓RTP包时，看到一堆不同的PT值会很懵：明明只推了一路视频，为什么PT有96又有97？其实96是VP8媒体流，97通常是对应RTX流的动态PT。而且这个PT值不是固定的，浏览器每次协商都可能不同，取决于SDP的m-line排序和rtpmap声明。

当你在mediasoup服务端通过producer.rtpParameters打印信息时，会看到类似这样的结构：

{ "codecs": [ { "mimeType": "video/VP8", "payloadType": 96, "clockRate": 90000, "rtcpFeedback": [] } ], "encodings": [ { "ssrc": 12345678, "rtx": { "ssrc": 12345679 }, "rid": "r0" } ] }

媒体流的ssrc和RTX流的ssrc在这里是配对的。你在抓包里看到媒体SSRC=12345678、RTX SSRC=12345679，说明apt映射关系正常。如果RTX的SSRC和媒体SSRC没有规律，多半是客户端实现不规范，这种端在重传策略上经常出问题。

3. 可靠性流：RTX重传流的工作原理与排查要点

3.1 RTX为什么不能省

RTX（Retransmission）是WebRTC抗丢包的第一道防线。它本质上是把收到NACK请求的旧包，用另一种PT（和媒体PT不同，但通过apt关联）重新发送一份。RTX包的内容除了PT不同、SSRC不同，序列号空间也是独立的，接收端靠原始序列号和原始SSRC还原数据。

mediasoup作为SFU转发这些RTX包时，不只是"看到什么转什么"，而是在内部维护了一个RtpStreamRecv的丢包检测窗口。当它发现某个包序号缺失，会主动向上游（也就是浏览器发送端）发NACK，而不是等接收端反应。这个设计非常重要：SFU相当于替所有下游消费者做了统一的重传请求。

3.2 开启RTX需要满足的配置前提

RTX不是想开就开，需要同时满足三个条件：

1. 媒体编码的rtcpFeedback里有nack和nack pli。
2. rtpParameters.encodings里为每个媒体编码声明了rtx.ssrc。
3. 浏览器端的SDP协商成功，并且rtx payloadType在format list里。

第2条最容易漏。如果你是自己构造rtpParameters送进producer.connect，而encodings里只写了媒体ssrc、没写rtx，那服务端虽然能收媒体流，但永远不会产生RTX流。抓包表现为：有NACK请求发出，但没有RTX包回应。

正确构造的encodings长这样：

encodings: [ { ssrc: 11111111, rtx: { ssrc: 11111112 }, maxBitrate: 500000 } ]

rtx对象里还有个可选字段payloadType，正常协商里不需要手动指定，因为服务端在codecs数组里已经通过rtx的关联声明过了。你只要保证ssrc配对正确即可。

3.3 实测感受：RTX对弱网体验的提升

我做过一次对比实验：同一网络环境下，A路开启RTX，B路关闭RTX，人为丢包率10%。A路的视频能明显看到短暂卡顿后快速恢复，画面虽然有几帧不连续但不会花屏；B路则直接大面积花屏，持续好几秒。这个差异在视频会议这种交互场景里是决定性的。

RTX的代价是带宽浪费——重传包的数据量和原始负载相同，丢包率越高浪费越大。所以生产环境里一般会配合maxRetransmits限制重传次数，或者通过Transport的rtcpMux、iceState变化做自适应判断。mediasoup没有提供直接限制RTX发包数量的API，但你可以控制Consumer端发送NACK的频率，或者在接收端上层的播放器里做抗丢帧策略。这里要强调的是：别指望RTX解决所有丢包问题，它在5%以内的随机丢包表现很好，一旦丢包率超过10%且是突发性丢包，RTX就会力不从心，这时候得靠FEC了。

4. 纠错流：FEC与音频冗余包的取舍细节

4.1 mediasoup对FlexFEC的真实支持度

FEC（前向纠错）的思路是发送冗余的校验包，接收端即使丢失部分RTP包，也能通过校验包和收到的其他包重建原始数据。这比RTX的往返等待快得多，但代价是持续占用带宽。

在WebRTC生态里，视频FEC主要走FlexFEC（RFC 8627）。不过老实说，mediasoup对FlexFEC的支持很有限：它能识别并转发FlexFEC包，但自身不会主动生成FlexFEC包。也就是说，如果浏览器发送端开了FlexFEC，mediasoup可以正确把这部分RTP流转发到订阅端，甚至能在某些丢包场景下利用收到的FlexFEC包重建数据再转发。但如果你希望mediasoup自己补偿丢包，它做不到——它不是一个FEC编码器，只是包转发器。

这句话翻译成白话就是：你想靠mediasoup的配置文件开启FEC功能，其实是没有直观开关的，得靠浏览器端是否协商FlexFEC来决定。

4.2 音频的RED冗余：一开一关的权衡

音频方向对应的FEC实现是RED + Opus的useinbandfec。Opus自带的inband FEC是把冗余信息藏在码流里，不需要额外RTP流；而RED是包装多层冗余数据，需要独立的RTP流和SSRC。

我实际测试过开启RED后的效果：在5%丢包率下，开启RED的音频几乎无感；关闭RED的音频出现轻微断续。但RED带来的额外码率开销大约在20%-30%，对于纯语音会议这种低码率场景可以接受，但如果音乐类直播同时推多路流，这个开销就要谨慎了。

配置RED的方式是在mediaCodecs里追加：

{ kind: 'audio', mimeType: 'audio/red', clockRate: 48000, channels: 2 }

注意顺序：audio/red要排在audio/opus之前，这会影响SDP里rtpmap的payload type分配顺序。顺序写反了，有些浏览器会协商出奇怪的PT值，导致无法解码。

4.3 我为什么最终放弃了服务端FEC增强方案

早期我想过在mediasoup后面加一层FEC代理，拿收到的RTP流自己做冗余编码再推给弱网观众。方向是可行的，但工程复杂度远超预期：FEC需要维护独立的SSRC映射、序列号映射、PT映射，还要处理RED与FlexFEC共存的优先级关系，在SFU多层转发链路里很容易搞乱链路状态。

后来我换了个思路：与其在服务端做FEC，不如在推流端的编码器上开FEC，同时接收端配合Range请求做容器级恢复。实践证明，这个方案的弱网表现更稳定，也更容易维护。

5. 分层与多路：Simulcast和SVC的RTP流组织

5.1 Simulcast多路RTP流在mediasoup中的路由方式

Simulcast的核心思想是：同一个视频源，同时编码出多路不同分辨率/码率的RTP流。推流端把这3路（通常3路）分别标记为rid: r0、r1、r2，每路有自己的SSRC、PT也可以相同。Mediasoup的Producer会同时接收这3路，并在内部为每路独立维护接收速率、丢包统计。

消费者的需求各不相同：大屏观众需要r2（高码率），小窗预览只需要r0（低码率）。因此mediasoup的Consumer在createConsumer时可以通过encodings指定需要哪几路，以及各路的目标码率上限。一个Consumer可以同时订阅多路（比如从r1切到r2时无感知），这就是流切换能平滑的原因。

我常用的Consumer创建参数示例：

const consumer = await transport.produce({ producerId: producer.id, rtpCapabilities: routerRtpCapabilities, paused: false, preferredLayers: { spatialLayer: 1, temporalLayer: 0 } });

preferredLayers是控制消费端初始层的——不写的话默认最高层，带宽不够时可能频繁回退。我习惯在信令里根据画面尺寸算一个初始层，比如小窗给spatialLayer=0。

5.2 SVC的流结构：比Simulcast更省带宽，但兼容性存疑

SVC（可伸缩视频编码）和Simulcast的最大区别是：它不需要多路独立编码，而是在单路码流里内嵌多个空间层和时间层。接收端可以根据带宽情况丢弃一些增强层包，解码器仍然能出画面，只是分辨率或帧率降低。

在mediasoup里，SVC是通过encodings[0].scalabilityMode来表达的。比如VP9常见的L3T3表示3个空间层+3个时间层，av1x的L3T3类似。这看起来比Simulcast更优雅，但实际落地有几个问题：

1. 浏览器对SVC的支持参差不齐，VP9的SVC在Chrome里需要硬件编码器支持，否则可能静默退化为单层。
2. mediasoup的Consumer层切换逻辑和preferredLayers虽然兼容SVC，但有些播放器内核（尤其Web端特定版本）对SVC包的解码兼容性不如Simulcast。
3. 在服务端做录制时，SVC流的处理比Simulcast困难：你得决定录哪一层，而Simulcast可以直接选一路完整流。

如果你面对的是通用用户群体，我建议先上Simulcast。SVC更适合你完全掌控编码器端的专业场景。

5.3 Consumer订阅多流的实际表现

我在一台2核2G的轻量服务器上跑过实测：1路Producer推Simulcast（3层），同时开8个Consumer分别订阅不同层。整体CPU占用和内存表现都在可接受范围。但当Consumer同时订阅多路时（比如r1和r2），带宽和CPU会明显上升，因为mediasoup内部要对每一路做独立的丢包重传统计。

这里有一个容易忽略的坑：Consumer的encodings数组长度和Producer的encodings数组长度不必相等，但每一路都必须对应到Producer真实存在的rid。如果你订阅了Producer不存在的rid，Consumer会一直处于等待状态，表现为拉流方一直黑屏，日志里默默输出no suitable stream之类的提示。排查方向就是打印producer.rtpParameters.encodings和consumer.rtpParameters.encodings逐一比对rid。

6. 特殊流类型：探测流与边界情况的处理

6.1 mediasoup的带宽探测流是怎么工作的

除了媒体、RTX、FEC之外，还有一类容易被忽略的RTP流——探测流（Probe Stream）。当消费者端带宽充足、跳层条件合适时，mediasoup会尝试通过发送一小段填充数据（Padding）来探测当前链路能否扛住更高的发送码率，探测成功后就把Consumer切换到更高层。

这段"探路"数据本质上也是一种RTP流，只不过负载可能是垃圾字节或者特定Padding扩展。它没有固定的SSRC含义，通常动态分配。你在抓包里看到短时出现、随后消失的陌生SSRC，很可能就是探测流在干活。

平时我们不需要手动配置探测流参数，但如果你发现Consumer经常在层之间震荡（一会儿720p一会儿360p），可以调整Consumer的maxSpatialLayer和maxTemporalLayer限制，或者下调producer的maxBitrate，让探测阈值更平滑。

6.2 静默流和暂停流：不传RTP但连接不断

还有一种边界情况：推流端暂时没有媒体数据（比如摄像头被遮挡或麦克风静音），但WebRTC连接还维持着。此时没有RTP媒体流，RTCP流还存在。mediasoup通过Producer的pause()和Consumer的pause()来处理这种状态。

如果你在producer.on('pause')里没有处理UI层逻辑，观众端就会一直显示最后一帧画面，容易被误判为卡死。我习惯的做法是：无论服务端收没收到暂态通知，都在应用层等2秒，如果还没媒体数据就主动提示"暂时无画面/无声音"。

6.3 对未知RTP流的安全策略

生产环境里偶尔会遇到异常客户端向服务端乱发RTP流的情况。mediasoup对未知SSRC的处理策略是忽略并记录日志，不会直接断连。这个设计很合理——避免一个异常包导致整个会话崩溃。但如果你发现一直接收到大量未知SSRC的RTP包，且都落在同一个Transport上，就要考虑是推流端的问题还是有人在探测你的服务行为。我遇到过某第三方SDK偷偷发送SVC扩展层的流但没在SDP里声明，导致服务端丢掉了那些包，画面清晰度始终上不去。这种问题的排查思路就是抓包看SSRC数量，再和服务端维护的SSRC白名单比对。

7. 验证与调试：如何确认当前会话用到了哪些流类型

7.1 用日志API快速识别流类型

mediasoup的调试信息非常丰富。把日志级别调到debug后，能看到每个流入的RTP包事件。比如打开DEBUG=mediasoup*再启动进程，会打出类似rtp stream with ssrc:1234, payloadType:96这样的日志。通过PT值就能判断是媒体流还是RTX流；通过encodings的rid能看到Simulcast路由状态。

7.2 用Wireshark抓包的实战思路

端到端排查时，我会在媒体服务器上用tcpdump抓包，过滤UDP端口，再导入Wireshark。几个高价值过滤条件：

• 通过rtp.ssrc跟踪某一路流。
• 通过rtp.payload_type区分媒体流与RTX流。
• 关注RTCP NACK类型包，统计哪些SSRC在频繁请求重传。

如果同一PT出现两个不同的SSRC，且其中一个SSRC的包负载看起来和前一个几乎一样，基本就是RTX流。如果看到RTX流存在、但丢包恢复效果不佳，下一步就去看接收端的rtp.sequenceNumber是否存在大段跳变——跳变说明有包丢失且未触发重传。

7.3 我常用的三种状态自检方法

• producer.rtpParameters.encodings：确认推流端的SSRC、rid、RTX配对是否齐全。
• consumer.rtpParameters.encodings：确认消费端订阅的层和路由。
• transport.getStats()：看总丢包率、发送码率、RTT，判断网络对当前流类型的影响。

这三板斧基本能覆盖绝大多数流类型相关的排查场景。

8. 踩坑实录：三例RTP流类型相关的线上问题复盘

8.1 案例一：RTX配对缺失导致弱网花屏

某次线上反馈某品牌安卓手机在视频会议里频繁花屏，其他设备正常。抓包发现，这款手机推流端没有建立RTX流，服务端发出的NACK全部石沉大海。进一步定位是客户端SDK的rtpParameters构造里只填了媒体SSRC，漏了rtx.ssrc。修复方式是升级该SDK，并让服务端在信令握手阶段做强校验：若encodings中媒体SSRC存在但rtx缺失，直接拒绝建流或在SDP层强制回退。回退策略比拒绝更友好，因为弱网下至少还能走完整媒体流。

8.2 案例二：Simulcast层切换导致短时黑屏

另一个项目里，观众端从小窗切换到大屏时，偶发黑屏1-2秒。排查发现Consumer的preferredLayers一直没有设置，服务端默认订阅最高层，而高层的分辨率和码率是动态变化的。切换时如果恰好遇到丢包，画面恢复需要重新等关键帧，就表现为黑屏。解决办法是在信令端根据观看窗口大小预计算spatialLayer，并且在消费端开启enableTcp等稳健传输参数。改完后切换基本无感。

8.3 案例三：RED配置顺序引发的音频编解码错乱

有一段时间线上反馈部分用户听不到对方声音，但视频正常。控制变量后发现，这些用户的浏览器在协商音频时选了RED PT而不是opus PT。原因就是我在mediaCodecs里把RED放在了opus前面，导致浏览器把RED当作首选。调整顺序后问题消失。这个教训我一直记着：PCMU/PCMA/RED这类兼容型编码的排序，直接决定了SDP的协商结果，不能想当然。

9. 给新手的配置清单与最终建议

配置RTP流类型时，记住这个最小清单：

• 音频：opus + inband FEC，满足绝大多数场景；不要激进配置RED。
• 视频：VP8 + Simulcast 三路，兼容性最好；若设备可控再考虑VP9/AV1。
• 重传：确保每个媒体SSRC都有对应RTX SSRC，这是弱网底线的保障。
• 分层：Consumer创建时明确preferredLayers，避免层切换瞬间黑屏。
• 调试：先看rtpParameters再抓包，先确认SSRC配对再查网络丢包。

我在实际开发中体会最深的一点是：RTP流类型不是一个"配置了就完事"的功能项，而是需要在整个项目周期里持续观察的动态属性。尤其是RTX和Simulcast，它们和网络状况、终端能力、编码器行为都强相关。建议你在功能上线前就建立一套流状态监控面板，把各路流的SSRC数、RTX命中率、层切换次数这些指标都打出来，省得以后线上出问题再去抓包复盘。

最后再分享一个小技巧：调试RTP流问题时，别急着上大流量模拟，先用单路固定码率、固定分辨率的方式跑通RTX和Simulcast全链路，确认SSRC配对无误后，再逐步加大并发和复杂度。这样排查问题的范围会小很多，也更容易积累出清晰的心智模型。