传真智能公话POS机故障处理手册

1、传真、智能公话、pos机故障处理手册传真、智能公话、pos机业务在传统的pstn属于数据业务，利用传统模拟线路将数据封装在语音流进行传输。在光进铜退的演变过程中，这些传统的数据业务依然沿用老的传输方式，而在语音已经实现voip后，原本简单易行的这些业务故障频出，而且经过多次数模转换，给问题的定位解决也带来诸多困难。本宝典目的在于对各位解决此类问题带来帮助，并且将逐步完善。这些数据业务具有共同的特征，在终端设备上都有一个调制解调器，将传输的数据调制后经过电话线传输，接入到我们的onu(ont)，进行采样后打成rtp包发到媒体服务器，对端再进行逆向过程，如下图：铜线传真机调制解调器智能公话调制解调

2、器pos机调制解调器onu(ont)rtp流从上图可以看出，虽然传真机、智能公话、pos机表现出来的形式各异，但其工作原理相同，所以处理这些问题也具有共同性。罪魁祸首之一丢包在voip网络中，丢包对于数据业务的影响，相当于传统铜线的老化，会让你不知道究竟问题出在哪，而最终可能会对整个网络进行整理。对于此种故障，首先就要判断是否存在丢包，少量的丢包对普通语音业务不会造成影响，但对于数据业务的影响却是致命的。症状轻微的只是偶尔失败，严重的讲导致此类业务无法使用。对于丢包的危害，大家已经共知，下面将给大家介绍判断丢包的方法。在判断丢包以及后续的介绍中，我们将大量使用抓包工具wireshake（老版本

3、名字为ethereal），使用软件版本的不同，将会出现有些菜单的位置不同。rtp流判断丢包通过rtp的统计来判断丢包是最简单的，我们通过wireshake打开抓包时，如下图：打开后在statistics->rtp->show all streams，如下图：点击打开如下窗口：图中红圈内的数字就表示丢包的统计。为了和后面的rtp流序列号反转进行比较，将该rtp就行分析：解析如下：找到丢包的位置：也可以点击status查看所有丢包的位置：按status排序后如下：出现丢包的位置随机，每次丢包一般都只有几个。使用rtp流判断丢包情况最简单直接，但存在以下三种障碍：1. 抓到的包没有rtp

4、流，首先确定抓包未进行过滤，如果抓到的包是下面的情况：这种情况是抓的包不包含信令(h.248,sip or mgcp)，导致wireshake不认识这些包，我们可以强制转换为rtp包，操作步骤如下：右键单击udp报文出现如下菜单：点击decode as在下面的列表中选择rtp：经过强制解析后，就可以看到我们亲切的rtp流了。如下：2. 可能存在序列号反转。当从rtp流统计信息看到存在丢包时，可能是假象，比如下面这种：一看有34.9%的丢包，居然还是负的，可能会误判断为丢包，但实际上并不是丢包，可以将该rtp流解析出来，在上图中，选中rtp流，点击下面一排菜单中的“analyze”，如下：解析出

5、来如下：找到丢包的起始位置：看到途中红圈位置所示，从序号为420的包到序号为423的包，sequence号从32349跳回到32143，而我们从rtp的时间戳来看，这两个包又是连续的，如下：红圈标记time=xxxxxxxxx为rtp流的时间戳，每隔10毫秒，该时间戳增加80，上面两个包时间间隔为约40毫秒，而两个时间戳正好相隔320，所以可以判断这两个包之间并不存在丢包，只是序列号反转，不会影响到业务。和上面rtp流判断丢包进行对比，序列号反转只有一次，而丢包是随机的分散在不同位置，而且序列号和时间戳同时发生不连续的变化。3. 只能判断我们设备收包的情况。现在所有的数据都是从我们的设备侧捕获

