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

传真、智能公话、POS机故障处理手册 传真、智能公话、POS机业务在传统的PSTN属于数据业务，利用传统模拟线路将数据封装在语音流进行传输。在光进铜退的演变过程中，这些传统的数据业务依然沿用老的传输方式，而在语音已经实现VoIP后，原本简单易行的这些业务故障频出，而且经过多次数模转换，给问题的定位解决也带来诸多困难。本宝典目的在于对各位解决此类问题带来帮助，并且将逐步完善。 这些数据业务具有共同的特征，在终端设备上都有一个调制解调器，将传输的数据调制后经过电话线传输，接入到我们的ONU(ONT)，进行采样后打成RTP包发到媒体服务器，对端再进行逆向过程，如下图： 从上图可以看出，虽然传真机、智能公话、POS机表现出来的形式各异，但其工作原理相同，所以处理这些问题也具有共同性。 罪魁祸首之一——丢包 在VoIP网络中，丢包对于数据业务的影响，相当于传统铜线的老化，会让你不知道究竟问题出在哪，而最终可能会对整个网络进行整理。对于此种故障，首先就要判断是否存在丢包，少量的丢包对普通语音业务不会造成影响，但对于数据业务的影响却是致命的。症状轻微的只是偶尔失败，严重的讲导致此类业务无法使用。对于丢包的危害，大家已经共知，下面将给大家介绍判断丢包的方法。在判断丢包以及后续的介绍中，我们将大量使用抓包工具wireshake（老版本名字为ethereal），使用软件版本的不同，将会出现有些菜单的位置不同。 RTP流判断丢包 通过RTP的统计来判断丢包是最简单的，我们通过wireshake打开抓包时，如下图： 打开后在Statistics-RTP-Show All Streams，如下图： 点击打开如下窗口： 图中红圈内的数字就表示丢包的统计。 为了和后面的RTP流序列号反转进行比较，将该RTP就行分析： 解析如下： 找到丢包的位置： 也可以点击Status查看所有丢包的位置： 按Status排序后如下： 出现丢包的位置随机，每次丢包一般都只有几个。 使用RTP流判断丢包情况最简单直接，但存在以下三种障碍： 抓到的包没有RTP流，首先确定抓包未进行过滤，如果抓到的包是下面的情况： 这种情况是抓的包不包含信令(H.248,SIP or MGCP)，导致wireshake不认识这些包，我们可以强制转换为RTP包，操作步骤如下： 右键单击UDP报文出现如下菜单： 点击Decode As…在下面的列表中选择RTP： 经过强制解析后，就可以看到我们亲切的RTP流了。如下： 可能存在序列号反转。当从RTP流统计信息看到存在丢包时，可能是假象，比如下面这种： 一看有34.9%的丢包，居然还是负的，可能会误判断为丢包，但实际上并不是丢包，可以将该RTP流解析出来，在上图中，选中RTP流，点击下面一排菜单中的“Analyze”，如下： 解析出来如下： 找到丢包的起始位置： 看到途中红圈位置所示，从序号为420的包到序号为423的包，Sequence号从32349跳回到32143，而我们从RTP的时间戳来看，这两个包又是连续的，如下： 红圈标记Time=xxxxxxxxx为RTP流的时间戳，每隔10毫秒，该时间戳增加80，上面两个包时间间隔为约40毫秒，而两个时间戳正好相隔320，所以可以判断这两个包之间并不存在丢包，只是序列号反转，不会影响到业务。 和上面RTP流判断丢包进行对比，序列号反转只有一次，而丢包是随机的分散在不同位置，而且序列号和时间戳同时发生不连续的变化。 只能判断我们设备收包的情况。 现在所有的数据都是从我们的设备侧捕获的，所以通过RTP的序列号只能看到我们收包的情况，而发送的RTP很多时候无法看出来。所以我们可以通过RTCP来查看丢包情况。 RTCP判断丢包 当通过RTP流判断没有丢包，并不代表整个网络没有丢包，比如下面这种情况： 接收的RTP显示有丢包，但按上面的判断方法，可以得知造成丢包假象的原因是序列号乱序，所以认为上面通过RTP显示是没有丢包的。 目前我们的抓包都是在我们设备侧进行，RTP流统计的丢包只能显示接收方向的情况，而发送的RTP是否能顺利到达目的，在我们设备侧抓包是无法看得到的。还好前人已经遇到同样的问题，定义了RTCP协议，RTCP就是RTP的控制协议，其中有一部分就是反应收包的情况。在通话过程中，收发双方会定时发送RTCP包，相对端“汇报”自己的收包情况，同样是上面的这个包，我们过滤接收的RTCP如下： 完全展开一个RTCP的Sender Report如下： 其中红线中标示的Fraction lost和Cumulative number of packets lost就是表示对方接收的RTP是否有丢失，Fraction lost是两次RTCP之间的丢包率，分母是256，Cumulative number o