2. RTSP协议基础

RTSP（Real Time Streaming Protocol，实时流传输协议）在推流与拉流链路中扮演的是“遥控器”角色，而不是“运输车”。它负责建立会话、协商媒体参数、控制播放状态，真正承载音视频数据的却是 RTP，传输质量反馈则由 RTCP 完成。理解这三者的分工，是后续排查推流不稳定、播放卡顿、会话中断等问题的前提。

一、RTSP 的协议定位：控制面而非数据面

RTSP 是一个应用层协议，默认使用 TCP 554 端口，语法风格接近 HTTP，采用文本化的请求—响应交互。它的核心职责是“控制”：告诉服务端我要推哪路流、用什么封装、以什么传输方式发送、什么时候开始、什么时候结束。它本身不传输音视频帧，也不保证帧的到达顺序和实时性。

可以把一次完整的 RTSP 推流会话理解为三个平面：

• 控制面（RTSP）：负责会话建立、参数协商、状态切换、会话销毁，走 TCP，强调可靠与有序。
• 数据面（RTP）：负责音视频帧的分组、打包、时间戳与序列号标记，通常走 UDP，强调实时性。
• 反馈面（RTCP）：负责发送者/接收者报告、丢包统计、抖动与往返时延反馈，用于质量监测和同步。

因此，当推流出现“连不上”时，问题往往在 RTSP 控制面；当出现“连上了但花屏、卡顿、音画不同步”时，问题更可能在 RTP/RTCP 数据面与网络层。这个判断方向能显著缩短排障路径。

二、RTSP 与 RTP/RTCP 的协作关系

三者不是并列替代关系，而是分层协作关系。RTSP 通过 SETUP 协商出 RTP/RTCP 的传输通道，通过 PLAY 触发 RTP 数据开始发送，通过 TEARDOWN 结束会话并释放通道。RTP 包中携带的 SSRC、序列号、时间戳，以及 RTCP 的 SR/RR 报告，共同支撑接收端的解码与同步。

从图中可以看到，RTSP 只负责“搭桥”，RTP 负责“跑车”，RTCP 负责“报路况”。推流稳定化的关键，是让这三层各自健康：控制面不能断，数据面不能堵，反馈面不能失真。

三、请求响应模型与常用方法

RTSP 采用客户端—服务端请求响应模型。客户端发送一行请求行（方法 + URI + 版本），随后是若干头部字段，服务端返回状态行（版本 + 状态码 + 原因）和响应头。与 HTTP 不同的是，RTSP 是有状态的：服务端会为每个会话维护 Session ID 和当前状态（INIT、READY、PLAYING、RECORDING）。

一次典型的推流会话，方法调用顺序如下：

1. OPTIONS：查询服务端支持哪些方法，确认能力集。
2. DESCRIBE：获取媒体描述（SDP），了解音视频编码、时钟频率、payload type。
3. SETUP：为每个媒体流建立传输通道，协商 RTP/RTCP 端口与传输方式，返回 Session ID。
4. PLAY：启动数据发送，进入 PLAYING 状态。
5. TEARDOWN：结束会话，释放资源。

下面是一段简化的推流交互示例，便于对照理解：

C -> S: OPTIONS rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 1

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

C -> S: DESCRIBE rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 2
        Accept: application/sdp

S -> C: RTSP/1.0 200 OK
        CSeq: 2
        Content-Type: application/sdp
        ...（SDP 描述：H.264, clock-rate=90000, AAC, clock-rate=44100）

C -> S: SETUP rtsp://192.168.1.10:554/live/test/streamid=0 RTSP/1.0
        CSeq: 3
        Transport: RTP/AVP;unicast;client_port=8000-8001

S -> C: RTSP/1.0 200 OK
        CSeq: 3
        Session: 12345678
        Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001

C -> S: PLAY rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 4
        Session: 12345678

S -> C: RTSP/1.0 200 OK
        CSeq: 4
        Session: 12345678
        RTP-Info: url=...;seq=1000;rtptime=0

C -> S: TEARDOWN rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 5
        Session: 12345678

S -> C: RTSP/1.0 200 OK
        CSeq: 5

常用方法及其作用可以归纳为下表：

四、典型场景与常见误区

在安防推流、直播转推、边缘盒子接入等场景中，RTSP 通常作为“第一跳”协议：摄像头或编码器通过 RTSP 把流推给媒体服务器，服务器再转成 RTMP、HLS、WebRTC 等协议分发。此时 RTSP 会话的稳定性直接决定后续所有分发链路的质量。

常见误区主要有三类：

• 把 RTSP 当成数据通道：误以为 RTSP 断开会立刻导致画面停止。实际上若 RTP 通道仍在，画面可能继续，但控制指令已失效，无法暂停或结束。
• 忽略 Session ID 的作用：SETUP 之后所有请求都必须携带 Session 头，否则服务端返回 454 Session Not Found。
• DESCRIBE 与 SETUP 顺序颠倒：未获取 SDP 就 SETUP，服务端无法确定媒体流数量与编码参数，通常返回 455 Method Not Valid In This State。