轉自：http://blog.csdn.net/arau_sh/article/details/2982914

E-mail：bryanj@163.com
譯者： Bryan.Wong（王晶，寧夏固原）
譯文版本：alpha 0.80
譯文發布時間：2007-7-25
版權：本中文翻譯文檔之版權歸王晶所有。可于非商業用途前提下自由轉載，但必須保留此翻譯及版權信息。

網絡工作組 H.Schulzrinne
請求注釋:2326 哥倫比亞大學.
類別: 標準跟蹤 A.Rao
Netscape
R.Lanphier
RealNetworks
1998年4月

實時流協議(RTSP)

本備忘錄狀態
本文為Internet社區描述了一種Internet標準跟蹤協議 ，還需要討論和建議以便進行改善。請查看最新版本的”Internet正式協議標準”（STD 1）了解本協議的標準化進程和狀態。本備忘錄的傳播不受限制。

版權聲明：
版權為The Internet Society 所有。所有權利保留。

摘要：
實時流協議（RTSP）是應用層協議，控制實時數據的傳送 。RTSP提供了一個可擴展框架，使受控、按需傳輸實時數據（如音頻與視頻）成為可能。數據源包括現場數據與存儲在剪輯中的數據。本協議旨在于控制多個數據發送會話，提供了一種選擇傳送途徑（如UDP、組播UDP與TCP）的方法，并提供了一種選擇基于RTP (RFC1889)的傳送機制的方法。

目錄：
1 介紹
1.1 目的
1.2 要求
1.3 術語
1.4 協議特性
1.5 RTSP擴展
1.6 整體運作
1.7 RTSP狀態
1.8 與其他協議的關系
2 符號協定
3 協議參數
3.1 RTSP版本
3.2 RTSP URL
3.3 會議標識
3.4 會話標識
3.5 SMPTE 相對時間戳
3.6正常播放時間
3.7 絕對時間
3.8 選項標簽
3.8.1 用IANA注冊新的選項標簽
*4 RTSP消息
4.1 消息類型
4.2 消息頭
4.3 消息主體
4.4 消息長度
*5 普通頭部段
*6 請求
6.1 請求行
6.2 請求消息頭段
*7 響應
7.1 狀態行
7.1.1 狀態碼和原因短語
7.1.2 響應頭部段
*8 實體
8.1 實體頭部域
8.2 實體主體 24
*9 連接
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狀態碼定義 29
11.1成功2xx 30
11.1.1 存儲空間低 250 30
11.2 重定向3xx 31
11.3 客戶端錯誤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 頭部段定義（HeaderField 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 命令序列題頭（CSeq） 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 倍速（Scale）
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 安全考慮（SecurityConsiderations） 52
*附錄A RTSP協議狀態機 53
*A.1 客戶端狀態機 53
*A.2 服務器端狀態機 53
*附錄B 與RTP協議的交互 53
*附錄C 使用SDP進行RTSP會話描述 54
+C.1 定義 54
o C.1.1 控制URL 55
o C.1.2 媒體流 55
o C.1.3 有效載荷類型 55
o C.1.4 詳細格式參數 55
o C.1.5 表示的范圍 56
o C.1.6 有效時間 56
o C.1.7 連接信息 56
o C.1.8 實體標簽 57
+C.2 合控制不可用 57
+C.3 合控制可用 57
*附錄D 最小RTSP實現 58
+D.1 客戶端 58
D.1.1基本回放 58
D.1.2 認證enabled 58
+D.2 服務器 59
D.2.1基本回放 59
D.2.2認證enabled 59
*附錄E 作者地址 60
*附錄F 致謝 60
*參考書目 60
*版權申明 61

