rtsp協定詳解

RTSP(Real Time Streaming Protocol), 實時流傳輸協定, 是TCP/IP協定體系中的一個<code>應用層</code>協定, 由哥倫比亞大學, 網景和RealNetworks公司送出的IETF RFC标準. 該協定定義了一對多應用程式如何有效地通過IP網絡傳送多媒體資料. RTSP在體系結構上位于RTP和RTCP之上, 它使用TCP或RTP完成資料傳輸.

流媒體服務協定棧

RTSP提供了一個可擴充架構, 使實時資料, 如音頻與視訊的受控點播成為可能. 資料源包括現場資料與存儲在剪輯中資料. 該協定目的在于控制多個資料發送連接配接, 為選擇發送通道, 如UDP, 多點傳播UDP與TCP, 提供途徑, 并為選擇基于RTP上發送機制提供方法.

它的文法和運作跟HTTP 1.1類似, 但并不特别強調時間同步, 是以比較能容忍網絡延遲.

HTTP與RTSP相比, * HTTP傳送HTML. HTTP請求由客戶機發出, 伺服器作出響應 * RTSP傳送的是多媒體資料. 使用RTSP時, 客戶機和伺服器都可以送出請求, 即RTSP可以是<code>雙向</code>的.

RTSP是用來控制聲音或影像的多媒體串流協定, 并允許同時多個串流需求控制, 傳輸時所用的網絡通訊協定并不在其定義的範圍内, 伺服器端可以自行選擇使用TCP或UDP來傳送串流内容.

而前面提到的允許同時多個串流需求控制(Multicast), 除了可以降低伺服器端的網絡用量, 更進而支援多方視訊會議(Video Conference). 因為與HTTP1.1的運作方式相似, 是以代理伺服器〈Proxy〉的快取功能〈Cache〉也同樣适用于RTSP, 并因RTSP具有重新導向功能, 可視實際負載情況來轉換提供服務的伺服器, 以避免過大的負載集中于同一伺服器而造成延遲.

該協定用于C/S模型, 是一個基于文本的協定, 用于在用戶端和伺服器端建立和協商實時流會話.

實時流協定(RTSP)建立并控制一個或幾個時間同步的連續流媒體. 盡管連續媒體流與控制流交換是可能的, 通常它本身并不發送連續流. 換言之, RTSP充當多媒體伺服器的網絡遠端控制. RTSP連接配接沒有綁定到傳輸層連接配接, 如TCP. 在RTSP連接配接期間, RTSP使用者可打開或關閉多個對伺服器的可傳輸連接配接以發出RTSP請求. 此外, 可使用無連接配接傳輸協定, 如UDP. RTSP流控制的流可能用到RTP, 但RTSP操作并不依賴用于攜帶連續媒體的傳輸機制.

協定支援的操作如下: (1)從媒體伺服器上檢索媒體: 使用者可通過HTTP或其它方法送出一個示範描述. 如示範是多點傳播, 示範式就包含用于連續媒體的的多點傳播位址和端口. 如示範僅通過單點傳播發送給使用者, 使用者為了安全應提供目的位址. (2)媒體伺服器邀請進入會議: 媒體伺服器可被邀請參加正進行的會議, 或回放媒體, 或記錄其中一部分, 或全部. 這種模式在分布式教育應用上很有用, 會議中幾方可輪流按遠端控制按鈕. (3)将媒體加到現成講座中: 如伺服器告訴使用者可獲得附加媒體内容, 對現場講座顯得尤其有用. 如HTTP/1.1中類似, 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添加方法.

适當的伺服器控制: 如使用者啟動一個流, 必須也可以停止一個流.

傳輸協調: 實際處理連續媒體流前, 使用者可協調傳輸方法.

性能協調: 如基本特征無效, 必須有一些清理機制讓使用者決定哪種方法沒生效. 這允許使用者提出适合的使用者界面.

C表示rtsp用戶端, S表示rtsp服務端

上述的過程是标準的, 友好的rtsp流程, 但實際的需求中并不一定按部就班來. 其中第3和4步是必需的！

