OmniPeek 之VoIP分析之胡炯宇 原创
杭州-上海 VoIP 故障分析报告
今日接报“杭州到上海的VoIP通讯发生了故障” 据杭州用户反映，杭州的用户拨叫上海的用户成功以后，正在正常通话时，通话忽然被中断。双方被迫进行第二次呼叫。但是上海的用户却没有抱怨这样的状况。
接到用户投诉后，立刻连接到我们的Infinistream系统。调取从AM9：45 - AM10：15分的杭州和上海两地的网络通讯的原始记录，进行还原和分析。经统计在这半个小时之内，总共有19次呼叫，这些呼叫发生时，网络的丢包率为0，MOS（语音通讯质量评估0-5）为3.76.属于中上水平。
这个时间段的jitter 峰值在160左右，对语音质量还是有一定的影响。但不是造成通话中断的原因。
在重构出19路对话以后，出乎意料的是我发现我们做的出现故障的两路测试电话，在专家系统里面居然是被正常关闭的。从表面上看不出明显的异常。
只能对通话进行进一步分析比对，其中非常重要的就是对Flow信息的分析，以查看VoIP通讯中，信令和语音数据流的行为是否会有异常。
经过比对，我们发现出现故障的通话中都会出现这样的情况：
如上图所示（蓝色箭头所标识），我们可以看到杭州和上海的两台PABX向对方发出了RoundTripDelayRequest的请求，但只有上海向杭州做出了响应，然后在上海PABX连续第5次没有收到杭州PABX的响应后，上海PABX自动发出终止通话的指令（endSessionCommand），然后对话结束。在这些故障通话的初期，杭州PABX也能正常的做出响应，出现这种故障在时间分布上是随机的。所以据此判断。
1 杭州PABX没有收到上海PABX的RoundTripDelayRequest，所以杭州PABX不做响应，如果是出现这种错误，那么我们判断是网络无法正常的投递数据包造成的，属于网络故障
2 杭州的PABX收到了上海的PABX的RoundTripDelayRequest，但杭州PABX没有发出响应的数据包，如果是这种情况，我们倾向于PABX设备故障。
为了更细化我们的判断，我们在杭州的语音交换机上（2950）对PABX的口进行网路抓包分析，经比对我们没有发现杭州PABX收到了上海的RoundTripDelayRequest，但没有做出回应。所以我们现在定位故障出在PABX上。
请检查PABX里面的系统设置，看看系统内设置的RoundTripDelayRequest发送的间隔是不是和上海这边匹配（杭州为10秒发一次），如果可以的话，更换一块电话板，看看做个替代测试，更进一步的来定位故障，从而解决故障
10月11日，在更换过PABX的IP板之后，再次进行了测试，通过半个小时的测试电话，测试电话表现正常。同时截取了所有的杭州到上海的通讯，经过omnipeek分析后，通过对flow的分析，看到杭州的RoundTripDelayRepsonse发送正常。从而确定故障为PABX设备的硬件问题所导致的。
总结，VoIP通讯流量分为两个部分，一个部分是信令，它负责建立呼叫，维持通话，以及终结呼叫，通常信令部分是由TCP来承载的，另外一部分是语音数据流，是由UDP来承载的。它由RTP和RTCP构成，RTP承载了语音，而RTCP是负责评估RTP传输质量的。omnipeek针对语音的三项比较主要的指标，packets loss，jitter，delay主要是从RTCP的report里得来的。
如果您碰到了语音质量的问题，比如说通话断断续续，声音有延时，或者忽然听不到对方的声音，那一般都是传输上的问题，检查带宽的链路利用率，线路延时，以及丢包率，
如果您碰到的是忽然通话终止，或者呼叫不成功，或者挂不断电话这种问题，应该着手检查信令方面的问题，检查TCP的三次握手，以及TCP是否被正常终结等等
[ 本帖最后由 hujiongyu 于 2008-9-8 21:33 编辑 ]
附件: 您所在的用户组无法下载或查看附件
