申明该文章参考了http://blog.csdn.net/haolipengzhanshen/article/details/50802081 的文章，在这里标示感谢！
这篇文章主要从几个方面分析EasyDarwin的RTSP内容
RTSP协议概述
wireshark抓包实例分析 一次完整RTSP的交互流程
EasyDarwin项目代码中 RTSP的初始化
EasyDarwin项目代码中 RTSP请求的处理过程
如果你是只想实现视频流的传输，对转发服务器没有太大要求，建议只要研究EasyDarwin的客户端即可，客户端涉及到解码播放显示在地面站上。对于EasyDarwin的使用在EasyDarwin的官方有详细说明。
第一部分: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 重要方法
C->S
表示从客户端给服务器发数据，S->C表示从服务器给客户端发数据。通过以上几个方法完成客户端和服务器之间的指令交互，构成RTSP协议的基本框架。
我们用 wireshark来分析下这个RTSP的命令流程熟悉指令流程对于我们理解EasyDarwin有很重要的帮助。
来分析下rtsp包：
图1.1 客户端推流给服务器
图1.2 播放器从服务器获得视频流
RTSP协议基本流程,我们打开EasyDarwin工程运行，流媒体服务器。
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 客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。OPTIONS 字段后的rtsp://192.168.1.100:8003/st0.sdp RTSP/1.0\r\n 是请求的Server上的URI资源。 Content-Type: application/sdp //表示回应为SDP信息 Content-Length: 1383 //以下为具体的SDP信息 媒体描述是我们分析时常用的。
OPTIONS 字段后的rtsp://192.168.1.100:8003/st0.sdp RTSP/1.0\r\n
是请求的Server上的URI资源。
Content-Type: application/sdp //表示回应为SDP信息
Content-Length: 1383 //以下为具体的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 个或多个媒体属性行）
3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话 3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误”455 Method Not Valid In This State”
用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误”455 Method Not Valid In This State”4.C->S:PLAY request //C请求播放 4.S->C:PLAY response //S回应该请求的信息方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。
方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。5.S->C:发送流媒体数据
6.C->S:TEARDOWN request //C请求关闭会话 6.S->C:TEARDOWN response //S回应该请求一个完整的RTSP协议请求流程就是这样
一个完整的RTSP协议请求流程就是这样上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。
其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。
更多内容请看:http://www.amovauto.com/?p=481 阿木社区
QQ群: 526221258