概述

        RTSP是一种基于文本的应用层协议，使用UTF-8编码，并通过TCP或UDP传输。它并不直接传输媒体数据，而是用于控制媒体数据的传输，比如：播放、暂停、快进等操作。RTSP客户端通过发送请求到服务器，服务器则响应这些请求来执行相应的操作。

RTSP请求的结构

        RTSP请求由请求行、请求头部和请求体三个部分组成。其中，请求行是必须的，而请求头部和请求体则根据具体情况可选。

        请求行

        请求行包含一个方法、一个请求URI和一个协议版本，它们之间以空格分隔，并以CRLF（即："\r\n"）结束。

        方法：常用的RTSP方法包括OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN等。

        请求URI：标识要操作的媒体资源，格式通常为rtsp://example.com/path/to/stream。

        协议版本：表示请求遵循的RTSP协议版本，一般为RTSP/1.0或RTSP/2.0。

        下面是一个完整的请求行的示例。

PLAY rtsp://example.com//path/to/stream RTSP/1.0\r\n

        请求头部

        请求头部包含一些附加信息，比如：CSeq（用于标识请求的序列号）、Session ID（会话标识符）、Transport（传输协议）等。每个头部字段由字段名、冒号和字段值组成，各头部字段之间以CRLF分隔。

        下面是一个完整的请求头部的示例。

CSeq: 1\r\n
Content-Type: application/sdp\r\n

        请求体

        某些RTSP（比如：DESCRIBE）请求可能包含请求体，用于传输额外的数据。请求体的具体内容，取决于请求行中所使用的RTSP方法。注意：在请求头部之后，需要插入一个空行（CRLF），用于区分请求头部与请求体。

        下面是一个完整的请求体的示例。

v=0\r\n
o=- 2890844526 2890842807 IN IP4 192.168.1.1\r\n
s=RTSP Session streamed by the LIVE555 Media Server\r\n

RTSP响应的结构

        RTSP响应由状态行、响应头部和响应体三个部分组成。与请求类似，状态行是必须的，而响应头部和响应体则根据具体情况可选。

        状态行

        状态行包含一个协议版本、一个状态码和一个状态文本，它们之间由空格分隔，并以CRLF（即："\r\n"）结束。

        协议版本：表示响应遵循的RTSP协议版本，一般为RTSP/1.0或RTSP/2.0。

        状态码：三位数字，比如：200、401、500等，用于指示请求的处理结果。第一位数字代表响应类别：2xx表示成功，4xx表示客户端错误，5xx表示服务器错误。

        状态文本：简短的文字描述，解释对应状态码的具体含义，比如：OK、Unauthorized等。

        响应头部

        响应头部包含与请求头部类似的信息，比如：CSeq（用于标识请求的序列号）、Session ID（会话标识符）、Transport（传输协议）等。每个响应头部字段的格式与请求头部相同，故这里不再赘述。

        响应体

        某些RTSP响应（比如：DESCRIBE）可能包含响应体，用于传输额外的数据。注意：在响应头部之后，需要插入一个空行（CRLF），用于区分响应头部与响应体。

OPTIONS请求与响应

        OPTIONS是RTSP中的一种请求方法，主要用于客户端查询服务器支持的RTSP方法、选项以及扩展功能。发送OPTIONS请求时，客户端并不期望对媒体资源本身进行任何操作，而是希望了解服务器的能力，以便后续进行正确的交互。

        一个基本的OPTIONS请求的格式如下。

OPTIONS rtsp://example.com/path/to/stream RTSP/1.0
CSeq: <sequence-number>
[Optional Headers]<empty line>

        其中，CSeq是一个必需的头部字段，表示请求的序列号，客户端应为每个新的请求递增序列号。每个RTSP请求都必须包含一个唯一的CSeq值，以便服务器能够正确地识别和处理请求。Optional Headers是可选头部，表示可能还包括其他头部，比如：User-Agent（标识客户端软件信息）、Authorization（携带认证信息）等，视具体交互需求而定。由于OPTIONS请求不涉及媒体数据传输，因此请求体为空，请求头部末尾应有一个空行（CRLF）作为分隔。

        可选头部的字段主要包括：Require、Proxy-Require、User-Agent等。

        Require：此字段可用于指定客户端或服务器需要的特定选项或扩展。它是一个可选字段，但在某些情况下可以用来指明对特殊功能或协议扩展的支持需求。如果服务器不支持这些特性，它应该返回一个551 Option not supported错误。

        Proxy-Require：与Require类似，但专门针对代理服务器。如果请求需要通过一个或多个代理，这个字段可以用来指明代理服务器必须支持的特定功能或选项。如果服务器不支持这些特性，它应该返回一个551 Option not supported错误。

        User-Agent：用于标识发送请求的客户端类型、版本和操作系统等信息。

        服务器收到OPTIONS请求后，应返回一个OPTIONS响应，明确列出其所支持的RTSP方法和可能提供的其他信息，这有助于客户端根据服务器的实际能力来规划后续的交互步骤。

        一个基本的OPTIONS响应的格式如下。

