-
RTSP
鎖定
實時流傳輸協議（Real Time Streaming Protocol，RTSP），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具有重新導向功能，可視實際負載情況來轉換提供服務的服務器，以避免過大的負載集中於同一服務器而造成延遲。
[1]
RTSP協議簡介
協議分類
RTSP是基於文本的協議，採用ISO10646字符集，使用UTF-8編碼方案。行以CRLF中斷，包括消息類型、消息頭、消息體和消息長。但接收者本身可將CR和LF解釋成行終止符。基於文本的協議使其以自描述方式增加可選參數更容易，接口中採用SDP作為描述語言。
[2]
RTSP是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在於控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，併為選擇基於RTP上發送機制提供方法。
RTSP建立並控制一個或幾個時間同步的連續流媒體。儘管連續媒體流與控制流交換是可能的，通常它本身並不發送連續流。換言之，RTSP充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用户可打開或關閉多個對服務器的可傳輸連接以發出RTSP請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。
[3]
協議支持的操作如下：
RTSP協議支持
（2）媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分佈式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
（3）將媒體加到現成講座中：如服務器告訴用户可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
RTSP重要概念
RTSP集合控制
RTSP實體（Entity）
實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協議，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略，而讓代理轉發。
RTSP容器文件（Containerfile）
可以容納多個媒體流的文件。RTSP服務器可以為這些容器文件提供集合控制。
RTSPRTSP會話
RTSP交互的全過程。對一個電影的觀看過程,會話（session）包括由客户端建立媒體流傳輸機制（SETUP），使用播放（PLAY）或錄製（RECORD）開始傳送流，用停止（TEARDOWN）關閉流。
[4]
RTSP協議特點
RTSP協議具有如下特點：
可擴展性：新方法和參數很容易加入RTSP。不同的媒體服務器可以根據各自的功能，支持不同的請求集，擴展自己的新參數、方法，甚至定義新版本協議;當然也正是由於這個特點，使得同一個客户端軟件不一定能同時支持不同的媒體服務器。
[11]
易解析：RTSP可由標準HTTP或MIME解析器解析。
安全：RTSP使用網頁安全機制。
獨立於傳輸：RTSP可使用不可靠數據報協議（EDP）、可靠數據報協議（RDP）；如要實現應用級可靠，可使用可靠流協議。
記錄設備控制：協議可控制記錄和回放設備。
演示描述中立：協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。
代理與防火牆友好：協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流打開一個“缺口”。
HTTP友好：此處，RTSP明智地採用HTTP觀念，使現在結構都可重用。結構包括Internet內容選擇平台（PICS）。由於在大多數情況下控制連續媒體需要服務器狀態，RTSP不僅僅向HTFP添加方法。
適當的服務器控制：如用户啓動一個流，必須也可以停止一個流。
傳輸協調：實際處理連續媒體流前，用户可協調傳輸方法。
性能協調：如基本特徵無效，必須有一些清理機制讓用户決定哪種方法沒生效。這允許用户提出適合的用户界面。
RTSP協議格式
RTSP中所有的操作都是通過服務器和客户端的消息應答機制完成的，其中消息包括請求和應答兩種，RTSP是對稱的協議，客户機和服務器都可以發送和迴應請求。RTSP是一個基於文本的協議，它使用UTF -8編碼（RFC2279）和ISO10646字符序列，採用RFC882定義的通用消息格式，每個語句行由CRLF結束。RTSP的消息包括請求和應答兩類。
RTSP請求消息
請求消息由請求行、標題行中的各種標題域和主體實體組成。請求行和標題行由ASCⅡ字符組成。
圖1 請求消息格式
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址，例如:rtsp://192.168.0.1/video.264。RTSP版本一般都是 RTSP/1.0。每行後面的CRLF表示回車換行，需要接收端有相應的解析，最後一個消息頭需要有兩個CRLF。消息體是可選的，有的請求消息並不帶消息體
[5]
RTSP應答消息
圖2 應答消息格式
RTSP協議參數
RTSPRTSP版本
H.321採用，用RTSP代替HTTP。
RTSPRTSPURL
“rksp"和“rtspu"方案用於指RTSP協議使用的網絡資源，為RTSP URL定義方案特定的語法和語義。
RTSP會議標識
會議標識對RTSP來説是模糊的，採用標準URI編碼方法編碼，可包含任何八位組數值。會議標識必須全局惟一。
RTSP連接標識
連接標識是長度不確定的字符串，必須隨機選擇，至少要8個八位組長，使其很難被猜出。
RTSPSMPTE相關時標
SMPTE相關時標表示相對剪輯開始的時間，相關時標表示成SMPTE時間代碼，精確到幀級。時間代碼格式為小時：分鐘：秒：幀。缺省smpte格式是"SMPTE 30"，幀速率為每秒29.97幀。其他SMPTE代碼可選擇使用smpte時間獲得支持（如"SMPIE 25"）。時間數值中幀段值可從0到29。每秒30與29.97幀的差別可將每分鐘的頭兩幀丟掉來實現。如幀值為零，就可刪除。
RTSP正常播放時間
正常播放時間（NPT）表示相對演示開始的流絕對位置。時標由十進制分數組成。左邊部分用秒或小時、分鐘、秒錶示；小數點右邊部分表示秒的部分。演示的開始對應0.0秒，負數沒有定義。特殊常數定義成現場事件的當前時刻，這也許只用於現場事件。直觀上，NPT是聯繫觀看者與程序的時鐘，通常以數字式顯示在VCR上。
RTSP絕對時間
RTSP可選標籤
可選標籤是用於指定RTSP新可選項的惟一標記。這些標記用在請求和代理-請求頭段。當登記新RTSP選項時，需提供下列信息：
（1）名稱和描述選項。名稱長度不限，但不應該多於20個字符。名稱不能包括空格、控制字符。
（2）表明誰改變選項的控制。如IETF，ISO，ITU-T，或其他國際標準團體、聯盟或公司。
（4）對專用選項，附上聯繫方式。
RTSPRTSP信息
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定義了附加狀態代碼，但沒有定義任何HTTP代碼。
RTSP連接
RTSP請求可以幾種不同方式傳送：
· 持久傳輸連接，用於多個請求/響應傳輸；
· 每個請求/響應傳輸一個連接；
· 無連接模式。
傳輸連接類型由RTSP URL來定義。對“rtsp'’方案，需要持續連接；而"rtspu"方案，調用RTSP請求發送，而不用建立連接。
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，但包括高層協議頭。每個$塊包含一個高層協議數據單元。
[6]
當傳輸選擇為RTP，RTCP信息也被服務器通過TCP連接插入。缺省情況下，RTCP包在比RTP通道高的第一個可用通道上發送。客户端可能在另一通道顯式請求RTCP包，這可通過指定傳輸頭插入參數中的兩個通道來做到。當兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當網絡設置需要通過TCP控制連接透過RTP/RTCP提供了一條方便的途徑，可能時，在UDP上進行傳輸。
RTSP擴展
（1） 以新參數擴展。如用户需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
（3） 定義新版本協議，允許改變所有部分（協議版本號位置除外）。
RTSP操作模式
在TCP中RTT估計的初始值為500ms。應用緩存最後所測量的RTT，作為將來連接的初始值。如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴低層傳輸提供可靠性。如兩個低層可靠傳輸（如TCP和RTSP）應用重發請求，有可能每個包損失導致兩次重傳。由於傳輸棧在第一次嘗試到達接收者前不會發送應用層重傳，接收者也不能充分利用應用層重傳。如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。時標頭用來避免重發模糊性問題，避免對圓錐算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每發送一個不同請求，它就加一。如由於沒有確認而重發請求，請求必須攜帶初始系列號。
實現RTSP的系統必須支持通過TCP傳輸RTSP，並支持UDP。對UDP和TCP，RTSP服務器的缺省端口都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數據可與RTP和RTCP包交叉。不像HTTP，RTSP信息必須包含一個內容長度頭，無論信息何時包含負載。否則，RTSP包以空行結束，後跟最後一個信息頭。
每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其他途徑用户可獲得這個文件，它沒有必要保存在媒體服務器上。為了説明這個問題，假設演示描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化説明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數外，網絡目標地址和端口也需要決定。RTSP作為流媒體傳輸中的控制協議，可以對流媒體提供播放，暫停、快進、慢退等操作。
[10]
下面區分幾種操作模式。
RTSP狀態
RTSP狀態機
（1） SETUP：讓服務器給流分配資源，啓動RTSP連接。
（2） PLAY與RECORD：啓動SETUP分配流的數據傳輸。
（3） PAUSE：臨時停止流，而不釋放服務器資源。
（4） TEARDOWN：釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，服務器連接產生連接標識。
RTSPRTSP與HTTP
RTSP引入了大量新方法並具有一個不同的協議標識符；
在大多數情況下，RTSP服務器需要保持缺省狀態，與HTTP的無狀態相對；
RTSP中客户端和服務器都可以發出請求；
在多數情況下，數據由不同的協議傳輸；
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規範目的在於允許在網頁服務器與實現RTSP媒體服務器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP服務器與用户不全依靠HTTP。
但是，RTSP與HTTP的本質差別在於數據發送以不同協議進行。HTTP是不對稱協議，用户發出請求，服務器作出響應。RTSP中，媒體用户和服務器都可發出請求，且其請求都是無狀態的；在請求確認後很長時間內，仍可設置參數，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近時，在緩存、代理和授權上採用HTTP功能是有價值的。
- 參考資料
-
- 1. RFC 2326 Real Time Streaming Protocol (RTSP) ．IETF[引用日期2019-06-21]
- 2. 周曉華. 基於RTSP協議的流媒體自適應系統的設計與實現[D]. 上海交通大學, 2012.
- 3. 王路幫.RTSP協議及其分佈式應用框架[J].安徽職業技術學院學報,2006,5(1):4-6
- 4. Automatic recovering of RTSP sessions in mobile telephones using JADE-LEAP ．百度學術[引用日期2019-06-21]
- 5. 褚典,江春華,郝宗波,江維.基於SIP、RTP/RTCP和RTSP協議的視頻監控系統[J].計算機與現代化,2013(11):139-142
- 6. 巴洪濤. DVS系統RTSP服務器軟件設計與實現[D]. 浙江大學, 2011.
- 7. 基於單播的手機電視業務平台研究及實現 ．中國知網[引用日期2019-06-22]
- 8. 王榮生.RTSP協議在視頻點播系統中的應用[J].計算機應用與軟件,2004,21(11):47-4892
- 9. 李繼玲,於凡.RTP/RTSP、HTTP流化技術比較分析[J].科技創新導報,2010(28):23-23
- 10. 李校林,劉海波,張傑,劉利權.RTP/RTCP,RTSP在無線視頻監控系統的設計與實現[J].電視技術,2011,35(19):89-92
- 11. 王芙蓉,陳立偉.RTSP協議在VOD系統中的實現[J].中國數據通信,2004,6(12):75-77
- 收起
