RTSP，實時流協議，是一個C/S多媒體節目協議， 它可以控制流媒體數據在IP網絡上的發送，同時提供用于音頻和視頻流的“VCR模式”遠程控制功能，如停止、快進、快退和定位。同時RTSP又是一個應用 層協議

，用來與諸如RTP、RSVP等更低層的協議一起，提供基于Internet的整套流化服務。基于RTSP協議流媒體服務器的實現方案可以讓流媒體在IP 上自由翱翔。

RTSP協議

1．協議特點

RTSP協議具有如下的特點：

● 可擴展性：新方法和參數很容易加入RTSP。

● 易解析：RTSP可由標準 HTTP或MIME解析器解析。

● 安全：RTSP使用網頁安全機制。

● 獨立于傳輸：RTSP傳輸通道，可使用不可靠數據包協議（UDP）或可靠數據包協議（RDP），如要實現應用級可靠，可使用諸如TCP的可靠流協議。

● 記錄設備控制：協議可控制記錄和回放設備。

● 適合專業應用：通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯。

● 演示描述中立：協議未強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少需包含一個RTSP URI。

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

● 適當的服務器控制：如用戶啟動一個流，則也可以停止一個流。

● 傳輸協調：實際處理連續媒體流前，用戶可協調傳輸方法。

● 性能協調：如基本特征無效，則必須有一些清理機制讓用戶決定那種方法不生效。這允許用戶提出適合自己的界面。

2．同其他協議的關系

RTSP在功能上與HTTP有重疊，最明顯的交叉是在流媒體內容的發布上——大多是通過網頁進行的。目前的協議規范同時允 許網頁服務器和流媒體服務器支持RTSP實現。例如，演示描述可通過HTTP或RTSP獲取，這樣減少了基于瀏覽器情況下的往返傳遞時間，同時也支持獨立 的RTSP 服務器與不依賴HTTP的客戶端通信。

但是，RTSP與HTTP 的本質差別在于以下五個方面

● RTSP和HTTP是兩個不同的協議，它們采用不同的方法和協議標志符。

● RTSP協議的數據發送不占用協議帶寬，并且以不同的協議發送。

● HTTP是一個不對稱協議，客戶端發出請求，服務器應答。在RTSP中，客戶端和服務器都可發出請求，且請求是有狀態的。

● HTTP是一個無狀態協議，而RTSP在任何情況下，必須保持一定狀態，以便在請求確認后的很長時間內，仍可設置參數，控制媒體流。

● RTSP使用ISO 10646（UTF-8）定義，而不使用ISO 8859-1定義，保持與當前的HTML一致。

雖然大多數實時媒體采用RTP作為傳輸協議，但RTSP并不綁定RTP。

重用HTTP的功能至少在兩個方面有好處:安全和代理。由于要求非常接近，因此在緩存、代理和授權上采用HTTP功能是有 價值的。

RTSP的實現

RTSP功能實現結構如下圖所示。

RTSP在流媒體傳輸過程中，僅僅為雙方建立連接，并不具備任何智能，也就不能很好地應付難以預料的網絡狀態。因此，必須 在它原有功能的基礎上，進行改進。

1、初始化

在建立連接之前，客戶端應向服務器提出測試請求，即要求服務器向客戶端發送相應的測試數據包。初始化的目的，是為了獲取客 戶端和服務器之間的一些網絡參數，估測基本網絡狀況，并以此選擇相應的網絡傳輸協議，使客戶端獲得最佳觀看效果。

接到這個請求之后，服務器將根據自身情況進行如下測試：

● 利用同客戶端建立的RTSP通道，采用TCP協議，下發測試數據包。

● 采用UDP協議，向客戶端下發測試數據包。

測試數據包僅做測試用，上面帶有相應的時間和順序信息，其內部數據并無任何意義。

需要向RTSP增加一個新的方法TEST，以支持這種傳輸前的測試工作。

2、TCP傳輸

