RFC2326(中文版)-實(shí)時(shí)流協(xié)議(RTSP)

RFC2326(中文版)-實(shí)時(shí)流協(xié)議(RTSP).txt我的人生有A面也有B面，你的人生有S面也有B面。失敗不可怕，關(guān)鍵看是不是成功他媽。現(xiàn)在的大學(xué)生太沒素質(zhì)了！過來拷毛片，居然用剪切！有空學(xué)風(fēng)水去，死后占個(gè)好墓也算彌補(bǔ)了生前買不起好房的遺憾。實(shí)時(shí)流協(xié)議(RTSP)(RealTimeStreamingProtocol(RTSP))備忘錄的狀態(tài)：本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建議以得到改進(jìn)。請參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)”(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。版權(quán)聲明：版權(quán)為TheInternetSociety所有。所有權(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)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP(RFC1889)上傳送機(jī)制提供方法。目錄：1緒論51.1目的51.2要求61.3術(shù)語61.4協(xié)議特點(diǎn)71.5RTSP擴(kuò)展81.6操作模式91.7RTSP狀態(tài)91.8與其他協(xié)議關(guān)系102符號協(xié)定103協(xié)議參數(shù)103.1RTSP版本103.2RTSPURL113.3會議標(biāo)識133.4會話標(biāo)識133.5SMPTE相對時(shí)間戳133.6正常播放時(shí)間143.7絕對時(shí)間153.8選擇標(biāo)簽153.8.1用IANA注冊新的選擇標(biāo)簽154RTSP消息154.1消息類型164.2消息標(biāo)題174.3消息主體174.4消息長度185普通標(biāo)題域186請求196.1請求隊(duì)列196.2請求標(biāo)題域197回應(yīng)207.1狀態(tài)行207.1.1狀態(tài)代碼和原因分析207.1.2回應(yīng)標(biāo)題域238實(shí)體238.1實(shí)體標(biāo)題域248.2實(shí)體主體249連接259.1流水線操作259.2可靠性及確認(rèn)2510方法定義2510.1選擇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ù)2911狀態(tài)代碼定義（StatusCodeDefinitions）2911.1成功2xx（Success2xx）3011.1.1存儲空間低2503011.2重定向（Redirection3xx）3111.3客戶端錯(cuò)誤（ClientError）4xx3111.3.1方法不允許3211.3.2參數(shù)不能理解3211.3.3會議未找到3311.3.4帶寬不足3311.3.5會話未找到3411.3.6本狀態(tài)下該方法無效3411.3.7標(biāo)題域?qū)Y源無效3411.3.8無效范圍3511.3.9參數(shù)只讀3511.3.10不允許合操作3611.3.11只允許合操作3611.3.12不支持的傳輸3611.3.13目標(biāo)不可達(dá)3711.3.14選擇不支持3712標(biāo)題域定義（HeaderFieldDefinitions）3812.1接受3812.2接受編碼3812.3接受語言3912.4允許（Allow）3912.5授權(quán)（Authorization）4012.6帶寬4012.7塊大小4012.8緩存控制4112.9會議4112.10連接4112.11基本內(nèi)容4212.12內(nèi)容編碼（Content-Encoding）4212.13內(nèi)容語言4312.14內(nèi)容長度（Content-Length）4312.15內(nèi)容位置4312.16內(nèi)容類型（Content-Type）4412.17序列號4412.18日期（Date）4412.19過期（Expires）4512.20來自（From）4512.21主機(jī)4512.22如果匹配4512.23從何時(shí)更改（If-Modified-Since）4612.24最近更改（Last-Modified）4612.25位置（Location）4612.26代理授權(quán)4712.27代理要求4712.28公用性4712.29范圍4912.30提交方（Referer）4912.31稍后再試4912.32要求4912.33RTP信息4912.34比例4912.35速度4912.36服務(wù)器（Server）4912.37會話4912.38時(shí)間戳4912.39傳輸4912.40不支持4912.41用戶代理（User-Agent）4912.42變化4912.43通過4912.44WWW-授權(quán)（WWW-Authenticate）5013緩存5014實(shí)例5014.1要求媒體（單播）5014.2容器文件的流5114.3單個(gè)流容器文件5114.4組播現(xiàn)場媒體表示5114.5在存在的會話中播放媒體5114.6錄制5215語法5215.1基本語法5216安全考慮（SecurityConsiderations）52附錄ARTSP協(xié)議狀態(tài)機(jī)53A.1客戶端狀態(tài)機(jī)53A.2服務(wù)器端狀態(tài)機(jī)53附錄B同RTP協(xié)議的交互53附錄C使用SDP進(jìn)行RTSP會話描述54C.1定義54C.1.1控制URL55C.1.2媒體流55C.1.3有效載荷類型55C.1.4詳細(xì)格式參數(shù)55C.1.5表示的范圍56C.1.6有效時(shí)間56C.1.7連接信息56C.1.8實(shí)體標(biāo)簽57C.2合控制不可用57C.3合控制可用57附錄D最簡單的RTSP實(shí)現(xiàn)58D.1客戶端58D.1.1回放58D.1.2授權(quán)58D.2服務(wù)器59D.2.1回放59D.2.2授權(quán)59附錄E作者地址60附錄F致謝60參考書目60版權(quán)申明611緒論1.1目的實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流有可能交叉，但RTSP本身通常并不發(fā)送連續(xù)媒體流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。表示描述(presentationdescription)定義了被控流，但本文并沒有定義表示描述的格式。這里沒有使用RTSP連接的概念，而由RTSP會話(session)代替（每次服務(wù)由服務(wù)器端保持一個(gè)帶標(biāo)簽的會話）。RTSP會話沒有綁定到傳輸層連接（如TCP連接）。因?yàn)殡m然在RTSP會話期間，RTSP客戶端可打開或關(guān)閉多個(gè)對服務(wù)器端的可靠傳輸連接以發(fā)出RTSP請求。但此外，也可能使用無連接傳輸協(xié)議，比如用UDP發(fā)送RTSP請求。RTSP控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。實(shí)時(shí)流協(xié)議在語法和操作上與HTTP/1.1類似，因此HTTP的擴(kuò)展機(jī)制大都可加入RTSP。盡管如此，RTSP在很多方面還是和HTTP有很大的不同：2RTSP引入了很多新方法并且有不同的協(xié)議標(biāo)識符。2RTSP服務(wù)器在大多數(shù)默認(rèn)情況下需要維持一個(gè)狀態(tài)，但HTTP是無狀態(tài)協(xié)議。2RTSP客戶機(jī)和服務(wù)器都可以發(fā)出請求。2數(shù)據(jù)由另一個(gè)協(xié)議傳送（有一特例除外）。2RTSP使用ISO10646(UTF-8)而不是ISO8859-1，以配合當(dāng)前HTML的國際化。2RTSP使用URI請求時(shí)包含絕對URI。而由于歷史原因造成的向后兼容性問題，HTTP/1.1只在請求中包含絕對路徑，把主機(jī)名放入單獨(dú)的標(biāo)題域中。這使得“虛擬主機(jī)”實(shí)現(xiàn)更為簡便，一個(gè)單獨(dú)IP地址的主機(jī)可虛擬為幾個(gè)文件樹主機(jī)。協(xié)議支持的操作如下：從媒體服務(wù)器上檢索媒體：用戶可通過HTTP或其它方法請求一個(gè)表示描述。如表示是組播，表示描述就包含用于連續(xù)媒體的的組播地址和端口。如表示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。媒體服務(wù)器邀請進(jìn)入會議：媒體服務(wù)器可被邀請參加正進(jìn)行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應(yīng)用上很有用，會議中幾方可輪流按遠(yuǎn)程控制按鈕。將媒體加到現(xiàn)成講座中：如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容，對現(xiàn)場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。1.2要求在本文檔中的關(guān)鍵字“必須”，“一定不能”，“要求”，“會”，“不會”，“應(yīng)該”，“不應(yīng)該”，“被推薦的”，“可以”，和“可選擇的”都在RFC2119中解釋。1.3術(shù)語一些術(shù)語原由HTTP/1.1采用。在HTTP/1.1中定義的術(shù)語這里不再列舉。合控制：服務(wù)器使用單條時(shí)間線對多個(gè)流的控制。對音頻/視頻回饋來講，這就意味著客戶端僅需發(fā)送一條播放或者暫停消息就可同時(shí)控制音頻和視頻的回饋。會議：多方參與的多媒體表示，這里的多方意味著大于或者等于一方?？蛻舳耍褐刚埱竺襟w服務(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ù)媒體的例子是音頻和動畫視頻。連續(xù)媒體可以是實(shí)時(shí)的（但是不交互的），它們在源和接受器之間是一種緊密的時(shí)序關(guān)系；或者是流的形式，這種關(guān)系就沒有那么嚴(yán)格了。實(shí)體：作為請求或者回應(yīng)的有效負(fù)荷傳輸?shù)男畔?。由以?shí)體標(biāo)題域（entity-headerfield）形式存在的元信息和以實(shí)體主體（entitybody）形式存在的內(nèi)容組成，如第八章所述。媒體的初始化：數(shù)據(jù)類型/編碼的具體初始化，這些包括時(shí)鐘輸率，顏色表等。用戶請求媒體回放的任何獨(dú)立傳輸信息，是在創(chuàng)建流時(shí)初始化媒體流相位時(shí)產(chǎn)生的。媒體參數(shù):針對回放前或回放過程中有可能改變的媒體類型而專門設(shè)定的參數(shù)。媒體服務(wù)器：可對一個(gè)或多個(gè)媒體流提供回放和錄制服務(wù)的服務(wù)器。同一個(gè)表示(presentation)中不同的媒體流可能來自于不同的媒體服務(wù)器。媒體服務(wù)器可以建立在作為傳送請求表示(presentation)的Web服務(wù)器的主機(jī)上，也可以建立在不同的主機(jī)上。媒體服務(wù)器重定向：重新定向媒體客戶端到另外一個(gè)媒體服務(wù)器。(媒體)流：單個(gè)媒體實(shí)例，比如，在應(yīng)用中共用音頻流或視頻流。當(dāng)使用RTP時(shí)，流包括由RTP會話(session)中源所創(chuàng)建的所有RTP和RTCP包。這和定義DSM-CC流時(shí)相同。消息：RTSP通訊的基本單元。由15章語法定義的一串八位位組組成，并通過連接或者無連接協(xié)議傳送。參與者：一個(gè)會議成員。參與者可以是機(jī)器，比如是媒體記錄或回放服務(wù)器。表示(presentation)：對用戶請求所回饋的一組流，其使用下面的表示描述(presentationdescription)形式。在本文中的多數(shù)情況下，其意味著對流進(jìn)行總體控制，但這并不是必須的。表示描述(presentationdescription)：表示描述包含在表示(presentation)中一個(gè)或者多個(gè)媒體流的信息。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息。另外，其他IETF協(xié)議，如SDP協(xié)議使用會話(session)代替現(xiàn)場presentation。表示描述可以采用包括會話描述(sessiondescription)SDP在內(nèi)的多種格式?；貞?yīng)：RTSP回應(yīng)。如果能理解HTTP回應(yīng)，就能清楚的理解RTSP回應(yīng)。請求；RTSP請求。如果能理解HTTP請求，就能清楚的理解RTSP請求。RTSP會話(session)：RTSP交互的全過程。比如，一個(gè)電影的觀看過程。會話(session)包括由客戶端建立連續(xù)媒體流傳輸機(jī)制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關(guān)閉流。傳輸初始化：客戶端和服務(wù)器端之間傳輸信息（端口號，傳輸協(xié)議等）的交互。1.4協(xié)議特點(diǎn)RTSP特性如下：可擴(kuò)展性：RTSP中很容易加入新方法和參數(shù)。易解析：RTSP可由標(biāo)準(zhǔn)HTTP或MIME解析器解析。安全：RTSP使用網(wǎng)頁安全機(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)用級可靠，可使用可靠流協(xié)議。多服務(wù)器支持：表示(presentation)中的每個(gè)流可放在不同服務(wù)器上，用戶端自動同不同服務(wù)器建立幾個(gè)并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。記錄設(shè)備控制：協(xié)議可控制記錄和回放設(shè)備，也可控制可在記錄和回放切換的設(shè)備。流控與會議開始分離：流控與邀請媒體服務(wù)器入會分離；僅要求會議初始化協(xié)議提供，或可用來創(chuàng)建唯一會議標(biāo)識號。特殊情況下，SIP或H.323可用來邀請服務(wù)器入會。適合專業(yè)應(yīng)用：通過SMPTE時(shí)標(biāo)，RTSP支持幀級精度，允許遠(yuǎn)程數(shù)字編輯。表示描述中立：協(xié)議沒強(qiáng)加特殊表示或元文件，可傳達(dá)所用格式類型；然而，表示描述至少必須包含一個(gè)RTSPURI。代理與防火墻友好：協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個(gè)\"缺口\"。HTTP友好：此處，RTSP明智的采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet內(nèi)容選擇平臺（PICS）。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài)，RTSP不僅僅向HTTP添加方法。適當(dāng)?shù)姆?wù)器控制：如用戶能啟動一個(gè)流，它必須也能停止一個(gè)流。服務(wù)器不能啟動一個(gè)用戶不能停止的流。傳輸協(xié)調(diào)：實(shí)際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。性能協(xié)調(diào)：如基本特征無效，必須有一些清理機(jī)制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。例如，如果不允許尋找，用戶界面必定能禁止位置條滑動。以前要求RTSP必須能支持多用戶，但現(xiàn)在得出一個(gè)更好的方法就是保證RTSP能很容易擴(kuò)展成支持多用戶即可。因?yàn)榱鞯臉?biāo)志可以被多個(gè)控制流使用，因此”遠(yuǎn)程通過”成為可能。協(xié)議不涉及到多個(gè)客戶端如何協(xié)調(diào)入口，其由下層“社會協(xié)議”或其他下層控制機(jī)制提供。1.5RTSP擴(kuò)展由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同請求集。例如：?服務(wù)器可能只須支持回放，因此不必不支持錄制功能。?對于支持現(xiàn)場播放的服務(wù)器可能不支持尋找功能。?一些服務(wù)器可能不支持設(shè)置流參數(shù)，因此不支持GET_PARAMETER和SET_PARAMETER。但服務(wù)器應(yīng)該實(shí)現(xiàn)所有12章中要求的標(biāo)題域。表示描述(presentationdescription)應(yīng)當(dāng)保證不提出服務(wù)器不支持的功能，這種情形和HTTP/1.1中[H19.6]描述方法不支持acrossserver的情形一致。RTSP可以如下三種方式擴(kuò)展，這里以改變大小排序：?以新參數(shù)擴(kuò)展。如用戶需要拒絕通知，而方法擴(kuò)展不支持，相應(yīng)標(biāo)記就加入要求的段中。?加入新方法。如信息接收者不理解請求，返回501錯(cuò)誤代碼（還未實(shí)現(xiàn)），發(fā)送者不應(yīng)再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務(wù)器支持的方法。服務(wù)器使用公共回應(yīng)標(biāo)題列出支持的方法。?定義新版本協(xié)議，允許改變所有部分。（除了協(xié)議版本號位置）1.6操作模式每個(gè)表示和媒體流可用RTSPURL識別。表示組成的整個(gè)表示與媒體屬性由表示描述(presentationdescription)文件定義，表示描述格式不在本協(xié)議中定義。使用HTTP或其它途徑用戶可獲得這個(gè)文件，它沒有必要保存在媒體服務(wù)器上。為了說明，假設(shè)表示描述(presentationdescription)描述了多個(gè)表示(presentation)，其中每個(gè)表示(presentation)維持了一個(gè)公共時(shí)間軸。為簡化說明，且不失一般性，假定表示描述(presentationdescription)的確包含這樣一個(gè)表示(presentation)。表示(presentation)可包含多個(gè)媒體流。表示描述(presentationdescription)即組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數(shù)。在表示描述中，被RTSP分別控制的媒體流由RTSPURL表示。RTSPURL指出了處理具體媒體流的服務(wù)器以及存在于該服務(wù)器上流的名字。多個(gè)媒體流可以放到不同的服務(wù)器上，比如音頻和視頻流可以分別放到不同服務(wù)器而負(fù)載共享。描述（description)還列出了服務(wù)器傳輸可使用的方法。除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。下面區(qū)分幾種操作模式：單播：以用戶選擇的端口號將媒體發(fā)送到RTSP請求源。組播，服務(wù)器選擇地址：媒體服務(wù)器選擇組播地址和端口，這是現(xiàn)場直播或準(zhǔn)點(diǎn)播常用的方式。組播，用戶選擇地址：如服務(wù)器加入正在進(jìn)行的組播會議，組播地址、端口和密匙由會議描述給出。1.7RTSP狀態(tài)RTSP控制通過單獨(dú)協(xié)議發(fā)送的流，與控制通道無關(guān)。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務(wù)器沒有收到請求，數(shù)據(jù)也會繼續(xù)發(fā)送。在會話生命期，單個(gè)媒體流可通過不同TCP連接順序發(fā)出請求來控制。所以，服務(wù)器需要維持能聯(lián)系流與RTSP請求的會話狀態(tài)。RTSP中很多方法與狀態(tài)無關(guān)，但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用：SETUP：讓服務(wù)器給流分配資源，啟動RTSP會話。PLAY與RECORD：啟動SETUP分配流的數(shù)據(jù)傳輸。PAUSE：臨時(shí)停止流，而不釋放服務(wù)器資源。TEARDOWN：釋放流的資源，RTSP會話停止。標(biāo)識狀態(tài)的RTSP方法使用會話(session)標(biāo)題域識別RTSP會話，為回應(yīng)SETUP請求，服務(wù)器生成會話標(biāo)識。1.8與其他協(xié)議關(guān)系RTSP在功能上與HTTP有重疊，與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務(wù)器與實(shí)現(xiàn)RTSP媒體服務(wù)器之間存在不同傳遞點(diǎn)。例如，表示描述(presentationdescription)可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨(dú)立RTSP服務(wù)器與用戶不全依靠HTTP。但是，RTSP與HTTP的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進(jìn)行。HTTP是不對稱協(xié)議，用戶發(fā)出請求，服務(wù)器作出回應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)出請求，且其請求都是無狀態(tài)的；在請求確認(rèn)后很長時(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符號協(xié)定既然很多定義和語法與HTTP/1.1中相同，這里僅指出它們在HTTP/1.1中定義的位置而并沒有拷貝它們到本文檔。為簡便起見，本文檔中[HX.Y]表示對應(yīng)HTTP/1.1（RFC2068）中的X.Y部分。（[譯者注：]為更方便學(xué)習(xí)RTSP，本翻譯文檔將相關(guān)段落完全譯出）與[H2.1]類似，本文對所有機(jī)制的說明都是以散文和補(bǔ)充反饋的方式來描述的。除RTSP中以”1#”代替”,”為分隔符不同外，其余在RFC2234中有詳細(xì)的描述。簡單說明補(bǔ)充反饋方式如下：補(bǔ)充反饋方式（augmentedBNF）包括下面的結(jié)構(gòu)：要解釋的名詞＝名詞解釋（name=definition）規(guī)則的名字（name）就是它本身（不帶任何尖括號，“<”，“>”），后面跟個(gè)等號＝，然后就是該規(guī)則的定義。如果規(guī)則需要用多個(gè)行來描述，利用空格進(jìn)行縮進(jìn)格式排版。某些基本的規(guī)則使用大寫，如SP,LWS,HT,CRLF,DIGIT,ALPHA,等等。定義中還可以使用尖括號來幫助理解規(guī)則名的使用。字面意思（"literal"）文字的字面意思放在引號中間，除非特別指定，該段文字是大小寫敏感的。規(guī)則1｜規(guī)則2（rule1|rule2）“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。（規(guī)則1規(guī)則2）（(rule1rule2)）在圓括號中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩種意思，即“元素1元素2元素4”和“元素1元素3元素4”*規(guī)則（*rule）在元素前加星號“*”表示循環(huán)，其完整形式是“<n>*<m>元素”，表明元素最少產(chǎn)生<n>次，最多<m>次。缺省值是0到無限，例如，“1*元素”意思是至少有一個(gè)，而“1*2元素”表明允許有1個(gè)或2個(gè)。［規(guī)則］（[rule]）方括號內(nèi)是可選元素。如“［元素1元素2］”與“*1（元素1元素2）”是一回事。N規(guī)則（Nrule）表明循環(huán)的次數(shù)：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精確指出<n>取值。因而，2DIGIT就是2位數(shù)字,3ALPHA就是由三個(gè)字母組成字符串。＃規(guī)則（#rule）“#”與“*”類似，用于定義元素列表。完整形式是“<n>#<m>元素”表示至少有<n>個(gè)至多有<m>個(gè)元素，中間用“,”或任意數(shù)量的空格（LWS-linearwhitespace）來分隔，這將使列表非常方便，如“（*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）分號后面是注釋，僅在單行使用。隱含*LWS（implied*LWS）本文的語法描述是基于單詞的。除非另有指定，線性空格（LWS）可以兩個(gè)鄰近符號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個(gè)符號之間必須有至少一個(gè)分隔符，因?yàn)樗鼈円惨鰹閱为?dú)的符號來解釋。實(shí)際上，應(yīng)用程序在產(chǎn)生HTTP結(jié)構(gòu)時(shí)，應(yīng)當(dāng)試圖遵照“通常方式”，因?yàn)楝F(xiàn)在的確有些實(shí)現(xiàn)方式在通常方式下無法正常工作。在本備忘錄中，我們用縮進(jìn)的小型段落來提供動機(jī)和背景資料。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來實(shí)現(xiàn)。3協(xié)議參數(shù)3.1RTSP版本同[H3.1]定義，僅用RTSP代替HTTP即可。如下：RTSP采用主從（<major>.<minor>）數(shù)字形式來表示版本。協(xié)議的版本政策傾向于讓發(fā)送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高版本的RTSP實(shí)現(xiàn)通訊。只增加擴(kuò)展域的值或增加了不影響通訊行為的消息組件都不會導(dǎo)致版本數(shù)據(jù)的變化。當(dāng)協(xié)議消息的主要解析算法沒變，而消息語法及發(fā)送方的隱含功能增加了，將會導(dǎo)致從版本號（<minor>）增加；當(dāng)協(xié)議中消息的格式變化了，主版本號（<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版本低。版本號前面的0將被接收方忽略，而在發(fā)送方處也不應(yīng)產(chǎn)生。本文檔定義了RTSP協(xié)議的1.0版本。發(fā)送本規(guī)范定義的請求（Request）或回應(yīng)（Response）消息的應(yīng)用必須指明RTSP的版本為“RTSP/1.0”。使用該版本號意味著發(fā)送消息的應(yīng)用至少有條件的遵循本規(guī)范。應(yīng)用的RTSP版本即為應(yīng)用至少能有條件遵循的RTSP版本中的最高版本。當(dāng)代理及網(wǎng)關(guān)收到與其自身版本不同的RTSP請求時(shí)，必須小心處理請求的推送，因?yàn)閰f(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關(guān)不應(yīng)發(fā)出高于自身版本的消息。如果收到高版本的請求，代理或網(wǎng)關(guān)必須降低該請求的版本，并回應(yīng)一個(gè)錯(cuò)誤。而低版本的請求也應(yīng)在被推送前升級。代理或網(wǎng)關(guān)回應(yīng)請求時(shí)必須和請求的版本相同。3.2RTSPURL“rtsp”和“rtspu”表示要通過RTSP協(xié)議來定位網(wǎng)絡(luò)資源。本節(jié)詳細(xì)定義了RTSPURL的語法和語義。rtsp_URL=("rtsp:"|"rtspu:")"http://"host[":"port][abs_path]host=<合法的Internet主機(jī)域名或IP地址(用十進(jìn)制數(shù)及點(diǎn)組成),見RFC1123，2.1節(jié)定義>port=*DIGITabs_path在[H3.2.1]中定義如下：abs_path="/"rel_pathrel_path=[path][";"params]["?"query]path=fsegment*("/"segment)fsegment=1*pcharsegment=*pcharparams=param*(";"param)param=*(pchar|"/")scheme=1*(ALPHA|DIGIT|"+"|"-"|".")net_loc=*(pchar|";"|"?")query=*(uchar|reserved)fragment=*(uchar|reserved)pchar=uchar|":"|"@"|"&"|"="|"+"uchar=unreserved|escapeunreserved=ALPHA|DIGIT|safe|extra|nationalescape="%"HEXHEXreserved=";"|"/"|"?"|":"|"@"|"&"|"="|"+"extra="!"|"*"|"'"|"("|")"|","safe="$"|"-"|"_"|"."unsafe=CTL|SP|<">|"#"|"%"|"<"|">"national=<anyOCTETexcludingALPHA,DIGIT,reserved,extra,safe,andunsafe>權(quán)威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。[注意]：段(fragment)和詢問(query)標(biāo)識符在這時(shí)沒有明確的定義，需要到RTSP服務(wù)器上解釋。rtsp要求使用可靠協(xié)議（Internet的TCP協(xié)議）發(fā)出命令，而rtspu則使用不可靠協(xié)議（Internet的UDP協(xié)議）。如是端口為空或沒指定，則缺省為80端口。對于rtsp_URI來說，擁有被請求的資源的服務(wù)器主機(jī)通過偵聽該端口的TCP連接(rtsp)或UDP包(rtspu)來接收該URI請求。只要可能，應(yīng)盡量避免的在URL中直接使用IP地址。（請參考RFC1924）文本媒體標(biāo)識符使用URL中的字符集及轉(zhuǎn)義規(guī)則（參考RFC1738）來標(biāo)識一個(gè)表示(presentation)與單個(gè)流(stream)。URL可以用于單個(gè)流或者多個(gè)流的集合，比如表示(presentation)。因此，在第十章所描述的請求(request)可以用于整個(gè)表示(presentation)或表示中的單個(gè)流。注意，有些請求方法僅能用于流而不能用于表示，反之亦然。例如：RTSPURL:rtsp://:554/twister/audiotrack標(biāo)識了twister表示(presentation)中，可以通過554端口的TCP連接發(fā)送RTSP請求來控制的音頻流。也可以是這樣RTSPURL：rtsp://:554/twister標(biāo)識了由音頻和視頻流組成的twister表示(presentation)。這并沒有給出URL中相關(guān)流的標(biāo)準(zhǔn)方法。表示描述定義了表示中的層次關(guān)系以及單獨(dú)流的URL。如一個(gè)表示描述可能將一個(gè)流命名為a.mov，而將整個(gè)表示命名為b.mov。RTSPURL的路徑組成對客戶端來說不可見并且也并沒有給出服務(wù)器的具體文件系統(tǒng)結(jié)構(gòu)。只需進(jìn)行簡單替換后，表示描述同樣可以用于非RTSP媒體控制協(xié)議。3.3會議標(biāo)識會議標(biāo)識采用URI標(biāo)準(zhǔn)編碼方法編碼，并對RTSP來說是不可見的。它們能包含任一八位位組值。必須保證會議標(biāo)識在全局中的唯一性。在H.323中，將用到會議的標(biāo)識值。conference-id=1*xchar會議標(biāo)識允許RTSP會話從媒體服務(wù)器參與的多媒體會議中獲取參數(shù)。比如，可以要求媒體服務(wù)器用會議描述中的標(biāo)識值來代替RTSP客戶端以提供詳細(xì)的傳輸信息。多媒體會議的建立不屬于本協(xié)議內(nèi)容，具體請參見H.323或SIP協(xié)議。3.4會話標(biāo)識會話標(biāo)識符是不可見的任意長度的字符串。線性空格必須是URL-escaped。會話標(biāo)識符必須隨機(jī)產(chǎn)生并且至少應(yīng)有8個(gè)八位位組長以保證其難以被猜出。（詳見16章）session-id=1*(ALPHA|DIGIT|safe)3.5SMPTE相對時(shí)間戳SMPTE相對時(shí)間戳表示相對于開始剪輯的時(shí)間。相對時(shí)間戳以SMPTE時(shí)間編碼形式表示而可以達(dá)到幀級量級的精度。時(shí)間編碼的格式為：時(shí)：分：秒；幀.子幀，并以剪輯開始為起點(diǎn)。缺省的SMPTE格式為“SMPTE30drop”格式，其幀速是29.97幀每秒?？赏ㄟ^選擇使用不同“SMPTEtime”來選擇其他SMPTE編碼格式（如“SMPTE25”格式）。幀域的時(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.01smpte-25=10:07:00-10:07:33:05.013.6正常播放時(shí)間正常播放時(shí)間(NPT)指出了流相對于表示(presentation)開始時(shí)的絕對位置。時(shí)間戳由一個(gè)十進(jìn)制小數(shù)組成，以秒為單位，小數(shù)點(diǎn)左邊可以直接以秒表示或者以小時(shí)：分：秒的形式表示。表示開始時(shí)對應(yīng)0.0秒。負(fù)值沒有意義。特殊的常數(shù)now定義為現(xiàn)場事件當(dāng)前瞬間。它只能用于現(xiàn)場事件。在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-hhmmssnpt-sec=1*DIGIT["."*DIGIT]npt-hhmmss=npt-hh":"npt-mm":"npt-ss["."*DIGIT]npt-hh=1*DIGIT;anypositivenumbernpt-mm=1*2DIGIT;0-59npt-ss=1*2DIGIT;0-59比如：npt=123.45-125npt=12:05:35.3-npt=now-語法遵循ISO8601規(guī)則。npt-sec標(biāo)志法便于自動產(chǎn)生，ntp-hhmmss標(biāo)志法便于人工使用?！皀ow”常數(shù)允許客戶端請求接收實(shí)時(shí)反饋而不是存儲或者延時(shí)的版本。因?yàn)閷τ谶@種情況而言，既沒有絕對時(shí)間，也沒有0時(shí)間，所以需要該參數(shù)。3.7絕對時(shí)間絕對時(shí)間表示為ISO8601時(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.25Z3.8選擇標(biāo)簽選擇標(biāo)簽是用來指定RTSP新選擇的唯一標(biāo)識符。這些標(biāo)簽用于要求(Require)(12.32節(jié))和代理要求(ProxyRequire)(12.27節(jié))標(biāo)題域中。語法：option-tag=1*xchar建立新的RTSP選擇可以通過在選擇前加入相反域名的前綴（如：對于能訪問到則com.foo.mynewfeature"是個(gè)合適的名字）或者在英特網(wǎng)權(quán)威數(shù)字分派委員會注冊（IANA）新的選擇。3.8.1用IANA注冊新的選擇標(biāo)簽當(dāng)注冊新RTSP選擇標(biāo)簽的時(shí)候，應(yīng)該提供以下信息：?選擇的名字和描述。名字長度不限，但是應(yīng)該不少于20字符。名字不得包含任何空格，控制符或句點(diǎn)。?指出誰擁有選擇的改變控制權(quán)（例如，IETF，國際標(biāo)準(zhǔn)化組織，國際電信聯(lián)盟-T，其他的國際標(biāo)準(zhǔn)化體，一個(gè)團(tuán)體，一個(gè)公司，或者一組公司）。?描述更為詳細(xì)的參考文檔（如果有），比如，RFC，發(fā)表論文，專利文檔，技術(shù)報(bào)告，源代碼，或者計(jì)算機(jī)手冊。?選擇的所有權(quán)，以及聯(lián)系地址（郵編及電子信件地址）。4RTSP消息RTSP是基于文本的協(xié)議，采用ISO10646字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。由于參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低，處理效率沒引起注意。如仔細(xì)研究，文本協(xié)議很容易以腳本語言（如：Tcl、VisualBasic與Perl）實(shí)現(xiàn)研究原型。10646字符集避免敏感字符集切換，但對應(yīng)用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO8859-1字符表示如100001x10xxxxxx.。RTSP信息可通過任何低層傳輸協(xié)議攜帶。請求包括方法、方法作用于其上的對象和進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。當(dāng)信息體包含在信息中，信息體長度有如下因素決定：不管實(shí)體標(biāo)題域是否出現(xiàn)在信息中，不包括信息體的的回應(yīng)信息總以標(biāo)題域后第一和空行結(jié)束。如出現(xiàn)內(nèi)容長度標(biāo)題域，其值以字節(jié)計(jì)，表示信息體長度。如未出現(xiàn)標(biāo)題域，其值為零。服務(wù)器關(guān)閉連接。注意：RTSP目前并不支持HTTP/1.1\"塊\"傳輸編碼，需要有內(nèi)容長度頭。假如返回適度表示描述長度，即使動態(tài)產(chǎn)生，使塊傳輸編碼沒有必要，服務(wù)器也應(yīng)該能決定其長度。如有實(shí)體，即使必須有內(nèi)容長度，且長度沒顯式給出，規(guī)則可確保行為合理。從用戶到服務(wù)器端的請求信息在第一行內(nèi)包括源采用的方法、源標(biāo)識和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼，而沒有定義任何HTTP代碼。4.1消息類型見[H4.1]。如下：RTSP消息由客戶端到服務(wù)器的請求和由服務(wù)器到客戶端的回應(yīng)組成。RTSP-message=Request|Response;RTSP/1.0messages請求（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-headerCRLF[message-body]start-line=Request-Line|Status-Line為了健壯性考慮，服務(wù)器應(yī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é)）、請求標(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)題域由后緊跟冒號的名字，單空格（SP），字符及域值組成。域名是大小寫敏感的。雖然不提倡，標(biāo)題域還是可以擴(kuò)展成多行使用，只要這些行以一個(gè)以上的SP或HT開頭就行。RTSP-header=field-name":"[field-value]CRLFfield-name=tokenfield-value=*(field-content|LWS)field-content=<theOCTETsmakeupthefield-valueandconsistingofeither*TEXTorcombinationsoftoken,tspecials,andquoted-string>標(biāo)題域接收的順序并不重要，但良好的習(xí)慣是，先發(fā)送主標(biāo)題，然后是請求標(biāo)題或回應(yīng)標(biāo)題，最后是實(shí)體標(biāo)題。當(dāng)且僅當(dāng)標(biāo)題域的全部域值都用逗號分隔的列表示時(shí)（即，#（值）），多個(gè)有相同域名的RTSP標(biāo)題域才可以表示在一個(gè)消息里。而且必須能在不改變消息語法的前提下，將并發(fā)的域值加到第一個(gè)值后面，之間用逗號分隔，最終能將多個(gè)標(biāo)題域結(jié)合成“域名：域值”對。4.3消息主體見[H4.3]。RTSP消息的消息主體（如果有）用來攜帶請求或回應(yīng)的主體。僅在使用傳輸編碼(Transfer-Encoding)時(shí)消息主體和實(shí)體主體才有所不同，這種情況在傳輸編碼標(biāo)題域中有詳細(xì)說明。（見[H14.40]）message-body=entity-body|<entity-bodyencodedasperTransfer-Encoding>傳輸編碼必須能解釋所有保證傳輸安全和正確的應(yīng)用程序的傳輸編碼。傳輸編碼是消息而不是實(shí)體的一個(gè)屬性，因此可以由任一應(yīng)用程序隨著請求/回應(yīng)鏈添加或者刪除。什么時(shí)候允許消息帶消息體的規(guī)則在請求和回應(yīng)兩種情況下有所不同。在請求中有無消息主體的標(biāo)志是是否包含內(nèi)容長度或請求消息標(biāo)題域中的傳輸編碼標(biāo)題域。只有當(dāng)請求方法允許有實(shí)體主體的時(shí)候才能在請求中包含消息主體。而對于回應(yīng)消息來說，無論消息中是否存在消息主體都與請求方法和回應(yīng)狀態(tài)編碼無關(guān)。所有回應(yīng)標(biāo)題請求方法的消息都不能包含消息主體，盡管有時(shí)會因?yàn)榇嬖趯?shí)體標(biāo)題域而使人產(chǎn)生誤解。所有1××（信息），204（無內(nèi)容），304（未修改）回應(yīng)都不包含消息主體。而其他回應(yīng)則都包含主體，盡管其長度有可能長度為零。4.4消息長度當(dāng)消息包含消息主體時(shí)，消息主體的長度由以下規(guī)則來決定（按優(yōu)先級高低順序排列）：1.任何回應(yīng)消息都不包含消息主體（如1××，204和304回應(yīng)），并且不管消息中是否存在實(shí)體標(biāo)題域都以消息標(biāo)題域后的第一行空行表示結(jié)束。2.如果內(nèi)容長度標(biāo)題域存在，它在字節(jié)中的值就是消息主體的長度。如果內(nèi)容標(biāo)題域不存在，則假設(shè)值為零。3.服務(wù)器關(guān)閉連接時(shí)。（關(guān)閉連接沒有用來表明請求主體結(jié)束，否則可能導(dǎo)致服務(wù)器不能回應(yīng)。注意，RTSP不支持（至少現(xiàn)在）HTTP/1.1的塊傳輸編碼（詳見[H3.6]）并且要求有內(nèi)容長度標(biāo)題域。盡管表示描述長度動態(tài)產(chǎn)生，但由于可獲得了表示描述返回長度，使得服務(wù)器總是能決定表示描述長度而不需使用塊傳輸編碼方式。只要有實(shí)體主體就必須有內(nèi)容長度項(xiàng)，這些規(guī)則保證了即使沒有給出明確長度也能做出合理的操作。5普通標(biāo)題域有幾種標(biāo)題域是請求與回應(yīng)都要使用的，但并不用于被傳輸?shù)膶?shí)體。這些標(biāo)題只用于被傳輸?shù)南ⅰeneral-Header=Date;Section10.6|Pragma;Section10.12普通標(biāo)題域名稱只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，新的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識別，其語法就可使用，而無法識別的標(biāo)題域都將被視為實(shí)體域。6請求從客戶端到服務(wù)器端的請求消息包括，消息首行中，對資源的請求方法、資源的標(biāo)識符及使用的協(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請求隊(duì)列Request-Line=MethodSPRequest-URISPRTSP-VersionCRLFMethod="DESCRIBE";Section10.2|"ANNOUNCE";Section10.3|"GET_PARAMETER";Section10.8|"OPTIONS";Section10.1|"PAUSE";Section10.6|"PLAY";Section10.5|"RECORD";Section10.11|"REDIRECT";Section10.10|"SETUP";Section10.4|"SET_PARAMETER";Section10.9|"TEARDOWN";Section10.7|extension-methodextension-method=tokenRequest-URI="*"|absolute_URIRTSP-Version="RTSP""/"1*DIGIT"."1*DIGIT6.2請求標(biāo)題域request-header=Accept;Section12.1|Accept-Encoding;Section12.2|Accept-Language;Section12.3|Authorization;Section12.5|From;Section12.20|If-Modified-Since;Section12.23|Range;Section12.29|Referer;Section12.30|User-Agent;Section12.41注意：相對于HTTP/1.1而言，RTSP請求要求絕對路徑（并包括rtsp或rtspu方案，主機(jī)，端口號）。HTTP/1.1要求服務(wù)器理解絕對URL,但是客戶端需要假設(shè)為主機(jī)請求標(biāo)題域。這樣做完全是為了HTTP/1.0服務(wù)器端向后兼容性，因此RTSP并不需要這樣做。在請求URI中星號“*”表示此請求不用于其他資源，只用于服務(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)的詞語文本組成，各元素間以空格（SP）分隔，除了結(jié)尾的CRLF外，不允許出現(xiàn)單獨(dú)的CR或LF符。Status-Line=HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF7.1.1狀態(tài)代碼和原因分析狀態(tài)代碼（Status-Code）由3位數(shù)字組成，表示請求是否被理解或被滿足。原因分析是用簡短的文字來描述狀態(tài)代碼產(chǎn)生的原因。狀態(tài)代碼用來支持自動操作，原因分析是為人類用戶準(zhǔn)備的?？蛻舳瞬恍枰獧z查或顯示原因分析。狀態(tài)代碼的第一位數(shù)字定義了回應(yīng)的類別，后面兩位數(shù)字沒有具體分類。首位數(shù)字有5種取值可能：o1xx:：保留，將來使用。o2xx：成功－操作被接收、理解、接受（received,understood,accepted）。o3xx：重定向（Redirection）－要完成請求必須進(jìn)行進(jìn)一步操作。o4xx：客戶端出錯(cuò)－請求有語法錯(cuò)誤或無法實(shí)現(xiàn)。o5xx：服務(wù)器端出錯(cuò)－服務(wù)器無法實(shí)現(xiàn)合法的請求。HTTP/1.0的狀態(tài)代碼、原因解釋在下面給出。下面的原因解釋只是建議采用，可任意更改，而不會對協(xié)議造成影響。完整的代碼定義在第9節(jié)。Status-Code="100";Continue|"200";OK|"201";Created|"250";LowonStorageSpace|"300";MultipleChoices|"301";MovedPermanently|"302";MovedTemporarily|"303";SeeOther|"304";NotModified|"305";UseProxy|"400";BadRequest|"401";Unauthorized|"402";PaymentRequired|"403";Forbidden|"404";NotFound|"405";MethodNotAllowed|"406";NotAcceptable|"407";ProxyAuthenticationRequired|"408";RequestTime-out|"410";Gone|"411";LengthRequired|"412";PreconditionFailed|"413";RequestEntityTooLarge|"414";Request-URITooLarge|"415";UnsupportedMediaType|"451";ParameterNotUnderstood|"452";ConferenceNotFound|"453";NotEnoughBandwidth|"454";SessionNotFound|"455";MethodNotValidinThisState|"456";HeaderFieldNotValidforResource|"457";InvalidRange|"458";ParameterIsRead-Only|"459";Aggregateoperationnotallowed|"460";Onlyaggregateoperationallowed|"461";Unsupportedtransport|"462";Destinationunreachable|"500";InternalServerError|"501";NotImplemented|"502";BadGateway|"503";ServiceUnavailable|"504";GatewayTime-out|"505";RTSPVersionnotsupported|"551";Optionnotsupported|extension-codeextension-code=3DIGITReason-Phrase=*<TEXT,excludingCR,LF>HTTP狀態(tài)代碼是可擴(kuò)展的，而只有上述代碼才可以被當(dāng)前全部的應(yīng)用所識別。HTTP應(yīng)用不要求了解全部注冊的狀態(tài)代碼，當(dāng)然，如果了解了更好。實(shí)際上，應(yīng)用程序必須理解任何一種狀態(tài)代碼，如果碰到不識別的情況，可根據(jù)其首位數(shù)字來判斷其類型并處理。另外，不要緩存無法識別的回應(yīng)。例如，如果客戶端收到一個(gè)無法識別的狀態(tài)碼431，可以安全地假定是請求出了問題，可認(rèn)為回應(yīng)的狀態(tài)碼就是400。在這種情況下，用戶代理應(yīng)當(dāng)在回應(yīng)消息的實(shí)體中通知用戶，因?yàn)閷?shí)體中可以包括一些人類可以識別的非正常狀態(tài)的描述信息。Codereason100Continueall200OKall201CreatedRECORD250LowonStorageSpaceRECORD300MultipleChoicesall301MovedPermanentlyall302MovedTemporarilyall303SeeOtherall305UseProxyall400BadRequestall401Unauthorizedall402PaymentRequiredall403Forbiddenall404NotFoundall405MethodNotAllowedall406NotAcceptableall407ProxyAuthenticationRequiredall408RequestTimeoutall410Goneall411LengthRequiredall412PreconditionFailedDESCRIBE,SETUP413RequestEntityTooLargeall414Request-URITooLongall415UnsupportedMediaTypeall451InvalidparameterSETUP452IllegalConferenceIdentifierSETUP453NotEnoughBandwidthSETUP454SessionNotFoundall455MethodNotValidInThisStateall456HeaderFieldNotValidall457InvalidRangePLAY458ParameterIsRead-OnlySET_PARAMETER459AggregateOperationNotAllowedall460OnlyAggregateOperationAllowedall461UnsupportedTransportall462DestinationUnreachableall500InternalServerErrorall501NotImplementedall502BadGatewayall503ServiceUnavailableall504GatewayTimeoutall505RTSPVersionNotSupportedall551OptionnotsupportallTable1:StatuscodesandtheirusagewithRTSPmethods7.1.2回應(yīng)標(biāo)題域回應(yīng)標(biāo)題域中包括不能放在狀態(tài)行中的附加回應(yīng)信息。該域還可以存放與服務(wù)器相關(guān)的信息，以及在對請求URI所指定資源進(jìn)行訪問的下一步信息。response-header=Location;Section12.25|Proxy-Authenticate;Section12.26|Public;Section12.28|Retry-After;Section12.31|Server;Section12.36|Vary;Section12.42|WWW-Authenticate;Section12.44回應(yīng)標(biāo)題域名只有在與協(xié)議版本的變化結(jié)合起來后，才能進(jìn)行可靠的擴(kuò)展。實(shí)際上，新的或?qū)嶒?yàn)中的標(biāo)題域只要能被通訊各方識別，其語法就可使用，而無法識別的標(biāo)題域都將被視為實(shí)體域。8實(shí)體如不受請求方法或回應(yīng)狀態(tài)編碼限制，請求和回應(yīng)消息可傳輸實(shí)體，實(shí)體由實(shí)體標(biāo)題域和實(shí)體主體組成，有些回應(yīng)僅包括實(shí)體頭。在此，根據(jù)誰發(fā)送實(shí)體、誰接收實(shí)體，發(fā)送者和接收者可分別指用戶和服務(wù)器。8.1實(shí)體標(biāo)題域?qū)嶓w標(biāo)題定義實(shí)體主體可選元信息，如沒有實(shí)體主體，指請求標(biāo)識的資源。entity-header=Allow;Section12.4|Content-Base;Section12.11|Content-Encoding;Section12.12|Content-Language;Section12.13|Content-Length;Section12.14|Content-Location;Section12.15|Content-Type;Section12.16|Expires;Section12.19|Last-Modified;Section12.24|extension-headerextension-header=message-header擴(kuò)展頭機(jī)制允許定義附加實(shí)體標(biāo)題域，而不用改變協(xié)議，但這些段不能假定接收者能識別。不可識別標(biāo)題域應(yīng)被接收者忽略，而讓代理轉(zhuǎn)發(fā)。8.2實(shí)體主體見[H7.2]與RTSP請求或回應(yīng)一起發(fā)送的實(shí)體主體的格式和編碼信息都在實(shí)體標(biāo)題域（Entity-Header）中定義。Entity-Body=*OCTET實(shí)體主體只在請求方法有要求時(shí)才會被放在請求消息中。請求消息標(biāo)題域處的內(nèi)容長度標(biāo)題域（Content-Lengthheaderfield）的標(biāo)志將指明請求中的實(shí)體主體是否存在。包含實(shí)體主體的RTSP/1.0請求必須包含合法的內(nèi)容長度標(biāo)題域。對回應(yīng)消息來說，消息中是否包含實(shí)體主體取決于請求方法和回應(yīng)代碼。所有的HEAD請求方法的回應(yīng)都不應(yīng)包括主體，即便是實(shí)體標(biāo)題域中指明有主體也一樣。在主體中不應(yīng)包括這些回應(yīng)信息，全部1xx（信息）、204（無內(nèi)容）和304（未修改）。而其它的回應(yīng)必須包括實(shí)體主體或其內(nèi)容長度標(biāo)題（Content-Lengthheader）域的定義值為0。9連接RTSP請求可以幾種不同方式傳送：1、持久傳輸連接，用于多個(gè)請求/回應(yīng)傳輸。2、每個(gè)請求/回應(yīng)傳輸一個(gè)連接。3、無連接模式。傳輸連接類型由RTSPURI來定義。對\"rtsp\"方案，需要持續(xù)連接；而\"rtspu\"方案，調(diào)用RTSP請求發(fā)送，而不用建立連接。不象HTTP，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請求。然而，這僅在持久連接時(shí)才支持，否則媒體服務(wù)器沒有可靠途徑到達(dá)用戶，這也是請求通過防火墻從媒體服務(wù)器傳到用戶的唯一途徑。9.1流水線操作支持持久連接或無連接的客戶端可能給其請求排隊(duì)。服務(wù)器必須以收到請求的同樣順序發(fā)出回應(yīng)。9.2可靠性及確認(rèn)如果請求不是發(fā)送給組播組，接收者就確認(rèn)請求，如沒有確認(rèn)信息，發(fā)送者可在超過一個(gè)來回時(shí)間（RTT）后重發(fā)同一信息。RTT在TCP中估計(jì)，初始值為500ms。應(yīng)用緩存最后所測量的RTT，作為將來連接的初始值。如使用一個(gè)可靠傳輸協(xié)議傳輸RTSP，請求不允許重發(fā)，RTSP應(yīng)用反過來依賴低層傳輸提供可靠性。如兩個(gè)低層可靠傳輸（如TCP和RTSP）應(yīng)用重發(fā)請求，有可能每個(gè)包損失導(dǎo)致兩次重傳。由于傳輸棧在第一次嘗試到達(dá)接收著者前不會發(fā)送應(yīng)用層重傳，接收者也不能充分利用應(yīng)用層重傳。如包損失由阻塞引起，不同層的重發(fā)將使阻塞進(jìn)一步惡化。時(shí)標(biāo)頭用來避免重發(fā)模糊性問題，避免對圓錐算法的依賴。每個(gè)請求在CSeq頭中攜帶一個(gè)系列號，每發(fā)送一個(gè)不同請求，它就加一。如由于沒有確認(rèn)而重發(fā)請求，請求必須攜帶初始系列號。實(shí)現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP，并支持UDP。對UDP和TCP，RTSP服務(wù)器的缺省端口都是554。許多目的一致的RTSP包被打包成單個(gè)低層PDU或TCP流。RTSP數(shù)據(jù)可與RTP和RTCP包交叉。不象HTTP，RTSP信息必須包含一個(gè)內(nèi)容長度頭，無論信息何時(shí)包含負(fù)載。否則，RTSP包以空行結(jié)束，后跟最后一個(gè)信息頭。10方法定義（methodtoken）表示了對請求統(tǒng)一資源標(biāo)志符（Request-URI）識別的資源所執(zhí)行的操作。方法名區(qū)分大小寫。將來可能定義新的方法。方法名可能不以美元符'＄'（十進(jìn)制數(shù)24）開頭，但必須具有表征意義(mustbeatoken)。表格2是對方法的一個(gè)小結(jié)。methoddirectionobjectrequirementDESCRIBEC->SP,SrecommendedANNOUNCEC->S,S->CP,SoptionalGETPARAMETERC->S,S->CP,SoptionalOPTIONSC->S,S->CP,Srequired(S!C:optional)PAUSEC->SP,SrecommendedPLAYC->SP,SrequiredRECORDC->SP,SoptionalREDIRECTS->CP,SoptionalSETUPC->SSrequiredSETPARAMETERC->S,S->CP,SoptionalTEARDOWNC->SP,Srequired表2：對RTSP方法，和其操作方向及所操作對象（P:表示,S:媒體流）的一個(gè)概覽注意：PAUSE方法是推薦的,但在構(gòu)建一個(gè)全功能的服務(wù)器（fullyfunctionalserver）時(shí)可能不支持此方法，這時(shí)就不需要它，比如對于livefeeds。如果服務(wù)器不支持某個(gè)特殊方法，它必將返回"501NotImplemented"，并且客戶端應(yīng)該不再向該服務(wù)器請求該方法。（注：Presentation是一個(gè)以完整的mediafeed呈現(xiàn)給client的一個(gè)或多個(gè)媒體流的集合，暫且翻譯成表示）10.1OPTIONS其行為與[H9.2]中描述的等同。OPTIONS請求可能在任何時(shí)候發(fā)出，例如客戶端將要發(fā)出一個(gè)非標(biāo)準(zhǔn)的請求時(shí)。它不影響服務(wù)器狀態(tài)。示例：C->S:OPTIONS*RTSP/1.0CSeq:1Require:implicit-playProxy-Require:gzipped-messagesS->C:RTSP/1.0200OKCSeq:1Public:DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE注意：這些都是必要的構(gòu)造特征（necessarilyfictionalfeatures）。(你可能不希望我們?nèi)ビ幸夂雎阅切?shí)際上有用的特征，因此在這一部分中我們將給出一個(gè)詳細(xì)的例子)。10.2DESCRIBEDESCRIBE方法從服務(wù)器檢索表示的描述或媒體對象，這些資源通過請求統(tǒng)一資源定位符（therequestURL）識別。此方法可能結(jié)合使用Accept首部域來指定客戶端理解的描述格式。服務(wù)器端用被請求資源的描述對客戶端作出響應(yīng)。DESCRIBE的答復(fù)-響應(yīng)對（reply-responsepair）組成了RTSP的媒體初始化階段。示例：C->S:DESCRIBErtsp:///fizzle/fooRTSP/1.0CSeq: