多媒體傳輸協定的階層及互動

2. RTSP

RTSP(Real Time Streaming Protocol，即時流協定) 是由 RealNetwork 和 Netscape 共同提出，該協定定義了一對多應用程式如何有效地通過 IP 網路傳送 多媒體資料。RTSP 在結構上位於 RTP 和 RTCP 之上，它使用 TCP 或 RTP 完成 資料傳輸。如果拿HTTP 比較，HTTP 傳送 HTML，而 RTP 傳送的是多媒體資料。

HTTP 請求由使用者端發出，伺服器端作出回應；使用 RTSP 時，使用者端和伺 服器端都可以發出請求，意即RTSP 可以是雙向的。

3. RSVP

由於音效和視訊資料流程比傳統資料對網路的延時更敏感，要在網路中傳輸 高質量的音效、視訊資訊，除頻寬要求之外，還需要其他更多的條件。

RSVP(Resource Reserve Protocol) 是正在開發的 Internet 上的資源預訂協議，使用 RSVP 預留一部份網路資源(即頻寬)，能在一定程度上為串流媒體的傳輸提供 QoS。

3.1.3 多媒體傳輸協定的階層及互動

上述幾個小節，我們對於 Streaming Media 及其相關的傳輸協定有概略性的了 解，以下，我們將針對這幾個傳輸協定在傳輸串流媒體時的互動，進一步的說明。

圖3-3 為 Streaming 相關的傳輸協定在 OSI 和 TCP/IP 網路分層協定上的層級分佈，

層級間的關係呈現沙漏型的分佈狀況[53]：

圖3-3 支援 Streaming 傳輸協定的層級分佈 [54]

接著，我們透過圖 3-4，說明這些通訊協定的互動情況：

圖3-4 簡易的 RTSP Session [55]

此圖說明由 Client 端向某網站發出聆聽音樂的需求，有關使用者選擇曲目、

播放曲目及終止播放的交談(Session)情況：

步驟一：RTSP Client 端透過 HTTP GET 的方式，向 Web Server 提 出影片聽取某一首曲子的需求。

(註) 此方式類似於現實生活中，顧客至出影片出租店詢問是否有某部 影片可租借的情況。

步驟二：Web Server 回應 Client 端提出需求的相關訊息(即 Server 與 Client 的交 談，以下以Session 代表)。

(註) 有關伺服器回應的方式有幾種選擇，其中之一是以 HTTP 回應，

此種方式只提供識別串流檔案的URL 的訊息。而在這個例子中，

Client 端向 RTSP Server 提出一個 RTSP DESCRBE 的需求，可獲 得完整的交談(Session)訊息。

步驟三：Client 端傳送 RTSP SETUP 需求給 RTSP Server，指出 URL、序號 (Sequence Number)以及傳輸參數(Transport Parameters)。(註) 在這個例 子中，AV Profile 由 RTP 進行傳輸，在 UDP 上

使用4588 的 port，結合 RTCP Session 是用 4589 的 port。

步驟四：Server 傳送的回應如下：

RTSP/1.0 200 OK CSeq：303

Date：16 Oct 2003 15:35:06 GMT Session：47112344

Transport： RTP/AVP；unicast;

Client_port=4588-4589;server_port=6256-6257

(註) 以上回應表示對 Client 端需求的接受：增加了序號(Sequence Number)、分配了交談編號(Session Number)以及顯示了 Server 傳 輸的參數值(Transport Parameters)。

步驟六：Server 端告知收到 Client 端回應的需求訊息，類似於步驟四的描述方 式。

步驟七：Server 端傳送持續性的 RTP 封包串流，這就是實際上的媒體串流。

步驟八：RTCP 資訊提供在 RTP 封包中插入資料分配的回應。

(註) 步驟七及步驟八，封包的傳送以一個接一個地由 Server 端平行的 傳送至Client 端，不過，並非一直保持連續不斷的傳送，而是有 一固定時間送出封包。在這段時間，Client 端有可能暫停或快轉影 片的某一段，所以，在等待封包送出的這一段時間，若Server 端 收到Client 端回應 PAUSE、PLAY 的需求等明確的指示，則 Server 端會依據收到的回應送出或暫停封包的傳送。

步驟九：Client 端傳送 RTSP TEARDOWN 需求給 Server 端，要求終止交談 (Session)。

步驟十：Server 端告知收到 Client 端傳送的要求。