【正文】 以是秒或者以小時(shí)：分：秒的形式表示。特殊的常數(shù)now定義為現(xiàn)場(chǎng)事件當(dāng)前瞬間。它經(jīng)常在VCR上數(shù)字顯示出來(lái)。當(dāng)處于暫停模式時(shí)，NPT停止。 any positive numbernptmm?，，?= 1*2DIGIT?，?。nptsec標(biāo)志法便于自動(dòng)生成， ntphhmmss標(biāo)志法便于人閱讀。 絕對(duì)時(shí)間utcrange?，? clock = utctime [ utctime ]utctime?，?= utcdate T utctime Zutcdate?，?= 8DIGIT?，，，，，，，，！?選擇標(biāo)簽選項(xiàng)標(biāo)簽是用來(lái)指示RTSP新選項(xiàng)的唯一標(biāo)識(shí)符?，，ptiontag = 1*xchar當(dāng)注冊(cè)新RTSP選項(xiàng)標(biāo)簽的時(shí)候，應(yīng)該提供以下信息： *選項(xiàng)的名字和描述。 *描述更為詳細(xì)的參考文檔（如果有），比如（按推薦程度排序），RFC，公開發(fā)表的論文，專利文檔，技術(shù)報(bào)告，源代碼，或者計(jì)算機(jī)手冊(cè)。每行結(jié)束處行以CRLF標(biāo)記，但接收方需有能力將CR和LF自行解釋成行終止符。如定義得較仔細(xì)，文本協(xié)議很容易以腳本語(yǔ)言（如：Tcl、Visual Basic與Perl）實(shí)現(xiàn)研究原型。ISO 88591通過(guò)在高位填充0，直接轉(zhuǎn)成Unicode。的低層傳輸協(xié)議傳送。的。見[]********************[]：請(qǐng)求（Request）和響應(yīng)（Response）消息都使用RFC822中實(shí)體傳輸部分規(guī)定（作為消息中的有效載荷）的消息格式。startline = RequestLine | StatusLine********************每個(gè)頭部域由后緊跟冒號(hào)的名字，單空格（SP），字符及域值組成。RTSPheaderfieldname of token, tspecials, and quotedstring頭部域接收的順序并不重要，但良好的習(xí)慣是，先發(fā)送主頭部，然后是請(qǐng)求頭部或響應(yīng)頭部，最后是實(shí)體頭部。********************[]：RTSP消息的消息主體（如果有）用來(lái)攜帶請(qǐng)求或響應(yīng)的主體。傳輸編碼必須能解釋所有保證傳輸安全和正確的應(yīng)用程序的傳輸編碼。而對(duì)于響應(yīng)消息來(lái)說(shuō)，無(wú)論消息中是否存在消息主體都與請(qǐng)求方法和響應(yīng)狀態(tài)編碼無(wú)關(guān)。********************2.（關(guān)閉連接不能被用于指示請(qǐng)求主體（request body）的結(jié)束，因?yàn)槟菢訉⑹狗?wù)器無(wú)法回送響應(yīng)。假如返回了長(zhǎng)度適當(dāng)?shù)谋硎久枋?，服?wù)器應(yīng)該總是可以確定它的長(zhǎng)度即便它是動(dòng)態(tài)產(chǎn)生，使得沒有必要采用塊傳輸編碼。 Section | Via6 請(qǐng)求 5章 請(qǐng)求行 | ANNOUNCE Section | PAUSE 。 Section 。 Section Section |extensionmethod requestheader 。 。 。 | IfModifiedSince Section Referer UserAgent注意：相對(duì)于HTTP/[2]而言，RTSP請(qǐng)求總是包含絕對(duì)URL（包括rtsp或rtspu前綴，主機(jī)，端口號(hào)）而不僅僅是絕對(duì)路徑。 Section 5| responseheader 。 CRLF這些狀態(tài)碼的完整定義在第十一章。HTTP/、對(duì)應(yīng)原因解釋在下面給出。 。 | 200 存儲(chǔ)空間不足 。 | 301 見其他 。 | 305 未通過(guò)認(rèn)證 。 | 403 不允許該方法 。 | 407 需要長(zhǎng)度 。 | 413 媒體類型不支持 。 | 452 找不到會(huì)話 。 | 456 參數(shù)是只讀的 。 | 460 無(wú)法到達(dá)目的地址 。 | 501 無(wú)法得到服務(wù) 。 | 505 原因解釋 = *文本, 包括 CR, LF的響應(yīng)。代碼 所有 OK300 見其他 所有305 未通過(guò)認(rèn)證所有402 禁止 所有406 所有408 不在服務(wù)器所有411 預(yù)處理失敗 DESCRIBE, SETUP 413 請(qǐng)求URI過(guò) 所有457參數(shù)是只讀的 所有461 所有 服務(wù)器內(nèi)部錯(cuò)誤 所有501 所有503 網(wǎng)關(guān)超時(shí) 響應(yīng)頭部域使得請(qǐng)求接收方可以發(fā)送不能放在狀態(tài)行中的附加響應(yīng)信息。 。 | Public Section 盡管如此，響應(yīng)頭部域語(yǔ)法中可能會(huì)加入新的或?qū)嶒?yàn)性的頭部域只要通訊各方能識(shí)別它是響應(yīng)頭部域，其語(yǔ)法就可使用。如不受請(qǐng)求方法或響應(yīng)狀態(tài)碼限制，請(qǐng)求和響應(yīng)消息可以傳送任何實(shí)體。 Allow 。 ContentLanguage Section | 。 ContentLocation Section | 。 extensionheader extensionheader不被識(shí)別的頭部域應(yīng)被接收者忽略，而讓代理發(fā)送。9 連接 RTSP請(qǐng)求可以幾種不同方式傳送： *持久傳輸連接，用于多個(gè)請(qǐng)求響應(yīng)傳輸。rtsp 方案說(shuō)明需要持續(xù)連接；而rtspu方案，則要求不建立連接就直接發(fā)送RTSP請(qǐng)求。這也是通過(guò)防火墻從媒體服務(wù)器傳送請(qǐng)求到用戶的唯一辦法。后重發(fā)同一信息。如使用可靠傳輸協(xié)議來(lái)承載RTSP，則請(qǐng)求不允許重發(fā)，RTSP應(yīng)用程序必須依賴低層傳輸協(xié)議來(lái)保證可靠性。若丟包由網(wǎng)絡(luò)阻塞引起，多個(gè)層上的的共同重發(fā)將使阻塞進(jìn)一步惡化。如果由于缺少確認(rèn)而重發(fā)一個(gè)請(qǐng)求，該請(qǐng)求必須攜帶原來(lái)的序列號(hào)（即是說(shuō)，序列號(hào)不增加）。一定數(shù)量的發(fā)往同一個(gè)控制末端的包可以放進(jìn)一個(gè)低層PDU或者封裝進(jìn)一個(gè)TCP流里。方法名稱不應(yīng)以$符號(hào)（數(shù)字24）開始，并且必須是一個(gè)關(guān)鍵字。 方法 DESCRIBE 推薦 P,S GET_PARAMETER CS, SC CS, SC P,S OPTIONS P,S CS, SC方向方法是大小寫敏感的。和HTTP不同，一條RTSP消息只要包含載荷（payload），就必須包含內(nèi)容長(zhǎng)度頭部。支持RTSP的系統(tǒng)必須支持通過(guò)TCP承載RTSP，然后也可以支持通過(guò)UDP承載。如果RTSP被用在小RTT如低層可靠傳輸協(xié)議（如TCP）和RTSP應(yīng)用程序都重發(fā)請(qǐng)求，有可能每次丟包都導(dǎo)致兩次重傳。一個(gè)實(shí)現(xiàn)可能會(huì)緩存最后所測(cè)量的RTT，作為將來(lái)連接的初始值。接受方需要確認(rèn)請(qǐng)求，除非請(qǐng)求是發(fā)給多播組。 支持持久連接或無(wú)連接的客戶端可能會(huì)使用管道方式傳送請(qǐng)求（即是說(shuō)：發(fā)送多個(gè)請(qǐng)求而不需等待單個(gè)的響應(yīng)）。 管道和HTTP不同的是，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請(qǐng)求。 實(shí)體主體 messageheader LastModified 。 Expires 。 | Section ContentBase 。實(shí)體頭部域定義了實(shí)體主體的可選元信息；如沒有實(shí)體主體，那些定義則是關(guān)于請(qǐng)求標(biāo)識(shí)的資源的。 Section Section Section RetryAfter | 。 ProxyAuthenticate | 。 Location =表一: 狀態(tài)碼及適用RTSP方法所有551所有505 網(wǎng)關(guān)錯(cuò)誤 無(wú)法到達(dá)目的地址 只允許合控制SET_PARAMETER459 此頭部域?qū)υ撡Y源無(wú)效 所有455 找不到會(huì)話 SETUP453 找不到會(huì)議 所有451 媒體類型不支持 代理需要認(rèn)證 不允許該方法 所有404400 所有302 被永久移除 錄制250 已創(chuàng)建 繼續(xù) 原因在這種情況下，用戶界面應(yīng)當(dāng)在把響應(yīng)消息的實(shí)體顯示給用戶，因?yàn)閷?shí)體中可能包括一些人類可以識(shí)別的關(guān)于此非正常狀態(tài)的描述信息。RTSP應(yīng)用程序不被要求了解全部注冊(cè)的狀態(tài)碼，當(dāng)然很明顯這種了解是被期望的。 擴(kuò)展碼 | 。 不支持此RTSP版本 503 | 。 未實(shí)現(xiàn) 462 | 。 只允許合控制 458 | 。 此頭部域?qū)υ撡Y源無(wú)效 454 | 。 找不到會(huì)議 415 | 。 請(qǐng)求實(shí)體過(guò)長(zhǎng) 411 | 。 請(qǐng)求超時(shí) 代理需要認(rèn)證 405 | 。 禁止 401 | 。 使用代理 303 | 。 被永久移除 250 | 。 OK 狀態(tài)碼注意：RTSP采用了大多數(shù)HTTP/ [2]狀態(tài)碼，并增加了一些形如x50的RTSP特有的狀態(tài)碼以避免與最新定義的HTTP狀態(tài)碼沖突。 *5xx：服務(wù)器端出錯(cuò) 服務(wù)器無(wú)法滿足合法的請(qǐng)求。 *4xx：客戶端出錯(cuò) 請(qǐng)求有語(yǔ)法錯(cuò)誤或無(wú)法實(shí)現(xiàn) *1xx：通知 已收到請(qǐng)求，繼續(xù)處理首位數(shù)字有5取值可能：狀態(tài)碼用來(lái)支持自動(dòng)操作，原因解釋用來(lái)方便人的查看。 響應(yīng)消息的第一行就是狀態(tài)行，它由協(xié)議版本、數(shù)字形式的狀態(tài)碼、與狀態(tài)碼對(duì)應(yīng)的文本解釋依次組成，各元素間以空格（SP）分隔，除了結(jié)尾的CRLF外，不允許出現(xiàn)CR或LF符。 Section [ messagebody ] Section generalheader 。 StatusLine =還有，RTSP增加了一些狀態(tài)碼，也棄用了一些HTTP狀態(tài)碼。如下面的例子：HTTP/ 要求服務(wù)器能夠理解絕對(duì)URL, 但還是期望客戶端使用主機(jī)請(qǐng)求頭部。 。 Section Section Range Section 。 | | | Accept 請(qǐng)求頭部域 extensionmethod = token 。 Section REDIRECT | PLAY | Section 。 請(qǐng)求行 = 方法 空格 請(qǐng)求URI 空格 RTSP版本 CRLF [ messagebody ] 。 。 Date | Section Connection | Section 注意：RTSP目前并不支持HTTP/塊傳輸編碼(見 [])，需要有內(nèi)容頭部域。 如果存在內(nèi)容長(zhǎng)度頭部域（ContentLength header field），它的值（單位為byte）就表示消息體的長(zhǎng)度。（注意：空行中只有CRLF。當(dāng)信息體包含在信息中時(shí)，信息體長(zhǎng)度由如下因素決定（按優(yōu)先度排列）： 所有1（信息），204（無(wú)內(nèi)容），304（未修改）響應(yīng)都不包含消息主體。只有當(dāng)請(qǐng)求方法允許有實(shí)體主體的時(shí)候才能在請(qǐng)求中包含消息主體。（見[]）而且必須能在不改變消息語(yǔ)法的前提下，將并發(fā)的域值加到第一個(gè)值后面，之間用逗號(hào)分隔，最終能將多個(gè)頭部域結(jié)合成域名：域值對(duì)。 = the OCTETs make up the fieldvalue = *( fieldcontent | LWS )雖然不提倡，頭部域還是可以擴(kuò)展成多行使用，只要這些行以一個(gè)以上的SP或HT開頭就行。見[]。換句話說(shuō)，如果服務(wù)器正在讀協(xié)議流，在一個(gè)消息開始時(shí)如果首先收到了CRLF，這個(gè)CRLF符應(yīng)被忽略。 。請(qǐng)求包括方法、方法作用于其上的對(duì)象和進(jìn)一步描述方法的參數(shù)。(見 RFC 2279 [21])10646字