如果在TCP測試中，客戶端反饋良好，即丟包率在可承受范圍之內，并且在規定時間內到達，那么就認為客戶端同服務器之間的 網絡狀況良好， 可以采用RTP over TCP的方式發送數據。由于TCP沒有丟包（其自身具有重傳機制），網絡狀況又屬于良好，因此客戶端將有較高的視聽享受。

當子網內存在防火墻時，就需要采用RTSP附加數據傳輸方式。即把音視頻數據直接打包，在RTSP通信信道內傳輸。這種傳 輸方式也存在一定的問題：

● 傳輸過程中，只是把音視頻文件當成一個普通文件來處理，而沒有考慮到它的音視頻特性，不利于以后的擴展。

● 音頻與視頻文件沒有分離，不利于某些特殊需求的場合。例如，客戶端需要對音、視頻做不同的處理。

● 客戶端的反饋和RTSP的控制信息也是通過同一條RTSP信道傳送，因此控制效率不高。

因此，一般情況下，都默認使用RTP over TCP的方式發送數據。

3、UDP傳輸

如果在TCP測試中，客戶端的反饋存在比較大的問題，即網絡情況不理想，就應該考慮進行UDP測試。

目前初步采取的措施，在服務器端準備了兩種碼率的視頻文件——高碼率和低碼率。

收到客戶端的TEST方法后，將采用UDP協議下發測試包。采取的策略是每間隔2秒，下發一個1500字節的UDP數據 包。當丟包率處于一定范圍（75％～85％）之內，就認為客戶端的網絡狀況基本良好，可以下發高碼率的電影文件;否則，認為測試不成功，由于網絡狀況的限 制，僅對客戶端下發低碼率的電影文件。

在基于UDP的播放過程中，可能會出現輕微的馬賽克，這是完全可以接受的。這些馬賽克出現的主要原因是：

● 不可靠連接造成的網絡丟包，為客戶端被動丟包。

● 高質量文件（DVD－>MP4）的高數據量，使得客戶端解碼線程和顯示線程出現擁塞，從而出現客戶端主動丟包。

但從整體而言，UDP傳輸消耗的帶寬，要比TCP小許多。在一般的視頻點播要求下，使用基于UDP的傳輸線路，是完全可以 滿足要求的。

4、傳輸反饋

在傳輸過程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，還存在一個回傳端口RTCP。

在服務器收到客戶端的RTCP回傳信息后，需要對其進行判斷。如果客戶端的丟包率、解碼率等指標在一定限度之下，就認為目 前傳送的視頻文件可令客戶端獲得最大程度的音視頻享受;否則，考慮改為傳輸更低碼率的視頻文件或放棄這次RTSP會話，以避免更大范圍的擁塞。

5、實際效果

采取如上方法設計的系統，可以滿足視頻點播的基本要求，避免了服務器視頻文件下發的盲目性，同時使客戶端應用效果最好。

引入智能流技術

隨著針對流媒體技術研究的不斷深入，簡單的流媒體實現已經不能滿足人們日益增長的網絡文化需求。即使在寬帶條件下，當網絡 用戶達到一定限額時，簡單的流媒體技術將面臨著網絡擁塞、丟包等常見的網絡問題。因此，如何在網絡出現異常的情況下，依然保證客戶端音視頻享受的最大化， 就成為現在研究的熱點。

一種解決方法是服務器減少發送給客戶端的數據而阻止再緩沖，在RealSystem 5.0中，這種方法稱為“視頻流瘦化”。這種方法的限制是RealVideo文件必須是一種數據速率設計，結果可通過抽取內部幀擴展到更低速率，導致質量 較低，離原始數據速率越遠，質量越差。

另一種解決方法是根據不同連接速率創建多個文件，根據用戶連接，服務器發送相應文件，這種方法帶來制作和管理上的困難，而 且，用戶連接是動態變化的，服務器也無法實時協調。

智能流技術通過兩種途徑克服帶寬協調和流瘦化:首先，確立一個編碼框架，允許不同速率的多個流同時編碼，合并到同一個文件 中；第二，采用一種復雜客戶/服務器機制探測帶寬變化。

