【轉(zhuǎn)】RFC2326(中文版)－實(shí)時(shí)流協(xié)議(RTSP)

轉(zhuǎn)載地址：http://blog.csdn.net/sendy888/archive/2007/12/19/1953288.aspx

實(shí)時(shí)流協(xié)議(RTSP)
( Real Time Streaming Protocol (RTSP) )

備忘錄的狀態(tài)：

本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建議以得到改進(jìn)。請(qǐng)參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)”(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。

版權(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ù)，如音頻與視頻的受控、點(diǎn)播成為可能。數(shù)據(jù)源包括現(xiàn)場(chǎng)數(shù)據(jù)與存儲(chǔ)在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP(RFC1889)上傳送機(jī)制提供方法。

1 緒論      5
1.1 目的      5
1.2 要求      6
1.3 術(shù)語(yǔ)      6
1.4 協(xié)議特點(diǎn)      7
1.5 RTSP擴(kuò)展      8
1.6 操作模式      9
1.7 RTSP狀態(tài)      9
1.8 與其他協(xié)議關(guān)系      10
2 符號(hào)協(xié)定      10
3 協(xié)議參數(shù)      10
3.1 RTSP版本      10
3.2 RTSP URL      11
3.3 會(huì)議標(biāo)識(shí)      13
3.4 會(huì)話標(biāo)識(shí)      13
3.5 SMPTE 相對(duì)時(shí)間戳      13
3.6正常播放時(shí)間      14
3.7 絕對(duì)時(shí)間      15
3.8 選擇標(biāo)簽      15
3.8.1 用IANA注冊(cè)新的選擇標(biāo)簽      15
4 RTSP消息      15
4.1 消息類型      16
4.2 消息標(biāo)題      17
4.3 消息主體      17
4.4 消息長(zhǎng)度      18
5 普通標(biāo)題域      18
6 請(qǐng)求      19
6.1 請(qǐng)求隊(duì)列      19
6.2 請(qǐng)求標(biāo)題域      19
7 回應(yīng)      20
7.1 狀態(tài)行      20
7.1.1 狀態(tài)代碼和原因分析      20
7.1.2 回應(yīng)標(biāo)題域      23
8 實(shí)體      23
8.1 實(shí)體標(biāo)題域      24
8.2 實(shí)體主體      24
9 連接      25
9.1 流水線操作      25
9.2 可靠性及確認(rèn)      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è)置參數(shù)      28
10.10 重定向      28
10.11 錄制      29
10.12 嵌入二進(jìn)制數(shù)據(jù)      29
11狀態(tài)代碼定義（Status Code Definitions）      29
11.1成功2xx（Success 2xx）      30
11.1.1 存儲(chǔ)空間低 250      30
11.2 重定向（Redirection 3xx）      31
11.3 客戶端錯(cuò)誤（Client Error ）4xx      31
11.3.1方法不允許      32
11.3.2參數(shù)不能理解      32
11.3.3會(huì)議未找到      33
11.3.4 帶寬不足      33
11.3.5 會(huì)話未找到      34
11.3.6 本狀態(tài)下該方法無效      34
11.3.7 標(biāo)題域?qū)Y源無效      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 目標(biāo)不可達(dá)      37
11.3.14 選擇不支持      37
12 標(biāo)題域定義（Header Field Definitions）      38
12.1 接受      38
12.2 接受編碼      38
12.3 接受語(yǔ)言      39
12.4 允許（Allow）      39
12.5 授權(quán)（Authorization）      40
12.6 帶寬      40
12.7 塊大小      40
12.8 緩存控制      41
12.9 會(huì)議      41
12.10 連接      41
12.11 基本內(nèi)容      42
12.12 內(nèi)容編碼（Content-Encoding）      42
12.13 內(nèi)容語(yǔ)言      43
12.14 內(nèi)容長(zhǎng)度（Content-Length）      43
12.15 內(nèi)容位置      43
12.16 內(nèi)容類型（Content-Type）      44
12.17 序列號(hào)      44
12.18 日期（Date）      44
12.19 過期（Expires）      45
12.20 來自（From）      45
12.21 主機(jī)      45
12.22 如果匹配      45
12.23 從何時(shí)更改（If-Modified-Since）      46
12.24 最近更改（Last-Modified）      46
12.25 位置（Location）      46
12.26 代理授權(quán)      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 服務(wù)器（Server）      49
12.37 會(huì)話      49
12.38 時(shí)間戳      49
12.39 傳輸      49
12.40 不支持      49
12.41 用戶代理（User-Agent）      49
12.42 變化      49
12.43 通過      49
12.44 WWW-授權(quán)（WWW-Authenticate）      50
13 緩存      50
14 實(shí)例      50
14.1 要求媒體（單播）      50
14.2 容器文件的流      51
14.3 單個(gè)流容器文件      51
14.4 組播現(xiàn)場(chǎng)媒體表示      51
14.5 在存在的會(huì)話中播放媒體      51
14.6 錄制      52
15 語(yǔ)法      52
15.1 基本語(yǔ)法      52
16 安全考慮（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é)議的交互      53
附錄C 使用SDP進(jìn)行RTSP會(huì)話描述      54
C.1 定義      54
C.1.1 控制URL      55
C.1.2 媒體流      55
C.1.3 有效載荷類型      55
C.1.4 詳細(xì)格式參數(shù)      55
C.1.5 表示的范圍      56
C.1.6 有效時(shí)間      56
C.1.7 連接信息      56
C.1.8 實(shí)體標(biāo)簽      57
C.2 合控制不可用      57
C.3 合控制可用      57
附錄D 最簡(jiǎn)單的RTSP實(shí)現(xiàn)      58
D.1 客戶端      58
D.1.1回放      58
D.1.2 授權(quán)      58
D.2 服務(wù)器      59
D.2.1回放      59
D.2.2授權(quán)      59
附錄E 作者地址      60
附錄F 致謝      60
參考書目      60
版權(quán)申明      61

1 緒論
1.1 目的
實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流有可能交叉，但RTSP本身通常并不發(fā)送連續(xù)媒體流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。

表示描述(presentation description)定義了被控流，但本文并沒有定義表示描述的格式。

