RTSP协议文档摘录（一）

吴自牧

已于 2024-04-15 10:17:12 修改

阅读量597

点赞数 19

文章标签：网络实时音视频 c语言 c++

于 2024-04-12 11:17:02 首次发布

本文链接：https://blog.csdn.net/weixin_49621395/article/details/137671538

版权

一、RTSP协议------简介

在学习网络相关协议的时候，可以参考RFC文档来初步了解协议内容，关键字等。RTSP协议介绍主要用于控制实时数据的传输，它并不传输数据，而是对实时数据传输进行一个控制。

附上原文档链接：RFC 2326 - Real Time Streaming Protocol (RTSP)

实时流协议（RTSP）是一种应用级协议，用于控制实时数据的传输。RTSP提供了一个可扩展的框架，以实现实时数据（如音频和视频）的受控、按需传输。数据源可以包括实时数据源和存储片段。该协议旨在控制多个数据传输会话，提供UDP、多播UDP和TCP等传输通道的手段，并提供一种基于RTP的发送机制选择方法（RFC 1889）。

1、目的

实时流协议（RTSP）建立并控制连续媒体（如音频和视频）的单个或多个时间同步流。它通常不传送连续流本身，尽管连续媒体流与控制流的交织是可能的（参见第10.12节）。换句话说，RTSP充当多媒体服务器的“网络遥控器”。

要控制的流集由表示描述定义。本备忘录并未规定陈述说明的格式。

没有RTSP连接的概念；相反，服务器维护由标识符标记的会话。RTSP会话决不与传输级连接（如TCP连接）绑定。在RTSP会话期间，RTSP客户端可以打开和关闭到服务器的许多可靠传输连接，以发出RTSP请求。

或者，它可以使用诸如UDP之类的无连接传输协议。

由RTSP控制的流可以使用RTP[1]，但是RTSP的操作不依赖于用于承载连续介质的传输机制。该协议有意在语法和操作上与HTTP/1.1[2]相似，因此在大多数情况下，HTTP的扩展机制也可以添加到RTSP中。但是，RTSP在许多重要方面与HTTP不同：

RTSP引入了许多新方法，并具有不同的协议标识符。
RTSP服务器在几乎所有情况下都需要缺省地维护状态，这与HTTP的无状态特性相反。
RTSP服务器和客户端都可以发出请求。

