轉(zhuǎn)自：http://blog.csdn.net/arau_sh/article/details/2982914

E-mail：bryanj@163.com
譯者： Bryan.Wong（王晶，寧夏固原）
譯文版本：alpha 0.80
譯文發(fā)布時間：2007-7-25
版權(quán)：本中文翻譯文檔之版權(quán)歸王晶所有?？捎诜巧虡I(yè)用途前提下自由轉(zhuǎn)載，但必須保留此翻譯及版權(quán)信息。

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

實時流協(xié)議(RTSP)

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

版權(quán)聲明：
版權(quán)為The Internet Society 所有。所有權(quán)利保留。

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

目錄：
1 介紹
1.1 目的
1.2 要求
1.3 術(shù)語
1.4 協(xié)議特性
1.5 RTSP擴展
1.6 整體運作
1.7 RTSP狀態(tài)
1.8 與其他協(xié)議的關(guān)系
2 符號協(xié)定
3 協(xié)議參數(shù)
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 狀態(tài)行
7.1.1 狀態(tài)碼和原因短語
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 獲取參數(shù) 28
10.9 設置參數(shù) 28
10.10 重定向 28
10.11 錄制 29
10.12 嵌入（交織）的二進制數(shù)據(jù) 29
*11狀態(tài)碼定義 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無法理解參數(shù) 32
11.3.3會議未找到 33
11.3.4 帶寬不足 33
11.3.5 會話未找到 34
11.3.6 本狀態(tài)下該方法無效 34
11.3.7 頭部域與資源不匹配 34
11.3.8 無效范圍 35
11.3.9 參數(shù)為只讀 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 授權(quán)（Authorization） 40
12.6 帶寬 40
12.7 塊大小 40
12.8 緩存控制 41
12.9 會議 41
12.10 連接 41
12.11 內(nèi)容-基礎(chǔ) 42
12.12 內(nèi)容-編碼（Content-Encoding） 42
12.13 內(nèi)容-語言 43
12.14 內(nèi)容-長度（Content-Length） 43
12.15 內(nèi)容-位置 43
12.16 內(nèi)容-類型（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協(xié)議狀態(tài)機 53
*A.1 客戶端狀態(tài)機 53
*A.2 服務器端狀態(tài)機 53
*附錄B 與RTP協(xié)議的交互 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 詳細格式參數(shù) 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實現(xiàn) 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
*版權(quán)申明 61

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

---

簡單說明增廣BNF如下： 增廣BNF（augmented BNF）包括下面的結(jié)構(gòu)： 要解釋的名詞＝名詞解釋（name= definition） 規(guī)則的名字（name）就是它本身（不帶任何尖括號，"<"，">"），后面跟個等號＝，然后就是該規(guī)則的定義。如果規(guī)則需要用多個行來描述，利用空格進行縮進格式排版。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義中還可以使用尖括號來幫助理解規(guī)則名的使用。 字面意思（"literal"） 文字的字面意思放在引號中間，若無特別指定，則該段文字是大小寫敏感的。

