在當今VOIP通信網絡，語音編碼轉換的需求正在逐步增長。IP電話網絡中，一個正常的語音通話，可能是在跨網絡，多協議，多語音編碼環境中進行。因此，終端之間跨網絡語音通信，語音編碼轉換是一個非常普遍，非常必要的需求。通常，對語音編碼轉換處理，有兩種方式：軟件語音編碼方式和Sangoma的硬件DSP處理方式。因為價格和穩定性方面的差異，用戶對軟件編碼處理和硬件編碼處理方式的不同有所疑問。為了給廣大用戶提供一個比較可行的，權威的測試數據，我們使用Sangoma E1語音卡，Sangoma 編碼卡和asterisk開源軟交換平臺作為測試平臺進行了壓力測試。 我們希望，通過Sangoma的測試方法，可以給用戶提供一個比較科學的，可信的壓力測試數據，為用戶將來在VOIP落地，編碼轉換解決方案，呼叫中心解決方案提供一個權威，有價值的行業參考標準。本測試用例分為幾個方面的內容： 　　測試工具選擇，測試流程方法，測試結果，測試局限性和對未來如何測試語音編碼轉換的展望。

Sangoma語音編碼測試工具

　　測試工具選擇 　　測試的方法多種多樣。選擇科學合理測試工具是非常重要的。選擇以上測試工具的理由：

1. Asterisk本身是目前最受歡迎的，相當穩定的開源呼叫中心平臺，具有可靠的穩定性。
2. 單張A108卡可以支持E1 240路并發呼叫，作為E1呼叫測試的接口，保證支持240路正常通話，使用兩張A108，測試呼叫量高達300路。
3. D100 支持市場上大部分的語音編碼，包括G.729,AMR,G.732等等語音編碼，當然也可以選擇Sangoma D500 作為高并發分布式系統測試。
4. SIPp 是目前開源的，免費SIP呼叫測試工具，可以靈活配置各種語音編碼，并且穩定性高，作為權威的測試工具是完全可以保證測試數據的真實性。
5. 通過3個不同型號的CPU進行測試，數據具有普遍性。
6. 使用標準的linux 發布版本：centos，平臺標準化保證了數據的說服力。

圖例 1：Sangoma A108/D100/SIPp語音編碼測試流程圖

　　測試流程方法 　　通過以上測試流程圖，我們可以看出，具體的測試過程需要以下6個步驟：

1. 通過SIPp 腳本語言發起一個SIP測試呼叫。
2. 網關接受SIP呼叫。
3. D100 編碼轉換卡轉換成G.711 語音編碼，然后發送到A108 數字卡。
4. 此呼叫通過A108端口回環呼叫，返回到A108數字卡的另一個端口。
5. D100 再次對此呼叫進行編碼。
6. 此呼叫通過網關呼出，接收端接收呼叫。

　　以每秒6路通話的頻率發起呼叫，直到網關asterisk CPU 不能負載任何系統任務。

　　測試結果 　　通過使用軟件編碼轉換和Sangoma硬件編碼轉換卡進行的G.711，G.729轉換處理得出以下數據結果：

圖例 2：G.711-G.729 Atcom D150 CPU 狀態（軟件回聲和硬件編碼卡對比結果）

圖例 3：G.711-G.729 Dual Core E5200 CPU（軟件回聲和硬件編碼卡對比結果）

圖例 4：G.711-G.729 Core 2 Quad Q8200 CPU（軟件回聲和硬件編碼卡對比結果）

　　通過兩組結果的對比，可以發現，同樣CPU，同樣的Asterisk軟交換平臺使用硬件編碼轉換卡比使用軟件編碼可以降低系統CPU負載50%，同時處理能力增加了100%。所以筆者建議，在比較大型（至少100路以上）的呼叫會話處理環境下，建議用戶使用Sangoma硬件編碼轉換卡做語音編碼解決方案。 　　測試局限性 　　任何參數都有一定的局限性，本方法的局限性是：

• 測試只是使用了G.711 和G.729 編碼，其他編碼沒有測試。
• 編碼轉換以后的語音質量是抽查樣本，不能代表所有語音會話，可以測試G.711, G.722, G.722.1, G.726, G.729AB, GSM-FR, GSM-EFR, AMR, AMR-WB (G.722.2), iLBC， 支持1000路會話處理。
• 通話時長不能完全體現實時的系統呼叫。
• 測試僅在內網進行，缺乏對Delay，抖動，丟包和QoS等因素非常有效的檢測。

　　測試語音編碼轉換的展望 　　以上測試方法肯定不是最完美的方法，存在很多不足之處，例如，如何測試高并發狀態下的系統資源狀態等等。為了進一步進行測試編碼轉換的高并發測試，用戶可以根據自己的應用環境做進一步的測試，采用Sangoma 16E1，D500 高并發的編碼卡在最新的Asterisk-11 平臺對其他幾種編碼進行測試，同時加大語音采樣樣本，最多限度反映真實的數據處理狀態。當然還有非常好的測試方法，希望有豐富經驗的用戶提出反饋意見。