這里沒有使用RTSP連接的概念，而由RTSP會(huì)話(session)代替（每次服務(wù)由服務(wù)器端保持一個(gè)帶標(biāo)簽的會(huì)話）。RTSP會(huì)話沒有綁定到傳輸層連接（如TCP連接）。因?yàn)殡m然在RTSP會(huì)話期間，RTSP客戶端可打開或關(guān)閉多個(gè)對(duì)服務(wù)器端的可靠傳輸連接以發(fā)出RTSP 請(qǐng)求。但此外，也可能使用無連接傳輸協(xié)議，比如用UDP發(fā)送RTSP請(qǐng)求。

RTSP控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(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)情況下需要維持一個(gè)狀態(tài)，但HTTP是無狀態(tài)協(xié)議。
²      RTSP客戶機(jī)和服務(wù)器都可以發(fā)出請(qǐng)求。
²      數(shù)據(jù)由另一個(gè)協(xié)議傳送（有一特例除外）。
²      RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當(dāng)前HTML的國(guó)際化。
²      RTSP使用URI請(qǐng)求時(shí)包含絕對(duì)URI。而由于歷史原因造成的向后兼容性問題，HTTP/1.1只在請(qǐng)求中包含絕對(duì)路徑，把主機(jī)名放入單獨(dú)的標(biāo)題域中。
這使得“虛擬主機(jī)”實(shí)現(xiàn)更為簡(jiǎn)便，一個(gè)單獨(dú)IP地址的主機(jī)可虛擬為幾個(gè)文件樹主機(jī)。

協(xié)議支持的操作如下：

從媒體服務(wù)器上檢索媒體：
用戶可通過HTTP或其它方法請(qǐng)求一個(gè)表示描述。如表示是組播，表示描述就包含用于連續(xù)媒體的的組播地址和端口。如表示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。

媒體服務(wù)器邀請(qǐng)進(jìn)入會(huì)議：
媒體服務(wù)器可被邀請(qǐng)參加正進(jìn)行的會(huì)議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應(yīng)用上很有用，會(huì)議中幾方可輪流按遠(yuǎn)程控制按鈕。

將媒體加到現(xiàn)成講座中：
　如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對(duì)現(xiàn)場(chǎng)講座顯得尤其有用。

如HTTP/1.1中類似，RTSP請(qǐng)求可由代理、通道與緩存處理。
1.2 要求
在本文檔中的關(guān)鍵字“必須”，“一定不能”，“要求”，“會(huì)”，“不會(huì)”，“應(yīng)該”，“不應(yīng)該”，“被推薦的”，“可以”，和“可選擇的”都在RFC2119中解釋。
1.3 術(shù)語(yǔ)
一些術(shù)語(yǔ)原由HTTP/1.1采用。在HTTP/1.1中定義的術(shù)語(yǔ)這里不再列舉。

合控制：
服務(wù)器使用單條時(shí)間線對(duì)多個(gè)流的控制。對(duì)音頻/視頻回饋來講，這就意味著客戶端僅需發(fā)送一條播放或者暫停消息就可同時(shí)控制音頻和視頻的回饋。
會(huì)議：
多方參與的多媒體表示，這里的多方意味著大于或者等于一方。
客戶端：
指請(qǐng)求媒體服務(wù)器上連續(xù)流媒體數(shù)據(jù)的客戶端。
連接：
      兩個(gè)應(yīng)用程序以通訊為目的在傳輸層建立虛擬電路。
容器文件：
      可以容納多個(gè)共同播放時(shí)包含表示(presentation)的媒體流的文件。RTSP服務(wù)器可以為這些容器文件提供合控制，但容器文件的概念本身并不是本協(xié)議內(nèi)容。
連續(xù)媒體：
      接受器和數(shù)據(jù)源之間存在時(shí)序關(guān)系的數(shù)據(jù)。也就是說，接受器需要重新產(chǎn)生存在于源數(shù)據(jù)中的時(shí)序關(guān)系。最普通的連續(xù)媒體的例子是音頻和動(dòng)畫視頻。連續(xù)媒體可以是實(shí)時(shí)的（但是不交互的），它們?cè)谠春徒邮芷髦g是一種緊密的時(shí)序關(guān)系；或者是流的形式，這種關(guān)系就沒有那么嚴(yán)格了。
實(shí)體：
作為請(qǐng)求或者回應(yīng)的有效負(fù)荷傳輸?shù)男畔ⅰＳ梢詫?shí)體標(biāo)題域（entity-header field）形式存在的元信息和以實(shí)體主體（entity body）形式存在的內(nèi)容組成，如第八章所述。
媒體的初始化：
數(shù)據(jù)類型/編碼的具體初始化，這些包括時(shí)鐘輸率，顏色表等。用戶請(qǐng)求媒體回放的任何獨(dú)立傳輸信息，是在創(chuàng)建流時(shí)初始化媒體流相位時(shí)產(chǎn)生的。
媒體參數(shù):
針對(duì)回放前或回放過程中有可能改變的媒體類型而專門設(shè)定的參數(shù)。
媒體服務(wù)器：
可對(duì)一個(gè)或多個(gè)媒體流提供回放和錄制服務(wù)的服務(wù)器。同一個(gè)表示(presentation)中不同的媒體流可能來自于不同的媒體服務(wù)器。媒體服務(wù)器可以建立在作為傳送請(qǐng)求表示(presentation)的Web服務(wù)器的主機(jī)上，也可以建立在不同的主機(jī)上。
媒體服務(wù)器重定向：
      重新定向媒體客戶端到另外一個(gè)媒體服務(wù)器。
(媒體)流：
      單個(gè)媒體實(shí)例，比如，在應(yīng)用中共用音頻流或視頻流。當(dāng)使用RTP時(shí)，流包括由RTP 會(huì)話(session)中源所創(chuàng)建的所有RTP和RTCP包。這和定義DSM-CC流時(shí)相同。
