RTSP协议（3）——介绍（RFC2326）

RTSP协议（3）——介绍

原文第一章

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地址的主机托管多个文档树。

协议支持以下操作：

• 从媒体服务器检索媒体：

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

• 邀请媒体服务器参加会议：

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

• 向现有演示文稿添加媒体：

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

RTSP请求可以由HTTP/1.1[2]中的代理、隧道和缓存来处理。

2.要求

本文件中的关键词“必须”、“不得”、“必须”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中的描述进行解释。

3.术语

一些术语已经从HTTP/1.1[2]中采用。这里没有列出的术语在HTTP/1.1中定义。

• 聚合控制：

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

• 会议：

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

• 客户：

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

• 连接：

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

• 容器文件：

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

• 连续介质：

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

• 实体：

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

• 媒体初始化：

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

• 介质参数：

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

• 媒体服务器：

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

• 媒体服务器间接寻址：

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

• （媒体）流：

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

• 信息：

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

• 参与者：

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

• 演示：

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

• 演示文稿说明：

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

• 答复：

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

• 请求：

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

• RTSP会话：

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

• 传输初始化：

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

4.协议属性

RTSP具有以下属性：

• 可扩展：

新的方法和参数可以很容易地添加到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的早期需求是多客户机功能。但是，确定更好的方法是确保协议易于扩展到多客户机场景。流标识符可由多个控制流使用，因此“通过远程”将是可能的。该协议不会解决多个客户端如何协商访问的问题；这是留给一个“社会协议”或其他一些楼层控制机制。

5.扩展RTSP

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

• 服务器可能只能回放，因此不需要支持记录请求。
• 如果服务器仅支持实时事件，则可能无法查找（绝对定位）。
• 有些服务器可能不支持设置流参数，因此不支持GET_参数和SET_u参数。

服务器应该实现第12节中描述的所有头字段。

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

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

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

6.整体操作

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

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

表示描述文件包含构成表示的媒体流的描述，包括它们的编码、语言和其他参数，这些参数使客户端能够选择最合适的媒体组合。在该表示描述中，RTSP单独控制的每个媒体流由RTSP URL标识，RTSP URL指向处理该特定媒体流的媒体服务器并命名存储在该服务器上的流。多个媒体流可以位于不同的服务器上；例如，音频和视频流可以跨服务器分割以进行负载共享。描述还列举了服务器能够使用的传输方法。

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

单播：

媒体被传输到RTSP请求的源，端口号由客户机选择。或者，媒体在与RTSP相同的可靠流上传输。

多播，服务器选择地址：

媒体服务器选择多播地址和端口。这是现场或近媒体点播传输的典型案例。

多播，客户端选择地址：

如果服务器要参与现有的多播会议，则多播地址、端口和加密密钥由会议描述给出，通过本规范范围之外的方式建立。

7.RTSP状态

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

RTSP中的许多方法对状态没有贡献。但是，以下内容在定义服务器上流资源的分配和使用时起着中心作用：设置、播放、录制、暂停和拆卸。

设置：

使服务器为流分配资源并启动RTSP会话。

播放和录制：

在通过安装程序分配的流上开始数据传输。

暂停：

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

拆卸：

释放与流关联的资源。服务器上不再存在RTSP会话。

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

8.与其他协议的关系

RTSP在功能上与HTTP有一些重叠。它还可以与HTTP交互，因为与流内容的初始接触通常是通过网页进行的。当前协议规范的目的是允许web服务器和实现RTSP的媒体服务器之间的不同切换点。例如，可以使用HTTP或RTSP检索演示文稿描述，这减少了基于web浏览器的场景中的往返，但也允许独立的RTSP服务器和根本不依赖HTTP的客户端。

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

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

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

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