RTSP协议--图文解释

一、什么是RTSP

RTSP（Real Time Streaming Protocol）实时流传输协议。是 TCP/IP 协议体系中的一个应用层协议，RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输如下图1所示。

                                                                       

                                                                             图1、TCP/IP协议体系

二、RTSP、RTP、RTCP之间关系

RTSP发起/终结流媒体、RTP传输流媒体数据、RTCP对RTP进行控制、同步。如图2所示

                                              

                                                                                  图2、RTSP、RTP、RTCP关系

三、RTSP交互过程

RTSP分为服务器与客户端，RTSP协议定义了服务器-客户端之间的接口，主要有OPTIONS，DESCRIBE，SETUP，PLAY，TEARDOWN，RECOED，ANNOUNCE。RTSP并不包括具体数据的传输，该功能一般由RTP与RTCP协议来实现，并可以通过TCP或UDP两种底层传输方式进行。

                            

                                                                                  图3、RTSP交互过程

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

1. 第一步：查询服务器端可用方法

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

1.S->C:OPTION response    //S回应信息的public头字段中包括提供的所有可用方法

2. 第二步：得到媒体描述信息

2.C->S:DESCRIBE request      //要求得到S提供的媒体描述信息

2.S->C:DESCRIBE response    //S回应媒体描述信息，一般是sdp信息

3. 第三步：建立RTSP会话

3.C->S:SETUPrequest            //通过Transport头字段列出可接受的传输选项，请求S建立会话

3.S->C:SETUPresponse          //S建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;

4. 第四步：请求开始传送数据

4.C->S:PLAY request        //C请求S开始发送数据

4.S->C:PLAYresponse            //S回应该请求的信息

5. 第五步： 数据传送播放中

S->C:发送流媒体数据    // 通过RTP协议传送数据

6. 第六步：关闭会话，退出

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

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

其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。

由图3可知，RTSP协议主要分为三个部分：RTSP会话（RTSP session）、RTP协议、RTCP协议。RTSP session部分本文会详细叙述，对于RTP协议与RTSP协议会以新的文章方式呈现。

四、RTSP会话（RTSP session）

4.1、OPTIONS：用于得到服务器提供的可用方法

客户端请求：

C->S: OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 1 

服务器返回：

S->C:RTSP/1.0 200 OK

CSeq: 1        //每个回应消息的cseq数值和请求消息的cseq相对应

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

4.2、DESCRIBE：发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。

客户端请求：

C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl,application/mheg)

服务器返回：

S->C: RTSP/1.0 200 OK

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Content-Type: application/sdp  //表示回应为SDP信息

Content-Length: 376

//这里为一个空行

//以下为具体的SDP信息

v=0 

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 3456 RTP/AVP 0

m=video 2232 RTP/AVP 31

m=whiteboard 32416 UDP WB

a=orient:portrait

4.3、SETUP：用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。equest中的Transport头字段指定了客户端可接受的数据传输参数；Response中的Transport 头字段包含了由服务器选出的传输参数。

客户端请求：

C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

服务器返回：

S->C: RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344 //产生一个SessionID

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

4.4、PLAY：PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。

客户端请求：

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 835

Session: 12345678

Range: npt=10-15

 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 836

Session: 12345678

Range: npt=20-25

 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 837

Session: 12345678

Range: npt=30-

4.5、PAUSE：PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。比如，指定暂停音频，播放将会无声。如果请求URL指定了一组流，那么在该组中的所有流的传输将被暂停

客户端请求：

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

Session: 12345678

服务端返回：

S->C: RTSP/1.0 200 OK

CSeq: 834

Date: 23 Jan 1997 15:35:06 GMT

4.6、TEARDOWN：EARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。

客户端请求：

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 892

Session: 12345678

服务端返回：

S->C: RTSP/1.0 200 OK

CSeq: 892

五、RTSP重要头字段参数

1. Accept:

用于指定客户端可以接受的媒体描述信息类型。比如:

Accept: application/rtsl, application/sdp;level=2

2. Bandwidth:

用于描述客户端可用的带宽值。

3.CSeq：

指定了RTSP请求回应对的序列号，在每个请求或回应中都必须包括这个头字段。对每个包含一个给定序列号的请求消息，都会有一个相同序列号的回应消息。

4.Rang：

用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元。

5. Session:

 Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的，客户端一当得到Session ID后，在以后的对Session 的操作请求消息中都要包含Session ID.

6. Transport:

 Transport头字段包含客户端可以接受的转输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如:

Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",

RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"