1、目录设备问题 .3一、呼叫转移故障处理技术案例 .3二、未知包引起语音断断续续故障处理 .5三、关于 07 型 ONU 出现的误摘挂机的情况说明 .5四、关于北京清河局 OLT2_4003 外层 VLAN 用户拨号 676 错误报告 .6五、同一个 PON 口下 15 型 ONU 上联 EUP2 盘引起其它 15ONU 传真的问题 .7六、modem 掉线问题的处理 .10七、07ONU 下接 MSAN 设备上网时延大处理 .10八、打包间隔不一致导致传真问题的处理方法 .11九、传真机模式错误导致传真失败问题处理 .12十、高科 iad 的 payload 值影响传真处理案例 .13十一、5
2、006-07 杂音问题处理案例 .15十二、5116-02 的 AC16 语音代理问题处理 .16十三、AN5006-03/04/09AONU 下挂 wlan 等设备未知包问题处理案例 .16十四、07B-ONU 传真问题 .18十五、AN5116-02 下挂 07ONU 催挂音超时处理问题 .22十六、930OLT 版本后 ONU 下挂 AG,DSLAM 等设备优先级注意问题 .26十七、payload 为特殊值导致传真故障处理案例 .28十八、用户拨号有时提示忙音处理案例 .29十九、IP 冲突导致语音不通处理案例 .30二十、外部电压不稳造成 AN5006-16 语音中断处理案例 .31
3、二十一、15ONU 设备语音业务被叫自动挂断故障案例 .32网管技术问题 .34一、ANM2000 在 Win2003 SP2 上运行间歇服务中断问题说明 .34二、网管配置过大导入不成功处理方法 .36三、网管内存过大导致数据库服务无法启动案例 .36四、AC16 上联用户信令数据配置无法读取故障处理 .37五、42SP1 网管无法对 ONU 端口进行业务配置问题处理 .37六、网管下 AC16 配置失败故障 .39七、客户端常报“数据库已修改”问题 .41八、计划任务不能启动处理案例 .41设备问题一、呼叫转移故障处理技术案例【网络拓朴】【现象描述】端点用户名为 AG58900, 07ON
4、U（R3.07.05.56） ，需要开通呼叫转接功能，软交换平台数据已做，用户在进行呼叫转接时，拨完*57*后有拨号音，继续输入转接号码时出现忙音。【处理过程】1、 通过命令行查看明确匹配及上报功能，确认没有打开；查看命令：Configprotocol# sh digNotify matched digit with type unambiguous :disableNotify matched digit delay :2552、 通过抓包分析软交换下发数图，发现数图定义不标准，如下图：在红框表示的数图中规定为EF0-90-9E.EF，表示前三位接受相关拨号后，第四位如果输入“*” （E 表
5、示*）或者“#” （F 表示#） ，都表示拨号结束，将立即上报所拨的号码，则 IAD 收到“*57*”后就把号码上报给软交换平台了，如下图：这样就造成拨号没有结束就上报了号码，导致转接不成功。3、 和软交换平台协商，把数图改为EF0-90-9E.F 后问题解决。【故障分析】数图的定义不符合标准。由于某些软交换是这样配置的，故我公司后期软件也将更改可以符合这种不标准的数图。【相关资料】二、未知包引起语音断断续续故障处理【网络拓朴】组网主图【故障分析】在没有上 15-onu 之前，在网运行 AN516-02 (OLT)，下挂 2 台 07B 型 ONU，共开通语音业务 29 户、数据业务 1 户，
6、至开通业务以来，没有用户报障情况。但新近加装 15-onu 后（开通 96 户语音，15 户数据） ，07B 和 15-onu 下的用户都出现了“外线拨打 15-onu 下的用户号码，被叫方听语音正常，主叫方听语音出现断断续续的现象，即上行方向有阻断” 。通过如上图所示 红点处抓包分析的结果来看当 15-onu 与外线通话时，确实存在 RTP流丢包情况。在 RTP 流建立之前，15-onu 与软交换平台的信令流交互过程中，信令包正常而且完整，可以排除线路问题和网络丢包情况。如下图所示：凡是从平台-ip 到 15-ip 的 RTP 流都没有丢包，即下行方向，15-onu 下用户听对方语音是清晰的
7、。而从 15-ip（10.33.210.26）到平台-ip 的 RTP 流出现了不同程度的丢包情况，严重时达到 43.0%，即上行方向，外线用户听 15-onu 下业主的声音，就出现了断断续续的情况，故障原因即为：15-onu 上行方向 RTP 流丢包所致。【故障具体原因】经技术人员对抓包数据的进一步分析表明：当 15-ip 向上发 ARP 包时（10.33.210.26 ping 10.33.210.1） ，目的 MAC 地址是 00:00:5e:00:01:c9 。但网关-ip 返回的包中（10.33.210.1 回复 10.33.210.26） ，源地址是 00:1a:f0:67:76:
8、74 ，与前面的目的 MAC 地址不一致。通常情况下，我公司 15-onu 上 AC16 盘的 MAC 地址表中是一个 IP 对应一个 MAC 地址，但现场实际的情况是同一个 IP（10.33.210.1）对应了两个 MAC 地址，使得 AC16 盘认为上层回复的包都是未知的包，即 unknown 的包，同时也认为与 MAC 地址 00:1a:f0:67:76:74对应的上行方向语音包也是 unknown 包。通过与相关人员沟通，出现一个 IP 对应两个 MAC 地址的情况是上层的贝尔 7750 路由设备出于主备保护的原因，特意作此设置的。由于我公司推出的 15-onu 属于 FTTC 型，0
9、7B 属于 FTTB 型，前者在设计时，考虑其128 户的最大接入能力，通过其 FSWB 盘实现：广播包抑制功能、多播包抑制功能、unkonwn 包抑制功能，避免在内网出现广播风暴、病毒攻击时出现设备端口被冲死的情况。所以在白天业务繁忙时，15-onu 下多个用户拨打或接听电话时，其内部会产生大量unknown 包，当达到设定门限时，unkonwn 包抑制功能启动，丢弃了这些 unkonwn 包（具体数量根据当时的通话线数而定） ，而这些包实际上是用户正常通信的语音 RTP 包，所以上行语音出现断断续续的情况，是因为这些 RTP 包被当作 unkonwn 包抑制了。为什么对原 07B-onu
10、产生影响？实际上，15-onu 在设计上沿用了 OLT 的方式，可以把它看做一个小型的 OLT，都具备广播包抑制功能、多播包抑制功能、unkonwn 包抑制功能。07B 属于 FTTB 型，它自身没有 unkonwn 包抑制功能，而 15-onu 出厂默认的 unkonwn包抑制数量是 150 个/s，一旦超出，就出现该故障现象，这也是为什么每天 17：00 之后，业务量减少后，故障现象消失的原因。（1） 当两型号都在同一 PON 口下时02-OLT 可以插 16 块 EC2 盘，每盘 2 个 PON 口，共 32 个 PON 口，它们相互隔离，unkonwn 包抑制是按照每个 PON 口来工
11、作的。当新上的 15-onu 与两台 07B-onu 共 PON口时，如果 15-onu 上的 unknown 包数量没有超过 15-onu 的门限，onu 就会放它继续上行，但在该 PON 口通道内，再加上从 07B 上来的 unknown 包（自身不具备抑制功能） ，两者一叠加，数量就有可能超过 02-OLT 的 unknown 包抑制门限值，所以两种型号 onu 上都出现故障现象。（2） 当两型号 onu 分别在两个 PON 口下时07B 下有 29 户，15-onu 下有 96 户，所以当 15-onu 上话务忙时，unknown 包越限，15-onu 自己就抑制了，控制了未知包的继续
12、上行。这时 02-OLT，主要面对的就是 07B上来的 unknown 包，因 07B 下同时通话超过限制的几率相对 15-onu 较低，所以分开到2 个 PON 口下，07B 就没有被影响。【处理过程】把 02-OLT 和 15-onu 的 unknown 包抑制门限从 150 改为 1500，相当于可同时让 50 线语音用户通话不受影响，故障现象已排除。三、关于 07 型 ONU 出现的误摘挂机的情况说明最近在几个省份陆续出现了 07 型 ONU 在下挂智能电话或是较高级的其他类型的电话是出现误摘机的现象。1. 主要现象如下：主叫正常，被叫时振铃一声就自动断掉了。换成别的话机就是正常的。出
13、故障时从抓包来看在振铃 0.6s 后，出现了 al/on 的挂机信号如下图在 5.3s 时 ONU 上报摘机，但 5.9s 却自动上报了挂机。之间只有 0.6s 的时间，明显不是人为挂机。 （MGCP 协议也有类似的情况）2. 原因分析：出现故障的话机一般为智能话机或功能较多的高级话机。此类话机工作时所需要的电流主要来自两个方面，一是本身自带的电池或电源，二会从电话线上取得一部分电流。这样问题就出现了。正常情况下，在用户没摘机的情况下，电话线上是没有电流的。但出故障的高级电话，由于自身工作的需要会从电话线上取得部分电流，而此时在电话没有摘机的情况下，电话线上却有了电流，于是我们的 onu 根据
14、线路上有了电流这一点判断认为用户已经摘机，故放了 al/of 摘机信号，但此时电话实际是没有摘机的，属于误判摘机，所以响一声就断了。3. 解决方法：研发提供了升级包，主要是提高了 ONU 对摘机的判断门限。目前主要针对故障 07onu进行升级解决，正式软件 3 月 20 日之前将释放，等待软件正式释放后再大面积升级。四、关于北京清河局 OLT2_4003 外层 VLAN 用户拨号 676 错误报告1、现象描述1 月 18 日清河局第二框 AN511602 设备出现所有外层 vlan 为 4003 的用户，PPPOE 拨号均返回 676 错误的问题。2、分析过程 仅外层 vlan 为 4003
15、的用户受到影响； 经过查看主交换盘的 mac 地址表发现 vid 为 4003 的 BRAS mac 地址学习到了槽位端口上，导致所有外层 vlan 为 4003 的，目的 mac 地址为 BRAS 的单播数据流发送目的地错误； 怀疑是用户家外接网络发生环路或者用户电脑中毒，通过查看 onu mac 地址表的方式找到了发生问题的用户端口，确定用户； 后发现用户家 ONU 下挂路由器的两个端口用网线连接形成环路导致下行方向BRAS 发出的报文又环回到设备，进一步引起系统 mac 地址学习发生错误。解决用户外接环路后，业务回复正常。4、 解决办法最终解决方案：建议通过配置远端 onu 过滤规则的方式解决该问题。操作步骤如下：用户仅需操作第一步。第一步：在网管上配置过滤规则，过滤规则为源 mac 地址等于 BRAS mac 地址（如果有多个 BRAS 需要配置多条） ；第二步：设备收到配置后会自动对当前所有在线 onu 进行配置，所有从用户侧端口收到的源 mac 地址为 BRAS mac 地址的数据包均被丢弃；第三步：对于以后上电的 onu 或者以后新增的 onu，系统会在该 onu 上电注册后自动将过滤规则下发。