6、的，所以通过rtp的序列号只能看到我们收包的情况，而发送的rtp很多时候无法看出来。所以我们可以通过rtcp来查看丢包情况。rtcp判断丢包当通过rtp流判断没有丢包，并不代表整个网络没有丢包，比如下面这种情况：接收的rtp显示有丢包，但按上面的判断方法，可以得知造成丢包假象的原因是序列号乱序，所以认为上面通过rtp显示是没有丢包的。目前我们的抓包都是在我们设备侧进行，rtp流统计的丢包只能显示接收方向的情况，而发送的rtp是否能顺利到达目的，在我们设备侧抓包是无法看得到的。还好前人已经遇到同样的问题，定义了rtcp协议，rtcp就是rtp的控制协议，其中有一部分就是反应收包的情况。在通话过程

7、中，收发双方会定时发送rtcp包，相对端“汇报”自己的收包情况，同样是上面的这个包，我们过滤接收的rtcp如下：完全展开一个rtcp的sender report如下：其中红线中标示的fraction lost和cumulative number of packets lost就是表示对方接收的rtp是否有丢失，fraction lost是两次rtcp之间的丢包率，分母是256，cumulative number of packets lost是整个通话过程中的丢包累计。但有些设备对这两个值的定义不一定准确，比如上面看到的这个包，fraction lost显示有丢包，但cumulative nu

8、mber of packets lost始终为0。所以我们在查看rtcp包时，只要这两个值的任何一个值不为0，都可以说明发出去的rtp没有全部到达对端。罪魁祸首之二回声在传统的pstn网络，交换机侧都会有专门的设备来做回声消除，而在voip网络中，回声消除都分散在媒体网关上，我们的onu设备在一定程度上来说也就是媒体网关。在说到回声抑制功能，就不得不提nlp非线性处理，nlp是回声抑制功能的一个子模块，从名字就可以看到nlp的含义。正常人说话的声音都是抑扬顿挫，跌宕起伏的，不可能是固定在某一个频率，也就是说不可能是线性的信号，为了更好的防止回声和拖音现象，dsp芯片在回声消除以后，再判断声音是

9、否是线性的，如果是线性的信号则简单的一刀切掉。nlp和回声抑制功能的关系如下图：回声抑制功能是为了改善通话效果，而对于数据业务则会造成致命的影响，但是否关闭回声就能一劳永逸了？当然没这么简单。那什么时候开，什么时候关了？我也不知道。一般的原则是，接低速设备，打开回声抑制；接高速设备，关闭回声抑制。接任何设备都要关闭nlp。高速设备需要关闭回声抑制功能，并不是说不需要消除回声了，而是在高速设备上，本身具有了回声抑制功能，我们的onu就不要开启回声抑制了。目前我们的onu都已经做了自适应，根据接的不同设备，自动做了回声抑制的开关控制。下面介绍几个案例分析，以增进大家的理解。案例一：汉中pos机问题

10、在介绍汉中pos机问题过程中，给大家引荐一个工具软件的使用，cooledit，对于我们处理语音的工程问题作用非常大。使用cooledit之前先要将rtp还原为声音，先使用wireshake打开抓包文件，解析出rtp流如下图：点击需要的rtp流，然后再点击下面的analyze（红圈标记）：点击之后如下图：上面的rtp stream analysis窗口比较”含羞”，一般在点击analyze按钮之后会出进度条，进度条显示完成之后却看不到这个窗口，是因为他跳到后面去了，需要再把它点出来。点击save payload之后出现如下窗口：在这个窗口中，我们需要选择存放文件夹和文件名称，文件格式和语音通道方

11、向，这里主要讲一下后面两个参数。文件格式(format)如下红线标示：可以有raw和au两种选择，raw是简单的将rtp的静荷拼接起来，au是可以直接使用播放器进行播放的格式。我们一般选择au格式。语音通道方向如下图： 可以选择forward(前向),reversed(反向),both(双向)三种情况，可以简单的视为左右声道和双声道，为了分析问题方便，我们都只选择单声道，也就是forward。在slection输入文件名，点击ok就可以保持出声音文件：点击ok后同样会出现进度条，存储完成可以在选择的目录下找到还原的声音文件，这个声音文件就可以用cooledit打开进行查看。用cooledit打

