RTP协议头部结构：从比特流到音画同步的基石

说实话，RTP协议头部的设计，是我见过最精巧的「轻量级」协议之一。它只有12个字节的固定头部，却承载了音视频传输最核心的信息。我当年第一次抓包分析RTP时，看着那一串十六进制数据，说实话有点懵。但当你把每个字段拆开来看，就会发现——嗯，每个bit都有它的使命。

咱们今天就把这12个字节掰开揉碎，一个一个讲清楚。

2.1 RTP固定头部：12字节的「身份证」

先看整体结构。RTP头部的前12个字节是固定的，后面跟着可选的CSRC列表和扩展头部。我习惯把这12个字节分成三组：

• 第1组（第1-4字节）：版本号、填充位、扩展位、CSRC计数器、标记位、负载类型
• 第2组（第5-8字节）：序列号
• 第3组（第9-12字节）：时间戳

等等，还有SSRC和CSRC？别急，它们在第13字节之后。咱们先看前12个字节的「核心三件套」。

2.2 版本号(V)：2bit的「协议指纹」

版本号占2个bit，位于第1字节的高2位。当前RTP的版本号是2。为什么是2？因为版本0和版本1都是早期实验版本，早就被废弃了。

我记得有一次排查一个兼容性问题，对方说他们的设备支持RTP，但抓包一看版本号是0。嗯，那其实是RTP的早期原型，根本不能和标准RTP互通。所以，看到版本号不是2，基本可以断定这个流有问题。

2.3 填充位(P)与扩展位(X)：1bit的「开关」

这两个字段各占1个bit，位置在第1字节的第2位和第1位（从高位算起）。

• 填充位(P)：如果置1，表示包尾有填充字节。填充字节的最后一个字节表示填充长度。为什么需要填充？有些加密算法要求明文长度是块大小的整数倍，这时候就需要填充。
• 扩展位(X)：如果置1，表示固定头部后面跟着一个头部扩展。扩展头部有自己独立的格式，用于携带一些额外的信息，比如视频的旋转角度、音频的采样率等。

我个人建议，除非有特殊需求，否则尽量别用扩展头部。为什么？因为很多老旧的解码器或者中间件，对扩展头部的支持并不好。我曾经在一个项目中，为了传递一个自定义的元数据，在扩展头部里塞了个时间戳偏移量。结果某个型号的硬件解码器直接把这个包当成了无效包……从那以后，我对扩展头部就格外谨慎。

2.4 CSRC计数器(CC)：4bit的「参会人数」

CC占4个bit，位于第1字节的低4位。它表示后面跟着多少个CSRC（贡献源标识符）。

CC的取值范围是0到15。如果CC=0，表示没有CSRC列表，头部在12字节处结束。如果CC=3，表示后面跟着3个CSRC，每个CSRC占4个字节，所以头部总长度是12 + 3×4 = 24字节。

这个字段在混音场景中特别重要。比如一个视频会议，有5个人在说话，混音器会把5个人的音频混合成一个流。这时候，SSRC是混音器的标识，而CSRC列表里就是那5个人的原始SSRC。接收端看到CSRC列表，就知道这个包是哪些人的声音混合而成的。

2.5 标记位(M)：1bit的「信号旗」

标记位占1个bit，位于第2字节的最高位。它的含义取决于负载类型。对于视频流，M位通常标记一帧的结束。对于音频流，M位通常标记一次说话的开始（比如通话中的「语音激活」）。

我举个例子。在H.264视频流中，一个视频帧可能被分割成多个RTP包。最后一个包的M位会被置1，表示这一帧结束了。接收端看到M位为1，就知道可以开始解码这一帧了。

2.6 负载类型(PT)：7bit的「编码格式」

PT占7个bit，位于第2字节的低7位。它告诉接收端，这个RTP包里的数据是什么编码格式。比如：

PT值	编码格式	说明
0	PCMU	G.711 μ-law，电话音频
3	GSM	GSM 6.10，移动通信音频
8	PCMA	G.711 A-law，欧洲电话音频
96-127	动态类型	由SDP协商决定，比如H.264通常用96或97

PT值0-95是静态分配的，由IANA定义。96-127是动态类型，通过SDP协商。比如H.264视频，没有固定的PT值，双方在SDP里约定用96来表示H.264。

我记得有一次，一个设备发送的H.264视频流，PT值写的是35。35在IANA定义里是「H.263」……结果接收端按照H.263去解码，画面全是马赛克。排查了半天，才发现是PT值写错了。所以，动态类型的PT值一定要和SDP协商一致，否则就是灾难。

