龙 伟
重庆邮电学院 信科公司 400065
摘 要： 对Ｓ１２４０交换机一次呼叫转移命令不成功故障排除的过程进行了分析。
关键词： 交换机； 呼叫转移； 字冠分析
贵州一个县局反映通用电话号簿编号（ＧＤＮ：Ｇｅｎｅｒａｌ Ｄｉｒｅｃｔｏｒｙ Ｎｕｍｂｅｒ）用户加无条件转移的特服不成功，包括Ｍｏｄｅｍ在内，请求帮助解决。于是笔者受重庆邮电学院信科公司的委派去排除这一故障，现将排除这一故障的思路及处理过程回顾如下，与同行共探讨。
首先下了一条命令，进行加无条件转移功能的试验：
从报告中可以看出这是一个加无条件转移的ＧＤＮ用户，而不是一个普通用户，其转移号Ｋ＇７２６７３６９７００表示的字冠为Ｋ＇７２６，用户号码为Ｋ＇７３６９７００，但系统已提示用户号码不能加无条件转移的功能。为了进一步判断其问题所在，笔者试着对普通用户加一个无条件转移的功能，其转移的号码也用Ｋ＇７２６７３６９７００。
于是下了第二条命令：
＜４２９４?押ＤＮ＝Ｋ＇７３６１２４０?熏 ＣＦＷＤ＝ＡＣＴＩＶＡＴＥ＆ＣＦＷＤＵ＆Ｋ＇７２６７３６９７００．
结果仍没成功，系统的提示与第一次命令一模一样。
ＭＯＤＩＦＹ－ＳＵＢＳＣＲ ＮＯＴ ＳＵＣＣＥＳＦＵＬ
于是笔者怀疑Ｋ＇７２６７３６９７００可能有问题。就又试着将转移的号码改为普通号码，对ＧＤＮ再加一次无条件转移，其命令为：
这回成功了，证明Ｋ＇７２６７３６９７００的确有问题，但不知Ｋ＇７２６７３６９７００中是Ｋ＇７２６字冠有问题还是Ｋ＇７３６９７００号码有问题。为了证实这个问题笔者将转移的号码改为Ｋ＇７３６９７００，再次对ＧＤＮ加无条件转移功能，其命令是：
此命令也成功了，说明号码Ｋ＇７３６９７００没问题而Ｋ＇７２６字冠有问题。那么问题出在什么地方呢？笔者又用７９５命令对Ｋ＇７２６字冠进行显示：
没发现什么问题，笔者又用命令７１２及７４７３把每个目的地的任务显示了一遍，也发现什么问题。
为了进一步找到问题，笔者用其它字冠加上Ｋ＇７３６９０００号码再一次试着给ＧＤＮ加无条件转移功能,其命令是：
终于成功了。于是用７１５命令把字冠Ｋ＇０２１的目的地任务一个一个地赋予字冠ｋ＇７２６，每改一次，执行此人机命令一次，即：
待把Ｋ＇０２１的ＤＥＳＴＡＣＣ赋予ｋ＇７２６之后，此条命令也成功了，可见是ＤＥＳＴＡＣＣ有问题。其
比较这两个ＤＥＳＴＡＣＣ，唯一相同的是在ＯＲＧＤＥＰ为３时指向了一个释放任务，于是试着将ＯＲＧＤＥＰ为３时改为与ＯＲＧＤＥＰ为２时一样，指向一个路由块，再执行命令：
＜４３１６,ＧＤＮ＝Ｋ＇７３６２９０１, ＣＦＷＤ＝ＡＣＴＩＶＡＴＥ＆ＣＦ－
ＷＤＵ＆Ｋ＇７２６７３６９７００
就成功了，终于找到了问题所在，即呼叫转移不能转到有释放任务的ＤＥＳＴＡＣＣ。为此，笔者创建了一个没有中继的路由块，将ＯＲＧＤＥＰ为３的目的地任务指向这个路由块，以代替释放任务，问题就彻底解决了。
在解决这个问题的过程中，笔者采用了类比的方法，一步一步地把问题的范围缩小，直到把问题找到。这种方法还是十分有效的。
摘自天津通信技术