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