針對軟件、設備和數據傳輸速度上的差別，用戶以不同帶寬瀏覽音視頻內容。為滿足客戶要求，Real Networks公司編碼、記錄不同速率下媒體數據，并保存在單一文件中，此文件被稱為智能流文件，即創建可擴展流式文件。當客戶端發出請求時，它將其帶 寬容量傳給服務器，媒體服務器根據客戶帶寬將智能流文件相應部分傳送給用戶。以此方式，用戶可使用最優質的傳輸，制作人員只需要壓縮一次，管理員也只需要 維護單一文件，而媒體服務器根據所得帶寬自動切換。智能流通過描述Internet上變化的帶寬特點來發送高質量媒體并保證其可靠性，并對混合連接環境的 內容授權提供了解決方法。這樣流媒體實現方式如下：對所有連接速率環境創建一個文件。在混合環境下以不同速率傳送媒體。根據網絡的變化情況，無縫切換到其 他速率。關鍵幀優先，音頻比部分視頻幀數據更重要，向后兼容老版本RealPlayer。

端口說明：554端口默認情況下用于“Real Time Streaming Protocol”（實時流協議，簡稱RTSP），該協議是由RealNetworks和Netscape共同提出的，通過RTSP協議可以借助于 Internet將流媒體文件傳送到RealPlayer中播放，并能有效地、最大限度地利用有限的網絡帶寬，傳輸的流媒體文件一般是Real服務器發布 的，包括有.rm、.ram。如今，很多的下載軟件都支持RTSP協議，比如FlashGet、影音傳送帶等等。

　　端口漏洞：目前，RTSP協議所發現的漏洞主要就是RealNetworks早期發布的Helix Universal Server存在緩沖區溢出漏洞，相對來說，使用的554端口是安全的。

　　操作建議：為了能欣賞并下載到RTSP協議的流媒體文件，建議開啟554端口。

　　1024端口

　　端口說明：1024端口一般不固定分配給某個服務，在英文中的解釋是“Reserved”（保留）。之前，我們曾經提到過動態端口的范圍是從 1024～65535，而1024正是動態端口的開始。該端口一般分配給第一個向系統發出申請的服務，在關閉服務的時候，就會釋放1024端口，等待其他 服務的調用。

　　端口漏洞：著名的YAI木馬病毒默認使用的就是1024端口，通過該木馬可以遠程控制目標計算機，獲取計算機的屏幕圖像、記錄鍵盤事件、獲取密 碼等，后果是比較嚴重的。

　　操作建議：一般的殺毒軟件都可以方便地進行YAI病毒的查殺，所以在確認無YAI病毒的情況下建議開啟該端口。

　　1080端口

　　端口說明：1080端口是Socks代理服務使用的端口，大家平時上網使用的WWW服務使用的是HTTP協議的代理服務。而Socks代理服務 不同于HTTP代理服務，它是以通道方式穿越防火墻，可以讓防火墻后面的用戶通過一個IP地址訪問Internet。Socks代理服務經常被使用在局域 網中，比如限制了QQ，那么就可以打開QQ參數設置窗口，選擇“網絡設置”，在其中設置Socks代理服務（如圖1）。另外，還可以通過安裝Socks代 理軟件來使用QQ，比如Socks2HTTP、SocksCap32等。

　　端口漏洞：著名的代理服務器軟件WinGate默認的端口就是1080，通過該端口來實現局域網內計算機的共享上網。不過，如 Worm.Bugbear.B（怪物II）、Worm.Novarg.B（SCO炸彈變種B）等蠕蟲病毒也會在本地系統監聽1080端口，給計算機的安全 帶來不利。

　　操作建議：除了經常使用WinGate來共享上網外，那么其他的建議關閉該端口。

　　1755端口

　　端口說明：1755端口默認情況下用于“Microsoft Media Server”（微軟媒體服務器，簡稱MMS），該協議是由微軟發布的流媒體協議，通過MMS協議可以在Internet上實現Windows Media服務器中流媒體文件的傳送與播放。這些文件包括.asf、.wmv等，可以使用Windows Media Player等媒體播放軟件來實時播放。其中，具體來講，1755端口又可以分為TCP和UDP的MMS協議，分別是MMST和MMSU，一般采用TCP 的MMS協議，即MMST。目前，流媒體和普通下載軟件大部分都支持MMS協議。

　　端口漏洞：目前從微軟官方和用戶使用MMS協議傳輸、播放流媒體文件來看，并沒有什么特別明顯的漏洞，主要一個就是MMS協議與防火墻和 NAT（網絡地址轉換）之間存在的兼容性問題。

　　操作建議：為了能實時播放、下載到MMS協議的流媒體文件，建議開啟該端口。

rtsp和http類似，屬于應用層協議
通過socket rtsp命令來進行通訊。
常用控制命令執行順序常用的是5個命令：

1，OPTIONS,//詢問server，那些命令可用
2，DESCRIBE,//請求rtsp路徑的媒體描述信息
3，SETUP,//設置會話的屬性，以及傳輸模式，建立會話

GET_PARAMETER,//取得流控制參數，可能某些服務器不支持
SET_PARAMETER,//設置流控制參數，可能某些服務器不支持

4，PLAY,//開始播放流媒體數據
5，TEARDOWN //關閉對話
————————————

ANNOUNCE, //更新會話描述
PAUSE,//臨時停止流，而不釋放服務器資源

client有請求(request)，server就有應答(response)
一般控制命令基于tcp協議。媒體數據傳輸使用udp。

————————————
參考http：和rtsp在功能上有相似重疊的地方，RTSP采用了HTTP/1.1 大多數的狀態碼，并且增加了RTSP特定的狀態碼。

HTTP協議定義了8種可能的請求方法：
GET???????????????? 檢索URI中標識資源的一個簡單請求
HEAD?????????????? 與GET方法相同，服務器只返回狀態行和頭標，并不返回請求文檔
POST??????????????? 服務器接受被寫入客戶端輸出流中的數據的請求
PUT???????????????? 服務器保存請求數據作為指定URI新內容的請求
DELETE??????????? 服務器刪除URI中命名的資源的請求
OPTIONS????????? 關于服務器支持的請求方法信息的請求
TRACE???????????? Web服務器反饋Http請求和其頭標的請求
CONNECT??????? 已文檔化但當前未實現的一個方法，預留做隧道處理
————————————
rtsp和http的協議規范分別在RFC2326 和 RFC2616有詳細描述

mms協議為微軟的私有協議，未公開協議。采用私有自定義控制結構體來發送命令，而不是像http，rtsp協議采用發送文本命令控制

實時流協議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，該協議定義了一 對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或RTP完成數據傳輸。HTTP與 RTSP相比，HTTP傳送HTML，而RTP傳送的是多媒體數據。HTTP請求由客戶機發出，服務器作出響應；使用RTSP時，客戶機和服務器都可以發 出請求，即RTSP可以是雙向的。

6.3 RTSP協議
實時流協議（RTSP）是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻，的受控、點播成為可能。數據源包括 現場數據與存儲在剪輯中數據。該協議目的在于控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發送 機制提供方法。
6.3.1 簡介
6.3.1.1 目的
實時流協議（RTSP）建立并控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制流交叉是可能的，通常它本身并不發送連續流。換言之，RTSP充 當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對服務器的可靠傳輸連接 以發出RTSP 請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續媒體的傳輸機制。實時流協議在語法 和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。協議支持的操作如下：
從媒體服務器上檢索媒體：
用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續媒體的的組播地址和端口。如演示僅通過單播發送給用戶，用戶為了安全 應提供目的地址。
媒體服務器邀請進入會議：
媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
將媒體加到現成講座中：
如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。