第一步, 隻要伺服器用戶端約定好, 有哪些方法可用, 則option請求可以不要.

第二步, 如果我們有其他途徑得到媒體初始化描述資訊(比如http請求等等), 則我們也不需要通過rtsp中的describe請求來完成.

第五步, 可以根據系統需求的設計來決定是否需要.

RTSP的消息有兩大類: <code>請求消息(request)</code>, <code>回應消息(response)</code>.

請求消息

其中<code>方法</code>包括OPTION回應中所有的指令,URI是接受方的位址,例如:rtsp://192.168.20.136. RTSP版本一般都是 RTSP/1.0. 每行後面的CR LF表示回車換行, 需要接受端有相應的解析, 最後一個<code>消息頭</code>需要有兩個CR LF(即空行)

回應消息

其中RTSP版本一般都是RTSP/1.0, 狀态碼是一個數值, 200表示成功, 解釋是與狀态碼對應的文本解釋.

方法記号表示資源上執行的方法, 它區分大小寫. 新方法可在将來定義, 但不能以$開頭. 已定義方法如下表所示:

(注: P----示範, S----流, C----使用者端, S----伺服器端)

某些防火牆設計與其他環境可能要求伺服器插入RTSP方法和流資料. 由于插入将使用戶端和伺服器操作複雜, 并增加附加開銷, 除非有必要, 應避免這樣做. 插入二進制資料僅在RTSP通過TCP傳輸時才可使用. 流資料(如RTP包)用一個ASCII字元'ʹ封裝, 後跟一個一位元組通道辨別, 其後是封裝二進制資料的長度, 兩位元組整數. 流資料緊跟其後, 沒有CRLF, 但包括高層協定頭. 每個塊包含一個高層協定資料單元.

當傳輸選擇為RTP, RTCP資訊也被伺服器通過TCP連接配接插入. 預設情況下, RTCP包在比RTP通道高的第一個可用通道上發送. 用戶端可能在另一通道顯式請求RTCP包, 這可通過指定傳輸頭插入參數中的兩個通道來做到. 當兩個或更多流交叉時, 為取得同步, 需要RTCP. 而且, 這為當網絡設定需要通過TCP控制連接配接透過RTP/RTCP提供了一條友善的途徑, 可能時, 在UDP上進行傳輸.

消息頭的定義如下表. 表格說明:

Type:

類型 "g" 表示請求和響應中的通用請求頭;

類型 "R" 表示請求頭;

類型 "r" 表示響應頭;

類型 "e" 表示實體頭字段.

Support:

"req." 表示必須由接收者以特殊的方法實作; 注意, 不是所有 "req." 字段在該類型的每個請求中都會被發送. "req." 隻表示客戶機(支援響應頭)和伺服器(支援請求頭)必須執行該字段.

"opt." 表示是可選的.

最後一欄列出了關于頭字段産生作用的方法; 其中 "entity" 針對于傳回一個資訊主體的所有方法. )

常用頭解析:

标準RTSP 消息的狀态碼(在應答消息的第一行表示)

本節針對上面所述的典型互動過程進行說明

OPTION

目的是得到伺服器提供的可用方法:

伺服器的回應資訊包括提供的一些方法,例如:

DESCRIBE

C向S發起DESCRIBE請求,為了得到會話描述資訊(SDP):

伺服器回應一些對此會話的描述資訊(sdp):

SETUP

用戶端提醒伺服器建立會話,并确定傳輸模式:

伺服器回應資訊:

PLAY

用戶端發送播放請求:

TEARDOWN

用戶端發起關閉請求:

伺服器回應:

以上方法都是互動過程中最為常用的, 其它還有一些重要的方法如<code>get/set_parameter,pause,redirect</code>等等

SDP 完全是一種會話描述格式, 它不屬于傳輸協定.

它使用不同的适當的傳輸協定，包括會話通知協定（SAP）、會話初始協定（SIP）、 實時流協定（RTSP）、MIME 擴充協定的電子郵件以及超文本傳輸協定（HTTP）。

