RTSP协议（一）

本文内容为转载并整理的。

协议标准：RFC2326.

1.   实时流协议RTSP(Real Time Streaming Protocol):

RTSP协 议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继 续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。

2.   RTSP协议简介

要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和 媒体服务器(mediaserver)。媒体服务器与媒体播放器的关系是服务器与客户的关系。

媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。

图1. RTSP与RTP和RTCP的关系

RTSP仅仅是使媒体播放器能控制多媒体流的传送。

3.   RTSP的报文结构

分两类：

请求报文：指从客户向服务器发送请求报文；

响应报文：指从服务器到客户的回答。

RTSP报文由三部分组成：开始行、首部行和实体主体。在请求报文中，开始行就是请求行。

RTSP请 求报文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER，

表1 RTSP请求报文的常用方法及 作用

方法

作用

OPTIONS

获得服务 器提供的可用方法

DESCRIBE

得到会话 描述信息

SETUP

客户端提 醒服务器建立会话，并确定传输模式

TEARDOWN

客户端发 起关闭请求

PLAY

客户端发 送播放请求

响应报文的开始行是状态行，RTSP响应报文的结构如图3所示

4.   RTSP协议的交互过程

点播一个视频文件，交换流程为：中文图右侧;

 

C表 示RTSP客户端，S表示RTSP服务端

① C->S: OPTION request           //询问S有 哪些方法可用

S->C: OPTIONresponse        //S回 应信息中包括提供的所有可用方法

② C->S: DESCRIBE request     //要求得到S提供 的媒体初始化描述信息

S->C: DESCRIBEresponse      //S回 应媒体初始化描述信息，主要是sdp

③ C->S: SETUP request        //设置会话属性，以及传输模式，提醒S建 立会话

S->C: SETUPresponse         //S建 立会话，返回会话标识符及会话相关信息

④ C->S: PLAY request         //C请求播放

S->C: PLAYresponse          //S回 应请求信息

S->C: 发 送流媒体数据

⑤ C->S: TEARDOWN request    //C请 求关闭会话

S->C: TEARDOWN response    //S回应请求

上述的过程是标准的RTSP流程，其中，3.4步是必须的。

5.   RTSP协议的实现

RTSP在流媒体传输过程中，仅仅为双方建立连接，并不具备任何智能，也就不能很好地应付难以预料的网络状态。因此，必须在它原有功能的基础上，进行改进

1、初始化

在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。初始化的目的，是为了获取客 户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使客户端获得最佳观看效果。

接到这个请求之后，服务器将根据自身情况进行如下测试：

● 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。

● 采用UDP协议，向客户端下发测试数据包。

测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。

需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。

2、TCP传输

如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的 网络状况良好， 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。

当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输。这种传 输方式也存在一定的问题：

● 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。

● 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。

● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。

因此，一般情况下，都默认使用RTP over TCP的方式发送数据。

3、UDP传输

如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。

目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。

收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据 包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件;否则，认为测试不成功，由于网络状况的限 制，仅对客户端下发低码率的电影文件。

在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克出现的主要原因是：

● 不可靠连接造成的网络丢包，为客户端被动丢包。

● 高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包。

但从整体而言，UDP传输消耗的带宽，要比TCP小许多。在一般的视频点播要求下，使用基于UDP的传输线路，是完全可以 满足要求的。

4、传输反馈

在传输过程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，还存在一个回传端口RTCP。

在服务器收到客户端的RTCP回传信息后，需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之下，就认为目 前传送的视频文件可令客户端获得最大程度的音视频享受;否则，考虑改为传输更低码率的视频文件或放弃这次RTSP会话，以避免更大范围的拥塞。

5、实际效果

采取如上方法设计的系统，可以满足视频点播的基本要求，避免了服务器视频文件下发的盲目性，同时使客户端应用效果最好。

下面是live555的具体实现过程^[4]：

（1）客户端发起RTSP OPTION请求，目的是得到服务器提供什么方法。RTSP提供的方法一般包括OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、SCALE、GET_PARAMETER。

