RTSP客户端和服务器端的状态机描述了从RTSP会话初始化到会话终止的过程中协议的行为。
根据每个对象的要素来定义其状态。可以通过媒体流URL和RTSP会话标志符来唯一地标识每个对象。聚合URL(aggregate URLs)用以标识由多个媒体流组成的表示,任何使用这种聚合URL的请求/回复都将会影响表示中所有媒体流的状态。例如,如果表示/movie包含两个 媒体流/movie/audio和/movie/video,使用下面的命令
PLAY rtsp://foo.com/movie RTSP/1.0
CSeq: 559
Session: 12345678
/movie/audio和/movie/video的状态将会受到影响。
OPTIONS, ANNOUNCE, DESCRIBE, GET PARAMETER, SET PARAMETER等请求不会影响客户端或服务器端的状态机,因此它们没有在状态表中列出。
A.1 客户端状态机
客户端呈现以下状态:
初始态(Init):SETUP请求已经发出,等待回复
就绪态(Ready):收到SETUP回复,或在播放态时收到PAUSE回复
播放态(Playing):收到PLAY回复
记录态(Recording):收到RECORD回复
通常来说,客户端在收到对请求的回复后立即改变状态。但要注意某些请求会在将来某个时间或某个位置才生效,比如PAUSE请求,到时状态也要作相应改变。 如果对象不需要显式的SETUP请求,比如它在一个可用组播群中,那么其起始态就为就绪态。在这种情况下只有两种状态:就绪态和播放态。当到达被请求范围 (the requested range)的结尾时,客户端也会将状态从播放态/记录态迁移到就绪态。
"下一状态"列表示在收到一个成功响应(2xx)后的状态。如果请求产生状态码3xx,状态将变成初始态,而要是4xx,状态将不作改变。在当前状态不能 发出的消息没有在状态机中列出,上文提到的那些不影响当前状态的消息也没有列出。从服务器端收到一个REDIRECT方法等同于从服务器接收到一个3xx 的重定向状态码。
状态 | 发出的消息 | 响应后下一状态 |
初始态 | SETUP | 就绪态 |
TEARDOWN | 初始态 | |
就绪态 | PLAY | 播放态 |
RECORD | 记录态 | |
TEARDOWN | 初始态 | |
SETUP | 就绪态 | |
播放态 | PAUSE | 就绪态 |
TEARDOWN | 初始态 | |
PLAY | 播放态 | |
SETUP | 播放态(改变传输) | |
记录态 | PAUSE | 就绪态 |
TEARDOWN | 初始态 | |
RECORD | 记录态 | |
SETUP | 记录态(改变传输) |
A.2 服务器端状态机
服务器端呈现以下状态:
初始态(Init):最初的状态,未收到有效的SETUP请求
就绪态(Ready):成功接收上一个SETUP请求,回复发出,或者从播放态迁移而来,成功接收上一个PAUSE请求,向客户端发回回复
播放态(Playing):成功接收上一个PLAY请求,对其回复发出。数据正在发送
记录态(Recording):服务器正在记录媒体数据
通常来说,服务器端在收到对请求后立即改变状态。在单播模式下,如果服务器在一个定义的时间间隔内(默认是1分钟)没有从客户端收到"满意的 (wellness)"的信息,那么它将从播放态或记录态回复到初始态,并且关闭(tear down)RTSP会话。服务器在会话响应头(Session response header)中声明另一个超时值(timeout value)。
如果处在就绪态的服务器在超过1分钟的时间间隔内没有收到一个RTSP请求,它将回复到初始态。注意某些请求(比如PAUSE)可能会在将来某个时间或某 个位置生效,服务器状态会在恰当的时间改变(而不是在收到请求后立即改变)。到达客户端请求范围的结尾时,服务器状态从播放态或记录态回复到就绪态。
除非REDIRECT消息有Range首部域指出重定向生效的时间,否则它在发出后立即生效。在有Range的情况下,服务器状态也会在恰当的时间改变。
如果对象不需要显式的SETUP请求,那它将以就绪态开始,并且只有就绪和播放两个状态。
"下一状态"列表示发出一个成功响应(2xx)后的状态。如果某个请求引起状态码3xx,则状态变成初始态。4xx的状态码不会引起状态改变。
状态 | 收到的消息 | 下一状态 |
初始态 | SETUP | 就绪态 |
TEARDOWN | 初始态 | |
就绪态 | PLAY | 播放态 |
SETUP | 就绪态 | |
TEARDOWN | 初始态 | |
RECORD | 记录态 | |
播放态 | PLAY | 播放态 |
PAUSE | 就绪态 | |
TEARDOWN | 初始态 | |
SETUP | 播放态 | |
记录态 | RECORD | 记录态 |
PAUSE | 就绪态 | |
TEARDOWN | 初始态 | |
SETUP | 记录态 |
附:RTSP状态
RTSP用以控制媒体流(stream),该媒体流可能通过一个单独的协议,与控制通道(control channel)无关的方式被发送的。比如,RTSP控制可能出现在TCP连接,而数据却通过UDP传送。因此,媒体服务器即使没有收到RTSP请求,数 据传递也会继续。同样地,在单个媒体流的生命周期里,它可能顺序地被不同TCP连接发出的RTSP请求所控制。所以服务器需要维护“会话状态 (session state)”,能够将RTSP请求和某个媒体流关联起来。状态迁移如上文所述。
RTSP中许多方法对状态无影响。但是,下面几个方法在定义服务器上媒体流资源的分配和使用时,有重要作用:SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN。
影响RTSP状态的方法使用会话首部域(Session header field)来标识状态正在被操作的会话。服务器在响应SETUP请求时,产生会话标志符。