RTSP学习(1)概念

参考：

RFC中文文档：http://www.cnpaf.net/class/RFC/

传输协议

1. RTP：实时传输协议
2. RTCP：实时传输控制协议
3. RTSP：实时流传输协议
4. RTMP：实时消息传输协议
5. RTMFP：Adobe实时消息流协议（P2P协议）
6. HTTP：超文本传输协议

RTSP：实时流协议
RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用
RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送

RTP：实时传输协议
RTP/RTCP是实际传输数据的协议（建立在udp和tcp协议之上，也就是调用关系）
RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server
整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）

RTCP：实时传输控制协议
是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈
RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议

RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。RTP是用来提供实时传输的，它建立在UDP之上，因而可以看成是传输层的一个子层。

一次基本的RTSP操作过程是:

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

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

1.第一步：查询服务器端可用方法
C->S:OPTIONrequest          //询问S有哪些方法可用
S->C:OPTIONresponse       //S回应信息的public头字段中包括提供的所有可用方法
2.第二步：得到媒体描述信息
C->S:DESCRIBE request    //要求得到S提供的媒体描述信息
S->C:DESCRIBE response  //回应媒体描述信息，一般是sdp信息
3.第三步：建立RTSP会话
C->S:SETUPrequest            //通过Transport头字段列出可接受的传输选项，请求S建立会话
S->C:SETUPresponse          //建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;
4.第四步：请求开始传送数据
C->S:PLAY request               //C请求S开始发送数据
S->C:PLAYresponse              //S回应该请求的信息
5.第五步：数据传送播放中
S->C:发送流媒体数据             //通过RTP协议传送数据
6.  第六步：关闭会话，退出
C->S:TEARDOWN request    //C请求关闭会话
S->C:TEARDOWN response //S回应该请求
上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。
其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。

RTSP 状态转换图解

RTSP重要术语

1.集合控制(Aggregatecontrol ):
        对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。
2.实体(Entity)：
        作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成
3.容器文件（Containerfile）：
        可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。
4.RTSP会话(RTSP session )：
        RTSP交互的全过程。对一个视频的播放过程，会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

5.消息(Message):

        RTSP通信的基本单元，由特定语法结构，序列化的八位字节流组成。

RTSP 关键字段说明

关键字： OPTIONS
得到服务器提供的可用方法（OPTION、 DESCRIBE、 SETUP、 TEARDOWN、 PLAY、 PAUSE、 SCALE、GET_PARAMETER、 SET_PARAMETER） 。

关键字： DESCRIBE
请求流的 SDP 信息。
注解： 此处需要了解 H264 Law Data 如何生成 SPS PPS 信息。

关键字： SETUP
客户端提醒服务器建立会话， 并建立传输模式。
注解： 此处确定了 RTP 传输交互式采用 TCP（面向连接） 还是 UDP（无连接） 模式。

关键字： PLAY
客户端发送播放请求。
注解： 此处引入 RTP 协议及 RTCP 协议。

关键字： PAUSE
播放暂停请求。
注解： 此关键字经常用在录像回放当中， 实时视频流几乎用不到。

关键字：TEARDOWN
客户端发送关闭请求

关键字：GET_PARAMETER
从服务器获取参数， 目前主要获取时间参数（可扩展）

关键字：SET_PARAMETER
给指定的 URL 或者流设置参数（可扩展）

RTSP消息格式

1.请求消息

其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址，例如:rtsp://192.168.0.1/video.264。RTSP版本一般都是 RTSP/1.0。每行后面的CRLF表示回车换行，需要接收端有相应的解析，最后一个消息头需要有两个CRLF。消息体是可选的，有的请求消息并不带消息体

2.响应消息