6.3.1.2 協議特點
RTSP 特性如下：
可擴展性：
新方法和參數很容易加入RTSP。
易解析：
RTSP可由標準 HTTP或MIME解吸器解析。
安全：
RTSP使用網頁安全機制。
獨立于傳輸：
RTSP可使用不可靠數據報協議（UDP）、可靠數據報協議（RDP），如要實現應用級可靠，可使用可靠流協議。
多服務器支持：
每個流可放在不同服務器上，用戶端自動同不同服務器建立幾個并發控制連接，媒體同步在傳輸層執行。
記錄設備控制：
協議可控制記錄和回放設備。
流控與會議開始分離：
僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下， SIP或H.323
可用來邀請服務器入會。
適合專業應用：
通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯
演示描述中立：
協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包含一個RTSP URI。
代理與防火墻友好：
協議可由應用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個"缺口"。
HTTP友好：
此處，RTSP明智的采用HTTP觀念，使現在結構都可重用。結構包括Internet 內容選擇平臺（PICS）。由于在大多數情況下控制連續媒體需要服務器狀態， RTSP不僅僅向HTTP 添加方法。
適當的服務器控制：
如用戶啟動一個流，他必須也可以停止一個流。
傳輸協調；
實際處理連續媒體流前，用戶 可協調傳輸方法。
性能協調：
如基本特征無效，必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。
6.3.1.3擴展RTSP
由于不是所有媒體服務器有著相同的功能，媒體服務器有必要支持不同請求集。RTSP 可以如下三種方式擴展，這里以改變大小排序：
以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
加入新方法。如信息接收者不理解請求，返回501錯誤代碼（還未實現），發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方 法。服務器使用公共響應頭列出支持的方法。
定義新版本協議，允許改變所有部分。（除了協議版本號位置）
6.3.1.4操作模式
每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其它途徑用戶可獲得這個文件，它沒有必要保存在媒體服務器上。
為了說明，假設演示描述描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多 個媒體流。除媒體參數外，網絡目標地址和端口也需要決定。下面區分幾種操作模式：
單播：
以用戶選擇的端口號將媒體發送到RTSP請求源。
組播，服務器選擇地址：
媒體服務器選擇組播地址和端口，這是現場直播或準點播常用的方式。
組播，用戶選擇地址：
如服務器加入正在進行的組播會議，組播地址、端口和密匙由會議描述給出。
6.3.1.5 RTSP狀態
RTSP控制通過單獨協議發送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體服務器沒有收到請求，數據 也會繼續發送。在連接生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，服務器需要維持能聯系流與RTSP請求的連接狀態。RTSP中很 多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起著重要的作用：
SETUP：
讓服務器給流分配資源，啟動RTSP連接。
PLAY與RECORD：
啟動SETUP 分配流的數據傳輸。
PAUSE：
臨時停止流，而不釋放服務器資源。
TEARDOWN：
釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，服務器連
接產生連接標識。

6.3.1.6 與其他協議關系
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規范目的在于允許在網頁服務器與實現RTSP媒 體服務器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP 服務器與用戶不全依靠HTTP。
但是，RTSP與HTTP 的本質差別在于數據發送以不同協議進行。HTTP是不對稱協議，用戶發出請求，服務器作出響應。RTSP中，媒體用戶和服務器都可發出請求，且其請求都是 無狀態的；在請求確認后很長時間內，仍可設置參數，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權 上采用HTTP功能是有價值的。
當大多數實時媒體使用RTP作為傳輸協議時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。

6.3.2 協議參數

