實時流協議RTSP(RealTimeStreamingProtocol)

實時流協議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的,該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上,它使用TCP或RTP完成數據傳輸。HTTP與RTSP相比,HTTP傳送HTML,而RTP傳送的是多媒體數據。HTTP請求由客戶機發出,服務器作出響應;使用RTSP時,客戶機和服務器都可以發出請求,即RTSP可以是雙向的。


6.3 RTSP協議
  實時流協議(RTSP)是應用級協議,控制實時數據的發送。RTSP提供了一個可擴展框架,使實時數據,如音頻與視頻,的受控、點播成爲可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在於控制多個數據發送連接,爲選擇發送通道,如UDP、組播UDP與TCP,提供途徑,併爲選擇基於RTP上發送機制提供方法。
  6.3.1 簡介
  6.3.1.1 目的
  實時流協議(RTSP)建立並控制一個或幾個時間同步的連續流媒體。儘管連續媒體流與控制流交叉是可能的,通常它本身並不發送連續流。換言之,RTSP充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接,如TCP。在RTSP連接期間,RTSP用戶可打開或關閉多個對服務器的可靠傳輸連接以發出RTSP 請求。此外,可使用無連接傳輸協議,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。實時流協議在語法和操作上與HTTP/1.1類似,因此HTTP的擴展機制大都可加入RTSP。協議支持的操作如下:
  從媒體服務器上檢索媒體:
  用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播,演示式就包含用於連續媒體的的組播地址和端口。如演示僅通過單播發送給用戶,用戶爲了安全應提供目的地址。
  媒體服務器邀請進入會議:
  媒體服務器可被邀請參加正進行的會議,或回放媒體,或記錄其中一部分,或全部。這種模式在分佈式教育應用上很有用,會議中幾方可輪流按遠程控制按鈕。
  將媒體加到現成講座中:
  如服務器告訴用戶可獲得附加媒體內容,對現場講座顯得尤其有用。如HTTP/1.1中類似,RTSP請求可由代理、通道與緩存處理。
 
  6.3.1.2 協議特點
  RTSP 特性如下:
  可擴展性:
  新方法和參數很容易加入RTSP。
  易解析:
  RTSP可由標準 HTTP或MIME解吸器解析。
  安全:
  RTSP使用網頁安全機制。
  獨立於傳輸:
  RTSP可使用不可靠數據報協議(UDP)、可靠數據報協議(RDP),如要實現應用級可靠,可使用可靠流協議。
  多服務器支持:
  每個流可放在不同服務器上,用戶端自動同不同服務器建立幾個併發控制連接,媒體同步在傳輸層執行。
  記錄設備控制:
  協議可控制記錄和回放設備。
  流控與會議開始分離:
  僅要求會議初始化協議提供,或可用來創建唯一會議標識號。特殊情況下, SIP或H.323
  可用來邀請服務器入會。
  適合專業應用:
  通過SMPTE 時標,RTSP支持幀級精度,允許遠程數字編輯
  演示描述中立:
  協議沒強加特殊演示或元文件,可傳送所用格式類型;然而,演示描述至少必須包含一個RTSP URI。
  代理與防火牆友好:
  協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法,爲UDP媒體流打開一個"缺口"。
  HTTP友好:
  此處,RTSP明智的採用HTTP觀念,使現在結構都可重用。結構包括Internet 內容選擇平臺(PICS)。由於在大多數情況下控制連續媒體需要服務器狀態, RTSP不僅僅向HTTP 添加方法。
  適當的服務器控制:
  如用戶啓動一個流,他必須也可以停止一個流。
  傳輸協調;
  實際處理連續媒體流前,用戶 可協調傳輸方法。
  性能協調:
  如基本特徵無效,必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。
  6.3.1.3擴展RTSP
  由於不是所有媒體服務器有着相同的功能,媒體服務器有必要支持不同請求集。RTSP 可以如下三種方式擴展,這裏以改變大小排序:
  以新參數擴展。如用戶需要拒絕通知,而方法擴展不支持,相應標記就加入要求的段中。
  加入新方法。如信息接收者不理解請求,返回501錯誤代碼(還未實現),發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方法。服務器使用公共響應頭列出支持的方法。
  定義新版本協議,允許改變所有部分。(除了協議版本號位置)
  6.3.1.4操作模式
  每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其它途徑用戶可獲得這個文件,它沒有必要保存在媒體服務器上。
  爲了說明,假設演示描述描述了多個演示,其中每個演示維持了一個公共時間軸。爲簡化說明,且不失一般性,假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數外,網絡目標地址和端口也需要決定。下面區分幾種操作模式:
  單播:
  以用戶選擇的端口號將媒體發送到RTSP請求源。
  組播,服務器選擇地址:
  媒體服務器選擇組播地址和端口,這是現場直播或準點播常用的方式。
  組播,用戶選擇地址:
  如服務器加入正在進行的組播會議,組播地址、端口和密匙由會議描述給出。
  6.3.1.5 RTSP狀態
  RTSP控制通過單獨協議發送的流,與控制通道無關。例如,RTSP控制可通過TCP連接,而數據流通過UDP。因此,即使媒體服務器沒有收到請求,數據也會繼續發送。在連接生命期,單個媒體流可通過不同TCP連接順序發出請求來控制。所以,服務器需要維持能聯繫流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關,但下列方法在定義服務器流資源的分配與應用上起着重要的作用:
  SETUP:
  讓服務器給流分配資源,啓動RTSP連接。
  PLAY與RECORD:
  啓動SETUP 分配流的數據傳輸。
  PAUSE:
  臨時停止流,而不釋放服務器資源。
  TEARDOWN:
  釋放流的資源,RTSP連接停止。
  標識狀態的RTSP方法使用連接頭段識別RTSP連接,爲響應SETUP請求,服務器連
  接產生連接標識。
 
  6.3.1.6 與其他協議關係
  RTSP在功能上與HTTP有重疊,與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規範目的在於允許在網頁服務器與實現RTSP媒體服務器之間存在不同傳遞點。例如,演示描述可通過HTTP和RTSP檢索,這降低了瀏覽器的往返傳遞,也允許獨立RTSP 服務器與用戶不全依靠HTTP。
  但是,RTSP與HTTP 的本質差別在於數據發送以不同協議進行。HTTP是不對稱協議,用戶發出請求,服務器作出響應。RTSP中,媒體用戶和服務器都可發出請求,且其請求都是無狀態的;在請求確認後很長時間內,仍可設置參數,控制媒體流。重用HTTP功能至少在兩個方面有好處,即安全和代理。要求非常接近,在緩存、代理和授權上採用HTTP功能是有價值的。
  當大多數實時媒體使用RTP作爲傳輸協議時,RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。
 
  6.3.2 協議參數
 
  6.3.3 RTSP 信息
  RTSP是基於文本的協議,採用ISO 10646 字符集,使用UTF-8編碼方案。行以CRLF中斷,但接收者本身可將CR和LF解釋成行終止符。基於文本的協議使以自描述方式增加可選參數更容易。由於參數的數量和命令的頻率出現較低,處理效率沒引起注意。如仔細研究,文本協議很容易以腳本語言(如:Tcl、Visual Basic與Perl)實現研究原型。
  10646字符集避免敏感字符集切換,但對應用來說不可見。RTCP也採用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協議攜帶。
  請求包括方法、方法作用於其上的對象和進一步描述方法的參數。方法也可設計爲在服務器端只需要少量或不需要狀態維護。當信息體包含在信息中,信息體長度有如下因素決定:
  不管實體頭段是否出現在信息中,不包括信息體的的響應信息總以頭段後第一和空行結束。
  如出現內容長度頭段,其值以字節計,表示信息體長度。如未出現頭段,其值爲零。
  服務器關閉連接。
  注意:RTSP目前並不支持HTTP/1.1"塊"傳輸編碼,需要有內容長度頭。假如返回適度演示描述長度,即使動態產生,使塊傳輸編碼沒有必要,服務器也應該能決定其長度。如有實體,即使必須有內容長度,且長度沒顯式給出,規則可確保行爲合理。
  從用戶到服務器端的請求信息在第一行內包括源採用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼,而沒有定義任何HTTP代碼。
  6.3.4 實體
  如不受請求方法或響應狀態編碼限制,請求和響應信息可傳輸實體,實體由實體頭文件和試題體組成,有些響應僅包括實體頭。在此,根據誰發送實體、誰接收實體,發送者和接收者可分別指用戶和服務器。
  實體頭定義實體體可選元信息,如沒有實體體,指請求標識的資源。擴展頭機制允許定義附加實體頭段,而不用改變協議,但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略,而讓代理轉發。
  6.3.5 連接
  RTSP請求可以幾種不同方式傳送:
  1、持久傳輸連接,用於多個請求/響應傳輸。
  2、每個請求/響應傳輸一個連接。
  3、無連接模式。
  傳輸連接類型由RTSP URI來定義。對 "rtsp" 方案,需要持續連接;而"rtspu"方案,調用RTSP 請求發送,而不用建立連接。
  不象HTTP,RTSP允許媒體服務器給媒體用戶發送請求。然而,這僅在持久連接時才支持,否則媒體服務器沒有可靠途徑到達用戶,這也是請求通過防火牆從媒體服務器傳到用戶的唯一途徑。
  6.3.6 方法定義
  方法記號表示資源上執行的方法,它區分大小寫。新方法可在將來定義,但不能以$開頭。
  某些防火牆設計與其他環境可能要求服務器插入RTSP方法和流數據。由於插入將使客戶端和服務器操作複雜,並強加附加開銷,除非有必要,應避免這樣做。插入二進制數據僅在RTSP通過TCP傳輸時纔可使用。流數據(如RTP包)用一個ASCII美圓符號封裝,後跟一個一字節通道標識,其後是封裝二進制數據的長度,兩字節整數。流數據緊

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章