What does ISDN Error code Cause i = 0x8A90 means

[venkatesh]

We are using 3945 gateway with CVP comprehensive model.

Issue: When the agents are on call with customer, the call is diconnecting in the middle of conversation.

Analysis: We enabled debug isdn q931 traces in gateway. We were able to see call disconnect cause as "Cause i = 0x8A90".

In the ISDN cause code details it is said that "8A = a network beyond the internetworking point".

I do not understand whether any component with customers network is triggering call disconnect or any component outside customer environment is causing the problem.

102713: .Mar 31 05:38:08.324: ISDN Se0/1/1:23 Q931: SETUP pd = 8  callref = 0x39E6

102714: .Mar 31 05:38:08.324: ISDN Se0/1/1:23 Q921: User TX -> RR sapi=0 tei=0 nr=25

102715: .Mar 31 05:38:08.328: ISDN Se0/1/1:23 Q931: Received SETUP  callref = 0xB9E6 callID = 0x3AA2 switch = primary-ni interface = User

102716: .Mar 31 05:38:08.336: ISDN Se0/1/1:23 Q921: User TX -> INFO sapi=0 tei=0, ns=44 nr=25

102717: .Mar 31 05:38:08.336: ISDN Se0/1/1:23 Q931: CALL_PROC pd = 8  callref = 0xB9E6

102725: .Mar 31 05:38:08.472: %ISDN-6-CONNECT: Interface Serial0/1/1:10 is now connected to 64677170 N/A

107762: Mar 31 06:04:03.501: ISDN Se0/1/1:23 Q921: User RX <- INFO sapi=0 tei=0, ns=15 nr=15

107763: Mar 31 06:04:03.501: ISDN Se0/1/1:23 Q931: DISCONNECT pd = 8  callref = 0x39E6

107764: Mar 31 06:04:03.501: ISDN Se0/1/1:23 Q921: User TX -> RR sapi=0 tei=0 nr=16

107765: Mar 31 06:04:03.501: %ISDN-6-DISCONNECT: Interface Serial0/1/1:10  disconnected from 64677170 , call lasted 1555 seconds

107766: Mar 31 06:04:03.501: ISDN Se0/1/1:23 Q921: User TX -> INFO sapi=0 tei=0, ns=15 nr=16

107767: Mar 31 06:04:03.501: ISDN Se0/1/1:23 Q931: RELEASE pd = 8  callref = 0xB9E6

107768: Mar 31 06:04:03.529: ISDN Se0/1/1:23 Q921: User RX <- RR sapi=0 tei=0 nr=16

107769: Mar 31 06:04:03.649: ISDN Se0/1/1:23 Q921: User RX <- INFO sapi=0 tei=0, ns=16 nr=16

107770: Mar 31 06:04:03.649: ISDN Se0/1/1:23 Q931: RELEASE_COMP pd = 8  callref = 0x39E6

[Amer rajai Sha'er]

Hello,

Is it ok if you share the Show run from the VXML gateway and the Ingress gateway ?

Amer

[Jonathan Schulenberg]

Analysis: We enabled debug isdn q931 traces in gateway. We were able to see call disconnect cause as "Cause i = 0x8A90".
In the ISDN cause code details it is said that "8A = a network beyond the internetworking point".

You're looking at the wrong byte. You should be looking at the 90 byte. The documentation states to drop the high-order bit which would make this a 10 hex or 16 decimal which represents a normal call clearing. Look at the direction of the DISCONNECT IE. Did you receive it or transmit it? If you received it the problem is not with the router you're looking at; it's upstream. If you transmitted it you should start following the problem downstream from the router. Whatever signaling protocol you are using to the call agent would be the next place to look.

[venkatesh]

Could you please tell me how find whether the request for disconnect was received from Service provider or some internal components.

[Jonathan Schulenberg]

It's right in the header of the debug isdn q931 output. TX means the router transmitted it while RX means the router received the request.

112982: Apr  6 13:29:00.631 CDT: ISDN Se0/1/1:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x3F09

        Cause i = 0x8090 - Normal call clearing

[venkatesh]

Jonathan - Thank you for sharing the information.

I was analyzing the logs for an call where i received cause code "0x8A90". In this i was able to find following information.

3915654: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q921: User RX <- INFO sapi=0 tei=0, ns=48 nr=61
3915655: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q931: DISCONNECT pd = 8  callref = 0x2BDA
Cause i = 0x8A90 - Normal call clearing
3915656: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q921: User TX -> RR sapi=0 tei=0 nr=49
3915657: Mar 31 07:56:13.827 PST: %ISDN-6-DISCONNECT: Interface Serial1/0/0:5  disconnected from 64677170 , call lasted 517 seconds
3915658: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q921: User TX -> INFO sapi=0 tei=0, ns=61 nr=49
3915659: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q931: RELEASE pd = 8  callref = 0xABDA
3915660: Mar 31 14:56:13.855: ISDN Se1/0/0:23 Q921: User RX <- RR sapi=0 tei=0 nr=62
3915661: Mar 31 14:56:13.979: ISDN Se1/0/0:23 Q921: User RX <- INFO sapi=0 tei=0, ns=49 nr=62
3915662: Mar 31 14:56:13.979: ISDN Se1/0/0:23 Q931: RELEASE_COMP pd = 8  callref = 0x2BDA

Does the 1st line indicate the disconnect request received from service provider end.

I have also attached complete log file with this entry.

[Jonathan Schulenberg]

What debug command are you using here? It should be 'debug isdn q931'. On my router this shows the directionality of the IEs in the log output; however, your output does not.

[mphasis]

Thanks a lot Jonathan. We are able to see the details only when we enable debug q931.

If we enable both q931 an q921, we do not get this information. Could you please check whether you are getting the details when both the debigs are enabled.

[Steven Holl]

j.schulenberg wrote:
What debug command are you using here? It should be 'debug isdn q931'. On my router this shows the directionality of the IEs in the log output; however, your output does not.

Yeah this is known behavior.  If you enabled q921, the direction of the message is reported in the associated q921 INFO message, instead of in the q931 message.

So for this:

3915654: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q921: User RX <- INFO sapi=0 tei=0, ns=48 nr=61
3915655: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q931: DISCONNECT pd = 8  callref = 0x2BDA
Cause i = 0x8A90 - Normal call clearing

That's the router receiving the Disconnect from the other side of ISDN.

Conversely, here is the router transmitting a release:
3915658: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q921: User TX -> INFO sapi=0 tei=0, ns=61 nr=49
3915659: Mar 31 14:56:13.827: ISDN Se1/0/0:23 Q931: RELEASE pd = 8  callref = 0xABDA

For most switchtypes, you can also look at the first byte of the callreference value.  That will change depending on the direction of the disconnect.  For this call, all messages will begin with 0x2 from the other side, and 0xa when we transmit out.

[Steven Holl]

And to answer your original question.  The provider is sending a disconnect with normal call clearing.  Likely, the PSTN user is hanging the call up.  If they aren't hanging up at the time the disconnect is sent from the provider to the CPE, then it's a telco issue.