1.在处理陆家嘴、外金分局的多起FTTH疑难故障申告中发现，用户上联OLT配置的数据、97配置的数据和RADIUS配置的数据都是一致的，但用户实际上线的端口却不是97对应的端口，导致用户上网验证错误691。维护中心通过NOC转报故障处理未果后，进一步对故障进行分析研究发现，此类用户都在IBP中存在“移先装”和“移后拆”两张工单，在流程中可能存在了一个拆机端口的判断错误。随后，维护中心立即将情况说明和相关系统截图再次上报NOC和企业信息化部，最后企业信息化部确认在系统开发中存在软件的流程缺陷，修正后重新上线，解决了此类用户的申告，确保“移先装”和“移后拆”业务流程的正常流转。
2.本月在张川分局现场支撑处理城市光网故障时,发现有部分用户上网网页打不开,本地连接设置DNS也不行.查看OLT SFU和E8/C设备数据配置下发都没有问题,光功率测试正常.更换局端光模块无效,最后恢复SFU的出厂默认配置然后重新输入SN号,网页可以正常打开.初步分析为SFU的MTU(最大传输单元)值没有生效,导致本机数据包无法通过,这应该属于个别SFU的问题,如果数量多了会及时与厂商联系解决.
3.本月外金分局东沟和曹路OLT下各发生一起ONT长发光导致所在PON口下其他用户同时断线的故障。以东沟发生的故障为例:维中在现场通过逐级测试，最终查找到有故障的ONT。在为用户更换ONT时发现故障ONT所用的电源变压器与同型号新设备所附带的变压器不一致，仔细比较后发现用户用的变压器规格是12v 1.5A，而正确匹配的应该是12V 1.0A。在更换了新的ONT和电源变压器后故障消失，其他FH用户全部正常上线。通过这个案例可以发现平时在安装和维修时多注意一下设备及其配套附件的一致性，可以减少一些障碍的发生。
PS:如果某个ONT的光模块处于常发光状态，会占用全部上行时隙，导致同一OLT端口下的其他ONT全部瘫痪。这类现象只有在ONT光模块出现异常或者个别用户恶意入侵系统才会发生。
4.城市光网用户日益增多,申告宽带网速不达标的数量不少,目前缺乏权威的电信级的测试标准测试手段,面对用户的质疑很为难.建议提交公司相关管理部门能牵头制定提供相应的测试手段和测试标准,为一线维护人员处理申告投诉提供依据,为城市光网大发展提供坚实基础.
5. 周家渡OLT 05下有光交接箱搬迁后跳纤错乱导致PON口业务中断的故障，事后专业室同监控平台对故障原因和故障判断处理方法进行了分析交流，并在维护中心内部部署了FTTH割接管控措施,同时与业务管控室，NOC 和线路局相关领导进行了沟通。同时也希望公司网运能建立一套普遍适用的FTTH光路割接搬迁后的确认流程办法。
6.陆家嘴民生OLT5下发生一起某一ONT弱长发光与同一光分下的其它ONT信号产生叠加,造成这些用户线路连接不稳定,网络时好时坏.此故障现象与ONT强长发光的不同,影响范围是同一光分下的用户,之前未曾遭遇此种案例。目前OLT上对弱发光也没有提供明确的告警指示,处理起来颇费时间,还需要在维护中不断积累.
7.本月张川分局和三林世博分局反映部分平移用户帐号错的问题，经过IT部查证，由于平移后，新的ad账号没有刷新到CRM里面，造成用户后面申请新业务，就会把老ad发下去，用户业务就断了。经过IT部对这部分用户进行全量刷新，问题得以暂时解决。
8. 北蔡华为OLT10下光网用户拨打”50””20”开头的电话号码听回铃音时延长,在号码后面加拨#则正常，然而有部分用户对此做法不认可。华为厂商的说法是其全网统一下发的数图中缺少”50””20”字段,如果用户拨打”50””20”开头的电话号码则默认使用长定时器，要修改数图并在全网使用需要NOC统一协调安排。后来北姚湾华为OLT02下也出现用户申告该故障,经协调华为厂商,针对FTTH用户的新数图方案已生成，待EPON网管补丁升级后，即可以及时更新。另外我们将向NOC交换中心和总师建议后续现网新增号段，能够提前通
知厂商修改，最好是和交换中心软交换的数图同步更新（现网在用的SFU上的原数图就是从中兴软交换上获取的），这样可以随时和软交换保持一致.
9.本月张川分局陆续报出用户申告IPTV回看点播卡,组播业务使用正常.经查询均为MDU设备下用户,线路指标正常.联系IPTV技术支撑远程抓包分析单播码流未见异常,但在处理过程中发现远程PING机顶盒的一段时间内未见节目卡的故障现象,初步判断报文交互有问题.于是我们远程登录MDU查看MAC地址老化时间设置,参数设置为10秒,改成300秒后故障现象随即消除.在点播业务的使用过程中,当单播查询交互时间超过MAC地址老化时间，就会引起断流，直到交互重新建立。由于MDU设备的MAC地址老化时间默认是300S,而开局时施工验收人员为了加快验收速度，将老化时间改小，验收完毕却没有将参数改回造成用户申告。因此相关部门在施工验收时要对该情况保持关注，现场测试验收完毕要将参数改回正常值。
10.龙博公寓ONU000039连续三天节点DOWN,测试光路及检查MDU设备都正常,查看OLT 上告警信息发现该MDU被去激活,通过分析MAC地址列表,发现MDU有一个端口有环路,如果MDU的环路检测机制没有开启,出现环路就会导致MDU被去激活;如果MDU的环路检测机制开启,出现环路就会导致网管上该节点状态时好时坏,但并不影响业务.所以先将出现环路的MDU端口去激活,然后上门协调用户一起排除环路,再激活用户端口,该类故障得以解决.
11.北蔡OLT4、陈家弄OLT1下用户IPTV在晚上21：00~23：00直播点播卡，经厂商现场抓包分析为云莲7810-B1受到未知单播包的影响，导致其下联OLT的FH用户申告，通过厂商在OLT上配置单播抑制和NOC在汇聚交换机上实施优化方案来修复故障
12. EIP000012755，EIP000007210，EIP000006136，EIP000008845，EIP000006440等施湾中兴OLT4下FTTO用户线路频繁断线.现场测试光功率正常，中兴厂商在OLT上起三层接口PING光猫正常。分局在用户端单机PING网关和DNS丢包严重.NOC查看上联设备LOG 信息，发现东昌7609-8/8端口有翻转记录,查看收光衰耗较大(光路较长),于是NOC决定更换长距离光模块,而不是切换到施湾中兴OLT4另一上联金桥7609-8/8（备用）端口上面去,最后故障由NOC修复.
13.故障现象：本月有分局报张江孙桥地区有FH用户和北蔡华中路EPON用户以及民生171 民生192EPON用户出现上网中断或PPPOE有死进程故障处理：首先维中专业室登录OLT 查看PON口性能参数和各类告警信息，均未发现相关的PON口有翻转现象，PON口下面连接的MDU没有翻转现象。在97数据库查询到PVC绑定都集中在e320-jsh-2/2-0-2和e320-jsh-2/3-0-2，于是报NOC技术支撑查看金生E320/2 BAS设备状态，确认BAS板卡不好需更换板卡。
14.本月，陆家嘴分局出现一FTTH故障VLAN，BAS和97不对应问题，整个过程比较复杂，WX10-00390147至NOC也流转多日，各部门网管一时也无法分析问题原因，维护中心从IBP看出来用户有从民生0LT07到0LT08的装，移，拆业务，装，移，拆过程中存在着连锁错乱，再次通过WX至信息化部调整后修复。之后，维护中心请NOC和信息化部对该故障进行分析跟踪，最后信息化部定位为系统BUG，于是修改了源程序，确保今后不会再有该类故障问题。
15.陈家弄OLT6下多台MDU的语音不好问题
陈家弄OLT6下多台MDU（ONU002005、ONU002095等）的语音不好，查看H248接口均为‘等待响应’状态，几台MDU上都PING不通语音网关地址。在OLT上查看，OLT有时可PING通故障的几台MDU语音地址，有时PING不通，查询ARP表，发现对应几个IP
地址的MAC是同一个，典型的MAC漂移.最后华为厂商查出北姚湾OLT6的上联有问题（暂无业务），0/17/0和0/18/0主备保护上行，但是这两块ETHB板的级联状态异常（估计是没插级联线，还有ETHB上行口角色为级联），导致MAC漂移，将该OLT ETHB的单板绑定和主备保护删除，VLAN 41只和0/17/0绑定（不绑0/18/0）故障MDU恢复，但是过了几分钟，又出现故障，手工强制将0/18/0去激活，故障未再重现！
16.三林世博分局反映不同局站下FTTH用户有申告上网无规律性丢包,丢包达6～7%以上,且晚上高峰时段出现问题频率较高,丢包率在10%以上,有的甚至上网中断达到10分钟左右才又自动恢复,更换SFU、E8-C、光分端口也无明显效果.维中专业室查看OLT数据时发现PON卡的配置类型与实际类型不一致,这样会导致用户上网不稳定,也会影响IPTV业务的使用,通过远程升级PON卡能解决问题.之后维中专业室将这一情况告之NOC,请NOC对浦东局的所有中兴OLT进行查看,有类似问题的及时处理.
17.华夏OLT01更换机框修复PON口故障
本月有分局上报华夏路860弄部分FTTH用户有家庭网关无法绑定问题，维护中心专业室选择了一家申告用户的信息在华夏中兴OLT01 PON口下接SFU设备进行测试分析，发现该用户接在SFU下可以正常使用PPPOE拨号，但无法打开网页，PING公网地址存在70%以上的丢包，初步判断故障和家庭网关无关，另外，由于是批量问题，我们把问题关注到了OLT。在维护中心尝试对OLT设备更换光模块，插拔PON板和更换PON板无效后，最后与厂商一起更换了OLT机框修复了故障。
18.本月，三林世博家园出现部分GPON用户组播黑屏现象，经过维护中心和ALCATEL厂商多次查证，该问题为OLT存在软件BUG，临时解决办法为重做数据，但用户端可能出现故障反复，ALCATEL厂商已经针对该问题出台升级OLT版本，由NOC进行对设备进行升级。
19.本月明华OLT03出现IPTV组播卡现象，华为工程师查看并重置数据后可暂时修复，但之后故障现象还会在其他PON口出现，华为工程师认为可能设备在开局过程中数据没有完全加载，导致出现该类故障现象，后对该OLT所有PON板均进行数据重置，没有再出现类似申告。同时华为厂商还称目前OLT存在一个已知的组播问题BUG,可通过相关补丁解决。
20.高行中兴OLT光模块死锁问题
本月安装人员到(EIP000007477)用户处施工，现场测得光功率-20db，但光猫无法激活，NOC 看不到设备在线。故安装人员报分局支撑。分局修理人员在光交上接光猫，也无法激活。到高行传输机房高行T1/ZTEC220-OLT02 高行T1/PON01/2/3/4/PON口上接光猫还是无法激活，但光功率正常。报维中处理，维中查看该光分下所有ONT均无法注册上线，与厂商沟通后，初步判断为光模块可能存在死锁现象，后插拔光模块后修复。
21.花木OLT06问题
问题描述：一小区内HG255d通过ITMS平台下发配置，下发进行到一半便提示”工单处理失败”。
定位过程：1）确认通过手动配置上网业务可以使用。
2）HG255d侧抓包，发现ITMS侧手工工单HG255d无法收到。
3）HG255d上报0boot，ITMS可以发现设备，但HG255d收到504错误响应。
无法正常交互TR069报文。
4）问题只在某一小区内发生，确认HG、SFU无问题后，怀疑为OLT单板问题导致。
处理结果：更换OLT单板后问题解决。
22.关于E8-C用户看组播黑屏问题分析
故障现象：三林分局新装E8-C用户看IPTV组播黑屏，点播回看均正常。
故障分析：先咨询外线安装现场组网情况为：中兴OLT-中兴F401-中兴H618C家庭网关，要在家庭网关上面实现宽带上网、IPTV功能，然后查看OLT相关配置发现下发给F401的配置中启用了组播剥离方式，将此功能关闭后IPTV组播业务恢复正常。
pon-onu-mng epon-onu_0/1/2:62
no Forbid-auto-dispatch
no Forbid-auto-dispatch voip
sla-profile apply default
vlan port eth_0/1 mode transparent
multicast vlan port eth_0/1 add vlanlist 51
multicast vlan tag-strip port eth_0/1 enable //将这个命令改成disable
故障原因：目前实现组播有两种常见方式(1)跨VLAN组播(2)组播剥离。根据目前电信组网标准下挂家庭网关的情况是由家庭网关来实现组播剥离，所以F401与H618C只有一方需要组播剥离即可实现IPTV组播业务，问题就出现在F401开启了组播剥离，下面的H618C 在ITMS平台下发的配置也启用了组播剥离，两者同时出现就会导致组播出现问题，只需要关闭其他一方的组播剥离功能就能解决IPTV黑屏问题。
故障总结：碰到FTTH组播问题时候可以分以下几步来分析问题：
(1)咨询现场设备的组网情况。
(2)咨询现场要实现的业务和相关配置规范。
(3)检查OLT侧相关数据是否正确。
23.最近发生两起IPTV用户机顶盒无法获取IP地址
一起是大量中兴A类OLT用户下的PON+DSL的用户，无法在机顶盒获取IP地址，其他区局都有类似问题，NOC在网络侧未发现问题，中兴公司后来处理后故障现象消失，据了解是中兴厂商MDU设备参数问题引起，具体故障分析报告还待中兴厂商发布。
另一起是东昌，沈家宅，民生等大量DSLAM用户发生无法获取IP地址，后查证是上联汇聚交换机7810侧上联网络出现故障，NOC切换光链路后修复。
另外公司层面特别关注IPTV质量问题，并由互联网部，NOC和阿网管公司轮番对张董家的IPTV质量进行持续跟踪测试，目前NOC测试结果网络层面未发现异常，互联网部测试发现存在少了媒体包丢包现象，并进行了一些流量并发控制，POP点扩容，磁盘检查等相关工作。阿网公司则推出机顶盒Qos测试平台，可通过相关历史数据分析跟踪IPTV的质量，为IPTV排障提供依据。目前各个区局已经有该平台相关账号进行试用。
24.关于一家用户影响整节点IPTV的故障
分局反映在三林145 POP点有多起IPTV故障，机顶盒报1302错误，IPTV网管PING用户机顶盒为严重丢包，初步判断为网络问题。维护中心立即联系NOC查看上联云莲汇聚交换机，发现了一个比较奇怪的现象，其对应的DSLAM端口下有一个MAC地址，学到了不同的IP，而且还在不同的IPVT VLAN中，后经分析，这个MAC是汇聚交换机上联的SR 地址，但汇聚交换机却从DSLAM侧学到了该地址，一定是下层的网络设备形成了环路。区局根据以上现象，记录了出现环路的MAC地址，进一步通过DSLAM侧查找，DSLAM设备是ZMIP64设备，在中兴工程师协助下，发现环路来自用户的6/39端口，立即在DSLAM 设备关闭了这个有问题的用户端口，使得整个节点的IPTV故障恢复。之后，再由分局联系到这家用户，确认用户端网络问题解决以后，开启端口。
25.本月，维护中心接到分局报修空港物流，王港新虹村，前进村等多个MUD语音时断时续，经过排查，现场设备运行状态正常，上联光链路测试正常，基本排除了设备本身故障，同时通过网管观测到设备有较多H.248链路告警，初步判断为OLT上联语音链路出现故障。维护中心一边将故障转到NOC，一边联系中兴厂商做进一步判断，经过中兴工程师检测，发现，OLT上联至语音网关存在大量丢包现象，而且，OLT上所学的MAC地址并非上联设
备7750的地址。维护中心继续联系NOC数据中心工程师查看7450和7750设备后发现，上述存在疑点的MAC来自一台孙桥的华为OLT06的设备。最后，维护中心联系到OLT建设部门工程公司，经判断，孙桥OLT06为故障发生前刚刚调测，在其上联语音捆绑链路中遗漏了一个重要的双链路聚合保护参数，添加该参数后，故障恢复。
上述案例故障影响面较广，查处难度较大，故障处理涉及多个部门，需要引起我们相关建设和维护部门的共同关注。
26.本月另一起语音问题故障是合庆朝阳村MDU设备语音用户在通话过程中有中断现象，维护中心在排查过程中一时无法捕捉到故障现象，即对设备进行了用户板和主控板的更换，结果故障现象依旧存在，之后，维护中心一方面联系NOC进行相关信令跟踪，一方面对设备的历史告警现象进行分析，发现历史告警中有多次出现了MDU温度上限超过70度门限和设备冷启动告警，经过和中兴厂商工程师分析，实际现场的MDU温度为41度，不存在设备过热问题。初步判断可能由于MDU设备机框的温控探头故障，导致设备冷启动，在冷启动的过程中产生端口复位现象，导致用户端出现中断。更换机框后并连续数日观测，目前设备运行正常。
上述案例现象比较罕见，是中兴厂商硬件设备问题，目前已经把换下的设备返回中兴厂商作进一步分析。
27.大量ZTE EPON升版问题
为了使中兴FTTH用户的开通使用符合E8-C业务规范，进行了OLT和ONU强行升级，由OLT将语音VLAN转换成46的统一VLAN，同时修改用户端ONU设备语音VLAN配置。由于97信息不全，用户ONU离线以及部分D420设备版本较老等原因，造成向用户侧ONU 数据下发失败，引发大量用户申告。申告过程中大部分问题由中兴厂商远程配置用户数据解决，并做梳理后将剩余离线用户和版本较老的问题下发分局外线上门处理，因为点多面广，陆续申告持续将近一周，用户申告数超过1000。
上述问题在各大区局升级过程中都有发生，浦东属于第二批升级的区局，也是用户量最多的区局，接下来还要进行华为EPON设备的升级改造，公司具体实施计划还在酝酿中。
28．关于外金分局EIP000007414 新装无法注册的解决办法
（1）EIP000007414 用户位于曹路局下一FTTO用户，其上联位于外高桥D 华为OLT01-4-2 PON口，光分位于曹路局下面的某光交接箱，外线安装发现在用户侧ONU无法注册，光功率为-17DB, 但在光纤经过的曹路局加上光分设备后也能够注册，分局携带车载电源至光分侧进行测试，在光分的上联口能够注册，在光分下联则无法注册，光功率正常。
（2）分局上报维护中心，经过和厂商沟通分析，发现该用户实际光路为外高桥D-高行-曹路-光交-用户，实际距离已经超过20KM, 目前华为OLT设备PON口默认的设置最大传输距离是20KM的，所以导致用户侧无法注册。
（3）华为OLT在PON模式下是可以实施最大传输距离的修改，经过把默认的20KM修改为30KM后，用户侧就可以注册了。（华为厂商称，修改OLT PON口最大传输距离，会对整个PON口的带宽利用率有一定影响，但对实际用户的速率没有影响，默认20KM是一个比较合理的模式）。
工作提示：
（1）这是发现OLT PON口最大传输距离的问题，因此分局要在安装设备的过程中，发现接收光功率正常，但传输距离超过20KM无法开通的情况下，需要联系NOC传输实施OLT PON口的最大传输距离的参数修改。
（2）这也是我们早期工程建设立项中存在的问题，在非常长的光链路后级建设光分，实施FTTO覆盖，随着目前OLT局点的增多，建设中应该尽可能避免光路过长问题。
29.在PON+DSL的固定IP专线故障处理和FTTH故障处理中,存在故障点难以定位,WX流转无章可循,各个网管部门互相扯皮现象时有发生.比方说经过一番太极推手后总算搞清楚PON+DSL的固定IP专线业务要开通,有多个部门需要在网络设备上配置参数，其中有些需要手工配置，有些是电子工单，如果电子工单下发不成功，导致数据没有配置，维护人员难以快速作出判断（如何知道是工单下发不成功），而NOC网管业已形成的口头禅：“查看设备正常，请区局自查”，让区局维护人员感觉很“痛苦”，一般情况下区局都是自查好了才去麻烦NOC的同志们,何况身旁还有用户的不依不饶啊。希望相关职能管理部门在大力发展新技术新业务的同时，各种细化的维护流程能紧密跟随，指导员工和各部门相互配合，提高维护效率，提升用户感知。
30．浦东局LN2201336762 为PON+LAN用户，安装一直出现错误691，WX（10-00154464）至信息化部和NOC平台均未解决问题，经询问NOC平台朱惠龙，称该业务账号为58209773@shtel 这类账号带后缀shtel 在E320 设备上是无法通过认证的，经确认58*****@shtel开头的账号为数码通LAN的账号，不属于PON+LAN账号，所以，需要97发新的账号工单给RADUIS, 请信息化部重新分配正确的帐号后类似的用户故障得以解决.
31．故障现象：德平路某FTTH用户有VOIP业务，36379853 语音装不通，拨打该号码为正常回铃，SS侧观察用户已经正常注册。初步怀疑该用户的SIP用户名和密码在另外一家用户非法的ONT终端具有相同配置，并且另外一家非法用户已经抢先注册上线，导致该合法用户无法再次注册。
区局维护中心故障处理思路：
(1)通过BAC 设备,通过用户的账号36379853 跟踪注册上来的IP地址。
(2)通过DHCP服务器查到用户IP对应的MAC地址。
(3)通过MAC地址，在OLT上查找用户FH编号。
(4)通过FH编号在97中查找非法上线用户名称地址。
(5)联系非法上线的用户，本地登录ONT,删除冲突的SIP用户名密码配置。
(6)验证合法用户业务
区局维护中心故障处理过程:
( 1)线务员发现故障，区局通过WX报到NOC传输和软交换。
( 2)区局询问华为公司EPON技术人员张亮，称无解决办法，除非能找到非法用户的MAC 地址。
(3)区局询问中兴公司EPON技术人员罗颂，称BAC服务器侧是可以查找SIP用户的注册IP地址的，技术可行。区局询问数据中心邓明昊，称ITMS的DHCP服务器目前归属信息网络部，可咨询朱海霞
(4)区局询问信网朱海霞，称ITMS服务器由邱晓雨这里可以查.
(5)区局询问邱晓雨称DHCP服务器上可以通过IP地址查到MAC地址，技术可行
( 6)区局通过NOC一时也无法找到BAC管理人员。
(7)区局询问工程公司马谷雨，称中兴公司姓熊的工程师可属于管BAC的
(8)区局联系中兴熊工，称NOC有位陈志伟的工程师可以执行相关操作。
(9)区局联系陈志伟，根据用户名36379853查到了非法用户注册的IP地址
(10)区局联系信网邱晓雨，进过ITMS服务器查看LOG信息，由于DHCP服务器LOG信息只能保存前20分钟的日志，故无法查到对应的MAC。
(11)信网邱晓雨联系NOC王晓文，从对7609网关设备看ARP表项上查到了对应的MAC地址，并报给了区局
(12)区局联系华为技术人员阮顿康，根据MAC地址从对应的明华OLT-01中找到了对应的FH编号。
(13)区局根据FH编号，在97系统中找到非法用户的家庭信息，到现场登录ONT,删除相关非法数据。
(14)NOC 软交换钱益华工程师联系区局，称查到用户注册的SIP端口为5061（一般主用的SIP端口为5060）
(15) 区局现场沈斌查看合法用户ONT配置，发现配置了5060，电话使用正常。联系NOC WX 结障。
几个需要关注的地方：
(1)上述故障由于FTTH业务都是数据自动激活，外线无需在ONT配置业务数据，但是一旦配置数据在自动激活中出现错误，就会出现故障。
(2)为什么会出现错误，如何确保数据自动激活的准确性，目前还需要相关部门专题研究。
(3)一旦出现了错误，该如何改正，目前各个部门之间都存在相互协调的问题，区局在这个过程中没有对应的流程可依，没有部门能实施全程管控。可谓是费尽心机，到处求人，锲而不舍。
(4) 若出现大面积自动激活下发错误的极端情况，大量用户集中申告，我们将要以何种手段应对？一定还需要一系列的技术和流程进行完善。
32．高行OLT下大量FTTH用户语音业务使用不正常
2010年5月23-25日接到浦东高行03、高行05、曹路01、3个OLT下面多个FTTH语音中断问题报障，现象为电话无法正常拨打，做主叫时拨完号码听忙音，做被叫时提示忙音。远程登陆F420的WEB页面查看VOIP状态为已注册，能ping通SS地址，这时设备如果重启或者重新下发语音用户名密码后均能恢复正常，但一下报出几十个用户故障情况比较特殊。现场故障分析：
当天晚上跟F420开发人员到达高行绿地威谦小区90号702室用户家中对问题F420进行故障定位，现场查看F420的POTS1灯是亮的表示线路1是激活状态，在页面查看SIP帐户也是已注册状态，直接在用户话机进行拨号测试，F420也能正常将号码送给SS，但SS回了404错误，原因是SS认为这台F420是不在线的，所以F420上报的号码消息被SS认为权限错误.SS回404错误是因为在SS平台上号码36371725是不在线的，但F420上面显示状态在线，正常在这种情况下F420在300秒周期内应该要重新向SS发起注册动作，但在出问题的F420进行底层打印消息和抓包当中发现在300秒过后没有向上发起注册动作，但用户拨号的INVITE消息能正常发出。
为了能复现问题，我们对已恢复业务F420进行了多次测试：
（1）重启VOIP服务后业务恢复正常，等待300秒后发现F420能正常向SS发起注册消息。（2）删除PON接口(这是模拟如果DHCP的VLAN改变导致IP改变的情况)，F420在新的PON接口拿到IP后能重新注册上SS，语音业务正常。
（3）拨掉光纤5分钟后再接上光纤，F420能重新注册上SS，语音业务正常。
（4）在B200上面把36371725这个用户踢除掉，F420在周期过后也能重新注册上SS。
问题处理结果：
为了尽快恢复业务，将高行03、高行05、曹路01、3个OLT的PON板进行了重启，F420在离线之后会重新向上发起注册，现业务全部恢复正常。
存在的问题：
（1）问题都集中在高行03、高行05、曹路01这三台OLT上面，其他OLT没有发现类拟问题，OLT版本与F420版本现网都是一样的，配置也是一样。
（2）在某些特殊环境中F420无法正常向SS发起周期性注册信息。
SS侧账号状态：
SS侧显示故障处用户账号处于离线状态。
分析情况：
（1）现场打开设备信令跟踪，摘机拨号后，可以看到设备能正常发送Invite消息到SS侧，但是由于SS判断用户处账号已经处于离线状态，所以对于终端发起的Invite消息回复了404消息，拒绝用户呼叫，用户听忙音。
（2）现场打开设备信令跟踪和调试log，跟踪故障点信令交互和log日志。发现跟踪30分钟（超过注册刷新周期：300秒)，终端侧一直都没有发起注册刷新消息，也没有收到SS侧的心跳消息及其它交互信令。
（3）重启设备或重新从网管下发用户账号数据后，业务恢复正常。
从故障现象和故障信息分析，故障的原因是由于终端长时间不发起注册刷新消息，导致SS 侧认为用户账号处于离线状态，用户侧的呼叫请求和被叫请求都被SS侧拒绝。分析可能是由于终端侧发起的注册刷新消息后，收到了异常的响应，导致终端进入一种异常的状态，而不再发起注册刷新消息。
中国电信SIP规范中的注册流程：
在注册消息交互中，终端发起的注册消息中携带了expires字段，该字段表示用户账号注册的生命周期，单位是秒
SS收到后，会判断该expires字段值是否在SS侧设置的注册生命周期上下限区间内，有如下三种情况：
如果小于下限，那么回复423错误；
如果在区间内，那么回复200OK消息，并在200OK响应中携带该expires字段的值，指示终端注册的生命周期，终端应该在注册周期内发起注册刷新消息；
如果大于上限，那么回复200OK消息，并在200OK响应中把expires字段值修改为上限值。中国电信SIP规范中的注册刷新消息流程：
在正常注册上以后，终端以注册刷新消息来判断同SS侧连接是否正常。如果终端发起的注册刷新消息，由于网络延时或丢包等原因，导致SS侧没有收到或是没有收到SS侧的响应
消息，那么在事物重传机制后，将切换到注销状态，并尝试向备用SS注册。如果备用SS 无法注册，则再向主用SS注册，不断进行切换，直到注册成功。
在正常注册上以后，SS以心跳消息（OPTIONS）来判断用户账号是否在线。如果SS发起的心跳消息，由于网络延时或丢包等原因，导致终端侧没有收到或是没有收到终端侧的响应消息，那么SS就认为用户账号离线，就会拒绝该用户的请求消息。