【正文】 大壓力，所以方法不可行。 下面就根據(jù) NAT的各種類型詳細(xì)解析如何 “打 孔 ”，如何穿透 NAT。 2．受限制錐形（ Restricted Cone） NAT A和 B還是要先連接服務(wù)器，服務(wù)器發(fā)送 A和 B的地址和端口信息給 A和 B，但由于受限制錐形 NAT的特點(diǎn)，他們所打開的 “孔 ”，只能與服務(wù)器通信。 3．端口受限制錐形（ Port Restricted Cone） NAT 第五章 穿透 NAT 35 對于該類型的 NAT，解決辦法跟上面的方法一樣。并且，語音視頻通信是用 UDP 傳輸?shù)?，故針?TCP的 NAT穿透在這里不作討論。 2. 軟件環(huán)境 服務(wù)器端： Microsoft Windows + JRE； 客戶端： Microsoft Windows + JRE + JMF。 ② 若設(shè)備列表為空，則結(jié)束，若不為空，用 Vector 類的 elementAt(int)方法獲得第一個(gè)可用的設(shè)備的名字，然后強(qiáng)制轉(zhuǎn)換為 CaptureDeviceInfo類。本功能模塊完成對原始信號(hào)的格式編碼轉(zhuǎn)換功能。 ④ 由獲得的 MediaLocator 創(chuàng)建 DataSource，便得到設(shè)備采集到的語音、視頻信號(hào)。 流程圖如 61所示。 NAT 設(shè)備將在一定時(shí)間后關(guān)閉 UDP 的一個(gè)映射，所以為了保持與服務(wù)器能夠一直通信，服務(wù)器或客戶端必須要周期性地發(fā)送 UDP包，保持映射不被關(guān)閉。 以上的穿透 NAT，是對 NAPT來進(jìn)行穿透，主要是針對 UDP 協(xié)議。這時(shí)主機(jī) A 向主機(jī) B的公網(wǎng) IP發(fā)送的信息導(dǎo)致 NAT A打開一個(gè)處于主機(jī) A的和主機(jī) B之間的會(huì)話，與此同時(shí)， NAT B也打開了一個(gè)處于主機(jī) B和主機(jī) A的會(huì)話。故 A 與 B 可連接對方的公網(wǎng)地址和端口直接進(jìn)行通信。 穿透 NAT—— UDP 打 孔 技術(shù) 所謂的 “打 孔 技術(shù) ”，就是在內(nèi)網(wǎng)的 NAT設(shè)備上打上一個(gè) “孔 ”（也就是在 NAT上建立一個(gè)會(huì)話，綁定地址和端口號(hào)），這個(gè) 孔 不能由外部來打，第五章 穿透 NAT 34 只能由內(nèi)網(wǎng)內(nèi)的主機(jī)來打。 有兩種方法解決這個(gè)問題。但如果外部的計(jì)算機(jī)想訪問子網(wǎng)內(nèi)的計(jì)算機(jī)就比較困難了，這可以使內(nèi)網(wǎng)主機(jī)先發(fā)起連接從而解決問題。然后 C只能用原來的端口和 A通信，其他的外網(wǎng)主機(jī)不可以。 ② 受限制錐形（ Restricted Cone） NAT 這種 NAT 內(nèi)部的主機(jī) A 連接過外網(wǎng)的主機(jī) C 后， NAT 打開一個(gè)端口。 完全錐型 NAT、受限制錐型 NAT 與端口受限制型 NAT 錐型 NAT 可另外分類為完全錐形（ Full Cone） NAT，受限制錐形第五章 穿透 NAT 32 （ Restricted Cone） NAT，端口受限制錐形（ Port Restricted Cone） NAT。 NAT會(huì)記住 62021 端口對應(yīng)的是 的 1234 端口，以后從外網(wǎng)服務(wù)器 62021端口的數(shù)據(jù)會(huì)被 NAT自動(dòng)的改變目的 IP和端口號(hào)，然后轉(zhuǎn)發(fā)到 （如圖 54右圖所示）。 C l i e n t圖 54 NAPT 的地址及端口轉(zhuǎn)換過程 私有網(wǎng)絡(luò)中某一主機(jī) Client A（ ），它的某個(gè)進(jìn)程通過 1234端口，想訪問外網(wǎng)服務(wù)器 的 1235 端口。 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 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 0N A T1 0 . 0 . 0 . 2 : 1 2 3 4 223。由于現(xiàn)在大部分都屬于另一種類型，即 NAPT，故這里不詳細(xì)討論基礎(chǔ) NAT。 NAT 功能通常被集成到路由器、防火墻、 ISDN 路由器或者單獨(dú)的NAT設(shè)備中。它要與外網(wǎng)通信，必須經(jīng)過 NAT設(shè)備（如網(wǎng)關(guān)，路由器）， 如 圖 52所示。 A、 B、 C類可 被 計(jì)算機(jī) 作為 IP地址， D類為組播地址，E類為特殊用途的地址。 第五章 穿透 NAT 28 第五章 穿透 NAT NAT 的作用 NAT(Network Address Translator)，網(wǎng)絡(luò)地址轉(zhuǎn)換。 2． 組播能節(jié)省網(wǎng)絡(luò)主干的帶寬。一個(gè)主機(jī)用組播協(xié) 議向 n個(gè)主機(jī)發(fā)送相同的數(shù)據(jù)時(shí)，只要發(fā)送 1次，其數(shù)據(jù)由網(wǎng)絡(luò)中的路由器和交換機(jī)進(jìn)行復(fù)制 ，如圖 43所示 。 組播 主機(jī)之間 “一對一 組 ”的通訊模式，也就是加入了同一個(gè)組的主機(jī)可以接 收 到此組內(nèi)的所有數(shù)據(jù)，網(wǎng)絡(luò)中的交換機(jī)和路由器只向有需求者復(fù)制并轉(zhuǎn)發(fā)其所需數(shù)據(jù)。 2． 網(wǎng)絡(luò)允許服務(wù)器提供數(shù)據(jù)的帶寬有限，客戶端的最大帶寬＝服務(wù)總帶寬。在數(shù)據(jù)網(wǎng)絡(luò)中也允許廣播的存在，但其被限制在二層交換機(jī)的局域網(wǎng)范圍內(nèi)，禁止廣播數(shù)據(jù)穿過路由器，防止廣播數(shù)據(jù)影響大面積的主機(jī)?，F(xiàn)在的 P2P應(yīng)用就已經(jīng)使主干經(jīng)常阻塞，只要有 5％的客戶在全速使用網(wǎng)絡(luò)，其他人就 分配不到帶寬 了。 2． 服務(wù)器針對每個(gè)客戶不通的請求發(fā)送不同的數(shù)據(jù)，容易實(shí)現(xiàn)個(gè)性化服務(wù)。 如 圖 41所示， 如果 9個(gè)客戶機(jī)需要相同的數(shù)據(jù)，則服務(wù)器需要逐一傳送，重復(fù) 9次相同的工作。此操作系統(tǒng)允許一臺(tái)計(jì)算機(jī)使用 MAC層組播向在本地 Ether段的一組其他計(jì)算機(jī)傳遞信息。此時(shí)通過引入 IP 組播技術(shù)，有助于解決以上問題。 5． APP:由應(yīng)用程序自己定義，解決了 RTCP的擴(kuò)展性問題，并且為協(xié)議的實(shí)現(xiàn)者提供了很大的靈活性。 RTCP 數(shù)據(jù)報(bào) 在 RTCP通信控制中， RTCP協(xié)議的功能是通過不同的 RTCP數(shù)據(jù)報(bào)來實(shí)現(xiàn)的，主要有如下幾種類型： 1． SR:發(fā)送端報(bào)告，所謂發(fā)送端是指發(fā)出 RTP數(shù)據(jù)報(bào)的應(yīng)用程 序或者終端，發(fā)送端同時(shí)也可以是接收端。 RTCP包中含有已發(fā)送的 數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料。 RTCP負(fù)責(zé)管理傳輸質(zhì)量并在當(dāng)前應(yīng)用進(jìn)程之間交換控制信息。標(biāo)識(shí)數(shù)量由 CC 段給出。盡管多個(gè)源選擇同一個(gè)標(biāo)識(shí)的概率很低，所有 RTP 實(shí)現(xiàn)都必須探測并解決沖突。時(shí)標(biāo)可以讓 接收 端知道在正確的時(shí)間將 數(shù)據(jù) 播放出來。 表 31列出了 常用 的載荷 類型 。 4． CSRC計(jì)數(shù)（ CC）： 4位， CSRC計(jì)數(shù)包括緊接在固定頭后 CSRC標(biāo)識(shí)符個(gè)數(shù)。 2． 填充標(biāo)識(shí)（ P）： 1位，如設(shè)置填充位，在包尾將包含附加填充字，它不屬于有效載荷。而 UDP的多路 復(fù)用讓 RTP 協(xié)議利用支持顯式的多點(diǎn)投遞，可以滿足多媒體會(huì)話的需求。 RTP 協(xié)議和 UDP 二者共同完成 傳 輸層協(xié)議功能。同步就是屬于應(yīng)用層 協(xié)議完成的。發(fā)送端依照即時(shí)的采樣在數(shù)據(jù)包里隱蔽 地 設(shè)置了時(shí)間標(biāo)簽。 RTP 工作機(jī)制 威脅多媒體數(shù)據(jù)傳輸?shù)囊粋€(gè)尖銳的問題 是 數(shù)據(jù)到達(dá)時(shí)間的 不可預(yù)料性 。 實(shí)時(shí)傳輸協(xié)議 RTP RTP（ RealTime Transport Protocol） 是針對 Inter上多媒體數(shù)據(jù)流的一個(gè)傳輸協(xié)議，由 IETF(Inter工程任務(wù)組 )作為 RFC1889發(fā)布。但是，由于 UDP 的傳輸時(shí)延低于 TCP，它能與音頻和視頻很好地配合。傳統(tǒng)的 TCP 協(xié)議是一個(gè)面向連接的協(xié)議，它的重傳機(jī)制和擁塞控制機(jī)制都是不適用于實(shí)時(shí)多媒體傳輸?shù)摹Ｅc單純的下載方式相比，這種對多媒體文件邊下載邊播放的流式傳輸方式不僅使啟動(dòng)延時(shí)大幅度地縮短，而且對系統(tǒng)緩存容量的需求也大大降低。由于網(wǎng)絡(luò)帶寬的限制，下載常常要花很長時(shí)間，所以這種處理方式延遲很大。 第二章 JMF基礎(chǔ) 15 圖 211 JMF RTP 事件 第三章 RTP、 RTCP 16 第三章 RTP、 RTCP 流媒體 流媒體概念 流媒體 (Streaming Media)技術(shù)是網(wǎng)絡(luò)技術(shù)和多媒體技術(shù)發(fā) 展到一定階段的產(chǎn)物。 圖 211 列出了所有的 RTP事件。 2．狀態(tài)轉(zhuǎn) 變事件可以使你的程序?qū)?Controller 對象的狀態(tài)轉(zhuǎn)變作出反應(yīng)。為了能在某一 MediaEvent事件發(fā)生時(shí)得到相應(yīng)的通知，必須實(shí)現(xiàn)適當(dāng)?shù)膫陕牻涌谝约霸趯?yīng)的類體中重寫該接口中處理 MediaEvent事件的方法體，并通過調(diào)用 addListener 方法來接收此 MediaEvent事件。 表 21 JMF支持的視音頻在 RTP 傳送中的格式 多媒體類別 RTP傳輸格式 音頻 AUDIO_G711_ULAW/rtp， dvi/rtp ， g723/rtp ， gsm/rtp 視頻 jpeg/rtp， h261/rtp， h263/rtp 事件模型 JMF利用事件報(bào)告機(jī)制來使基于 JMF的程序獲知媒體系統(tǒng)當(dāng)前的狀第二章 JMF基礎(chǔ) 12 態(tài)，從而使程序能夠?qū)?相應(yīng)狀態(tài)的改變作出相應(yīng)的操作。 如圖 27所示，通過 管理器（ RTPManager） ，我們可以把采集到的音第二章 JMF基礎(chǔ) 11 頻或視頻數(shù)據(jù)發(fā)送出去，或把本地的媒體文件發(fā)送出去。 ● CaptureDeviceManager：該管理器中保存了截取設(shè)備的注冊信息。 圖 26 表示 JMF對音頻格式和視頻格式的定義： 第二章 JMF基礎(chǔ) 10 圖 26 JMF的媒體數(shù)據(jù)格式 管理器 JMF提供了下面四種管理器 （ Manager） ： ● Manager： Manager 相當(dāng)于兩個(gè)類之間的接口。只是描述了該格式的編碼名稱和數(shù)據(jù)類別。一個(gè)特定的 DataSink 或把數(shù)據(jù)輸出到一個(gè)文件，或通過網(wǎng)絡(luò)傳輸數(shù)據(jù)，或進(jìn)行 RTP廣播。 ● Configuring：當(dāng)調(diào)用 configure( )方法后，處理器對象進(jìn)入該狀態(tài)。處理器支持所有播放器擁有的播放控制功能。 處理器 處理器（ Processor）對應(yīng)的接口是 Processor。通過 ControllerListener接口，你的程序可以確定播放器在什么狀態(tài)并作出相應(yīng)的反應(yīng)。這個(gè)過程被稱為預(yù)?。?Prefetch）。在這種狀態(tài)下， Player 對象正在確定它 需要占用哪些資源。在正常情況下 Player 對象需要經(jīng)歷每個(gè)狀態(tài)，然后才能播放多媒體。 MediaLocator 類似于 URL，并 且可以由 URL來構(gòu)造，即使在沒有安裝相應(yīng)的協(xié)議處理機(jī)制的情況下，也能構(gòu)造 MediaLocator（在 Java，只有在系統(tǒng)上安裝了 URL協(xié)議的處理機(jī)制的情況下，才能構(gòu)造一個(gè) URL）。在 JMF 中， DataSource 對象就是數(shù)據(jù)源，它可以是從采集設(shè)備獲得的數(shù)據(jù)，也可以是一個(gè)多媒體文件，也可以是 從互聯(lián)網(wǎng)上下載的數(shù)據(jù)流。如圖 21所示，首先用攝像機(jī)拍攝內(nèi)容，拍攝下來的內(nèi)容錄制在 DV帶中。 JMF 還支持廣受歡迎的媒體類型，如Quicktime、 Microsofts AVI和 MPEG1等。 本文在第五章介紹了 NAT的基本原理及 NAT的穿 透方法， 在第六章給出實(shí)現(xiàn)的方法。 第一章 概述 3 在廣域網(wǎng)， P2P軟件可能失靈，主要是由于 NAT設(shè)備的存在 。發(fā)送廣播，子網(wǎng)內(nèi)所有主機(jī)均可收到數(shù)據(jù)報(bào)，通信量巨大，智能低，并且不允許跨越網(wǎng)段。 鑒于語音聊天軟件的發(fā)展，多人語音聊天已成為語音聊天軟件必不可少的一個(gè)功能，所以本軟件也加入了這一功能。 語音聊天軟件的設(shè)計(jì) 要實(shí)現(xiàn)在網(wǎng)絡(luò)上進(jìn)行語音通信，便要解決音頻信號(hào)的采集、回放、編解碼以及數(shù)據(jù)的傳輸?shù)膯栴}。 TCP較可靠，所以應(yīng)用在不允許數(shù)據(jù)丟 失的應(yīng)用上。從節(jié)省帶寬的角度考慮，我們很有必要對這樣的數(shù)據(jù)進(jìn)行壓縮。 該 軟件 既能 進(jìn)行點(diǎn)對點(diǎn)的語音視頻通信 ，也能進(jìn)行 多人語音視頻通信，并用 UDP 打 孔 技術(shù)完成 了 對 NAT的穿透，使該軟件能在廣域網(wǎng)上使用。 IP 組播能有效地節(jié)省網(wǎng)絡(luò)和主機(jī)的資源，并且它允許在廣域網(wǎng)上傳輸。 RTP只保證實(shí)時(shí)數(shù)據(jù)的傳輸，并不提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠 RTCP提供這些服務(wù)。 JMF 用 RTP 協(xié)議傳輸實(shí)時(shí)媒體信號(hào)。摘 要 I 摘 要 隨著網(wǎng)絡(luò)的不斷發(fā)展，在網(wǎng)絡(luò)上的 語 音 視頻 通信成為研究和應(yīng)用的熱點(diǎn)之一。 JMF是 Java的一種可選用的應(yīng)用編程接口 (API)軟件包，它 為音頻和視頻等媒體內(nèi)容的 采集 、回放、傳輸和編碼轉(zhuǎn)換等提供了一個(gè)統(tǒng)一的架構(gòu)。 RTP建立在 UDP 上。加入了同一個(gè)組的主機(jī)可以接 收 到此組內(nèi)的所有數(shù)據(jù)，網(wǎng)絡(luò)中的交換機(jī)和路由器只向有需求者復(fù)制并轉(zhuǎn)發(fā)其所需數(shù)據(jù)。 本文 使 用 JMF完成語音 視頻 聊天軟件的實(shí)現(xiàn)。 音頻數(shù)字信號(hào)的編碼與解碼 如果直接把采集到的音頻信號(hào)數(shù)據(jù)流在網(wǎng)絡(luò)上進(jìn)行傳輸，它所占有的帶寬也是十分大的，以 8KHz的采樣率采集 14 位的音頻數(shù)據(jù)，那么就有以下這樣的一個(gè)式子： 14 bit 8000Hz = 112,000 bits