rtsp协议流媒体服务器,流媒体协议RTSP

协议介绍

现在流行的流媒体协议有两种:RTSP和MMS。RTSP协议是IETF制定的流媒体控制协议公开标准。MMS是微软私有的协议,微软没有公开任何技术细节,所以网络上所能获取的相关资料都是爱好者通过抓包分析汇总的,并没有官方授权或保证。

5.1

流媒体控制协议RTSP

5.1.1

简述

RTSP是一个应用层协议,用来控制实时传输的多媒体数据。RTSP一般来说本身并不用来传输媒体流,但是在交织模式下,媒体流和控制流是混合在一起的。

RTSP独立于传输层协议,可以使用TCP,也可以使用UDP。

RTSP是从HTTP发展而来的,语法结构、操作和很多概念都是沿自HTTP/1.1。但是跟HTTP是无状态协议不同,RTSP需要维护协议状态。

RTSP消息包是基于文本格式的。

5.1.2

状态机

一般情况下,RTSP媒体流控制与媒体流传输是相互独立的,那么在媒体流传输开始后,即使流媒体服务器没收到RTSP信令,媒体流的传输仍然会继续。所以会存在这样一种情况,在整个媒体流过程中,RTSP媒体流控制信令会分别通过多个顺序的TCP连接来传输。因此,流媒体服务器需要保持会话状态来把RTSP信令关联到相应的媒体流控制上。

客户端的状态机:

Init:已经发送SETUP信令,等待服务器回复;

Ready:收到SETUP信令的回复或者在Playing状态收到PAUSE信令;

Playing:收到PLAY信令的回复;

Recording:收到RECORD信令的回复;

服务器的状态机:

Init:初始化状态,没收到任何SETUP信令;

Ready:收到SETUP信令,并回复或者在Playing状态收到PAUSE信令并回复;

Playing:收到PLAY信令,并回复,媒体流数据已经发送;

Recording:在保存媒体流数据;

客户端在接收到请求成功的回复时改变状态,而服务器在收到请求并成功处理的时候改变状态。

5.1.2

参数

5.1.2.1

会话索引

会话索引是每个媒体流控制的全局标志,服务器收到SETUP信令并成功处理就会生成一个会话索引并通过回复发送到客户端。后续对该媒体流的控制请求都需要带上会话索引。

5.1.2.2

NPT

NPT显示媒体流以播放时间为度量基准相对开始的播放位置。NPT通常用于指示播放、暂停或者录播的开始/结束时间。

5.1.3

回复

RTSP回复状态码和原因说明如下:

1xx:通知回复—表示请求已经收到,而且正在处理中;

2xx:成功—表示请求已经正常处理;

3xx:重定向—表示请求需要发送到另外的服务器进行处理;

4xx:客户端错误—表示请求因为格式不对而处理出错;

5xx:服务器错误—表示请求因为服务器问题而处理出错;

5.1.4

方法定义

5.1.4.1

DESCRIBE

DESCRIBE用来获取服务器上媒体文件的描述(如音/视频编解码格式,媒体流格式等)。

5.1.4.2

SETUP

SETUP指定媒体流的传送方式。对于正在传输的媒体流,SETUP可以改变传输参数。

5.1.4.3

PLAY

PLAY请求服务器开始传输由SETUP指定传送方式的媒体流。PLAY可以指定需要传输的流文件的时间段,如指定开始时间和结束时间。如果客户端已经处于PLAYING状态,发送PLAY不会引起状态变化,所以也可以用来作为客户端对服务器的心跳检测。

5.1.4.4

PAUSE

PAUSE暂停媒体流传输。PAUSE可以指定时间点,当媒体流传输到该时间点的时候,就会实现暂停。如果该时间点在流传输时间前面,那么会返回“457

Invalid Range”错误。如果没有指定时间点,正在传输的媒体流会立刻停止。

5.1.4.5

TEARDOWN

TEARDOWN停止相应的媒体流传输,释放相关的会话资源。

5.1.4.6

GET_PARAMETER

GET_PARAMETER是用获取相关流的参数。回复里面的内容可以自定义。GET_PARAMETER请求里面如果没有消息体,通常是用来做客户端和服务器之间的连接心跳检测的。

5.1.4.7

RECORD

RECORD是用来录像的,需要指定开始时间和结束时间,如果没有就从会话开始时间开始录像。需要注意的是,如果要对某个会议进行录像,在调用RTSP的RECORD功能前,必须已经加入这个会议,RTSP协议并不能实现加入会议的功能,需要用其它(如H.323)协议完成。

5.1.4.8 Embedded

(Interleaved) Binary Data

由于RTSP和媒体流传输是分离的,在碰到服务器和客户端之间存在NAT/FW的情况下,媒体流的传输就会被NAT/FW挡住而导致出现收不到媒体流数据的问题。为了解决这个问题,RTSP提供了媒体流控制和媒体流数据交织的方式。这种方式只能应用于TCP连接。

当媒体流数据使用RTP传输时,RTCP信令也需要交织在RTSP数据包里面。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
协议用于C/S模型,是一个基于文本的协议,用于在客户端和服务器端建立和协商实时流会话。   实时流协议RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频,的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP上发送机制提供方法。   实时流协议RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外,可使用无连接传输协议,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。   协议支持的操作如下:   (1)从媒体服务器上检索媒体:用户可通过HTTP或其它方法提交一个演示描述。如演示是组播,演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户,用户为了安全应提供目的地址。   (2)媒体服务器邀请进入会议:媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录其中一部分,或全部。这种模式在分布式教育应用上很有用,会议中几方可轮流按远程控制按钮。   (3)将媒体加到现成讲座中:如服务器告诉用户可获得附加媒体内容,对现场讲座显得尤其有用。如HTTP/1.1中类似,RTSP请求可由代理、通道与缓存处理

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值