逢 甲 大 學
資 訊 工 程 學 系 專 題 報 告
安全的視訊會議
周雍傑(四丙)
學 生 : 陳元修(四丙)
張峻源(四丙)
指導教授 : 李維斌
中華民國九十一年十二月
目錄
圖表目錄... II 摘 要 ... II 第一章 專題簡介... 1 1.1 專題研究的動機與目的... 1 1.2 何謂視訊會議... 1 1.3 開發工具與環境簡介... 2 1.4 成果簡介... 3 1.5 文章架構... 3 第二章 影音撥放與影音傳輸的概念及應用... 4 2.1 JMF 的影音撥放架構與應用... 4 2.1.1 影音設備的抽象化... 4 2.1.2 影音撥放的處理過程與選擇性... 5 2.1.3 影音撥放的實作... 9 2.2 RTP 的基本概念與運用...11 2.2.1 影音與網路的關係...112.2.2 Real-Time Transport Protocol...12
2.2.3 Real-Time Control Protocol...15
2.2.4 RTP 實際運用...17 第三章 加解密的原理與實作...20 3.1 密碼學簡介...20 3.1.1 對稱金鑰密碼系統...20 3.1.2 非對稱金鑰密碼系統...21 3.2 加解密的使用介紹...23 3.2.1 使用的工具...23 3.2.2 資料加密前的步驟...23 3.2.3 文字的加解密...26 3.2.4 影像與聲音的加解密...27 第四章 實現多對多機制的設計方法與核心架構...33 4.1 達成多對多模式的構想...33 4.1.1 使用端採平等方式-無主從模式...33 4.1.2 主從模式-所有訊息及資料都須經過 Server.34
4.1.3 主從模式-影音使用直接點對點...36 4.2 Server 與 Client 的結構及溝通規則設計...38 4.2.1 Server 端結構與訊息 Parser...38 4.2.2 Client 端結構與訊息 Parser...43 4.2.3 訊息溝通的實際操作...46 4.2.4 操作流程...50 第五章 軟體未來發展的可行性與心得感想...51 5.1 軟體未來的發展...51 5.2 心得感想...53 參考資料...54 附錄 A 操作手冊... 56 附錄 B 專題實作過程實錄... 62
圖表目錄
圖 2-1 JMF 撥放架構與實體架構對應圖... 4
圖 2-2 Player 類別的狀態流程... 6
圖 2-3 JMF Player 與 Processor 的模型... 7
圖 2-4 Processor 類別的狀態流程(Realized 後與 Player 相同).7 圖 2-5 Processor stages... 8
圖 2-6 簡易撥放架構... 9
圖 2-7 RTP 結構...12
圖 2-8 RTP data-packet header format...14
圖 2-9 RTP 傳送與接收實作示意圖...17 圖 3-1 對稱加密系統... ...21 圖 3-2 非對稱加密系統... ...22 圖 3-3 Key 的產生流程... ...24 圖 3-4 Padding... ...25 圖 3-5 視訊傳輸的流程... ...29 圖 3-6 加密流程圖... ...31 圖 3-7 DESX 的加密步驟...32 圖 4-1 使用端採平等方式-無主從架構示意圖... ...34 圖 4-2 主從模式-訊息及資料經過 Server 管制... ...35 圖 4-3 主從模式-影音使用直接點對點... ....37 圖 4-4 Server 端結構圖...39 圖 4-5 Server 的訊息分析服務...40 圖 4-6 訊息的指令格式... ...41 圖 4-8 Client 端結構圖...44 圖 4-9 訊息傳遞(一)... ...47 圖 4-10 訊息傳遞(二)... ..48 圖 4-11 訊息傳遞(三)... ...49 圖 4-12 操作流程圖... ...50 表 4-1 Server 的指令表... ...42 表 4-2 Client 的指令表... ...45
摘要
隨著網路快速的發展，除了在網路上尋找資料外，大部分的時間 大家都有使用到某些軟體來互相溝通。一開始有 BBS，再來又出現 ICQ、NetMeeting、MSN 等軟體，相信大家也相當熟悉吧，這些軟體 提供了比 BBS 更好的溝通環境。在連絡的功能上這些軟體也不斷的創 新，從一開始的文字傳輸到增加了聲音聊天，現在更新增了視訊的功 能，利用網路來聯絡似乎已經成為必要的需求。不過限於網路的速 度，視訊還不能相當普及，但視訊擷取設備的價格已經漸漸便宜，再 過不久，透過網路來面對面交談，大概會成為每天的必做功課吧。當 然除了個人的使用外，也可以推展到教育、企業界…等地方。能夠讓 相隔兩地的人輕鬆面對面的交談，就是這些軟體的目的，屆時人與人 之間將沒有距離的隔閡。 鑒於這些軟體的普遍使用，我們也嘗試的寫出一個多對多的影音 通訊程式，也許我們做出來的專題功能不及這些市面上的軟體，但是 我們還可以慢慢嘗試改進。不過，我們在傳輸資料方面，為了避免資 訊被人窺視喪失了隱私，我們對資料做了加密的動作，在使用上可以 更為安心。第一章 專題簡介 1.1 專題研究的動機與目的 當使用網路的人日漸普及，在網路上的應用軟體，也隨之應運而 生，當然提供的功能也越來越多元化。為了增加人與人之間溝通的真 實性，聲音、影像也可以透過網路來傳輸。市面上也有幾款軟體提供 這樣的功能。在經常使用之下，進而也想嘗試做出類似功能的軟體。 一方面是因為使用上的興趣，一方面是好奇如何實際作出該軟體，所 以我們就著手於這個專題的實作。 在達到網路視訊傳輸的目標之後，也許大家會懷疑網路上傳送的 影音是否安全，畢竟對於有些隱私的事情是不想讓人知道的。的確， 由於網路是開放性的，資料可能輕易的就被人獲取。因此，對於傳送 資料的保護一定不可少。尤其在企業界，如果商業機密被人竊取，就 會造成嚴重的後果。所以，我們想到在進行視訊會議時，對於傳送出 去的任何資料都經過加密，以確保安全。 1.2 何謂視訊會議 所謂視訊會議（Video Conference）簡而言之是透過網路連接不 同地點之兩方，使雙方與會人員在各自會議室中，不但能聽到對方的 聲音，並且能從電視（腦）螢幕中看到對方的動態影像。 (1) 發展: 近年來，由於網路速度的提升，要在網路上及時傳輸大 量的資料已經不成問題，因此可以在網路上應用的軟體也陸 續發展而出。譬如近年來興起的遠距教學，可以讓各學校教 授在其他學校進行授課，增加學生在課程上的選擇性。甚至 在視訊會議建置後，國內學校可與國外學校做進一步的教學 溝通及資源分享。
在企業界中，透過視訊會議來達成會議，也是必然的趨 勢。對一般企業來說，每年在人員出差費用支出上，都占相 當可觀的比例；而隨著企業規模擴大、分公司陸續建置的情 況下，公司人員至不同地方開會或洽談業務的比例也隨之增 加，導致大家在時間分配上，因考量路程往返的因素下，降 低其工作效能。然而一旦透過視訊會議系統，雙方即可省去 時間及距離的因素，立即做線上面對面會談，且對於一般較 難以電話說明的事情，也可利用視訊讓雙方見到實體情況， 在第一時間內解決問題。如此一來，不但為企業省下大筆出 差費用， 也可提高工作效率，並提升企業專業形象。 現在市面上，就有許多套大家熟知的視訊聊天軟體，像 是 NetMeeting、MSN…等，讓廣大的使用者都能體驗一下視 訊會議的魅力。 (2) 未來: 目前無法普遍的原因，是因為網路頻寬的問題，速度不 夠快，以至於撥放的畫面不順暢。但是在網路硬體設配快速 發展之下，網路使用的花費會越來越便宜，效能也會越來越 強，使用者當然也會日益增多。不難想像，在未來幾年每個 人只要有一個 Camera，連上網路，就可以馬上與相隔兩地 的人做面對面的交談，甚至與其他多個不同國家的人進行交 談，不必花上大把的金錢與時間，就可以有身歷其境的感覺。 1.3 開發工具與環境簡介 開發語言: 專題實驗主要是用 JAVA 語言開發，介面的設計用到了 Swing，影像與聲音的即時傳輸是由 JMF 的 RTP 來達成，並使用 JMF 來達成撥放。Server 與 Client 之間的連線使用 JAVA 的
Socket。加密則使用到 JCE 的 DES 演算法。 開發環境: 安裝 JDk1.4.1(內含 JCE 套件)和 JMF，JMF 會偵測出聲音及 影像的硬體設備，並加入套件於 JDK 之中。JMF 提供即時傳輸與 撥放的功能。這樣就可以用 JDK 來編譯程式。最後再加上麥克 風、Camera，就可以實作我們的專題。 1.4 成果簡介 利用 Client 連上 Server 後就可以與所有在線上的人進行文字的 交談，可以傳送訊息給所有人，或是只傳給某一人。假如有 Camera 和麥克風的設備，就可以選擇與線上的某些人進行多對多的影音交 談。最重要的是在網路上所傳送的任何資料，全部都經過加解密，不 用怕資料被中途竊取。不過，受限於網路的上傳速度，我們只能在區 域網路上實作影音的傳輸。 1.5 文章架構 本篇報告主要分為三大部分。第一部分介紹如何達成及時的影音 傳送。第二部分介紹資料的加解密。第三部分介紹 Server 與 Client 之間的連線，以及指令間的傳遞。另外附錄中有操作這個軟體的整個 流程。
第二章 影音撥放與影音傳輸的概念及應用 本章將分為兩大部分，第一部份將簡單介紹 Java™ Media Framework(以下簡稱 JMF)的撥放架構及機制，還有如何以 JMF 來實 現影音撥放，在第二部分將介紹何謂 Real-Time Transport Protocol(以下簡稱 RTP) 、RTP 的基本概念以及如何使用 JMF 來實 作 RTP。 2.1 JMF 的影音撥放架構與應用 JMF 提供了統一的結構和管理多媒體資料取得、處理及撥放的協 定，而且 JMF 已經能支援多種標準影音格式，如：AIFF、AU、AVI、 GSM、MIDI、MPEG、QuickTime、RMF、WAV、H.263、JPEG、MPEG-4… 等，JMF 也提供了跨平台的特性。 2.1.1 影音設備的抽象化 JMF 對於一般軟體開發者而言，就如同一位影音玩家面對著眾多 影音器材，滿腦子都想著如何才能讓自己所需的影音功能藉由這些設 備一步一步組裝、呈現，圖 2-1 便可簡單的說明這種概念。 圖 2-1 JMF 撥放架構與實體架構對應圖
整組系統(以上眾設備以系統簡稱)以 VCR 為中心，系統提供錄 製、處理、撥放影音資料。當你要撥放一部影片時，你需要一個錄影 帶或是一片光碟，當然這些錄影帶及光碟需要事先錄製完成，這樣裡 面才存有影音資料，接著經過 VCR 的讀取、辨識及處理資料後，VCR 便以特定格式，將影音訊號傳送給顯示器和喇叭，呈現出視聽效果。 JMF 即使用這種類似的基本模型，以物件導向的方式，做出許多抽象 的設備。錄影帶對 JMF 來說相當於 Data Source 物件，它能將眾多格 式的影音以一種物件包裝起來，再送給 Player 物件處理，Player 就 好比 VCR，它擁有 VCR 的功能，並將處理過的訊號交給顯示器及揚聲 器撥放，由此可知，視訊會議便可使用簡易的麥克風、數位攝影機、 顯示器和喇叭當作最基本使用端架構。事實上，整個 JMF 撥放影音的 體系中，Player 扮演極為重要的角色，所以下一小節將簡單說明 Player 的概念與比較。 2.1.2 影音撥放的處理過程與選擇性 一組音樂撥放系統，必須具備音樂光碟片、光碟片的撥放機以及 揚聲器，而當我們把周杰倫的八度空間專輯光碟片放入撥放機中，先 不急著撥放，因為我們只想聽其中的第七首歌，於是便在撥放機上設 定，告訴撥放機我只要聽第七首，接著按下撥放鍵，揚聲器變傳出美 妙的音樂。事實上在整個撥放過程中，撥放機已經經過了許多階段， 簡單的說，當你按下撥放鍵後，裡面的小馬達開始轉動光碟，其主要 目的是要讓磁頭讀取資料並且開始辨識此光碟片裡面有哪些資料、資 料是何種格式和資料的大小，等撥放機完成認識光碟片的工作後，便 依照使用者的設定，讓磁頭循著適當的方法移動到第七首所在的磁區 並開始解碼，把資料轉成訊號送給揚聲器發聲。就 JMF 的撥放架構來 看，Player 類別就擁有撥放機的功能，而且也有類似的處理階段， 圖 2-2 繪出六個狀態。
圖 2-2 Player 類別的狀態流程 在正常的操作下，一個被宣告的 Player 物件會經過每個狀態直 到進入 Started 為止。 當 Player 在 Unrealized 狀態中，它對它所要撥放的影音資 訊(DataSource)一無所知，連它有沒有載入 DataSource 都 不得而知，而剛建立的 Player 物件就是處在 Unrealized 狀 態中。 當我們呼叫了 realize 方法，則狀態就會從 Unrealized 轉 到 Realizing。而在此狀態下 Player 得到了 DataSource。 當完成了 Realizing 後，Player 進入 Realized，這時 Player 已經了解 DataSource 的媒體格式資訊以及這個影音資料需 要什麼東西。 此時狀態進入了 Prefetching，此時 Player 正準備呈現它的 影音，不過在此狀態下它必須做一項重要工作，就是檢查它 的 DataSource 有沒有被其他 Player 佔用，因為在正常情況 下，一個 DataSource 只能被一個 Player 所處理。 到了 Prefetched 狀態，就表示準備要開始撥放，隨即進入 Started 狀態撥放。 雖然 Player 在簡單的撥放處理上已經算是具備了基本功能，但 如果遇上“要讓處理過的 DataSource 以 RTP 的方式經過網路送到對
Unrealize Realizing Realized Prefetching Prefetched Started realize
deallocate deallocate
deallocate
方主機”，那 Player 的能力就遠遠不及 Player 的子類別 Processor， 圖 2-3 為兩種類別的模型。 圖 2-3 JMF Player 與 Processor 的模型 以視訊會議的目的來說，在 DataSource 處理完後必須將影音資 料透過網路傳遞給遠端主機，在 JMF 的概念裡，傳遞影音必須藉由 RTP Manager 來控制傳送，傳送的物件是一個處理過的 DataSource， 由圖 2-3 便可知道 Processor 能符合我們的需求，這是其中一個原 因，另外，Processor 在狀態流程中，比 Player 多了兩個狀態 Configuring 和 Configured (界於 Unrealized、Realizing 之間)。 圖 2-4 將簡單說明這兩個狀態的用處。
Unrealize Realizing Realized
realize
deallocate Configuring Configure
ConfigureCompleteEven configure
圖 2-4 Processor 類別的狀態流程(Realized 後與 Player 相同) 當 configure 方法被呼叫後，狀態進入 Configuring，在此 狀態下 Processor 已能與 DataSource 連結，對 DataSource 中的 input stream 進行解多工(demultiplexes)，並可讀取 多媒體資料的相關影音格式(format)。
一旦狀態進行到 Configured，Processor 便能從 input stream 中取出 track 加以處理(圖 2-5 將有詳細介紹)。 當狀態進入到 Realized，格式大致都已建構完成。
圖 2-5 Processor stages
在圖 2-5 中，Demultiplexer 主要是對 input stream 進行分析， 如果 stream 裡存在多個 track，那麼這些 track 將會被個別取出， 例如視訊會議中，同一個 stream 裡將分別被取出 audio(麥克風)和 video(數位攝影機) tracks。接下來是做轉換編碼的工作，它能把輸 入的 track 格式轉換成你所設定的格式，例如我們如果想把影音資料 送上網路，那麼你所設定的格式必須要能符合網路上的傳輸協定，通 DataSource DataSource Demultiplexer Multiplexer Codec Renderer Renderer Track 1 Track 2
常都是 JPEG_RTP 或是 H.263，而上述功能便是選擇 Processor 做視 訊會議的另一個原因了。當個別處理完 track 之後隨即經由
Multiplexer 的功能將各 track 以單一 output stream 的方式輸出或 是直接交給 Renderer 進行撥放工作。 2.1.3 影音撥放的實作 這小節我以撥放 MPEG Movie 為例子，簡單說明如何實際運用。 使用 Java 的 JMF 套件。 圖 2-6 簡易撥放架構 A. 首先我們要找出影片檔案，讓它能順利放入 DataSource。 DataSource DS = javax.media.Manager.createDataSource(new MediaLocator("file:/c:/sample.mpg"));
B. 接著將 DataSource 加入 Processor 中，並註冊 Listener。
Disk
DataSource Sample
Processor processor = javax.media.Manager.createProcessor(DS); processor.addControllerListener(this);
dualPlayer.start();
C. 建立一 controllerUpdate 函式，它能隨時接收 processor 的 所有狀態，並由使用者寫出撥放元件。
public synchronized void controllerUpdate(ControllerEvent event) {
if (event instanceof RealizeCompleteEvent) { Component comp;
if ((comp = process.getVisualComponent()) != null) add ("Center", comp); //加入影像顯示元件
if ((comp = process.getControlPanelComponent()) != null) add ("South", comp); //加入 media 控制元件
validate(); }
2.2 RTP 的基本概念與運用 如果想在網際網路與高速區域網路中收看、收聽 Live 的廣播秀 或是進行視訊會議，就必須有能力以即時(real-time)的方式傳送與 接收媒體串流(media stream)，本節將介紹支援即時傳送的通訊協定 RTP，以及這種技術在視訊會議上的實際運用。 2.2.1 影音與網路的關係 在介紹 RTP 之前，先簡單的了解影音在網路上的傳輸。要讓 media content 在網路上流動應該不是問題，但要讓 media content 以即時 的方式讓遠端主機能在整個 media 還未完全 download 就撥放，這就 必須制定一種通訊協定來協調整個傳輸規則。基本上，以即時方式傳 送 streaming media 需要足夠的頻寬，而接收 streaming media 時， 必須考慮到遺失資料與延遲。再來,如果以 TCP 與 UDP 兩種協定來做 比較，我們將發現 TCP 較不適合 streaming media，因為它具有封包 的可靠性，也就是當封包遺失時，TCP 就會要求重傳，一旦重傳發生 了，這將會拖慢整個傳輸的速率，相反的 UDP 是一種不具可靠性的協 定，它不保證每個封包都會到達目的端，也不會保證目的端會收到正 確順序的封包，因此 UDP 會有遺失封包、收到重複封包以及收到不正 確順序封包的代價，但此代價卻比使用 TCP 時還小，所以 UDP 自然就 成為 streaming media 的基礎。
2.2.2 Real-Time Transport Protocol
圖 2-7 RTP 結構
由圖 2-6 可以知道，RTP 屬於獨立的通訊協定，它通常建立在 UDP 之上，並提供即時資料傳輸的點對點(end-to-end)傳送服務。基本上 RTP 擁有 unicast 以及 multicast 的網路功能，當使用 unicast 方式 傳送資料時，資料會被拷貝成 N 份並且傳給 N 個目的端，而使用 multicast 時傳送端只送一次，接著由 network 負責把資料分送給多 個位址。
RTP 的專有名詞：
• RTP packet：一個開頭有 RTP header 的 packet。通常在底 層 protocol 中，一個 packet 只包含一個 RTP packet， 但透過一些特別的 encapsulation 方法，底層 packet 也 可以含一個以上的 RTP packet。 • RTP payload：在 RTP packet 中，真正要傳送的資料。例如 在視訊會議中，影像資料就是 RTP payload。 • RTCP packet：一個開頭是 RTCP header，後面接著控制資 料的 packet。通常許多 RTCP packet 會被結合，再加上 底層的 header，而結合後的 RTCP packet 長度會被紀錄 在 RTCP header 中的 length 欄位。
Real-Time Media Frameworks and Applications
Real-Time Control Protocol (RTCP) Real-Time Transport Protocol (RTP) Other Network and
Transport Protocols (TCP,ATM,ST-II,etc.)
UDP
• Port：當 RTP 想傳送 RTP packet 與 RTCP packet 到同一個 IP Address 時，port 就可以用來區分目的地的不同。 • RTP session：對於每一個 RTP 使用者而言，RTP session 是由一對 destination transport address 定義而成(一 個為了 RTP，另一個為了 RTCP)。要注意的是，一個多媒 體會議中，不同的媒體資料最好在不同的 RTP session 中傳送。 • Synchronization source (SSRC)：SSRC 是一個隨機選取的 識別值，用意是使一個 RTP session 中的 participant 都有獨一無二的識別資訊。但是同一個使用者在不同的 RTP session 中，並不一定要用同一個 SSRC。
• Contributing source (CSRC): mixer 可以將不同來源的 RTP packet 混和放到同一個 RTP packet 中。此時，RTP 也會 在 RTP header 中紀錄與這個 packet 有關的 SSRC，而這 些 SSRC 合起來就叫做 CSRC。 RTP 的服務： RTP 能讓你自行定義送出資料的資料型態，決定封包的序 列，對不同來源的 media stream 進行同步化。由於 RTP 不 能確保封包的接收順序及遺失封包的代價，因此我們可以使 用 RTP 封包的 header 來完成次序的重組和偵測有哪些封包 遺失，另外 RTP 本身不具時效性的傳輸與其他的品質服務 (quality of service)，因此它還需要另一個協定 RTCP(Real time control protocol)來對 RTP 進行品質的監視並提供 RTP 額外的控制與識別機制。
RTP 的架構： RTP session，包含了一個 address 和一對 port，一個 port 用在 media data，另一個則用在控制 media data(RTCP)， 除此之外，在整個 session 中，單一主機(參與傳送或接收 的遠端主機)被稱為 participant，它可以被動的接收資料
(成為接收端)，或是主動傳送資料(成為傳送端)，或是兩者 行為同時存在，另外，不同型態的 media data 必須在不同 的 session 傳送，例如在視訊會議中，一個 participant 一 定會送出影像及聲音，而這兩種型態的 media data 須放在 不同的 session 中，換句話說，影像與聲音不是在同一 port 上傳送的，然而，如此做法是要讓低頻寬的 participant 能 有彈性的選擇所需的 media data，它可以只接收聲音並捨棄 影像，以適應低頻寬的環境。接下來我們將說明 RTP 資料封 包(Data Packet)。 在 RTP 裡，media data 是以一序列的封包在傳送的，每 個封包都包含了兩個部分，header 以及實體資料(packet's payload)。
圖 2-8 RTP data-packet header format
•Version (V)：說明 RTP 的版本。
•Padding (P)：如果這個欄位被設定，RTP packet 尾端將 會包含一個以上的 padding octets，但它們並不是 RTP payload 的一部份，而在 padding 的最後一個 octet 會記 錄在這個 RTP packet 中有多少個 octet。在某些壓縮演
算法，或是底層的通訊協定，padding 有可能會被用到。 •Extension (X)：如果這個欄位被設定，在固定的 RTP
header 後還要加上一個 header extension。 •CSRC count (CC)：紀錄 CSRC 的個數。
•Marker (M)：用作重要事件，像是影像中 frame 的界限識 別值。這個值的解釋是留給 application 去處理。 •Payload type (PT)：用來定義 RTP payload 的 format，
而 format 的解釋則是留給 application 去處理。
•Sequence number：每送出一個 RTP packet 之後，sequence number 就會增加 1。Sequence number 也可以被 receiver 用來偵測封包遺失，以及恢復 packet 的順序。
•Timestamp：記錄 RTP packet 第一個 octet 被讀取的取樣 時間。
•SSRC：如同前面的定義。要注意的是，如果一個 source 改變它的 source transport address，它必須選擇一個 新的 SSRC。
•CSRC list：如同前面的定義。要注意的是，如果一個 RTP packet 包含 15 個以上的 CSRC，只有 15 個 CSRC 可以被識 別。
2.2.3 Real-Time Control Protocol
使用與 RTP 傳送 packet 一樣的傳送機制，每隔一段時間就傳送 control packet。
RTCP 三大功能：
(1) RTCP 主要的功能是了解資料 distribution 的 quality。再配合 distribution 機制，像是 IP Multicast，就可以讓 network service provider 這
類實際上沒有加入 RTP session 的單位，去診斷網路 上的問題。
(2) RTCP 包含一個不變的 RTP source 的 transport-level
CNAME 來 identifier，叫做 canonical name 或是 CNAME。Receiver 依靠追蹤每一個 participant。RTP 也使用 CNAME 在一組相關的 RTP sessions 中，將來自 同一個 participant 的多個 data stream 作聯繫。 (3) 前面兩個功能都需要所有的 participant 傳送 RTCP
packet，所以為了適應大量的 participant，傳送的 速率就要控制。透過每一個 participant 傳送 RTCP packet 給其他 participant，所有的 participant 可 以觀察現在 participant 總數目，而這個數目就用來 計算傳送 RTCP packet 的速率。
RTCP Packet 種類：
RTCP packet 可以包含以下五種資訊
SR：紀錄 sender 的 reception statistics。 RR：紀錄 receiver 的 reception statistics。 SDES：有關 source 的資訊，像是 CNAME。
BYE：指出某一 participant 的離開。
APP：指出某一 application 特有的 functions。 RTCP 注意事項： (1) 每一個 RTCP packet 最前面都會有固定的部分，然後 根據 packet 種類的不同，接著長度不同的資料，但總 bit 數都是 32 的倍數。 (2) 多個 RTCP packet 可以結合，而不需要任何的 separator。 (3) 每一個 RTCP packet 一定要包含 SR/RR 與有 CNAME 的 SDES，而且 SR/RR 一定是在最前面。
2.2.4 RTP 實際運用 我們以簡易的結構(一部主機是傳送端，另一部則負責接收)來做 例子。使用 Java 的 JMF 套件。 圖 2-9 RTP 傳送與接收實作示意圖 (A)傳送端： 當 processor 已完成了格式設定後，便取出 DataSource，交給 DataSource Processor Mic DataSource SendStream RTP RecieveStream RT P DataSource Network Processor CCD
RTPManager，並由 SendStream 送出。
DataSource dataOutput = processor.getDataOutput(); RTPManager rtpMgrs = new RTPManager();
rtpMgrs = RTPManager.newInstance(); SessionAddress localAddr = new
SessionAddress(InetAddress.getLocalHost(),port);
//本地端
SessionAddress destAddr = new SessionAddress(ipAddr,port);
//對方位址
rtpMgrs.initialize(localAddr); rtpMgrs.addTarget(destAddr);
SendStream sendStream = rtpMgrs[i].createSendStream(dataOutput,i); sendStream.start();
(B)接收端：
(1)接收端程式必須實作 ReceiveStreamListener 和
SessionListener 並讓 RTPManager 註冊 Listener，這樣才能順 利偵測是否有新傳送者加入
RTPManager mgrs = new RTPManager();
mgrs = (RTPManager) RTPManager.newInstance(); mgrs.addSessionListener(this); mgrs.addReceiveStreamListener(this); localAddr= new SessionAddress(InetAddress.getLocalHost(),session.port); //本地端
destAddr = new SessionAddress(ipAddr,session.port);
//對方位址
mgrs.initialize(localAddr); mgrs.addTarget(destAddr);
(2)再來是建立一個 update 函式，讓它能接收新加入者事件。 public synchronized void update( ReceiveStreamEvent evt) {
if (evt instanceof RemotePayloadChangeEvent) { ...
}
...//此時如有新 participant 加入，便能從 ReceiveStream
...//取得 DataSource 再交給 Processor 加以撥放
}
else if (evt instanceof StreamMappedEvent) { ...
}
else if (evt instanceof ByeEvent) { ...
} }
上面的程式片段包含了傳送及接收功能，如果在一台機器上同時 擁有這兩個功能的話，就是最簡單的視訊會議 Client 端。
第三章 加解密的原理與實作 3.1 密碼學(Cryptology)簡介 密碼學(Cryptology)一字源自希臘文"krypto's"及"logos"兩 字，直譯即為"隱藏"及"訊息"之意。而其使用，可以追溯到大約四千 年前。公元二千年，埃及人就將祭文刻在墓碑上。之後人們都是以書 寫在紙張上的方式，用來傳秘密訊息。在二次大戰中，密碼更是扮演 一個舉足輕重的角色，許多人認為同盟國之所以能打贏這場戰爭完全 歸功於二次大戰時所發明的破譯密文數位式計算機破解德日密碼。西 元 1949 年，Shannon 提出第一篇討論密碼系統通訊理論之論文，近 代密碼學可說是濫觴於斯。直至西元 1975 年，Diffie 與 Hellman 提 出公開金匙密碼系統之觀念，近代密碼學之研究方向，正式脫離秘密 金匙密碼系統之窠臼，蓬勃發展，至今已近二十年。發展至今，已有 二大類的密碼系統。第一類為對稱金鑰(Symmetric Key)密碼系統， 第二類為非對稱金鑰(Asymmetric Key)密碼系統。
3.1.1 對 稱 金 鑰 密 碼 系 統 (Symmetric Key Cryptographic
System) 加 解密速度快是其優點，但因其加密金鑰與解密金鑰為相同一 把金鑰，資訊的傳送在加密之後，如何將該把加密金鑰以安全的方式 傳送給接收方，如何使雙方能共享該把秘密金鑰，以利其解密，是這 系統的一大缺點。著名的對稱金鑰密碼系統中最著名者為 DES(Data Encryption Standard)。其運作情形如 圖 3-1:
3.1.2 非對稱金鑰密碼系統 (Asymmetric Key Cryptographic
System)
每一方皆有一對相互對應的金鑰，一把為公開加密金鑰(Public Key)，另一把為保持機密的解密金鑰(Private Key)。當 A 方要傳送 資訊給 B 方時，A 方使用 B 方的 Public Key 對資訊作加密。B 方接 收到後，用自己的 Private Key 對資訊作解密。其加密金鑰與解密金 鑰不是同一把，改善了對稱金鑰密碼系統的缺點，這樣可以確保使用 B 方的 Public Key 加密之資訊只有 B 方可以解讀。但非對稱金鑰密 碼系統非常不適合加密內容較大之訊息，因為他比對稱金鑰密碼系統 的速度還慢，較著名金鑰密碼系統為 RSA(Rivest Shamir Adleman)。 如圖 3-2: Key Key 1 明 文 加 密 密 文 2 傳送金鑰給接收方 Internet 密 文 明 文 解 密 4 3 圖 3-1 對稱加密系統
A 方
B 方
B 的 Public Key B 的 Private Key
2 1 密 文 加 密 明 文 Internet 3 密 文 解 密 4 明 文 圖 3-2 非對稱加密系統
3.2 加解密的使用介紹
3.2.1 使用的工具
我們選擇用來加解密的工具為 JAVA 的 JCE (Java Cryptographic Extension) API，它可以實施多種類型的加密和其他涉及安全的任 務。為了避免在傳送即時影音時產生嚴重的延遲，專題中使用的加密 演算法為 DES，比起其他的演算法，他擁有較快的處理速度。 DES(Data Encryption Standard)，美國數據保密標準，是對稱
金鑰密碼系統中最著名資料加密方法。DES屬屬於於區區塊塊加加密密法法，，而而區區塊塊 加 加密密法法就就是是對對一一定定大大小小的的明明文文或或密密文文來來做做加加密密或或解解密密動動作作，，將 64 位 元的資料，利用 56 位元的金鑰加密，設計原理源起於 Shannon 的乘 法保密系統(Product cipher)觀念，在運算推導過程中利用混淆 (Confusion)與擴散(Diffusion)、切割分散的功能使得明文在運算的 階段中一次又一次互換位置(查表)及增加(查表填位)、減少位元數 (二進位轉十進位、查表)，經過 16 次的運算處理從事加、解密的工 作。 3.2.2 資料加密前的步驟 (1) 產生 Key
由於 DES 的缺點就是只有一把 Key，如何將 Key 安全的傳送 到其他使用者身上，是很大的問題。因此我們不直接在程式中產 生 Key，而是自己輸入 Key。至於 Key 的內容則利用其他的方式 告知使用者。
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(“DES”);
SecretKey desKey = keyFactory.generateSecret(desKeySpec); 上面這段程式碼中 desKeyData 為使用者輸入的 Key(已轉 為 byte)。DESKeySpec 的唯一用途就是對 Key 進行分組（並為它 們提供型態安全性）,在此將 Key 歸類為 DES 使用的型態。 SecretKeyFactory 再將 desKeySpec 產生成真正 DES 加解密時的 密鑰。下面是產生 DES Key 的流程圖:
(2) 產生 Cipher
Cipher(加解密器)就是用來將資料加解密的函式，首先必須
設定它的參數:
Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
(A).演算法型態
提供 AES、DES、RSA 等演算法，因為我們使用的是 DES 演算法，所以在這裡參數設為 DES。
(B).Mode
提供 CBC(Cipher Block Chaining)、ECB(Electronic Codebook )、CFB(Cipher Feedback )…等模組，ECB 是
DesKeySpec SecretKeyFactory SecretKey
產生 Key
圖 3-3 Key 的產生流程
塊狀加密器(Block Cipher)中最簡單的模式，不論是加密 或解密都是一次以 64 個 Bits 的資料長度作處理，使用相 同的一把金鑰，一個明文只存在一個唯一的相對應密文。 (C).Padding 在加密的過程中，資料會被切成 64 位元區塊，加密 後再輸出，但是每一筆輸入的資料不一定是 64 位元的倍 數，因此在最後一個不滿 64 位元的區塊中，使用 Padding 將區塊補滿。在資料解密時，將 Padding 的部分切除，便 可以還原成原來的資料。舉例來說，假如最後的區塊只有 4byte，則會捕上 4byte 的資料變成 8byte。如下圖:
Data Data Data Data ** ** ** **
設定完參數之後，就可以初使化 cipher，在這裡必須設 定要做加密或是解密的動作，還有加密時使用的 key(上一小 節中產生的 key)，如下所示: cipher.init(Cipher.ENCRYPT_MODE, desKey); //加密 Key Padding 圖 3-4 Padding
cipher.init(Cipher.DECRYPT_MODE, desKey); //解密 3.2.3 文字的加解密 (1) 序列化物件 簡單來說，序列化物件就是一個能夠以 byte streams 的 格式來讀取與寫入的物件。JAVA 物件序列化的方法，就是用 ObjectOutputStream 去儲存一個可序列化的物件，再用 ObjectInputStream 將物件讀取回來，就完成了物件的序列化。 (2) 文字加解密的過程 由於傳送的文字是 String 的格式，String 又屬於可序列化 的物件，而且 JAVA 提供了 SealedObject 可以用來建立一個加密 物件，所以我們在文字的傳送接收上使用物件的格式。只要我們 將要加密的字串做成 SealedObject，就可以將這個加密後的物 件輸出到網路的另一端。接收端也是接收物件的型態，再將這個 物件解密成字串。這樣就完成了文字傳輸的加解密。程式碼如下 所示:
傳送: SealedObject so = new SealedObject(str,cipher); dos.writeObject(so);
// str 為 String , dos 為 ObjectOutputStream , cipher 就 是前一小節完成的加解密器
str = (String)so.getObject(cipher); 3.2.4 影像及聲音的加解密 影像與聲音在傳輸的方法上是與文字不同的，影像與聲音無法像 文字一樣用物件加密後即傳送出去。為了完成視訊加解密，在實作過 程中我們用了兩種方式來達成視訊的傳輸，目的都是為了要將視訊資 料以 byte 的型式傳送出去，而加解密的動作就是針對 byte 的型態， 基本上兩種模式加密的方法及過程都一樣，都是在傳送之前將 byte 加密，再將加密後的 byte 傳送出去。首先介紹兩種傳輸方式: (1) 第一種影音傳輸方式 這種方式的主要步驟就是在一開始先定義一種新的影音格 式。JMF 中每一種內定的格式都有一個 Payload 的編號，他也提 供了動態的 Payload 範圍，讓使用者可以去設定新的格式。完成 定義新的型態之後，在 RTPManager 中新增這種格式，就可以使 用這個格式傳送接收影像或是聲音的訊息。當接收到某個格式的 聲音影像之時，馬上將它轉成你自訂的格式傳送出去，接收到自 訂的格式後，再將他轉回原來的格式撥放。由於轉換成自訂的格 式之時，他會將輸入的資料放進 Buffer 之中，再以自訂的格式 輸出。這樣我們就可以將 Buffer 之中的資料轉成 byte 做加密的 動作。解密也是同樣的方式，接收到資料之後在轉換格式之時對 Buffer 做解密。 但是，困難之處就在於設定新的格式之時，必須要設定新格 式的標頭，來說明這種格式的型態(如:size,rate,channel…
等)，聲音與影像所要求的標頭內容並不相同。新格式的型態交 代清楚了，才能順利的將輸入的資料轉換成你要的格式傳送出 去。聲音方面我們已經完成，但是影像一直無法達成。錯誤的地 方在於最後要轉回 JMF 支援的輸出格式時無法成功，這就表示在 第一歩轉成自訂的格式時就有錯誤，所以才沒有辦法再轉換回原 來的輸入格式。由於要完全了解影像的格式，需要花很多時間， 所以才有第二種方式達成影音之間的傳送。 (2) 第二種影音傳輸方式 這種方式是用 UDP 來傳送資料。首先我們建立一個類別 RTPSocketAdapter 在 RTPManager 中起使它。而這個類別使用到 RTPConnect 這個物件，這個物件中有 getDataOutputStream、 getControlOutputStream、getDataInputStream、 getControlInputStream 的方法，前兩個方法回傳 OutputDataStream，是用來傳送的資料，而後兩個是回傳 PushSourceStream，就是要接收的資料。 傳送的部分，就是回傳的 OutputDataStream，它提供一個 write 的 Method，它會將準備傳送的資料放在 Buffer 中。我們 就先將 Buffer 中 byte 型態的資料先加密，再來用
DatagramSocket 的 send 方法將資料送出，資料是一個個的 DatagramPacket，這樣就完成了 write。
接收的部分，是回傳的 PushSourceStream，它也提供了 Read 的 Method，將接收的資料放進 Buffer。與傳送不同的是，這裡 先用 DatagramSocket 的 receive 將 DatagramPacket 接收，再將
Buffer 中的資料解密。圖 3-5 可以簡單的看出步驟: (藍色線條
(3) 影音的加密方法
Key 與 Cipher 的產生跟文字加解密的部分是相同的，不同 的地方在於最後對資料加密的動作。這裡我們用到了 dofinal 這個方法，dofinal 是對單一 array of bytes 資料進行加解密 的動作。Cipher 除了提供 dofinal 外還有 update，update 的 方法是對有多個 array of bytes 的 Stream 進行加解密，最後 一段 array 再交給 dofinal 加密。在專題裡，我們就是只用 dofinal 這種方式，將單一段接收到的 DatagramPacket 直接加 解密。程式碼如下: RTPConnect getDataOutputStream getControlOutputStream getDataInputStream getControlInputStream OutputDataStream PushSourceStream Method Method 取得要傳送 的資料 取得要接收 的資料 Write Method Send Datagram Socket Read Method Write Read Datagram Socket Recieve 圖 3-5 視訊傳輸的流程
temp = cipher.doFinal(data); //加密 cipher.doFinal(buffer,p.getOffset(),p.getLength() ,buffer,offset); //解密 從產生 Key 到加密完成的整個流程圖，同時使用了 update 與 dofinal 兩個方法，如 圖 3-6 所示: 準備傳送的 byte 資料 加密後的 byte 資料 接收到的 byte 資料 接收到資料的起始位置 接收到的長度 解密後的 byte 資料 解密後存放資料的起始位置
Cipher c=Cipher.getInstance(information)
建立金鑰
初使化 Cipher
c.init(Cipher.ENCRYPT MODE,key)
byte[] output=c.update(data) 讀取資料
還有資料嗎？
byte [] output=c.doFinal()
還有要加密的資料嗎？ 結束 yes yes no 圖 3-6 加密流程圖
(4) 對傳送的資料作 XOR
JCE 提供了 DES 與 Triple DES，Triple DES 雖然較為安全 但是必須要花費相當多的時間，不能夠滿足即時的需求。但是只 用 DES 又怕安全性不夠，所以我們想選擇使用 DESX。DESX 花費 的時間只多了一些，但是卻提供了更大的安全性。DESX 需要三 把 KEY，圖 3-7 就是 DESX 的方法 : 圖 3-7 DESX 加密步驟
由於 JCE 並沒有提供 DESX 的演算法，所以我們自行在 DES 之前 和之後，各對資料進行了 XOR 的動作，來達到類似 DESX 的目的。 對輸出資料與 KEY1 作 XOR 將資料作 DES 加 密 對輸入資料與 KEY3 作 XOR 第二把 KEY 第一把 KEY 第三把 KEY 對輸出資料與 KEY1 作 XOR 對輸入資料與 KEY3 作 XOR 將資料作 DES 加 密 第一把 KEY 第三把 KEY 第二把 KEY 輸 出 輸 入
第四章 實現多對多機制的設計方法與核心架構
為了讓專題能完成多對多的機制，我們從最簡單的一對一文字會 議開始構想，採用一邊推展進度一邊選擇策略的方式，階段性改良程 式的缺點。另外我們將說明 Server 與 Client 之間的溝通方式，Parser 的使用和整個操作流程。 4.1 達成多對多模式的構想 在專題製作的過程中，我們討論過一些能建立多對多的結構，所 謂多對多，便是希望在整個視訊會議中能夠讓超過兩人的會議順利進 行，換句話說，我們需要一種方式去協調與會者和與會者的溝通。以 下我們將列出從開始到模式底定的各個溝通架構。 4.1.1 使用端採平等方式-無主從模式 這種做法看起來比較單純，沒有主從關係，構想上使用者彼此要 先約定一個時間，然後在時間之內所有使用者都要在網路上，再以事 先約定的位址互相連結，構成多對多模式。圖 4-1 以圖示說明。
圖 4-1 使用端採平等方式-無主從架構示意圖 每部主機透過網際網路或是高速區域網路的方式，互相連結，而 且每部主機都必須接收、傳送文字的資料流，還有影像聲音的 media stream。 缺點：事前的約定相當麻煩，需要各使用者一致化，再者如果使用者 一多，難保訊息的判定錯誤，而且架構過於單純，沒有一個權 限較高的管理員，很難在溝通上取得一個標準。 因此基於這些理由，決定再研擬出較適當的方法。 4.1.2 主從模式-所有訊息及資料都須經過 Server
圖 4-2 主從模式-訊息及資料經過 Server 管制 在這種模式下，使用者功能不變，不同的是多了一台管理者 Server，Server 的功能是幫助使用者進行溝通，由於 Server 預設為 隨時都在網路上，因此這樣就能方便於使用者的連線，使用者可不定 時的連上 Server 以及離線，事先只須約定好會議時所要使用的加解 密 KEY，而且透過 Server 的管理，使用者不但可以動態加入與離開， 還能請求 Server 把自己的影音資料傳給特定使用者，在經由 Server 的判斷下，會議便可以分成各個小群組，換句話說，在同一台 Server
中可能存在兩個以上的會議群組，而且每個群組都有屬於自己的 KEY，因此群組間就有安全的保障。 缺點：由於使用者不管是傳送文字或是傳送影音，其資料都會經過 Server 轉送，因此這將會造成 Server 嚴重的負擔，也就是說 只要上線人數超過一定數量，Server 就可能因資源不足而停 擺，還有，如果所有東西都經過 Server，難保資料不被竊取。 基於上述理由，繼續對此模式進行最後改良。 4.1.3 主從模式-影音使用直接點對點 由於影音資料直接經過 Server，可能會導致資源不足，因此直 接的方式便是將文字與 media stream 分開，利用 Server 的功能，直 接取得欲進行會議者的位址，再分別以各位址為遠端目的主機，將影 音資料傳送過去，圖 4-3 簡單說明此模式。
圖 4-3 主從模式-影音使用直接點對點
黑色線代表 Client 與 Server 之間的規則溝通路線，橘色虛線則 代表 Client 與 Client 之間的影音傳送，當 A 想跟 B、C 進行視訊會 議時，A 就告訴 Server，經由 Server 的 Parser 得知與會者共有 A、 B、C 三人，隨即 Server 回應至 Client，通知 A 關於 B、C 的位址， 通知 B 關於 A、C 的位址，通知 C 關於 A、B 的位址，如此三人便能以 該資訊，將位址送給自己的 sender 以及 receiver，進行 media stream 的傳送與接收工作。
A
B
C
4.2 Server 與 Client 的結構及溝通規則設計
在完成了初步的多對多機制後，接下來便要對 Server 與 Client 的溝通方式做一個規劃，於是我們將訊息傳遞的部分分成兩組訊息 Parser，一組給 Server 端使用，另一組則用在 Client 端，原則上訊 息傳遞我們運用了 Java 所提供的 ServerSocket 與 Socket 作為 Server 端與 Client 端的溝通管道。以下分成 Server、Client 與訊 息溝通的實際操作，三個小節來作說明。
4.2.1 Server 端結構與訊息 Parser 結構
在多對多的機制下，一部 Server 主機，必須有能力同時與多部 Client 端主機進行連線，因此 Server 使用了線程(Thread)管理的方 式，隨時都有一個 Socket 等待連線，當有新 Client 要連線至 Server 時，Server 便會開始建構 Thread，並將新的來的 Socket 傳給 Thread 以便能擷取使用者資訊，圖 4-4 說明了 Server 端的基本結構。
圖 4-4 Server 端結構圖
圖中 ClientThread 與 Client 是成對運作的，當有新的 Client 加入時，ServerSocket 會收到通知，於是呼叫 ClientGroup 建立新 的 Thread 進行連接 Client 的工作，每個 ClientThread 都有各自的 I/O stream，它是訊息的出入接口，然而整個 Server 最核心的部分，
ServerSocket ClientGroup ClientThread 3 ClientThread 1 Main Client 1 ClientThread 2 Client 2 Client 3
Internet
就屬 ClientGroup，由於它是每個 ClientThread 的上層，相當於一 個管理者，它有建立、刪除、修改 ClientThread 的權利，所有從 ClientThread 收到的訊息都要經過 ClientGroup，如圖 4-5，當 Client 1 要對 Client 3 說悄悄話時，便需要 ClientGroup 的轉送功 能，所以 ClientGroup 就需要有訊息 Parser 的能力。
圖 4-5 Server 的訊息分析服務
分析器(Parser)
Server 的 Parser 所要分析的訊息均來自 Client，因此所有 Server 接收到的訊息都有一定的格式，就像指令或命令一樣，經過 Parser 的翻譯，成為了實際的動作。指令格式如圖 4-6。
ClientGroup
ClientThread 3
ClientThread 1 ClientThread 2
圖 4-6 訊息的指令格式
圖 4-7 中，整個命令分成兩部分，前半部是指令列，後半部是伴 隨的內容值，中間以符號“||”隔開，其中切字串的技巧是運用到了 Java 所提供的 StringTokenizer 類別，使用方法如下：
String sampleCommand ="strA||strB||strC||strD";
StringTokenizer st = new StringTokenizer(sampleCommand, "||"); for (int i=0; i<st.countTokens(); i++)
System.out.println(st.nextToken()); /* 此程式片段將會印出 strA strB strC strD */
say
嗨! 你好嗎? 我是你家隔壁的小強。 say || 嗨! 你好嗎? 我是你家隔壁的小強。 將此段訊息，送給 Server 上的其他使用者。 指令列 內容值Server 的 Parser 所分析的指令如下表：
表 4-1 Server 的指令表
C o m m a n d 說 明
l o g i n
此指令為登入指令，當有新 Client 要登入 Server 時，Client 便送出第一個指令 login || Tom || 2 命令列為login，內容為Tom || 2，其中，內容會繼續以"||" 為單位再切出兩個字串，Tom為登入者暱稱，數字2代表登入者 所選的圖像編號。 Server 的回應指令： To all users：
login || Tom || Tom 進入聊天室
To all users： list || Tom # 2 s a y 此指令為說話指令，當 Client 端的使用者要在聊天室對大家發 言時(文字)，便會有如下的指令： say || 大家好!我是小豬 命令列為say，內容為大家好!我是小豬，其中內容便是使用者 發言的內容。 Server 的回應指令： To all users： say || Tom 說：大家好!我是小豬 wh i s p e r 此指令為悄悄話指令，當 Client 端的使用者 Tom 想對另一個使 用者 Selina 說悄悄話時，便會有如下的指令： whisper || 嘿!我告訴你一個秘密喔 || Selina 命令列為whisper，內容為嘿!我告訴你一個秘密喔 || Selina， 其中，內容會繼續以"||"為單位再切出兩個字串，嘿!我告訴你 一個秘密喔為對話內容，Selina為受話者。 Server 的回應指令： To Selina： whisper || Tom 對你說悄悄話：嘿!我告訴你一個秘密喔 v i d e o
此指令為視訊會議指令，當 Client 端的使用者 Tom 想與 Selian、 hebe 進行視訊會議，便會有如下的指令：
video || Selina & hebe
"&"為單位在切出兩個字串，Selina和hebe都是接受者。 Server 的回應指令：
To Selina、hebe and Tom：
video || Tom 想邀請你加入視訊會議 || 192.168.0.1&192.168.0.2&192.168.0.3 To all users： list ||Tom(視訊中)#3&Selina(視訊中)#1&hebe(視訊中)#5 AVo f f l i n e 此指令為結束視訊會議指令，當其中 Tom 想結束時，便會有如下 的指令： AVoffline || Tom 命令列為AVoffline，內容為Tom。 Server 的回應指令： To all users： list ||Tom#3&Selina#1&hebe#5 l o g o u t 此指令為登出指令，當使用者 Tom 想登出聊天室時，便會有如下 的指令： logout || Tom 命令列為logout，內容為Tom。 To all users： logout || Tom 離開聊天室
To all users：(假設聊天室只剩 Selina 與 hebe 兩人)
list || Selina#1&hebe#5
4.2.2 Client 端結構與訊息 Parser 結構
都寫在同一個類別，只需要知道 Server 的位址與 KEY 便可以連上 Server 進入聊天室。圖 4-8 說明了 Client 的結構。
圖 4-8 Client 端結構圖
圖中 Client 為主要核心，它能利用 Socket 連上 Server，所有 的指令訊息也都從這裡進出，因此它必須具備 Parser 的功能，另外 GUI 建立了整個聊天室的外觀和許多操作的介面，方便使用者輸入與 觀看回應結果，AVTransmit 負責將 media stream 以 RTP 封包的方式 傳送出去，AVReceiveAndPlayer 則接收 RTP media stream 並將之撥
Conference Client GUI AVTransmit AVReceive AndPlayer
Internet
Audio & Video Audio & Video Message
放，呈現在 GUI 元件中，然而 AVTransmit 與 AVReceiveAndPlayer 並 不會直接連到 Server，它們是透過 Client 與 Server 的溝通，取得 將要進行視訊會議使用者的位址，然後利用這些位址與參與視訊會議 的使用者直接連線，進而達到交換 media stream 的目的。 分析器(Parser) Client 所接收的訊息均來自 Server 端，其中指令格式前面有介 紹過了。Client 的 Parser 所分析的指令如下表： 表 4-2 Client 的指令表 C o m m a n d 說 明 l o g i n
此指令為登入指令，當有新 Client 要登入 Server 時，Server 會把新使用者的訊息傳送給所有在線上的使用者，指令如下：
login || Tom || Tom 進入聊天室
命令列為login，內容為Tom || Tom 進入聊天室，其中，內容
會繼續以"||"為單位再切出兩個字串，Tom為登入者暱稱，Tom 進入聊天室會呈現在聊天訊息框中。 Client 的動作： 將登入者的消息顯示出來，並等待接下來的 list 指令，以更新 使用者名單。 l i s t 此指令為更新使用者名單指令，當有新 Client 要登入 Server 時，Server 便會把最新使用者名單傳送給所有在線上的使用者， 指令如下：(假設目前 Tom 已在線上，Selina 現在加入)
list || Tom # 2 & Selina # 5
命令列為list，內容為Tom # 2 & Selina # 5，內容會繼續以 "&"為單位再切出Tom # 2與Selina # 5，其中Selina # 5，再 以"#"為單位切成Selina與5，Selina代表使用者暱稱，5代表 使用者圖像編號。 Client 的動作： 根據使用者名單，更新使用者列表框的暱稱與使用者圖像。 v i d e o 此指令為視訊會議指令，假設線上使用者有五人，其中 Tom、 hebe、Selina 三人想進行視訊會議，由 Tom 邀請，於是在 Selina 的 Client 端就會接受到如下的指令：
192.168.0.1&192.168.0.2&192.168.0.3 命令列為video，內容為Tom 想邀請你加入視訊會議 || 192.168.0.1&192.168.0.2&192.168.0.3，內容會繼續以"&"為單 位再切出Tom 想邀請你加入視訊會議與192.168.0.1 & 192.168.0.2 & 192.168.0.3，其中Tom 想邀請你加入視訊會議 會在聊天室訊息框呈現，192.168.0.1 & 192.168.0.2 & 192.168.0.3再以"&"為單位切成三個 IP，分別代表三個與會者。 Client 的動作： 將所擷取的 IP 位址交給影音資料的傳送者(AVTransmit)與接收 者(AVReceiveAndPlayer)進行 media stream 的傳送與撥放。
l o g o u t 此指令為登出指令，當線上有使用者登出時，Server 會傳送訊 息給所有使用者，通知有人登出了，指令如下： logout || Tom 離開聊天室 命令列為logout，內容為Tom 離開聊天室。 Client 的動作： 將登出者的消息顯示出來，並等待接下來的 list 指令，以更新 使用者名單。
其 他 其他如 say、whipser…等 Server 送來的指令，Client 端只要把
內容顯示出來即可
4.2.3 訊息溝通的實際操作
圖 4-9 訊息傳遞(一) 分為兩部分，上面是 Server 端訊息，下 面為 Client 端訊息。此圖說明使用者 PIRANDELLO 登入 Server 的訊息表示 (1)Client 端送出 login 指令。 (2)Server 收到 login 指 令，並進行 parse。 (3)parse 完後送出 list 指令給使用者。 (4)Client 端收到 list 指 令，更新使用者名單。 (5)Client 端傳送 say 指 令。 (6)Server 收到 say 指 令，parse 完後，傳給大 家。
(1)使用者 PIRANDELLO 送出 video 指令，表示要和 laidog 與 crackman 兩人進行視訊會議。 (2)Server 收到 video 指令，取得 三人的 IP 後，便將 IP 分送給三 人，並且傳送更新使用者名單指令 list，在暱稱後都加上(視訊中)。 (3)使用者 PIRANDELLO 收到 video 指令，從中擷取了其他兩 人的 IP。 (4) 使用者 PIRANDELLO 收到 list 指令，更新使用 者名單。 分為兩部分，上面是 Server 端訊 息，下面為 Client 端訊息。此圖說 明使用者 PIRANDELLO 邀請 laidog 與 crackman 參加視訊會議的訊息表示。
圖 4-10 訊息傳遞(二) 圖 4-11 訊息傳遞(三) 分為三部分，上面是 Server 端訊息，中間是使用 者 PIRANDELLO 的訊息欄，下面為使用者 crackman 的訊息欄。此圖說明 crack 登出 Server 時，在 Server、PIRANDELLO、crackman 的訊息欄上之訊 息表示。 (1)使用者 crackman 送出 logout 指令，表示要登 出。 (2)Server 收到 crackman 的登出指令後，將此訊息 送給線上的所有使用者， 並傳送更新使用者名單指 令 list。 (3)在線上的另一使用者 PIRANDELLO，從 Server 那 端收到 crackman 登出訊 息以及更新使用者名單訊 息。
4.2.4 操作流程 輸入 Server 的 IP,Port、暱稱、Key 檢查 Key 是否正 確? 成功登入 指令輸出至 Server Server 判斷為說話、悄悄話、視訊會議、 或是登出，再傳達指令至 Client。 Client 接收訊息，若是文字則顯示，若 為視訊會議，出現邀請視窗。 是否要進行視訊 會議? 檢查 Key 是否正 確? 按下結束視訊會議 進行視訊會議 錯誤 登出 取消 錯誤 輸入 Key，按下確定 正確
圖 4-12 操作流程圖 第五章 軟體未來發展的可行性與心得感想 5.1 軟體未來的發展 在發展這個專題的時候，我們曾一起討論，究竟要讓這個軟體提 供多少的功能，基本上我們先要達到文字與影像聲音的傳送功能，再 來才是我們希望能夠完成的功能，以下就是可以加強的部分： 1. 檔案傳輸的功能： 能夠讓每個使用者之間，分享自己的文章、圖案、音樂… 等，增加使用者方便性。 2. 分立群組的功能：
Server 提供分立群組的功能，Client 在登入到 Server 的 時候，可以選擇要進入的群組，或是另開群組，每一個群組可 以討論自己的事情，有群組主持人、群組 Topic，而且每一個 群組可以設立不同的 Key 提供加密，要進入這個群組傳遞訊息 就必須先知道 Key，否則無法解讀資料，這樣就不會被群組外 的人獲取討論的資訊。就像是開一個小型的隱密聊天室一樣， 如果人一多而不分群組就會影響到品質，一些不想看到的訊息 也會出現在螢幕上。當然分化群組之後，也可以單獨的與群組 之外的人做一對一的交談，使用的 Key 是登入時就知道的，與 群組的 Key 不同，否則一旦加入群組，就無法與外界溝通。
3. Server 對使用者的控管: 提供帳號與密碼的登入，Server 擁有每個使用者的資料。 至於 Client 提供編制好友的清單，當好友上線時，Server 會 提醒 Client。Client 也可以設定自己的線上模式，譬如說只接 收好友的訊息，或是完全不想接收訊息。 4. 提升影音傳送的速度 真正的使用品質才是最重要的，也許在速度上我們還可以 找到方法讓它提升，雖然網路的配備速度會提升，但是一旦使 用者一增多，速度也還是有可能拖慢，所以軟體上的處理速度 還是要能夠補強，才能夠發揮的淋漓盡致。 5. 擴充 RTP 的傳送格式 由於支援 RTP 的影音格式有限，而新的影音格式又不斷推 陳出新，使得原有的支援格式將不敷使用，因此未來將擴充支 援格式，例如 MPEG-4，我們將對它做 packeting 和 depacketing 的處理，使 RTP 能順利支援 MPEG-4 的傳送。
6. 改善使用者介面
為了讓使用者更方便、更簡單的使用，介面就要改善到更 趨於人性化，尤其在加進更多功能之後，一定要讓人能夠輕鬆 的使用。
5.2 心得感想 這次的專題是自己依照著興趣去實作，一開始完全沒有方向真的 不知道要如何著手，該用什麼語言好？用到哪些套件？該了解哪些東 西？在書上所獲取的相關資源有限，因此多半時間都是在網路上搜尋 資料，開始的那段期間進展非常慢，曾經試著要利用其他的方法去達 成我們的目標，畢竟許多套件都是我們沒有碰過的，究竟哪一種能夠 完全符合我們的要求，做成我們想要的東西，實在無法肯定。感覺上 好像走了很多冤枉路，其實並不然。也因為這個機會多認識了好多的 東西，像是 J2EE、JMS、JAIN…等，我們都去接觸了一些，後來是因 為無法找到很明確的方向去達成，相關的資料也不多，JMF 又提供了 符合我們需求的 RTP 功能，所以我們放棄了其他的方法。這時候我們 才慢慢加快了腳步，漸漸的有了成果。 學習到東西才是這次專題的重點，該如何去尋找資料，判斷資料 是不是有用，這次專題都是很好的學習經驗。畢竟新的東西實在太 多，當初在 JAVA 的網站尋找資料時，看到很多沒有碰過的套件，實 在覺得滿震撼的，原來這麼多的東西我都不會，甚至不知道是用來做 什麼的。指導老師-李維斌，也常告訴我們，市面上的書都是舊的知 識，你會別人也會，而新的、別人不會的東西都在網路上，要試著去 學習它們提供的說明。當新的東西出來時，你才會具有競爭力，因為 你已經嘗試過學習一個未知的東西，相對的你也有辦法去學習這次的 新東西。這期間我們看了很多 Java 提供的 API Documentation、 Programmer’s Guide，也在討論區中找尋相關的文章，甚至去問發 表文章的人，進而學習他們的實作經驗。
總之當我們再去學習一樣新的東西時，我們已經有經驗知道該如 何去尋找資料，該如何學習。也懂得如何互相討論，互相分工合作，
來達成我們的目標。
參考資料：
[1] The RTP specification is a product of the Audio Video
Transport (AVT) working group of the Internet Engineering Task Force (IETF). For additional information about the IETF, see http://www.ietf.org. The AVT working group charter and
proceedings are available at
http://www.ietf.org/html.charters/avt-charter.html
[2]
IETF RFC 1889, RTP: A Transport Protocol for Real Time
Applications
Current revision: http://www.ietf.org/rfc/rfc1889.txt
[3]
IETF RFC 1890: RTP Profile for Audio and Video Conferences
with Minimal Control
Current revision: http://www.ietf.org/rfc/rfc1890.txt
[4] API Documentation，JavaTM Media Framework API Guide，JMF
Solutions
http://java.sun.com/products/java-media/jmf/
[5] An Introduction to the Java Media Framework Application Programming Interface
http://www-106.ibm.com/developerworks/java/library/jmf/ jmfwhite.html?dwzone=java
[6] Program multimedia with JMF
http://www.javaworld.com/javaworld/jw-04-2001/jw-0406-j mf1.html
[7]JAVA 徹底研究，作者：Steven Holzner 譯：張裕益，博碩文化 出版
[8]Java How to Program 第三版，作者：Deitel&Deitel，全華出版
[9] Java Cryptography Extension1.2.2
http://java.sun.com/products/jce/doc/guide/API_users_gu ide.html
[10] Advanced Object Serialization
http://developer.java.sun.com/developer/technicalArtic les/ALT/serialization/
[11]JAVA 密碼學，作者:Johnathan Knudsen，O’Reilly 出版
[12]JAVA2 設計實務，作者:Herber Schildt，譯者:洪志鋒、朱光宇、 洪靜宜，McGraw-Hill 出版
附錄 A 操作手冊 一.server 端開啟 1. 輸入文字傳送與接收時加解密所需的 Key 2. 按下啟動伺服器 3. 不是輸入八個字元的 Key，出現錯誤訊息。 Key 的輸入位置
二.Client 端的開啟
1.輸入 Server 的 IP 與 Port
2.輸入與 Server 相同的 Key，當輸入不同的 Key 會出現錯誤訊息，無 法與 Server 進行連線。不是輸入八個字元也會出現錯
Key 不是八位元 Key 與 Server 不同
3.輸入帳號，選擇喜歡的圖示。按下登入後就可以馬上加入文字 聊天室。
1 2
三.文字聊天室 1. 對所有在線上的人傳出文字訊息 2. 對其中一人進行悄悄話，只有被選到的人可以看到你傳出去的 訊息。 將滑鼠點向這個位置就 可以對所有人傳送訊息 文字訊息輸入處 將滑鼠指向其中一人 不同的地方
四.開啟視訊會議 1.選擇要一起進行視訊會議的人，用滑鼠點選之後，按下視訊會 議。 2.出現要你輸入 Key 的視窗，這個是視訊傳送接收時加解密的 Key 可以設定與文字不同的 Key。也可以選擇取消，不加入會議。 3. 當輸入錯誤的 Key，不是輸入八個字元時會出現錯誤訊息。如 果輸入與其他人不同的 Key，會無法接收到別人的視訊，別人 也無法接收到你的視訊。
4.輸入好 Key 並按下確定之後，就可以進行視訊會議。 5.按下離開視訊，就可以結束視訊傳輸。 五.結束會議 Client 只要按下登出後就會與伺服器結束連線。
附錄 B 專題的實作過程與圖片
(A)簡單 RTP 實驗，將主機 192.168.1.3 的影片送到 192.168.1.2 撥放， 其中 port4000 傳送影像，port4002 傳送聲音。
傳送端
(B)最初的會議架構，聲音影像文字都分開處理，也沒有 Server 傳遞訊息，僅 兩部主機直接連線互傳。
192.168.0.2
(C)撥放介面的改良，此時有三部主機，影音訊息以廣播放式傳送，還未加入 Server 機制以及文字傳送。
(D)加入 Server，可以傳送文字，並且藉由 Server 的訊息傳遞，與其他使用者 進行視訊會議。
(E)最後整合階段，加入了安全機制，把所有會經過網路的資料做家解密的動作， 並要求使用者輸入 KEY
