RTSP協(xié)議中文版

1 緒論

1.1 目的
實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流有可能交叉，但RTSP本身通常并不發(fā)送連續(xù)媒體流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。

表示描述(presentation description)定義了被控流，但本文并沒有定義表示描述的格式。

這里沒有使用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有很大的不同：

2 RTSP引入了很多新方法并且有不同的協(xié)議標(biāo)識符。
2 RTSP服務(wù)器在大多數(shù)默認(rèn)情況下需要維持一個(gè)狀態(tài)，但HTTP是無狀態(tài)協(xié)議。
2 RTSP客戶機(jī)和服務(wù)器都可以發(fā)出請求。
2 數(shù)據(jù)由另一個(gè)協(xié)議傳送（有一特例除外）。
2 RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當(dāng)前HTML的國際化。
2 RTSP使用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ù)媒體的例子是音頻和動(dòng)畫視頻。連續(xù)媒體可以是實(shí)時(shí)的（但是不交互的），它們在源和接受器之間是一種緊密的時(shí)序關(guān)系；或者是流的形式，這種關(guān)系就沒有那么嚴(yán)格了。
實(shí)體：
作為請求或者回應(yīng)的有效負(fù)荷傳輸?shù)男畔ⅰＳ梢詫?shí)體標(biāo)題域（entity-header field）形式存在的元信息和以實(shí)體主體（entity body）形式存在的內(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)：
對用戶請求所回饋的一組流，其使用下面的表示描述(presentation description)形式。在本文中的多數(shù)情況下，其意味著對流進(jìn)行總體控制，但這并不是必須的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一個(gè)或者多個(gè)媒體流的信息。比如，編碼，網(wǎng)絡(luò)地址和內(nèi)容的信息。另外，其他IETF協(xié)議，如SDP協(xié)議使用會話(session)代替現(xiàn)場presentation。表示描述可以采用包括會話描述(session description)SDP在內(nèi)的多種格式。
回Γ?br />?，TSP回應(yīng)。如果能理解HTTP回應(yīng)，就能清楚的理解RTSP回應(yīng)。
請求；
?，TSP請求。如果能理解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ù)器上，用戶端自動(dòng)同不同服務(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è)RTSP URI。
代理與防火墻友好：
協(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ù)器控制：
　 如用戶能啟動(dòng)一個(gè)流，它必須也能停止一個(gè)流。 服務(wù)器不能啟動(dòng)一個(gè)用戶不能停止的流。
傳輸協(xié)調(diào)：
　 實(shí)際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。
性能協(xié)調(diào)：
如基本特征無效，必須有一些清理機(jī)制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。 例如，如果不允許尋找，用戶界面必定能禁止位置條滑動(dòng)。
以前要求RTSP必須能支持多用戶，但現(xiàn)在得出一個(gè)更好的方法就是保證RTSP能很容易擴(kuò)展成支持多用戶即可。因?yàn)榱鞯臉?biāo)志可以被多個(gè)控制流使用，因此”遠(yuǎn)程通過”成為可能。協(xié)議不涉及到多個(gè)客戶端如何協(xié)調(diào)入口，其由下層“社會協(xié)議”或其他下層控制機(jī)制提供。
1.5 RTSP擴(kuò)展
由于不是所有媒體服務(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/1.1中[H19.6]描述方法不支持across server的情形一致。
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è)表示和媒體流可用RTSP URL識別。表示組成的整個(gè)表示與媒體屬性由表示描述(presentation description)文件定義，表示描述格式不在本協(xié)議中定義。使用HTTP或其它途徑用戶可獲得這個(gè)文件，它沒有必要保存在媒體服務(wù)器上。
　 為了說明，假設(shè)表示描述(presentation description)描述了多個(gè)表示(presentation)，其中每個(gè)表示(presentation)維持了一個(gè)公共時(shí)間軸。為簡化說明，且不失一般性，假定表示描述(presentation description)的確包含這樣一個(gè)表示(presentation)。表示(presentation)可包含多個(gè)媒體流。
表示描述(presentation description)即組成表示的流的描述，包括它們的編碼，語言和使用戶可以選擇最符合要求媒體的其他參數(shù)。在表示描述中，被RTSP分別控制的媒體流由RTSP URL表示。RTSP URL指出了處理具體媒體流的服務(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.7 RTSP狀態(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ù)器給流分配資源，啟動(dòng)RTSP會話。
PLAY與RECORD：
　 啟動(dòng)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)。例如，表示描述(presentation description)可通過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（RFC 2068）中的X.Y部分。（[譯者注：]為更方便學(xué)習(xí)RTSP，本翻譯文檔將相關(guān)段落完全譯出）

