What does ISDN Error code Cause i = 0x8A90 means
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2011 03:27 AM - edited 03-19-2019 02:41 AM
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.
|
- Labels:
-
UC Applications
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2011 03:55 AM
Hello,
Is it ok if you share the Show run from the VXML gateway and the Ingress gateway ?
Amer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2011 10:44 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2011 11:27 AM
Could you please tell me how find whether the request for disconnect was received from Service provider or some internal components.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2011 11:29 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2011 07:49 PM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-07-2011 10:27 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-08-2011 06:31 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-08-2011 08:01 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-08-2011 08:50 AM
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.