SDP協定是也是基于文本的協定，這樣就能保證協定的可擴充性比較強, 這樣就使其具有廣泛的應用範圍。SDP 不支援會話内容或媒體編碼的協商, 是以在流媒體中隻用來描述媒體資訊。媒體協商這一塊要用RTSP來實作．

SDP描述由許多文本行組成，文本行的格式為&lt;類型&gt;=&lt;值&gt;，&lt;類型&gt;是一個字母，&lt;值&gt;是結構化的文本串，其格式依&lt;類型&gt;而定。

<code>＜type＞=&lt;value&gt;[CRLF]</code>

sdp的格式:

SDP（Session Description Protocol）是一個用來描述多媒體會話的應用層控制協定，它是一個基于文本的協定，用于會話建立過程中的媒體類型和編碼方案的協商等。

消息正文格式：

v=0 //該行訓示協定的版本

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 //o行中包含與會話所有者有關的參數

第一個參數表明會話發起者的名稱，該參數可不填寫，如填寫和SIP消息中，from消息頭的内容一緻。

第二個參數為主叫方的會話辨別符。

第三個參數為主叫方會話的版本，會話資料有改變時，版本号遞增。

第四個參數定義了網絡類型，IN表示Internet網絡類型，目前僅定義該網絡類型。

第五個參數為位址類型，目前支援IPV4和IPV6兩種位址類型。

第六個參數為位址：表明會話發起者的IP位址，該位址為信令面的IP位址，信令PDP激活時為手機配置設定。

s=SDP Seminar //表明本次會話的标題，或會話的名稱

i=A Seminar on the session description protocol //會話的描述

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps //會話的URI，通過該位址可以查閱到會話的更多内容

[email protected] (Mark Handley) //會話責任人的EMIAL位址

c=IN IP4 224.2.17.12/127 //C行包含為多媒體會話而建立的連接配接的資訊，其中指出了真正的媒體流使用的IP位址

第一個參數為網絡類型，目前僅定義INTERNET網絡類型。用“IN”表示。

第二個參數為位址類型，目前支援兩種位址類型：IPV4和IPV6。

第三個參數為位址，該位址為多媒體流使用的IP位址。

t=2873397496 2873404696 //表示會話的開始時間和結束時間

第一個參數表明會話的開始時間，數字表明從1900年1月1日00：00以來所經過的秒數。

第二個參數表明會話的結束時間，數字表明從1900年1月1日00：00以來所經過的秒數。

m=audio 3458 RTP/AVP 0 96 97 // m行又稱媒體行，描述了發送方所支援的媒體類型等資訊

第一個參數為媒體名稱：表明支援音頻類型。

第二個參數為端口号，表明UE在本地端口為3458上發送音頻流。

第三個參數為傳輸協定，一般為RTP/AVP協定。

第四~七參數為所支援的四種淨荷類型編号

a=rtpmap:0 PCMU //a行為媒體的屬性行，以屬性的名稱：屬性值的方式表示。

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

格式為：a=rtpmap:&lt;淨荷類型&gt;&lt;編碼名稱&gt; * 淨荷類型0固定配置設定給了PCMU， * 淨荷類型96對應的編碼方案為G.726,為動态配置設定的。 * 淨荷類型97對應的編碼方式為自适應多速率寬帶編碼（AMR-WB），為動态配置設定的。

m=video 3400 RTP/AVP 98 99 //m行又稱媒體行，描述了發送方所支援的媒體類型等資訊

第一個參數為媒體名稱：表明支援視訊類型。

第二個參數為端口号，表明UE在本地端口為3400上發送視訊流。

四、五參數給出了兩種淨荷類型編号

a=rtpmap:98 MPV

a=rtpmap:99 H.261

格式為：a=rtpmap:&lt;淨荷類型&gt;&lt;編碼名稱&gt; * 淨荷類型98對應的編碼方案為MPV,為動态配置設定的。 * 淨荷類型97對應的編碼方式為H.261，為動态配置設定的。