4、RTSP协议详解：RTSP的请求方法（OPTIONS、DESCRIBE、SETUP、PLAY）、会话流程与状态机

RTSP（Real Time Streaming Protocol，实时流传输协议）是视频监控、IP摄像机（IPC）和流媒体服务器之间进行会话控制的核心协议。它由IETF在RFC 2326（后更新为RFC 7826）中定义，其作用类似于视频世界的“遥控器”——负责协商媒体参数、建立会话、控制播放（播放、暂停、停止），而实际的音视频数据则通过RTP/RTCP协议另行传输。在GB28181国标未普及的存量设备、以及大量ONVIF协议摄像头中，RTSP仍然是接入视频流的最主要方式。理解RTSP的请求方法、会话流程与状态机，是进行视频接入开发、流媒体网关调试和播放器兼容性排查的必备基础。

上图展示了RTSP客户端与服务器之间的基本交互关系以及会话状态机的核心流转路径。RTSP本身并不传输媒体数据，而是通过文本命令控制媒体会话的建立与释放，媒体流通常承载于RTP（Real-time Transport Protocol）之上。在实际工程中，RTSP默认使用TCP 554端口（也可配置为其他端口），而RTP流可能使用UDP或TCP（RTP over RTSP）传输。

4.1 核心原理：RTSP的请求方法与C/S架构

RTSP采用类似HTTP的文本协议格式，每条请求由方法（Method）、URI（统一资源标识符）、协议版本和若干头部字段组成。服务器响应则包含状态行（如RTSP/1.0 200 OK）、头部字段和可选的消息体。与HTTP不同，RTSP是有状态协议——服务器需要维护每个会话（Session）的状态，以跟踪客户端当前处于初始化、就绪还是播放状态。

在视频接入场景中，最常用的RTSP方法包括以下五种：

除了上述基本方法，RTSP还定义了PAUSE（暂停）、GET_PARAMETER（获取参数）、SET_PARAMETER（设置参数）、REDIRECT（重定向）等方法。在视频监控接入中，PAUSE和GET_PARAMETER也时有使用，例如通过GET_PARAMETER发送keep-alive心跳包以维持NAT会话。

4.2 判断方法与操作流程：标准RTSP交互过程

一次完整的RTSP会话建立流程通常包含以下步骤。理解每一步的报文特征，有助于快速定位接入失败的原因。

1. OPTIONS请求：客户端向服务器发送OPTIONS，询问支持的方法。虽然有些服务器允许跳过此步，但建议保留，因为它能提前暴露URL错误或端口不通的问题。
2. DESCRIBE请求：客户端请求媒体描述。服务器返回SDP（Session Description Protocol）文本，其中包含媒体类型（视频/音频）、编码格式（H.264/H.265）、分辨率、帧率、以及媒体流的RTP payload type编号。
3. SETUP请求：客户端根据SDP中的媒体信息，为每一个媒体流（视频轨、音频轨）发送SETUP请求。此步骤协商传输模式（TCP/UDP）、端口号、以及RTP over RTSP的interleaved通道编号。服务器返回Session ID，后续所有请求都需要携带该ID。
4. PLAY请求：客户端发送PLAY命令，服务器开始通过RTP发送媒体数据。PLAY响应中通常包含RTP-Info头部，指示初始的RTP时间戳和序列号。
5. 媒体传输与保活：在播放过程中，客户端可定期发送OPTIONS或GET_PARAMETER作为心跳，防止会话超时。对于UDP传输，还需要处理RTCP RR（Receiver Report）以维持NAT映射。
6. TEARDOWN请求：播放结束或异常退出时，客户端发送TEARDOWN释放会话资源。

以下是一个典型的RTSP交互报文序列（使用TCP传输）：

C: OPTIONS rtsp://192.168.1.64:554/stream1 RTSP/1.0
C: CSeq: 1
C: User-Agent: VLC/3.0.18

S: RTSP/1.0 200 OK
S: CSeq: 1
S: Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, GET_PARAMETER

C: DESCRIBE rtsp://192.168.1.64:554/stream1 RTSP/1.0
C: CSeq: 2
C: Accept: application/sdp

