RTSP（Real Time Stream Protocol，實時流協(xié)議）是應(yīng)用級協(xié)議，控制實時數(shù)據(jù)的發(fā)送。RTSP提供了一個可擴展框架，使實時數(shù)據(jù)，如音頻與視頻的受控、點播成為可能。數(shù)據(jù) 源包括現(xiàn)插數(shù)據(jù)與存儲在剪輯中的數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道如UDP、多播UDP與TCP等提供途徑，并為選擇基于RTP 上發(fā)送機制提供方法。

一．簡介

1．目的

實時流協(xié)議建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交叉是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當(dāng)多媒 體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關(guān)閉多個對服務(wù)器的可靠傳輸連接以發(fā)出 RTSP請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機制。實時流協(xié) 議在語法和操作上與HTTP 1.1類似，因此HTTP的擴展機制大都可加入RTSP。協(xié)議支持的操作如下：

(1)從媒體服務(wù)器上檢索媒體

用戶可通過HTTP或其他方法提交一個演示描述。如演示是多播，演示時就包含用于連續(xù)媒體的多播地址和端口。如演示僅通過單播發(fā)送給用戶，用戶為了安全應(yīng)提供目的地址。

(2)媒體服務(wù)器邀請進(jìn)入會議

媒體服務(wù)器可被邀請參加正進(jìn)行的會議，或回放媒體，或記錄其中一部分或全部。這種模式在分布式教育應(yīng)用上很有用，會議中幾方可輪流按遠(yuǎn)程控制按鈕。

(3)將媒體加到現(xiàn)成講座中

例如，服務(wù)器告訴用戶可獲得附加媒體內(nèi)容。這對現(xiàn)場講座顯得尤其有用。如HTTP 1.1中類似，RTSP請求可由代理、通道與緩存處理。

2．協(xié)議特點

RTSP有如下特性。

(1) 可擴展性：新方法和參數(shù)很容易加入RTSP。

(2) 易解析：RTSP可由標(biāo)準(zhǔn)HTTP或MIME解析器解析。

(3) 安全：RTSP使用網(wǎng)頁安全機制。

(4) 獨立于傳輸：RTSP可使用不可靠數(shù)據(jù)報協(xié)議(EDP)、可靠數(shù)據(jù)報協(xié)議(RDP)；如要實現(xiàn)應(yīng)用級可靠，可使用可靠流協(xié)議。

(5) 多服務(wù)器支持：每個流可放在不同服務(wù)器上，用戶端自動與不同服務(wù)器建立幾個并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。

(6) 記錄設(shè)備控制：協(xié)議可控制記錄和回放設(shè)備。

(7) 流控與會議開始分離：僅要求會議初始化協(xié)議提供，或可用來創(chuàng)建惟一會議標(biāo)識號。特殊情況下，可用SIP或H.323來邀請服務(wù)器入會。

(8) 適合專業(yè)應(yīng)用：通過SMPTE時標(biāo)，RTSP支持幀級精度，允許遠(yuǎn)程數(shù)字編輯。

(9) 演示描述中立：協(xié)議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。

(10) 代理與防火墻友好：協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個“缺口”。

(11) HTTP友好：此處，RTSP明智地采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet內(nèi)容選擇平臺(PICS)。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài)，RTSP不僅僅向HTFP添加方法。

(12) 適當(dāng)?shù)姆?wù)器控制：如用戶啟動一個流，必須也可以停止一個流。

(13) 傳輸協(xié)調(diào)：實際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。

(14) 性能協(xié)調(diào)：如基本特征無效，必須有一些清理機制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。

3．?dāng)U展RTSP

由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同請求集。RTSP可以如下三種方式擴展：

(1) 以新參數(shù)擴展。如用戶需要拒絕通知，而方法擴展不支持，相應(yīng)標(biāo)記就加人要求的段中。