6.3.3 RTSP 信息
RTSP是基于文本的協議，采用ISO 10646 字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協議使以自描述方式增加可選參數更容易。由于 參數的數量和命令的頻率出現較低，處理效率沒引起注意。如仔細研究，文本協議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實現研究原型。
10646字符集避免敏感字符集切換，但對應用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協議攜帶。
請求包括方法、方法作用于其上的對象和進一步描述方法的參數。方法也可設計為在服務器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度有 如下因素決定：
不管實體頭段是否出現在信息中，不包括信息體的的響應信息總以頭段后第一和空行結束。
如出現內容長度頭段，其值以字節計，表示信息體長度。如未出現頭段，其值為零。
服務器關閉連接。
注意：RTSP目前并不支持HTTP/1.1"塊"傳輸編碼，需要有內容長度頭。假如返回適度演示描述長度，即使動態產生，使塊傳輸編碼沒有必要，服務器 也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。
從用戶到服務器端的請求信息在第一行內包括源采用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼，而沒有定義任何HTTP代碼。
6.3.4 實體
如不受請求方法或響應狀態編碼限制，請求和響應信息可傳輸實體，實體由實體頭文件和試題體組成，有些響應僅包括實體頭。在此，根據誰發送實體、誰接收實 體，發送者和接收者可分別指用戶和服務器。
實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協議，但這些段不能假定接收者能識別。不可識 別頭段應被接收者忽略，而讓代理轉發。
6.3.5 連接
RTSP請求可以幾種不同方式傳送：
1、持久傳輸連接，用于多個請求/響應傳輸。
2、每個請求/響應傳輸一個連接。
3、無連接模式。
傳輸連接類型由RTSP URI來定義。對 "rtsp" 方案，需要持續連接；而"rtspu"方案，調用RTSP 請求發送，而不用建立連接。
不象HTTP，RTSP允許媒體服務器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否則媒體服務器沒有可靠途徑到達用戶，這也是請求通過防火墻從 媒體服務器傳到用戶的唯一途徑。
6.3.6 方法定義
方法記號表示資源上執行的方法，它區分大小寫。新方法可在將來定義，但不能以$開頭。
某些防火墻設計與其他環境可能要求服務器插入RTSP方法和流數據。由于插入將使客戶端和服務器操作復雜，并強加附加開銷，除非有必要，應避免這樣做。插 入二進制數據僅在RTSP通過TCP傳輸時才可使用。流數據（如RTP包）用一個ASCII美圓符號封裝，后跟一個一字節通道標識，其后是封裝二進制數據 的長度，兩字節整數。流數據緊跟其后，沒有CRLF，但包括高層協議頭。每個$塊包含一個高層協議數據單元。
當傳輸選擇為RTP，RTCP信息也被服務器通過TCP連接插入。缺省情況下，RTCP包在比RTP通道高的第一個可用通道上發送。客戶端可能在另一通道 顯式請求RTCP包 ，這可通過指定傳輸頭插入參數中的兩個通道來做到。當兩個或更多流交叉時，為取得同步，需要RTCP。而且，這為當網絡設置需要通過TCP控制連接透過 RTP/RTCP提供了一條方便的途徑，可能時，在UDP上進行傳輸。
6.3.7 流水線操作
支持持久連接或無連接的客戶端可能給其請求排隊。服務器必須以收到請求的同樣順序發出響應。如果請求不是發送給組播組，接收者就確認請求，如沒有確認信 息，發送者可在超過一個來回時間（RTT）后重發同一信息。
RTT在TCP中估計，初始值為500 ms。應用緩存最后所測量的RTT，作為將來連接的初始值。如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴低層傳輸提供可 靠性。如兩個低層可靠傳輸（如TCP 和RTSP）應用重發請求，有可能每個包損失導致兩次重傳。由于傳輸棧在第一次嘗試到達接收著者前不會發送應用層重傳，接收者也不能充分利用應用層重傳。 如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。時標頭用來避免重發模糊性問題，避免對圓錐算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每 發送一個不同請求，它就加一。如由于沒有確認而重發請求，請求必須攜帶初始系列號。
實現RTSP的系統必須支持通過TCP傳輸RTSP ，并支持UDP。對UDP和TCP，RTSP服務器的缺省端口都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數據可與 RTP和RTCP包交叉。不象HTTP，RTSP信息必須包含一個內容長度頭，無論信息何時包含負載。否則，RTSP包以空行結束，后跟最后一個信息頭。