【文章內(nèi)容簡介】 方提出請求 ， 然后由發(fā)送方重新定義接收組并發(fā)布出去 。 這種方法的優(yōu)點是發(fā)送方總知道誰是接收者 ，并控制接收組新成員的加入 ， 這對于某些需要限制多媒體信息傳播范圍的應用系統(tǒng) (如視頻會議內(nèi)容不便公開廣播 ，僅限少數(shù)有關(guān)人員收看 )來說是必要的 ， 但也會帶來一些不便之處 ， 還會增加網(wǎng)絡流量負擔 。 此外 ， 由于 QoS是發(fā)送方規(guī)定的 ， 對所有接收者都是相同的 ， 這意味著每個接收者不能根據(jù)各自的需要選擇相應的 QoS， 缺乏靈活性 。 ? 3. RSVP協(xié)議 （ Resource reSerVation Protocol）是 一種基于網(wǎng)絡資源保留的多媒體通信協(xié)議，通過建立連接，為特定的媒體保留資源，提供 QoS服務。 (DS) 由于 RSVP實現(xiàn)起來比較復雜， IETF建議另一種QoS的保障機制即區(qū)分服務。 RTP協(xié)議提供了一種端到端的強制性同步控制機制 ， 以滿足多媒體流內(nèi)和流間的同步控制需求 。 基于 RTP的帶寬調(diào)節(jié)控制算法可以將報文丟失率限制在某一范圍內(nèi) ， 使基于無連接協(xié)議的網(wǎng)絡傳輸質(zhì)量的不穩(wěn)定性得到了一定的補償 。 ? 因特網(wǎng)的演進 ? 計算機網(wǎng)絡最初是為傳送數(shù)據(jù)信息設計的 。 因特網(wǎng) IP 層提供的 “ 盡最大努力交付 ” 服務對傳送數(shù)據(jù)信息也是很合適的 。 ? 當我們從因特網(wǎng)下載文件時 ， 過長的網(wǎng)絡響應時間雖然令人頗為煩惱 ， 但這至少不會對我們產(chǎn)生有害的結(jié)果 。 ? 因特網(wǎng)使用的 TCP 協(xié)議可以很好地解決網(wǎng)絡不能提供可靠交付這一問題 。 ? 因特網(wǎng)是非等時的 ? 模擬的多媒體信號經(jīng)過采樣和模數(shù)轉(zhuǎn)換變?yōu)閿?shù)字信號 ， 再組裝成分組 。 這些分組的發(fā)送速率是 恒定的 （ 等時的 ） 。 ? 傳統(tǒng)的因特網(wǎng)本身是 非等時的 。 因此經(jīng)過因特網(wǎng)的分組變成了 非恒定速率 的分組 。 t t 因特網(wǎng) t 模擬信號 t 采樣后的信號 構(gòu)成分組 恒定速率 非恒定速率 ? ? 多媒體數(shù)據(jù)往往是 實時數(shù)據(jù) (real time data)，它的含義是：在發(fā)送實時數(shù)據(jù)的同時，在接收端邊接收邊播放。 ? 如果 直接 邊接收邊播放，就會產(chǎn)生很大的失真 。接收端需設置適當大小的緩存，當緩存中的分組數(shù)達到一定的數(shù)量后再以恒定速率按順序把分組讀出進行還原播放，可以 減小失真 。如下圖 ? 緩存實際上就是一個先進先出的隊列。圖中標明的 T 叫做 播放時延 。 在接收端設置緩存 t T 緩存（隊列） 恒定速率 t 非恒定速率 有可能發(fā)生 分組丟失 ? 在傳輸多媒體數(shù)據(jù)時 ， 對時延和時延抖動均有較高的要求 。 ? 緩存使所有到達的分組都經(jīng)受了遲延。 ? 早到達的分組在緩存中停留的時間較長，而晚到達的分組在緩存中停留的時間則較短。 ? 以非恒定速率到達的分組，經(jīng)過緩存后再以恒定速率讀出，能夠在一定程度上消除了時延的抖動。但我們付出的代價是增加了時延。 ? 在傳送 時延敏感 (delay sensitive)的實時數(shù)據(jù)時，不僅傳輸時延不能太大，而且時延抖動也必須受到限制。 ? 對于傳送實時多媒體數(shù)據(jù)，很少量分組的丟失對播放效果的影響并不大（因為這是由人來進行主觀評價的），因而是可以容忍的。 丟失容忍 (loss tolerant)也是實時數(shù)據(jù)的另一個重要特點 。 需要解決的問題 ? 針對現(xiàn)有因特網(wǎng)的措施 ? 盡量利用 UDP來傳送音頻和視頻。 ? 在客戶端采用推遲播放和緩沖區(qū)技術(shù)以減弱傳輸延遲和傳輸抖動的影響。 ? 在各個分組上加上順序號、時間戳和同步標記，使客戶端能夠正確播放。 ? 針對分組丟失可以采用冗余糾錯技術(shù)、交錯傳輸技術(shù)和插值技術(shù)進行修復。 ? 如何改造現(xiàn)有的因特網(wǎng) ? 大量使用光纜和高速路由器 ， 網(wǎng)絡的時延和時延抖動就可以足夠小 ， 在因特網(wǎng)上傳送實時數(shù)據(jù)就不會有問題 。 ? 對現(xiàn)有的網(wǎng)絡環(huán)境進行徹底改造，制定新的適合多媒體通信的網(wǎng)絡協(xié)議（ BISDN、 ATM、 IPv RSVP）， 把因特網(wǎng)改造為能夠?qū)Χ说蕉说膸拰崿F(xiàn) 預留 (reservation)，把使用無連接協(xié)議的因特網(wǎng)轉(zhuǎn)變?yōu)槊嫦蜻B接的網(wǎng)絡。 ?對網(wǎng)絡層和傳輸層進行很小的改變，且在網(wǎng)絡邊緣（用戶與 ISP之間）引入簡單的記價和規(guī)劃策略（ DiffServ） . ? 部分改動因特網(wǎng)的協(xié)議棧所付出的代價較小 ， 而這也能夠使多媒體信息在因特網(wǎng)上的傳輸質(zhì)量得到改進 。 ?在現(xiàn)有的基于 TCP/IP協(xié)議的因特網(wǎng)基礎上增加鏈路帶寬 ,并使用一些輔助手段（ FEC、 RTP、 RTCP、 IGMP、 ） . ? 因特網(wǎng)的多媒體體系結(jié)構(gòu) TCP UDP AAL 3/4 AAL 5 PPP SDH/SONET ATM 以太網(wǎng) 調(diào)制解調(diào)器 信令 服務質(zhì)量 IPv4/IPv6 RTSP RTCP RSVP SIP RTP PPP 應 用 層 協(xié) 議 聲音 /視像 SDP ? 背景 ：用戶已不再滿足在網(wǎng)絡資源中僅有文本、圖片和聲音這一類簡單的信息，而是希望得到音頻、視頻并茂的實時媒體。 目前在網(wǎng)絡上傳播多媒體信息主要有兩種方式： 下載和流式傳輸。 流媒體 是相對于傳統(tǒng)的下載－回放（ DownloadPlayback）方式而言的一種媒體格式，它能從 Inter上獲取音頻和視頻等連續(xù)的多媒體流，客戶端可以邊接收邊播放，使時延大大減少，而不用等到完全下載完畢再播放。 （ Streaming Media）技術(shù) ? 流媒體系統(tǒng) ? 技術(shù)：壓縮技術(shù)、流格式編碼技術(shù)、媒體發(fā)布技術(shù)、多媒體傳輸技術(shù)、緩存技術(shù)、高性能計算機技術(shù)等 ? 協(xié)議： RTP、 RTCP、實時流協(xié)議 RTSP、 MMS（ Microsoft Media Service）等 ? 軟件：（ 1）編碼工具（ 2）流媒體服務器（ 3）播放器（ 4） Web服務器 /瀏覽器 RTSP傳送播放、快進、快退、暫停等控制信息 RTP/UDP傳送媒體數(shù)據(jù) 5555 ? Inter音視頻流體系結(jié)構(gòu) 存儲設備已壓縮視頻已壓縮音頻流服務器 客戶 / 接收器應用層Q o S 控制應用層Q o S 控制運輸層協(xié)議 運輸層協(xié)議原始音頻音頻壓縮原始視頻視頻壓縮Int e r n e t( 媒體連續(xù)分發(fā)服務 )視頻解碼器 音頻解碼器媒體同步流服務器 接收器媒體連續(xù)分發(fā)服務? 包括 6個關(guān)鍵的部分： – 音頻和視頻壓縮 ,應用層 QoS控制 ,連續(xù)的媒體分發(fā)服務 – 流服務器 ,媒體同步機制 ,流媒體協(xié)議 ? 實時運輸協(xié)議 RTP (Realtime Transport Protocol) ? RTP 為實時應用提供端到端的運輸，但不提供任何服務質(zhì)量的保證。 ? 多媒體數(shù)據(jù)塊經(jīng)壓縮編碼處理后，先送給 RTP 封裝成為 RTP 分組，再裝入運輸層的 UDP 用戶數(shù)據(jù)報，然后再交給 IP 層。 ? RTP 自己并不對多媒體數(shù)據(jù)塊做任何處理，而只是向應用層提供一些附加的信息，讓應用層知道應當如何進行處理。 發(fā)送 RTP 分組 UDP 用戶數(shù)據(jù)報 IP 數(shù)據(jù)報 IP 首部 UDP 首部 RTP 首部 RTP 數(shù)據(jù)部分（應用層數(shù)據(jù)） ? 實時傳輸協(xié)議 RTP ? RTP是一個應用層協(xié)議，它規(guī)定了音頻和視頻數(shù)據(jù)、順序號和時間戳等信息如何封裝在傳輸層（ UDP）分組中。 ? RTP 是一個協(xié)議框架，只包含了實時應用的一些共同的功能。 ? RTP本身不提供任何機制來確保數(shù)據(jù)的按時發(fā)送或保證服務的質(zhì)量，甚至不能保證分組的順序遞交。服務質(zhì)量的保證由 RTCP協(xié)議來完成，而數(shù)據(jù)傳輸功能是由底層的傳輸協(xié)議完成，一般情況下，利用 UDP進行。 ? RTP 的層次 ? 從應用開發(fā)者的角度看， RTP 應當是應用層的一部分。 ? 在應用的發(fā)送端，開發(fā)者必須編寫用 RTP 封裝分組的程序代碼，然后把 RTP 分組交給 UDP 插口接口。 ? 在接收端， RTP 分組通過 UDP 插口接口進入應用層后，還要利用開發(fā)者編寫的程序代碼從 RTP 分組中把應用數(shù)據(jù)塊提取出來。 ? RTP 分組的首部格式 12 字節(jié) 序 號 SN 比特 0 1 3 8 16 31 有效載荷類型 版本 P X M 參與源數(shù) 時 間 戳 TS 同 步 源 標 識 符 (SSRC) 參 與 源 標 識 符 (CSRC) [0..15] … 前 12 個字節(jié)為固定的頭部，其后的 CSRC標志符為任選部分。有效負荷可以是音頻或視頻數(shù)據(jù)。分組頭部第 1 個字節(jié)包含 2位的 V（版本號，置 2）、 1位的 P（填充位，置0）、 1位的 X（擴展位，置 0）、 4位的 CC（ CSRC 計數(shù)，置 0）。因此，常見的 RTP 分組以十六進制數(shù) 0x80 開頭 M（ marker，標志） 凈荷類型 （ payload type， PT ） SN（ sequence number，序列號）：每發(fā)送一個 RTP 分組，序號加 1。接收端以此判定分組丟失及恢復順序。 TS（ timestamp，時間戳）：指示 RTP 數(shù)據(jù)分組第 1 個字節(jié)的取樣時刻 SSRC（ synchronization source identifiers，同步源標識） ? 實時運輸控制協(xié)議 RTCP (RTP Control Protocol) ? RTCP 是與 RTP 配合使用的協(xié)議。 ? RTCP 協(xié)議的主要功能是：服務質(zhì)量的監(jiān)視與反饋、媒體間的同步，以及多播組中成員的標識。 ? RTCP 分組也使用 UDP 傳送，但 RTCP 并不對聲音或視像分組進行封裝。 ? 可將多個 RTCP 分組封裝在一個 UDP 用戶數(shù)據(jù)報中。 ? RTCP 分組周期性地在網(wǎng)上傳送，它帶有發(fā)送端和接收端對服務質(zhì)量的統(tǒng)計信息報告。 ? RTCP 使用的五種分組類型 ? 結(jié)束分組 BYE 表示關(guān)閉一個數(shù)據(jù)流。 ? 特定應用分組 APP 使應用程序能夠定義新的分組類型。 ? 接收端報告分組 RR 用來使接收端周期性地向所有的點用多播方式進行報告。 ? 發(fā)送端報告分組 SR 用來使發(fā)送端周期性地向所有接收端用多播方式進行報告。 ? 源點描述分組 SDES 給出會話中參加者的描述。 ? 實時流式協(xié)議 RTSP (RealTime Streaming Protocol) ? RTSP 協(xié)議以客戶服務器方式工作，它是一個多媒體播放控制協(xié)議，用來使用戶在播放從因特網(wǎng)下載的實時數(shù)據(jù)時能夠進行控制，如：暫停 /繼續(xù)、后退、前進等。因此 RTSP 又稱為“ 因特網(wǎng)錄像機遙控協(xié)議 ”。 ? 要實現(xiàn) RTSP 的控制功能，我們不僅要有協(xié)議，而且要有專門的 媒體播放器 (media player)和媒體服務器 (media server)。 ? RTSP 與 RTP 和 RTCP 的關(guān)系 RTSP 播放器 RTSP 服務器 RTSP 控制分組（ TCP） RTP 數(shù)據(jù)分組（ UDP） RTCP 分組（ UDP） 客戶 服務器 RTSP 僅僅是使媒體播放器能控制多媒體流的傳送。因此， RTSP 又稱為帶外協(xié)議，而多媒體流是使用 RTP 在帶內(nèi)傳送的。 ? 2. IP 電話 ? 狹義的 IP 電話 就是指在 IP 網(wǎng)絡上打電話。所謂“ IP 網(wǎng)絡”就是“使用 IP 協(xié)議的分組交換網(wǎng)”的簡稱。 ? 廣義的 IP 電話 則不僅僅是電話通信，而且還可以是在 IP網(wǎng)絡上進行交互式多媒體實時通信（包括話音、視像等），甚至還包括 即時通知 IM (Instant Messaging)。 ? IP 電話網(wǎng)關(guān)的幾種連接方法 分組交換 電路交換 電路交換 因特網(wǎng) PC 到 PC 公用電話網(wǎng) IP 電話 網(wǎng)關(guān) 因特網(wǎng) PC 到普通電話機 公用電話網(wǎng) IP 電話 網(wǎng)關(guān) 公用電話網(wǎng) IP 電話 網(wǎng)關(guān) 因特網(wǎng) 普通電話機到普通電話機 ? (1) ? 是 ITUT 于 1996 年制訂的一個名稱很長的建議書， 1998 年的第二個版本改用的名稱是“ 基于分組的多媒體通信系統(tǒng) ”。 ? 包括系統(tǒng)和構(gòu)件的描述，呼叫模型的描述，呼叫信令過程，控制報文，復用，話音編解碼器，視像編解碼器，以及數(shù)據(jù)協(xié)議等，但不保證服務質(zhì)量 QoS。 標準指明的四種