WireShark抓取rtsp包

一．WireShark抓取rtsp打印

上图是抓取RK3568传输到WINDOWS的RTSP流媒体服务器的数据报文,我们来分析下这里的报文,这个RTSP码流是用RECORD进行推流

二.RTSP报文分析

上面是Rtsp交互的分析,需要在输入框加上tcp.dstport == 25544 || udp.dstport == 25544进行过滤搜索。整个协议交互是用TCP进行处理的。

一、OPTIONS 请求 / 响应

OPTIONS rtsp://192.168.100.66:25544/live/01 RTSP/1.0
CSeq: 1
User-Agent: Lavf58.29.100

服务器响应：

RTSP/1.0 200 OK
Server: Sugar
CSeq: 1
Public: DESCRIBE, ANNOUNCE, SETUP, PLAY, PAUSE, RECORD, TEARDOWN

• 状态行 200 OK 表示成功。

• Server: Sugar 指明服务器软件为 Sugar（可能是开源 RTSP 服务器或定制实现）。

• Public 列出服务器支持的方法：DESCRIBE, ANNOUNCE, SETUP, PLAY, PAUSE, RECORD, TEARDOWN。其中 ANNOUNCE 和 RECORD 是推流（发布）模式的关键方法。

三、ANNOUNCE 请求 / 响应

ANNOUNCE rtsp://192.168.100.66:25544/live/01 RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: Lavf58.29.100
Content-Length: 308

[ SDP 文本 ]

• 方法 ：ANNOUNCE ，用于将媒体流的 SDP 描述 告知服务器，相当于告诉服务器"我要推送什么格式的流"。

• Content-Type ：application/sdp，表明消息体是 SDP 格式。

• Content-Length：SDP 长度 308 字节。

SDP 分析

红色部分展示了RTSP客户端向服务器发送的ANNOUNCE请求消息，用于访问媒体流描述信息：

ANNOUNCE rtsp://192.168.100.66:25544/live/01 RTSP/1.0

• 目标服务器：rtsp://192.168.100.66:25544/live/01
• 协议版本：RTSP 1.0

请求头信息：

• Content-Type: application/sdp（消息体采用SDP格式）
• CSeq: 2（请求序号）
• User-Agent: Lavf58.29.100（使用FFmpeg的libavformat库，版本58.29.100）
• Content-Length: 308（消息体长度）

SDP会话描述**（Session Description Protocol，会话描述协议）**：

v=0（SDP版本号）
o=- 0 0 IN IP4 127.0.0.1（源信息：用户名未指定，会话ID和版本均为0，IPv4地址127.0.0.1）
s=No Name（会话名称）
c=IN IP4 192.168.100.66（连接信息：IPv4地址192.168.100.66）
t=0 0（无时间限制）
a=tool:libavformat 58.29.100（生成工具：FFmpeg libavformat 58.29.100）
m=video 0 RTP/AVP 96（视频流，端口未指定，RTP/AVP协议，Payload Type 96）
b=AS:6220（带宽需求：6220kbps）
a=rtpmap:96 H264/90000（编码格式：H264，时钟频率90000Hz）
a=fmtp:96 packetization-mode=1（RTP分包模式：非交错模式）
sprop-parameter-sets=Z20AKK2Z0HBCI+NEAAADAAQAAAMA8Dxexlg=,a0vssiw=（H.264参数集：SPS和PPS的Base64编码）
profile-level-id=640028（H.264配置：High Profile, Level 4.0）
a=control:streamid=0（控制URL，流ID为0）

蓝色部分是服务器响应： RTSP/1.0 200 OK（成功响应） CSeq: 2（对应请求序号）

SETUP报文

一、SETUP 请求（客户端 → 服务器）

SETUP rtsp://192.168.100.66:25544/live/01/streamid=0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=23666-23667;mode=record
CSeq: 3
User-Agent: Lavf58.29.100

1. 请求行

• 方法 ：SETUP -- 用于为某个媒体流建立传输通道。

• URL ：rtsp://192.168.100.66:25544/live/01/streamid=0

  • 服务器地址：192.168.100.66:25544

  • 挂载点：/live/01

  • 流控制路径：streamid=0 ，应与之前 ANNOUNCE 中 SDP 的**a=control:streamid=0** 一致。

• RTSP 版本：1.0。

2. 请求头部

• Transport：指定传输参数，是 SETUP 的核心。

  • RTP/AVP/UDP：使用 RTP over UDP，载荷类型为 AVP（Audio/Video Profile）。

  • unicast：单播传输模式。

  • client_port=23666-23667 ：客户端告知服务器，它将使用 23666 端口接收 RTP 数据，23667 端口接收 RTCP 数据。

    注意：虽然是推流（record），但 RTSP 协议中端口描述依然沿用"client_port"这一术语，实际上客户端会向服务器发送 RTP 包，但客户端也需要接收可能的 RTCP 反馈，因此仍保留端口对。实际发送方向由 mode=record 指定。

  • mode=record ：设置会话模式为 record，表示此 SETUP 是为推流（从客户端到服务器）准备的。

• CSeq: 3：事务序号，客户端用此匹配响应。