2.7 序列号(SN)：16bit的「流水号」

序列号占16个bit，位于第3-4字节。每个RTP包发送时，序列号递增1。初始序列号是随机的（不是从0开始），这是为了安全考虑——防止攻击者猜测序列号。

序列号的作用有两个：

• 检测丢包：如果接收到的序列号不连续，说明中间有包丢失了。
• 排序：网络传输中，包可能乱序到达。接收端根据序列号重新排序，恢复原始顺序。

序列号是16位的，取值范围0-65535。溢出后会回绕到0。处理回绕是RTP实现中的一个常见坑点。我建议用无符号整数比较，或者用序列号差值来判断（比如新序列号 - 旧序列号 & 0xFFFF）。

2.8 时间戳(Timestamp)：32bit的「时间轴」

时间戳占32个bit，位于第5-8字节。它表示RTP包中第一个采样数据的采样时刻。时间戳的单位取决于负载类型：

• 音频：单位是采样周期。比如8kHz采样的音频，每个采样周期是125微秒。时间戳每增加1，表示过去了125微秒。
• 视频：单位是时钟频率。通常视频的时钟频率是90kHz。时间戳每增加1，表示过去了1/90000秒（约11.1微秒）。

时间戳是音画同步的核心。接收端根据时间戳来决定什么时候播放这个包。如果音频和视频的时间戳是同步的（基于同一个时钟），那么播放时就能保持唇同步。

我遇到过一个问题：一个视频会议系统，音频和视频的时间戳分别来自不同的时钟源。音频时间戳来自声卡，视频时间戳来自摄像头。结果两个时钟的漂移不一致，导致音画不同步越来越严重。后来我们统一用NTP时间作为参考，才解决了这个问题。

2.9 同步源标识(SSRC)：32bit的「流ID」

SSRC占32个bit，位于第9-12字节。它唯一标识一个RTP流。在一个RTP会话中，每个参与者都有一个唯一的SSRC。SSRC是随机生成的，但必须保证在同一个会话中不重复。

SSRC的作用是区分不同的流。比如一个视频会议，有3个人在说话，每个人都有自己的音频流和视频流。每个流都有一个独立的SSRC。接收端根据SSRC来区分这些流，分别处理。

SSRC冲突怎么办？RTP协议有冲突检测机制。如果两个参与者生成了相同的SSRC，其中一个会检测到冲突，然后重新生成一个新的SSRC。我在项目中遇到过SSRC冲突，当时两个客户端同时加入会议，生成了相同的SSRC。结果接收端把两个流混在了一起……后来我们增加了SSRC冲突检测的逻辑，问题就解决了。

2.10 贡献源列表(CSRC)：32bit×N的「贡献者名单」

CSRC列表跟在固定头部后面，每个CSRC占32个bit。CSRC的数量由CC字段决定。CSRC列表记录了哪些源对这个RTP包有贡献。通常用于混音场景。

比如一个混音器，把3个人的音频混合成一个流。这个流的SSRC是混音器自己的标识，而CSRC列表里是那3个人的原始SSRC。接收端看到CSRC列表，就知道这个包是哪些人的声音混合而成的。这在实现「谁在说话」指示器时非常有用。

CSRC列表是可选的。如果CC=0，就没有CSRC列表。大多数点对点通信中，CC都是0。

2.11 整体结构图：一张图看懂RTP头部

下面这张SVG图，把RTP头部的所有字段和它们的位置关系画了出来。你可以把它当作一个速查表。

2.12 字段速查表：一表在手，抓包不愁

最后，我把所有字段整理成一个速查表。你在抓包分析时，可以对照这个表来解析RTP头部。

字段	缩写	长度	位置	作用
版本号	V	2bit	第1字节高2位	标识RTP版本，当前为2
填充位	P	1bit	第1字节第2位	是否包含填充字节
扩展位	X	1bit	第1字节第1位	是否包含扩展头部
CSRC计数器	CC	4bit	第1字节低4位	CSRC列表中的标识符数量
标记位	M	1bit	第2字节最高位	帧边界标记（视频帧结束/语音激活）
负载类型	PT	7bit	第2字节低7位	编码格式标识
序列号	SN	16bit	第3-4字节	包序号，用于丢包检测和排序
时间戳	TS	32bit	第5-8字节	采样时刻，用于音画同步
同步源标识	SSRC	32bit	第9-12字节	唯一标识一个RTP流
贡献源列表	CSRC	32bit×CC	第13字节起	混音场景中的原始源标识列表