其中RTSP版本一般都是RTSP/1.0。状态码是一个数值，用于表示请求消息的执行结果，比如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
[email protected] (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

s = （会话名称）
i = * （会话信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （电话号码）
c = * （连接信息）
b = * （带宽信息）
z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
时间描述：
t = （会话活动时间）
r = * （0 或多次重复次数）
媒体描述：
m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）
k = * （加密密钥）
a = * （0 个或多个媒体属性行）

如果该协议仅仅用在视频流媒体当中， 不考虑带宽及其他会话信息， 常用到的 SDP 描述关键字段分别为：
1） m 字段： “m=<media> <port> <transport> <fmt list>” ：
样例： m=video 0 RTP/AVP 96
解释： 作为媒体描述的重要组成部分描述了媒体信息的详细内容： 表示一个 Session 的 video 是通过 RTP 格式来传
送的， 其中 Payload 值是 96， 传输端口开没有确定； 其中 Payload 值请参考 RFC 文档。
2） b 字段： “b=<modifier>:<bandwidth-value>” ：
样例： b=AS:70
解释： 70 是 VIDEO 的 bitrate，其它一些协议（HTTP，email附件，等）；
3） a 字段： “a=<attribute>:<value>” ：
样例： a=control:trackID=0
解释：表示通过流媒体 0 来传输 VIDEO，a 的属性有很多种，常用的是 control，比如“a=range:npt=0-72.080000 ”
表示流媒体的长度，再比如：“a=rtpmap:96 MPEG4-GENERIC/32000/2” 表示音频为 AAC 的其 sample
为 32000 等等， 根据具体的要求来使用。
4） v 字段： 表示 SDP 的版本， 一般填 0。
5） o 字段：定义了 SDP 一些源信息，“o=<username> <session id> <version> <network type> <address type><address>”
username： 该服务器的名称； session id： 会话 ID， 版本信息， 网络类型： IPV4 或 IPV6 传输地址；
样例： “o=StreamingServer 3331435948 1116907222000 IN IP4 192.168.1.123”
6） c 字段： “c=IN IP4 0.0.0.0 //connect 的信息， 分别描述了： 网络协议， 地址的类型， 连接地址”
7） t 字段： “t=0 0 //时间信息， 分别表示开始的时间和结束的时间， 一般在流媒体的直播的时移中见的比较多” 。

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

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"

真实的传输信息：

/mnt # ./sample_venc_rtsp 
MPP Ver  HI_VERSION=Hi3518EV200_MPP_V1.0.3.0 B040 Release
RTSP:-----Init Rtsp server
s32ChnNum = 1
=============SAMPLE_COMM_VI_SetMipiAttr enWDRMode: 0
linear mode
Aptina AR0130 sensor 720P30fps init success!
please press twice ENTER to exit this sample
<<<<RTSP Client 192.168.43.110 Connected...
RTSP:-----Create Client 192.168.43.110
[]<<<<<OPTIONS rtsp://192.168.43.145:554/stream_chn0.h264 RTSP/1.0
CSeq: 1
User-Agent: Lavf57.56.101


[][][][][][][]>>>>>RTSP/1.0 200 OK
CSeq: 1
Date: Thu, Jan 01 1970 00:04:47 GMT
Public: OPTIONS,DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN


[]<<<<<DESCRIBE rtsp://192.168.43.145:554/stream_chn0.h264 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf57.56.101


[][][][][][][]--------------------------------------------@钉?
                                                               >>>>>RTSP/1.0 200 OK
CSeq: 2
Date: Thu, Jan 01 1970 00:04:47 GMT
Content-Type: application/sdp
Content-length: 341
Content-Base: rtsp://@钉?stream_chn0.h264/

v=0
o=StreamingServer 3331435948 1116907222000 IN IP4 @钉?
s=H.264
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
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=AAABBCCC
m=audio 0 RTP/AVP 97
a=control:trackID=1
a=rtpmap:97 G726-32/8000/1
a=fmtp:97 packetization-mode=1

[]<<<<<SETUP rtsp://@钉?stream_chn0.h264/trackID=0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=23280-23281
CSeq: 3
User-Agent: Lavf57.56.101


[][][][][][][]--------------------------------------------
>>>>>RTSP/1.0 200 OK
CSeq: 3
Date: Thu, Jan 01 1970 00:04:47 GMT
Transport: RTP/AVP;unicast;destination=;client_port=23280-23281;server_port=53255-53511
Session: 1000

[]<<<<<SETUP rtsp://@钉?stream_chn0.h264/trackID=1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=23282-23283
CSeq: 4
User-Agent: Lavf57.56.101
Session: 1000


[][][][][][][]--------------------------------------------
>>>>>RTSP/1.0 200 OK
CSeq: 4
Date: Thu, Jan 01 1970 00:04:47 GMT
Transport: RTP/AVP;unicast;destination=;client_port=23282-23283;server_port=53255-53511
Session: 1000

RTMPInitTimer: c2f9bf44
[]<<<<<PLAY rtsp://@钉?stream_chn0.h264/ RTSP/1BA Ori Session Timeout(1) : Send ADD BA again
.0
Range: npt=0.000-
CSeq: 5
User-Agent: Lavf57.56.101
Session: BA - Send ADDBA request. StartSeq = 1c,  FrameLen = 33. BufSize = 64
1000

4
User-Agent: Lavf57.56.101
Session: 1000


[][][][][][][]--------------------------------------------
>>>>>RTSP/1.0 200 OK
CSeq: 5
Date: Thu, Jan 01 1970 00:04:47PeerAddBARspAction ==> Wcid(1)
 GMT
Range: npt=0.000-
Session: 1000            StatusCode = 0

RTP-Info: url=rtsp:///stream_chn0.h26ba>WinSize=63, MaxSize=21, MaxPeerRxSize=39
4;seq=0

udp up
Start Play
ba> reassign max win size from 63 to 21
BAOriSessionAdd():TXBAbitmap=41, BAWinSize=21, TimeOut=0
#BAOriSessionTearDown===>Wcid=1.TID=0 
        ===>Idx = 1, Wcid=1.TID=0, ORI_BA_Status = 3 
==> MlmeDELBAAction(), Initiator(1) 
BA - MlmeDELBAAction() . Send BAR to refresh peer reordering buffer 
BA - MlmeDELBAAction() . 3 DELBA sent. Initiator(1)
BATableFreeOriEntry: Wcid = 1, TID = 0
BATableFreeOriEntry numAsOriginator= 1
BAOriSessionTearDown===>Wcid=1.TID=6 
        ===>Idx = 2, Wcid=1.TID=6, ORI_BA_Status = 3 
==> MlmeDELBAAction(), Initiator(1) 
BA - MlmeDELBAAction() . Send BAR to refresh peer reordering buffer 
BA - MlmeDELBAAction() . 3 DELBA sent. Initiator(1)
BATableFreeOriEntry: Wcid = 1, TID = 6
BATableFreeOriEntry numAsOriginator= 1
################################@
RTMPInitTimer: c2f9bf04
BA Ori Session Timeout(1) : Send ADD BA again
BA - Send ADDBA request. StartSeq = 124,  FrameLen = 33. BufSize = 64
PeerAddBARspAction ==> Wcid(1)
                 StatusCode = 0
ba>WinSize=63, MaxSize=21, MaxPeerRxSize=39
ba> reassign max win size from 63 to 21
BAOriSessionAdd():TXBAbitmap=1, BAWinSize=21, TimeOut=0
RTMPInitTimer: c2f9bf44
BA Ori Session Timeout(1) : Send ADD BA again
BA - Send ADDBA request. StartSeq = 22,  FrameLen = 33. BufSize = 64
PeerAddBARspAction ==> Wcid(1)
                 StatusCode = 0
ba>WinSize=63, MaxSize=21, MaxPeerRxSize=39
ba> reassign max win size from 63 to 21
BAOriSessionAdd():TXBAbitmap=41, BAWinSize=21, TimeOut=0
#BAOriSessionTearDown===>Wcid=1.TID=0 
        ===>Idx = 1, Wcid=1.TID=0, ORI_BA_Status = 3 
==> MlmeDELBAAction(), Initiator(1) 
BA - MlmeDELBAAction() . Send BAR to refresh peer reordering buffer 
BA - MlmeDELBAAction() . 3 DELBA sent. Initiator(1)
BATableFreeOriEntry: Wcid = 1, TID = 0
BATableFreeOriEntry numAsOriginator= 1
BAOriSessionTearDown===>Wcid=1.TID=6 
        ===>Idx = 2, Wcid=1.TID=6, ORI_BA_Status = 3 
==> MlmeDELBAAction(), Initiator(1) 
BA - MlmeDELBAAction() . Send BAR to refresh peer reordering buffer 
BA - MlmeDELBAAction() . 3 DELBA sent. Initiator(1)
BATableFreeOriEntry: Wcid = 1, TID = 6
BATableFreeOriEntry numAsOriginator= 1
###############################################################@
RTMPInitTimer: c2f9bf04
BA Ori Session Timeout(1) : Send ADD BA again
BA - Send ADDBA request. StartSeq = 23,  FrameLen = 33. BufSize = 64
RTMPInitTimer: c2f9bf44
BA Ori Session Timeout(1) : Send ADD BA again
BA - Send ADDBA request. StartSeq = 546,  FrameLen = 33. BufSize = 64
PeerAddBARspAction ==> Wcid(1)
                 StatusCode = 0
ba>WinSize=63, MaxSize=21, MaxPeerRxSize=39
ba> reassign max win size from 63 to 21
BAOriSessionAdd():TXBAbitmap=40, BAWinSize=21, TimeOut=0
PeerAddBARspAction ==> Wcid(1)
                 StatusCode = 0
ba>WinSize=63, MaxSize=21, MaxPeerRxSize=39
ba> reassign max win size from 63 to 21
BAOriSessionAdd():TXBAbitmap=41, BAWinSize=21, TimeOut=0
[]<<<<<OPTIONS rtsp://@钉?stream_chn0.h264/ RTSP/1.0
CSeq: 6
User-Agent: Lavf57.56.101
Session: 1000

ession: 1000

4
User-Agent: Lavf57.56.101
Session: 1000


[][][][][][][]>>>>>RTSP/1.0 200 OK
CSeq: 6
Date: Thu, Jan 01 1970 00:05:17 GMT
Public: OPTIONS,DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN


RTSP:Recv Error--- -1
RTSP:-----Exit Client 192.168.43.110