目的：

实时流协议（RTSP）用于建立和控制单个或多个时间同步的连续媒体流，例如音频和视频。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 地址的主机可以托管多个文档树

该协议支持以下操作：

• 1、 从媒体服务器检索媒体 ：客户端可以通过 HTTP 或其他方法请求演示描述。如果演示内容是通过多播进行的，演示描述将包含用于连续媒体的多播地址和端口。如果演示内容仅通过单播发送给客户端，出于安全原因，客户端需要提供目标地址。

• 2、邀请媒体服务器加入会议 : 媒体服务器可以被“邀请”加入一个已存在的会议，既可以将媒体播放到演示中，也可以录制演示中的全部或部分媒体。此模式对分布式教学应用非常有用。会议中的多方可以轮流“按下遥控按钮”。

• 3、向现有演示中添加媒体：特别是对于实时演示，如果服务器能够通知客户端有新的媒体可用，这是非常有用的。

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

协议特性：

RTSP 具有以下性质：

• 1、 可扩展性：可以轻松地向 RTSP 添加新方法和参数。

• 2、 易于解析：RTSP 可以通过标准的 HTTP 或 MIME 解析器进行解析。

• 3、 安全性：RTSP 重新利用了网络安全机制。所有 HTTP 认证机制，例如基本认证（RFC 2068 [2，第11.1节]）和摘要认证（RFC 2069 [8]），都可以直接应用。此外，还可以复用传输层或网络层的安全机制。

• 4、 传输独立性：RTSP 可以使用不可靠的数据报协议（UDP）（RFC 768 [9]）、可靠的数据报协议（RDP，RFC 1151，未广泛使用 [10]）或可靠的流协议（如 TCP，RFC 793 [11]），因为它实现了应用层的可靠性。

• 5、 多服务器能力：一个展示中的每个媒体流可以驻留在不同的服务器上。客户端会自动与不同的媒体服务器建立多个并发的控制会话。媒体同步在传输层进行。

• 6、 录制设备的控制：该协议可以控制录制和播放设备，以及能够在两种模式间切换的设备（如‘录像机’）。

• 7、 流控制与会议初始化的分离：流控制与邀请媒体服务器参加会议是分离的。唯一的要求是会议初始化协议要么提供、要么可以用于创建一个唯一的会议标识符。特别是，SIP [12] 或 H.323 [13] 可以用于邀请服务器加入会议。

• 8、 适用于专业应用：RTSP 支持通过 SMPTE 时间戳实现帧级精确度，以允许远程数字编辑。

• 9、 呈现描述中立性：该协议不强制要求特定的呈现描述或元文件格式，并且可以传达要使用的格式类型。然而，呈现描述必须至少包含一个 RTSP URI。

• 10、 代理和防火墙友好：该协议应能够被应用层和传输层（SOCKS [14]）防火墙轻松处理。防火墙可能需要理解 SETUP 方法，以便为 UDP 媒体流打开一个‘通道’

• 11、HTTP 友好：在合理的情况下，RTSP 复用了 HTTP 的概念，以便可以重用现有的基础设施。该基础设施包括用于将标签与内容关联的 PICS（互联网内容选择平台 [15,16]）。然而，RTSP 不仅仅是向 HTTP 添加方法，因为控制连续媒体在大多数情况下需要服务器状态。

• 12、 适当的服务器控制：如果客户端能够启动流，则必须能够停止流。服务器不应以客户端无法停止流的方式开始向客户端传输流。

• 13、 传输协商：客户端可以在实际处理连续媒体流之前协商传输方式。

• 14、 功能协商：如果基本功能被禁用，必须有某种明确的机制让客户端确定哪些方法不会被实现。这使客户端能够呈现适当的用户界面。例如，如果不允许寻址功能，用户界面必须能够禁止移动滑动位置指示器。

• 15、RTSP 早期的一个要求是多客户端能力。然而，后来确定更好的方法是确保该协议能够轻松扩展到多客户端场景。流标识符可以被多个控制流使用，因此可以实现‘传递遥控器’的功能。该协议不解决多个客户端如何协商访问的问题，这留给‘社交协议’或其他控制机制来处理。

扩展 RTSP：

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

• 1、服务器可能只具备播放功能，因此无需支持 RECORD 请求。

• 2、如果服务器只支持直播事件，它可能无法进行寻址（绝对定位）。

