【运维小能手】光猫接入IMS传真故障

嘟嘟飞 Moderator VIP

(1)
5 years 7 months ago View: 8378 Reply: 14

1F
View The Author

【案例摘要】

某某社区2个IMS电话，设备为XXX下挂F822,无法正常接收联通传真。

1、问题描述

某某社区2个IMS电话，设备为XXX下挂F822，收发电信号码传真正常，发送联通号码正常，但无法接收联通号码的传真。故障不定期出现。

2、原因分析

根据故障现象，首先考虑接入设备ONU的冗余和增益，更改参数后，仍无法接收联通传真。

其次排查网络侧原因。在中兴F822上ping F822的网关。Ping 1500大小的包，ping包无丢包，延时都在1ms内。最大抖动为7ms，平均抖动0ms。证明F822至网关网络正常。

在核心IMS测媒体包，ONU找不到BAC的媒体地址11.0.20.241，判断ONU至BAC的媒体面有异常。

最后我们找传真机进行接收测试，联系用户配合，核心IMS侧和接入侧同时抓包跟踪。当给联通某用户（号码：XXXXXXX）发送传真的时候，发送4次传真，有3次失败，1次正常。

3、问题定位

对于传真发送失败的原因通过分析抓包消息可以看到，每次发送传真:当信令接通后，语音媒体用的PCMA编码，当开始发传真的时候，两端协商为PCMU编码。

传真发送成功时：两端的媒体编码格式都切换为PCMU率。
传真发送失败时：本端已经将编码格式切换为PCMU了，但是对端仍然用语音态的PCMA编码。

此附件为传真无法发送的情况：

4、问题分析

根据核心网侧的反馈的配置，传真的SDP配置了RTP 8，Modem SDP配置了RTP0 8（在RTP协议中，RTP 0对应的为PCMU编码格式，RTP8对应的是PCMA编码格式）。

但是分析现场抓包结果，在H248信令中，calltyp=DATA，表示该传真走的是高速传真，用的是Modem SDP，

现场抓包的时候，发现IMS平台给下发的媒体协商信令中，为RTP 0 8。即PCMU编码优先。

所以在媒体编码格式协商过程中，和对端联通号码协商为PCMU律进行对话。但是对端未切换为PCMU律，一直还用语音态的PCMA律发送信息。导致传真发送失败。

5、问题解决及处理过程

中兴工程师再此到达用户现场，联系核心网同事，在IMS侧新建一个模板。该模板中传真SDP和Modem SDP都只设置RTP 8。既只使用PCMA编码格式进行传真。

现场测试和联通号码（XXXXXXX）互发传真，都没问题。RTP一直使用PCMA编码格式通信。为避免其他局只使用PCMU律进行传真，让核心网同事更换RTP的编码优先级，将PCMA律设置为优先，现场测试正常。故障恢复正常。

鉴于PCMA应用范围较广，核心网IMS的同事对全省范围内，所有modem SDP的编码优先级做了调整，调整后以PCMA编码优先，PCMU编码其次。

6、经验总结

针对这次传真故障，使我们熟知了G.711A（PCMA）和G.711U（PCMU）两种编码。当媒体编码格式有问题的时候，我们还可以通过修改该号码的编码格式优先级方法来尝试解决。具有很好的借鉴意义。

其实，我们在处理语音类故障时，都会使用抓包工具，所以我们需要加强数据包分析等方面的学习，提高自身维护技能，可以更快的定位故障，解决故障。