数据通过不同的协议在带外传输(有一个例外。）

RTSP被定义为使用iso10646（UTF-8）而不是iso8859-1，这与当前的HTML国际化工作一致[3]。

请求URI始终包含绝对URI。由于向后兼容历史错误，HTTP/1.1[2]只在请求中携带绝对路径，并将主机名放在单独的头字段中。

这使得“虚拟主机”更容易，一个IP地址的主机托管多个文档树。

1.1、从媒体服务器检索媒体

客户机可以通过HTTP或其他方法请求表示描述。（如网络通信TCP）如果呈现是多播的，则呈现描述包含用于连接媒体的多播地址和断开。如果演示文稿仅通过单播发送给客户端，出于安全原因，客户端将提供目的地。

1.2、邀请媒体服务器参加会议

可以”邀请“媒体服务器加入现有会议，将媒体播放到演示文稿中，或在演示文稿中录制所有或部分媒体。这种模式适用于分布式教学应用。

1.3、向现有演示文稿添加媒体

特别是对于现场演示文稿，如果服务器能够告诉客户机更多可用媒体，则此功能非常有用。

2、术语

2.1、聚合控制

服务器使用单个时间线控制多个流。对于音频/视频源，这意味着客户端可以发出单个播放或暂停消息来控制音频和视频源。

2.2、会议

一种多方多媒体演示，其中“multi”表示大于或等于一。

2.3、客户

客户端从媒体服务器请求连续的媒体数据。

2.4、连接

一种传输层虚拟电路，在两个程序之间建立，用于通信。

2.5、容器文件

一种文件，可包含多个媒体流，当一起播放时，这些媒体流通常构成一个表示。RTSP服务器可以提供对这些文件的聚合控制，尽管在协议中没有嵌入容器文件的概念。

2.6、连续介质

源和接收器之间存在定时关系的数据；也就是说，接收器必须复制源中存在的时间关系。连续媒体最常见的例子是音频和运动视频。连续媒体可以是实时（交互式），在这种情况下源和接收器之间存在“紧”的定时关系，或者流（回放），其中关系不那么严格。

2.7、实体

作为请求或响应的有效载荷而传送的信息。实体由实体标题字段的形式的元信息和实体实体形式的内容组成，如第8节所述。

2.8、媒体初始化

特定于数据类型/编解码器的初始化。这包括诸如时钟速率、颜色表等事物。客户端回放媒体流所需的任何与传输无关的信息都发生在流设置的媒体初始化阶段。

2.9、介质参数

特定于媒体类型的参数，该类型可能在流播放之前或播放期间更改。

2.10、媒体服务器

为一个或多个媒体流提供回放或录制服务的服务器。呈现中的不同媒体流可以来自不同的媒体服务器。媒体服务器可以与调用表示的web服务器驻留在同一个或不同的主机上。

2.11、媒体服务器间接寻址

将媒体客户端重定向到不同的媒体服务器。

2.12、（媒体）流

单个媒体实例，例如音频流或视频流以及单个白板或共享应用程序组。使用RTP时，流由RTP会话中源创建的所有RTP和RTCP包组成。这相当于DSM-CC流的定义（[5]）。

2.13、信息

RTSP通信的基本单元，由符合第15节中定义的语法的八位字节的结构化序列组成，并通过连接或无连接协议传输。

2.14、参与者

会议成员。参与者可以是机器，例如，媒体记录或回放服务器。

2.15、演示

一组一个或多个流，作为一个完整的媒体源呈现给客户机，使用下面定义的呈现描述。在RTSP上下文中的大多数情况下，这意味着对这些流的聚合控制，但不必这样做。

2.16、演示文稿说明

演示文稿描述包含演示文稿中一个或多个媒体流的信息，例如编码集、网络地址和有关内容的信息。其他IETF协议，如SDP（RFC 2327[6]）使用术语“session”进行实时演示。演示文稿描述可以采用几种不同的格式，包括但不限于会话描述格式SDP。

2.17、答复

RTSP响应。如果表示HTTP响应，则显式指示。

2.18、请求

RTSP请求。如果一个HTTP请求是有意的，那么它是显式的。

2.19、RTSP会话

一个完整的RTSP“事务”，例如观看电影。会话通常由一个客户端组成，为连续媒体流设置传输机制（SETUP），用PLAY或RECORD启动流，用TEARDOWN关闭流。

2.20、传输初始化

客户机和服务器之间传输信息（如端口号、传输协议）的协商。

3、协议属性

可扩展：新的方法和参数可以很容易地添加到RTSP。
易于分析：RTSP可以由标准HTTP或MIME解析器解析。
安全：RTSP重新使用web安全机制。所有HTTP认证机制，如basic（rfc2068[2，第11.1节]）和digest认证（rfc2069[8]），都可以直接应用。还可以重用传输层或网络层安全机制。
独立运输：RTSP可以使用不可靠数据报协议（UDP）（RFC 768[9]）、可靠数据报协议（RDP，RFC 1151，未广泛使用[10]）或可靠流协议（例如TCP）（RFC 793[11]）来实现应用程序级可靠性。
支持多服务器：演示文稿中的每个媒体流都可以驻留在不同的服务器上。客户端会自动与不同媒体服务器建立多个并发控制会话。介质同步在传输级别执行。
记录设备的控制：该协议可以控制记录和回放设备，以及可以在两种模式之间切换的设备（“VCR”）。
流控制和会议启动分离：流控制与邀请媒体服务器参加会议是分离的。唯一的要求是会议发起协议提供或可用于创建唯一的会议标识符。特别地，SIP[12]或H.323[13]可用于邀请服务器参加会议。
适合专业应用：RTSP通过SMPTE时间戳支持帧级精度，以允许远程数字编辑。
演示文稿描述中性：该协议不强制使用特定的表示描述或元文件格式，并且可以传递要使用的格式类型。但是，表示说明必须至少包含一个RTSP URI。
代理和防火墙友好：应用层和传输层（SOCKS[14]）防火墙都应该很容易处理该协议。防火墙可能需要了解为UDP媒体流打开“漏洞”的设置方法。
HTTP友好：在合理的情况下，RTSP重用HTTP概念，这样就可以重用现有的基础设施。这个基础设施包括PICS（互联网内容选择平台[15,16]），用于将标签与内容相关联。然而，RTSP并不只是向HTTP添加方法，因为在大多数情况下，控制连续介质需要服务器状态。
适当的服务器控制：如果客户机可以启动流，那么它必须能够停止流。服务器不应以客户端无法停止流的方式开始流式传输到客户端。
运输谈判：客户端可以在实际需要处理连续媒体流之前协商传输方法。
能力谈判：如果基本特性被禁用，那么客户端必须有一些干净的机制来确定哪些方法将不被实现。这允许客户端呈现适当的用户界面。例如，如果不允许搜索，则用户界面必须能够禁止移动滑动位置指示器。

RTSP的早期需求是多客户机功能。但是，确定更好的方法是确保协议易于扩展到多客户机场景。流标识符可由多个控制流使用，因此“通过远程”将是可能的。该协议不会解决多个客户端如何协商访问的问题；这是留给一个“社会协议”或其他一些楼层控制机制。

4.扩展RTSP

由于并非所有媒体服务器都具有相同的功能，因此媒体服务器必然会支持不同的请求集。

例如：

服务器可能只能回放，因此不需要支持记录请求。
如果服务器仅支持实时事件，则可能无法查找（绝对定位）。
有些服务器可能不支持设置流参数，因此不支持GET_参数和SET_u参数。
服务器应该实现第12节中描述的所有头字段。

不去问服务器的不可能，这取决于演示描述的创建者。这种情况在HTTP/1.1[2]中类似，在HTTP/1.1[2]中，不太可能在所有服务器上都支持[H19.6]中描述的方法。

RTSP可以通过三种方式进行扩展，下面按支持的更改的大小顺序列出：

只要收件人可以安全地忽略这些参数，就可以使用新参数扩展现有方法(这相当于向HTML标记添加新参数。）如果客户端在不支持方法扩展时需要否定确认，则可以在Require:字段中添加与该扩展对应的标记（参见第12.32节）。
可以添加新方法。如果消息的接收者不理解请求，它将以错误代码501（未实现）响应，发送者不应再次尝试使用此方法。客户机还可以使用OPTIONS方法来查询服务器支持的方法。服务器应该列出它支持的使用公共响应头的方法。
可以定义协议的新版本，允许几乎所有方面（除了协议版本号的位置）发生更改。

5.整体操作

每个呈现和媒体流可以由rtspurl标识。整个演示文稿和演示文稿所用媒体的属性由演示文稿描述文件定义，其格式不在本规范的范围内。呈现描述文件可以由客户端使用HTTP或诸如电子邮件之类的其它方式获得，并且不必存储在媒体服务器上。

为了本说明书的目的，假设呈现描述描述一个或多个呈现，其中每个呈现保持公共时间轴。为了说明的简单性和不丧失一般性，假设呈现描述正好包含一个这样的呈现。一个表示可以包含多个媒体流。

表示描述文件包含构成表示的媒体流的描述，包括它们的编码、语言和其他参数，这些参数使客户端能够选择最合适的媒体组合。在该表示描述中，RTSP单独控制的每个媒体流由RTSP URL标识，RTSP URL指向处理该特定媒体流的媒体服务器并命名存储在该服务器上的流。多个媒体流可以位于不同的服务器上；

例如，音频和视频流可以跨服务器分割以进行负载共享。描述还列举了服务器能够使用的传输方法。

除了媒体参数外，还需要确定网络目标地址和端口。可以区分几种操作模式：

单播：媒体被传输到RTSP请求的源，端口号由客户机选择。或者，媒体在与RTSP相同的可靠流上传输。
多播，服务器选择地址：媒体服务器选择多播地址和端口。这是现场或近媒体点播传输的典型案例。
多播，客户端选择地址：如果服务器要参与现有的多播会议，则多播地址、端口和加密密钥由会议描述给出，通过本规范范围之外的方式建立。

6.RTSP状态

RTSP控制可以通过独立于控制信道的单独协议发送的流。

例如，当数据通过UDP流动时，TCP连接上可能会发生RTSP控制。因此，即使媒体服务器未接收到RTSP请求，数据传递仍在继续。此外，在其生命周期内，单个媒体流可以由在不同TCP连接上依次发出的RTSP请求控制。因此，服务器需要保持“会话状态”，以便能够将RTSP请求与流关联起来。状态转换在A节中描述。

RTSP中的许多方法对状态没有贡献。

但是，以下内容在定义服务器上流资源的分配和使用时起着中心作用：设置、播放、录制、暂停和拆卸。

设置：使服务器为流分配资源并启动RTSP会话。setup
播放和录制：在通过安装程序分配的流上开始数据传输。play
暂停：暂时停止流而不释放服务器资源。pause
拆卸：释放与流关联的资源。服务器上不再存在RTSP会话。teardown

有助于状态的RTSP方法使用会话头字段（第12.37节）来标识其状态正在被操纵的RTSP会话。服务器根据设置请求生成会话标识符（第10.4节）。

7.与其他协议的关系

RTSP在功能上与HTTP有一些重叠。它还可以与HTTP交互，因为与流内容的初始接触通常是通过网页进行的。当前协议规范的目的是允许web服务器和实现RTSP的媒体服务器之间的不同切换点。

例如，可以使用HTTP或RTSP检索演示文稿描述，这减少了基于web浏览器的场景中的往返，但也允许独立的RTSP服务器和根本不依赖HTTP的客户端。

然而，RTSP与HTTP的根本不同之处在于，数据传输是在不同的协议中在带外进行的。

HTTP是一种非对称协议，客户端发出请求，服务器响应。
在RTSP中，媒体客户端和媒体服务器都可以发出请求。
RTSP请求也不是无状态的；它们可以设置参数并在请求被确认之后很长时间内继续控制媒体流。

重用HTTP功能至少在两个方面有优势，即安全性和代理。这些要求非常相似，因此能够在缓存、代理和身份验证上采用HTTP是很有价值的。

虽然大多数实时媒体将使用RTP作为传输协议，但RTSP并不与RTP绑定。

RTSP假设存在一种表示描述格式，该格式可以表示包含多个媒体流的表示的静态和时间属性。

二、RTSP协议------协议参数（原文第三章）

1、RTSP版本

【H3.1】applies，with HTTP replaced by RTSP

2、RTSP URL

“rtsp”和“rtspu”方案用于通过rtsp协议引用网络资源。本节定义rtspurl的特定于方案的语法和语义。

请注意，片段标识符和查询标识符此时没有明确定义的含义，解释权留给RTSP服务器。

方案rtsp要求通过可靠的协议（在Internet中，TCP）发出命令，而方案rtspu标识不可靠的协议（在Internet中，UDP）。

如果端口为空或未给定，则假定端口554。

其语义是，所标识的资源可以由服务器上的RTSP控制，该服务器侦听该主机端口上的TCP（方案“RTSP”）连接或UDP（方案“rtspu”）数据包，并且资源的请求URI是RTSP_URL。

应尽可能避免在URL中使用IP地址（见RFC1924[19]）。

表示或流由文本媒体标识符标识，使用url的字符集和转义约定[H3.2]（RFC 1738[20]）。url可指流或流的集合，即表示。因此，第10节中描述的请求可以应用于整个呈现或者呈现中的单个流。请注意，某些请求方法只能应用于流，不能应用于表示，反之亦然。

例如，RTSP URL:

rtsp://media.example.com：554/twister/audiotrack

标识演示文稿“扭曲器”中的音频流，可通过TCP连接到host media.example.com端口554发出的RTSP请求来控制。

此外，RTSP URL：

rtsp://media.example.com:554/twister

标识表示“twister”，它可能由音频和视频流组成。

这并不意味着在URL中引用流的标准方法。表示描述定义了表示中的层次关系以及各个流的url。表示描述可以将流命名为“A.mov”，而将整个表示命名为“b.mov”。

rtspurl的路径组件对客户端来说是不透明的，并不意味着服务器有任何特定的文件系统结构。

这种解耦还允许通过替换URL中的方案，将表示描述与非RTSP媒体控制协议一起使用。

3、会议标识符

会议标识符对RTSP是不透明的，并且使用标准URI编码方法进行编码（即，LWS用%转义）。它们可以包含任何八进制值。会议标识符必须全局唯一。对于H.323，将使用conferenceID值。

conference-id = 1*xchar

会议标识符用于允许RTSP会话从媒体服务器参与的多媒体会议中获取参数。这些会议是由本规范范围之外的协议创建的，例如H.323[13]或SIP[12]。例如，它不显式地提供传输信息的RTSP客户端，而是要求媒体服务器使用会议描述中的值。

4.会话标识符

会话标识符是任意长度的不透明字符串。必须转义线性空白。会话标识符必须随机选择，并且必须至少有8个八位字节长，以增加猜测的难度(见第16节。）

session-id = 1*( ALPHA | DIGIT | safe )

5.SMPTE相对时间戳

SMPTE相对时间戳表示相对于片段开始的时间。相对时间戳表示为SMPTE时间码，用于帧级访问精度。

时间代码的格式为hours:minutes:seconds:frames.subframes，原点位于片段的开头。

默认的smpte格式为“smpte 30 drop”格式，帧速率为29.97帧/秒。

通过使用“SMPTE time”的替代用法，可以支持其他SMPTE码（例如“SMPTE 25”）。

对于“帧”，时间值中的“帧”字段可以假定值0到29。每秒30帧和29.97帧之间的差异是通过删除每分钟的前两个帧索引（值00和01）来处理的，但每十分钟除外。如果帧值为零，则可以省略。子帧是以帧的百分之一来度量的。

例如：

6.正常播放时间

正常播放时间（NPT）表示相对于演示开始的流绝对位置。

时间戳由小数部分组成。小数点后的部分可以用秒或小时、分钟和秒表示。小数点右边的部分是一秒钟的分数。

演示文稿的开头对应于0.0秒。未定义负值。特殊常量现在定义为活动事件的当前瞬间。它只能用于现场活动。

NPT在DSM-CC中被定义为：“直观地说，NPT是观察者与程序关联的时钟。它通常以数字方式显示在录像机上。

当处于正常播放模式（比例=1）时，NPT正常前进；
当处于快速向前扫描（高正比例比）时，NPT以更快的速度前进；
当处于反向扫描（高负比例比）时，NPT递减；
当处于暂停模式时，NPT固定。NPT（逻辑上）等同于 SMPTE时间码

例如：

语法符合ISO 8601。npt sec符号优化为自动生成，ntp HHMMS符号供人类读者使用。“现在”常量允许客户端请求接收实时提要，而不是存储或延迟的版本。这是必要的，因为绝对时间和零时间都不适合这种情况。

7.绝对时间

绝对时间表示为ISO 8601时间戳，使用UTC（GMT）。可以指示秒的分数。

例如，1996年11月8日14时37分和20分之一秒UTC：

19961108T143720.25Z

8.选项标记

选项标记是用于在RTSP中指定新选项的唯一标识符。这些标签用于Require（第12.32节）和Proxy Require（第12.27节）标题字段。

语法：

新RTSP选项的创建者应在该选项的前缀中添加反向域名（例如，“com.foo.mynewfeature”是可在“foo.com”上找到发明人的功能的apt名称），或者向Internet分配号码颁发机构（IANA）注册新选项。

8.1向IANA注册新选项标记

注册新的RTSP选项时，应提供以下信息：

选项的名称和说明。名称可以任意长度，但长度不得超过20个字符。名称不能包含任何空格、控制字符或句点。
指明谁对该方案拥有变更控制权（例如，IETF、ISO、ITU-T、其他国际标准化机构、联合体或特定公司或公司集团）；
对进一步描述的引用，如可用，例如（按优先顺序）RFC、已发表论文、专利申请、技术报告、记录的源代码或计算机手册；
对于专有选项，请提供联系信息（邮政和电子邮件地址）；

三、RTSP协议------RTSP消息（原文第四章）

RTSP是一种基于文本的协议，使用UTF-8编码中的ISO 10646字符集（RFC 2279[21]）。

行由CRLF终止，但是接收器也应该准备好将CR和LF本身解释为行终止符。

基于文本的协议使得以自描述的方式添加可选参数变得更容易。由于参数的数目和命令的频率较低，处理效率不受关注。基于文本的协议，如果做得仔细的话，还可以用脚本语言（如Tcl、visualbasic和Perl）轻松实现研究原型。

10646字符集避免了复杂的字符集切换，但只要使用US-ASCII，应用程序就看不到它。这也是用于RTCP的编码。iso8859-1直接翻译成具有高阶八位字节零的Unicode。具有最高有效位集的ISO 8859-1字符表示为1100001x 10xxxxxx(参见RFC 2279[21]）

        ISO 10646字符集（即Universal Character Set，UCS）是Unicode标准的基础，它统一了全球各种字符集的表示方式，从而避免了不同字符集之间切换的复杂性。这意味着使用UCS或Unicode的应用程序可以处理世界上几乎所有的字符，而不需要针对特定语言或地区进行复杂的字符集转换。
        US-ASCII与Unicode兼容性：US-ASCII是7位字符集，只包含128个字符，对于ASCII字符集中的字符，其编码在Unicode中保持一致，所以只要应用仅处理ASCII字符，那么无论底层是ASCII还是Unicode编码，应用程序都不会感知到区别。
        ISO 8859-1与Unicode转换：ISO 8859-1（也称为Latin-1）是一个单字节编码方案，其中前128个字符与ASCII相同，后128个字符用于扩展欧洲语言的特殊符号和字母。当从ISO 8859-1向Unicode转换时，ISO 8859-1中的每个字符可以直接映射为Unicode中的相应位置，且对于那些落在ISO 8859-1编码范围内的字符（即0x00至0xFF），转换相当直接，高位字节部分会被设置为0，然后整个数值作为Unicode的一个字符来表示。
        高阶八位字节零的Unicode表示：按照RFC 2279所述，对于ISO 8859-1中具有最高有效位（即第8位）被设置为1的字符（也就是非ASCII扩展部分的字符，它们的编码范围是0x80至0xFF），在转换为Unicode时，会采用两个字节的形式来表示，形式为110xxxxx 10yyyyyy（即UTF-8编码格式的一部分）。这里描述的不是直接转换为Unicode的高阶字节为零的情况，而是指出了ISO 8859-1中非ASCII字符如何在多字节编码如UTF-8中得到体现。
        总结来说，这段话主要强调了Unicode如何通过兼容ASCII及简单转换ISO 8859-1编码来简化国际字符的处理，并提到了ISO 8859-1字符在转换成Unicode时的具体表示方法。

RTSP消息可以通过任何8位干净的低层传输协议传输。

请求包含方法、方法所操作的对象以及进一步描述方法的参数。方法是幂等的，除非另有说明。方法也被设计成只需要很少或不需要在媒体服务器上进行状态维护。

1、消息长度

当消息正文包含在消息中时，该正文的长度由以下内容之一（按优先顺序）确定：

任何不包括消息正文的响应消息（例如1xx、204和304响应）总是以头字段后面的第一个空行终止，而不管消息中存在的实体头字段是什么(注意：空行只包含CRLF。）

如果存在内容长度头字段（第12.14节），则其字节值表示消息正文的长度。如果此标头字段不存在，则假定值为零。

由服务器关闭连接(关闭连接不能用于指示请求主体的结束，因为这将使服务器无法发回响应。）

注意，RTSP（目前）不支持HTTP/1.1“分块”传输编码（参见[H3.6]），并且要求存在Content-Length头字段。

给定返回的表示描述的中等长度，服务器应该始终能够确定其长度，即使它是动态生成的，这使得分块传输编码不必要。即使存在任何实体体，内容长度也必须存在，但即使没有明确给出长度，规则也能确保行为合理。

四、RTSP协议------请求（原文第六章）

从客户机到服务器（反之亦然）的请求消息在该消息的第一行中包括要应用于资源的方法、资源的标识符和正在使用的协议版本。

1.请求行

2.请求标头字段

注意，与HTTP/1.1[2]不同，RTSP请求总是包含绝对URL（即，包括scheme、host和port），而不仅仅是绝对路径。

HTTP/1.1要求服务器理解绝对URL，但是客户端应该使用主机请求头。这纯粹是为了与HTTP/1.0服务器向后兼容而需要的，这一点不适用于RTSP。

请求URI中的星号“*”表示请求不应用于特定资源，而是应用于服务器本身，并且仅当所使用的方法不一定应用于资源时才允许。

一个例子是：

OPTIONS * RTSP/1.0

五、RTSP协议------回应（原文第七章）

[H6]适用，但HTTP版本替换为RTSP版本。另外，RTSP定义了额外的状态码，而没有定义一些HTTP代码。表1中定义了有效的响应代码及其可用于的方法。

在接收并解释请求消息之后，接收者用RTSP响应消息进行响应。

1.状态行

响应消息的第一行是状态行，由协议版本后面跟着数字状态代码和与状态代码关联的文本短语组成，每个元素由SP字符分隔。除最终CRLF序列外，不允许CR或LF。

Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

1.1状态代码和原因短语

Status Code元素是一个3位整数的结果代码，用于尝试理解和满足请求。这些代码在第11节中有完整的定义。原因短语旨在对状态代码进行简短的文本描述。状态代码是供自动机使用的，原因短语是供人类用户使用的。客户端不需要检查或显示原因短语。

状态码的第一位数字定义了响应的类别。最后两位数字没有任何分类角色。第一个数字有5个值：

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

下面给出了为RTSP/1.0定义的数字状态码的各个值以及相应原因短语的示例集。这里列出的原因短语只是推荐的-它们可以被本地等价物替换而不影响协议。注意，RTSP采用了大多数HTTP/1.1[2]状态码，并从x50开始添加RTSP特定的状态码，以避免与新定义的HTTP状态码冲突。

状态码=“100”；继续
| “200” ; 好的
| “201” ; 创建
| “250” ; 存储空间不足
| “300” ; 多项选择
| “301” ; 永久移除
| “302” ; 临时移动
| “303” ; 查看其他
| “304” ; 未修改
| “305” ; 使用代理
| “400” ; 错误的请求
| “401” ; 未经授权
| “402” ; 要求付款
| “403” ; 被禁止的
| “404” ; 找不到
| “405” ; 不允许的方法
| “406” ; 不可接受
| “407” ; 需要代理身份验证
| “408” ; 请求超时
| “410” ; 跑了
| “411” ; 所需长度
| “412” ; 先决条件失败
| “413” ; 请求实体太大
| “414” ; 请求URI太大
| “415” ; 不支持的媒体类型
| “451” ; 无法理解参数
| “452” ; 找不到会议
| “453” ; 带宽不足
| “454” ; 找不到会话
| “455” ; 方法在此状态下无效
| “456” ; 头字段对资源无效
| “457” ; 无效范围
| “458” ; 参数为只读
| “459” ; 不允许聚合操作
| “460” ; 只允许聚合操作
| “461” ; 不支持的传输
| “462” ; 信宿不可达
| “500” ; 内部服务器错误
| “501” ; 未实施
| “502” ; 坏网关
| “503” ; 服务不可用
| “504” ; 网关超时
| “505” ; 不支持RTSP版本
| “551” ; 不支持选项
|extension-code
extension-code = 3DIGIT
Reason-Phrase = *

RTSP状态码是可扩展的。RTSP应用程序不需要理解所有注册状态码的含义，尽管这种理解显然是可取的。但是，应用程序必须理解任何状态代码的类（如第一个数字所示），并将任何未识别的响应视为等同于该类的x00状态代码，除非不能缓存未识别的响应。例如，如果客户端接收到无法识别的状态码431，它可以安全地假设其请求有问题，并将响应视为已接收到400状态码。在这种情况下，用户代理应该向用户呈现随响应一起返回的实体，因为该实体可能包含人类可读的信息，这些信息将解释异常状态。

状态码及其在RTSP方法中的使用：

代码原因

100 继续 all
200 OK all
201 创建 RECORD
250 存储空间不足 RECORD
300 多种选择 all
301 永久移动 all
302 临时移动 all
303 见其他 all
305 使用代理 all
400 错误请求 all
401 未经授权 all
402 需要付款 all
403 禁止 all
404 未找到 all
405 方法不允许 all
406 不可接受 all
407 需要代理身份验证 all
408 请求超时 all
410 没有了 all
411 所需长度 all
412 前提条件失败 DESCRIBE, SETUP
413 请求实体太大 all
414 请求URI太长 all
415 不支持的媒体类型 all
451 无效参数 SETUP
452 非法会议标识符 SETUP
453 带宽不足 SETUP
454 找不到会话 all
455 方法在此状态下无效 all
456 标题字段无效 all
457 无效范围 PLAY
458 参数为只读 SET_PARAMETER
459 不允许聚合操作 all
460 只允许聚合操作 all
461 不支持的传输 all
462 目标无法访问 all
500 内部服务器错误 all
501 未实现 all
502 坏网关 all
503 服务不可用 all
504 网关超时 all
505 RTSP版本不支持 all
551 选项不支持 all

1.2响应头字段

响应头字段允许请求收件人传递有关响应的附加信息，这些信息不能放在状态行中。这些头字段提供有关服务器的信息以及有关进一步访问由请求URI标识的资源的信息。

只有结合协议版本的更改，响应头字段名称才能可靠地扩展。然而，如果通信中的所有各方都承认它们是响应头字段，那么新的或实验的头字段可能会被赋予响应头字段的语义。无法识别的标头字段被视为实体标头字段。

六、RTSP协议------实体（原文第八章）

如果不受请求方法或响应状态码的限制，请求和响应消息可以传输实体。实体由实体头字段和实体体组成，尽管有些响应只包含实体头。

在本节中，发送方和接收方都指客户机或服务器，具体取决于谁发送和谁接收实体。

1.实体标题字段

实体头字段定义关于实体主体的可选元信息，如果没有主体，则定义关于请求标识的资源的可选元信息。

扩展头机制允许在不更改协议的情况下定义其他实体头字段，但不能假定收件人可以识别这些字段。收件人应忽略无法识别的标头字段，并由代理转发。

七、RTSP协议------连接（原文第九章）

RTSP请求可以几种不同的方式传输：

用于多个请求-响应事务的持久传输连接；
每个请求/响应事务一个连接；
无连接模式。
传输连接的类型由rtspuri定义（第3.2节）。对于方案“rtsp”，假定存在持久连接，而方案“rtspu”则调用发送rtsp请求，而不设置连接。
与HTTP不同，RTSP允许媒体服务器向媒体客户端发送请求。但是，这只支持持久连接，因为媒体服务器没有可靠的方式到达客户端。而且，这是从媒体服务器到客户端的请求可能穿越防火墙的唯一方法。