RTSP簡介
RTSP（Real Time Streaming Protocol）是由Real Network和Netscape共同提出的如何有效地在IP網絡上傳輸流媒體資料的應用層協定。RTSP對流媒體提供了諸如暫停，快進等控制，而它本身并不傳輸資料，RTSP的作用相當于流媒體伺服器的遠端控制。伺服器端可以自行選擇使用TCP或UDP來傳送串流内容，它的文法和運作跟HTTP 1.1類似，但并不特别強調時間同步，是以比較能容忍網絡延遲。而且允許同時多個串流需求控制（Multicast），除了可以降低伺服器端的網絡用量，還可以支援多方視訊會議（Video onference）。 因為與HTTP1.1的運作方式相似，是以代理伺服器《Proxy》的快取功能《Cache》也同樣适用于RTSP，并因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中于同一伺服器而造成延遲。
RTSP是一種基于文本的協定，用CRLF作為一行的結束符。使用基于文本協定的好處在于我們可以随時在使用過程中的增加自定義的參數，也可以随便将協定包抓住很直覺的進行分析。
RTSP有兩類封包：請求封包和響應封包。請求封包是指從客戶向伺服器發送請求封包，響應封包是指從伺服器到客戶的回答。 由于 RTSP 是面向正文的(text-oriented)，是以在封包中的每一個字段都是一些 ASCII 碼串，因而每個字段的長度都是不确定的。 RTSP封包由三部分組成，即開始行、首部行和實體主體。在請求封包中，開始行就是請求行。
一次基本的RTSP操作過程：
- 首先，用戶端連接配接到流伺服器并發送一個RTSP描述指令（DESCRIBE）。
- 流伺服器通過一個SDP描述來進行回報，回報資訊包括流數量、媒體類型等資訊。
- 用戶端再分析該SDP描述，并為會話中的每一個流發送一個RTSP建立指令(SETUP)，RTSP建立指令告訴伺服器用戶端用于接收媒體資料的端口。流媒體連接配接建立完成後，
- 用戶端發送一個播放指令(PLAY)，伺服器就開始在UDP上傳送媒體流（RTP包）到用戶端。 在播放過程中用戶端還可以向伺服器發送指令來控制快進、快退和暫停等。
- 最後，用戶端可發送一個終止指令(TERADOWN)來結束流媒體會話
RTSP封包結構
RTSP是一種基于文本的協定，用CRLF作為一行的結束符。使用基于文本協定的好處在于我們可以随時在使用過程中的增加自定義的參數，也可以随便将協定包抓住很直覺的進行分析。
RTSP有兩類封包：請求封包和響應封包。請求封包是指從客戶向伺服器發送請求封包，響應封包是指從伺服器到客戶的回答。 由于 RTSP 是面向正文的(text-oriented)，是以在封包中的每一個字段都是一些 ASCII 碼串，因而每個字段的長度都是不确定的。 RTSP封包由三部分組成，即開始行、首部行和實體主體。在請求封包中，開始行就是請求行。
RTSP請求封包的結構
響應消息
簡單的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 EARDOWN request //C請求關閉會話
S->C TEARDOWN response //S回應該請求
上述的過程隻是标準的、友好的rtsp流程，但實際的需求中并不一定按此過程。 其中第三和第四步是必需的！第一步，隻要伺服器和用戶端約定好有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述資訊（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。