RTSP协议中文版

1 绪论

1.1 目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流有可能交叉，但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的网络远程控制。

表示描述(presentation description)定义了被控流，但本文并没有定义表示描述的格式。

这里没有使用RTSP连接的概念，而由RTSP会话(session)代替（每次服务由服务器端保持一个带标签的会话）。RTSP会话没有绑定到传输层连接（如TCP连接）。因为虽然在RTSP会话期间，RTSP客户端可打开或关闭多个对服务器端的可靠传输连接以发出RTSP 请求。但此外，也可能使用无连接传输协议，比如用UDP发送RTSP请求。

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

2 RTSP引入了很多新方法并且有不同的协议标识符。
2 RTSP服务器在大多数默认情况下需要维持一个状态，但HTTP是无状态协议。
2 RTSP客户机和服务器都可以发出请求。
2 数据由另一个协议传送（有一特例除外）。
2 RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。
2 RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中。
这使得“虚拟主机”实现更为简便，一个单独IP地址的主机可虚拟为几个文件树主机。

协议支持的操作如下：

从媒体服务器上检索媒体：
用户可通过HTTP或其它方法请求一个表示描述。如表示是组播，表示描述就包含用于连续媒体的的组播地址和端口。如表示仅通过单播发送给用户，用户为了安全应提供目的地址。

媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

将媒体加到现成讲座中：
　 如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。

如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
1.2 要求
在本文档中的关键字“必须”，“一定不能”，“要求”，“会”，“不会”，“应该”，“不应该”，“被推荐的”，“可以”，和“可选择的”都在RFC2119中解释。
1.3 术语
一些术语原由HTTP/1.1采用。在HTTP/1.1中定义的术语这里不再列举。

合控制：
服务器使用单条时间线对多个流的控制。对音频/视频回馈来讲，这就意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回馈。
会议：
多方参与的多媒体表示，这里的多方意味着大于或者等于一方。
客户端：
指请求媒体服务器上连续流媒体数据的客户端。
连接：
 两个应用程序以通讯为目的在传输层建立虚拟电路。
容器文件：
 可以容纳多个共同播放时包含表示(presentation)的媒体流的文件。RTSP服务器可以为这 些容器文件提供合控制，但容器文件的概念本身并不是本协议内容。
连续媒体：
 接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重新产生存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（但是不交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流的形式，这种关系就没有那么严格了。
实体：
作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成，如第八章所述。
媒体的初始化：
数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。用户请求媒体回放的任何独立传输信息，是在创建流时初始化媒体流相位时产生的。
媒体参数:
针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。
媒体服务器：
可对一个或多个媒体流提供回放和录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建立在作为传送请求表示(presentation)的Web服务器的主机上，也可以建立在不同的主机上。
媒体服务器重定向：
 重新定向媒体客户端到另外一个媒体服务器。
(媒体)流：
 单个媒体实例，比如，在应用中共用音频流或视频流。当使用RTP时，流包括由RTP 会话(session)中源所创建的所有RTP和RTCP包。这和定义DSM-CC流时相同。
