RTSP协议消息格式及SDP协议解析

1 RTSP消息格式:

RTSP的消息有两大类 --- 请求消息(request), 回应消息(response)。
请求消息：
方法 URI RTSP版本 CR LF 
消息头 CR LF CR LF 
消息体 CR LF 

如下：

DESCRIBE rtsp://192.168.1.211 RTSP/1.0

CSeq: 1

Accept: application/sdp

User-Agent: magnus-fc

 

其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如:rtsp://192.168.20.136。RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF

回应消息：
RTSP版本 状态码 解释 CR LF 
消息头 CR LF CR LF 
消息体 CR LF 

如下：

RTSP/1.0 200 OK

CSeq: 1

Server: GrandStream Rtsp Server V100R001

Content-Type: application/sdp

Content-length: 256

Content-Base: rtsp://192.168.1.211/0

 

v=0

o=StreamingServer 3331435948 1116907222000 IN IP4 192.168.1.211

s=h264.mp4

c=IN IP4 0.0.0.0

t=0 0

a=control:*

m=video 0 RTP/AVP 96

a=control:trackID=0

a=rtpmap:96 H264/90000

m=audio 0 RTP/AVP 97

a=control:trackID=1

a=rtpmap:97 G726-16/8000

 

其中RTSP版本一般都是RTSP/1.0, 状态码是一个数值, 200表示成功, 解释是与状态码对应的文本解释.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

简单的rtsp交互过程: 

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

1. C->S:OPTION request //询问S有哪些方法可用
1. S->C:OPTION response //S回应信息中包括提供的所有可用方法

2. C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息
2. S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp

3. C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话
3. S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息

4. C->S:PLAY request //C请求播放
4. S->C:PLAY response //S回应该请求的信息

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

5. C->S:TEARDOWN request //C请求关闭会话
5. S->C:TEARDOWN response //S回应该请求

上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。 其 中第3和4步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信 息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。第五步，可以根据系统需求的设计来决定是否需要。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2 rtsp中常用方法: 

2.1. OPTION

目的是得到服务器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每个消息都有序号来标记，第一个包通常是option请求消息
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器的回应信息包括提供的一些方法,例如:
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1
Cseq: 1 //每个回应消息的cseq数值和请求消息的cseq相对应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,GET_PARAMETER //服务器提供的可用的方法

2.2 DESCRIBE 

C向S发起DESCRIBE请求,为了得到会话描述信息(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 2
token: 
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) 

服务器回应一些对此会话的描述信息(sdp):
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 2 
x-prev-url: rtsp://192.168.20.136:5000 
x-next-url: rtsp://192.168.20.136:5000 
x-Accept-Retransmit: our-retransmit 
x-Accept-Dynamic-Rate: 1 
Cache-Control: must-revalidate 
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT 
Date: Fri, 10 Nov 2006 12:34:38 GMT 
Expires: Fri, 10 Nov 2006 12:34:38 GMT 
Content-Base: rtsp://192.168.20.136:5000/xxx666/ 
Content-Length: 344 
Content-Type: application/sdp 

v=0 //以下都是sdp信息  
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136 
s=/xxx666 
u=http:/// 
e=admin@ 
c=IN IP4 0.0.0.0 
t=0 0 
a=isma-compliance:1,1.0,1 

a=range:npt=0- 
m=video 0 RTP/AVP 96 //m表示媒体描述，下面是对会话中视频通道的媒体描述
a=rtpmap:96 MP4V-ES/90000 
a=fmtp:96 profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 a=control:trackID=0 //trackID＝0表示视频流用的是通道0

3.3 .SETUP 

客户端提醒服务器建立会话,并确定传输模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0 
CSeq: 3 
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
//uri中 带有trackID＝0，表示对该通道进行设置。Transport参数设置了传输模式，包的结构。接下来的数据包头部第二个字节位置就是 interleaved，它的值是每个通道都不同的，trackID＝0的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接 受端根据interleaved的值来区别是哪种数据包。

服务器回应信息:
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 3 
Session: 6310936469860791894 //服务器回应的会话标识符
Cache-Control: no-cache 
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567

4.4.PLAY 

