2. RTSP协议基础
RTSP（Real Time Streaming Protocol，实时流传输协议）是流媒体部署中最常被误解的一层协议。很多初学者以为“RTSP 就是传视频的协议”，实际上 RTSP 本身不承载音视频数据，它更像一个“远程录像机遥控器”：负责建立会话、描述媒体、控制播放，而真正的音视频码流由 RTP 承载、由 RTCP 反馈质量。理解这一分工，是后续排查音画不同步问题的前提。
一、RTSP 的定位：控制面与数据面分离
RTSP 工作在应用层，默认端口 554，语法风格接近 HTTP，但它是有状态的：一次会话会持续存在，直到被 TEARDOWN 或超时。它把“控制”和“传输”拆成两条链路：
- 控制面（RTSP）：DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN 等方法，负责协商和指挥。
- 数据面（RTP/RTCP）：RTP 传输音视频包，RTCP 周期性发送发送者报告（SR）和接收者报告（RR），携带 NTP 时间戳与 RTP 时间戳的对应关系。
音画同步的关键信息——RTP 时间戳与绝对时间的映射——正是通过 RTCP SR 传递的，而不是 RTSP。因此只抓 RTSP 报文无法定位同步问题，必须同时抓 RTP/RTCP。
二、RTSP 常用方法与 URL 格式
RTSP URL 的典型格式为：
rtsp://[用户名:密码@]主机[:端口]/路径[?参数]
示例：
rtsp://admin:pass123@192.168.1.64:554/Streaming/Channels/101
rtsp://camera.local/live/ch0
rtsp://10.0.0.8:8554/test.mp4其中路径部分由服务端定义，海康、大华、ONVIF 设备的通道路径各不相同，部署时必须以设备文档为准。常用方法如下表：
| 方法 | 方向 | 作用 | 是否必需 |
|---|---|---|---|
| OPTIONS | C→S | 查询服务端支持的方法 | 可选 |
| DESCRIBE | C→S | 获取 SDP 媒体描述 | 必需 |
| SETUP | C→S | 建立传输通道，协商 RTP/RTCP 端口 | 必需 |
| PLAY | C→S | 启动或恢复播放 | 必需 |
| PAUSE | C→S | 暂停，保留会话 | 可选 |
| TEARDOWN | C→S | 结束会话，释放资源 | 推荐 |
| GET_PARAMETER | C→S | 保活或查询参数 | 可选 |
三、典型会话流程
一次完整的 RTSP 交互通常按 OPTIONS → DESCRIBE → SETUP → PLAY →（RTP/RTCP 传输）→ TEARDOWN 的顺序进行。DESCRIBE 返回的 SDP 中会声明媒体类型、编码格式、时钟频率（如 90000）和 control 属性，SETUP 则根据 control 建立具体传输通道。下图展示了控制面与数据面的协作关系：
四、与 RTP/RTCP 的关系及常见交互案例
三者分工可以概括为：RTSP 建会话、RTP 送数据、RTCP 报质量。RTP 包头中的时间戳以采样率为单位递增，例如视频 90000Hz、音频 48000Hz，它本身只是相对时间；RTCP SR 包则携带“这一刻的 NTP 绝对时间”和“对应的 RTP 时间戳”，接收端用这两组值把音视频流对齐到同一时间轴，从而实现唇音同步。
一个常见的部署案例是：使用 FFmpeg 拉取 RTSP 流并转推。命令如下：
ffmpeg -rtsp_transport tcp \
-i "rtsp://admin:pass123@192.168.1.64:554/Streaming/Channels/101" \
-c copy -f flv rtmp://127.0.0.1/live/cam1若此处使用 UDP 传输，在丢包网络下容易出现花屏和音画漂移；改用 TCP 交织传输可提升稳定性，但会引入一定延迟。这是部署中非常典型的取舍。
五、常见误区与复盘
- 误区一：认为 RTSP 传输音视频。实际上 RTSP 只传控制信令，音视频走 RTP，抓包时若只过滤 554 端口会看不到任何码流。
- 误区二：忽略 Session ID。SETUP 之后的所有请求都必须携带 Session 头，否则服务端返回 454 Session Not Found。
- 误区三：DESCRIBE 返回的 SDP 中 clock rate 被忽略。时钟频率是时间戳换算的基础，配置错误会直接导致同步偏差。
- 误区四：不发送 TEARDOWN。会话未释放会占用服务端连接数，长期运行可能导致新连接被拒绝。