與[H2.1]類似，本文對所有機(jī)制的說明都是以散文和補(bǔ)充反饋的方式來描述的。除RTSP中以”1#”代替”,”為分隔符不同外，其余在RFC 2234中有詳細(xì)的描述。簡單說明補(bǔ)充反饋方式如下：

補(bǔ)充反饋方式（augmented BNF）包括下面的結(jié)構(gòu)：

要解釋的名詞＝名詞解釋（name = definition）
規(guī)則的名字（name）就是它本身（不帶任何尖括號，“

字面意思（"literal"）
文字的字面意思放在引號中間，除非特別指定，該段文字是大小寫敏感的。

規(guī)則1｜規(guī)則2（rule1 | rule2）
“｜”表示其分隔的元素是可選的，比如，“是｜否”要選擇‘是’或‘否’。

（規(guī)則1　規(guī)則2）（(rule1 rule2)）
在圓括號中的元素表明必選其一。如（元素1（元素2｜元素3）元素4）可表明兩
種意思，即“元素1　元素2　元素4”和“元素1　元素3　元素4”

*規(guī)則（*rule）
在元素前加星號“*”表示循環(huán)，其完整形式是“

〔規(guī)則〕（[rule]）
方括號內(nèi)是可選元素。如“〔元素1　元素2〕”與“*1（元素1　元素2）”是一回事。

N　規(guī)則（N rule）
表明循環(huán)的次數(shù)：“

＃規(guī)則（#rule）
“#”與“*”類似，用于定義元素列表。

完整形式是“

空元素在結(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)的小型段落來提供動(dòng)機(jī)和背景資料。這將使沒有參與制定RTSP規(guī)范的讀者更容易理解RTSP中各部分為什么要以該方式來實(shí)現(xiàn)。

3 協(xié)議參數(shù)
3.1 RTSP版本
同[H3.1]定義，僅用RTSP代替HTTP即可。如下：
RTSP采用主從（

