1、 目錄1、 問題背景概述二、協議分析說明分析 2.1 RTSP 總結2.2 MMS總結2.3 RTSP總結三、技術綜述報告四、前景展望1、 問題背景概述 流媒體指在Internet/Intranet中使用流式傳輸技術的連續時基媒體，如：音頻、視頻或多媒體文件。流式媒體在播放前并不下載整個文件，只將開始部分內容存入內存，流式媒體的數據流隨時傳送隨時播放，只是在開始時有一些延遲。流媒體實現的關鍵技術就是流式傳輸。 常見的流媒體協議有以下幾種：1、RTMP（RealTime Messaging Protocol），這是Adobe公司開發的流媒體傳輸協議，使用Flash Media Server來搭建

2、。2、MMS（Media Server Protocol,MMS），這是微軟定義的一種流媒體傳輸協議，可使用WIndows Media Server搭建。3、即時串流通訊協議（Real Time Streaming Protocol，RTSP），它是RealNetworks公司協助建立的一個用來傳送串流媒體的開放網頁標準，使用RealServer服務器搭建環境。二、協議分析說明分析 2.1RTSP 總結 Real Time .1 RMessaging Protocol（實時消息傳送協議協議)概述實時消息傳送協議是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸開

3、發的私有協議。它有三種變種：1)工作在TCP之上的明文協議，使用端口1935；2)RTMPT封裝在HTTP請求之中，可穿越防火墻；3)RTMPS類似RTMPT，但使用的是HTTPS連接；介紹:RTMP協議是被Flash用于對象,視頻,音頻的傳輸.該協議建立在TCP協議或者輪詢HTTP協議之上.RTMP協議就像一個用來裝數據包的容器,這些數據可以是AMF格式的數據,也可以是FLV中的視/音頻數據.一個單一的連接可以通過不同的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的. 下面的文檔詳細說明了RTMP 消息塊流。它位高層多媒體流協議提供多路技術和包服務RTMP 消息塊流是為RTMP

4、 協議設計的。他可以處理任何傳送消息流的協議。每一個消息包含時間戳合有效負載類型標示。RTMP 消息塊流和RTMP 一起適用于多樣性音視頻應用程序，從一對一和一對多向視頻點播服務器直接廣播到交互式會議應用程序。 當用到實時傳輸協議就像TCP，RTMP 消息塊流提供可靠地規則時間戳的端到端全信息傳送。穿過多層流，RTMP 消息塊流不提供任何控制的優先級別和相似形式，但是可以用于高層協議提供這樣的優先級。例如，一段實時視頻服務會選擇丟棄給于緩慢的客戶的視頻信息確保音頻信息可以及時被接收。RTMP 消息塊流包含它自己的入隊協議控制消息，也提供一個高層協議機制用于嵌入用戶的控制消息。2. 定義 有效負

5、載 包含在包中的數據，就像音頻樣本或者壓縮的視頻數據。 包： 一個數據包由固定的包頭和有效負載數據組成，一些底層協議或許需要包的封裝來被定義 端口： 在TCP/P 協議中定義的用正整數表示的端口號用于在傳輸中提取以區分目標主機的不同應用于OSI 傳輸層的傳輸選擇。TSEL就是端口。 傳輸地址： 網絡地址和端口的組合識別一個傳輸層終端端口。例如一個IP 地址和TCP 端口。數據包從一個源傳：輸層地址傳送到目標段的傳輸層地址。 消息流：一個通信的邏輯通道，允許消息流通。 消息流ID：􀈍每一個消息擁有一個分配的ID 識別跟隨的消息流。 消息快：消息的片段，消息被分成小的部分。在他們

6、在網絡中發送之前交叉存儲。消息塊確保定制時間戳的端到端全消息傳送穿過多層流。 消息塊流：一個通信的邏輯通道允許消息塊在一個特定的方向上流通，消息塊流可以從客戶端傳送到服務器也可以相反。 消息塊流ID:每一個消息塊有一個分配的ID 用于識別更隨的消息塊流。 復合技術:把分開的音視頻數據組合成一條音視頻流的過程，使同時傳送許多音視頻數據成為可能。 逆復合技術:復合的反向過程交叉存取組裝的音頻視頻數據，使他們成為最初的音視頻數據3􀈅 字節順序，列隊和時間格式所有的整數字段有被網絡字節負載著，字節0 是第一個顯示出來的.也是一段文字和字段中最重要的。這種字節順序一般被認為“大字節”.

