【正文】 getDeviceList(Format)方法得到Vector 類的 deviceList[15]。TCP 協(xié)議也有可能，但是可行性非常小，要求更高。服務器在這里充當 “介紹人 ”，告訴 A 與 B 對方的地址和端口號。方法一：通過服務器，服務器作為中間人，轉發(fā)主機間的數據。 例如 A: NAT: C: A(:5000) NAT(:8000) C(:2021) 第五章 穿透 NAT 33 只有 C(:2021)發(fā)送到 NAT(:8000)的數據都可以到達 A(:5000)。 ① 完全錐形（ Full Cone） NAT 這種 NAT 內部的主機 A 連接過外網主機 C 后， NAT 會打開一個端口。那么當數據包通過NAT時，這個 NAT的外網地址是 ，首先 NAT會改變這個數據包的原 IP 地址，改為 。 另外一種 NAT叫做 NAPT（ Network Address/Port Translator），從名稱上我們也可以看得出， NAPT不但會改變經過這個 NAT設備的 IP 數據報的 IP 地址，還會改變 IP 數據報的 TCP/UDP 端口。 主機A 與服務器 S 通信， 它須先通過 網關 ，此時 網關 改變它的數據包地址及端口，把私有地址 （ ） 改為公有地址 （ ），使數據包能在公網上被路由，送至服務器端。顧名思義，它是一種把內部私有網絡 IP 地址翻譯成公有網絡 IP 地址的技術，如圖 51所示。這樣，減少了服務器的負擔，節(jié)省網絡主干的帶寬。例如有線電視的客戶端的線路支持 100個頻道（如果采用數字壓縮技術，理論上可以提供 500個頻道），即使服務商有更大的財力配置更多的發(fā)送設備、改成光纖主干，也無法超過此極限。而將主干擴展 20倍幾乎是不可能。但由于其能夠針對每個客戶的及時響應，所以現在的網頁瀏覽全部都是采用 IP 單播協(xié)議。組播網絡中，即使組播用戶數量成倍增長，骨干網絡中網絡帶寬也無需增加。 2． RR:接收端報告，所謂接收端是指僅接收但不發(fā)送 RTP數據報的應用程序或者終端。 RTCP 工作機制 當應用程序開始一個 RTP會話時，它將使用兩個端口：一個給 RTP，一個給 RTCP。如源改變源傳輸地址，也必須選擇一個新 SSRC標識以避免插入成環(huán)行源。 表 31 常用 類 型 Payload Type Codec 0 PCM μ Law 8 PCMA Law 9 audio codec 4 audio codec 15 audio codec 18 audio codec 34 audio codec 31 audio codec 7． 序 列號： 16 位， 序 列號隨每個 RTP 數據包而增加 1，由接收者用來探測包損失。填充的最后一個八進制包含應該忽略的八進制計數 。 UDP 協(xié)議只是傳輸數據包，不管數據包傳輸的時間順序。在接收端收到數據包后，就依照時間標簽 ， 按照正確的速率恢復成原始的實時數據。 RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。 RTP 是一個應用型的傳輸第三章 RTP、 RTCP 17 層協(xié)議，它并不提供任何傳輸可靠性的保證和流量的擁塞控制機制。而流媒體實現的關鍵技術是流式傳輸。 RTP事件可分為四類， ReceiveStreamEvent，通過它得到一個正在接收的 RTP數據流狀態(tài)的改變信息； RemoteEvent，通過它得到遠端會話參與者的時間或 RTP 控制信息； SendStreamEvent，通過它得到一個正在傳送的 RTP數據流狀態(tài)的改變信息； SessionEvent，通過它得到一個會話狀態(tài)的改變信息。 如 圖 29 所示， JMF 中的 Controller 對象，例如播放器（ Player）和處理器（ Processor），以及 Control 對象，例如 GainControl 都可以發(fā)出MediaEvent事件。 C a p t u r eD e v i c eF i l eD a t a S o u r c e P r o c e s s o rR T P M a n a g e rD a t a S i n kD a t a S o u r c eD a t a S o u r c eF i l eN e t w o r k 圖 27 RTP 的發(fā)送 如圖 28所示，通過 RTPManager，我們也可以接收 RTP數據流，并在本地播放它們，也可以把它們保存到文件。例如當你需要播放一個 DataSource 對象，你可以通過使用 Manager 對象 createPlayer( )方法創(chuàng)建一個 Player 對象來播放它。像 Player 一樣， DataSink對象以 DataSource 作為參數，通過管理器（ Manager）來構造。 如 圖 24 所示， 除了將媒體數據傳送至播放終端外，處理器可以將媒體數據輸出至一個數據源（ DataSource ），使用 Processor 的getDataOutput( )方法實現，此數據源可以作為其它的播放器的數據源， 或是通過其它的處理器對其進行進一步操作控制，或將其作為數據池（ DataSink）的參數，利用數據池或存儲到一個文件，或傳送到網絡中去。使用這種事件 報告機制，你可以在調用播放器的方法前確定播放器是否在其適當的第二章 JMF基礎 8 狀態(tài)。 ● Realized：在這種狀態(tài)下 Player 對象已經確定了它需要哪些資源，并且也知道需要播放的多媒體的類型。 MediaLocator 用來定位采集設備、本機的媒體文件、網絡上的媒體文件以及網絡 RTP流。 DV帶可以放在播放器里播放，播放器提供視頻信號給電視機，提供音頻信號給音箱，這樣我們就可以在電視機上看到畫面，從音箱那里聽到聲音。 第二章 JMF基礎 4 第二章 JMF 基礎 關于 JMF 技術 JMF(Java Media Framework)， Java媒體架構， 是對應 Java 2平臺標準版 (J2SE)的一種可選用的應用編程接口 (API)軟件包，它為音頻和視頻等媒體內容的捕獲、回放、傳輸和編碼轉換等提供了一個統(tǒng)一的架構。組播為主機之間 “一對一組 ”的通訊模式 ，加入了同一個組的主機可以接 收 到此組內的所有數據，網絡中的交換機和路由器只向有需求者復制并轉發(fā)其所需數據。 Java的 JMF是一種應用編程接口 (API)軟件包，它為音頻和視頻等媒體內容的捕獲、回放、傳輸和編碼轉換等提供了一個統(tǒng)一的架構。對多媒體信號的壓縮我們有許多可以選擇的格式，如 mpmp GSM 等等。 由于 NAT 的存在，令許多 P2P 應用無法應用于 NAT 背后的主機，語音 視頻 通信 也不例外。 RTP 是針對 Inter 上多媒體數據流的一個傳輸協(xié)議。 本文將用 Java的 JMF解決這些問題。 IP 組播是主機之間 “一對一組 ”的通訊模式。 采 集 編 碼 發(fā) 送 接 收 解 碼 回 放網 絡圖 11 語音通信系統(tǒng)模型 音頻信號的采集以及回放 在進行音頻信號的采集中，我們必 須考慮到采樣率的問題，聲音信號的采樣率有 8KHz、 16KHz、 32KHz、 44KHz等，每種數據采樣率產生的數據量都不一樣，越高的采樣率產生的數據量越大，所以我們要選擇合適的采樣率以適應網絡的帶寬 [1]。通信協(xié)議的選擇取決于我們所要做的應用的類型。我們能夠用這三模式中的其中一個完成多人語音聊天這一功能。但它也導致了 內外網無法直接通信或受到某些限制的問題 。 JMF 模型 在開發(fā) JMF應用程序之前要理解 JMF的體系架構、接口和類。當創(chuàng)建了 DataSource 對象后，可以將它送入 Player 對象中，而 Player 對象不需要關心 DataSource 中的多媒體是如何獲得的，以及格式是什么 [3]。 第二章 JMF基礎 7 圖 23播放器的狀態(tài)轉換圖 ● Unrealized：在這種狀態(tài)下， Player 對象已經被實例化，但是并不知道它需要播放的多媒體的任何信息。 ● Started：當 調用 start( )方法后， Player 對象就進入了該狀態(tài)并播放多媒體。 Processor 同樣可以用來播放媒體數據。 ● Configured：當完成數據源連接 ，獲得輸入數據格式的信息后，處第二章 JMF基礎 9 理器對象就處于 Configured狀態(tài)。在AudioFormat中，描述了音頻格式的屬性，如采樣頻率、每次采樣的數據位數等等。 RTP 管理器 JMF在 ， ， 和 中定義了有關 RTP 的 API，我們可利用它們進行 RTP流的發(fā)送和接收。MediaEvent 的 子 類 包 括 ControllerEvern ， DataSinkEvent ，GainChangeEvent， RTPEvent。 3．當 Controller 關閉時，它將產生關閉事件。在網上傳輸音頻、視頻等多媒體信息目前主要有兩種方式：下載和流式傳輸。 到目前為止， Inter上使用較多的流式視頻格式主要有以下三種：RealNetworks 公司的 RealMedia， Apple公司的 QuickTime 以及 Microsoft公司的 Advanced Streaming Format (ASF)。目前，支持流媒體傳輸的協(xié)議主要有實時傳輸協(xié)議 RTP(RealTime Transport Protocol) 、實時傳輸控制協(xié)議RTCP(RealTime Transport Control Protocol)和實時流協(xié)議 RTSP(RealTime Streaming Protocol)等。 RTP協(xié)議提供了時間標簽 、序列號以及其它的結構用于控制實時數據的 播 放。 RTP報文甚至不包括長度和報文邊界的描述。 RTP 協(xié)議通常根據一個具體的應用來提供服務， RTP 只提供協(xié)議框架，開發(fā)者可以根據應用的具體要求對協(xié)議進行充分的擴展。設置可定義其他標示位，或通過改變位數量來指定沒有標記位。 9． SSRC： 32 位， SSRC 段標識同步源。 CSRC標識由混合器插入，采用作用源的 SSRC標識。 RTP和 RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。IPTV、視頻會議、數據和資料分發(fā)、網絡音頻應用、網絡視頻應用、多媒體遠程教育等寬帶應用都對現有寬帶多媒體網絡的承載能力提出了挑戰(zhàn)。 單播 /組播 /廣播 通訊協(xié)議的特點及應用對比 當前的網絡中有三種通訊模式：單播、廣播、組播，其中的組播出第四章 組播技術 24 現時間最晚 ， 但同時具備單播和廣播的優(yōu)點，最具有發(fā)展前景。 2． 現有的網絡帶寬是金字塔結構，城際省際主干帶寬僅僅相當于其所有用戶帶寬之和的 5％。 第四章 組播技術 26 2． 由于服務器不用向每個客戶機單獨發(fā)送數據，所以服務器流量負載極低。這樣既能一次將數據傳輸給多個有需要（加入組）的主機，又能保證不影響其他不需要（未加入組）的主機的其他通訊。 組播的缺點： 1． 與單播協(xié)議相比沒有糾錯機制，發(fā)生丟包錯包后難以彌補，但可以通過一定的容錯機制和 QoS加以彌補。公有地址是全球唯一的，能在公網上被路由。 NAT 的分類及工作原理 N A T基 礎 N A TN A P T動 態(tài) N A T靜 態(tài) N A T完 全 錐 形 （ F u l l C o n e ）受 限 制 錐 形 （ R e s t r i c t e d C o n e ）端 口 受 限 制 錐 形 （ P o r t R e s t r i c t e d C o n e ）對 稱 ( S y m m e t r i c ) N A T錐 形 ( C o n e ) N A T圖 53 NAT 的分類 基本 NAT 與 NAPT 如圖 53 所示， NAT 分為兩大類，基本的 NAT 和 NAPT（ Network Address/Port Translator） [10][11]。 1 5 5 . 9 9 . 2 5 . 1 1 : 6 2 0 0 0C l i e n t A1 0 . 0 . 0 . 2 : 1 2 3 4S e r v e r S 1 :1 8 . 1 8 1 . 0 . 3 1 : 1 2 3 51 0 . 0 . 0 . 2 : 1 2 3 41 8 . 1 8 1 . 0 . 3 1 : 1 2 3 51 5 5 . 9 9 . 2 5 . 1 1 : 6 2 0 0 01 8 . 1 8 1 . 0 . 3 1 : 1 2 3 5C l i e n t 224。而對于對等型 NAT， NAT 將會分配另一端口號（如 62021）給 Client A 的 1235端口。 例如 A: NAT: C: A(:5000) NAT(:8000) C(:2021) 任何從 C 發(fā)送到 NAT(:8000)的數據都可以到達A(:50