CSOFTX3000重要问题知会.docx
- 文档编号:7251332
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:13
- 大小:34.89KB
CSOFTX3000重要问题知会.docx
《CSOFTX3000重要问题知会.docx》由会员分享,可在线阅读,更多相关《CSOFTX3000重要问题知会.docx(13页珍藏版)》请在冰豆网上搜索。
CSOFTX3000重要问题知会
目录
作者信息iii
修改记录iii
1EPI端口查询显示“信号位丢失”,开2M信令链路不成功问题4
1.1问题描述4
1.2问题版本4
1.3产生原因4
1.4规避措施4
1.5解决方案5
2同一个子路由下两个SIP中继出局只能选择一个的问题5
2.1问题描述5
2.2问题版本5
2.3产生原因6
2.4规避措施6
2.5解决方案6
3拨打国际漫游用户发生前转后,前转话单中的主叫号码错误6
3.1问题描述6
3.2问题版本7
3.3产生原因7
3.4规避措施7
3.5解决方案7
4SIP入局PRA出局呼叫模型下DTMF收号失败7
4.1问题描述7
4.2问题版本8
4.3产生原因8
4.4规避措施8
4.5解决方案8
5印度Syham监听概率性失败问题8
5.1问题描述8
5.2问题版本9
5.3产生原因9
5.4规避措施9
5.5解决方案9
6LSTSCTPPORT中的端口协议类型错误问题9
6.1问题描述9
6.2问题版本9
6.3产生原因10
6.4规避措施10
6.5解决方案10
7LSTN7DSP、DSPN7DSP显示信令点信息不一致问题10
7.1问题描述10
7.2问题版本11
7.3产生原因11
7.4规避措施12
7.5解决方案12
8菲律宾跨V100R003C02B053SPH007版本升级补丁后发现附着用户数下降问题12
8.1问题描述12
8.2问题版本12
8.3产生原因12
8.4规避措施13
8.5解决方案13
9埃及MOD局点从V1R6C03版本升级到R7C01版本因呼叫源表未配置MSCID导致PRA中继入局呼叫失败14
9.1问题描述14
9.2问题版本14
9.3产生原因14
9.4规避措施15
9.5解决方案15
作者信息
作者
严杰43723
Date
2010-03-01
测试
Date
审核人
Date
签发人
Date
修改记录
文档版本
修改说明
发布日期
作者
签发
V1.00
初稿完成
2010-01-20
严杰
V1.01
补充修改
2010-3-1
严杰
本文针对C9产品2009年12月、2010年01月、02月发生的重要问题,预警和其他一些注意事项进行说明,并给出规避措施,建议各局点按照说明和规避措施进行改进,本文规避方法中引用的参考文档请在进行规避操作前仔细阅读。
本次沟通针对的版本为CSOFTX3000R3、R6、R7C01在网版本。
1EPI端口查询显示“信号位丢失”,开2M信令链路不成功问题
1.1问题描述
现网开2M信令链路不成功,操作过程如下:
1、修改了CPC扣板上的链路(MML命令是MODCPCCFG),从64K链路修改成2M链路了;
2、重启过单板(执行命令rstbrd)。
3、修改后,查询N7LNK的状态是空闲,故障;
4、修改后,查询E1端口状态是信号位丢失,E1端口软件环回不成功,操作超时。
网上问题单号:
200910310032
1.2问题版本
CSOFTX3000V100R006C02SPH016及以前所有版本
1.3产生原因
SMU的单板配置信息表中记录2框2槽EPI单板的“模块号”和“节点号”全为无效值FF,从而2框2槽EPI收不到SMU下发的消息,EPI的的状态信息也发送不到SMU板,从而SMU上存储的E1端口状态得不到更新。
该问题由于定位信息不足,未找到导致SMU的单板配置信息表中记录异常的根本原因。
1.4规避措施
在空闲槽位增、删一块CSU和EPI板,SMU就会重新更新这个表,可以解决该问题。
1.5解决方案
补丁实现本地单板配置信息表的自我恢复功能:
当SMU向EPI下发消息失败,失败原因是单板配置信息表中相关数值无效时,自动根据单板描述表信息进行刷新单板配置信息表,实现其自我失效后的恢复功能。
同时,在可能产生问题的地方加上相关的打印以方便彻底定位问题。
CSOFTX3000V100R006C02SPH017版本合入该问题上述解决方案。
2同一个子路由下两个SIP中继出局只能选择一个的问题
2.1问题描述
一个路由下面分两个子路由,子路由1使用ISUP中继,子路由2使用SIP中继,且该子路由下面有两个SIP中继群。
但子路由2第二个SIP中继群没有话务占用。
现在的问题是对SIP中继群1和2在子路由1中是轮选的,但是从话统来看,出局不能选SIP中继群2。
咨询问题单号:
Q20091218003
2.2问题版本
CSOFTX3000V100R006C02SPH015
2.3产生原因
此问题是B059已知问题,已经在CS7.1中修改,具体问题分析如下:
设置非信令优选和必选并且打开了最短中间串路径软参P137的情况下,选择中继群时会遍历路由下所有的中继群以便选择一个最短中间串的网关。
SIP中继群选路:
在得到中继群号后,会进行主被叫网关的选择和中间串的选择,此后系统错误的保存此次选路结果,在遍历下一个中继群时,同样会更新选路结果,这样就造成最终选择的中继群是该子路由下的最后一个中继群,从而导致轮选失败。
非SIP中继选路:
由于不会每次循环都保存选则的中继群,而是只是保存第一次选择的中继群,在循环过程中,如果有更短的中间串路径则会对选路结果进行更新,如果各个中继群下对应的网关间的中间串路径都一样长,则会进行中继群的轮选。
2.4规避措施
规避方法有如下两种:
1、修改P137号软参的值为0,缺点会导致其他类型的中继群也不能支持最短路径。
2、修改路由分析,把信令优先级修改为SIP优选。
建议采用方法2。
2.5解决方案
CSOFTX3000V100R007C01版本中已经修改。
R6版本不修改,采用规避方案解决。
3拨打国际漫游用户发生前转后,前转话单中的主叫号码错误
3.1问题描述
拨打国际漫游用户发生前转后,前转话单中的主叫号码错误。
网上问题单号:
20091223001
3.2问题版本
CSOFTX3000V100R006C02SPH016及以前版本
CSOFTX3000V100R007C01SPH103及以前版本
3.3产生原因
1、触发条件:
(1)拨打本局用户且用户发生国际漫游;
(2)被叫用户触发无应答前转;
(3)本局将国际TLDN按国际号码字冠配置为PSTN出局。
2、问题影响:
前转话单中主叫号码填写错误导致计费错误。
3、产生原因:
由于匹配为PSTN出局,MSCe会以出局的被叫号码(此时实际为TLDN)填写前转话单中的主叫号码,导致前转话单中主叫号码为TLDN而不是MDN。
3.4规避措施
无
3.5解决方案
当呼叫国际漫游用户且此用发生前转时,以被叫号码的MDN填充前转话单中主叫号码。
CSOFTX3000V100R006C02SPH017版本合入该问题上述解决方案。
CSOFTX3000V100R007C01SPH104版本合入该问题上述解决方案。
4SIP入局PRA出局呼叫模型下DTMF收号失败
4.1问题描述
MSC1 MSC2
UMG1 ----sip----->UMG2 ---pra--->PBX
在上图所示呼叫模型中,对于MSC2是SIP入局、PRA出局,在呼叫接通后进行DTMF收号失败。
网上问题单号:
201001110121
4.2问题版本
CSOFTX3000V100R006C02SPH016及以前所有版本
CSOFTX3000V100R007C01SPH103及以前版本
4.3产生原因
该问题是PRA模块处理缺陷导致,具体如下:
(1)MSC在建立中间串端点时已经下发了2833编解码。
(2)入局SIP模块编解码协商过程中:
收到alert消息后,向CCB回了bear_info,CCB将消息透传给PRA。
现网问题中,bear_info消息中的编解码和当前中间串使用的编解码是一致的,PRA模块并不需要下发MODCHAR操作,但PRA错误的下发了MODCHAR,且该操作中没有带2833参数。
CRO给H248的MODCHAR操作中,判断业务层没有带2833指示,因此也没有下发2833参数,从而UMG认为CSX指示关闭2833,导致呼叫DTMF收号失败。
4.4规避措施
修改SIP入局的路由,通过TDM方式入局规避该问题。
4.5解决方案
修改PRA模块缺陷,在PRA判断bear_info消息中的中间串编解码和当前使用的中间串编解码是否不一致时,如果编解码一致则不下发MODCHAR操作。
CSOFTX3000V100R006C02SPH017版本合入该问题上述解决方案。
CSOFTX3000V100R007C01SPH104版本合入该问题上述解决方案。
5印度Syham监听概率性失败问题
5.1问题描述
印度Syham局点在验收监听时,当监听输出方为本局移动号码时,监听出现概率性的失败。
咨询单号:
无
5.2问题版本
CSOFTX3000V100R006C02SPH012版本
5.3产生原因
印度Syham局点在验收监听时,当监听输出方为本局移动号码时,监听输出方CM在接通后,执行MOD_REQ操作修改承载为双向,CRO返回失败后,监听输出方CM即给CCB发送拆线消息,监听输出方异常拆线,导致监听出现概率性的失败。
5.4规避措施
根据现网情况,如果只配置一对CCU模块将不会发生该问题。
5.5解决方案
CSOFTX3000V100R006C02SPH018版本合入该问题解决方案。
CSOFTX3000V100R007C01SPH105版本合入该问题解决方案。
解决方案如下:
监听输出方CM在PB的时候识别到当前为监听输出方则设置streammode为send/receive,后续收到CONNECT消息时若识别为监听输出方则不再修改被叫端点的收发能力为send/receive。
6LSTSCTPPORT中的端口协议类型错误问题
6.1问题描述
LSTSCTPPORT中的端口错误,H248和M2UA的部分端口,变成了IUA协议端口。
咨询单号:
Q20091207002
其他局点也出现过该问题。
6.2问题版本
CSOFTX3000V100R006C02SPH012版本
6.3产生原因
tbl_SCTPProtocolCfg(SCTP协议配置表)的如下升级路径升级脚本中,为了升级后支持“协议类型”和“服务模式”两个字段,直接把升级后所有记录的“协议类型”置为了1(IUA),把“服务模式”置为了0(Client)。
(1)R002C02B052-R003C01B011,中英文版本均存在问题
(2)R002C03B062-R003C01B016,中英文版本均存在问题
经确认,该局点确实从V100R002C02B052版本升级到R3,再从R3升级到R6,经过了R002C02B052-R003C01B011路径,因此导致了该问题发生。
影响分析:
经平台确认,tbl_SCTPProtocolCfg表虽然格式化到主机,但主机不会使用。
因此,该问题仅影响后台LSTSCTPPORT命令查询结果,不影响业务。
6.4规避措施
无。
6.5解决方案
CSOFTX3000V100R006C02SPH018版本合入该问题解决方案。
CSOFTX3000V100R007C01SPH105版本合入该问题解决方案。
解决方案如下:
对于tbl_SCTPProtocolCfg(SCTP协议配置表),需要根据数据库记录中的“本地IP地址+本地端口号+对端IP地址+对端端口号”去匹配各宽带链路(IUA、M2PA、M3UA、M2UA、H248、SUA)中的地址数据得到该链路实际的链路类型、服务模式来刷新该表中“协议类型”和“服务模式”两个字段。
R2版本中无M2PA和SUA,可以不考虑这两种链路。
7LSTN7DSP、DSPN7DSP显示信令点信息不一致问题
7.1问题描述
尼日利亚某局点新建N7局向,链路一直起不来,跟踪链路消息,发现接收到的SLTM消息中,OPC和DPC都没有问题,是我们配置的信令点;但是发送出去的SLTM消息,OPC和DPC都不对。
1、LSTN7DSP,查询结果和配置一致;
2、DSPN7DSP,查询结果和LSTN7DSP不一致。
DSPN7DSP查询结果中DPC信令点是SGU11的信令点,SGU11信令点原来在3000上配置为ISUP局向,通过STP转接;后来将3000到STP的连接由TDM切换成IP后,已经在N7DSP表中删除该局向,配置在M3DE表中。
3、检查配置,没有发现任何问题,校验前、后台数据,没有错误。
咨询单号:
Q20100107001
其他局点也出现过该问题。
7.2问题版本
CSOFTX3000V100R006C02SPH017及以前版本
CSOFTX3000V100R007C01SPH104及以前版本
7.3产生原因
根据现网的操作描述,实验室进行了镜像测试,复现了该问题。
具体过程如下:
1.ADDN7DSP,目的信令点点码为A,且此信令点必须为非相邻点。
2.ADDSCCPDSP,目的信令点也为A。
3.ADDM3DE,目的信令点也为A,也就是说到远端点是双承载的。
4.RMVN7DSP,删除目的信令点为A的远端点。
5.ADDN7DSP,目的信令点B,此信令点没有限制。
此时问题就复现,LSTN7DSP时,显示的信令点为B,但DSPN7DSP目的信令点为B时,显示出来的信令点还是A,而此时A已经配置在M3DE中了。
该场景和现网的场景完全一致。
进一步分析导致上述结果的原因如下:
如果某N7DSP信令点同时存在M3DE和SCCPDSP时,会在MTP3业务相关DPC表存在对应的记录。
但是产品存储过程在执行RMVN7DSP删除N7DSP点时,没有预先删除“MTP业务相关目的信令点表”对应该信令点的记录。
当命令下发到主机MTP3协议栈时,协议栈内部会判断该信令点是否在“MTP业务相关目的信令点表”中有对应记录。
如果存在对应记录的话,则协议栈并不删除此N7DSP信令点,从而就导致了产品侧和MTP3协议栈中此N7DSP信令点数据不一致。
LSTN7DSP命令查询结果来自BAM库后台数据,属于产品的数据信息;DSPN7DSP命令查询结果来自主机MTP3协议栈数据。
因此,会出现查询结果不一致的情况。
7.4规避措施
规避方案:
当发现某个索引的N7DSP有此问题,通过增加一个垃圾N7DSP数据把此索引占上,后续再增加其他N7DSP数据就没有问题。
7.5解决方案
CSOFTX3000V100R006C02SPH018版本合入该问题解决方案。
CSOFTX3000V100R007C01SPH105版本合入该问题解决方案。
解决方案如下:
修改删除N7DSP命令的存储过程。
增加判断删除的记录是否被上层引用,包括通配的情况。
如果在MTP业务相关信令点表中有对应记录,则该信令点从MTP信令点表删除时需要先删除MTP业务相关信令点表中的记录。
对于现网已经存在问题的数据配置,该方案同时提供MTP业务相关信令点表数据修复功能。
请按照补丁说明书进行操作即可。
8菲律宾跨V100R003C02B053SPH007版本升级补丁后发现附着用户数下降问题
8.1问题描述
菲律宾从V100R003C02B053升级补丁到V100R003C02SPH023后,通过话统发现附着用户数下降,用户应答率从50%降到27%左右,并且被叫不能正常振铃。
咨询单号:
无
8.2问题版本
CSOFTX3000V100R003C02B053SPH007
8.3产生原因
该问题由于CSOFTX3000V100R003C02B053SPH007补丁中修改导致。
菲律宾现网用户签约的漫游类型为区域漫游,需要在位置登记是携带LAC信息给HLR(华为HLR),否则HLR会拒绝位置登记。
也就是说MSCe位置登记时不携带LAC信元必然导致用户位置登记不成功,VDB置用户状态为去活态,造成VDB中用户数量下降。
同时,也导致此类用户做被叫时无法成功。
在V100R003C02B053SPH007补丁之前,位置登记时MSCe是否携带LAC信息是由华为一卡多号License和功能软件控制的。
但在V100R003C02B053SPH007补丁中修改了该控制条件(见问题单AS8D04334),认为REGNOT消息中携带LAC不应该收到华为一卡多号LICENSE的限制,LAC在协议里为可选信元,不应受到和特性相关的限制,于是增加软参了P260bit4,用于控制MSCe给HLR发送的位置登记请求消息中是否携带LAC。
默认值为1,表示不携带;为0表示携带。
查看菲律宾现网配置发现华为一卡多号License和功能软参均开启,说明补丁升级前,位置登记时MSCe会携带LAC信息给HLR。
升级到V100R003C02SPH023补丁后,位置登记是否携带LAC由P260bit4控制,该软参默认值不携带,结果导致用户位置登记失败,出现补丁升级失败问题。
由V100R003C02B053SPH007之前版本直接升级到R6、R7版本也会出现该问题。
8.4规避措施
升级后根据现网配置修改P260Bit4软参取值,如果升级前位置登记时携带LAC,则执行如下命令
MODMSFP:
ID=P260,MODTYPE=P1,BIT=4,BITVAL=0;
8.5解决方案
CSOFTX3000V100R006C02SPH018版本合入该问题解决方案。
CSOFTX3000V100R007C01SPH106版本合入该问题解决方案。
解决方案如下:
R3版本已经EOS,不再输出补丁。
需要在R6、R7升级指导书中增加配置说明,如果存在该问题则提示升级完成后修改P260BIT4的取值。
9埃及MOD局点从V1R6C03版本升级到R7C01版本因呼叫源表未配置MSCID导致PRA中继入局呼叫失败
9.1问题描述
2010年2月8日晚埃及MOD局点升级从V1R6C03版本升级到R7C01版本,PRA中继入局失败。
咨询单号:
无
9.2问题版本
CSOFTX3000V100R007C01SPH104及以前版本
9.3产生原因
升级后PRA中继入局呼叫失败问题是由于入局中继群引用的呼叫源表中未配置MSCID信息导致。
V1R3C02B042之前的版本对于入中继呼叫,如果入中继群引用的呼叫源表中未配置MSCID信息,无论是汇接还是落地CCB直接拆除呼叫。
V1R3C02B043版本进行性能优化,性能优化前后软件判断条件不一致,如果入中继群引用的呼叫源表中未配置MSCID信息,呼叫可以正常进行(潜在存在一些问题:
PSTN入局呼叫MTC话单中未填写主叫MSCID信息、入局主叫被监听,上报的主叫用户的MSCID信息不正确、PSTN入局触发CFNA业务不成功)。
中国电信一期使用V1R6C02B059版本开局时发现该问题,经讨论后裁决在V1R7C01版本中修改,和V1R3C02B042版本保持一致(如果入中继群引用的呼叫源表中未配置MSCID信息,无论是汇接还是落地CCB直接拆除呼叫)。
目前在研版本V2R7C02和V2R7C03版本保持和V1R7C01版本保持一致(入局呼叫中继群表对应呼叫源中不配置MSCID拆除呼叫)。
目前在网的CPCI主力版本是V1R3C02B053和V1R6C02B059,且这两个主力版本的处理保持一致,即入局呼叫,入中继群引用的呼叫源表中未配置MSCID信息,呼叫可以正常进行。
但从V1R3C02B053/V1R6C02B059版本升级到V1R7C01版本,都存在升级后入局呼叫失败的风险,严重影响升级前后对外表现。
9.4规避措施
在对应入中继引用的呼叫源表中配置MSCID。
9.5解决方案
在V1R7C01补丁、V2R7C02和V2R7C03版本中回退,保持和现网主力版本V1R3C02B053、V1R6C02B059保持一致,同时修改帮助文件的描述(对于入局呼叫,MSCID信息必须配置)。
同时在V1R6及后续版本的HCT工具中增加对应的检查项,在升级前或者例行检查中发现该问题,提前进行规避处理。
CSOFTX3000V100R007C01SPH105版本合入该问题解决方案。
此后,从R3、R6升级到V100R007C01SPH105及后续按本将不存在该问题。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CSOFTX3000 重要问题知会 重要 问题 知会
![提示](https://static.bdocx.com/images/bang_tan.gif)