RFC2326 - Real Time Streaming Protocol (RTSP) 完整中英文对照版

RFC2326 - Real Time Streaming Protocol (RTSP) 完整中英文对照版

E-mail：[e-mail]

译者： Bryan.Wong（王晶，宁夏固原）

译文版本：alpha 0.80

译文发布时间：2007-7-25

版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。

网络工作组                                                H. Schulzrinne

请求注释: 2326                                             哥伦比亚大学.

类别: 标准跟踪                                                   A. Rao

                                                               Netscape

                                                             R. Lanphier

                                                            RealNetworks

                                                            1998年4月

                      实时流协议(RTSP)

本备忘录状态

本文为Internet社区描述了一种Internet标准跟踪协议[V1] ，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。

版权声明：

版权为The Internet Society 所有。所有权利保留。

摘要：

实时流协议（RTSP）是应用层协议，控制实时数据的传送[V2] 。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。

目录：

1 介绍     

1.1 目的     

1.2 要求     

1.3 术语     

1.4 协议特性     

1.5 RTSP扩展     

1.6 整体运作     

1.7 RTSP状态     

1.8 与其他协议的关系     

2 符号协定     

3 协议参数     

3.1 RTSP版本     

3.2 RTSP URL     

3.3 会议标识     

3.4 会话标识     

3.5 SMPTE 相对时间戳     

3.6正常播放时间     

3.7 绝对时间     

3.8 选项标签     

3.8.1 用IANA注册新的选项标签     

*4 RTSP消息     

4.1 消息类型     

4.2 消息头     

4.3 消息主体     

4.4 消息长度     

*5 普通头部段      

*6 请求     

6.1 请求行     

6.2 请求消息头段     

*7 响应     

7.1 状态行     

7.1.1 状态码和原因短语     

7.1.2 响应头部段     

*8 实体     

8.1 实体头部域     

8.2 实体主体     24

*9 连接     

9.1 流水线化     25

9.2 可靠性及确认     25

*10 方法定义     25

10.1 可选项     26

10.2 描述     26

10.3 通知     26

10.4 建立     26

10.5 播放     27

10.6 暂停     27

10.7 断开     27

10.8 获取参数     28

10.9 设置参数     28

10.10 重定向     28

10.11 录制     29

10.12 嵌入（交织）的二进制数据     29

*11状态码定义     29

11.1成功2xx     30

11.1.1 存储空间低 250     30

11.2 重定向 3xx    31

11.3 客户端错误 4xx     31

11.3.1方法不允许     32

11.3.2无法理解参数     32

11.3.3会议未找到     33

11.3.4 带宽不足     33

11.3.5 会话未找到     34

11.3.6 本状态下该方法无效     34

11.3.7 头部域与资源不匹配     34

11.3.8 无效范围     35

11.3.9 参数为只读     35

11.3.10 不允许合操作     36

11.3.11 只允许合操作     36

11.3.12 不支持的传输     36

11.3.13 目标不可达     37

11.3.14 不支持的选项     37

12 头部段定义（Header Field Definitions）     38

12.1 接受     38

12.2 接受-编码     38

12.3 接受-语言     39

12.4 允许（Allow）     39

12.5 授权（Authorization）     40

12.6 带宽     40

12.7 块大小     40

12.8 缓存控制     41

12.9 会议     41

12.10 连接     41

12.11 内容-基础     42

12.12 内容-编码（Content-Encoding）     42

12.13 内容-语言     43

12.14 内容-长度（Content-Length）     43

12.15 内容-位置     43

12.16 内容-类型（Content-Type）     44

12.17 命令序列题头（CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布     47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

12.41 用户代理（User-Agent）     49

12.42 变化     49

12.43 通过     49

12.44 WWW-认证（WWW-Authenticate）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 实体标签     57

+C.2 合控制不可用     57

+C.3 合控制可用     57

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1 介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

传输初始化：

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

   可以很容易地向RTSP加入新方法和参数。

易解析：

   RTSP可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

   若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

*     服务器可能只能回放，因此不必支持录制请求。

*     用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

*     一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

   *已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。

   *可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

   *可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

   每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

   根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

   表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

   除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

   以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体[V8] 。

多播，服务器选择地址：

   媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

多播，用户选择地址：

   若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

 

1.7 RTSP状态

   RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

  RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

   让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

   启动SETUP所分配的流的数据传输。

PAUSE：

   临时暂停流，而不释放服务器资源。

TEARDOWN：

   释放流占用的资源，RTSP会话停止，从服务器端退出。

   与状态相关的RTSP方法使用会话头部域（Session header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节10.4)的响应中，服务器生成会话标识。

1.8 与其他协议关系

   RTSP在功能上与HTTP有重叠。它也可能与HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述(presentation description)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立RTSP 服务器与客户端。

   但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议[V9] 进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态[V10] 的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

   重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

   虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

   RTSP假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。

2 符号约定

   既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某Type）     44

12.17 命令序列题头（CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布     47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

12.41 用户代理（User-Agent）     49

12.42 变化     49

12.43 通过     49

12.44 WWW-认证（WWW-Authenticate）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 实体标签     57

+C.2 合控制不可用     57

+C.3 合控制可用     57

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1 介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

传输初始化：

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

   可以很容易地向RTSP加入新方法和参数。

易解析：

   RTSP可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

   若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

*     服务器可能只能回放，因此不必支持录制请求。

*     用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

*     一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

   *已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。

   *可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

   *可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

   每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

   根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

   表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

   除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

   以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体[V8] 。

