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