RTSP協(xié)議詳解中文版

1、E-mail：譯者： Bryan.Wong（王晶，寧夏固原）譯文版本：alpha 0.80譯文發(fā)布時(shí)間：2007-7-25版權(quán)：本中文翻譯文檔之版權(quán)歸王晶所有。可于非商業(yè)用途前提下自由轉(zhuǎn)載，但必須保留此翻譯及版權(quán)信息。http:/www.uusha/filedownload?user=bryanj&id=611206網(wǎng)絡(luò)工作組 H. Schulzrinne請(qǐng)求注釋: 2326 哥倫比亞大學(xué).類別: 標(biāo)準(zhǔn)跟蹤 A. Rao Netscape R. Lanphier RealNetworks 1998年4月 實(shí)時(shí)流協(xié)議(RTSP)本備忘錄狀態(tài)本文為Internet社區(qū)描述了一種Internet標(biāo)準(zhǔn)

2、跟蹤協(xié)議，還需要討論和建議以便進(jìn)行改善。請(qǐng)查看最新版本的Internet正式協(xié)議標(biāo)準(zhǔn)（STD 1）了解本協(xié)議的標(biāo)準(zhǔn)化進(jìn)程和狀態(tài)。本備忘錄的傳播不受限制。版權(quán)聲明：版權(quán)為The Internet Society 所有。所有權(quán)利保留。摘要：實(shí)時(shí)流協(xié)議（RTSP）是應(yīng)用層協(xié)議，控制實(shí)時(shí)數(shù)據(jù)的傳送。RTSP提供了一個(gè)可擴(kuò)展框架，使受控、按需傳輸實(shí)時(shí)數(shù)據(jù)（如音頻與視頻）成為可能。數(shù)據(jù)源包括現(xiàn)場(chǎng)數(shù)據(jù)與存儲(chǔ)在剪輯中的數(shù)據(jù)。本協(xié)議旨在于控制多個(gè)數(shù)據(jù)發(fā)送會(huì)話，提供了一種選擇傳送途徑（如UDP、組播UDP與TCP）的方法，并提供了一種選擇基于RTP (RFC1889)的傳送機(jī)制的方法。 目錄：1 介紹 1.1 目

3、的 1.2 要求 1.3 術(shù)語(yǔ) 1.4 協(xié)議特性 1.5 RTSP擴(kuò)展 1.6 整體運(yùn)作 1.7 RTSP狀態(tài) 1.8 與其他協(xié)議的關(guān)系 2 符號(hào)協(xié)定 3 協(xié)議參數(shù) 3.1 RTSP版本 3.2 RTSP URL 3.3 會(huì)議標(biāo)識(shí) 3.4 會(huì)話標(biāo)識(shí) 3.5 SMPTE 相對(duì)時(shí)間戳 3.6正常播放時(shí)間 3.7 絕對(duì)時(shí)間 3.8 選項(xiàng)標(biāo)簽 3.8.1 用IANA注冊(cè)新的選項(xiàng)標(biāo)簽 *4 RTSP消息 4.1 消息類型 4.2 消息頭 4.3 消息主體 4.4 消息長(zhǎng)度 *5 普通頭部段 *6 請(qǐng)求 6.1 請(qǐng)求行 6.2 請(qǐng)求消息頭段 *7 響應(yīng) 7.1 狀態(tài)行 7.1.1 狀態(tài)碼和原因短語(yǔ) 7.1

4、.2 響應(yīng)頭部段 *8 實(shí)體 8.1 實(shí)體頭部域 8.2 實(shí)體主體 24*9 連接 9.1 流水線化 259.2 可靠性及確認(rèn) 25*10 方法定義 2510.1 可選項(xiàng) 2610.2 描述 2610.3 通知 2610.4 建立 2610.5 播放 2710.6 暫停 2710.7 斷開 2710.8 獲取參數(shù) 2810.9 設(shè)置參數(shù) 2810.10 重定向 2810.11 錄制 2910.12 嵌入（交織）的二進(jìn)制數(shù)據(jù) 29*11狀態(tài)碼定義 2911.1成功2xx 3011.1.1 存儲(chǔ)空間低 250 3011.2 重定向 3xx 3111.3 客戶端錯(cuò)誤 4xx 3111.3.1方法不允

5、許 3211.3.2無(wú)法理解參數(shù) 3211.3.3會(huì)議未找到 3311.3.4 帶寬不足 3311.3.5 會(huì)話未找到 3411.3.6 本狀態(tài)下該方法無(wú)效 3411.3.7 頭部域與資源不匹配 3411.3.8 無(wú)效范圍 3511.3.9 參數(shù)為只讀 3511.3.10 不允許合操作 3611.3.11 只允許合操作 3611.3.12 不支持的傳輸 3611.3.13 目標(biāo)不可達(dá) 3711.3.14 不支持的選項(xiàng) 3712 頭部段定義（Header Field Definitions） 3812.1 接受 3812.2 接受-編碼 3812.3 接受-語(yǔ)言 3912.4 允許（Allow）

6、 3912.5 授權(quán)（Authorization） 4012.6 帶寬 4012.7 塊大小 4012.8 緩存控制 4112.9 會(huì)議 4112.10 連接 4112.11 內(nèi)容-基礎(chǔ) 4212.12 內(nèi)容-編碼（Content-Encoding） 4212.13 內(nèi)容-語(yǔ)言 4312.14 內(nèi)容-長(zhǎng)度（Content-Length） 4312.15 內(nèi)容-位置 4312.16 內(nèi)容-類型（Content-Type） 4412.17 命令序列題頭（CSeq） 4412.18 日期（Date） 4412.19 過期（Expires） 4512.20 來(lái)自（From） 4512.21 主機(jī) 45

7、12.22 如果匹配 4512.23如果-被修改-自從（If-Modified-Since） 4612.24 最后修改（Last-Modified） 4612.25 位置（Location） 4612.26 代理認(rèn)證 4712.27 代理要求 4712.28 公布 4712.29 范圍 4912.30 提交方（Referer） 4912.31 稍后重試 4912.32 要求 4912.33 RTP信息 4912.34 倍速（Scale）12.35 速度 4912.36 服務(wù)器（Server） 4912.37 會(huì)話 4912.38 時(shí)間戳 4912.39 傳輸 4912.40 不支持 4912.

8、41 用戶代理（User-Agent） 4912.42 變化 4912.43 通過 4912.44 WWW-認(rèn)證（WWW-Authenticate） 50*13 緩存 50*14 例子 5014.1 按需點(diǎn)播（單播） 5014.2 容器文件的流化 5114.3 單個(gè)流容器文件 5114.4 實(shí)況媒體表示的組播 5114.5 在存在的會(huì)話中播放媒體 5114.6 錄制 52*15 語(yǔ)法 5215.1 基本語(yǔ)法 5216 安全考慮（Security Considerations） 52*附錄A RTSP協(xié)議狀態(tài)機(jī) 53*A.1 客戶端狀態(tài)機(jī) 53*A.2 服務(wù)器端狀態(tài)機(jī) 53*附錄B 與RTP協(xié)議

9、的交互 53*附錄C 使用SDP進(jìn)行RTSP會(huì)話描述 54+C.1 定義 54o C.1.1 控制URL 55o C.1.2 媒體流 55o C.1.3 有效載荷類型 55o C.1.4 詳細(xì)格式參數(shù) 55o C.1.5 表示的范圍 56o C.1.6 有效時(shí)間 56o C.1.7 連接信息 56o C.1.8 實(shí)體標(biāo)簽 57+C.2 合控制不可用 57+C.3 合控制可用 57*附錄D 最小RTSP實(shí)現(xiàn) 58+D.1 客戶端 58D.1.1基本回放 58D.1.2 認(rèn)證enabled 58+D.2 服務(wù)器 59D.2.1基本回放 59D.2.2認(rèn)證enabled 59*附錄E 作者地址 60

10、*附錄F 致謝 60*參考書目 60*版權(quán)申明 611 介紹1.1 目的 實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體，比如音頻或視頻。盡管在連續(xù)媒體流中有可能插入控制流（見10.12節(jié)），但RTSP本身通常并不發(fā)送連續(xù)媒體流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遙控器。 表示描述定義了流的控制操作的集合，但本文并沒有規(guī)定表示描述的格式。 RTSP沒有連接這個(gè)概念，而由RTSP會(huì)話(session)代替（服務(wù)器端保持一個(gè)由識(shí)別符標(biāo)記的會(huì)話）。RTSP會(huì)話沒有綁定傳輸層連接（如TCP連接）。在RTSP會(huì)話期間，RTSP客戶端可以打開或關(guān)閉多個(gè)到服務(wù)器端的可靠傳輸連接以發(fā)出RT

11、SP請(qǐng)求。但也可以使用無(wú)連接傳輸協(xié)議，比如UDP，來(lái)發(fā)送RTSP請(qǐng)求。 RTSP所控制的流可能用到RTP，但RTSP的操作并不依賴用來(lái)傳送連續(xù)媒體的傳輸機(jī)制。實(shí)時(shí)流協(xié)議在語(yǔ)法和操作上有意地類似于HTTP/1.1，使得HTTP的擴(kuò)展機(jī)制大都可加入RTSP。盡管如此，RTSP在很多重要方面與HTTP有所不同： *RTSP引入了很多新方法并且有不同的協(xié)議標(biāo)識(shí)符。 *RTSP服務(wù)器在絕大多數(shù)默認(rèn)情況下需要維持狀態(tài)，而HTTP是無(wú)狀態(tài)協(xié)議。 *RTSP客戶機(jī)和服務(wù)器都可以發(fā)出請(qǐng)求。 *數(shù)據(jù)由信帶外的另一個(gè)協(xié)議傳送（但有一個(gè)特例）。 *RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-

12、1，以配合當(dāng)前HTML的國(guó)際化。 *RTSP的URI請(qǐng)求時(shí)總是包含絕對(duì)URI。而由于歷史原因造成的后向兼容性問題，HTTP/1.1只在請(qǐng)求中包含絕對(duì)路徑，把主機(jī)名放入單獨(dú)的頭部域中。 當(dāng)只有一個(gè)IP的主機(jī)要提供多個(gè)文檔樹時(shí)，可使虛擬主機(jī)的實(shí)現(xiàn)更簡(jiǎn)單。協(xié)議支持以下操作： 從媒體服務(wù)器上獲得媒體： 用戶可通過HTTP或其它途徑請(qǐng)求一個(gè)表示描述。如果該表示是組播，表示描述就包含用于該連續(xù)媒體的的多播地址和端口。如表示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)起見要提供目的地址。邀請(qǐng)媒體服務(wù)器進(jìn)入會(huì)議： 媒體服務(wù)器可被邀請(qǐng)加入已存在的的會(huì)議，包括向該表示內(nèi)回放媒體，或記錄此表示中的一部分或全部媒體。這種模式

13、在分布式教學(xué)應(yīng)用上很有用。會(huì)議中的各方可輪流按網(wǎng)絡(luò)遙控器的按鈕。 將媒體加到已存在的表示中： 現(xiàn)場(chǎng)表示的專用概念。當(dāng)服務(wù)器可以告訴客戶端可以附加媒體時(shí)有用。和HTTP/1.1類似，RTSP的請(qǐng)求可由代理、通道與緩存處理。 1.2 要求在本文檔中的關(guān)鍵字必須，必須不、需要、必須、必須不、應(yīng)該、不應(yīng)該、推薦、可能、和可選的，都和RFC2119 4中的解釋一致。1.3 術(shù)語(yǔ)一些HTTP/1.1的術(shù)語(yǔ)被采用。這里沒有舉出的術(shù)語(yǔ)，其定義與HTTP/1.1相同。合控制： 服務(wù)器使用一條時(shí)間線對(duì)多個(gè)流進(jìn)行控制。對(duì)音頻/視頻的回放來(lái)講，這意味著客戶端僅需發(fā)送一條播放或者暫停消息就可同時(shí)控制音頻和視頻的回放。會(huì)

14、議： 多方參與的多媒體表示，這里的多方意味著大于或等于一方?？蛻舳耍?指請(qǐng)求媒體服務(wù)器上連續(xù)流媒體數(shù)據(jù)的客戶端。連接： 以通訊為目的，在傳輸層建立的兩個(gè)程序間的虛擬信道。容器文件： 可以容納多個(gè)媒體流的文件，而這些媒體流共同播放時(shí)通常還包含一個(gè)表示。RTSP服務(wù)器可以為這些容器文件提供合控制，但容器文件的概念本身并不包含在本協(xié)議中。連續(xù)媒體： 接受器和數(shù)據(jù)源之間存在時(shí)序關(guān)系的數(shù)據(jù)。也就是說，接受器需要重放原來(lái)存在于源數(shù)據(jù)中的時(shí)序關(guān)系。最普通的連續(xù)媒體的例子是音頻和動(dòng)畫視頻。連續(xù)媒體可以是實(shí)時(shí)的（交互的），它們?cè)谠春徒邮芷髦g是一種緊密的時(shí)序關(guān)系；或者是流（回放）的形式，時(shí)序關(guān)系沒那么嚴(yán)格。實(shí)體