多播，服务器选择地址：

   媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

多播，用户选择地址：

   若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

 

1.7 RTSP状态

   RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

  RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

   让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

   启动SETUP所分配的流的数据传输。

PAUSE：

   临时暂停流，而不释放服务器资源。

TEARDOWN：

   释放流占用的资源，RTSP会话停止，从服务器端退出。

   与状态相关的RTSP方法使用会话头部域（Session header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节10.4)的响应中，服务器生成会话标识。

1.8 与其他协议关系

   RTSP在功能上与HTTP有重叠。它也可能与HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述(presentation description)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立RTSP 服务器与客户端。

   但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议[V9] 进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态[V10] 的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

   重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

   虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

   RTSP假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。

2 符号约定

   既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某Type）     44

12.17 命令序列题头（CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布     47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

12.41 用户代理（User-Agent）     49

12.42 变化     49

12.43 通过     49

12.44 WWW-认证（WWW-Authenticate）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 实体标签     57

+C.2 合控制不可用     57

+C.3 合控制可用     57

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1 介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

传输初始化：

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

   可以很容易地向RTSP加入新方法和参数。

易解析：

   RTSP可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

   若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

*     服务器可能只能回放，因此不必支持录制请求。

*     用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

*     一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

   *已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。

   *可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

   *可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

   每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

   根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

   表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

   除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

   以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体[V8] 。

多播，服务器选择地址：

   媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

多播，用户选择地址：

   若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

 

1.7 RTSP状态

   RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

  RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

   让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

   启动SETUP所分配的流的数据传输。

PAUSE：

   临时暂停流，而不释放服务器资源。

TEARDOWN：

   释放流占用的资源，RTSP会话停止，从服务器端退出。

   与状态相关的RTSP方法使用会话头部域（Session header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节10.4)的响应中，服务器生成会话标识。

1.8 与其他协议关系

   RTSP在功能上与HTTP有重叠。它也可能与HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述-ption)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立RTSP 服务器与客户端。-text-align: left;" class="MsoNormal">   但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议[V9] 进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态[V10] 的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

   重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

   虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

   RTSP假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。

2 符号约定

   既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某Type）     44

12.17 命令序列题头（CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布     47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

12.41 用户代理（User-Agent）     49

12.42 变化     49

12.43 通过     49

12.44 WWW-认证（WWW-Authenticate）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

-MsoNormal" align="left">o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 实体标签     57

+C.2 合控制不可用     57

+C.3 合控制可用     57

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1 介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

传输初始化：

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

   可以很容易地向RTSP加入新方法和参数。

易解析：

   RTSP可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

   若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

*     服务器可能只能回放，因此不必支持录制请求。

*     用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

*     一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

   *已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。

   *可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

   *可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

   每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

   根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

   表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

   除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

   以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体[V8] 。

多播，服务器选择地址：

   媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

多播，用户选择地址：

   若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

 

1.7 RTSP状态

   RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

  RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

   让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

   启动SETUP所分配的流的数据传输。

PAUSE：

   临时暂停流，而不释放服务器资源。

TEARDOWN：

   释放流占用的资源，RTSP会话停止，从服务器端退出。

   与状态相关的RTSP方法使用会话头部域（Session header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节-校衿魃苫峄氨晔丁?span lang="EN-US">

1.8 与其他协议关系

   RTSP在功能上与HTTP有重叠。它也可能与HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述-ption)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立RTSP 服务器与客户端。-text-align: left;" class="MsoNormal">   但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议[V9] 进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态[V10] 的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

   重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

   虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

   RTSP假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。

2 符号约定

   既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某Type）     44

12.17 命令序列题头（CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布     47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

12.41 用户代理（User-Agent）     49

12.42 变化     49

12.43 通过     49

12.44 WWW-认证（WWW-Authenticate）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

-MsoNormal" align="left">o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 实体标签     57

+C.2 合控制不可用     57

+C.3 合控制可用     57

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1 介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

-涑跏蓟?span lang="EN-US">

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

-an>可以很容易地向RTSP加入新方法和参数。

易解析：

   -style="">可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

   若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

*     服务器可能只能回放，因此不必支持录制请求。

*     用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

*     一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

   *已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。

   *可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

   *可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

   每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

   根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

   表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言?span lang="EN-US">-体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

   除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

   以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体[V8]-n>。

多播，服务器选择地址：

   媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

-font-family: 宋体;">多播，用户选择地址：

   若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

 

1.7 RTSP状态

   RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

  RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

   让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

-;" class="MsoNormal" align="left">   启动SETUP所分配的流的数据传输。

PAUSE：--align: left;" class="MsoNormal">   临时暂停流，而不释放服务器资源。

TEARDOWN：

-tyle="font-family: 宋体;" lang="EN-US">   释放流占用的资源，RTSP会话停止，从服务器端退出。

   与状态相关的RTSP方法使用会话头部域?span lang="EN-US">- header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节-校衿魃苫峄氨晔丁?span lang="EN-US">

1.8 与其他协议关系

   RTSP在功能上与HTTP有重叠。它-HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述-ption)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立-Ф恕?span lang="EN-US">-text-align: left;" class="MsoNormal">   但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议[V9] 进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态-gg/article/details/2050516#_msocom_10" id="_anchor_10" class="msocomanchor">[V10] 的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

   重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

   虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

   RTSP-: 宋体;">假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。

2 符号约定

   既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某Type）     44

12.17 -EN-US">CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

-">12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布-/span>-47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

--US">12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

-MsoNormal" align="left">12.41 用户代理（User-Agent）     49

