10-01-2010 07:46 AM - edited 03-16-2019 01:07 AM
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
10-01-2010 08:16 AM
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.
10-01-2010 04:23 PM
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
10-02-2010 06:02 AM
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.
10-02-2010 06:26 AM
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
10-02-2010 06:29 AM
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.
10-02-2010 11:20 AM
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
10-03-2010 04:13 PM
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.
10-04-2010 08:52 AM
Also make sure you are configured for the correct ISDN switch type.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide