【正文】 必要 可選要求 將來(lái)可能會(huì)定義新的方法。否則，一個(gè)RTSP包通過(guò)最后一個(gè)消息頭部后的第一個(gè)空行馬上截止。UDP和TCP的默認(rèn)RTSP端口都是554.每個(gè)請(qǐng)求都帶有一個(gè)序列號(hào)，位于CSeq頭部（），每發(fā)出一個(gè)單獨(dú)的請(qǐng)求，這個(gè)序列號(hào)就加一。網(wǎng)絡(luò)，使用標(biāo)準(zhǔn)的初始TCP RTT時(shí)間測(cè)量?jī)?yōu)化過(guò)程，像T/TCP (RFC 1644) [22]那樣，將是有益的。由于傳輸棧在第一次嘗試到達(dá)接收者以前不會(huì)發(fā)送應(yīng)用層重傳，所以接收者并不能充分利用應(yīng)用層重傳。如沒(méi)有確認(rèn)信息，發(fā)送者可在超過(guò)一個(gè)來(lái)回時(shí)間（RTT）服務(wù)器必須以和收到的請(qǐng)求同樣的順序發(fā)出響應(yīng)。然而，這僅在持久連接模式中才支持，否則媒體服務(wù)器沒(méi)有可靠途徑到達(dá)用戶。傳輸連接類(lèi)型由RTSP URI（）來(lái)定義。見(jiàn)[]及其全部子章節(jié)擴(kuò)展頭部機(jī)制允許定義附加實(shí)體頭部域，而不用改變協(xié)議，但并不能假定接收者能識(shí)別這些附加域。 =| Section | Section ContentType 。 ContentLength 。 | Section entityheader 在本章中，根據(jù)誰(shuí)發(fā)送實(shí)體、誰(shuí)接收實(shí)體，用戶和服務(wù)器都可能指發(fā)送者或者接收者。8 實(shí)體 響應(yīng)頭部域名只有在與協(xié)議版本的變化結(jié)合起來(lái)后，才能進(jìn)行可靠的擴(kuò)展。 Server | 。 Section Section 響應(yīng)頭部域 無(wú)法得到服務(wù)所有502 未實(shí)現(xiàn)所有462 傳輸方式不支持所有460 無(wú)效范圍所有456SETUP454SETUP452所有415 請(qǐng)求實(shí)體過(guò)長(zhǎng) 需要長(zhǎng)度 請(qǐng)求超時(shí) 所有407 不接受 所有405 需要付費(fèi) 使用代理 所有301 有多個(gè)選項(xiàng)錄制 所有201100盡管如此，應(yīng)用程序【必須】理解任何一個(gè)狀態(tài)碼的首位所標(biāo)識(shí)的類(lèi)別，將任何不理解的狀態(tài)碼等同為那個(gè)類(lèi)的x00狀態(tài)碼，只是【必須不】緩存無(wú)法識(shí)別 不支持選項(xiàng) 504 | 。 網(wǎng)關(guān)錯(cuò)誤 500 | 。 傳輸方式不支持 459 | 。 無(wú)效范圍 455 | 。 帶寬不足 451 | 。 請(qǐng)求URI過(guò)長(zhǎng) 412 | 。 不在服務(wù)器 406 | 。 沒(méi)有找到 402| 。 錯(cuò)誤的請(qǐng)求 304 | 。 被臨時(shí)移除 300 | 。 已創(chuàng)建 100 =客戶端不需要檢查或顯示原因解釋。狀態(tài)行 = HTTP版本 空格 狀態(tài)碼 空格 原因解釋 CRLF 狀態(tài)碼和原因解釋狀態(tài)碼（StatusCode）由3位數(shù)字組成，表示請(qǐng)求是否被理解或被滿足。 狀態(tài)行 。 *( Section Response在表一中，對(duì)有效的響應(yīng)碼和可用的方法進(jìn)行了定義。OPTIONS * RTSP/。這樣做完全是為了向后兼容HTTP/，因此在RTSP中不需要這樣做。 Section || 。 | Section Authorization AcceptLanguage AcceptEncoding RequestURI = * | absolute_URI Section 。 SET_PARAMETER | 。 。 Section 。 GET_PARAMETER | Section CRLF | entityheader ) 。 | requestheader 。 *( generalheader 。Request = RequestLine 。 Section 。 除了Pragma、TransferEncoding 和 Upgrade頭部，其余見(jiàn)[]5 普通頭部域 通過(guò)服務(wù)器關(guān)閉連接。如果此頭部域沒(méi)有出現(xiàn)，則假設(shè)其值為0。）1.而其他響應(yīng)則都包含主體，盡管其長(zhǎng)度有可能長(zhǎng)度為零。什么時(shí)候允許消息帶消息體的規(guī)則在請(qǐng)求和響應(yīng)兩種情況下有所不同。messagebody = entitybody| entitybody encoded as per TransferEncoding******************** 消息主體見(jiàn)[]。fieldcontent = tokenfieldvalue = fieldname : [ fieldvalue ] CRLF RTSP頭部域，包括主頭部（GeneralHeader,）、請(qǐng)求頭部（RequestHeader ,）、響應(yīng)頭部（ResponseHeader ,）及實(shí)體頭部（EntityHeader,），[7]給出的通用格式定義。********************[]：genericmessage = startline *messageheaderCRLF[ messagebody ] RTSP / messagesRTSP message = Request | Response 消息類(lèi)型除非另外說(shuō)明，否則方法是冪等RTSP信息可通過(guò)任何8bit cleanRTCP也采用這種編碼方案。由于參數(shù)的數(shù)量和命令出現(xiàn)的頻率較低，處理效率不予考慮。 RTSP是基于文本的協(xié)議，采用ISO 10646 字符集和UTF8編碼方案。4 RTSP消息 *指出誰(shuí)擁有選項(xiàng)的改變控制權(quán)（例如，IETF，國(guó)際標(biāo)準(zhǔn)化組織，國(guó)際電信聯(lián)盟T，其他的國(guó)際標(biāo)準(zhǔn)化體，一個(gè)團(tuán)體，一個(gè)公司，或者一組公司）。 用IANA注冊(cè)新的選項(xiàng)標(biāo)簽語(yǔ)法： 語(yǔ)法遵循ISO 8601規(guī)則。 例如： npt= npt=12:05: npt=nownptrange?，? ( npttime [ npttime ] ) | ( npttime )npttime?，?= now | nptsec | npthhmmssnptsec?，，? 1*DIGIT [ . *DIGIT ]npthhmmss = npthh : nptmm : nptss [ . *DIGIT ]npthh?，，?= 1*DIGIT?，?。當(dāng)處于反向掃描模式(倍速小于1)時(shí)，NPT快速后退。在DSM CC中，正常播放時(shí)間（NPT）是這樣定義的：直觀地講，NPT是用戶和程序聯(lián)系的時(shí)鐘。負(fù)值沒(méi)有意義。正常播放時(shí)間(NPT)指示流相對(duì)于表示(presentation)開(kāi)始的位置。幀域（frames field）的時(shí)間值在0到29之間。相對(duì)時(shí)間戳以SMPTE時(shí)間編碼形式表示以保證幀級(jí)的訪問(wèn)精度。（詳見(jiàn)16章）會(huì)話標(biāo)識(shí)符是非直讀這些會(huì)議是用該規(guī)范之外的協(xié)議創(chuàng)建的， [13] 或 SIP [12]協(xié)議。將用到會(huì)議的標(biāo)識(shí)值。簡(jiǎn)單替換URL中的前綴后，表示描述同樣可以用于非RTSP媒體控制協(xié)議。這里并沒(méi)有暗示相關(guān)流URL的標(biāo)準(zhǔn)。注意，某些請(qǐng)求方法只能用于流，而不能用于表示，反之亦然。（請(qǐng)參考RFC1924）語(yǔ)義如下：擁有被請(qǐng)求的資源的服務(wù)器主機(jī)通過(guò)監(jiān)聽(tīng)TCP連接(rtsp方案)或主機(jī)上相應(yīng)端口的UDP包(rtspu方案)，來(lái)控制所標(biāo)記的資源。 | = | + escape uchar = uchar | : | | amp。 | ? ) scheme = *( pchar | / ) = fsegment *( / segment ) path params ] [ ? query ] = / rel_path abs_path********************[]：port本節(jié)詳細(xì)定義了RTSP URL的語(yǔ)法和語(yǔ)義。代理或網(wǎng)關(guān)響應(yīng)請(qǐng)求時(shí)必須和請(qǐng)求的版本相同。應(yīng)用的RTSP版本即為應(yīng)用至少能有條件遵循的RTSP版本中的最高版本。版本號(hào)前面的0將被接收方忽略，而在發(fā)送方處也不應(yīng)產(chǎn)生。 RTSP消息的版本由消息第一行中的RTSP版本域來(lái)表示。當(dāng)協(xié)議消息的主要解析算法沒(méi)變，而消息語(yǔ)法及發(fā)送方的隱含功能增加了，將會(huì)導(dǎo)致從版本號(hào)（minor）增加；當(dāng)協(xié)議中消息的格式變化了，主版本號(hào)（major）也將發(fā)生改變。 RTSP采用主從（major.minor）數(shù)字形式來(lái)表示版本。 同[]定義，僅用RTSP代替HTTP即可。 RTSP版本 在本備忘錄中，我們用縮進(jìn)的小型段落來(lái)提供背景和動(dòng)機(jī)。********************隱含*LWS（implied *LWS）本文的語(yǔ)法描述是基于單詞的。缺省值是0到無(wú)限，即（元素）表示可取任何數(shù)值，包括0；而1元素表示至少有1個(gè)；而12元素表示有1個(gè)或2個(gè)。如［元素1 元素2］與*1（元素1 元素2）是一回事。*規(guī)則（*rule）在元素前加星號(hào)*表示循環(huán)，其完整形式是n*m元素，表明元素最少產(chǎn)生n次，最多m次。 ｜表示其分隔的元素是可選的，比如，是｜否要選擇‘是’或‘否’。字面意思（literal）如果規(guī)則需要用多個(gè)行來(lái)描述，利用空格進(jìn)行縮進(jìn)格式排版。此形式在RFC 2234中有詳細(xì)的描述，唯一的不同是RTSP中以1代替,為分隔符。 既然很多定義和語(yǔ)法與HTTP/，這里僅指出它們?cè)贖TTP/。2 符號(hào)約定要求非常接近，在緩存、代理和授權(quán)上采用HTTP功能是有價(jià)值的。RTSP中，媒體用戶和服務(wù)器都可發(fā)送請(qǐng)求。例如，表示描述(presentation description)可通過(guò)HTTP和RTSP得到，這降低了基于瀏覽器的應(yīng)用模式的往返傳遞，也允許完全不依賴HTTP的獨(dú)立RTSP 服務(wù)器與客戶端。 啟動(dòng)SETUP所分配的流的數(shù)據(jù)傳輸。 SETUP： 因此，即使媒體服務(wù)器沒(méi)有收到請(qǐng)求，數(shù)據(jù)也會(huì)繼續(xù)發(fā)送。會(huì)議描述的建立不在此規(guī)范中討論。多播，用戶選擇地址： 以用戶選擇的端口號(hào)將媒體發(fā)送到RTSP請(qǐng)求的來(lái)源處。下面區(qū)分幾種操作模式： RTSP URL指出了處理具體媒體流的服務(wù)器以及存在于該服務(wù)器上流的名字。為簡(jiǎn)明但不失一般性，假定表示描述(presentation description)正好包含一個(gè)這樣的表示(presentation)。 每個(gè)表示和媒體流可用RTSP URL識(shí)別。 整體運(yùn)作 客戶端可以用OPTIONS方法去詢問(wèn)服務(wù)器支持的方法。 擴(kuò)展RTSP由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同的請(qǐng)求集。 例如，如果不允許尋找，用戶界面必須能禁止位置條滑動(dòng)。 若客戶端能啟動(dòng)一個(gè)流，它必須也能停止一個(gè)流。 此處，RTSP明智地重用了HTTP概念，使現(xiàn)有的基礎(chǔ)結(jié)構(gòu)可被重用。 RTSP依賴SMPTE時(shí)間戳支持幀級(jí)精度，使得可以進(jìn)行遠(yuǎn)程數(shù)字編輯。適合專業(yè)應(yīng)用： RTSP即可使用不可靠數(shù)據(jù)報(bào)協(xié)議（UDP）、可靠數(shù)據(jù)報(bào)協(xié)議（RDP），如要實(shí)現(xiàn)應(yīng)用級(jí)可靠，也可使用可靠流協(xié)議如TCP。 RTSP重用傳輸初始化： 包括一次RTSP事務(wù)（transaction）的全過(guò)程。響應(yīng)：?，TSP響應(yīng)。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息，的集合。表示描述(presentation description)： 作為一個(gè)完整的媒體信