立你斯學習記錄

RTSP（Real Time Streaming Protocol） ，實時流傳輸協議，是 TCP/IP 協議體系中的一個應用層協議，由 RTSP哥倫比亞大學、網景和RealNetworks公司提交的 IETF RFC 標準。該協議定義了一對多應用程序如何有效地通過 IP 網絡傳送多媒體數據。 RTSP在體系結構上位於 RTP 和 RTCP 之上，它使用 TCP 或RTP完成數據傳輸。HTTP 與RTSP相比，HTTP傳送HTML，而RTP傳送的是多媒體數據。 HTTP請求由客戶機發出，服務器作出響應；使用RTSP時，客戶機和服務器都可以發出請求，即RTSP可以是雙向的。

RTSP - RTSP概述

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

實時流協議 （RTSP）是應用級協議，控制實時數據的發送。 RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻，的受控、點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在於控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，並為選擇基於RTP上發送機制提供方法。

實時流協議（RTSP）建立並控制一個或幾個時間同步的連續流a媒體。儘管連續媒體流與控制流交*是可能的，通常它本身並不發送連續流。換言之，RTSP充當多媒體服務器的網絡遠程控制。 RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對服務器的可*傳輸連接以發出RTSP請求。此外，可使用無連接傳輸協議，如UDP。 RTSP流控制的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。實時流協議在語法和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。然而，在很多重要方面RTSP仍不同於HTTP：

RTSP引入了大量新方法並具有一個不同的協議標識符；

在大多數情況下，RTSP服務器需要保持預設狀態，與HTTP的無狀態相對；

RTSP中客戶端和服務器都可以發出請求；

在多數情況下，數據由不同的協議傳輸；

RTSP使用ISO 10646（UTF-8）而並非ISO 8859-1，與當前的國際標準HTML相一致；

URI請求總是包含絕對URI。為了與過去的錯誤相互兼容，HTTP/1.1只在請求過程中傳送絕對路徑並將主機名置於另外的頭字段。

協議支持的操作如下：

從媒體服務器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體的的組播地址和端口。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。

媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分佈式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。

將媒體加到現成講座中：如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。

RTSP - RTSP 特性

可擴展性：
新方法和參數很容易加入RTSP。
易解析：
RTSP可由標準HTTP或MIME解吸器解析。
安全：
RTSP使用網頁安全機制。
獨立於傳輸：
RTSP可使用不可*數據報協議（UDP）、可*數據報協議（RDP），如要實現應用級可*，可
使用可*流協議。
多服務器支持：
每個流可放在不同服務器上，用戶端自動同不同服務器建立幾個並發控制連接，媒體同步在
傳輸層執行。
記錄設備控制：
協議可控制記錄和回放設備。
流控與會議開始分離：
僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下， SIP或H.323
可用來邀請服務器入會。
適合專業應用：
通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯

RTSP - 協議結構

RTSP是一種文本協議，採用UTF-8編碼中的ISO 10646字符集。一行可通過CRLF終止，但接收端需要做好解釋CR和LF作為一行終止符的準備。關於頭字段概述如下：

Header 　　　　　　Type 　　Support 　　Methods

Accept 　　　　　　 R 　　　　opt. 　　　　entity

Accept-Encoding　　 R 　　　　　opt. entity

　Accept-Language 　 R 　　　　opt. all

Allow　　　　　　　 R 　　　　　opt. all

Authorization 　　　 R 　　　　　opt. all

Bandwidth 　　　　　R 　　　　　opt. all

Blocksize 　　　　　 R 　　　　　opt. All but OPTIONS, TEARDOWN

Cache-Control 　　　G 　　　　　opt. SETUP

Conference 　　　　 R 　　　　　opt. SETUP

Connection 　　　　 G 　　　　　req. all

Content-Base 　　　 E 　　　　　opt. entity

Content-Encoding 　 E 　　　　　req. SET_PARAMETER

Content-Encoding 　 E　　　　　 req. DESCRIBE, ANNOUNCE

Content-Language 　E 　　　　　req. DESCRIBE, ANNOUNCE

Content-Length 　　 E　　　　　 req. SET_PARAMETER, ANNOUNCE

Content-Length 　　 E 　　　　　req. entity

Content-Location 　 E 　　　　　opt. entity

