CrystalGabrielle的博客

RTSP协议（18）——安全注意事项原文第十六章由于RTSP服务器和HTTP服务器之间的语法和用法相似，因此[H15]中概述的安全考虑因素适用。具体而言，请注意以下内容：Authentication Mechanisms：RTSP和HTTP共享共同的身份验证方案，因此在身份验证方面应该遵循相同的规定。有关客户端身份验证问题，请参阅[H15.1]，有关支持多种身份验证机制的问题，请参阅[H15.2]。Abuse of Server Log Information：RTSP和HTTP服务器可能具有类似

RTSP协议（17）——语法原文第十五章RTSP语法是在rfc2068[2]中使用的增广Backus-Naur形式（BNF）中描述的。1.基本语法[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7MRbzoao-1622022430851)(https://z3.ax1x.com/2021/05/26/29afEV.png)][外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KZS4EbZ2-1622022430853)(https://z

RTSP协议（16）——示例原文第十四章以下示例涉及非标准的流描述格式，例如RTSL。以下示例不作为这些格式的参考。1.媒体点播（单播）客户端C从媒体服务器a（audio.example.com）和V（video.example.com）请求电影。媒体描述存储在web服务器W上。媒体描述包含演示文稿及其所有流的描述，包括可用的编解码器、动态RTP有效负载类型、协议堆栈以及内容信息（如语言或版权限制）。它也可能给出电影的时间表的指示。在这个例子中，客户只对电影的最后一部分感兴趣。[外链图片转存

RTSP协议（15）——缓存原文第十三章在HTTP中，响应请求对被缓存。RTSP在这方面有很大的不同。响应不可缓存，由descripe返回或包含在ANNOUNCE中的演示文稿描述除外(由于除了descripe和GET_PARAMETER之外的任何响应都不会返回任何数据，因此缓存对于这些请求来说并不是真正的问题。）但是，需要缓存连续媒体数据（通常相对于RTSP在带外传递）以及会话描述。在接收到设置或播放请求时，代理确定其是否具有连续媒体内容及其描述的最新副本。它可以通过分别发出SETUP或descrip

RTSP协议（14）——标题字段定义原文第十二章HTTP/1.1[2]或其他未在此列出的非标准头字段目前没有明确定义的含义，收件人应忽略这些字段。表3总结了RTSP使用的头字段。类型“g”表示在请求和响应中都可以找到的一般请求头，“R”表示请求头，“R”表示响应头，“e”表示实体头字段。在标有“支持”的列中标有“req.”的字段必须由特定方法的收件人实现，而标有“opt.”的字段是可选的。请注意，并不是所有标记为“req.”的字段都将在每个此类请求中发送。“req.”表示只有客户机（用于响应头）和服务

RTSP协议（13）——状态代码定义原文第十一章在适用的情况下，可以重用HTTP状态[H10]代码。具有相同含义的状态代码在此不再重复。请参阅表1以获取哪些请求可能返回哪些状态代码的列表。1.成功2xx1.1 250低存储空间服务器在接收到可能由于存储空间不足而无法完全完成的记录请求后返回此警告。如果可能的话，服务器应该使用Range头来指示它可能仍然能够记录的时间段。由于服务器上的其他进程可能同时占用存储空间，因此客户端应该仅将此作为估计。2. 3xx重定向看[H10.3].在RTSP中，

RTSP协议（12）——方法定义原文第十章方法token指示对请求URI标识的资源执行的方法。该方法区分大小写。将来可能会定义新的方法。方法名不能以$字符（十进制24）开头，必须是标记。方法总结见表2。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XaWl41CR-1621667290213)(https://z3.ax1x.com/2021/05/22/gqCiFS.png)]表2:RTSP方法的概述，它们的方向，以及它们操作的对象（P:presentation，S

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

RTSP协议（10）——实体原文第八章如果不受请求方法或响应状态码的限制，请求和响应消息可以传输实体。实体由实体头字段和实体体组成，尽管有些响应只包含实体头。在本节中，发送方和接收方都指客户机或服务器，具体取决于谁发送和谁接收实体。1.实体标题字段实体头字段定义关于实体主体的可选元信息，如果没有主体，则定义关于请求标识的资源的可选元信息。扩展头机制允许在不更改协议的情况下定义其他实体头字段，但不能假定收件人可以识别这些字段。收件人应忽略无法识别的标头字段，并由代理转发。2.实体看[H7.2

RTSP协议（9）——回应原文第七章[H6]适用，但HTTP版本替换为RTSP版本。另外，RTSP定义了额外的状态码，而没有定义一些HTTP代码。表1中定义了有效的响应代码及其可用于的方法。在接收并解释请求消息之后，接收者用RTSP响应消息进行响应。1.状态行响应消息的第一行是状态行，由协议版本后面跟着数字状态代码和与状态代码关联的文本短语组成，每个元素由SP字符分隔。除最终CRLF序列外，不允许CR或LF。Status-Line = RTSP-Version SP Status-Code S

RTSP协议（8）——请求原文第六章从客户机到服务器（反之亦然）的请求消息在该消息的第一行中包括要应用于资源的方法、资源的标识符和正在使用的协议版本。1.请求行2.请求标头字段注意，与HTTP/1.1[2]不同，RTSP请求总是包含绝对URL（即，包括scheme、host和port），而不仅仅是绝对路径。HTTP/1.1要求服务器理解绝对URL，但是客户端应该使用主机请求头。这纯粹是为了与HTTP/1.0服务器向后兼容而需要的，这一点不适用于RTSP。请求URI中的星号“*”表示请求不

RTSP协议（7）——常规标题字段原文第五章参见[H4.5]，除了Pragma、传输编码和升级头没有定义之外：

RTSP协议（6）——RTSP消息原文第四章RTSP是一种基于文本的协议，使用UTF-8编码中的ISO 10646字符集（RFC 2279[21]）。行由CRLF终止，但是接收器也应该准备好将CR和LF本身解释为行终止符。基于文本的协议使得以自描述的方式添加可选参数变得更容易。由于参数的数目和命令的频率较低，处理效率不受关注。基于文本的协议，如果做得仔细的话，还可以用脚本语言（如Tcl、visualbasic和Perl）轻松实现研究原型。10646字符集避免了复杂的字符集切换，但只要使用US-ASC

RTSP协议（5）——协议参数原文第三章1.RTSP版本[H3.1]applies，with HTTP replaced by RTSP.2.RTSP URL“rtsp”和“rtspu”方案用于通过rtsp协议引用网络资源。本节定义rtspurl的特定于方案的语法和语义。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xo4Tyk8g-1621482431384)(https://z3.ax1x.com/2021/05/20/go9RTH.png)]请注意，片段

RTSP协议（4）——符号约定原文第二章由于许多定义和语法与HTTP/1.1相同，因此本规范只指向定义它们的部分，而不是复制它们。为简洁起见，[HX.Y]将参考当前HTTP/1.1规范（RFC 2068[2]）的X.Y节。本文件中规定的所有机制均以散文和类似于[H2.1]中所用的增广巴科斯诺尔形式（BNF）进行了描述。RFC 2234[17]对此进行了详细描述，不同的是，此RTSP规范为逗号分隔的列表保留了“1#”表示法。在这份备忘录中，我们使用缩进和小字体段落来提供背景和动机。这是为了让那些不参与

RTSP协议（3）——介绍原文第一章1.目的实时流协议（RTSP）建立并控制连续媒体（如音频和视频）的单个或多个时间同步流。它通常不传送连续流本身，尽管连续媒体流与控制流的交织是可能的（参见第10.12节）。换句话说，RTSP充当多媒体服务器的“网络遥控器”。要控制的流集由表示描述定义。本备忘录并未规定陈述说明的格式。没有RTSP连接的概念；相反，服务器维护由标识符标记的会话。RTSP会话决不与传输级连接（如TCP连接）绑定。在RTSP会话期间，RTSP客户端可以打开和关闭到服务器的许多可靠传输连

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

RTSP协议（1）——简介VP9还没学完，我又开始学RTSP啦！本文基本是照着RFC2326翻译的原文档链接：https://datatracker.ietf.org/doc/rfc2326/