12.42 变化     49

-nt-family: 宋体;" lang="EN-US">12.43 通过     49

12.44 WWW-认证（-）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

-MsoNormal" align="left">o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

-="MsoNormal" align="left">o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 - 宋体;">实体标签     57

-yle="font-family: 宋体;" lang="EN-US">+C.2 合控制不可用     57

+C.3 合控制可用   -n>

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1-ize: 10.5pt;font-family: 宋体;">介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

-涑跏蓟?span lang="EN-US">

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

-an>可以很容易地向RTSP加入新方法和参数。

易解析：

   -style="">可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

-" align="left">   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。

传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：

   若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必须能禁止位置条滑动。

早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证-很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。

1.5 扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：

*     服务器可能只能回放，因此不必支持录制请求。

*     用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。

*     一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER请求。

但服务器应该实现所有12章中要求的标题域。

表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。

RTSP 可以如下三种方式扩展，按所支持的改变多少排序：

   *已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。

   *可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。

   *可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。

1.6 整体运作

   每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。

   根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。

   表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言?span lang="EN-US">-体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。

   除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

   以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体[V8]-n>。

多播，服务器选择地址：

   媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。

-font-family: 宋体;">多播，用户选择地址：

   若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

 

1.7 RTSP状态

   RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

  RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

   让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

-;" class="MsoNormal" align="left">   启动SETUP所分配的流的数据传输。

PAUSE：--align: left;" class="MsoNormal">   临时暂停流，而不释放服务器资源。

TEARDOWN：

-tyle="font-family: 宋体;" lang="EN-US">   释放流占用的资源，RTSP会话停止，从服务器端退出。

   与状态相关的RTSP方法使用会话头部域?span lang="EN-US">- header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节-校衿魃苫峄氨晔丁?span lang="EN-US">

1.8 与其他协议关系

   RTSP在功能上与HTTP有重叠。它-HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述-ption)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立-Ф恕?span lang="EN-US">-text-align: left;" class="MsoNormal">   但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议[V9] 进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态-gg/article/details/2050516#_msocom_10" id="_anchor_10" class="msocomanchor">[V10] 的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

   重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

   虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

   RTSP-: 宋体;">假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。

2 符号约定

   既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某Type）     44

12.17 -EN-US">CSeq）     44

12.18 日期（Date）     44

12.19 过期（Expires）     45

12.20 来自（From）     45

12.21 主机     45

12.22 如果匹配     45

-">12.23如果-被修改-自从（If-Modified-Since）     46

12.24 最后修改（Last-Modified）     46

12.25 位置（Location）     46

12.26 代理认证     47

12.27 代理要求     47

12.28 公布-/span>-47

12.29 范围     49

12.30 提交方（Referer）     49

12.31 稍后重试     49

12.32 要求     49

12.33 RTP信息     49

12.34 倍速（Scale）

--US">12.35 速度     49

12.36 服务器（Server）     49

12.37 会话     49

12.38 时间戳     49

12.39 传输     49

12.40 不支持     49

-MsoNormal" align="left">12.41 用户代理（User-Agent）     49

12.42 变化     49

-nt-family: 宋体;" lang="EN-US">12.43 通过     49

12.44 WWW-认证（-）     50

*13 缓存     50

*14 例子     50

14.1 按需点播（单播）     50

14.2 容器文件的流化     51

14.3 单个流容器文件     51

14.4 实况媒体表示的组播     51

14.5 在存在的会话中播放媒体     51

14.6 录制     52

*15 语法     52

15.1 基本语法     52

16 安全考虑（Security Considerations）     52

*附录A RTSP协议状态机     53

*A.1 客户端状态机     53

*A.2 服务器端状态机     53

*附录B 与RTP协议的交互     53

*附录C 使用SDP进行RTSP会话描述     54

+C.1 定义     54

-MsoNormal" align="left">o C.1.1 控制URL     55

o C.1.2 媒体流     55

o C.1.3 有效载荷类型     55

o C.1.4 详细格式参数     55

-="MsoNormal" align="left">o C.1.5 表示的范围     56

o C.1.6 有效时间     56

o C.1.7 连接信息     56

o C.1.8 - 宋体;">实体标签     57

-yle="font-family: 宋体;" lang="EN-US">+C.2 合控制不可用     57

+C.3 合控制可用   -n>

*附录D 最小RTSP实现     58

+D.1 客户端     58

D.1.1基本回放     58

D.1.2 认证enabled     58

+D.2 服务器     59

D.2.1基本回放     59

D.2.2认证enabled     59

*附录E 作者地址     60

*附录F 致谢     60

*参考书目     60

*版权申明     61

1-ize: 10.5pt;font-family: 宋体;">介绍

 

1.1 目的

   实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。

   表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。

   RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

   RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：

     *RTSP引入了很多新方法并且有不同的协议标识符。

     *RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

     *RTSP客户机和服务器都可以发出请求。

     *数据由信带外的另一个协议传送（但有一个特例）。

     *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

     *RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

   当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。

协议支持以下操作：

从媒体服务器上获得媒体：

   用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。

邀请媒体服务器进入会议：

   媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。

将媒体加到已存在的表示中：

   现场表示[V3] 的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。

和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。

1.2 要求

在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。

1.3 术语

一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。

合控制：

   服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。

会议：

   多方参与的多媒体表示，这里的多方意味着大于或等于一方。

客户端：

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

连接：

   以通讯为目的，在传输层建立的两个程序间的虚拟信道。

容器文件：

   可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。

