sip故障分析处理

5) 如果被叫摘机,呼叫马上释放,则极有可能是媒体协商没有完成,需要检查主被叫媒体

信息是否在可靠的信令中完成协商。通话中释放,可能是通话心跳检测出了问题。范例见下图:

范例1:支持媒体类型不匹配导致摘机后释放

37

范例2:通话维持中ippbx发出option,收不到对方发出的200ok响应,3秒超时收不到后,ippbx发bye结束通话。

6) 现场Wireshark抓包分析,UCS设备发送INVITE请求后,等待5S后没有收到平台返回的

183消息,UCS设备的IMP板就自动发送CANCEL拆线。

登录WEB网管查看【IPPBX管理】-【语音业务配置】-【系统信息表配置】中的系统等

38

待振铃时长设置为5S,修改为20S后,让其拨打测试正常。原因是拨打外地手机时,需要对方归属hlr给出漫游号码,拨打漫游号码后,基站要对手机发起寻呼,寻呼响应后,被叫提供回铃音,这个过程有可能大于5秒,系统设置等18x消息小于5秒会导致呼叫失败。同时,其他长途等等也可能回回铃音比较慢,所以要设置大一些。

7) 数图错误导致17909加外地手机号码无法拨出

抓包发现:

发现ippbx发出的invite消息发出的被叫号码只有1790901376468,号码不全,主叫等后续18x超时20秒后发408超时释放呼叫。查看iad数图配置如下:

39

修改数图里的1[34578]xxxxxxxxx为|1[3458]xxxxxxxxx,删掉里面的7后,观察拨测正常。

【反馈信息】

1)SIP信令跟踪消息和主被叫用户内部模块间接口跟踪消息

2)如果呼叫涉及其他协议类型的用户或中继,请同时提供该类型的信令跟踪

3.4 SIP呼叫语音视频单通或双不通类问题

【问题现象】

1)主叫用户可以听到看到被叫用户,但被叫用户无法听到看到主叫用户 2)主叫用户无法听到看到被叫用户,但被叫用户可以听到看到主叫用户 3)主叫用户无法听到看到被叫用户,且被叫用户无法听到看到主叫用户 【处理思路】

1) 终端之间的网络是否畅通,也就是RTP流是否可以顺利到达对方;IAD上行网口被配

置为半双工模式

2) RTP流编解码是否与主被叫协商成功的编解码一致 3) 双方RTP流打包时长是否一致

4) 终端是否接受远端采用不同端口收发的RTP流 5) RTP流的端口是否为偶数

6) 终端是否在通话过程中接受媒体改向后新的RTP流

7) 如果有SBC参与呼叫,则要考虑SBC是否能正确转发RTP流 【配置检查】

1)确保网络畅通,比如可以在两个终端上,互Ping 对端的IP地址测试;

2)在距离被叫侧用户终端最近的网络位置,使用wireshark等工具抓取被叫侧的RTP流 3)在距离主叫侧用户终端最近的网络位置,抓取主叫侧的RTP流,可以分析主叫用户采用的编解码的目的IP地址和端口、打包时长、是否接收到被叫语音流等信息 【反馈信息】

1) SIP信令跟踪消息和主被叫用户内部模块间接口跟踪消息

2) 如果呼叫涉及其他协议类型的用户或中继,请同时提供该协议的信令跟踪 3) 主被叫设备上,执行互Ping对方IP地址的结果

4) 采用Ethereal工具在分别距离主被叫物理位置最近的地方,抓取主被叫侧的RTP流 5) 分析的方法:从invite的sdp和被叫发的200ok的sdp的Connection Information (c):获

得ip地址,Media Description, name and address (m):获得端口地址。然后利用callid和udp.port进行过滤。

下面是一个双方无音的案例分析:

40

联系客服:779662525#qq.com(#替换为@)