(2) 加入新方法。如信息接收者不理解請求，返回501錯誤代碼，發(fā)送者不應(yīng)再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務(wù)器支持的方法。服務(wù)器使用公共響應(yīng)頭列出支持的方法。

(3) 定義新版本協(xié)議，允許改變所有部分(協(xié)議版本號位置除外)。

4．操作模式

每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其他途徑用戶可獲得這個文件，它沒有必要保存在媒體服務(wù)器上。為了說明這個 問題，假設(shè)演示描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體 流。除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。

下面區(qū)分幾種操作模式。

(1)單播：用戶選擇的端口號將媒體發(fā)送到RTSP請求源。

(2)服務(wù)器選擇地址多播：媒體服務(wù)器選擇多播地址和端口，這是現(xiàn)場直播或準(zhǔn)點播常用的方式。

(3)用戶選擇地址多播：如服務(wù)器加入正在進(jìn)行的多播會議，多播地址、端口和密鑰由會議描述給出。

5．RTSP狀態(tài)

RTSP控制通過單獨協(xié)議發(fā)送的流，與控制通道無關(guān)。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務(wù)器沒有收到請 求，數(shù)據(jù)也會繼續(xù)發(fā)送。在連接生命期，單個媒體流可通過不同TCP連接順序發(fā)出請求來控制。所以，服務(wù)器需要維持能聯(lián)系流與RTSP請求的連接狀態(tài)。 RTSP中很多方法與狀態(tài)無關(guān)，但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用：

(1) SETUP：讓服務(wù)器給流分配資源，啟動RTSP連接。

(2) PLAY與RECORD：啟動SETUP分配流的數(shù)據(jù)傳輸。

(3) PAUSE：臨時停止流，而不釋放服務(wù)器資源。

(4) TEARDOWN：釋放流的資源，RTSP連接停止。

標(biāo)識狀態(tài)的RTSP方法使用連接頭段識別RTSP連接，為響應(yīng)SETUP請求，服務(wù)器連接產(chǎn)生連接標(biāo)識。

6．與其他協(xié)議的關(guān)系

RTSP在功能上與HTTP有重疊，與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務(wù)器與實現(xiàn) RTSP媒體服務(wù)器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立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)后很長時間內(nèi)，仍可設(shè)置參數(shù)，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要 求非常接近時，在緩存、代理和授權(quán)上采用HTTP功能是有價值的。

當(dāng)大多數(shù)實時媒體使用RTP作為傳輸協(xié)議時，RTSP沒有綁定到RTP。RTSP假設(shè)存在演示描述格式可表示包含幾個媒體流的演示的靜態(tài)與臨時屬性。

二. 協(xié)議參數(shù)

1．RTSP版本

H.321采用，用RTSP代替HTTP。

2．RTSPURL

“rksp"和“rtspu"方案用于指RTSP協(xié)議使用的網(wǎng)絡(luò)資源，為RTSP URL定義方案特定的語法和語義。

3．會議標(biāo)識

會議標(biāo)識對RTSP來說是模糊的，采用標(biāo)準(zhǔn)URI編碼方法編碼，可包含任何八位組數(shù)值。會議標(biāo)識必須全局惟一。

4．連接標(biāo)識

連接標(biāo)識是長度不確定的字符串，必須隨機選擇，至少要8個八位組長，使其很難被猜出。

5．SMPTE相關(guān)時標(biāo)

SMPTE相關(guān)時標(biāo)表示相對剪輯開始的時間，相關(guān)時標(biāo)表示成SMPTE時間代碼，精確到幀級。時間代碼格式為小時：分鐘：秒：幀。缺省smpte格 式是"SMPTE 30"，幀速率為每秒29.97幀。其他SMPTE代碼可選擇使用smpte時間獲得支持(如"SMPIE 25")。時間數(shù)值中幀段值可從0到29。每秒30與29.97幀的差別可將每分鐘的頭兩幀丟掉來實現(xiàn)。如幀值為零，就可刪除。