消息：
RTSP通訊的基本單元。由15章語(yǔ)法定義的一串八位位組組成，并通過連接或者無連接協(xié)議傳送。
參與者：
一個(gè)會(huì)議成員。參與者可以是機(jī)器，比如是媒體記錄或回放服務(wù)器。
表示(presentation)：
對(duì)用戶請(qǐng)求所回饋的一組流，其使用下面的表示描述(presentation description)形式。在本文中的多數(shù)情況下，其意味著對(duì)流進(jìn)行總體控制，但這并不是必須的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一個(gè)或者多個(gè)媒體流的信息。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息。另外，其他IETF協(xié)議，如SDP協(xié)議使用會(huì)話(session)代替現(xiàn)場(chǎng)presentation。表示描述可以采用包括會(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)求，就能清楚的理解RTSP請(qǐng)求。
RTSP會(huì)話(session)：
RTSP交互的全過程。比如，一個(gè)電影的觀看過程。會(huì)話(session)包括由客戶端建立連續(xù)媒體流傳輸機(jī)制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關(guān)閉流。
傳輸初始化：
客戶端和服務(wù)器端之間傳輸信息（端口號(hào)，傳輸協(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ī)制如basic和digest授權(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é)議。
多服務(wù)器支持：
表示(presentation)中的每個(gè)流可放在不同服務(wù)器上，用戶端自動(dòng)同不同服務(wù)器建立幾個(gè)并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。
記錄設(shè)備控制：
　協(xié)議可控制記錄和回放設(shè)備，也可控制可在記錄和回放切換的設(shè)備。
流控與會(huì)議開始分離：
流控與邀請(qǐng)媒體服務(wù)器入會(huì)分離；僅要求會(huì)議初始化協(xié)議提供，或可用來創(chuàng)建唯一會(huì)議標(biāo)識(shí)號(hào)。特殊情況下， SIP或H.323 可用來邀請(qǐng)服務(wù)器入會(huì)。
適合專業(yè)應(yīng)用：
　通過SMPTE 時(shí)標(biāo)，RTSP支持幀級(jí)精度，允許遠(yuǎn)程數(shù)字編輯。
表示描述中立：
協(xié)議沒強(qiáng)加特殊表示或元文件，可傳達(dá)所用格式類型；然而，表示描述至少必須包含一個(gè)RTSP URI。
代理與防火墻友好：
協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個(gè)\"缺口\"。
HTTP友好：
此處，RTSP明智的采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet 內(nèi)容選擇平臺(tái)（PICS）。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài)， RTSP不僅僅向HTTP 添加方法。
適當(dāng)?shù)姆?wù)器控制：
　如用戶能啟動(dòng)一個(gè)流，它必須也能停止一個(gè)流。服務(wù)器不能啟動(dòng)一個(gè)用戶不能停止的流。
傳輸協(xié)調(diào)：
　實(shí)際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。
性能協(xié)調(diào)：
如基本特征無效，必須有一些清理機(jī)制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。例如，如果不允許尋找，用戶界面必定能禁止位置條滑動(dòng)。
以前要求RTSP必須能支持多用戶，但現(xiàn)在得出一個(gè)更好的方法就是保證RTSP能很容易擴(kuò)展成支持多用戶即可。因?yàn)榱鞯臉?biāo)志可以被多個(gè)控制流使用，因此”遠(yuǎn)程通過”成為可能。協(xié)議不涉及到多個(gè)客戶端如何協(xié)調(diào)入口，其由下層“社會(huì)協(xié)議”或其他下層控制機(jī)制提供。
1.5 RTSP擴(kuò)展
由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同請(qǐng)求集。例如：
Ø      服務(wù)器可能只須支持回放，因此不必不支持錄制功能。
Ø      對(duì)于支持現(xiàn)場(chǎng)播放的服務(wù)器可能不支持尋找功能。
Ø      一些服務(wù)器可能不支持設(shè)置流參數(shù)，因此不支持GET_PARAMETER和SET_PARAMETER。
但服務(wù)器應(yīng)該實(shí)現(xiàn)所有12章中要求的標(biāo)題域。
表示描述(presentation description)應(yīng)當(dāng)保證不提出服務(wù)器不支持的功能，這種情形和HTTP/1.1中[H19.6]描述方法不支持across server的情形一致。
RTSP 可以如下三種方式擴(kuò)展，這里以改變大小排序：
Ø      以新參數(shù)擴(kuò)展。如用戶需要拒絕通知，而方法擴(kuò)展不支持，相應(yīng)標(biāo)記就加入要求的段中。
Ø      加入新方法。如信息接收者不理解請(qǐng)求，返回501錯(cuò)誤代碼（還未實(shí)現(xiàn)），發(fā)送者不應(yīng)再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務(wù)器支持的方法。服務(wù)器使用公共回應(yīng)標(biāo)題列出支持的方法。
Ø      定義新版本協(xié)議，允許改變所有部分。（除了協(xié)議版本號(hào)位置）
1.6 操作模式
　每個(gè)表示和媒體流可用RTSP URL識(shí)別。表示組成的整個(gè)表示與媒體屬性由表示描述(presentation description)文件定義，表示描述格式不在本協(xié)議中定義。使用HTTP或其它途徑用戶可獲得這個(gè)文件，它沒有必要保存在媒體服務(wù)器上。
　為了說明，假設(shè)表示描述(presentation description)描述了多個(gè)表示(presentation)，其中每個(gè)表示(presentation)維持了一個(gè)公共時(shí)間軸。為簡(jiǎn)化說明，且不失一般性，假定表示描述(presentation description)的確包含這樣一個(gè)表示(presentation)。表示(presentation)可包含多個(gè)媒體流。
     表示描述(presentation description)即組成表示的流的描述，包括它們的編碼，語(yǔ)言和使用戶可以選擇最符合要求媒體的其他參數(shù)。在表示描述中，被RTSP分別控制的媒體流由RTSP URL表示。RTSP URL指出了處理具體媒體流的服務(wù)器以及存在于該服務(wù)器上流的名字。多個(gè)媒體流可以放到不同的服務(wù)器上，比如音頻和視頻流可以分別放到不同服務(wù)器而負(fù)載共享。描述（description)還列出了服務(wù)器傳輸可使用的方法。
