【摘要】有几条专线做主叫时经常拨打电话不成功，拨打完成号码后，电话经常会自动挂断，引起网络的接通率低。
　　分析过程
　　小交换机在采用逐号发送时，有时发送过来的号码是11位，被叫号码齐全，但主叫号码会变成乱码。
　　对于逐号发送的模式会引起收号不全或者主叫号码乱码，最终导致呼叫失败，那么就对小交换机的发号模式进行修改，修改成整体发送。
　　由以上信令可以看出此次呼叫成功，在SETUP消息里面可以看到小交机发送过来的主叫号码是5788328，被叫号码是13692796308。
　　修改小交机发送号码的模式后，主叫号码没有变成乱码，小交换送过来的号码也是11位，号码收全，所以呼叫正常。
　　3、初步定位是由于发号模式的问题引起呼叫失败，而逐号发送号码的模式怎么就会引起被叫号码收号不全及主叫号码变成乱码的呢？而且此交换机一直都是运用逐号发送的模式，怎么现在才引起呼叫失败呢？鉴于这些问题，就要对此呼叫失败的原因再进一步的进行分析。
　　4、对此专线的Q921消息进行跟踪，发现此专线的信令链有些异常。正常的信令是只发送RR的测试消息的，但这条专线的信令是在发送一段时间RR消息后，对端会回复一条INVALIDFRAME信令，然后又是发送RR信令。
　　传输整改后，信令链的信令消息正常。由以上分析的过程可以看出此次呼叫失败的原因是由于传输误码引起CRC校验不成功，当小交换机采用逐号发送的模式时，会使对端发送过来的部分号码丢失，引起呼叫失败。
　　处理过程
　　传输对此专线的线路进行整改，整改后专线的信令链消息正常。而且再把专线更改回来逐号发送的模式，也不会出现呼叫失败的现象。
　　总结
　　对以上专线呼叫失败的处理，最后定位出专线呼叫失败的原因是传输有误码，而不是专线的逐号发送模式引起。
　　对于一般专线呼叫失败时，首先要核查是移动网络还是铁通网络引起的呼叫失败，在中创中查询呼叫记录，查看是由哪端网元发起拆线消息，此次呼叫失败在中创中根本查不到相关的呼叫记录，那么说明此次呼叫时没有经过铁通的网络，排除了铁通引起呼叫失败的可能性。其次是核查在移动的哪个网元引起呼叫失败，因为此次呼叫未经过铁通，那么此次呼叫也是未经过核心网的两个关口局，排除了核心网关口局引起呼叫失败的可能性。再次就是核查剩下的几个移动网元，由于HZAGW是在B表中定义数据，而B表是整个号段定义数据，如果此数据定义错误的话，就完全打不通电话，不可能有呼叫成功的可能性，所以又排除了HZAGW引起呼叫失败的可能性。最后剩下NGN及对端小交换机及NGN和小交换机所连接的传输可能会引起呼叫失败。在UGC中跟踪信令发现呼叫不成功的时候是因为对端小交换机送过来的号码不全或者主叫变成乱码而引起呼叫失败，而且在跟踪Q921消息的时候，发现对端有发送INVALIDFRAME无效帧消息。可能NGN在收对端发送号码的时候同时收到一个INVALIDFRAME无效帧引起收号不齐或者主叫号码变成乱码。但对端小交换机跟踪信令的时候发现号码已全部发送出去及发送的主叫号码也是正常的。是什么原因引起发送的信令与收到的信令是不一致的？可能是Q921中有INVALIDFRAME无效帧引起，但又是什么原因让信令链中有INVALIDFRAME消息呢？NGN和对端小交换机都没有发送这些消息，那么可能就是由连接两端的中间传输引起此问题。对传输的误码进行测试，发现传输的误码较高，尝试对传输进行整改，整改后，信令链没有再出现INVALIDFRAME消息，而且也未出现呼叫失败的情况。
　　经过此次故障的处理，总结出处理故障时要从根本上解决问题，而不要让故障的表面现象所迷惑。如果此专线呼叫失败的问题定位成是由于小交换机的逐号发送模式引起收号不全，最终导致呼叫失败，就会对小交换机的发号模式进行更改成整号发送，更改后会大大的减少呼叫失败的次数，让我们觉得更改后就不会出现呼叫失败了，偶而出现一次呼叫失败则可能定位成网络临时问题，这样的话最终还是没有解决根本的问题。而传输状态是正常的，信令链的状态也是正常的，而且也没有相应的告警，但传输有误码还是会引起呼叫失败，影响网络的接通率。所以在解决问题时，要找出引起问题的最终原因才能真正的解决网络问题。