• User-Agent ：Lavf58.29.100，FFmpeg 库标识。

二、SETUP 响应（服务器 → 客户端）

RTSP/1.0 200 OK
CSeq: 3
Date: Mon, 10 Mar 2025 19:03:40 CST
Session: 191201771
Transport: RTP/AVP/UDP;unicast;client_port=23666-23667;server_port=30024-30025;mode=record

1. 状态行

• 200 OK：请求成功，服务器同意建立传输通道。

2. 响应头部

• CSeq: 3：与请求事务序号一致，表明对此请求的应答。

• Date：服务器时间戳。

• Session: 191201771：服务器为此会话生成的唯一标识符。后续的 RECORD、TEARDOWN 等请求必须携带此 Session ID。

• Transport：回显并补充参数。

  • 回显客户端的参数：RTP/AVP/UDP，unicast，client_port=23666-23667，mode=record。

  • 新增 server_port=30024-30025 ：服务器告知客户端，它会在端口 30024 上等待接收 RTP 数据，在端口 30025 上等待接收 RTCP 数据。客户端后续将 RTP 包发送到服务器 IP:30024，RTCP 包发送到 30025。

  • 注意：UDP 端口通常成对出现，偶数为 RTP，奇数为 RTCP。

三、SETUP 在 RTSP 推流中的作用

阶段	说明
前序	已完成 OPTIONS 查询和 ANNOUNCE 推送 SDP。
SETUP	为视频流（streamid=0）协商传输方式、端口及会话模式。
后续	客户端将发送 RECORD 启动推流，然后通过 UDP 通道持续发送 RTP 包。

• 模式 record：明确这是一个推流会话，数据流向为客户端 → 服务器，与播放（PLAY）相反。

• 服务器分配的 server_port 是 UDP 接收端口，客户端需向该端口推送 RTP 包。

• 会话 ID 191201771 将在后续 RECORD 及 TEARDOWN 中使用。

四、与播放（PLAY）模式的区别

特性	PLAY（拉流）	RECORD（推流）
数据方向	服务器 → 客户端	客户端 → 服务器
Transport 中 mode	通常缺省或为 play（很少显式写）	mode=record
使用的方法	SETUP 后使用 PLAY	SETUP 后使用 RECORD
端口分配	客户端告知自己的接收端口，服务器选择发送端口	客户端告知自己的接收端口（尽管实际不接收RTP），服务器告知自己的接收端口
典型场景	点播、观看	摄像机推流、直播推流

四.RTP数据包报文

（图一）

（图二）

一、RTP 包整体特征（图一列表部分）

1. 数据流向：

   • 源 IP 192.168.100.80 为 RK3568 设备（推流客户端）。

   • 目标 IP 192.168.100.66 为 Windows 主机（RTSP 服务器，端口 25544）。

2. Payload Type（PT）分布：

   • PT=96（DynamicRTP-Type-96）：出现频率最高，数据包长度从 280 到 1514 字节不等。

     • 部分包带有 Mark 标志（如 Seq=3537, 3538, 3539 等），表明该包为一个视频帧的结束（通常是一帧 H.264 的最后一个分片）。

     • 同一 SSRC（0x4CA586DE）表示属于同一视频流。时间戳递增规律：相邻包时间戳差 ≈ 3000（对应 90 kHz 时钟下约 33.33 ms，即 30 fps）。

   • PT=123 （DynamicRTP-Type-123）：出现两个连续包（Seq=4259），长度 1514 字节，SSRC 为 0x2F8FD9C，时间戳相同且与视频流时间戳不同。可能是音频流或其他数据流。值得注意的是 Wireshark 显示为重复包（同一 Seq 和 Time），可能是抓包重复或网络重传。

   • PT=Unassigned (255?)：出现两个连续包，长度 357 字节，SSRC 为 0xA565F37F ，时间戳非常大（26111308505）。可能是 RTCP 或未知数据，但 Wireshark 未识别 PT 类型。

3. 序列号（Seq）连续性：

   • 视频流（SSRC=0x4CA586DE）Seq 从 3537 递增到 3549，没有明显丢包（但中间夹杂了其他流的包，说明 RTP 多路复用）。

4. 包长度变化：视频包长度从 280 到 1514 不等，说明 H.264 编码的 NALU 大小不一，且存在分片（大于 MTU 时会被拆成多个 RTP 包，但此处单个包最大 1514，可能与网络 MTU 限制有关）。大包（1514 字节）连续出现（Seq 3543~3549），可能对应一个大的视频帧（如 I 帧）。

二、单个 RTP 包详细解析（第二张图）

1. Version (版本号): 2 (2 bits)

• 值 : 10 (二进制) → 十进制 2

• 含义: RTP 版本号。RFC 3550 中定义版本号为 2。当前所有 RTP 实现都使用此版本。

2. Padding (填充标志): False (1 bit)

• 值 : 0

• 含义: 指示 RTP 包末尾是否包含额外的填充字节。本包中为假，没有填充。填充通常用于使包长满足底层传输要求。

3. Extension (扩展头标志): False (1 bit)

• 值 : 0

