近段有些朋友说UCS系统，常常丢包，导致语音不清晰。香港IDC机房也说自己的香港服务器网络带宽是足够大的，不可能出现丢包，有的甚至把带宽开到100M独享，还是出现丢包。
葵芳idc告诉你无线网络传输示意图是怎么样的
刚好碰到一个案例，客户也很愿意配合，香港机房愿意配合，我们就这个做一个深入的分析。该客户的情况是这样的，运行UCS系统并发开到200线并发，一切正常，超过500线，出现播放语音广告清楚，但是转坐席声音听不清楚，卡顿，查看CPU消息利用率不高，磁盘I/O也很低。我收到这个消息，看病望症，肯定是丢包引起。打开监控工具CDRVIEW
看到发包方出现10%~50%左右的丢包。UCS肯定不会引起丢包，他只是一个软交换，他负责语音流的转发而已。而且CPU与磁盘IO都不高，基本判断不是UCS问题，问题到底在哪？
发送丢包：1、从UCS对外发包丢失 2、对方上行到UCS的包丢失。 发送语音广告清楚，表示UCS对外发包是正常的，也就是对外发包是正常的。唯一可能就是TG对服务器丢包。
为了确认该问题，在丢包时我们通过第三方的服务器对TGping包，发现不丢，然后我们又通过第三方的服务器对UCS服务器进行ping包，发现也不丢包。
问题来了：既然都不丢包，难道就是UCS内部丢包？我们查了UCS内部的语音缓冲空闲的很，绝对不是UCS引起的丢包。
测试的过程发现一个小现象，当用ping时，加是-f 1000的参数时，服务器出现ping包全部丢失，这种情况一般是服务器位于防火墙内，防止ping攻击的。 既然ping会被卡死，语音也有可能被防火墙阻挡，语音如果走G729基本是一路是1秒100个包，500线，相当于每秒 5万个包，语音双向的，相当于，每秒10万个包，经过防火墙，防火墙有充足的理由认为这个是非法的网络流。
果断与机房取得联系后，让服务器绕过防火墙，CDRVIEW上面的丢包立即为０。 转坐席立即正常。由此也得出结论：所有经过的网络节点都是出现问题可能点。要排查问题必须想到所有的节点问题。