1 介紹
1.1 目的
實時流協議（RTSP）建立并控制一個或幾個時間同步的連續流媒體，比如音頻或視頻。盡管在連續媒體流中有可能插入控制流（見10.12節），但RTSP本身通常并不發送連續媒體流。換言之，RTSP充當多媒體服務器的”網絡遙控器”。
表示描述定義了流的控制操作的集合，但本文并沒有規定表示描述的格式。
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 [4]中的解釋一致。
1.3 術語
一些HTTP/1.1的術語被采用。這里沒有舉出的術語，其定義與HTTP/1.1相同。
合控制：
服務器使用一條時間線對多個流進行控制。對音頻/視頻的回放來講，這意味著客戶端僅需發送一條播放或者暫停消息就可同時控制音頻和視頻的回放。
會議：
多方參與的多媒體表示，這里的多方意味著大于或等于一方。
客戶端：
指請求媒體服務器上連續流媒體數據的客戶端。
連接：
以通訊為目的，在傳輸層建立的兩個程序間的虛擬信道。
容器文件：
可以容納多個媒體流的文件，而這些媒體流共同播放時通常還包含一個表示。RTSP服務器可以為這些容器文件提供合控制，但容器文件的概念本身并不包含在本協議中。
連續媒體：
接受器和數據源之間存在時序關系的數據。也就是說，接受器需要重放原來存在于源數據中的時序關系。最普通的連續媒體的例子是音頻和動畫視頻。連續媒體可以是實時的（交互的），它們在源和接受器之間是一種緊密的時序關系；或者是流（回放）的形式，時序關系沒那么嚴格。
實體：
請求或者響應的載荷部分中所傳輸的信息。實體由信息元組成，而每個信息元由由實體頭部域和實體主體組成。實體頭部域內是信息格式，實體主體內是信息內容，如第8章所述。
媒體初始化：
數據類型/編碼的具體初始化。這包括時鐘頻率，顏色空間等。客戶端請求一個媒體流回放時所需的任何獨立于傳輸的信息，都是在流創建時媒體初始化階段產生的。
媒體參數:
對于某種特定的媒體類型來說，回放前或者回放中有可能會發生改變的一些參數。
媒體服務器：
提供一個或多個媒體流之回放或錄制服務的服務器。同一個表示(presentation)中不同的媒體流可能來自于不同的媒體服務器。媒體服務器可以建在激活該表示(presentation)的Web服務器上，也可以建立在不同的主機上。
媒體服務器重定向：
重新把媒體客戶端定向到另外一個媒體服務器。
(媒體)流：
單個媒體實例，比如，一個音頻流或者一個視頻流，連同一個白板或者共享程序組。當使用RTP時，流包括由RTP會話(session)中同一個源所創建的所有RTP和RTCP包。這和DSM-CC流([5])的定義相同。
消息：
RTSP通訊的基本單元。由15章語法定義的結構化八位位組序列組成，并通過有連接或者無連接協議傳送。
參與者：
一個會議的成員。參與者可以是機器，比如是媒體記錄或回放服務器。
表示(presentation)：
作為一個完整的媒體信息，回饋性地表述給客戶端的一個或多個流的集合。表示使用下面的表示描述進行表述。大部分情況下，在RTSP中的文字部分中，這暗示集合中的流的合控制，但并非必須。
表示描述(presentationdescription)：
表示描述包含在表示(presentation)中一個或者多個媒體流的信息。比如，編碼，網絡地址和內容的信息，的集合。另外，其他IETF協議，如SDP協議使用術語”會話(session)”代替”現場表示”。表示描述可以采用包括會話描述(session description)SDP在內的多種格式。
響應：
RTSP響應。如果能理解HTTP響應，就能清楚地理解RTSP響應。
請求：
RTSP請求。如果能理解HTTP請求，就能清楚地理解RTSP請求。
RTSP會話(session)：
包括一次RTSP”事務”（transaction）的全過程。比如，一個電影的觀看過程。會話(session)一般包括由客戶端為連續媒體建立傳輸機制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關閉流。
傳輸初始化：
客戶端和服務器端之間關于傳輸所需的相關信息（端口號，傳輸協議等）的協商。
1.4 協議特點
RTSP有以下特性：
易于擴展：
可以很容易地向RTSP加入新方法和參數。
易解析：
RTSP可由標準HTTP或MIME解析器解析。
安全：
RTSP重用 了網頁安全機制。所有HTTP授權機構如basic (RFC 2068 [2, Section11.1])和digest (RFC2069 [8])授權都可直接使用。也可以重用傳輸層或網絡層安全機制。
獨立于傳輸：
RTSP即可使用不可靠數據報協議（UDP）、可靠數據報協議（RDP），如要實現應用級可靠，也可使用可靠流協議如TCP。
多服務器支持：
表示(presentation)中的每個流可放在不同服務器上，客戶端自動同不同服務器建立幾個并發控制的會話，媒體同步在傳輸層執行。
錄制設備控制：
協議可控制記錄和回放設備，以及可在兩種模式之間切換的設備（VCR）。
流控制與會議初始化分離：
流控制與邀請媒體服務器入會相分離；僅要求會議初始化協議可提供，或可用來創建具有唯一性的會議標識號。具體地說， SIP或H.323 可用來邀請服務器入會。
適合專業應用：
通過SMPTE 時標，RTSP支持幀級別精度，以支持遠程數字編輯。
適合專業應用：
RTSP依賴SMPTE時間戳支持幀級精度，使得可以進行遠程數字編輯。
表示描述中立：
協議沒強行指定特定的表示或元文件格式，可傳達所用的格式類型；然而，表示描述必須至少包含一個RTSP URI。
代理與防火墻友好：
協議需由應用層協同傳輸層(SOCKS [14])防火墻友好地進行處理。防火墻需要理解SETUP方法，以為UDP媒體流打開一個”洞口”。
HTTP友好：
此處，RTSP明智地重用了HTTP概念，使現有的基礎結構可被重用。這些基礎結構包括Internet 內容選擇平臺（PICS：Platform for Internet ContentSelection [15,16]），以便通過相關標簽訪問內容。但由于在大多數情況下，控制連續媒體需要服務器狀態 ， RTSP不僅僅向HTTP 添加方法。
合適的服務器控制：
若客戶端能啟動一個流，它必須也能停止一個流。服務器不能啟動一個用戶不能停止的流。
傳輸協商：
實際處理連續媒體流前，客戶端可協商傳輸方法。
性能協商：
若基礎特性被禁用，必須有某種明確的機制讓用戶決定哪種方法將不不被實現。這允許用戶提出適合的用戶界面。例如，如果不允許尋找，用戶界面必須能禁止位置條滑動。
早期曾要求RTSP支持多用戶，但現在有了更好的方案，就是保證RTSP能很容易擴展成支持多用戶即可。因為流的標志可以被多個控制流使用，因此可以”輪換持有控制器”。協議不涉及到多個客戶端如何協調入口–這項任務被留給”社會協議”或其他層。
1.5 擴展RTSP
由于不是所有媒體服務器有著相同的功能，媒體服務器有必要支持不同的請求集。例如：
服務器可能只能回放，因此不必支持錄制請求。
用于提供現場直播的服務器可能不支持尋找（絕對位置）功能。
一些服務器可能不支持設置流參數，因此不支持GET_PARAMETER和SET_PARAMETER請求。
但服務器應該實現所有12章中要求的標題域。
表示描述(presentationdescription)應當保證不提出服務器不支持的功能，這種情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服務器都支持的情形一致。
RTSP 可以如下三種方式擴展，按所支持的改變多少排序：
*已有的方法可以擴展加入新參數，只要這些參數可以被接收方安全地忽略。（這和給一種HTML tag增加新標簽是一樣的）如果客戶端在請求失敗時需要一個拒絕確認，需要在請求：字段(見Section12.32)中加入一個對應于該擴展的標簽。
*可以加入新方法。如果接收方不理解請求，它就返回一個501錯誤碼（意指未實現），發送方就不應再嘗試這種方法。客戶端可以用OPTIONS方法去詢問服務器支持的方法。服務器應該在公共回應頭里列出它所支持的所有方法。
*可以定義新版本的協議，以支持幾乎所有方面的改變（除了版本協議號的位置）。
1.6 整體運作
每個表示和媒體流可用RTSP URL識別。表示組成的整個表示與媒體屬性由表示描述(presentation description)文件定義，其格式不在本協議中定義。客戶端可以通過HTTP或其它途徑（如email）獲得此表示描述文件，它沒有必要保存在媒體服務器上。
根據此規范的目標，我們假想一個表示描述(presentation description)描述了多個表示(presentation)，每個表示(presentation)維持一個統一的時間軸。為簡明但不失一般性，假定表示描述(presentation description)正好包含一個這樣的表示(presentation)。表示(presentation)可包含多個媒體流。
表示描述(presentation description)包含組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數。在表示描述中，各個由RTSP分別控制的媒體流各有一個RTSPURL。RTSP URL指出了處理具體媒體流的服務器以及存在于該服務器上流的名字。多個媒體流可以放到不同的服務器上，比如音頻和視頻流可以分別放到不同服務器而實現均分負載。描述（description)還列出了服務器可使用的傳輸方法。
除媒體參數外，網絡目標地址和端口也需要決定。下面區分幾種操作模式：
單播：
以用戶選擇的端口號將媒體發送到RTSP請求的來源處。另一種選擇是，用和RTSP相同的可靠流傳輸媒體 。
多播，服務器選擇地址：
媒體服務器選擇多播地址和端口，這是現場直播或準點播常用的方式。
多播，用戶選擇地址：
若服務器要加入正在進行的多播會議，多播地址、端口和密匙由會議描述給出。會議描述的建立不在此規范中討論。
1.7 RTSP狀態
RTSP控制通過與控制通道無關的獨立協議發送的流。例如，RTSP控制可能是使用TCP連接，而數據流使用UDP。因此，即使媒體服務器沒有收到請求，數據也會繼續發送。在會話生命期，單個媒體流可通過不同TCP連接按順序發出的請求來控制。所以，服務器需要維護”會話狀態”以便使RTSP請求和流相互關聯。狀態之間的轉換在附錄A中描述。
RTSP中很多方法與狀態無關，但下列方法在服務器流資源的定位和應用上起著重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.
SETUP：
讓服務器給流分配資源，啟動RTSP會話。
PLAY與RECORD：
啟動SETUP所分配的流的數據傳輸。
PAUSE：
臨時暫停流，而不釋放服務器資源。
TEARDOWN：
釋放流占用的資源，RTSP會話停止，從服務器端退出。
與狀態相關的RTSP方法使用會話頭部域（Sessionheader field (Section 12.37)）來識別哪個RTSP會話的狀態需要處理，在SETUP請求(章節10.4)的響應中，服務器生成會話標識。
1.8 與其他協議關系
RTSP在功能上與HTTP有重疊。它也可能與HTTP相互作用，體現在與流內容的初始接觸是通過網頁的。目前的協議規范目的在于允許網頁服務器與RTSP媒體服務器之間有多種接力點。例如，表示描述(presentation description)可通過HTTP和RTSP得到，這降低了基于瀏覽器的應用模式的往返傳遞，也允許完全不依賴HTTP的獨立RTSP 服務器與客戶端。
但是，RTSP與HTTP 的本質差別在于數據發送以信帶外的不同協議 進行。HTTP是不對稱協議，用戶發送請求，服務器作出響應。RTSP中，媒體用戶和服務器都可發送請求。RTSP請求也不是無狀態 的；在請求確認后很長時間后，仍可設置參數，繼續控制媒體流。
重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權上采用HTTP功能是有價值的。
雖然大多數實時媒體使用RTP作為傳輸層協議，RTSP并沒有綁定到RTP。
RTSP假設存在可表示包含幾個媒體流的表示的靜態與臨時屬性的表示描述格式。
2 符號約定
既然很多定義和語法與HTTP/1.1中相同，這里僅指出它們在HTTP/1.1中定義的位置而并沒有拷貝它們到本文檔。為簡便起見，本文檔中[ HX.Y ]表示對應HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[譯者注：]為更方便學習RTSP，本翻譯文檔將相關段落完全譯出）
與[H2.1]類似，本文對所有機制的說明都是以增廣BNF的形式來描述的。此形式在RFC 2234中有詳細的描述，唯一的不同是RTSP中以”1#”代替”,”為分隔符。