客户端发送播放请求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 
CSeq: 4 
Session: 6310936469860791894 
Range: npt=0.000- //设置播放时间的范围
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应信息:
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 4 
Session: 6310936469860791894 
Range: npt=0.000000- 
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309 
//seq和rtptime都是rtp包中的信息

5.5 TEARDOWN 

客户端发起关闭请求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 
CSeq: 5 
Session: 6310936469860791894 
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) 

服务器回应:
RTSP/1.0 200 OK 
Server: UServer 0.9.7_rc1 
Cseq: 5 
Session: 6310936469860791894 
Connection: Close 

以上方法都是交互过程中最为常用的, 其它还有一些重要的方法如get/set_parameter,pause,redirect等等 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

3 SDP协议介绍

sdp的格式：

v=<version>

o=<username> <session id> <version> <network type> <address type> <address>

s=<session name>

i=<session description>

u=<URI>

e=<email address>
p=<phone number>
c=<network type> <address type> <connection address>

b=<modifier>:<bandwidth-value>

t=<start time> <stop time>

r=<repeat interval> <active duration> <list of offsets from start-time>

z=<adjustment time> <offset> <adjustment time> <offset> ....

k=<method>
k=<method>:<encryption key>

a=<attribute>
a=<attribute>:<value>

m=<media> <port> <transport> <fmt list>

v = （协议版本）

o = （所有者/创建者和会话标识符）

s = （会话名称）

i = * （会话信息）

u = * （URI 描述）

e = * （Email 地址）

p = * （电话号码）

c = * （连接信息）

b = * （带宽信息）

z = * （时间区域调整）

k = * （加密密钥）

a = * （0 个或多个会话属性行）

 

时间描述：

t = （会话活动时间）

r = * （0或多次重复次数）

 

媒体描述：

m = （媒体名称和传输地址）

i = * （媒体标题）

c = * （连接信息 — 如果包含在会话层则该字段可选）

b = * （带宽信息）

k = * （加密密钥）

a = * （0 个或多个媒体属性行）

SDP一会话描述协议一描述SAP、sIP和RTSR会话的协议,是一种文件描述协议,是由服务器生成的描述媒体文件编码信息以及所在服务器的链接等的信息。在多媒体会话
中sDP传送有关媒体流的信息,使会话描述的参人方加人会话。sDP主要用于Intemet网中,但也可以在其它网络环境下使用。SDP十分通用,可描述其它网络环境中的会话,但主要用
于Intemet中。在Intemet环境下,sDP有两个主要目的:一是表明会话存在,二是传送足够信息给接收方,以便能加人、参加该会话。SDP所传达的信息包括:会话名称和目的,会话
活动时间,组成会话媒体种类,接收这些媒体的控制信息(如地址、端口、格式、带宽和会议管理人员资料等)。

总结：在RTSP交互过程中，只要在客户端发出Describe请求的时候，服务端回应的时候会有SDP消息发出，用SDP来描述会话情况和内容，方便客户端能够加入该会话，

第一部分:RTSP协议

一、RTSP协议概述

RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。

RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。

一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话

二、RTSP协议与HTTP协议区别

1.  RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；

2.  HTTP是无状态的协议，而RTSP为每个会话保持状态；

3.  RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTPF协议中，只有客户端能发送Request请求。

4.  在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。

5.  使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化；

6.  RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中；

三、RTSP重要术语

1.   集合控制(Aggregatecontrol ):

对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。

2.   实体(Entity)：

作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成

3.   容器文件（Containerfile）：

可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。

4.   RTSP会话(RTSP session )：

RTSP交互的全过程。对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

四、RTSP请求消息

1.   消息格式：

方法 URI RTSP版本       CR LF

       消息头 CRLF          CRLF         

       消息体 CR LF

 

其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。

RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF

消息体是可选的，有的Request消息并不带消息体。

五、RTSP回应消息

1.   消息格式：

      RTSP版本状态码解释      CR LF

       消息头 CR LF          CR LF

       消息体 CR LF

其中RTSP版本一般都是RTSP/1.0,状态码是一个数值，用于表示Request消息的执行结果,比如200表示成功,解释是与状态码对应的文本解释.

六、RTSP 重要方法

1.        OPTIONS:

用于得到服务器提供的可用方法；

如:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 1        

服务器的回应信息会在Public字段列出提供的方法。如:

RTSP/1.0 200 OK

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

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

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)

 