7、數字常量在這種文檔里是用十進制表示。 所有RTMP 消息塊流是以用字節列隊，例如，一個16 字節的字段也許會在字數字節的偏移段。那里要填充被標示.填充字節應該有0 值。 在RTMP 消息塊流中的時間戳用整數表示，單位為毫秒。每一個消息塊流以時間戳0 開始但是這不是必須的，只要兩個終端在時間點上達成一致，注意那就意味著任何穿過多消息塊流異步傳輸(特別是分散的主機).在RTMP 消息塊流之外需要一些而外的機制。 時間戳必須始終在線性的增加，允許應用程序處理異步傳輸，帶寬度量，檢測和流控制。 因為時間戳一般是只有32 字節的長度，他們周期小于50 天，因為六流是允許不停地流動的，最終可以運行幾年。一

8、個RTMP 消息塊流應用必須用到模運算用于相減和比較，任何合理的方式都可以被接受，只要兩端都達成一致。一個應用可以假設，例如，所有相近的時間戳在2 的31 次方以內。所以10000 在4000000000 后面.3000000000 在4000000000 前面。 時間戳delta 作為一個表示毫秒的無符號整數也會被詳細介紹，和先前的時間戳相比，時間戳delta 可以是24 字節或者是32 字節的長度4。􀈅 消息格式： 一個消息的格式可以分裂成消息塊以支持復用，依靠高層協議，消息格式應該包含創造消息塊的必須字段。 時間戳： 消息的時間戳，這個字段可以傳輸4 個字節。 長度：

9、消息的有效負載的長度，如果消息頭不能被省略，他應該包含在長度中，這個字段在消息塊包頭中占有3 個字節。 類型ID：􀈍 協議控制消息的類型字段的范圍是被保留的，這些傳播信息的消息被RTMP 消息塊和高層協議處理。所有其他的類型ID 可被高層協議使用，被RTMP 消息塊當做不透明的值事實上在RTMP 消息塊中需要這些值當做類型的是沒有的，所有的消息可以成為通一種類型?；蛘邞贸绦蛴眠@個字段區分同步跡象而不是類型，這個字段占用1 個字節。 消息流ID: 消息流ID 可以是任意值，不同的消息復合依靠的同樣的消息塊流是基于他們的消息流ID 被逆復合而成的，在此之上，直到RTMP 消息塊

10、被關注，這是一個不透明的值，這個字段在包頭中占用4 個字節。5􀈅 握手 一個RTMP 通信以握手開始，握手不像其他的協議，他包含三個固定長度的消息塊。客戶（初始化通信的終端）和服務器每放發送同樣的三個消息塊，說明一下，被客戶段發送的消息塊被指定為C0，C1，C2，被服務器端發送的消息被指定為S0，S1，S2。2.2 MMS總結 MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務器協議”，用來訪問并流式接收 Windows Media 服務器中 .asf 文件的一種協議。MMS 協議用于訪問 Windows Media 發布點上的單播

11、內容。MMS 是連接 Windows Media 單播服務的默認方法。若觀眾在 Windows Media Player 中鍵入一個 URL 以連接內容，而不是通過超級鏈接訪問內容，則他們必須使用MMS 協議引用該流。MMS的預設埠（端口）是1755。 當使用 MMS 協議連接到發布點時，使用協議翻轉以獲得最佳連接?！皡f議翻轉”始于試圖通過 MMSU 連接客戶端。 MMSU 是 MMS 協議結合 UDP 數據傳送。如果 MMSU 連接不成功，則服務器試圖使用 MMST。MMST 是 MMS 協議結合 TCP 數據傳送。 如果連接到編入索引的 .asf 文件，想要快進、后退、暫停、開始和停止流，

12、則必須使用 MMS。不能用 UNC 路徑快進或后退。若您從獨立的 Windows Media Player 連接到發布點，則必須指定單播內容的 URL。若內容在主發布點點播發布，則 URL 由服務器名和 .asf 文件名組成。例如：mms:/windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務器名，sample.asf 是您想要使之轉化為流的 .asf 文件名。 若您有實時內容要通過廣播單播發布，則該 URL 由服務器名和發布點別名組成。例如：mms:/windows_media_server/Li

