2. RTSP协议基础
RTSP（Real Time Streaming Protocol，实时流传输协议）是推流与拉流系统中最核心的控制协议之一。它并不负责搬运音视频数据本身，而是负责“指挥”媒体会话：建立会话、描述媒体、启动播放、暂停、定位、停止以及拆除会话。理解 RTSP 的定义、工作原理、与 RTP/RTCP 的分工关系，以及它的请求响应模型和常见方法，是后续搭建 RTSP 推流环境、排查推流失败与播放异常的基础。
一、RTSP协议定义与定位
RTSP 是一个应用层协议，默认使用 TCP 端口 554，也可通过 HTTP 隧道或 TLS 承载。它采用文本化的请求/响应语法，风格与 HTTP 类似，但语义面向“流媒体会话控制”。RTSP 的核心价值在于：把媒体流的“控制面”和“数据面”分离。控制面由 RTSP 负责，数据面通常由 RTP 承载，质量反馈由 RTCP 承担。
因此，RTSP 常被描述为“流媒体的遥控器”。它不直接传输 H.264 视频帧或 AAC 音频帧，而是告诉服务端或客户端：有哪些媒体轨道、用什么传输方式、从什么时间点开始、以什么速度播放、何时暂停或关闭。真正承载音视频包的是 RTP，RTCP 则负责统计与同步信息。
关键结论：RTSP 负责会话控制，RTP 负责媒体数据传输，RTCP 负责传输质量反馈与同步。三者协同，才构成完整的 RTSP 流媒体体系。
二、RTSP与RTP/RTCP的关系
在典型的 RTSP 推流或拉流场景中，客户端与服务端先通过 RTSP 建立控制通道，再通过 SDP 描述媒体信息，随后使用 RTP 传输音视频数据，同时用 RTCP 周期性发送发送端报告、接收端报告、丢包统计和抖动信息。RTSP 的 SETUP 方法决定 RTP/RTCP 使用哪组端口或哪种传输方式，PLAY 方法触发 RTP 数据开始发送，PAUSE 和 TEARDOWN 则控制暂停与结束。
需要特别注意的是：RTSP 本身不保证音视频数据的实时性，它只负责控制信令。RTP 才负责把编码后的音视频帧封装为 RTP 包，并通过时间戳、序列号支持乱序重排、丢包检测和播放同步。RTCP 则让发送端和接收端能够感知网络质量，例如丢包率、延迟抖动和往返时间。
三、请求响应模型与常见方法
RTSP 采用客户端/服务端请求响应模型。客户端发送方法请求，服务端返回状态码和响应头。常见状态码包括 200 OK、401 Unauthorized、404 Not Found、454 Session Not Found、500 Internal Server Error 等。RTSP 会话由 Session ID 标识，后续请求需要携带该 ID，否则服务端无法定位会话。
RTSP 的常见方法如下表所示。它们构成了推流与拉流控制的基本操作集合。
| 方法 | 作用 | 典型方向 | 关键点 |
|---|---|---|---|
| OPTIONS | 查询服务端支持的方法 | 客户端 → 服务端 | 用于能力探测，常作为第一步 |
| DESCRIBE | 获取媒体描述信息（SDP） | 客户端 → 服务端 | 返回媒体轨道、编码、时钟频率等 |
| SETUP | 建立传输会话，确定 RTP/RTCP 参数 | 客户端 → 服务端 | 指定传输方式（UDP/TCP）、端口、SSRC |
| PLAY | 启动或恢复媒体流传输 | 客户端 → 服务端 | 可带 Range 指定播放区间 |
| PAUSE | 暂停媒体流，保留会话 | 客户端 → 服务端 | 暂停后可用 PLAY 恢复 |
| TEARDOWN | 结束会话，释放资源 | 客户端 → 服务端 | 推流结束或播放器退出时调用 |
| ANNOUNCE | 向服务端推送媒体描述 | 推流端 → 服务端 | 推流场景中常见，用于告知媒体信息 |
| RECORD | 请求服务端开始录制 | 推流端 → 服务端 | 与 ANNOUNCE 配合完成推流录制 |
四、典型交互流程与实操观察
以拉流播放为例，一次完整的 RTSP 交互通常如下：客户端先发 OPTIONS 探测服务端能力；再发 DESCRIBE 获取 SDP；然后对音频和视频分别发 SETUP，建立 RTP/RTCP 通道；接着发 PLAY 开始传输；播放结束后发 TEARDOWN 释放会话。推流场景则更常使用 ANNOUNCE、SETUP、RECORD 等组合。
OPTIONS rtsp://192.168.1.10:554/live/test RTSP/1.0
CSeq: 1
User-Agent: Lavf58.76.100
RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, RECORD, ANNOUNCE
DESCRIBE rtsp://192.168.1.10:554/live/test RTSP/1.0
CSeq: 2
Accept: application/sdp
RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 0 IN IP4 192.168.1.10
s=Live Stream
t=0 0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:trackID=0
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/44100/2
a=control:trackID=1
SETUP rtsp://192.168.1.10:554/live/test/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
PLAY rtsp://192.168.1.10:554/live/test RTSP/1.0
CSeq: 4
Session: 12345678
Range: npt=0.000-
RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
Range: npt=0.000-
从上面的交互可以看到，RTSP 的请求和响应都是文本形式，CSeq 用于匹配请求与响应，Session 用于标识会话，Transport 用于协商 RTP/RTCP 的承载方式。推流实战中，如果 SETUP 失败，常见原因是传输方式不匹配、端口被占用或鉴权未通过；如果 PLAY 后没有画面，则要检查 RTP 包是否真正到达、SDP 中的编码参数是否正确、RTCP 反馈是否异常。
实操建议：使用 FFmpeg 推流时，可通过 -rtsp_transport tcp 强制使用 TCP 承载 RTP，减少 UDP 丢包导致的画面花屏。使用 Wireshark 抓包时，过滤 rtsp 可观察控制信令，过滤 rtp 可观察媒体包，过滤 rtcp 可观察质量反馈。
五、常见误区与复盘要点
- 误区一：把 RTSP 当成音视频传输协议。RTSP 只负责控制，真正传输音视频的是 RTP。排查“没有画面”时，不能只看 RTSP 是否返回 200，还要确认 RTP 包是否到达。
- 误区二：忽略 Session ID。SETUP 之后的服务端响应会返回 Session，后续 PLAY、PAUSE、TEARDOWN 必须携带，否则服务端会返回 454 Session Not Found。
- 误区三：不关注 SDP。SDP 中的编码格式、时钟频率、payload type 和 control 属性直接决定 RTP 如何解析。SDP 错误会导致播放器无法解码。
- 误区四：UDP 与 TCP 混用。SETUP 中协商的 Transport 必须与后续 RTP 实际承载方式一致，否则会出现信令成功但媒体不通的情况。
- 复盘要点：先看 RTSP 方法序列是否完整，再看状态码和 CSeq 是否匹配，最后看 RTP/RTCP 是否正常收发。按照“控制面 → 描述面 → 数据面 → 反馈面”的顺序排查，效率最高。
注意：RTSP 默认端口为 554，但实际项目中可能被改为 8554 或其他端口。推流地址、防火墙策略、NAT 映射和鉴权配置必须与 RTSP 服务端保持一致，否则会在 DESCRIBE 或 SETUP 阶段直接失败。
掌握 RTSP 的定义、与 RTP/RTCP 的分工、请求响应模型和常见方法后，后续搭建 RTSP 推流环境时，就能更准确地判断问题出在信令协商、媒体传输还是质量反馈环节。无论是使用 FFmpeg、GStreamer、Live555 还是自研推流端，RTSP 的这套控制逻辑都是必须打牢的基础。