【正文】 端定向到另外一個媒體服務(wù)器。(媒體)流： 單個媒體實(shí)例，比如，一個音頻流或者一個視頻流，連同一個白板或者共享程序組。當(dāng)使用RTP時，流包括由RTP會話(session)中同一個源所創(chuàng)建的所有RTP和RTCP包。這和DSMCC流([5])的定義相同。消息： RTSP通訊的基本單元。由15章語法定義的結(jié)構(gòu)化八位位組序列組成，并通過有連接或者無連接協(xié)議傳送。參與者：?，Ｒ粋€會議的成員。參與者可以是機(jī)器，比如是媒體記錄或回放服務(wù)器。表示(presentation)： 作為一個完整的媒體信息，回饋性地表述給客戶端的一個或多個流的集合。表示使用下面的表示描述進(jìn)行表述。大部分情況下，在RTSP中的文字部分中，這暗示集合中的流的合控制，但并非必須。表示描述(presentation description)： 表示描述包含在表示(presentation)中一個或者多個媒體流的信息。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息，的集合。另外，其他IETF協(xié)議，如SDP協(xié)議使用術(shù)語會話(session)代替現(xiàn)場表示。表示描述可以采用包括會話描述(session description)SDP在內(nèi)的多種格式。響應(yīng)：?，TSP響應(yīng)。如果能理解HTTP響應(yīng)，就能清楚地理解RTSP響應(yīng)。請求： RTSP請求。如果能理解HTTP請求，就能清楚地理解RTSP請求。RTSP會話(session)： 包括一次RTSP事務(wù)（transaction）的全過程。比如，一個電影的觀看過程。會話(session)一般包括由客戶端為連續(xù)媒體建立傳輸機(jī)制(SETUP)，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關(guān)閉流。傳輸初始化： 客戶端和服務(wù)器端之間關(guān)于傳輸所需的相關(guān)信息（端口號，傳輸協(xié)議等）的協(xié)商。 協(xié)議特點(diǎn) RTSP有以下特性：易于擴(kuò)展： 可以很容易地向RTSP加入新方法和參數(shù)。 易解析： RTSP可由標(biāo)準(zhǔn)HTTP或MIME解析器解析。安全： RTSP重用了網(wǎng)頁安全機(jī)制。所有HTTP授權(quán)機(jī)構(gòu)如basic (RFC 2068 [2, Section ])和digest (RFC 2069 [8])授權(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é)議如TCP。 多服務(wù)器支持： 表示(presentation)中的每個流可放在不同服務(wù)器上，客戶端自動同不同服務(wù)器建立幾個并發(fā)控制的會話，媒體同步在傳輸層執(zhí)行。 錄制設(shè)備控制： 協(xié)議可控制記錄和回放設(shè)備，以及可在兩種模式之間切換的設(shè)備（VCR）。 流控制與會議初始化分離： 流控制與邀請媒體服務(wù)器入會相分離；僅要求會議初始化協(xié)議可提供，或可用來創(chuàng)建具有唯一性的會議標(biāo)識號。具體地說， 可用來邀請服務(wù)器入會。適合專業(yè)應(yīng)用： 通過SMPTE 時標(biāo)，RTSP支持幀級別精度，以支持遠(yuǎn)程數(shù)字編輯。適合專業(yè)應(yīng)用： RTSP依賴SMPTE時間戳支持幀級精度，使得可以進(jìn)行遠(yuǎn)程數(shù)字編輯。表示描述中立： 協(xié)議沒強(qiáng)行指定特定的表示或元文件格式，可傳達(dá)所用的格式類型；然而，表示描述必須至少包含一個RTSP URI。 代理與防火墻友好： 協(xié)議需由應(yīng)用層協(xié)同傳輸層(SOCKS [14])防火墻友好地進(jìn)行處理。防火墻需要理解SETUP方法，以為UDP媒體流打開一個洞口。 HTTP友好： 此處，RTSP明智地重用了HTTP概念，使現(xiàn)有的基礎(chǔ)結(jié)構(gòu)可被重用。這些基礎(chǔ)結(jié)構(gòu)包括Internet 內(nèi)容選擇平臺（PICS：Platform for Internet Content Selection [15,16]），以便通過相關(guān)標(biāo)簽訪問內(nèi)容。但由于在大多數(shù)情況下，控制連續(xù)媒體需要服務(wù)器狀態(tài)， RTSP不僅僅向HTTP 添加方法。 合適的服務(wù)器控制： 若客戶端能啟動一個流，它必須也能停止一個流。服務(wù)器不能啟動一個用戶不能停止的流。傳輸協(xié)商： 實(shí)際處理連續(xù)媒體流前，客戶端可協(xié)商傳輸方法。 性能協(xié)商： 若基礎(chǔ)特性被禁用，必須有某種明確的機(jī)制讓用戶決定哪種方法將不不被實(shí)現(xiàn)。這允許用戶提出適合的用戶界面。 例如，如果不允許尋找，用戶界面必須能禁止位置條滑動。早期曾要求RTSP支持多用戶，但現(xiàn)在有了更好的方案，就是保證RTSP能很容易擴(kuò)展成支持多用戶即可。因?yàn)榱鞯臉?biāo)志可以被多個控制流使用，因此可以輪換持有控制器。協(xié)議不涉及到多個客戶端如何協(xié)調(diào)入口這項(xiàng)任務(wù)被留給社會協(xié)議或其他層。 擴(kuò)展RTSP由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同的請求集。例如：服務(wù)器可能只能回放，因此不必支持錄制請求。用于提供現(xiàn)場直播的服務(wù)器可能不支持尋找（絕對位置）功能。一些服務(wù)器可能不支持設(shè)置流參數(shù)，因此不支持GET_PARAMETER和SET_PARAMETER請求。但服務(wù)器應(yīng)該實(shí)現(xiàn)所有12章中要求的標(biāo)題域。表示描述(presentation description)應(yīng)當(dāng)保證不提出服務(wù)器不支持的功能，這種情形和HTTP/ [2]中，[]所描述的方法不太可能被所有服務(wù)器都支持的情形一致。RTSP 可以如下三種方式擴(kuò)展，按所支持的改變多少排序： *已有的方法可以擴(kuò)展加入新參數(shù)，只要這些參數(shù)可以被接收方安全地忽略。（這和給一種HTML tag增加新標(biāo)簽是一樣的）如果客戶端在請求失敗時需要一個拒絕確認(rèn)，需要在請求：字段(見Section )中加入一個對應(yīng)于該擴(kuò)展的標(biāo)簽。 *可以加入新方法。如果接收方不理解請求，它就返回一個501錯誤碼（意指未實(shí)現(xiàn)），發(fā)送方就不應(yīng)再嘗試這種方法。客戶端可以用OPTIONS方法去詢問服務(wù)器支持的方法。服務(wù)器應(yīng)該在公共回應(yīng)頭里列出它所支持的所有方法。 *可以定義新版本的協(xié)議，以支持幾乎所有方面的改變（除了版本協(xié)議號的位置）。 整體運(yùn)作 每個表示和媒體流可用RTSP URL識別。表示組成的整個表示與媒體屬性由表示描述(presentation description)文件定義，其格式不在本協(xié)議中定義。客戶端可以通過HTTP或其它途徑（如）獲得此表示描述文件，它沒有必要保存在媒體服務(wù)器上。 根據(jù)此規(guī)范的目標(biāo)，我們假想一個表示描述(presentation description)描述了多個表示(presentation)，每個表示(presentation)維持一個統(tǒng)一的時間軸。為簡明但不失一般性，假定表示描述(presentation description)正好包含一個這樣的表示(presentation)。表示(presentation)可包含多個媒體流。 表示描述(presentation description)包含組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數(shù)。在表示描述中，各個由RTSP分別控制的媒體流各有一個RTSP URL。RTSP URL指出了處理具體媒體流的服務(wù)器以及存在于該服務(wù)器上流的名字。多個媒體流可以放到不同的服務(wù)器上，比如音頻和視頻流可以分別放到不同服務(wù)器而實(shí)現(xiàn)均分負(fù)載。描述（description)還列出了服務(wù)器可使用的傳輸方法。 除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。下面區(qū)分幾種操作模式： 單播： 以用戶選擇的端口號將媒體發(fā)送到RTSP請求的來源處。另一種選擇是，用和RTSP相同的可靠流傳輸媒體多播，服務(wù)器選擇地址： 媒體服務(wù)器選擇多播地址和端口，這是現(xiàn)場直播或準(zhǔn)點(diǎn)播常用的方式。 多播，用戶選擇地址： 若服務(wù)器要加入正在進(jìn)行的多播會議，多播地址、端口和密匙由會議描述給出。會議描述的建立不在此規(guī)范中討論。 RTSP狀態(tài) RTSP控制通過與控制通道無關(guān)的獨(dú)立協(xié)議發(fā)送的流。例如，RTSP控制可能是使用TCP連接，而數(shù)據(jù)流使用UDP。因此，即使媒體服務(wù)器沒有收到請求，數(shù)據(jù)也會繼續(xù)發(fā)送。在會話生命期，單個媒體流可通過不同TCP連接按順序發(fā)出的請求來控制。所以，服務(wù)器需要維護(hù)會話狀態(tài)以便使RTSP請求和流相互關(guān)聯(lián)。狀態(tài)之間的轉(zhuǎn)換在附錄A中描述。 RTSP中很多方法與狀態(tài)無關(guān)，但下列方法在服務(wù)器流資源的定位和應(yīng)用上起著重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.SETUP： 讓服務(wù)器給流分配資源，啟動RTSP會話。 PLAY與RECORD： 啟動SETUP所分配的流的數(shù)據(jù)傳輸。 PAUSE： 臨時暫停流，而不釋放服務(wù)器資源。 TEARDOWN： 釋放流占用的資源，RTSP會話停止，從服務(wù)器端退出。 與狀態(tài)相關(guān)的RTSP方法使用會話頭部域（Session header field (Section )）來識別哪個RTSP會話的狀態(tài)需要處理，在SETUP請求()的響應(yīng)中，服務(wù)器生成會話標(biāo)識。 與其他協(xié)議關(guān)系 RTSP在功能上與HTTP有重疊。它也可能與HTTP相互作用，體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許網(wǎng)頁服務(wù)器與RTSP媒體服務(wù)器之間有多種接力點(diǎn)。例如，表示描述(presentation description)可通過HTTP和RTSP得到，這降低了基于瀏覽器的應(yīng)用模式的往返傳遞，也允許完全不依賴HTTP的獨(dú)立RTSP 服務(wù)器與客戶端。 但是，RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以信帶外的不同協(xié)議進(jìn)行。HTTP是不對稱協(xié)議，用戶發(fā)送請求，服務(wù)器作出響應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)送請求。RTSP請求也不是無狀態(tài)的；在請求確認(rèn)后很長時間后，仍可設(shè)置參數(shù)，繼續(xù)控制媒體流。 重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權(quán)上采用HTTP功能是有價值的。 雖然大多數(shù)實(shí)時媒體使用RTP作為傳輸層協(xié)議，RTSP并沒有綁定到RTP。 RTSP假設(shè)存在可表示包含幾個媒體流的表示的靜態(tài)與臨時屬性的表示描述格式。 2 符號約定 既然很多定義和語法與HTTP/，這里僅指出它們在HTTP/。為簡便起見，本文檔中[ ]表示對應(yīng)HTTP/（RFC 2068 [2]）。（[譯者注：]為更方便學(xué)習(xí)RTSP，本翻譯文檔將相關(guān)段落完全譯出）與[]類似，本文對所有機(jī)制的說明都是以增廣BNF的形式來描述的。此形式在RFC 2234中有詳細(xì)的描述，唯一的不同是RTSP中以1代替,為分隔符。********************簡單說明增廣BNF如下：增廣BNF（augmented BNF）包括下面的結(jié)構(gòu)：要解釋的名詞＝名詞解釋（name = definition）規(guī)則的名字（name）就是它本身（不帶任何尖括號，），后面跟個等號＝，然后就是該規(guī)則的定義。如果規(guī)則需要用多個行來描述，利用空格進(jìn)行縮進(jìn)格式排版。某些基本的規(guī)則使用大寫，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定義中還可以使用尖括號來幫助理解規(guī)則名的使用。字面意思（literal） 文字的字面意思放在引號中間，若無特別指定，則該段文字是大小寫敏感的。規(guī)則1｜規(guī)則2（rule1 | rule2） ｜表示其分隔的元素是可選的，比如，是｜否要選擇‘是’或‘否’。（規(guī)則1 規(guī)則2）（(rule1 rule2)）在圓括號中的元素表明必然出現(xiàn)。如（元素1（元素2｜元素3）元素4）可表明兩種意思，即元素1 元素2 元素4和元素1 元素3 元素4*規(guī)則（*rule）在元素前加星號*表示循環(huán)，其完整形式是n*m元素，表明元素最少產(chǎn)生n次，最多m次。缺省值是0到無限，例如，1*元素意思是至少有一個，而1*2元素表明允許有1個或2個。［規(guī)則］（[rule]）方括號內(nèi)是可選元素。如［元素1 元素2］與*1（元素1 元素2）是一回事。N 規(guī)則（N rule）表明循環(huán)的次數(shù)：n（元素）就是n*n（元素），也就是精確指出n取值。因而，2DIGIT 就是2位數(shù)字, 3ALPHA 就是由三個字母組成字符串。＃規(guī)則（rule）與*類似，用于定義元素列表。完整形式是nm元素表示至少有n個至多有m個元素，中間用,或任意數(shù)量的空格（LWS）來分隔，這將使列表非常方便，如（*LWS 元素 *（ *LWS , *LWS 元素 ））就等同于1元素?？赵卦诮Y(jié)構(gòu)中可被任意使用，但不參與元素個數(shù)的計(jì)數(shù)。也就是說，（元素1），（元素2）僅表示2個元素。但在結(jié)構(gòu)中，應(yīng)至少有一個非空的元素存在。缺省值是0到無限，即（元素）表示可取任何數(shù)值，包括0；而1元素表示至少有1個；而12元素表示有1個或2個。 ；注釋（。 ment） 分號后面是注釋，僅在單行使用。隱含*LWS（implied *LWS）本文的語法描述是基于單詞的。除非另有指定，否則線性空格（LWS）可以在兩個鄰近符號或分隔符（tspecials）之間任意使用，而不會對整句的意思造成影響。在兩個符號之間必須有至少一個分隔符，因?yàn)樗鼈円惨鰹閱为?dú)的符號來解釋。實(shí)際上，應(yīng)用程序在產(chǎn)生HTTP結(jié)構(gòu)時，應(yīng)當(dāng)試圖遵照通常方式，因?yàn)楝F(xiàn)在的確有些實(shí)現(xiàn)方式在通常方式下無法正常工作。******************** 在本備忘錄中，我們用縮進(jìn)的小型段落來提供背景和動機(jī)。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來實(shí)現(xiàn)。3 協(xié)議參數(shù) RTSP版本 同[]定義，僅用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版本域來表示。RTSPVersion = RTSP / 1*DIGIT . 1*DIGIT注意，主從版本應(yīng)當(dāng)被看作單獨(dú)的整數(shù)，因?yàn)樗鼈兌加锌赡茉黾?，從而超過一位整數(shù)。因而，RTSP/，而RTSP/。版本號前面的0將被接收方忽略，而在發(fā)送方處也不應(yīng)產(chǎn)生。發(fā)送本規(guī)范定義的請求（Request）或響應(yīng)（Response）消息的應(yīng)用必須指明RTSP的版本為RTSP/。使用該版本號意味著發(fā)送消息的應(yīng)用至少有條件的遵循本規(guī)范。應(yīng)用的RTSP版本即為應(yīng)用至少能有條件遵循的RTSP版本中的最高版本。 當(dāng)代理及網(wǎng)關(guān)收到與其自身版本不同的RTSP請求時，必須小心處理請求的推送，因?yàn)閰f(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關(guān)不應(yīng)發(fā)出高于自身版本的消息。如果收到高版本的請求，代理或網(wǎng)關(guān)必須降低該請求的版本，并響應(yīng)一個錯誤。而低版本的請求也應(yīng)在被推送前升級。代理或網(wǎng)關(guān)響應(yīng)請求時必須和請求的版本相同。******************** RTSP URLrtsp和rtspu前綴表示要通過RTSP協(xié)議來定位網(wǎng)絡(luò)資源。本節(jié)詳細(xì)定義了RTSP URL的語法和語義。rtsp_URL= ( rtsp: | rtspu: ) // host [ : port ] [ abs_path ]host?，，? 合法的Internet主機(jī)域名或IP地址(用十進(jìn)制數(shù)及點(diǎn)組成), 見RFC1123，port ?，? *DIGITabs_path 在 []中定義。********************[]： abs_path = / rel_path rel_path = [ path ] [ 。 params ] [ ? query ] path = fsegment *( / segment ) fsegment = 1*pchar segment = *pchar params = param *( 。 param ) param = *( pchar | / ) scheme = 1*( ALPHA | DIGIT | + | | . ) net_loc = *( pchar | 。 | ? ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | : | @ | amp。 | = | + uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national escape = % HEX HEX reserved = 。 | / | ? | : | @ | amp。 | = | + extra = ! | * | 39。 | ( | ) | , safe = $ | | _ | . unsafe = CTL | SP | | | % | | national = any OCTET excluding ALPHA, DIGIT, reserved, extra, safe, and unsafe 權(quán)威的URL語法及語義信息請參見RFC1738[4]和RFC1808[9]。********************注意：fragment和query標(biāo)識符在這時沒有明確的定義，需要到RTSP服務(wù)器上解釋。rtsp前綴要求使用可靠協(xié)議（在Internet上指TCP協(xié)議）發(fā)出命令，而rtspu前綴則說明使用不可靠協(xié)議（在Internet指UDP協(xié)議）。如是端口為空或沒指定，則缺省為554端口。語義如下：擁有被請求的資源的服務(wù)器主機(jī)通過監(jiān)聽TCP連接(rtsp方案)或主機(jī)上相應(yīng)端