连续媒体：

   接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。

实体：

   请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。

媒体初始化：

   数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。

媒体参数:

   对于某种特定的媒体类型来说[V4] ，回放前或者回放中有可能会发生改变的一些参数。

媒体服务器：

   提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。

媒体服务器重定向：

   重新把媒体客户端定向到另外一个媒体服务器。

(媒体)流：

   单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。

消息：

   RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。

参与者：

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

表示(presentation)：

   作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。

表示描述(presentation description)：

   表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。

响应：

RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。

请求：

   RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。

RTSP会话(session)：

   包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

-涑跏蓟?span lang="EN-US">

   客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。

1.4 协议特点

RTSP有以下特性：

易于扩展：

-an>可以很容易地向RTSP加入新方法和参数。

易解析：

   -style="">可由标准HTTP或MIME解析器解析。[MS5] 

安全：

   RTSP重用[MS6] 了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。

独立于传输：

   RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。

多服务器支持：

   表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。

录制设备控制：

   协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。

流控制与会议初始化分离：

   流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说， SIP或H.323 可用来邀请服务器入会。

适合专业应用：

   通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。

适合专业应用：

   RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。

表示描述中立：

   协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。

代理与防火墙友好：

   协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。

HTTP友好：

   此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态[MS7] ， RTSP不仅仅向HTTP 添加方法。

合适的服务器控制：

-" align="left">   若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的-an>

-gn="left">传输协商：

   实际处理连续媒体流前，客户端可协商传输方法。

性能协商：-内容 | LWS )

  field-content     =     <the 构成 field-value ，组成

                             *TEXT 或token、 tspecials、

                             quoted-string组合成的OCTETs>

  safe              = "/$" | "-" | "_" | "." | "+"

  extra             = "!" | "*" | "$'$" | "(" | ")" | ","

  hex               = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |

                       "a" | "b" | "c" | "d" | "e" | "f"

  escape            = "/%" hex hex

  reserved          = ";" | "/" | "?" | ":" | "@" | "&" | "="

  unreserved        = alpha | digit | safe | extra

  xchar             = unreserved | reserved | escape

16 安全考虑

   由于RTSP服务器和HTTP服务器在语法和使用上的相似性，应用[H15]所述的安全机制。请特别注意以下内容：

鉴权机制：

RTSP和HTTP分享相同的鉴权方案，因此应该遵循相同的鉴权原则。客户端鉴权课题见[H15.1],多鉴权机制支持的相关课题见[H15.2]。

服务器日志信息的误用：

RTSP和HTTP服务器将有大致类似的日志记录机制，因此应该平等地对待日志内容保护，及用户和服务器隐私的保护。HTTP服务器日志相关的服务器推荐见[H15.3]。

敏感信息的传递：

没有理由认为RTSP上传输的信息会没有一般HTTP上传输的信息那么敏感。因此，所有涉及到保护数据隐私权和用户隐私权的警示，是每个RTSP客户端、服务器、代理的实现者都需要考虑的。更多细节见[H15.4]。

基于文件和路径名的攻击：

尽管RTSP URL是不透明的句柄，没必要有文件系统语义，但还是期望很多实现能够把请求URL的一部分直接转化成文件系统目录。此种情况下，文件系统【应该】遵循[H15.5]给出的警示，例如检查路径元素中的“..”。

个人信息：

一般在HTTP上是隐私的信息（用户名，地址，等等），在RTSP上也是，因此它们应该对等。更多推荐意见见[H15.6]。

Accept头部相关的隐私问题：

由于RTSP中存在很多和HTTP一样的“Accept”头部，因此也要遵循[H15.7]中关于它们的使用的相同的警示。

DNS欺骗：

可以推测，如果给典型的和HTTP会话相关的RTSP会话更长连接时间，RTSP客户端DNS优化应该会少些普遍性。尽管如此，对于任何试图依靠DNS-to-IP的映射来保持该映射的简单使用的实现，[H15.8]提供的推荐意见仍然有普遍意义。

地址头部及欺骗：

如果一个支持多优化的服务器不相信其他服务器，那么它必须检查响应中在上述优化的控制下产生的Location和Content-Location头部的值，以确保它们不会向没有权限（[H15.9]）的无效资源作尝试。

作为现有HTTP规范（本规范编写时的RFC 2068 [2]）的推荐的补充，将来的HTTP规范可能提供安全方面的补充指导。

下面是RTSP实现的额外考虑：

集中的拒绝服务式攻击：

协议提供了用远程控制来进行拒绝服务式攻击的机会。攻击者可能会通过修改SETUP请求的目的地地址，向一个或多个IP地址发起传输流。该情况中可能可以看到攻击者的IP，但对于预防更多的攻击者或确认攻击者的标识这并不总是管用。因此，RTSP服务器【应该】只允许客户端为RTSP发起的传输流指定目的地址，如果服务器验证过客户端标识--通过建立一个已知的使用RTSP鉴权机制的用户的数据库（可能是digest鉴权或者更强），或者其他手段--的话。

会话劫持：

因为传输层连际和RTSP之间没有直接联系，恶意客户端就可能以发起会话标识为随机值的请求来影响正常的客户端。服务器【应该】使用较大的随机无序会话标识来降低此种攻击的机会。

鉴权：

服务器应该同时实现基本的和digest[8]的鉴权。在需要控制消息有较强安全性的环境，RTSP控制流可能会被加密。

流课题：