除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。下面區(qū)分幾種操作模式：
單播：
　以用戶選擇的端口號(hào)將媒體發(fā)送到RTSP請(qǐng)求源。
組播，服務(wù)器選擇地址：
　媒體服務(wù)器選擇組播地址和端口，這是現(xiàn)場(chǎng)直播或準(zhǔn)點(diǎn)播常用的方式。
組播，用戶選擇地址：
　如服務(wù)器加入正在進(jìn)行的組播會(huì)議，組播地址、端口和密匙由會(huì)議描述給出。
1.7 RTSP狀態(tài)
　 RTSP控制通過單獨(dú)協(xié)議發(fā)送的流，與控制通道無關(guān)。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務(wù)器沒有收到請(qǐng)求，數(shù)據(jù)也會(huì)繼續(xù)發(fā)送。在會(huì)話生命期，單個(gè)媒體流可通過不同TCP連接順序發(fā)出請(qǐng)求來控制。所以，服務(wù)器需要維持能聯(lián)系流與RTSP請(qǐng)求的會(huì)話狀態(tài)。
RTSP中很多方法與狀態(tài)無關(guān)，但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用：
SETUP：
　讓服務(wù)器給流分配資源，啟動(dòng)RTSP會(huì)話。
PLAY與RECORD：
　啟動(dòng)SETUP 分配流的數(shù)據(jù)傳輸。
PAUSE：
　臨時(shí)停止流，而不釋放服務(wù)器資源。
TEARDOWN：
　釋放流的資源，RTSP會(huì)話停止。
　標(biāo)識(shí)狀態(tài)的RTSP方法使用會(huì)話(session)標(biāo)題域識(shí)別RTSP會(huì)話，為回應(yīng)SETUP請(qǐ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ù)器與實(shí)現(xiàn)RTSP媒體服務(wù)器之間存在不同傳遞點(diǎn)。例如，表示描述(presentation description)可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨(dú)立RTSP 服務(wù)器與用戶不全依靠HTTP。
　但是，RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進(jìn)行。HTTP是不對(duì)稱協(xié)議，用戶發(fā)出請(qǐng)求，服務(wù)器作出回應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)出請(qǐng)求，且其請(qǐng)求都是無狀態(tài)的；在請(qǐng)求確認(rèn)后很長(zhǎng)時(shí)間內(nèi)，仍可設(shè)置參數(shù)，控制媒體流。
重用HTTP功能至少在兩個(gè)方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權(quán)上采用HTTP功能是有價(jià)值的。
　當(dāng)大多數(shù)實(shí)時(shí)媒體使用RTP作為傳輸協(xié)議時(shí)，RTSP沒有綁定到RTP。
RTSP假設(shè)存在表示描述格式可表示包含幾個(gè)媒體流的表示的靜態(tài)與臨時(shí)屬性。
2 符號(hào)協(xié)定
既然很多定義和語(yǔ)法與HTTP/1.1中相同，這里僅指出它們?cè)贖TTP/1.1中定義的位置而并沒有拷貝它們到本文檔。為簡(jiǎn)便起見，本文檔中[ HX.Y ]表示對(duì)應(yīng)HTTP/1.1（RFC 2068）中的X.Y部分。（[譯者注：]為更方便學(xué)習(xí)RTSP，本翻譯文檔將相關(guān)段落完全譯出）

與[H2.1]類似，本文對(duì)所有機(jī)制的說明都是以散文和補(bǔ)充反饋的方式來描述的。除RTSP中以”1#”代替”,”為分隔符不同外，其余在RFC 2234中有詳細(xì)的描述。簡(jiǎn)單說明補(bǔ)充反饋方式如下：

補(bǔ)充反饋方式（augmented BNF）包括下面的結(jié)構(gòu)：

要解釋的名詞＝名詞解釋（name = definition）
規(guī)則的名字（name）就是它本身（不帶任何尖括號(hào)，“<”，“>”），后面跟個(gè)等號(hào)＝，
然后就是該規(guī)則的定義。如果規(guī)則需要用多個(gè)行來描述，利用空格進(jìn)行縮進(jìn)格式排
版。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義
中還可以使用尖括號(hào)來幫助理解規(guī)則名的使用。

字面意思（"literal"）
文字的字面意思放在引號(hào)中間，除非特別指定，該段文字是大小寫敏感的。

規(guī)則1｜規(guī)則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。

（規(guī)則1　規(guī)則2）（(rule1 rule2)）
在圓括號(hào)中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩
種意思，即“元素1　元素2　元素4”和“元素1　元素3　元素4”

*規(guī)則（*rule）
在元素前加星號(hào)“*”表示循環(huán)，其完整形式是“<n>*<m>元素”，表明元素最少產(chǎn)
生<n>次，最多<m>次。缺省值是0到無限，例如，“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ù)：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精確指出<n>
取值。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個(gè)字母組成字符串。

＃規(guī)則（#rule）
“#”與“*”類似，用于定義元素列表。

完整形式是“<n>#<m>元素”表示至少有<n>個(gè)至多有<m>個(gè)元素，中間用“,”或
任意數(shù)量的空格（LWS-linear whitespace）來分隔，這將使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素））”就等同于“1#元素”。

空元素在結(jié)構(gòu)中可被任意使用，但不參與元素個(gè)數(shù)的計(jì)數(shù)。也就是說，“（元素1），，
（元素2）”僅表示2個(gè)元素。但在結(jié)構(gòu)中，應(yīng)至少有一個(gè)非空的元素存在。缺省
值是0到無限，即“#（元素）”表示可取任何數(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)來解釋。實(shí)際上，應(yīng)用程序在
產(chǎn)生HTTP結(jié)構(gòu)時(shí)，應(yīng)當(dāng)試圖遵照“通常方式”，因?yàn)楝F(xiàn)在的確有些實(shí)現(xiàn)方式在通常方
式下無法正常工作。

在本備忘錄中，我們用縮進(jìn)的小型段落來提供動(dòng)機(jī)和背景資料。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來實(shí)現(xiàn)。
3 協(xié)議參數(shù)
3.1 RTSP版本
同[H3.1]定義，僅用RTSP代替HTTP即可。

如下：
RTSP采用主從（<major>.<minor>）數(shù)字形式來表示版本。協(xié)議的版本政策傾向于讓發(fā)
送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高
版本的RTSP實(shí)現(xiàn)通訊。只增加擴(kuò)展域的值或增加了不影響通訊行為的消息組件都不會(huì)導(dǎo)致
版本數(shù)據(jù)的變化。當(dāng)協(xié)議消息的主要解析算法沒變，而消息語(yǔ)法及發(fā)送方的隱含功能增加了，
將會(huì)導(dǎo)致從版本號(hào)（<minor>）增加；當(dāng)協(xié)議中消息的格式變化了，主版本號(hào)（<major>）也
將發(fā)生改變。
RTSP消息的版本由消息第一行中的RTSP版本域來表示。

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

        escape       = "%" HEX HEX
          reserved     = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
        extra       = "!" | "*" | "'" | "(" | ")" | ","
          safe       = "$" | "-" | "_" | "."
        unsafe       = CTL | SP | <"> | "#" | "%" | "<" | ">"
        national     = <any OCTET excluding ALPHA, DIGIT,

