14、RTCP-MUX与RTP/RTCP复用：RTCP-MUX的SDP标记、减少端口占用的好处
聊到WebRTC的媒体协商，有个细节我每次都会被问到——RTCP-MUX。说白了，就是让RTP和RTCP走同一个端口。嗯，这事儿看起来简单，但坑不少。我最早接触这个特性是在做一款视频会议产品时，当时被端口不够用的问题折磨得够呛。后来才发现，RTCP-MUX就是那个救星。
为什么需要RTCP-MUX？
先想想传统RTP/RTCP是怎么工作的。RTP负责传音视频数据，RTCP负责传控制信息（比如丢包率、延迟、接收报告）。在传统SIP协议里，这两个流是分开的——RTP用一个端口，RTCP用下一个端口（RTP端口+1）。
举个例子：
- RTP用端口10000
- RTCP就用端口10001
这在单个通话时没问题。但WebRTC场景下，一个浏览器可能同时打开多个PeerConnection，每个连接又可能有多路媒体流（音频、视频、屏幕共享）。你想想看，端口消耗会多快？
核心问题：每个媒体流需要2个端口，N个流就需要2N个端口。在NAT穿透、防火墙策略严格的网络环境下，端口资源非常宝贵。
RTCP-MUX的SDP标记
RTCP-MUX的协商是通过SDP中的rtcp-mux属性完成的。我记得第一次看RFC 5761时，觉得这个设计很优雅——不需要额外信令，只需在SDP里加一行标记。
SDP中的标记方式：
// Offer端
a=rtcp-mux
// Answer端
a=rtcp-mux
就这么简单。但要注意，这是端到端的协商。Offer端声明支持，Answer端如果也支持，就在回复中带上同样的属性。如果Answer端不支持，那Offer端就得回退到传统模式——RTP和RTCP分端口。
我的习惯：在实现中，我会在创建Offer时默认带上a=rtcp-mux。如果Answer端不支持，再动态调整。这样可以最大化复用端口的概率。
RTCP-MUX在SDP中的完整示例
来看一个实际的SDP片段。这是一个支持RTCP-MUX的音频流：
m=audio 49170 UDP/TLS/RTP/SAVPF 111 0 8
c=IN IP4 192.168.1.100
a=rtcp-mux
a=rtcp:49170
a=mid:audio
a=sendrecv
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
注意看，m=行只声明了一个端口49170。而a=rtcp:49170明确告诉对方：RTCP也走这个端口。这就是复用的核心——RTP和RTCP共享同一个传输地址（IP+端口）。
减少端口占用的好处
好处其实很明显，我归纳为三点：
- 端口节省50%——每个媒体流从2个端口降到1个端口。如果你有3路流（音频+视频+屏幕共享），原来需要6个端口，现在只要3个。
- NAT穿透更容易——少一个端口，就少一次NAT映射。防火墙策略也更好配置。我在项目中遇到过，有些企业防火墙只开放了有限的UDP端口范围，RTCP-MUX直接让可用流数量翻倍。
- ICE候选者减少——每个媒体流只需要收集一组候选者（而不是两组），ICE连通性检查的复杂度也降低了。
曾经踩过的坑：有一次我忘了在Answer端检查a=rtcp-mux，直接默认对方支持。结果对方是老旧的SIP网关，不支持复用。RTP和RTCP都挤在一个端口上，RTCP包被当成RTP包解析，导致解码器崩溃。嗯，从那以后我养成了习惯——一定要在收到Answer后校验rtcp-mux协商结果。
RTCP-MUX的协商流程
我画了一张图，帮你理清整个协商过程：
实现中的注意事项
RTCP-MUX虽然好，但实现时有几个细节不能忽略：
- 复用后的包区分——RTP和RTCP都走同一个端口，接收端怎么区分？靠的是payload type和包类型。RTP包的PT范围是96-127，RTCP包有固定的类型值（如SR=200, RR=201）。实现时一定要正确解析。
- ICE与RTCP-MUX的交互——ICE候选者收集时，如果启用了RTCP-MUX，只需要为每个媒体流收集一组候选者。但要注意，ICE的
ufrag和pwd仍然是共享的。 - 兼容性处理——不是所有终端都支持RTCP-MUX。我建议在Offer中总是声明支持，但Answer端如果不支持，要能优雅降级。
避坑指南：我曾经在一个跨平台项目中，Android端支持RTCP-MUX，但iOS端某个旧版本不支持。结果Android端一直收不到RTCP包，以为是网络问题。排查了半天才发现是协商失败。后来我加了个日志——每次协商完都打印rtcp-mux状态，问题一目了然。
总结
RTCP-MUX不是什么黑科技，但它解决了一个很实际的问题——端口不够用。在WebRTC这种多流、多连接的场景下，端口复用几乎是必须的。SDP里加一行a=rtcp-mux，就能省下一半的端口，何乐而不为？
嗯，如果你正在做WebRTC的媒体协商，记得把这个特性加上。它不会让你的音视频质量变好，但能让你的系统更稳定、更易部署。这就是工程中的“小优化，大收益”。
公众号:蓝海资料掘金营，微信deep3321