口干舌燥喝水不解渴？从津液代谢到中医调理的实操思路
2026/10/21 7:24:37
写文章的时候要讲清楚一个核心前提：MediaSoup 本身并不是 SDP 的解析者，它更像一个“画好地盘等你进场”的媒体系。所有 Offer/Answer 的构造、解析、协商状态机，最终还是要靠你的信令服务、客户端 SDK 和浏览器来共同完成。搞懂这一层，后面那些 SDP 字段才真正有了意义。
先回到最基础的问题：我们常说的“MediaSoup 的 SDP 协商”，到底指的是什么？是 MediaSoup 自带的“SDP 协议栈”？不是。更准确的说法是：在 MediaSoup 的 SFU 架构下，客户端和服务端之间如何完成一次标准的 WebRTC Offer/Answer 交换。MediaSoup 服务端会给你一组传输参数，你要靠这些参数拼出合法的 SDP，发出去，再把对方的 Answer 收回来核对。这中间任何一个字段对不上，媒体就起不来。
1. SDP协商到底是什么：先搞懂WebRTC的握手协议
1.1 Offer/Answer模型和三个核心能力
WebRTC 的 SDP 协商走的是 RFC 3264 定义的 Offer/Answer 模型。通俗点说：发起方把自己的媒体能力、通信参数写进一份 Offer，对方收到后，根据自己的能力和 Offer 里的约束条件，生成一份 Answer 回复。Offer 和 Answer 最终描述的是“两边接下来要用什么协议、通过哪条路、传哪些格式的媒体”。
一份典型的 SDP 里，真正决定媒体链路能不能通的其实是三样东西：
- ICE 参数：
ice-ufrag和ice-pwd，用来做连通性检测。ICE 负责解决“数据走哪条路”的问题。 - DTLS 参数：
fingerprint和setup属性，fingerprint表示 DTLS 证书的哈希指纹，setup表示谁是主动方、谁是被动方。DTLS 负责给 RTP 包做加密和身份认证。 - 媒体描述：以
m=开头的行，描述媒体类型、端口、协议、编解码格式。同时还会带上mid、ssrc、rid、simulcast、rtcp-fb这类扩展字段。
很多新手有个直觉误区：WebRTC 整个协商过程只要“能听到声音、看到画面”就算成功。实际上，声音画面只是最后一步的结果。ICE 一旦失败，连 UDP 通道都打不通；DTLS 失败，就算通道通了，媒体包也会因为无法解密被丢弃。SDP 里每一行都是在给后续的 RTP/RTCP 流程定规矩，少一个rtcp-fb: nack，视频卡顿时的丢包重传就少一条生路。
1.2 为什么MediaSoup不参与端到端加密，却绕不开SDP
MediaSoup 是一个纯 SFU（Selective Forwarding Unit），它做的工作是“选择性转发”：从一个发布者那里收到 RTP 包，决定要不要转发给哪些订阅者。它不会对 RTP 内容做任何修改，也就不可能解出里面的明文媒体数据。端到端加密（也就是 DTLS-SRTP 说的那个加密）是浏览器到 MediaSoup 之间建立的，MediaSoup 只持有 SRTP 会话的密钥，并不关心视频画面本身。
但正因为媒体面上要转发 RTP，MediaSoup 必须知道几件事：
- 每个 RTP 包属于哪条流？靠
SSRC和MID区分。 - 每条流用的是什么编码、什么负载类型？靠 SDP 里的
rtpmap判断。 - 发布者声明了哪些 Simulcast 层？每个层级的
RID是什么？转发时要不要选择性丢弃？ - 订阅者想要的是正常画质还是低清晰度？靠
simulcast属性里的方向语义来协调。
这些东西全是靠 SDP 协商带出来的。只要有一份 SDP 描述得不准确，MediaSoup 可能能转发数据，但客户端接收端会对不上号，于是出现“有流量、黑屏、没有声音”的经典症状。
1.3 MediaSoup在协商里的真实角色：它不是端点
理解 MediaSoup 的 SDP 协商，必须先放下“它是服务器端”这个惯性思维。在 WebRTC 的协商模型里，MediaSoup 本身不发起 Offer，也不生成 Answer（除非你手动写代码构造）。它做的事情更像“提供协商所需的素材”：
服务端创建WebRtcTransport时，MediaSoup 会生成随机的iceParameters（包含ufrag、pwd）和dtlsParameters（包含本端指纹、角色、设置）。你的应用层拿到这些参数后，要么把它传给mediasoup-client这样的库帮你生成客户端 SDP，要么自己在代码里拼 SDP。然后通过信令把 Offer / Answer 在两端之间来回传递。
所以，当你听到别人说“MediaSoup 的 SDP 协商有问题”时，其实是在说“基于 MediaSoup 参数构造的 SDP，在客户端侧没有通过浏览器的合法校验”，或者“MediaSoup 服务端在connect()/produce()阶段没有收到它期望的 DTLS / RTP 信息”。搞清这个责任边界，排错时就不会一头扎进服务端源码里。
2. MediaSoup与SDP协商的关键设计：为什么你发的offer和浏览器不太一样
2.1 Transport的创建：ICE/DTLS参数从哪来
在 MediaSoup v3 里，所有媒体都跑在WebRtcTransport上。这个 Transport 对应浏览器端的一个RTCPeerConnection，但你千万不能把它理解成一条直接的 socket，它是 MediaSoup 内部管理 ICE、DTLS、RTP 会话的容器。
创建 Transport 的典型流程是这样的：
- 客户端通过信令通知服务端“我想加入房间”。
- 服务端调用
webRtcTransport.create()，返回一个包含iceParameters、dtlsParameters、sctpParameters等字段的 JSON。 - 客户端拿到这些字段，用它来初始化自己的
RTCPeerConnection。如果用mediasoup-client，它会自动把这些字段封装进内部 SDP 生成逻辑；如果手写，就需要把它们塞进 SDP 对应位置。
这里有个容易忽略的点：MediaSoup 返回的iceParameters里的ufrag和pwd，是服务端 ICE 凭证。而浏览器生成的 SDP 里也会有自己的ice-ufrag和ice-pwd。两边各自使用自己的凭证，协商时互相比对的是 ICE 候选和 DTLS 指纹，不是比对ufrag是否相同。
手写协商时常见的一个错误：有人尝试把 MediaSoup 返回的ufrag直接写到本地 SDP 里。这会导致浏览器用错误的 ICE 凭证发起检测，连接永远停留在checking状态。正确做法是：ufrag、pwd是服务端身份信息，浏览器的 SDP 里应该写浏览器自己生成的凭证。
2.2 MediaSoup的SDP生成策略：服务端生成或客户端生成
在 MediaSoup 体系里，有两条常见的协商路径，取决于你用的是哪类客户端 SDK：
- 客户端构造 Offer / 响应 Answer：这是主流方式。
mediasoup-client在收到服务端传输参数后，会监听本地RTCPeerConnection的negotiationneeded事件，然后生成 Offer；或者直接调用pc.createOffer()，最后把 Offer 通过信令发给服务端。服务端不做 SDP 解析，只做connect()和produce()。 - 服务端拼好完整的 SDP 传给客户端：这种方式适合某些不能直接暴露
RTCPeerConnection细节的环境（比如部分小程序、特定嵌入式客户端）。服务端要把m=、a=mid、a=ice-ufrag等字段全部手写出来，再让客户端加载。这条路坑最多，因为 SDP 里任何一个标点出错浏览器都不认。
实际开发中，只要环境允许，绝大多数人都会选择mediasoup-client。原因很简单：WebRTC 的 SDP 格式至今仍然相当脆弱，空格、换行、attribute 顺序都会影响兼容性，手写等于把浏览器几十个版本的兼容性包袱都揽到自己头上。
2.3 mid、SSRC、RID这些字段到底谁说了算
协商时，SDP 里有几个“身份”字段需要特别关注：
- mid：媒体行的唯一标识，MediaSoup 在
produce()时把客户端发送的 RTP 包的MID扩展字段和本地 Transport 关联起来。如果你手动改 SDP 里的 mid，必须让 RTP 包里的 MID 扩展值和它一致，否则 MediaSoup 无法把包路由到正确的 Producer。 - SSRC：RTP 包的同步源标识。一般而言，发送端的 SSRC 由发送方自己决定，MediaSoup 不会去改它。但在 Simulcast 和 RTX 场景下，一个视频流会有多个 SSRC，分布在 SDP 的多个
a=ssrc行里。 - RID：Simulcast 里标识不同层的名字，比如
f表示完整分辨率、h表示半分辨率、q表示四分之一分辨率。RID 必须注册在 SDP 的a=rid属性中，同时启用 RTP Header Extensionurn:ietf:params:rtp-hdrext:sdes:rid，否则接收端无法解析层信息。
这些字段不是 MediaSoup 服务端“指定的”，而是 SDP 协商的“产物”。MediaSoup 要做的，是把 RTP 包里实际携带的信息和 SDP 中声明的信息对上号。一旦两者不一致，媒体流就会出现在错误的状态——Producer 看起来有数据，Consumer 却什么都收不到。
3. 手写一次MediaSoup SDP协商：从Transport参数到可播放的流
3.1 步骤拆解：创建Transport → 准备SDP → 交换Offer/Answer
完整的流程通常可以拆成五个阶段：
- 创建 Transport：服务端创建
WebRtcTransport，拿到iceParameters、dtlsParameters。 - 客户端初始化：客户端创建
RTCPeerConnection，把服务端参数注入（实际是让mediasoup-client通过transport.send()发出某种 signal）。 - 生成 Offer 并发送：客户端触发
createOffer()，带上sendRecv或sendonly等方向。 - 服务端响应：服务端调用
transport.connect()，收到客户端的 DTLS 指纹和 ICE 参数；如果客户端发的是 Offer，服务端需要生成一个 Answer 回给客户端。通常mediasoup-client的transport.answer()会处理这件事。 - 建立媒体：DTLS 握手完成后，调用
transport.produce()/transport.consume()，把 RTP 包和 Consumer 关联起来。
之所以把这五步分开，是为了在排查时能准确判断故障落在哪个阶段。
3.2 一个可参考的协商流程示例（伪代码/信令时序）
下面用伪代码描述一个简化场景：客户端 A 发布视频，客户端 B 订阅视频。
// 服务端：创建传输 const transport = await worker.createWebRtcTransport({ listenIps: [{ ip: "0.0.0.0", announcedIp: "x.x.x.x" }], enableUdp: true, enableTcp: true, preferUdp: true, }); // 返回给客户端的初始参数 const serverParams = { iceParameters: transport.iceParameters, dtlsParameters: transport.dtlsParameters, };客户端拿到serverParams后，用mediasoup-client的device.load()初始化：
// 客户端（A 发布端） await device.load({ routerRtpCapabilities }); const transport = device.createSendTransport({ id: serverParams.transportId, iceParameters: serverParams.iceParameters, dtlsParameters: serverParams.dtlsParameters, });然后监听传输的connect和produce事件：
transport.on("connect", ({ dtlsParameters }, callback, errback) => { // 通过信令把客户端的 DTLS 参数发给服务端 signaling.send({ type: "connect", dtlsParameters }) .then(callback) .catch(errback); }); transport.on("produce", ({ kind, rtpParameters }, callback, errback) => { signaling.send({ type: "produce", kind, rtpParameters }) .then((id) => callback({ id })) .catch(errback); });紧接着用getUserMedia()拿本地流，调用transport.produce()。mediasoup-client会在内部触发一次重新协商，自动发送 SDP Offer。服务端收到后，调用transport.connect()保存 DTLS 指纹，再调用transport.produce()创建 Producer，并通过信令把 Producer ID 返回客户端。
订阅端 B 的流程类似，但用的是createRecvTransport()和transport.consume()。客户端 B 收到服务端发来的rtpParameters后，需要通过pc.setRemoteDescription()配合pc.addTrack()把接收到的流播放出来。
3.3 关键参数对照表：SDP中必须与MediaSoup参数一致的项
下面是手写 SDP 时必须仔细核对的字段对照：
| SDP 字段 | 用途 | 必须一致的项 |
|---|---|---|
a=ice-ufrag/a=ice-pwd | ICE 连通性检测凭证 | 不能把 MediaSoup 的凭证抄到本地 Offer 里 |
a=fingerprint | DTLS 证书指纹 | 客户端指纹必须通过信令传给 MediaSoup 并调用connect() |
a=setup | DTLS 角色 | active/passive/actpass要匹配 |
a=mid | 媒体标识 | 必须与 RTP 包中的 MID 扩展值一致 |
a=ssrc | RTP 同步源 | Simulcast 场景要列出所有 SSRC |
a=rid | Simulcast 层名称 | 必须与a=simulcast声明一致 |
a=extmap | RTP Header Extension | 例如mid、rid、abs-send-time的 ID 要和协商一致 |
提示：使用
mediasoup-client时，这些字段会自动生成，你基本不用手动核对。但当你遇到“黑屏但有音频”“能推流但别人看不到”的问题时，对照这张表去查，往往比瞎调编码快得多。
4. Simulcast、RTX与SDP协商：MediaSoup场景下最容易翻车的点
4.1 Simulcast在SDP里的表达方式：RID与simulcast属性
Simulcast 是视频会议里很常用的能力：发布端编码出多个分辨率的流，SFU 根据每个订阅者的带宽和屏幕大小决定转发哪一层。放到 SDP 里，它长这样：
a=rid:f send a=rid:h send a=rid:q send a=simulcast:send f;h;q意思是我要发送三条 RID 分别为f、h、q的流。接收方的 Answer 里可能这样回应：
a=simulcast:recv f;h;q如果接收方只想收最高层，也可以写成a=simulcast:recv f，但这个决定权并不总在 SDP 阶段。MediaSoup 的 Simulcast 转发决策是动态的，它根据 Consumer 的preferredLayers、targetLayers以及内部带宽估算来决定转发哪一层。SDP 里的 simulcast 属性只是告诉我们每一层存在，并不负责实时切换。
4.2 RTX、FEC这些扩展能力的协商
RTX（Retransmission）用于丢包重传，FEC（前向纠错）用于冗余恢复。SDP 里通常在媒体行下加：
a=rtpmap:96 rtx/90000 a=fmtp:96 apt=98其中apt=98表示 RTX 对应的是负载类型 98 的原始流。MediaSoup 支持处理 RTX 包，但它不主动重传，真正请求重传的是接收端发起的 RTCP NACK。也就是说，协商时报了 RTX 能力，实际重传行为却是在媒体包传输过程中按需触发的。
很多开发者会在客户端禁用 RTX，理由是“SFU 本来就是转发，要重传干嘛”。但 MediaSoup 场景下禁用 RTX 可能反而导致体验变差：当某条链路发生随机丢包时，没有 RTX 就无法补包，接收端只能自行插值，画面会出现撕裂或停顿。除非你的应用对延迟极度敏感，否则建议保留 RTX。
4.3 收到多个编码层后，MediaSoup怎么“选择转发”
MediaSoup 的转发决策并不在 SDP 协商阶段完成，而是在 Consumer 创建后持续调整。流程是：
- 发布者的 SDP 声明了多个 Simulcast 层，
produce()成功。 - 订阅者创建 Consumer，服务端会告诉订阅者“我已经看到若干层可用”，并记录当前默认层。
- 某个时刻，服务端根据订阅者的可用带宽（通过 REMB / Transport CC 反馈估算）以及
preferredLayers设置，切换实际转发的 RTP 流。
这里有个常见误解：以为只要 SDP 里写了 Simulcast，浏览器就会同时发送多层。实际上，浏览器是否真正编码多层，受限于机器性能、编码器能力和 page 里的 setParameters 调用。如果发布端只编码了一层，SDP 里声明了三层，那么 MediaSoup 虽然能识别出三层声明，但实际收到的流里可能只有一层。这时候查问题，先去看发布端的编码器状态，而不是盯着 SDP。
5. 常见问题与排查技巧：协商失败时先看这五个地方
5.1 症状、原因、解决方案表
实际踩坑经验里，下面这些现象出现频率最高，我把它们整理成速查表：
| 症状 | 可能原因 | 处理方式 |
|---|---|---|
| ICE 一直 checking，最后 timeout | 本地 SDP 的 ufrag/pwd 抄错；没有收集到候选 | 删除手写的 ICE 凭证，改用浏览器自动生成 |
| DTLS 握手失败，transport 停在 connecting | fingerprint 不匹配；setup 角色设置冲突 | 通过信令把客户端 DTLS 参数完整传给服务端并connect()；确认setup是actpass或主动方一致 |
| 音频正常，视频黑屏 | Simulcast 层声明与编码器设置不符；RID Header Extension 未启用 | 检查a=extmap里是否有sdes:rid；查看发布端 getParameters 的 encodings 配置 |
| 发布成功，但订阅端无流 | SDP 方向不对，Consumer 创建时用了错误的recvonly声明 | 检查 SDP 里的方向属性，确认订阅端声明的是recvonly而发布端是sendonly |
| 视频起播慢，频繁卡顿 | RTX 未协商；Transport 带宽估计不准 | 在 SDP 中确认rtcp-fbNACK 和 RTX 负载存在；开启Transport-cc |
| Producer 状态显示 connected，但 RTP 包没进入 | 客户端produce()时 rtpParameters 里没带 mid；SSRC 与 SDP 不一致 | 检查rtpParameters.mid是否与服务端mid对应 |
5.2 在线排查工具和日志姿势：别盯着JS控制台干瞪眼
很多人在 MediaSoup 调试时不停刷新 JS 页面，看控制台报错。这当然有用，但 WebRTC 的很多错误根本不会暴露给 JS。推荐几个更直接的排查姿势：
- 浏览器内置的 WebRTC 统计页：输入
chrome://webrtc-internals（对应 Chromium 内核的浏览器都有），可以看到完整的 SDP 变化历史、ICE 候选对、DTLS 状态、RTP 包收发统计和丢包率。这里能直观看到“Offer 里声明的 rid 到底有没有被 Answer 接受”。 - 抓包 SDP：在 DevTools 的 Network 面板里，过滤
type=sdp或直接看信令请求体。手写 SDP 时最容易出错的往往是空格和换行，对照官方 RFC 逐行检查。 - 开启 MediaSoup 的 debug 日志：通过
mediasoup的 logger 模块设置DEBUG=mediasoup:*或在配置里开启worker日志级别，可以看到transport.connect()和produce()时收到的参数细节，很多问题在服务端日志里一眼就能定位。
特别提醒：不要同时依赖多个工具去猜一个问题。先把 SDP 交换链路理顺——谁生成的 Offer、谁回应的 Answer、每一步信令是否完整到达——然后再去看统计面板。很多时候问题不是 SDP 格式坏了，而是信令层把某个参数漏传了。
6. 我对MediaSoup SDP协商的几点体会
如果问我做 MediaSoup 集成的过程中最想提醒后来人一句什么，我会说：永远把 “媒体参数” 和 “信令传输” 责任分清楚。MediaSoup 给你的只是一堆参数，它不会帮你保证“浏览器发的 Offer 一定合法”。在客户端把device.load()那一步的routerRtpCapabilities和服务端实际能力对齐，后面再出问题，八成在 SDP 细节里。
我个人踩过最深的一个坑，是手写 SDP 时把a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid的 ID 写成了 2，导致 MediaSoup 收到 RTP 包时无法解析出 MID，Producer 建了但一个包都收不进去。这种问题从 JS 控制台完全看不出来，只有抓包看 RTP 扩展头才能发现。从那以后，我给自己定了个规矩：凡是能交给mediasoup-client生成 SDP 的场景，绝不手写。
如果你是在维护一个非浏览器客户端（比如原生 App 或嵌入式设备），那就更需要一份完整的 SDP 构造参考文档。建议把mid、rid、ssrc、ice-ufrag、fingerprint这几个字段的关系图先画清楚，再动手写实现。至少这样，每一条 SDP 出错时，你知道该去查哪一侧的代码。
最后分享一个小技巧：把服务端的router.rtpCapabilities缓存起来，通过信令下发给客户端时别每次都现取。因为客户端device.load()用的是这份能力声明，里面包含了你支持的编解码、RTP Header Extension、FEC 等完整信息。一旦这份声明在某个版本升级后发生变化，旧客户端就会带着过期能力去协商，此时就算 SDP 本身完全正确，也会因为能力不匹配而在媒体面出怪问题。提前固化并做版本管理，能少踩很多莫名其妙的坑。