RTSP仅提供流控制。在此章节及余下的备忘里，不包括流传输课题。RTSP实现最有可能采取的方式是依赖于其他协议如RTP、IP multicast、 RSVP 和 IGMP，并应解决这些或其他适用规范所带来的安全问题。

持续性可疑行为：

RTSP服务器【应该】在收到一个进程的存在安全隐患的行为后返回错误代码403（禁止）。RTSP服务器也【应该】能意识到探测服务器弱点和进口的尝试，并【可能】强行断开连接并忽略认为违反了本地安全策略的客户端的其他请求。

附录A：RTSP 协议状态机

   RTSP客户端和服务器状态机给出了协议从RTSP会话初始化到RTSP会话终止之间的表现。

状态是基于每个对象定义的。一个对象由流URL和RTSP会话标识唯一地标识出来。任何使用跟多个流构成的表示的合URL相关的请求/回复，都对所有单个的流的状态有影响。例如，如果一个表示/movie包含两个流，/movie/audio 和 /movie/video，那么下列命令：

    PLAY rtsp://foo.com/movie RTSP/1.0

    CSeq: 559

    Session: 12345678

将对/movie/audio 和 /movie/video的状态有影响。

该示例没有示范标准URL形式或和文件系统的关系的意思。见3.2节。

OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER,SET_PARAMETER 请求对客户端或服务器的状态没有影响，因此未列入状态表。

A.1 客户端状态机

客户端可以处于如下的状态：

Init（初始）：

   已经发出SETUP，等待回应中。

Ready（就绪）：

   SETUP回复已收到或在Playing状态中PAUSE回复已收到。

Playing（播放）：

   PLAY回复已收到。

Recording（录制）：

   RECORD回复已收到。

总之，客户端在收到请求的回复之后改变状态。注意某些请求是在未来的时间或位置起作用的（如PAUSE），而状态的改变也要视情况而定。如果对象（例如多播组有效的）不要求显式的SETUP，状态自Ready开始。在此情况就只有两种状态，Ready和Playing。当到达所请求的range的结尾时，的客户端也会从Playing/Recording状态转到Ready。

“下一状态”栏指示接受到成功响应（2xx）后可能的状态。如果请求所得来的状态码是3xx，那么状态变成Init，而4xx状态码不会导致状态改变。没有在对应状态列出的消息，【必须不】在此状态下被客户端发出--例外是上文列出的对状态没有影响的消息。从服务器收到一个REDIRECT等同于收到3xx重定向状态。

  状 态      可发消息        响应后下一状态

  Init       SETUP           Ready

              TEARDOWN        Init

  Ready      PLAY            Playing

              RECORD          Recording

              TEARDOWN        Init

              SETUP           Ready

  Playing    PAUSE           Ready

              TEARDOWN        Init

              PLAY            Playing

              SETUP           Playing (changed transport)

  Recording  PAUSE           Ready

              TEARDOWN        Init

              RECORD          Recording

              SETUP           Recording (changed transport)

A.2 服务器状态码

服务器可以处于如下状态：

Init（初始）：

   初始化状态，没有收到有效SETUP。

Ready（就绪）：

   最近收到的SETUP请求成功，回复已发送；或在播放中，最近收到的PAUSE请求成功，回复已发送。

Playing（播放）：

   最近收到的PLAY请求成功，回复已发送。数据开始发送。

Recording（录制）：

   服务器正在录制媒体数据。

总之，服务器根据收到的请求改变状态。如果服务器处于Playing或Recording和单播模式下，且如果在给定期间没有从客户端收到“健康的”信息，例如RTCP报告或RTSP命令，服务器【可能】会转到Init状态或关闭RTSP会话。服务器可以在会话响应头部（12.37节）声明另一个超时值。如果服务器状态为Ready，且在一分钟或者更长时间内没有收到RTSP请求，它【可能】转为Init状态。注意某些请求是在未来的时间或位置起作用（如PAUSE），服务器在合适的时间状态的改变。在到达客户端所请求范围的末端后，服务器从Playing或Recording状态转为Ready。

REDIRECT消息一旦发出就立即生效，除非在Range头部中另外指出了重定向何时生效。此种情况中，服务器状态也是在合适的时间才改变。

如果对象不要求有显式的SETUP，则状态从Ready开始，且只有Ready和Playing两个状态。

“下一状态”栏指示接受到成功响应（2xx）后可能的状态。如果请求所得来的状态码是3xx，那么状态变成Init，而4xx状态码不会导致状态改变。

   状 态           可收消息        下一状态

    Init           SETUP            Ready

                    TEARDOWN         Init

    Ready          PLAY             Playing

                    SETUP            Ready

                    TEARDOWN         Init

                    RECORD           Recording

    Playing        PLAY             Playing

                    PAUSE            Ready

                    TEARDOWN         Init

                    SETUP            Playing

    Recording      RECORD           Recording

                    PAUSE            Ready

                    TEARDOWN         Init

                    SETUP            Recording

附录B：同RTP交互

   RTSP允许媒体客户端控制媒体表示中选择出的非连续片段，表现为RTP媒体层[24]的流。表现为RTP流的媒体层不应该受NPT时间的跳跃的影响。因此，RTP序列号和RTP时间戳在跨越NPT时间跳跃时都【必须】是连续且单调递增的。

例如，假设时钟频率是8000Hz，包之间的时间间隔是100毫秒，初始序列号和时间戳都是0。我们首先播放NPT 10到NPT 15，然后向前跳播放NPT 18到NPT 20。第一个片段在RTP包上表现为序列号从0到49，时间戳从0到39，200。第二个片段则表现为序列号从50到69，时间戳从40，000到55，200。