規(guī)則1｜規(guī)則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，”是｜否”要選擇‘是’或‘否’。
（規(guī)則1 規(guī)則2）（(rule1 rule2)）
在圓括號中的元素表明必然出現(xiàn)。如（元素1（元素2｜元素3）元素4）可表明兩種意思，即”元素1 元素2 元素4”和”元素1 元素3 元素4”
*規(guī)則（*rule）
在元素前加星號”“表示循環(huán)，其完整形式是”元素”，表明元素最少產(chǎn)生次，最多次。缺省值是0到無限，例如，”1*元素”意思是至少有一個，而”1*2元素”表明允許有1個或2個。
［規(guī)則］（[rule]）
方括號內(nèi)是可選元素。如”［元素1 元素2］”與”*1（元素1 元素2）”是一回事。
N 規(guī)則（N rule）
表明循環(huán)的次數(shù)：”（元素）”就是”*（元素）”，也就是精確指出取值。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個字母組成字符串。
＃規(guī)則（#rule）
“#”與”*”類似，用于定義元素列表。
完整形式是”#元素”表示至少有個至多有個元素，中間用”,”或任意數(shù)量的空格（LWS）來分隔，這將使列表非常方便，如”（LWS 元素 （ *LWS”,” *LWS 元素 ））”就等同于”1#元素”。
空元素在結(jié)構(gòu)中可被任意使用，但不參與元素個數(shù)的計數(shù)。也就是說，”（元素1），，（元素2）”僅表示2個元素。但在結(jié)構(gòu)中，應至少有一個非空的元素存在。缺省值是0到無限，即”#（元素）”表示可取任何數(shù)值，包括0；而”1#元素”表示至少有1個；而”1#2元素”表示有1個或2個。
；注釋（; comment）
分號后面是注釋，僅在單行使用。
隱含*LWS（implied *LWS）
本文的語法描述是基于單詞的。除非另有指定，否則線性空格（LWS）可以在兩個鄰近符號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之間必須有至少一個分隔符，因為它們也要做為單獨的符號來解釋。實際上，應用程序在產(chǎn)生HTTP結(jié)構(gòu)時，應當試圖遵照”通常方式”，因為現(xiàn)在的確有些實現(xiàn)方式在通常方式下無法正常工作。

---

在本備忘錄中，我們用縮進的小型段落來提供背景和動機。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來實現(xiàn)。

3 協(xié)議參數(shù)
3.1 RTSP版本
同[H3.1]定義，僅用RTSP代替HTTP即可。

---

[H3.1]：
RTSP采用主從（.）數(shù)字形式來表示版本。協(xié)議的版本政策傾向于讓發(fā)送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高版本的RTSP實現(xiàn) 通訊。只增加擴展域的值或增加了不影響通訊行為的消息組件都不會導致版本數(shù)據(jù)的變化。當協(xié)議消息的主要解析算法沒變，而消息語法及發(fā)送方的隱含功能增加了，將會導致從版本號（）增加；當協(xié)議中消息的格式變化了，主版本號（）也將發(fā)生改變。
RTSP消息的版本由消息第一行中的RTSP版本域來表示。
RTSP-Version = “RTSP” “/” 1*DIGIT “.”1*DIGIT
注意，主從版本應當被看作單獨的整數(shù)，因為它們都有可能增加，從而超過一位整數(shù)。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。
版本號前面的0將被接收方忽略，而在發(fā)送方處也不應產(chǎn)生。
本文檔定義了RTSP協(xié)議的1.0版本。發(fā)送本規(guī)范定義的請求（Request）或響應（Response）消息的應用必須指明RTSP的版本為”RTSP/1.0”。使用該版本號意味著發(fā)送消息的應用至少有條件的遵循本規(guī)范。
應用的RTSP版本即為應用至少能有條件遵循的RTSP版本中的最高版本。
當代理及網(wǎng)關(guān)收到與其自身版本不同的RTSP請求時，必須小心處理請求的推送，因為協(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關(guān)不應發(fā)出高于自身版本的消息。如果收到高版本的請求，代理或網(wǎng)關(guān)必須降低該請求的版本，并響應一個錯誤。而低版本的請求也應在被推送前升級。代理或網(wǎng)關(guān)響應請求時必須和請求的版本相同。

---

3.2 RTSP URL
“rtsp”和”rtspu”前綴表示要通過RTSP協(xié)議來定位網(wǎng)絡資源。本節(jié)詳細定義了RTSP URL的語法和語義。
rtsp_URL =(“rtsp:” | “rtspu:” ) “//” host [ “:”port ] [ abs_path ]
host =<合法的Internet主機域名或IP地址(用十進制數(shù)及點組成), 見RFC1123，2.1節(jié)定義>
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 =

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。