本文檔定義了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)?br />協(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.2 RTSP URL
“rtsp”和“rtspu”表示要通過RTSP協(xié)議來定位網(wǎng)絡(luò)資源。本節(jié)詳細(xì)定義了RTSP URL的語法和語義。
rtsp_URL= ( "rtsp:" | "rtspu:" ) "http://" host [ ":" port ] [ abs_path ]
host?，?

9 連接
　 RTSP請求可以幾種不同方式傳送：
　 1、持久傳輸連接，用于多個(gè)請求/回應(yīng)傳輸。
　 2、每個(gè)請求/回應(yīng)傳輸一個(gè)連接。
　 3、無連接模式。
　 傳輸連接類型由RTSP URI來定義。對 /"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ì)，初始值為500 ms。應(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 方法定義（method token）表示了對請求統(tǒng)一資源標(biāo)志符（Request-URI）識別的資源所執(zhí)行的操作。方法名區(qū)分大小寫。將來可能定義新的方法。方法名可能不以美元符'＄'（十進(jìn)制數(shù)24）開頭，但必須具有表征意義(must be a token)。

表格2是對方法的一個(gè)小結(jié)。

method direction object requirement

DESCRIBE C -> S P,S recommended

ANNOUNCE C -> S,S ->C P,S optional

GET PARAMETER C -> S,S ->C P,S optional

OPTIONS C -> S,S ->C P,S required(S ! C: optional)

PAUSE C -> S P,S recommended

PLAY C -> S P,S required

RECORD C -> S P,S optional

REDIRECT S ->C P,S optional

SETUP C -> S S required

SET PARAMETER C -> S,S ->C P,S optional

TEARDOWN C -> S P,S required

表2：對RTSP方法，和其操作方向及所操作對象（P: 表示, S: 媒體流）的一個(gè)概覽

注意：PAUSE方法是推薦的, 但在構(gòu)建一個(gè)全功能的服務(wù)器（fully functional server）

時(shí)可能不支持此方法，這時(shí)就不需要它，比如對于live feeds。如果服務(wù)器不支持某個(gè)特殊

方法，它必將返回"501 Not Implemented"，并且客戶端應(yīng)該不再向該服務(wù)器請求該方法。

（注：Presentation是一個(gè)以完整的media feed呈現(xiàn)給client的一個(gè)或多個(gè)媒體流的集合，

暫且翻譯成表示）

10.1 OPTIONS

其行為與[H9.2]中描述的等同。OPTIONS請求可能在任何時(shí)候發(fā)出，例如客戶端將要發(fā)

出一個(gè)非標(biāo)準(zhǔn)的請求時(shí)。它不影響服務(wù)器狀態(tài)。

示例：

C->S: OPTIONS * RTSP/1.0

CSeq: 1

Require: implicit-play

Proxy-Require: gzipped-messages

S->C: RTSP/1.0 200 OK

CSeq: 1

Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

注意：這些都是必要的構(gòu)造特征（necessarily fictional features）。 (你可能不希望我

們?nèi)ビ幸夂雎阅切?shí)際上有用的特征，因此在這一部分中我們將給出一個(gè)詳細(xì)的例子)。

10.2 DESCRIBE

DESCRIBE方法從服務(wù)器檢索表示的描述或媒體對象，這些資源通過請求統(tǒng)一資源定位符（the request URL）識別。此方法可能結(jié)合使用Accept首部域來指定客戶端理解的描述格式。服務(wù)器端用被請求資源的描述對客戶端作出響應(yīng)。DESCRIBE的答復(fù)-響應(yīng)對（reply-response pair）組成了RTSP的媒體初始化階段。

示例：

C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl, application/mheg

S->C: RTSP/1.0 200 OK

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Content-Type: application/sdp

Content-Length: 376

v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 3456 RTP/AVP 0

m=video 2232 RTP/AVP 31

m=whiteboard 32416 UDP WB

a=orient:portrait

DESCRIBE響應(yīng)必須包含它所描述資源的所有媒體初始化信息。如果媒體客戶端從一個(gè)數(shù)據(jù)源獲得表示描述，而非通過DESCRIBE，并且該描述包含了一個(gè)媒體初始化參數(shù)的全集，那么客戶端就應(yīng)該使用這些參數(shù)，而不是再通過RTSP請求相同媒體的描述。

再有，服務(wù)器不應(yīng)該（SHOULD NOT）使用DESCRIBE響應(yīng)作為media indirection的方法。

需要建立基本的規(guī)則，使得客戶端有明確的方法了解何時(shí)通過DESCRIBE請求媒體初始化信息，何時(shí)不請求。強(qiáng)制DESCRIBE響應(yīng)包含它所描述媒體流集合的所有初始化信息，不鼓勵(lì)將DESCRIBE用作media indirection的方法，通過這兩點(diǎn)避免了使用其他方法可能會引起的循環(huán)問題（looping problems）

媒體初始化是任何基于RTSP系統(tǒng)的必要條件，但RTSP規(guī)范并沒有規(guī)定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過3種方法來接收媒體初始化信息：