reserved, extra, safe, and unsafe>
權(quán)威的URL語(yǔ)法及語(yǔ)義信息請(qǐng)參見RFC1738[4]和RFC1808[9]。
[注意]：段(fragment)和詢問(query)標(biāo)識(shí)符在這時(shí)沒有明確的定義，需要到RTSP服務(wù)器上解釋。

rtsp要求使用可靠協(xié)議（Internet的TCP協(xié)議）發(fā)出命令，而rtspu則使用不可靠協(xié)議（Internet的UDP協(xié)議）。

如是端口為空或沒指定，則缺省為80端口。對(duì)于rtsp_URI來說，擁有被請(qǐng)求的
資源的服務(wù)器主機(jī)通過偵聽該端口的TCP連接(rtsp)或UDP包(rtspu)來接收該URI請(qǐng)求。

只要可能，應(yīng)盡量避免的在URL中直接使用IP地址。（請(qǐng)參考RFC1924）

文本媒體標(biāo)識(shí)符使用URL中的字符集及轉(zhuǎn)義規(guī)則（參考RFC1738）來標(biāo)識(shí)一個(gè)表示(presentation)與單個(gè)流(stream)。URL可以用于單個(gè)流或者多個(gè)流的集合，比如表示(presentation)。因此，在第十章所描述的請(qǐng)求(request)可以用于整個(gè)表示(presentation)或表示中的單個(gè)流。注意，有些請(qǐng)求方法僅能用于流而不能用于表示，反之亦然。

例如：RTSP URL:
rtsp://media.example.com:554/twister/audiotrack
標(biāo)識(shí)了twister表示(presentation)中，可以通過media.example.com554端口的TCP連接發(fā)送RTSP請(qǐng)求來控制的音頻流。

也可以是這樣RTSP URL：
rtsp://media.example.com:554/twister
標(biāo)識(shí)了由音頻和視頻流組成的twister表示(presentation)。

這并沒有給出URL中相關(guān)流的標(biāo)準(zhǔn)方法。表示描述定義了表示中的層次關(guān)系以及單獨(dú)流的URL。如一個(gè)表示描述可能將一個(gè)流命名為a.mov，而將整個(gè)表示命名為b.mov。
RTSP URL的路徑組成對(duì)客戶端來說不可見并且也并沒有給出服務(wù)器的具體文件系統(tǒng)結(jié)構(gòu)。

只需進(jìn)行簡(jiǎn)單替換后，表示描述同樣可以用于非RTSP媒體控制協(xié)議。
3.3 會(huì)議標(biāo)識(shí)
會(huì)議標(biāo)識(shí)采用URI標(biāo)準(zhǔn)編碼方法編碼，并對(duì)RTSP來說是不可見的。它們能包含任一八位位組值。必須保證會(huì)議標(biāo)識(shí)在全局中的唯一性。在H.323中，將用到會(huì)議的標(biāo)識(shí)值。

conference-id = 1*xchar

會(huì)議標(biāo)識(shí)允許RTSP會(huì)話從媒體服務(wù)器參與的多媒體會(huì)議中獲取參數(shù)。比如，可以要求媒體服務(wù)器用會(huì)議描述中的標(biāo)識(shí)值來代替RTSP客戶端以提供詳細(xì)的傳輸信息。多媒體會(huì)議的建立不屬于本協(xié)議內(nèi)容，具體請(qǐng)參見H.323或SIP協(xié)議。
3.4 會(huì)話標(biāo)識(shí)
會(huì)話標(biāo)識(shí)符是不可見的任意長(zhǎng)度的字符串。線性空格必須是URL-escaped。會(huì)話標(biāo)識(shí)符必須隨機(jī)產(chǎn)生并且至少應(yīng)有8個(gè)八位位組長(zhǎng)以保證其難以被猜出。（詳見16章）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相對(duì)時(shí)間戳
SMPTE相對(duì)時(shí)間戳表示相對(duì)于開始剪輯的時(shí)間。相對(duì)時(shí)間戳以SMPTE時(shí)間編碼形式表示而可以達(dá)到幀級(jí)量級(jí)的精度。時(shí)間編碼的格式為：時(shí)：分：秒；幀.子幀，并以剪輯開始為起點(diǎn)。缺省的SMPTE格式為“SMPTE 30 drop”格式，其幀速是29.97幀每秒。可通過選擇使用不同“SMPTE time”來選擇其他SMPTE編碼格式（如“SMPTE 25”格式）。幀域的時(shí)間值在0到29之間。30幀每秒和29.97幀每秒的不同之處在于后者除每第十分鐘外的每分鐘都要丟掉頭兩個(gè)幀（00和01）。忽略幀值為0的幀，子幀以百分之一幀為單位。

smpte-range= smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
 ; 還可以加入其他時(shí)間編碼
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正常播放時(shí)間
正常播放時(shí)間(NPT)指出了流相對(duì)于表示(presentation)開始時(shí)的絕對(duì)位置。時(shí)間戳由一個(gè)十進(jì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)常作為數(shù)字顯示在VCR上。當(dāng)處于普通播放模式(scale = 1)時(shí)，NPT正常前進(jìn)。當(dāng)處于快進(jìn)掃描模式時(shí)(scale率為大于1的正數(shù))，NPT快速前進(jìn)。當(dāng)處于反向掃描模式(scale率小于-1)時(shí)，NPT快速后退。當(dāng)處于暫停模式時(shí)，NPT停止。NPT（邏輯上）等同于SMPTE時(shí)間編碼。

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-

 語(yǔ)法遵循ISO 8601規(guī)則。npt-sec標(biāo)志法便于自動(dòng)產(chǎn)生， ntp-hhmmss標(biāo)志法便于人工使用。“now”常數(shù)允許客戶端請(qǐng)求接收實(shí)時(shí)反饋而不是存儲(chǔ)或者延時(shí)的版本。因?yàn)閷?duì)于這種情況而言，既沒有絕對(duì)時(shí)間，也沒有0時(shí)間，所以需要該參數(shù)。
3.7 絕對(duì)時(shí)間
絕對(duì)時(shí)間表示為ISO 8601時(shí)間戳，使用UTC(GMT)小數(shù)法表示。

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點(diǎn)37分20.25秒U(xiǎn)TC時(shí)間為：
19961108T143720.25Z
3.8 選擇標(biāo)簽
選擇標(biāo)簽是用來指定RTSP新選擇的唯一標(biāo)識(shí)符。這些標(biāo)簽用于要求(Require)(12.32節(jié))和代理要求(Proxy Require)(12.27節(jié))標(biāo)題域中。