• 3、有些服务器可能不支持设置流参数，因此不支持 GET_PARAMETER 和 SET_PARAMETER 请求。

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

呈现描述的创建者应避免向服务器提出不可能实现的要求。这种情况类似于 HTTP/1.1 [2]，其中 [H19.6] 中描述的方法不太可能被所有服务器支持。

RTSP 可以通过三种方式扩展，这些方式按所支持的更改幅度排列如下：

• 1、现有方法可以通过新参数进行扩展，只要接收方能够安全地忽略这些参数。（这相当于向 HTML 标签添加新参数。）如果客户端在方法扩展不被支持时需要负面确认，则可以在 Require: 字段中添加对应于该扩展的标签（参见第12.32节）。

• 2、可以添加新方法。如果消息的接收方不理解请求，它会返回错误代码 501（未实现），并且发送方不应再次尝试使用此方法。客户端还可以使用 OPTIONS 方法查询服务器支持的方法。服务器应使用 Public 响应头列出其支持的方法。

• 3、可以定义协议的新版本，允许几乎所有方面发生变化（除了协议版本号的位置）。

整体操作：

每个展示和媒体流都可以通过一个 RTSP URL 进行标识。展示的整体内容以及构成展示的媒体属性由展示描述文件定义，其格式超出了本规范的范围。展示描述文件可以通过客户端使用 HTTP 或其他方式（如电子邮件）获取，并不一定存储在媒体服务器上。

根据本规范的要求，假设展示描述描述了一个或多个展示，每个展示都有一个共同的时间轴。为简化说明且不失一般性，假设展示描述只包含一个这样的展示。一个展示可以包含多个媒体流。

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

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

• 1、 单播：媒体传输到 RTSP 请求的来源，端口号由客户端选择。或者，媒体通过与 RTSP 相同的可靠流进行传输。

• 2、 多播，服务器选择地址：媒体服务器选择多播地址和端口。这是直播或准点播传输的典型情况。

• 3、 多播，客户端选择地址：如果服务器要参与一个已存在的多播会议，会议描述将提供多播地址、端口和加密密钥，这些是通过本规范范围之外的方法建立的  。

RTSP 状态：

RTSP 控制的流可以通过一个独立于控制通道的协议传输。例如，RTSP 控制可以通过 TCP 连接进行，而数据通过 UDP 传输。因此，即使媒体服务器未收到 RTSP 请求，数据传输仍然会继续。此外，在其生命周期内，单个媒体流可以通过依次在不同的 TCP 连接上发出的 RTSP 请求进行控制。因此，服务器需要维护‘会话状态’以便将 RTSP 请求与流关联。状态转换在第 A 节中描述。

许多 RTSP 方法不影响状态。然而，以下方法在定义服务器上流资源的分配和使用方面起着核心作用：SETUP、PLAY、RECORD、PAUSE 和 TEARDOWN：

• 1、SETUP:   使服务器为流分配资源并启动 RTSP 会话 .

• 2、PLAY  and  RECORD:  启动通过 SETUP 分配的流的数据传输。

• 3、PAUSE:  暂时停止流的传输，但不释放服务器资源。

• 4、TEARDOWN:  释放与该流相关的资源。RTSP 会话在服务器上终止。

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

与其他协议的关系 ：

RTSP 在功能上与 HTTP 有一定的重叠。它也可能与 HTTP 交互，因为对流媒体内容的初始访问通常通过网页进行。当前的协议规范旨在允许在实现 RTSP 的网络服务器和媒体服务器之间设置不同的交接点。例如，展示描述可以通过 HTTP 或 RTSP 获取，这减少了基于网页浏览器场景中的往返次数，同时也支持独立的 RTSP 服务器和客户端，完全不依赖于 HTTP。

然而，RTSP 与 HTTP 在本质上有所不同，因为数据传输是在带外通过不同的协议进行的。HTTP 是一个非对称协议，客户端发出请求，服务器响应。而在 RTSP 中，媒体客户端和媒体服务器都可以发出请求。RTSP 请求也不是无状态的；它们可以设置参数，并在请求被确认后继续控制媒体流。

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

虽然大多数实时媒体会使用 RTP 作为传输协议，但 RTSP 并不依赖于 RTP。RTSP 假设存在一种展示描述格式，能够表达包含多个媒体流的展示的静态和时间属性。

协议参数：

RTSP Version：

[H3.1] 适用，将 HTTP 替换为 RTSP。

RTSP URL：

'rtsp' 和 'rtspu' 方案用于通过 RTSP 协议引用网络资源。本节定义了 RTSP URL 的特定方案语法和语义 ：

rtsp_URL  =   ( "rtsp:" | "rtspu:" )"//" host [ ":" port ] [ abs_path ]host      =   <A legal Internet host domain name of IP address(in dotted decimal form), as defined by Section 2.1of RFC 1123 \cite{rfc1123}>port      =   *DIGIT

abs_path 定义于 [H3.2.1]。

请注意，片段和查询标识符目前没有明确定义，其解释留给 RTSP 服务器处理。

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

如果端口为空或未指定，则假定为端口 554。语义是，所标识的资源可以通过 RTSP 进行控制，服务器在主机的该端口上监听 TCP（'rtsp' 方案）连接或 UDP（'rtspu' 方案）数据包，该资源的 Request-URI 为 rtsp_URL。

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

展示或流通过文本媒体标识符进行标识，使用 URL 的字符集和转义约定 [H3.2]（RFC 1738 [20]）。URL 可以引用一个流或多个流的集合，即展示。因此，第10节中描述的请求可以应用于整个展示或展示中的单个流。请注意，有些请求方法只能应用于流，不能应用于展示，反之亦然。

例如，RTSP URL：

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

标识展示 'twister' 中的音频流，该流可以通过向主机 media.example.com 的 554 端口发出的 RTSP 请求进行控制，RTSP 请求通过 TCP 连接发送。

同样，RTSP URL：

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

标识展示 'twister'，该展示可能由音频和视频流组成。
这并不意味着存在一种标准方式来通过 URL 引用流。展示描述定义了展示中的层次关系以及各个流的 URL。展示描述可能将一个流命名为 'a.mov'，而将整个展示命名为 'b.mov'。

RTSP URL 的路径部分对客户端是不可见的，并且不暗示服务器有任何特定的文件系统结构。这种解耦还允许通过简单地替换 URL 中的方案，将展示描述用于非 RTSP 媒体控制协议。

会议标识符：

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

conference-id =   1*xchar

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

会话标识符:

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

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

SMPTE 相对时间戳:

SMPTE 相对时间戳表示相对于剪辑开始的时间。相对时间戳以 SMPTE 时间码表示，以实现帧级访问精度。时间码的格式为 小时:分钟:秒:帧.子帧，起点为剪辑的开头。默认的 SMPTE 格式为 'SMPTE 30 drop' 格式，帧率为 29.97 帧每秒。其他 SMPTE 码（例如 'SMPTE 25'）可以通过使用其他 'SMPTE 时间' 支持。时间值中的 'frames' 字段可以取值 0 到 29。30 帧每秒与 29.97 帧每秒之间的差异通过在每分钟的前两帧索引（值为 00 和 01）丢弃来处理，除了每第十分钟。如果帧值为零，可以省略。子帧以帧的百分之一测量。

正常播放时间:

正常播放时间 (NPT) 表示流相对于展示开头的绝对位置。时间戳由小数部分组成。小数点左边的部分可以用秒或小时、分钟和秒表示。小数点右边的部分表示秒的小数部分。

展示的开始对应于 0.0 秒。不定义负值。特殊常量 'now' 表示直播事件的当前时刻，仅可用于直播事件。

NPT 的定义与 DSM-CC 中相同：'直观上，NPT 是观看者与节目相关联的时钟。它通常会在录像机上以数字形式显示。当处于正常播放模式（比例 = 1）时，NPT 正常前进；当快速向前扫描时，NPT 以更快的速率前进（高正比例）；当反向扫描时，NPT 减少（高负比例）；暂停模式下，NPT 固定不动。NPT 在逻辑上相当于 SMPTE 时间码。'" [5]

该语法符合 ISO 8601 标准。npt-sec 记法优化用于自动生成，npt-hhmmss 记法则便于人类阅读。'now' 常量允许客户端请求接收直播内容，而非存储或延迟播放的版本。这是必要的，因为对于这种情况，绝对时间或零时间都不合适。

绝对时间:

绝对时间以 ISO 8601 时间戳表示，使用协调世界时 (UTC)（格林尼治标准时间）。可以表示秒的小数部分.