. DESCRIBE方法；

.其它一些協(xié)議（HTTP，email附件，等）；

.命令行或標(biāo)準(zhǔn)輸入（同一個(gè)SDP或其它媒體初始化格式的文件一起啟動(dòng)，工作方式類似于瀏覽器的幫助程序）。

為了實(shí)際協(xié)同工作，嚴(yán)重（）推薦最精簡的服務(wù)器也支持DESCRIBE方法，最精簡的客戶端也支持從標(biāo)準(zhǔn)輸入，命令行和/或其它對于客戶端操作環(huán)境合適的方法來接收媒體初始化文件的能力。

10.3 ANNOUNCE

ANNOUNCE方法有兩個(gè)用途：

當(dāng)客戶端向服務(wù)器發(fā)送時(shí)，ANNOUNCE將通過請求URL識別的表示描述或者媒體對象提交給服務(wù)器；

當(dāng)服務(wù)器相客戶端發(fā)送時(shí)，ANNOUNCE實(shí)時(shí)更新會話描述。

如果有新的媒體流加到表示中（比如在一個(gè)現(xiàn)場表示中），整個(gè)表示描述應(yīng)該重發(fā)；而不只是增加組件，如果這樣做的話，組件也可以被刪除了。

示例：

C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344

Content-Type: application/sdp

Content-Length: 332

v=0

o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 3456 RTP/AVP 0

m=video 2232 RTP/AVP 31

S->C: RTSP/1.0 200 OK

CSeq: 312

10.4 SETUP

SETUP請求為URI指定流式媒體的傳輸機(jī)制。客戶端能夠發(fā)出一個(gè)SETUP請求為正在播放的媒體流改變傳輸參數(shù)，服務(wù)器可能同意這些參數(shù)的改變。若是不同意，它必須響應(yīng)錯(cuò)誤"455 Method Not Valid In This State"。 為了盡量繞開防火墻干涉，即使它不會影響參數(shù)，客戶端也必須指出傳輸參數(shù)，例如，指出服務(wù)器向外發(fā)布的固定的廣播地址。

由于SETUP包括了所有傳輸初始化信息，防火墻和其他中間的網(wǎng)絡(luò)設(shè)備（它們需要這些信息）分讓了解析DESCRIBE響應(yīng)的繁瑣任務(wù)，這些任務(wù)留給了媒體初始化。

Transport首部域指定了客戶端數(shù)據(jù)傳輸時(shí)可接受的傳輸參數(shù)；響應(yīng)包含了由服務(wù)器選出的傳輸參數(shù)。

C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

S->C: RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

作為對SETUP請求的響應(yīng)，服務(wù)器產(chǎn)生了會話標(biāo)志符。如果對服務(wù)器的請求中包含了會話標(biāo)志符，服務(wù)器必須將此setup請求捆綁到一個(gè)存在的會話，或者返回"459 Aggregate Operation Not Allowed"。

10.5 PLAY

PLAY方法告知服務(wù)器通過SETUP中指定的機(jī)制開始發(fā)送數(shù)據(jù) 。在尚未收到SETUP請求的成功應(yīng)答之前，客戶端不可以發(fā)出PLAY請求。PLAY請求將正常播放時(shí)間（normal play time）定位到指定范圍的起始處，并且傳輸數(shù)據(jù)流直到播放范圍結(jié)束。PLAY請求可能被管道化（pipelined），即放入隊(duì)列中（queued）；服務(wù)器必須將PLAY請求放到隊(duì)列中有序執(zhí)行。也就是說，后一個(gè)PLAY請求需要等待前一個(gè)PLAY請求完成才能得到執(zhí)行。

比如，在下例中，不管到達(dá)的兩個(gè)PLAY請求之間有多緊湊，服務(wù)器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到結(jié)束。

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 835

Session: 12345678