語(yǔ)法：
option-tag = 1*xchar

建立新的RTSP選擇可以通過在選擇前加入相反域名的前綴（如：對(duì)于能訪問到foo.com則com.foo.mynewfeature" 是個(gè)合適的名字）或者在英特網(wǎng)權(quán)威數(shù)字分派委員會(huì)注冊(cè)（IANA）新的選擇。
3.8.1 用IANA注冊(cè)新的選擇標(biāo)簽
當(dāng)注冊(cè)新RTSP選擇標(biāo)簽的時(shí)候，應(yīng)該提供以下信息：
Ø      選擇的名字和描述。名字長(zhǎng)度不限，但是應(yīng)該不少于20字符。名字不得包含任何空格，控制符或句點(diǎn)。
Ø      指出誰(shuí)擁有選擇的改變控制權(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è)。
Ø      選擇的所有權(quán)，以及聯(lián)系地址（郵編及電子信件地址）。
4 RTSP消息
　 RTSP是基于文本的協(xié)議，采用ISO 10646 字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。由于參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低，處理效率沒引起注意。如仔細(xì)研究，文本協(xié)議很容易以腳本語(yǔ)言（如：Tcl、Visual Basic與Perl）實(shí)現(xiàn)研究原型。
　 10646字符集避免敏感字符集切換，但對(duì)應(yīng)用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協(xié)議攜帶。
　請(qǐng)求包括方法、方法作用于其上的對(duì)象和進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。當(dāng)信息體包含在信息中，信息體長(zhǎng)度有如下因素決定：
　不管實(shí)體標(biāo)題域是否出現(xiàn)在信息中，不包括信息體的的回應(yīng)信息總以標(biāo)題域后第一和空行結(jié)束。
　如出現(xiàn)內(nèi)容長(zhǎng)度標(biāo)題域，其值以字節(jié)計(jì)，表示信息體長(zhǎng)度。如未出現(xiàn)標(biāo)題域，其值為零。
　服務(wù)器關(guān)閉連接。
　注意：RTSP目前并不支持HTTP/1.1\"塊\"傳輸編碼，需要有內(nèi)容長(zhǎng)度頭。假如返回適度表示描述長(zhǎng)度，即使動(dòng)態(tài)產(chǎn)生，使塊傳輸編碼沒有必要，服務(wù)器也應(yīng)該能決定其長(zhǎng)度。如有實(shí)體，即使必須有內(nèi)容長(zhǎng)度，且長(zhǎng)度沒顯式給出，規(guī)則可確保行為合理。
　從用戶到服務(wù)器端的請(qǐng)求信息在第一行內(nèi)包括源采用的方法、源標(biāo)識(shí)和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼，而沒有定義任何HTTP代碼。

4.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è)標(biāo)題域（headers）、一行表示標(biāo)題域結(jié)束的空行（即CRLF前沒有內(nèi)容的行），和一個(gè)消息主體（message-body,可選）。

generic-message = start-line
*message-header
CRLF
[ 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 消息標(biāo)題
見[H4.2]。
RTSP標(biāo)題域，包括主標(biāo)題（General-Header,4.3節(jié)）、請(qǐng)求標(biāo)題（Request-Header ,5.2節(jié)）、
回應(yīng)標(biāo)題（Response-Header ,6.2節(jié)）及實(shí)體標(biāo)題（Entity-Header,7.1節(jié)），都遵照RFC822-3.1
節(jié)[7]給出的通用格式定義。每個(gè)標(biāo)題域由后緊跟冒號(hào)的名字，單空格（SP），字符及域值組
成。域名是大小寫敏感的。雖然不提倡，標(biāo)題域還是可以擴(kuò)展成多行使用，只要這些行以一
個(gè)以上的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>
標(biāo)題域接收的順序并不重要，但良好的習(xí)慣是，先發(fā)送主標(biāo)題，然后是請(qǐng)求標(biāo)題或回應(yīng)
標(biāo)題，最后是實(shí)體標(biāo)題。
     當(dāng)且僅當(dāng)標(biāo)題域的全部域值都用逗號(hào)分隔的列表示時(shí)（即，#（值）），多個(gè)有相同域名
的RTSP標(biāo)題域才可以表示在一個(gè)消息里。而且必須能在不改變消息語(yǔ)法的前提下，將并發(fā)
的域值加到第一個(gè)值后面，之間用逗號(hào)分隔，最終能將多個(gè)標(biāo)題域結(jié)合成“域名：域值”對(duì)。

4.3 消息主體
見[H4.3]。
RTSP消息的消息主體（如果有）用來攜帶請(qǐng)求或回應(yīng)的主體。僅在使用傳輸編碼(Transfer-Encoding)時(shí)消息主體和實(shí)體主體才有所不同，這種情況在傳輸編碼標(biāo)題域中有詳細(xì)說明。（見[H14.40]）

message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>

傳輸編碼必須能解釋所有保證傳輸安全和正確的應(yīng)用程序的傳輸編碼。傳輸編碼是消息而不是實(shí)體的一個(gè)屬性，因此可以由任一應(yīng)用程序隨著請(qǐng)求/回應(yīng)鏈添加或者刪除。

什么時(shí)候允許消息帶消息體的規(guī)則在請(qǐng)求和回應(yīng)兩種情況下有所不同。

在請(qǐng)求中有無消息主體的標(biāo)志是是否包含內(nèi)容長(zhǎng)度或請(qǐng)求消息標(biāo)題域中的傳輸編碼標(biāo)題域。只有當(dāng)請(qǐng)求方法允許有實(shí)體主體的時(shí)候才能在請(qǐng)求中包含消息主體。

而對(duì)于回應(yīng)消息來說，無論消息中是否存在消息主體都與請(qǐng)求方法和回應(yīng)狀態(tài)編碼無關(guān)。所有回應(yīng)標(biāo)題請(qǐng)求方法的消息都不能包含消息主體，盡管有時(shí)會(huì)因?yàn)榇嬖趯?shí)體標(biāo)題域而使人產(chǎn)生誤解。所有1××（信息），204（無內(nèi)容），304（未修改）回應(yīng)都不包含消息主體。而其他回應(yīng)則都包含主體，盡管其長(zhǎng)度有可能長(zhǎng)度為零。
4.4 消息長(zhǎng)度
當(dāng)消息包含消息主體時(shí)，消息主體的長(zhǎng)度由以下規(guī)則來決定（按優(yōu)先級(jí)高低順序排列）：
1.      任何回應(yīng)消息都不包含消息主體（如1××，204和304回應(yīng)），并且不管消息中是否存在實(shí)體標(biāo)題域都以消息標(biāo)題域后的第一行空行表示結(jié)束。
2.      如果內(nèi)容長(zhǎng)度標(biāo)題域存在，它在字節(jié)中的值就是消息主體的長(zhǎng)度。如果內(nèi)容標(biāo)題域不存在，則假設(shè)值為零。
3.      服務(wù)器關(guān)閉連接時(shí)。（關(guān)閉連接沒有用來表明請(qǐng)求主體結(jié)束，否則可能導(dǎo)致服務(wù)器不能回應(yīng)。
注意，RTSP不支持（至少現(xiàn)在）HTTP/1.1的塊傳輸編碼（詳見[H3.6]）并且要求有內(nèi)容長(zhǎng)度標(biāo)題域。
     盡管表示描述長(zhǎng)度動(dòng)態(tài)產(chǎn)生，但由于可獲得了表示描述返回長(zhǎng)度，使得服務(wù)器總是能決定表示描述長(zhǎng)度而不需使用塊傳輸編碼方式。只要有實(shí)體主體就必須有內(nèi)容長(zhǎng)度項(xiàng)，這些規(guī)則保證了即使沒有給出明確長(zhǎng)度也能做出合理的操作。

