RTSP（Real Time Streaming Protocol），RFC2326，實時流傳輸協定，是TCP/IP協定體系中的一個套用層協定，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。該協定定義了一對多應用程式如何有效地通過IP網路傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。HTTP與RTSP相比，HTTP請求由客戶機發出，伺服器作出回響；使用RTSP時，客戶機和伺服器都可以發出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協定，並允許同時多個串流需求控制，傳輸時所用的網路通訊協定並不在其定義的範圍內，伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但並不特彆強調時間同步，所以比較能容忍網路延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低伺服器端的網路用量，更進而支持多方視訊會議（Video Conference）。因為與HTTP1.1的運作方式相似，所以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。
基本介紹
協定簡介,重要概念,集合控制（Aggregatecontrol ）,實體（Entity）,容器檔案（Containerfile）,RTSP會話（RTSP session ）,協定特點,協定格式,請求訊息,應答訊息,協定參數,RTSP版本,RTSPURL,會議標識,連線標識,SMPTE相關時標,正常播放時間,絕對時間,可選標籤,RTSP信息,連線,方法定義,擴展,操作模式,狀態,RTSP與HTTP,
協定簡介
其是 TCP/IP 協定體系中的一個套用層協定，該協定定義了一對多應用程式如何有效地通過 IP 網路傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或RTP完成數據傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTSP傳送的是多媒體數據。
RTSP是基於文本的協定，採用ISO10646字元集，使用UTF-8編碼方案。行以CRLF中斷，包括訊息類型、訊息頭、訊息體和訊息長。但接收者本身可將CR和LF解釋成行終止符。基於文本的協定使其以自描述方式增加可選參數更容易，接口中採用SDP作為描述語言。
RTSP是套用級協定，控制實時數據的傳送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協定目的在於控制多個數據傳送連線，為選擇傳送通道，如UDP、組播UDP與TCP，提供途徑，並為選擇基於RTP上傳送機制提供方法。
RTSP建立並控制一個或幾個時間同步的連續流媒體。儘管連續媒體流與控制流交換是可能的，通常它本身並不傳送連續流。換言之，RTSP充當多媒體伺服器的網路遠程控制。RTSP連線沒有綁定到傳輸層連線，如TCP。在RTSP連線期間，RTSP用戶可打開或關閉多個對伺服器的可傳輸連線以發出RTSP請求。此外，可使用無連線傳輸協定，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。
協定支持的操作如下：
（1）從媒體伺服器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體的組播地址和連線埠。如演示僅通過單播傳送給用戶，用戶為了安全應提供目的地址。
RTSP協定支持
RTSP協定支持（2）媒體伺服器邀請進入會議：媒體伺服器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分散式教育套用上很有用，會議中幾方可輪流按遠程控制按鈕。
重要概念
集合控制（Aggregatecontrol ）
對多個流的同時控制。對音頻/視頻來講，客戶端僅需傳送一條播放或者暫停訊息就可同時控制音頻流和視頻流。
實體（Entity）
作為請求或者回應的有效負荷傳輸的信息。由以實體標題域（entity-header field）形式存在的元信息和以實體主體（entity body）形式存在的內容組成。
如不受請求方法或回響狀態編碼限制，請求和回響信息可傳輸實體，實體則由實體頭檔案和實體體組成，有些回響僅包括實體頭。在此，根據誰傳送實體、誰接收實體，傳送者和接收者可分別指用戶和伺服器。
實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協定，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略，而讓代理轉發。
容器檔案（Containerfile）
可以容納多個媒體流的檔案。RTSP伺服器可以為這些容器檔案提供集合控制。
RTSP會話（RTSP session ）
RTSP互動的全過程。對一個電影的觀看過程,會話（session）包括由客戶端建立媒體流傳輸機制（SETUP），使用播放（PLAY）或錄製（RECORD）開始傳送流，用停止（TEARDOWN）關閉流。
協定特點
RTSP協定具有如下特點：
可擴展性：新方法和參數很容易加入RTSP。
易解析：RTSP可由標準HTTP或MIME解析器解析。
安全：RTSP使用網頁安全機制。
獨立於傳輸：RTSP可使用不可靠數據報協定（EDP）、可靠數據報協定（RDP）；如要實現套用級可靠，可使用可靠流協定。
記錄設備控制：協定可控制記錄和回放設備。
流控與會議開始分離：僅要求會議初始化協定提供，或可用來創建惟一會議標識號。特殊情況下，可用SIP或H.323來邀請伺服器入會。
適合專業套用：通過SMPTE時標，RTSP支持幀級精度，允許遠程數字編輯。
演示描述中立：協定沒強加特殊演示或元檔案，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。
代理與防火牆友好：協定可由套用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流打開一個“缺口”。
HTTP友好：此處，RTSP明智地採用HTTP觀念，使現在結構都可重用。結構包括Internet內容選擇平台（PICS）。由於在大多數情況下控制連續媒體需要伺服器狀態，RTSP不僅僅向HTFP添加方法。
適當的伺服器控制：如用戶啟動一個流，必須也可以停止一個流。
傳輸協調：實際處理連續媒體流前，用戶可協調傳輸方法。
性能協調：如基本特徵無效，必須有一些清理機制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。
協定格式
RTSP中所有的操作都是通過伺服器和客戶端的訊息應答機制完成的，其中訊息包括請求和應答兩種，RTSP是對稱的協定，客戶機和伺服器都可以傳送和回應請求。RTSP是一個基於文本的協定，它使用UTF -8編碼（RFC2279）和ISO10646字元序列，採用RFC882定義的通用訊息格式，每個語句行由CRLF結束。RTSP的訊息包括請求和應答兩類。
請求訊息
請求訊息由請求行、標題行中的各種標題域和主體實體組成。請求行和標題行由ASCⅡ字元組成。
請求訊息的格式如右圖所示。
請求訊息格式
請求訊息格式其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址，例如:rtsp://192.168.0.1/video.264。RTSP版本一般都是 RTSP/1.0。每行後面的CRLF表示回車換行，需要接收端有相應的解析，最後一個訊息頭需要有兩個CRLF。訊息體是可選的，有的請求訊息並不帶訊息體
應答訊息
RTSP應答訊息的格式如右圖所示。
應答訊息格式
應答訊息格式其中RTSP版本一般都是RTSP/1.0。狀態碼是一個數值，用於表示請求訊息的執行結果，比如200表示成功。短語是與狀態碼對應的文本解釋。
協定參數
RTSP版本
H.321採用，用RTSP代替HTTP。
RTSPURL
“rksp"和“rtspu"方案用於指RTSP協定使用的網路資源，為RTSP URL定義方案特定的語法和語義。
會議標識
會議標識對RTSP來說是模糊的，採用標準URI編碼方法編碼，可包含任何八位組數值。會議標識必須全局惟一。
連線標識
連線標識是長度不確定的字元串，必須隨機選擇，至少要8個八位組長，使其很難被猜出。
SMPTE相關時標
SMPTE相關時標表示相對剪輯開始的時間，相關時標表示成SMPTE時間代碼，精確到幀級。時間代碼格式為小時：分鐘：秒：幀。預設smpte格式是"SMPTE 30"，幀速率為每秒29.97幀。其他SMPTE代碼可選擇使用smpte時間獲得支持（如"SMPIE 25"）。時間數值中幀段值可從0到29。每秒30與29.97幀的差別可將每分鐘的頭兩幀丟掉來實現。如幀值為零，就可刪除。
正常播放時間
正常播放時間（NPT）表示相對演示開始的流絕對位置。時標由十進制分數組成。左邊部分用秒或小時、分鐘、秒表示；小數點右邊部分表示秒的部分。演示的開始對應0.0秒，負數沒有定義。特殊常數定義成現場事件的當前時刻，這也許只用於現場事件。直觀上，NPT是聯繫觀看者與程式的時鐘，通常以數字式顯示在VCR上。
絕對時間
絕對時間表示成ISO 8601時標，採用UTC（GMT）。
可選標籤
可選標籤是用於指定RTSP新可選項的惟一標記。這些標記用在請求和代理-請求頭段。當登記新RTSP選項時，需提供下列信息：
（1）名稱和描述選項。名稱長度不限，但不應該多於20個字元。名稱不能包括空格、控制字元。
（2）表明誰改變選項的控制。如IETF，ISO，ITU-T，或其他國際標準團體、聯盟或公司。
（3）深入描述的參考，如RFC、論文、專利、技術報告、文檔源碼和計算機手冊。
（4）對專用選項，附上聯繫方式。
RTSP信息
RTSP是基於文本的協定，採用ISO 10646字元集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基於文本的協定使以自描述方式增加可選參數更容易。由於參數的數量和命令的頻率出現較低，處理效率沒引起注意。文本協定很容易以腳本語言（如：Tcl，Visual Basic與Perl）實現研究原型。
ISO 10646字元集避免敏感字元集切換，但對套用來說不可見。RTCP也採用這種編碼方案。帶有重要意義位的ISO 8859-1字元表示如100001x 10x x x x x x。RTSP信息可通過任何低層傳輸協定攜帶。
請求包括方法、方法作用於其上的對象以及進一步描述方法的參數。方法也可設計為在伺服器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度由如下因素決定：
（1）不管實體頭段是否出現在信息中，不包括信息體的回響，信息總以頭段後第一個空行結束。
（2）如出現內容長度頭段，其值以位元組計，表示信息體長度。如未出現頭段，其值為零。
（3）伺服器關閉連線。
注意，RTSP目前並不支持HTTP 1.1“塊”傳輸編碼，需要有內容長度頭。假如返回適度演示描述長度，即使動態產生，使塊傳輸編碼沒有必要，伺服器也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。
連線
RTSP請求可以幾種不同方式傳送：
· 持久傳輸連線，用於多個請求/回響傳輸；
· 每個請求/回響傳輸一個連線；
· 無連線模式。
傳輸連線類型由RTSP URL來定義。對“rtsp'’方案，需要持續連線；而"rtspu"方案，調用RTSP請求傳送，而不用建立連線。
方法定義
方法記號表示資源上執行的方法，它區分大小寫。新方法可在將來定義，但不能以$開頭。已定義方法如下表所示。
方法 | 方向 | 對象 | 要求 | 含義 |
DESCRIBE | C->S | P，S | 推薦 | 檢查演示或媒體對象的描述，也允許使用接收頭指定用戶理解的描述格式。DESCRIBE的答覆-回響組成媒體RTSP初始階段 |
ANNOUNCE | C->S S->C | P，S | 可選 | 當從用戶發往伺服器時，ANNOUNCE將請求URL識別的演示或媒體對象描述傳送給伺服器；反之，ANNOUNCE實時更新連線描述。如新媒體流加入演示，整個演示描述再次傳送，而不僅僅是附加組件，使組件能被刪除 |
GET_PARAMETER | C->S S->C | P，S | 可選 | GET_PARAMETER請求檢查URL指定的演示與媒體的參數值。沒有實體體時，GET_PARAMETER也許能用來測試用戶與伺服器的連通情況 |
OPTIONS | C->S S->C | P，S | 要求 | 可在任意時刻發出OPTIONS請求，如用戶打算嘗試非標準請求，並不影響伺服器狀態 |
PAUSE | C->S | P，S | 推薦 | PAUSE請求引起流傳送臨時中斷。如請求URL命名一個流，僅回放和記錄被停止；如請求URL命名一個演示或流組，演示或組中所有當前活動的流傳送都停止。恢復回放或記錄後，必須維持同步。在SETUP訊息中連線頭逾時參數所指定時段期間被暫停後，儘管伺服器可能關閉連線並釋放資源，但伺服器資源會被預訂 |
PLAY | C->S | P，S | 要求 | PLAY告訴伺服器以SETUP指定的機制開始傳送數據；直到一些SETUP請求被成功回響，客戶端才可發布PLAY請求。PLAY請求將正常播放時間設定在所指定範圍的起始處，傳送流數據直到範圍的結束處。PLAY請求可排成佇列，伺服器將PLAY請求排成佇列，順序執行 |
RECORD | C->S | P，S | 可選 | 該方法根據演示描述初始化媒體數據記錄範圍，時標反映開始和結束時間；如沒有給出時間範圍，使用演示描述提供的開始和結束時間。如連線已經啟動，立即開始記錄，伺服器數據請求URL或其他URL決定是否存儲記錄的數據；如伺服器沒有使用URL請求，回響應為201（創建），並包含描述請求狀態和參考新資源的實體與位置頭。支持現場演示記錄的媒體伺服器必須支持時鐘範圍格式，smpte格式沒有意義 |
REDIRECT | S->C | P，S | 可選 | 重定向請求通知客戶端連線到另一伺服器地址。它包含強制頭地址，指示客戶端發布URL請求；也可能包括參數範圍，以指明重定向何時生效。若客戶端要繼續傳送或接收URL媒體，客戶端必須對當前連線傳送TEARDOWN請求，而對指定主執新連線傳送SETUP請求 |
SETUP | C->S | S | 要求 | 對URL的SETUP請求指定用於流媒體的傳輸機制。客戶端對正播放的流發布一個SETUP請求，以改變伺服器允許的傳輸參數。如不允許這樣做，回響錯誤為"455 Method Not Valid In This State”。為了透過防火牆，客戶端必須指明傳輸參數，即使對這些參數沒有影響 |
SET_PARAMETER | C->S S->C | P，S | 可選 | 這個方法請求設定演示或URL指定流的參數值。請求僅應包含單個參數，允許客戶端決定某個特殊請求為何失敗。如請求包含多個參數，所有參數可成功設定，伺服器必須只對該請求起作用。伺服器必須允許參數可重複設定成同一值，但不讓改變參數值。注意：媒體流傳輸參數必須用SETUP命令設定。將設定傳輸參數限制為SETUP有利於防火牆。將參數劃分成規則排列形式，結果有更多有意義的錯誤指示 |
TEARDOWN | C->S | P，S | 要求 | TEARDOWN請求停止給定URL流傳送，釋放相關資源。如URL是此演示URL，任何RTSP連線標識不再有效。除非全部傳輸參數是連線描述定義的，SETUP請求必須在連線可再次播放前發布 |
註：P----演示，S----流，C----用戶端，S----伺服器端
某些防火牆設計與其他環境可能要求伺服器插入RTSP方法和流數據。由於插入將使客戶端和伺服器操作複雜，並增加附加開銷，除非有必要，應避免這樣做。插入二進制數據僅在RTSP通過TCP傳輸時才可使用。流數據（如RTP包）用一個ASCII字元$封裝，後跟一個一位元組通道標識，其後是封裝二進制數據的長度，兩位元組整數。流數據緊跟其後，沒有CRLF，但包括高層協定頭。每個$塊包含一個高層協定數據單元。
當傳輸選擇為RTP，RTCP信息也被伺服器通過TCP連線插入。預設情況下，RTCP包在比RTP通道高的第一個可用通道上傳送。客戶端可能在另一通道顯式請求RTCP包，這可通過指定傳輸頭插入參數中的兩個通道來做到。當兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當網路設定需要通過TCP控制連線透過RTP/RTCP提供了一條方便的途徑，可能時，在UDP上進行傳輸。
擴展
由於不是所有媒體伺服器有著相同的功能，媒體伺服器有必要支持不同請求集。RTSP可以如下三種方式擴展：
（1） 以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
（2） 加入新方法。如信息接收者不理解請求，返回501錯誤代碼，傳送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢伺服器支持的方法。伺服器使用公共回響頭列出支持的方法。
（3） 定義新版本協定，允許改變所有部分（協定版本號位置除外）。
操作模式
在TCP中RTT估計的初始值為500ms。套用快取最後所測量的RTT，作為將來連線的初始值。如使用一個可靠傳輸協定傳輸RTSP，請求不允許重發，RTSP套用反過來依賴低層傳輸提供可靠性。如兩個低層可靠傳輸（如TCP和RTSP）套用重發請求，有可能每個包損失導致兩次重傳。由於傳輸棧在第一次嘗試到達接收者前不會傳送套用層重傳，接收者也不能充分利用套用層重傳。如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。時標頭用來避免重發模糊性問題，避免對圓錐算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每傳送一個不同請求，它就加一。如由於沒有確認而重發請求，請求必須攜帶初始系列號。
下面區分幾種操作模式。
（3）用戶選擇地址多播：如伺服器加入正在進行的多播會議，多播地址、連線埠和密鑰由會議描述給出。
狀態
RTSP控制通過單獨協定傳送的數據流，與控制通道無關。例如，RTSP控制可通過TCP連線，而數據流通過UDP。因此，即使媒體伺服器沒有收到請求，數據也會繼續傳送。在連線生命期，單個媒體流可通過不同TCP連線順序發出請求來控制。所以，伺服器需要維持能聯繫流與RTSP請求的連線狀態。RTSP中很多方法與狀態無關，但下列方法在定義伺服器流資源的分配與套用上起著重要的作用：
RTSP狀態機
RTSP狀態機（1） SETUP：讓伺服器給流分配資源，啟動RTSP連線。
（2） PLAY與RECORD：啟動SETUP分配流的數據傳輸。
（3） PAUSE：臨時停止流，而不釋放伺服器資源。
（4） TEARDOWN：釋放流的資源，RTSP連線停止。
標識狀態的RTSP方法使用連線頭段識別RTSP連線，為回響SETUP請求，伺服器連線產生連線標識。
RTSP與HTTP
實時流協定在語法和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。然而，在很多重要方面RTSP仍不同於HTTP：
RTSP引入了大量新方法並具有一個不同的協定標識符；
在大多數情況下，RTSP伺服器需要保持預設狀態，與HTTP的無狀態相對；
RTSP中客戶端和伺服器都可以發出請求；
在多數情況下，數據由不同的協定傳輸；
RTSP使用ISO 10646（UTF-8）而並非ISO 8859-1，與當前的國際標準HTML相一致；
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協定規範目的在於允許在網頁伺服器與實現RTSP媒體伺服器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP伺服器與用戶不全依靠HTTP。
但是，RTSP與HTTP的本質差別在於數據傳送以不同協定進行。HTTP是不對稱協定，用戶發出請求，伺服器作出回響。RTSP中，媒體用戶和伺服器都可發出請求，且其請求都是無狀態的；在請求確認後很長時間內，仍可設定參數，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近時，在快取、代理和授權上採用HTTP功能是有價值的。
當大多數實時媒體使用RTP作為傳輸協定時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。
