RTSP协议状态机

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 下一状态 就绪态 初始态 播放态 就绪态 初始态 记录态 播放态 记录态

附：RTSP状态

PAUSE TEARDOWN SETUP RECORD PAUSE TEARDOWN SETUP 就绪态 初始态 播放态 记录态 就绪态 初始态 记录态 RTSP用以控制媒体流（stream），该媒体流可能通过一个单独的协议，与控制通道（control channel）无关的方式被发送的。比如，RTSP控制可能出现在TCP连接，而数据却通过UDP传送。因此，媒体服务器即使没有收到RTSP请求，数 据传递也会继续。同样地，在单个媒体流的生命周期里，它可能顺序地被不同TCP连接发出的RTSP请求所控制。所以服务器需要维护“会话状态 （session state）”，能够将RTSP请求和某个媒体流关联起来。状态迁移如上文所述。

RTSP中许多方法对状态无影响。但是，下面几个方法在定义服务器上媒体流资源的分配和使用时，有重要作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN。 SETUP：使服务器为媒体流和启动一个RTSP会话分配资源。 PLAY和RECORD：开始在媒体流（通过SETUP分配）上传送数据 PAUSE：暂时中断某个媒体流，但没有释放服务器资源

TEARDOWN：释放与媒体流相关的资源。RTSP会话终止，在服务器退出。

影响RTSP状态的方法使用会话首部域（Session header field）来标识状态正在被操作的会话。服务器在响应SETUP请求时，产生会话标志符。