5 普通標(biāo)題域
有幾種標(biāo)題域是請(qǐng)求與回應(yīng)都要使用的，但并不用于被傳輸?shù)膶?shí)體。這些標(biāo)題只用于被
傳輸?shù)南ⅰ?/p>

General-Header = Date                  ; Section 10.6
        | Pragma            ; Section 10.12
     普通標(biāo)題域名稱只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，
新的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識(shí)別，其語(yǔ)法就可使用，而無法識(shí)別的標(biāo)題域都將
被視為實(shí)體域。
6 請(qǐng)求
從客戶端到服務(wù)器端的請(qǐng)求消息包括，消息首行中，對(duì)資源的請(qǐ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é)

注意：相對(duì)于HTTP/1.1而言，RTSP請(qǐng)求要求絕對(duì)路徑（并包括rtsp或rtspu方案，主機(jī)，端口號(hào)）。

HTTP/1.1 要求服務(wù)器理解絕對(duì)URL, 但是客戶端需要假設(shè)為主機(jī)請(qǐng)求標(biāo)題域。這樣做完全是為了HTTP/1.0服務(wù)器端向后兼容性，因此RTSP并不需要這樣做。

在請(qǐng)求URI中星號(hào)“*”表示此請(qǐng)求不用于其他資源，只用于服務(wù)器本身，并且它只能在使用的方法不要求應(yīng)用于資源時(shí)才能使用。

比如：OPTIONS * RTSP/1.0。

7 回應(yīng)
7.1 狀態(tài)行
完整回應(yīng)消息的第一行就是狀態(tài)行，它依次由協(xié)議版本、數(shù)字形式的狀態(tài)代碼、及相應(yīng)
的詞語(yǔ)文本組成，各元素間以空格（SP）分隔，除了結(jié)尾的CRLF外，不允許出現(xiàn)單獨(dú)的
CR或LF符。

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

7.1.1 狀態(tài)代碼和原因分析
狀態(tài)代碼（Status-Code）由3位數(shù)字組成，表示請(qǐng)求是否被理解或被滿足。原因分析是
用簡(jiǎn)短的文字來描述狀態(tài)代碼產(chǎn)生的原因。狀態(tài)代碼用來支持自動(dòng)操作，原因分析是為人類
用戶準(zhǔn)備的。客戶端不需要檢查或顯示原因分析。

狀態(tài)代碼的第一位數(shù)字定義了回應(yīng)的類別，后面兩位數(shù)字沒有具體分類。首位數(shù)字有5
種取值可能：

o 1xx:：保留，將來使用。

o 2xx：成功－操作被接收、理解、接受（received, understood, accepted）。

o 3xx：重定向（Redirection）－要完成請(qǐng)求必須進(jìn)行進(jìn)一步操作。

o 4xx：客戶端出錯(cuò) －請(qǐng)求有語(yǔ)法錯(cuò)誤或無法實(shí)現(xiàn)。

o 5xx：服務(wù)器端出錯(cuò) －服務(wù)器無法實(shí)現(xiàn)合法的請(qǐng)求。

HTTP/1.0的狀態(tài)代碼、原因解釋在下面給出。下面的原因解釋只是建議采用，可任意
更改，而不會(huì)對(duì)協(xié)議造成影響。完整的代碼定義在第9節(jié)。

HTTP狀態(tài)代碼是可擴(kuò)展的，而只有上述代碼才可以被當(dāng)前全部的應(yīng)用所識(shí)別。HTTP
應(yīng)用不要求了解全部注冊(cè)的狀態(tài)代碼，當(dāng)然，如果了解了更好。實(shí)際上，應(yīng)用程序必須理解
任何一種狀態(tài)代碼，如果碰到不識(shí)別的情況，可根據(jù)其首位數(shù)字來判斷其類型并處理。另外，
不要緩存無法識(shí)別的回應(yīng)。

例如，如果客戶端收到一個(gè)無法識(shí)別的狀態(tài)碼431，可以安全地假定是請(qǐng)求出了問題，
可認(rèn)為回應(yīng)的狀態(tài)碼就是400。在這種情況下，用戶代理應(yīng)當(dāng)在回應(yīng)消息的實(shí)體中通知用戶，
因?yàn)閷?shí)體中可以包括一些人類可以識(shí)別的非正常狀態(tài)的描述信息。

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 回應(yīng)標(biāo)題域
回應(yīng)標(biāo)題域中包括不能放在狀態(tài)行中的附加回應(yīng)信息。該域還可以存放與服務(wù)器相關(guān)的
信息，以及在對(duì)請(qǐng)求URI所指定資源進(jìn)行訪問的下一步信息。

回應(yīng)標(biāo)題域名只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，新
的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識(shí)別，其語(yǔ)法就可使用，而無法識(shí)別的標(biāo)題域都將被
視為實(shí)體域。

