这个呼叫中心的客户我接触比较晚,去测试的时候需求已经很明确,把Avaya IPSoftPhone的语音通过XD的ICA通道传输,测试我们的解决方案能够节省多少带宽资源。
去现场之前做了些功课,仔细拜读了论坛里的大作:http://community.citrix.com/display/ocb/2010/01/07/Delivering+VoIP+apps+with+XenDesktop+4
看到新的XD Codec能够使Voice on ICA减少到40Kbps以内,相当的自信,仿佛看见大单在向我们挥手。
测试的结果:
使用HDX Monitor在缺省配置下语音通话时的双向流量是210Kbps,配置为”Optimize for Speech”(推荐的配置)时是60Kbps,配置为最差音质时是36Kbps。这是个相当振奋人心的结果,因为Avaya传统方式双向流量是171Kbps,我们新的Codec可以只有三分之一的带宽!
然而问题来了,客户使用Wireshark做了并行测试,没有语音通话时是10Kbps左右(很不错的结果),语音在三种策略下分别是:290Kbps,260Kbps和210Kbps!以”Optimize for Speech”选项为例差别是60Kbps VS. 260Kbps,而且无论哪个配置,都比传统方式大很多,也就是说我们的方案根本无法降低语音通话对带宽的占用。
于是赶紧向Tech Support求助,等了好几天说HDX Monitor不属于Support范围,但是我们发现HDX Monitor只是个展示工具,真正的数据来自Windows Performance Monitor里面ICA Session Counter,这个数据就和Wireshark的值相差很远。到现在还没有一个明确的答复。
倒是客户帮我们进行了猜测,是不是我们的ICA Session Counter里面Voice部分只计算了语音包本身的大小,而对于其在网络里面传输时的TCP包头,协议其他的封装数据统统没有计算在内?如果确实是这个原因,那么40Kbps以内的说法是让Voice在TCP/IP网络上裸奔了。
冷静了想想Avaya做语音这么多年,使用的是UDP协议才能把带宽控制在171Kbps,我们的ICA用的是TCP协议没有理由能把带宽降下来啊。
在别的客户处也做了类似测试,结果在35KB左右,这个值和我们的260Kbps也比较接近。这个问题一直没有解决,还不断在各种资料中看到关于新的Codec能让流量降到36Kbps左右,哎,难道就一直这样裸奔下去?