6．正常播放時間

正常播放時間(NPT)表示相對演示開始的流絕對位置。時標(biāo)由十進(jìn)制分?jǐn)?shù)組成。左邊部分用秒或小時、分鐘、秒表示；小數(shù)點右邊部分表示秒的部分。演 示的開始對應(yīng)0.0秒，負(fù)數(shù)沒有定義。特殊常數(shù)定義成現(xiàn)場事件的當(dāng)前時刻，這也許只用于現(xiàn)場事件。直觀上，NPT是聯(lián)系觀看者與程序的時鐘，通常以數(shù)字式 顯示在VCR上。

7．絕對時間

絕對時間表示成ISO 8601時標(biāo)，采用UTC(GMT)。

8．可選標(biāo)簽

可選標(biāo)簽是用于指定RTSP新可選項的惟一標(biāo)記。這些標(biāo)記用在請求和代理-請求頭段。當(dāng)?shù)怯浶翿TSP選項時，需提供下列信息：

（1）名稱和描述選項。名稱長度不限，但不應(yīng)該多于20個字符。名稱不能包括空格、控制字符。

（2）表明誰改變選項的控制。如IETF，ISO，ITU-T，或其他國際標(biāo)準(zhǔn)團體、聯(lián)盟或公司。

（3）深入描述的參考，如RFC、論文、專利、技術(shù)報告、文檔源碼和計算機手冊。

（4）對專用選項，附上聯(lián)系方式。

三. RTSP信息

RTSP是基于文本的協(xié)議，采用ISO 10646字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更 容易。由于參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低，處理效率沒引起注意。文本協(xié)議很容易以腳本語言(如：Tcl，Visual Basic與Perl)實現(xiàn)研究原型。

ISO 10646字符集避免敏感字符集切換，但對應(yīng)用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通過任何低層傳輸協(xié)議攜帶。

請求包括方法、方法作用于其上的對象以及進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計為在服務(wù)器端只需要少量或不需要狀態(tài)維護。當(dāng)信息體包含在信息中，信息體長度由如下因素決定：

(1)不管實體頭段是否出現(xiàn)在信息中，不包括信息體的響應(yīng)，信息總以頭段后第一個空行結(jié)束。

(2)如出現(xiàn)內(nèi)容長度頭段，其值以字節(jié)計，表示信息體長度。如未出現(xiàn)頭段，其值為零。

(3)服務(wù)器關(guān)閉連接。

注意，RTSP目前并不支持HTTP 1.1“塊”傳輸編碼，需要有內(nèi)容長度頭。假如返回適度演示描述長度，即使動態(tài)產(chǎn)生，使塊傳輸編碼沒有必要，服務(wù)器也應(yīng)該能決定其長度。如有實體，即使必須有內(nèi)容長度，且長度沒顯式給出，規(guī)則可確保行為合理。

從用戶到服務(wù)器端的請求信息在第一行內(nèi)包括源采用的方法、源標(biāo)識和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼，但沒有定義任何HTTP代碼。

四. 實體

如不受請求方法或響應(yīng)狀態(tài)編碼限制，請求和響應(yīng)信息可傳輸實體，實體則由實體頭文件和實體體組成，有些響應(yīng)僅包括實體頭。在此，根據(jù)誰發(fā)送實體、誰接收實體，發(fā)送者和接收者可分別指用戶和服務(wù)器。

實體頭定義實體體可選元信息，如沒有實體體，指請求標(biāo)識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協(xié)議，但這些段不能假定接收者能識別。不可識別頭段應(yīng)被接收者忽略，而讓代理轉(zhuǎn)發(fā)。

五. 連接

RTSP請求可以幾種不同方式傳送：

·             持久傳輸連接，用于多個請求／響應(yīng)傳輸。

·             每個請求／響應(yīng)傳輸一個連接。

·             無連接模式。

傳輸連接類型由RTSP URL來定義。對“rtsp'’方案，需要持續(xù)連接；而"rtspu"方案，調(diào)用RTSP請求發(fā)送，而不用建立連接。

不像HTTP，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請求。然而，這僅在持久連接時才支持，否則媒體服務(wù)器沒有可靠途徑到達(dá)用戶，這也是請求通過防火墻從媒體服務(wù)器傳到用戶的惟一途徑。

六. 方法定義

方法記號表示資源上執(zhí)行的方法，它區(qū)分大小寫。新方法可在將來定義，但不能以$開頭。已定義方法如表14-03-1所示。

表14-03-1   RTSP方法

注：P----演示，S----流，C----用戶端，S----服務(wù)器端

某些防火墻設(shè)計與其他環(huán)境可能要求服務(wù)器插入RTSP方法和流數(shù)據(jù)。由于插入將使客戶端和服務(wù)器操作復(fù)雜，并增加附加開銷，除非有必要，應(yīng)避免這樣 做。插入二進(jìn)制數(shù)據(jù)僅在RTSP通過TCP傳輸時才可使用。流數(shù)據(jù)(如RTP包)用一個ASCII字符$封裝，后跟一個一字節(jié)通道標(biāo)識，其后是封裝二進(jìn)制 數(shù)據(jù)的長度，兩字節(jié)整數(shù)。流數(shù)據(jù)緊跟其后，沒有CRLF，但包括高層協(xié)議頭。每個$塊包含一個高層協(xié)議數(shù)據(jù)單元。

當(dāng)傳輸選擇為RTP，RTCP信息也被服務(wù)器通過TCP連接插入。缺省情況下，RTCP包在比RTP通道高的第一個可用通道上發(fā)送?？蛻舳丝赡茉诹? 一通道顯式請求RTCP包，這可通過指定傳輸頭插入?yún)?shù)中的兩個通道來做到。當(dāng)兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當(dāng)網(wǎng)絡(luò)設(shè)置需要 通過TCP控制連接透過RTP／RTCP提供了一條方便的途徑，可能時，在UDP上進(jìn)行傳輸。

七. 流水線操作

支持持久連接或無連接的客戶端可能給其請求排隊。服務(wù)器必須以收到請求的同樣順序發(fā)出響應(yīng)。如果請求不是發(fā)送給多播組，接收者就確認(rèn)請求，如沒有確認(rèn)信息，發(fā)送者可在超過一個來回時間(RTT)后重發(fā)同一信息。

在TCP中RTT估計的初始值為500ms。應(yīng)用緩存最后所測量的RTT，作為將來連接的初始值。如使用一個可靠傳輸協(xié)議傳輸RTSP，請求不允許 重發(fā)，RTSP應(yīng)用反過來依賴低層傳輸提供可靠性。如兩個低層可靠傳輸(如TCP和RTSP)應(yīng)用重發(fā)請求，有可能每個包損失導(dǎo)致兩次重傳。由于傳輸棧在 第一次嘗試到達(dá)接收者前不會發(fā)送應(yīng)用層重傳，接收者也不能充分利用應(yīng)用層重傳。如包損失由阻塞引起，不同層的重發(fā)將使阻塞進(jìn)一步惡化。時標(biāo)頭用來避免重發(fā) 模糊性問題，避免對圓錐算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每發(fā)送一個不同請求，它就加一。如由于沒有確認(rèn)而重發(fā)請求，請求必須攜帶初始 系列號。

實現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP，并支持UDP。對UDP和TCP，RTSP服務(wù)器的缺省端口都是554。許多目的一致的 RTSP包被打包成單個低層PDU或TCP流。RTSP數(shù)據(jù)可與RTP和RTCP包交叉。不像HTTP，RTSP信息必須包含一個內(nèi)容長度頭，無論信息何 時包含負(fù)載。否則，RTSP包以空行結(jié)束，后跟最后一個信息頭。