1 Introduction (简介)

1.1 Purpose (目的)

Real-Time Streaming Protocol (实时流协议, RTSP) 建立并控制单个或多个时间同步的连续媒体流, 如音频和视频。它通常不自行传输连续流, 尽管连续媒体流与控制流的交织是可能的 (参见第 10.12 节)。换句话说, RTSP 充当多媒体服务器的 "网络远程控制"。

要控制的流集由演示描述 (presentation description) 定义。本备忘录不定义演示描述的格式。

RTSP 没有连接的概念; 相反, 服务器维护一个由标识符标记的会话。RTSP 会话绝不与传输层连接 (如 TCP 连接) 绑定。在 RTSP 会话期间, RTSP 客户端可以打开和关闭多个可靠的传输连接到服务器以发出 RTSP 请求。或者, 它可以使用无连接传输协议, 如 UDP。

RTSP 控制的流可以使用 RTP [1], 但 RTSP 的操作不依赖于用于传输连续媒体的传输机制。该协议在语法和操作上有意与 HTTP/1.1 [2] 相似, 以便在大多数情况下也可以将 HTTP 的扩展机制添加到 RTSP。但是, RTSP 在许多重要方面与 HTTP 不同:

RTSP 引入了许多新方法并具有不同的协议标识符。* RTSP 服务器在几乎所有情况下默认需要维护状态, 这与 HTTP 的无状态性质相反。* RTSP 服务器和客户端都可以发出请求。* 数据通过不同的协议带外传输。(这有一个例外。) * RTSP 定义为使用 ISO 10646 (UTF-8) 而不是 ISO 8859-1, 与当前的 HTML 国际化工作 [3] 一致。* Request-URI 始终包含绝对 URI。由于与历史错误的向后兼容性, HTTP/1.1 [2] 仅在请求中携带绝对路径, 并将主机名放在单独的头部字段中。

这使得 "虚拟主机" 更容易, 其中具有一个 IP 地址的单个主机托管多个文档树。

该协议支持以下操作:

从媒体服务器检索媒体: 客户端可以通过 HTTP 或其他方法请求演示描述。如果演示正在组播, 演示描述包含用于连续媒体的组播地址和端口。如果演示仅通过单播发送到客户端, 出于安全原因, 客户端提供目标地址。

邀请媒体服务器参加会议: 可以 "邀请" 媒体服务器加入现有会议, 以将媒体播放到演示中或记录演示中的全部或部分媒体。此模式对分布式教学应用程序很有用。会议中的几方可以轮流 "按远程控制按钮"。

向现有演示添加媒体: 特别是对于实时演示, 如果服务器可以告诉客户端有关其他可用媒体的信息, 这会很有用。

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

1.2 Requirements (要求)

本文档中的关键词 "MUST" (必须), "MUST NOT" (绝对不能), "REQUIRED" (必需), "SHALL" (应), "SHALL NOT" (不应), "SHOULD" (应该), "SHOULD NOT" (不应该), "RECOMMENDED" (推荐), "MAY" (可以) 和 "OPTIONAL" (可选) 应按 RFC 2119 [4] 中描述的方式解释。

1.3 Terminology (术语)

一些术语采用自 HTTP/1.1 [2]。此处未列出的术语与 HTTP/1.1 中的定义相同。

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

Conference (会议): 多方、多媒体演示, 其中 "multi" (多) 意味着大于或等于一。

Client (客户端): 客户端从媒体服务器请求连续媒体数据。

Connection (连接): 为通信目的在两个程序之间建立的传输层虚拟电路。

Container file (容器文件): 可能包含多个媒体流的文件, 这些流在一起播放时通常构成演示。RTSP 服务器可以对这些文件提供聚合控制, 尽管容器文件的概念未嵌入协议中。

Continuous media (连续媒体): 源和接收器之间存在时间关系的数据; 也就是说, 接收器必须重现源处存在的时间关系。连续媒体的最常见示例是音频和运动视频。连续媒体可以是实时的 (交互式), 其中源和接收器之间存在 "紧密" 的时间关系, 或者是流式的 (播放), 其中关系不那么严格。

Entity (实体): 作为请求或响应的有效载荷传输的信息。实体由实体头部字段形式的元信息和实体主体形式的内容组成, 如第 8 节所述。

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

Media parameter (媒体参数): 特定于媒体类型的参数, 可以在流播放之前或期间更改。