消息：
RTSP通讯的基本单元。由15章语法定义的一串八位位组组成，并通过连接或者无连接协议传送。
参与者：
一个会议成员。参与者可以是机器，比如是媒体记录或回放服务器。
表示(presentation)：
对用户请求所回馈的一组流，其使用下面的表示描述(presentation description)形式。在本文中的多数情况下，其意味着对流进行总体控制，但这并不是必须的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息。另外，其他IETF协议，如SDP协议使用会话(session)代替现场presentation。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。
回Γ?br />RTSP回应。如果能理解HTTP回应，就能清楚的理解RTSP回应。
请求；
RTSP请求。如果能理解HTTP请求，就能清楚的理解RTSP请求。
RTSP会话(session)：
RTSP交互的全过程。比如，一个电影的观看过程。会话(session)包括由客户端建立连续媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。
传输初始化：
客户端和服务器端之间传输信息（端口号，传输协议等）的交互。
1.4 协议特点
RTSP 特性如下：
可扩展性：
　 RTSP中很容易加入新方法和参数。
易解析：
　 RTSP可由标准 HTTP或MIME解析器解析。
安全：
RTSP使用网页安全机制。所有HTTP授权机制如basic和digest授权都可直接使用。也可以传输层或网络层安全机制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
表示(presentation)中的每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：
　 协议可控制记录和回放设备，也可控制可在记录和回放切换的设备。
流控与会议开始分离：
流控与邀请媒体服务器入会分离；仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323 可用来邀请服务器入会。
适合专业应用：
　 通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
表示描述中立：
协议没强加特殊表示或元文件，可传达所用格式类型；然而，表示描述至少必须包含一个RTSP URI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个/"缺口/"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
适当的服务器控制：
　 如用户能启动一个流，它必须也能停止一个流。 服务器不能启动一个用户不能停止的流。
传输协调：
　 实际处理连续媒体流前，用户可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。 例如，如果不允许寻找，用户界面必定能禁止位置条滑动。
以前要求RTSP必须能支持多用户，但现在得出一个更好的方法就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此”远程通过”成为可能。协议不涉及到多个客户端如何协调入口，其由下层“社会协议”或其他下层控制机制提供。
1.5 RTSP扩展
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。例如：
? 服务器可能只须支持回放，因此不必不支持录制功能。
? 对于支持现场播放的服务器可能不支持寻找功能。
? 一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER。
但服务器应该实现所有12章中要求的标题域。
表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1中[H19.6]描述方法不支持across server的情形一致。
RTSP 可以如下三种方式扩展，这里以改变大小排序：
? 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
? 加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共回应标题列出支持的方法。
? 定义新版本协议，允许改变所有部分。（除了协议版本号位置）
1.6 操作模式
　 每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，表示描述格式不在本协议中定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
　 为了说明，假设表示描述(presentation description)描述了多个表示(presentation)，其中每个表示(presentation)维持了一个公共时间轴。为简化说明，且不失一般性，假定表示描述(presentation description)的确包含这样一个表示(presentation)。表示(presentation)可包含多个媒体流。
表示描述(presentation description)即组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，被RTSP分别控制的媒体流由RTSP URL表示。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而负载共享。描述（description)还列出了服务器传输可使用的方法。
除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
单播：
　 以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
　 媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
　 如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
1.7 RTSP状态
　 RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的会话状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的用：
SETUP：
　 让服务器给流分配资源，启动RTSP会话。
PLAY与RECORD：
　 启动SETUP 分配流的数据传输。
PAUSE：
　 临时停止流，而不释放服务器资源。
TEARDOWN：
　 释放流的资源，RTSP会话停止。
　 标识状态的RTSP方法使用会话(session)标题域识别RTSP会话，为回应SETUP请求，服务器生成会话标识。
1.8 与其他协议关系
　 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，表示描述(presentation description)可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。
　 但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出回应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。
重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
　 当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。
RTSP假设存在表示描述格式可表示包含几个媒体流的表示的静态与临时属性。

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

与[H2.1]类似，本文对所有机制的说明都是以散文和补充反馈的方式来描述的。除RTSP中以”1#”代替”,”为分隔符不同外，其余在RFC 2234中有详细的描述。简单说明补充反馈方式如下：

补充反馈方式（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）
规则的名字（name）就是它本身（不带任何尖括号，“

字面意思（"literal"）
文字的字面意思放在引号中间，除非特别指定，该段文字是大小写敏感的。

规则1｜规则2（rule1 | rule2）
“｜”表示其分隔的元素是可选的，比如，“是｜否”要选择‘是’或‘否’。

（规则1　规则2）（(rule1 rule2)）
在圆括号中的元素表明必选其一。如（元素1（元素2｜元素3）元素4）可表明两
种意思，即“元素1　元素2　元素4”和“元素1　元素3　元素4”

*规则（*rule）
在元素前加星号“*”表示循环，其完整形式是“

〔规则〕（[rule]）
方括号内是可选元素。如“〔元素1　元素2〕”与“*1（元素1　元素2）”是一回事。

N　规则（N rule）
表明循环的次数：“

＃规则（#rule）
“#”与“*”类似，用于定义元素列表。

完整形式是“

空元素在结构中可被任意使用，但不参与元素个数的计数。也就是说，“（元素1），，
（元素2）”仅表示2个元素。但在结构中，应至少有一个非空的元素存在。缺省
值是0到无限，即“#（元素）”表示可取任何数值，包括0；而“1#元素”表示至
少有1个；而“1#2元素”表示有1个或2个。

；注释（; comment）
分号后面是注释，仅在单行使用。

隐含*LWS（implied *LWS）
本文的语法描述是基于单词的。除非另有指定，线性空格（LWS）可以两个邻近符
号或分隔符（tspecials）之间任意使用，而不会对整句的意思造成影响。在两个符号之
间必须有至少一个分隔符，因为它们也要做为单独的符号来解释。实际上，应用程序在
产生HTTP结构时，应当试图遵照“通常方式”，因为现在的确有些实现方式在通常方
式下无法正常工作。

在本备忘录中，我们用缩进的小型段落来提供动机和背景资料。这将使没有参与制定RTSP规范的读者更容易理解RTSP中各部分为什么要以该方式来实现。

