从零开始学习EasyDarwin(RTSP篇之协议分析篇)
这篇文章主要从几个方面分析EasyDarwin的RTSP内容
RTSP协议概述
wireshark抓包实例分析 一次完整RTSP的交互流程
EasyDarwin项目代码中 RTSP的初始化
EasyDarwin项目代码中 RTSP请求的处理过程
第一部分:RTSP协议
一、RTSP协议概述
RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。HTTP协议相信大家都比较熟悉了.
RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。
一次基本的RTSP操作过程是:
首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。
流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。
流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。
在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话
二、RTSP 重要方法
使用wireshark抓取的rtsp过程的包
OPTIONS:
用于得到服务器提供的可用方法,如:
服务器的回应信息会在Public字段列出提供的方法。如:
DESCRIBE：
客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。
如：
OPTIONS 字段后的rtsp://192.168.1.3:554/easytest.mp4 RTSP/1.0\r\n
是请求的Server上的URI资源。
服务器回应URI指定媒体的描述信息:
Content-Type: application/sdp //表示回应为SDP信息
Content-Length: 1383
//以下为具体的SDP信息
媒体描述是我们分析时常用的。比如m和c
m= （媒体名称和传输地址）
i=* （媒体标题）
c=* （连接信息 — 如果包含在会话层则该字段可选）
b=* （带宽信息）
k=* （加密密钥）
a=* （0个或多个会话属性线路）
媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过以下方法来接收媒体描述信息：
a) 通过DESCRIBE方法；
b) 其它一些协议（HTTP，email附件，等）；
c) 通过命令行或标准输入设备
SETUP：
用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误”455 Method Not Valid In This State”。
Request中的Transport头字段指定了客户端可接受的数据传输参数；Response中的Transport 头字段包含了由服务器选出的传输参数。
如:
Transport: RTP/AVP;unicast;client_port=63086-63087
服务器端对SETUPRequest产生一个Session Identifiers。
如:
Session: 89056146913001
Transport: RTP/AVP;unicast;source=192.168.1.3;client_port=63086-63087;server_port=6970-6971;ssrc=00004CDF
PLAY：
PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。
PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。
比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。
CSeq: 835
Session: 89056146913001
Range: npt=10-15
C->S: PLAY rtsp://192.168.1.3:554/easytest.mp4 RTSP/1.0
CSeq: 836
Session: 89056146913001
Range: npt=20-25
C->S: PLAY rtsp://192.168.1.3:554/easytest.mp4 RTSP/1.0
CSeq: 837
Session: 89056146913001
Range: npt=30-
Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。
不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（the pause point）重新开始。
如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。
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头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。
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消息交互过程
C表示RTSP客户端,S表示RTSP服务端
第一步：查询服务器端可用方法
C->S:OPTION request //询问S有哪些方法可用
S->C:OPTION response //S回应信息的public头字段中包括提供的所有可用方法
第二步：得到媒体描述信息
C->S:DESCRIBE request //要求得到S提供的媒体描述信息
S->C:DESCRIBE response //S回应媒体描述信息，一般是sdp信息
第三步：建立RTSP会话
C->S:SETUP request //通过Transport头字段列出可接受的传输选项，请求S建立会话
S->C:SETUP response //S建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;
第四步：请求开始传送数据
C->S:PLAY request //C请求S开始发送数据
S->C:PLAY response //S回应该请求的信息
第五步： 数据传送播放中
S->C:发送流媒体数据 // 通过RTP协议传送数据
第六步：关闭会话，退出
C->S:TEARDOWN request //C请求关闭会话
S->C:TEARDOWN response //S回应该请求
上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。
其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。