Media server (媒体服务器): 为一个或多个媒体流提供播放或录制服务的服务器。演示中的不同媒体流可能来自不同的媒体服务器。媒体服务器可以与调用演示的 Web 服务器驻留在同一主机上或不同主机上。

Media server indirection (媒体服务器重定向): 将媒体客户端重定向到不同的媒体服务器。

(Media) stream (媒体流): 单个媒体实例, 例如音频流或视频流以及单个白板或共享应用程序组。使用 RTP 时, 流由 RTP 会话中源创建的所有 RTP 和 RTCP 数据包组成。这等同于 DSM-CC 流的定义 ([5])。

Message (消息): RTSP 通信的基本单元, 由与第 15 节中定义的语法匹配的结构化八位字节序列组成, 并通过连接或无连接协议传输。

Participant (参与者): 会议的成员。参与者可以是机器, 例如媒体记录或播放服务器。

Presentation (演示): 作为完整媒体源呈现给客户端的一组一个或多个流, 使用如下定义的演示描述。在 RTSP 上下文中的大多数情况下, 这意味着对这些流的聚合控制, 但不一定如此。

Presentation description (演示描述): 演示描述包含有关演示中一个或多个媒体流的信息, 例如编码集、网络地址和有关内容的信息。其他 IETF 协议 (如 SDP, RFC 2327 [6]) 对实时演示使用术语 "session" (会话)。演示描述可以采用几种不同的格式, 包括但不限于会话描述格式 SDP。

Response (响应): RTSP 响应。如果指的是 HTTP 响应, 则会明确指出。

Request (请求): RTSP 请求。如果指的是 HTTP 请求, 则会明确指出。

RTSP session (RTSP 会话): 完整的 RTSP "事务", 例如观看电影。会话通常包括客户端为连续媒体流设置传输机制 (SETUP)、使用 PLAY 或 RECORD 启动流以及使用 TEARDOWN 关闭流。

Transport initialization (传输初始化): 客户端和服务器之间传输信息 (例如端口号、传输协议) 的协商。

1.4 Protocol Properties (协议属性)

RTSP 具有以下属性:

Extendable (可扩展): 可以轻松地向 RTSP 添加新方法和参数。

Easy to parse (易于解析): RTSP 可以由标准 HTTP 或 MIME 解析器解析。

Secure (安全): RTSP 重用 Web 安全机制。所有 HTTP 身份验证机制 (如基本身份验证, RFC 2068 [2, 第 11.1 节]) 和摘要身份验证 (RFC 2069 [8]) 都直接适用。也可以重用传输或网络层安全机制。

Transport-independent (传输独立): RTSP 可以使用不可靠的数据报协议 (UDP) (RFC 768 [9])、可靠的数据报协议 (RDP, RFC 1151, 未广泛使用 [10]) 或可靠的流协议 (如 TCP, RFC 793 [11]), 因为它实现了应用层可靠性。

Multi-server capable (多服务器能力): 演示中的每个媒体流可以驻留在不同的服务器上。客户端自动与不同的媒体服务器建立多个并发控制会话。媒体同步在传输层执行。

Control of recording devices (录制设备的控制): 该协议可以控制录制和播放设备, 以及可以在两种模式之间交替的设备 ("VCR")。

Separation of stream control and conference initiation (流控制与会议启动的分离): 流控制与邀请媒体服务器参加会议是分离的。唯一的要求是会议启动协议提供或可用于创建唯一的会议标识符。特别是, SIP [12] 或 H.323 [13] 可用于邀请服务器参加会议。

Suitable for professional applications (适合专业应用): RTSP 通过 SMPTE 时间戳支持帧级精度, 以允许远程数字编辑。

Presentation description neutral (演示描述中立): 该协议不强加特定的演示描述或元文件格式, 可以传达要使用的格式类型。但是, 演示描述必须至少包含一个 RTSP URI。

Proxy and firewall friendly (代理和防火墙友好): 该协议应该易于由应用程序和传输层 (SOCKS [14]) 防火墙处理。防火墙可能需要理解 SETUP 方法以打开 UDP 媒体流的 "洞"。

HTTP-friendly (HTTP 友好): 在合理的情况下, RTSP 重用 HTTP 概念, 以便可以重用现有基础设施。此基础设施包括 PICS (Platform for Internet Content Selection [15,16]) 用于将标签与内容关联。但是, RTSP 不仅向 HTTP 添加方法, 因为在大多数情况下控制连续媒体需要服务器状态。

