第四章、 研究結果
4.2. 數據分析
由4.1節所規劃的三種測試環境皆為實際測量方式，其中的每一個項目測試 環境在本架構中皆由一台Master作為分配負載之伺服器，將使用者所產生之流量 指派到二台Slave伺服器作平衡負載、編碼轉換與通話監聽之測量。
在平衡負載測試項目中由一台 OpenSER 作為分配負載之伺服器，經由 OpenSER 將 RTP 會議導向到二台 RTP proxy 伺服器作為分擔使用者之流量，並 與本架構作為平衡負載之數據比較。在編碼轉換測試項目中由一台 SIP 伺服器 (Asterisk)擔任使用者之間編碼轉換之伺服器，並測量本架構與使用主從式架構之 SIP 伺服器在使用編碼轉換時的數據比較。最後在通話監聽測試項目中同樣由一 台使用主從式架構之 SIP 伺服器作為監聽側錄之服務，並與本架構使用分散的方 式所建構的監聽系統作為比較。
4.2.1. 平衡負載：
平衡負載測試項目中測量本系統架構與 OpenSER 搭配 RTP proxy 架構，在 使用者方面由 8 與 13 對 UA 所組成，每對 UA 最大同時通話數為 20 通，總共產 生的 SIP 會議為 500，因此系統將負擔 160 與 260 通同時通話數，其數據分析如 下：
1. SIP 會議建立與終結時間
如圖 31與所示左邊為多重伺服器架構，右邊為OpenSER架構，多重伺服器 在同時 160 通話數下UAC建立與終結SIP會議的時間大約分佈於 9 到 12 毫秒間，
在OpenSER環境下會議建立時間分佈於 40 到 80 毫秒區間，與多重伺服器相差約 30 毫秒。
(a) Multi Server (b) OpenSER with 2 RTP proxys
圖 31 平衡負載 SIP 建立與終結時間 – concurrent 160 call
如圖 32為同時 260 個通話數下對於SIP建立與終結時間比較，在多重伺服器 中會議時間大部份分佈於 10 到 20 毫秒區間，而在OpenSER架構下當UAC執行 到第 40 個會議時表示目前有 260 通電話同時進行，系統開始出現負載使得SIP 會議建立時間明顯增加。
(a) Multi Server (b) OpenSER with 2 RTP proxys
圖 32 平衡負載 SIP 建立與終結時間 – concurrent 260 call
如表 5為同時 160 與 260 通話數在會議建立與終結時間表，在多重伺服器架 構下同時 160 通話數時 500 個SIP會議分佈時間在 25 毫秒以下，其中分佈在 10 到 25 毫秒之間佔 75%，在同時 260 通話數時分佈在 10 到 25 毫秒下的SIP會佔全 部的 94%，而超過 50 毫秒的SIP會議數共有 4 通。在OpenSER架構下同時在 160 通話數下分佈於 50 到 100 毫秒之間，佔全部會議的 97%，在同時 260 通話數下 佈全部的 95.8%分佈於 100 毫秒以上，表系統已到達飽和狀態進而影響SIP會議 的建立與終結時間。
表 5 平衡負載 SIP 會議建立與終結時間表
Session Multi Server - 160
OpenSER - 160
Multi Server - 260 增加了 6 毫秒的延遲時間。在OpenSER架構下使用二台RTP proxy對於同時 160 通話數延遲時間約分佈在 200 到 300 毫秒區間，然而二台RTP proxy並無法負荷 同時 260 個通話數，因此在 500 個SIP會議中RTP proxy只完成了約 68%的語音傳 送服務，而RTP proxy在 260 個同時通話數下達到了滿載的情況，進而影響了RTP 延遲時間與OpenSER建立SIP會議時間。
(a) Multi Server (b) OpenSER with 2 RTP proxys
圖 33 平衡負載 RTP 延遲時間
表 6 平衡負載 RTP 延遲時間表
Delay Multi Server - 160
OpenSER - 160
Multi Server - 260 260 個同時通話數時，二台RTP proxy並無法負擔，因此抖動時間愈來愈長並且無 法完成所有的RTP會議。
(a) Multi Server (b) OpenSER with 2 RTP proxys
圖 34 平衡負載 RTP 抖動時間
Jitter Multi Server OpenSER - Multi Server OpenSER -
- 160 160 - 260 260
<1 ms 10 0 0 0
<2 ms 486 0 344 0
<10 ms 4 0 156 0
<20 ms 0 163 0 12
<40 ms 0 309 0 130
>40 ms 0 28 0 194
4.2.2. 編碼轉換：
在編碼轉換測試項目中，由多重伺服器與單一 Asterisk 作為比較，Asterisk 為 SIP IP PBX 的一種，使用 B2BUA 方式以主從式架構傳送 RTP 訊息，因此當 RTP 經過伺服器時 Asterisk 可從中進行編碼轉換的服務。由於不同的編碼有不同 的取樣頻率與使用頻寬，伺服器對於不同的頻寬時需使用緩衝器(buffer)平衡頻寬 不同問題，因此由延遲時間與抖動時間可顯示使用者經由編碼轉換時的通話品 質。
1. SIP 會議建立與終結時間
如圖 35為多重伺服器與單一Asterisk在同時 80 個通話數時建立與終結SIP會 議所需時間，多重伺服器在建立與終結SIP會議時間約分佈於 9 到 11 毫秒區間，
而Asterisk則分佈於 11 到 14 毫秒之間。
(a) Multi Server (b) Single Asterisk
圖 35 編碼轉換 SIP 建立與終結時間 – concurrent 80 call
如圖 36為二架構同時 120 通話數時SIP建立與終結所需時間，多重伺服器約 分佈於 9 到 13 毫秒區間，與同時 80 通話數大約增加了 2 毫秒，而在單一Asterisk 架構中同時 120 通話數約分佈於 12 到 18 毫秒區間，與同時 80 通話數大約增加 了 4 毫秒。
(a) Multi Server (b) Single Asterisk
圖 36 編碼轉換 SIP 建立與終結時間 – concurrent 120 call
如表 8時間比較表，在多重伺服器中同時 80 與 120 通話數在 10 毫秒以內佔 43%與 27%，而Asterisk則全部分佈於 10 到 25 毫秒區間。
表 8 編碼轉換 SIP 會議建立與終結時間表
Session Multi Server-80 Asterisk-80 Multi Server-120 Asterisk-120
<10 ms 215 0 135 0
<25 ms 285 500 365 500
<50 ms 0 0 0 0
<100 ms 0 0 0 0
>100 ms 0 0 0 0
2. RTP 延遲時間
如圖 37為RTP封包延遲圖，二種架構對於編碼轉換時所產生的延遲時間分 佈相近，約為 30.5 到 33 毫秒區間，然而Asterisk使用主從式架構傳送RTP訊息，
在單一伺服器中測量最高可同時傳送 120 通話數量，因為對於同時 120 通話數時 延遲時間相似，一但超過時Asterisk將無法負擔過多的RTP訊息。
(a) Multi Server (b) Single Asterisk
圖 37 編碼轉換 RTP 延遲時間
如表 9為延遲時間比較表，二種架構在同時 80 與 120 通話數皆分佈於 25 到 50 毫秒之間。
表 9 編碼轉換 RTP 延遲時間表
Delay Multi Server - 80 構對於二種不同通話數仍保有相似的抖動時間，在單一Asterisk架構中同時 80 與 120 通話數之抖動時間有明顯的差異，表示Asterisk在處理不同的通話數時系統效 能慢慢影響RTP封包延遲的變化量。
(a) Multi Server (b) Single Asterisk
圖 38 編碼轉換 RTP 抖動時間
如表 10為RTP抖動時間分佈表，二種架構在抖動時間分佈類似約介於 2 到 10 毫秒之間。
表 10 編碼轉換 RTP 抖動時間表
Jitter Multi Server - 80
<1 ms 0 0 0 0
<2 ms 0 0 3 0
<10 ms 500 500 497 500
<20 ms 0 0 0 0
<40 ms 0 0 0 0
>40 ms 0 0 0 0
4.2.3. 通話監聽：
在通話監聽測試項目中以多重伺服器架構與單一 Asterisk 作為比較，在進行 通話監聽服務時系統需將使用傳送的 RTP 訊息給予記錄，而在記錄的過程中由 於增加了寫入硬碟的 I/O 時間因此增加系統額外的負擔，由於在監聽過程中不能 讓使用者得知目前的通話以被記錄，因此由 SIP 會議建立到終結的時間與 RTP 延遲、抖動時間將直接影響使用者通話品質。
1. SIP 會議建立與終結時間
如圖 39為同時 80 通話數下二種架構在建立與終結SIP會議時的比較，在 Asterisk架構中由於受限於硬碟I/O時間的影響，系統對於SIP處理時間相對的 增，由於SIP會議時間分佈忽高忽低表示Asterisk處於不穩定的情況下。在多重伺 服器中SIP會議時間大約分佈於 10 到 20 毫秒之間，雖然部份SIP會議時間較長，
但不像Asterisk架構處於不穩情況。
(a) Multi Server (b) Single Asterisk
圖 39 通話監聽 SIP 建立與終結時間 – concurrent 80 call
如圖 40為同時 120 通話數下二種架構對於監聽時所量測的SIP會議建立與 結時間，由Asterisk架構顯示系統無法負擔 120 通監聽數，因此嚴重的影響SIP會 議時間，並且無法成功的完成 500 個SIP會議。在多重伺服器架構下比起同時 80 通話數明顯增加了SIP會議時間，但在整體情況下多重伺服器在同時 120 通話數
比Asterisk在同時 80 通話數環境下表現的較好。
(a) Multi Server (b) Single Asterisk
圖 40 通話監聽 SIP 建立與終結時間 – concurrent 120 call
如表 11為二種架構在同時 80 與 120 通話數下SIP會議建立與終結時間比較 表在多種伺服器架構中以 10 到 25 毫秒分佈最多，在 80 通話數下佔 57.8%，在 120 通話數下佔 55.8%。在Asterisk架構中同時 80 通話數分佈在 10 到 25 毫秒佔 43.4%，其它則分佈於 100 毫秒以上佔 34.8%，在同時 120 通話數時Asterisk以處 於不穩定情況，在已完成的SIP會議比例中超過 100 毫秒的會議佔大多數。
表 11 通話監聽 SIP 會議建立與終結時間表
Session Multi Server - 80
Asterisk - 80
Multi Server - 120
(a) Multi Server (b) Single Asterisk
Delay Multi Server - 80 量。在Asterisk架構中說明單一個伺服器在處理監聽服務時，同時 80 通話數可能 是系統最大處理能力，在同時 120 通話數時系統開始丟棄無法處理的RTP會議，
而其它正在傳送的RTP訊息受到系統不穩定的情況下，抖動時間呈現不規則分 佈。
(a) Multi Server (b) Single Asterisk
Jitter Multi Server - 80 Asterisk 的抖動時間中可看出 Asterisk 在 120 通同時通話情況下，系統所造成的 負擔進而影響抖動時間的變化，但是在多重伺服器架構下抖動時間並沒有太大的