（2）服务器对RTSP OPTION回应，服务器实现什么方法就回应哪些方法。在此系统中，我们只对DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE方法做了实现。

（3）客户端发起RTSP DESCRIBE请求，服务器收到的信息主要有媒体的名字，解码类型，视频分辨率等描述，目的是为了从服务器那里得到会话描述信息（SDP）。

（4）服务器对RTSP DESCRIBE响应，发送必要的媒体参数，在传输H.264文件时，主要包括SPS/PPS、媒体名、传输协议等信息。

（5）客户端发起RTSP SETUP请求，目的是请求会话建立并准备传输。请求信息主要包括传输协议和客户端端口号。

（6）服务器对RTSP SETUP响应，发出相应服务器端的端口号和会话标识符。

（7）客户端发出了RTSP PLAY的请求，目的是请求播放视频流。

（8）服务器对RTSP PLAY响应，响应的消息包括会话标识符，RTP包的序列号，时间戳。此时服务器对H264视频流封装打包进行传输。

（9）客户端发出RTSP TEARDOWN请求，目的是关闭连接，终止传输。

（10）服务器关闭连接，停止传输。

RTSP点播消息流程实例（客户端：VLC， RTSP服务器：LIVE555 Media Server) 
1)C(Client)-> M(Media Server) 
OPTIONS rtsp://192.168.1.109/1.mpg RTSP/1.0 
CSeq: 1 
user-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

1)M -> C 
RTSP/1.0 200 OK 
CSeq: 1 
Date: wed, Feb 20 2008 07:13:24 GMT 
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 

2)C -> M 
DESCRIBE rtsp://192.168.1.109/1.mpg RTSP/1.0 
CSeq: 2 
Accept: application/sdp 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

2)M -> C 
RTSP/1.0 200 OK 
CSeq: 2 
Date: wed, Feb 20 2008 07:13:25 GMT 
Content-Base: rtsp://192.168.1.109/1.mpg/ 
Content-type: application/sdp 
Content-length: 447 
v=0 
o =- 2284269756 1 IN IP4 192.168.1.109 
s=MPEG-1 or 2 program Stream, streamed by the LIVE555 Media Server 
i=1.mpg 
t=0 0 
a=tool:LIVE555 Streaming Media v2008.02.08 
a=type:broadcast 
a=control:* 
a=range:npt=0-66.181 
a=x-qt-text-nam:MPEG-1 or Program Stream, streamed by the LIVE555 Media Server 
a=x-qt-text-inf:1.mpg 
m=video 0 RTP/AVP 32 
c=IN IP4 0.0.0.0 
a=control:track1 
m=audio 0 RTP/AVP 14 
c=IN IP4 0.0.0.0 
a=control:track2 

3)C -> M 
SETUP rtsp://192.168.1.109/1.mpg/track1 RTSP/1.0 
CSeq: 3 
Transport: RTP/AVP; unicast;client_port=1112-1113 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

3)M -> C 
RTSP/1.0 200 OK 
CSeq: 3 
Date: wed, Feb 20 2008 07:13:25 GMT 
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1112-1113;server_port=6970-6971 
Session: 3 

4)C -> M 
SETUP rtsp://192.168.1.109/1.mpg/track2 RTSP/1.0 
CSeq: 4 
Transport: RTP/AVP; unicast;client_port=1114-1115 
Session: 3 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

4)M -> C 
RTSP/1.0 200 OK 
CSeq: 4 
Date: wed, Feb 20 2008 07:13:25 GMT 
Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1114-1115;server_port=6972-6973 
Session: 3 

5)C -> M 
PLAY rtsp://192.168.1.109/1.mpg/ RTSP/1.0 
CSeq: 5 
Session: 3 
Range: npt=0.000- 
User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 

5)M -> C 
RTSP/1.0 200 OK 
CSeq: 5 
Range: npt=0.000- 
Session: 3 
RTP-Info: url=rtsp://192.168.1.109/1.mpg/track1;seq=9200;rtptime=214793785,url=rtsp://192.168.1.109/1.mpg/track2;seq=12770;rtptime=31721 

(开始传输流媒体...)