在当今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 平台对其他几种编码进行测试，同时加大语音采样样本，最多限度反映真实的数据处理状态。当然还有非常好的测试方法，希望有丰富经验的用户提出反馈意见。