【正文】 。當(dāng)處于快進掃描模式時(倍速為大于1的正數(shù))，NPT快速前進。 059因為對于這種情況而言，絕對時間和0時間都不適用。 比如，UTC時間為：名字【必須不】包含任何空格，控制符或句點?；谖谋镜膮f(xié)議使得易于以自描述方式增加可選參數(shù)。(見 RFC 2279 [21]) 。換句話說，如果服務(wù)器正在讀協(xié)議流，在一個消息開始時如果首先收到了CRLF，這個CRLF符應(yīng)被忽略。 = *( fieldcontent | LWS )而且必須能在不改變消息語法的前提下，將并發(fā)的域值加到第一個值后面，之間用逗號分隔，最終能將多個頭部域結(jié)合成域名：域值對。所有1（信息），204（無內(nèi)容），304（未修改）響應(yīng)都不包含消息主體。注意：RTSP目前并不支持HTTP/塊傳輸編碼(見 [])，需要有內(nèi)容頭部域。 Connection Section | 請求行 = 方法 空格 請求URI 空格 RTSP版本 CRLF 。 Section | REDIRECT Section 。 請求頭部域 | | Range Section 。如下面的例子：還有，RTSP增加了一些狀態(tài)碼，也棄用了一些HTTP狀態(tài)碼。 StatusLine 。 [ messagebody ] 響應(yīng)消息的第一行就是狀態(tài)行，它由協(xié)議版本、數(shù)字形式的狀態(tài)碼、與狀態(tài)碼對應(yīng)的文本解釋依次組成，各元素間以空格（SP）分隔，除了結(jié)尾的CRLF外，不允許出現(xiàn)CR或LF符。首位數(shù)字有5取值可能： *4xx：客戶端出錯 請求有語法錯誤或無法實現(xiàn)注意：RTSP采用了大多數(shù)HTTP/ [2]狀態(tài)碼，并增加了一些形如x50的RTSP特有的狀態(tài)碼以避免與最新定義的HTTP狀態(tài)碼沖突。 OK 。 | 303 使用代理 。 | 405 代理需要認證 請求超時 。 | 415 找不到會議 。 | 458 只允許合控制 。 | 503 不支持此RTSP版本 。 |在這種情況下，用戶界面應(yīng)當(dāng)在把響應(yīng)消息的實體顯示給用戶，因為實體中可能包括一些人類可以識別的關(guān)于此非正常狀態(tài)的描述信息。 繼續(xù) 所有302 所有404SETUP453所有455 此頭部域?qū)υ撡Y源無效 SET_PARAMETER459 只允許合控制 無法到達目的地址網(wǎng)關(guān)錯誤 Location | | Section 。 Expires LastModified 實體主體 和HTTP不同的是，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請求。 支持持久連接或無連接的客戶端可能會使用管道方式傳送請求（即是說：發(fā)送多個請求而不需等待單個的響應(yīng)）。一個實現(xiàn)可能會緩存最后所測量的RTT，作為將來連接的初始值。如果RTSP被用在小RTT支持RTSP的系統(tǒng)必須支持通過TCP承載RTSP，然后也可以支持通過UDP承載。 P,S CS, SC GET_PARAMETER 推薦 方法方法名稱不應(yīng)以$符號（數(shù)字24）開始，并且必須是一個關(guān)鍵字。如果由于缺少確認而重發(fā)一個請求，該請求必須攜帶原來的序列號（即是說，序列號不增加）。若丟包由網(wǎng)絡(luò)阻塞引起，多個層上的的共同重發(fā)將使阻塞進一步惡化。后重發(fā)同一信息。rtsp 方案說明需要持續(xù)連接；而rtspu方案，則要求不建立連接就直接發(fā)送RTSP請求。 RTSP請求可以幾種不同方式傳送： 不被識別的頭部域應(yīng)被接收者忽略，而讓代理發(fā)送。 extensionheader 。 ContentLocation ContentLanguage如不受請求方法或響應(yīng)狀態(tài)碼限制，請求和響應(yīng)消息可以傳送任何實體。 Section Public 。響應(yīng)頭部域使得請求接收方可以發(fā)送不能放在狀態(tài)行中的附加響應(yīng)信息。 網(wǎng)關(guān)超時所有503 所有 參數(shù)是只讀的 請求URI過 DESCRIBE, SETUP 413所有411 所有408 所有406 禁止 未通過認證 OK的響應(yīng)。 | 。 無法得到服務(wù) 501 | 。 參數(shù)是只讀的 456 | 。 媒體類型不支持 413 | 。 不允許該方法 403 | 。 見其他 301 | 。HTTP/、對應(yīng)原因解釋在下面給出。 responseheader Referer Section IfModifiedSince | 。 。 Section 。 Section 請求行 5章6 請求 Via（關(guān)閉連接不能被用于指示請求主體（request body）的結(jié)束，因為那樣將使服務(wù)器無法回送響應(yīng)。2.而對于響應(yīng)消息來說，無論消息中是否存在消息主體都與請求方法和響應(yīng)狀態(tài)編碼無關(guān)。傳輸編碼必須能解釋所有保證傳輸安全和正確的應(yīng)用程序的傳輸編碼。RTSPheaderstartline = RequestLine | StatusLine的。ISO 88591通過在高位填充0，直接轉(zhuǎn)成Unicode。每行結(jié)束處行以CRLF標(biāo)記，但接收方需有能力將CR和LF自行解釋成行終止符。 *選項的名字和描述?，，ptiontag = 1*xcharutcrange?，? clock = utctime [ utctime ]utctime?，?= utcdate T utctime Zutcdate?，?= 8DIGIT?，，，，，，，，?。nptsec標(biāo)志法便于自動生成， ntphhmmss標(biāo)志法便于人閱讀。 any positive numbernptmm?，，?= 1*2DIGIT。它經(jīng)常在VCR上數(shù)字顯示出來。時間戳由一個十進制小數(shù)組成，以秒為單位，小數(shù)點左邊可以是秒或者以小時：分：秒的形式表示。 other timecodes may be added smptetype = smptetime [ smptetime ]（00和01）。sessionid = 1*( ALPHA | DIGIT | safe )這樣就不用RTSP客戶端顯式地提供傳輸信息，而改用其他方式代替，例如，客戶端要求媒體服務(wù)器使用會議描述中的值。 會議標(biāo)識會議標(biāo)識采用URI標(biāo)準(zhǔn)編碼方法（即是說，LWS被轉(zhuǎn)義為%）編碼，并對RTSP不透明。也可以是這樣RTSP URL：rtsp://:554/twister一個表示或者流是通過基于文本的媒體標(biāo)記來標(biāo)識的，此媒體標(biāo)記使用URLs (RFC 1738 [20])中的字符集和轉(zhuǎn)義規(guī)則[]。rtsp前綴要求使用可靠協(xié)議（在Internet上指TCP協(xié)議）發(fā)出命令，而rtspu前綴則說明使用不可靠協(xié)議（在Internet指UDP協(xié)議）。= ALPHA | DIGIT | safe | extra | national | = | + pchar fragment param ******************** 協(xié)議的版本政策傾向于讓發(fā)送方表明其消息的格式及功能，而不僅僅為了獲得通訊的特性，這樣做的目的是為了與更高版本的RTSP實現(xiàn)空元素在結(jié)構(gòu)中可被任意使用，但不參與元素個數(shù)的計數(shù)。 雖然大多數(shù)實時媒體使用RTP作為傳輸層協(xié)議，RTSP并沒有綁定到RTP。 但是，RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以信帶外的不同協(xié)議 RTSP在功能上與HTTP有重疊。 臨時暫停流，而不釋放服務(wù)器資源。PLAY與RECORD： 另一種選擇是，用和RTSP相同的可靠流傳輸媒體服務(wù)器應(yīng)該在公共回應(yīng)頭里列出它所支持的所有方法。 *已有的方法可以擴展加入新參數(shù)，只要這些參數(shù)可以被接收方安全地忽略。但服務(wù)器應(yīng)該實現(xiàn)所有12章中要求的標(biāo)題域。早期曾要求RTSP支持多用戶，但現(xiàn)在有了更好的方案，就是保證RTSP能很容易擴展成支持多用戶即可。服務(wù)器不能啟動一個用戶不能停止的流。這些基礎(chǔ)結(jié)構(gòu)包括Internet 內(nèi)容選擇平臺（PICS：Platform for Internet Content Selection [15,16]），以便通過相關(guān)標(biāo)簽訪問內(nèi)容。 了網(wǎng)頁安全機制。 協(xié)議特點 比如，一個電影的觀看過程。另外，其他IETF協(xié)議，如SDP協(xié)議使用術(shù)語會話(session)代替現(xiàn)場表示。表示使用下面的表示描述進行表述。當(dāng)使用RTP時，流包括由RTP會話(session)中同一個源所創(chuàng)建的所有RTP和RTCP包。媒體服務(wù)器：這包括時鐘頻率，顏色空間等。 請求或者響應(yīng)的載荷部分中所傳輸?shù)男畔ⅰ?接受器和數(shù)據(jù)源之間存在時序關(guān)系的數(shù)據(jù)。 指請求媒體服務(wù)器上連續(xù)流媒體數(shù)據(jù)的客戶端。一些HTTP/。 現(xiàn)場表示 *數(shù)據(jù)由信帶外的另一個協(xié)議傳送（但有一個特例）。1 介紹 60*附錄F 致謝 57*附錄D 最小RTSP實現(xiàn) 55o 有效載荷類型 RTSP協(xié)議狀態(tài)機 52*15 語法 50*13 緩存 49 會話 47 公布 45 來自（From） 42 內(nèi)容編碼（ContentEncoding） 39 允許（Allow） 36 只允許合操作 32 30 存儲空間低 250 27 斷開 25 可靠性及確認 狀態(tài)行 消息頭 會話標(biāo)識 整體運作實時流協(xié)議（RTSP）是應(yīng)用層協(xié)議，控制實時數(shù)據(jù)的傳送 網(wǎng)絡(luò)工作組H. Schulzrinne請求注釋: 2326 A. Rao RealNetworks本備忘錄的傳播不受限制。摘要： 目的 2 符號協(xié)定 絕對時間 *5 普通頭部段 *8 實體 26 描述 28 重定向 34 本狀態(tài)下該方法無效 37 不支持的選項 40 塊大小 43 內(nèi)容位置 45（IfModifiedSince） 49 稍后重試 49 不支持 50 容器文件的流化 52*附錄A 53*附錄B 與RTP協(xié)議的交互 56o 有效時間 58 認證enabled 61換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遙控器。 *RTSP使用ISO 10646(UTF8) 而不是ISO 88591，以配合當(dāng)前HTML的國際化。而由于歷史原因造成的后向兼容性問題，HTTP/，把主機名放入單獨的頭部域中。從媒體服務(wù)器上獲得媒體： 術(shù)語對音頻/視頻的回放來講，這意味著客戶端僅需發(fā)送一條播放或者暫停消息就可同時控制音頻和視頻的回放。容器文件： 數(shù)據(jù)類型/編碼的具體初始化。媒體服務(wù)器重定向： 單個媒體實例，比如，一個音頻流或者一個視頻流，連同一個白板或者共享程序組。由15章語法定義的結(jié)構(gòu)化八位位組序列組成，并通過有連接或者無連接協(xié)議傳送。 作為一個完整的媒體信息，回饋性地表述給客戶端的一個或多個流的集合。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息，的集合。 包括一次RTSP事務(wù)（transaction）的全過程。 RTSP重用 RTS