15、： 請(qǐng)求或者響應(yīng)的載荷部分中所傳輸?shù)男畔ⅰ?shí)體由信息元組成，而每個(gè)信息元由由實(shí)體頭部域和實(shí)體主體組成。實(shí)體頭部域內(nèi)是信息格式，實(shí)體主體內(nèi)是信息內(nèi)容，如第8章所述。媒體初始化： 數(shù)據(jù)類型/編碼的具體初始化。這包括時(shí)鐘頻率，顏色空間等?？蛻舳苏?qǐng)求一個(gè)媒體流回放時(shí)所需的任何獨(dú)立于傳輸?shù)男畔ⅲ际窃诹鲃?chuàng)建時(shí)媒體初始化階段產(chǎn)生的。媒體參數(shù): 對(duì)于某種特定的媒體類型來(lái)說，回放前或者回放中有可能會(huì)發(fā)生改變的一些參數(shù)。媒體服務(wù)器： 提供一個(gè)或多個(gè)媒體流之回放或錄制服務(wù)的服務(wù)器。同一個(gè)表示(presentation)中不同的媒體流可能來(lái)自于不同的媒體服務(wù)器。媒體服務(wù)器可以建在激活該表示(presentation

16、)的Web服務(wù)器上，也可以建立在不同的主機(jī)上。媒體服務(wù)器重定向： 重新把媒體客戶端定向到另外一個(gè)媒體服務(wù)器。(媒體)流： 單個(gè)媒體實(shí)例，比如，一個(gè)音頻流或者一個(gè)視頻流，連同一個(gè)白板或者共享程序組。當(dāng)使用RTP時(shí)，流包括由RTP會(huì)話(session)中同一個(gè)源所創(chuàng)建的所有RTP和RTCP包。這和DSM-CC流(5)的定義相同。消息： RTSP通訊的基本單元。由15章語(yǔ)法定義的結(jié)構(gòu)化八位位組序列組成，并通過有連接或者無(wú)連接協(xié)議傳送。參與者：一個(gè)會(huì)議的成員。參與者可以是機(jī)器，比如是媒體記錄或回放服務(wù)器。表示(presentation)： 作為一個(gè)完整的媒體信息，回饋性地表述給客戶端的一個(gè)或多個(gè)流的集

17、合。表示使用下面的表示描述進(jìn)行表述。大部分情況下，在RTSP中的文字部分中，這暗示集合中的流的合控制，但并非必須。表示描述(presentation description)： 表示描述包含在表示(presentation)中一個(gè)或者多個(gè)媒體流的信息。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息，的集合。另外，其他IETF協(xié)議，如SDP協(xié)議使用術(shù)語(yǔ)會(huì)話(session)代替現(xiàn)場(chǎng)表示。表示描述可以采用包括會(huì)話描述(session description)SDP在內(nèi)的多種格式。響應(yīng)：RTSP響應(yīng)。如果能理解HTTP響應(yīng)，就能清楚地理解RTSP響應(yīng)。請(qǐng)求： RTSP請(qǐng)求。如果能理解HTTP請(qǐng)求，就能清楚地理解R

18、TSP請(qǐng)求。RTSP會(huì)話(session)： 包括一次RTSP事務(wù)（transaction）的全過程。比如，一個(gè)電影的觀看過程。會(huì)話(session)一般包括由客戶端為連續(xù)媒體建立傳輸機(jī)制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關(guān)閉流。傳輸初始化： 客戶端和服務(wù)器端之間關(guān)于傳輸所需的相關(guān)信息（端口號(hào)，傳輸協(xié)議等）的協(xié)商。1.4 協(xié)議特點(diǎn) RTSP有以下特性：易于擴(kuò)展： 可以很容易地向RTSP加入新方法和參數(shù)。 易解析： RTSP可由標(biāo)準(zhǔn)HTTP或MIME解析器解析。安全： RTSP重用了網(wǎng)頁(yè)安全機(jī)制。所有HTTP授權(quán)機(jī)構(gòu)如basic (R

19、FC 2068 2, Section 11.1)和digest (RFC 2069 8)授權(quán)都可直接使用。也可以重用傳輸層或網(wǎng)絡(luò)層安全機(jī)制。 獨(dú)立于傳輸： RTSP即可使用不可靠數(shù)據(jù)報(bào)協(xié)議（UDP）、可靠數(shù)據(jù)報(bào)協(xié)議（RDP），如要實(shí)現(xiàn)應(yīng)用級(jí)可靠，也可使用可靠流協(xié)議如TCP。 多服務(wù)器支持： 表示(presentation)中的每個(gè)流可放在不同服務(wù)器上，客戶端自動(dòng)同不同服務(wù)器建立幾個(gè)并發(fā)控制的會(huì)話，媒體同步在傳輸層執(zhí)行。 錄制設(shè)備控制： 協(xié)議可控制記錄和回放設(shè)備，以及可在兩種模式之間切換的設(shè)備（VCR）。 流控制與會(huì)議初始化分離： 流控制與邀請(qǐng)媒體服務(wù)器入會(huì)相分離；僅要求會(huì)議初始化協(xié)議可提供，或

20、可用來(lái)創(chuàng)建具有唯一性的會(huì)議標(biāo)識(shí)號(hào)。具體地說， SIP或H.323 可用來(lái)邀請(qǐng)服務(wù)器入會(huì)。適合專業(yè)應(yīng)用： 通過SMPTE 時(shí)標(biāo)，RTSP支持幀級(jí)別精度，以支持遠(yuǎn)程數(shù)字編輯。適合專業(yè)應(yīng)用： RTSP依賴SMPTE時(shí)間戳支持幀級(jí)精度，使得可以進(jìn)行遠(yuǎn)程數(shù)字編輯。表示描述中立： 協(xié)議沒強(qiáng)行指定特定的表示或元文件格式，可傳達(dá)所用的格式類型；然而，表示描述必須至少包含一個(gè)RTSP URI。 代理與防火墻友好： 協(xié)議需由應(yīng)用層協(xié)同傳輸層(SOCKS 14)防火墻友好地進(jìn)行處理。防火墻需要理解SETUP方法，以為UDP媒體流打開一個(gè)洞口。 HTTP友好： 此處，RTSP明智地重用了HTTP概念，使現(xiàn)有的基礎(chǔ)結(jié)構(gòu)

21、可被重用。這些基礎(chǔ)結(jié)構(gòu)包括Internet 內(nèi)容選擇平臺(tái)（PICS：Platform for Internet Content Selection 15,16），以便通過相關(guān)標(biāo)簽訪問內(nèi)容。但由于在大多數(shù)情況下，控制連續(xù)媒體需要服務(wù)器狀態(tài)， RTSP不僅僅向HTTP 添加方法。 合適的服務(wù)器控制： 若客戶端能啟動(dòng)一個(gè)流，它必須也能停止一個(gè)流。服務(wù)器不能啟動(dòng)一個(gè)用戶不能停止的流。傳輸協(xié)商： 實(shí)際處理連續(xù)媒體流前，客戶端可協(xié)商傳輸方法。 性能協(xié)商： 若基礎(chǔ)特性被禁用，必須有某種明確的機(jī)制讓用戶決定哪種方法將不不被實(shí)現(xiàn)。這允許用戶提出適合的用戶界面。 例如，如果不允許尋找，用戶界面必須能禁止位置條滑動(dòng)

22、。早期曾要求RTSP支持多用戶，但現(xiàn)在有了更好的方案，就是保證RTSP能很容易擴(kuò)展成支持多用戶即可。因?yàn)榱鞯臉?biāo)志可以被多個(gè)控制流使用，因此可以輪換持有控制器。協(xié)議不涉及到多個(gè)客戶端如何協(xié)調(diào)入口-這項(xiàng)任務(wù)被留給社會(huì)協(xié)議或其他層。1.5 擴(kuò)展RTSP由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同的請(qǐng)求集。例如：服務(wù)器可能只能回放，因此不必支持錄制請(qǐng)求。用于提供現(xiàn)場(chǎng)直播的服務(wù)器可能不支持尋找（絕對(duì)位置）功能。一些服務(wù)器可能不支持設(shè)置流參數(shù)，因此不支持GET_PARAMETER和SET_PARAMETER請(qǐng)求。但服務(wù)器應(yīng)該實(shí)現(xiàn)所有12章中要求的標(biāo)題域。表示描述(presentation

23、 description)應(yīng)當(dāng)保證不提出服務(wù)器不支持的功能，這種情形和HTTP/1.1 2中，H19.6所描述的方法不太可能被所有服務(wù)器都支持的情形一致。RTSP 可以如下三種方式擴(kuò)展，按所支持的改變多少排序： *已有的方法可以擴(kuò)展加入新參數(shù)，只要這些參數(shù)可以被接收方安全地忽略。（這和給一種HTML tag增加新標(biāo)簽是一樣的）如果客戶端在請(qǐng)求失敗時(shí)需要一個(gè)拒絕確認(rèn)，需要在請(qǐng)求：字段(見Section 12.32)中加入一個(gè)對(duì)應(yīng)于該擴(kuò)展的標(biāo)簽。 *可以加入新方法。如果接收方不理解請(qǐng)求，它就返回一個(gè)501錯(cuò)誤碼（意指未實(shí)現(xiàn)），發(fā)送方就不應(yīng)再嘗試這種方法?？蛻舳丝梢杂肙PTIONS方法去詢問服務(wù)器支

24、持的方法。服務(wù)器應(yīng)該在公共回應(yīng)頭里列出它所支持的所有方法。 *可以定義新版本的協(xié)議，以支持幾乎所有方面的改變（除了版本協(xié)議號(hào)的位置）。1.6 整體運(yùn)作 每個(gè)表示和媒體流可用RTSP URL識(shí)別。表示組成的整個(gè)表示與媒體屬性由表示描述(presentation description)文件定義，其格式不在本協(xié)議中定義?？蛻舳丝梢酝ㄟ^HTTP或其它途徑（如email）獲得此表示描述文件，它沒有必要保存在媒體服務(wù)器上。 根據(jù)此規(guī)范的目標(biāo)，我們假想一個(gè)表示描述(presentation description)描述了多個(gè)表示(presentation)，每個(gè)表示(presentation)維持一個(gè)統(tǒng)一

25、的時(shí)間軸。為簡(jiǎn)明但不失一般性，假定表示描述(presentation description)正好包含一個(gè)這樣的表示(presentation)。表示(presentation)可包含多個(gè)媒體流。 表示描述(presentation description)包含組成表示的流的描述，包括它們的編碼，語(yǔ)言和使用戶可以選擇最符合要求媒體的其他參數(shù)。在表示描述中，各個(gè)由RTSP分別控制的媒體流各有一個(gè)RTSP URL。RTSP URL指出了處理具體媒體流的服務(wù)器以及存在于該服務(wù)器上流的名字。多個(gè)媒體流可以放到不同的服務(wù)器上，比如音頻和視頻流可以分別放到不同服務(wù)器而實(shí)現(xiàn)均分負(fù)載。描述（descripti

26、on)還列出了服務(wù)器可使用的傳輸方法。 除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。下面區(qū)分幾種操作模式： 單播： 以用戶選擇的端口號(hào)將媒體發(fā)送到RTSP請(qǐng)求的來(lái)源處。另一種選擇是，用和RTSP相同的可靠流傳輸媒體。多播，服務(wù)器選擇地址： 媒體服務(wù)器選擇多播地址和端口，這是現(xiàn)場(chǎng)直播或準(zhǔn)點(diǎn)播常用的方式。 多播，用戶選擇地址： 若服務(wù)器要加入正在進(jìn)行的多播會(huì)議，多播地址、端口和密匙由會(huì)議描述給出。會(huì)議描述的建立不在此規(guī)范中討論。1.7 RTSP狀態(tài) RTSP控制通過與控制通道無(wú)關(guān)的獨(dú)立協(xié)議發(fā)送的流。例如，RTSP控制可能是使用TCP連接，而數(shù)據(jù)流使用UDP。因此，即使媒體服務(wù)器沒有收到請(qǐng)求，數(shù)據(jù)也

27、會(huì)繼續(xù)發(fā)送。在會(huì)話生命期，單個(gè)媒體流可通過不同TCP連接按順序發(fā)出的請(qǐng)求來(lái)控制。所以，服務(wù)器需要維護(hù)會(huì)話狀態(tài)以便使RTSP請(qǐng)求和流相互關(guān)聯(lián)。狀態(tài)之間的轉(zhuǎn)換在附錄A中描述。 RTSP中很多方法與狀態(tài)無(wú)關(guān)，但下列方法在服務(wù)器流資源的定位和應(yīng)用上起著重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.SETUP： 讓服務(wù)器給流分配資源，啟動(dòng)RTSP會(huì)話。 PLAY與RECORD： 啟動(dòng)SETUP所分配的流的數(shù)據(jù)傳輸。 PAUSE： 臨時(shí)暫停流，而不釋放服務(wù)器資源。 TEARDOWN： 釋放流占用的資源，RTSP會(huì)話停止，從服務(wù)器端退出。 與狀態(tài)相關(guān)的RTSP方法使

