流媒體傳輸協議系列之--RTSP協議詳解

分類：IT技術 時間:2016-10-11

流媒體傳輸協議介紹

一、RTSP協議介紹

什麽是rtsp?

RTSP協議以客戶服務器方式工作，，如：暫停/繼續、後退、前進等。它是一個多媒體播放控制協議，用來使用戶在播放從因特網下載的實時數據時能夠進行控制, 因此 RTSP 又稱為“因特網錄像機遙控協議”。

        RTSP(Real-Time Stream Protocol)是一種基於文本的應用層協議，在語法及一些消息參數等方面，RTSP協議與HTTP協議類似。 是TCP/IP協議體系中的一個應用層協議, 由哥倫比亞大學, 網景和RealNetworks公司提交的IETF RFC標準. 對應的RFC編號是2326，可以在這裏搜索 RFC Editor

        該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據. RTSP在體系結構上位於RTP和RTCP之上, 它使用TCP或RTP完成數據傳輸. RTSP被用於建立的控制媒體流的傳輸，它為多媒體服務扮演“網絡遠程控制”的角色。盡管有時可以把RTSP控制信息和媒體數據流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流數據。媒體數據的傳送可通過RTP/RTCP等協議來完成。

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

網絡體系

RTSP是類似http的應用層協議，一個典型的流媒體框架網絡體系可參考下圖

image

一次基本的RTSP操作過程:

  • 首先，客戶端連接到流服務器並發送一個RTSP描述命令（DESCRIBE）。

  • 流服務器通過一個SDP描述來進行反饋，反饋信息包括流數量、媒體類型等信息。

  • 客戶端再分析該SDP描述，並為會話中的每一個流發送一個RTSP建立命令(SETUP)，RTSP建立命令告訴服務器客戶端用於接收媒體數據的端口。流媒體連接建立完成後，

  • 客戶端發送一個播放命令(PLAY)，服務器就開始在UDP上傳送媒體流（RTP包）到客戶端。 在播放過程中客戶端還可以向服務器發送命令來控制快進、快退和暫停等。

  • 最後，客戶端可發送一個終止命令(TERADOWN)來結束流媒體會話

sequenceDiagram
客戶端->>服務器:DESCRIBE
服務器->>客戶端: 200 OK (SDP)
客戶端->>服務器:SETUP
服務器->>客戶端: 200 OK
客戶端->>服務器:PLAY
服務器->>客戶端: (RTP包)

協議特點

  • 可擴展性: 新方法和參數很容易加入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協議與HTTP協議區別

  1. RTSP引入了幾種新的方法，比如DESCRIBE、PLAY、SETUP 等，並且有不同的協議標識符，RTSP為rtsp 1.0,HTTP為http 1.1；

  2. HTTP是無狀態的協議，而RTSP為每個會話保持狀態；

  3. RTSP協議的客戶端和服務器端都可以發送Request請求，而在HTTPF 協議中，只有客戶端能發送Request請求。

  4. 在RTSP協議中，載荷數據一般是通過帶外方式來傳送的(除了交織的情況)，及通過RTP協議在不同的通道中來傳送載荷數據。而HTTP協議的載荷數據都是通過帶內方式傳送的，比如請求的網頁數據是在回應的消息體中攜帶的。

  5. 使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化；

  6. RTSP使用URI請求時包含絕對URI。而由於歷史原因造成的向後兼容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機名放入單獨的標題域中；

二、RTSP 的報文結構

RTSP URL的語法結構

一個終端用戶是通過在播放器中輸入URL地址開始進行觀看流媒體業務的第一步，而對於使用RTSP協議的移動流媒體點播而言，URL的一般寫法如下：

一個以“rtsp”或是“rtspu”開始的URL鏈接用於指定當前使用的是RTSP 協議。RTSP URL的語法結構如下：

