协议介绍
现在流行的流媒体协议有两种: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数据包里面。