28、用會(huì)話頭部域（Session header field (Section 12.37)）來(lái)識(shí)別哪個(gè)RTSP會(huì)話的狀態(tài)需要處理，在SETUP請(qǐng)求(章節(jié)10.4)的響應(yīng)中，服務(wù)器生成會(huì)話標(biāo)識(shí)。1.8 與其他協(xié)議關(guān)系 RTSP在功能上與HTTP有重疊。它也可能與HTTP相互作用，體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁(yè)的。目前的協(xié)議規(guī)范目的在于允許網(wǎng)頁(yè)服務(wù)器與RTSP媒體服務(wù)器之間有多種接力點(diǎn)。例如，表示描述(presentation description)可通過HTTP和RTSP得到，這降低了基于瀏覽器的應(yīng)用模式的往返傳遞，也允許完全不依賴HTTP的獨(dú)立RTSP 服務(wù)器與客戶端。 但是，RTSP與HT

29、TP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以信帶外的不同協(xié)議進(jìn)行。HTTP是不對(duì)稱協(xié)議，用戶發(fā)送請(qǐng)求，服務(wù)器作出響應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)送請(qǐng)求。RTSP請(qǐng)求也不是無(wú)狀態(tài)的；在請(qǐng)求確認(rèn)后很長(zhǎng)時(shí)間后，仍可設(shè)置參數(shù)，繼續(xù)控制媒體流。 重用HTTP功能至少在兩個(gè)方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權(quán)上采用HTTP功能是有價(jià)值的。 雖然大多數(shù)實(shí)時(shí)媒體使用RTP作為傳輸層協(xié)議，RTSP并沒有綁定到RTP。 RTSP假設(shè)存在可表示包含幾個(gè)媒體流的表示的靜態(tài)與臨時(shí)屬性的表示描述格式。 2 符號(hào)約定 既然很多定義和語(yǔ)法與HTTP/1.1中相同，這里僅指出它們?cè)贖TTP/1.1中定義的位置而

30、并沒有拷貝它們到本文檔。為簡(jiǎn)便起見，本文檔中 HX.Y 表示對(duì)應(yīng)HTTP/1.1（RFC 2068 2）中的X.Y部分。（譯者注：為更方便學(xué)習(xí)RTSP，本翻譯文檔將相關(guān)段落完全譯出）與H2.1類似，本文對(duì)所有機(jī)制的說明都是以增廣BNF的形式來(lái)描述的。此形式在RFC 2234中有詳細(xì)的描述，唯一的不同是RTSP中以1#代替,為分隔符。*簡(jiǎn)單說明增廣BNF如下：增廣BNF（augmented BNF）包括下面的結(jié)構(gòu)：要解釋的名詞名詞解釋（name = definition）規(guī)則的名字（name）就是它本身（不帶任何尖括號(hào)，），后面跟個(gè)等號(hào)，然后就是該規(guī)則的定義。如果規(guī)則需要用多個(gè)行來(lái)描述，利用空格

31、進(jìn)行縮進(jìn)格式排版。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義中還可以使用尖括號(hào)來(lái)幫助理解規(guī)則名的使用。字面意思（literal） 文字的字面意思放在引號(hào)中間，若無(wú)特別指定，則該段文字是大小寫敏感的。規(guī)則1規(guī)則2（rule1 | rule2） 表示其分隔的元素是可選的，比如，是否要選擇是或否。（規(guī)則1 規(guī)則2）（(rule1 rule2)）在圓括號(hào)中的元素表明必然出現(xiàn)。如（元素1（元素2元素3）元素4）可表明兩種意思，即元素1 元素2 元素4和元素1 元素3 元素4*規(guī)則（*rule）在元素前加星號(hào)*表示循環(huán)，其完整形式是*元素，表明元素

32、最少產(chǎn)生次，最多次。缺省值是0到無(wú)限，例如，1*元素意思是至少有一個(gè)，而1*2元素表明允許有1個(gè)或2個(gè)。規(guī)則（rule）方括號(hào)內(nèi)是可選元素。如元素1 元素2與*1（元素1 元素2）是一回事。N 規(guī)則（N rule）表明循環(huán)的次數(shù)：（元素）就是*（元素），也就是精確指出取值。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個(gè)字母組成字符串。規(guī)則（#rule）#與*類似，用于定義元素列表。完整形式是#元素表示至少有個(gè)至多有個(gè)元素，中間用,或任意數(shù)量的空格（LWS）來(lái)分隔，這將使列表非常方便，如（*LWS 元素 *（ *LWS , *LWS 元素 ）就等同于1#元素。空元素在結(jié)構(gòu)中可被任意

33、使用，但不參與元素個(gè)數(shù)的計(jì)數(shù)。也就是說，（元素1），（元素2）僅表示2個(gè)元素。但在結(jié)構(gòu)中，應(yīng)至少有一個(gè)非空的元素存在。缺省值是0到無(wú)限，即#（元素）表示可取任何數(shù)值，包括0；而1#元素表示至少有1個(gè)；而1#2元素表示有1個(gè)或2個(gè)。 ；注釋（; comment） 分號(hào)后面是注釋，僅在單行使用。隱含*LWS（implied *LWS）本文的語(yǔ)法描述是基于單詞的。除非另有指定，否則線性空格（LWS）可以在兩個(gè)鄰近符號(hào)或分隔符（tspecials）之間任意使用，而不會(huì)對(duì)整句的意思造成影響。在兩個(gè)符號(hào)之間必須有至少一個(gè)分隔符，因?yàn)樗鼈円惨鰹閱为?dú)的符號(hào)來(lái)解釋。實(shí)際上，應(yīng)用程序在產(chǎn)生HTTP結(jié)構(gòu)時(shí)，應(yīng)當(dāng)試

34、圖遵照通常方式，因?yàn)楝F(xiàn)在的確有些實(shí)現(xiàn)方式在通常方式下無(wú)法正常工作。* 在本備忘錄中，我們用縮進(jìn)的小型段落來(lái)提供背景和動(dòng)機(jī)。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來(lái)實(shí)現(xiàn)。3 協(xié)議參數(shù) 3.1 RTSP版本 同H3.1定義，僅用RTSP代替HTTP即可。*H3.1： RTSP采用主從（.）數(shù)字形式來(lái)表示版本。協(xié)議的版本政策傾向于讓發(fā)送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高版本的RTSP實(shí)現(xiàn)通訊。只增加擴(kuò)展域的值或增加了不影響通訊行為的消息組件都不會(huì)導(dǎo)致版本數(shù)據(jù)的變化。當(dāng)協(xié)議消息的主要解析算法沒變，而消息語(yǔ)法及發(fā)送方的隱