13、veEvents。這里 windows_media_server 是 Windows Media 服務器名，而 LiveEvents 是發布點名。 MMS是Multimedia Messaging Service的縮寫，中文譯為多媒體信息服務，也稱“彩信”，是按照3GPP的標準也是WAP論壇的標準有關多媒體信息的標準開發的最新業務，它最大的特色就是支持多媒體功能，可以在GPRS、CDMA 1X、3G、EDGE的支持下，以WAP無線應用協議為載體傳送視頻短片、圖片、聲音和文字，傳送方式除了在手機間傳送外，還可以是手機與電腦之間的傳送。具有MMS功能的移動電話的獨特之處在于其內置的媒體編輯器，使用

14、戶可以很方便地編寫多媒體信息。如果手機具有一個內置或外置的照相機，用戶便可以制作出PowerPoint格式的信息或電子明信片，并把他們傳送給朋友或同事。目前，這一應用服務已逐漸走向成熟，成為主流的短信格式。2.3 RTSP總結 RTSP（Real Time Streaming Protocol），實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或RTP完成數據傳輸。HTTP與RTSP相比

15、，HTTP傳送HTML，而RTSP傳送的是多媒體數據。HTTP請求由客戶機發出，服務器作出響應；使用RTSP時，客戶機和服務器都可以發出請求，即RTSP可以是雙向的。 概念RTSP是用來控制聲音或影像的多媒體串流協議，并允許同時多個串流需求控制，傳輸時所用的網絡通訊協定并不在其定義的范圍內，服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但并不特別強調時間同步，所以比較能容忍網 RTSP絡延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低服務器端的網絡用量，更進而支持多方視訊會議（Video Conference）。因為與

16、HTTP1.1的運作方式相似，所以代理服務器Proxy的快取功能Cache也同樣適用于RTSP，并因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的服務器，以避免過大的負載集中于同一服務器而造成延遲。 簡介該協議用于C/S模型，是一個基于文本的協議，用于在客戶端和服務器端建立和協商實時流會話。 實時流協議（RTSP）是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在于控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發送機制提供方

