4. RTP/RTCP协议基础
各位同学好，我是老周。今天咱们聊聊RTP和RTCP这两个协议。说实话，我在做IMS信令分析的头两年，对媒体这块一直有点发怵。总觉得SIP信令才是核心，媒体流嘛，能通就行。直到有一次排查一个视频通话卡顿的问题，抓了包一看，RTP时间戳乱跳，RTCP的丢包率报表惨不忍睹——这才意识到，不懂媒体协议，你连问题出在哪都说不清楚。
所以这一章，咱们把RTP和RTCP的基础打牢。你想想看，IMS里所有的语音、视频、彩信，最终都要靠这两个协议来承载。搞不懂它们，逆向分析就缺了一条腿。
4.1 RTP协议概述
RTP，全称Real-time Transport Protocol，实时传输协议。它跑在UDP上面，专门用来传输音视频数据。
为什么不用TCP？因为实时通信最怕延迟。TCP丢包重传那一套，在语音通话里根本等不起。你这边重传一个包，那边话音已经断了半秒，用户早骂娘了。
RTP本身不保证服务质量，它只负责把媒体数据打包、加上时间戳和序号，然后扔到网络上。至于丢包、乱序、抖动这些问题，它不管。那谁管？RTCP管。咱们后面再说。
我个人习惯把RTP看作一个「快递员」。它把媒体数据装进一个个包裹，贴上标签（头部），然后送出去。至于包裹有没有丢、送得快不快，那是另一个部门（RTCP）的事。
4.2 RTP头部结构
RTP头部是固定12字节。别小看这12个字节，里面信息量很大。我直接给你画个结构图，比干讲强。
我来拆解一下这几个关键字段：
- 版本号（V）：目前是2。我记得早期有些设备还在用版本1，抓包时看到版本号不对，直接就能判断是老旧设备。
- 载荷类型（PT）：这个字段告诉接收方，你收到的数据是什么编码格式。比如PT=0是PCMU语音，PT=96通常是H264视频。我在项目中遇到过，有些厂商自定义PT值，导致解码器不识别，画面直接花屏。
- 序列号：每个RTP包递增1。接收方靠它来检测丢包和乱序。我曾经排查过一个丢包问题，发现序列号跳了100多，但RTCP报告里丢包率才0.5%——明显是统计口径有问题。
- 时间戳：这个容易搞混。它不是绝对时间，而是采样时刻的时钟计数。语音通常用8000Hz时钟，视频用90000Hz。为什么视频用这么高？因为要精确到帧级别，90000Hz能分辨出1/90000秒的差异。
- SSRC：同步源标识，每个RTP流唯一。同一个通话里，语音流和视频流的SSRC不同。我在逆向分析时，经常靠SSRC来区分不同的媒体流。
重点提醒：RTP头部没有「源IP」和「目的IP」字段。这些信息在IP层已经有了，RTP只关心媒体本身。所以抓包时，你得结合IP层和UDP层一起看，才能完整还原一个RTP流。
4.3 RTCP协议概述
RTCP，Real-time Transport Control Protocol，实时传输控制协议。它和RTP是一对搭档。RTP负责运货，RTCP负责汇报路况。
RTCP周期性地在会话中发送控制报文。它主要干三件事：
- 服务质量监控：统计丢包率、抖动、往返时延。这些数据对排查问题太重要了。
- 媒体流同步：通过RTCP里的NTP时间戳和RTP时间戳的映射关系，接收方可以把音频和视频对齐。你想想看，如果没有这个同步机制，视频里嘴型和声音就对不上了。
- 会话管理：比如参与者信息、会话结束通知等。
RTCP的带宽通常控制在会话总带宽的5%以内。别小看这5%，在带宽紧张的场景下，RTCP报文本身也会造成拥塞。我调过一些嵌入式设备，RTCP发送间隔设得太短，结果控制报文占了不少带宽，反而影响了媒体质量。
我的经验：在逆向分析时，我习惯先看RTCP的丢包率。如果丢包率超过5%，基本可以断定网络有问题。如果丢包率很低但通话质量差，那就要看抖动和时延了。有一次我排查一个跨国通话问题，丢包率只有0.1%，但抖动高达200ms——原因是路由绕路了，数据包到达时间忽早忽晚。
4.4 RTCP报文类型
RTCP有几种报文类型，我列个表给你看，这样更清楚。
| 类型编号 | 报文名称 | 作用 | 发送频率 |
|---|---|---|---|
| 200 | SR (Sender Report) | 发送方报告：包含发送统计和NTP时间戳 | 发送方定期发送 |
| 201 | RR (Receiver Report) | 接收方报告：包含丢包率、抖动等接收统计 | 接收方定期发送 |
| 202 | SDES (Source Description) | 源描述：包含CNAME、NAME等标识信息 | 会话开始时及定期 |
| 203 | BYE | 会话结束通知 | 参与者离开时 |
| 204 | APP (Application-defined) | 应用自定义报文 | 按需 |
说几个我在实战中常用的点：
- SR报文：里面有个NTP时间戳和RTP时间戳的对应关系。做媒体同步时，这个映射是关键。我写过一个工具，专门解析SR报文来对齐音视频流。
- RR报文：丢包率字段是8位整数，范围0-255，对应0%-100%的丢包率。计算方法是：丢包率 = 丢包数 / 期望接收包数。我曾经见过一个设备，丢包率算出来是256，明显是溢出错误。
- SDES报文：里面的CNAME是规范名称，通常格式是user@host。在抓包分析时，CNAME可以帮助你识别不同的参与者。
- BYE报文：这个报文很简单，但很重要。如果一方异常退出，没有发送BYE，另一方就会一直等待，直到超时。我在调试一个视频会议系统时，就遇到过这种「幽灵会话」的问题。
注意：RTCP报文是复合报文。什么意思呢？就是一次RTCP发送可能包含多个报文类型。比如一个UDP包里，可能先放一个SR，再跟一个SDES。解析时要注意报文边界，别把不同类型的数据混在一起读。
好了，这一章的内容就这些。RTP和RTCP是IMS媒体分析的基石。你把这些基础打牢了，后面分析复杂的媒体流时，心里就有底了。