RTSP协议

1 前言

RTSP协议作为音视频实时监控一个非常重要的协议，具有非常广泛的应用。RTSP由RFC 2326规范化，它允许客户端通过请求不同的媒体资源来控制流媒体服务器。RTSP是一种应用层协议，通常基于TCP连接，用于建立和控制媒体会话。这使得RTSP成为了许多实时流媒体应用的核心组成部分，包括视频会议、IP摄像头、流媒体服务器等。本文将深入探讨RTSP协议的原理、交互流程、高级用法以及如何进行抓包分析。

2 RTSP协议

RTSP协议定义主要是是在RFC2326规定，这是一个文本类的协议，用于控制实时的音视频流的传输协议。

2.1 RTSP协议交互流程

将重点讨论协议协商的过程，RTSP采用的是服务器客户端的模式，一个服务器可以承载多个客户端同时连接。这里需要注意的是服务器一直监听某个端口默认端口554。客户端发起TCP连接后即开始进行RTSP协商。下图是一个基本的RTSP协商流程：

1. OPTIONS：
   客户端行为：客户端发送OPTIONS请求，以了解服务器支持哪些方法。
   服务器响应：服务器将支持的方法列表包含在响应中，这有助于客户端了解服务器的功能。
2. DESCRIBE：
   客户端行为：客户端发送DESCRIBE请求，以获取关于媒体资源的描述信息，如编码、分辨率等。
   服务器响应：服务器返回媒体资源的描述信息，通常是SDP（会话描述协议）格式，包括媒体流的属性和相关参数。
3. SETUP：
   客户端行为：客户端发送SETUP请求，用于建立媒体会话，指定传输通道，如UDP或TCP，并请求分配端口。
   服务器响应：服务器确认SETUP请求，指定了媒体流的传输通道和端口，允许客户端与服务器建立连接。
4. PLAY：
   客户端行为：客户端发送PLAY请求，以开始媒体流的播放。
   服务器响应：服务器确认PLAY请求，并启动媒体流的传输。
5. GET_PARAMETER：
   客户端行为：客户端发送GET_PARAMETER请求，以获取有关媒体会话的参数信息，如媒体流的播放状态或其他参数。
   服务器响应：服务器通常返回与GET_PARAMETER请求相关的参数信息。
6. TEARDOWN：
   客户端行为：客户端发送TEARDOWN请求，以终止媒体会话，停止播放并释放资源。
   服务器响应：服务器确认TEARDOWN请求，关闭会话并释放与媒体流相关的资源。

2.2 RTSP媒体描述

RTSP协商核心的流程是媒体信息的交换，主要是通过DESCRIBE请求来完成。服务器是通过SDP将媒体信息回复给客户端，这里主要是携带媒体的信息，分为音频和视频两部分。

音频媒体描述字段：

m=（媒体行）：指定媒体类型，通常为"audio"，以及用于传输媒体的协议和端口号。例如：m=audio 5004 RTP/AVP 0，表示音频流使用RTP协议在端口5004上传
输，媒体格式为0（通常对应PCMU或G.711u编码）。
a=rtpmap（RTP映射）：指定RTP负载类型（Payload Type）和媒体格式。例如：a=rtpmap:0 PCMU/8000，表示Payload Type为0的RTP流使用PCMU编码，采样率
为8000Hz。
a=control（控制URL）：指定控制媒体流的URL。例如：a=control:audio，表示控制音频流的URL。
a=recvonly（只接收）：指定该媒体流为只接收模式，表示该端只接收媒体，不发送。例如：a=recvonly。

视频媒体描述字段：

m=（媒体行）：指定媒体类型，通常为"video"，以及用于传输媒体的协议和端口号。例如：m=video 5006 RTP/AVP 96，表示视频流使用RTP协议在端口5006上
传输，媒体格式为96（通常对应H.264编码）。
a=rtpmap（RTP映射）：指定RTP负载类型（Payload Type）和媒体格式。例如：a=rtpmap:96 H264/90000，表示Payload Type为96的RTP流使用H.264编码，
时钟速率为90000。
a=control（控制URL）：指定控制媒体流的URL。例如：a=control:video，表示控制视频流的URL。
a=recvonly（只接收）：指定该媒体流为只接收模式，表示该端只接收媒体，不发送。例如：a=recvonly。

这些字段描述了媒体流的基本信息，包括媒体类型、传输协议、端口号、编码格式、时钟速率等。这些描述对于RTSP客户端和服务器之间的媒体会话建立和控制非常重要，因为它们帮助确定如何处理媒体数据以及如何与媒体流进行交互。不同的媒体格式和参数可能会导致不同的媒体流配置。

2.3 RTSP端口协商

SETUP命令的主要作用是建立媒体会话的传输通道，它告知服务器客户端希望使用什么协议和端口来接收媒体流。服务器会响应SETUP请求，确认媒体会话的建立，并提供了实际的传输通道信息，以便客户端开始接收媒体流。
音频SETUP：
客户端：
音频SETUP请求用于建立音频媒体会话的传输通道。以下是音频SETUP请求的一般形式：

