EasyDarwin開源社區流媒體視頻課程：流媒體傳輸控制通訊協定(RTSP RTP SDP)詳解之RTSP

標籤：

視頻課程及相關文檔代碼地址：https://github.com/EasyDarwin/Course#course-3

流媒體傳輸協議介紹一、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的應用程式層協議，一個典型的流媒體架構網路體系可參考

一次基本的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請求報文的結構如所示

                        圖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響應報文的結構如所示

                        圖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	=
.	|
.	|
.	|

2. Response Header Fields

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

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

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請求檢查RUL指定的示範與媒體的參數值。沒有實體體時，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—示範，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  

擷取更多資訊

郵件：[email protected]

WEB：www.EasyDarwin.org

Copyright ? EasyDarwin.org 2012-2016

EasyDarwin開源社區流媒體視頻課程：流媒體傳輸控制通訊協定(RTSP RTP SDP)詳解之RTSP