经常有人认为，在SSL VPN链路上应用VoIP，VoIP通话质量不会很好。为了验证这种论断，我们在4个
假设的网络场景中测试了10款SSL VPN产品来观察一下VOIP的呼叫质量。
测试结果非常鼓舞人心。在高带宽，低延迟的环境下，一个未加密的VoIP呼叫和同样在SSL VPN上传输
的VoIP呼叫其通话质量没有什么本质的不同。更好的消息是，在宽带Internet连接环境下，SSL VPN
上传输的VoIP通话质量甚至比未加密的呼叫还要好。唯一的坏消息是：在不好的网络连接条件下--高丢
包率、小带宽，无论是未加密的VoIP呼叫还是受SSL VPN保护的呼叫，其通话都质量差强人意。
参测厂商除了Fortinet公司的Fortigate产品之外，还包括AEP Networks的Netilla安全平台，
Array Networks的SPX-5000，Aventail的Smart SSL VPN，Caymas System的Caymas 525，
Check point的Connectra，F5的FirePass 4100，Juniper Network的Secure Access 6000，
Nokia的Secure Access System 500，Nortel的VPN网关3070和SonicWall的SSL-VPN 2000。
在不同产品之间，我们的测试结果会有一些差别，MOS值细微的差别不因该被认为是非常大的区别。我
们应着重注意到：在宽带网络上，SSL VPN和VoIP一起工作得非常和谐，甚至是在网络丢包和拥塞的情
况下。同时，我们还应注意到，同一家以datagram（数据报）技术为基础的SSL VPN，例如Nortel和
Juniper，和以TCP技术为基础的SSL VPN产品在VoIP传输结果方面相比，不会有任何实际的先进之
处。
为了测试在SSL VPN上传输VoIP的效果，我们利用了GL通信公司的产品来衡量语音呼叫质量，此产品
具有标准化的测试流程。为了观察VoIP在宽带Internet服务提供商真实世界中的表现，我们使用了
Shunra Virtual企业版软件来注入延迟、丢包或者其他的一些损伤，注入的这些损伤值是我们是根据
在实际的无线热点宽带IP服务应用中所得出的，这些无线热点包括旅馆和其他一些临时的地点。我们在
SSL VPN客户端使用了“软电话”SIP软件，在SSL VPN服务器内部使用了SIP“硬电话”。
我们测试了4个假定的情景，范围从完美的无延迟的百兆网络到具有60毫秒延迟吞吐量为100Kbps很
差的网络，或者包括其他一些损伤的网络环境。我们假定了4个场景-“未受损伤的
（unimpaired）”、“好的（good）”，“差的（bad）”，“差的/慢的（bad/slow）”。
我们的第一个测试是看一下在没有VPN情况下，SIP软件和硬件是如何工作的。GL语音质量测试工具可
以测试语音呼叫的MOS等级，高等级代表更好地呼叫质量。大部分人认为分数在3.0以上是可以接受的，
尽管语音质量有明显的降级。目前仍然没有一些规定好的语音呼叫质量标准认为哪些测试分数是可以接
受的。
我们的下一个测试是衡量在无损伤的网络环境下，每一家SSL VPN产品承载VoIP呼叫的表现如何。测
试结果非常好。通常来说，SSL VPN会引起非常小的VoIP呼叫质量损伤。最好的MOS值是4.24，在这个
测试中，最坏的值是4.16（F5除外）。最坏的值和最好的值区别不是很大。F5 FirePass 4.02的分数
值较低为4.02，但仍然被认为通话质量比较好的呼叫。我们承认，在零延迟的无损伤网络环境下所测试
出的结果，并不能告诉我们这些设备在真实世界中的表现如何。
在性能非常好的网络中测试的性能值非常违反常规的感觉。我们预测：在SSL VPN链路上传输的VoIP
其呼叫质量不会比在一个“干净”的链路传输得更好，这仅仅是因为协议层次的SSL VPN上，TCP和SSL
协议会发生额外地解释，而在SSL VPN上传输了以UDP协议为主的VoIP数据流。我们吃惊的看到，在条
件好的网络上进行地测试表明，一些SSL VPN会改善VoIP呼叫的通话质量，我们重新进行了测试，依然
是这个结果。语音呼叫质量改善了将近20%。在我们分析其中原因时，发现当数据包穿越好的网络环境
时，TCP会通过重组和转发数据包来改善语音呼叫的通话质量。
每一个测试案例中，当宽带网络的环境很好时，在SSL VPN上传输VoIP，其通话质量都可以得到改
善。所以作为结果，给VoIP呼叫封装SSL可以让它得到更好的结构，这就像是在法国布里白乳酪外面加
上一层好的包装一样。我们并没有计算在500Kbps宽带连接环境下和VoIP所要求的64Kbps带宽之间，
其通话质量到底有多大的不同。宽带连接的速度太快了，TCP可以修复损伤而不会减少通话质量。
然而，并不是所有的SSL VPN会在客户端上利用TCP协议进行SSL的封装。Nortel在TCP上加密TCP流
量，却在UDP上加密UDP流量。Juniper的客户端利用ESP(Encapsulating Security Protocol)来
传输IPSec数据，其服务非常类似于UDP。在对于TCP和UDP流量时，这是一个可选的选项，假如客户端
第一次尝试利用ESP传输数据失败时，将会退回到标准的在TCP上利用SSL封装来传输数据。
我们利用TCP和ESP协议测试了Juniper的产品，因为它们可以受到网络管理员的控制。我们预测利用
TCP协议传输VoIP的效果会比利用数据报服务之类的UDP和ESP协议传输的效果会差一些。因为TCP对于
数据包的重发，会干扰语音质量。我们的测试结果显示，在一个好的网络环境下，Nortel和Juniper公
司的产品利用数据报服务传输VoIP的语音质量会低于利用TCP传输15%。这个语音质量测试结果和在未
加密的网络上语音传输效果相比差不多。
在我们所有测试结果中发现的好消息是，当我们设置一个比较坏的网络环境时，再次上演了在宽带服
务测试中的场景。在这个测试中，TCP再次拯救了VoIP通话质量。在所有参测的SSL VPN厂商中，有3家
厂商的产品改善了不可接受的呼叫质量，提高后的呼叫质量足以可以被人接受。在测试中，我们发现大
概有45~50%的语音质量改善。对于期望在SSL VPN上部署VoIP的网络管理者来说，在条件比较坏的宽
带网络上传输语音其语音质量是可以接受的。
我们的最后一个测试，是在条件坏、网速慢的网络上，看一下测试结果。在测试结果中，像利用ESP
协议进行传输数据之类的厂商如F5、Nortel、SonicWall和Juniper，其在条件比较坏的网络上传输
语音的质量也非常不好。由于网络条件坏和网速慢的不利条件和VoIP的相互影响，导致了非常不好的测
试结果。
网络管理者们希望在最好的网络环境中利用SSL VPN进行VoIP服务。对于家庭用户来说，他们有非常
高质量的宽带网络连接，而对于大部分旅行者来说，SSL VPN则可以给他们一个很好的体验。我们这次
测试仅仅关注于SSL VPN的远程接入的语音呼叫质量。我们的测试结果并不能帮助你区分产品的好坏。
我们的测试只是显示了VoIP和SSL VPN可以良好的共存。
语音质量测试指标介绍
通常来说，电话中的语音质量测试，非常含糊不清，但近年来在VoIP和移动通信领域，语音质量测试
变得令人关注起来。ITU（International Telecommution Union）已经出台了VoIP的标准测试，
起初在电话和电信技术领域非常知名的是ICC（International ConsulativeCommittee。
最初的ITU标准是P.800，它是针对语音质量测试的。这个测试标准要求有一个判断面板来监听语音呼
叫并且基于一套详细的标准来给语音呼叫打分。用单个数字来代表所打的分数，这种方法就叫做用户平
均意见得分（Mean Opinion Scores-MOS），比较典型的值范围是1~5。进行MOS测试是非常昂贵和耗
时的。幸运的是，ITU注意到测试需要一种更有效和可重复地方法来测试语音质量，并且这种测试必须
是可以自动的。
可感知语音质量（PESQ）代表了一种复杂的，并且是客观的测试方法，测试结果非常类似于MOS。
PESQ可以根据一些感知标准来客观地评价语音信号的质量，从而提供可以完全量化的语音质量衡量方
法，而这些衡量标准又是与人类对语音质量的感受完全吻合的。
一系列定义好的参数，如其中包括级别和时间校准对齐，输入过滤，感知模型，均衡和扰乱处理。通
过以上定义所测试出的结果，称作PESQ-LQO（Listening Quality,Objextive)测试。ITU有好几次
试图使PESQ的分数和MOS值得到匹配。在我们的测试中，我们使用了ITU 建议标准P.862.1来报告
PESQ-LQO分数，这是因为PESQ-LQO与我们惯常使用的MOS值匹配非常紧密。
所有3种分数实际上衡量的是同一个事物，然而他们的比例范围非常不同。这就意味着假如我们利用不
同版本的测试方法来衡量测试结果是不可能的。
确切理解MOS代表的确切意思是另外一个大麻烦，尽管显而易见的是分数越高越好，我们试图确定语
音呼叫质量什么时候是从可接受的变化到不可接受的是另外一个麻烦。一个正常的模拟或者数字话机的
MOS值是4.2~4.4。一个典型的蜂窝话机的MOS值范围是3.0~3.7，而一个通话质量差的蜂窝手机其得分
值低于2。另外一个ITU所描述的语音质量得分评定系统是感知分析测量系统法（PAMS）。PAMS是一个
“listening opinion”测试，它与PESQ存在很大的不同，PESQ是一个“conversation
opinion”测试。PAMS尝试测试收听的质量（和PESQ的尺度范围一样）和收听能力。PAMS特定寻找引
入的语音信道的错误是如何影响收听质量和收听能力的。
测试语音质量的另外一种方法是PSQM（感知语音质量测试）。PSQM用来评估语音数据编码，而不是一
个完全的语音连接行为。PSQM也经常被引用。而PSQM的值范围是0（极好）~6.5（差)，所以我们要重
新调节PSQM值来匹配PESQ值的范围。
在我们的测试中，我们生成了以上所有形式的分数
测试方法
我们此次利用了GL通信公司的硬件和软件还有Shunra软件来测试SSL VPN上VoIP的通话质量
GL通信公司语音质量测试（VQT）工具套件可以评估VoIP呼叫的质量。VoIP呼叫一方是
Grandstream公司的SIP电话。GL通信公司的UTA(Universal Telephony Adapter)硬件作为一个手
持设备连接到SIP话机上，截取两个方向的音频流。
在VoIP呼叫的另一端是一个DELL笔记本电脑，在其上运行了开源软件 X-Lite和SJPhone SIP软电
话软件程序包。我们使用了Griffin公司的iMic产品作为电脑的line-level音频输入和输出（因为
DELL 电脑仅仅只有一个mic级别的音频输入），同时连接到GL通信公司的UTA上。
以上设置可以让GL通信公司的VQT软件来运行“硬”SIP电话里的音频文件，并且在软电话那端接收
VoIP连接通路上的音频文件。GL通信公司VQT软件会使用ITU标准来评估语音通话的质量。我们使用
ITU G.711 u-law来压缩解码所有的呼叫。G.711 u-law压缩解码标准在美国是最为流行，它要求
64Kbps的带宽数据路径。
我们从GL通信公司的样例库中选取了一组6个，8秒的音频样例文件，在VoIP呼叫路径的两个方向上来
发送这些文件，从而生成了语音呼叫质量的数值。通过重复这个测试10次可让我们的测试数据与正常数
值相比有超过1%的偏差。
下一步，我们利用Shunra的虚拟企业网络软件来模拟向VoIP网络中引入延迟、带宽限制和网络丢
包。我们给这个软件设置了4个配置文件来进行测试。第一个配置是以太网在”无延迟，无丢包”情况下
测试出VoIP在有无SSL VPN链路上传输的效果。
下一个测试设置是代表了用户从一个地方旅游到另一个地方的宽带连接体验。我们限制到了0.5Mbps
的带宽。这代表了好的宽带连接，我们依据全美国的T-Mobile热点和有线宽带设施所收集来的网络实际
情况数据来进行设置。T-Mobile的数据传输质量是相当不错的，我们得到了相当稳定测试结果--接近
于0%的包丢失率（甚至是在无线中），从我们在亚利桑那州的数据中心到宽带网络的来回线路延迟是90
毫秒。我们也测试出了T-Mobile网络往返线路抖动时20毫秒。我们用这些测量值在Shunra软件中模拟
设置了“好的宽带连接”。
在第三个测试设置代表了“平均宽带连接情况”。我们依据从美国，亚洲、欧洲和加勒比海的几个饭
店中的以太网接口和无线热点连接中得来的网络情况来进行设置。这些网络连接具有高延迟和丢包的特
点，并且达到了2%的丢包（无论是有线或者无线），此外，到图森（美国亚利桑那州南部城市）的往返
延迟为120毫秒。抖动测试是40毫秒。
最后，我们创造了第四个测试设置。这种测试代表了极坏的网络连接环境：丢包率2%、120毫秒的往
返延迟和40毫秒的抖动，带宽为100Kbps。
对于每款SSL VPN设备，我们都在软电话客户端和SSL VPN设备之间设置了Shunra，SSL VPN设备通
过以太网连接到硬电话和我们剩余VoIP网络上。
然后我们在以上介绍的每个网络环境设置下运行GL通信测试（在每个方向上都接受或者发送6个语音
测试样例文件）10次，去掉一个最高分，去掉一个最低分，然后算出每个网络配置环境下的每款SSL
VPN设备的最终得分。
下面为图形化测试结果：
图表说明：
图表中的4条垂线代表了分别在每种网络情况下，没有SSL VPN时所测试出的VoIP传输性能。在垂直
线右侧的数据点代表性能有所改善，在垂直线左侧的数据点代表性能值有所下降。
代表条件为bad/slow的网络环境--0.1Mbps网络速度，60毫秒的延迟，20毫秒的抖动，2%的丢包率，
1%的包失序，1%复制包，每20秒出现网络拥塞从而发生30%的丢包率和1000毫秒的延迟。
代表条件为bad的网络环境--0.5Mbps网络速度，60毫秒的延迟，20毫秒的抖动，2%的丢包率，1%的包
失序，1%复制包，每20秒出现网络拥塞从而发生30%的丢包率和1000毫秒的延迟。
代表条件为good的网络环境--0.5Mbps网络速度，45毫秒的延迟，10毫秒的抖动，0.25%的丢包率，
1%的包失序，1%的复制包并且没有网络拥塞现象的发生。
代表无损伤的网络--100Mbps网络速度，没有延迟，丢包，缺陷和网络拥塞。 |