---

簡單說明增廣BNF如下： 增廣BNF（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）
在元素前加星號”“表示循環，其完整形式是”元素”，表明元素最少產生次，最多次。缺省值是0到無限，例如，”1*元素”意思是至少有一個，而”1*2元素”表明允許有1個或2個。
［規則］（[rule]）
方括號內是可選元素。如”［元素1 元素2］”與”*1（元素1 元素2）”是一回事。
N 規則（N rule）
表明循環的次數：”（元素）”就是”*（元素）”，也就是精確指出取值。因而，2DIGIT 就是2位數字, 3ALPHA 就是由三個字母組成字符串。
＃規則（#rule）
“#”與”*”類似，用于定義元素列表。
完整形式是”#元素”表示至少有個至多有個元素，中間用”,”或任意數量的空格（LWS）來分隔，這將使列表非常方便，如”（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即可。

---

[H3.1]：
RTSP采用主從（.）數字形式來表示版本。協議的版本政策傾向于讓發送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高版本的RTSP實現 通訊。只增加擴展域的值或增加了不影響通訊行為的消息組件都不會導致版本數據的變化。當協議消息的主要解析算法沒變，而消息語法及發送方的隱含功能增加了，將會導致從版本號（）增加；當協議中消息的格式變化了，主版本號（）也將發生改變。
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]中定義。

---

[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 =

總結

以上是生活随笔為你收集整理的RTSP协议-中文定义的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。