RTSP/1.0 200 OK
CSeq: <sequence-number>
Public: <supported-methods>
[Other headers]<empty line>

        其中，CSeq是响应头部字段，与请求中的CSeq值相对应，用于标识这个响应是针对哪个请求的。CSeq的值使用请求中相同的序列号即可，用于匹配请求与响应。Public是一个响应头部字段，列出了服务器支持的所有方法，以逗号分隔。比如：“Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN”，表示服务器支持OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE和TEARDOWN这些方法。Other headers是其他可选头部，可能包括：服务器支持的特性和选项、会话管理信息、服务器名称等。同样的，OPTIONS响应不包含响应体，因此响应消息末尾有一个空行（CRLF）。

        除了Public字段，还有其他一些标准RTSP头部字段可能在OPTIONS响应中出现，提供服务器的特定特性与选项信息。

        Server：用于标识服务器软件的名称和版本，有时可能包含额外的信息（如供应商名称）。比如：“Server: RTSP Server/1.0 (Vendor XYZ)”，表示服务器软件名为“RTSP Server”，版本为“1.0”，由“Vendor XYZ”提供。

        Supported：用于列举服务器支持的非标准扩展和特性，包括特定的扩展头字段、选项或功能，以逗号进行分隔。比如：“Supported: feature1, feature2”，表示服务器支持名为“feature1”和“feature2”的非标准扩展。

        Date：提供服务器生成响应的日期和时间，有助于客户端判断响应的新鲜度或进行时间同步。Date字段的格式符合RFC 1123，比如：Sat, 06 Apr 2024 11:15:00 GMT。

        Retry-After：在服务器暂时不可用或过载时，建议客户端在指定时间段后重试请求。可以是绝对日期时间或以秒为单位的持续时间，比如：Retry-After: 120，表示120秒后重试；Retry-After: Sat, 06 Apr 2024 11:15:00 GMT，指定日期时间重试。

        服务器可能还会返回非标准的RTSP头部字段，以传达特定的特性与选项。这些字段通常以X-或Vendor-前缀开头，以避免与未来可能出现的标准头部字段冲突。这些非标准头部字段的具体含义、格式和用法，需参照服务器文档或与服务器提供商联系以获取详细信息。

X-Server-Features: featureA, featureB
Vendor-Custom-Option: value

DESCRIBE请求与响应

        DESCRIBE主要用于客户端向服务器检索有关媒体资源的描述信息。这些信息通常以SDP（Session Description Protocol）格式进行编码，描述了媒体流的诸多特性，比如：编码方式、媒体类型、时间戳、多路复用结构、网络位置等。

        一个基本的DESCRIBE请求的格式如下。

DESCRIBE rtsp://example.com/path/to/stream RTSP/1.0
CSeq: <sequence-number>
Accept: application/sdp
Other-Header: <value>CRLF

        其中，CSeq表示请求的序列号，前面已经介绍过。Accept: application/sdp表示客户端期望服务器以SDP格式回复媒体描述。Other headers是其他可选头部，可能包括：Session、Authorization等。

        Session: <session-id>，可选字段。如果客户端已有与服务器建立的会话，可以包含会话ID。

        Authorization: <authentication-info>，可选字段。如果服务器要求身份验证，则包含认证信息，比如：基于HTTP Basic或Digest的身份验证头。

        服务器收到DESCRIBE请求后，应返回一个包含所请求媒体资源详细描述的响应。响应体通常是SDP（Session Description Protocol）文本，描述了媒体的格式、网络位置、播放参数等。

        一个基本的DESCRIBE响应的格式如下。

RTSP/1.0 200 OK
CSeq: <sequence-number>
Content-Type: application/sdp
Content-Length: <length-of-sdp-body>
Other-Header: <value>CRLF
SDP Body

        其中，Content-Type指示响应体内容的MIME类型为SDP。Content-Length指定了SDP文本的字节长度，便于客户端正确解析。Other headers是其他可选头部，可能包括：Session、Server、Date、Location等。Location表示服务器会提供新的URI，客户端应向该地址重新发起请求以继续会话。Location字段可以实现类似HTTP重定向的效果，引导客户端连接到不同的服务器以获取媒体流服务，这种机制有助于实现负载均衡、故障转移或服务迁移等场景下的透明重定向。

        SDP Body是响应体，包含详细的媒体描述信息，按照SDP规范格式化。SDP格式比较复杂，我们会在后续的专栏文章中专门进行介绍。