肇庆公司5月通知音跟新相关故障报告.DOC

漏定通知音导致个别音轨不能正常放音 案例背景 根据集团公司 2 月初发布的《关于更新与规范中国移动现网录音通知的通知》，肇庆网络维护中心在4月对肇庆全网元10个MGW（分别存在R5\R6版本）进行通知加载和更新，同时开发了OPS小工具测试以快递进行整改测试。在此过程中，发现现网3个MGW中有两条通知音存在异常情况。即根据相应播放条件拨打，没有通知音播放。 通知音是用户在使用移动网络能直接感知的信息，根据集团要求，需要定制统一的通知音，如果现网端局通知音不一致，会严重影响用户感知。 问题案例描述 4月28日凌晨，在对1月入网的ZQM08、ZQM09、ZQM10进行通知音加载时，发现ANNC为8170和8370的通知音上存到MGW后，进行监听没有听到任何放音，把正常能听到这两个音轨音的MGW3通知音文件拷贝过来，监听后仍然不能听到放音。查看通知音规范和工单，确定该通知音是现网应该具备的。8170的内容是：“对不起，同一号码每月最多可代为他人充值10次，请您使用其它号码为本机进行充值，谢谢合作。”8370的内容是：“A single phone number can only make ten payments to other numbers each month. If you wish to proceed with this payment please use a different phone number。” 分析与对策 通知音的产生可分为2类： 局数据直接指定 通过交换机的局数据定义，在对用户主/被叫号码分析的时候，直接将呼叫指向一通知音源，进行通知音播放。 此类通知音如：拨打紧急号码112的通知音和升位通知音。 交换机内部错误代码产生 在呼叫过程中，因某种原因，交换机拒绝呼叫或者释放呼叫，交换机将产生错误代码，局数据依据错误代码，指向相应的通知音源，进行通知音播放。 此类通知音如：用户关机空号等通知音，该类占交换机通知音大部分，爱立信交换局的错误代码为EOS（End of Selection）通知音产生的接续过程如下： 1、用户在呼叫过程中由于出现了某种错误导致呼叫终止，在交换系统内会产生一个导致呼叫失败的cause value，交换机会根据此cause value在相关的交换节点产生相应的EOS（End of Selection）,或者叫终选码。 2、得到相应的EOS之后，如果需要播放通知音，经E表分析后转到B表。 3、假如需要放音，将会在B表99源（录音通知机分析源）进行分析，得出RC。 4、经过RC表分析（ANRSI）后选择相应的TCIA（TCIAL/TCIAR）路由，进入TCIA功能块分析，产生ANNC，和User Function预定义的ANNC发送给功能块AUIF，在AUIF进行ANNC analysis，把ANNC翻译成listening or recording route（EXAUI:ANNC=…,R=TRAC/REC;），占上TRAC或REC路由。 5、再经过子路由R1，占用通知音设备主路由，一般MAST录音通知机有32个设备与主路由连接，主路由根据通知音选择相应的设备进行占用，从而进行录音或播放通知机包含的通知音。 MSC-S会把普通通知音或智能网通音的语音号（ANNC）和通知音变量（智能网通知音才有，变量对应于年月日、圆角分等变量）使用GCP命令下发给MGW，MGW得到ANNC号后会查找得到对应的通知音（MESSAGE_ID，MESSAGE_ID = ANNC）。肇庆R5版本的MGW： ZQM01,ZQM02,ZQM03,ZQM04,ZQM05,ZQM06,ZQM07; R6版本的MGW: ZQM08,ZQM09,ZQM10,ZQM11。 1).核查MGW 在OSS上查询广州其他一些R6版本的MGW，发现有些MGW有以上两个通知音的相关数据，有些没有。 下面以GZM35和GZM36为例,GZM35是有做8170的数据，而GZM36却没有。 图表 2—GZM35 图表 3—GZM36 然后我们核查了一下本地的其他R5版本的网元，发现除了ZQM08、ZQM09、ZQM10,其他都有配置8170和8370的数据。 图表 4—ZQM03 2).核查SERVER 再检查MGW上联的SERVER数据，用指令： EXAUP:MSGH=H’240,MSGL=H’14;------------8170 EXAUP:MSGH=H’280,MSGL=H’14;------------8370; 发现除了GZS23（与湛江共用一个SERVER）上做了数据外，肇庆其他的MGW上联的SERVER都没有做相关数据 。之所以GZS23有相关数据，是湛江制作MGW通知音时增加了该通知音数据。 图表 5—GZS23 最后