cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1515
Views
0
Helpful
8
Replies

Call Disconnects

mike-greene
Level 4
Level 4

Hi,

I'm having issues with a number that comes from the PSTN via PRI and then on to UCCX.  If I call it ten times, five out of those calls just disconnect...no ring, on UCCX recording.  When the calls disconnect I see the below q931 errors.  I've got a TAC case open but the engineer does not seem to know what the problem might be.

.Sep 30 16:15:04.961: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0203
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98387
                Exclusive, Channel 7
        Calling Party Number i = 0x2181, '5127957145'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '5534'
                Plan:Unknown, Type:Unknown
.Sep 30 16:15:04.965: ISDN Se0/0/0:23 Q931: Received SETUP  callref = 0x8203 callID =
0x56F9 switch = primary-ni interface = User
.Sep 30 16:15:04.973: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x8203
        Channel ID i = 0xA98387
                Exclusive, Channel 7
.Sep 30 16:15:05.105: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x8203
.Sep 30 16:15:05.309: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x8203
.Sep 30 16:15:05.369: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x8203
        Cause i = 0x8090 - Normal call clearing
.Sep 30 16:15:05.369: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x0203
.Sep 30 16:15:05.369: ISDN Se0/0/0:23 **ERROR**: Ux_BadMsg: Invalid Message for call state
11, call id 0x56F9, call ref 0x8203, event 0xF
.Sep 30 16:15:05.369: ISDN Se0/0/0:23 Q931: TX -> STATUS pd = 8  callref = 0x8203
        Cause i = 0xC0E50F - Message not compatible with call state
        Call State i = 0x0B
.Sep 30 16:15:06.165: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x0203
.Sep 30 16:15:06.169: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x8203

I've looked all over and I can't find this cause code... any ideas?

Thanks,

Mike

8 Replies 8

afmmanicke
Level 1
Level 1

I've found this link to be very helpful in the past:
http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

Further options are:

Watch the connection with the RTMT.

Try a show controllers t1 check for slips.

Verify the layer 1.

Call the providor.

Good luck and have a good weekend.

Bruno Rangel
Spotlight
Spotlight

I think it's telco problem in the exchange you GW and with isdn swithc.

let us see the output result of commands:

sh e1 controll

sh isdn stat

sh isdn servi

Cheers
Bruno Rangel
Please remember to rate helpful responses using the star bellow and identify helpful or correct answers

paolo bevilacqua
Hall of Fame
Hall of Fame

Your router is disconnecting the call before the errors you have highligthed:

Sep 30 16:15:05.309: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x8203
.Sep 30 16:15:05.369: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x8203
        Cause i = 0x8090 - Normal call clearing

Consequently, you must disregard these errors, and look instead why your system is disconnecting.

Hi Mike,

Do post the following:

sh run

sh version

please try the following:

put the isdn sending-complete on the outbound serial interface, and see if that resolves the issue.

After adding this command, please post isdn q931 for a failed call again.

Regards
Kunal

kusatija wrote:

Hi Mike,

Do post the following:

sh run

sh version

please try the following:

put the isdn sending-complete on the outbound serial interface, and see if that resolves the issue.

That cannot help, because the failure is for incoming calls, not outgoing.

As i mentioned before, the OP must find why his UCCX system is disconnecting, lack of resources or what.

Paolo is right.

My bad, should have noticed that earlier.

But we still need the running configuration from the gateway.

How many calls are being routed through the gateway at that time?

I think a call manager trace would help, please set them to detailed and post a trace for a bad call with calling called party numbers.

HTH

Kunal

Right on Paulo.

We need to understand why UCCX disconnects the Call. We need to know the complete call flow. Please let the thread know about the same. Once the IP leg protocol you can take the relevant H.323/SIP/MGCP debugs to verify that once the call is Connect, do you get a RELEASE/BYE/DLCX on IP leg. If so the gateway is bound to Disconnect the call.

Trace the problem back from gateway to UCCX and troubleshoot one step up as you approach the exact point where the problem.


Also make sure you are configured for the correct ISDN switch type.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: