1. 會議參與者權力分為主席(chairman)與一般(normal) 2. 擁有主席權限的端點為
I. 建立該會議者 II. 可使用投票系統 III. 驅逐參與者
IV. 主席關閉會議，所有人一並離開會議。
3. 產生視訊會議的方式有：邀請使用者及加入會議，當端點無參與視 訊會議並邀請其它端點建立會議時，即成為主席。
4. 當某端點己身在某一會議，即無法加入其它端點的會議，或被邀 請，也就是說，每一端點僅能建立一個會議。
5. 當會議僅剩一人時，會議即結束。
4.4.2 元件概觀
元件名稱 主司
ConferenceModule 使用者透過此，與Conference及 ConferenceWindow互動，也負責告知 Main 如何關於會議的選單文字 ConferenceWindow 視訊會議的使用者界面
ConferenceService 負責視訊會議的流程，管理Conference 元件
Conference 管理多個Participant元件及媒體元件 Participant 記錄其它參與者之會議相關資訊
表 4.4.2.1 元件概觀 ConferenceModule –
使用者按下『邀請使用者』或『加入會議』ConferenceModule即 呼叫ConferenceService處理使用者的要求，並要為ConferenceService 向主程式要求需要的媒體裝置元件。
ConferenceService –
透過PeerProvider收發相關視訊會議的訊息，依視訊會議邏輯，呼 叫Conference以執行流程。
Conference –
1. 記錄端點的會議流程狀態，以避免例外情況發生 2. 操作媒體裝置元件，產生視訊及聲訊
3. 記錄同一會議之參與者及彼此的關係 Participant –
記錄其它參與者的權限及端點會議與其它參與者間，媒體裝置的傳 收關係。
圖 4.4.2.1 視訊會議系統堆疊圖
Main
ConferenceModule ConferenceService
Conference
Participant Participant Participant
4.4.3 系統狀態及流程
圖4.4.3.1 系統狀態流程圖
使用狀態記錄目前會議的邏輯流程，以避免進入無法預測的狀態，
例如：使用者在加入某會議的同時，又同意了另一使用者的邀請，當狀 態處於AUTHORIZE CALL ATTEMP或CALL DELIVERY時，便無法加 入其它人的會議或邀請他人加入會議。
DISCONNECTED AUTHORIZE_CALL_ATTEMPT
CALL_DELIVERYY
CONNECTED
4.4.4 以邀請建立會議的各種狀態流程
Chairman Inviter Invited
1.
INVITE DISCONNECTEDAUTHORIZE_CALL_ATTEMPT
DISCONNECTED
AUTHORIZE_CALL_ATTEMPT
CONNECTED
CALL_DELIVERY
CALL_DELIVERY
CONNECTED
CONNECTED
1. 邀請方在INVITE Request中，指出會議相關訊息，包括 會議編號、主席端點位地、會議主題、是否有視訊聲訊會 議，邀請方的起始狀態可以是DISCONNECTED或 CONNECTED。
2. 被邀請方接受邀請送回ACCEPT Response前，將主席加 入己方的會議、並與主席建立訊息管線，若建立視訊聲 訊，則建立視訊聲訊網路接收裝置以等候主席端傳送媒體 串流。
3. 邀請方收到ACCEPT Response後，將Response內參數加 入CADDN Requeset，並對主席端發出請求。
4. 主席端先回應邀請方，再與被邀請方建立相關媒體連線，
並以NADDO Request告知被邀請方目前會議的成員。
5.
被邀請方a. 加入各會議成員
b. 與各成員建立訊息管線
c. 以OADDN Request告知各成員，自己己經加入
4.4.4.2 主席邀請第三者(接受)進入會議
Chairman Invited
1. INVITE CONNECTED
DISCONNECTED
AUTHORIZE_CALL_ATTEMP
Query User
CALL_DELIVERY AUTHORIZE_CALL_ATTEMP
2. ACCEPT 0x01
CALL_DELIVERY
3. NADDO
CONNECTED 4. NADDO 0x08
由於邀請人為主席，因此不用另行通知，其流程與非主席參與者邀 請第三者(接受)進入會議類似且更為精簡，接下來是邀請流程的UML 順序圖。
圖 4.4.4.2.1 邀請流程的UML順序圖
由於版面限制本圖最右方的是PeerProvider物件未畫出，本圖所描 述情境是邀請方並未建立會議，因此一開始呼叫ConfereService的 createChairmanConference()，如果邀請方己處於會議中，則直接呼叫 Conference的inviteUsesr()，接下來介紹的是非主席參與者邀請被拒的 狀態流程。
:ConferenceModule :ConferenceServic :Conferenc createChairmanConference() new Conference()
inviteUser()
processResponse() addParticipant() :ConferenceListener
addParticipant()
transmitAudio() transmitVideo() addAudioReceivePort() addVideoReceivePort()
sendRequest()
圖 4.4.4.2.2 非主席參與者邀請被拒狀態流程圖
由圖可知，參與者仍可保持送出邀請前及收到邀請前的狀態，使會 議可繼續進行，這是視訊會議系統非常重要的特性，就是狀態的安全 性，我們必須避免狀態超出掌控的情況，無論是受到使用者無意的不正 常使用，或網路及執行環境的影響，這些影響將於後述。
4.4.5 以加入動作進入會議
加入動作只有在並沒有建立本地會議的情形下，才能動作，若己建立會 議則無法使用此動作，加入動作下達後，可能發生的情況。
1. 本地會議己建立，動作中止 2. 對方同意
3. 對方拒絶
4. 對方忙碌中(可能正與他人建立會議) 5. .對方未建立會議
Inviter Invited
1. INVITE
2. REJINVITE 0x02
CONNECTED
DISCONNECTED
AUTHORIZE_CALL_ATTEMPT
DISCONNECTED AUTHORIZE_CALL_ATTEMPT
Query User
CONNECTED
4.4.5.1 以非主席參與者為對象(接受)加入會議
圖 4.4.5.1.1 以非主席參與者為對象(接受)加入會議
CONNECTED 7.NADDO
6.OK 0x05 4.CADDN
3. JOIN
2. CONFERENCE 0x06 Joined
Chairman Joiner
DISCONNECTED 1. QUERY
CONNECTED
AUTHORIZE_CALL_ATTEMP
Query User
CONNECTED
AUTHORIZE_CALL_ATTEMPT
CALL_DELIVERY
CALL_DELIVERY
5.WELCOME 0x04 CALL_DELIVERY
9. OADDN
1. 首先查詢對方的會議狀況：
² 對方會議狀態為DISCONNECTED則回應「對方為建立會 議」
² 對方會議狀態不為CONNECTED且不DISCONNECTED 則回應「對方忙碌中」
²
對方會議狀態為CONNECTED則進入下一步2. 加入方送出加入請求，被加入方會議詢問使用者是否同意此 加入請求。
3. 被加入方同意後將回應WELCOME Response並送一份 CADDN Request至主席端。
4. 主席端先回應邀請方，再與被邀請方建立相關媒體連線，並 以NADDO Request告知被邀請方目前會議的成員。
5. 被邀請方
Ø 加入各會議成員
Ø 與各成員建立訊息管線
Ø 以OADDN Request告知各成員，自己己經加入
其中步驟4、5與非主席參與者邀請第三者(接受)進入會議相 同，就是為了保持會議參與者列表的一致性及整體會議流程的一致 性
4.4.5.2 以非主席參與者為對象(拒絶)加入會議。
圖 4.4.5.2.1 加入被拒狀態流程圖
雖然同樣是回應CONFERENCE Response但與對方同意加入 請求不同的是Response中，包含一參數FLAG值為N，同意則為Y，
若參數中無SESSION則表示對方沒有建立會議。
1.QUERY
2. CONFERENCE 0x06
Joined Joiner
CONNECTED DISCONNECTED
AUTHORIZE_CALL_ATTEMPT
DISCONNECTED Query User
AUTHORIZE_CALL_ATTEMPT
CONNECTED
4.4.5.3 加入會議的UML順序圖
圖 4.4.5.3.1 加入會議的UML順序圖
上圖的觀點在於加入者本地會議系統的呼叫流程，一開始從 ConferenceService取Conference物件，狀態DISCONNECTED，
之後利用該物件查詢被加入者的會議狀態，一旦對方同意後再重新 sendResponse() transmitVideo()
transmitAudio()
addVideoReceivePort() addAudioReceivePort() processServiceEvent()
processRequest() processResponse()
sendRequest() joinConference()
createNormalConfence()
sendRequest() getConference()
queryConference()
:ConferenceModule :ConferenceServic :Conferenc
processResponse()
addParticipant() :ConferenceListener
addParticipant()
4.4.6 正常離開視訊會議
Leaver
4.OK 0x05 3.KICKOUT
2.OK 0x05 1.QUIT
Chairman Other
CONNECTED CONNECTED CONNECTED
DISCONNECTED
同樣的，為保持一致性，參與者的離開請求需送至主席，再由主席 轉告，主席轉由KICKOUT Request告知，KICKOUT Request本是用在 強制驅離視訊會議的使用者，不過也可用於此，下圖為主席方收到離開 CADDN Request至主席，此時主席可能正處理其它人的 CADDN Request或本身的邀請流程，如果不予理會而處理此 請求，則可能造成整體會議中，有兩位參與者看不到彼此，
如果回應忙碌則造成使用上的不便。
解決方法：使用一訊息佇列暫存請求，待主席處理其它事務完畢後 再從訊息佇列取出並處理。
(2) 非主席參與者送離開請求至主席，此時主席可能正處理其它 人的CADDN Request或本身的邀請流程，如果新進入之會議 參與者己收到會議參與者名單並送出OADDN Request則離 開者也會收到請求而不予理會，導至新參與者出現
TimeOut，同時多媒體裝置的開啟及關閉也會出現不同步現 象。
remoteVideoDevice() remoteAudioDevice() removeParticipant()
processRequest()
:ConferenceListene :ConferenceService :Conference
sendRequest()
例外狀況則是因為使用者不正常使用或網路環境因素導至，可能發 生的情況如下：
(1) 使用者不關閉視訊會議視窗而直接關閉主程式。
解決方法：由於主程式的關閉會告知JEMI-Server，JEMI-Server 會轉告該使用者所有上線連絡人，ContactService將丟出
ContactUserRemove事件，ConferenceService收到此事件後，直 接將該參與者從本地參與者列表中移除。
(2)使用者網路中斷。
解決方法：無可避免的，其它會議參與者對該使用者的訊息管線將 出現錯誤，某訊息管線出現錯誤，Conference將關閉該管線，並於 視窗界面中告知無法傳送訊息至該使用者，但並不移除該參與者，
直到JEMI-Server偵測不到該使用者而發出通知。
4.4.8 結論
本視訊會議的特點是decenterization，所有使用者的會議的管理並 非集中至JEMI-Server而是由該會議中的某一參與者負責，也就是主 席，這種作法的好處是避免集中管理的缺點，例如因集中管理程式或主 機失誤而導至所有使用者無法建立視訊會議，也可避免集中管理主機負 載過重而導至效能低落，因為具有這些優點所以視訊會議採用
decenterization技術。