RFC2326(中文版)－实时流协议(RTSP) 第10章
时间:2007-03-25 22:15:48 来源:本站搜集整理 作者:Eric
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 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range首部域缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。
利用PAUSE请求可忽视所有排队的PLAY请求，但必须维护媒体流中的暂停点。不带Range首部域的后继PLAY请求从暂停点重启播放。
比如，如果服务器有两个挂起的播放请求，播放范围（range）分别是10到15和20到29，这时收到一个暂停请求，暂停点是NPT21，那么它将会开始播放第二个范围，并且在NPT21处停止。如果服务器正在服务第一个请求播放到NPT13位置，收到暂停请求，暂停点NPT12，那么它将立即停止。如果请求在NPT16暂停，那么服务器在完成第一个播放请求后停止，放弃了第二个播放请求。
再如，服务器收到播放请求，播放范围从10到15和13到20（即之间有重叠），PAUSE暂停点是NPT14，则当服务器播放第一段范围时，PAUSE请求将生效，而第二个PLAY请求会被忽略重叠部分，就好像服务器在开始播放第二段前收到PAUSE请求。不管PAUSE请求何时到达，它总是设置NPT到14。//？
如果服务器已经在Range首部域指定的时间外发送了数据，后继的PLAY仍会在暂停点及时重启，因为它认为客户端会丢弃在暂停点后收到的数据。这就确保了连续、无隙的暂停/播放循环。
10.7 TEARDOWN
TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。如果该URI是对此表示的表示URI，那么任何与此会话相关的任何RTSP会话标志符将不再有效。除非所有传输参数由会话描述符定义，否则SETUP请求必须在会话能被再次播放之前发出。
示例：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
10.8 GET PARAMETER
GET PARAMETER请求检索URI指定的表示或媒体流的参数值。答复和响应的内容留给了实现。不带实体主体的GET PARAMETER可用来测试客户端或服务器是否存活（"Ping"）。
示例：
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
"text/parameters"段只是参数类型的一个例子。对此方法有意的进行了松散的定义，对于答复和响应的内容将在更深一层的实验中给出定义。
10.9 SET PARAMETER
此方法给URI指定的表示或媒体流设置参数值。
帮助客户端检查某个特殊的请求为何失败的请求（晕~）应该只附带一个参数。当请求附带多个参数时，服务器只有在这些参数全都设置正确时才作出响应。服务器必须允许某个参数被重复设置成相同的值，但可能不允许改变参数值。
注意：必须只能使用SETUP命令来给媒体流设置传输参数。
限制只有SETUP能设置传输参数有利于防火墙设计。
示例：
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
"text/parameters"段只是参数类型的一个例子。对此方法有意的进行了松散的定义，对于答复和响应的内容将在更深一层的实验中给出定义。
10.10 REDIRECT
REDIRECT请求告知客户端连接到另一个服务器位置。它包含首部域Location，该域指出了客户端应该发出请求的URL。它可能包含参数Range，在重定向生效时，该域指明了媒体流的范围。如果客户端希望继续发送或接收其URI指定的媒体，它必须发出一个TEARDOWN请求来关闭当前会话，并向委派的主机发送SETUP以建立新的会话。
本例中，在给定的播放时间将URI请求重定向到新的服务器：
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
10.11 RECORD
此方法根据表示描述开始记录媒体数据。时间戳（timestamp）表现了起始和结束时间（UTC）。如果没有给定时间范围，就使用表示描述中提供的开始和结束时间。如果会话已经开启，立即开始记录。由服务器来决定是否存储记录的数据到请求URI下或者其它URI下。如果服务器没有使用请求URI，那么响应代码应该是201（创建），并且包含一个实体，该实体描述了请求的状态，并通过Location首部域指向新资源。
允许记录现场表示（live presentations）的媒体服务器必须支持时钟范围格式（the clock range format），smpte格式对此无用。
在本示例中，媒体服务器被邀请到指定的会议
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
10.12 Embedded (Interleaved) Binary Data
可能某些防火墙设计和环境会强制服务器交叉RTSP方法和媒体流数据。这种交叉增加了客户端和服务器操作的复杂性，带来了额外的开销，因此通常情况下应该避免；除非必须交叉。只有RTSP在TCP上运载时，交叉的二进制数据才能使用。
媒体流数据，如RTP包，被封装成下列形式：ASCII的美元符（十进制数24），一个字节的通道标志符（channel identifier），被封装的二进制数据的长度，以网络字节顺序编码的2字节整数。紧接着的是上层的协议头。每个＄块都正确地包含了一个上层协议数据单元，比如一个RTP包。
通道标志符使用交叉参数定义在传输头。
当使用实时传输协议传输时，RTP和RTCP消息也会在TCP连接上相互交叉。默认情况下，RTCP包会在第一个可用的通道上发送，高于RTP通道。而客户端可能在另一个通道显式地请求RTCP包。在传输头的交叉参数中指定两个通道可解决此问题。
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes RTCP packet}
方法表征（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 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range首部域缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。
利用PAUSE请求可忽视所有排队的PLAY请求，但必须维护媒体流中的暂停点。不带Range首部域的后继PLAY请求从暂停点重启播放。
比如，如果服务器有两个挂起的播放请求，播放范围（range）分别是10到15和20到29，这时收到一个暂停请求，暂停点是NPT21，那么它将会开始播放第二个范围，并且在NPT21处停止。如果服务器正在服务第一个请求播放到NPT13位置，收到暂停请求，暂停点NPT12，那么它将立即停止。如果请求在NPT16暂停，那么服务器在完成第一个播放请求后停止，放弃了第二个播放请求。
再如，服务器收到播放请求，播放范围从10到15和13到20（即之间有重叠），PAUSE暂停点是NPT14，则当服务器播放第一段范围时，PAUSE请求将生效，而第二个PLAY请求会被忽略重叠部分，就好像服务器在开始播放第二段前收到PAUSE请求。不管PAUSE请求何时到达，它总是设置NPT到14。//？
如果服务器已经在Range首部域指定的时间外发送了数据，后继的PLAY仍会在暂停点及时重启，因为它认为客户端会丢弃在暂停点后收到的数据。这就确保了连续、无隙的暂停/播放循环。
10.7 TEARDOWN
TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。如果该URI是对此表示的表示URI，那么任何与此会话相关的任何RTSP会话标志符将不再有效。除非所有传输参数由会话描述符定义，否则SETUP请求必须在会话能被再次播放之前发出。
示例：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
10.8 GET PARAMETER
GET PARAMETER请求检索URI指定的表示或媒体流的参数值。答复和响应的内容留给了实现。不带实体主体的GET PARAMETER可用来测试客户端或服务器是否存活（"Ping"）。
示例：
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
"text/parameters"段只是参数类型的一个例子。对此方法有意的进行了松散的定义，对于答复和响应的内容将在更深一层的实验中给出定义。
10.9 SET PARAMETER
此方法给URI指定的表示或媒体流设置参数值。
帮助客户端检查某个特殊的请求为何失败的请求（晕~）应该只附带一个参数。当请求附带多个参数时，服务器只有在这些参数全都设置正确时才作出响应。服务器必须允许某个参数被重复设置成相同的值，但可能不允许改变参数值。
注意：必须只能使用SETUP命令来给媒体流设置传输参数。
限制只有SETUP能设置传输参数有利于防火墙设计。
示例：
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
"text/parameters"段只是参数类型的一个例子。对此方法有意的进行了松散的定义，对于答复和响应的内容将在更深一层的实验中给出定义。
10.10 REDIRECT
REDIRECT请求告知客户端连接到另一个服务器位置。它包含首部域Location，该域指出了客户端应该发出请求的URL。它可能包含参数Range，在重定向生效时，该域指明了媒体流的范围。如果客户端希望继续发送或接收其URI指定的媒体，它必须发出一个TEARDOWN请求来关闭当前会话，并向委派的主机发送SETUP以建立新的会话。
本例中，在给定的播放时间将URI请求重定向到新的服务器：
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
10.11 RECORD
此方法根据表示描述开始记录媒体数据。时间戳（timestamp）表现了起始和结束时间（UTC）。如果没有给定时间范围，就使用表示描述中提供的开始和结束时间。如果会话已经开启，立即开始记录。由服务器来决定是否存储记录的数据到请求URI下或者其它URI下。如果服务器没有使用请求URI，那么响应代码应该是201（创建），并且包含一个实体，该实体描述了请求的状态，并通过Location首部域指向新资源。
允许记录现场表示（live presentations）的媒体服务器必须支持时钟范围格式（the clock range format），smpte格式对此无用。
在本示例中，媒体服务器被邀请到指定的会议
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
10.12 Embedded (Interleaved) Binary Data
可能某些防火墙设计和环境会强制服务器交叉RTSP方法和媒体流数据。这种交叉增加了客户端和服务器操作的复杂性，带来了额外的开销，因此通常情况下应该避免；除非必须交叉。只有RTSP在TCP上运载时，交叉的二进制数据才能使用。
媒体流数据，如RTP包，被封装成下列形式：ASCII的美元符（十进制数24），一个字节的通道标志符（channel identifier），被封装的二进制数据的长度，以网络字节顺序编码的2字节整数。紧接着的是上层的协议头。每个＄块都正确地包含了一个上层协议数据单元，比如一个RTP包。
通道标志符使用交叉参数定义在传输头。
当使用实时传输协议传输时，RTP和RTCP消息也会在TCP连接上相互交叉。默认情况下，RTCP包会在第一个可用的通道上发送，高于RTP通道。而客户端可能在另一个通道显式地请求RTCP包。在传输头的交叉参数中指定两个通道可解决此问题。
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes RTCP packet}
文章评论
共有 0 位网友发表了评论 此处只显示部分留言 点击查看完整评论页面