35、含功能增加了，將會(huì)導(dǎo)致從版本號(hào)（）增加；當(dāng)協(xié)議中消息的格式變化了，主版本號(hào)（）也將發(fā)生改變。 RTSP消息的版本由消息第一行中的RTSP版本域來(lái)表示。RTSP-Version = RTSP / 1*DIGIT . 1*DIGIT注意，主從版本應(yīng)當(dāng)被看作單獨(dú)的整數(shù)，因?yàn)樗鼈兌加锌赡茉黾?，從而超過一位整數(shù)。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。版本號(hào)前面的0將被接收方忽略，而在發(fā)送方處也不應(yīng)產(chǎn)生。本文檔定義了RTSP協(xié)議的1.0版本。發(fā)送本規(guī)范定義的請(qǐng)求（Request）或響應(yīng)（Response）消息的應(yīng)用必須指明RTSP的版本為RTS

36、P/1.0。使用該版本號(hào)意味著發(fā)送消息的應(yīng)用至少有條件的遵循本規(guī)范。應(yīng)用的RTSP版本即為應(yīng)用至少能有條件遵循的RTSP版本中的最高版本。 當(dāng)代理及網(wǎng)關(guān)收到與其自身版本不同的RTSP請(qǐng)求時(shí)，必須小心處理請(qǐng)求的推送，因?yàn)閰f(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關(guān)不應(yīng)發(fā)出高于自身版本的消息。如果收到高版本的請(qǐng)求，代理或網(wǎng)關(guān)必須降低該請(qǐng)求的版本，并響應(yīng)一個(gè)錯(cuò)誤。而低版本的請(qǐng)求也應(yīng)在被推送前升級(jí)。代理或網(wǎng)關(guān)響應(yīng)請(qǐng)求時(shí)必須和請(qǐng)求的版本相同。*3.2 RTSP URLrtsp和rtspu前綴表示要通過RTSP協(xié)議來(lái)定位網(wǎng)絡(luò)資源。本節(jié)詳細(xì)定義了RTSP URL的語(yǔ)法和語(yǔ)義。rtsp_URL= ( rtsp: |

37、rtspu: ) / host : port abs_path host= port = *DIGITabs_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_l

38、oc = *( pchar | ; | ? ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | : | | & | = | + uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national escape = % HEX HEX reserved = ; | / | ? | : | | & | = | + extra = ! | * | | ( | ) | , safe = $ | - |

39、 _ | . unsafe = CTL | SP | | # | % | national = 權(quán)威的URL語(yǔ)法及語(yǔ)義信息請(qǐng)參見RFC17384和RFC18089。*注意：fragment和query標(biāo)識(shí)符在這時(shí)沒有明確的定義，需要到RTSP服務(wù)器上解釋。rtsp前綴要求使用可靠協(xié)議（在Internet上指TCP協(xié)議）發(fā)出命令，而rtspu前綴則說明使用不可靠協(xié)議（在Internet指UDP協(xié)議）。如是端口為空或沒指定，則缺省為554端口。語(yǔ)義如下：擁有被請(qǐng)求的資源的服務(wù)器主機(jī)通過監(jiān)聽TCP連接(rtsp方案)或主機(jī)上相應(yīng)端口的UDP包(rtspu方案)，來(lái)控制所標(biāo)記的資源。資源的請(qǐng)求URI是

40、rtsp_URL。應(yīng)盡可能避免在URL中直接使用IP地址。（請(qǐng)參考RFC1924）一個(gè)表示或者流是通過基于文本的媒體標(biāo)記來(lái)標(biāo)識(shí)的，此媒體標(biāo)記使用URLs (RFC 1738 20)中的字符集和轉(zhuǎn)義規(guī)則H3.2。URLs可以指向一個(gè)流或者一個(gè)流的集合，即是說，一個(gè)表示。請(qǐng)求視情況可以指向一個(gè)完整的表示或者表示中的單個(gè)流，見第十章。注意，某些請(qǐng)求方法只能用于流，而不能用于表示，反之亦然。例如：RTSP URL:rtsp:/media.examp:554/twister/audiotrack標(biāo)識(shí)了表示twister中的音頻流，它可以通過發(fā)送基于TCP連接的RTSP請(qǐng)求至主機(jī)media.examp的5

41、54端口進(jìn)行控制。也可以是這樣RTSP URL：rtsp:/media.examp:554/twister標(biāo)識(shí)了表示twister，它可能是由音頻和視頻流組成的。這里并沒有暗示相關(guān)流URL的標(biāo)準(zhǔn)。表示的結(jié)構(gòu)關(guān)系和各個(gè)流的URL在表示描述中定義。如一個(gè)表示描述可能將一個(gè)流命名為a.mov，而將整個(gè)表示命名為b.mov。RTSP URL的路徑組成對(duì)客戶端是不透明的，也不暗含任何服務(wù)器的具體文件系統(tǒng)結(jié)構(gòu)。簡(jiǎn)單替換URL中的前綴后，表示描述同樣可以用于非RTSP媒體控制協(xié)議。3.3 會(huì)議標(biāo)識(shí)會(huì)議標(biāo)識(shí)采用URI標(biāo)準(zhǔn)編碼方法（即是說，LWS被轉(zhuǎn)義為%）編碼，并對(duì)RTSP不透明。它們能包含任意字節(jié)值?！颈仨?/p>

42、】保證會(huì)議標(biāo)識(shí)在全局中的唯一性。在H.323中，將用到會(huì)議的標(biāo)識(shí)值。conference-id = 1*xchar會(huì)議標(biāo)識(shí)用以允許RTSP會(huì)話從媒體服務(wù)器參與的多媒體會(huì)議中獲取參數(shù)。這些會(huì)議是用該規(guī)范之外的協(xié)議創(chuàng)建的，例如H.323 13 或 SIP 12協(xié)議。這樣就不用RTSP客戶端顯式地提供傳輸信息，而改用其他方式代替，例如，客戶端要求媒體服務(wù)器使用會(huì)議描述中的值。3.4 會(huì)話標(biāo)識(shí)會(huì)話標(biāo)識(shí)符是非直讀的任意長(zhǎng)度的字符串。線性空格必須是URL轉(zhuǎn)義的。會(huì)話標(biāo)識(shí)符【必須】隨機(jī)產(chǎn)生并且【必須】至少由8個(gè)字節(jié)組成，以保證其難以被猜出。（詳見16章）session-id = 1*( ALPHA | DI

43、GIT | safe )3.5 SMPTE 相對(duì)時(shí)間戳SMPTE 相對(duì)時(shí)間戳表示相對(duì)于開始剪輯的時(shí)間。相對(duì)時(shí)間戳以SMPTE時(shí)間編碼形式表示以保證幀級(jí)的訪問精度。時(shí)間編碼的格式為：時(shí)：分：秒：幀.子幀，并以 剪輯開始為起點(diǎn)。缺省的SMPTE格式為SMPTE 30 drop格式，其幀率是29.97幀每秒。也可能可通過選擇使用不同SMPTE time來(lái)選擇其他SMPTE編碼格式（如SMPTE 25）。幀域（frames field）的時(shí)間值在0到29之間。30幀每秒和29.97幀每秒的不同之處在于后者除了整十分鐘外的每分鐘都要丟掉頭兩個(gè)幀（00和01）。忽略幀值為0的幀，子幀以百分之一幀為單位。

44、smpte-range = smpte-type = smpte-time - smpte-time smpte-type = smpte | smpte-30-drop | smpte-25 ; other timecodes may be added 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.013.6正常

45、播放時(shí)間正常播放時(shí)間(NPT)指示流相對(duì)于表示(presentation)開始的位置。時(shí)間戳由一個(gè)十進(jìn)制小數(shù)組成，以秒為單位，小數(shù)點(diǎn)左邊可以是秒或者以小時(shí)：分：秒的形式表示。小數(shù)點(diǎn)右邊表示秒的小數(shù)部分。表示開始時(shí)對(duì)應(yīng)0.0秒。負(fù)值沒有意義。特殊的常數(shù)now定義為現(xiàn)場(chǎng)事件當(dāng)前瞬間。它只能用于現(xiàn)場(chǎng)事件。在DSM -CC中，正常播放時(shí)間（NPT）是這樣定義的：直觀地講，NPT是用戶和程序聯(lián)系的時(shí)鐘。它經(jīng)常在VCR上數(shù)字顯示出來(lái)。當(dāng)處于普通播放模式 (倍速= 1)時(shí)，NPT正常前進(jìn)。當(dāng)處于快進(jìn)掃描模式時(shí)(倍速為大于1的正數(shù))，NPT快速前進(jìn)。當(dāng)處于反向掃描模式(倍速小于-1)時(shí)，NPT快速后退。當(dāng)處于

46、暫停模式時(shí)，NPT停止。NPT（邏輯上）等同于SMPTE時(shí)間編碼。npt-range= ( npt-time - npt-time ) | ( - npt-time )npt-time = now | npt-sec | npt-hhmmssnpt-sec= 1*DIGIT . *DIGIT npt-hhmmss = npt-hh : npt-mm : npt-ss . *DIGIT npt-hh = 1*DIGIT ; any positive numbernpt-mm = 1*2DIGIT; 0-59npt-ss = 1*2DIGIT; 0-59 例如： npt=123.45-125 np

47、t=12:05:35.3- npt=now- 語(yǔ)法遵循ISO 8601規(guī)則。npt-sec標(biāo)志法便于自動(dòng)生成， ntp-hhmmss標(biāo)志法便于人閱讀。now常數(shù)允許客戶端請(qǐng)求接收實(shí)時(shí)反饋而不是存儲(chǔ)或者延時(shí)的版本。因?yàn)閷?duì)于這種情況而言，絕對(duì)時(shí)間和0時(shí)間都不適用。3.7 絕對(duì)時(shí)間絕對(duì)時(shí)間表示為ISO 8601時(shí)間戳，使用UTC(GMT)時(shí)間。秒的小數(shù)部分也可能會(huì)出現(xiàn)。utc-range= clock = utc-time - utc-time utc-time = utc-date T utc-time Zutc-date = 8DIGIT; utc-time = 6DIGIT . fractio