SETUP rtsp://server-address/audio-resource RTSP/1.0
CSeq: [Sequence Number]
Transport: RTP/AVP;unicast;client_port=5000-5001
rtsp://server-address/audio-resource：指定音频资源的URL路径。

Transport: RTP/AVP：这部分说明音频传输使用的协议和配置，通常为RTP/AVP，表示使用RTP传输协议。
client_port=5000-5001：客户端指定了用于接收音频的端口范围，即5000到5001，这意味着服务器应该将音频流发送到这个端口范围。
服务器：
服务器将响应音频SETUP请求，确认了传输通道的建立，并提供实际的传输参数，如服务器分配的端口号。

RTSP/1.0 200 OK
CSeq: [与请求中的CSeq相同]
Transport: RTP/AVP;unicast;client_port=5000-5001;server_port=6000-6001

视频SETUP：
客户端：
视频SETUP请求用于建立视频媒体会话的传输通道。以下是视频SETUP请求的一般形式：

SETUP rtsp://server-address/video-resource RTSP/1.0
CSeq: [Sequence Number]
Transport: RTP/AVP;unicast;client_port=6000-6001
rtsp://server-address/video-resource：指定视频资源的URL路径。

Transport: RTP/AVP：这部分说明视频传输使用的协议和配置，通常为RTP/AVP，表示使用RTP传输协议。
client_port=6000-6001：客户端指定了用于接收视频的端口范围，即6000到6001，这意味着服务器应该将视频流发送到这个端口范围。

服务器：
服务器将响应视频SETUP请求，确认了传输通道的建立，并提供实际的传输参数，如服务器分配的端口号。

RTSP/1.0 200 OK
CSeq: [与请求中的CSeq相同]
Transport: RTP/AVP;unicast;client_port=6000-6001;server_port=7000-7001

2.4 RTSP 播放确认

RTSP（实时流媒体传输协议）中的PLAY字段用于启动或继续媒体流的播放。它是RTSP协议的一种请求命令，通常在SETUP之后用于开始媒体流的传输。以下是PLAY字段的详细解释：
客户端：
PLAY命令格式：PLAY命令通常以如下的格式发送到RTSP服务器：

PLAY rtsp://server-address/resource RTSP/1.0
CSeq: [Sequence Number]
Session: [Session ID]
Range: [播放范围]

rtsp://server-address/resource：这是RTSP服务器的地址和媒体资源的路径。客户端通过此URL指定要播放的资源。
RTSP/1.0：指定了使用的RTSP协议版本。
CSeq：用于命令序列的计数器，以确保命令的顺序性和唯一性。
Session：在SETUP请求成功建立媒体会话后，服务器分配的会话ID，以标识正在播放的会话。
Range：可选字段，用于指定播放的时间范围。这允许客户端进行时间范围内的媒体流播放，如跳转到某个时间点或从某个时间点开始播放。
服务器：
PLAY命令的响应通常遵循RTSP协议的响应格式，以确认播放操作并提供相关信息。以下是PLAY响应的一般格式：

RTSP/1.0 200 OK
CSeq: [与请求中的CSeq相同]
Session: [Session ID]
RTP-Info: [媒体信息]

RTSP/1.0 200 OK：这表示服务器成功接受并处理了PLAY请求，通信正常。
CSeq：响应中的CSeq与请求中的CSeq相同，以维护命令的顺序性。
Session：在SETUP请求成功建立媒体会话后，服务器分配的会话ID，以标识正在播放的会话。这个会话ID是客户端和服务器之间识别会话的关键。
RTP-Info：这是一个可选字段，它包含有关媒体流的信息，如媒体流的SSRC（同步信源标识符）和RTP序列号。这些信息可以用于帮助客户端更好地解析和处理媒体流。

2.5 异常流程

在RTSP（实时流媒体传输协议）中，异常流程通常涉及客户端或服务器遇到问题时，通过特定的状态码来表示错误或异常情况。以下是一些常见的RTSP状态码，用于标识异常流程的情况。状态代码的第一位数字定义了响应的类别。这最后两位数字没有任何分类作用。有 5 个
第一个数字的值：具体状态码需要查RFC2326文档。

1xx：信息 - 已收到请求，正在继续处理
2xx：成功 - 操作已成功接收、理解，并接受
3xx：重定向 - 必须采取进一步的操作才能完成请求
4xx：客户端错误 - 请求包含错误语法或无法实现了
5xx：服务器错误 - 服务器未能完成明显的任务有效请求

3 RTSP高级用法

3.1 RTSP over TCP

RTSP over TCP允许使用可靠的TCP连接来进行RTSP握手和媒体传输，与RTSP over UDP相比，具有更高的可靠性和更容易穿越防火墙和代理服务器。在协商过程中，主要差异包括TCP连接的建立，Transport字段的参数以及双工通道的使用。这种方式适用于需要可靠传输和高级控制的实时流媒体应用。RTSP over TCP采用与默认的UDP传输音视频不一样的地方是，音视频也是走服务器端口，比如是554公用一个连接进行数据的传输。协商主要是在SETUP字段上完成。
RTSP over TCP传输格式：