S: RTSP/1.0 200 OK
S: CSeq: 2
S: Content-Type: application/sdp
S: Content-Length: 456
S:
S: v=0
S: o=- 123456 123456 IN IP4 192.168.1.64
S: s=Stream
S: t=0 0
S: m=video 0 RTP/AVP 96
S: a=rtpmap:96 H264/90000
S: a=fmtp:96 profile-level-id=42001F; packetization-mode=1
S: a=control:track1

在上述报文中，m=video 0 RTP/AVP 96表示视频流使用动态payload type 96，a=control:track1指定了该媒体流的控制URL，SETUP请求应发送到该URL。

4.3 案例拆解：VLC拉取海康IPC流时的RTSP交互与排障

某项目需要将海康威视DS-2CD3T56WD-I3摄像头的视频流接入自研分析平台。平台使用VLC的libVLC库进行拉流测试，但始终无法播放，VLC日志显示“Connection failed”或“Unsupported protocol”。

初始现象与目标：摄像头IP为192.168.1.108，端口554。目标是通过RTSP获取H.264主码流。VLC打开网络串流时提示失败。

分析判断过程：首先使用VLC的“工具-消息”功能开启详细日志，发现VLC发送OPTIONS后未收到任何响应。进一步使用telnet测试端口连通性：telnet 192.168.1.108 554，发现端口不通。初步判断为网络防火墙或摄像头RTSP服务未启用。

实际操作步骤：

1. 检查摄像头Web管理页面，确认“RTSP认证”设置为“digest”，且RTSP端口为554。
2. 在摄像头所在局域网内使用另一台PC执行 ping 192.168.1.108，网络连通。
3. 使用 nmap -p 554 192.168.1.108 扫描端口，发现554端口被过滤。检查交换机ACL，发现该端口仅允许特定IP访问。
4. 调整ACL后，VLC重新拉流，日志显示DESCRIBE成功，但SETUP阶段报错“Transport: RTP/AVP/TCP;unicast;interleaved=0-1”。
5. 分析发现VLC默认尝试UDP传输，而摄像头所在网络禁止UDP大包。在VLC的“工具-偏好设置-输入/编解码器-网络”中，将“RTP over RTSP (TCP)”勾选为强制。
6. 重新播放，成功获取视频流。

结果对比与复盘：通过抓包（Wireshark）对比，发现UDP模式下RTP包在传输层被分片，部分包丢失导致解码器无法同步。切换TCP模式后，RTP包通过RTSP的TCP连接以interleaved方式传输，避免了UDP丢包。此案例说明，RTSP接入排障应遵循“先通（网络）、再控（会话）、后流（媒体）”的顺序，且传输模式的选择需结合网络环境。

4.4 常见误区与总结复盘

在RTSP协议的实际应用中，开发者和运维人员常陷入以下误区：

• 混淆RTSP与HTTP：RTSP虽然语法类似HTTP，但它是有状态协议，且默认端口不同。不能直接使用HTTP代理转发RTSP。
• 忽略SDP中的control字段：多轨流（如视频+音频）需要分别SETUP，且SETUP的URL必须使用SDP中control字段指定的地址，而非根URL。
• 未处理Session ID：SETUP响应中的Session ID是后续PLAY、PAUSE、TEARDOWN请求的必带头部，遗漏会导致服务器返回454 Session Not Found。
• 认证方式不匹配：RTSP支持Basic和Digest认证。部分设备默认开启Digest，客户端若仅实现Basic认证，会收到401 Unauthorized。
• 忽略keep-alive：长时间不发送任何RTSP请求，服务器可能因超时主动断开会话。建议每30-60秒发送一次OPTIONS或GET_PARAMETER。

总结复盘：RTSP协议的核心价值在于其灵活性和可扩展性，但也正因如此，不同厂商的实现存在差异。在接入新设备时，建议先使用VLC或ffprobe进行验证，确认URL、认证方式和传输模式无误后，再编写正式接入代码。对于大规模接入场景，应设计统一的RTSP会话管理模块，负责会话建立、保活、断线重连和资源释放，避免因单个会话异常导致内存泄漏或文件描述符耗尽。