富士通交换机不识别我司ISDN setup_ack信令的故障案例

富士通交换机不识别我司ISDN setup_ack信令的故障案例

一、组网：

 R3680E 4BS――――本地PSTN交换机――――――――R1604

       |

       |―――――异地PSTN交换机――――――――2 BS R2631E

 某电器公司中心使用我司的R3680E路由器，本地分支机构使R1604路由器，异地机构使用R2631E路由器，中间通过电信的ISDN线做备份互连。

 软件版本：R3680E 、R2631E  1.74-0105

                    R1604  VRP1.44-005

 二、故障现象：

三台路由器都使用典型的拨号配置――配置没有看出明显问题。但发现：

1、从中心拨本地分支正常；

2、从本地分支拨中心拨不通；

3、从异地分支拨中心拨不通；

4、从中心拨异地分支拨不通；

 三：初步判断：

先看版本，基本都是最新的VRP版本，没有发现异常。

配置是参考拨号典型配置做的，也没有发现明显异常。

由于故障现象1、2的两台设备之间互拨的不对称性，先把重点放在这两台路由器上，想到进行一下ISDN Q931信令的观测，看看同样在被叫侧观察到的信令有何不同。打开debug isdn q931 all调试信息开关。

四、进行对比：

将正常时的信令过程同不正常时的信令过程做个对比找出差异：

1）从中心拨本地分支正常的信令过程：

User

 Bri0

    N->U   DL_UI_DATA_IND  CES = 0

    cr= 01 70 SETUP  *bearer=04 02 88 90 *chan_id=18 01 89 *calling_n=6c 09 41 8

3 37 35 37 35 37 39 35 *low_l=7c 02 88 90

 Bri0

    U->N   DL_Establish_REQ  CES = 1

 

 Bri0

    N->U   DL_Establish_CFM  CES = 1

 

 Bri0

    U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 f0 CONN  *chan_id=18 01 89

 Bri0

    N->U   DL_I_DATA_IND  CES = 1

    cr= 01 70 CONN_ACK

%10:00:19: Line protocol ip on interface Bri0(Bri0:1), changed state to UP

[RFzSc4]

 

2）从本地分支拨中心不正常的信令过程：

[RFzFb]

 Bri2

    N->U   DL_UI_DATA_IND  CES = 0

    cr= 01 09 SETUP  *bearer=04 02 88 90 *chan_id=18 01 89 *calling_n=6c 09 41 8

3 37 35 31 31 32 30 32   //从网络侧到用户侧的信令，是PSTN给路由器的，该信令同正常信令bearer、 chan_id一致，calling_n是主叫号码，没有怀疑之处。

 Bri2

    U->N   DL_Establish_REQ  CES = 1  //路由器给PSTN侧的REQ消息

 

 Bri2

    N->U   DL_Establish_CFM  CES = 1  //PSTN侧给路由器的CFM消息，同正常信令完全一致，没有怀疑之处。

 

 Bri2

    U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 89 SETUP_ACK  *chan_id=18 01 89

  Receive call on interface Bri2:1 with caller num:7511202

 Bri2

    U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 89 CONN    //路由器连发的两个信令 setup_ack和CONN，都是对PSTN侧setup消息的回应消息，其中setup_ack 附带chan_id信息。而CONN信令不带参数。而正常过程回应的是1个CONN信令，带chan_id参数。从返回的消息类型和参数看，虽然返回的消息不一致，但附带的信息没有明显差别，应该都是正确的消息。

 Bri2

    N->U   DL_I_DATA_IND  CES = 1

    cr= 01 09 STATUS  *cause=08 03 82 e1 0d (Message type non-existent or not im

plemented) *call_state=14 01 06  //发现PSTN侧程控交换机返回错误代码，说明路由器刚回复的信令无法被程控交换机理解，认为存在问题。

 Bri2

    U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 89 REL  *cause=08 02 80 e5 (Message not compatible with call state)

 Bri2    //路由器发送给PSTN，对PSTN认为的某错误信息原因，做出拆线的决定（发REL）。

    N->U   DL_I_DATA_IND  CES = 1

    cr= 01 09 CONN_ACK  //PSTN侧对路由器发的CONN的一个回应。

 Bri2

    U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 89 STATUS  *cause=08 02 80 e2 (Message not compatible with call state

) *call_state=14 01 13

 Bri2

    N->U   DL_I_DATA_IND  CES = 1

    cr= 01 09 REL_COM  *cause=08 02 80 e5 (Message not compatible with call stat

e)

  Receiving disconnect  indication on interface Bri2

 Bri2

    N->U   DL_I_DATA_IND  CES = 1

    cr= 01 09 REL_COM  *cause=08 03 82 e5 7d (Message not compatible with call s

tate)

[RFzFb]

 

五：缩小范围：

把这段信令过程抽出来看：

     U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 89 SETUP_ACK  *chan_id=18 01 89

  Receive call on interface Bri2:1 with caller num:7511202

 Bri2

    U->N   DL_I_DATA_REQ  CES = 1

    cr= 01 89 CONN    //路由器连发的两个信令 setup_ack和CONN，都是对PSTN侧setup消息的回应消息，其中setup_ack 附带chan_id信息。而CONN信令不带参数。而正常过程回应的是1个CONN信令，带chan_id参数。从返回的消息类型和参数看，虽然返回的消息不一致，但附带的信息没有明显差别，应该都是正确的消息。

 Bri2

    N->U   DL_I_DATA_IND  CES = 1

    cr= 01 09 STATUS  *cause=08 03 82 e1 0d (Message type non-existent or not im

plemented) *call_state=14 01 06  //发现PSTN侧程控交换机返回错误代码，说明路由器刚回复的信令无法被程控交换机理解，认为存在问题。

 

判断这段信令存在问题。通过在中心路由器上配置 isdn ignore callednum命令，再次从分支拨测中心，在异地分支R2631E上也配置相同命令，问题解决。