4. RTP会话与传输层

RTP本身只定义了媒体数据的封装格式与时间戳、序列号等同步机制，它并不负责把包送到对端。真正决定“能不能通、延迟多高、丢包怎么办、是否加密”的，是RTP所依赖的传输层与安全层组合。理解RTP over UDP、TCP、TLS、SRTP的差异，是排查“有信令无媒体”“单向无声”“卡顿抖动”等问题的第一道分水岭。

一、四种承载方式的本质差异

RTP最常见的承载是UDP。UDP不重传、不排序、不拥塞控制，正好契合实时媒体“宁可丢一帧，不可等一秒”的需求。RTP在UDP之上通过序列号检测丢包、通过时间戳重建播放节奏，再配合RTCP反馈丢包率与抖动，形成完整的实时传输闭环。

RTP over TCP则把RTP包直接放进TCP字节流。TCP保证可靠有序，但代价是队头阻塞：一个包丢失，后续所有包都要等待重传，延迟瞬间抬升。因此TCP承载通常只用于信令、屏幕共享或网络严格限制UDP的场景，纯语音视频通话很少主动选择。

RTP over TLS是在TCP之上再加一层加密，即RTP先进入TLS记录层，再由TCP传输。它解决了TCP承载的明文问题，但队头阻塞依旧存在，且TLS握手与记录层开销会进一步增加延迟。

SRTP则是另一条路线：它不改变UDP承载，而是在RTP包结构上直接加密载荷并认证包头，同时用Srtp密钥与ROC（Rollover Counter）抵抗重放。SRTP是WebRTC、VoIP默认的媒体安全方案，兼顾低延迟与机密性。

二、端口分配：RTP与RTCP的成对规则

RTP会话通常成对出现：RTP用偶数端口，RTCP用相邻的奇数端口。例如RTP监听5004，RTCP就是5005。这个约定来自RFC 3550，虽然现代实现允许显式指定，但抓包时仍应优先按“偶RTP、奇RTCP”去识别。

端口分配有两种模式：静态分配与动态分配。静态分配常见于SIP网关、媒体服务器，端口固定便于防火墙放行；动态分配则从一段端口池中随机选取，例如10000–20000，WebRTC和多数SIP客户端都采用这种方式。动态分配提高了并发能力，却让NAT和防火墙配置更复杂。

# 典型RTP端口对
RTP  : 5004  (偶数)
RTCP : 5005  (奇数)

# 动态端口池示例
min_port = 10000
max_port = 20000
# 每个会话占用一对端口，实际并发数约为 (20000-10000)/2 = 5000

三、复用：同一端口承载多路媒体

当端口资源紧张或NAT映射数量受限时，会使用复用技术。常见的有RTP/RTCP复用（RFC 5761），即RTP和RTCP共用同一个端口，通过包类型区分；还有BUNDLE复用（WebRTC），把音频、视频、数据通道全部复用到同一个五元组上，只做一次NAT穿越，显著降低建连失败率。

复用带来的代价是解复用逻辑更复杂：接收端必须根据SSRC、payload type和包类型正确分流，否则会出现“音频串到视频”“RTCP被当成RTP”等异常。

四、NAT穿越基础：为什么媒体总是“连不上”

NAT让内网主机共享公网IP，但也破坏了RTP的端到端可达性。RTP包从内网发出时，NAT会建立映射，但外部主动发来的包若没有对应映射，就会被丢弃。因此RTP会话必须借助STUN、TURN、ICE来完成地址发现与连通性检查。

• STUN：客户端向STUN服务器发请求，获知自己的公网映射地址，即srflx候选。
• TURN：当直连失败时，通过中继服务器转发RTP，保证连通但增加延迟与带宽成本。
• ICE：收集host、srflx、relay候选，按优先级配对并做连通性检查，选出最优路径。

五、对比清单与选型建议

六、常见误区与复盘

复盘一个典型故障：某视频会议出现单向无声。抓包发现SDP中RTP端口为偶数，但防火墙只放行了该端口，未放行相邻的RTCP端口，导致RTCP Receiver Report无法回传，发送端误判链路良好而持续高码率，最终拥塞丢包。修复方式是同时放行RTP/RTCP端口对，或在SDP中启用rtcp-mux复用同一端口。

选型时记住一条主线：实时优先选UDP，安全优先在UDP上加SRTP，NAT复杂时用ICE+BUNDLE减少端口映射，TCP/TLS只作为受限网络的最后手段。把这条主线与端口分配、复用策略、NAT穿越结合起来，才能让RTP会话既通得快，又稳得住。