rtsp_url = (“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name

host：可以是一個有效的域名或是IP地址。

port：端口號，對於RTSP協議來說，缺省的端口號為554。當我們在確認流媒體服務器提供的端口號為554時，此項可以省略 說明：當HMS服務器使用的端口號為554時，我們在寫點播鏈接時，可以不用寫明端口號，但當使用非554端口時，在RTSP URL中一定要指定相應的端口。

abs_path: 為RTSPServer中的媒體流資源標識，見下章節的錄像資源命名。 

RTSPURL用來標識RTSPServer的媒體流資源，可以標識單一的媒體流資源，也可以標 識多個媒體流資源的集合。 

RTSP的報文結構

    RTSP是一種基於文本的協議，用CRLF作為一行的結束符。使用基於文本協議的好處在於我們可以隨時在使用過程中的增加自定義的參數，也可以隨便將協議包抓住很直觀的進行分析。

    RTSP有兩類報文：請求報文和響應報文。請求報文是指從客戶向服務器發送請求報文，響應報文是指從服務器到客戶的回答。 由於 RTSP 是面向正文的(text-oriented)，因此在報文中的每一個字段都是一些 ASCII 碼串，因而每個字段的長度都是不確定的。 RTSP報文由三部分組成，即開始行、首部行和實體主體。在請求報文中，開始行就是請求行.

RTSP請求報文的結構如下圖所示

image

                        圖2 RTSP請求報文的結構

RTSP請求報文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。

一個請求消息（a request message）即可以由客戶端向服務端發起也可以由服務端向客戶端發起。請求消息的語法結構如下：

Request = Request-Line

  *(  general-header   | request-header | entity-header)

      CRLF

      [message-body]
1. Request Line

請求消息的第一行的語法結構如下：

Request-Line    =   Method 空格 Request-URI 空格 RTSP-version CRLF

其中在消息行中出現的第一個單詞即是所使用的信令標誌。目前已經有的信息標誌如下：

  Method      =   “DESCRIBE” 
          |   “ANNOUNCE”
          |   “GET_PARAMETER”
          |   “OPTIONS”
          |   “PAUSE”
          |   “PLAY”
          |   “RECORD”
          |   “REDIRECT”
          |   “SETUP”
          |   “SET_PARAMETER”
          |   “TEARDOWN”

例子：

DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0

2. Request Header Fields

在消息頭中除了第一行的內容外，還有一些需求提供附加信息。其中有些是一定要的，後續我們會詳細介紹經常用到的幾個域的含義。

  Request-header      =   Accept
              |   Accept-Encoding
              |   Accept-Language
              |   Authorization
              |   From
              |   If-Modified-Since
              |   Range
              |   Referer
              |   User-Agent

響應消息

響應報文的開始行是狀態行，RTSP響應報文的結構如下圖所示 image

                        圖3 RTSP響應報文的結構

響應消息的語法結構如下：

Response = Status-Line *( general-header | response-header | entity-header) CRLF [message-body]

1. Status-Line

響應消息的第一行是狀態行（status-line），每個元素之間用空格分開。除了最後的CRLF之外，在此行的中間不得有CR或是LF的出現。它的語法格式如下，

Status-Line = RTSP-Version 空格 Status-Code 空格 Reason-Phrase CRLF

狀態碼（Status-Code） 是一個三位數的整數，用於描述接收方對所收到請求消息的執行結果

Status-Code的第一位數字指定了這個回復消息的種類，一共有5類：

  •  1XX: Informational – 請求被接收到，繼續處理

  •  2XX: Success – 請求被成功的接收，解析並接受

  •  3XX: Redirection – 為完成請求需要更多的操作

  •  4XX: Client Error – 請求消息中包含語法錯誤或是不能夠被有效執行

  •  5XX: Server Error – 服務器響應失敗，無法處理正確的有效的請求消息

我們在處理問題時經常會遇到的狀態碼有如下：




Status-Code=“200”.|“400”.|“404”.|“500”
2. Response Header Fields

在響應消息的域中存放的是無法放在Status-Line中,而又需要傳送給請求者的一些附加信息。

 Response-header    =   Location
              |   Proxy-Authenticate
              |   Public
              |   Retry-After
              |   Server
              |   Vary
              |   WWW-Authenticate

RTSP的主要方法：

方法方向對象要求含義DESCRIBEC->SP,S推薦檢查演示或媒體對象的描述，也允許使用接收頭指定用戶理解的描述格式。DESCRIBE的答復-響應組成媒體RTSP初始階段ANNOUNCEC->S S->CP,S可選當從用戶發往服務器時，ANNOUNCE將請求URL識別的演示或媒體對象描述發送給服務器；反之，ANNOUNCE實時更新連接描述。如新媒體流加入演示，整個演示描述再次發送，而不僅僅是附加組件，使組件能被刪除GET_PARAMETERC->S S->CP,S可選GET_PARAMETER請求檢查RUL指定的演示與媒體的參數值。沒有實體體時，GET_PARAMETER也許能用來測試用戶與服務器的連通情況OPTIONSC->S S->CP,S要求可在任意時刻發出OPTIONS請求，如用戶打算嘗試非標準請求，並不影響服務器狀態PAUSEC->SP,S推薦PAUSE請求引起流發送臨時中斷。如請求URL命名一個流，僅回放和記錄被停止；如請求URL命名一個演示或流組，演示或組中所有當前活動的流發送都停止。恢復回放或記錄後，必須維持同步。在SETUP消息中連接頭超時參數所指定時段期間被暫停後，盡管服務器可能關閉連接並釋放資源，但服務器資源會被預訂PLAYC->SP,S要求PLAY告訴服務器以SETUP指定的機制開始發送數據；直到一些SETUP請求被成功響應，客戶端才可發布PLAY請求。PLAY請求將正常播放時間設置在所指定範圍的起始處，發送流數據直到範圍的結束處。PLAY請求可排成隊列，服務器將PLAY請求排成隊列，順序執行RECORDC->SP,S可選該方法根據演示描述初始化媒體數據記錄範圍，時標反映開始和結束時間；如沒有給出時間範圍，使用演示描述提供的開始和結束時間。如連接已經啟動，立即開始記錄，服務器數據請求URL或其他URL決定是否存儲記錄的數據；如服務器沒有使用URL請求，響應應為201（創建），並包含描述請求狀態和參考新資源的實體與位置頭。支持現場演示記錄的媒體服務器必須支持時鐘範圍格式，smpte格式沒有意義REDIRECTS->CP,S可選重定向請求通知客戶端連接到另一服務器地址。它包含強制頭地址，指示客戶端發布URL請求；也可能包括參數範圍，以指明重定向何時生效。若客戶端要繼續發送或接收URL媒體，客戶端必須對當前連接發送TEARDOWN請求，而對指定主執新連接發送SETUP請求SETUPC->SS要求對URL的SETUP請求指定用於流媒體的傳輸機制。客戶端對正播放的流發布一個SETUP請求，以改變服務器允許的傳輸參數。如不允許這樣做，響應錯誤為"455 Method Not Valid In This State”。為了透過防火墻，客戶端必須指明傳輸參數，即使對這些參數沒有影響SET_PARAMETERC->S S->CP,S可選請求設置演示或URL指定流的參數值。請求僅應包含單個參數，允許客戶端決定某個特殊請求為何失敗。如請求包含多個參數，所有參數可成功設置，服務器必須只對該請求起作用。服務器必須允許參數可重復設置成同一值，但不讓改變參數值。註意：媒體流傳輸參數必須用SETUP命令設置。將設置傳輸參數限制為SETUP有利於防火墻。將參數劃分成規則排列形式，結果有更多有意義的錯誤指示TEARDOWNC->SP,S要求TEARDOWN請求停止給定URL流發送，釋放相關資源。如URL是此演示URL，任何RTSP連接標識不再有效。除非全部傳輸參數是連接描述定義的，SETUP請求必須在連接可再次播放前發布
註：P---演示，C---客戶端,S---服務器， S（對象欄）---流
信令指的是在Request-URI中指定的需要被接收者完成的操作。信令（The method）大小寫敏感，不能以字符”$”開始，並且一定要是一個標記符。

RTSP重要頭字段參數

  1. Accept: 用於指定客戶端可以接受的媒體描述信息類型。比如: Accept: application/rtsl, application/sdp;level=2

  2. Bandwidth: 用於描述客戶端可用的帶寬值。

  3. CSeq： 指定了RTSP請求回應對的序列號，在每個請求或回應中都必須包括這個頭字段。對每個包含一個給定序列號的請求消息，都會有一個相同序列號的回應消息。

  4. Rang： 用於指定一個時間範圍，可以使用SMPTE、NTP或clock時間單元。

  5. Session: Session頭字段標識了一個RTSP會話。Session ID 是由服務器在SETUP的回應中選擇的，客戶端一當得到Session ID後，在以後的對Session 的操作請求消息中都要包含Session ID.

  6. Transport: Transport頭字段包含客戶端可以接受的轉輸選項列表，包括傳輸協議，地址端口，TTL等。服務器端也通過這個頭字段返回實際選擇的具體選項。如: Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

簡單的RTSP消息交互過程

C表示RTSP客戶端,S表示RTSP服務端

第一步：查詢服務器端可用方法

C->S OPTION request //詢問S有哪些方法可用

S->C OPTION response //S回應信息的public頭字段中包括提供的所有可用方法

第二步：得到媒體描述信息

C->S DESCRIBE request //要求得到S提供的媒體描述信息

S->C DESCRIBE response //S回應媒體描述信息，一般是sdp信息

第三步：建立RTSP會話

C->S SETUP request //通過Transport頭字段列出可接受的傳輸選項，請求S建立會話

S->C SETUP response //S建立會話，通過Transport頭字段返回選擇的具體轉輸選項，並返回建立的Session ID;

第四步：請求開始傳送數據

C->S PLAY request //C請求S開始發送數據

S->C PLAY response //S回應該請求的信息

第五步： 數據傳送播放中

S->C 發送流媒體數據 // 通過RTP協議傳送數據

第六步：關閉會話，退出

C->S EARDOWN request //C請求關閉會話

S->C TEARDOWN response //S回應該請求

上述的過程只是標準的、友好的rtsp流程，但實際的需求中並不一定按此過程。 其中第三和第四步是必需的！第一步，只要服務器和客戶端約定好有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。

RTSP的請求響應示例

 其中C是客戶端，S是服務端。
OPTIONS
  C->S:       OPTION request //詢問S有哪些方法可用
  S->C:       OPTION response //S回應信息中包括提供的所有可用方法

** 客戶端到服務端 **

OPTIONS rtsp://218.207.101.236:554/mobile/3/67A451E937422331 RTSP/1.0
Cseq: 1 

服務端對OPTIONS的回應：（服務器的回應信息會在Public字段列出提供的方法。）

RTSP/1.0 200 OK
Server: PVSS/1.4.8 (Build/20090111; Platform/Win32; Release/StarValley; )
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD 

DESCRIBE
  C->S:      DESCRIBE request //要求得到S提供的媒體初始化描述信息
  S->C:      DESCRIBE response //S回應媒體初始化描述信息，主要是sdp

客戶端到服務端的請求舉例:（客戶端向服務器端發送DESCRIBE，用於得到URI所指定的媒體描述信息，一般是SDP信息。客戶端通過Accept頭指定客戶端可以接受的媒體述信息類型。）

DESCRIBE rtsp://218.207.101.236:554/mobile/3/67A451E937422331/8jH5QPU5GWS07Ugn.sdp RTSP/1.0
Cseq: 2 

服務端對DESCRIBE的回應：（服務器回應URI指定媒體的描述信息）

RTSP/1.0 200 OK  
Server: PVSS/1.4.8 (Build/20090111; Platform/Win32; Release/StarValley; )  
Cseq: 2  
Content-length: 421  
Date: Mon, 03 Aug 2009 08:21:33 GMT  
Expires: Mon, 03 Aug 2009 08:21:33 GMT  
Content-Type: application/sdp  
x-Accept-Retransmit: our-retransmit  
x-Accept-Dynamic-Rate: 1  
Content-Base: rtsp://218.207.101.236:554/mobile/3/67A451E937422331/8jH5QPU5GWS07Ugn.sdp/  


v=0  
o=MediaBox 127992 137813 IN IP4 0.0.0.0  
s=RTSP Session  
i=Starv Box Live Cast  
c=IN IP4 218.207.101.236  
t=0 0  
a=range:npt=now-  
a=control:*  
m=video 0 RTP/AVP 96  
b=AS:20  
a=rtpmap:96 MP4V-ES/1000  
a=fmtp:96 profile-level-id=8; config=000001b008000001b5090000010000000120008440fa282c2090a31f; decode_buf=12586  
a=range:npt=now-  
a=framerate:5  
a=framesize:96 176-144  
a=cliprect:0,0,144,176  
a=control:trackID=1

Tags: 哥倫比亞 應用程序 IP協議 服務器 多媒體

文章來源：

ads
ads
相關文章
ads

相關文章

ad