服务器回应URI指定媒体的描述信息:

如:

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=[e-mail] (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

 

媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过以下方法来接收媒体描述信息：

a)  通过DESCRIBE方法；

b)  其它一些协议（HTTP，email附件，等）；

c)  通过命令行或标准输入设备

3.        SETUP：

用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。

Request中的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

 

服务器端对SETUPRequest产生一个Session Identifiers。

如:

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.        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-

 

Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。

不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（the pause point）重新开始。

如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。

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

 

PAUSE请求中可能包含一个Range头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pause point）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。如果Range头指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。

6.        TEARDOWN：

TEARDOWN请求终止了给定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"

八、简单的RTSP消息交互过程

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

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

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

1.S->C:OPTIONresponse    //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回应该请求

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。

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

第二部分:SDP协议

一、SDP协议概述

SDP(SessionDescription Protocol )会话描述协议，用于描述多媒体会话，它为会话通知、会话初始和其它形式的多媒体会话初始等操作提供服务。

SDP的设计宗旨是通用性协议，所有它可以应用于很大范围的网络环境和应用程序，但 SDP 不支持会话内容或媒体编码的协商操作。

SDP信息包括：

• 会话名称和目标；
• 会话活动时间；
• 构成会话的媒体；
• 有关接收媒体的信息、地址等。

二、SDP格式

SDP 信息是文本信息，UTF-8 编码采用 ISO 10646 字符设置。SDP 会话描述如下（标注*符号的表示可选字段）：

• v= （协议版本）
• o= （所有者/创建者和会话标识符）
• s= （会话名称）
• i=* （会话信息）
• u=* （URI 描述）
• e=* （Email 地址）
• p=* （电话号码）
• c=* （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
• b=* （带宽信息）

　　一个或更多时间描述（如下所示）：

• z=* （时间区域调整）
• k=* （加密密钥）
• a=* （0个或多个会话属性线路）
• 0个或多个媒体描述（如下所示）

　　时间描述

• t= （会话活动时间）
• r=* （0或多次重复次数）

　　媒体描述

• m= （媒体名称和传输地址）
• i=* （媒体标题）
• c=* （连接信息 — 如果包含在会话层则该字段可选）
• b=* （带宽信息）
• k=* （加密密钥）
• a=* （0个或多个会话属性线路）