Content-Type 　　　E 　　　　　req. SET_PARAMETER, ANNOUNCE

Content-Type 　　　R 　　　　　req. entity

CSeq 　　　　　　 G 　　　　　req. all

Date 　　　　　　　G 　　　　　opt. all

Expires 　　　　　　E 　　　　　opt. DESCRIBE, ANNOUNCE

From 　　　　　　　R 　　　　　opt. all

　If-Modified-Since 　　R opt. DESCRIBE, SETUP

　Last-Modified 　　　E opt. entity

　Proxy-Authenticate

　Proxy-Require 　　　R req. all

　Public 　　　　　　R opt. all

Range 　　　　　　R opt. PLAY, PAUSE, RECORD

Range 　　　　　　R opt. PLAY, PAUSE, RECORD

　Referer 　　　　　　R opt. all

　Require 　　　　　　R req. all

　Retry-After 　　　　　R opt. all

　RTP-Info 　　　　　R req. PLAY

Scale 　　　　　　　Rr opt. PLAY, RECORD

Session　　　　　　Rr req. All but SETUP, OPTIONS

　Server 　　　　　　R opt. all

　Speed 　　　　　　　Rr opt. PLAY

　Transport 　　　　　Rr req. SETUP

　Unsupported　　　　R req. all

　User-Agent　　　　　R opt. all

　Via　　　　　　　　 G opt. all

　WWW-Authenticate　R opt. all

類型"g"表示請求和響應中的通用請求頭；類型“R”表示請求頭；類型“r”表示響應頭；類型"e"表示實體頭字段。在“support”一欄中標有“req.”的字段必須由接收者以特殊的方法實現；而“opt.”的字段是可選的。注意，不是所有“req.”字段在該類型的每個請求中都會被發送。 “req.”只表示客戶機（支持響應頭）和服務器（支持請求頭）必須執行該字段。最後一欄列出了關於頭字段產生作用的方法；其中“entity”針對於返回一個信息主體的所有方法。

RTSP - 微軟與RTSP

　RTSP並非只是微軟在用！

這是一個公開的規範，在這個規範上開發了很多的流服務器。甚至Linux服務提供者和蘋果的程序員也使用rtsp協議以及Real Networks流媒體。似乎整個世界的網絡流傳輸都用這個協議。然而，微軟並不只在rtsp上有所作為。

　微軟和RTSP

在寫這個文檔的時候，微軟正處於從首選MMS協議轉換到首選採用RTSP協議的過程中。這個說明在Media Player 9.0版本和流媒體服務器2003版本之後，我們會看到微軟將rtsp協議作為流媒體傳輸的主要協議。

隨著時間慢慢的流逝，我們會發現mms協議正逐步走出人們的視野。 It is only assumed that this is so MS can say they are being open with their protocols (rtsp is an open standard) while at the same time disregarding the need to publicise their own MMS protocol once its gone from media player. 然而，mms還沒有真的死亡，至少在接下來的幾年中我們依然可以看到它在流媒體傳輸中的身影。

是否微軟的RTSP協議和標準的開放式RTSP不同？

　是的。跟在RFC2326（1998年四月）中定義的原始RTSP協議相比，微軟的rtsp協議有一些輕微的改動。我們網站上有本文檔（還有後續版本）和一個簡單的研究，它們可以幫助你了解這些信息。

　區別在哪兒？

微軟的rstp規範與標準rtsp協議相比最主要的改動是發送包payloads到客戶端的方式，另外還有一些請求命令有一些改動。傳輸單個媒體包的機制並沒有文檔（就我目前所知），這可能是微軟要保留的信息。

就像MMS和HTTP 1.0流協議使用一個媒體數據包頭一樣，RTSP也有。但是微軟的數據包頭格式沒有在任何的rtsp文檔中註明。在企圖連接微軟的rtsp服務器時，這是主要的問題。

微軟RTSP協議的命令採用的語法和標準rtsp協議的命令語法一樣，只有一些小的修改和添加，可以通過閱讀網上的一些文檔，就可以知道怎麼去組成這些命令。 微軟rtsp命令部分已經有文檔了。

RTSP - 參考資料

[1] http://dslab.ee.ncku.edu.tw/~lily/learning/learning_ch2-1.html