參考資料地址
http://blog.sina.com.cn/s/blog_450e44880100mfiu.html
http://www.mikewootc.com/wiki/net/protocol/rtsp.html
RTSP，實時流傳輸協議，是TCP/UDP協議體系中的一個應用層協議，由哥倫比亞大學, 網景和RealNetworks公司提交的IETF RFC標准.該協議定義了一對多應用程序如何有效地通過IP網絡傳輸多媒體數據。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或者RTP完成數據傳輸。
流媒體服務協議棧
RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能，數據源包括現場數據與存儲在剪輯中數據。該協議目的在於控制多個數據發送鏈接，Wie選擇發送通道。如UDP 組播UDP與TCP，提供途徑，並為選擇基於RTP上發送機制提供方法。
它的語法和運作跟HTTP 1.1類似, 但並不特別強調時間同步, 所以比較能容忍網絡延遲.
HTTP與RTSP相比, * HTTP傳送HTML. HTTP請求由客戶機發出, 服務器作出響應 * RTSP傳送的是多媒體數據. 使用RTSP時, 客戶機和服務器都可以發出請求, 即RTSP可以是雙向的.
RTSP是用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，傳輸時所用的網絡通信協議並不在其定義的范圍內，服務器段可以自動選擇使用TCP或UDP來傳送串流內容。
而前面提到的允許同時多個串流需求控制，除了可以減低服務器端的網絡用量，更能支持多方視訊會議，因為與HTTP 1.1的運作方式相似，所以代理服務器的快選功能，同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的服務器，以避免過大的負載集中在同一服務器而造成延遲。
該協議用於CS模型，是一個基於文本的協議，用於在客戶端和服務器段建立和協商實時流會話。
實時流協議建立並控制一個或幾個時間同步的連續流媒體，盡管連續媒體流與控制流交換是可可能的。通常它本省並不發送連續流，換言之，RTSP充當多媒體服務器的網絡遠程控制，RTSP鏈接沒有綁定到傳輸層鏈接，如TCP，在RTSP連接期間，RTSP用戶可以打開或關閉多個服務器的可傳輸連接已發出RTSP請求。此外，可以使用無連接傳輸協議，如UDP，RTSP流控制的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制.
下面給出具體實現過程：
（1）客戶端發起RTSP OPTION請求，目的是得到服務器提供什么方法。RTSP提供的方法一般包括OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、SCALE、GET_PARAMETER。
（2）服務器對RTSP OPTION回應，服務器實現什么方法就回應哪些方法。在此系統中，我們只對DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE方法做了實現。
（3）客戶端發起RTSP DESCRIBE請求，服務器收到的信息主要有媒體的名字，解碼類型，視頻分辨率等描述，目的是為了從服務器那里得到會話描述信息（SDP）。
（4）服務器對RTSP DESCRIBE響應，發送必要的媒體參數，在傳輸H.264文件時，主要包括SPS/PPS、媒體名、傳輸協議等信息。
（5）客戶端發起RTSP SETUP請求，目的是請求會話建立並准備傳輸。請求信息主要包括傳輸協議和客戶端端口號。
（6）服務器對RTSP SETUP響應，發出相應服務器端的端口號和會話標識符。
（7）客戶端發出了RTSP PLAY的請求，目的是請求播放視頻流。
（8）服務器對RTSP PLAY響應，響應的消息包括會話標識符，RTP包的序列號，時間戳。此時服務器對H264視頻流封裝打包進行傳輸。
（9）客戶端發出RTSP TEARDOWN請求，目的是關閉連接，終止傳輸。
（10）服務器關閉連接，停止傳輸。
3. SETUP請求消息處理過程
RTSPClientSession類用於處理單獨的客戶會話。其類成員函數handleCmd_SETUP()處理客戶端的SETUP請求。調用parseTransportHeader()對SETUP請求的傳輸頭解析，調用子會話(這里具體實現類為OnDemandServerMediaSubsession)的getStreamParameters()函數獲取流媒體發送傳輸參數。將這些參數組裝成響應消息，返回給客戶端。
獲取發送傳輸參數的過程：調用子會話(具體實現類MPEG1or2DemuxedServerMediaSubsession)的createNewStreamSource(...)創建MPEG1or2VideoStreamFramer，選擇發送傳輸參數，並調用子會話的createNewRTPSink(...)創建MPEG1or2VideoRTPSink。同時將這些信息保存在StreamState類對象中，用於記錄流的狀態。
客戶端發送兩個SETUP請求，分別用於建立音頻和視頻的RTP接收。
4. PLAY請求消息處理過程
RTSPClientSession類成員函數handleCmd_PLAY()處理客戶端的播放請求。首先調用子會話的startStream(),內部調用MediaSink::startPlaying(...)，然后是MultiFramedRTPSink::continuePlaying()，接着調用MultiFramedRTPSink::buildAndSendPacket(...)。buildAndSendPacke內部先設置RTP包頭，內部再調用MultiFramedRTPSink::packFrame()填充編碼幀數據。
packFrame內部通過FramedSource::getNextFrame(), 接着MPEGVideoStreamFramer::doGetNextFrame()，再接着經過MPEGVideoStreamFramer::continueReadProcessing()， FramedSource::afterGetting(...), MultiFramedRTPSink::afterGettingFrame(...), MultiFramedRTPSink::afterGettingFrame1(...)等一系列繁瑣調用，最后到了MultiFramedRTPSink::sendPacketIfNecessary(), 這里才真正發送RTP數據包。然后是計算下一個數據包發送時間，把MultiFramedRTPSink::sendNext(...)函數句柄傳給任務調度器，作為一個延時事件調度。在主循環中，當MultiFramedRTPSink::sendNext()被調度時，又開始調用MultiFramedRTPSink::buildAndSendPacket(...)開始新的發送數據過程，這樣客戶端可以源源不斷的收到服務器傳來的RTP包了。
發送RTP數據包的間隔計算方法：
Update the time at which the next packet should be sent, based on the duration of the frame that we just packed into it.