4.5.1 多媒體影音留言
近年由於手機的普及，加上科技日益進步，過去我們只能以文字和 語音的方式來留言，如今已大為改觀。在手機上已可以顯示多媒體訊 息，包括了聲音和影像，因此各電信業者也加入了此項服務，也就是時 下最流行得Multimedia Mail Service(MMS)。而在手機上的即時影像 和聲音，由於電信頻寬的限制(目前為止)，所以現在的 MMS 多以圖片
Server 端每一使用者，都會有其所儲存的使用者留言資訊，其 目錄結構如下:
-UserName +Audio +Video +Binary +Text +Mix -mail.xml
在每個資料夾中，分別存放各種多媒體留言資料和相關資訊。
當目的端不在時，會回傳不存在的資訊，當來源端收到此訊息 後，將向伺服器送出其要留言的要求，把留言先保留在伺服器端，
待接受端上線後，再將其留言訊息送到目的端，而傳送的方式也是 經由串流儲存在伺服器。
當使用者上線後，會先向伺服器端送出是否有其留言訊息，當 伺服器有其留言時，會先回傳其所有的留言訊息到使用者端，使用 者可選擇其所想聽的留言項目，當使用者選擇選定後，伺服器會回 傳該留言，以串流直接到使用者端輸出。
4.5.2 留言訊息的保留及利用
當使用者收完在伺服器上留言後，可以選擇是否先保存在伺服器，
本地端可以先不保留，所以使用者可以在不同地方重覆地接收其留言。
當使用者要將其留言保留後，可以經由在本地端的encoder 將其編碼為 如mp3、mpeg、mov、avi 等通用格式保存，以方便重覆收聽。也因 為有保存其留言，所以使用者也可以將其留言自已送給其它使用者，以 完成資訊共享的目的。
4.5.3 MailServer 之間的溝通
由於使用者每次所Login 的 Server 可能不同，因此多媒體留言是 使用分散式資料共享的方式來儲存，所以使用者端必需向Server 詢問 是否該使用者的mail 訊息及所 mail 所儲存的多媒體留言所在 Server 位置.也因為如此，每個 MailServer 之間必需有良好溝通機智。在本系 統中我們的Server 是使用樹狀結構方式，每一 Server 在一段時間後會 向RootServer 詢問目前那些 Server 已啟動，及是否有使用者留言，如 果有新的留言訊息，會將其訊息傳回Server，等使用者得到其 mail 的 資訊後，再向存有其真正存多媒體留言的Server 接收其 mail 內容。
4.5.4 混音
在本計畫中的Conference，也使用了混音的技術，來減少頻寬的 使用。所謂的混音，就是將多個聲音來源，在一個集中的來作聲音的結 合動作，將多個聲音來源，只以一個聲音頻寬的大小來輸出，大大地減 少頻寬的使用。而混音最大的困難就是如何將多個來源快速地結合，以 減少時間Delay 的問題，所以在作混音的 Chairman，再作混音時，作 每個來源必需有適合的緩衝區大小，以平衡各個來源不同頻寬的同步。
除此之外，另一個問題就是當已混音的聲音頻寬，突然加入另一來源必 需先對之前的來源暫存，並重新混音:，而且這些動作都是即時的，所 以在設計上必需考慮其動作先後時序。
4.5.5 多人視訊流程會議簡化設計方法
首先必需先有人當視訊會議的的暫時伺服器(會議的建立者)，每個 要加入會議的人，都先連線到此伺服器，如果有其它的可用暫時伺服 器，也可以將所有加入會議的人可以平均分配到所有暫時伺服器，以簡
4.5.6 多人視訊會議的多媒體特殊設計方法
本專題中為法達成多人視訊會議的目標，特別設計出一套可多人連 線，自動轉接，自動分配封包的Media Router，透過 Reorderable Multimedia Queue，來作多媒體串流的處理， 並且成功地以只用到二 個port 來傳輸所有人的影像及聲音，以下是本專題多媒體的架構 -jemi.media
-device
-Device +player
+recoder -rtp
+Audio +Video +Adapter +moniter +file +util
套件名稱 功能
device 將每一種可能的來源與目的定義為一種device，並且為其 加上 Heart Processor 為其 heart，只要 heart 正常運作，
就可以自動將Stream 無限地分支傳輸。
Video、 Adapter、moniter、file 這些子套件來處理各種多 媒體傳輸。
以下是其主要功能元件功能說明:
1. DeviceManager:此為管理及 detect 各種裝置的主要物件，可由其 來發現使用者使用環境上所有可用的裝置，如Camera、
Microphone、Audio Card、和所需的元件是否已經安裝，且可透 過此物件來產生各種所需的NetworkDevice，包含目的及來源的 NetworkDevice。
2. NetworkDevice:此為最處理底層 RTP 協定的主要元件，包含了 RTP Stream 的傳輸、混音、混影像、各種 RTP 事件的處理、來源 串流的分析及分配、來源串流使用者的確認與比對，由於同一 NetworkDevice 可能處理多個到無限制來源的多媒體串流，所以其 處理能力相當重要。
3. VideoTransmitter 及 AduioTransmitter:其分別為處理及管理 Video 與 Audio 使送目的主要物件，它接收由 NetworkDevice 來 的各種事件及各個可用的多媒體串流，其中VideoTransmitter 更 可以和AudioTransmitter 結合，可辨別出來自同一來源的串流來 作組合，因為網路上的串流來的順序可能不一樣，其中Audio 及 Video 都可能發生，所以處理這部份是本專題的重點之一。
4. MediaRecoder:此為將各源的串流存為檔案的主物件，包含來自網 路的H.263、g.723、JPEG、mpeg 等 RTP 串流，和本地的 MicroPhone、Camera 等裝置的串流，編碼為各種檔案類型，如 mov、mp3、avi、mpeg 等常用的檔案，以方使用者存取。
5. VideoPlayer:其為呈現來自網路、本地的各種多媒體裝置，其可處 理包含本地的各種聲音及影像檔案，另外它也可以處理來自網路上 的各種RTP 串流呈現給使用者。
4.5.7 傳輸架構
4.5.7.1 使用中的傳輸架構
本專題中是做用所謂的Client-Server 架構，但 Client 與 Server 之 間，和Server 與 Server 卻都是以 Peer-to-Peer 的方式來模擬，當 Client 和Server 之間建立一次 Video 及 Audio 的連線後，以後再有使用者加 是以Client-Server 端的模式為基礎，首先使用者必需先加入會議中，
先連線到Chairman 中，彼此先建立雙方會議，在此 Chairman 和使用 者之會分別用4 個 port 用來傳遞彼此的視訊和聲音，透過 RTP 協定來 作溝通，將視訊編碼為H.263/JPEG 等格式，而聲音則可編碼為 GSM/ULAW/G.732/mpeg 等格式，依使用者的環境和喜好來設定，且 彼此間沒有必需使用相同的格式來傳輸，除此之外，雙方的視訊和聲音
在雙方建立完連線後，雙方底層必需隨時監看串流的變化，且也必 需注意 RTP 的訊息是否有變化。在連線的過程中，可以由使用者的需求 決定串流的傳送、暫停、停止等情況，當使用者暫停時，接收端必需也 暫停串流的輸出呈現，另外如果使用都停止傳送時，必需由 RTP 協定告 知接收端必需結束串流的呈現，並將畫面結束。這些動作雙方的底層都 會自動的處理和維護。
4.5.7.2 三方到 N 方會議的處理方式
在本專題中可以由Client-Server 的模式來建立 N 方會議，以下是 傳統上處理多人會議上所需面對的難題
ü 串流的處理相當複雜，在多人連線的情況下，Sever 端必需結 收所有人的連線。
ü Server 端的連線數多，且必需將串流和其他使用者再建立連 線來傳輸，流運非常大。
ü 每人到 Server 端的視訊與聲音串流來的順序並不相同，必需 有特別的設計來作處理。
ü 和其它人的連線。流程複雜且效能不理想，使用者和使用者之 不如直接建立連來得好。
4.5.7.3 優點
Server 端建立基本的連線後，以後就不必再建立任何其它 的連線了(此為特別設計)。 者建立連線，包括 private ip to private ip、private ip to public ip、public ip to public 等環境。8. 加上可減少 delay 的設計方法，使其連線速度接近一對一 Server 建立雙方通話，就會自動地用已建立連線的使用者 用既有的連線得到另一會議的所有使用者資料。
12.提出特別的設計架構，使得使用者端的多媒體資料如同心 臟一般可以自由的分支和處理。
以下是多人會議時其連線架構:
4.5.8 使用者端 Device 的建立
首先對每一用者的裝置作了一個特別的架構，將每一種裝置如Camera 定義為VideoDevice，Audio Card 為 AudioDevice，各種多媒體檔定義為 FileDevice，Network Card 定義為 NetworkDevice，且在每一 Device 中加 入一種Heart processor 來作為其串流的開關和分支，當使用者建立了每一 Device 後，Device 會試著去測試連線，以確認該 Device 可用，之後會啟動 其內部的串流作不斷地送出，之後只要對該Device 要求就可得到該 Device 的串流，以後不管有少個要求，都可以動態地分支，重覆使用，如同有許多 Device 來作服務，而當使用者把 Heart Processor 停止時，所有分送出去的 串流也會自動地停止，也可以動態地單獨暫停某一分支，然後再啟動。除此 之外，也可以透過特別的介面，把二個devce 的輸出轉為輸入，如可以把 AudioDevice 的輸出轉到 FileDevice 的輸入，就可以在把串流在到檔案去，
更可以把如AudioDevcie、VideoDevice、FileDevice 傳到 NetworkDevcie，
如此就可以將串流傳輸到另一方的NetworkDevice 來輸出呈現。以下是其 Device 的 logic 圖:
AudioDevice FileDevice VideoDevice
每一Device 如同心臟一般，內部有一 個特別的Heart processor，只要心臟 User1 Chairman
User2
User3 多人會議多媒體處理方式
4.5.9 主席端內部的特別設計
本專題中主席必能有能力處理來自各方的串流，由於所有的串流都必需 經由主席來傳輸到其它人，所以其流量非常大，且有相當複雜的情況，如串 流來的順序，串流的來源的分析(因為所有人串流者經由主席，必需將串流 傳到還沒有的會議中的使用者)，所以設計在其內部設計了一個 Auto Reorder Queue，用來將不同順序到來的串流自動作 reorder 和分析其編碼 格式，並將聲音混音，且將影像以多工器的方式模擬加入同一串流輸出，其 reorder Queue 中移除，且不可以使其它在傳輸中的使用者斷線、暫停 等不良情況，使得使用者可以動態地加入和離開，但卻不會影響其它使 用者的連線。
以下是主席端中Reorder Queue 的架構
4.5.10 內部的 Multicast
當有新的使用加入到會議中時，主席會將得到的新串流送給其它已加入 會議中的人，所中是軟體的方式模擬Multicast 的傳送，主席會將收到的串 流，自動作串流的分支的動作，將串流分送給其它人，這個過程相當快且不 可以斷斷續續，必需一直維持其串流的穩定。
以下是其Multicast 的過程：
以下是其Multicast 的過程：