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播放态 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。

SETUP：使服务器为媒体流和启动一个RTSP会话分配资源。

PLAY和RECORD：开始在媒体流（通过SETUP分配）上传送数据

PAUSE：暂时中断某个媒体流，但没有释放服务器资源

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

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

http://blog.csdn.net/eustoma/article/details/6704128