我们不能假定RTSP客户端可以与RTP媒体agent通信，因为这可能是两个独立的进程。如果RTP时间戳的时间间隔和NPT一样，媒体agent将假设表示有暂停[V44] 。如果NPT时间跳跃足够大，RTP时间戳可能会到达上限而从头开始，这样媒体agent可能会认为之后的包跟之前已播放的包重复了。

对于某些数据类型，RTSP层和RTP层之间的紧密整合是有必要的。这完全不能排除上文所述的限制。RTSP/RTP组合媒体客户端应该用RTP-Info域来判断要来的RTP包是在搜索之前还是之后发的。

对于连续音频，服务器【应该】在服务于新PLAY请求之始就设置RTP标志位。这使客户端可以进行播放延迟调整[V45] 。

对于倍速改变（12.34节），RTP时间戳应该和回放计时一致。例如，当以两倍速、speed为1播放30帧/秒的视频记录，服务器应该每两帧丢弃一帧以维持用间隔为3000每帧的正常时间戳传送视频流，但是NPT每一视频帧增加1/15秒。

客户端可以通过通知位置重设后的第一个包的RTP时间戳值，来维护正确NPT的播放。RTP-info（12.33）头部的sequence参数提供下个片段的首个序列号。

附录C：用SDP描述RTSP会话

会话描述协议（SDP, RFC 2327 [6]）可能会RTSP被用于描述流或表示。这类使用被限制在以下几个方面，用于给出访问方式和编码：

合控制：

不能够合控制的由来自于一个或多个服务器多个流组成的表示。这类描述通常由其他途径得来，以HTTP为典型。不它们也可以通过ANNOUNCE方法接收。

非合控制：

能够合控制的由多个来自于一个服务器的流组成的表示。这类描述通常在对一个URL的 DESCRIBE请求的回复中给出，或通过ANNOUNCE方法接收。

该附录描述一个SDP文件，例如通过HTTP获取的,如何决定一个RTSP会话上的操作。它还描述了客户端如何解释DESCRIBE请求的回复所给的SDP内容。SDP不为客户端提供能够不用人工指引，而区分多个要同时提交的媒体流和多个互为替换的流的集合（例如，两个讲不同语言的音频流）。

C.1 定义

该附件使用的词条"会话级别", "媒体级别"和其他键/属性名及值的定义在SDP（RFC 2327[6]中：

C.1.1 控制URL

“a=control”属性用来传送控制RUL。该属性可用在会话和媒体描述上。；如果用于单个媒体，它指示用来控制那个特定媒体流的URL。如果用在会话级别，该属性指示合控制的URL。

例子：

    a=control:rtsp://example.com/foo

该属性可能包含相对或者绝对URL，遵循RFC 1808 [25]的规则和习惯。实现应该按以下顺序寻找基URL：

  1.    RTSP Content-Base 域

  2.     RTSP Content-Location 域

  3.    RTSP 请求 URL

如果此属性只包含星号（*）,则URL被以空内嵌UL对待，因此继承整个基URL。

C.1.2 媒体－流

   "m="被用来列举流。它期望所有列举出的流都将有合适的同步处理。如果会话是单播，端口号则是服务器对客户端的推荐；客户端在SETUP中还是应该在包括它并有可能忽略此推荐。如果服务器没有偏好，它【应该】把端口号值置零。

例子：

    m=audio 0 RTP/AVP 31

C.1.3 载荷类型

   载荷类型以"m="域给出。若载荷类型是RFC 1890[1]里的静态载荷类型，则不需要其他信息。若是动态载荷类型，则用媒体属性“rtpmap”说明是什么媒体。“rtpmap”属性中的“encoding name”可能是RFC 1890（章节5和6）中规定的一中，或SDP（RFC 2327 [6]）规定的“X-”为前缀的实践性编码。Codec-specific（编码器－细节）参数不在此域之中，而在下文描述的“fmtp”属性中。想要注册新编码的实现者应该遵循RFC 1890 [1]中的手续。如果媒体类型不匹配RTP AV规范，那么推新建一个子集并使用合适的名字，以代替"m="域的"RTP/AVP"。

C.1.4 格式－细节 参数

   格式细节参数用“fmtp“媒体参数表达。”fmtp“的语法具体对应于属性所指的编码。注意打包时间间隔用“ptime”属性传递。

C.1.5 表示的范围

   "a=range"属性定义所储会话的总时间范围。（现场会话的长度可以由“t”和“r”属性推导出。）除非表示含有不同持续时间的媒体流，否则范围属性是会话级别的属性。首先给出的是单位，后跟值范围。单位和它们的值在3.5、3.6、3.7节中给出定义。

例子：

    a=range:npt=0-34.4368

    a=range:clock=19971113T2115-19971113T2203

C.1.6

   “t=”域【必须】包含合适的合控制或非合控制流的开始和停止时间的值。在合控制里，服务器【应该】指示保证描述有效的停止时间值，以及等于或早于收到DESCRIBE请求时刻的开始时间。它也【可能】把开始和停止时间指示为0，意为会话始终有效。在非合控制里，那些值应该反映会话能有效保持SDP语义的时期，且不需要借助其他途径（如包含描述的web页面的生命期）来达到此目的。

C.1.7 连接信息

   在SDP里，“C=”域包含媒体流的目的地址。但是，对于按需点播流和一些多播流，目的地址由客户端通过SETUP请求给出。除非媒体内容有固定的目的地址，否则”C=”域将被置为合适的空值。对于型为“IP4“的地址，该值为"0.0.0.0"。

