-
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是 TCP/IP 協議體系中的一個應用層協議,該協議定義了一對多應用程序如何有效地通過 IP 網絡傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上,它使用TCP或UDP完成數據傳輸。HTTP與RTSP相比,HTTP傳送HTML,而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]
協議支持的操作如下:
(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Ⅱ字符組成。
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。URL是接接收方的地址,例如:rtsp://192.168.0.1/video.264。RTSP版本一般都是 RTSP/1.0。每行後面的CRLF表示回車換行,需要接收端有相應的解析,最後一個消息頭需要有兩個CRLF。消息體是可選的,有的請求消息並不帶消息體
[5]
RTSP應答消息
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控制通過單獨協議發送的數據流,與控制通道無關。例如,RTSP控制可通過TCP連接,而數據流通過UDP。因此,即使媒體服務器沒有收到請求,數據也會繼續發送。在連接生命期,單個媒體流可通過不同TCP連接順序發出請求來控制。所以,服務器需要維持能聯繫流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關,但下列方法在定義服務器流資源的分配與應用上起着重要的作用:
[8]
(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
- 收起