IAD - AG故障排除手册--数据业务处理分册 - 图文

IAD/AG故障排除手册--数据业务故障分册

文档版本历史 文档版本号 V1.0.0 V1.0.1

编辑时间 2014-03-04 2014-03-06 编者 施文钊 施文钊 备注 初始版本 增加pos刷卡故障示例 第1章 数据故障排除

本章介绍了传真故障排除的基本思路，以及分析、处理的常用方法和使用命令等。 本章内容

? ? ?

数据业务故障排除基本思路 数据业务故障排除基本方法 传真常见故障处理

1.1 数据业务故障排除基本思路

传真故障分析基本思路：排除问题之前确认设备上配置，不会影响到当前的数据业务，在基本业务运行正常的情况，利用debug、封包等信息定位分析问题。 分析步骤一：

通过wireshark工具以及设备提供的debug调试信息，分析确认信令交互流程。

分析步骤二：

通过wireshark工具分析媒体流的状态包括打包时间、是否存在丢包、媒体编码等信息。 分析步骤三：

通过cooledit工具分析交互的各种tone音，解析声音的属性包括能量、频率、占空比以及声音的质量包括回声、是否存在断续等

1.2 传真故障排除基本方法

1、通过信令的交互确认传真数据开始交互在封包中的位置(以SIP协议为例 ACK消息之后为真实的传真数据)

2、过滤出rtp媒体信息，选择一个方向的媒体流，同时通过wireshark提供的rtp分析工具对媒体流进行解析

3、通过解析的界面，点击\保存媒体负载信息，在该界面可以查看媒体流是否存在丢包等信息

4、在弹出的界面中，选择保存声音的类型，同样的方式保存另一方向的声音

5、通过音频解析工具cooledit打开保存的声音文件，通过软件自带的音频分析工具分析声音的属性 频率、能量、占空等信息

6、通过查看波形/光谱切换按钮，来查看声音的能量分布，通过能量分布图可以很直观的分析出信号的交互过程以及是否存在回声

故障三：编码不一致导致传真失败

原因： 通话的首选编码与设备传真模式默认首选编码不一致导致传真失败 故障现象：发送传真正常，无法接受传真

设备封包提示信息： 服务端->设备: 服务端要求媒体的首选编码为 g711u

设备端->服务端: 设备端应答首选编码为 g711u

信令协商成功后，开始传真时候实际交互的编码信息,与协商的编码不一致。

原因分析： 通过封包信息分析，传真过程中媒体流同时存在711a和711u，对于语音通话，设备端支持语音编码自动协商，因此双方可以正常通话，但是由于系统架构原因,传真默认选择g711a编码，需要强制修改编码。

处理措施： 设备上启用强制线路编码 voip dsp line-pcm-codec ulaw

故障四：打包时间不一致导致传真失败

原因： 打包时间不一致，导致传真失败 故障现象：语音通话正常，传真失败

设备封包提示信息： 语音通话协商打包时间为20ms、传真协商打包时长为10ms，由于设备端打包时间设置未生效，导致传真失败 接收端->发送端：作为传真接收方主动发送invite进行传真信令协商，数据类型a=fax，打包时长为ptime=20ms

发送端->接收端: 设备端应答，200OK中携带a=fax，并且打包时长为 ptime=10ms

接收端->发送端：数据交互过程实际打包时长 10ms

发送端->接收端：数据交互过程实际打包时长 20ms

原因分析： 通过封包信息分析， 语音通话打包时长协商为ptime=20ms，通话双方打包时长一致通话正常；传真时候打包时长协商为10ms，而设备端仍然以20ms发送，

导致传真失败。

处理措施： 新版本上支持ptime时间自动协商。

故障五：传真模式不一致导致传真失败

原因： 传真模式不一致(服务端T38、设备端T30)导致传真失败 故障现象：发送传真正常，无法接受传真

设备封包提示信息： 服务端->设备: 服务端要求传真模式为T.38

设备端->服务端: 设备端应答，只支持传真T.30

服务端->设备端：二次协商要求用T.30进行传真

设备端->服务端：设备端应答(不支持二次协商，直接用对端200OK中的SDP字段进行回复)

设备端->服务端：设备端主动挂掉