C.1.8 实体标签

   可选的“a=etag”属性标识会话描述的版本。它对客户端不透明。SETUP请求可能在If-Match域（见12.22节）包含此标识，以在当该属性值仍和当前描述中的对应时只允建立会话。该属性值是不透明的且可以包含SDP属性所允许包含的任意值。

例子：

    a=etag:158bb3e7c7fd62ce67f12b533f06b83a

有人可能会说“o=”域提供相同的功能。但是，这样做可以对需为同一个媒体内容片段提供多种SDP以外的的会话描述类型支持的服务器进行强制要求。

C.2 合控制无效

   如果一个给出了多个媒体部分的表示不支持合控制，【必须】通过"a=control:"属性给出每个部分的控制URL。

例子：

    v=0

    o=- 2890844256 2890842807 IN IP4 204.34.34.32

    s=I came from a web page

    t=0 0

    c=IN IP4 0.0.0.0

    m=video 8002 RTP/AVP 31

    a=control:rtsp://audio.com/movie.aud

    m=audio 8004 RTP/AVP 3

    a=control:rtsp://video.com/movie.vid

注意：描述中控制URL的位置暗示客户端要分别建立到服务器audio.com 和 video.com的RTSP控制会话。

推荐在SDP文件中包含完整的媒体初始化信息，即使SDP是通过非RTSP途径传送到媒体客户端的。这是有必要的，因为没有机制可以指示客户端应该通过DESCRIBE请求更多媒体流细节信息。

C.3 合控制有效

   此种前提下，服务器有可以被当作一个整体控制的多个流。在此情况下，就即有用于给出流URL的媒体级"a=control:"属性，又有用作合控制的请求URL的会话级"a=control:"。如果媒体级URL是相对URL，它将根据上文C1.1节所述被处理为绝对URL。

如果表示只由单个流组成，媒体级"a=control:"将被全部忽略。但是，如果表示包含多于一个流，每个媒体流部分【必须】包含自己的"a=control:"属性。

例子：

    v=0

    o=- 2890844256 2890842807 IN IP4 204.34.34.32

    s=I contain

    i=<more info>

    t=0 0

    c=IN IP4 0.0.0.0

    a=control:rtsp://example.com/movie/

    m=video 8002 RTP/AVP 31

    a=control:trackID=1

    m=audio 8004 RTP/AVP 3

    a=control:trackID=2

在此实例里，客户端被要求建立一个到服务器的RTSP会话，并用分别用URL rtsp://example.com/movie/trackID=1 和rtsp://example.com/movie/trackID=2 建立视频和音频流。URL rtsp://example.com/movie/控制整个电影。

附录D：最小RTSP实现

D.1 客户端

客户端实现【必须】能够做到如下几点：

*生成下列请求：SETUP, TEARDOWN, 和 PLAY (意即, 一个最小回放客户端) 或 RECORD (意即, 一个最小录制客户端)。如果RECORD被实现，ANNOUNCE【必须】也被实现。

*在请求中包含下列头部：CSeq, Connection, Session, Transport。如果 ANNOUNCE 被实现，也应该实现包含Content-Language, Content-Encoding, Content-Length, 及 Content-Type 头部的能力。

*解析并理解下列响应中的头部：CSeq,Connection, Session, Transport, Content-Language, Content-Encoding, Content-Length, Content-Type。如果实现了RECORD，则也必须理解Location头部。RTP-compliant（RTP适用的）实现应该再实现RTP-Info。

*如果收到一个型别为4xx 或5xx的错误代码，理解所收到错误代码的型别并通知最终用户。如果最终用户明确指出不想要一个或所有状态码的产生条件，则可以不进行通知。

*期待并回复服务器的异步请求，例如ANNOUNCE。这并不是说它一定要实现ANNOUNCE方法，而只是【必须】对收到的任何服务器请求作出肯定或否定响应。

虽然不是必需，但为了便于实际中同早期实现协同工作且/或成为“好市民”，在发布时仍强烈推荐实现下述功能。

    * 实现 RTP/AVP/UDP ，使其成为有效 transport.

    * 包含 User-Agent 头部.

    * 理解附件C中定义的 SDP 会话描述

    * 接受从标准输入、命令行、及其他适合操作环境的效果如同一个程序（如web浏览器）的“帮助程序”的方式等,得来的媒体初始化格式(例如 SDP)。

可能有些RTSP程序跟RTSP规范的创建者的预想不同，对于这些程序，上述要求并无意义。因此，上面的推荐仅作为指导，而非严格的要求。

D.1.1 基本回放

   为支持按需点播媒体流，客户端【必须】额外地支持：

*生成PAUSE请求

*实现REDIRECT方法及Location头部

D.1.2 鉴权－激活

   为访问要求鉴权的RTSP服务器上的媒体表示，客户端【必须】额外地支持：

*识别401状态码

*解析并包括WWW-Authenticate头部

*实现基本鉴权和Digest鉴权

D.2 服务器

   最小服务器实现【必须】能够做到：

*实现下列方法：SETUP, TEARDOWN, OPTIONS 以及PLAY (对于最小回放服务器) or RECORD (对于最小录制服务器)。如果实现RECORD, ANNOUNCE也应该实现。

*包含下列头部：Connection, Content-Length, Content-Type, Content-Language, Content-Encoding, Transport, Public。如果实现RECORD方法，也应实现包含Location头部的能力。RTP-compliant（RTP适应的）实现还应该实现RTP-info域。

