流媒體傳輸控制協議詳解之RTSP

阿新 • • 發佈：2019-01-19

流媒體傳輸協議介紹

一、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協議區別

RTSP引入了幾種新的方法，比如DESCRIBE、PLAY、SETUP 等，並且有不同的協議識別符號，RTSP為rtsp 1.0,HTTP為http 1.1；
HTTP是無狀態的協議，而RTSP為每個會話保持狀態；
RTSP協議的客戶端和伺服器端都可以傳送Request請求，而在HTTPF 協議中，只有客戶端能傳送Request請求。
在RTSP協議中，載荷資料一般是通過帶外方式來傳送的(除了交織的情況)，及通過RTP協議在不同的通道中來傳送載荷資料。而HTTP協議的載荷資料都是通過帶內方式傳送的，比如請求的網頁資料是在迴應的訊息體中攜帶的。
使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化；
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重要頭欄位引數

Accept:
用於指定客戶端可以接受的媒體描述資訊型別。比如:
Accept: application/rtsl, application/sdp;level=2
Bandwidth:
用於描述客戶端可用的頻寬值。
CSeq：
指定了RTSP請求迴應對的序列號，在每個請求或迴應中都必須包括這個頭欄位。對每個包含一個給定序列號的請求訊息，都會有一個相同序列號的迴應訊息。
Rang：
用於指定一個時間範圍，可以使用SMPTE、NTP或clock時間單元。
Session:
Session頭欄位標識了一個RTSP會話。Session ID 是由伺服器在SETUP的迴應中選擇的，客戶端一當得到Session ID後，在以後的對Session 的操作請求訊息中都要包含Session ID.
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