原因分析： 通过封包信息分析，外线呼入的时候，平台要求设备端选择T.38模式进行传真，由于设备配置成T.30模式，因此以T.30模式进行应答，传真模式不一致，平台下方消息进行二次协商，由于设备端不支持二次协商，所有协商完成后设备端主动挂断

处理措施： 设备端修改传真模式为T.38或者平台修改传真模式

故障六：传真扩展参数问题导致传真失败

原因： 设备端不支持传真携带字段(a=fax/modem)，导致传真失败 故障现象：信令协商阶段服务端主动发送bye消息中断传真

设备封包提示信息： 服务端->设备: 对端作为传真接收方，按下传真键后，主动发送invite消息并携带a=modem字段(高速数据业务)

设备端->服务端: 设备端应答，200OK中未携带相关字段

服务端->设备端：服务端主动发送bye中断传真业务

原因分析： 通过封包信息分析，对端传真机按下传真键之后，主动发送invite消息(a=modem)告知当前的业务为高速数据业务，而设备端应答的200 OK中为携带数据类型字段，导致传真被中断。设备端应该以当前传真机支持的业务进行应答a=数据类型，(高速：modem；低速：fax)，

处理措施： 启用命令，在传真信令协商的消息中增加a=fax/modem支持 voip sip x-param x-fax x-modem

备注： 为了将G.711方式下的语音和传真区别开来，将媒体参数的属性进行扩展，增加属性，a=fax，表面此时为传真业务，a=modem，表明此时为modem业务 参考来源：扩展字段说明，中国电信基于SIP的传真业务实现规范.pdf

1.4 POS常见故障处理示例

故障一：阻抗不匹配导致POS刷卡失败

原因：阻抗导致POS刷卡失败

故障现象：刷卡(查询)成功，刷卡过程中pos显示\正在连接中\时间比较长 设备封包提示信息： pos端的媒体解析

原因分析： 通过解析封包信息，pos信号中存在回声现象，由于pos业务设备端需要关闭EC配置，所以当阻抗不匹配产生的回声无法消除,干扰到pos刷卡。 处理措施： 确认设备端阻抗配置

备注说明： 数据业务包括低速数据业务(传真)和高速数据业务(高速传真、pos业务等)，针对高速数据业务必须关闭设备端的EC/VAD/CNG等可能对原始信号产生影响的功

能，对低速影响不大。

同类问题举例： 原因：阻抗不匹配

故障现象：POS机刷卡后出现，连接服务器失败或连接服务器后读卡失败 故障排除： 分析pos交互的媒体信息，确认存在回声现象。

故障二：EC配置导致POS刷卡失败

原因：EC配置导致POS刷卡失败 故障现象：刷卡失败

设备封包提示信息： pos端的媒体解析

现象一：pos数据不连续出现丢失,pos刷卡失败设备端的媒体信息

现象二：pos刷卡正常封包

原因分析： 通过解析封包信息，可以查看pos机的数据经过设备之后，数据中断不连续，具体原因是由于设备上EC处于启用状态，导致部分数据被设备的DSP视为回声消

除导致数据丢失，pos刷卡失败

处理措施： 对于pos业务，需要启用检测ip端tone开关

AIM> voip dsp vbd tdm-ip-auto //启用ip端tone检测开关，设备检测到ip侧的tone，DSP会自动关闭ec配置 备注说明：

1、高速传真机和高速modem在开始传真和modem时候都会上报带相位翻转的2100HZ信号，区别是传真后续还会上报V21 Flag信号，改参数的作用在于检测到带相位翻转的2100HZ信号时候启用一个定时器，如果在定时器超时前再受到V21Flag信号，则认为是传真，如果超时则上报modem。定时器建议 10s，如图示

2、数据业务包括低速数据业务(传真)和高速数据业务(高速传真、pos业务等)，针对高速数据业务必须关闭设备端的EC/VAD/CNG等可能对原始信号产生影响的功能，对低速影响不大。

3、pos交互流程说明：

a、pos刷卡的时候设备端向平台发送发起呼叫(sip/mgcp/h248，基本呼叫流程)

b、平台接通后，在媒体通道开始pos数据交互(由于pos数据为高速的数据，所以在pos数据交换之前，需要发送一个带相位翻转的2100HZ的信号，设备检测到该信号后需要关闭EC/VAD/CNG等可能影响到信号的功能)

c、平台接通后，pos信令交互流程

本文来源：https://www.bwwdw.com/article/o5zg.html