【正文】 時序關系；或者是流（回放）的形式，時序關系沒那么嚴格。RTSP服務器可以為這些容器文件提供合控制，但容器文件的概念本身并不包含在本協(xié)議中。合控制：會議中的各方可輪流按網(wǎng)絡遙控器的按鈕。如果該表示是組播，表示描述就包含用于該連續(xù)媒體的的多播地址和端口。 *RTSP客戶機和服務器都可以發(fā)出請求。盡管如此，RTSP在很多重要方面與HTTP有所不同：在RTSP會話期間，RTSP客戶端可以打開或關閉多個到服務器端的可靠傳輸連接以發(fā)出RTSP請求。 59*附錄E 作者地址 57+ 合控制可用 55o 媒體流 51 錄制 49 WWW認證（WWWAuthenticate） 49 服務器（Server） 47 代理要求 44 過期（Expires） 41 內容基礎 38 接受語言 35 不允許合操作 32 29 27 暫停 流水線化 *7 響應 消息類型 會議標識 RTSP擴展本協(xié)議旨在于控制多個數(shù)據(jù)發(fā)送會話，提供了一種選擇傳送途徑（如UDP、組播UDP與TCP）的方法，并提供了一種選擇基于RTP (RFC1889)的傳送機制的方法。版權聲明：本備忘錄狀態(tài)1998年4月R. LanphierEmail：bryanj譯者： （王晶，寧夏固原）譯文版本：alpha 譯文發(fā)布時間：2007725版權：本中文翻譯文檔之版權歸王晶所有。 哥倫比亞大學.類別: 標準跟蹤 本文為Internet社區(qū)描述了一種Internet標準跟蹤協(xié)議版權為The Internet Society 所有。 要求 3 協(xié)議參數(shù) 選項標簽*6 請求 實體頭部域 26 通知 28 錄制 34 頭部域與資源不匹配 3712 頭部段定義（Header Field Definitions）40 緩存控制 43 內容類型（ContentType） 46 最后修改（LastModified） 49 要求 49 用戶代理（UserAgent） 51 單個流容器文件 53*附錄C 使用SDP進行RTSP會話描述 56o 連接信息 58+ 服務器 表示描述定義了流的控制操作的集合，但本文并沒有規(guī)定表示描述的格式。但也可以使用無連接傳輸協(xié)議，比如UDP，來發(fā)送RTSP請求。 當只有一個IP的主機要提供多個文檔樹時，可使虛擬主機的實現(xiàn)更簡單。如表示僅通過單播發(fā)送給用戶，用戶為了安全應起見要提供目的地址。 和HTTP/，RTSP的請求可由代理、通道與緩存處理。 多方參與的多媒體表示，這里的多方意味著大于或等于一方。媒體初始化：同一個表示(presentation)中不同的媒體流可能來自于不同的媒體服務器。(媒體)流：表示(presentation)：如果能理解HTTP響應，就能清楚地理解RTSP響應。RTSP會話(session)： 可以很容易地向RTSP加入新方法和參數(shù)。安全：獨立于傳輸： 表示(presentation)中的每個流可放在不同服務器上，客戶端自動同不同服務器建立幾個并發(fā)控制的會話，媒體同步在傳輸層執(zhí)行。適合專業(yè)應用： 協(xié)議沒強行指定特定的表示或元文件格式，可傳達所用的格式類型；然而，表示描述必須至少包含一個RTSP URI。HTTP友好： 合適的服務器控制： 實際處理連續(xù)媒體流前，客戶端可協(xié)商傳輸方法。例如：服務器可能只能回放，因此不必支持錄制請求。RTSP 可以如下三種方式擴展，按所支持的改變多少排序： 表示組成的整個表示與媒體屬性由表示描述(presentation description)文件定義，其格式不在本協(xié)議中定義。表示(presentation)可包含多個媒體流。多個媒體流可以放到不同的服務器上，比如音頻和視頻流可以分別放到不同服務器而實現(xiàn)均分負載。單播： 在會話生命期，單個媒體流可通過不同TCP連接按順序發(fā)出的請求來控制。 與其他協(xié)議關系 RTSP請求也不是無狀態(tài) 為簡便起見，本文檔中[ ]表示對應HTTP/（RFC 2068 [2]）。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。規(guī)則1｜規(guī)則2（rule1 | rule2）缺省值是0到無限，例如，1*元素意思是至少有一個，而1*2元素表明允許有1個或2個。＃規(guī)則（rule）與*類似，用于定義元素列表。 除非另有指定，否則線性空格（LWS）可以在兩個鄰近符號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來實現(xiàn)。********************[]：= RTSP / 1*DIGIT . 1*DIGIT發(fā)送本規(guī)范定義的請求（Request）或響應（Response）消息的應用必須指明RTSP的版本為RTSP/。 當代理及網(wǎng)關收到與其自身版本不同的RTSP請求時，必須小心處理請求的推送，因為協(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關不應發(fā)出高于自身版本的消息。 = param *( 。 net_loc = *( uchar | reserved ) reserved unsafe 權威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。資源的請求URI是rtsp_URL。表示的結構關系和各個流的URL在表示描述中定義。的任意長度的字符串。時間編碼的格式為：時：分：秒：，并以 剪輯開始為起點。 = = [ . 1*2DIGIT ]特殊的常數(shù)now定義為現(xiàn)場事件當前瞬間。當處于暫停模式時，NPT停止。 絕對時間 選擇標簽選項標簽是用來指示RTSP新選項的唯一標識符。當注冊新RTSP選項標簽的時候，應該提供以下信息： *描述更為詳細的參考文檔（如果有），比如（按推薦程度排序），RFC，公開發(fā)表的論文，專利文檔，技術報告，源代碼，或者計算機手冊。如定義得較仔細，文本協(xié)議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實現(xiàn)研究原型。的低層傳輸協(xié)議傳送。見[]********************[]：請求（Request）和響應（Response）消息都使用RFC822中實體傳輸部分規(guī)定（作為消息中的有效載荷）的消息格式。********************每個頭部域由后緊跟冒號的名字，單空格（SP），字符及域值組成。fieldname of token, tspecials, and quotedstring頭部域接收的順序并不重要，但良好的習慣是，先發(fā)送主頭部，然后是請求頭部或響應頭部，最后是實體頭部。********************[]：RTSP消息的消息主體（如果有）用來攜帶請求或響應的主體。********************假如返回了長度適當?shù)谋硎久枋觯掌鲬摽偸强梢源_定它的長度即便它是動態(tài)產(chǎn)生，使得沒有必要采用塊傳輸編碼。 Section | | ANNOUNCE Section | PAUSE 。 Section |extensionmethod requestheader 。 UserAgent注意：相對于HTTP/[2]而言，RTSP請求總是包含絕對URL（包括rtsp或rtspu前綴，主機，端口號）而不僅僅是絕對路徑。 Section 5| 。 CRLF這些狀態(tài)碼的完整定義在第十一章。 200 存儲空間不足 。 | 305 未通過認證 。 | 407 需要長度 。 | 452 找不到會話 。 | 460 無法到達目的地址 。 | 505 原因解釋 = *文本, 包括 CR, LF代碼 所有300 見其他 所有305所有402 不在服務器 預處理失敗 所有457所有461 服務器內部錯誤所有501 |盡管如此，響應頭部域語法中可能會加入新的或實驗性的頭部域只要通訊各方能識別它是響應頭部域，其語法就可使用。 Allow 。 Section | 。 Section | extensionheader9 連接 *持久傳輸連接，用于多個請求響應傳輸。這也是通過防火墻從媒體服務器傳送請求到用戶的唯一辦法。如使用可靠傳輸協(xié)議來承載RTSP，則請求不允許重發(fā)，RTSP應用程序必須依賴低層傳輸協(xié)議來保證可靠性。一定數(shù)量的發(fā)往同一個控制末端的包可以放進一個低層PDU或者封裝進一個TCP流里。 DESCRIBE P,S CS, SC P,S OPTIONS CS, SC方向方法是大小寫敏感的。和HTTP不同，一條RTSP消息只要包含載荷（payload），就必須包含內容長度頭部。如低層可靠傳輸協(xié)議（如TCP）和RTSP應用程序都重發(fā)請求，有可能每次丟包都導致兩次重傳。接受方需要確認請求，除非請求是發(fā)給多播組。 管道 messageheader 。 。 | Section ContentBase實體頭部域定義了實體主體的可選元信息；如沒有實體主體，那些定義則是關于請求標識的資源的。 Section Section RetryAfter 。 ProxyAuthenticate 。 =表一: 狀態(tài)碼及適用RTSP方法所有551所有505 找不到會話 找不到會議 所有451 媒體類型不支持 代理需要認證 不允許該方法400 被永久移除 錄制250 已創(chuàng)建 原因RTSP應用程序不被要求了解全部注冊的狀態(tài)碼，當然很明顯這種了解是被期望的。 擴展碼 | 。 未實現(xiàn) 462 | 。 此頭部域對該資源無效 454 | 。 請求實體過長 411 | 。 禁止 401 | 。 被永久移除 250 狀態(tài)碼 *5xx：服務器端出錯 服務器無法滿足合法的請求。 *1xx：通知 已收到請求，繼續(xù)處理狀態(tài)碼用來支持自動操作，原因解釋用來方便人的查看。 Section Section generalheader =HTTP/ 要求服務器能夠理解絕對URL, 但還是期望客戶端使用主機請求頭部。 Section Section 。 | Accept extensionmethod = token PLAY | [ messagebody ] 。 。 Date | Section 如果存在內容長度頭部域（ContentLength header field），它的值（單位為byte）就表示消息體的長度。（注意：空行中只有CRLF。當信息體包含在信息中時，信息體長度由如下因素決定（按優(yōu)先度排列）： 只有當請求方法允許有實體主體的時候才能在請求中包含消息主體。（