3 协议参数
3.1 RTSP版本
同[H3.1]定义，仅用RTSP代替HTTP即可。如下：
RTSP采用主从（

本文档定义了RTSP协议的1.0版本。发送本规范定义的请求（Request）或回应（Response）消息的应用必须指明RTSP的版本为“RTSP/1.0”。使用该版本号意味着发送消息的应用至少有条件的遵循本规范。应用的RTSP版本即为应用至少能有条件遵循的RTSP版本中的最高版本。

当代理及网关收到与其自身版本不同的RTSP请求时，必须小心处理请求的推送，因为
协议版本表明发送方的能力，代理或网关不应发出高于自身版本的消息。如果收到高版本的请求，代理或网关必须降低该请求的版本，并回应一个错误。而低版本的请求也应在被推送前升级。代理或网关回应请求时必须和请求的版本相同。

3.2 RTSP URL
“rtsp”和“rtspu”表示要通过RTSP协议来定位网络资源。本节详细定义了RTSP URL的语法和语义。
rtsp_URL= ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host=

9 连接
　 RTSP请求可以几种不同方式传送：
　 1、持久传输连接，用于多个请求/回应传输。
　 2、每个请求/回应传输一个连接。
　 3、无连接模式。
　 传输连接类型由RTSP URI来定义。对 /"rtsp/" 方案，需要持续连接；而/"rtspu/"方案，调用RTSP 请求发送，而不用建立连接。
　 不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。

9.1 流水线操作
　 支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出回应。
9.2 可靠性及确认
如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。 RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
　 实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。

10 方法定义（method token）表示了对请求统一资源标志符（Request-URI）识别的资源所执行的操作。方法名区分大小写。将来可能定义新的方法。方法名可能不以美元符'＄'（十进制数24）开头，但必须具有表征意义(must be a token)。

表格2是对方法的一个小结。

method direction object requirement

DESCRIBE C -> S P,S recommended

ANNOUNCE C -> S,S ->C P,S optional

GET PARAMETER C -> S,S ->C P,S optional

OPTIONS C -> S,S ->C P,S required(S ! C: optional)

PAUSE C -> S P,S recommended

PLAY C -> S P,S required

RECORD C -> S P,S optional

REDIRECT S ->C P,S optional

SETUP C -> S S required

SET PARAMETER C -> S,S ->C P,S optional

TEARDOWN C -> S P,S required

表2：对RTSP方法，和其操作方向及所操作对象（P: 表示, S: 媒体流）的一个概览

注意：PAUSE方法是推荐的, 但在构建一个全功能的服务器（fully functional server）

时可能不支持此方法，这时就不需要它，比如对于live feeds。如果服务器不支持某个特殊

方法，它必将返回"501 Not Implemented"，并且客户端应该不再向该服务器请求该方法。

（注：Presentation是一个以完整的media feed呈现给client的一个或多个媒体流的集合，

暂且翻译成表示）

10.1 OPTIONS

其行为与[H9.2]中描述的等同。OPTIONS请求可能在任何时候发出，例如客户端将要发

出一个非标准的请求时。它不影响服务器状态。

示例：

C->S: OPTIONS * RTSP/1.0

CSeq: 1

Require: implicit-play

Proxy-Require: gzipped-messages

S->C: RTSP/1.0 200 OK

CSeq: 1

Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

注意：这些都是必要的构造特征（necessarily fictional features）。 (你可能不希望我

们去有意忽略那些实际上有用的特征，因此在这一部分中我们将给出一个详细的例子)。

10.2 DESCRIBE

DESCRIBE方法从服务器检索表示的描述或媒体对象，这些资源通过请求统一资源定位符（the request URL）识别。此方法可能结合使用Accept首部域来指定客户端理解的描述格式。服务器端用被请求资源的描述对客户端作出响应。DESCRIBE的答复-响应对（reply-response pair）组成了RTSP的媒体初始化阶段。

示例：

C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl, application/mheg

S->C: RTSP/1.0 200 OK

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Content-Type: application/sdp

Content-Length: 376

v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 3456 RTP/AVP 0

m=video 2232 RTP/AVP 31

m=whiteboard 32416 UDP WB

a=orient:portrait

DESCRIBE响应必须包含它所描述资源的所有媒体初始化信息。如果媒体客户端从一个数据源获得表示描述，而非通过DESCRIBE，并且该描述包含了一个媒体初始化参数的全集，那么客户端就应该使用这些参数，而不是再通过RTSP请求相同媒体的描述。

再有，服务器不应该（SHOULD NOT）使用DESCRIBE响应作为media indirection的方法。