17、法。 實時流協議（RTSP）建立并控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制流交換是可能的，通常它本身并不發送連續流。換言之，RTSP充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對服務器的可傳輸連接以發出RTSP請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續媒體的傳輸機制。 協議支持的操作如下： (1）從媒體服務器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續媒體的的組播地址和端口。如演示僅

18、通過單播發送給用戶，用戶為了安全應提供目的地址。 (2）媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。 (3）將媒體加到現成講座中：如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。 協議特點(1) 可擴展性：新方法和參數很容易加入RTSP。 (2) 易解析：RTSP可由標準HTTP或MIME解析器解析。 (3) 安全：RTSP使用網頁安全機制。 (4) 獨立于傳輸：RTSP可使用不可靠數據報協議（EDP

19、）、可靠數據報協議（RDP）；如要實現應用級可靠，可使用可靠流協議。 (5) 多服務器支持：每個流可放在不同服務器上，用戶端自動與不同服務器建立幾個并發控制連接，媒體同步在傳輸層執行。 (6) 記錄設備控制：協議可控制記錄和回放設備。 (7) 流控與會議開始分離：僅要求會議初始化協議提供，或可用來創建惟一會議標識號。特殊情況下，可用SIP或H.323來邀請服務器入會。 (8) 適合專業應用：通過SMPTE時標，RTSP支持幀級精度，允許遠程數字編輯。 (9) 演示描述中立：協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。 (10) 代理與防火墻友

20、好：協議可由應用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個“缺口”。 (11) HTTP友好：此處，RTSP明智地采用HTTP觀念，使現在結構都可重用。結構包括Internet內容選擇平臺（PICS）。由于在大多數情況下控制連續媒體需要服務器狀態，RTSP不僅僅向HTFP添加方法。 (12) 適當的服務器控制：如用戶啟動一個流，必須也可以停止一個流。 (13) 傳輸協調：實際處理連續媒體流前，用戶可協調傳輸方法。 (14) 性能協調：如基本特征無效，必須有一些清理機制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。 協議結構RTSP是一種文本協議，采用UT

21、F-8編碼中的ISO 10646字符集。一行可通過CRLF終止，但接收端需要做好解釋CR和LF作為一行終止符的準備。關于頭字段概述如下： Header Type Support Methods Accept R opt. entity Accept-EncodingR opt. entity Accept-Language R opt. all AllowR opt. all Authorization R opt. all Bandwidth R opt. all Blocksize R opt. All but OPTIONS,TEARDOWN Cache-Control G opt. S

22、ETUP Conference R opt. SETUP Connection G req. all Content-Base E opt. entity Content-Encoding E req. SET_PARAMETER Content-Encoding Ereq. DESCRIBE,ANNOUNCE Content-Language E req. DESCRIBE,ANNOUNCE Content-Length Ereq. SET_PARAMETER,ANNOUNCE Content-Length E req. entity Content-Location E opt. enti

23、ty Content-Type E req. SET_PARAMETER,ANNOUNCE Content-Type R req. entity CSeq G req. all Date G opt. all Expires E opt. DESCRIBE,ANNOUNCE From R opt. all If-Modified-Since R opt. DESCRIBE,SETUP Last-Modified E opt. entity Proxy-Authenticate Proxy-Require R req. all Public R opt. all Range R opt. PLA

24、Y,PAUSE,RECORD Range R opt. PLAY,PAUSE,RECORD Referer R opt. all Require R req. all Retry-After R opt. all RTP-Info R req. PLAY Scale Rr opt. PLAY,RECORD SessionRr req. All but SETUP,OPTIONS Server R opt. all Speed Rr opt. PLAY Transport Rr req. SETUP UnsupportedR req. all User-AgentR opt. all ViaG

25、opt. all WWW-AuthenticateR opt. all 類型"g"表示請求和響應中的通用請求頭；類型“R”表示請求頭；類型“r”表示響應頭；類型"e"表示實體頭字段。在“support”一欄中標有“req.”的字段必須由接收者以特殊的方法實現；而“opt.”的字段是可選的。注意，不是所有“req.”字段在該類型的每個請求中都會被發送。“req.”只表示客戶機（支持響應頭）和服務器（支持請求頭）必須執行該字段。最后一欄列出了關于頭字段產生作用的方法；其中“entity”針對于返回一個信息主體的所有方法。 協議參數1RTSP版本 H.321采

26、用，用RTSP代替HTTP。 2RTSPURL “rksp"和“rtspu"方案用于指RTSP協議使用的網絡資源，為RTSP URL定義方案特定的語法和語義。 3會議標識 會議標識對RTSP來說是模糊的，采用標準URI編碼方法編碼，可包含任何八位組數值。會議標識必須全局惟一。 4連接標識 連接標識是長度不確定的字符串，必須隨機選擇，至少要8個八位組長，使其很難被猜出。 5SMPTE相關時標 SMPTE相關時標表示相對剪輯開始的時間，相關時標表示成SMPTE時間代碼，精確到幀級。時間代碼格式為小時：分鐘：秒：幀。缺省smpte格式是"SMPTE 30"，幀

27、速率為每秒29.97幀。其他SMPTE代碼可選擇使用smpte時間獲得支持（如"SMPIE 25")。時間數值中幀段值可從0到29。每秒30與29.97幀的差別可將每分鐘的頭兩幀丟掉來實現。如幀值為零，就可刪除。 6正常播放時間 正常播放時間（NPT）表示相對演示開始的流絕對位置。時標由十進制分數組成。左邊部分用秒或小時、分鐘、秒表示；小數點右邊部分表示秒的部分。演示的開始對應0.0秒，負數沒有定義。特殊常數定義成現場事件的當前時刻，這也許只用于現場事件。直觀上，NPT是聯系觀看者與程序的時鐘，通常以數字式顯示在VCR上。 7絕對時間 絕對時間表示成ISO 8601時標，采

28、用UTC(GMT）。 8可選標簽 可選標簽是用于指定RTSP新可選項的惟一標記。這些標記用在請求和代理-請求頭段。當登記新RTSP選項時，需提供下列信息： （1）名稱和描述選項。名稱長度不限，但不應該多于20個字符。名稱不能包括空格、控制字符。 （2）表明誰改變選項的控制。如IETF，ISO，ITU-T，或其他國際標準團體、聯盟或公司。 （3）深入描述的參考，如RFC、論文、專利、技術報告、文檔源碼和計算機手冊。 （4）對專用選項，附上聯系方式。 RTSP信息RTSP是基于文本的協議，采用ISO 10646字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止

29、符?；谖谋镜膮f議使以自描述方式增加可選參數更容易。由于參數的數量和命令的頻率出現較低，處理效率沒引起注意。文本協議很容易以腳本語言（如：Tcl，Visual Basic與Perl）實現研究原型。 ISO 10646字符集避免敏感字符集切換，但對應用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通過任何低層傳輸協議攜帶。 請求包括方法、方法作用于其上的對象以及進一步描述方法的參數。方法也可設計為在服務器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度由如下因素決定： (1）不管實體頭

30、段是否出現在信息中，不包括信息體的響應，信息總以頭段后第一個空行結束。 (2）如出現內容長度頭段，其值以字節計，表示信息體長度。如未出現頭段，其值為零。 (3）服務器關閉連接。 注意，RTSP目前并不支持HTTP 1.1“塊”傳輸編碼，需要有內容長度頭。假如返回適度演示描述長度，即使動態產生，使塊傳輸編碼沒有必要，服務器也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。 從用戶到服務器端的請求信息在第一行內包括源采用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼，但沒有定義任何HTTP代碼。 RTSP實體如不受請求方法或響應狀態編碼限制，請求和響

31、應信息可傳輸實體，實體則由實體頭文件和實體體組成，有些響應僅包括實體頭。在此，根據誰發送實體、誰接收實體，發送者和接收者可分別指用戶和服務器。 實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協議，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略，而讓代理轉發。 連接RTSP請求可以幾種不同方式傳送： ·持久傳輸連接，用于多個請求/響應傳輸。 ·每個請求/響應傳輸一個連接。 ·無連接模式。 傳輸連接類型由RTSP URL來定義。對“rtsp'方案，需要持續連接；而"rtspu"

32、;方案，調用RTSP請求發送，而不用建立連接。 不像HTTP，RTSP允許媒體服務器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否則媒體服務器沒有可靠途徑到達用戶，這也是請求通過防火墻從媒體服務器傳到用戶的惟一途徑。 流水線操作支持持久連接或無連接的客戶端可能給其請求排隊。服務器必須以收到請求的同樣順序發出響應。如果請求不是發送給多播組，接收者就確認請求，如沒有確認信息，發送者可在超過一個來回時間（RTT）后重發同一信息。 在TCP中RTT估計的初始值為500ms。應用緩存最后所測量的RTT，作為將來連接的初始值。如使用一個可靠傳輸協議傳輸RTSP，請求不允許重發，RTSP應用反過來依賴

33、低層傳輸提供可靠性。如兩個低層可靠傳輸（如TCP和RTSP）應用重發請求，有可能每個包損失導致兩次重傳。由于傳輸棧在第一次嘗試到達接收者前不會發送應用層重傳，接收者也不能充分利用應用層重傳。如包損失由阻塞引起，不同層的重發將使阻塞進一步惡化。時標頭用來避免重發模糊性問題，避免對圓錐算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每發送一個不同請求，它就加一。如由于沒有確認而重發請求，請求必須攜帶初始系列號。 實現RTSP的系統必須支持通過TCP傳輸RTSP，并支持UDP。對UDP和TCP，RTSP服務器的缺省端口都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數

34、據可與RTP和RTCP包交叉。不像HTTP，RTSP信息必須包含一個內容長度頭，無論信息何時包含負載。否則，RTSP包以空行結束，后跟最后一個信息頭。 擴展RTSP由于不是所有媒體服務器有著相同的功能，媒體服務器有必要支持不同請求集。RTSP可以如下三種方式擴展： (1) 以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。 (2) 加入新方法。如信息接收者不理解請求，返回501錯誤代碼，發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務器支持的方法。服務器使用公共響應頭列出支持的方法。 (3) 定義新版本協議，允許改變所有部分（協議版本號位置除外）。

35、操作模式每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其他途徑用戶可獲得這個文件，它沒有必要保存在媒體服務器上。為了說明這個問題，假設演示描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數外，網絡目標地址和端口也需要決定。 下面區分幾種操作模式。 (1）單播：用戶選擇的端口號將媒體發送到RTSP請求源。 (2）服務器選擇地址多播：媒體服務器選擇多播地址和端口，這是現場直播或準點播常用的方式。 (3）用戶選擇地址多播：如服務器加入正在進行的多播會議

36、，多播地址、端口和密鑰由會議描述給出。 RTSP狀態RTSP控制通過單獨協議發送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體服務器沒有收到請求，數據也會繼續發送。在連接生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，服務器需要維持能聯系流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起著重要的作用： (1) SETUP：讓服務器給流分配資源，啟動RTSP連接。 (2) PLAY與RECORD：啟動SETUP分配流的數據傳輸。 (3) PAUSE：臨時停止流，而不釋放服務器資源。

37、(4) TEARDOWN：釋放流的資源，RTSP連接停止。 標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，服務器連接產生連接標識。 與其他協議的關系實時流協議在語法和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。然而，在很多重要方面RTSP仍不同于HTTP： RTSP引入了大量新方法并具有一個不同的協議標識符； 在大多數情況下，RTSP服務器需要保持缺省狀態，與HTTP的無狀態相對； RTSP中客戶端和服務器都可以發出請求； 在多數情況下，數據由不同的協議傳輸； RTSP使用ISO 10646（UTF-8）而并非ISO 8859-1，與當前

38、的國際標準HTML相一致； URI請求總是包含絕對URI。為了與過去的錯誤相互兼容，HTTP/1.1只在請求過程中傳送絕對路徑并將主機名置于另外的頭字段。 RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規范目的在于允許在網頁服務器與實現RTSP媒體服務器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP服務器與用戶不全依靠HTTP。 但是，RTSP與HTTP的本質差別在于數據發送以不同協議進行。HTTP是不對稱協議，用戶發出請求，服務器作出響應。RTSP中，媒體用戶和服務器都可發出請

39、求，且其請求都是無狀態的；在請求確認后很長時間內，仍可設置參數，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近時，在緩存、代理和授權上采用HTTP功能是有價值的。 當大多數實時媒體使用RTP作為傳輸協議時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。 微軟與RTSP簡述RTSP并非只是微軟在用！這是一個公開的規范，在這個規范上開發了很多的流服務器。甚至Linux服務提供者和蘋果的程序員也使用rtsp協議以及Real Networks流媒體。似乎整個世界的網絡流傳輸都用這個協議。然而，微軟并不只在rtsp上有所作

40、為。 微軟和RTSP 在寫這個文檔的時候，微軟正處于從首選MMS協議轉換到首選采用RTSP協議的過程中。這個說明在Media Player 9.0版本和流媒體服務器2003版本之后，我們會看到微軟將rtsp協議作為流媒體傳輸的主要協議。 隨著時間慢慢的流逝，我們會發現mms協議正逐步走出人們的視野。It is only assumed that this is so MS can say they are being open with their protocols (rtsp is an open standard) while at the same time disregarding

41、the need to publicise their own MMS protocol once its gone from media player. 然而，mms還沒有真的死亡，至少在接下來的幾年中我們依然可以看到它在流媒體傳輸中的身影。 是否微軟的RTSP協議和標準的開放式RTSP不同？ 是的。跟在RFC2326（1998年四月）中定義的原始RTSP協議相比，微軟的rtsp協議有一些輕微的改動。我們網站上有本文檔（還有后續版本）和一個簡單的研究，它們可以幫助你了解這些信息。 區別微軟的rtsp規范與標準rtsp協議相比最主要的改動是發送包payloads到客戶端的方式，另外還有一些請求

42、命令有一些改動。傳輸單個媒體包的機制并沒有文檔（就我目前所知），這可能是微軟要保留的信息。就像MMS和HTTP 1.0流協議使用一個媒體數據包頭一樣，RTSP也有。但是微軟的數據包頭格式沒有在任何的rtsp文檔中注明。在企圖連接微軟的rtsp服務器時，這是主要的問題。 微軟RTSP協議的命令采用的語法和標準rtsp協議的命令語法一樣，只有一些小的修改和添加，可以通過閱讀網上的一些文檔，就可以知道怎么去組成這些命令。微軟rtsp命令部分已經有文檔了。3、 技術綜述報告 隨著Internet的迅猛發展，流媒體技術已經廣泛應用于新聞發布、廣播電視、教育、金融、視頻會議、安防等領域，對人們的工作及生活

43、方式產生深遠的影響。本文通過對現有的流媒體技術的原理、系統構成、傳輸協議等的總結分析，系統的介紹了流媒體的基本概念及特點，研究了流媒體的關鍵技術，并從用戶的角度對流媒體的應用前景做了展望。 關鍵詞：流媒體；傳輸協議；系統結構 流媒體（Streaming Media）是指采用流式傳輸的方式在Internet播放的多媒體格式。在流媒體出現之前，人們在互聯網上獲取音視頻信息的唯一方式就是將音視頻文件下載到本地計算機進行觀看。而流媒體技術把連續的影像和聲音信息以數據流的方式實時發布，即邊下邊播的方式，使得用戶無需等待下載或只需少量時間緩沖即可觀看，大大提高了音視頻信息的可觀賞性，節約用戶時間及系統資源

44、。自從1995年progressive Network公司（即RealNetwork公司）發布第一個流產品以來，流媒體得到巨大的發展，已經成為目前互聯網上呈現音、視頻信息的主要方式。1. 流媒體傳輸的方法流媒體傳輸技術分為兩類：:順序流傳輸(Progressive streaming )和實時流傳輸(Realtime streaming)。順序流方式又叫漸進式下載，其傳輸方式是順序下載，在下載文件的同時用戶可觀看在線內容，用戶只能觀看已下載的部分，而不能跳到還未下載的部分。由于標準的HTTP服務器可發送順序流式傳輸的文件，也不需要其他特殊協議，所以順序流式傳輸經常被稱作HTTP流式傳輸。實時流

45、方式：實時流式傳輸使媒體可被實時觀看到，特別適合現場廣播并提供VCR 功能，具備交互性，可以在播放的過程中響應用戶的快進或后退等操作。實時流式傳輸必須匹配網絡帶寬，其出錯的部分一般被忽略，傳輸質量特別時低帶寬時的質量要比順序傳輸的差。實時流傳輸需要專門的流媒體服務器和流傳輸協議。2. 流媒體技術原理流式傳輸方式是指通過特定算法將音頻和視頻等多媒體文件分解成多個小的數據包，由服務器向客戶端連續傳送，用戶可播放已經接收到的數據包，而不需要將整個文件下載到客戶端。由于TCP協議不太適合傳輸多媒體數據，故在實時流媒體方案中，一般采用HTTP/TCP來傳輸控制信息，而用RTP/UDP來傳輸實時數據。3.

46、 流媒體技術的系統結構目前不同公司的流媒體解決方案各不相同。但就其本質來說，一個完整的流媒體系統至少包括三個組件:編碼工具、服務器及播放器。這三個組件間通過特定的通信協議相互聯系，按特定的格式相互交換數據。4. 傳輸協議流媒體系統各組件通過傳輸協議相互通信。對于順序流傳輸，可采用HTTP協議進行傳輸。但HTTP協議并不適合傳輸實時流數據。在流式傳輸的實現方案中，一般采用HTTP/TCP來傳輸控制信息，而用RTP/UDP來傳輸實時多媒體數據。傳輸協議是流媒體技術的一個重要組成部分，也是基礎組成部分。它包括"RSVP(資源預留協議)"、"RTP(實時傳輸協議)&quo

47、t;、"R T C P (實時傳輸控制協議)" 和"RTSP(實時流協議)"，這四種協議構成了"rea1-time"服務的基礎。4.1 資源預留協議RSVP (Resource Reserve Protocol)RSVP是Internet上的資源預訂協議，使用RSVP可以讓流數據的接收者主動請求流數據上的路由器，為該數據流預留一分網絡資源（即帶寬），在一定程度上為流媒體的傳輸提供服務質量。4.2 實時傳輸協議RTP與RTCPRTP是用于Internet/Intranet針對多媒體數據流的一種傳輸協議。RTP被定義為在一對一或一對多傳輸

48、的情況下工作，其目的是提供時間信息和實現流同步。RTP通常使用UDP來傳送數據，但它本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。RTCP和RTP一起提供流量控制和擁塞控制服務。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，特別適合傳送網上的實時數據。4.3 實時流協議RTSP RTSP是由Real Networks和Netscape共同提出的，該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或RTP完成數據傳輸。RTSP 是應用級協議，它以底層的RTP和RSVP為依托，控制實時數據的發送，它提供了可擴展框架，使實時數據的受控、點播成為可能。在客戶端應用程序中對流式多媒體內容的播放、暫停等操作都是通過RTSP協議實現的。4.4 MMS協議（Microsoft Media Serve