48、n ; 比如，1996年11月8日14點(diǎn)37分20.25秒U(xiǎn)TC時(shí)間為：19961108T143720.25Z3.8 選擇標(biāo)簽選項(xiàng)標(biāo)簽是用來(lái)指示RTSP新選項(xiàng)的唯一標(biāo)識(shí)符。這些標(biāo)簽用于要求(Require)(12.32節(jié))和代理要求(Proxy Require)(12.27節(jié))頭部域中。語(yǔ)法：option-tag = 1*xchar要建立新的RTSP選項(xiàng)，可以在選項(xiàng)前加入反轉(zhuǎn)域名的前綴（如：對(duì)于能訪問到則com.foo.mynewfeature 是個(gè)合適的名字），或者在英特網(wǎng)權(quán)威數(shù)字分派委員會(huì)注冊(cè)（IANA）新的選項(xiàng)。3.8.1 用IANA注冊(cè)新的選項(xiàng)標(biāo)簽當(dāng)注冊(cè)新RTSP選項(xiàng)標(biāo)簽的時(shí)候，應(yīng)該提

49、供以下信息： *選項(xiàng)的名字和描述。名字長(zhǎng)度不限，但是應(yīng)該不多于20字符。名字【必須不】包含任何空格，控制符或句點(diǎn)。 *指出誰(shuí)擁有選項(xiàng)的改變控制權(quán)（例如，IETF，國(guó)際標(biāo)準(zhǔn)化組織，國(guó)際電信聯(lián)盟-T，其他的國(guó)際標(biāo)準(zhǔn)化體，一個(gè)團(tuán)體，一個(gè)公司，或者一組公司）。 *描述更為詳細(xì)的參考文檔（如果有），比如（按推薦程度排序），RFC，公開發(fā)表的論文，專利文檔，技術(shù)報(bào)告，源代碼，或者計(jì)算機(jī)手冊(cè)。 *對(duì)于私有的選項(xiàng)，需要給出聯(lián)系地址（郵政地址及電子郵箱）。4 RTSP消息 RTSP是基于文本的協(xié)議，采用ISO 10646 字符集和UTF-8編碼方案。每行結(jié)束處行以CRLF標(biāo)記，但接收方需有能力將CR和LF自行解

50、釋成行終止符。基于文本的協(xié)議使得易于以自描述方式增加可選參數(shù)。由于參數(shù)的數(shù)量和命令出現(xiàn)的頻率較低，處理效率不予考慮。如定義得較仔細(xì)，文本協(xié)議很容易以腳本語(yǔ)言（如：Tcl、Visual Basic與Perl）實(shí)現(xiàn)研究原型。 10646字符集避免了繁瑣的字符集切換，但若應(yīng)用程序使用US-ASCII字符集，它將不可見。RTCP也采用這種編碼方案。ISO 8859-1通過在高位填充0，直接轉(zhuǎn)成Unicode。標(biāo)志位不為0的ISO 8859-1字符被表示如100001x 10 xxxxxx.。(見 RFC 2279 21)RTSP信息可通過任何8-bit clean的低層傳輸協(xié)議傳送。 請(qǐng)求包括方法、方

51、法作用于其上的對(duì)象和進(jìn)一步描述方法的參數(shù)。除非另外說明，否則方法是冪等的。方法還被設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。4.1 消息類型見H4.1*H4.1：RTSP消息由客戶端到服務(wù)器的請(qǐng)求和由服務(wù)器到客戶端的響應(yīng)組成。RTSP -message = Request | Response ; RTSP /1.0 messages請(qǐng)求（Request）和響應(yīng)（Response）消息都使用RFC822中實(shí)體傳輸部分規(guī)定（作為消息中的有效載荷）的消息格式。兩者的消息都可能包括一起始行，一個(gè)或多個(gè)頭部域（headers）、一行表示頭部域結(jié)束的空行（即CRLF前沒有內(nèi)容的行），和一個(gè)消息主體（m