8 實(shí)體
如不受請(qǐng)求方法或回應(yīng)狀態(tài)編碼限制，請(qǐng)求和回應(yīng)消息可傳輸實(shí)體，實(shí)體由實(shí)體標(biāo)題域和實(shí)體主體組成，有些回應(yīng)僅包括實(shí)體頭。
在此，根據(jù)誰(shuí)發(fā)送實(shí)體、誰(shuí)接收實(shí)體，發(fā)送者和接收者可分別指用戶和服務(wù)器。
8.1 實(shí)體標(biāo)題域
實(shí)體標(biāo)題定義實(shí)體主體可選元信息，如沒有實(shí)體主體，指請(qǐng)求標(biāo)識(shí)的資源。

擴(kuò)展頭機(jī)制允許定義附加實(shí)體標(biāo)題域，而不用改變協(xié)議，但這些段不能假定接收者能識(shí)別。不可識(shí)別標(biāo)題域應(yīng)被接收者忽略，而讓代理轉(zhuǎn)發(fā)。
8.2 實(shí)體主體
見[H7.2]
　與RTSP請(qǐng)求或回應(yīng)一起發(fā)送的實(shí)體主體的格式和編碼信息都在實(shí)體標(biāo)題域
（Entity-Header）中定義。

Entity-Body = *OCTET

     實(shí)體主體只在請(qǐng)求方法有要求時(shí)才會(huì)被放在請(qǐng)求消息中。請(qǐng)求消息標(biāo)題域處的內(nèi)容長(zhǎng)度
標(biāo)題域（Content-Length header field）的標(biāo)志將指明請(qǐng)求中的實(shí)體主體是否存在。包含實(shí)體
主體的RTSP/1.0請(qǐng)求必須包含合法的內(nèi)容長(zhǎng)度標(biāo)題域。

     對(duì)回應(yīng)消息來說，消息中是否包含實(shí)體主體取決于請(qǐng)求方法和回應(yīng)代碼。所有的HEAD
請(qǐng)求方法的回應(yīng)都不應(yīng)包括主體，即便是實(shí)體標(biāo)題域中指明有主體也一樣。在主體中不應(yīng)包
括這些回應(yīng)信息，全部1xx（信息）、204（無內(nèi)容）和304（未修改）。而其它的回應(yīng)必須包
括實(shí)體主體或其內(nèi)容長(zhǎng)度標(biāo)題（Content-Length header）域的定義值為0。

9 連接
　 RTSP請(qǐng)求可以幾種不同方式傳送：
　 1、持久傳輸連接，用于多個(gè)請(qǐng)求/回應(yīng)傳輸。
　 2、每個(gè)請(qǐng)求/回應(yīng)傳輸一個(gè)連接。
　 3、無連接模式。
　傳輸連接類型由RTSP URI來定義。對(duì) \"rtsp\" 方案，需要持續(xù)連接；而\"rtspu\"方案，調(diào)用RTSP 請(qǐng)求發(fā)送，而不用建立連接。
　不象HTTP，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請(qǐng)求。然而，這僅在持久連接時(shí)才支持，否則媒體服務(wù)器沒有可靠途徑到達(dá)用戶，這也是請(qǐng)求通過防火墻從媒體服務(wù)器傳到用戶的唯一途徑。

9.1 流水線操作
　支持持久連接或無連接的客戶端可能給其請(qǐng)求排隊(duì)。服務(wù)器必須以收到請(qǐng)求的同樣順序發(fā)出回應(yīng)。
9.2 可靠性及確認(rèn)
如果請(qǐng)求不是發(fā)送給組播組，接收者就確認(rèn)請(qǐng)求，如沒有確認(rèn)信息，發(fā)送者可在超過一個(gè)來回時(shí)間（RTT）后重發(fā)同一信息。 RTT在TCP中估計(jì)，初始值為500 ms。應(yīng)用緩存最后所測(cè)量的RTT，作為將來連接的初始值。
如使用一個(gè)可靠傳輸協(xié)議傳輸RTSP，請(qǐng)求不允許重發(fā)，RTSP應(yīng)用反過來依賴低層傳輸提供可靠性。
如兩個(gè)低層可靠傳輸（如TCP 和RTSP）應(yīng)用重發(fā)請(qǐng)求，有可能每個(gè)包損失導(dǎo)致兩次重傳。由于傳輸棧在第一次嘗試到達(dá)接收著者前不會(huì)發(fā)送應(yīng)用層重傳，接收者也不能充分利用應(yīng)用層重傳。如包損失由阻塞引起，不同層的重發(fā)將使阻塞進(jìn)一步惡化。
時(shí)標(biāo)頭用來避免重發(fā)模糊性問題，避免對(duì)圓錐算法的依賴。
每個(gè)請(qǐng)求在CSeq頭中攜帶一個(gè)系列號(hào)，每發(fā)送一個(gè)不同請(qǐng)求，它就加一。如由于沒有確認(rèn)而重發(fā)請(qǐng)求，請(qǐng)求必須攜帶初始系列號(hào)。
　實(shí)現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP ，并支持UDP。對(duì)UDP和TCP，RTSP服務(wù)器的缺省端口都是554。許多目的一致的RTSP包被打包成單個(gè)低層PDU或TCP流。RTSP數(shù)據(jù)可與RTP和RTCP包交叉。不象HTTP，RTSP信息必須包含一個(gè)內(nèi)容長(zhǎng)度頭，無論信息何時(shí)包含負(fù)載。否則，RTSP包以空行結(jié)束，后跟最后一個(gè)信息頭。

本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/sendy888/archive/2007/12/19/1953288.aspx

posted on 2009-07-22 11:17 阿蜜果閱讀(2120) 評(píng)論(0) 編輯收藏所屬分類: 協(xié)議

新用戶注冊(cè) 刷新評(píng)論列表


只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關(guān)文章: SIP常用消息實(shí)例參考蜜果私塾：使用SIPP來進(jìn)行SIP壓力測(cè)試（2）【電信知識(shí)】RFC3581——SIP中的rport機(jī)制【轉(zhuǎn)】SIP 擴(kuò)展與相關(guān) RFC 介紹蜜果私塾：http協(xié)議學(xué)習(xí)和總結(jié)系列——深入了解篇蜜果私塾：http協(xié)議學(xué)習(xí)和總結(jié)系列——協(xié)議詳解篇蜜果私塾：使用SIPP來進(jìn)行SIP壓力測(cè)試(一) 使用Wireshark進(jìn)行SIP包解析【轉(zhuǎn)】RFC3550 RTP 中文版蜜果私塾：RTSP實(shí)例