12、开后如下：好，关于cooledit的简单介绍就到这里，以后有其他功能使用再介绍，现在言归正传到汉中pos机的问题。将汉中pos机发出去的rtp还原为声音文件，用cooledit打开如下：点击图中红圈标示的放大按钮，或者使用鼠标的滚轮，将声音文件放大后如下：从图中就可以清晰的看到，我们发出去的语音被切断，是因为前面介绍的nlp功能导致的，目前我们设备不提供nlp的开关配置，只能通过回声抑制开关配置来控制nlp，也就是关闭回声抑制，同时关闭nlp。目前软件可以做到自动识别pos号码，来对回声抑制、nlp进行开关控制。那就需要我们在设备上配置pos号码，目前大多数版本只能在onu本地配置，正在增加网

13、管配置项。此处的pos号码不是用户的号码，而是pos机拨出去的号码，一般是设置在pos机内部，可以询问pos机的接入号，或者通过抓包在信令中查看。案例二：湖南株洲传真问题湖南株洲龙兴桥15设备向湖边汉川发送传真失败，其他使用场景都正常，分析传真声音文件，此处省略将rtp还原为语音的过程。我们使用cooledit打开声音文件默认界面如上，一般称为波形图，分析回声时，我们一般切换到光谱图，点击下图中红色框内的按钮：切换到光谱图如下：图中红色部分为光谱，通过肉眼来看，亮度越高就是能量越大，简单来说就是声音越大，为了比较收发双方，我们需要打开两个cooledit窗口，分别打开收发双方的声音文件进行比较

14、：从上图蓝色圈内可以看出，我们收到的传真音被部分的回过去了，导致与对方的传真机协商失败。最终将回声抑制功能打开就能解决问题了。目前我们设备软件已经能够自动识别传真机是高速还是低速，来自动设置dsp的参数。当高速传真机和低速传真机对接时，高速传真机首先上报高速传真事件，然后再上报低速传真事件，最终以低速模式进行传输。而湖南的这个问题是因为，对方传真机先上报低速，再上报高速，最终以低速模式传输。而我们设备却判断为高速传真，误将回声功能关闭了。目前我们设备的处理办法是，只要上报了低速传真事件，肯定就以低速模式传输，只有在仅上报高速事件时，才以高速模式传输。影响因素三事件上报此类故障出现比较少，不算致

15、命的，而且很容易看出来。目前发现两种情况：一、北京电信mgcp工程，要求按rfc2833的标准传输传真事件，而且rfc2833的pt值为101，非我们设备普通使用的97，只需要将设备的2833pt修改为101就可以了。而且只需要我们接收2833的包，不要求我们发送，分析如下：二、汉中出现传真是上报信令，导致拆除通话，抓包如下：我们设备主动上报的cng事件，导致mgc播放忙音，传真失败。关闭传真事件上报即可解决问题。 蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂

16、螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃

17、螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃

18、袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁

19、袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂

20、袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃艿葿虿袅膂莄蚈羇莈芀蚇肀膀蕿蚇蝿羃蒅螆袁腿莁螅羄羂芇螄蚃膇膃螃袆羀薂螂羈芅蒈螁肀肈莄螁螀芄芀螀袂肆薈衿羅节蒄袈肇肅莀袇螇芀芆蒄罿肃节蒃肁莈薁蒂螁膁蒇蒁袃莇莃蒀羆膀艿蕿肈羂薇蕿螇膈蒃薈袀羁荿薇肂膆莅薆螂聿芁薅袄芄薀薄羆肇蒆薃聿芃莂蚃螈肆芈蚂袁芁膄蚁羃肄薃蚀螃