三、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=[e-mail] (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 31

m=application 32416 udp wb

a=orient:portrait

 

//字段解释

V=0     ;Version 给定了SDP协议的版本

o=<username><session id> <version> <network type> <address type>

<address>； Origin ,给定了会话的发起者信息

s=<sessionname> ;给定了Session Name

i=<sessiondescription> ; Information 关于Session的一些信息

u=<URI> ; URI

e=<emailaddress>    ;Email

c=<networktype> <address type> <connection address> ;Connect Data包含连接数据

t=<start time><stop time> ;Time

a=<attribute>     ; Attribute

a=<attribute>:<value>

m=<media><port> <transport> <fmt list> ; MediaAnnouncements

 

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

RTSP没有“连接”这个概念，而由RTSP会话（session）代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。

rtsp前缀要求使用可靠协议（在Internet上指TCP协议）发出命令，而rtspu前缀则说明使用不可靠协议（在Internet指UDP协议）。

RTSP建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的“网络遥控器”。RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，但有重要的不同。

RTSP引入了很多新方法并且有不同的协议标识符。

1. RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。

2. RTSP客户机和服务器都可以发出请求。

3. 数据由信带外的另一个协议传送（但有一个特例）。

4. RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。

5. RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。

6. 当只有一个IP的主机要提供多个文档树时，可使“虚拟主机”的实现更简单。

方法描述

OPTIONS:

OPTIONS请求在任何时候都可能产生，例如：当一个客户端准备尝试一个非标准的请求时。它不影响服务器的状态。

DESCRIBE:

服务器取得请求URL所标识的表示或者媒体对象的描述。它可能使用同意头部（Accept header）来指出客户端能理解的描述格式。服务器以所请求的资源的描述作为回应。DESCRIBE 回复-响应对继续了RTSP的媒体初始化阶段。DESCRIBE响应必须包含它所描述的资源的所有媒体初始化信息。

ANNOUNCE：

该方法方法有两个目的：

当从客户端发往服务器端，ANNOUNCE向服务器端上传请求URL所标识的表示或媒体对象的描述。当从服务器端发往客户端，ANNOUNCE实时更新会话描述。

当一个新的媒体流加入一个表示（例如：在一个现场表示活动期间）时，整个表示而不仅是所增加的部分，应该被重发，以便部分删除。

SETUP：

让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

启动SETUP所分配的流的数据传输。

PAUSE：

临时暂停流，而不释放服务器资源。

GET_PARAMETER：

请求用于获取URI所标识的一个表示或者流的参数的值。回复和响应的内容被留给具体实现。没有实体的GET_PARAMETER可能被用于测试客户端或者服务器端是否现场直播（"ping"）。

TEARDOWN：

释放流占用的资源，RTSP会话停止，从服务器端退出。

 

在VLC播放器中的抓包(正常播放)-vlcServer

（粉红色部分是客户端发出的请求，黑色部分是服务器的响应，//后面是注释）

OPTIONS rtsp://219.219.218.224:554/m RTSP/1.0     

CSeq: 1

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Server: vlc 1.0.1

Content-Length: 0

Cseq: 1

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

DESCRIBE rtsp://219.219.218.224:554/m RTSP/1.0

CSeq: 2

Accept: application/sdp

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Content-type: application/sdp

Server: VLC Server

Content-Length: 544

CSeq: 2

Cache-Control: no-cache

v=0 //协议版本

o=- 78967746000 3 IN IP4 219.219.218.224 //拥有者，即会话的创建者

c=IN IP4 0.0.0.0  //连接信息，此处表示本机

t=0 0 //如果stop-time设置为0,则会话没有时间限制。如果start-time也设置为0，则会话被认为是永久的.

a=tool:vlc 1.0.1  //创建任务描述的工具的名称及版本号

a=range:npt=0-7.741 //视频的正常播放范围

m=audio 0 RTP/AVP 96  //音频流使用的协议 m=<media> <port>/<number of ports> <proto> <fmt> …

a=rtpmap:96 mpeg4-generic/32000 //a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1290; SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1; //a=fmtp:<format> <format specific parameters>

a=control:rtsp://219.219.218.224:554/m/trackID=0

m=video 0 RTP/AVP 97 //视频流使用的协议

a=rtpmap:97 MP4V-ES/90000

a=fmtp:97 profile-level-id=3; config=000001b022000001b50900000100000001200084456a285020f0a300;

a=control:rtsp://219.219.218.224:554/m/trackID=1

SETUP rtsp://219.219.218.224:554/m/trackID=0 RTSP/1.0

CSeq: 3

Transport: RTP/AVP;unicast;client_port=3106-3107

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Transport: RTP/AVP/UDP;client_port=3106-3107

Server: VLC Server

Content-Length: 0

Cseq: 3

Cache-Control: no-cache

Session: 11478

SETUP rtsp://219.219.218.224:554/m/trackID=1 RTSP/1.0

CSeq: 4

Transport: RTP/AVP;unicast;client_port=3108-3109

Session: 11478

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Transport: RTP/AVP/UDP;client_port=3108-3109

Server: VLC Server

Content-Length: 0

Cseq: 4

Cache-Control: no-cache

Session: 11478

PLAY rtsp://219.219.218.224:554/m RTSP/1.0

CSeq: 5

Session: 11478

Range: npt=0.000-

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Server: VLC Server

Content-Length: 0

CSeq: 5

Cache-Control: no-cache

Session: 11478;timeout=5

GET_PARAMETER rtsp://219.219.218.224:554/m RTSP/1.0

CSeq: 6

Session: 11478

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Server: VLC Server

Content-Length: 0

CSeq: 6

Cache-Control: no-cache

TEARDOWN rtsp://219.219.218.224:554/m RTSP/1.0

CSeq: 7

Session: 11478

User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.09)

RTSP/1.0 200 OK

Server: VLC Server

Content-Length: 0

CSeq: 7

Cache-Control: no-cache

Session: 11478;timeout=5

以上是利用RTSP协议进行流媒体播放的一个完整过程，其中setup，play是必须用到的方法，其它方法是可选。上述红色的标注部分是对sdp协议的一些主要参数进行的解释。

在RealPlayer中（无法播放）-VlcServer

