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请求时,产生会话标志符。

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
海康威视是一家专业从事视频监控产品研发和生产的知名企业,其产品使用了一种被称为RTSP(Real Time Streaming Protocol)的协议RTSP协议是一种用于实时流媒体传输的应用层协议RTSP协议的主要作用是实现客户端和服务器之间的媒体数据传输和控制。它允许客户端通过类似于HTTP的请求和响应方式来发送控制命令和获取媒体数据。与HTTP协议相比,RTSP协议更加轻量级,适用于实时性要求高的视频监控场景。 RTSP协议的工作流程如下: 1. 客户端与服务器建立TCP连接。 2. 客户端发送描述请求,获取服务器支持的媒体格式、编码方式等信息。 3. 服务器响应描述请求,提供媒体相关信息。 4. 客户端发送SETUP请求,请求建立传输通道,并指定传输媒体的相关参数。 5. 服务器响应SETUP请求,告知是否成功建立传输通道。 6. 客户端发送播放请求,开始接收媒体数据。 7. 服务器响应播放请求,开始传输媒体数据。 RTSP协议支持多媒体格式和编码方式,比如H.264、MPEG-4和JPEG等。同时,它也支持实时音频和视频的传输,可以满足不同场景的需求。 在海康威视的产品中,RTSP协议可以通过IP摄像机等设备的访问地址获取实时视频流。用户可以通过支持RTSP协议的客户端软件,如视频监控软件或流媒体播放器,来实时观看和控制监控画面。 总结来说,海康威视的RTSP协议是一种用于实时流媒体传输的协议,通过它可以实现客户端与服务器之间的媒体数据传输和控制。它具有轻量级、实时性高等特点,适用于视频监控和流媒体传输等场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值