申明該文章參考了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資訊 媒體描述是我們分析時常用的。

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”

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請求完成才能得到執行。

5.S->C:傳送流媒體資料 

6.C->S:TEARDOWN request //C請求關閉會話 
6.S->C:TEARDOWN response //S迴應該請求 
一個完整的RTSP協議請求流程就是這樣

上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不一定按此過程。

其中第三和第四步是必需的！第一步，只要伺服器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。

QQ群: 526221258