Appropriate server control (适当的服务器控制): 如果客户端可以启动流, 则必须能够停止流。服务器不应以客户端无法停止流的方式开始向客户端流式传输。

Transport negotiation (传输协商): 客户端可以在实际需要处理连续媒体流之前协商传输方法。

Capability negotiation (能力协商): 如果禁用基本功能, 则必须有一些干净的机制让客户端确定哪些方法不会被实现。这允许客户端呈现适当的用户界面。例如, 如果不允许查找, 用户界面必须能够禁止移动滑动位置指示器。

RTSP 的早期要求是多客户端能力。但是, 确定了更好的方法是确保协议易于扩展到多客户端场景。流标识符可以由多个控制流使用, 以便 "传递遥控器" 成为可能。该协议不会解决多个客户端如何协商访问; 这留给 "社交协议" 或其他底板控制机制。

1.5 Extending RTSP (扩展 RTSP)

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

服务器可能仅能够播放, 因此不需要支持 RECORD 请求。* 如果服务器仅支持实时事件, 则可能无法查找 (绝对定位)。* 某些服务器可能不支持设置流参数, 因此不支持 GET_PARAMETER 和 SET_PARAMETER。

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

演示描述的创建者有责任不要求服务器做不可能的事情。这种情况与 HTTP/1.1 [2] 类似, 其中 [H19.6] 中描述的方法不太可能在所有服务器上得到支持。

RTSP 可以通过三种方式扩展, 此处按支持的更改幅度顺序列出:

可以使用新参数扩展现有方法, 只要接收方可以安全地忽略这些参数。(这相当于向 HTML 标签添加新参数。) 如果客户端在不支持方法扩展时需要否定确认, 则可以在 Require: 字段中添加与扩展对应的标签 (参见第 12.32 节)。* 可以添加新方法。如果消息的接收方不理解请求, 则响应错误代码 501 (Not implemented), 发送方不应再次尝试使用此方法。客户端还可以使用 OPTIONS 方法来查询服务器支持的方法。服务器应该使用 Public 响应头部列出它支持的方法。* 可以定义协议的新版本, 允许几乎所有方面 (协议版本号的位置除外) 发生变化。

1.6 Overall Operation (整体操作)

每个演示和媒体流可以由 RTSP URL 标识。整体演示和演示所组成的媒体的属性由演示描述文件定义, 其格式超出了本规范的范围。客户端可以使用 HTTP 或其他方式 (如电子邮件) 获取演示描述文件, 并且不一定存储在媒体服务器上。

就本规范而言, 假设演示描述描述一个或多个演示, 每个演示维护一个共同的时间轴。为了简化说明并且不失一般性, 假设演示描述恰好包含一个这样的演示。演示可以包含多个媒体流。

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

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

Unicast (单播): 媒体传输到 RTSP 请求的源, 端口号由客户端选择。或者, 媒体在与 RTSP 相同的可靠流上传输。

Multicast, server chooses address (组播, 服务器选择地址): 媒体服务器选择组播地址和端口。这是实时或接近按需媒体传输的典型情况。

Multicast, client chooses address (组播, 客户端选择地址): 如果服务器要参与现有的组播会议, 则组播地址、端口和加密密钥由会议描述给出, 通过本规范范围之外的方式建立。

1.7 RTSP States (RTSP 状态)

RTSP 控制可以通过独立于控制通道的单独协议发送的流。例如, RTSP 控制可能发生在 TCP 连接上, 而数据通过 UDP 流动。因此, 即使媒体服务器没有收到 RTSP 请求, 数据传输也会继续。此外, 在其生命周期中, 单个媒体流可能由在不同 TCP 连接上顺序发出的 RTSP 请求控制。因此, 服务器需要维护 "会话状态" 以便能够将 RTSP 请求与流相关联。状态转换在附录 A 中描述。

RTSP 中的许多方法不会对状态产生影响。但是, 以下方法在定义服务器上流资源的分配和使用方面起着核心作用: SETUP、PLAY、RECORD、PAUSE 和 TEARDOWN。

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

PLAY 和 RECORD: 在通过 SETUP 分配的流上启动数据传输。

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

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

影响状态的 RTSP 方法使用 Session 头部字段 (第 12.37 节) 来标识正在操作其状态的 RTSP 会话。服务器响应 SETUP 请求生成会话标识符 (第 10.4 节)。

1.8 Relationship with Other Protocols (与其他协议的关系)

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

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

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

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

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