52、essage-body, 可選）。generic-message = start-line *message-headerCRLF message-body start-line = Request-Line | Status-Line為了健壯性考慮，服務(wù)器應(yīng)該忽略任何在期望收到請(qǐng)求行時(shí)收到的空行。換句話說，如果服務(wù)器正在讀協(xié)議流，在一個(gè)消息開始時(shí)如果首先收到了CRLF，這個(gè)CRLF符應(yīng)被忽略。*4.2 消息頭部見H4.2。*H4.2： RTSP頭部域，包括主頭部（General-Header,4.3節(jié)）、請(qǐng)求頭部（Request-Header ,5.2節(jié)）、響應(yīng)頭部（Response-Hea

53、der ,6.2節(jié)）及實(shí)體頭部（Entity-Header,7.1節(jié)），都遵照RFC822-3.1節(jié)7給出的通用格式定義。每個(gè)頭部域由后緊跟冒號(hào)的名字，單空格（SP），字符及域值組成。域名是大小寫敏感的。雖然不提倡，頭部域還是可以擴(kuò)展成多行使用，只要這些行以一個(gè)以上的SP或HT開頭就行。RTSP-header = field-name : field-value CRLFfield-name = tokenfield-value = *( field-content | LWS )field-content = 頭部域接收的順序并不重要，但良好的習(xí)慣是，先發(fā)送主頭部，然后是請(qǐng)求頭部或響應(yīng)頭部，

54、最后是實(shí)體頭部。 當(dāng)且僅當(dāng)頭部域的全部域值都用逗號(hào)分隔的列表示時(shí)（即，#（值），多個(gè)有相同域名的RTSP頭部域才可以表示在一個(gè)消息里。而且必須能在不改變消息語(yǔ)法的前提下，將并發(fā)的域值加到第一個(gè)值后面，之間用逗號(hào)分隔，最終能將多個(gè)頭部域結(jié)合成域名：域值對(duì)。*4.3 消息主體見H4.3。*H4.3：RTSP消息的消息主體（如果有）用來(lái)攜帶請(qǐng)求或響應(yīng)的主體。僅在使用傳輸編碼(Transfer-Encoding)時(shí)消息主體和實(shí)體主體才有所不同，這種情況在傳輸編碼頭部域中有詳細(xì)說明。（見H14.40）message-body = entity-body| 傳輸編碼必須能解釋所有保證傳輸安全和正確的應(yīng)用程

55、序的傳輸編碼。傳輸編碼是消息而不是實(shí)體的一個(gè)屬性，因此可以由任一應(yīng)用程序隨著請(qǐng)求/響應(yīng)鏈添加或者刪除。什么時(shí)候允許消息帶消息體的規(guī)則在請(qǐng)求和響應(yīng)兩種情況下有所不同。在請(qǐng)求中有無(wú)消息主體的標(biāo)志是是否包含內(nèi)容長(zhǎng)度或請(qǐng)求消息頭部域中的傳輸編碼頭部域。只有當(dāng)請(qǐng)求方法允許有實(shí)體主體的時(shí)候才能在請(qǐng)求中包含消息主體。而對(duì)于響應(yīng)消息來(lái)說，無(wú)論消息中是否存在消息主體都與請(qǐng)求方法和響應(yīng)狀態(tài)編碼無(wú)關(guān)。所有響應(yīng)頭部請(qǐng)求方法的消息都不能包含消息主體，盡管有時(shí)會(huì)因?yàn)榇嬖趯?shí)體 頭部域而使人產(chǎn)生誤解。所有1（信息），204（無(wú)內(nèi)容），304（未修改）響應(yīng)都不包含消息主體。而其他響應(yīng)則都包含主體，盡管其長(zhǎng)度有可能長(zhǎng)度為零。*4

56、.4 消息長(zhǎng)度當(dāng)信息體包含在信息中時(shí)，信息體長(zhǎng)度由如下因素決定（按優(yōu)先度排列）： 1. 任何【必須不】包含消息體message body的響應(yīng)消息（如1XX，204，及304響應(yīng)），總是在頭域后的第一個(gè)空行后就結(jié)束，而不管實(shí)體頭部域是否出現(xiàn)在信息中。（注意：空行中只有CRLF。）2. 如果存在內(nèi)容長(zhǎng)度頭部域（Content-Length header field），它的值（單位為byte）就表示消息體的長(zhǎng)度。如果此頭部域沒有出現(xiàn)，則假設(shè)其值為0。3. 通過服務(wù)器關(guān)閉連接。（關(guān)閉連接不能被用于指示請(qǐng)求主體（request body）的結(jié)束，因?yàn)槟菢訉⑹狗?wù)器無(wú)法回送響應(yīng)。）注意：RTSP目前并不

57、支持HTTP/1.1塊傳輸編碼(見 H3.6)，需要有內(nèi)容頭部域。假如返回了長(zhǎng)度適當(dāng)?shù)谋硎久枋?，服?wù)器應(yīng)該總是可以確定它的長(zhǎng)度-即便它是動(dòng)態(tài)產(chǎn)生，使得沒有必要采用塊傳輸編碼。如有實(shí)體，即使必須有內(nèi)容長(zhǎng)度，且長(zhǎng)度沒顯式給出，上述規(guī)則也可確保行為的合理性。5 普通頭部域 除了Pragma、Transfer-Encoding 和 Upgrade頭部，其余見H4.5 general-header = Cache-Control ; Section 12.8 | Connection ; Section 12.10 | Date ; Section 12.18 | Via ; Section 12.43

58、6 請(qǐng)求從客戶端到服務(wù)器端或與之相反的請(qǐng)求消息，在消息首行中包括：應(yīng)用于資源的方法、資源的標(biāo)識(shí)符及所使用的協(xié)議。Request = Request-Line ; 6.1節(jié) *( general-header ; 5章 | request-header ; 6.2節(jié) | entity-header ) ; 8.1節(jié) CRLF message-body ; 4.3節(jié)6.1 請(qǐng)求行 請(qǐng)求行 = 方法 空格 請(qǐng)求-URI 空格 RTSP-版本 CRLF Method = DESCRIBE ; Section 10.2 | ANNOUNCE ; Section 10.3 | GET_PARAMETER

59、; 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-Ver

60、sion = RTSP / 1*DIGIT . 1*DIGIT6.2 請(qǐng)求頭部域 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 ;