*正确解析及响应请求中的下列头部：Connection, Session, Transport, Require。

虽然不是必需，但为了便于实际中同早期实现协同工作且/或成为“好市民”，在发布时仍强烈推荐实现下述功能。

    * 实现 RTP/AVP/UDP ，使其成为有效 transport。

    * 包含 Server 头部。

    * 实现DESCRIBE方法。

    * 按附录C中的定义生成SDP会话描述。

可能有些RTSP程序跟RTSP规范的创建者的预想不同，对于这些程序，上述要求并无意义。因此，上面的推荐仅作为指导，而非严格的要求。

D.2.1 基本回放

   为支持媒体流按需点播，服务器【必须】额外地支持：

*识别Range头部，并在不支持搜索时返回error。

*实现PAUSE方法。

此外，为支持普遍接受的用户界面特性，高度推荐按需点播媒体服务器支持以下几点：

*包含并解析Range头部，使用 NPT单位。并推荐实现SMPTE单位。

*在媒体初始化信息中包含媒体表示的长度。

*包含从数据－相关 时间戳到NPT的映射。使用RTP时，用RTP-info域的rtptime部分来把RTP时间戳映射到NPT。

客户端实现可能会用length信息的出现与否来判断剪辑是否可搜索，并据此屏蔽没有length信息的剪辑的搜索特性。常见的表示长度的应用是实现一个“滑动条”，它即可以指示进度，又可以指示时间位置。

RTP时间戳到NPT的映射是必要的，以保证滑动条位置正确。

D.2.2 鉴权－激活

   为正确处理客户端鉴权，服务器【必须】额外支持：

*当资源需要鉴权时生成401状态码

*解析并包括WWW-Authenticate头部

*实现基本鉴权和Digest鉴权

---

 [V1]指此协议的发布方式，与本协议内容无关。

 [V2]只提供控制层协议，不包括传输层

 [V3]如视频会议等

 [V4]言下之意似乎是对于不同的媒体类型，Media parameter可能会不同？望高手指教。

 [MS5]事实上我觉得没有那么简单

 [MS6]指延续使用了http上的一些机制

 [MS7]http服务器是无状态的，而rtsp服务器有

 [V8]指媒体流的传输和rtsp使用同一个tcp连接

 [V9]指独立于RTSP协议所用的传输层协议，而HTTP协议的数据传输是和HTTP本身共用同一个传输层协议的。

 [V10]HTTP协议没有状态机制

 [V11]啰嗦一句，中文翻译中有的“实现”是动词，有的是“动名词”，但有些是纯粹的名词，指解决方案，请大家根据上下文理解。

 [V12]指不是基于字符的，不限于某种字符集

 [V13]这应该是说仅支持US-ASCII的程序无法支持该字符集

 [V14]许多程式由於各式各样的原因，并未考虑到输

入的资料可能是 non-ASCII 码的问题。它往往假设了它所要处理的资料都是

ASCII 码，更糟糕的是，当它遇到 non-ASCII 码时，常常假设它不存在，而将它

的第八个位元截去! 这是所谓的 8-bit clean 问题。

 [V15]unchanged in value following multiplication by itself

 [V16]指无法理解后两位内容的

 [V17]round-trip-time，一项衡量网络延迟的指标

 [V18]RTT(Round-Trip Time): 往返时延，在计算机网络中它也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延;

 [V19]其实就是类似flashget等程序的启动方式：一旦点击或拷贝了下载路径，就自动开始工作。（我只是举例说明它的启动方式，不是说要实现那种后台监控功能）

 [V20]指使服务器端能支持RTSP标准协议的最小功能集

 [V21]指使客户端能以最简单的功能集支持RTSP标准协议

 [V22]所以客户端应尽可能把自己支持的传输方式都列上去，以便服务器做出选择：列出的方式越多，传输成功建立的可能性就越大

 [V23]这当然是指对同一个客户端而言。

 [V24]一种绝对时间，其内容相当于2007年4月12日3:05:37这种。

 [V25]应该是意指范围的形式不同，而实际意义相同

 [V26]即我们可以让图像继续播放，而声音暂停传输。

 [V27]应是指当前还没结束或者还没开始的一个PLAY请求。

 [V28]指对参数值的设定

 [V29]即尽量不把会由于不同原因被拒绝的参数放在一起

 [V30]原子操作即不可以或者不应该再分割的操作，写过多线程程序的人应该有体会。又例如：智能收费卡的pos机上，"读取当前余额+扣除本次消费+更新余额信息”应该被实现为一次原子操作，要么全部成功，要么全部失败，否则就容易出现学生卡已被扣费食堂却说缴费失败这类问题。

 [V31]指媒体内的时间而言

 [V32]常见的情况是网关不允许UDP传输或只打开了HTTP端口

 [V33]end-to-end authentication：与nod-to-nod authentication不同，中间有可能经过其他节点，但无论其他节点如何，会保证这两端的鉴权

 [V34]这是一个时间段

 [V35]这是一个时间点

 [V36]

 [V37]在我找到的RFC文档中应该是[H14.35.1]

 [V38]和什么相关？

 [V39]例如对视频进行拖放

 [V40]应该是指光RTCP还不是充分条件

 [V41]endpoint address 端点地址: 对于任何赋予计算机能用作目的地地址的一类地址术语。例如,IP地址是一种端点地 址。

 [V42]意为“直达，切入式，直通的”

 [V43]我不太清楚这是指语言翻译呢还是编码格式的转换

 [V44]不太理解

 [V45]