SETUP rtsp://server-address/resource/trackID RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;interleaved=[双数开始的RTP通道号]-[双数开始的RTCP通道号]

注意，RTSP over TCP使用Transport字段的RTP/AVP/TCP参数来指示TCP传输，而interleaved参数指示了双工通道的RTP和RTCP通道号。
RTSP over UDP传输格式：

SETUP rtsp://server-address/video-resource RTSP/1.0
CSeq: [Sequence Number]
Transport: RTP/AVP;unicast;client_port=6000-6001

媒体数据封装，RTSP over TCP采用的是Magic头部来进行音视频数据的区分，一般第一个字节是固定的 Magic:0x24；第二个字节是指定媒体的通道，第三和第四个字节是指定RTP包的长度，一般不用，直接用Magic头进行分割。
所描述的 “Interleaved Channel” 头部是一种特定于 RTSP over TCP 的私有协议扩展，用于标识和传输 RTP 和 RTCP 数据。这个头部的格式如下：

第一个字节（byte 1）为 '$'，通常用作 Interleaved Channel 的开始标志。
第二个字节（byte 2）用于指示通道的 ID，其取值由 RTSP-SETUP 消息中确定。
通常，0 表示视频的 RTP 数据，1 表示视频的 RTCP 数据，2 表示音频的 RTP 数据，3 表示音频的 RTCP 数据。
第三和第四个字节（byte 3-4）用于指示 RTP 包的长度

4 抓包分析

rtsp协商过程中抓包分析是一个非常重要的手段，很多时候兼容性问题都需要通过wareshark进行抓包分析，首先抓包后第一步是利用流追踪将抓包转换为文本流进一步分析，下面是rtsp over tcp的一个抓包。

从抓包中可以看出，这里做了两次options操作，第一次没有携带账号密码，服务器回复了401,第二次客户端带上账号密码才协商成功。
RTSP over TCP协商主要体现在SETUP字段。

下面是一个完整的RTSP over UDP的协商过程：

OPTIONS rtsp://192.168.88.101:554/ch0 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)RTSP/1.0 200 OK
CSeq: 2
Date: Sun, Jun 25 2023 01:16:55 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETERDESCRIBE rtsp://192.168.88.101:554/ch0 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdpRTSP/1.0 200 OK
CSeq: 3
Date: Sun, Jun 25 2023 01:16:55 GMT
Content-Base: rtsp://192.168.88.101/ch0/
Content-Type: application/sdp
Content-Length: 605v=0
o=- 1687655781765442 1 IN IP4 192.168.88.101
s=face recognition live
i=LIVE555 Streaming Media v2023.05.10
t=0 0
a=tool:LIVE555 Streaming Media v2023.05.10
a=type:broadcast
a=control:*
a=range:npt=now-
a=x-qt-text-nam:face recognition live
a=x-qt-text-inf:LIVE555 Streaming Media v2023.05.10
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:100
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640033;sprop-parameter-sets=Z2QAM6zoBQBbJsgAAB9AAAdTBCA=,aO48sA==
a=control:track1
m=audio 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:100
a=rtpmap:96 PCMA/8000
a=control:track2
SETUP rtsp://192.168.88.101/ch0/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=52624-52625RTSP/1.0 200 OK
CSeq: 4
Date: Sun, Jun 25 2023 01:16:55 GMT
Transport: RTP/AVP;unicast;destination=192.168.88.171;source=192.168.88.101;client_port=52624-52625;server_port=6970-6971
Session: 71F8DA1A;timeout=65SETUP rtsp://192.168.88.101/ch0/track2 RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=52626-52627
Session: 71F8DA1ARTSP/1.0 200 OK
CSeq: 5
Date: Sun, Jun 25 2023 01:16:55 GMT
Transport: RTP/AVP;unicast;destination=192.168.88.171;source=192.168.88.101;client_port=52626-52627;server_port=6972-6973
Session: 71F8DA1A;timeout=65PLAY rtsp://192.168.88.101/ch0/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Session: 71F8DA1A
Range: npt=0.000-RTSP/1.0 200 OK
CSeq: 6
Date: Sun, Jun 25 2023 01:16:55 GMT
Range: npt=0.000-
Session: 71F8DA1A
RTP-Info: url=rtsp://192.168.88.101/ch0/track1;seq=50270;rtptime=1941266457,url=rtsp://192.168.88.101/ch0/track2;seq=32464;rtptime=2232875491TEARDOWN rtsp://192.168.88.101/ch0/ RTSP/1.0
CSeq: 7
User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
Session: 71F8DA1ARTSP/1.0 200 OK
CSeq: 7
Date: Sun, Jun 25 2023 01:17:02 GMT