Range: npt=10-15

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 836

Session: 12345678

Range: npt=20-25

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 837

Session: 12345678

Range: npt=30-

結(jié)合PAUSE請求的描述，看更深一層的示例。

不含Range首部域的PLAY請求也是合法的。它從媒體流開頭開始播放，直到媒體流被暫停。如果媒體流通過PAUSE暫停，媒體流傳輸將在暫停點(diǎn)（the pause point）重新開始。

如果媒體流正在播放，那么這樣一個(gè)PLAY請求將不起更多的作用，只是客戶端可以用此來測試服務(wù)器是否存活。

Range首部域可能包含一個(gè)時(shí)間參數(shù)。該參數(shù)以UTC格式指定了播放（palayback）開始的時(shí)間。如果在這個(gè)指定時(shí)間后收到消息，那么播放立即開始。時(shí)間參數(shù)可能用來幫助同步從不同數(shù)據(jù)源獲取的數(shù)據(jù)流。

對于一個(gè)點(diǎn)播（On-demand）媒體流，服務(wù)器用播放（play back）的實(shí)際范圍答復(fù)請求。This

may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source.如果在請求中沒有指定范圍，當(dāng)前位置將在答復(fù)中返回。答復(fù)中播放范圍的單位與請求中相同。在播放完被要求的范圍后，表示將自動(dòng)暫停，就好像發(fā)出了一個(gè)PAUSE請求。

下面的示例在play整個(gè)表示時(shí)從SMPTE時(shí)間0:10:20直到剪輯（clip）結(jié)束。播放開始于1997年1月23號，15點(diǎn)36分

C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0

CSeq: 833

Session: 12345678

Range: smpte=0:10:20-;time=19970123T153600Z

S->C: RTSP/1.0 200 OK

CSeq: 833

Date: 23 Jan 1997 15:35:06 GMT

Range: smpte=0:10:22-;time=19970123T153600Z

For playing back a recording of a live presentation, it may be desirable to use clock

units:

C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0

CSeq: 835

Session: 12345678

Range: clock=19961108T142300Z-19961108T143520Z

S->C: RTSP/1.0 200 OK

CSeq: 835

Date: 23 Jan 1997 15:35:06 GMT

只有播放的媒體服務(wù)器必須支持npt時(shí)間格式，可能支持clock和smpte格式。

10.6 PAUSE

PAUSE請求引起媒體流傳輸?shù)臅簳r(shí)中斷。如果請求URL中指定了具體的媒體流，那么只有該媒體流的播放和記錄被暫停（halt）。比如，指定暫停音頻，播放將會無聲。如果請求URL指定了一個(gè)表示或者媒體流已成組，那么在該表示或組中的所有當(dāng)前活動(dòng)流的傳輸將被暫停。在重啟播放或記錄后，必須維護(hù)不同媒體軌跡（track）的同步。盡管服務(wù)器可能在暫停后，在timeout的時(shí)間內(nèi)關(guān)閉會話，釋放資源，但是任何資源都必須保存，其中timeout參數(shù)位于SETUP消息的會話頭中。

示例：

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 834

Date: 23 Jan 1997 15:35:06 GMT

PAUSE請求中可能包含一個(gè)Range首部域用來指定何時(shí)媒體流或表示暫停，我們稱這個(gè)時(shí)刻為暫停點(diǎn)（pause point）。該首部域必須包含一個(gè)精確的值，而不是一個(gè)時(shí)間范圍。媒體流的正常播放時(shí)間設(shè)置成暫停點(diǎn)。當(dāng)服務(wù)器遇到在任何當(dāng)前掛起（pending）的PLAY請求中指定的時(shí)間點(diǎn)后，暫停請求生效。如果Range首部域指定了一個(gè)時(shí)間超出了任何一個(gè)當(dāng)前掛起的PLAY請求，將返回錯(cuò)誤"457 Invali