OPTIONS rtsp://219.219.218.224:554 RTSP/1.0

CSeq: 1

User-Agent: RealMedia Player HelixDNAClient/10.0.1.754 (win32)

Supported: ABD-1.0

ClientChallenge: ffa50e558e3986073c2da8888484e48c

ClientID: WinNT_5.1_12.0.0.301_RealPlayer_R51CND_zh-CN_686

CompanyID: 7S3jofzYT7kR2j8sdJG0vA==

GUID: 00000000-0000-0000-0000-000000000000

PlayerStarttime: [28/09/2009:19:04:13 08:00]

Pragma: initiate-session

RegionData: 0

RTSP/1.0 200 OK

Server: vlc 1.0.1

Content-Length: 0

Cseq: 1

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

DESCRIBE rtsp://219.219.218.224:554/jiao RTSP/1.0

CSeq: 2

Accept: application/sdp

User-Agent: RealMedia Player HelixDNAClient/10.0.1.754 (win32)

Bandwidth: 3531079

ClientID: WinNT_5.1_12.0.0.301_RealPlayer_R51CND_zh-CN_686

GUID: 00000000-0000-0000-0000-000000000000

Language: zh-CN, zh, *

RegionData: 0

Require: com.real.retain-entity-for-setup

SupportsMaximumASMBandwidth: 1

RTSP/1.0 200 OK

Content-type: application/sdp

Server: VLC Server

Content-Length: 381

CSeq: 2

Cache-Control: no-cache

v=0

o=- 435378000 3 IN IP4 219.219.218.224

c=IN IP4 0.0.0.0

t=0 0

a=tool:vlc 1.0.1

a=range:npt=0-203.000

m=audio 0 RTP/AVP 14

a=rtpmap:14 MPA/90000

a=control:rtsp://219.219.218.224:554/jiao/trackID=0

m=video 0 RTP/AVP 96

a=rtpmap:96 MP4V-ES/90000

a=fmtp:96 profile-level-id=3; config=0000012008868400670c4e10c0518f;

a=control:rtsp://219.219.218.224:554/jiao/trackID=1

SETUP rtsp://219.219.218.224:554/jiao/trackID=0 RTSP/1.0

CSeq: 3

Transport: RTP/AVP;unicast;client_port=6970-6971;mode=play,RTP/AVP/TCP;unicast;mode=play

User-Agent: RealMedia Player HelixDNAClient/10.0.1.754 (win32)

RTSP/1.0 200 OK

Transport: RTP/AVP/UDP;client_port=6970-6971 //此处没有返回服务器端口

vlcClient——Helix Server

RTSP响应：Transport: RTP/AVP;unicast;client_port=3190-3191;server_port=18044-18045 返回了服务器端口

rtp协议实现传输，服务器向客户端推送报文，客户端利用rtcp协议通过提供的端口接收报文。

realPlayer——Helix Server

RTSP响应：Transport: x-real-rdt/udp;client_port=6970;server_port=15728 返回了服务器端口。

利用real专有的rdt协议实现传输，客户端主动发起请求，服务器响应后通过返回的端口进行传输数据。

vlc——vlcServer

RTSP响应：Transport: RTP/AVP/UDP;client_port=2926-2927 vlcServer不返回服务器端口

rtp协议传输，服务器向客户端推送报文，客户端利用rtcp协议通过tcpmux端口（传输控制协议端口服务多路开关选择器，不关心发送请求时提供的什么样的服务）接收报文。

由以上可知，当realPlayer—–vlcServer时，服务器向客户端推送报文，但是realPlayer无法利用rtcp协议通过tcpmux端口来接收报文（需要一个确切的端口号），导致了无法播放。但是目前并没有找到合适的解决方案。

Server: VLC Server

Content-Length: 0

Cseq: 3

Cache-Control: no-cache

Session: 19169

TEARDOWN rtsp://219.219.218.224:554 RTSP/1.0

CSeq: 4

User-Agent: RealMedia Player HelixDNAClient/10.0.1.754 (win32)

Session: 19169

RTSP/1.0 404 Not found

Content-Length: 311

Content-Type: text/html

经过抓包发现，在KMPlayer，暴风影音中的流媒体播放是借用了Real的库函数，所以与RealPlayer效果是一样的。