需要建立基本的规则，使得客户端有明确的方法了解何时通过DESCRIBE请求媒体初始化信息，何时不请求。强制DESCRIBE响应包含它所描述媒体流集合的所有初始化信息，不鼓励将DESCRIBE用作media indirection的方法，通过这两点避免了使用其他方法可能会引起的循环问题（looping problems）

媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过3种方法来接收媒体初始化信息：

. DESCRIBE方法；

.其它一些协议（HTTP，email附件，等）；

.命令行或标准输入（同一个SDP或其它媒体初始化格式的文件一起启动，工作方式类似于浏览器的帮助程序）。

为了实际协同工作，严重（）推荐最精简的服务器也支持DESCRIBE方法，最精简的客户端也支持从标准输入，命令行和/或其它对于客户端操作环境合适的方法来接收媒体初始化文件的能力。

10.3 ANNOUNCE

ANNOUNCE方法有两个用途：

当客户端向服务器发送时，ANNOUNCE将通过请求URL识别的表示描述或者媒体对象提交给服务器；

当服务器相客户端发送时，ANNOUNCE实时更新会话描述。

如果有新的媒体流加到表示中（比如在一个现场表示中），整个表示描述应该重发；而不只是增加组件，如果这样做的话，组件也可以被删除了。

示例：

C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344

Content-Type: application/sdp

Content-Length: 332

v=0

o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 3456 RTP/AVP 0

m=video 2232 RTP/AVP 31

S->C: RTSP/1.0 200 OK

CSeq: 312

10.4 SETUP

SETUP请求为URI指定流式媒体的传输机制。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。 为了尽量绕开防火墙干涉，即使它不会影响参数，客户端也必须指出传输参数，例如，指出服务器向外发布的固定的广播地址。

由于SETUP包括了所有传输初始化信息，防火墙和其他中间的网络设备（它们需要这些信息）分让了解析DESCRIBE响应的繁琐任务，这些任务留给了媒体初始化。

Transport首部域指定了客户端数据传输时可接受的传输参数；响应包含了由服务器选出的传输参数。

C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

S->C: RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

作为对SETUP请求的响应，服务器产生了会话标志符。如果对服务器的请求中包含了会话标志符，服务器必须将此setup请求捆绑到一个存在的会话，或者返回"459 Aggregate Operation Not Allowed"。

10.5 PLAY

PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。

比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 835

Session: 12345678

Range: npt=10-15

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 836

Session: 12345678

Range: npt=20-25

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 837

Session: 12345678

Range: npt=30-

结合PAUSE请求的描述，看更深一层的示例。

不含Range首部域的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（the pause point）重新开始。

如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。

Range首部域可能包含一个时间参数。该参数以UTC格式指定了播放（palayback）开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。

对于一个点播（On-demand）媒体流，服务器用播放（play back）的实际范围答复请求。This

may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source.如果在请求中没有指定范围，当前位置将在答复中返回。答复中播放范围的单位与请求中相同。在播放完被要求的范围后，表示将自动暂停，就好像发出了一个PAUSE请求。

下面的示例在play整个表示时从SMPTE时间0:10:20直到剪辑（clip）结束。播放开始于1997年1月23号，15点36分

C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0

CSeq: 833

Session: 12345678

Range: smpte=0:10:20-;time=19970123T153600Z

S->C: RTSP/1.0 200 OK

CSeq: 833

Date: 23 Jan 1997 15:35:06 GMT

Range: smpte=0:10:22-;time=19970123T153600Z

For playing back a recording of a live presentation, it may be desirable to use clock

units:

C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0

CSeq: 835

Session: 12345678

Range: clock=19961108T142300Z-19961108T143520Z

S->C: RTSP/1.0 200 OK

CSeq: 835

Date: 23 Jan 1997 15:35:06 GMT

只有播放的媒体服务器必须支持npt时间格式，可能支持clock和smpte格式。

10.6 PAUSE

PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。比如，指定暂停音频，播放将会无声。如果请求URL指定了一个表示或者媒体流已成组，那么在该表示或组中的所有当前活动流的传输将被暂停。在重启播放或记录后，必须维护不同媒体轨迹（track）的同步。尽管服务器可能在暂停后，在timeout的时间内关闭会话，释放资源，但是任何资源都必须保存，其中timeout参数位于SETUP消息的会话头中。

示例：

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 834

Date: 23 Jan 1997 15:35:06 GMT

PAUSE请求中可能包含一个Range首部域用来指定何时媒体流或表示暂停，我们称这个时刻为暂停点（pause point）。该首部域必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。如果Range首部域指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invali