RTSP - fwrite

RTSP 協議#

實時流協議（Real Time Streaming Protocol，RTSP）是一種網絡應用協議，專為娛樂和通信系統的使用，以控制流媒體伺服器。該協議用於創建和控制終端之間的媒體會話。媒體伺服器的客戶端發布 VCR 命令，例如播放、錄製和暫停，以便於實時控制從伺服器到客戶端（視頻點播）或從客戶端到伺服器（語音錄音）的媒體流。是 TCP/IP 協議體系中的一個應用層協議，由哥倫比亞大學、網景和 RealNetworks 公司提交的 IETF RFC 標準。對應的 RFC 編號是 2326，可以在這裡搜索 RFC Editor

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

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

協議體系#

一次基本的 RTSP 操作過程：

首先，客戶端連接到流伺服器並發送一個 RTSP 描述命令（DESCRIBE）。
流伺服器通過一個 SDP 描述來進行反饋，反饋信息包括流數量、媒體類型等信息。
客戶端再分析該 SDP 描述，並為會話中的每一個流發送一個 RTSP 建立命令（SETUP），RTSP 建立命令告訴伺服器客戶端用於接收媒體數據的端口。流媒體連接建立完成後，
客戶端發送一個播放命令（PLAY），伺服器就開始在 UDP 上傳送媒體流（RTP 包）到客戶端。在播放過程中客戶端還可以向伺服器發送命令來控制快進、快退和暫停等。
最後，客戶端可發送一個終止命令（TEARDOWN）來結束流媒體會話。

    客戶端->伺服器：DESCRIBE
    伺服器->客戶端：200 OK (SDP)
    客戶端->伺服器：SETUP
    伺服器->客戶端：200 OK
    客戶端->伺服器：PLAY
    伺服器->客戶端：(RTP 包）

協議特點#

可擴展性：新方法和參數很容易加入 RTSP。
易解析：RTSP 可由標準 HTTP 或 MIME 解析器解析。
安全：RTSP 使用網頁安全機制。
獨立於傳輸：RTSP 可使用不可靠數據報協議（UDP），可靠數據報協議（RDP）；如要實現應用級可靠，可使用可靠流協議。
多伺服器支持：每個流可放在不同伺服器上，用戶端自動與不同伺服器建立幾個並發控制連接，媒體同步在傳輸層執行。
記錄設備控制：協議可控制記錄和回放設備。
流控與會議開始分離：僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下，可用 SI 或 H.323 來邀請伺服器入會。
適合專業應用：通過 SMPTE 時標，RTSP 支持幀級精度，允許遠程數字編輯。
演示描述中立：協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個 RTSP URL。
代理友好：此處，RTSP 明智地採用 HTTP 觀念，使現在結構都可重用。結構包括 Internet 內容選擇平台（PICS）。由於在大多數情況下控制連續媒體需要伺服器狀態，RTSP 不僅僅向 HTTP 添加方法。
適當的伺服器控制：如用戶啟動一個流，必須也可以停止一個流。
傳輸協調：實際處理連續媒體流前，用戶可協調傳輸方法。
性能協調：如基本特徵無效，必須有一些清理機制讓用戶決定哪種方法沒生效。

報文結構#

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 時，此項可以省略。
abs_path：為 RTSP Server 中的媒體流資源標識，見下章節的錄像資源命名。

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

RTSP 報文#

RTSP 是一種基於文本的協議，用 CRLF 作為一行的結束符。

RTSP 有兩類報文：請求報文和響應報文。請求報文是指從客戶向伺服器發送請求報文，響應報文是指從伺服器到客戶的回答。由於 RTSP 是面向正文的（text-oriented），因此在報文中的每一個字段都是一些 ASCII 碼串，因而每個字段的長度都是不確定的。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]

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://example.com/media.mp4 RTSP/1.0

Request Header Fields

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

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

響應消息

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

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

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": OK ,
              “400”: Bad Request ,
              “404”: Not Found ,
              “500”: Internal Server Error

Response Header Fields

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

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

主要方法#

方法	方向	對象	要求	含義
DESCRIBE	C->S	P S	推薦	檢查演示或媒體對象的描述，DESCRIBE 的答復 - 響應組成媒體 RTSP 初始階段
ANNOUNCE	C->S S->C	P S	可選	URL 識別的對象發送給服務，反之，ANNOUNCE 實時更新連接描述。
GET_PARAMETER	C->S S->C	P S	可選	請求檢查 RUL 指定的演示與媒體的參數值
OPTIONS	C->S S->C	P S	要求	可在任意時刻發出 OPTIONS 請求
PAUSE	C->S	P S	推薦	PAUSE 請求引起流發送臨時中斷
PLAY	C->S	P S	要求	PLAY 告訴伺服器以 SETUP 指定的機制開始發送數據
RECORD	C->S	P S	可選	該方法根據演示描述初始化媒體數據記錄範圍
REDIRECT	S->C	P S	可選	重定向請求通知客戶端連接到另一伺服器地址
SETUP	C->S	S	要求	對 URL 的 SETUP 請求指定用於流媒體的傳輸機制
SET_PARAMETER	C->S S->C	P S	可選	請求設置演示或 URL 指定流的參數值
TEARDOWN	C->S	P S	要求	TEARDOWN 請求停止給定 URL 流發送，釋放相關資源

注：P--- 演示，C--- 客戶端，S--- 伺服器，S（對象欄）--- 流

信令指的是在 Request-URI 中指定的需要被接收者完成的操作。信令（The method）大小寫敏感，不能以字符”$” 開始，並且一定要是一個標記符。

RTSP Header 參數#

Accept：用於指定客戶端可以接受的媒體描述信息類型。比如：Accept: application/rtsl, application/sdp;level=2。
Bandwidth：用於描述客戶端可用的帶寬值。
CSeq：指定了 RTSP 請求回應對的序列號，在每個請求或回應中都必須包括這個頭字段。對每個包含一個給定序列號的請求消息，都会有一個相同序列號的回應消息。
Range：用於指定一個時間範圍，可以使用 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=1289-1290;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 TEARDOWN request 	C 請求關閉會話
S->C TEARDOWN response 	S 回應該請求

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