• 含义: 指示 RTP 固定头部之后、载荷之前是否存在扩展头。本包中没有扩展头。

4. CSRC Count (CSRC 计数): 0 (4 bits)

• 值 : 0000

• 含义: 表示跟随在 SSRC 之后的 CSRC（贡献源）标识符的数量。此处为 0，表示没有 CSRC。CSRC 用于混音器或多源场景。

5. Marker (标记位): False (1 bit)

• 值 : 0

• 含义 : 由 profile 定义，通常用于标记一个帧的边界（如视频帧的最后一个分片）。本包中 Marker=0，说明此 RTP 包不是一帧的结束，可能是中间包或非边界包。

6. Payload Type (负载类型): 96 (7 bits)

• 值 : 96

• 含义 : 指示 RTP 载荷的编码格式。96 属于动态类型范围（96--127），具体编码需通过 SDP 协商确定。根据前文 RTSP 会话的 SDP，可知 PT=96 对应 H.264 视频 （rtpmap:96 H264/90000）。

7. Sequence Number (序列号): 14992 (16 bits)

• 值 : 14992

• 含义: 每发送一个 RTP 包，序列号加 1。接收方据此检测丢包和恢复包序。此处序列号为 14992。

8. Timestamp (时间戳): 3027177261 (32 bits)

• 值 : 3027177261 (十进制)

• 含义: 反映该 RTP 包中第一个采样点的时刻。时钟频率由 payload type 决定，对于 H.264 视频，时钟频率通常为 90 kHz。时间戳用于同步和抖动计算。该数值很大，表明流已运行一段时间。

9. SSRC (同步源标识符): 0xc22d9da5 (32 bits)

• 值 : 0xc22d9da5 (十六进制) = 3257769381 (十进制)

• 含义 : 唯一标识一个 RTP 流的源。同一 SSRC 的所有 RTP 包属于同一个媒体流（例如同一个视频流）。不同媒体流（如音频、视频）使用不同的 SSRC。本包中的 SSRC 与列表中其他包的 SSRC 不同（列表中视频流 SSRC 为 0x4CA586DE），说明此包可能来自另一个流或抓取的是另一时间点的会话。

10. Payload (载荷): [truncated]

• 由于抓包截断，未显示完整载荷。根据 PT=96，载荷应为 H.264 视频数据（可能包含 NALU 起始码或分片单元）。

11. Contributing Sources (CSRC): 无

• CC=0，因此没有 CSRC 字段。

五.RTCP数据包报文

RTCP数据包报文分成SR、RR、APP、SDES、BYE五个控制包, 在这个抓包数据里面主要分析SR、RR、BYE这几个包。

SR包(Sender Report发送方报道控制包):

字段解析（对应图中数值）

字段	十六进制/十进制值	解释
Version	2（二进制10）	RTP/RTCP 版本号，标准为 2
Padding	0	无填充字节
Reception report count (RC)	0	本 SR 包之后不附带任何接收报告块（reception report blocks）
Packet type	200 (0xC8)	Sender Report 类型码
Length	6	表示 RTCP 包长度为 (6+1)*4 = 28 字节（length 字段单位是 32 位字，减 1 后存放）
Sender SSRC	0xffc3fc42	发送端的同步源标识符，标识该 RTP 流
NTP timestamp (MSW)	3710861479 (0xdd2f40a7)	NTP 时间戳的高 32 位，表示从 1900 年 1 月 1 日至今的秒数
NTP timestamp (LSW)	3539053051 (0xd2f1a9fb)	NTP 时间戳的低 32 位，表示秒的小数部分（约 0.823999999 秒）
RTP timestamp	360742208	与 NTP 时间戳对应的 RTP 时钟参考值（时钟频率由媒体定义，如 90 kHz）
Sender's packet count	1427	该发送端自会话开始累计发送的 RTP 数据包总数（包括重传）
Sender's octet count	1857092	累计发送的 RTP 载荷字节数（不包括头部和填充）

图中 RTCP length: 6 表示包总长度为 28 字节（因为 (6+1)*4 = 28）。由于 RC=0，没有报告块，所以包体到此结束。

解析意义

• 该 SR 包由发送端 192.168.100.80 发往 192.168.100.66，反馈自身的发送统计。

• 包含绝对时间（NTP）和相对媒体时间（RTP timestamp）的映射，用于接收端同步音频与视频或计算端到端延迟。

• 发送端报告当前已发送 1427 个包、1857092 字节，可用于估算数据速率。

六.BYE控制包

V (Version): RFC 1889 Version (2)
(基于 RFC 1889 的 RTP 协议实现，版本号为 2)

P (Padding): False
(未使用填充字段)

SC (Source Count): 20
(SSRC/CSRC 数量为 20)

Packet Type: Goodbye (203)
(接收方类型控制包)

BYE Message Length: 8821 (35288 bytes)
(报文长度为 35288 字节)

Identifier: 0x2055539a (542462874)
(发送当前 RTCP 报文的参与者 SSRC 码: 0x2055539a)

Identifier: 0x948f24da (2492409050)
(发送当前 RTCP 报文的参与者 SSRC 码: 0x948f24da)