實時流協議(RTSP)
( Real Time Streaming Protocol (RTSP) )
備忘錄的狀態：
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協
議標準”(STD1)來獲得本協議的標準化程度和狀態。本備忘錄的發佈不受任何限制。
版權聲明：
版權爲The Internet Society 所有。所有權利保留。
摘要：
實時流協議（RTSP）是應用層協議，控制實時數據的傳送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成爲可能。數據源包括現
場數據與存儲在剪輯中數據。該協議目的在於控制多個數據發送連接，爲選擇發送通道，如UDP、組播UDP與TCP，提供途徑，併爲選擇基於
RTP(RFC1889)上傳送機制提供方法。
目錄：
1 緒論 5
1.1 目的 5
1.2 要求 6
1.3 術語 6
1.4 協議特點 7
1.5 RTSP擴展 8
1.6 操作模式 9
1.7 RTSP狀態 9
1.8 與其他協議關係 10
2 符號協定 10
3 協議參數 10
3.1 RTSP版本 10
3.2 RTSP URL 11
3.3 會議標識 13
3.4 會話標識 13
3.5 SMPTE 相對時間戳 13
3.6正常播放時間 14
3.7 絕對時間 15
3.8 選擇標籤 15
3.8.1 用IANA註冊新的選擇標籤 15
4 RTSP消息 15
4.1 消息類型 16
4.2 消息標題 17
4.3 消息主體 17
4.4 消息長度 18
5 普通標題域 18
6 請求 19
6.1 請求隊列 19
6.2 請求標題域 19
7 迴應 20
7.1 狀態行 20
7.1.1 狀態代碼和原因分析 20
7.1.2 迴應標題域 23
8 實體 23
8.1 實體標題域 24
8.2 實體主體 24
9 連接 25
9.1 流水線操作 25
9.2 可靠性及確認 25
10 方法定義 25
10.1 選擇 26
10.2 描述 26
10.3 通告 26
10.4 建立 26
10.5 播放 27
10.6 暫停 27
10.7 斷開 27
10.8 獲取參數 28
10.9 設置參數 28
10.10 重定向 28
10.11 錄製 29
10.12 嵌入二進制數據 29
11狀態代碼定義（Status Code Definitions） 29
11.1成功2xx（Success 2xx） 30
11.1.1 存儲空間低 250 30
11.2 重定向（Redirection 3xx） 31
11.3 客戶端錯誤（Client Error ）4xx 31
11.3.1方法不允許 32
11.3.2參數不能理解 32
11.3.3會議未找到 33
11.3.4 帶寬不足 33
11.3.5 會話未找到 34
11.3.6 本狀態下該方法無效 34
11.3.7 標題域對資源無效 34
11.3.8 無效範圍 35
11.3.9 參數只讀 35
11.3.10 不允許合操作 36
11.3.11 只允許合操作 36
11.3.12 不支持的傳輸 36
11.3.13 目標不可達 37
11.3.14 選擇不支持 37
12 標題域定義（Header Field Definitions） 38
12.1 接受 38
12.2 接受編碼 38
12.3 接受語言 39
12.4 允許（Allow） 39
12.5 授權（Authorization） 40
12.6 帶寬 40
12.7 塊大小 40
12.8 緩存控制 41
12.9 會議 41
12.10 連接 41
12.11 基本內容 42
12.12 內容編碼（Content-Encoding） 42
12.13 內容語言 43
12.14 內容長度（Content-Length） 43
12.15 內容位置 43
12.16 內容類型（Content-Type） 44
12.17 序列號 44
12.18 日期（Date） 44
12.19 過期（Expires） 45
12.20 來自（From） 45
12.21 主機 45
12.22 如果匹配 45
12.23 從何時更改（If-Modified-Since） 46
12.24 最近更改（Last-Modified） 46
12.25 位置（Location） 46
12.26 代理授權 47
12.27 代理要求 47
12.28 公用性 47
12.29 範圍 49
12.30 提交方（Referer） 49
12.31 稍後再試 49
12.32 要求 49
12.33 RTP信息 49
12.34 比例 49
12.35 速度 49
12.36 服務器（Server） 49
12.37 會話 49
12.38 時間戳 49
12.39 傳輸 49
12.40 不支持 49
12.41 用戶代理（User-Agent） 49
12.42 變化 49
12.43 通過 49
12.44 WWW-授權（WWW-Authenticate） 50
13 緩存 50
14 實例 50
14.1 要求媒體（單播） 50
14.2 容器文件的流 51
14.3 單個流容器文件 51
14.4 組播現場媒體表示 51
14.5 在存在的會話中播放媒體 51
14.6 錄製 52
15 語法 52
15.1 基本語法 52
16 安全考慮（Security Considerations） 52
附錄A RTSP協議狀態機 53
A.1 客戶端狀態機 53
A.2 服務器端狀態機 53
附錄B 同RTP協議的交互 53
附錄C 使用SDP進行RTSP會話描述 54
C.1 定義 54
C.1.1 控制URL 55
C.1.2 媒體流 55
C.1.3 有效載荷類型 55
C.1.4 詳細格式參數 55
C.1.5 表示的範圍 56
C.1.6 有效時間 56
C.1.7 連接信息 56
C.1.8 實體標籤 57
C.2 合控制不可用 57
C.3 合控制可用 57
附錄D 最簡單的RTSP實現 58
D.1 客戶端 58
D.1.1回放 58
D.1.2 授權 58
D.2 服務器 59
D.2.1回放 59
D.2.2授權 59
附錄E 作者地址 60
附錄F 致謝 60
參考書目 60
版權申明 61
1 緒論
1.1 目的
實時流協議（RTSP）建立並控制一個或幾個時間同步的連續流媒體。儘管連續媒體流與控制流有可能交叉，但RTSP本身通常並不發送連續媒體流。換言
之，RTSP充當多媒體服務器的網絡遠程控制。
表示描述(presentation description)定義了被控流，但本文並沒有定義表示描述的格式。
這裏沒有使用RTSP連接的概念，而由RTSP會話(session)代替（每次服務由服務器端保持一個帶標籤的會話）。RTSP會話沒有綁定到傳輸層連
接（如TCP連接）。因爲雖然在RTSP會話期間，RTSP客戶端可打開或關閉多個對服務器端的可靠傳輸連接以發出RTSP
請求。但此外，也可能使用無連接傳輸協議，比如用UDP發送RTSP請求。
RTSP控制的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。實時流協議在語法和操作上與HTTP/1.1類似，因此HTTP的
擴展機制大都可加入RTSP。儘管如此，RTSP在很多方面還是和HTTP有很大的不同：
² RTSP引入了很多新方法並且有不同的協議標識符。
² RTSP服務器在大多數默認情況下需要維持一個狀態，但HTTP是無狀態協議。
² RTSP客戶機和服務器都可以發出請求。
² 數據由另一個協議傳送（有一特例除外）。
² RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化。
²
RTSP使用URI請求時包含絕對URI。而由於歷史原因造成的向後兼容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機名放入單獨的標題域
中。
這使得“虛擬主機”實現更爲簡便，一個單獨IP地址的主機可虛擬爲幾個文件樹主機。
協議支持的操作如下：
從媒體服務器上檢索媒體：
用戶可通過HTTP或其它方法請求一個表示描述。如表示是組播，表示描述就包含用於連續媒體的的組播地址和端口。如表示僅通過單播發送給用戶，用戶爲了安
全應提供目的地址。
媒體服務器邀請進入會議：
媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分佈式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
將媒體加到現成講座中：
如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。
如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
1.2 要求
在本文檔中的關鍵字“必須”，“一定不能”，“要求”，“會”，“不會”，“應該”，“不應該”，“被推薦的”，“可以”，和“可選擇的”都在
RFC2119中解釋。
1.3 術語
一些術語原由HTTP/1.1採用。在HTTP/1.1中定義的術語這裏不再列舉。
合控制：
服務器使用單條時間線對多個流的控制。對音頻/視頻回饋來講，這就意味着客戶端僅需發送一條播放或者暫停消息就可同時控制音頻和視頻的回饋。
會議：
多方參與的多媒體表示，這裏的多方意味着大於或者等於一方。
客戶端：
指請求媒體服務器上連續流媒體數據的客戶端。
連接：
兩個應用程序以通訊爲目的在傳輸層建立虛擬電路。
容器文件：
可以容納多個共同播放時包含表示(presentation)的媒體流的文件。RTSP服務器可以爲這些容器文件提供合控制，但容器文件的概念本身並不
是本協議內容。
連續媒體：
接受器和數據源之間存在時序關係的數據。也就是說，接受器需要重新產生存在於源數據中的時序關係。最普通的連續媒體的例子是音頻和動畫視頻。連續媒體可
以是實時的（但是不交互的），它們在源和接受器之間是一種緊密的時序關係；或者是流的形式，這種關係就沒有那麼嚴格了。
實體：
作爲請求或者回應的有效負荷傳輸的信息。由以實體標題域（entity-header field）形式存在的元信息和以實體主體（entity
body）形式存在的內容組成，如第八章所述。
媒體的初始化：
數據類型/編碼的具體初始化，這些包括時鐘輸率，顏色表等。用戶請求媒體回放的任何獨立傳輸信息，是在創建流時初始化媒體流相位時產生的。
媒體參數:
針對回放前或回放過程中有可能改變的媒體類型而專門設定的參數。
媒體服務器：
可對一個或多個媒體流提供回放和錄製服務的服務器。同一個表示(presentation)中不同的媒體流可能來自於不同的媒體服務器。媒體服務器可以建
立在作爲傳送請求表示(presentation)的Web服務器的主機上，也可以建立在不同的主機上。
媒體服務器重定向：
重新定向媒體客戶端到另外一個媒體服務器。
(媒體)流：
單個媒體實例，比如，在應用中共用音頻流或視頻流。當使用RTP時，流包括由RTP
會話(session)中源所創建的所有RTP和RTCP包。這和定義DSM-CC流時相同。
消息：
RTSP通訊的基本單元。由15章語法定義的一串八位位組組成，並通過連接或者無連接協議傳送。
參與者：
一個會議成員。參與者可以是機器，比如是媒體記錄或回放服務器。
表示(presentation)：
對用戶請求所回饋的一組流，其使用下面的表示描述(presentation
description)形式。在本文中的多數情況下，其意味着對流進行總體控制，但這並不是必須的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一個或者多個媒體流的信息。比如，編碼，網絡地址和內容的信息。另外，其他IETF協議，如SDP協議
使用會話(session)代替現場presentation。表示描述可以採用包括會話描述(session
description)SDP在內的多種格式。
迴應：
RTSP迴應。如果能理解HTTP迴應，就能清楚的理解RTSP迴應。
請求；
RTSP請求。如果能理解HTTP請求，就能清楚的理解RTSP請求。
RTSP會話(session)：
RTSP交互的全過程。比如，一個電影的觀看過程。會話(session)包括由客戶端建立連續媒體流傳輸機制(SETUP)，使用播放(PLAY)或錄
制(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
傳輸初始化：
客戶端和服務器端之間傳輸信息（端口號，傳輸協議等）的交互。
1.4 協議特點
RTSP 特性如下：
可擴展性：
RTSP中很容易加入新方法和參數。
易解析：
RTSP可由標準 HTTP或MIME解析器解析。
安全：
RTSP使用網頁安全機制。所有HTTP授權機制如basic和digest授權都可直接使用。也可以傳輸層或網絡層安全機制。
獨立於傳輸：
RTSP可使用不可靠數據報協議（UDP）、可靠數據報協議（RDP），如要實現應用級可靠，可使用可靠流協議。
多服務器支持：
表示(presentation)中的每個流可放在不同服務器上，用戶端自動同不同服務器建立幾個併發控制連接，媒體同步在傳輸層執行。
記錄設備控制：
協議可控制記錄和回放設備，也可控制可在記錄和回放切換的設備。
流控與會議開始分離：
流控與邀請媒體服務器入會分離；僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下， SIP或H.323 可用來邀請服務器入會。
適合專業應用：
通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯。
表示描述中立：
協議沒強加特殊表示或元文件，可傳達所用格式類型；然而，表示描述至少必須包含一個RTSP URI。
代理與防火牆友好：
協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，爲UDP媒體流打開一個/"缺口/"。
HTTP友好：
此處，RTSP明智的採用HTTP觀念，使現在結構都可重用。結構包括Internet
內容選擇平臺（PICS）。由於在大多數情況下控制連續媒體需要服務器狀態， RTSP不僅僅向HTTP 添加方法。
適當的服務器控制：
如用戶能啓動一個流，它必須也能停止一個流。 服務器不能啓動一個用戶不能停止的流。
傳輸協調：
實際處理連續媒體流前，用戶可協調傳輸方法。
性能協調：
如基本特徵無效，必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。 例如，如果不允許尋找，用戶界面必定能禁止位置條滑動。
以前要求RTSP必須能支持多用戶，但現在得出一個更好的方法就是保證RTSP能很容易擴展成支持多用戶即可。因爲流的標誌可以被多個控制流使用，因此”
遠程通過”成爲可能。協議不涉及到多個客戶端如何協調入口，其由下層“社會協議”或其他下層控制機制提供。
1.5 RTSP擴展
由於不是所有媒體服務器有着相同的功能，媒體服務器有必要支持不同請求集。例如：
Ø 服務器可能只須支持回放，因此不必不支持錄製功能。
Ø 對於支持現場播放的服務器可能不支持尋找功能。
Ø 一些服務器可能不支持設置流參數，因此不支持GET_PARAMETER和SET_PARAMETER。
但服務器應該實現所有12章中要求的標題域。
表示描述(presentation
description)應當保證不提出服務器不支持的功能，這種情形和HTTP/1.1中[H19.6]描述方法不支持across
server的情形一致。
RTSP 可以如下三種方式擴展，這裏以改變大小排序：
Ø 以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
Ø
加入新方法。如信息接收者不理解請求，返回501錯誤代碼（還未實現），發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方
法。服務器使用公共迴應標題列出支持的方法。
Ø 定義新版本協議，允許改變所有部分。（除了協議版本號位置）
1.6 操作模式
每個表示和媒體流可用RTSP URL識別。表示組成的整個表示與媒體屬性由表示描述(presentation
description)文件定義，表示描述格式不在本協議中定義。使用HTTP或其它途徑用戶可獲得這個文件，它沒有必要保存在媒體服務器上。
爲了說明，假設表示描述(presentation
description)描述了多個表示(presentation)，其中每個表示(presentation)維持了一個公共時間軸。爲簡化說明，且
不失一般性，假定表示描述(presentation
description)的確包含這樣一個表示(presentation)。表示(presentation)可包含多個媒體流。
表示描述(presentation
description)即組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數。在表示描述中，被RTSP分別控制的媒
體流由RTSP URL表示。RTSP
URL指出了處理具體媒體流的服務器以及存在於該服務器上流的名字。多個媒體流可以放到不同的服務器上，比如音頻和視頻流可以分別放到不同服務器而負載共
享。描述（description)還列出了服務器傳輸可使用的方法。
除媒體參數外，網絡目標地址和端口也需要決定。下面區分幾種操作模式：
單播：
以用戶選擇的端口號將媒體發送到RTSP請求源。
組播，服務器選擇地址：
媒體服務器選擇組播地址和端口，這是現場直播或準點播常用的方式。
組播，用戶選擇地址：
如服務器加入正在進行的組播會議，組播地址、端口和密匙由會議描述給出。
1.7 RTSP狀態
RTSP控制通過單獨協議發送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體服務器沒有收到請求，數據
也會繼續發送。在會話生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，服務器需要維持能聯繫流與RTSP請求的會話狀態。
RTSP中很多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起着重要的作用：
SETUP：
讓服務器給流分配資源，啓動RTSP會話。
PLAY與RECORD：
啓動SETUP 分配流的數據傳輸。
PAUSE：
臨時停止流，而不釋放服務器資源。
TEARDOWN：
釋放流的資源，RTSP會話停止。
標識狀態的RTSP方法使用會話(session)標題域識別RTSP會話，爲迴應SETUP請求，服務器生成會話標識。
1.8 與其他協議關係
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規範目的在於允許在網頁服務器與實現RTSP媒
體服務器之間存在不同傳遞點。例如，表示描述(presentation
description)可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP 服務器與用戶不全依靠HTTP。
但是，RTSP與HTTP
的本質差別在於數據發送以不同協議進行。HTTP是不對稱協議，用戶發出請求，服務器作出迴應。RTSP中，媒體用戶和服務器都可發出請求，且其請求都是
無狀態的；在請求確認後很長時間內，仍可設置參數，控制媒體流。
重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權上採用HTTP功能是有價值的。
當大多數實時媒體使用RTP作爲傳輸協議時，RTSP沒有綁定到RTP。
RTSP假設存在表示描述格式可表示包含幾個媒體流的表示的靜態與臨時屬性。
2 符號協定
既然很多定義和語法與HTTP/1.1中相同，這裏僅指出它們在HTTP/1.1中定義的位置而並沒有拷貝它們到本文檔。爲簡便起見，本文檔中[
HX.Y ]表示對應HTTP/1.1（RFC 2068）中的X.Y部分。（[譯者注：]爲更方便學習RTSP，本翻譯文檔將相關段落完全譯出）
與[H2.1]類似，本文對所有機制的說明都是以散文和補充反饋的方式來描述的。除RTSP中以”1#”代替”,”爲分隔符不同外，其餘在RFC
2234中有詳細的描述。簡單說明補充反饋方式如下：
補充反饋方式（augmented BNF）包括下面的結構：
要解釋的名詞＝名詞解釋（name = definition）
規則的名字（name）就是它本身（不帶任何尖括號，“<”，“>”），後面跟個等號＝，
然後就是該規則的定義。如果規則需要用多個行來描述，利用空格進行縮進格式排
版。某些基本的規則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義
中還可以使用尖括號來幫助理解規則名的使用。
字面意思（"literal"）
文字的字面意思放在引號中間，除非特別指定，該段文字是大小寫敏感的。
規則1｜規則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。
（規則1 規則2）（(rule1 rule2)）
在圓括號中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩
種意思，即“元素1 元素2 元素4”和“元素1 元素3 元素4”
*規則（*rule）
在元素前加星號“*”表示循環，其完整形式是“<n>*<m>元素”，表明元素最少產
生<n>次，最多<m>次。缺省值是0到無限，例如，“1*元素”意思是至少有一個，
而“1*2元素”表明允許有1個或2個。
［規則］（[rule]）
方括號內是可選元素。如“［元素1 元素2］”與“*1（元素1 元素2）”是一回
事。
N 規則（N rule）
表明循環的次數：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精確指出<n>
取值。因而，2DIGIT 就是2位數字, 3ALPHA 就是由三個字母組成字符串。
＃規則（#rule）
“#”與“*”類似，用於定義元素列表。
完整形式是“<n>#<m>元素”表示至少有<n>個至多有<m>個元素，中間用“,”或
任意數量的空格（LWS-linear whitespace）來分隔，這將使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素 ））”就等同於“1#元素”。
空元素在結構中可被任意使用，但不參與元素個數的計數。也就是說，“（元素1），，
（元素2）”僅表示2個元素。但在結構中，應至少有一個非空的元素存在。缺省
值是0到無限，即“#（元素）”表示可取任何數值，包括0；而“1#元素”表示至
少有1個；而“1#2元素”表示有1個或2個。
；註釋（; comment）
分號後面是註釋，僅在單行使用。
隱含*LWS（implied *LWS）
本文的語法描述是基於單詞的。除非另有指定，線性空格（LWS）可以兩個鄰近符
號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之
間必須有至少一個分隔符，因爲它們也要做爲單獨的符號來解釋。實際上，應用程序在
產生HTTP結構時，應當試圖遵照“通常方式”，因爲現在的確有些實現方式在通常方
式下無法正常工作。
在本備忘錄中，我們用縮進的小型段落來提供動機和背景資料。這將使沒有參與制定RTSP規範的讀者更容易理解RTSP中各部分爲什麼要以該方式來實現。
3 協議參數
3.1 RTSP版本
同[H3.1]定義，僅用RTSP代替HTTP即可。
如下：
RTSP採用主從（<major>.<minor>）數字形式來表示版本。協議的版本政策傾向於讓發
送方表明其消息的格式及功能，而不僅僅爲了獲得通訊的特性，這樣做的目的是爲了與更高
版本的RTSP實現通訊。只增加擴展域的值或增加了不影響通訊行爲的消息組件都不會導致
版本數據的變化。當協議消息的主要解析算法沒變，而消息語法及發送方的隱含功能增加了，
將會導致從版本號（<minor>）增加；當協議中消息的格式變化了，主版本號（<major>）也
將發生改變。
RTSP消息的版本由消息第一行中的RTSP版本域來表示。
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
注意，主從版本應當被看作單獨的整數，因爲它們都有可能增加，從而超過一位整
數。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。
版本號前面的0將被接收方忽略，而在發送方處也不應產生。
本文檔定義了RTSP協議的1.0版本。發送本規範定義的請求（Request）或迴應（Response）消息的應用必須指明RTSP的版本爲
“RTSP/1.0”。使用該版本號意味着發送消息的應用至少有條件的遵循本規範。
應用的RTSP版本即爲應用至少能有條件遵循的RTSP版本中的最高版本。
當代理及網關收到與其自身版本不同的RTSP請求時，必須小心處理請求的推送，因爲
協議版本表明發送方的能力，代理或網關不應發出高於自身版本的消息。如果收到高版本的
請求，代理或網關必須降低該請求的版本，並回應一個錯誤。而低版本的請求也應在被推送
前升級。代理或網關回應請求時必須和請求的版本相同。
3.2 RTSP URL
“rtsp”和“rtspu”表示要通過RTSP協議來定位網絡資源。本節詳細定義了RTSP URL的語法和語義。
rtsp_URL= ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host= <合法的Internet主機域名或IP地址(用十進制數及點組成), 見RFC1123，2.1節定義>
port= *DIGIT
abs_path 在 [H3.2.1]中定義如下：
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" |
"+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" |
">"
national = <any OCTET excluding ALPHA, DIGIT,
reserved, extra, safe, and unsafe>
權威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。
[注意]：段(fragment)和詢問(query)標識符在這時沒有明確的定義，需要到RTSP服務器上解釋。
rtsp要求使用可靠協議（Internet的TCP協議）發出命令，而rtspu則使用不可靠協議（Internet的UDP協議）。
如是端口爲空或沒指定，則缺省爲80端口。對於rtsp_URI來說，擁有被請求的
資源的服務器主機通過偵聽該端口的TCP連接(rtsp)或UDP包(rtspu)來接收該URI請求。
只要可能，應儘量避免的在URL中直接使用IP地址。（請參考RFC1924）
文本媒體標識符使用URL中的字符集及轉義規則（參考RFC1738）來標識一個表示(presentation)與單個流(stream)。URL可以
用於單個流或者多個流的集合，比如表示(presentation)。因此，在第十章所描述的請求(request)可以用於整個表示
(presentation)或表示中的單個流。注意，有些請求方法僅能用於流而不能用於表示，反之亦然。
例如：RTSP URL:
rtsp://media.example.com:554/twister/audiotrack
標識了twister表示(presentation)中，可以通過media.example.com554端口的TCP連接發送RTSP請求來控制的
音頻流。
也可以是這樣RTSP URL：
rtsp://media.example.com:554/twister
標識了由音頻和視頻流組成的twister表示(presentation)。
這並沒有給出URL中相關流的標準方法。表示描述定義了表示中的層次關係以及單獨流的URL。如一個表示描述可能將一個流命名爲a.mov，而將整個表示
命名爲b.mov。
RTSP URL的路徑組成對客戶端來說不可見並且也並沒有給出服務器的具體文件系統結構。
只需進行簡單替換後，表示描述同樣可以用於非RTSP媒體控制協議。
3.3 會議標識
會議標識採用URI標準編碼方法編碼，並對RTSP來說是不可見的。它們能包含任一八位位組值。必須保證會議標識在全局中的唯一性。在H.323中，將用
到會議的標識值。
conference-id = 1*xchar
會議標識允許RTSP會話從媒體服務器參與的多媒體會議中獲取參數。比如，可以要求媒體服務器用會議描述中的標識值來代替RTSP客戶端以提供詳細的傳輸
信息。多媒體會議的建立不屬於本協議內容，具體請參見H.323或SIP協議。
3.4 會話標識
會話標識符是不可見的任意長度的字符串。線性空格必須是URL-escaped。會話標識符必須隨機產生並且至少應有8個八位位組長以保證其難以被猜
出。（詳見16章）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相對時間戳
SMPTE相對時間戳表示相對於開始剪輯的時間。相對時間戳以SMPTE時間編碼形式表示而可以達到幀級量級的精度。時間編碼的格式爲：時：分：秒；幀.
子幀，並以剪輯開始爲起點。缺省的SMPTE格式爲“SMPTE 30 drop”格式，其幀速是29.97幀每秒。可通過選擇使用不同“SMPTE
time”來選擇其他SMPTE編碼格式（如“SMPTE
25”格式）。幀域的時間值在0到29之間。30幀每秒和29.97幀每秒的不同之處在於後者除每第十分鐘外的每分鐘都要丟掉頭兩個幀（00和01）。忽
略幀值爲0的幀，子幀以百分之一幀爲單位。
smpte-range= smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
; 還可以加入其他時間編碼
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
[ "." 1*2DIGIT ]
比如：
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
3.6正常播放時間
正常播放時間(NPT)指出了流相對於表示(presentation)開始時的絕對位置。時間戳由一個十進制小數組成，以秒爲單位，小數點左邊可以直接
以秒錶示或者以小時：分：秒的形式表示。
表示開始時對應0.0秒。負值沒有意義。特殊的常數now定義爲現場事件當前瞬間。它只能用於現場事件。
在DSM-CC中，正常播放時間（NPT）是這樣定義的：“直觀地講，NPT是用戶和程序聯繫的時鐘。它經常作爲數字顯示在VCR上。當處於普通播放模式
(scale =
1)時，NPT正常前進。當處於快進掃描模式時(scale率爲大於1的正數)，NPT快速前進。當處於反向掃描模式(scale率小於-1)時，NPT
快速後退。當處於暫停模式時，NPT停止。NPT（邏輯上）等同於SMPTE時間編碼。
npt-range= ( npt-time "-" [ npt-time ] ) | ( "-" npt-time )
npt-time = "now" | npt-sec | npt-hhmmss
npt-sec= 1*DIGIT [ "." *DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh = 1*DIGIT ; any positive number
npt-mm = 1*2DIGIT; 0-59
npt-ss = 1*2DIGIT; 0-59
比如：
npt=123.45-125
npt=12:05:35.3-
npt=now-
語法遵循ISO 8601規則。npt-sec標誌法便於自動產生，
ntp-hhmmss標誌法便於人工使用。“now”常數允許客戶端請求接收實時反饋而不是存儲或者延時的版本。因爲對於這種情況而言，既沒有絕對時間，
也沒有0時間，所以需要該參數。
3.7 絕對時間
絕對時間表示爲ISO 8601時間戳，使用UTC(GMT)小數法表示。
utc-range= "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT; < YYYYMMDD >
utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >
比如，1996年11月8日14點37分20.25秒UTC時間爲：
19961108T143720.25Z
3.8 選擇標籤
選擇標籤是用來指定RTSP新選擇的唯一標識符。這些標籤用於要求(Require)(12.32節)和代理要求(Proxy
Require)(12.27節)標題域中。
語法：
option-tag = 1*xchar
建立新的RTSP選擇可以通過在選擇前加入相反域名的前綴（如：對於能訪問到foo.com則com.foo.mynewfeature"
是個合適的名字）或者在英特網權威數字分派委員會註冊（IANA）新的選擇。
3.8.1 用IANA註冊新的選擇標籤
當註冊新RTSP選擇標籤的時候，應該提供以下信息：
Ø 選擇的名字和描述。名字長度不限，但是應該不少於20字符。名字不得包含任何空格，控制符或句點。
Ø
指出誰擁有選擇的改變控制權（例如，IETF，國際標準化組織，國際電信聯盟-T，其他的國際標準化體，一個團體，一個公司，或者一組公司）。
Ø 描述更爲詳細的參考文檔（如果有），比如，RFC，發表論文，專利文檔，技術報告，源代碼，或者計算機手冊。
Ø 選擇的所有權，以及聯繫地址（郵編及電子信件地址）。
4 RTSP消息
RTSP是基於文本的協議，採用ISO 10646
字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基於文本的協議使以自描述方式增加可選參數更容易。由於
參數的數量和命令的頻率出現較低，處理效率沒引起注意。如仔細研究，文本協議很容易以腳本語言（如：Tcl、Visual
Basic與Perl）實現研究原型。
10646字符集避免敏感字符集切換，但對應用來說不可見。RTCP也採用這種編碼方案。帶有重要意義位的ISO
8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協議攜帶。
請求包括方法、方法作用於其上的對象和進一步描述方法的參數。方法也可設計爲在服務器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度有
如下因素決定：
不管實體標題域是否出現在信息中，不包括信息體的的迴應信息總以標題域後第一和空行結束。
如出現內容長度標題域，其值以字節計，表示信息體長度。如未出現標題域，其值爲零。
服務器關閉連接。
注意：RTSP目前並不支持HTTP/1.1/"塊/"傳輸編碼，需要有內容長度頭。假如返回適度表示描述長度，即使動態產生，使塊傳輸編碼沒有必要，服
務器也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行爲合理。
從用戶到服務器端的請求信息在第一行內包括源採用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼，而沒有定義任何HTTP代碼。
4.1 消息類型
見[H4.1]。如下：
RTSP消息由客戶端到服務器的請求和由服務器到客戶端的迴應組成。
RTSP -message = Request | Response ; RTSP /1.0 messages
請求（Request）和迴應（Response）消息都使用RFC822中實體傳輸部分規定（作爲消息中的有效載荷）的消息格式。兩者的消息都可能包
括一起始行，一個或多個標題域（headers）、一行表示標題域結束的空行（即CRLF前沒有內容的行），和一個消息主體（message-body,
可選）。
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
爲了健壯性考慮，服務器應該忽略任何在期望收到請求行時收到的空行。換句話說，如果服務器正在讀協議流，在一個消息開始時如果首先收到了CRLF，這個
CRLF符應被忽略。
4.2 消息標題
見[H4.2]。
RTSP標題域，包括主標題（General-Header,4.3節）、請求標題（Request-Header ,5.2節）、
迴應標題（Response-Header ,6.2節）及實體標題（Entity-Header,7.1節），都遵照RFC822-3.1
節[7]給出的通用格式定義。每個標題域由後緊跟冒號的名字，單空格（SP），字符及域值組
成。域名是大小寫敏感的。雖然不提倡，標題域還是可以擴展成多行使用，只要這些行以一
個以上的SP或HT開頭就行。
RTSP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs make up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
標題域接收的順序並不重要，但良好的習慣是，先發送主標題，然後是請求標題或迴應
標題，最後是實體標題。
當且僅當標題域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同域名
的RTSP標題域纔可以表示在一個消息裏。而且必須能在不改變消息語法的前提下，將併發
的域值加到第一個值後面，之間用逗號分隔，最終能將多個標題域結合成“域名：域值”對。
4.3 消息主體
見[H4.3]。
RTSP消息的消息主體（如果有）用來攜帶請求或迴應的主體。僅在使用傳輸編碼(Transfer-Encoding)時消息主體和實體主體才有所不同，
這種情況在傳輸編碼標題域中有詳細說明。（見[H14.40]）
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
傳輸編碼必須能解釋所有保證傳輸安全和正確的應用程序的傳輸編碼。傳輸編碼是消息而不是實體的一個屬性，因此可以由任一應用程序隨着請求/迴應鏈添加或者
刪除。
什麼時候允許消息帶消息體的規則在請求和迴應兩種情況下有所不同。
在請求中有無消息主體的標誌是是否包含內容長度或請求消息標題域中的傳輸編碼標題域。只有當請求方法允許有實體主體的時候才能在請求中包含消息主體。
而對於迴應消息來說，無論消息中是否存在消息主體都與請求方法和迴應狀態編碼無關。所有迴應標題請求方法的消息都不能包含消息主體，儘管有時會因爲存在實
體標題域而使人產生誤解。所有1××（信息），204（無內容），304（未修改）迴應都不包含消息主體。而其他迴應則都包含主體，儘管其長度有可能長度
爲零。
4.4 消息長度
當消息包含消息主體時，消息主體的長度由以下規則來決定（按優先級高低順序排列）：
1.
任何迴應消息都不包含消息主體（如1××，204和304迴應），並且不管消息中是否存在實體標題域都以消息標題域後的第一行空行表示結束。
2. 如果內容長度標題域存在，它在字節中的值就是消息主體的長度。如果內容標題域不存在，則假設值爲零。
3. 服務器關閉連接時。（關閉連接沒有用來表明請求主體結束，否則可能導致服務器不能迴應。
注意，RTSP不支持（至少現在）HTTP/1.1的塊傳輸編碼（詳見[H3.6]）並且要求有內容長度標題域。
儘管表示描述長度動態產生，但由於可獲得了表示描述返回長度，使得服務器總是能決定表示描述長度而不需使用塊傳輸編碼方式。只要有實體主體就必須有內容
長度項，這些規則保證了即使沒有給出明確長度也能做出合理的操作。
5 普通標題域
有幾種標題域是請求與迴應都要使用的，但並不用於被傳輸的實體。這些標題只用於被
傳輸的消息。
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
普通標題域名稱只有在與協議版本的變化結合起來後，才能進行可靠的擴展。實際上，
新的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將
被視爲實體域。
6 請求
從客戶端到服務器端的請求消息包括，消息首行中，對資源的請求方法、資源的標識符
及使用的協議。
Request = Request-Line ; 6.1節
*( general-header ; 5章
| request-header ; 6.2節
| entity-header ) ; 8.1節
CRLF
[ message-body ] ; 4.3節
6.1 請求隊列
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" ; Section 10.2
| "ANNOUNCE" ; Section 10.3
| "GET_PARAMETER" ; Section 10.8
| "OPTIONS" ; Section 10.1
| "PAUSE" ; Section 10.6
| "PLAY" ; Section 10.5
| "RECORD" ; Section 10.11
| "REDIRECT" ; Section 10.10
| "SETUP" ; Section 10.4
| "SET_PARAMETER" ; Section 10.9
| "TEARDOWN" ; Section 10.7
| extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
6.2 請求標題域
request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3
| Authorization ; Section 12.5
| From ; Section 12.20
| If-Modified-Since ; Section 12.23
| Range ; Section 12.29
| Referer ; Section 12.30
| User-Agent ; Section 12.41
注意：相對於HTTP/1.1而言，RTSP請求要求絕對路徑（幷包括rtsp或rtspu方案，主機，端口號）。
HTTP/1.1 要求服務器理解絕對URL,
但是客戶端需要假設爲主機請求標題域。這樣做完全是爲了HTTP/1.0服務器端向後兼容性，因此RTSP並不需要這樣做。
在請求URI中星號“*”表示此請求不用於其他資源，只用於服務器本身，並且它只能在使用的方法不要求應用於資源時才能使用。
比如：OPTIONS * RTSP/1.0。
7 迴應
7.1 狀態行
完整迴應消息的第一行就是狀態行，它依次由協議版本、數字形式的狀態代碼、及相應
的詞語文本組成，各元素間以空格（SP）分隔，除了結尾的CRLF外，不允許出現單獨的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
7.1.1 狀態代碼和原因分析
狀態代碼（Status-Code）由3位數字組成，表示請求是否被理解或被滿足。原因分析是
用簡短的文字來描述狀態代碼產生的原因。狀態代碼用來支持自動操作，原因分析是爲人類
用戶準備的。客戶端不需要檢查或顯示原因分析。
狀態代碼的第一位數字定義了迴應的類別，後面兩位數字沒有具體分類。首位數字有5
種取值可能：
o 1xx:：保留，將來使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成請求必須進行進一步操作。
o 4xx：客戶端出錯 － 請求有語法錯誤或無法實現。
o 5xx：服務器端出錯 － 服務器無法實現合法的請求。
HTTP/1.0的狀態代碼、原因解釋在下面給出。下面的原因解釋只是建議採用，可任意
更改，而不會對協議造成影響。完整的代碼定義在第9節。
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created
| "250" ; Low on Storage Space
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood
| "452" ; Conference Not Found
| "453" ; Not Enough Bandwidth
| "454" ; Session Not Found
| "455" ; Method Not Valid in This State
| "456" ; Header Field Not Valid for Resource
| "457" ; Invalid Range
| "458" ; Parameter Is Read-Only
| "459" ; Aggregate operation not allowed
| "460" ; Only aggregate operation allowed
| "461" ; Unsupported transport
| "462" ; Destination unreachable
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; RTSP Version not supported
| "551" ; Option not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP狀態代碼是可擴展的，而只有上述代碼纔可以被當前全部的應用所識別。HTTP
應用不要求瞭解全部註冊的狀態代碼，當然，如果瞭解了更好。實際上，應用程序必須理解
任何一種狀態代碼，如果碰到不識別的情況，可根據其首位數字來判斷其類型並處理。另外，
不要緩存無法識別的迴應。
例如，如果客戶端收到一個無法識別的狀態碼431，可以安全地假定是請求出了問題，
可認爲迴應的狀態碼就是400。在這種情況下，用戶代理應當在迴應消息的實體中通知用戶，
因爲實體中可以包括一些人類可以識別的非正常狀態的描述信息。
Code reason
100 Continue all
200 OK all
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
551 Option not support all
Table 1: Status codes and their usage with RTSP methods
7.1.2 迴應標題域
迴應標題域中包括不能放在狀態行中的附加回應信息。該域還可以存放與服務器相關的
信息，以及在對請求URI所指定資源進行訪問的下一步信息。
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
迴應標題域名只有在與協議版本的變化結合起來後，才能進行可靠的擴展。實際上，新
的或實驗中的標題域只要能被通訊各方識別，其語法就可使用，而無法識別的標題域都將被
視爲實體域。
8 實體
如不受請求方法或迴應狀態編碼限制，請求和迴應消息可傳輸實體，實體由實體標題域和實體主體組成，有些迴應僅包括實體頭。
在此，根據誰發送實體、誰接收實體，發送者和接收者可分別指用戶和服務器。
8.1 實體標題域
實體標題定義實體主體可選元信息，如沒有實體主體，指請求標識的資源。
entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header
擴展頭機制允許定義附加實體標題域，而不用改變協議，但這些段不能假定接收者能識別。不可識別標題域應被接收者忽略，而讓代理轉發。
8.2 實體主體
見[H7.2]
與RTSP請求或迴應一起發送的實體主體的格式和編碼信息都在實體標題域
（Entity-Header）中定義。
Entity-Body = *OCTET
實體主體只在請求方法有要求時纔會被放在請求消息中。請求消息標題域處的內容長度
標題域（Content-Length header field）的標誌將指明請求中的實體主體是否存在。包含實體
主體的RTSP/1.0請求必須包含合法的內容長度標題域。
對迴應消息來說，消息中是否包含實體主體取決於請求方法和迴應代碼。所有的HEAD
請求方法的迴應都不應包括主體，即便是實體標題域中指明有主體也一樣。在主體中不應包
括這些迴應信息，全部1xx（信息）、204（無內容）和304（未修改）。而其它的迴應必須包
括實體主體或其內容長度標題（Content-Length header）域的定義值爲0。
9 連接
RTSP請求可以幾種不同方式傳送：
1、持久傳輸連接，用於多個請求/迴應傳輸。
2、每個請求/迴應傳輸一個連接。
3、無連接模式。
傳輸連接類型由RTSP URI來定義。對 /"rtsp/" 方案，需要持續連接；而/"rtspu/"方案，調用RTSP
請求發送，而不用建立連接。
不象HTTP，RTSP允許媒體服務器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否則媒體服務器沒有可靠途徑到達用戶，這也是請求通過防火牆從
媒體服務器傳到用戶的唯一途徑。
9.1 流水線操作
支持持久連接或無連接的客戶端可能給其請求排隊。服務器必須以收到請求的同樣順序發出迴應。
9.2 可靠性及確認
如果請求不是發送給組播組，接收者就確認請求，如沒有確認信息，發送者可在超過一個來回時間（RTT）後重發同一信息。
RTT在TCP中估計，初始值爲500 ms。應用緩存最後所測量的RTT，作爲將來連接的初始值。
如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴低層傳輸提供可靠性。
如兩個低層可靠傳輸（如TCP
和RTSP）應用重發請求，有可能每個包損失導致兩次重傳。由於傳輸棧在第一次嘗試到達接收着者前不會發送應用層重傳，接收者也不能充分利用應用層重傳。
如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。
時標頭用來避免重發模糊性問題，避免對圓錐算法的依賴。
每個請求在CSeq頭中攜帶一個系列號，每發送一個不同請求，它就加一。如由於沒有確認而重發請求，請求必須攜帶初始系列號。
實現RTSP的系統必須支持通過TCP傳輸RTSP
，並支持UDP。對UDP和TCP，RTSP服務器的缺省端口都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數據可與
RTP和RTCP包交叉。不象HTTP，RTSP信息必須包含一個內容長度頭，無論信息何時包含負載。否則，RTSP包以空行結束，後跟最後一個信息頭。
10 方法定義（ method token ）表示了對請求統一資源標誌符（ Request-URI ）識別的資源所執行的操作。方法名區分大小寫。將來 可能定義新的方法。方法名可能不以美元符 ' ＄ ' （十進制數 24 ）開頭，但必須具有表徵意義 (must be a token) 。
表格 2 是對方法的一個小結。
method direction object requirement
DESCRIBE C -> S P,S recommended
ANNOUNCE C -> S,S ->C P,S optional
GET PARAMETER C -> S,S ->C P,S optional
OPTIONS C -> S,S ->C P,S required(S ! C: optional)
PAUSE C -> S P,S recommended
PLAY C -> S P,S required
RECORD C -> S P,S optional
REDIRECT S ->C P,S optional
SETUP C -> S S required
SET PARAMETER C -> S,S ->C P,S optional
TEARDOWN C -> S P,S required
表 2 ：對 RTSP 方法，和其操作方向及所操作對象（ P: 表示 , S: 媒體流）的一個概覽
注意： PAUSE 方法是推薦的 , 但在構建一個全功能的服務器（ fully functional server ）
時可能不支持此方法，這時就不需要它，比如對於 live feeds 。如果服務器不支持某個特殊
方法，它必將返回 "501 Not Implemented" ，並且客戶端應該不再向該服務器請求該方法。
（注： Presentation 是一個以完整的 media feed 呈現給 client 的一個或多個媒體流的集合，
暫且翻譯成表示）
10.1 OPTIONS
其行爲與 [H9.2] 中描述的等同。 OPTIONS 請求可能在任何時候發出，例如客戶端將要發
出一個非標準的請求時。它不影響服務器狀態。
示例：
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
注意：這些都是必要的構造特徵 （ necessarily fictional features ） 。 ( 你可能不希望我
們去有意忽略那些實際上有用的特徵，因此在這一部分中我們將給出 一個詳細的例子 ) 。
10.2 DESCRIBE
DESCRIBE 方法從服務器檢索表示的描述或媒體對象，這些資源通 過請求統一資源定位符（ the request URL ）識別。此方法可能結合使用 Accept 首部域來指定客戶端理解的描述格式。服務器端用被請 求資源的描述對客戶端作出響應。 DESCRIBE 的答覆 - 響應對（ reply-response pair ）組成了 RTSP 的媒體初始化階段。
示例：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
[email protected] (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
DESCRIBE 響應必須包含它所描述資源的所有媒體初始化信息。如 果媒體客戶端從一個數據源獲得表示描述，而非通過 DESCRIBE ，並且該描述包含了一個媒體初始化參數的全集，那麼 客戶端就應該使用這些參數，而不是再通過 RTSP 請求相同媒體的描述。
再有，服務器不應該（ SHOULD NOT ）使用 DESCRIBE 響應作爲 media indirection 的方法。
需要建立基本的規則，使得客戶端有明確的方法瞭解何 時通過 DESCRIBE 請求媒體初始化信息，何時不請求。強制 DESCRIBE 響應包含它所描述媒體流集合的所有初始化信息，不鼓 勵將 DESCRIBE 用作 media indirection 的方法，通過這兩點避免了使用其他方法可能會引起的 循環問題（ looping problems ）
媒體初始化是任何基於 RTSP 系統的必要條件，但 RTSP 規範並沒有規定它必須通過 DESCRIBE 方法完成。 RTSP 客戶端可以通過 3 種方法來接收媒體初始化信息：
. DESCRIBE 方法；
. 其它一些協議（ HTTP ， email 附件，等）；
. 命令行或標準輸入（同一個 SDP 或其它媒體初始化格式的文件一起啓動，工作方式類似 於瀏覽器的幫助程序）。
爲了實際協同工作，嚴重（）推薦最精簡的服務器也支 持 DESCRIBE 方法，最精簡的客戶端也支持從標準輸入，命令行和 / 或其它對於客戶端操作環境合適的方法來接收媒體初始 化文件的能力。
10.3 ANNOUNCE
ANNOUNCE 方法有兩個用途：
當客戶端向服務器發送時， ANNOUNCE 將通過請求 URL 識別的表示描述或者媒體對象提交給服務器；
當服務器相客戶端發送時， ANNOUNCE 實時更新會話描述。
如果有新的媒體流加到表示中（比如在一個現場表示 中），整個表示描述應該重發；而不只是增加組件，如果這樣做的話，組件也可以被刪除了。
示例：
C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Content-Type: application/sdp
Content-Length: 332
v=0
o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
[email protected] (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
S->C: RTSP/1.0 200 OK
CSeq: 312
10.4 SETUP
SETUP 請求爲 URI 指定流式媒體的傳輸機制。客戶端能夠發出一個 SETUP 請求爲正在播放的媒體流改變傳輸參數，服務器可能同 意這些參數的改變。若是不同意，它必須響應錯誤 "455 Method Not Valid In This State" 。 爲了儘量繞開防火牆干涉，即使它不會影響參數，客戶 端也必須指出傳輸參數，例如，指出服務器向外發佈的固定的廣播地址。
由於 SETUP 包括了所有傳輸初始化信息，防火牆和其他中間的網絡 設備（它們需要這些信息）分讓瞭解析 DESCRIBE 響應的繁瑣任務，這些任務留給了媒體初始化。
Transport 首部域指定了客戶端數據傳輸時可接受的傳輸參數；響 應包含了由服務器選出的傳輸參數。
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
作爲對 SETUP 請求的響應，服務器產生了會話標誌符。如果對服務器 的請求中包含了會話標誌符，服務器必須將此 setup 請求捆綁到一個存在的會話，或者返回 "459 Aggregate Operation Not Allowed" 。
10.5 PLAY
PLAY 方法告知服務器通過 SETUP 中指定的機制開始發送數據 。在尚未收到 SETUP 請求的成功應答之前，客戶端不可以發出 PLAY 請求。 PLAY 請求將正常播放時間（ normal play time ）定位到指定範圍的起始處，並且傳輸數據流直到播放 範圍結束。 PLAY 請求可能被管道化（ pipelined ），即放入隊列中（ queued ）；服務器必須將 PLAY 請求放到隊列中有序執行。也就是說，後一個 PLAY 請求需要等待前一個 PLAY 請求完成才能得到執行。
比如，在下例中，不管到達的兩個 PLAY 請求之間有多緊湊，服務器首先 play 第 10 到 15 秒，然後立即第 20 到 25 秒，最後是第 30 秒直到結束。
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
結合 PAUSE 請求的描述，看更深一層的示例。
不含 Range 首部域的 PLAY 請求也是合法的。它從媒體流開頭開始播放，直到媒體 流被暫停。如果媒體流通過 PAUSE 暫停，媒體流傳輸將在暫停點（ the pause point ）重新開始。
如果媒體流正在播放，那麼這樣一個 PLAY 請求將不起更多的作用，只是客戶端可以用此來測試服 務器是否存活。
Range 首部域可能包含一個時間參數。該參數以 UTC 格式指定了播放（ palayback ）開始的時間。如果在這個指定時間後收到消息，那麼 播放立即開始。時間參數可能用來幫助同步從不同數據源獲取的數據流。
對於一個點播（ On-demand ）媒體流，服務器用播放（ play back ）的實際範圍答覆請求。 This
may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source . 如果在請求中沒有指定範圍，當前位置將在答覆中返 回。答覆中播放範圍的單位與請求中相同。在播放完被要求的範圍後，表示將自動暫停，就好像發出了一個 PAUSE 請求。
下面的示例在 play 整個表示時從 SMPTE 時間 0:10:20 直到剪輯（ clip ）結束。播放開始於 1997 年 1 月 23 號， 15 點 36 分
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z
S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
For playing back a recording of a live presentation, it may be desirable to use clock
units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
CSeq: 835
Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT
只有播放的媒體服務器必須支持 npt 時間格式，可能支持 clock 和 smpte 格式。
10.6 PAUSE
PAUSE 請求引起媒體流傳輸的暫時中斷。如果請求 URL 中指定了具體的媒體流，那麼只有該媒體流的播放和記 錄被暫停（ halt ）。比如，指定暫停音頻，播放將會無聲。如果請求 URL 指定了一個表示或者媒體流已成組，那麼在該表示或組 中的所有當前活動流的傳輸將被暫停。在重啓播放或記錄後，必須維護不同媒體軌跡（ track ）的同步。儘管服務器可能在暫停後，在 timeout 的時間內關閉會話，釋放資源，但是任何資源都必須保 存，其中 timeout 參數位於 SETUP 消息的會話頭中。
示例：
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
PAUSE 請求中可能包含一個 Range 首部域用來指定何時媒體流或表示暫停，我們稱這個時 刻爲暫停點（ pause point ）。該首部域必須包含一個精確的值，而不是一個時間 範圍。媒體流的正常播放時間設置成暫停點。當服務器遇到在任何當前掛起（ pending ）的 PLAY 請求中指定的時間點後，暫停請求生效。如果 Range 首部域指定了一個時間超出了任何一個當前掛起的 PLAY 請求，將返回錯誤 "457 Invalid Range" 。如果一個媒體單元（比如一個音頻或視頻禎）正好在 一個暫停點開始，那麼表示將不會被播放或記錄。如果 Range 首部域缺失，那麼在收到暫停消息後媒體流傳輸立即中 斷，並且暫停點設置成當前正常播放時間。
利用 PAUSE 請求可忽視所有排隊的 PLAY 請求，但必須維護媒體流中的暫停點。不帶 Range 首部域的後繼 PLAY 請求從暫停點重啓播放。
比如，如果服務器有兩個掛起的播放請求，播放範圍（ range ）分別是 10 到 15 和 20 到 29 ，這時收到一個暫停請求，暫停點是 NPT21 ，那麼它將會開始播放第二個範圍，並且在 NPT21 處停止。如果服務器正在服務第一個請求播放到 NPT13 位置，收到暫停請求，暫停點 NPT12 ，那麼它將立即停止。如果請求在 NPT16 暫停，那麼服務器在完成第一個播放請求後停止，放棄 了第二個播放請求。
再如，服務器收到播放請求，播放範圍從 10 到 15 和 13 到 20 （即之間有重疊）， PAUSE 暫停點是 NPT14 ，則當服務器播放第一段範圍時， PAUSE 請求將生效，而第二個 PLAY 請求會被忽略重疊部分，就好像服務器在開始播放第二 段前收到 PAUSE 請求。不管 PAUSE 請求何時到達，它總是設置 NPT 到 14 。
如果服務器已經在 Range 首部域指定的時間外發送了數據，後繼的 PLAY 仍會在暫停點及時重啓，因爲它認爲客戶端會丟棄在暫 停點後收到的數據。這就確保了連續、無隙的暫停 / 播放循環。
10.7 TEARDOWN
TEARDOWN 請求終止了給定 URI 的媒體流傳輸，並釋放了與該媒體流相關的資源。如果 該 URI 是對此表示的表示 URI ，那麼任何與此會話相關的任何 RTSP 會話標誌符將不再有效。除非所有傳輸參數由會話描述 符定義，否則 SETUP 請求必須在會話能被再次播放之前發出。
示例：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
10.8 GET PARAMETER
GET PARAMETER 請求檢索 URI 指定的表示或媒體流的參數值。答覆和響應的內容留給 了實現。不帶實體主體的 GET PARAMETER 可用來測試客戶端或服務器是否存活（ "Ping" ）。
示例：
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
packets_received
jitter
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
"text/parameters" 段只是參數類型的一個例子。對此方法有意的進行了鬆 散的定義，對於答覆和響應的內容將在更深一層的實驗中給出定義。
10.9 SET PARAMETER
此方法給 URI 指定的表示或媒體流設置參數值。
幫助客戶端檢查某個特殊的請求爲何失敗的請求（暈 ~ ）應該只附帶一個參數。當請求附帶
多個參數時，服務器只有在這些參數全都設置正確時才作出響應。服 務器必須允許某個參數被
重複設置成相同的值，但可能不允許改變參數值。
注意：必須只能使用 SETUP 命令來給媒體流設置傳輸參數。 限制只有 SETUP 能設置傳輸參數有利於防火牆設計。
示例：
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
"text/parameters" 段只是參數類型的一個例子。對此方法有意的進行了鬆 散的定義，對於答覆和響應的內容將在更深一層的實驗中給出定義。
10.10 REDIRECT
REDIRECT 請求告知客戶端連接到另一個服務器位置。它包含首部 域 Location ，該域指出了客戶端應該發出請求的 URL 。它可能包含參數 Range ，在重定向生效時，該域指明瞭媒體流的範圍。如果客 戶端希望繼續發送或接收其 URI 指定的媒體，它必須發出一個 TEARDOWN 請求來關閉當前會話，並向委派的主機發送 SETUP 以建立新的會話。
本例中，在給定的播放時間將 URI 請求重定向到新的服務器：
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
10.11 RECORD
此方法根據表示描述開始記錄媒體數據。時間戳（ timestamp ）表現了起始和結束時間（ UTC ）。
如果沒有給定時間範圍，就使用表示描述中提供的開始和結束時間。 如果會話已經開啓，立即開始記錄。由服務器來決定是否存儲記錄的數據到請求 URI 下或者其它 URI 下。如果服務器沒有使用請求 URI ，那麼響應代碼應該是 201 （創建），並且包含一個實體，該實體描述了請求的狀 態，並通過 Location 首部域指向新資源。
允許記錄現場表示（ live presentations ）的媒體服務器必須支持時鐘範圍格式（ the clock
range format ）， smpte 格式對此無用。
在本示例中，媒體服務器被邀請到指定的會議
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
10.12 Embedded (Interleaved) Binary Data
可能某些防火牆設計和環境會強制服務器交叉 RTSP 方法和媒體流數據。這種交叉增加了客戶端和服務器操 作的複雜性，帶來了額外的開銷，因此通常情況下應該避免；除非必須交叉。只有 RTSP 在 TCP 上運載時，交叉的二進制數據才能使用。
媒體流數據，如 RTP 包，被封裝成下列形式： ASCII 的美元符（十進制數 24 ），一個字節的通道標誌符（ channel identifier ），被封裝的二進制數據的長度，以網絡字節順序編碼 的 2 字節
整數。緊接着的是上層的協議頭。每個＄塊都正確地包含了一個上層 協議數據單元，比如一個 RTP 包。
通道標誌符使用交叉參數定義在傳輸頭。
當使用實時傳輸協議傳輸時， RTP 和 RTCP 消息也會在 TCP 連接上相互交叉。默認情況下， RTCP 包會在第一個可用的通道上發送，高於 RTP 通道。而客戶端可能在另一個通道顯式地請求 RTCP 包。在傳輸頭的交叉參數中指定兩個通道可解決此問 題。
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S->C: $/000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $/000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $/001{2 byte length}{"length " bytes RTCP packet}